Deploy a Container Instance with Public IP

Architecture Overview

Azure Container Instances (ACI) is the simplest way to run a container on Azure. You specify a container image, resource requirements, and networking preferences, and Azure runs it within seconds. There are no VMs to provision, no clusters to configure, and no orchestrators to manage. This makes ACI the fastest path from a container image to a running application in the Azure ecosystem.

This deployment creates a container group, which is ACI’s scheduling unit, similar to a Kubernetes pod. The container group can hold one or more containers that share the same network and lifecycle. In this deployment, you run a single container with a public IP address, making it immediately accessible from the internet.

The restart policy is set to automatically recover from failures, so if the container crashes, Azure restarts it without manual intervention. This provides basic resilience for workloads that do not need the full sophistication of a container orchestrator.

Container Group

The container group is the deployment unit for ACI. It defines the operating system, restart policy, networking configuration, and the containers that run within it. Containers in the same group share a localhost network and can communicate over local ports, similar to containers in a Kubernetes pod.

For single-container deployments, the container group is a thin wrapper that mostly handles lifecycle management. For multi-container scenarios, it provides co-scheduling and shared networking without requiring Kubernetes.

Resource Allocation

Each container in the group receives dedicated CPU and memory. Azure allocates exactly what you request. Unlike VMs, you do not pay for a fixed instance size. This per-container billing model makes ACI cost-effective for workloads that need specific resource quantities rather than a general-purpose machine.

You can adjust CPU and memory allocations to match your workload. Lightweight web servers may need minimal resources, while data processing jobs might require more memory or compute.

Networking and Public Access

The container group receives a public IP address, making the application reachable from the internet. Azure assigns the IP when the container group is created and deallocates it when the group is deleted. You can configure which ports are exposed and what protocol they use (TCP or UDP).

For production workloads that need a stable DNS name, you can configure a DNS name label on the container group, which provides a predictable FQDN under the azurecontainer.io domain.

Common Customizations

• Deploy from a private registry: Point the container group at an Azure Container Registry or any private Docker registry by providing registry credentials in the container group configuration.
• Mount storage volumes: Attach Azure Files shares or emptyDir volumes to the container for persistent or shared storage across container restarts.
• Add sidecar containers: Deploy multiple containers in the same group for patterns like log shipping, monitoring agents, or reverse proxies that share the network namespace.
• Place in a virtual network: Deploy the container group into a VNet subnet for private networking, allowing it to communicate with other Azure resources without public internet exposure.