What is a Container Group in Azure Container Instance (ACI)?

A container group is a top-level resource within Azure Container Instance (ACI). To understand the azure container groups, we must dig a bit and understand (ACI) and its features.

What is Azure Container Instance (ACI)?

Azure Container Instance (ACI) is a service that offers the fastest and most straightforward way to run containers directly on the Microsoft Azure cloud, without having to provision any virtual machines and without the need for a higher-level service.

Azure Container Instance (ACI) Features

Azure Container Instance (ACI) gives you direct control over containers without needing to configure Virtual Machines (VMs). Some of the benefits include:

  • Fast startup time — ACI can start up containers in just a few seconds.
  • Capability to enable Internet connection to containers using a fully qualified domain name and IP address.
  • It supports both Windows and Linux.
  • Specifying the number of CPU cores and memory allocated for container instances is possible.
  • Supports persistent storage via mounting Azure file shares to the container.
  • Launching new containers through the Azure portal or command-line interface (CLI) — underlying computing resources are automatically set up and scaled.
  • Groups to arrange many containers that share the same host, storage, and networking resources. We’ll discuss this in detail article.

Now we know about ACI and understand that it helps us run containers over the Azure cloud. We should move ahead with discussing container groups, their features, and ways to deploy container groups.

What is a container group in Azure Cloud?

A container group in Microsoft Azure is a collection of containers that runs on the same computer. The resources, storage volumes, local network, and lifespan of a container group are all shared by the containers in the group. In concept, it is analogous to a Kubernetes pod.

The below image shows a diagram of a container group with many containers and has the following specifications.

  • The group of two containers runs on the same host machine
  • It has a labeled DNA name assigned to it.
  • Has one exposed port and a single IP address
  • It has two containers, with port 80 and port 90 respectively.
  • Each container is mounted separately on two separate Azure file share volumes.

Resource allocation 

Azure Container Instances offers resources such as CPUs, RAM, and possibly GPUs (preview) to a multi-container group by adding the resource requirements of the instances in the group. If we take the CPU as an example while creating a container group of two separate container instances, each needed to be equipped with one CPU, the request of these instances using a CPU is completed ACI by assigning them one CPU each.

Resource usage by container instances

The resources indicated in the resource request get assigned to each container instance in a group. However, if you define its optional resource limit property, the maximum resources consumed by a container instance in a group may change. The resource allocation for a container should always be greater than or equal to the resource allocation request property.

  • Container maximum resource usage will always remain equal to the resource allocation request if you do not specify.
  • Container resource usage can be more when you define it in the resource request.
  • Maximum resource usage in a container also differs within a container group. A container instance resource may decrease because the max resource limit you can set for a container instance equals the total resources of the container group.
  • Your containers will not access the complete resources in a container group as a small number of resources gets consumed by the underlying infrastructure on which these services run.

Minimum and maximum allocation

  • A container group should have at least one CPU and one gigabyte of RAM. You can configure container instances with fewer than one CPU and one gigabyte of memory.
  • You must evaluate the resource availability for container instances to check the deployment region for the maximum resources in a container group.

A container group can share a fully qualified DNS label with a Fully Qualified Domain Name (FQDN) with an external IP address with one or two ports on each of the containers.

Storage

Within a container group, you can select which external volumes to mount. Storage volumes that are supported include:

  • GitRepo volume — At container startup, the gitRepo volume mounts a directory and clones the provided Git repository into it. You can avoid adding code to your applications by using a gitRepo in your container instances.
  • EmptyDir volume — The emptyDir provides a writable directory accessible to each container instance in the container group. This volume can be mounted using different or the same paths within the group.
  • Secret Volume — To provide confidential information to the containers in a container group, you can use this storage volume. By storing it in these volumes, you can avoid adding sensitive data such as SSH keys or database credentials to your application code.
  • Azure file share — Container instances can mount an Azure file share containing Azure files. Azure Files provides fully managed file sharing hosted in Azure Storage and is accessible over the Industry Standard Server Message Block (SMB) protocol.

Networking

A container group can share a fully qualified DNS label with a Fully Qualified Domain Name (FQDN) with an external IP address with one or two ports on each of the containers. If an external client wants to reach any of the containers within the container group, you must expose the port on a particular IP address from a container instance. Container instances can communicate with each other through a local host on any available ports without needing to expose those ports externally on the group’s IP address.

When you delete a container group, the IP address and (FQDN) linked to that group are released.

Ways to Deploy Container Groups

Container groups can be deployed using the Resource Manager template or a YAML file. You should use the Resource Manager Template when you need to deploy additional resources and use the YAML file when you do not need it due to its more precise nature.

You have the option to export the configurations of a container group to a YAML file using the Azure CLI command (az container export). You can use this option to easily store all the configurations of a container group in version control for “configuration as code.” Or you can use the exported file all over again as a starting point when deploying a new configuration in YAML.

The Wrap

When you need to break a single functional task into a limited number of container images, multi-container groups prove very helpful. These images may be delivered by various teams and need different resources.

Connect with our team of professionals at AnAr Solutions working on Azure Could make the best use of container groups with your applications already deployed on Azure Cloud. For Example, you can deploy your application’s Front-end over one container instance and Back-end over another container instance using a container group. The Front-end can be a web application, while Back-end can be a service retrieving data from a source.

Further Reading

Azure Resource Manager – What are the Benefits & Best Practices of ARM?
Accelerate Digital Transformation using Azure DevOps
Accelerate Digital Transformation using Azure DevOps
Microservices Architecture
Application Architecture : Azure Architecture Styles
Azure Service Fabric
Application lifecycle management with Azure Service Fabric
cloud-native storage solutions
10 Popular Cloud-native Storage Solutions ?
Privacy Preferences
When you visit our website, it may store information through your browser from specific services, usually in form of cookies. Here you can change your privacy preferences. Please note that blocking some types of cookies may impact your experience on our website and the services we offer.