|
| 1 | +--- |
| 2 | +title: Networking architecture in Azure Container Apps |
| 3 | +description: Learn how to configure virtual networks in Azure Container Apps |
| 4 | +services: container-apps |
| 5 | +author: craigshoemaker |
| 6 | +ms.service: container-apps |
| 7 | +ms.topic: conceptual |
| 8 | +ms.date: 05/06/2022 |
| 9 | +ms.author: cshoe |
| 10 | +--- |
| 11 | + |
| 12 | +# Networking architecture in Azure Container Apps |
| 13 | + |
| 14 | +Azure Container Apps run in the context of an [environment](environment.md), which is supported by a virtual network (VNET). When you create an environment, you can provide a custom VNET, otherwise a VNET is automatically generated for you. Generated VNETs are inaccessible to you as they're created in Microsoft's tenent. To take full control over your VNET, provide an existing VNET to Container Apps as you create your environment. |
| 15 | + |
| 16 | +The following articles feature step-by-step instructions for creating Container Apps environments with different accessibility levels. |
| 17 | + |
| 18 | +| Accessibility level | Description | |
| 19 | +|--|--| |
| 20 | +| [External](vnet-custom.md) | Container Apps environments deployed as external resources are available for public requests. External environments are deployed with a virtual IP on an external, public facing IP address. | |
| 21 | +| [Internal](vnet-custom-internal.md) | When set to internal, the environment has no public endpoint. Internal environments are deployed with a virtual IP (VIP) mapped to an internal IP address. The internal endpoint is an Azure internal load balancer (ILB) and IP addresses are issued from the custom VNET's list of private IP addresses. | |
| 22 | + |
| 23 | +## Custom VNET configuration |
| 24 | + |
| 25 | +As you create a custom VNET, keep in mind the following situations: |
| 26 | + |
| 27 | +- If you want your container app to restrict all outside access, create an [internal Container Apps environment](vnet-custom-internal.md). |
| 28 | + |
| 29 | +- When you provide your own VNET, the network needs a single subnet. |
| 30 | + |
| 31 | +- Network addresses are assigned from a subnet range you define as the environment is created. |
| 32 | + |
| 33 | + - You can define the subnet range used by the Container Apps environment. |
| 34 | + - Once the environment is created, the subnet range is immutable. |
| 35 | + - A single load balancer and single Kubernetes service are associated with each container apps environment. |
| 36 | + - Each [revision](revisions.md) is assigned an IP address in the subnet. |
| 37 | + - You can restrict inbound requests to the environment exclusively to the VNET by deploying the environment as [internal](vnet-custom-internal.md). |
| 38 | + |
| 39 | +As you begin to design the network around your container app, refer to [Plan virtual networks](/azure/virtual-network/virtual-network-vnet-plan-design-arm) for important concerns surrounding running virtual networks on Azure. |
| 40 | + |
| 41 | +:::image type="content" source="media/networking/azure-container-apps-virtual-network.png" alt-text="Diagram of how Azure Container Apps environments use an existing V NET, or you can provide your own."::: |
| 42 | + |
| 43 | +<!-- |
| 44 | +https://docs.microsoft.com/azure/azure-functions/functions-networking-options |
| 45 | +
|
| 46 | +https://techcommunity.microsoft.com/t5/apps-on-azure-blog/azure-container-apps-virtual-network-integration/ba-p/3096932 |
| 47 | +--> |
| 48 | + |
| 49 | +### HTTP edge proxy behavior |
| 50 | + |
| 51 | +Azure Container Apps uses [Envoy proxy](https://www.envoyproxy.io/) as an edge HTTP proxy. TLS is terminated on the edge and requests are routed based on their traffic split rules and routes traffic to the correct application. |
| 52 | + |
| 53 | +HTTP applications scale based on the number of HTTP requests and connections. Envoy routes internal traffic inside clusters. Downstream connections support HTTP1.1 and HTTP2 and Envoy automatically detects and upgrades the connection should the client connection be upgraded. Upstream connection is defined by setting the `transport` property on the [ingress](azure-resource-manager-api-spec.md#propertiesconfiguration) object. |
| 54 | + |
| 55 | +### Ingress configuration |
| 56 | + |
| 57 | +Under the [ingress](azure-resource-manager-api-spec.md#propertiesconfiguration) section, you can configure the following settings: |
| 58 | + |
| 59 | +- **Accessibility level**: You can set your container app as externally or internally accessible in the environment. An environment variable `CONTAINER_APP_ENV_DNS_SUFFIX` is used to automatically resolve the FQDN suffix for your environment. |
| 60 | + |
| 61 | +- **Traffic split rules**: You can define traffic split rules between different revisions of your application. |
| 62 | + |
| 63 | +### Scenarios |
| 64 | + |
| 65 | +The following scenarios describe configuration settings for common use cases. |
| 66 | + |
| 67 | +#### Rapid iteration |
| 68 | + |
| 69 | +In situations where you're frequently iterating development of your container app, you can set traffic rules to always shift all traffic to the latest deployed revision. |
| 70 | + |
| 71 | +The following example routes all traffic to the latest deployed revision: |
| 72 | + |
| 73 | +```json |
| 74 | +"ingress": { |
| 75 | + "traffic": [ |
| 76 | + { |
| 77 | + "latestRevision": true, |
| 78 | + "weight": 100 |
| 79 | + } |
| 80 | + ] |
| 81 | +} |
| 82 | +``` |
| 83 | + |
| 84 | +Once you're satisfied with the latest revision, you can lock traffic to that revision by updating the `ingress` settings to: |
| 85 | + |
| 86 | +```json |
| 87 | +"ingress": { |
| 88 | + "traffic": [ |
| 89 | + { |
| 90 | + "latestRevision": false, // optional |
| 91 | + "revisionName": "myapp--knowngoodrevision", |
| 92 | + "weight": 100 |
| 93 | + } |
| 94 | + ] |
| 95 | +} |
| 96 | +``` |
| 97 | + |
| 98 | +#### Update existing revision |
| 99 | + |
| 100 | +Consider a situation where you have a known good revision that's serving 100% of your traffic, but you want to issue and update to your app. You can deploy and test new revisions using their direct endpoints without affecting the main revision serving the app. |
| 101 | + |
| 102 | +Once you're satisfied with the updated revision, you can shift a portion of traffic to the new revision for testing and verification. |
| 103 | + |
| 104 | +The following configuration demonstrates how to move 20% of traffic over to the updated revision: |
| 105 | + |
| 106 | +```json |
| 107 | +"ingress": { |
| 108 | + "traffic": [ |
| 109 | + { |
| 110 | + "revisionName": "myapp--knowngoodrevision", |
| 111 | + "weight": 80 |
| 112 | + }, |
| 113 | + { |
| 114 | + "revisionName": "myapp--newerrevision", |
| 115 | + "weight": 20 |
| 116 | + } |
| 117 | + ] |
| 118 | +} |
| 119 | +``` |
| 120 | + |
| 121 | +#### Staging microservices |
| 122 | + |
| 123 | +When building microservices, you may want to maintain production and staging endpoints for the same app. Use labels to ensure that traffic doesn't switch between different revisions. |
| 124 | + |
| 125 | +The following example demonstrates how to apply labels to different revisions. |
| 126 | + |
| 127 | +```json |
| 128 | +"ingress": { |
| 129 | + "traffic": [ |
| 130 | + { |
| 131 | + "revisionName": "myapp--knowngoodrevision", |
| 132 | + "weight": 100 |
| 133 | + }, |
| 134 | + { |
| 135 | + "revisionName": "myapp--98fdgt", |
| 136 | + "weight": 0, |
| 137 | + "label": "staging" |
| 138 | + } |
| 139 | + ] |
| 140 | +} |
| 141 | +``` |
| 142 | + |
| 143 | +## Portal dependencies |
| 144 | + |
| 145 | +For every app in Azure Container Apps, there are two URLs. |
| 146 | + |
| 147 | +The first URL is generated by Container Apps and is used to access your app. See the *Application Url* in the *Overview* window of your container app in the Azure portal for the fully qualified domain name (FQDN) of your container app. |
| 148 | + |
| 149 | +The second URL grants access to the log streaming service and the console. If necessary, you may need to add `https://azurecontainerapps.dev/` to the allowlist of your firewall or proxy. |
| 150 | + |
| 151 | +## Ports and IP addresses |
| 152 | + |
| 153 | +The VNET associated with a Container Apps environment uses a single subnet with 255 addresses. |
| 154 | + |
| 155 | +The following ports are exposed for inbound connections. |
| 156 | + |
| 157 | +| Use | Port(s) | |
| 158 | +|--|--| |
| 159 | +| HTTP/HTTPS | 80, 443 | |
| 160 | + |
| 161 | +Container Apps reserves 60 IPs in your VNET, and the amount may grow as your container environment scales. |
| 162 | + |
| 163 | +IP addresses are broken down into the following types: |
| 164 | + |
| 165 | +| Type | Description | |
| 166 | +|--|--| |
| 167 | +| Public inbound IP address | Used for app traffic in an external deployment, and management traffic in both internal and external deployments. | |
| 168 | +| Outbound public IP | Used as the "from" IP for outbound connections that leave the virtual network. These connections aren't routed down a VPN. | |
| 169 | +| Internal load balancer IP address | This address only exists in an internal deployment. | |
| 170 | +| App-assigned IP-based TLS/SSL addresses | These addresses are only possible with an external deployment, and when IP-based TLS/SSL binding is configured. | |
| 171 | + |
| 172 | +## Restrictions |
| 173 | + |
| 174 | +Subnet address ranges can't overlap with the following reserved ranges: |
| 175 | + |
| 176 | +- 169.254.0.0/16 |
| 177 | +- 172.30.0.0/16 |
| 178 | +- 172.31.0.0/16 |
| 179 | +- 192.0.2.0/24 |
| 180 | + |
| 181 | +## Subnet |
| 182 | + |
| 183 | +As a Container Apps environment is created, you provide resource IDs for a single subnet. |
| 184 | + |
| 185 | +If you're using the CLI, the parameter to define the subnet resource ID is `infrastructure-subnet-resource-id`. The subnet hosts infrastructure components and user app containers. |
| 186 | + |
| 187 | +If you're using the Azure CLI and the [platformReservedCidr](vnet-custom-internal.md#networking-parameters) range is defined, both subnets must not overlap with the IP range defined in `platformReservedCidr`. |
| 188 | + |
| 189 | +## Routes |
| 190 | + |
| 191 | +There's no forced tunneling in Container Apps routes. |
| 192 | + |
| 193 | +## Managed resources |
| 194 | + |
| 195 | +When you deploy an internal or an external environment into your own network, a new resource group prefixed with `MC_` is created in the Azure subscription where your environment is hosted. This resource group contains infrastructure components managed by the Azure Container Apps platform, and shouldn't be modified. The resource group contains Public IP addresses used specifically for outbound connectivity from your environment and a load balancer. As the load balancer is created in your subscription, there are extra costs associated with deploying the service to a custom virtual network. |
| 196 | + |
| 197 | +## Next steps |
| 198 | + |
| 199 | +- [Deploy with an external environment](vnet-custom.md) |
| 200 | +- [Deploy with an internal environment](vnet-custom-internal.md) |
0 commit comments