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.
Flux de travail des déploiements blue/green de services Amazon ECS
Le processus de blue/green déploiement d'Amazon ECS suit une approche structurée comportant 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 travail de blue/green déploiement complet, illustrant l'interaction entre Amazon ECS et l'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 les blue/green déploiements ECS, il s'agit d'un changement immédiat (all-at-once) où 100 % du trafic est transféré de l'environnement bleu vers 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 les CloudWatch métriques, 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 des étapes distinctes du cycle de vie (une série d'événements au cours de l'opération de déploiement, tels que « après le transfert du trafic de 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 au déploiement, puis lance une restauration après une période de 24 heures. CloudFormation les déploiements sont soumis à des restrictions de délai d'expiration supplémentaires. Bien que la limite de 24 heures reste en vigueur, elle CloudFormation impose une limite de 36 heures à l'ensemble du déploiement. CloudFormation échoue au déploiement, puis lance une annulation si le processus ne se termine pas dans les 36 heures.
| É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 |
| 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 |
| 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 |
| 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
