Container Apps and Container Registry

Container Apps runs most containerized APIs and workers without the burden of operating Kubernetes.

Azure Container Apps runs containers on a managed Kubernetes-based platform you never see. You get HTTPS ingress, autoscaling (including to zero), revisions, jobs and service discovery, without managing clusters, nodes or upgrades.

Key concepts:

Environment: a secure boundary (shared VNet, Log Analytics) for a group of apps. Apps in one environment reach each other by name.
Container app: one or more containers with ingress settings (external or internal, target port).
Revisions: immutable snapshots of the app's template. Changing the image or env vars creates a new revision; in multiple-revision mode you split traffic by percentage for blue/green and canary releases.
Scale rules: based on HTTP concurrency, CPU, or any KEDA scaler (Service Bus queue length, Kafka lag). minReplicas: 0 scales to zero.
Jobs: run-to-completion containers on a schedule, manually or per event.

Images come from Azure Container Registry (ACR). Give the app a managed identity with the AcrPull role on the registry instead of admin credentials. az acr build builds an image in the cloud from a Dockerfile, no local Docker needed.

Choose Container Apps for most microservices; pick AKS when you need the Kubernetes API itself.

Example

az acr create -g rg-apps -n acrorders --sku Standard
az acr build -r acrorders -t orders-api:1.4.0 .     # cloud build from ./Dockerfile

az containerapp env create -g rg-apps -n cae-orders --location westeurope

az containerapp create -g rg-apps -n orders-api --environment cae-orders \
  --image acrorders.azurecr.io/orders-api:1.4.0 \
  --registry-server acrorders.azurecr.io --registry-identity system \
  --ingress external --target-port 8000 \
  --min-replicas 0 --max-replicas 10 \
  --env-vars LOG_LEVEL=info

az containerapp show -g rg-apps -n orders-api --query properties.configuration.ingress.fqdn -o tsv
# orders-api.<hash>.westeurope.azurecontainerapps.io

Remember

Environment = shared boundary; app = containers + ingress + scale rules
Every template change creates a revision; traffic can be split between revisions
KEDA scale rules allow scale-to-zero on queue depth and more
Pull from ACR with a managed identity and AcrPull

Watch out for

Using the latest tag: redeploying the same tag doesn't create a new revision, so the new image may never roll out.

Check yourself

How would you send 10% of traffic to a new release in Container Apps?

Official docs: learn.microsoft.com/en-us/azure/container-apps/overview

Example

Remember

Watch out for

Check yourself

Builds on

Unlocks