Skip to content

Commit 595f0fb

Browse files
authored
Merge pull request #109026 from dlepow/acifix2
[ACI] VNet GA updates
2 parents 3e0e9ac + 05ee6fe commit 595f0fb

File tree

7 files changed

+147
-132
lines changed

7 files changed

+147
-132
lines changed

articles/container-instances/TOC.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -51,6 +51,8 @@
5151
href: container-instances-orchestrator-relationship.md
5252
- name: Security considerations
5353
href: container-instances-image-security.md
54+
- name: Virtual networking
55+
href: container-instances-virtual-network-concepts.md
5456
- name: How-to guides
5557
items:
5658
- name: Deploy

articles/container-instances/container-instances-container-groups.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -64,7 +64,7 @@ In this scenario, you could set a resource limit of up to 2 CPUs for the contain
6464

6565
## Networking
6666

67-
Container groups can share an external-facing IP address, one or more ports on that IP address, and a DNS label with a fully qualified domain name (FQDN). To enable external clients to reach a container within the group, you must expose the port on the IP address and from the container. Because containers within the group share a port namespace, port mapping isn't supported. A container group's IP address and FQDN will be released when the container group is deleted.
67+
Container groups can share an external-facing IP address, one or more ports on that IP address, and a DNS label with a fully qualified domain name (FQDN). To enable external clients to reach a container within the group, you must expose the port on the IP address and from the container. A container group's IP address and FQDN are released when the container group is deleted.
6868

6969
Within a container group, container instances can reach each other via localhost on any port, even if those ports aren't exposed externally on the group's IP address or from the container.
7070

@@ -113,7 +113,7 @@ Learn how to deploy a multi-container container group with an Azure Resource Man
113113
[resource-limits]: /rest/api/container-instances/containergroups/createorupdate#resourcelimits
114114
[resource-requirements]: /rest/api/container-instances/containergroups/createorupdate#resourcerequirements
115115
[azure-files]: container-instances-volume-azure-files.md
116-
[virtual-network]: container-instances-vnet.md
116+
[virtual-network]: container-instances-virtual-network-concepts.md
117117
[secret]: container-instances-volume-secret.md
118118
[volume-gitrepo]: container-instances-volume-gitrepo.md
119119
[gpus]: container-instances-gpu.md

articles/container-instances/container-instances-region-availability.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
title: Resource availability by region
33
description: Availability of compute and memory resources for the Azure Container Instances service in different Azure regions.
44
ms.topic: article
5-
ms.date: 02/19/2020
5+
ms.date: 04/27/2020
66
ms.author: danlep
77

