Container Groups

• What a container group is and when to use it
• How containers in a group share resources and networking
• Deployment options (CLI, YAML, ARM)
• Example YAML for a multi-container group
• Persistence, ports, and limitations

​

Conceptual overview

• A container group is a single scheduling unit: containers in the same group are deployed to the same host and share the same network namespace and lifecycle.
• Containers within a group can share storage (for example, an Azure File share) and communicate using localhost or the container group’s IP address for low-latency inter-container communication.
• CPU and memory are specified per container; the platform schedules the entire group on a host that satisfies the combined resource requests.

​

Typical scenario

• Persistent storage backed by Azure Files.
• A helper (sidecar) container for logging, backup, or telemetry.
• The web container exposed to the internet on port 80, while the sidecar listens on an internal port (for example, 1433) that is not publicly exposed.

• Ensures they run on the same host.
• Lets them share volumes and network namespace.
• Makes deployment and lifecycle management simpler because the containers behave as one logical unit.

​

Deployment options

​

Resources and sizing

• Resource requests (CPU and memory) are declared per container; the scheduler places the group onto a host that satisfies the sum of those requests.
• This granularity allows you to allocate different resource sizes to main and sidecar containers.
• Persistent storage (such as Azure Files) can be mounted into one or more containers within the group.

​

Networking details

• All containers in a container group share a single IP address and network namespace.
• Internal communication: use localhost or 127.0.0.1 with the container port to reach other containers in the group.
• External exposure: ports are exposed at the container-group level on the group’s IP address. You explicitly declare which ports on the group IP map to container ports.

​

Example: create a container group from YAML

apiVersion: 2018-10-01
location: eastus
name: mycontainergroup
properties:
  containers:
    - name: web
      properties:
        image: mcr.microsoft.com/azuredocs/aci-helloworld
        resources:
          requests:
            cpu: 1.0
            memoryInGB: 1.5
        ports:
          - port: 80
        volumeMounts:
          - name: acifileshare
            mountPath: /mnt/azfiles
    - name: sidecar
      properties:
        image: mcr.microsoft.com/azuredocs/aci-tiny
        resources:
          requests:
            cpu: 0.25
            memoryInGB: 0.5
        ports:
          - port: 1433
        volumeMounts:
          - name: acifileshare
            mountPath: /mnt/azfiles-sidecar
  osType: Linux
  ipAddress:
    type: Public
    ports:
      - protocol: tcp
        port: 80
  volumes:
    - name: acifileshare
      azureFile:
        shareName: myshare
        storageAccountName: mystorageaccount
        storageAccountKey: "<storage-account-key>"

az container create --resource-group myResourceGroup --file container-group.yml

​

Notes on ports and internal communication

• In the YAML example above, port 80 is exposed publicly via the group IP. The sidecar’s port 1433 is defined on the container but not exposed on the group IP; it remains accessible internally from the other container via localhost:1433.
• Azure Container Instances does not provide automatic DNS name resolution between containers by container name — use localhost and ports for intra-group communication.

​

Persistence and volume mounting

• Azure Files is commonly used to provide persistent storage to container groups. Mount a shared Azure Files volume into multiple containers to share data.
• Ensure the storage account and file share exist and that the container group includes the correct volume definition and mount paths.
• When using azureFile volumes in ACI, you typically provide the storage account key in the volume definition, or use a supported identity-based authentication method when available.

​

Limitations and considerations

• Best for small sets of containers that must run together (for example, web + sidecar).
• Not a full orchestration platform: lacks built-in autoscaling, rolling updates, and advanced service discovery compared to Kubernetes.
• Plan resource requests carefully — costs and host sizing depend on the sum of container resource requests.

​

Quick reference: common CLI commands

​

Wrapping up

​

Links and references

• Azure Container Instances (ACI)
• Azure Files
• Azure CLI: az container create
• Azure Resource Manager templates
• Azure Container Apps
• Azure Kubernetes Service (AKS)