Customer VNet Integration

[SatyKrish]

We are looking for Docker replacement for hosting container workloads without the overhead of managing AKS cluster. Any plans to support integration with Customer VNet for deploying isolated workloads as Container Apps? All our services deployed on Azure are strictly accessible only from within Customer network (no Public IP).

[vturecek]

Yes, we will support bringing your own VNET in the very near future.

Currently, you can run Container Apps with HTTPS endpoints that are not accessible publicly, without bringing your own VNET, by setting the configuration.ingress.external to false (see: https://docs.microsoft.com/en-us/azure/container-apps/ingress?tabs=bash#configuration). But you won't be able to deploy other Azure resource into that VNET this way, so this is mainly used for microservices within a Container App Environment that need to communicate directly with each other.

[Phiph]

@vturecek Yes please, can't wait for this integration! Very interested in this, as the first thing I wanted to try is connecting to my Redis Cluster via a Private Link.

[mackie1001]

@vturecek Yes please, can't wait for this integration! Very interested in this, as the first thing I wanted to try is connecting to my Redis Cluster via a Private Link.

Ditto Cosmos DB with a dedicated gateway amongst other things.

[gpltaylor]

Can I please up-vote. We have many bare-metal in-house services that we expose over VNET/s.

I would like the ability to add multiple VNETs to the Container App Environment, where all containers with the ENV wound be granted access.

[bihe]

VNET Integration is needed for us to consider ACA for prod-usage. Our services need to access on prem resources via Express-Route. Very much looking forward to have a VNET possibility!

[onionhammer]

In light of ChaosDB, Azure should really be putting in the effort to allow their 'consumption' 'serverless' compute platforms talk to DBs behind firewalls.

[dewolfs]

Upvoting this feature request also. We would like to ingest ACA into our existing VNET.

[KaiWalter]

As we already spoke in our private preview onboarding call: My group cannot shift any workloads from Service Fabric or AKS without bring-your-own-VNET.

[takekazuomi]

Congratulations, it seems to have been released. I will try using it.
https://docs.microsoft.com/en-us/azure/container-apps/vnet-custom?tabs=bash&pivots=azure-cli

[krispenner]

Documentation doesn’t mention private endpoints or NAT gateways. Curious if private endpoints to Cosmos DB, blob storage and key vaults will work, and can a VNet NAT gateway be applied to the subnets?

[KaiWalter]

I removed and installed the extension again - containerapp-0.2.2-py2.py3-none-any.whl as there was no 0.2.3 and 0.3.0 - but could not se the Azure CLI parameter --app-subnet-resource-id mentioned here https://docs.microsoft.com/en-us/azure/container-apps/vnet-custom?tabs=bash&pivots=azure-cli#create-an-environment

...but there is such a parameter in Pulumi.AzureNative 1.55.0-alpha.1643762497

        var kubeEnv = new KubeEnvironment("env", new KubeEnvironmentArgs
        {
            ContainerAppsConfiguration = new ContainerAppsConfigurationArgs
            {
                AppSubnetResourceId
            },

I will give it a spin

[KaiWalter]

Documentation doesn’t mention private endpoints or NAT gateways. Curious if private endpoints to Cosmos DB, blob storage and key vaults will work, and can a VNet NAT gateway be applied to the subnets?

Private endpoints is what I want to test for our scenarios.

[tomkerkhove]

This is available in preview: https://techcommunity.microsoft.com/t5/apps-on-azure-blog/azure-container-apps-virtual-network-integration/ba-p/3096932