Slot di distribuzione e swap

Gli slot di distribuzione sono ambienti attivi e separati per un'app Web di App Service, ciascuno con il proprio nome host (ad esempio myapp-staging.azurewebsites.net). Gli slot condividono lo stesso piano App Service e le stesse risorse dello slot di produzione, ma vengono eseguiti in modo indipendente. Consentono le distribuzioni blue-green: è possibile convalidare una nuova versione in uno slot di staging e poi scambiarla con quella in produzione senza tempi di inattività. Gli slot sono disponibili a partire dal livello Standard.

Aggiunga un nuovo slot di distribuzione all'app Web usando il portale Azure o l'interfaccia della riga di comando. Ogni slot dispone di un proprio URL, di impostazioni dell'applicazione e di stringhe di connessione. È possibile creare fino a 5 slot nel livello Standard e fino a 20 slot nel livello Premium. I nomi comuni degli slot includono staging, canary, hotfix e integration, che riflettono le diverse fasi della pipeline di rilascio.

Prima dello scambio, è fondamentale preparare lo slot di staging, in modo che la nuova versione sia completamente inizializzata. Un'istanza di App Service non preparata risponde lentamente alle prime richieste mentre il runtime si inizializza, una situazione inaccettabile in produzione. Abiliti Auto Swap oppure invii manualmente richieste HTTP di preparazione allo slot di staging. App Service supporta anche una configurazione applicationInitialization per definire i percorsi di preparazione che devono restituire 200 prima che lo slot venga considerato pronto.

Uno scambio sostituisce atomicamente gli slot di staging e di produzione. Durante uno scambio, App Service indirizza innanzitutto il traffico alle istanze di staging che eseguono il nuovo codice, attende che si inizializzino, quindi reindirizza tutto il traffico di produzione alle nuove istanze; le precedenti istanze di produzione diventano così il nuovo slot di staging. In questo modo il rollback è semplicissimo: è sufficiente eseguire nuovamente lo scambio per ripristinare la versione precedente.

Le impostazioni dell'applicazione possono essere contrassegnate come associate (specifiche dello slot) o non associate (scambiabili). Le impostazioni non associate seguono lo slot di distribuzione durante lo scambio, quindi la stringa di connessione al database di staging segue il codice in produzione. Le impostazioni associate restano con lo slot indipendentemente dagli scambi, quindi la produzione conserva sempre la propria stringa di connessione al database di produzione. Contrassegni le impostazioni come associate usando la casella di controllo 'deployment slot setting' o l'interfaccia della riga di comando.

App Service supporta la suddivisione del traffico, ovvero l'instradamento di una percentuale del traffico di produzione verso uno slot non di produzione senza eseguire uno scambio completo. Ciò consente i rilasci canary, in cui si sposta gradualmente il traffico dal 5% al 10% e poi al 50% man mano che aumenta la fiducia nella nuova versione, monitorando i tassi di errore a ogni passaggio. Gli utenti che accedono allo slot canary ricevono un cookie persistente che li mantiene sulla stessa versione, garantendo la coerenza della sessione.

Auto Swap trasferisce automaticamente uno slot di staging in produzione ogni volta che vi viene distribuito nuovo codice. È ideale per le pipeline CI/CD in cui si desidera rendere immediatamente disponibile ogni distribuzione completata correttamente. Auto Swap attende che le richieste HTTP dello slot di staging restituiscano 200 prima di completare lo scambio. Lo abiliti per ogni slot nel portale o nell'interfaccia della riga di comando, ma lo utilizzi con cautela, poiché tra la distribuzione e la produzione non è previsto alcun passaggio di approvazione manuale.

Segua queste procedure consigliate per gli slot di distribuzione: convalidi sempre in staging prima dello scambio con la produzione, utilizzi impostazioni associate per mantenere isolate dalle connessioni di staging quelle dei database di produzione, esegua smoke test sull'URL dello slot di staging dopo la distribuzione, configuri i percorsi dei controlli di integrità per assicurarsi che App Service non completi lo scambio se la nuova versione non è integra e assegni tag alle distribuzioni per poter identificare quale commit è attivo in ogni slot.

In una pipeline CI/CD tipica, la fase di compilazione compila e testa il codice, la fase di distribuzione invia l'artefatto allo slot di staging, una fase di test di integrazione esegue test automatici sull'URL di staging e la fase di scambio trasferisce lo staging in produzione, facoltativamente con l'approvazione manuale come requisito. Questo modello è supportato nativamente sia da Azure Pipelines sia da GitHub Actions con l'azione di distribuzione di App Service.

Durante e dopo uno scambio di slot, monitori le metriche chiave in Azure Monitor per confermare che la nuova versione sia integra. Controlli eventuali picchi negli errori HTTP 5xx, nel tempo medio di risposta e nell'utilizzo di CPU/memoria. Configuri avvisi sulle metriche che si attivino se i tassi di errore superano una soglia: ciò fornisce un segnale per eseguire rapidamente lo scambio inverso. Il rilevamento intelligente di Application Insights può avvisarla automaticamente delle anomalie dopo una distribuzione.

Gli slot di distribuzione sono preferibili alla gestione di app App Service completamente separate per staging e produzione, perché condividono lo stesso piano (senza costi aggiuntivi), consentono uno scambio con rollback in un clic, supportano la suddivisione del traffico e sono gestiti all'interno della stessa risorsa App Service. Utilizzi app separate solo quando lo staging richiede SKU del piano sostanzialmente diversi, requisiti di isolamento o una fatturazione completamente separata.

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

In questa lezione ha appreso che gli slot di distribuzione forniscono ambienti isolati che consentono distribuzioni blue-green; le impostazioni associate allo slot mantengono la configurazione specifica dell'ambiente (come gli URL dei database) legata allo slot anziché al codice; e la suddivisione del traffico consente rilasci canary indirizzando una percentuale del traffico di produzione verso una nuova versione. Nella prossima lezione esamineremo il ridimensionamento automatico e i domini personalizzati.