Migra le distribuzioni CodeDeploy blue/green deployments to Amazon ECS blue/green

CodeDeploy blue/green and Amazon ECS blue/greenle distribuzioni offrono funzionalità simili, ma differiscono nel modo in cui vengono configurate e gestite.

CodeDeploy panoramica sulla distribuzione in blu e verde

Quando crei un servizio Amazon ECS utilizzando CodeDeploy, tu:

1. Crea un sistema di bilanciamento del carico con un listener di produzione e (facoltativamente) un listener di test. Ogni listener è configurato con un'unica regola (predefinita) che indirizza tutto il traffico verso un singolo gruppo target (il gruppo target principale).

2. Crea un servizio Amazon ECS, configurato per utilizzare il listener e il gruppo target, con deploymentController tipo impostato su. CODE_DEPLOY La creazione del servizio comporta la creazione di un set di attività (blu) registrato con il gruppo target specificato.

3. Crea un gruppo di CodeDeploy distribuzione (come parte di un' CodeDeploy applicazione) e configuralo con i dettagli del cluster Amazon ECS, il nome del servizio, i listener di load balancer, due gruppi target (il gruppo target principale utilizzato nella regola del listener di produzione e un gruppo target secondario da utilizzare per le attività di sostituzione), un ruolo di servizio (per concedere le CodeDeploy autorizzazioni per manipolare le risorse Amazon ECS ed Elastic Load Balancing) e vari parametri che controllano il comportamento di distribuzione.

Con CodeDeploy, le nuove versioni di un servizio vengono distribuite utilizzandoCreateDeployment(), specificando il nome CodeDeploy dell'applicazione, il nome del gruppo di distribuzione e un AppSpec file che fornisce dettagli sulla nuova revisione e sugli hook opzionali del ciclo di vita. La CodeDeploy distribuzione crea un set di attività sostitutivo (verde) e ne registra le attività con il gruppo target secondario. Quando diventa funzionante, è disponibile per i test (opzionale) e per la produzione. In entrambi i casi, il reindirizzamento si ottiene modificando la rispettiva regola del listener in modo che punti al gruppo target secondario associato al set di attività verde. Il rollback si ottiene modificando la regola del listener di produzione riportandola al gruppo target principale.

Panoramica della blue/green distribuzione di Amazon ECS

Con le blue/green distribuzioni di Amazon ECS, la configurazione di distribuzione fa parte del servizio Amazon ECS stesso:

1. È necessario preconfigurare il listener di produzione del load balancer con una regola che includa due gruppi target con pesi pari a 1 e 0.

2. È necessario specificare le seguenti risorse o aggiornare le risorse del servizio:

   • L'ARN di questa regola del listener

   • I due gruppi target

   • Un ruolo IAM per concedere ad Amazon ECS l'autorizzazione a chiamare Elastic Load Balancing APIs

   • Un ruolo IAM opzionale per eseguire le funzioni Lambda

   • Imposta il deploymentController tipo su ECS e deploymentConfiguration.strategy su. BLUE_GREEN Ciò si traduce nella creazione di una distribuzione di servizi (blu) le cui attività sono registrate presso il gruppo target principale.

Con Amazon ECS blu/green, viene creata una nuova revisione del servizio chiamando Amazon ECS UpdateService() e trasmettendo i dettagli della nuova revisione. L'implementazione del servizio crea nuove attività (verdi) di revisione del servizio e le registra con il gruppo target secondario. Amazon ECS gestisce le operazioni di re-routing e rollback modificando i pesi sulla regola del listener.

Principali differenze di implementazione

Sebbene entrambi gli approcci comportino la creazione di una serie iniziale di attività, l'implementazione sottostante è diversa:

• CodeDeploy utilizza un set di attività, mentre Amazon ECS utilizza una revisione del servizio. I set di attività di Amazon ECS sono una struttura precedente che è stata sostituita dalle revisioni e dalle implementazioni dei servizi Amazon ECS. Questi ultimi offrono una maggiore visibilità sul processo di distribuzione, nonché sulla cronologia di distribuzione e revisione del servizio.

• Con CodeDeploy, i lifecycle hook vengono specificati come parte del AppSpec file a cui viene fornito. CreateDeployment() Ciò significa che gli hook possono essere modificati da una distribuzione all'altra. Con Amazon ECS blu/green, gli hook sono specificati come parte della configurazione del servizio e qualsiasi aggiornamento richiederebbe una chiamata. UpdateService()

• CodeDeploy Sia Amazon ECS che Amazon ECS blue/green utilizzano Lambda per l'implementazione degli hook, ma gli input e gli output previsti sono diversi.

  Con CodeDeploy, la funzione deve effettuare una chiamata PutLifecycleEventHookExecutionStatus() per restituire lo stato dell'hook, che può essere o. SUCCEEDED FAILED Con Amazon ECS, la risposta Lambda viene utilizzata per indicare lo stato dell'hook.

• CodeDeploy richiama ogni hook come chiamata una tantum e prevede la restituzione dello stato di esecuzione finale entro un'ora. Gli hook di Amazon ECS sono più flessibili in quanto possono restituire un IN_PROGRESS indicatore, che segnala che l'hook deve essere richiamato ripetutamente fino a quando non risulta o. SUCCEEDED FAILED Per ulteriori informazioni, consulta Lifecycle hook per le implementazioni di servizi Amazon ECS.

Approcci alla migrazione

Esistono tre approcci principali alla migrazione dalle CodeDeploy blue/green to Amazon ECS blue/green distribuzioni. Ciascun approccio presenta caratteristiche diverse in termini di complessità, rischio, capacità di ripristino e potenziali tempi di inattività.

Riutilizza le stesse risorse Elastic Load Balancing utilizzate per CodeDeploy

Aggiorna il servizio Amazon ECS esistente per utilizzare il controller di distribuzione Amazon ECS con strategia di blue/green distribuzione anziché il controller di CodeDeploy distribuzione. Quando utilizzi questo approccio, considera quanto segue:

• La procedura di migrazione è più semplice perché stai aggiornando il controller di distribuzione e la strategia di distribuzione del servizio Amazon ECS esistenti.

• Non ci sono tempi di inattività se configurati e migrati correttamente.

• Un rollback richiede l'annullamento della revisione del servizio.

• Il rischio è elevato perché non esiste una configurazione blu/verde parallela.

Utilizzate lo stesso listener di load balancer e gli stessi gruppi target utilizzati per. CodeDeploy Se lo stai usando AWS CloudFormation, vedi. Migrazione di un modello AWS CloudFormation CodeDeploy blue/green deployment template to an Amazon ECS blue/green AWS CloudFormation

1. Modifica la regola predefinita degli production/test ascoltatori per includere il gruppo target alternativo e imposta il peso del gruppo target primario su 1 e del gruppo target alternativo su 0.

   Infatti CodeDeploy, i listener del load balancer collegato al servizio sono configurati con un'unica regola (predefinita) che indirizza tutto il traffico verso un singolo gruppo di destinazione. Per Amazon ECS blu/green, i listener di load balancer devono essere preconfigurati con una regola che includa i due gruppi target con pesi.

2. Aggiorna il servizio Amazon ECS esistente chiamando l'UpdateServiceAPI e impostando il parametro deploymentController su ECS e il parametro deploymentStrategy suBLUE_GREEN. Specificate il ARNs gruppo target, il gruppo target alternativo, il listener di produzione e un listener di test opzionale.

3. Verifica che il servizio funzioni come previsto.

4. Elimina la CodeDeploy configurazione per questo servizio Amazon ECS poiché ora utilizzi Amazon ECS blu/verde.

Nuovo servizio con sistema di bilanciamento del carico esistente

Questo approccio utilizza la blue/green strategia per la migrazione.

Quando utilizzi questo approccio, considera quanto segue:

• Le interruzioni sono minime. Si verifica solo durante lo scambio di porte Elastic Load Balancing.

• Un rollback richiede il ripristino dello swap delle porte Elastic Load Balancing.

• Il rischio è basso perché esistono configurazioni parallele. Pertanto è possibile eseguire il test prima del cambio di traffico.

1. Lascia intatti gli ascoltatori, i gruppi target e il servizio Amazon ECS per la CodeDeploy configurazione in modo da poter tornare facilmente a questa configurazione, se necessario.

2. Crea nuovi gruppi target e nuovi listener (con porte diverse dai listener originali) utilizzando il sistema di bilanciamento del carico esistente. Quindi, crea un nuovo servizio Amazon ECS che corrisponda al servizio Amazon ECS esistente, tranne che lo usi ECS come controller di distribuzione, BLUE_GREEN come strategia di distribuzione e trasferisci le regole ARNs per i nuovi gruppi target e i nuovi ascoltatori.

3. Verifica la nuova configurazione inviando manualmente il traffico HTTP al servizio. Se tutto va bene, scambiate le porte dei listener originali con quelle dei nuovi listener per indirizzare il traffico verso la nuova configurazione.

4. Verifica la nuova configurazione e, se tutto continua a funzionare come previsto, elimina la configurazione. CodeDeploy

Nuovo servizio con un nuovo sistema di bilanciamento del carico

Come l'approccio precedente, questo approccio utilizza la blue/green strategia per la migrazione. La differenza fondamentale è che il passaggio dalla CodeDeploy configurazione alla configurazione di Amazon ECS blue/green avviene a un livello di proxy inverso sopra il load balancer. Le implementazioni di esempio per il livello di reverse proxy sono Route 53 e. CloudFront

Questo approccio è adatto ai clienti che dispongono già di questo livello di reverse proxy e se tutte le comunicazioni con il servizio avvengono attraverso di esso (ad esempio, nessuna comunicazione diretta a livello di load balancer).

Quando utilizzi questo approccio, considera quanto segue:

• Ciò richiede un livello di proxy inverso.

• La procedura di migrazione è più complessa perché è necessario aggiornare il controller di distribuzione del servizio Amazon ECS e la strategia di distribuzione esistenti.

• Le interruzioni sono minime. Si verifica solo durante lo scambio di porte Elastic Load Balancing.

• Un rollback richiede l'annullamento delle modifiche alla configurazione del proxy.

• Il rischio è basso perché esistono configurazioni parallele. Pertanto è possibile eseguire il test prima del cambio di traffico.

1. Non modificare intatta la CodeDeploy configurazione esistente (load balancer, listener, gruppi target, servizio Amazon ECS e CodeDeploy gruppo di distribuzione).

2. Crea un nuovo sistema di bilanciamento del carico, gruppi target e listener configurati per le distribuzioni di Amazon ECS blue/green .

   Configura le risorse appropriate.

   • Application Load Balancer: per ulteriori informazioni, vedere. Risorse Application Load Balancer per le implementazioni blue/green

   • Network Load Balancer: per ulteriori informazioni, vedere. Risorse Network Load Balancer per le implementazioni blu/verdi di Amazon ECS

3. Crea un nuovo servizio ECS come controller di implementazione e BLUE_GREEN come strategia di distribuzione, puntando sulle nuove risorse del load balancer.

4. Verifica la nuova configurazione testandola tramite il nuovo sistema di bilanciamento del carico.

5. Aggiorna la configurazione del reverse proxy per indirizzare il traffico verso il nuovo sistema di bilanciamento del carico.

6. Osserva la nuova revisione del servizio e, se tutto continua a funzionare come previsto, elimina la CodeDeploy configurazione.

Passaggi successivi

Dopo la migrazione alle distribuzioni di Amazon ECS: blue/green

• Aggiorna gli script e le CI/CD pipeline di distribuzione per utilizzare l'API Amazon ECS anziché UpdateService l'API. CodeDeploy CreateDeployment

• Aggiorna il monitoraggio e gli avvisi per tenere traccia delle distribuzioni dei servizi Amazon ECS anziché delle distribuzioni. CodeDeploy

• Prendi in considerazione l'implementazione di test automatici del tuo nuovo processo di distribuzione per assicurarti che funzioni come previsto.