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 attuale (blu) alla nuova versione (verde).
-
Fase di preparazione: creare l'ambiente verde insieme a quello blu esistente. Ciò include la fornitura di nuove revisioni dei servizi e la preparazione dei gruppi di destinazione.
-
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 dell'ambiente verde utilizzando l'instradamento del traffico di test. L'Application Load Balancer indirizza le richieste di test verso l'ambiente verde mentre il traffico di produzione rimane sul blu.
-
Fase di spostamento del traffico: spostamento del 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 tempo di incorporamento. Quando vengono rilevati problemi, viene avviata un'operazione di rollback.
-
Fase di completamento: finalizzazione dell'implementazione 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 implementazione 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 di destinazione blu contenente attività blu integre.
-
Provisioning dell'ambiente verde: Amazon ECS crea nuove attività utilizzando la definizione di quelle aggiornate. Queste attività vengono registrate presso un nuovo gruppo di destinazione verde, ma inizialmente non ricevono traffico.
-
Convalida del controllo dell'integrità: l'Application Load Balancer esegue controlli di integrità sulle attività verdi. Solo quando le attività verdi superano i controlli dell'integrità, l'implementazione passa alla fase successiva.
-
Test di instradamento 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 sul blu. Questo è controllato dallo stesso listener che gestisce il traffico di produzione, utilizzando regole diverse basate sugli attributi della richiesta.
-
Spostamento del traffico di produzione: 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 del listener che controllano la distribuzione del traffico tra i gruppi di destinazione blu e verdi in base alle ponderazioni.
-
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 tempo di incorporamento: la durata in cui le revisioni del servizio blu e verde vengono eseguite contemporaneamente dopo lo spostamento del traffico di produzione.
-
Terminazione dell'ambiente blu: dopo il corretto spostamento del traffico e la convalida, l'ambiente blu viene terminato per liberare risorse del cluster o mantenuto per consentire una rapida capacità 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 distribuzione, ad esempio «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 scade, fallisce l'implementazione e quindi avvia un rollback dopo che una fase raggiunge le 24 ore. CloudFormation le distribuzioni hanno restrizioni di timeout aggiuntive. Sebbene il limite delle fasi di 24 ore rimanga in vigore, CloudFormation impone un limite di 36 ore all'intera implementazione. CloudFormation fallisce l'implementazione e quindi avvia un rollback se il processo non viene completato entro 36 ore.
| Fasi del ciclo di vita | Description | Usare questa fase per gli hook del ciclo di vita? |
|---|---|---|
| RECONCILE_SERVICE | Questa fase si verifica solo quando si avvia una nuova implementazione del servizio con più di 1 revisione del servizio in uno stato ACTIVE. | Sì |
| PRE_SCALE_UP | La revisione del servizio verde non è stata avviata. La revisione del servizio blu gestisce il 100% del traffico di produzione. Non è previsto alcun traffico di test. | 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 è stata avviata. La revisione del servizio blu gestisce il 100% del traffico di produzione. Non è previsto alcun traffico di test. | Sì |
| TEST_TRAFFIC_SHIFT | Le revisioni del servizio blu e verde sono in esecuzione. La revisione del servizio blu gestisce il 100% del traffico di produzione. La revisione del servizio verde migra dallo 0% al 100% del traffico di test. | Sì |
| POST_TEST_TRAFFIC_SHIFT | Lo spostamento del traffico di test è completo. La revisione del servizio verde gestisce il 100% del traffico di test. | 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 blu è 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 punti di controllo di convalida integrati che devono essere superati prima di passare alla fase successiva. Se una convalida ha esito negativo, l'implementazione può essere ripristinata automaticamente per mantenere la disponibilità e l'affidabilità del servizio.
Quando si utilizza una funzione Lambda, la funzione deve completare il lavoro o ritornare IN_PROGRESS entro 15 minuti. È possibile utilizzare il callBackDelaySeconds per ritardare la chiamata a Lambda. Per ulteriori informazioni, vedete la funzione app.py
