Provision a container by using Azure Container Apps
Manage Container App Lifecycle and Configuration
Azure Container Apps is a serverless platform that lets you run containerized applications without managing the underlying Kubernetes infrastructure. When you provision a container app, you first create an environment that acts as a secure boundary where multiple container apps live and share the same network and logging configurations. This environment handles the complex Kubernetes details so you can focus on your application code.
The container app definition includes a template section where you specify the container image and resource settings. You must define the vCPU and memory requirements based on the chosen workload profile, which determines the compute power available to your application. Advanced configurations allow for sidecar containers that run helper processes alongside your main app, init containers that run setup tasks before the main application starts, and environment variables that control application behavior.
Ingress rules determine how network traffic reaches your application and support both HTTP and TCP protocols. You can configure external ingress for public internet access or internal ingress to keep services private within your virtual network. The ingress proxy handles TLS termination to decrypt incoming traffic, provides session affinity for stateful connections, and allows IP restrictions to control who can access your endpoint.
Scaling policies in Azure Container Apps are powered by KEDA, an event-driven autoscaler that can scale your application to zero when there is no demand, saving costs on compute resources. You can trigger scaling based on HTTP traffic volume, CPU or memory utilization, or custom triggers like message queue depth. This automatic scaling responds to demand changes without manual intervention.
Secrets management stores sensitive data like API keys and connection strings securely. Secrets are defined at the application level and can be referenced as environment variables or mounted as files. For enhanced security, integrate with Azure Key Vault and use managed identities to pull images from private registries without hard-coding credentials.
Revision control creates immutable snapshots of your configuration, allowing you to manage the application lifecycle. You can use traffic splitting to direct specific percentages of users to different versions for Blue/Green deployments, which ensures high availability and lets you safely test new features before a full rollout.
Deploying a container app starts with choosing a container registry such as Azure Container Registry (ACR) or Docker Hub where your image is stored. You can deploy using the Azure portal, Azure CLI, or ARM templates. For example, the az containerapp up command creates the environment, registers the container app, and configures ingress in a single operation, specifying the image, target port, and whether the ingress is external or internal.
Environment variables configure your application behavior and can be set during app creation or later by creating a new revision. When you update environment variables, Azure Container Apps creates a new revision rather than modifying the running app, which preserves the ability to roll back if needed. This revision-based approach means you can update configuration without downtime.
Secrets in Azure Container Apps securely store sensitive configuration values that can be referenced from Azure Key Vault using URIs. To use Key Vault secrets, you enable a managed identity for your container app and grant it access to Key Vault. The app then retrieves secrets at runtime without exposing them in configuration files.
The deployment process involves building a container image in your Azure Container Registry, then specifying deployment settings such as the target port and ingress type. For applications requiring persistent storage, you can mount Azure File shares. The container app pulls the image from the registry, starts in the environment, and begins accepting traffic based on your ingress configuration.
Establish Azure Container Apps Environments
An Azure Container Apps environment serves as the foundational host where container apps run and share network and logging infrastructure. Before creating an environment, you must register the Microsoft.App resource provider in your subscription. You can provision the environment through the Azure portal during initial container app creation or deploy it separately using the Azure CLI.
There are two primary environment types: Workload profiles and Consumption only. Workload profiles offer dedicated compute resources including memory-optimized or GPU-enabled instances for specific tasks, while Consumption only environments are designed for simpler workloads and do not support dedicated hardware or advanced egress controls like NAT Gateways. Choose workload profiles when your application needs consistent performance or specialized compute.
VNet integration is essential for building a secure foundation. Workload profile environments require a subnet with a minimum size of /27, while Consumption only requires a larger /23 subnet. This integration enables private endpoints and secure communication with other internal Azure services. Without proper VNet configuration, your containers cannot communicate privately with other Azure resources.
To achieve high reliability, enable zone redundancy during environment creation since this setting cannot be changed afterward. Zone redundancy automatically distributes application replicas across different physical data centers within a region, protecting against localized outages. For optimal resiliency, set a minimum replica count of three so your application remains available even if one zone fails.
Security and observability rely on managed identities and Log Analytics workspaces. A managed identity provides an automatically managed identity in Microsoft Entra ID that allows your app to access protected resources like Key Vault without embedding secrets in your code. A Log Analytics workspace collects and analyzes system logs, providing the detailed data needed to monitor complex microservice interactions and troubleshoot issues.