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.
Déploiements linéaires Amazon ECS
Les déploiements linéaires déplacent progressivement le trafic de l'ancienne révision du service vers la nouvelle, par incréments égaux au fil du temps, ce qui vous permet de surveiller chaque étape avant de passer à la suivante. Grâce aux déploiements linéaires d'Amazon ECS, contrôlez le rythme du transfert du trafic et validez les nouvelles révisions de service en fonction de volumes croissants de trafic de production. Cette approche fournit un moyen contrôlé de déployer les modifications avec la possibilité de surveiller les performances à chaque incrément.
Ressources impliquées dans un déploiement linéaire
Les ressources suivantes sont impliquées dans les déploiements linéaires d'Amazon ECS :
-
Transfert de trafic : processus utilisé par Amazon ECS pour déplacer le trafic de production. Pour les déploiements linéaires Amazon ECS, le trafic est transféré par incréments de pourcentage égaux avec des temps d'attente configurables entre chaque incrément.
-
Pourcentage d'étape : pourcentage de trafic à modifier à chaque incrément au cours d'un déploiement linéaire. Ce champ prend Double comme valeur, et les valeurs valides sont comprises entre 3,0 et 100,0.
-
Temps de cuisson par étapes : durée d'attente entre chaque incrément de changement de trafic lors d'un déploiement linéaire. Les valeurs valides sont comprises entre 0 et 1 440 minutes.
-
Temps de préparation du déploiement : temps, en minutes, qu'Amazon ECS attend après avoir transféré tout le trafic de production vers la nouvelle révision de service, avant de mettre fin à l'ancienne révision de service. Il s'agit de la durée pendant laquelle les révisions de service en bleu et en vert sont exécutées simultanément après le déplacement du trafic de production.
-
Étapes du cycle de vie : une série d’événements au cours de l’opération de déploiement, tels que le « après transfert du trafic de production » :
-
Hook du cycle de vie : fonction Lambda ou point de pause à une étape spécifique du cycle de vie. Les hooks Lambda invoquent les fonctions Lambda que vous avez définies pour exécuter du code personnalisé. Les crochets de pause interrompent le déploiement et attendent que vous appeliez
ContinueServiceDeploymentpour continuer. Les hooks sont configurés pourPRODUCTION_TRAFFIC_SHIFTouPRE_PRODUCTION_TRAFFIC_SHIFTsont invoqués à chaque étape du transfert du trafic de production. -
Groupe cible : ressource Elastic Load Balancing utilisée pour acheminer les requêtes vers une ou plusieurs cibles enregistrées (par exemple, des instances EC2). Lorsque vous créez un écouteur, vous spécifiez un groupe cible pour son action par défaut. Le trafic est transféré vers le groupe cible spécifié dans la règle de l'écouteur.
-
Écouteur : une ressource Elastic Load Balancing qui vérifie les demandes de connexion à l’aide du protocole et du port que vous configurez. Les règles que vous définissez pour un écouteur déterminent la manière dont Amazon ECS achemine les requêtes vers ses cibles enregistrées.
-
Règle : ressource Elastic Load Balancing associée à un écouteur. Une règle définit la manière dont les requêtes sont acheminées et comprend une action, une condition et une priorité.
Considérations
Tenez compte des éléments suivants lors du choix d’un type de déploiement :
-
Utilisation des ressources : les déploiements linéaires exécutent temporairement les révisions de service bleue et verte simultanément, ce qui peut doubler votre utilisation des ressources pendant les déploiements.
-
Surveillance du déploiement : les déploiements linéaires fournissent des informations détaillées sur l'état du déploiement, ce qui vous permet de surveiller chaque étape du processus de déploiement et chaque incrément de transfert de trafic.
-
Annulation : les déploiements linéaires permettent de revenir plus facilement à la version précédente si des problèmes sont détectés, car la révision bleue est maintenue jusqu'à la fin du temps de cuisson.
-
Validation progressive : les déploiements linéaires vous permettent de valider la nouvelle révision en fonction de volumes croissants de trafic de production, ce qui renforce la confiance dans le déploiement.
-
Durée du déploiement : les déploiements linéaires prennent plus de temps que les déploiements complets en raison du déplacement progressif du trafic et des temps d'attente entre les étapes.
Comment fonctionne le déploiement linéaire
Le processus de déploiement linéaire 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.
-
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 linéaire du trafic : déplacez progressivement le trafic de production du bleu au vert par incréments de pourcentage égaux en fonction de la stratégie de déploiement que vous avez configurée.
-
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 : finalisez le déploiement en mettant fin à l'environnement bleu.
La phase de transfert linéaire du trafic suit les étapes suivantes :
-
Initiale : le déploiement commence avec 100 % du trafic acheminé vers la version bleue (actuelle) du service. La (nouvelle) révision de service verte reçoit du trafic de test mais aucun trafic de production au départ.
-
Déplacement progressif du trafic - Le trafic passe progressivement du bleu au vert par paliers de pourcentage égaux. Par exemple, avec une configuration par étapes à 10,0 %, les changements de trafic se produisent comme suit :
-
Étape 1 : 10,0 % au vert, 90,0 % au bleu
-
Étape 2 : 20,0 % au vert, 80,0 % au bleu
-
Étape 3 : 30,0 % au vert, 70,0 % au bleu
-
Et ainsi de suite jusqu'à ce que 100 % atteigne le vert
-
-
Temps de cuisson par étapes : entre chaque incrément de changement de trafic, le déploiement attend une durée configurable (temps de cuisson par étapes) pour permettre de surveiller et de valider les performances de la nouvelle révision en fonction de l'augmentation de la charge de trafic. Notez que le temps de cuisson de la dernière étape est ignoré une fois que le trafic est décalé de 100,0 %.
-
Hooks du cycle de vie : des fonctions Lambda facultatives ou des crochets de pause peuvent être configurés à différentes étapes du cycle de vie pendant le déploiement afin d'effectuer une validation, une surveillance ou une logique personnalisée automatisées. Les hooks sont configurés pour
PRODUCTION_TRAFFIC_SHIFTouPRE_PRODUCTION_TRAFFIC_SHIFTsont invoqués à chaque étape du transfert du trafic de production.
Étapes du cycle de vie du déploiement
Le processus de déploiement linéaire passe par différentes étapes du cycle de vie, 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 et, en outre, chaque étape de changement de trafic dans PRODUCTION_TRAFFIC_SHIFT 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 | Support Lifecycle Hook |
|---|---|---|
| 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 chaque incrément de changement de trafic de production. Les hooks de cycle de vie configurés pour cette étape sont invoqués à chaque étape du changement de trafic. | Oui |
| PRODUCTION_TRAFFIC_SHIFT | Le trafic passe progressivement du bleu au vert par incréments de pourcentage égaux jusqu'à ce que le vert reçoive 100 % du trafic. Chaque changement de trafic invoque un hook de cycle de vie avec un délai d'expiration de 24 heures. | 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 |
