DEV Community

iapilgrim
iapilgrim

Posted on

Master Azure Container Instances (ACI) and Restart Policies

#azure #cloud #docker #tutorial

Azure Container Instances (ACI) are the "speed demons" of the Azure cloud. If you need to run a containerized application without the overhead of managing Virtual Machines or the complexity of Kubernetes, ACI is your go-to service.

In this recap, we’ll walk through how to deploy a web server, benchmark it using a task-oriented container, and understand how to scale your resources effectively.

1. Authenticating and Setting the Stage

Before deploying, you must connect your terminal to your Azure subscription. Using the Azure CLI is the fastest way to interact with ACI.

# Log in using your browser
az login --use-device-code

# Save your Resource Group name to a variable for easy use
rg=$(az group list --query "[].name" --output tsv)
Enter fullscreen mode Exit fullscreen mode

2. Deploying Your First Container

We start by deploying a simple "Hello World" web server. Unlike a VM, which might take minutes to boot, ACI starts in seconds.

The Command:

az container create --resource-group $rg \
  --name calabscontainer \
  --image gcr.io/cloudacademy-labs-support/aci-helloworld:1.0.0 \
  --dns-name-label my-web-app-$rg \
  --ports 80 --cpu 1 --memory 2 --os-type Linux
Enter fullscreen mode Exit fullscreen mode

Key Insight: By defining a --dns-name-label, Azure gives you a readable URL (FQDN) like my-web-app.eastus.azurecontainer.io instead of just a random IP address.

3. Running One-Off Tasks with "Restart Policies"

One of ACI's best features is its billing model: you only pay while the container is running. This makes it perfect for "Run and Done" tasks like benchmarking, image processing, or data migrations.

To ensure a container stops (and stops costing money) once its task is finished, we use the --restart-policy Never.

The Benchmark Command:

# Capture the URL of the web server
fqdn=$(az container show --name calabscontainer --resource-group $rg --query "ipAddress.fqdn" -o tsv)

# Run a benchmark tool against the web server
az container create \
  --resource-group $rg \
  --name benchmark \
  --image gcr.io/cloudacademy-labs-support/ab:1.0.0 \
  --command-line "/usr/bin/ab -k -c 1 -n 10000 http://$fqdn/" \
  --restart-policy Never
Enter fullscreen mode Exit fullscreen mode

4. Scaling Resources: The "Delete and Re-deploy" Rule

A common mistake is trying to "live-resize" an ACI instance. Azure Container Instances are immutable. If you realize your web server needs 2 CPUs instead of 1, you cannot simply update it; you must delete the existing group and recreate it with the new specs.

The Scaling Workflow:

  1. Delete: az container delete --name calabscontainer --yes
  2. Re-deploy: Run the az container create command again with --cpu 2 --memory 4.
  3. Re-test: Simply run az container start --name benchmark to trigger the test again and see if performance improved!

Summary Table: Which Restart Policy Should You Use?

Policy Behavior Best Use Case
Always (Default) Restarts if it crashes or finishes. Web Servers, APIs, Background listeners.
OnFailure Restarts only if it errors out. Batch processing where success is mandatory.
Never Stays stopped once the task is done. Benchmarking, DB migrations, Scheduled reports.

Conclusion

Azure Container Instances offer a "serverless" approach to containers. By mastering Restart Policies, you can build highly efficient, cost-optimized workflows that only run when they have work to do.

Top comments (0)