1.3 Deploy Containers to Azure App Service

After images live in ACR, the next AI-200 skill is deploying containers to Azure App Service. App Service (Web Apps for Containers) is a managed hosting option: you get HTTPS endpoints, scaling, deployment slots, and diagnostics without operating VMs or Kubernetes control planes. For many AI cloud APIs—REST front doors to models, lightweight orchestration services, webhook receivers—App Service containers are the fastest path from registry image to public URL.

When App Service Containers Fit

Choose App Service containers when you need:

• A HTTP/HTTPS web API or site packaged as a container
• Platform features: custom domains, TLS, Easy Auth, slots, autoscale
• Simpler operations than AKS for a single service or a small Compose set

Prefer Container Apps or AKS (later chapters) when you need event-driven scale to zero, complex service meshes, or large multi-service Kubernetes workloads. App Service still matters heavily on the exam for “configure the web app to run this container and supply settings/secrets.”

Create and Configure a Container Web App

High-level steps:

1. Create a Linux Web App (Windows containers exist but Linux + ACR is the common AI-200 path).
2. Set the container source to Azure Container Registry (or another private/public registry).
3. Specify image and tag (or digest).
4. Configure authentication to ACR (managed identity recommended).
5. Set port and app settings / secrets.
6. Optionally enable continuous deployment from ACR.

Single container versus Docker Compose

Compose on App Service is not a replacement for Container Apps environments; it is a convenience for co-located containers sharing the same app lifecycle.

Critical Setting: WEBSITES_PORT

App Service terminates TLS and forwards traffic to your container. Your process might listen on 8000, 8080, or 5000—App Service must know which port to target.

Set the application setting WEBSITES_PORT to the container’s listening port (for example 8000). If this is wrong, health checks fail, the site shows application errors, and logs show the platform probing the wrong port even though the container “works” when run locally with an explicit -p mapping.

Related ideas:

• Expose only what the platform needs; do not assume host port 80 inside the container equals App Service routing without configuration.
• Pair with a proper health endpoint so restarts and slot swaps detect readiness.

Exam trap

Changing the Dockerfile EXPOSE line alone does not always fix App Service routing—WEBSITES_PORT (or the portal’s port field that maps to it) is the platform signal.

Environment Variables and App Settings

App Service Application settings are injected into the container as environment variables. This is how you supply:

• Connection strings to Azure databases
• Feature flags and non-secret URLs
• Model endpoint hostnames
• WEBSITES_PORT itself

App settings versus Key Vault references

Key Vault references use a special app setting syntax that tells App Service to fetch the secret from Azure Key Vault at runtime. The web app’s managed identity needs get permission on the secrets. This keeps passwords out of source control and out of the image—aligned with Domain 4 Key Vault skills you will deepen later.

Practice pattern for an AI API container:

• WEBSITES_PORT=8080 as a normal setting
• MODEL_ENDPOINT=https://… as a normal setting
• MODEL_API_KEY=@Microsoft.KeyVault(SecretUri=…) as a Key Vault reference

Restart or setting refresh behavior matters: after secret rotation in Key Vault, understand whether the app must restart to pick up new values (depending on reference caching/configuration).

Pulling from Private ACR Securely

For private registries:

1. Enable a system-assigned or user-assigned managed identity on the Web App.
2. Grant that identity AcrPull on the ACR resource (or scoped repository permissions where used).
3. Configure the app’s container registry credentials to use managed identity instead of admin username/password.

Admin credentials work in labs but create shared-secret sprawl. Managed identity is the production answer the exam prefers when options include both.

Continuous Deployment from ACR

App Service can subscribe to ACR webhooks so that when a watched tag is updated, the app pulls and restarts on the new image. This pairs with ACR Tasks:

1. Task builds contoso.azurecr.io/ai-api:prod.
2. Push completes; ACR webhook notifies App Service.
3. App Service pulls the new image and recycles the site.

Use deployment slots for safer releases: CD updates a staging slot; you swap to production after smoke tests. Digest pins in staging reduce “tag moved underneath us” surprises.

Networking, Scaling, and Diagnostics (Exam Touches)

• Scaling: scale out App Service Plan instances; each instance pulls/runs the container. Cold starts depend on image size—keep AI API images lean.
• Networking: VNet integration and private endpoints affect how the app reaches private ACR or private backends; Premium ACR private link scenarios may require careful network design so pulls succeed.
• Logs: container stdout/stderr stream to App Service log stream and can forward to Log Analytics—first stop when WEBSITES_PORT or missing env vars cause crashes.

End-to-End Configuration Checklist

When an exam scenario says “deploy the container and configure environment variables and secrets,” walk this list:

1. Image URL from ACR (tag or digest)
2. Managed identity + AcrPull
3. WEBSITES_PORT matches process listen port
4. Non-secret config in app settings → env vars
5. Secrets via Key Vault references + identity access to Key Vault
6. Optional ACR continuous deployment / slots
7. Verify with log stream and an HTTP probe

Putting Chapter 1 Together

• ACR images: store and version artifacts (tags/digests, SKUs, geo-replication concepts).
• ACR Tasks: build and run those artifacts in Azure with triggers.
• App Service containers: host the image, map ports, inject settings/secrets, and optionally redeploy on every successful push.

If you can explain how a commit becomes a Task build, lands as a digest-friendly tag in ACR, and is pulled by an App Service app that reads WEBSITES_PORT plus Key Vault–backed secrets, you have completed the “implement container application hosting” slice of Domain 1. Later chapters extend hosting into Container Apps, KEDA, and AKS—but App Service remains the canonical managed web host for containerized HTTP APIs on this exam.