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 font progressivement passer le trafic de l'ancienne version du service à la nouvelle par incréments égaux au fil du temps, ce qui vous permet de surveiller chaque étape avant de passer à la suivante. Avec les déploiements linéaires d'Amazon ECS, contrôlez le rythme de transfert du trafic et validez les nouvelles révisions de service en fonction de l'augmentation du 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 transférer le trafic de production. Pour les déploiements linéaires Amazon ECS, le trafic est déplacé par incréments de pourcentage égaux, avec des temps d'attente configurables entre chaque incrément.
-
Pourcentage d'étape : pourcentage du trafic à déplacer à chaque incrément au cours d'un déploiement linéaire. Ce champ prend la valeur 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.
-
Durée 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 du service, avant de mettre fin à l'ancienne révision du service. Il s'agit de la durée pendant laquelle les révisions des services bleu et 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 » :
-
Lifecycle Hook : fonction Lambda qui s'exécute à un stade spécifique du cycle de vie. Vous pouvez créer une fonction qui vérifie le déploiement. Les fonctions Lambda ou les hooks de cycle de vie configurés pour PRODUCTION_TRAFFIC_SHIFT seront invoqués à chaque étape du transfert du trafic de production.
-
Groupe cible : ressource ELB utilisée pour acheminer les demandes vers une ou plusieurs cibles enregistrées (par exemple, des EC2 instances). 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 : ressource ELB 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 ELB 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 des services bleu et vert 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, vous permettant de surveiller chaque étape du processus de déploiement et chaque augmentation du trafic.
-
Annulation : les déploiements linéaires facilitent le retour à la version précédente en cas de détection de problèmes, car la version bleue est maintenue en cours d'exécution jusqu'à l'expiration du temps de cuisson.
-
Validation progressive : les déploiements linéaires vous permettent de valider la nouvelle révision en fonction de l'augmentation du 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 all-at-once les déploiements en raison du transfert 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 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.
-
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 lorsque 100 % du trafic est acheminé vers la version bleue (actuelle) du service. La version verte (nouvelle) du service reçoit du trafic de test mais aucun trafic de production au départ.
-
Transfert progressif du trafic - Le trafic passe progressivement du bleu au vert par paliers de pourcentage égaux. Par exemple, avec une configuration par étapes de 10,0 %, les changements de trafic se produisent comme suit :
-
Étape 1 : 10,0 % vers le vert, 90 % vers le bleu
-
Étape 2 : 20,0 % vers le vert, 80,0 % vers le bleu
-
Étape 3 : 30,0 % vers le vert, 70,0 % vers le bleu
-
Et ainsi de suite jusqu'à ce que 100 % atteignent le vert
-
-
Temps de cuisson par étapes : entre chaque incrément de transfert de trafic, le déploiement attend une durée configurable (temps de cuisson par étapes) afin de permettre le suivi et la validation des performances de la nouvelle révision compte tenu 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 %.
-
Lifecycle Hooks : les fonctions Lambda facultatives peuvent être exécutées à différentes étapes du cycle de vie au cours du déploiement pour effectuer une validation automatisée, une surveillance ou une logique personnalisée. Les fonctions Lambda ou les hooks de cycle de vie configurés pour PRODUCTION_TRAFFIC_SHIFT seront 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 des étapes distinctes 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. De plus, chaque étape de transfert 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 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 | 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 |
| 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 passe progressivement du bleu au vert par paliers de pourcentage égaux jusqu'à ce que le vert reçoive 100 % du trafic. Chaque changement de trafic déclenche un cycle de vie avec un délai d'expiration de 24 heures. | |
| 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 |
