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 distribuzioni lineari spostano gradualmente il traffico dalla vecchia revisione del servizio a quella nuova con incrementi uguali nel tempo, consentendo di monitorare ogni passaggio prima di passare a quello successivo. Con le distribuzioni lineari di Amazon ECS, controlla il ritmo di spostamento del traffico e convalida le nuove revisioni dei servizi con quantità crescenti di traffico di produzione. Questo approccio fornisce un modo controllato per implementare le modifiche con la possibilità di monitorare le prestazioni a 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 distribuzioni lineari di Amazon ECS, il traffico viene spostato in incrementi percentuali uguali con tempi di attesa configurabili tra ogni incremento.
-
Step percent: la percentuale di traffico da spostare in ogni incremento durante una distribuzione lineare. Questo campo utilizza Double come valore e i valori validi sono compresi tra 3,0 e 100,0.
-
Step bake time: il tempo di attesa tra ogni incremento di spostamento del traffico durante un'implementazione lineare. I valori validi sono compresi tra 0 e 1440 minuti.
-
Tempo di attesa della distribuzione: il tempo, in minuti, che Amazon ECS attende dopo aver trasferito tutto il traffico di produzione verso la nuova revisione del servizio, prima di terminare la vecchia revisione del servizio. Questa è la durata in cui le revisioni del servizio blu e verde 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 o un punto di pausa in una fase specifica del ciclo di vita. Gli hook Lambda richiamano le funzioni Lambda che hai definito per eseguire codice personalizzato. Gli hook di pausa mettono in pausa la distribuzione e attendono la chiamata per procedere.
ContinueServiceDeploymentGli hook configuratiPRODUCTION_TRAFFIC_SHIFToPRE_PRODUCTION_TRAFFIC_SHIFTvengono richiamati in ogni fase del passaggio del traffico di produzione. -
Gruppo di destinazione: una risorsa di bilanciamento del carico elastico utilizzata per indirizzare le richieste verso una o più destinazioni registrate (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 di bilanciamento del carico elastico che controlla le richieste di connessione utilizzando il protocollo e la porta configurata. Le regole definite per un listener determinano il modo in cui Amazon ECS instrada le richieste alle destinazioni registrate.
-
Regola: una risorsa di bilanciamento del carico elastico 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 implementazioni lineari eseguono temporaneamente le revisioni del servizio blu e verde contemporaneamente, il che potrebbe raddoppiare l'utilizzo delle risorse durante le distribuzioni.
-
Monitoraggio dell'implementazione: le implementazioni lineari forniscono informazioni dettagliate sullo stato dell'implementazione, consentendo di monitorare ogni fase del processo di distribuzione e ogni incremento di spostamento del traffico.
-
Rollback: le implementazioni lineari semplificano il ripristino alla versione precedente se vengono rilevati problemi, poiché la revisione blu viene mantenuta in esecuzione fino alla scadenza del tempo di attesa.
-
Convalida graduale: le implementazioni lineari consentono di convalidare la nuova revisione con quantità crescenti di traffico di produzione, garantendo maggiore sicurezza nell'implementazione.
-
Durata dell'implementazione: il completamento delle implementazioni lineari richiede più tempo rispetto alle distribuzioni complete a causa dello spostamento incrementale del traffico e dei tempi di attesa tra le fasi.
Come funziona l'implementazione lineare
Il processo di distribuzione di Amazon ECS Linear 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 questi passaggi:
-
Iniziale: l'implementazione inizia con il 100% del traffico indirizzato alla revisione blu (attuale) del servizio. La revisione verde (nuova) del servizio riceve inizialmente traffico di prova ma 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%, i cambiamenti di traffico si verificano come segue:
-
Passaggio 1: dal 10,0% al verde, al 90,0% al blu
-
Passaggio 2: dal 20,0% al verde, all'80,0% al blu
-
Fase 3:30,0% verso il verde, 70,0% verso il blu
-
E così via fino a quando il 100% non raggiunge il verde
-
-
Step bake time: tra ogni incremento di spostamento del traffico, l'implementazione attende una durata configurabile (step-bake time) per consentire il monitoraggio e la convalida delle prestazioni della nuova revisione in base all'aumento del carico di traffico. Nota: il tempo di attesa dell'ultimo passaggio viene saltato una volta che il traffico viene spostato del 100,0%.
-
Hook del ciclo di vita: le funzioni Lambda opzionali o gli hook di pausa possono essere configurati in varie fasi del ciclo di vita durante l'implementazione per eseguire convalida, monitoraggio o logica personalizzata automatizzati. Gli hook sono configurati o vengono richiamati in ogni fase del passaggio del traffico di produzione
PRODUCTION_TRAFFIC_SHIFT.PRE_PRODUCTION_TRAFFIC_SHIFT
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 verifica 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, non riesce a implementare e quindi avvia un rollback dopo che una fase raggiunge le 24 ore.
CloudFormation le implementazioni 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 non riesce la distribuzione e quindi avvia un rollback se il processo non viene completato entro 36 ore.
Per i pause hook, puoi configurare il timeout fino a 20.160 minuti (14 giorni). Il timeout complessivo di implementazione è di 30 giorni.
| 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ì (solo Lambda) |
| POST_TEST_TRAFFIC_SHIFT | Lo spostamento del traffico di test è completo. La revisione del servizio verde gestisce il 100% del traffico di test. | Sì |
| PRE_PRODUCTION_TRAFFIC_SHIFT | Si verifica prima di ogni incremento dello spostamento del traffico di produzione. Gli hook del ciclo di vita configurati per questa fase vengono richiamati in ogni fase di spostamento del traffico. | 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 un blocco del ciclo di vita con un timeout di 24 ore. | Sì (solo Lambda) |
| 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 |
