Migra CodeDeploy blue/green deployments to Amazon ECS blue/green le distribuzioni - Amazon Elastic Container Service
CodeDeploy panoramica sulla distribuzione in blu e verdePanoramica della blue/green distribuzione di Amazon ECSDifferenze di implementazione principaliApprocci per la migrazioneFasi successive

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à.

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

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. Creare un bilanciatore del carico con un listener di produzione e (facoltativamente) uno di test. Ogni listener è configurato con un'unica regola (predefinita) che instrada tutto il traffico verso un singolo gruppo di destinazione (il gruppo di destinazione principale).

  2. Creare un servizio Amazon ECS, configurato per utilizzare il listener e il gruppo di destinazione, con il tipo deploymentController impostato su CODE_DEPLOY. La creazione del servizio comporta la creazione di una serie di attività (blu) registrate con il gruppo di destinazione 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 di Amazon ECS ed Elastic Load Balancing) e vari parametri che controllano 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 integra, è disponibile per i test (facoltativo) e per la produzione. In entrambi i casi, il re-instradamento si ottiene modificando la rispettiva regola del listener in modo tale che punti al gruppo di destinazione secondario associato alla serie di attività verde. Il rollback si ottiene modificando la regola del listener di produzione riportandola al gruppo di destinazione primario.

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 bilanciatore del carico con una regola che includa due gruppi di destinazione con pesi pari a 1 e 0.

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

    • L'ARN di questa regola del listener

    • I due gruppi di destinazione

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

    • Un ruolo IAM facoltativo per eseguire le funzioni Lambda

    • Impostare il tipo deploymentController su ECS e deploymentConfiguration.strategy su BLUE_GREEN. Ciò si traduce nella creazione di un'implementazione del servizio (blu) le cui attività sono registrate nel gruppo di destinazione primario.

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

Differenze di implementazione principali

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 un costrutto precedente sostituito dalle revisioni e dalle implementazioni dei servizi Amazon ECS. Queste offrono una maggiore visibilità sul processo di implementazione, nonché sulla cronologia di implementazione e revisione del servizio.

  • Con CodeDeploy, gli hook del ciclo di vita vengono specificati come parte del AppSpec file a cui viene fornito. CreateDeployment() Ciò significa che gli hook possono essere modificati da un'implementazione all'altra. Con Amazon ECS blu/verde, 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 di 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 indicatore IN_PROGRESS, che segnala che l'hook deve essere invocato ripetutamente fino a quando non determina un SUCCEEDED o FAILED. Per ulteriori informazioni, consultare Hook del ciclo di vita per le implementazioni di servizi Amazon ECS.

Approcci per la migrazione

Esistono tre approcci principali alla migrazione dalle distribuzioni. CodeDeploy blue/green to Amazon ECS blue/green Ogni approccio dispone di caratteristiche diverse in termini di complessità, rischio, capacità di rollback e potenziale tempo 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 si adotta questo approccio, considerare quanto segue:

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

  • Non è previsto un tempo di inattività con una configurazione e una migrazione corrette.

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

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

Utilizzi lo stesso listener di load balancer e gli stessi gruppi target utilizzati per. CodeDeploy Se lo stai usando CloudFormation, vedi. Migrazione di un modello CloudFormation CodeDeploy blue/green deployment template to an Amazon ECS blue/green 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/verde, i listener del bilanciatore del carico devono essere preconfigurati con una regola che includa i due gruppi di destinazione con pesi. Il gruppo di destinazione principale deve essere ponderato a 1 e il gruppo di destinazione alternativo deve essere ponderato a 0.

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

  3. Verificare 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 il bilanciatore del carico esistente

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

Quando si adotta questo approccio, considerare quanto segue:

  • Le interruzioni sono minime. Si verificano solo durante lo scambio di porte per il bilanciamento del carico elastico.

  • Un rollback richiede il ripristino dello swap della porta per il bilanciamento del carico elastico.

  • Il rischio è basso perché vi sono configurazioni parallele. Pertanto è possibile eseguire il test prima dello spostamento del 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. Creare nuovi gruppi di destinazione e nuovi listener (con porte diverse dai listener originali) utilizzando il bilanciatore 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. Verificare la nuova configurazione inviando manualmente il traffico HTTP al servizio. Se tutto va bene, scambiare le porte dei listener originali con quelle dei nuovi listener per instradare 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 bilanciatore 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 avviene a un livello di proxy inverso al di sopra del blue/green sistema di bilanciamento del carico. 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 proxy inverso e se tutte le comunicazioni con il servizio avvengono attraverso di esso (ad esempio, nessuna comunicazione diretta a livello di bilanciatore del carico).

Quando si adotta questo approccio, considerare quanto segue:

  • Ciò richiede un livello di proxy inverso.

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

  • Le interruzioni sono minime. Si verificano solo durante lo scambio di porte per il bilanciamento del carico elastico.

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

  • Il rischio è basso perché vi sono configurazioni parallele. Pertanto è possibile eseguire il test prima dello spostamento del 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 .

    Configurare le risorse appropriate.

  3. Creare un nuovo servizio con ECS come controller di implementazione e BLUE_GREEN come strategia di implementazione, puntando alle nuove risorse del bilanciatore del carico.

  4. Verificare la nuova configurazione testandola tramite il nuovo bilanciatore del carico.

  5. Aggiornare la configurazione del proxy inverso per instradare il traffico verso il nuovo bilanciatore del carico.

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

Fasi successive

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

  • Considerare l'implementazione di test automatici del nuovo processo di implementazione per garantirne il funzionamento previsto.