Develop containerized solutions on Azure

A container image that starts cleanly on a laptop can still answer every request with 503 on Azure App Service, sit in ImagePullBackOff on Azure Kubernetes Service (AKS), and never scale past a single replica on Azure Container Apps, without one byte inside the image changing. That gap is the organizing idea of the whole domain: an image is fixed content identified by a SHA-256 manifest digest, and nothing inside it knows how a platform will authenticate the pull, which port to route requests to, where configuration and secrets come from, or how a new version takes over from the running one. Every question here lands in one of three stages of that image's life on Azure: produce it in Azure Container Registry (ACR), run it on a host, or observe it once it is running. The trap this model helps you dodge is the scenario written to sound like an application bug when the missing piece is a platform-side setting the image could never have carried.

Read the subtopics in order and the three stages join up. Manage container images in Azure Container Registry settles what an image reference actually points at, separating a movable tag from the fixed manifest underneath it, and Build and run images with ACR Tasks hands the build itself to Azure compute and picks the event that triggers each rebuild. The run stage then walks the three hosts in order of how much of the platform you operate yourself: Deploy containers to Azure App Service for one web container fronted by staging slots; Deploy applications to Azure Container Apps, where apps run inside a shared environment boundary and a change to the template becomes a new revision you can give a traffic weight; Event-driven scaling with KEDA for the replica-count rules that ride on that same app; and Deploy to AKS with manifest files for the full Kubernetes object model. Monitor and troubleshoot AKS and Container Apps then closes the loop as the observe stage. Notice what repeats across those three hosts: each answers the same four handoffs, namely who authenticates the registry pull, which container port receives traffic, how configuration and secrets reach the process, and how a new version replaces the old, so learn those four questions once and each host becomes a different set of answers to them.

Every host in this domain has an identity-based way to reach the registry and the secret store, and that is consistently the option to choose over its password-shaped twin. App Service pairs the app's managed identity and the AcrPull role with the acrUseManagedIdentityCreds site property, Container Apps sets an identity on the registry entry it lists under configuration.registries, az aks update --attach-acr grants AcrPull to the identity attached to an AKS cluster's agent pool, and a KEDA scale rule carries a credential of its own because the component polling the queue runs on the platform side rather than inside your replica. Secrets follow the same shape: a Key Vault reference in an App Service app setting, or a Container Apps secret bound into an environment variable with secretref:, keeps the literal value out of both the image and the deployment definition. So when one option stores a registry username and password on the app and another grants a role to an identity, the identity option is the answer.