88
---
Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
---
2+
title: Scenarios to use a virtual network
3+
description: Scenarios, resources, and limitations to deploy container groups to an Azure virtual network.
4+
ms.topic: article
5+
ms.date: 04/29/2020
6+
ms.author: danlep
7+
8+
---
9+
10+
# Virtual network scenarios and resources
11+
12+
[Azure Virtual Network](../virtual-network/virtual-networks-overview.md) provides secure, private networking for your Azure and on-premises resources. By deploying container groups into an Azure virtual network, your containers can communicate securely with other resources in the virtual network.
13+
14+
This article provides background about virtual network scenarios, limitations, and resources. For deployment examples using the Azure CLI, see [Deploy container instances into an Azure virtual network](container-instances-vnet.md).
15+
16+
## Scenarios
17+
18+
Container groups deployed into an Azure virtual network enable scenarios like:
19+
20+
* Direct communication between container groups in the same subnet
21+
* Send [task-based](container-instances-restart-policy.md) workload output from container instances to a database in the virtual network
22+
* Retrieve content for container instances from a [service endpoint](../virtual-network/virtual-network-service-endpoints-overview.md) in the virtual network
23+
* Enable container communication with on-premises resources through a [VPN gateway](../vpn-gateway/vpn-gateway-about-vpngateways.md) or [ExpressRoute](../expressroute/expressroute-introduction.md)
24+
* Integrate with [Azure Firewall](../firewall/overview.md) to identify outbound traffic originating from the container
25+
* Resolve names via the internal Azure DNS for communication with Azure resources in the virtual network, such as virtual machines
26+
* Use NSG rules to control container access to subnets or other network resources
27+
28+
## Unsupported networking scenarios
29+
30+
* **Azure Load Balancer** - Placing an Azure Load Balancer in front of container instances in a networked container group is not supported
31+
* **Global virtual network peering** - Global peering (connecting virtual networks across Azure regions) is not supported
32+
* **Public IP or DNS label** - Container groups deployed to a virtual network don't currently support exposing containers directly to the internet with a public IP address or a fully qualified domain name
33+
34+
## Other limitations
35+
36+
* Currently, only Linux containers are supported in a container group deployed to a virtual network.
37+
* To deploy container groups to a subnet, the subnet can't contain other resource types. Remove all existing resources from an existing subnet prior to deploying container groups to it, or create a new subnet.
38+
* You can't use a [managed identity](container-instances-managed-identity.md) in a container group deployed to a virtual network.
39+
* You can't enable a [liveness probe](container-instances-liveness-probe.md) or [readiness probe](container-instances-readiness-probe.md) in a container group deployed to a virtual network.
40+
* Due to the additional networking resources involved, deployments to a virtual network are typically slower than deploying a standard container instance.
41+
42+
## Where to deploy
43+
44+
The following regions and maximum resources are available to deploy a container group in an Azure virtual network.
45+
46+
[!INCLUDE [container-instances-vnet-limits](../../includes/container-instances-vnet-limits.md)]
47+
48+
## Required network resources
49+
50+
There are three Azure Virtual Network resources required for deploying container groups to a virtual network: the [virtual network](#virtual-network) itself, a [delegated subnet](#subnet-delegated) within the virtual network, and a [network profile](#network-profile).
51+
52+
### Virtual network
53+
54+
A virtual network defines the address space in which you create one or more subnets. You then deploy Azure resources (like container groups) into the subnets in your virtual network.
55+
56+
### Subnet (delegated)
57+
58+
Subnets segment the virtual network into separate address spaces usable by the Azure resources you place in them. You create one or several subnets within a virtual network.
59+
60+
The subnet that you use for container groups may contain only container groups. When you first deploy a container group to a subnet, Azure delegates that subnet to Azure Container Instances. Once delegated, the subnet can be used only for container groups. If you attempt to deploy resources other than container groups to a delegated subnet, the operation fails.
61+
62+
### Network profile
63+
64+
A network profile is a network configuration template for Azure resources. It specifies certain network properties for the resource, for example, the subnet into which it should be deployed. When you first use the [az container create][az-container-create] command to deploy a container group to a subnet (and thus a virtual network), Azure creates a network profile for you. You can then use that network profile for future deployments to the subnet.
65+
66+
To use a Resource Manager template, YAML file, or a programmatic method to deploy a container group to a subnet, you need to provide the full Resource Manager resource ID of a network profile. You can use a profile previously created using [az container create][az-container-create], or create a profile using a Resource Manager template (see [template example](https://github.com/Azure/azure-quickstart-templates/tree/master/101-aci-vnet) and [reference](https://docs.microsoft.com/azure/templates/microsoft.network/networkprofiles)). To get the ID of a previously created profile, use the [az network profile list][az-network-profile-list] command.
67+
68+
In the following diagram, several container groups have been deployed to a subnet delegated to Azure Container Instances. Once you've deployed one container group to a subnet, you can deploy additional container groups to it by specifying the same network profile.
69+
70+
![Container groups within a virtual network][aci-vnet-01]
71+
72+
## Next steps
73+
74+
* For deployment examples with the Azure CLI, see [Deploy container instances into an Azure virtual network](container-instances-vnet.md).
75+
* To deploy a new virtual network, subnet, network profile, and container group using a Resource Manager template, see [Create an Azure container group with VNet](https://github.com/Azure/azure-quickstart-templates/tree/master/101-aci-vnet
76+
).
77+
78+
79+
<!-- IMAGES -->
80+
[aci-vnet-01]: ./media/container-instances-virtual-network-concepts/aci-vnet-01.png
81+
82+
<!-- LINKS - Internal -->
83+
[az-container-create]: /cli/azure/container#az-container-create
84+
[az-network-profile-list]: /cli/azure/network/profile#az-network-profile-list
85+

0 commit comments

Comments
 (0)