Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Workflow de déploiement des blue/green services Amazon ECS
Le processus de blue/green déploiement d'Amazon ECS suit une approche structurée en six phases distinctes qui garantissent des mises à jour d'applications sûres et fiables. Chaque phase a un objectif spécifique en validant et en faisant passer votre application de la version actuelle (bleu) à la nouvelle version (vert).
-
Phase de préparation : création de l’environnement vert à côté de l’environnement bleu existant. Cela inclut la mise à disposition de nouvelles révisions de service et la préparation des groupes cibles.
-
Phase de déploiement : déploiement de la nouvelle version du service dans un environnement vert. Amazon ECS lance de nouvelles tâches à l’aide de la révision de service mise à jour tandis que l’environnement bleu continue de desservir le trafic de production.
-
Phase de test : validation de l’environnement vert à l’aide du routage du trafic de test. L’Application Load Balancer dirige les requêtes de test vers l’environnement vert tandis que le trafic de production reste en mode bleu.
-
Phase de transfert du trafic : déplacement du trafic de production du bleu au vert en fonction de votre stratégie de déploiement configurée. Cette phase inclut des points de contrôle de surveillance et de validation.
-
Phase de surveillance : surveillance de l’état de l’application, des métriques de performance et des états d’alarme pendant la durée de l’intégration. Une opération de restauration est lancée lorsque des problèmes sont détectés.
-
Phase d’achèvement : finalisation du déploiement en résiliant l’environnement bleu ou en le maintenant pour d’éventuels scénarios de restauration, en fonction de votre configuration.
Flux de travail
Le schéma suivant illustre le flux de blue/green déploiement complet, illustrant l'interaction entre Amazon ECS et Application Load Balancer :
Le processus de déploiement amélioré inclut les étapes détaillées suivantes :
-
État initial : le service bleu (production actuelle) gère 100 % du trafic de production. L’Application Load Balancer possède un écouteur unique avec des règles qui acheminent toutes les requêtes vers le groupe cible bleu contenant des tâches bleues saines.
-
Allocation d’un environnement vert : Amazon ECS crée de nouvelles tâches à l’aide de la définition de tâche mise à jour. Ces tâches sont enregistrées auprès d’un nouveau groupe cible vert, mais ne reçoivent aucun trafic au départ.
-
Validation de la surveillance de l’état : l’Application Load Balancer effectue des surveillances de l’état sur les tâches vertes. Ce n’est que lorsque les tâches vertes ont satisfait aux surveillances de l’état que le déploiement passe à la phase suivante.
-
Routage du trafic de test : si elles sont configurées, les règles d’écoute de l’Application Load Balancer acheminent certains types de trafic (tels que les requêtes avec des en-têtes de test) vers l’environnement vert à des fins de validation, tandis que le trafic de production reste sur l’environnement bleu. Ceci est contrôlé par le même écouteur qui gère le trafic de production, en utilisant des règles différentes basées sur les attributs des requêtes.
-
Transfert du trafic de production : en fonction de la configuration de déploiement, le trafic passe du bleu au vert. Dans blue/green les déploiements ECS, il s'agit d'un changement immédiat (en une seule fois) où 100 % du trafic passe de l'environnement bleu à l'environnement vert. L’Application Load Balancer utilise un écouteur unique avec des règles d’écoute qui contrôlent la distribution du trafic entre les groupes cibles bleus et verts en fonction des pondérations.
-
Surveillance et validation : tout au long du transfert de trafic, Amazon ECS surveille CloudWatch les mesures, les états d'alarme et l'état du déploiement. Des déclencheurs de restauration automatique s’activent si des problèmes sont détectés.
-
Durée de l’intégration : durée pendant laquelle les révisions de service bleues et vertes sont exécutées simultanément après le transfert du trafic de production.
-
Résiliation de l’environnement bleu : une fois le transfert de trafic et la validation réussis, l’environnement bleu est résilié pour libérer les ressources du cluster, ou maintenu pour permettre une restauration rapide.
-
État final : l’environnement vert devient le nouvel environnement de production, gérant 100 % du trafic. Le déploiement est marqué comme réussi.
Étapes du cycle de vie du déploiement
Le processus de blue/green déploiement passe par différentes étapes du cycle de vie (une série d'événements au cours de l'opération de déploiement, tels que le « transfert du trafic après la production »), chacune comportant des responsabilités et des points de contrôle de validation spécifiques. La compréhension de ces étapes vous permet de suivre la progression du déploiement et de résoudre les problèmes de manière efficace.
Chaque étape du cycle de vie peut durer jusqu’à 24 heures. Nous recommandons que la valeur reste inférieure à 24 heures. Cela est dû au fait que les processus asynchrones ont besoin de temps pour déclencher les hooks. Le système expire, échoue lors du déploiement, puis lance une restauration après qu'une étape ait atteint 24 heures. CloudFormation les déploiements sont soumis à des restrictions de délai supplémentaires. Tant que la limite de 24 heures reste en vigueur, elle CloudFormation impose une limite de 36 heures pour l'ensemble du déploiement. CloudFormation fait échouer le déploiement, puis lance une restauration si le processus ne se termine pas dans les 36 heures.
Pour les crochets de pause, vous pouvez configurer le délai d'attente jusqu'à 20 160 minutes (14 jours). Le délai de déploiement global est de 30 jours.
| Étapes du cycle de vie | Description | Utiliser cette étape pour le hook de cycle de vie ? |
|---|---|---|
| RECONCILE_SERVICE | Cette étape ne se produit que lorsque vous démarrez un nouveau déploiement de service avec plus d’une révision de service dans un état ACTIF. | Oui |
| PRE_SCALE_UP | La révision de service verte n’a pas commencé. La révision de service bleue gère 100 % du trafic de production. Il n’y a aucun trafic de test. | Oui |
| SCALE_UP | Le moment où la révision de service verte augmente verticalement jusqu’à 100 % et lance de nouvelles tâches. La révision de service verte ne génère aucun trafic pour le moment. | Non |
| POST_SCALE_UP | La révision de service verte a commencé. La révision de service bleue gère 100 % du trafic de production. Il n’y a aucun trafic de test. | Oui |
| TEST_TRAFFIC_SHIFT | Les révisions de service bleues et vertes sont en cours. La révision de service bleue gère 100 % du trafic de production. La révision de service verte passe de 0 % à 100 % du trafic de test. | Oui (Lambda uniquement) |
| POST_TEST_TRAFFIC_SHIFT | Le transfert du trafic de test est terminé. La révision de service verte gère 100 % du trafic de test. | Oui |
| CHANGEMENT_DE_CIRCULATION_PRÉPRODUCTION | Se produit avant le changement de trafic de production. Pour les blue/green déploiements, cette étape est invoquée une seule fois. | Oui |
| PRODUCTION_TRAFFIC_SHIFT | Le trafic de production est transféré vers la révision de service verte. La révision de service verte passe de 0 % à 100 % du trafic de production. | Oui (Lambda uniquement) |
| POST_PRODUCTION_TRAFFIC_SHIFT | Le transfert du trafic de production est terminé. | Oui |
| BAKE_TIME | Durée pendant laquelle les révisions de service bleues et vertes sont exécutées simultanément. | Non |
| CLEAN_UP | La révision de service bleue a été complètement réduite à 0 tâches en cours d’exécution. Au terme de cette étape, la révision de service verte devient la révision de service de production. | Non |
Chaque étape du cycle de vie comprend des points de contrôle de validation intégrés qui doivent être validés avant de passer à l’étape suivante. Si une validation échoue, le déploiement peut être automatiquement annulé pour garantir la disponibilité et la fiabilité du service.
Lorsque vous utilisez une fonction Lambda, celle-ci doit terminer le travail ou renvoyer EN_COURS dans les 15 minutes. Vous pouvez utiliser le callBackDelaySeconds pour retarder l’appel à Lambda. Pour plus d'informations, consultez la fonction app.py
