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à.
Implementazioni lineari di Amazon ECS
Le implementazioni lineari spostano gradualmente il traffico dalla revisione precedente del servizio a quella nuova con incrementi uguali nel tempo, consentendoti di monitorare ogni fase prima di passare alla successiva. Con le implementazioni lineari di Amazon ECS, controlla il ritmo dello spostamento del traffico e convalida nuove revisioni dei servizi con quantità crescenti di traffico di produzione. Questo approccio offre un modo controllato per implementare le modifiche con la possibilità di monitorare le prestazioni ad ogni incremento.
Risorse coinvolte in una distribuzione lineare
Le seguenti sono le risorse coinvolte nelle distribuzioni lineari di Amazon ECS:
-
Spostamento del traffico: il processo utilizzato da Amazon ECS per spostare il traffico di produzione. Per le implementazioni lineari di Amazon ECS, il traffico viene spostato in incrementi percentuali uguali con tempi di attesa configurabili tra ogni incremento.
-
Percentuale: la percentuale di traffico da spostare in ogni incremento durante un'implementazione lineare. Questo campo utilizza Double come valore e i valori validi sono compresi tra 3,0 e 100,0.
-
Step Bake Time: la durata di attesa tra un incremento di traffico e l'altro durante una distribuzione lineare. I valori validi sono compresi tra 0 e 1440 minuti.
-
Tempo di attesa dell'implementazione: il tempo, in minuti, che Amazon ECS attende dopo aver spostato tutto il traffico di produzione alla nuova revisione del servizio, prima di terminare la vecchia revisione del servizio. Si tratta del periodo in cui le revisioni blu e verde del servizio vengono eseguite contemporaneamente dopo lo spostamento del traffico di produzione.
-
Fasi del ciclo di vita: una serie di eventi nell'operazione di implementazione, ad esempio “dopo lo spostamento del traffico di produzione”.
-
Lifecycle hook: una funzione Lambda che viene eseguita in una fase specifica del ciclo di vita. È possibile creare una funzione che verifichi la distribuzione. Le funzioni Lambda o gli hook del ciclo di vita configurati per PRODUCTION_TRAFFIC_SHIFT verranno richiamati in ogni fase del trasferimento del traffico di produzione.
-
Gruppo target: una risorsa ELB utilizzata per indirizzare le richieste verso uno o più obiettivi registrati (ad esempio, istanze). EC2 Quando si crea un listener, si specifica un gruppo di destinazione per l'operazione predefinita. Il traffico viene inoltrato al gruppo di destinazione specificato nella regola del listener.
-
Listener: una risorsa ELB che verifica le richieste di connessione utilizzando il protocollo e la porta configurati. Le regole definite per un listener determinano il modo in cui Amazon ECS instrada le richieste alle destinazioni registrate.
-
Regola: una risorsa ELB associata a un listener. Una regola definisce il modo in cui le richieste vengono instradate e consiste in un'azione, una condizione e una priorità.
Considerazioni
Si tenga in considerazione quanto segue quando si sceglie un tipo di implementazione:
-
Utilizzo delle risorse: le distribuzioni lineari eseguono temporaneamente le revisioni blu e verde del servizio contemporaneamente, il che può raddoppiare l'utilizzo delle risorse durante le distribuzioni.
-
Monitoraggio dell'implementazione: le implementazioni lineari forniscono informazioni dettagliate sullo stato dell'implementazione, consentendoti di monitorare ogni fase del processo di implementazione e ogni incremento del traffico.
-
Rollback: le implementazioni lineari semplificano il ripristino alla versione precedente se vengono rilevati problemi, poiché la revisione blu viene mantenuta attiva fino alla scadenza del tempo di cottura.
-
Convalida graduale: le implementazioni lineari consentono di convalidare la nuova revisione con quantità crescenti di traffico di produzione, offrendo maggiore fiducia nell'implementazione.
-
Durata dell'implementazione: le implementazioni lineari richiedono più tempo per essere completate rispetto alle implementazioni a causa dello spostamento incrementale del all-at-once traffico e dei tempi di attesa tra le fasi.
Come funziona l'implementazione lineare
Il processo di distribuzione lineare 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.
-
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 lineare del traffico: sposta gradualmente il traffico di produzione dal blu al verde con incrementi percentuali uguali in base alla strategia di distribuzione configurata.
-
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: finalizza l'implementazione chiudendo l'ambiente blu.
La fase di spostamento lineare del traffico segue le seguenti fasi:
-
Iniziale: l'implementazione inizia con il 100% del traffico indirizzato alla revisione blu (attuale) del servizio. La (nuova) revisione del servizio verde riceve traffico di prova ma inizialmente nessun traffico di produzione.
-
Spostamento incrementale del traffico: il traffico viene gradualmente spostato dal blu al verde con incrementi percentuali uguali. Ad esempio, con una configurazione a gradini del 10,0%, gli spostamenti del traffico si verificano come segue:
-
Fase 1: dal 10,0% al verde, al 90,0% al blu
-
Fase 2:20,0% verso il verde, 80,0% verso il blu
-
Fase 3:30,0% verso il verde, 70,0% verso il blu
-
E così via fino a quando il 100% raggiunge il verde
-
-
Step Bake Time: tra ogni incremento del traffico, l'implementazione attende una durata configurabile (step bake time) per consentire il monitoraggio e la convalida delle prestazioni della nuova revisione con l'aumento del carico di traffico. Tieni presente che il tempo di cottura dell'ultimo passaggio viene saltato una volta che il traffico viene spostato del 100,0%.
-
Lifecycle Hook: le funzioni Lambda opzionali possono essere eseguite in varie fasi del ciclo di vita durante l'implementazione per eseguire convalida, monitoraggio o logica personalizzata automatizzati. Le funzioni Lambda o gli hook del ciclo di vita configurati per PRODUCTION_TRAFFIC_SHIFT verranno richiamati in ogni fase del trasferimento del traffico di produzione.
Fasi del ciclo di vita dell'implementazione
Il processo di implementazione lineare procede attraverso fasi distinte del ciclo di vita, ognuna 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 e inoltre ogni fase di spostamento del traffico in PRODUCTION_TRAFFIC_SHIFT 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 | Supporto per Lifecycle Hook |
|---|---|---|
| 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 viene gradualmente spostato dal blu al verde con incrementi percentuali uguali fino a quando il verde riceve il 100% del traffico. Ogni spostamento del traffico richiama il lifecycle hook con un timeout di 24 ore. | |
| 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 |