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 gRPC su App Service di Azure
Utilizzare la funzione EF.Parameter per forzare la parametrizzazione di una costante con Entity Framework
Utilizzare Container Queries nominali
Ottimizzare le pull con Artifact Cache di Azure Container Registry
Managed deployment strategy in Azure DevOps
Simulare Azure Cosmos DB in locale con Docker
Utilizzare Copilot con Azure Cosmos DB
Applicare un filtro per recuperare alcune issue di GitHub
Migliorare i tempi di risposta di GPT tramite lo streaming endpoint in ASP.NET Core
Gestire eccezioni nei plugin di Semantic Kernel in ASP.NET Core Web API
Utilizzare EF.Constant per evitare la parametrizzazione di query SQL
I più letti di oggi
- Novità nella gestione del modello asincrono in C# 5 e VB 11
- Configurare backup di lungo termine per Azure SQL Database
- Usare Azure Active Directory con SQL Database
- Usare le user assigned identity per accedere a Azure SQL Database tramite AAD
- Sfruttare gli embedding e la ricerca vettoriale con Azure SQL Database
- Eseguire una query su SQL Azure tramite un workflow di GitHub
- Recuperare la data di creazione e ultima modifica di un record con Entity Framework Core e le temporal table di SQL Server