Strategie di distribuzione blu-verde in Azure Spring Apps
Nota
I piani Basic, Standard ed Enterprise saranno deprecati a partire dalla metà di marzo 2025, con un periodo di ritiro di 3 anni. È consigliabile eseguire la transizione ad App Azure Container. Per altre informazioni, vedere l'annuncio di ritiro di Azure Spring Apps.
Il piano Standard a consumo e dedicato sarà deprecato a partire dal 30 settembre 2024, con un arresto completo dopo sei mesi. È consigliabile eseguire la transizione ad App Azure Container. Per altre informazioni, vedere Eseguire la migrazione del consumo di Azure Spring Apps Standard e del piano dedicato alle app Azure Container.
Questo articolo si applica a: ✔️ Basic/Standard ✔️ Enterprise
Questo articolo descrive il supporto per la distribuzione blu-verde in Azure Spring Apps.
App Spring di Azure (piano Standard e versioni successive) consente due distribuzioni per ogni app, una delle quali riceve il traffico di produzione. Questo modello è comunemente noto come distribuzione blu-verde. Il supporto di Azure Spring Apps per la distribuzione blu-verde, insieme a una pipeline di recapito continuo (CD) e a test automatizzati rigorosi, consente distribuzioni agile di applicazioni con elevata attendibilità.
Distribuzioni alternate
Il modo più semplice per implementare la distribuzione blu-verde con Azure Spring Apps consiste nel creare due distribuzioni fisse e distribuire sempre nella distribuzione che non riceve traffico di produzione. Con l'attività Azure Spring Apps per Azure Pipelines, è possibile distribuire in questo modo semplicemente impostando il UseStagingDeployment flag su true.
Ecco come funziona l'approccio alle distribuzioni alternate in pratica:
Si supponga che l'applicazione abbia due distribuzioni: deployment1 e deployment2. Attualmente, deployment1 è impostato come distribuzione di produzione ed è in esecuzione la versione v3 dell'applicazione.
Ciò rende deployment2 la distribuzione di staging. Pertanto, quando la pipeline di recapito continuo (CD) è pronta per l'esecuzione, distribuisce la versione successiva dell'app, versione v4, nella distribuzione deployment2di staging.
Dopo v4 l'avvio in deployment2, è possibile eseguire test automatizzati e manuali su di esso tramite un endpoint di test privato per garantire v4 che soddisfi tutte le aspettative.
Quando si ha fiducia in v4, è possibile impostare deployment2 come distribuzione di produzione in modo che riceva tutto il traffico di produzione. v3 rimarrà in esecuzione deployment1 nel caso in cui si rilevi un problema critico che richiede il rollback.
A questo momento, deployment1 è la distribuzione di staging. L'esecuzione successiva della pipeline di distribuzione viene quindi distribuita in deployment1.
È ora possibile eseguire il test V5 sull'endpoint deployment1di test privato.
Infine, dopo v5 aver soddisfatti tutte le aspettative, impostare deployment1 di nuovo come distribuzione di produzione, in modo che v5 riceva tutto il traffico di produzione.
Compromessi dell'approccio alle distribuzioni alternate
L'approccio alle distribuzioni alternate è semplice e veloce, perché non richiede la creazione di nuove distribuzioni. Tuttavia, presenta diversi svantaggi, come descritto nelle sezioni seguenti.
Distribuzione di staging permanente
La distribuzione di staging rimane sempre in esecuzione e quindi usa le risorse dell'istanza di Azure Spring Apps. Ciò raddoppia efficacemente i requisiti delle risorse di ogni applicazione in Azure Spring Apps.
La race condition di approvazione
Si supponga che nell'applicazione precedente la pipeline di versione richieda l'approvazione manuale prima che ogni nuova versione dell'applicazione possa ricevere traffico di produzione. Ciò comporta il rischio che mentre una versione (v6) attende l'approvazione manuale nella distribuzione di staging, la pipeline di distribuzione verrà eseguita di nuovo e la sovrascriverà con una versione più recente (v7). Quindi, quando viene concessa l'approvazione per v6 , la pipeline distribuita v6 imposta la distribuzione di staging come produzione. Ma ora sarà il non approvato v7, non l'approvato v6, che viene distribuito in tale distribuzione e riceve il traffico.
È possibile evitare la race condition assicurandosi che il flusso di distribuzione per una versione non possa iniziare fino al completamento o all'interruzione del flusso di distribuzione per tutte le versioni precedenti. Un altro modo per impedire la race condition di approvazione consiste nell'usare l'approccio Named Deployments descritto di seguito.
Distribuzioni denominate
Nell'approccio alle distribuzioni denominate viene creata una nuova distribuzione per ogni nuova versione dell'applicazione in fase di distribuzione. Dopo che l'applicazione viene testata nella distribuzione personalizzata, tale distribuzione viene impostata come distribuzione di produzione. La distribuzione contenente la versione precedente può essere consentita per rendere persistente abbastanza a lungo per essere certi che non sia necessario eseguire il rollback.
Nella figura seguente, la versione v5 è in esecuzione nella distribuzione deployment-v5. Il nome della distribuzione contiene ora la versione perché la distribuzione è stata creata in modo specifico per questa versione. Non esiste alcuna altra distribuzione all'inizio. Ora, per distribuire la versione v6, la pipeline di distribuzione crea una nuova distribuzione deployment-v6 e distribuisce la versione dell'app in questa posizione v6 .
Non esiste alcun rischio di distribuzione parallela di un'altra versione. Prima di tutto, Azure Spring Apps non consente la creazione di una terza distribuzione mentre esistono già due distribuzioni. In secondo luogo, anche se è possibile avere più di due distribuzioni, ogni distribuzione viene identificata dalla versione dell'applicazione che contiene. Di conseguenza, la pipeline che orchestra la distribuzione di v6 tenterebbe solo di impostare deployment-v6 come distribuzione di produzione.
Dopo aver creato la distribuzione per la nuova versione riceve il traffico di produzione, è necessario rimuovere la distribuzione contenente la versione precedente per fare spazio per le distribuzioni future. Se si rileva un problema critico nella nuova versione, è possibile posticipare di alcuni minuti o ore per poter eseguire il rollback alla versione precedente.
Compromessi dell'approccio alle distribuzioni denominate
L'approccio alle distribuzioni denominate offre i vantaggi seguenti:
- Impedisce la race condition di approvazione.
- Riduce il consumo di risorse eliminando la distribuzione di staging quando non è in uso.
Tuttavia, esistono anche svantaggi, come descritto nella sezione seguente.
Errori della pipeline di distribuzione
Tra l'avvio di una distribuzione e l'ora di eliminazione della distribuzione di staging, eventuali tentativi aggiuntivi di eseguire la pipeline di distribuzione avranno esito negativo. La pipeline tenterà di creare una nuova distribuzione, che genererà un errore perché sono consentite solo due distribuzioni per ogni applicazione in Azure Spring Apps.
Pertanto, l'orchestrazione della distribuzione deve avere i mezzi per ripetere un processo di distribuzione non riuscito in un secondo momento oppure il modo per garantire che i flussi di distribuzione per ogni versione rimangano in coda fino al completamento del flusso per tutte le versioni precedenti.