Implement Container Application Hosting on Azure

1. Registry Hierarchy

1. Registry — top-level ACR account with unique DNS: myapp.azurecr.io. Up to 500 repositories per registry.
2. Repository — named collection of related images (for example: api, worker, batch).
3. Tag — mutable pointer to an image digest (for example: latest, v2.1). Can be overwritten.
4. Digest — immutable SHA-256 hash (sha256:abc123...). Survives tag rewrites. Always use in production.

Memory aid: Library → Bookshelf → Label → ISBN

2. ACR SKUs Compared

3. ACR Authentication Options

1. Microsoft Entra ID + RBAC (recommended) — roles: AcrPull (read-only), AcrPush (push), AcrDelete (delete). Works with managed identities — no stored credentials.
2. Admin account — single username + 2 rotatable passwords. Disabled by default. Only for legacy tools that can't use Entra. Never production.
3. Repository-scoped tokens — Premium only. Grants access to specific repos only. Great for vendors/external CI.

ACR Tasks — Three Types

1. Quick Task — one-shot cloud build. No local Docker daemon needed. Ideal for CI pipelines.

   az acr build --registry myregistry --image api:v1 .

2. Triggered Task — runs automatically on an event:
   1. Source trigger — on git commit or PR via GitHub/ADO webhook
   2. Base image trigger — rebuilds your image when its FROM base image is updated (Premium only)
   3. Schedule trigger — cron-style, runs on a timer for nightly scans

   az acr task create \
     --registry myregistry --name build-on-commit \
     --image "api:{{.Run.ID}}" \
     --context https://github.com/org/repo.git --branch main \
     --file Dockerfile --git-access-token $TOKEN

3. Multi-Step Task (YAML) — build → test → push pipeline in YAML:

   version: v1.1.0
   steps:
     - build: -t myregistry.azurecr.io/api:test -f Dockerfile .
     - push: ["myregistry.azurecr.io/api:test"]
     - cmd: myregistry.azurecr.io/api:test --run-tests
     - build: -t myregistry.azurecr.io/api:latest -f Dockerfile .
     - push: ["myregistry.azurecr.io/api:latest"]

1. Stable vs Unique Tags

1. Stable tags (for example: latest, v1) — mutable. Convenient but silently change. Dev/test only.
2. Unique tags (for example: v1.2.3-20250601) — immutable per build. Fully traceable. Use in production.
3. Digests (image@sha256:abc...) — never changes even if tag is overwritten. Gold standard for prod.

2. Locking Images (Write-Protection)

az acr repository update \
  --name myregistry --image api:v1.2.3 --write-enabled false

Locked images cannot be overwritten or deleted. Protects production images from accidental pushes.

3. Lifecycle Policies (Auto-Cleanup)

az acr config retention update \
  --registry myregistry --status enabled --days 30 --type UntaggedManifests

Auto-deletes untagged manifests older than N days. Prevents storage bloat from accumulated dangling layers.

1. Image Sources

1. Azure Container Registry — recommended. Native integration with managed identity. Best for production.
2. Docker Hub — public images or authenticated private repos. Avoid for production (rate limits, no RBAC).
3. Private registry — any registry exposing the Docker HTTP API. Supply server URL + credentials.

2. ACR Authentication for App Service

1. Managed Identity (recommended)

   az webapp identity assign -g rg -n myapp
   az role assignment create \
     --assignee $(az webapp identity show -g rg -n myapp --query principalId -o tsv) \
     --role AcrPull \
     --scope $(az acr show -n myregistry --query id -o tsv)
   az webapp config container set -n myapp -g rg \
     --docker-custom-image-name myregistry.azurecr.io/api:v1 \
     --docker-registry-server-url https://myregistry.azurecr.io

2. Admin credentials (legacy) — enable admin on ACR, set server/user/password in App Service config. Stores long-lived credentials.

3. Continuous Deployment (CD)

az webapp deployment container config -n myapp -g rg --enable-cd true

Creates a webhook URL. Configure ACR to POST to it on image push. App Service auto-pulls the new image — zero CI/CD pipeline needed for simple scenarios.

1. Port Mapping — WEBSITES_PORT

App Service routes all traffic to the port specified by WEBSITES_PORT. Default assumption is port 80.

az webapp config appsettings set -g rg -n myapp --settings WEBSITES_PORT=8000

2. Custom Startup Command

az webapp config set -g rg -n myapp --startup-file "gunicorn app:app --bind 0.0.0.0:8000"

Overrides the image CMD/ENTRYPOINT at runtime without rebuilding. Useful for multi-environment configs.

3. Persistent Storage

By default the container filesystem is ephemeral — lost on restart. Set WEBSITES_ENABLE_APP_SERVICE_STORAGE=true to mount /home persistently for models, logs, or write-able files.

4. Health Checks

1. Always On — keeps app warm (no cold start). Enable for production, disable to save cost on dev.
2. Health check path — App Service polls your endpoint (for example: /health). Unhealthy instances are recycled.

1. App Settings → Environment Variables

az webapp config appsettings set -g rg -n myapp --settings MODEL_NAME=gpt-4o LOG_LEVEL=info

Every App Setting becomes an environment variable in your container — the primary config injection mechanism.

2. Key Vault References (Secure Secrets)

az webapp config appsettings set -g rg -n myapp \
  --settings "[email protected](SecretUri=https://myvault.vault.azure.net/secrets/api-key/)"

App Service fetches the secret at runtime. Secret rotations propagate automatically — no redeployment needed.

3. Connection String Prefixes

1. SQLAZURECONNSTR_ — SQL Azure
2. MYSQLCONNSTR_ — MySQL
3. POSTGRESQLCONNSTR_ — PostgreSQL
4. CUSTOMCONNSTR_ — any custom connection string

1. Log Stream (Live Logs)

az webapp log tail -g rg -n myapp

Streams container stdout/stderr in real time. First stop when a deployment fails.

2. SSH Console (Kudu)

App Service exposes SSH to running containers via https://myapp.scm.azurewebsites.net. Exec into the container and diagnose issues interactively. Your container must expose port 2222 for SSH to work.

3. Application Insights

Set APPLICATIONINSIGHTS_CONNECTION_STRING as an App Setting + add the SDK. Provides request tracing, exceptions, and performance metrics.