A set of containers that all run on the same host computer is known to be as a container group in Microsoft azure. A container group's lifespan, resources, local network, and storage volumes are all shared by the containers in the group. It's similar to a Kubernetes pod in terms of idea.

Below image shows the example of the container group with many containers.

The above example of container group has -

• It's only running on one host system.
• Has a DNS name label attached to it.
• Only one public IP address and one vulnerable port are exposed.
• It is made up of two containers.

Deployment of Resource Manager

A Resource Manager template or a YAML file are two common ways to deploy a multi-container group. For an instance if we are deploying an azure file instance, the Resource Manager template is usually recommended if we need to deploy extra Azure service resources while deploying a container instance.

When our deployment just comprises container instances, a YAML file is preferable due to its more succinct nature.

We can export a container group's configuration to a YAML file using the Azure CLI command az container export to retain the configuration.

Resource allocation

By adding the resource requirements of the instances in the group, Azure Container Instances provides resources such as CPUs, RAM, and possibly GPUs (preview) to a multi-container group. For example, if we build a container group with two container instances, each asking one CPU, the container group will be given two CPUs.

Minimum and maximum allocation

• Give each container group at least one CPU and one GB of memory. Within a group, individual container instances can be provided with fewer than one CPU and one GB of memory.
• In order to check the deployment region for the maximum resources in a container group, the resource availability for Azure Container Instances must be checked.

Storage in the container group

We can mount the external and even the internal volumes within the container group. The volumes that are supported are as follows -

• The Empty directory
• The Cloned git repo in the container group
• The Secret
• File share

Within the various containers in a group, we can map those volumes to specified pathways.

Common scenarios

When we need to break a single functional task into a limited number of container pictures, multi-container groups come in handy. These photos can then be delivered by several teams, each with their own set of resources.

Example usage could include:

• The monitoring container sends a request to the application on a regular basis to confirm that it is running and responding correctly, and if it isn't, it generates an alarm.
• There are two containers in which one of them is for the frontend and the another one is for the backend. The front end may provide a web application, while the back end may host a data retrieval service.

Azure Virtual Network allows us to connect our Azure and on-premises resources in a safe and private manner.

Virtual network

The place where one or more subnets are created is the address space in the virtual network. The Azure resources (such as container groups) are then deployed onto the virtual network's subnets.

Subnet (delegated)

Subnets divide the virtual network into distinct address spaces that Azure resources placed in them can access. Within a virtual network, we can build one or more subnets.

We use the only container group that may be on the subnet which we can use for the container group. Azure delegates a subnet to Azure Container Instances when we first deploy a container group to it. The subnet can only be utilized for container groups once it has been delegated. If we try to deploy the container group to a delegated subnet then the procedure will automatically fail.

Network profile of the container group

A Microsoft's Azure resource's network configuration template is a network profile. This network profile is the one which provides the resource's network attributes, such as the subnet into which it should be deployed. If we are going to deploy the container group into a subnet and then to a virtual network, then the azure produces a network profile for us when we use the az container create command.

We may then use that network profile to deploy to the subnet in the future.

We can leverage an existing profile generated using az container build or start from scratch with a Resource Manager template (see template example and reference). Use the az network profile list command to acquire the ID of a previously generated profile.

After we've deployed one container group to a subnet, we can use the same network profile to deploy additional container groups to it.