Create and manage container images for solutions
Constructing and Optimizing Container Images
A multi-stage Dockerfile helps you build efficient images by separating the compilation environment from the final runtime environment. The build stage compiles the application, and then only the required production files are copied into a clean, small runtime image. This separation reduces the overall image size and minimizes security vulnerabilities by leaving development tools behind. Ordering your instructions to maximize layer caching speeds up rebuilds, while using a .dockerignore file prevents unneeded files from bloating the build.
Managing Registry Access and Security
Azure Container Registry (ACR) serves as your private store for container images. To secure your registry, you should disable the registry's admin user account and use a managed identity for access control. You assign specific Role-Based Access Control (RBAC) roles, such as AcrPull for downloading images and AcrPush for uploading them, to enforce the principle of least privilege. For security scanning, ACR integrates with Microsoft Defender for Cloud to analyze images upon push, while ACR Tasks can automate custom security checks.
Managing image tags is essential for tracking versions and avoiding unintended updates in production environments. A CI/CD pipeline in GitHub Actions or Azure DevOps can automate the process of building, tagging, and pushing these images directly to ACR. When deploying to Azure hosting services, your container must listen on the port specified by the PORT environment variable. You should also configure liveness and readiness probes so the hosting service can monitor container health and route incoming traffic properly.
Publish an image to Azure Container Registry
Authentication and Access Options
To authenticate with ACR without exposing passwords, you can configure either a system-assigned managed identity or a user-assigned managed identity. For non-Azure systems or external automated pipelines, a service principal or repository-scoped tokens provide secure, limited access to specific repositories. During local development or within virtual machine sessions, you run az login --identity followed by az acr login to securely sign in using an access token. Disabling the admin account in favor of Microsoft Entra ID authentication reduces security risks by centralizing access control.
Image Tagging and ACR Tasks
A systematic tagging strategy ensures that every image is traceable and easy to audit across different deployment environments. Teams should avoid using generic tags like latest in production, choosing instead to tag images with specific version numbers or Git commit hashes. To automate this workflow, ACR Tasks can rebuild and retag images whenever source code changes or a base image is updated. This automation integrates directly with CI/CD tools, using actions like azure/webapps-deploy@v2 in GitHub Actions to streamline the deployment pipeline.
Commands for Creating and Publishing Images
The publishing process follows a specific order of operations using the Azure CLI and Docker. First, you run az acr create to provision the registry, followed by az acr login to establish a secure connection. Next, you use the docker tag command to associate your local image with your registry's unique login server address. Finally, running docker push uploads the image layers to ACR, where you can verify the deployment using az acr repository list and az acr repository show-tags.
Run containers by using Azure Container Instances
Container Groups and Resource Planning
An Azure Container Group is a collection of containers scheduled on the same physical host that share a lifecycle, network, and storage. These containers share a single public IP address, allowing them to communicate with each other over localhost, which makes them ideal for sidecar architectures. When defining a group, you must allocate specific CPU and memory resources to each container while respecting regional resource limits. You can persist data by mounting Azure File Shares as storage volumes, and you must apply a restart policy such as Always, OnFailure, or Never to control how Azure manages stopped containers.
Deployment and Configuration with the CLI
Azure Container Instances (ACI) allow you to run serverless containers quickly without managing any underlying virtual machines. You deploy these containers using the az container create command and pass environment variables to configure runtime behavior. For instance, to deploy an Azure AI Health Insights container, you must provide valid ApiKey, Billing, Eula, and RAI_Terms variables, or the container will fail to start. After deployment, you manage the container lifecycle using az container start and az container stop, while monitoring performance with az container logs and Application Insights.
Network Security and Environment Settings
ACI supports both public networking for internet-accessible apps and private networking for secured internal environments. Integrating your container group with an Azure Virtual Network (VNet) assigns private IP addresses to your containers and limits exposure to the public internet. Within a VNet, you can configure custom DNS settings to resolve local domain names and use Network Security Groups (NSGs) to control incoming and outgoing traffic. Sensitive configuration data should never be hardcoded; instead, retrieve secrets securely from Azure Key Vault to limit access based on the principle of least privilege.
Create solutions by using Azure Container Apps
Microservices and Communication Security
Azure Container Apps provides a fully managed platform designed for running microservices within a secure boundary called a Container Apps environment. Each container app can leverage the Distributed Application Runtime (Dapr) sidecar to handle complex microservices tasks like service discovery, state management, and publish/subscribe messaging. External traffic is managed through secure HTTPS ingress with TLS termination, while internal ingress keeps inter-service communication isolated from the public internet. This isolation can be extended by deploying the environment within a virtual network and using private endpoints for all backend communication.
Deploying and Configuring Container Apps
When deploying to Azure Container Apps, you start by establishing an environment, where you can enable zone redundancy to ensure high availability. You then deploy your container image, which can be pulled from a public registry or a private ACR instance using secure credentials. The platform uses workload profiles to allocate CPU and memory resources and optimize hosting costs for different application requirements. Scaling is managed dynamically by the platform, allowing your application to automatically adjust its running instances based on the incoming workload.
Revision Management and Autoscaling
Every configuration change you deploy to Azure Container Apps automatically creates a new, immutable revision. This enables zero-downtime deployments and safe rollbacks because you can use traffic splitting to shift a percentage of user requests to the new version. Autoscaling is powered by KEDA, which monitors triggers like HTTP concurrency, CPU utilization, or Azure Service Bus messages to adjust replica counts. You can configure the scaling rules to allow the replica count to drop to zero, eliminating all compute costs when the application is completely idle.