Aggiornare e distribuire le modifiche nelle app Azure Container
La gestione delle modifiche può risultare complessa quando si sviluppano applicazioni in contenitori nel cloud. In definitiva, è necessario il supporto per tenere traccia delle modifiche, garantire il tempo di attività e disporre di meccanismi per gestire i rollback senza problemi.
La gestione delle modifiche nelle app contenitore di Azure è basata su revisioni, che sono uno snapshot di ogni versione dell'app contenitore.
Le caratteristiche principali delle revisioni includono:
Non modificabile: una volta stabilita, una revisione rimane immutabile.
Controllo delle versioni: le revisioni fungono da record delle versioni dell'app contenitore, acquisendone lo stato in varie fasi.
Provisioning automatico: quando si distribuisce un'app contenitore per la prima volta, viene creata automaticamente una revisione iniziale.
Modifiche con ambito: mentre le revisioni rimangono statiche, le modifiche dell'ambito applicazione possono influire su tutte le revisioni, mentre le modifiche apportate all'ambito di revisione creano una nuova revisione.
Record cronologico: per impostazione predefinita, si ha accesso a 100 revisioni inattive, ma è possibile modificare questa soglia manualmente.
Più revisioni: è possibile eseguire più revisioni contemporaneamente. Questa funzionalità è particolarmente utile quando devi gestire contemporaneamente versioni diverse della tua app.
Ciclo di vita
Ogni revisione subisce stati specifici, influenzati dallo stato e dalla disponibilità. Durante il ciclo di vita, un'app contenitore passa attraverso un provisioning, un'esecuzione e uno stato inattivo diversi.
Stato del provisioning
Quando si crea una nuova revisione, l'app contenitore viene sottoposta a controlli di avvio e conformità. Durante questa fase, lo stato del provisioning funge da guida per tenere traccia dello stato di avanzamento dell'app contenitore.
| Stato | Descrizione |
|---|---|
| Provisioning in corso | La revisione è nel processo di verifica. |
| Sottoposto a provisioning | La revisione ha superato tutti i controlli. |
| Provisioning non riuscito | La revisione ha riscontrato problemi durante la verifica. |
Stato di esecuzione
Dopo il provisioning di un'app contenitore, una revisione entra nella fase operativa. Lo stato di esecuzione consente di monitorare l'integrità e le funzionalità di un'app contenitore.
| Stato | Descrizione |
|---|---|
| Provisioning in corso | La revisione è nel processo di verifica. |
| Scala a 0 | Zero repliche in esecuzione e non provisioning di nuove repliche. L'app contenitore può creare nuove repliche se vengono attivate regole di scalabilità. |
| Attivazione | Nessuna replica in esecuzione, di cui viene effettuato il provisioning di una replica. |
| Attivazione non riuscita | Impossibile effettuare il provisioning della prima replica. |
| Ridimensionamento/elaborazione | Si sta verificando un aumento o un numero di istanze. È in esecuzione una o più repliche, mentre viene eseguito il provisioning di altre repliche. |
| In esecuzione | Sono in esecuzione una o più repliche. Non sono presenti problemi da segnalare. |
| In esecuzione (al massimo) | Il numero massimo di repliche (in base alle regole di scala della revisione) è in esecuzione. Non sono presenti problemi da segnalare. |
| Deprovisioning | La revisione passa da attiva a inattiva e rimuove tutte le risorse create. |
| Degraded | Almeno una replica nella revisione è in uno stato di errore. Visualizzare i dettagli dello stato di esecuzione per problemi specifici. |
| Non riuscito | Gli errori critici hanno causato l'esito negativo delle revisioni. Lo stato di esecuzione fornisce i dettagli. Le cause comuni includono: •Terminazione • Codice di uscita 137 |
Stato inattivo
Le revisioni possono anche entrare in uno stato inattivo. Queste revisioni non dispongono di stati di provisioning o di esecuzione. Tuttavia, App Contenitore di Azure mantiene un elenco di queste revisioni, accomodando fino a 100 voci inattive. È possibile attivare una revisione in qualsiasi momento.
Modifica del limite di revisione inattivo
È possibile usare il --max-inactive-revisions parametro con i containerapp create comandi o containerapp update per controllare il numero di revisioni inattive rilevate dalle app contenitore.
Questo esempio illustra come creare una nuova app contenitore che tiene traccia di 50 revisioni inattive:
az containerapp create --max-inactive-revisions 50
Modalità di revisione
App Contenitore di Azure supporta due modalità di revisione. La scelta della modalità determina il numero di revisioni dell'app contemporaneamente attive.
| Modalità di revisione | Descrizione | Default |
|---|---|---|
| Singola | Le nuove revisioni vengono automaticamente sottoposte a provisioning, attivate e ridimensionate in base alle dimensioni desiderate. Dopo che tutte le repliche vengono eseguite come definito dalla regola di scalabilità, il traffico viene deviato dalla versione precedente a quella nuova. Se un aggiornamento non riesce, il traffico rimane indicata alla revisione precedente. Il deprovisioning delle revisioni precedenti viene eseguito automaticamente. | Sì |
| Multiplo | È possibile avere più revisioni attive, dividere il traffico tra le revisioni e scegliere quando effettuare il deprovisioning delle revisioni precedenti. Questo livello di controllo è utile per testare più versioni di un'app, test blu-verde o assumere il controllo completo degli aggiornamenti delle app. Per altri dettagli, vedere Suddivisione del traffico. |
Etichette
Per le app contenitore con traffico HTTP esterno, le etichette indirizzano il traffico a revisioni specifiche. Un'etichetta fornisce un URL univoco che è possibile usare per instradare il traffico alla revisione assegnata dall'etichetta.
Per spostare il traffico tra revisioni, è possibile spostare l'etichetta da una revisione a un'altra.
- Le etichette mantengono lo stesso URL quando si passa da una revisione a un'altra.
- Un'etichetta può essere applicata a una sola revisione alla volta.
- L'allocazione per la suddivisione del traffico non è necessaria per le revisioni con etichette.
- Le etichette sono più utili quando l'app è in modalità di revisione multipla.
- È possibile abilitare etichette, suddivisione del traffico o entrambe.
Le etichette sono utili per testare le nuove revisioni. Ad esempio, quando si vuole concedere l'accesso a un set di utenti di test, è possibile assegnare loro l'URL dell'etichetta. Quindi, quando si desidera spostare gli utenti in una revisione diversa, è possibile spostare l'etichetta in tale revisione.
Le etichette funzionano indipendentemente dalla suddivisione del traffico. La suddivisione del traffico distribuisce il traffico che passa all'URL dell'applicazione dell'app contenitore alle revisioni in base alla percentuale di traffico. Quando il traffico viene indirizzato all'URL di un'etichetta, il traffico viene instradato a una revisione specifica.
Un nome di etichetta deve:
- Costituito da caratteri alfanumerici minuscoli o trattini (
-) - Iniziare con un carattere alfabetico
- Termina con un carattere alfanumerico
Le etichette non devono:
- Avere due trattini consecutivi (
--) - Contenere più di 64 caratteri
È possibile gestire le etichette dalla pagina di gestione delle revisioni dell'app contenitore nella portale di Azure.
L'URL dell'etichetta è disponibile nel riquadro dei dettagli della revisione.
Distribuzione senza tempo di inattività
In modalità di revisione singola, App contenitore garantisce che l'app non subisca tempi di inattività durante la creazione di una nuova revisione. La revisione attiva esistente non viene disattivata finché la nuova revisione non è pronta.
Se l'ingresso è abilitato, la revisione esistente continua a ricevere il 100% del traffico fino a quando la nuova revisione non è pronta.
Una nuova revisione viene considerata pronta quando:
- Il provisioning della revisione è stato eseguito correttamente
- La revisione è stata ridimensionata in modo da corrispondere al numero di repliche delle revisioni precedenti (rispettando il numero di repliche min e max della nuova revisione)
- Tutte le repliche hanno superato i probe di avvio e preparazione
In modalità di revisione multipla è possibile controllare quando le revisioni vengono attivate o disattivate e quali revisioni ricevono traffico in ingresso. Se una regola di suddivisione del traffico è configurata con latestRevision impostato su true, il traffico non passa alla revisione più recente finché non è pronto.
Usare più revisioni
Anche se la modalità di revisione singola è quella predefinita, a volte potrebbe essere necessario avere il controllo completo sulla modalità di gestione delle revisioni.
La modalità di revisione multipla offre la flessibilità necessaria per gestire manualmente la revisione. Ad esempio, l'uso di più modalità di revisione consente di decidere esattamente la quantità di traffico allocata a ogni revisione.
Suddivisione del traffico
Il diagramma seguente mostra un'app contenitore con due revisioni.
Questo scenario presuppone che l'app contenitore sia nello stato seguente:
- L'ingresso è abilitato, rendendo disponibile l'app contenitore tramite HTTP o TCP.
- La prima revisione è stata distribuita come revisione 1.
- Dopo l'aggiornamento del contenitore, una nuova revisione è stata attivata come revisione 2.
- Le regole di suddivisione del traffico vengono configurate in modo che la revisione 1 riceva l'80% delle richieste e la revisione 2 riceva il rimanente 20%.
Accesso diretto alla revisione
Invece di usare una regola di routing per deviare il traffico a una revisione, potrebbe essere necessario rendere disponibile una revisione per le richieste di un URL specifico. La modalità di revisione multipla consente di inviare tutte le richieste provenienti al dominio alla revisione più recente, mentre le richieste di una revisione precedente sono disponibili tramite etichette per l'accesso diretto.
Stato di attivazione
In modalità di revisione multipla è possibile attivare o disattivare le revisioni in base alle esigenze. Le revisioni attive sono operative e possono gestire le richieste, mentre le revisioni inattive rimangono inattive.
App contenitore non addebita alcun addebito per le revisioni inattive. Tuttavia, esiste un limite per il numero totale di revisioni disponibili, con quelli meno recenti eliminati dopo aver superato un conteggio di 100.
Tipi di modifiche
Le modifiche apportate a un'app contenitore rientrano in due categorie: modifiche all'ambito di revisione o all'ambito dell'applicazione. Le modifiche dell'ambito di revisione attivano una nuova revisione quando si distribuisce l'app, mentre le modifiche apportate all'ambito dell'applicazione non vengono apportate.
Modifiche all'ambito di revisione
Una nuova revisione viene creata quando un'app contenitore viene aggiornata con modifiche all'ambito di revisione. Le modifiche sono limitate alla revisione in cui vengono distribuite e non influiscono su altre revisioni.
Una modifica dell'ambito di revisione è qualsiasi modifica apportata ai parametri nella properties.template sezione del modello di risorsa dell'app contenitore.
Questi parametri includono:
- Suffisso revisione
- Configurazione e immagini dei contenitori
- Regole di scalabilità per l'applicazione contenitore
Modifiche all'ambito di applicazione
Quando si distribuisce un'app contenitore con modifiche all'ambito dell'applicazione :
- Le modifiche vengono applicate a livello globale a tutte le revisioni.
- Non viene creata una nuova revisione.
Le modifiche all'ambito dell'applicazione vengono definite come qualsiasi modifica ai parametri nella properties.configuration sezione del modello di risorsa dell'app contenitore.
Questi parametri includono:
- Valori dei segreti (le revisioni devono essere riavviate prima che un contenitore riconosca i nuovi valori dei segreti)
- Modalità revisione
- Configurazione in ingresso, tra cui:
- Attivazione o disattivazione dell'ingresso
- Regole di suddivisione del traffico
- Etichette
- Credenziali per i registri contenitori privati
- Impostazioni Distributed Apps Runtime
Personalizzare le revisioni
È possibile personalizzare il nome e le etichette delle revisioni per allinearsi meglio alle convenzioni di denominazione o alla strategia di controllo delle versioni.
Suffisso del nome
A ogni revisione in App contenitore viene assegnato un identificatore univoco. Mentre i nomi vengono generati automaticamente, è possibile personalizzare il nome della revisione.
Il formato tipico per un nome di revisione è:
<CONTAINER_APP_NAME>-<REVISION_SUFFIX>
Ad esempio, se si ha un'app contenitore denominata album-api e si decide il suffisso di revisione first-revision, il nome di revisione completo diventa album-api-first-revision.
Un nome di suffisso di revisione deve:
- Costituito solo da caratteri alfanumerici minuscoli o trattini (
-) - Iniziare con un carattere alfabetico
- Termina con un carattere alfanumerico
I nomi non devono avere:
- Due trattini consecutivi (
--) - Contenere più di 64 caratteri
È possibile impostare il suffisso di revisione nel modello di Resource Manager tramite l'interfaccia della riga di comando di Azure az containerapp create e az containerapp update i comandi oppure quando si crea una revisione tramite il portale di Azure.
Utilizzare casi
Di seguito sono riportati i casi d'uso comuni per l'uso delle revisioni nelle app contenitore. Questo elenco non è un elenco completo dello scopo o delle funzionalità dell'uso delle revisioni di App contenitore.
Gestione del rilascio
Le revisioni semplificano il processo di introduzione di nuove versioni dell'app. Quando si è pronti per implementare un aggiornamento o una nuova funzionalità, è possibile creare una nuova revisione senza influire sulla versione dinamica corrente. Questo approccio garantisce una transizione uniforme e riduce al minimo le interruzioni per gli utenti finali.
Ripristino delle versioni precedenti
A volte è necessario ripristinare rapidamente una versione precedente e stabile dell'app. Se necessario, è possibile eseguire il rollback a una revisione precedente dell'app contenitore.
Test A/B
Quando vuoi testare versioni diverse dell'app, le revisioni possono supportare i test A/B. È possibile indirizzare un subset di utenti a una nuova revisione, raccogliere commenti e suggerimenti e prendere decisioni informate in base ai dati reali.
Distribuzioni blu-verde
Le revisioni supportano la strategia di distribuzione blu-verde. Avendo due revisioni parallele (blu per la versione dinamica e verde per la nuova versione), è possibile gradualmente eseguire una fase in una nuova revisione. Una volta che si è certi della stabilità e delle prestazioni della nuova versione, è possibile passare completamente il traffico all'ambiente verde.