Environment Variables and Restart Policies in Azure Container Instances

1. Dynamic Configuration with Environment Variables

As a software engineer, you're familiar with separating configuration from code, whether using appsettings.json in .NET or similar mechanisms. In the container world, environment variables are the standard way to achieve this. They allow you to use the same container image in different environments (dev, test, prod) by simply providing different variables at runtime.

ACI supports setting environment variables when you create a container instance. Let's see how this works using a public sample container designed to demonstrate this feature.

As you saw in the reading, you can pass variables using the --environment-variables (or -e) argument. Let's try it.

The mcr.microsoft.com/azuredocs/aci-wordcount:latest image runs a Python script that analyzes text. Its behavior can be modified by two environment variables:

• NumWords: The number of top words to display.
• MinLength: The minimum character length of words to consider.

Here is the Azure CLI command to run this container, setting it to find the top 5 words with a minimum length of 8 characters. Note the use of --restart-policy OnFailure, which we'll discuss next. Since this is a task that runs and then stops, this policy ensures it doesn't restart unnecessarily.

az container create \
  --resource-group <your-resource-group> \
  --name my-wordcount-container \
  --image mcr.microsoft.com/azuredocs/aci-wordcount:latest \
  --restart-policy OnFailure \
  --environment-variables 'NumWords'='5' 'MinLength'='8'

After the container runs and terminates, you can view its output using the logs command:

az container logs --resource-group <your-resource-group> --name my-wordcount-container

You will see output that reflects the environment variables you set. Experiment by deleting and recreating the container with different values.

Handling Sensitive Data with Secure Variables

What about sensitive data like passwords or API keys? Placing them in plain text environment variables is a security risk, as they can be viewed by anyone with access to the container's definition in the Azure portal or CLI.

ACI addresses this with secure environment variables. Their values are not displayed in the Azure portal or CLI output, and can only be accessed from within the container itself.

While you can't set secure variables directly via a CLI argument, you can use a YAML file with the az container create --file command. This is a powerful pattern for defining and deploying complex configurations.

Here’s an example secure-container.yaml file:

apiVersion: 2021-09-01
location: eastus
name: securetest
properties:
  containers:
  - name: mycontainer
    properties:
      environmentVariables:
      - name: 'REGULAR_VAR'
        value: 'this-is-visible'
      - name: 'SECRET_VAR'
        secureValue: 'my-secret-password'
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      ports:
      - port: 80
      resources:
        requests:
          cpu: 1.0
          memoryInGB: 1.5
  osType: Linux
  restartPolicy: Always
tags: null
type: Microsoft.ContainerInstance/containerGroups

You would deploy this using:
az container create --resource-group <your-resource-group> --file secure-container.yaml

If you then inspect the container's properties, you'll see the value for REGULAR_VAR but not for SECRET_VAR, demonstrating that the secret is protected.

2. Controlling Container Lifecycles with Restart Policies

Not all containers are meant to run forever. Some, like the word-count example, perform a task and then exit. Others, like a web server, should always be running. ACI's restart policy lets you control this behavior.

There are three policies available:

You've already seen this in action. The aci-wordcount container we ran earlier is a task-based container. By setting --restart-policy OnFailure, we instructed ACI to:

1. Run the container.
2. If the script inside finishes successfully (exit code 0), stop the container and leave it in a Terminated state.
3. If the script fails (non-zero exit code), try running it again.

For the .NET web app you deployed in the previous lesson, the default policy of Always is appropriate, as you want the web server to be restarted if it ever crashes.

3. Configuring ACI in the Azure Portal

While the CLI is excellent for automation, it's helpful to see where these settings live in the Azure portal. The video and image below show the 'Advanced' tab during container creation, where you can configure both restart policies and environment variables graphically.

Conclusion

You've now learned how to control and configure your Azure Container Instances. This moves you from simply running a container to managing it effectively for real-world scenarios.

Here are the key takeaways:

• Environment variables are set using the --environment-variables parameter in the az container create command to provide dynamic configuration to your application.
• For sensitive data, use secure environment variables (defined with secureValue in a YAML file) to prevent secrets from being exposed.
• Restart policies (--restart-policy) control the container's lifecycle. Always is for long-running services, while OnFailure and Never are for task-based workloads.
• These settings can be configured via the Azure CLI for automation or through the Azure portal for manual deployments.

In our next lesson, we will move from Azure Container Instances to Azure Container Apps. While ACI is great for single containers, Container Apps is a service designed for building scalable applications and microservices, offering features like built-in scaling, versioning, and networking. This will be a logical next step in your containerization journey on Azure.