Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Flusso di lavoro di implementazione dei blue/green servizi Amazon ECS
Il processo di blue/green distribuzione di Amazon ECS segue un approccio strutturato con sei fasi distinte che garantiscono aggiornamenti delle applicazioni sicuri e affidabili. Ogni fase ha uno scopo specifico nella convalida e nella transizione dell'applicazione dalla versione corrente (blu) alla nuova versione (verde).
-
Fase di preparazione: crea l'ambiente verde accanto all'ambiente blu esistente. Ciò include la fornitura di nuove revisioni dei servizi e la preparazione dei gruppi target.
-
Fase di implementazione: implementazione della nuova revisione del servizio nell'ambiente verde. Amazon ECS avvia nuove attività utilizzando la revisione aggiornata del servizio mentre l'ambiente blu continua a servire il traffico di produzione.
-
Fase di test: convalida l'ambiente verde utilizzando il routing del traffico di test. L'Application Load Balancer indirizza le richieste di test verso l'ambiente verde mentre il traffico di produzione rimane in blu.
-
Fase di spostamento del traffico: sposta il traffico di produzione dal blu al verde in base alla strategia di implementazione configurata. Questa fase include i punti di controllo di monitoraggio e convalida.
-
Fase di monitoraggio: monitoraggio dello stato delle applicazioni, delle metriche delle prestazioni e degli stati di allarme durante il periodo di cottura. Quando vengono rilevati problemi, viene avviata un'operazione di rollback.
-
Fase di completamento: finalizza la distribuzione chiudendo l'ambiente blu o mantenendolo per potenziali scenari di rollback, a seconda della configurazione.
Flusso di lavoro
Il diagramma seguente illustra il flusso di lavoro di blue/green distribuzione completo, mostrando l'interazione tra Amazon ECS e Application Load Balancer:
Il flusso di lavoro di implementazione avanzato include i seguenti passaggi dettagliati:
-
Stato iniziale: il servizio blu (produzione attuale) gestisce il 100% del traffico di produzione. L'Application Load Balancer dispone di un unico listener con regole che indirizzano tutte le richieste al gruppo target blu contenente attività blu sane.
-
Green Environment Provisioning: Amazon ECS crea nuove attività utilizzando la definizione di attività aggiornata. Queste attività vengono registrate presso un nuovo gruppo target verde, ma inizialmente non ricevono traffico.
-
Health Check Validation: L'Application Load Balancer esegue controlli di integrità sulle attività verdi. Solo quando le attività verdi superano i controlli di integrità, la distribuzione passa alla fase successiva.
-
Test del routing del traffico: se configurate, le regole del listener di Application Load Balancer indirizzano modelli di traffico specifici (come le richieste con intestazioni di test) verso l'ambiente verde per la convalida, mentre il traffico di produzione rimane in blu. Questo è controllato dallo stesso listener che gestisce il traffico di produzione, utilizzando regole diverse basate sugli attributi della richiesta.
-
Production Traffic Shift: in base alla configurazione di implementazione, il traffico passa dal blu al verde. Nelle blue/green implementazioni ECS, si tratta di uno spostamento immediato (all-at-once) in cui il 100% del traffico viene spostato dall'ambiente blu a quello verde. L'Application Load Balancer utilizza un singolo listener con regole di ascolto che controllano la distribuzione del traffico tra i gruppi target blu e verdi in base ai pesi.
-
Monitoraggio e convalida: durante l'intero spostamento del traffico, Amazon ECS monitora CloudWatch metriche, stati di allarme e stato di implementazione. I trigger di rollback automatici si attivano se vengono rilevati problemi.
-
Periodo di cottura: il periodo in cui le revisioni blu e verde del servizio vengono eseguite contemporaneamente dopo lo spostamento del traffico di produzione.
-
Terminazione dell'ambiente blu: dopo il corretto spostamento e la convalida del traffico, l'ambiente blu viene chiuso per liberare risorse del cluster o mantenuto per consentire una rapida funzionalità di rollback.
-
Stato finale: l'ambiente verde diventa il nuovo ambiente di produzione, che gestisce il 100% del traffico. L'implementazione è contrassegnata come riuscita.
Fasi del ciclo di vita dell'implementazione
Il processo di blue/green implementazione procede attraverso fasi distinte del ciclo di vita (una serie di eventi durante l'operazione di installazione, ad esempio lo «spostamento del traffico dopo la produzione»), ciascuna con responsabilità e punti di controllo di convalida specifici. La comprensione di queste fasi consente di monitorare l'avanzamento dell'implementazione e risolvere i problemi in modo efficace.
Ogni fase del ciclo di vita può durare fino a 24 ore. Si consiglia di mantenere il valore al di sotto della soglia delle 24 ore. Questo perché i processi asincroni richiedono tempo per attivare gli hook. Il sistema va in timeout, fallisce l'implementazione e quindi avvia un rollback dopo che una fase raggiunge le 24 ore. AWS CloudFormation le distribuzioni hanno restrizioni di timeout aggiuntive. Sebbene il limite delle fasi di 24 ore rimanga in vigore, AWS CloudFormation impone un limite di 36 ore all'intera implementazione. AWS CloudFormation fallisce l'implementazione e quindi avvia un rollback se il processo non viene completato entro 36 ore.
| Fasi del ciclo di vita | Descrizione | Usa questa fase per Lifecycle Hook? |
|---|---|---|
| RECONCILE_SERVICE | Questa fase si verifica solo quando si avvia una nuova distribuzione del servizio con più di una revisione del servizio in uno stato ATTIVO. | Sì |
| PRE_SCALE_UP | La revisione del servizio verde non è stata avviata. La revisione blu del servizio gestisce il 100% del traffico di produzione. Non esiste traffico di prova. | Sì |
| SCALE_UP | Il momento in cui la revisione del servizio verde aumenta fino al 100% e avvia nuove attività. La revisione del servizio verde non serve alcun traffico a questo punto. | No |
| POST_SCALE_UP | La revisione del servizio verde è iniziata. La revisione blu del servizio gestisce il 100% del traffico di produzione. Non esiste traffico di prova. | Sì |
| TEST_TRAFFIC_SHIFT | Le revisioni blu e verde del servizio sono in esecuzione. La revisione blu del servizio gestisce il 100% del traffico di produzione. La revisione del servizio verde sta migrando dallo 0% al 100% del traffico di prova. | Sì |
| POST_TEST_TRAFFIC_SHIFT | Lo spostamento del traffico di prova è completo. La revisione del servizio verde gestisce il 100% del traffico di prova. | Sì |
| PRODUCTION_TRAFFIC_SHIFT | Il traffico di produzione sta passando alla revisione del servizio verde. La revisione del servizio verde sta migrando dallo 0% al 100% del traffico di produzione. | Sì |
| POST_PRODUCTION_TRAFFIC_SHIFT | Lo spostamento del traffico di produzione è completo. | Sì |
| BAKE_TIME | La durata in cui le revisioni del servizio blu e verde vengono eseguite contemporaneamente. | No |
| CLEAN_UP | La revisione del servizio blue è stata completamente ridotta a 0 attività in esecuzione. La revisione del servizio verde è ora la revisione del servizio di produzione dopo questa fase. | No |
Ogni fase del ciclo di vita include checkpoint di convalida integrati che devono essere superati prima di passare alla fase successiva. Se una convalida fallisce, l'implementazione può essere ripristinata automaticamente per mantenere la disponibilità e l'affidabilità del servizio.
