La containerizzazione è centrale in AZ-204: devi saper scegliere il servizio di compute corretto in base al carico e conoscere il ciclo di vita dell’immagine, dal build allo store fino al deploy autenticato.

Azure Container Registry (ACR)

Azure Container Registry è il registry privato OCI-compliant per immagini e artifact Helm/OCI. La scelta dello SKU è una decisione architetturale ricorrente:

  • Basic: dev/test, storage e throughput ridotti.
  • Standard: produzione con volumi moderati.
  • Premium: abilita le feature che l’esame ama chiedere — geo-replication, private endpoint, content trust, customer-managed keys e maggiore throughput/concorrenza.

ACR Tasks

ACR Tasks sposta il build in cloud, senza Docker locale. I pattern chiave:

  • Quick task (az acr build): builda e pusha un’immagine on-demand, utile in pipeline.
  • Trigger automatici: su commit Git, su aggiornamento di una base image, o su schedule. Il trigger sulla base image è il vantaggio distintivo: quando la tua immagine di base riceve una patch di sicurezza, ACR ricostruisce automaticamente le immagini derivate.
  • Multi-step task (YAML): build, test e push orchestrati in un unico flusso.

Autenticazione

Evita gli admin credentials (utente/password del registry, disabilitati di default) in produzione. La risposta corretta quasi sempre è la managed identity: assegni all’identità (di una VM, di un Container App, di AKS) il ruolo RBAC AcrPull per il pull o AcrPush per il push. La geo-replication (solo Premium) espone un unico endpoint di login mentre serve i layer dalla region più vicina, riducendo latenza e traffico cross-region.

Azure Container Instances (ACI)

ACI esegue singoli container (o container group) senza gestire infrastruttura: serverless, fatturato al secondo, avvio rapido. È l’opzione giusta per:

  • Task effimeri e batch/job che partono, elaborano e terminano.
  • Burst di capacità (anche come virtual node verso AKS via Virtual Kubelet).
  • Scenari isolati semplici, senza service discovery né bilanciamento tra istanze.

ACI non offre orchestrazione, rolling update, scaling automatico basato su eventi né ingress HTTP gestito con certificati: se lo scenario richiede queste capacità, ACI è la risposta sbagliata.

Azure Container Apps

Azure Container Apps è il servizio serverless per microservizi e app event-driven, costruito su Kubernetes + Dapr + KEDA ma senza esporre il control plane. Concetti d’esame:

  • Ingress: HTTP(S) gestito con TLS automatico; puoi esporre l’app external (internet) o internal (solo nell’environment), con traffic splitting nativo.
  • Revisions: ogni modifica al container o alla config crea una nuova revision immutabile. Puoi tenere più revisioni attive e distribuire il traffico in percentuale, abilitando blue-green e canary.
  • Scaling con KEDA: regole di scala basate su HTTP concurrency, CPU/memoria o scaler event-driven (Service Bus, Event Hubs, Storage Queue, Kafka). Supporta lo scale to zero: nessuna istanza (e nessun costo di compute) quando non c’è traffico o coda.

Quale servizio scegliere

  • App Service for Containers: singola web app/API monolitica, con feature PaaS mature (slot di deployment, easy auth, domini custom). Ottimo per app web tradizionali, ma non scala a zero e non ha scaler event-driven.
  • Container Apps: microservizi, worker guidati da code/eventi, necessità di scale-to-zero e revisioni. È la via di mezzo giusta quando App Service è troppo limitato ma non vuoi gestire un cluster.
  • AKS: serve controllo diretto su Kubernetes — networking avanzato, operator, GPU node pool custom, service mesh specifici. Massima flessibilità, massimo onere operativo.

Trappole tipiche d’esame

  • Serve scaling event-driven da una coda con scale-to-zero → Azure Container Apps (KEDA), non ACI: ACI non scala automaticamente sugli eventi.
  • Job batch effimero one-shot, avvio rapido, nessuna orchestrazione → Azure Container Instances, non Container Apps o AKS (sarebbero over-engineering).
  • Autenticazione al registry da una VM/Container App → managed identity con ruolo AcrPull, non admin user né credenziali nel codice.
  • Ridurre latenza di pull in più region con un unico endpoint → geo-replication su SKU Premium; Basic/Standard non la supportano.
  • Ricostruire automaticamente l’immagine quando la base image riceve una patch → ACR Task con base image update trigger, non una pipeline schedulata manuale.
  • Rilascio graduale di una nuova versione con rollback rapido → revisions + traffic splitting in Container Apps; su App Service l’equivalente sono i deployment slot.