Managing Revisions and Secrets in Azure Container Apps

Azure Container Apps supports versioning through revisions. Each revision represents a distinct version of your application and works similarly to deployment slots in Azure App Service. Whether you update environment variables, adjust compute settings, or deploy a new container image, every update creates a new revision. This design enables efficient tracking of changes, management of different versions, and control over which revisions handle external traffic—ideal for A/B testing or gradual feature rollouts.

For example, you can update parameters such as environment variables, scaling settings, or container images using the Azure Container Apps update command.

If an update includes a revision scope change, the system automatically generates a new revision.

Managing Secrets

Managing secrets is essential for protecting sensitive data such as API keys and connection strings. In Azure Container Apps, secrets are defined at the application level and are accessible by all app revisions. This centralized approach enhances security by ensuring that sensitive data is not hardcoded into the application or its configuration files.

When creating a Container App, you can define secrets using the --secrets parameter in the command line, ensuring that secrets are securely handled during deployment.

Configuring Revisions

To enable multiple revisions, first switch your app's revision mode to multi-revision mode. This mode allows you to manage several revisions simultaneously by assigning labels, controlling traffic distribution, and monitoring individual replicas.

For example, when using the Microsoft Azure portal, you might encounter an interface like this:

Notice that inspecting another app (e.g., one functioning properly) might display a single node. Converting an app to multi-revision mode allows you to perform actions such as configuring labels, directing traffic flows, and monitoring replicas. You can also deactivate and reactivate revisions—for instance, unchecking a revision deactivates it, while reactivating it returns it to service.

Updating Containers

When it comes to updating containers, you have two primary options: using the kubectl update command or the Azure CLI update command. Both methods offer various parameters that allow you to tailor your deployment. You can:

• Create a new revision
• Set a termination grace period
• Specify a new container image
• Configure scale sizes
• Add volumes
• Attach secret or service bindings

Consider this portal view for creating a new container app revision:

You can update a Container App using the following command:

az containerapp update [--args]
                       [--command]
                       [--container-name]
                       [--cpu]
                       [--ids]
                       [--image]
                       [--max-replicas]
                       [--memory]
                       [--min-replicas]
                       [--name]
                       [--no-wait]
                       [--remove-all-env-vars]
                       [--remove-env-vars]
                       [--replace-env-vars]
                       [--resource-group]
                       [--revision-suffix]
                       [--scale-rule-auth]
                       [--scale-rule-http-concurrency]
                       [--scale-rule-metadata]
                       [--scale-rule-name]
                       [--scale-rule-type]
                       [--secret-volume-mount]
                       [--set-env-vars]
                       [--subscription]
                       [--tags]
                       [--termination-grace-period]
                       [--workload-profile-name]
                       [--yaml]

For example, to update the container image, execute:

az containerapp update -n my-containerapp -g MyResourceGroup \
    --image myregistry.azurecr.io/my-app:v2.0

Further Revision Customizations

When creating a new revision, you can further customize various aspects of your container app, including:

• Adding sidecar containers for extra processes
• Specifying a termination grace period
• Adjusting scaling options such as the minimum and maximum number of replicas

The Microsoft Azure portal provides an intuitive interface to configure these settings:

You can define autoscaling rules by specifying replica counts:

Additionally, you can configure persistent storage by mounting volumes from Azure File Storage:

You can also securely mount secrets into your container and add service bindings for popular add-ons like Redis, MariaDB, PostgreSQL, or Kafka:

Managing Traffic Distribution

After creating new revisions, you can manage external traffic distribution between them. For example, you might allocate 50% of the traffic to a new demo revision while keeping 50% on the current active revision. This gradual rollout approach allows continuous monitoring and quick rollback if issues arise.

Creating and Managing Secrets Directly

In addition to defining secrets via command-line deployments, you can also create and manage secrets directly from the Azure portal. This interface allows you to add key/value pairs manually or link to a Key Vault, ensuring sensitive information is managed securely.

Dapr Integration

Azure Container Apps can be integrated with Dapr, simplifying microservices development by enabling seamless inter-service communication. This integration enhances the overall architecture and accelerates application development.

With this comprehensive overview, you now understand how to manage revisions and secrets in Azure Container Apps. Whether you use the Azure CLI or the Microsoft Azure portal, these features provide a robust framework for deploying and managing containerized applications securely and efficiently.

References

• Azure Container Apps Documentation
• Kubernetes Basics
• Docker Hub
• Terraform Registry