Azure Container Apps

Azure Container Apps (ACA) è un servizio serverless completamente gestito per l'hosting di container, basato su Kubernetes e su KEDA (Kubernetes Event-Driven Autoscaling). A differenza di AKS, non è necessario gestire direttamente il piano di controllo, i pool di nodi o i manifest Kubernetes. È invece possibile distribuire i container usando una semplice CLI o una definizione YAML, mentre Azure gestisce tutta l'orchestrazione. ACA è ideale per microservizi, backend API, worker basati su eventi e processi in background che devono adattarsi dinamicamente al carico, inclusa la riduzione a zero delle istanze.

Un ambiente Container Apps è il confine isolato all'interno del quale vengono eseguite una o più Container Apps. Tutte le app di un ambiente condividono la stessa rete virtuale e lo stesso workspace di Log Analytics. Gli ambienti sono associati a un'area e a un gruppo di risorse. È possibile distribuire più ambienti per isolare team o fasi diverse (produzione e staging). Un ambiente può essere facoltativamente inserito in una VNet personalizzata per consentire la comunicazione privata tra Container Apps e altri servizi Azure senza passare da Internet pubblico.

Per distribuire una Container App, si specificano l'immagine del container (proveniente da Azure Container Registry o da qualsiasi registro pubblico), il numero di repliche e le variabili di ambiente. Se si abilita l'ingress esterno, l'app è accessibile pubblicamente tramite un URL HTTPS generato automaticamente. La configurazione dell'ingress include la porta di destinazione, la suddivisione del traffico per le distribuzioni blue-green e la possibilità di consentire solo HTTP o solo HTTPS. ACA scarica l'immagine al momento della distribuzione; l'ambiente deve disporre delle autorizzazioni di pull sul registro.

Container Apps esegue il ridimensionamento usando gli scaler di KEDA, che si attivano in base a metriche esterne. Gli scaler KEDA integrati includono: traffico HTTP (richieste simultanee per replica), profondità della coda Azure Service Bus (messaggi in attesa), Azure Storage Queue, Cron (basato sul tempo) e CPU/memoria. Quando la metrica dello scaler scende a zero e minReplicas è impostato su 0, Container Apps esegue il scale to zero, senza costi di calcolo finché non arrivano nuove richieste. Il scale-to-zero è particolarmente adatto ai worker basati su eventi con carichi di lavoro sporadici.

Dapr (Distributed Application Runtime) è un runtime portabile e basato sugli eventi che semplifica la creazione di microservizi. Container Apps offre un'integrazione nativa con Dapr, che può essere abilitata per ogni app con un singolo flag. Dapr fornisce building block per: invocazione di servizi (con retry e mTLS), messaggistica pub/sub (astrazione di Service Bus ed Event Hubs), gestione dello stato (astrazione di Redis e Cosmos DB) e output binding. Con Dapr, i microservizi comunicano tramite il sidecar Dapr senza conoscere i dettagli dell'infrastruttura sottostante.

Ogni distribuzione in una Container App crea una nuova revisione. Nella modalità con più revisioni, è possibile suddividere il traffico tra le revisioni per distribuzioni blue-green o canary. Ad esempio, è possibile inviare il 10% del traffico a una nuova revisione e il 90% alla revisione stabile corrente. Monitori le percentuali di errore e la latenza della nuova revisione prima di aumentarne la quota di traffico al 100%. Le revisioni precedenti possono essere disattivate, ma vengono conservate nella cronologia, consentendo un rollback immediato riportando la quota di traffico alla revisione precedente.

Container Apps supporta due modalità per inserire la configurazione: variabili di ambiente (per configurazioni non sensibili, come i flag delle funzionalità o gli URL delle API) e segreti (per valori sensibili, come le stringhe di connessione). I segreti vengono archiviati a livello di Container App e referenziati dalle variabili di ambiente o dai componenti Dapr. Per la configurazione più sicura, faccia riferimento ai segreti di Azure Key Vault usando un'identità gestita, in modo che il valore del segreto venga recuperato in fase di esecuzione e non venga mai archiviato nel piano di configurazione della Container App.

Container Apps Jobs estende la piattaforma per supportare carichi di lavoro con esecuzione fino al completamento: contenitori che vengono avviati, eseguono un'attività e terminano. I job supportano tre tipi di trigger: Manuale (attivato tramite API o CLI), Pianificato (espressione cron) e Basato su eventi (i trigger dello scaler KEDA attivano ogni esecuzione). I job vengono fatturati solo per il tempo effettivo di esecuzione e sono ideali per l'elaborazione batch, la generazione di report, le migrazioni di database e le pipeline di inferenza ML eseguite periodicamente o in risposta a eventi.

Container Apps invia i log di sistema (eventi della piattaforma, come la creazione delle revisioni e lo scaling) e i log della console (stdout/stderr dell'applicazione) all'area di lavoro Log Analytics associata all'ambiente. Esegua query sui log con KQL: ContainerAppConsoleLogs_CL | where ContainerAppName_s == 'myapi' | project TimeGenerated, Log_s. Le metriche di Azure Monitor integrate includono il numero di repliche, il numero di richieste, la latenza delle richieste e l'utilizzo di CPU e memoria per replica, tutte disponibili nel portale di Azure senza alcuna configurazione aggiuntiva.

Per scegliere la piattaforma Azure per contenitori più adatta: Container Apps è ideale per microservizi, worker basati su eventi e API quando si desiderano i vantaggi di Kubernetes senza gestire il cluster, soprattutto quando è utile lo scale-to-zero. AKS è ideale quando sono necessari il controllo completo di Kubernetes, operatori personalizzati o configurazioni specifiche dei nodi (GPU, memoria elevata). App Service è ideale per applicazioni Web e API tradizionali quando il team di sviluppo preferisce un semplice modello PaaS senza il sovraccarico della gestione dei contenitori. Tutti e tre supportano i contenitori; la differenza consiste nel compromesso tra complessità di gestione e livello di controllo.

Container Apps supporta due modalità di ingresso: Esterno (raggiungibile pubblicamente tramite un endpoint HTTPS con bilanciamento del carico e TLS automatico) e Interno (raggiungibile solo dall'interno dello stesso ambiente Container Apps o da risorse con peering VNet). L'ingresso interno viene utilizzato per i servizi back-end che non devono mai essere esposti a Internet. Le app possono chiamarsi a vicenda usando il nome DNS interno generato automaticamente http://myapi all'interno dello stesso ambiente, consentendo una semplice comunicazione tra servizi senza distribuire un API gateway.

Verifichi la Sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione ha imparato che Azure Container Apps offre l'hosting serverless di contenitori basato su Kubernetes e KEDA senza dover gestire un cluster, che gli scaler KEDA consentono lo scale-to-zero in base alla profondità della coda, al traffico HTTP o alle pianificazioni cron e che l'integrazione con Dapr semplifica la comunicazione tra microservizi e la gestione dello stato. Ora collegheremo tutti gli elementi in un flusso di lavoro completo per sviluppatori, dall'inizio alla fine.