Abbiamo visto con gli scorsi script come possiamo ottenere tutti i vantaggi di un cluster Kubernetes (K8S), ma senza la sua complessità di gestione, grazie ad Azure Container App.
Ci basta indicare l'immagine Docker, impostare le regole di scaling e al resto ci pensa Azure, il tutto con un approccio server less che ci permette anche di spendere nulla quando non stiamo usando il nostro container.
Il container di fatto è una console app che però ha tempi di avvio e resta in vita per sempre. Se siamo "fortunati", errori gravi possono causare il crash del processo che essendo monitorato viene subito ripristinato. Può succedere invece che il processo sia attivo, ma che in realtà non riesca a soddisfare le richieste via HTTP o via SQL, oppure sebbene risponda, non abbia tutta la filiera delle dipendenze (database, ecc) funzionante. Inoltre, quando il container parte non è detto che sia immediatamente pronto, perciò è necessario dire al gateway se effettivamente instradare le richieste sulla nuova istanza/replica.
Per tutte queste ragioni, note se abbiamo già gestito un cluster K8S, su Azure Container App possiamo impostare le regole di health probe, rispettivamente per:
- Liveness: per monitorare lo stato di salute generale;
- Readiness: per monitorare se è in grado di accettare il traffico;
- Startup: per avvi lunghi e ritardare quindi l'avvio dei due precedenti monitor.
Tutto questo è basato sullo stesso motore di K8S ed è configurabile attraverso la sezione health probes in fase di deploy di un container.

Possiamo abilitare singolarmente il tipo di monitor ognuno dei quali presenta la stessa configurazione. Innanzitutto, il monitor si basa sull'interrogare regolarmente un endpoint HTTP o TCP. Nel primo caso si verifica lo status code della risposta, che sia tra 200 e minore di 400. Nel secondo caso il motore verifica che sia possibile una connessione TCP.

Dobbiamo quindi indicare il percorso da chiamare (nel caso di HTTP), eventuali secondi di attesa prima di cominciare a fare le verifiche (5 secondi), ogni quanti secondi controllare il percorso (10 secondi), quanto tempo massimo aspettare per una risposta (1 secondo), quante risposte sono necessarie per considerare in salute il processo (1) e quante risposte non valide per considerare fallito il processo (3).
Consigliamo quindi di impostare sembra almeno una di queste regole per garantire l'affidabilità.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Utilizzare la session affinity con Azure Container Apps
Creare applicazioni distribuite con Azure Container Apps e Dapr
Utilizzare i primary constructor in C#
Usare ASP.NET Core dev tunnels per testare le applicazioni su internet
Semplificare il deployment di siti statici con Azure Static Web App
Ottenere il riferimento alla finestra che ha aperto un'altra finestra con HTML5 e JavaScript
Eseguire attività pianificate con Azure Container Jobs
Gestire gli errori di caricamento delle immagini
Usare gateway dedicati con Azure Cosmos DB per migliorare le prestazioni
Impostare dinamicamente il nome di una run di un workflow di GitHub
Specificare il versioning nel path degli URL in ASP.NET Web API
Utilizzare database e servizi con gli add-on di Container App
I più letti di oggi
- .NET Conference Italia 2023 - Milano e Online
- Utilizzare database e servizi con gli add-on di Container App
- Evitare la script injection nelle GitHub Actions
- Reactive form tipizzati con modellazione del FormBuilder in Angular
- Eseguire attività basate su eventi con Azure Container Jobs
- Eseguire query verso tipi non mappati in Entity Framework Core
- Utilizzare le collection expression in C#
- Registrare servizi multipli tramite chiavi in ASP.NET Core 8
- Reactive form tipizzati con FormBuilder in Angular