3 <= 0.5 * 1 => 200| 3 (la valeur calculée est inférieure au minimum) | | 25 |
3 <= 0.5 * 25 => 200| 13 (la valeur est arrondie à la valeur supérieure) | | 400 |
3 <= 0.5 * 400 => 200| 200 | | 800 |
3 <= 0.5 * 800 => 200| 200 (la valeur calculée est supérieure au maximum) | Par exemple, lorsque le seuil est de 3, le disjoncteur se déclenche lorsque le nombre de défaillances atteint 0. Lorsqu’une tâche ne parvient pas à atteindre l’état `RUNNING`, le disjoncteur de déploiement augmente le nombre d’échecs d’une unité. Lorsque le nombre d’échecs est égal à 3, le déploiement est marqué comme `FAILED`. Pour obtenir des exemples supplémentaires sur l'utilisation de l'option de restauration, consultez [Announcing Amazon ECS deployment circuit breaker](https://aws.amazon.com/blogs/containers/announcing-amazon-ecs-deployment-circuit-breaker/) (Annonce du disjoncteur de circuit de déploiement Amazon ECS). # Comment les CloudWatch alarmes détectent les échecs de déploiement d'Amazon ECS Vous pouvez configurer Amazon ECS pour définir le déploiement comme un échec lorsqu'il détecte qu'une CloudWatch alarme spécifiée est passée dans `ALARM` cet état. Vous pouvez éventuellement définir la configuration pour qu'elle revienne au dernier déploiement réussi en cas d'échec d'un déploiement. L'`create-service` AWS CLI exemple suivant montre comment créer un service Linux lorsque les alarmes de déploiement sont utilisées avec l'option de restauration. ``` aws ecs create-service \ --service-name MyService \ --deployment-controller type=ECS \ --desired-count 3 \ --deployment-configuration "alarms={alarmNames=[alarm1Name,alarm2Name],enable=true,rollback=true}" \ --task-definition sample-fargate:1 \ --launch-type FARGATE \ --platform-family LINUX \ --platform-version 1.4.0 \ --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}" ``` Tenez compte des points suivants lorsque vous utilisez la méthode CloudWatch des alarmes Amazon sur un service. + La durée pendant laquelle les révisions de service bleues et vertes se déroulent simultanément après le transfert du trafic de production. Amazon ECS calcule cette période en fonction de la configuration d'alarme associée au déploiement. Vous ne pouvez pas définir cette valeur. + Le paramètre de demande `deploymentConfiguration` contient désormais le type de données `alarms`. Vous pouvez spécifier les noms des alarmes, si vous souhaitez utiliser la méthode et si vous souhaitez lancer une restauration lorsque les alarmes indiquent un échec de déploiement. Pour plus d'informations, consultez le [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)manuel *Amazon Elastic Container Service API Reference*. + La réponse `DescribeServices` donne un aperçu de l'état d'un déploiement, le `rolloutState` et `rolloutStateReason`. Lorsqu'un nouveau déploiement démarre, il commence à l'état `IN_PROGRESS`. Lorsque le service atteint un état stable et que la durée de l'intégration est terminée, l'état du déploiement passe à `COMPLETED`. Si le service n'arrive pas à atteindre un état stable et que l'alarme passe à l'état `ALARM`, le déploiement passe à un état `FAILED`. Un déploiement dans un état `FAILED` ne lancera aucune nouvelle tâche. + Outre les événements de changement d'état de déploiement de service qu'Amazon ECS envoie pour les déploiements qui ont démarré et se sont terminés, Amazon ECS envoie également un événement lorsqu'un déploiement qui utilise des alarmes échoue. Ces événements fournissent des informations sur la raison pour laquelle un déploiement a échoué ou si un déploiement a été démarré en raison d'une restauration. Pour de plus amples informations, veuillez consulter [Événements de modification de l’état de déploiement de service Amazon ECS](ecs_service_deployment_events.md). + Si un nouveau déploiement démarre parce qu'un déploiement précédent a échoué et que la restauration a été activée, le champ `reason` de l'événement de changement d'état de déploiement de service indique que le déploiement a démarré en raison d'une restauration. + Si vous utilisez le disjoncteur de déploiement et les CloudWatch alarmes Amazon pour détecter les défaillances, l'un ou l'autre peut provoquer un échec du déploiement dès que les critères de l'une ou l'autre méthode sont remplis. Une restauration se produit lorsque vous utilisez l'option de restauration pour la méthode à l'origine de l'échec du déploiement. + Les CloudWatch alarmes Amazon ne sont prises en charge que pour les services Amazon ECS qui utilisent le contrôleur de déploiement rolling update (`ECS`). + Vous pouvez configurer cette option à l’aide de la console Amazon ECS ou de l’ AWS CLI. Pour plus d'informations, consultez [Créer un service à l'aide de paramètres définis](create-service-console-v2.md#create-custom-service) et [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) dans la *Référence AWS Command Line Interface *. + Vous remarquerez peut-être que l'état du déploiement reste `IN_PROGRESS` pendant une durée prolongée. La raison en est qu'Amazon ECS ne modifie pas le statut tant qu'il n'a pas supprimé le déploiement actif, et cela ne se produit qu'après la durée de l'intégration. En fonction de votre configuration d'alarme, le déploiement peut sembler prendre plusieurs minutes de plus que lorsque vous n'utilisez pas d'alarmes (même si le nouvel ensemble de tâches principales est augmenté et l'ancien déploiement réduit). Si vous utilisez des CloudFormation délais d'attente, envisagez de les augmenter. Pour de plus amples informations, veuillez consulter [Création de conditions d'attente dans un modèle](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html) dans le *Guide de l'utilisateur AWS CloudFormation *. + Amazon ECS appelle `DescribeAlarms` pour sonder les alarmes. Les appels à prendre en `DescribeAlarms` compte dans les quotas de CloudWatch service associés à votre compte. Si d'autres AWS services appellent`DescribeAlarms`, Amazon ECS risque d'avoir un impact sur le fait d'interroger les alarmes. Par exemple, si un autre service effectue suffisamment d’appels à `DescribeAlarms` pour atteindre le quota, ce service est limité ; Amazon ECS est alors également limité et incapable d’interroger les alarmes. Si une alarme est générée pendant la période de limitation, Amazon ECS peut ne pas la détecter et la restauration peut ne pas avoir lieu. Cela n'a aucun autre impact sur le déploiement. Pour plus d'informations sur les quotas CloudWatch de service, consultez la section [Quotas de CloudWatch service](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.htm) dans le *Guide de CloudWatch l'utilisateur*. + Si une alarme est activée à l’état `ALARM` au début d'un déploiement, Amazon ECS ne surveille pas les alarmes pendant la durée de ce déploiement (il ignore la configuration des alarmes). Ce comportement concerne le cas où vous souhaitez lancer un nouveau déploiement afin de corriger un échec initial. ## Alarmes recommandées Nous vous recommandons d'utiliser les métriques d'alarme suivantes : + Si vous utilisez un Application Load Balancer, utilisez les métriques d'Application Load Balancer `HTTPCode_ELB_5XX_Count` et `HTTPCode_ELB_4XX_Count`. Ces métriques surveillent la présence de pics HTTP. Pour plus d'informations sur les métriques d'Application Load Balancer, consultez CloudWatch les métriques de [votre Application Load](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) Balancer dans *le Guide d'utilisation des* Application Load Balancers. + Si vous avez déjà une application, utilisez les métriques `CPUUtilization` et `MemoryUtilization`. Elles vérifient l'utilisation de l'UC et de la mémoire en pourcentage utilisées par le cluster ou le service. Pour de plus amples informations, veuillez consulter [Considérations](cloudwatch-metrics.md#enable_cloudwatch). + Si vous utilisez des Amazon Simple Queue Service files d'attente dans vos tâches, utilisez la métrique `ApproximateNumberOfMessagesNotVisible` Amazon SQS. Cette métrique vérifie le nombre de messages dans la file d'attente qui sont retardés et qui ne peuvent pas être lus immédiatement. Pour plus d'informations sur les métriques Amazon SQS, consultez la section Mesures [disponibles CloudWatch pour Amazon SQS dans le manuel Amazon](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html) *Simple Queue* Service Developer Guide. ## Durée de l’intégration Lorsque vous utilisez l'option de restauration pour vos déploiements de services, Amazon ECS attend un délai supplémentaire après le déploiement de la révision du service cible avant d'envoyer une alarme. CloudWatch C’est ce que l’on appelle la durée de l’intégration. Cette durée commence lorsque : + toutes les tâches d’une révision de service cible sont en cours d’exécution et en bon état ; + les révisions du service source sont réduites à 0 %. La durée de l’intégration par défaut est inférieure à 5 minutes. Le déploiement de service est marqué comme terminé après l’expiration de la durée de l’intégration. Vous pouvez configurer la durée de l’intégration pour un déploiement continu. Lorsque vous utilisez des CloudWatch alarmes pour détecter une panne, si vous modifiez le temps de cuisson, puis que vous décidez de choisir la valeur par défaut d'Amazon ECS, vous devez définir manuellement le temps de cuisson. # Hooks de cycle de vie pour les déploiements de service Amazon ECS Lorsqu’un déploiement démarre, il passe par différentes étapes du cycle de vie. Ces étapes peuvent avoir l’état EN\$1COURS ou RÉUSSI. Vous pouvez utiliser les hooks du cycle de vie, qui sont des fonctions Lambda qu’Amazon ECS exécute en votre nom à des étapes du cycle de vie spécifiées. Les fonctions peuvent être l’une des suivantes : + Une API asynchrone qui valide la surveillance de l’état endéans 15 minutes. + Une API de consultation qui lance un autre processus asynchrone qui évalue l’achèvement du hook de cycle de vie. Une fois l’exécution de la fonction terminée, elle doit renvoyer un `hookStatus` pour que le déploiement se poursuive. Si aucun `hookStatus` n’est renvoyé ou si la fonction échoue, le déploiement est annulé. Voici les valeurs pour `hookStatus` : + `SUCCEEDED` : le déploiement se poursuit jusqu’à l’étape suivante du cycle de vie + `FAILED` : le déploiement revient au dernier déploiement réussi. + `IN_PROGRESS` : Amazon ECS réexécute la fonction après un court laps de temps. Par défaut, il s’agit d’un intervalle de 30 secondes, mais cette valeur est personnalisable en renvoyant un `callBackDelay` avec le `hookStatus`. L’exemple suivant montre comment renvoyer un `hookStatus` avec un délai de rappel personnalisé. Dans cet exemple, Amazon ECS réessaierait ce hook au bout de 60 secondes au lieu des 30 secondes par défaut : ``` { "hookStatus": "IN_PROGRESS", "callBackDelay": 60 } ``` En cas de restauration, Amazon ECS exécute les hooks de cycle de vie pour les étapes du cycle de vie suivantes : + PRODUCTION\$1TRAFFIC\$1SHIFT + TEST\$1TRAFFIC\$1SHIFT ## Données utiles de cycle de vie Lorsque vous configurez des hooks de cycle de vie pour vos déploiements de service ECS, Amazon ECS invoque ces hooks à des étapes spécifiques du processus de déploiement. Chaque étape du cycle de vie fournit des données utiles JSON avec des informations sur l’état actuel du déploiement. Ce document décrit la structure les données utiles pour chaque étape du cycle de vie. ### Structure de données utiles communes Toutes les données utiles liées aux étapes du cycle de vie incluent les champs communs suivants : + `serviceArn` : l’Amazon Resource Name (ARN) du service. + `targetServiceRevisionArn` : lÂRN de la révision de service cible est en cours de déploiement. + `testTrafficWeights`- Une carte de révision des services en fonction ARNs des pourcentages de pondération du trafic de test correspondants. + `productionTrafficWeights`- Une carte de révision des services en fonction ARNs des pourcentages de pondération du trafic de production correspondants. ### Données utiles relatives aux étapes de cycle de vie #### RECONCILE\$1SERVICE Cette étape a lieu au début du processus de déploiement lorsque le service est en cours de réconciliation. Voici un exemple de données utiles pour cette étape du cycle de vie. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": { "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100, "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0 }, "productionTrafficWeights": { "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100, "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0 } } ``` **Résultats attendus à cette étape :** + Le jeu de tâches principal est à un niveau de 0 % #### PRE\$1SCALE\$1UP Cette étape a lieu avant que les nouvelles tâches ne soient augmentée verticalement. Voici un exemple de données utiles pour cette étape du cycle de vie. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": {} } ``` **Résultats attendus à cette étape :** + Les tâches de révision de service verte sont à un niveau de 0 % #### POST\$1SCALE\$1UP Cette étape intervient une fois que les nouvelles tâches ont été augmentées verticalement et qu’elles sont saines. Voici un exemple de données utiles pour cette étape du cycle de vie. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": {} } ``` **Résultats attendus à cette étape :** + Les tâches de révision de service verte sont à un niveau de 100 % + Les tâches dans la révision de service verte sont saines #### TEST\$1TRAFFIC\$1SHIFT Cette étape se produit lorsque le trafic de test est transféré vers les tâches de révision de service verte. Voici un exemple de données utiles pour cette étape du cycle de vie. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": { "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100, "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0 }, "productionTrafficWeights": {} } ``` **Résultats attendus à cette étape :** + Le trafic de test est en train de passer aux tâches de révision de service verte. #### POST\$1TEST\$1TRAFFIC\$1SHIFT Cette étape intervient une fois que le trafic de test a été entièrement transféré vers les nouvelles tâches. Voici un exemple de données utiles pour cette étape du cycle de vie. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": {} } ``` **Résultats attendus à cette étape :** + 100 % du trafic de test a été affecté aux tâches de révision de service verte. #### PRODUCTION\$1TRAFFIC\$1SHIFT Cette étape se produit lorsque le trafic de production est transféré vers les tâches de révision de service verte. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": { "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100, "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0 } } ``` **Résultats attendus à cette étape :** + Le trafic de production est en train de passer à la révision de service verte. #### POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT Cette étape intervient une fois que le trafic de production a été entièrement transféré aux tâches de révision de service verte. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": {} } ``` **Résultats attendus à cette étape :** + 100 % du trafic de production a été transféré vers les tâches de révision de service verte. ### Catégories d’étapes du cycle de vie Les étapes du cycle de vie entrent dans deux catégories principales : 1. **Étapes d’invocation uniques** : ces étapes ne sont invoquées qu’une seule fois lors du déploiement d’un service : + PRE\$1SCALE\$1UP + POST\$1SCALE\$1UP + POST\$1TEST\$1TRAFFIC\$1SHIFT + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT 1. **Étapes d’invocation récurrentes** : ces étapes peuvent être invoquées plusieurs fois au cours du déploiement d’un service, par exemple lors d’une opération de restauration : + TEST\$1TRAFFIC\$1SHIFT + PRODUCTION\$1TRAFFIC\$1SHIFT ### État du déploiement pendant les hooks de cycle de vie Pendant l’exécution des hooks de cycle de vie, le statut de déploiement sera `IN_PROGRESS` pour toutes les étapes du cycle de vie. | Étape du cycle de vie | Statut du déploiement | | --- | --- | | RECONCILE\$1SERVICE | EN\$1COURS | | PRE\$1SCALE\$1UP | EN\$1COURS | | POST\$1SCALE\$1UP | EN\$1COURS | | TEST\$1TRAFFIC\$1SHIFT | EN\$1COURS | | POST\$1TEST\$1TRAFFIC\$1SHIFT | EN\$1COURS | | PRODUCTION\$1TRAFFIC\$1SHIFT | EN\$1COURS | | POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | EN\$1COURS | # Arrêt de déploiements de service Amazon ECS Vous pouvez arrêter manuellement un déploiement lorsqu'un déploiement défaillant n'a pas été détecté par le disjoncteur ou les CloudWatch alarmes. Les types d’arrêt suivants sont disponibles : + Restauration : cette option restaure le déploiement de service à la version précédente du service. Vous pouvez utiliser cette option même si vous n’avez pas configuré le déploiement de service pour l’option de restauration. Vous pouvez arrêter un déploiement qui se trouve dans l’un des états suivants. Pour de plus amples informations sur les états de déploiement de service, consultez la section [Affichage de l’historique d’un service à l’aide des déploiements de service Amazon ECS](service-deployment.md). + EN ATTENTE : le déploiement de service passe à l’état RESTAURATION\$1DEMAMDÉE, puis l’opération de restauration commence. + EN\$1COURS : le déploiement de service passe à l’état RESTAURATION\$1DEMAMDÉE, puis l’opération de restauration commence. + ARRÊT\$1DEMANDÉ : le déploiement de service continue de s’arrêter. + RESTAURATION\$1DEMAMDÉE : le déploiement de service poursuit l’opération de restauration. + RESTAURATION\$1EN\$1COURS : le déploiement de service poursuit l’opération de restauration. ## Procédure Avant de commencer, configurez les autorisations requises pour consulter les déploiements de service. Pour de plus amples informations, veuillez consulter [Autorisations requises pour consulter les déploiements de service Amazon ECS](service-deployment-permissions.md). ------ #### [ Amazon ECS Console ] 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Sur la page **Clusters**, choisissez le cluster. 1. Sur la page des détails du cluster, dans la section **Services**, choisissez le service. La page des détails du service s’affiche. 1. Sur la page des détails du service, choisissez **Déploiements**. La page des déploiements s’affiche. 1. Sous **Déploiement en cours**, choisissez **Restaurer**. Ensuite, dans la fenêtre de confirmation, choisissez **Restaurer**. ------ #### [ AWS CLI ] 1. Exécutez `list-service-deployments` pour récupérer l’ARN de déploiement de service. Remplacez le *user-input* par vos valeurs. ``` aws ecs list-service-deployments --cluster cluster-name --service service-name ``` Notez le `serviceDeploymentArn` du déploiement que vous souhaitez arrêter. ``` { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5", "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/cluster-name/service-name", "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/cluster-name", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/cluster-name/service-name/4980306466373577095", "status": "SUCCESSFUL" } ] } ``` 1. Exécutez `stop-service-deployments`. Utilisez celui `serviceDeploymentArn` qui a été renvoyé par `list-service-deployments`. Remplacez le *user-input* par vos valeurs. ``` aws ecs stop-service-deployment --service-deployment-arn arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 --stop-type ROLLBACK ``` ------ ## Étapes suivantes Décidez quelles modifications doivent être apportées au service, puis mettez-le à jour. Pour de plus amples informations, veuillez consulter [Mettre à jour un service Amazon ECS](update-service-console-v2.md). # Déploiement de services Amazon ECS en remplaçant des tâches Lorsque vous créez un service qui utilise le type de déploiement *Mise à jour propagée* (`ECS`), le planificateur de service Amazon ECS remplace les tâches en cours d’exécution par de nouvelles tâches. Le nombre de tâches ajoutées au service ou supprimées du service par Amazon ECS lors d'une mise à jour propagée est contrôlé par la configuration de déploiement du service. Amazon ECS utilise les paramètres suivants pour déterminer le nombre de tâches : + Le `minimumHealthyPercent` représente la limite inférieure du nombre de tâches qui devraient être exécutées et saines pour un service lors d'un déploiement continu ou lorsqu'une instance de conteneur est épuisée, en pourcentage du nombre de tâches souhaité pour le service. Cette valeur est arrondie à la valeur supérieure. Par exemple, si le pourcentage minimum d'instances saines est `50` et que le nombre de tâches souhaité est de quatre, le planificateur peut arrêter deux tâches existantes avant de démarrer deux nouvelles tâches. De même, si le pourcentage de santé minimum est de 75 % et que le nombre de tâches souhaité est de deux, le planificateur ne peut pas arrêter de tâche car la valeur résultante est également de deux. + Le `maximumPercent` représente la limite supérieure du nombre de tâches qui doivent être exécutées pour un service lors d'un déploiement continu ou lorsqu'une instance de conteneur est épuisée, en pourcentage du nombre de tâches souhaité pour un service. Cette valeur est arrondie à la valeur inférieure. Par exemple, si le pourcentage maximum est de quatre `200` et que le nombre de tâches souhaité est de quatre, le planificateur peut démarrer quatre nouvelles tâches avant d'arrêter quatre tâches existantes. De même, si le pourcentage maximal est `125` et que le nombre de tâches souhaité est de trois, le planificateur ne peut pas démarrer de tâche, car la valeur résultante est également de trois. Lors d'un déploiement continu, lorsque les tâches ne fonctionnent plus correctement, Amazon ECS les remplace afin de maintenir la disponibilité de votre service `minimumHealthyPercent` et d'en protéger la disponibilité. Les tâches défectueuses sont remplacées à l'aide de la même révision de service à laquelle elles appartiennent. Cela garantit que le remplacement de tâches défectueux dans la révision source est indépendant des échecs de tâches dans la révision cible. Lorsque le `maximumPercent` paramètre le permet, le planificateur lance des tâches de remplacement avant d'arrêter celles qui ne fonctionnent pas correctement. Si le `maximumPercent` paramètre empêche le planificateur de démarrer d'abord une tâche de remplacement, il arrête une tâche défectueuse à la fois pour libérer de la capacité avant de lancer une tâche de remplacement. **Important** Lorsque vous définissez un pourcentage minimum ou maximal d'instances saines, vous devez vous assurer que le planificateur peut arrêter ou démarrer au moins une tâche lorsqu'un déploiement est déclenché. Si votre service a un déploiement bloqué en raison d'une configuration de déploiement non valide, un message d'événement de service est envoyé. Pour de plus amples informations, veuillez consulter [service (*service-name*) n'a pas pu arrêter ou démarrer des tâches pendant un déploiement en raison de la configuration du déploiement du service. Mettez à jour la valeur minimumHealthyPercent ou MaximumPercent et réessayez.](service-event-messages-list.md#service-event-messages-7). Les déploiements progressifs s’appuient sur deux méthodes permettant d’identifier rapidement l’échec d’un déploiement de service : + [Détection des pannes par le disjoncteur de déploiement Amazon ECS](deployment-circuit-breaker.md) + [Comment les CloudWatch alarmes détectent les échecs de déploiement d'Amazon ECS](deployment-alarm-failure.md) Les méthodes peuvent être utilisées séparément ou conjointement. Lorsque les deux méthodes sont utilisées, le déploiement est défini en échec dès que les critères d’échec de l’une ou l’autre méthode sont remplis. Suivez les instructions suivantes pour déterminer quelle méthode utiliser : + Disjoncteur : utilisez cette méthode lorsque vous souhaitez arrêter un déploiement car les tâches ne peuvent pas démarrer. + CloudWatch alarmes - Utilisez cette méthode lorsque vous souhaitez arrêter un déploiement en fonction des métriques de l'application. Les deux méthodes permettent de restaurer la version de service précédente. ## Résolution des images de conteneurs Amazon ECS résout les noms des images de conteneurs et toutes les balises d’image spécifiées dans la définition de la tâche en condensés d’images de conteneurs. Si vous créez un service qui exécute et gère une seule tâche, cette tâche est utilisée pour établir des condensés d’images pour les conteneurs de la tâche. Si vous créez un service qui exécute et gère plusieurs tâches, la première tâche démarrée par le planificateur de service lors du déploiement est utilisée pour établir les condensés d’images pour les conteneurs contenus dans les tâches. Si au moins trois tentatives d’établissement des condensés d’images du conteneur échouent, le déploiement se poursuit sans résolution de condensé d’image. Si le disjoncteur de déploiement est activé, le déploiement échoue également et est annulé. Une fois les condensés des images du conteneur établis, Amazon ECS les utilise pour démarrer toutes les autres tâches souhaitées et pour toute future mise à jour de service. Ainsi, toutes les tâches d’un service exécutent toujours des images de conteneur identiques, ce qui garantit la cohérence des versions de votre logiciel. Vous pouvez configurer ce comportement pour chaque conteneur de votre tâche en utilisant le paramètre `versionConsistency` figurant dans la définition du conteneur. Pour de plus amples informations, veuillez consulter [versionConsistency](task_definition_parameters.md#ContainerDefinition-versionconsistency). **Note** Les versions de l’agent Amazon ECS inférieures à `1.31.0` ne prennent pas en charge la résolution du condensé d’image. Les versions de l’agent `1.31.0` à `1.69.0` ne prenent en charge la résolution de condensé d’images que pour les images transférées vers les référentiels Amazon ECR. Les versions de l’agent `1.70.0` ou supérieures prennent en charge la résolution de condensé d’image pour toutes les images. La version de plateforme Linux Fargate minimale pour la résolution du résumé d’image est `1.3.0`. La version de plateforme Windows Fargate minimale pour la résolution du condensé d’image est `1.0.0`. Amazon ECS ne capture pas les résumés des conteneurs annexes gérés par Amazon ECS, tels que l'agent de GuardDuty sécurité Amazon ou le proxy Service Connect. Pour réduire la latence potentielle associée à la résolution des images de conteneur dans les services comportant plusieurs tâches, exécutez la version `1.83.0` ou supérieure de l’agent Amazon ECS sur les instances de conteneur EC2. Pour éviter toute latence potentielle, spécifiez des condensés d’images de conteneur dans votre définition de tâche. Si vous créez un service avec un nombre de tâches souhaité égal à zéro, Amazon ECS ne peut pas établir de résumés de conteneurs tant que vous n’avez pas déclenché un autre déploiement du service avec un nombre de tâches souhaité supérieur à zéro. Pour établir des condensés d’images mis à jour, vous pouvez forcer un nouveau déploiement. Les condensés mis à jour seront utilisés pour démarrer de nouvelles tâches et n’affecteront pas les tâches déjà en cours. Pour plus d'informations sur le forçage de nouveaux déploiements, consultez [forceNewDeployment](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html#ECS-UpdateService-request-forceNewDeployment)la *référence des API Amazon ECS*. Lorsque vous utilisez des fournisseurs de capacité EC2, si la capacité est insuffisante pour démarrer une tâche lors du déploiement initial, la cohérence des versions logicielles peut échouer. Pour garantir la cohérence des versions même lorsque la capacité est limitée, définisse explicitement `versionConsistency: "enabled"` dans la configuration de votre conteneur de définition de tâches plutôt que de vous fier au comportement par défaut. Cela oblige Amazon ECS à attendre que la capacité soit disponible avant de procéder au déploiement. # Pratiques exemplaires relatives aux paramètres d’un service Amazon ECS Pour éviter toute durée d’indisponibilité de l’application, le processus de déploiement est le suivant : 1. Démarrez les nouveaux conteneurs d’applications tout en maintenant les conteneurs existants en activité. 1. Vérifiez que les nouveaux conteneurs sont sains. 1. Arrêtez les anciens conteneurs. En fonction de la configuration de votre déploiement et de la quantité d’espace libre non réservé dans votre cluster, plusieurs cycles peuvent être nécessaires pour remplacer toutes les anciennes tâches par de nouvelles tâches. Il existe deux options de configuration de service que vous pouvez utiliser pour modifier le nombre : + `minimumHealthyPercent` : 100 % (par défaut) La limite inférieure du nombre de tâches pour lesquelles votre service doit rester dans l’état `RUNNING` lors d’un déploiement. Cette valeur est exprimée en tant que pourcentage de `desiredCount` arrondi à la valeur supérieure la plus proche. Ce paramètre vous permet de procéder au déploiement sans avoir recours à une capacité de cluster supplémentaire. + `maximumPercent` : 200 % (par défaut) La limite supérieure du nombre de tâches pour votre service autorisées dans l’état `RUNNING` ou `PENDING` pendant un déploiement. Cette valeur est exprimée en tant que pourcentage de `desiredCount` arrondi à la valeur inférieure la plus proche. **Exemple : options de configuration par défaut** Considérons le service suivant qui comporte six tâches, déployées dans un cluster pouvant accueillir huit tâches au total. Les options de configuration de service par défaut ne permettent pas au déploiement d’aller en dessous de 100 % des six tâches souhaitées. Le processus de déploiement est le suivant : 1. L’objectif est de remplacer les six tâches. 1. Le planificateur lance deux nouvelles tâches, car les paramètres par défaut exigent que six tâches soient en cours d’exécution. Il existe désormais six tâches existantes et deux nouvelles tâches. 1. Le planificateur arrête deux des tâches existantes. Il existe désormais quatre tâches existantes et deux nouvelles tâches. 1. Le planificateur lance deux nouvelles tâches supplémentaires. Il existe désormais quatre tâches existantes et quatre nouvelles tâches. 1. Le planificateur arrête deux des tâches existantes. Il existe désormais deux tâches existantes et quatre nouvelles. 1. Le planificateur lance deux nouvelles tâches supplémentaires. Il y a maintenant deux tâches existantes et six nouvelles tâches 1. Le planificateur arrête les deux dernières tâches existantes. Il y a désormais six nouvelles tâches. Dans l’exemple ci-dessus, si vous utilisez les valeurs par défaut pour les options, il y a une attente de 2,5 minutes pour chaque nouvelle tâche qui démarre. En outre, l’équilibreur de charge devra peut-être attendre 5 minutes pour que l’ancienne tâche s’arrête. **Exemple : modifier `minimumHealthyPercent`** Vous pouvez accélérer le déploiement en définissant la valeur `minimumHealthyPercent` sur 50 %. Considérons le service suivant qui comporte six tâches, déployées dans un cluster pouvant accueillir huit tâches au total. Le processus de déploiement est le suivant : 1. L’objectif est de remplacer six tâches. 1. Le planificateur arrête trois des tâches existantes. Il subsiste trois tâches en cours d’exécution qui correspondent à la valeur de `minimumHealthyPercent`. 1. Le planificateur lance cinq nouvelles tâches. Il existe trois tâches existantes et cinq nouvelles tâches. 1. Le planificateur arrête les trois tâches existantes restantes. Il y a cinq nouvelles tâches 1. Le planificateur lance la dernière nouvelle tâche. Il y a six nouvelles tâches. **Exemple : modifier l’espace libre du cluster** Vous pouvez également ajouter de l’espace libre afin de pouvoir exécuter des tâches supplémentaires. Considérons le service suivant qui comporte six tâches, déployées dans un cluster pouvant accueillir dix tâches au total. Le processus de déploiement est le suivant : 1. L’objectif est de remplacer les tâches existantes. 1. Le planificateur arrête trois des tâches existantes. Il y a trois tâches existantes. 1. Le planificateur lance six nouvelles tâches. Il y a maintenant trois tâches existantes et six nouvelles tâches 1. Le planificateur arrête les trois tâches existantes. Il y a six nouvelles tâches. **Recommandations** Utilisez les valeurs suivantes pour les options de configuration du service lorsque vos tâches sont inactives pendant un certain temps et que leur taux d’utilisation n’est pas élevé. + `minimumHealthyPercent` : 50 % + `maximumPercent` : 200 % # Création d’un déploiement de mise à jour propagée Amazon ECS Créez un service pour exécuter et maintenir simultanément un nombre spécifié d’instances d’une définition de tâche dans un cluster. Si l'une de vos tâches échoue ou s'arrête, le planificateur de service d'Amazon ECS service lance une autre instance de votre définition de tâche pour la remplacer. Cela permet de maintenir le nombre de tâches souhaité dans le service. Définissez les paramètres de configuration suivants avant de créer un service : + Deux options de calcul permettent de distribuer vos tâches. + Une **capacity provider strategy** (stratégie de fournisseurs de capacités) permet à Amazon ECS de distribuer vos tâches avec un ou plusieurs fournisseurs de capacité. Si vous souhaitez exécuter vos charges de travail sur des instances gérées Amazon ECS, vous devez utiliser l’option de stratégie de fournisseur de capacité. + Un **type de lancement** permet à Amazon ECS de lancer vos tâches directement sur Fargate ou sur les instances Amazon EC2 enregistrées dans vos clusters. Si vous souhaitez exécuter vos charges de travail sur des instances gérées Amazon ECS, vous devez utiliser l’option de stratégie de fournisseur de capacité. + Les définitions de tâches qui utilisent le mode réseau `awsvpc` ou les services configurés pour utiliser un équilibreur de charge doivent avoir une configuration réseau. Par défaut, la console sélectionne l'Amazon VPC par défaut ainsi que tous ses sous-réseaux et son groupe de sécurité par défaut. + La stratégie de placement des tâches par défaut répartit les tâches de manière uniforme entre les zones de disponibilité. Nous vous recommandons d’utiliser le rééquilibrage des zones de disponibilité pour garantir la haute disponibilité de votre service. Pour de plus amples informations, veuillez consulter [Équilibrage d’un service Amazon ECS entre les zones de disponibilité](service-rebalancing.md). + Lorsque vous utilisez **Launch Type** (Type de lancement) pour le déploiement de votre service, le service démarre par défaut dans les sous-réseaux de votre VPC de cluster. + Pour la **stratégie des fournisseurs de capacités**, la console sélectionne une option de calcul par défaut. Voici l'ordre utilisé par la console pour sélectionner une valeur par défaut : + Si votre cluster a une stratégie de fournisseur de capacité définie par défaut, elle est sélectionnée. + Si votre cluster n’a pas de stratégie de fournisseur de capacité par défaut définie, mais que les fournisseurs de capacité Fargate ont été ajoutés au cluster, une stratégie de fournisseur de capacité personnalisée qui utilise le fournisseur de capacité `FARGATE` est sélectionnée. + Si votre cluster ne dispose pas d’une stratégie de fournisseur de capacité par défaut définie, mais qu’un ou plusieurs fournisseurs de capacité de groupe Auto Scaling ont été ajoutés au cluster, l’option **Utiliser une stratégie personnalisée (avancée)** est sélectionnée et vous devez définir manuellement la stratégie. + Si votre cluster n'a pas de stratégie de fournisseur de capacité par défaut définie et qu'aucun fournisseur de capacité n'est ajouté au cluster, le type de lancement Fargate est sélectionné. + Les options par défaut de détection des échecs de déploiement consistent à utiliser l’option **Disjoncteur de déploiement Amazon ECS** avec l’option **Restauration en cas d’échec**. Pour de plus amples informations, veuillez consulter [Détection des pannes par le disjoncteur de déploiement Amazon ECS](deployment-circuit-breaker.md). + Décidez si vous souhaitez qu’Amazon ECS augmente ou diminue automatiquement le nombre souhaité de tâches dans votre service. Pour plus d'informations, consultez [Mise à l’échelle automatique de votre service Amazon ECS](service-auto-scaling.md). + Si vous avez besoin d'une application pour vous connecter à d'autres applications qui s'exécutent dans Amazon ECS, déterminez l'option adaptée à votre architecture. Pour de plus amples informations, veuillez consulter [Interconnexion des services Amazon ECS](interconnecting-services.md). + Lorsque vous créez un service qui utilise le disjoncteur Amazon ECS, Amazon ECS crée un déploiement et une révision de service. Ces ressources vous permettent de consulter des informations détaillées sur l’historique des services. Pour de plus amples informations, veuillez consulter [Affichage de l’historique d’un service à l’aide des déploiements de service Amazon ECS](service-deployment.md). Pour plus d'informations sur la création d'un service à l'aide du AWS CLI, reportez-vous [https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)à la section *AWS Command Line Interface Référence*. Pour plus d'informations sur la création d'un service à l'aide de AWS CloudFormation, consultez [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html)le *guide de AWS CloudFormation l'utilisateur*. ## Création d’un service avec les options par défaut Vous pouvez utiliser la console pour créer et déployer rapidement un service. Le service a la configuration suivante : + Déploie dans le VPC et les sous-réseaux associés à votre cluster + Déploie une tâche + Utilise le déploiement continu + Utilise la stratégie de fournisseur de capacité avec votre fournisseur de capacité par défaut + Utilise le disjoncteur de déploiement pour détecter les défaillances et définit l'option permettant d'annuler automatiquement le déploiement en cas de problème Pour déployer un service à l'aide des paramètres par défaut, procédez comme suit. **Pour créer un service (console Amazon ECS)** 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans la page de navigation, choisissez **Clusters**. 1. Sur la page **Clusters**, choisissez le cluster dans lequel créer le service. 1. Sous l'onglet **Services** choisissez **Create** (Créer). La page **Créer un service** s’affiche. 1. Sous **Détails du service**, procédez comme suit : 1. Pour **Définition de tâche**, saisissez la famille et la révision de définition de tâche à utiliser. 1. Pour **Service name** (Nom du service), saisissez un nom pour votre service. 1. Pour utiliser ECS Exec afin de déboguer le service, sous **Configuration de la résolution des problèmes**, sélectionnez **Activer ECS Exec**. 1. Sous **Configuration du déploiement**, procédez comme suit : 1. Pour **Desired tasks** (Tâches souhaitées), saisissez le nombre de tâches à lancer et à conserver dans le service. 1. (Facultatif) Pour vous aider à identifier votre service et vos tâches, développez **Tags** (balises), puis configurez vos balises. Pour qu'Amazon ECS étiquette automatiquement toutes les tâches nouvellement lancées avec le nom du cluster et les balises de définition des tâches, sélectionnez **Turn on Amazon ECS managed tags** (Activer les balises gérées par Amazon ECS), puis sélectionnez **Task definitions** (Définitions de tâches). Pour qu'Amazon ECS étiquette automatiquement toutes les tâches nouvellement lancées avec le nom du cluster et les balises d'un service, sélectionnez **Turn on Amazon ECS managed tags** (Activer les balises gérées par Amazon ECS), puis sélectionnez **Service**. Ajoutez ou supprimez une balise. + [Ajouter une balise] Choisissez **Add tag** (Ajouter une balise), puis procédez comme suit : + Pour **Clé**, saisissez le nom de la clé. + Pour **Valeur**, saisissez la valeur de clé. + [Supprimer une balise] En regard de la balise, choisissez **Supprimer la balise**. ## Créer un service à l'aide de paramètres définis Pour créer un service à l’aide de paramètres définis, procédez comme suit. **Pour créer un service (console Amazon ECS)** 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Déterminez la ressource à partir de laquelle vous lancez le service. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/create-service-console-v2.html) La page **Créer un service** s’affiche. 1. Sous Détails du service, procédez comme suit : 1. Pour **Définition de tâche**, saisissez la définition de tâche à utiliser. Ensuite, pour **Révision**, choisissez la révision à utiliser. 1. Pour **Service name** (Nom du service), saisissez un nom pour votre service. 1. Pour **Cluster existant**, choisissez le cluster. Choisissez **Créer un cluster** pour exécuter la tâche sur un nouveau cluster 1. Choisissez comment vos tâches sont distribuées dans votre infrastructure de cluster. Sous **Configuration de calcul**, choisissez votre option. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. Pour utiliser ECS Exec afin de déboguer le service, sous **Configuration de la résolution des problèmes**, sélectionnez **Activer ECS Exec**. 1. Sous **Configuration du déploiement**, procédez comme suit : 1. Pour **Service type** (Type de service), choisissez la stratégie de planification du service. + Pour que le planificateur déploie exactement une tâche sur chaque instance de conteneur active qui répond à toutes les contraintes de placement des tâches spécifiées dans votre cluster, choisissez **Daemon** (Démon). + Pour que. le planificateur place et gère le nombre de tâches souhaité dans votre cluster, choisissez **Replica**. 1. Si vous choisissez **Replica** pour **Desired tasks** (Tâches souhaitées), saisissez le nombre de tâches à lancer et à conserver dans le service. 1. Si vous avez choisi **Replica**, pour qu’Amazon ECS surveille la répartition des tâches entre les zones de disponibilité et les redistribue en cas de déséquilibre, sous **Rééquilibrage des services entre zones de disponibilité**, sélectionnez **Rééquilibrage des services entre zones de disponibilité**. 1. Pour **Période de grâce pour la surveillance de l’état**, saisissez la durée (en secondes) pendant laquelle le planificateur de service ignore les surveillances de l’état de Elastic Load Balancing, VPC Lattice et des conteneurs qui ne sont pas saines après le démarrage initial d’une tâche. Si vous ne spécifiez aucune valeur pour la période de grâce de surveillance de l’état, la valeur par défaut 0 est utilisée. 1. Déterminez le type de déploiement de votre service. Développez **Options de déploiement**, puis spécifiez les paramètres suivants. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. Pour configurer la manière dont Amazon ECS détecte et gère les échecs de déploiement, développez **Deployment failure detection** (Détection des échecs de déploiement), puis choisissez vos options. 1. Pour arrêter un déploiement lorsque les tâches ne peuvent pas démarrer, sélectionnez **Use the Amazon ECS deployment circuit breaker** (Utiliser le disjoncteur de déploiement Amazon ECS). Pour que le logiciel restaure automatiquement le dernier état de déploiement terminé lorsque le disjoncteur de déploiement définit le déploiement comme ayant échoué, sélectionnez **Restauration en cas d’échec**. 1. Pour arrêter un déploiement en fonction des métriques de l'application, sélectionnez **Utiliser une ou plusieurs CloudWatch alarmes**. Ensuite, à partir du **nom de l'CloudWatch alarme**, choisissez les alarmes. Pour créer une nouvelle alarme, rendez-vous sur la CloudWatch console. Pour que le logiciel annule automatiquement le déploiement au dernier état de déploiement terminé lorsqu'une CloudWatch alarme indique que le déploiement a échoué, sélectionnez Annulation en **cas d'échec**. 1. Si votre définition de tâche utilise le mode réseau `awsvpc`, vous pouvez spécifier une configuration réseau personnalisée ; développez **Mise en réseau**, puis procédez comme suit : 1. Pour **VPC**, sélectionnez le VPC à utiliser. 1. Pour **Subnets** (Sous-réseaux), sélectionnez un ou plusieurs sous-réseaux du VPC que le planificateur de tâches prend en compte lors du placement de vos tâches. 1. Pour **Security group (Groupe de sécurité)**, vous pouvez sélectionner un groupe de sécurité existant ou en créer un nouveau. Pour utiliser un groupe de sécurité existant, sélectionnez-le et passez à l'étape suivante. Pour créer un nouveau groupe de sécurité, sélectionnez **Create a new security group** (Créer un nouveau groupe de sécurité). Vous devez spécifier un nom de groupe de sécurité et une description, puis ajouter une ou plusieurs règles entrantes pour le groupe de sécurité. 1. Pour **Public IP (Adresse IP publique)**, indiquez si vous voulez attribuer automatiquement une adresse IP publique à l'interface réseau Elastic (ENI) de la tâche. AWS Fargate les tâches peuvent se voir attribuer une adresse IP publique lorsqu'elles sont exécutées dans un sous-réseau public afin qu'elles disposent d'une route vers Internet. Il n’est pas possible d’attribuer une adresse IP publique aux tâches EC2 à l’aide de ce champ. Pour plus d’informations, consultez les sections [Options de mise en réseau des tâches Amazon ECS pour Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html) et [Allocation d’une interface réseau pour une tâche Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking-awsvpc.html). 1. (Facultatif) Pour interconnecter votre service à l’aide de Service Connect, développez **Service Connect**, puis spécifiez les éléments suivants : 1. Sélectionnez **Activer Service Connect**. 1. Sous **Service Connect configuration** (Configuration de Service Connect), spécifiez le mode client. + Si votre service exécute une application client réseau qui doit uniquement se connecter à d’autres services de l’espace de noms, sélectionnez **Côté client uniquement**. + Si votre service exécute une application réseau ou un service Web et doit fournir des points de terminaison pour ce service, et se connecte à d'autres services dans l'espace de noms, choisissez **Client and server** (Client et serveur). 1. Pour utiliser un espace de noms qui n'est pas l'espace de noms de cluster par défaut, dans **Namespace** (Espace de noms), choisissez l'espace de noms du service. Il peut s'agir d'un espace de noms créé séparément dans le même espace Région AWS dans votre région Compte AWS ou d'un espace de noms dans la même région qui est partagé avec votre compte en utilisant AWS Resource Access Manager ()AWS RAM. *Pour plus d'informations sur les AWS Cloud Map espaces de noms partagés, consultez la section [Partage d'espaces de AWS Cloud Map noms entre comptes](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) dans le Guide du AWS Cloud Map développeur.* 1. (Facultatif) Spécifiez une configuration de journal. Sélectionnez **Utiliser la collecte de journaux**. L'option par défaut envoie les journaux du conteneur à CloudWatch Logs. Les autres options du pilote de journal sont configurées à l'aide de AWS FireLens. Pour de plus amples informations, veuillez consulter [Envoyer les journaux Amazon ECS à un AWS service ou AWS Partner](using_firelens.md). Voici une description plus détaillée de chaque destination de journal de conteneur. + **Amazon CloudWatch** — Configurez la tâche pour envoyer les journaux des conteneurs à CloudWatch Logs. Les options du pilote de journal par défaut sont fournies, ce qui permet de créer un groupe de CloudWatch journaux en votre nom. Pour spécifier un autre nom de groupe de journaux, modifiez les valeurs des options de pilote. + **Amazon Data Firehose** : configurez la tâche pour envoyer des journaux de conteneur à Firehose. Les options par défaut du pilote de journalisation sont fournies. Elles envoient les journaux vers un flux de livraison Firehose. Pour spécifier un autre nom de flux de diffusion, modifiez les valeurs des options de pilote. + **Amazon Kinesis Data Streams** : configurez la tâche pour envoyer des journaux de conteneur à Kinesis Data Streams. Les options par défaut du pilote de journalisation sont fournies. Elles permettent d’envoyer les journaux vers un flux Kinesis Data Streams. Pour spécifier un autre nom de flux, modifiez les valeurs des options de pilote. + **Amazon OpenSearch Service** — Configurez la tâche pour envoyer les journaux des conteneurs vers un domaine OpenSearch de service. Les options de pilote de journal doivent être fournies. + **Simple Storage Service (Amazon S3)** : configurez la tâche pour envoyer des journaux de conteneur à un compartiment Simple Storage Service (Amazon S3). Les options de pilote de journal par défaut sont fournies, mais vous devez spécifier un nom de compartiment Simple Storage Service (Amazon S3) valide. 1. (Facultatif) Pour activer les journaux d'accès, procédez comme suit : 1. Développez la **configuration du journal d'accès**. Pour **Format**, choisissez **JSON** ou`TEXT`. 1. Pour inclure les paramètres de requête dans les journaux d'accès, sélectionnez **Inclure les paramètres de requête**. 1. (Facultatif) Pour interconnecter votre service à l’aide de la découverte de service, développez **Découverte de service**, puis spécifiez les éléments suivants : 1. Sélectionnez **Utiliser la découverte de service**. 1. Pour utiliser un nouvel espace de noms, sous **Configurer l’espace de noms**, choisissez **Créer un espace de noms**, puis fournissez un nom et une description de l’espace de noms. Pour utiliser un espace de noms existant, choisissez **Sélectionner un espace de noms existant**, puis choisissez l’espace de noms que vous souhaitez utiliser. 1. Fournissez des informations sur le service de découverte de service, telles que le nom et la description du service. 1. Pour qu’Amazon ECS effectue des surveillances de l’état périodiques au niveau du conteneur, sélectionnez **Activer la propagation de l’état des tâches Amazon ECS**. 1. Pour **DNS record type (Type de registre DNS)**, sélectionnez le type de registre DNS à créer pour votre service. La découverte de service Amazon ECS prend uniquement en charge les registres **A** et **SRV**, en fonction du mode réseau spécifié par votre définition de tâche. Pour de plus amples informations sur ces types de registres, veuillez consulter [Supported DNS Record Types (Types de registres DNS pris en charge)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html) dans le *Guide du développeur Amazon Route 53*. + Si la définition de tâche spécifiée par votre tâche de service utilise le mode réseau `bridge` ou `host`, seuls les enregistrements de type **SRV** sont pris en charge. Choisissez une combinaison de nom et de port de conteneur à associer au registre. + Si la définition de tâche spécifiée par votre tâche de service utilise le mode réseau `awsvpc`, sélectionnez le type d'enregistrement **A** ou **SRV**. Si vous avez choisi **A**, passez à l’étape suivante. Si vous choisissez **SRV**, spécifiez le port sur lequel le service est accessible ou une combinaison de nom et de port de conteneur à associer à l'enregistrement. Pour **Durée de vie**, saisissez la durée en secondes pendant laquelle un jeu d'enregistrements est conservé en cache par les résolveurs DNS et les navigateurs Web. 1. (Facultatif) Pour interconnecter votre service à l’aide de VPC Lattice, développez **VPC Lattice**, puis procédez comme suit : 1. Sélectionnez **Activer le VPC Lattice** 1. Pour **Rôle d’infrastructure**, choisissez le rôle d’infrastructure. Si vous n’avez pas créé de rôle, choisissez **Créer un rôle d’infrastructure**. 1. Sous **Groupes cibles**, sélectionnez le ou les groupes cibles. Vous devez choisir au moins un groupe cible et pouvez en avoir jusqu’à cinq. Sélectionnez **Ajouter un groupe cible** pour ajouter d’autres groupes cibles. Choisissez le **Nom du port**, le **Protocole** et le **Port** pour chaque groupe cible que vous avez choisi. Pour supprimer un groupe cible, sélectionnez **Supprimer**. **Note** Si vous souhaitez ajouter un groupe cible existant, vous devez utiliser l’ AWS CLI. *Pour obtenir des instructions sur la façon d'ajouter des groupes cibles à l'aide de AWS CLI, voir [register-targets](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/register-targets.html) dans la AWS Command Line Interface référence.* Bien qu’un service VPC Lattice puisse avoir plusieurs groupes cibles, chaque groupe cible ne peut être ajouté qu’à un seul service. 1. Pour terminer la configuration de VPC Lattice, incluez vos nouveaux groupes cibles dans l’action par défaut de l’écouteur ou dans les règles d’un service VPC Lattice existant dans la console VPC Lattice. Pour plus d’informations, consultez la section [Règles d’écoute pour votre service VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/listener-rules.html). 1. (Facultatif) Pour configurer un équilibreur de charge pour votre service, développez **Load balancing** (Répartition de charge). Choisissez l'équilibreur de charge. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. (Facultatif) Pour configurer l’autoscaling du service, développez **Autoscaling du service**, puis spécifiez les paramètres suivants. Pour utiliser l’autoscaling prédictif, qui examine les données de charge passées à partir des flux de trafic, configurez-le après avoir créé le service. Pour de plus amples informations, veuillez consulter [Utilisez des modèles historiques pour faire évoluer les services Amazon ECS grâce à une mise à l'échelle prédictive](predictive-auto-scaling.md). 1. Pour utiliser la mise à l'échelle automatique du service, sélectionnez **Service Auto Scaling** (mise à l'échelle automatique du service). 1. Pour **Nombre minimum de tâches**, saisissez la limite inférieure du nombre de tâches à utiliser pour l’autoscaling du service. Le nombre souhaité ne sera pas inférieur à ce nombre. 1. Pour **Nombre maximal de tâches**, saisissez la limite supérieure du nombre de tâches à utiliser par l’autoscaling du service. Le nombre souhaité ne sera pas supérieur à ce nombre. 1. Choisissez le type de stratégie. Sous **Type de stratégie de mise à l’échelle**, choisissez l’une des options suivantes. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. (Facultatif) Pour utiliser une stratégie de placement des tâches autre que la stratégie par défaut, développez **Task Placement** (Placement des tâches), puis choisissez parmi les options suivantes. Pour de plus amples informations, veuillez consulter [Comment Amazon ECS place les tâches sur des instances de conteneur](task-placement.md). + **Répartition équilibrée par AZ** : permet de répartir les tâches entre les zones de disponibilité et les instances de conteneur de la zone de disponibilité. + **AZ Balanced BinPack** — Répartissez les tâches entre les zones de disponibilité et entre les instances de conteneur disposant du moins de mémoire disponible. + **BinPack**— Répartissez les tâches en fonction de la quantité minimale de processeur ou de mémoire disponible. + **Une tâche par hôte** : permet de placer au maximum une tâche du service sur chaque instance de conteneur. + **Personnalisé** : permet de définir votre propre stratégie de placement des tâches. Si vous avez choisi **Custom** (Personnaliser), définissez l'algorithme de placement des tâches et les règles à prendre en compte lors du placement des tâches. + Sous **Strategy** (Stratégie), pour **Type** et **Field** (Champ), choisissez l'algorithme et l'entité à utiliser pour l'algorithme. Vous pouvez saisir jusqu'à 5 stratégies maximum. + Sous **Contrainte**, pour **Type** et **Expression**, choisissez la règle et l'attribut pour la contrainte. Par exemple, pour définir la contrainte permettant de placer des tâches sur des instances T2, pour **Expression**, saisissez **attribute:ecs.instance-type =\$1 t2.\$1**. Vous pouvez saisir jusqu'à 10 contraintes maximum. 1. Si votre tâche utilise un volume de données compatible avec la configuration lors du déploiement, vous pouvez configurer le volume en développant **Volume**. Le nom et le type de volume sont configurés lorsque vous créez une révision de définition de tâche et ne peuvent pas être modifiés lors de la création d’un service. Pour mettre à jour le nom et le type du volume, vous devez créer une révision de définition de tâche et créer un service à l’aide de la nouvelle révision. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. Pour utiliser ECS Exec afin de déboguer le service, sous **Configuration de la résolution des problèmes**, sélectionnez **Activer ECS Exec**. 1. (Facultatif) Pour vous aider à identifier votre service et vos tâches, développez **Tags** (balises), puis configurez vos balises. Pour qu'Amazon ECS balise automatiquement toutes les tâches nouvellement lancées avec le nom du cluster et les balises de définition des tâches, sélectionnez **Activer les balises gérées Amazon ECS**, puis pour **Propager des balises à partir de**, choisissez **Définitions de tâches**. Pour qu'Amazon ECS balise automatiquement toutes les tâches nouvellement lancées avec le nom du cluster et les balises d'un service, sélectionnez **Activer les balises gérées Amazon ECS**, puis pour **Propager des balises à partir de**, choisissez **Service**. Ajoutez ou supprimez une balise. + [Ajouter une balise] Choisissez **Add tag** (Ajouter une balise), puis procédez comme suit : + Pour **Clé**, saisissez le nom de la clé. + Pour **Valeur**, saisissez la valeur de clé. + [Supprimer une balise] En regard de la balise, choisissez **Supprimer la balise**. 1. Choisissez **Créer**. ## Étapes suivantes Voici les actions supplémentaires à effectuer après avoir créé un service. + Configurez l’autoscaling prédictif, qui examine les données de charge passées issues des flux de trafic. Pour de plus amples informations, veuillez consulter [Utilisez des modèles historiques pour faire évoluer les services Amazon ECS grâce à une mise à l'échelle prédictive](predictive-auto-scaling.md). + Suivez votre déploiement et consultez l’historique des services pour les services qui utilisent le disjoncteur Amazon ECS. Pour de plus amples informations, veuillez consulter [Affichage de l’historique d’un service à l’aide des déploiements de service Amazon ECS](service-deployment.md). # blue/green Déploiements Amazon ECS Un blue/green déploiement est une méthodologie de publication qui réduit les temps d'arrêt et les risques en exécutant deux environnements de production identiques appelés bleu et vert. Avec les blue/green déploiements Amazon ECS, vous pouvez valider les nouvelles révisions des services avant de diriger le trafic de production vers celles-ci. Cette approche fournit un moyen plus sûr de déployer les modifications avec la possibilité de revenir rapidement en arrière si nécessaire. ## Avantages Les avantages de l'utilisation des blue/green déploiements sont les suivants : + Réduction des risques en testant le trafic de production avant de passer à la production. Vous pouvez valider le nouveau déploiement avec le trafic de test avant de diriger le trafic de production vers celui-ci. + Déploiements sans durée d’indisponibilité. L’environnement de production reste disponible tout au long du processus de déploiement, garantissant ainsi la disponibilité continue du service. + Restauration facile si des problèmes sont détectés. Si des problèmes surviennent avec le déploiement vert, vous pouvez rapidement revenir au déploiement bleu sans interruption de service prolongée. + Environnement de test contrôlé. L’environnement vert fournit un espace isolé pour tester les nouvelles fonctionnalités avec des modèles de trafic réels avant le déploiement complet. + Processus de déploiement prévisible. L’approche structurée avec des étapes du cycle de vie définies rend les déploiements plus cohérents et fiables. + Validation automatisée via des hooks de cycle de vie. Vous pouvez implémenter des tests automatisés à différentes étapes du déploiement afin de vérifier le fonctionnement. ## Terminologie Les conditions de blue/green déploiement d'Amazon ECS sont les suivantes : + 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. + Déploiement bleu : révision actuelle du service de production que vous souhaitez remplacer. + Déploiement vert : nouvelle version du service que vous souhaitez déployer. + É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 de cycle de vie : fonction Lambda qui vérifie le déploiement à une étape spécifique du cycle de vie. + É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é. + 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. + Transfert de trafic : processus utilisé par Amazon ECS pour transférer le trafic du déploiement bleu au déploiement vert. Pour les blue/green déploiements Amazon ECS, tout le trafic passe du service bleu au service vert en une seule fois. ## Considérations Tenez compte des éléments suivants lors du choix d’un type de déploiement : + Utilisation des ressources : Blue/green les déploiements 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 : Blue/green les déploiements fournissent des informations plus détaillées sur l'état du déploiement, ce qui vous permet de surveiller chaque étape du processus de déploiement. + Annulation : Blue/green les déploiements 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 délai de cuisson. + Crochets du cycle de vie du Network Load Balancer : si vous utilisez un Network Load Balancer blue/green pour les déploiements, 10 minutes supplémentaires sont nécessaires pour les étapes du cycle de vie TEST\$1TRAFFIC\$1SHIFT et PRODUCTION\$1TRAFFIC\$1SHIFT. Cela est dû au fait qu'Amazon ECS veille à ce que le trafic puisse être transféré en toute sécurité. # 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). 1. **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. 1. **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. 1. **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. 1. **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. 1. **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. 1. **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 : ![\[Schéma complet illustrant le processus de blue/green déploiement dans Amazon ECS avec les interactions détaillées entre les composants, les phases de transfert du trafic et les points de contrôle de surveillance\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/blue-green.png) Le processus de déploiement amélioré inclut les étapes détaillées suivantes : 1. **É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. 1. **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. 1. **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. 1. **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. 1. **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. 1. **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. 1. **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. 1. **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. 1. **É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\$1SERVICE | 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\$1SCALE\$1UP | 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\$1UP | 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\$1SCALE\$1UP | 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\$1TRAFFIC\$1SHIFT | 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\$1TEST\$1TRAFFIC\$1SHIFT | Le transfert du trafic de test est terminé. La révision de service verte gère 100 % du trafic de test. | Oui | | PRODUCTION\$1TRAFFIC\$1SHIFT | 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\$1PRODUCTION\$1TRAFFIC\$1SHIFT | Le transfert du trafic de production est terminé. | Oui | | BAKE\$1TIME | Durée pendant laquelle les révisions de service bleues et vertes sont exécutées simultanément. | Non | | CLEAN\$1UP | 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\$1COURS dans les 15 minutes. Vous pouvez utiliser le `callBackDelaySeconds` pour retarder l’appel à Lambda. Pour plus d'informations, consultez [la fonction app.py](https://github.com/aws-samples/sample-amazon-ecs-blue-green-deployment-patterns/blob/main/ecs-bluegreen-lifecycle-hooks/src/approvalFunction/app.py#L20-L25) dans le sample-amazon-ecs-blue champ - green-deployment-patterns on GitHub. # Ressources requises pour les blue/green déploiements Amazon ECS Pour utiliser un blue/green déploiement avec transfert de trafic géré, votre service doit utiliser l'une des fonctionnalités suivantes : + Elastic Load Balancing + Service Connect Les services qui n'utilisent pas Service Discovery, Service Connect, VPC Lattice ou Elastic Load Balancing peuvent également utiliser des blue/green déploiements, mais ne bénéficient d'aucun des avantages de la gestion du transfert de trafic. La liste suivante fournit un aperçu général de ce que vous devez configurer pour les blue/green déploiements Amazon ECS : + Votre service utilise Application Load Balancer, Network Load Balancer ou Service Connect Configurez les ressources appropriées. + Application Load Balancer : pour plus d’informations, consultez la section [Ressources d'Application Load Balancer pour les déploiements bleu/vert, linéaires et Canary](alb-resources-for-blue-green.md). + Network Load Balancer : pour plus d’informations, consultez la section [Ressources du Network Load Balancer pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](nlb-resources-for-blue-green.md). + Service Connect : pour plus d’informations, consultez la section [Ressources Service Connect pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](service-connect-blue-green.md). + Définissez le contrôleur de déploiement de service sur `ECS`. + Configurez la stratégie de déploiement sur `blue/green` dans votre définition de service. + Configurez éventuellement des paramètres supplémentaires tels que : + La durée de l’intégration pour le nouveau déploiement + CloudWatch alarmes pour annulation automatique + Les hooks de cycle de vie du déploiement pour les tests (il s’agit de fonctions Lambda qui s’exécutent à des étapes de déploiement spécifiées) ## Bonnes pratiques Suivez ces bonnes pratiques pour réussir vos blue/green déploiements Amazon ECS : + Configurez les surveillances de l’état appropriées qui reflètent précisément l’état de votre application. + Définissez une durée de l’intégration permettant de tester suffisamment le déploiement vert. + Implémentez des CloudWatch alarmes pour détecter automatiquement les problèmes et déclencher des annulations. + Utilisez les hooks de cycle de vie pour effectuer des tests automatisés à chaque étape du déploiement. + Assurez-vous que votre application peut gérer les révisions de service bleues et vertes exécutées simultanément. + Prévoyez une capacité de cluster suffisante pour gérer les deux révisions de service lors du déploiement. + Testez vos procédures de restauration avant de les mettre en œuvre en production. # Ressources d'Application Load Balancer pour les déploiements bleu/vert, linéaires et Canary Pour utiliser les équilibreurs de charge d'application avec les blue/green déploiements Amazon ECS, vous devez configurer des ressources spécifiques qui permettent le routage du trafic entre les révisions de service bleues et vertes. ## Groupes cibles Pour les blue/green déploiements avec Elastic Load Balancing, vous devez créer deux groupes cibles : + Un groupe cible principal pour la révision de service bleue (trafic de production actuel) + Un autre groupe cible pour la révision de service verte (nouvelle version) Les deux groupes cibles doivent être configurés avec les paramètres suivants : + Type de cible : `IP` (pour Fargate ou EC2 en mode réseau `awsvpc`) + Protocole : `HTTP` (ou le protocole utilisé par votre application) + Port : port sur lequel votre application écoute (généralement `80` pour le protocole HTTP) + VPC : le même VPC que vos tâches Amazon ECS + Paramètres de surveillance de l’état : configurés pour vérifier correctement l’état de votre application Au cours d'un blue/green déploiement, Amazon ECS enregistre automatiquement les tâches auprès du groupe cible approprié en fonction de l'étape de déploiement. **Example Création de groupes cibles pour un Application Load Balancer** Les commandes CLI suivantes créent deux groupes cibles à utiliser avec un Application Load Balancer dans le cadre d'un blue/green déploiement : ``` aws elbv2 create-target-group \ --name blue-target-group \ --protocol HTTP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-path / \ --health-check-protocol HTTP \ --health-check-interval-seconds 30 \ --health-check-timeout-seconds 5 \ --healthy-threshold-count 2 \ --unhealthy-threshold-count 2 aws elbv2 create-target-group \ --name green-target-group \ --protocol HTTP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-path / \ --health-check-protocol HTTP \ --health-check-interval-seconds 30 \ --health-check-timeout-seconds 5 \ --healthy-threshold-count 2 \ --unhealthy-threshold-count 2 ``` ## Application Load Balancer Vous devez créer un Application Load Balancer avec la configuration suivante : + Schéma : connecté à Internet ou interne, selon vos besoins + Type d'adresse IP : IPv4 + VPC : le même VPC que vos tâches Amazon ECS + Sous-réseaux : au moins deux sous-réseaux dans des zones de disponibilité différentes + Groupes de sécurité : groupe de sécurité qui autorise le trafic sur les ports de l’écouteur Le groupe de sécurité attaché à l’Application Load Balancer doit disposer d’une règle sortante qui autorise le trafic vers le groupe de sécurité associé à vos tâches Amazon ECS. **Example Création d'un équilibreur de charge Application Load Balancer** Les commandes CLI suivantes créent un Application Load Balancer pour une utilisation dans un déploiement bleu/vert : ``` aws elbv2 create-load-balancer \ --name my-application-load-balancer \ --type application \ --security-groups sg-abcd1234 \ --subnets subnet-12345678 subnet-87654321 ``` ## Écouteurs et règles Pour les blue/green déploiements, vous devez configurer des écouteurs sur votre Application Load Balancer : + Écouteur de production : gère le trafic de production (généralement sur le port 80 ou 443) + Transfère initialement le trafic au groupe cible principal (révision de service bleue) + Après le déploiement, transfert le trafic vers le groupe cible alternatif (révision de service verte) + Écouteur de test (facultatif) : gère le trafic de test pour valider la révision de service verte avant de passer au trafic de production. + Peut être configuré sur un autre port (par exemple, 8080 ou 8443) + Transfère le trafic vers le groupe cible alternatif (révision de service verte) pendant les tests Au cours d'un blue/green déploiement, Amazon ECS met automatiquement à jour les règles du récepteur pour acheminer le trafic vers le groupe cible approprié en fonction de la phase de déploiement. **Example Création d’un écouteur de production** La commande CLI suivante crée un écouteur de production sur le port 80 qui transmet le trafic au groupe cible principal (bleu) : ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \ --protocol HTTP \ --port 80 \ --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/abcdef123456 ``` **Example Création d’un écouteur de test** La commande CLI suivante crée un écouteur de test sur le port 8080 qui transfère le trafic vers le groupe cible alternatif (vert) : ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \ --protocol HTTP \ --port 8080 \ --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` **Example Création d’une règle d’écoute pour le routage basé sur le chemin** La commande CLI suivante crée une règle qui transmet le trafic d’un chemin spécifique au groupe cible vert à des fins de test : ``` aws elbv2 create-rule \ --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \ --priority 10 \ --conditions Field=path-pattern,Values='/test/*' \ --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` **Example Création d’une règle d’écoute pour le routage basé sur l’en-tête** La commande CLI suivante crée une règle qui transfère le trafic avec un en-tête spécifique vers le groupe cible vert à des fins de test : ``` aws elbv2 create-rule \ --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \ --priority 20 \ --conditions Field=http-header,HttpHeaderConfig='{Name=X-Environment,Values=[test]}' \ --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` ## Configuration du service Vous devez disposer des autorisations nécessaires pour autoriser Amazon ECS à gérer les ressources de l’équilibreur de charge dans vos clusters en votre nom. Pour de plus amples informations, veuillez consulter [Rôle IAM d’infrastructure Amazon ECS pour les équilibreurs de charge](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Lorsque vous créez ou mettez à jour un service Amazon ECS pour blue/green des déploiements avec Elastic Load Balancing, vous devez spécifier la configuration suivante. Remplacez le *user-input* par vos valeurs. Les principaux composants de cette configuration sont les suivants : + `targetGroupArn` : l’ARN du groupe cible principal (révision de service bleue). + `alternateTargetGroupArn` : l’ARN du groupe cible alternatif (révision de service verte). + `productionListenerRule` : l’ARN de la règle d’écoute du trafic de production. + `roleArn` : l’ARN du rôle qui permet à Amazon ECS de gérer les ressources Elastic Load Balancing. + `strategy` : l’défini sur `BLUE_GREEN` pour activer les déploiements bleu/vert. + `bakeTimeInMinutes` : la durée pendant laquelle les révisions de service bleues et vertes se déroulent simultanément après le transfert du trafic de production. + `TestListenerRule` : l’ARN de la règle d’écoute du trafic de test. Ce paramètre est facultatif. ``` { "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/primary-target-group/abcdef123456", "containerName": "container-name", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/alternate-target-group/ghijkl789012", "productionListenerRule": "arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/load-balancer-name/abcdef123456/listener/ghijkl789012/rule/mnopqr345678", "roleArn": "arn:aws:iam::123456789012:role/ecs-elb-role" } } ], "deploymentConfiguration": { "strategy": "BLUE_GREEN", "maximumPercent": 200, "minimumHealthyPercent": 100, "bakeTimeInMinutes": 5 } } ``` ## Flux de trafic pendant le déploiement Lors d'un blue/green déploiement avec Elastic Load Balancing, le trafic circule dans le système comme suit : 1. *État initial* : tout le trafic de production est acheminé vers le groupe cible principal (révision de service bleue). 1. *Déploiement de la révision de service verte* : Amazon ECS déploie les nouvelles tâches et les enregistre auprès du groupe cible alternatif. 1. *Trafic de test* : si un écouteur de test est configuré, le trafic de test est acheminé vers le groupe cible alternatif pour valider la révision de service verte. 1. *Transfert du trafic de production* : Amazon ECS met à jour la règle d’écoute de production pour acheminer le trafic vers le groupe cible alternatif (révision de service verte). 1. *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. 1. *Achèvement* : après un déploiement réussi, la révision de service bleue est résiliée. Si des problèmes sont détectés lors du déploiement, Amazon ECS peut automatiquement procéder à une restauration en redirigeant le trafic vers le groupe cible principal (révision de service bleue). # Ressources du Network Load Balancer pour les déploiements Amazon ECS bleu/vert, linéaire et Canary Pour utiliser un Network Load Balancer avec les blue/green déploiements Amazon ECS, vous devez configurer des ressources spécifiques qui permettent le routage du trafic entre les révisions de service bleues et vertes. Cette section explique les composants requis et leur configuration. Lorsque votre configuration inclut un Network Load Balancer, Amazon ECS ajoute un délai de 10 minutes aux étapes du cycle de vie suivantes : + TEST\$1TRAFFIC\$1SHIFT + PRODUCTION\$1TRAFFIC\$1SHIFT Ce délai est à l’origine des problèmes de synchronisation du Network Load Balancer, qui peuvent entraîner une inadéquation entre les pondérations de trafic configurées et le routage réel du trafic dans le plan de données. ## Groupes cibles Pour les blue/green déploiements avec un Network Load Balancer, vous devez créer deux groupes cibles : + Un groupe cible principal pour la révision de service bleue (trafic de production actuel) + Un autre groupe cible pour la révision de service verte (nouvelle révision de service) Les deux groupes cibles doivent être configurés avec les paramètres suivants : + Type de cible : `ip` (pour Fargate ou EC2 en mode réseau `awsvpc`) + Protocole : `TCP` (ou le protocole utilisé par votre application) + Port : port sur lequel votre application écoute (généralement `80` pour le protocole HTTP) + VPC : le même VPC que vos tâches Amazon ECS + Paramètres de surveillance de l’état : configurés pour vérifier correctement l’état de votre application Pour les surveillances de l’état du protocole TCP, le Network Load Balancer établit une connexion TCP avec la cible. Si la connexion est réussie, la cible est considérée comme saine. Pour les bilans de HTTP/HTTPS santé, le Network Load Balancer envoie une HTTP/HTTPS demande à la cible et vérifie la réponse. Au cours d'un blue/green déploiement, Amazon ECS enregistre automatiquement les tâches auprès du groupe cible approprié en fonction de l'étape de déploiement. **Example Création de groupes cibles pour un Network Load Balancer** Les commandes AWS CLI suivantes créent deux groupes cibles à utiliser avec un Network Load Balancer dans le cadre d'un blue/green déploiement : ``` aws elbv2 create-target-group \ --name blue-target-group \ --protocol TCP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-protocol TCP aws elbv2 create-target-group \ --name green-target-group \ --protocol TCP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-protocol TCP ``` ## Network Load Balancer Vous devez créer un Network Load Balancer avec la configuration suivante : + Schéma : connecté à Internet ou interne, selon vos besoins + Type d'adresse IP : IPv4 + VPC : le même VPC que vos tâches Amazon ECS + Sous-réseaux : au moins deux sous-réseaux dans des zones de disponibilité différentes Contrairement aux Application Load Balancer, les Network Load Balancer fonctionnent au niveau de la couche transport (couche 4) et n’utilisent pas de groupes de sécurité. Vous devez plutôt vous assurer que les groupes de sécurité associés à vos tâches Amazon ECS autorisent le trafic provenant du Network Load Balancer sur les ports de l’écouteur. **Example Créer un Network Load Balancer** La commande AWS CLI suivante crée un Network Load Balancer à utiliser dans le cadre d'un blue/green déploiement : ``` aws elbv2 create-load-balancer \ --name my-network-load-balancer \ --type network \ --subnets subnet-12345678 subnet-87654321 ``` ## Considérations relatives à l'utilisation du NLB lors de déploiements blue/green Lorsque vous utilisez un Network Load Balancer pour les blue/green déploiements, tenez compte des points suivants : + **Fonctionnement de couche 4** : les Network Load Balancer fonctionnent au niveau de la couche transport (couche 4) et n’inspectent pas le contenu de la couche application (couche 7). Cela signifie que vous ne pouvez pas utiliser les en-têtes ou les chemins HTTP pour les décisions de routage. + **Surveillance de l’état** : les surveillances de l’état du Network Load Balancer sont limitées aux protocoles TCP, HTTP ou HTTPS. Pour les surveillances de l’état du protocole TCP, le Network Load Balancer vérifie uniquement que la connexion peut être établie. + **Préservation de la connexion** : les Network Load Balancer préservent l’adresse IP source du client, ce qui peut être utile à des fins de sécurité et de journalisation. + **Adresses IP statiques** : les Network Load Balancer fournissent des adresses IP statiques pour chaque sous-réseau, ce qui peut être utile pour les listes blanches ou lorsque les clients doivent se connecter à une adresse IP fixe. + **Trafic de test** : étant donné que les Network Load Balancer ne prennent pas en charge le routage basé sur le contenu, le trafic de test doit être envoyé vers un port différent du trafic de production. ## Écouteurs et règles Pour les blue/green déploiements avec un Network Load Balancer, vous devez configurer des écouteurs : + Écouteur de production : gère le trafic de production (généralement sur le port 80 ou 443) + Transfère initialement le trafic au groupe cible principal (révision de service bleue) + Après le déploiement, transfert le trafic vers le groupe cible alternatif (révision de service verte) + Écouteur de test (facultatif) : gère le trafic de test pour valider la révision de service verte avant de passer au trafic de production. + Peut être configuré sur un autre port (par exemple, 8080 ou 8443) + Transfère le trafic vers le groupe cible alternatif (révision de service verte) pendant les tests Contrairement aux Application Load Balancer, les Network Load Balancer ne prennent pas en charge les règles de routage basées sur le contenu. Au lieu de cela, le trafic est acheminé en fonction du port et du protocole de l’écouteur. Les commandes AWS CLI suivantes créent des écouteurs de production et de test pour un Network Load Balancer : Remplacez le *user-input* par vos valeurs. ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \ --protocol TCP \ --port 80 \ --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456 aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \ --protocol TCP \ --port 8080 \ --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456 ``` ## Configuration du service Vous devez disposer des autorisations nécessaires pour autoriser Amazon ECS à gérer les ressources de l’équilibreur de charge dans vos clusters en votre nom. Pour de plus amples informations, veuillez consulter [Rôle IAM d’infrastructure Amazon ECS pour les équilibreurs de charge](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Lorsque vous créez ou mettez à jour un service Amazon ECS pour blue/green des déploiements avec un Network Load Balancer, vous devez spécifier la configuration suivante : Remplacez le *user-input* par vos valeurs. Les principaux composants de cette configuration sont les suivants : + `targetGroupArn` : l’ARN du groupe cible principal (révision de service bleue) + `alternateTargetGroupArn` : l’ARN du groupe cible alternatif (révision de service verte) + `productionListenerRule` : l’ARN de l’écouteur du trafic de production. + `testListenerRule` : (facultatif) l’ARN de l’écouteur du trafic de test + `roleArn` : l’ARN du rôle qui permet à Amazon ECS de gérer les ressources Network Load Balancer + `strategy`: défini sur pour activer `BLUE_GREEN` les blue/green déploiements + `bakeTimeInMinutes`: durée pendant laquelle les révisions du service bleu et vert sont exécutées simultanément après le déplacement du trafic de production ``` { "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456", "containerName": "container-name", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456", "productionListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/1234567890123456", "testListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/2345678901234567", "roleArn": "arn:aws:iam::123456789012:role/ecs-nlb-role" } } ], "deploymentConfiguration": { "strategy": "BLUE_GREEN", "maximumPercent": 200, "minimumHealthyPercent": 100, "bakeTimeInMinutes": 5 } } ``` ## Flux de trafic pendant le déploiement Lors d'un blue/green déploiement avec un Network Load Balancer, le trafic circule dans le système comme suit : 1. *État initial* : tout le trafic de production est acheminé vers le groupe cible principal (révision de service bleue). 1. *Déploiement de la révision de service verte* : Amazon ECS déploie les nouvelles tâches et les enregistre auprès du groupe cible alternatif. 1. *Trafic de test* : si un écouteur de test est configuré, le trafic de test est acheminé vers le groupe cible alternatif pour valider la révision de service verte. 1. *Transfert du trafic de production* : Amazon ECS met à jour l’écouteur de production pour acheminer le trafic vers le groupe cible alternatif (révision de service verte). 1. *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. 1. *Achèvement* : après un déploiement réussi, la révision de service bleue est résiliée. Si des problèmes sont détectés lors du déploiement, Amazon ECS peut automatiquement procéder à une restauration en redirigeant le trafic vers le groupe cible principal (révision de service bleue). # Ressources Service Connect pour les déploiements Amazon ECS bleu/vert, linéaire et Canary Lorsque vous utilisez Service Connect avec blue/green des déploiements, vous devez configurer des composants spécifiques pour permettre le routage correct du trafic entre les révisions de service bleues et vertes. Cette section explique les composants requis et leur configuration. ## Présentation de l’architecture Service Connect développe à la fois des fonctionnalités de découverte de services et de maillage de services par le biais d’un proxy parallèle géré qui est automatiquement injecté dans vos tâches Amazon ECS. Ces proxys gèrent les décisions de routage, les nouvelles tentatives et la collecte des métriques, tout en AWS Cloud Map fournissant le backend du registre des services. Lorsque vous déployez un service avec Service Connect activé, le service s'enregistre et les AWS Cloud Map services clients le découvrent via l'espace de noms. Dans une implémentation standard de Service Connect, les services client se connectent à des noms de service logiques, et le proxy sidecar gère le routage vers les instances de service réelles. Avec blue/green les déploiements, ce modèle est étendu pour inclure le routage du trafic de test via la `testTrafficRules` configuration. Au cours d'un blue/green déploiement, les composants clés suivants fonctionnent ensemble : + **Proxy Service Connect** : tout le trafic entre les services passe par le proxy Service Connect, qui prend les décisions de routage en fonction de la configuration. + **AWS Cloud Map Enregistrement** : les déploiements bleu et vert sont enregistrés auprès de AWS Cloud Map, mais le déploiement vert est initialement enregistré en tant que point de terminaison « test ». + **Routage du trafic de test** : les `testTrafficRules` dans la configuration de Service Connect déterminent comment identifier et acheminer le trafic de test vers le déploiement vert. Cela se fait par le biais d’un **routage basé sur les en-têtes**, dans le cadre duquel des en-têtes HTTP spécifiques contenus dans les requêtes dirigent le trafic vers la révision de test. Par défaut, Service Connect reconnaît l’en-tête `x-amzn-ecs-blue-green-test` des protocoles HTTP lorsqu’aucune règle personnalisée n’est spécifiée. + **Configuration du client** : tous les clients de l’espace de noms reçoivent automatiquement les itinéraires de production et de test, mais seules les requêtes correspondant aux règles de test seront transférées vers le déploiement vert. La puissance de cette approche réside dans le fait qu’elle permet de gérer la complexité de la découverte de service pendant les transitions. À mesure que le trafic passe du déploiement bleu au déploiement vert, tous les mécanismes de connectivité et de découverte sont automatiquement mis à jour. Il n’est pas nécessaire de mettre à jour les enregistrements DNS, de reconfigurer les équilibreurs de charge ou de déployer les modifications apportées à la découverte de service séparément, car le maillage de services gère tout cela. ## Routage et tests du trafic Service Connect fournit des fonctionnalités avancées de routage du trafic pour les blue/green déploiements, notamment le routage basé sur les en-têtes et la configuration d'alias client pour les scénarios de test. ### Test des règles d’en-tête du trafic Au cours blue/green des déploiements, vous pouvez configurer les règles d'en-tête du trafic de test pour acheminer des demandes spécifiques vers la (nouvelle) révision du service vert à des fins de test. Cela vous permet de valider la nouvelle version avec un trafic contrôlé avant de terminer le déploiement. Service Connect utilise le **routage basé sur les en-têtes** pour identifier le trafic de test. Par défaut, Service Connect reconnaît l’en-tête `x-amzn-ecs-blue-green-test` des protocoles HTTP lorsqu’aucune règle personnalisée n’est spécifiée. Lorsque cet en-tête est présent dans une requête, le proxy Service Connect achemine automatiquement la requête vers le déploiement vert à des fins de test. Les règles d’en-tête du trafic de test vous permettent : + d’acheminer les demandes avec des en-têtes spécifiques vers la révision de service verte ; + de tester de nouvelles fonctionnalités avec un sous-ensemble de trafic ; + de valider le comportement du service avant le basculement complet du trafic ; + de mettre en œuvre des stratégies de test canary. + de réaliser des tests d’intégration dans un environnement similaire à celui de la production. Le mécanisme de routage basé sur les en-têtes fonctionne en toute transparence avec votre architecture applicative existante. Les services clients n'ont pas besoin de connaître le processus de blue/green déploiement : ils incluent simplement les en-têtes appropriés lors de l'envoi de demandes de test, et le proxy Service Connect gère automatiquement la logique de routage. Pour plus d'informations sur la configuration des règles d'en-tête du trafic de test, consultez [ServiceConnectTestTrafficHeaderRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderRules.html)le manuel *Amazon Elastic Container Service API Reference*. ### Règles de correspondance des en-têtes Les règles de correspondance des en-têtes définissent les critères de routage du trafic de test lors blue/green des déploiements. Vous pouvez configurer plusieurs conditions de correspondance pour contrôler avec précision les demandes qui sont acheminées vers la révision de service verte. La correspondance des en-têtes prend en charge : + la correspondance exacte des valeurs d’en-tête ; + la vérification de la présence d’en-têtes ; + la correspondance basée sur des modèles ; + plusieurs combinaisons d’en-têtes. Les exemples de cas d’utilisation incluent le routage des demandes avec des chaînes d’agent utilisateur spécifiques, des versions d’API ou des indicateurs de fonctionnalité vers le service vert à des fins de test. Pour plus d'informations sur la configuration de la correspondance des en-têtes, consultez [ServiceConnectTestTrafficHeaderMatchRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderMatchRules.html)le manuel *Amazon Elastic Container Service API Reference*. ### Alias clients pour les déploiements blue/green Les alias de client fournissent des points de terminaison DNS stables pour les services lors blue/green des déploiements. Ils permettent un routage fluide du trafic entre les révisions de service bleues et vertes sans obliger les applications clientes à modifier leurs points de terminaison de connexion. Lors d'un blue/green déploiement, les alias du client : + maintiennent des noms DNS cohérents pour les connexions client ; + permettent la commutation automatique du trafic entre les révisions de service ; + prennent en charge les stratégies de migration progressive du trafic ; + fournissent des fonctionnalités de restauration en redirigeant le trafic vers la version bleue. Vous pouvez configurer plusieurs alias de client pour différents ports ou protocoles, ce qui permet à des architectures de service complexes de maintenir la connectivité pendant les déploiements. Pour plus d'informations sur la configuration des alias clients, consultez le [ServiceConnectClientAlias](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectClientAlias.html)manuel *Amazon Elastic Container Service API Reference*. ### Pratiques exemplaires en matière de test de routage du trafic : Lors de la mise en œuvre du routage du trafic pour blue/green les déploiements avec Service Connect, tenez compte des meilleures pratiques suivantes : + **Commencer par des tests basés sur les en-têtes** : utilisez les règles d’en-tête du trafic de test pour valider le service vert avec un trafic maîtrisé avant de transférer tout le trafic. + **Configurer les surveillances de l’état** : assurez-vous que les services bleu et vert disposent de surveillances de l’état appropriés configurés pour empêcher le routage du trafic vers des instances défectueuses. + **Surveiller les métriques de service** : suivez les indicateurs de performance clés des deux révisions de service pendant le déploiement afin d’identifier les problèmes à un stade précoce. + **Planifier une stratégie de restauration** : configurez les alias clients et les règles de routage pour permettre une restauration rapide du service bleu si des problèmes sont détectés. + **Tester la logique de correspondance des en-têtes** : validez vos règles de correspondance des en-têtes dans un environnement hors production avant de les appliquer à des déploiements de production. ## Flux de travail de blue/green déploiement de Service Connect Comprendre comment Service Connect gère le processus de blue/green déploiement vous permet de mettre en œuvre et de résoudre efficacement vos déploiements. Le flux de travail suivant montre comment les différents composants interagissent au cours de chaque phase du déploiement. ### Phases de déploiement Le blue/green déploiement de Service Connect passe par plusieurs phases distinctes : 1. **État initial** : le service bleu gère 100 % du trafic de production. Tous les services clients de l’espace de noms se connectent au service bleu via le nom de service logique configuré dans Service Connect. 1. **Enregistrement du service écologique** : Lorsque le déploiement écologique commence, il est enregistré en AWS Cloud Map tant que point de terminaison « test ». Le proxy Service Connect des services clients reçoit automatiquement les configurations d’itinéraires de production et de test. 1. **Routage du trafic de test** : les requêtes contenant les en-têtes de trafic de test (tels que `x-amzn-ecs-blue-green-test`) sont automatiquement acheminées vers le service vert par le proxy Service Connect. Le trafic de production continue d’affluer vers le service bleu. 1. **Préparation au transfert du trafic** : une fois les tests réussis, le processus de déploiement prépare le transfert du trafic de production. Les services bleus et verts restent enregistrés et sains. 1. **Transfert du trafic de production** : la configuration de Service Connect est mise à jour pour acheminer le trafic de production vers le service vert. Cela se produit automatiquement sans nécessiter de mises à jour du service client ou de modifications du DNS. 1. **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. 1. Annulation de l'**enregistrement du service bleu** : une fois le transfert de trafic et la validation réussis, le service bleu est désenregistré AWS Cloud Map et le déploiement est terminé. ### Comportement du proxy Service Connect Le proxy Service Connect joue un rôle crucial dans la gestion du trafic lors des blue/green déploiements. Comprendre son comportement vous aide à concevoir des stratégies de test et de déploiement efficaces. Principaux comportements des proxys lors des blue/green déploiements : + **Découverte automatique des itinéraires** : le proxy découvre automatiquement les itinéraires de production et de test AWS Cloud Map sans qu'il soit nécessaire de redémarrer l'application ou de modifier la configuration. + **Routage basé sur les en-têtes** : le proxy examine les en-têtes des requêtes entrantes et achemine le trafic vers la version de service appropriée en fonction des règles de trafic de test configurées. + **Intégration de la surveillance de l’état** : le proxy n’achemine le trafic que vers des instances de service saines, excluant automatiquement les tâches défectueuses du groupe de routage. + **Nouvelle tentative et disjoncteur** : le proxy intègre une logique de réessai et des fonctionnalités de disjoncteur, améliorant ainsi la résilience lors des déploiements. + **Collecte de métriques** : le proxy collecte des métriques détaillées pour les services bleus et verts, permettant une surveillance complète lors des déploiements. ### Mise à jour de la découverte de service L'un des principaux avantages de l'utilisation de Service Connect pour les blue/green déploiements est la gestion automatique des mises à jour de découverte de services. Les blue/green déploiements traditionnels nécessitent souvent des mises à jour DNS complexes ou une reconfiguration de l'équilibreur de charge, mais Service Connect gère ces modifications de manière transparente. Au cours d’un déploiement, Service Connect gère les éléments suivants : + **Mises à jour de l’espace de noms** : l’espace de noms Service Connect inclut automatiquement les points de terminaison de service bleus et verts, avec des règles de routage appropriées. + **Configuration du client** : tous les services clients de l’espace de noms reçoivent automatiquement des informations de routage mises à jour sans nécessiter un redémarrage ni un redéploiement. + **Transition progressive** : les mises à jour de la découverte de service se font progressivement et en toute sécurité, sans perturber les requêtes en cours. + **Support de restauration** : si une restauration est nécessaire, Service Connect peut rapidement rétablir les configurations de découverte de service afin de rediriger le trafic vers le service bleu. # Création d'un blue/green déploiement Amazon ECS En utilisant les blue/green déploiements Amazon ECS, vous pouvez apporter et tester des modifications de service avant de les implémenter dans un environnement de production. ## Conditions préalables Effectuez les opérations suivantes avant de démarrer un blue/green déploiement. 1. Configurez les autorisations appropriées. + Pour plus d’informations sur les autorisations Elastic Load Balancing, consultez la section [Rôle IAM d’infrastructure Amazon ECS pour les équilibreurs de charge](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). + Pour plus d’informations sur les autorisations Lambda, consultez la section[Autorisations requises pour les fonctions Lambda dans les déploiements Amazon ECS blue/green](blue-green-permissions.md). 1. Les blue/green déploiements Amazon ECS nécessitent que votre service utilise l'une des fonctionnalités suivantes : Configurez les ressources appropriées. + Application Load Balancer : pour plus d’informations, consultez la section [Ressources d'Application Load Balancer pour les déploiements bleu/vert, linéaires et Canary](alb-resources-for-blue-green.md). + Network Load Balancer : pour plus d’informations, consultez la section [Ressources du Network Load Balancer pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](nlb-resources-for-blue-green.md). + Service Connect : pour plus d’informations, consultez la section [Ressources Service Connect pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](service-connect-blue-green.md). 1. Décidez si vous souhaitez exécuter des fonctions Lambda pendant les étapes du cycle de vie. + PRE\$1SCALE\$1UP + POST\$1SCALE\$1UP + TEST\$1TRAFFIC\$1SHIFT + POST\$1TEST\$1TRAFFIC\$1SHIFT + PRODUCTION\$1TRAFFIC\$1SHIFT + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT Pour plus d’informations sur l’utilisation de Lambda, consultez la section [Créer une fonction Lambda avec la console](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function) dans le *Guide du développeur AWS Lambda *. ## Procédure Vous pouvez utiliser la console ou le AWS CLI pour créer un blue/green service Amazon ECS. ------ #### [ Console ] 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Déterminez la ressource à partir de laquelle vous lancez le service. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/deploy-blue-green-service.html) La page **Créer un service** s’affiche. 1. Sous **Détails du service**, procédez comme suit : 1. Pour **Famille de définition de tâche**, choisissez la définition de tâche à utiliser. Ensuite, pour **Révision de définition de tâche**, saisissez la révision à utiliser. 1. Pour **Service name** (Nom du service), saisissez un nom pour votre service. 1. Pour exécuter le service dans un cluster existant, pour **Cluster existant**, sélectionnez le cluster. Pour exécuter le service dans un nouveau cluster, choisissez **Créer un cluster** 1. Choisissez comment vos tâches sont distribuées dans votre infrastructure de cluster. Sous **Configuration de calcul**, choisissez votre option. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/deploy-blue-green-service.html) 1. Sous **Configuration du déploiement**, procédez comme suit : 1. Pour **Type de service**, choisissez **Replica**. 1. Pour **Desired tasks** (Tâches souhaitées), saisissez le nombre de tâches à lancer et à conserver dans le service. 1. Pour qu’Amazon ECS surveille la répartition des tâches entre les zones de disponibilité et les redistribue en cas de déséquilibre, sous **Rééquilibrage des services entre zones de disponibilité**, sélectionnez **Rééquilibrage des services entre zones de disponibilité**. 1. Pour **Période de grâce pour la surveillance de l’état**, saisissez la durée (en secondes) pendant laquelle le planificateur de service ignore les surveillances de l’état de Elastic Load Balancing, VPC Lattice et des conteneurs qui ne sont pas saines après le démarrage initial d’une tâche. Si vous ne spécifiez aucune valeur pour la période de grâce de surveillance de l’état, la valeur par défaut 0 est utilisée. 1. 1. Pour **Durée de l’intégration**, saisissez le nombre de minutes pendant lesquelles les révisions de service bleues et vertes seront exécutées simultanément avant que la révision bleue ne soit résiliée. Cela laisse le temps de procéder à des vérifications et à des tests. 1. (Facultatif) Exécutez des fonctions Lambda à des étapes spécifiques du déploiement. Sous **Hooks de cycle de vie du déploiement**, sélectionnez les étapes dans lesquelles exécuter les hooks de cycle de vie. Pour ajouter un hook de cycle de vie 1. Choisissez **Ajouter**. 1. Pour **Fonction Lambda**, saisissez le nom ou l’ARN de la fonction. 1. Pour **Rôle**, sélectionnez le rôle IAM qui dispose de l’autorisation requise pour invoquer la fonction Lambda. 1. Pour **Étapes du cycle de vie**, sélectionnez les étapes dans lesquelles la fonction Lambda doit être exécutée. 1. Pour configurer la manière dont Amazon ECS détecte et gère les échecs de déploiement, développez **Deployment failure detection** (Détection des échecs de déploiement), puis choisissez vos options. 1. Pour arrêter un déploiement lorsque les tâches ne peuvent pas démarrer, sélectionnez **Use the Amazon ECS deployment circuit breaker** (Utiliser le disjoncteur de déploiement Amazon ECS). Pour que le logiciel restaure automatiquement le dernier état de déploiement terminé lorsque le disjoncteur de déploiement définit le déploiement comme ayant échoué, sélectionnez **Restauration en cas d’échec**. 1. Pour arrêter un déploiement en fonction des métriques de l'application, sélectionnez **Utiliser une ou plusieurs CloudWatch alarmes**. Ensuite, à partir du **nom de l'CloudWatch alarme**, choisissez les alarmes. Pour créer une nouvelle alarme, rendez-vous sur la CloudWatch console. Pour que le logiciel annule automatiquement le déploiement au dernier état de déploiement terminé lorsqu'une CloudWatch alarme indique que le déploiement a échoué, sélectionnez Annulation en **cas d'échec**. 1. (Facultatif) Pour interconnecter votre service à l’aide de Service Connect, développez **Service Connect**, puis spécifiez les éléments suivants : 1. Sélectionnez **Activer Service Connect**. 1. Sous **Service Connect configuration** (Configuration de Service Connect), spécifiez le mode client. + Si votre service exécute une application client réseau qui doit uniquement se connecter à d’autres services de l’espace de noms, sélectionnez **Côté client uniquement**. + Si votre service exécute une application réseau ou un service Web et doit fournir des points de terminaison pour ce service, et se connecte à d'autres services dans l'espace de noms, choisissez **Client and server** (Client et serveur). 1. Pour utiliser un espace de noms qui n'est pas l'espace de noms de cluster par défaut, dans **Namespace** (Espace de noms), choisissez l'espace de noms du service. Il peut s'agir d'un espace de noms créé séparément dans le même espace Région AWS dans votre région Compte AWS ou d'un espace de noms dans la même région qui est partagé avec votre compte en utilisant AWS Resource Access Manager ()AWS RAM. *Pour plus d'informations sur les AWS Cloud Map espaces de noms partagés, consultez la section [Partage d'espaces de AWS Cloud Map noms entre comptes](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) dans le Guide du AWS Cloud Map développeur.* 1. (Facultatif) Configurez les règles d'en-tête du trafic de test pour les blue/green déploiements. Sous **Routage du trafic de test**, spécifiez les éléments suivants : 1. Sélectionnez **Activer les règles d’en-tête du trafic de test** pour acheminer des requêtes spécifiques vers la révision de service verte pendant les tests. 1. Pour **Règles de correspondance des en-têtes**, configurez les critères de routage du trafic de test suivants : + **Nom de l’en-tête** : saisissez le nom de l’en-tête HTTP correspondant (par exemple, `X-Test-Version` ou `User-Agent`). + **Type de correspondance** : choisissez les critères de correspondance : + **Correspondance exacte** : acheminer les requêtes dont la valeur d’en-tête correspond exactement à la valeur spécifiée + **En-tête présent** : acheminer les requêtes contenant l’en-tête spécifié, quelle que soit sa valeur + **Correspondance de modèle** : acheminer les requêtes dont la valeur d’en-tête correspond à un modèle spécifié + **Valeur d’en-tête** (si vous utilisez une correspondance exacte ou une correspondance de modèle) : saisissez la valeur ou le modèle à comparer. Vous pouvez ajouter plusieurs règles de correspondance d’en-têtes pour créer une logique de routage complexe. Les requêtes correspondant à l’une des règles configurées seront acheminées vers la version verte du service à des fins de test. 1. Choisissez **Ajouter une règle d’en-tête** pour configurer des conditions de correspondance d’en-tête supplémentaires. **Note** Les règles d’en-tête du trafic de test vous permettent de valider les nouvelles fonctionnalités avec un trafic contrôlé avant de procéder au déploiement complet. Cela vous permet de tester la révision de service verte avec des requêtes spécifiques (telles que celles provenant d’outils de test internes ou d’utilisateurs bêta) tout en maintenant un flux de trafic normal vers la révision de service bleue. 1. (Facultatif) Spécifiez une configuration de journal. Sélectionnez **Utiliser la collecte de journaux**. L'option par défaut envoie les journaux du conteneur à CloudWatch Logs. Les autres options du pilote de journal sont configurées à l'aide de AWS FireLens. Pour de plus amples informations, veuillez consulter [Envoyer les journaux Amazon ECS à un AWS service ou AWS Partner](using_firelens.md). Voici une description plus détaillée de chaque destination de journal de conteneur. + **Amazon CloudWatch** — Configurez la tâche pour envoyer les journaux des conteneurs à CloudWatch Logs. Les options du pilote de journal par défaut sont fournies, ce qui permet de créer un groupe de CloudWatch journaux en votre nom. Pour spécifier un autre nom de groupe de journaux, modifiez les valeurs des options de pilote. + **Amazon Data Firehose** : configurez la tâche pour envoyer des journaux de conteneur à Firehose. Les options par défaut du pilote de journalisation sont fournies. Elles envoient les journaux vers un flux de livraison Firehose. Pour spécifier un autre nom de flux de diffusion, modifiez les valeurs des options de pilote. + **Amazon Kinesis Data Streams** : configurez la tâche pour envoyer des journaux de conteneur à Kinesis Data Streams. Les options par défaut du pilote de journalisation sont fournies. Elles permettent d’envoyer les journaux vers un flux Kinesis Data Streams. Pour spécifier un autre nom de flux, modifiez les valeurs des options de pilote. + **Amazon OpenSearch Service** — Configurez la tâche pour envoyer les journaux des conteneurs vers un domaine OpenSearch de service. Les options de pilote de journal doivent être fournies. + **Simple Storage Service (Amazon S3)** : configurez la tâche pour envoyer des journaux de conteneur à un compartiment Simple Storage Service (Amazon S3). Les options de pilote de journal par défaut sont fournies, mais vous devez spécifier un nom de compartiment Simple Storage Service (Amazon S3) valide. 1. (Facultatif) Configurez l’**équilibrage de charge** pour un déploiement bleu/vert. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/deploy-blue-green-service.html) 1. (Facultatif) Pour vous aider à identifier votre service et vos tâches, développez **Tags** (balises), puis configurez vos balises. Pour qu'Amazon ECS balise automatiquement toutes les tâches nouvellement lancées avec le nom du cluster et les balises de définition des tâches, sélectionnez **Activer les balises gérées Amazon ECS**, puis pour **Propager des balises à partir de**, choisissez **Définitions de tâches**. Pour qu'Amazon ECS balise automatiquement toutes les tâches nouvellement lancées avec le nom du cluster et les balises d'un service, sélectionnez **Activer les balises gérées Amazon ECS**, puis pour **Propager des balises à partir de**, choisissez **Service**. Ajoutez ou supprimez une balise. + [Ajouter une balise] Choisissez **Add tag** (Ajouter une balise), puis procédez comme suit : + Pour **Clé**, saisissez le nom de la clé. + Pour **Valeur**, saisissez la valeur de clé. + [Supprimer une balise] En regard de la balise, choisissez **Supprimer la balise**. 1. Choisissez **Créer**. ------ #### [ AWS CLI ] 1. Créez un fichier nommé `service-definition.json` avec le contenu suivant. Remplacez le *user-input* par vos valeurs. ``` { "serviceName": "myBlueGreenService", "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster", "taskDefinition": "sample-fargate:1", "desiredCount": 5, "launchType": "FARGATE", "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "subnet-09ce6e74c116a2299", "subnet-00bb3bd7a73526788", "subnet-0048a611aaec65477" ], "securityGroups": [ "sg-09d45005497daa123" ], "assignPublicIp": "ENABLED" } }, "deploymentController": { "type": "ECS" }, "deploymentConfiguration": { "strategy": "BLUE_GREEN", "maximumPercent": 200, "minimumHealthyPercent": 100, "bakeTimeInMinutes": 2, "alarms": { "alarmNames": [ "myAlarm" ], "rollback": true, "enable": true }, "lifecycleHooks": [ { "hookTargetArn": "arn:aws:lambda:us-west-2:7123456789012:function:checkExample", "roleArn": "arn:aws:iam::123456789012:role/ECSLifecycleHookInvoke", "lifecycleStages": [ "PRE_SCALE_UP" ] } ] }, "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197", "containerName": "fargate-app", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199", "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-blue-green-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911", "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS" } } ] } ``` 1. Exécutez `create-service`. Remplacez le *user-input* par vos valeurs. ``` aws ecs create-service --cli-input-json file://service-definition.json ``` Vous pouvez également utiliser l'exemple suivant qui crée un service de blue/green déploiement avec une configuration d'équilibreur de charge : ``` aws ecs create-service \ --cluster "arn:aws:ecs:us-west-2:123456789012:cluster/MyCluster" \ --service-name "blue-green-example-service" \ --task-definition "nginxServer:1" \ --launch-type "FARGATE" \ --network-configuration "awsvpcConfiguration={subnets=[subnet-12345,subnet-67890,subnet-abcdef,subnet-fedcba],securityGroups=[sg-12345],assignPublicIp=ENABLED}" \ --desired-count 3 \ --deployment-controller "type=ECS" \ --deployment-configuration "strategy=BLUE_GREEN,maximumPercent=200,minimumHealthyPercent=100,bakeTimeInMinutes=0" \ --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg1/abcdef1234567890,containerName=nginx,containerPort=80,advancedConfiguration={alternateTargetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg2/0987654321fedcba,productionListenerRule=arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/MyLB/1234567890abcdef/1234567890abcdef,roleArn=arn:aws:iam::123456789012:role/ELBManagementRole}" ``` ------ ## Étapes suivantes + Mettez à jour le service pour démarrer le déploiement. Pour de plus amples informations, veuillez consulter [Mettre à jour un service Amazon ECS](update-service-console-v2.md). + Surveillez le processus de déploiement pour vous assurer qu'il suit le blue/green modèle : + La révision de service verte est créée et augmentée horizontalement + Le trafic de test est acheminé vers la révision verte (si elle est configurée) + Le trafic de production est transféré vers la révision verte + Au terme de la durée de l’intégration, la révision bleue est résiliée # Résolution des problèmes liés aux blue/green déploiements Amazon ECS Ce qui suit fournit des solutions aux problèmes courants que vous pouvez rencontrer lors de l'utilisation de blue/green déploiements avec Amazon ECS. Blue/green des erreurs de déploiement peuvent survenir au cours des phases suivantes : + *Chemin synchrone* : erreurs qui apparaissent immédiatement en réponse aux appels d’API `CreateService` ou `UpdateService`. + *Chemin asynchrone* : erreurs qui apparaissent dans le champ `statusReason` de `DescribeServiceDeployments` et entraînent une restauration du déploiement **Astuce** Vous pouvez utiliser les assistants [Serveur Amazon ECS MCP](ecs-mcp-introduction.md) dotés d'intelligence artificielle pour surveiller les déploiements et résoudre les problèmes de déploiement à l'aide du langage naturel. ## Erreurs de configuration de l’équilibreur de charge La configuration de l'équilibreur de charge est un élément essentiel des blue/green déploiements dans Amazon ECS. Une configuration correcte des règles d’écoute, des groupes cibles et des types d’équilibreurs de charge est essentielle à la réussite des déploiements. Cette section couvre les problèmes courants de configuration des équilibreurs de charge qui peuvent entraîner l'échec blue/green des déploiements. Pour résoudre les problèmes d’équilibreur de charge, il est important de comprendre la relation entre les règles d’écoute et les groupes cibles. Dans le cadre d'un blue/green déploiement : + La règle d’écoute de production dirige le trafic vers la révision de service actuellement active (bleue) + La règle d’écoute de test peut être utilisée pour valider la nouvelle révision de service (verte) avant le transfert du trafic de production + Les groupes cibles sont utilisés pour enregistrer les instances de conteneur à partir de chaque révision de service + Au cours du déploiement, le trafic passe progressivement de la révision de service bleue à la révision de service verte en ajustant les pondérations des groupes cibles dans les règles d’écoute ### Erreurs de configuration des règles d’écoute Les problèmes suivants sont liés à une configuration incorrecte des règles d'écoute pour les blue/green déploiements. Utilisation d’un ARN d’écouteur Application Load Balancer au lieu d’un ARN de règle d’écoute *Message d’erreur* : `productionListenerRule has an invalid ARN format. Must be RuleArn for ALB or ListenerArn for NLB. Got: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456` *Solution* : lorsque vous utilisez un Application Load Balancer, vous devez spécifier un ARN de règle d’écoute pour `productionListenerRule` et `testListenerRule`, et non un ARN d’écouteur. Pour les Network Load Balancer, vous devez utiliser l’ARN de l’écouteur. Pour plus d’informations sur la manière de trouver l’ARN de l’écouteur, consultez la section [Écouteurs pour vos Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) dans le *Guide de l’utilisateur Application Load Balancer*. L’ARN d’une règle a le format `arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/...`. Utiliser la même règle pour les écouteurs de production et de test *Message d’erreur* : `The following rules cannot be used as both production and test listener rules: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789` *Solution* : vous devez utiliser des règles d’écoute différentes pour le trafic de production et de test. Créez une règle d’écoute distincte pour le trafic de test qui achemine le trafic vers votre groupe cible de test. Groupe cible non associé aux règles d’écoute *Message d’erreur* : `Service deployment rolled back because of invalid networking configuration: Target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myAlternateTG/abc123 is not associated with either productionListenerRule or testListenerRule.` *Solution* : le groupe cible principal et le groupe cible secondaire doivent être associés à la règle d’écoute de production ou à la règle d’écoute de test. Mettez à jour la configuration de votre équilibreur de charge pour vous assurer que les deux groupes cibles sont correctement associés à vos règles d’écoute. Règle d’écoute de test manquante avec un Application Load Balancer *Message d’erreur* : `For Application LoadBalancer, testListenerRule is required when productionListenerRule is not associated with both targetGroup and alternateTargetGroup` *Solution* : lorsque vous utilisez un Application Load Balancer, si aucun des deux groupes cibles n’est associé à la règle d’écoute de production, vous devez spécifier une règle d’écoute de test. Ajoutez une `testListenerRule` à votre configuration et assurez-vous que les deux groupes cibles sont associés à la règle de production ou à la règle d’écoute de test. Pour plus d’informations, consultez la section [Écouteurs pour vos Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) du *Guide de l’utilisateur Application Load Balancer*. ### Erreurs de configuration du groupe cible Les problèmes suivants sont liés à une configuration incorrecte du groupe cible pour les blue/green déploiements. Plusieurs groupes cibles recevant du trafic dans une règle d’écoute *Message d’erreur* : `Service deployment rolled back because of invalid networking configuration. productionListenerRule arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789 should have exactly one target group serving traffic but found 2 target groups which are serving traffic` *Solution* : Avant de commencer un blue/green déploiement, assurez-vous qu'un seul groupe cible reçoit du trafic (avec une pondération différente de zéro) dans votre règle d'écoute. Mettez à jour la configuration de vos règles d’écoute pour définir le poids à zéro pour tout groupe cible qui ne devrait pas recevoir de trafic. Groupes cibles en double dans les entrées de l’équilibreur de charge *Message d’erreur* : `Duplicate targetGroupArn found: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myecs-targetgroup/abc123` *Solution* : l’ARN de chaque groupe cible doit être unique pour toutes les entrées de l’équilibreur de charge figurant dans votre définition de service. Passez en revue votre configuration et assurez-vous d’utiliser des groupes cibles différents pour chaque entrée de l’équilibreur de charge. Groupe cible inattendu dans la règle d’écoute de production *Message d’erreur* : `Service deployment rolled back because of invalid networking configuration. Production listener rule is forwarding traffic to unexpected target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/random-nlb-tg/abc123. Expected traffic to be forwarded to either targetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-targetgroup/def456 or alternateTargetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-tg-alternate/ghi789` *Solution* : la règle d’écoute de production achemine le trafic vers un groupe cible qui n’est pas spécifié dans votre définition de service. Assurez-vous que la règle d’écoute est configurée pour n’acheminer le trafic que vers les groupes cibles spécifiés dans votre définition de service. Pour plus d’informations, consultez la section [Actions de transfert](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#forward-actions) dans le *Guide de l’utilisateur Application Load Balancer*. ### Erreurs de configuration du type d’équilibreur de charge Les problèmes suivants sont liés à une configuration incorrecte du type d'équilibreur de charge pour les blue/green déploiements. Combinaison des configurations Classic Load Balancer et Application Load Balancer ou Network Load Balancer *Message d’erreur* : `All loadBalancers must be strictly either ELBv1 (defining loadBalancerName) or ELBv2 (defining targetGroupArn)` Les Classic Load Balancer correspondent à la génération précédente d’équilibreurs de charge Elastic Load Balancing. Nous vous recommandons de passer à un équilibreur de charge de génération actuelle. Pour plus d’informations, consultez la section [Migration de votre Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/migrate-classic-load-balancer.html). *Solution* :. Utilisez soit uniquement des Classic Load Balancer, soit des Application Load Balancer et des Network Load Balancer. Pour les Application Load Balancer et Network Load Balancer, ne spécifiez que le champ `targetGroupArn`. Utilisation d’une configuration avancée avec un Classic Load Balancer *Message d’erreur* : `advancedConfiguration field is not allowed with ELBv1 loadBalancers` *Solution : La* configuration avancée pour les blue/green déploiements n'est prise en charge qu'avec les équilibreurs de charge d'application et les équilibreurs de charge réseau. Si vous utilisez un Classic Load Balancer (spécifié avec `loadBalancerName`), vous ne pouvez pas utiliser le champ `advancedConfiguration`. Passez à un Application Load Balancer ou supprimez le champ `advancedConfiguration`. Configuration avancée incohérente entre les équilibreurs de charge *Message d’erreur* : `Either all or none of the provided loadBalancers must have advancedConfiguration defined` *Solution* : si vous utilisez plusieurs équilibreurs de charge, vous devez définir `advancedConfiguration` soit pour tous, soit pour aucun. Mettez à jour votre configuration pour garantir la cohérence entre toutes les entrées de l’équilibreur de charge. Configuration avancée manquante lors blue/green du déploiement *Message d’erreur* : `advancedConfiguration field is required for all loadBalancers when using a non-ROLLING deployment strategy` *Solution* : Lorsque vous utilisez une stratégie de blue/green déploiement avec des équilibreurs de charge d'application, vous devez spécifier le `advancedConfiguration` champ pour toutes les entrées de l'équilibreur de charge. Ajoutez l’`advancedConfiguration` nécessaire à la configuration de votre équilibreur de charge. ## Problèmes d’autorisations Les problèmes suivants concernent des autorisations insuffisantes pour les blue/green déploiements. Stratégie d’approbation manquante concernant le rôle de l’infrastructure *Message d’erreur* : `Service deployment rolled back because of invalid networking configuration. ECS was unable to manage the ELB resources due to missing permissions on ECS Infrastructure Role 'arn:aws:iam::123456789012:role/Admin'.` *Solution* : le rôle IAM spécifié pour gérer les ressources de l’équilibreur de charge ne dispose pas de la bonne stratégie d’approbation. Mettez à jour la stratégie d’approbation du rôle afin de permettre au service d’assumer ce rôle. La stratégie d’approbation doit inclure : **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ecs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` Autorisations de lecture manquantes sur le rôle d’équilibreur de charge *Message d’erreur* : `service myService failed to describe target health on target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:DescribeTargetHealth because no identity-based policy allows the elasticloadbalancing:DescribeTargetHealth action)` *Solution* : le rôle IAM utilisé pour gérer les ressources de l’équilibreur de charge n’est pas autorisé à lire les informations relatives à l’état de la cible. Ajoutez la politique d’autorisation `elasticloadbalancing:DescribeTargetHealth` au rôle. Pour plus d’informations sur les autorisations Elastic Load Balancing, consultez la section [Rôle IAM d’infrastructure Amazon ECS pour les équilibreurs de charge](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Autorisations d’écriture manquantes pour le rôle d’équilibreur de charge *Message d’erreur* : `service myService failed to register targets in target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:RegisterTargets on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myTargetGroup/abc123 because no identity-based policy allows the elasticloadbalancing:RegisterTargets action)` *Solution* : le rôle IAM utilisé pour gérer les ressources de l’équilibreur de charge n’est pas autorisé à enregistrer des cibles. Ajoutez la politique d’autorisation `elasticloadbalancing:RegisterTargets` au rôle. Pour plus d’informations sur les autorisations Elastic Load Balancing, consultez la section [Rôle IAM d’infrastructure Amazon ECS pour les équilibreurs de charge](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Autorisation manquante pour modifier les règles d’écoute *Message d’erreur* : `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. User: arn:aws:sts::123456789012:assumed-role/myELBRole/ECSNetworkingWithELB is not authorized to perform: elasticloadbalancing:ModifyListener on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456 because no identity-based policy allows the elasticloadbalancing:ModifyListener action` *Solution* : le rôle IAM utilisé pour gérer les ressources de l’équilibreur de charge n’est pas autorisé à modifier les écouteurs. Ajoutez la politique d’autorisation `elasticloadbalancing:ModifyListener` au rôle. Pour plus d’informations sur les autorisations Elastic Load Balancing, consultez la section [Rôle IAM d’infrastructure Amazon ECS pour les équilibreurs de charge](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Pour les blue/green déploiements, nous vous recommandons d'associer la politique `AmazonECS-ServiceLinkedRolePolicy` gérée à votre rôle d'infrastructure, qui inclut toutes les autorisations nécessaires à la gestion des ressources de l'équilibreur de charge. ## Problèmes de hook de cycle de vie Les problèmes suivants concernent les crochets liés au cycle de vie dans les blue/green déploiements. Stratégie d’approbation incorrecte sur le rôle du hook Lambda *Message d’erreur* : `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to assume role arn:aws:iam::123456789012:role/Admin` *Solution* : le rôle IAM spécifié pour le hook de cycle de vie Lambda ne dispose pas de la bonne stratégie d’approbation. Mettez à jour la stratégie d’approbation du rôle afin de permettre au service d’assumer ce rôle. La stratégie d’approbation doit inclure : **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ecs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` Le hook Lambda renvoie le statut ÉCHEC *Message d’erreur* : `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. Lifecycle hook target arn:aws:lambda:us-west-2:123456789012:function:myHook returned FAILED status.` *Solution* : la fonction Lambda spécifiée en tant que hook de cycle de vie a renvoyé un statut ÉCHEC. Consultez les journaux des fonctions Lambda dans les CloudWatch journaux Amazon pour déterminer la raison de l'échec, et mettez à jour la fonction pour qu'elle gère correctement l'événement de déploiement. Autorisation manquante pour invoquer une fonction Lambda *Message d’erreur* : `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to invoke hook target arn:aws:lambda:us-west-2:123456789012:function:myHook due to User: arn:aws:sts::123456789012:assumed-role/myLambdaRole/ECS-Lambda-Execution is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-west-2:123456789012:function:myHook because no identity-based policy allows the lambda:InvokeFunction action` *Solution* : le rôle IAM utilisé pour le hook de cycle de vie Lambda n’est pas autorisé à appeler la fonction Lambda. Ajoutez l’autorisation `lambda:InvokeFunction` à la politique du rôle pour l’ARN de la fonction Lambda spécifique. Pour plus d’informations sur les autorisations Lambda, consultez la section [Autorisations requises pour les fonctions Lambda dans les déploiements Amazon ECS blue/green](blue-green-permissions.md). Délai d’expiration d’une fonction Lambda ou réponse non valide *Message d’erreur* : `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to parse the response from arn:aws:lambda:us-west-2:123456789012:function:myHook due to HookStatus must not be null` *Solution* : la fonction Lambda a expiré ou a renvoyé une réponse non valide. Assurez-vous que votre fonction Lambda renvoie une réponse valide avec un champ `hookStatus` défini sur `SUCCEEDED` ou `FAILED`. Vérifiez également que le délai d’expiration de la fonction Lambda est défini de manière appropriée pour votre logique de validation. Pour de plus amples informations, veuillez consulter [Hooks de cycle de vie pour les déploiements de service Amazon ECS](deployment-lifecycle-hooks.md). Exemple de réponse Lambda valide : ``` { "hookStatus": "SUCCEEDED", "reason": "Validation passed" } ``` # 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\$1TRAFFIC\$1SHIFT seront 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 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, ce qui vous permet 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). 1. Phase de préparation : création de l’environnement vert à côté de l’environnement bleu existant. 1. 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. 1. 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. 1. 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. 1. 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. 1. 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\$1TRAFFIC\$1SHIFT 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\$1TRAFFIC\$1SHIFT 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\$1SERVICE | 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\$1SCALE\$1UP | 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\$1UP | 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\$1SCALE\$1UP | 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\$1TRAFFIC\$1SHIFT | 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\$1TEST\$1TRAFFIC\$1SHIFT | Le transfert du trafic de test est terminé. La révision de service verte gère 100 % du trafic de test. | Oui | | PRODUCTION\$1TRAFFIC\$1SHIFT | 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\$1PRODUCTION\$1TRAFFIC\$1SHIFT | Le transfert du trafic de production est terminé. | Oui | | BAKE\$1TIME | Durée pendant laquelle les révisions de service bleues et vertes sont exécutées simultanément. | Non | | CLEAN\$1UP | 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 | # Ressources requises pour les déploiements linéaires d'Amazon ECS Pour utiliser un déploiement linéaire avec transfert de trafic géré, votre service doit utiliser l'une des fonctionnalités suivantes : + Elastic Load Balancing + Service Connect La liste suivante fournit une vue d'ensemble détaillée de ce que vous devez configurer pour les déploiements linéaires Amazon ECS : + Votre service utilise Application Load Balancer, Network Load Balancer ou Service Connect Configurez les ressources appropriées. + Application Load Balancer : pour plus d’informations, consultez la section [Ressources d'Application Load Balancer pour les déploiements bleu/vert, linéaires et Canary](alb-resources-for-blue-green.md). + Network Load Balancer : pour plus d’informations, consultez la section [Ressources du Network Load Balancer pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](nlb-resources-for-blue-green.md). + Service Connect : pour plus d’informations, consultez la section [Ressources Service Connect pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](service-connect-blue-green.md). + Définissez le contrôleur de déploiement de service sur `ECS`. + Configurez la stratégie de déploiement sur `linear` dans votre définition de service. + Configurez éventuellement des paramètres supplémentaires tels que : + La durée de l’intégration pour le nouveau déploiement + Le pourcentage de trafic à déplacer à chaque incrément. + Durée d'attente en minutes entre chaque incrément de changement de trafic. + CloudWatch alarmes pour annulation automatique + Hooks du cycle de vie du déploiement (il s'agit de fonctions Lambda qui s'exécutent à des étapes de déploiement spécifiées, telles que BEFORE\$1INSTALL, PRODUCTION\$1TRAFFIC\$1SHIFT ou POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT) ## Bonnes pratiques Suivez ces bonnes pratiques pour réussir les déploiements linéaires d'Amazon ECS : + **Assurez-vous que votre application peut gérer les deux révisions de service exécutées simultanément.** + **Prévoyez une capacité de cluster suffisante pour gérer les deux révisions de service lors du déploiement.** + **Testez vos procédures de rollback avant de les mettre en œuvre en production.** + Configurez les surveillances de l’état appropriées qui reflètent précisément l’état de votre application. + Définissez un temps de cuisson qui permet de tester suffisamment la nouvelle révision du service. + Implémentez des CloudWatch alarmes pour détecter automatiquement les problèmes et déclencher des annulations. + Choisissez des pourcentages d'étapes et des temps de cuisson qui équilibrent la vitesse de déploiement avec les besoins de validation. + Utilisez des pourcentages d'étapes plus faibles (5 à 10 %) pour les applications critiques afin de minimiser l'exposition aux risques. + Définissez des temps de cuisson plus longs pour les applications qui ont besoin de temps pour se réchauffer ou se stabiliser. + Implémentez des CloudWatch alarmes pour détecter automatiquement les problèmes et déclencher des annulations à chaque augmentation du trafic. + Surveillez de près les indicateurs des applications lors de chaque changement de trafic afin de détecter rapidement la dégradation des performances. + Assurez-vous que votre application peut gérer les deux révisions de service exécutées simultanément. + Testez vos procédures de rollback à différents pourcentages de trafic avant de les mettre en œuvre en production. # Création d'un déploiement linéaire Amazon ECS En utilisant les déploiements linéaires Amazon ECS, vous pouvez progressivement déplacer le trafic par incréments égaux sur des intervalles de temps spécifiés. Cela permet une validation contrôlée à chaque étape du processus de déploiement. ## Conditions préalables Effectuez les opérations suivantes avant de démarrer un déploiement linéaire. 1. Configurez les autorisations appropriées. + Pour plus d’informations sur les autorisations Elastic Load Balancing, consultez la section [Rôle IAM d’infrastructure Amazon ECS pour les équilibreurs de charge](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). + Pour plus d’informations sur les autorisations Lambda, consultez la section [Autorisations requises pour les fonctions Lambda dans les déploiements Amazon ECS blue/green](blue-green-permissions.md). 1. Les déploiements linéaires Amazon ECS nécessitent que votre service utilise l'une des fonctionnalités suivantes : Configurez les ressources appropriées. + Application Load Balancer : pour plus d’informations, consultez la section [Ressources d'Application Load Balancer pour les déploiements bleu/vert, linéaires et Canary](alb-resources-for-blue-green.md). + Network Load Balancer : pour plus d’informations, consultez la section [Ressources du Network Load Balancer pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](nlb-resources-for-blue-green.md). + Service Connect : pour plus d’informations, consultez la section [Ressources Service Connect pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](service-connect-blue-green.md). ## Procédure Vous pouvez utiliser la console ou le AWS CLI pour créer un service de déploiement linéaire Amazon ECS. ------ #### [ Console ] 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Déterminez la ressource à partir de laquelle vous lancez le service. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/deploy-linear-service.html) La page **Créer un service** s’affiche. 1. Sous **Détails du service**, procédez comme suit : 1. Pour **Famille de définition de tâche**, choisissez la définition de tâche à utiliser. Ensuite, pour **Révision de définition de tâche**, saisissez la révision à utiliser. 1. Pour **Service name** (Nom du service), saisissez un nom pour votre service. 1. Pour exécuter le service dans un cluster existant, pour **Cluster existant**, sélectionnez le cluster. Pour exécuter le service dans un nouveau cluster, choisissez **Créer un cluster** 1. Choisissez comment vos tâches sont distribuées dans votre infrastructure de cluster. Sous **Configuration de calcul**, choisissez votre option. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/deploy-linear-service.html) 1. Sous **Configuration du déploiement**, procédez comme suit : 1. Pour **Type de service**, choisissez **Replica**. 1. Pour **Desired tasks** (Tâches souhaitées), saisissez le nombre de tâches à lancer et à conserver dans le service. 1. Pour qu’Amazon ECS surveille la répartition des tâches entre les zones de disponibilité et les redistribue en cas de déséquilibre, sous **Rééquilibrage des services entre zones de disponibilité**, sélectionnez **Rééquilibrage des services entre zones de disponibilité**. 1. Pour **Période de grâce pour la surveillance de l’état**, saisissez la durée (en secondes) pendant laquelle le planificateur de service ignore les surveillances de l’état de Elastic Load Balancing, VPC Lattice et des conteneurs qui ne sont pas saines après le démarrage initial d’une tâche. Si vous ne spécifiez aucune valeur pour la période de grâce de surveillance de l’état, la valeur par défaut 0 est utilisée. 1. Sous **Configuration du déploiement**, configurez les paramètres de déploiement linéaire : 1. Pour **Stratégie de déploiement**, choisissez **Linear**. 1. Pour **le pourcentage d'augmentation du trafic**, entrez le pourcentage de trafic à déplacer à chaque incrément (par exemple, 10 % pour déplacer le trafic par tranches de 10 %). 1. Pour **Intervalle entre les incréments**, entrez le temps d'attente en minutes entre chaque incrément de changement de trafic. 1. Pour le **temps de cuisson**, entrez le nombre de minutes pendant lesquelles les révisions du service bleu et vert seront exécutées simultanément après le dernier changement de trafic avant que la révision bleue ne soit terminée. 1. (Facultatif) Exécutez des fonctions Lambda à des étapes spécifiques du déploiement. Sous **Hooks de cycle de vie du déploiement**, sélectionnez les étapes dans lesquelles exécuter les hooks de cycle de vie. Pour ajouter un hook de cycle de vie 1. Choisissez **Ajouter**. 1. Pour **Fonction Lambda**, saisissez le nom ou l’ARN de la fonction. 1. Pour **Rôle**, sélectionnez le rôle IAM qui dispose de l’autorisation requise pour invoquer la fonction Lambda. 1. Pour **Étapes du cycle de vie**, sélectionnez les étapes dans lesquelles la fonction Lambda doit être exécutée. 1. Pour configurer la manière dont Amazon ECS détecte et gère les échecs de déploiement, développez **Deployment failure detection** (Détection des échecs de déploiement), puis choisissez vos options. 1. Pour arrêter un déploiement lorsque les tâches ne peuvent pas démarrer, sélectionnez **Use the Amazon ECS deployment circuit breaker** (Utiliser le disjoncteur de déploiement Amazon ECS). Pour que le logiciel restaure automatiquement le dernier état de déploiement terminé lorsque le disjoncteur de déploiement définit le déploiement comme ayant échoué, sélectionnez **Restauration en cas d’échec**. 1. Pour arrêter un déploiement en fonction des métriques de l'application, sélectionnez **Utiliser une ou plusieurs CloudWatch alarmes**. Ensuite, à partir du **nom de l'CloudWatch alarme**, choisissez les alarmes. Pour créer une nouvelle alarme, rendez-vous sur la CloudWatch console. Pour que le logiciel annule automatiquement le déploiement au dernier état de déploiement terminé lorsqu'une CloudWatch alarme indique que le déploiement a échoué, sélectionnez Annulation en **cas d'échec**. 1. (Facultatif) Pour interconnecter votre service à l’aide de Service Connect, développez **Service Connect**, puis spécifiez les éléments suivants : 1. Sélectionnez **Activer Service Connect**. 1. Sous **Service Connect configuration** (Configuration de Service Connect), spécifiez le mode client. + Si votre service exécute une application client réseau qui doit uniquement se connecter à d’autres services de l’espace de noms, sélectionnez **Côté client uniquement**. + Si votre service exécute une application réseau ou un service Web et doit fournir des points de terminaison pour ce service, et se connecte à d'autres services dans l'espace de noms, choisissez **Client and server** (Client et serveur). 1. Pour utiliser un espace de noms qui n'est pas l'espace de noms de cluster par défaut, dans **Namespace** (Espace de noms), choisissez l'espace de noms du service. Il peut s'agir d'un espace de noms créé séparément dans le même espace Région AWS dans votre région Compte AWS ou d'un espace de noms dans la même région qui est partagé avec votre compte en utilisant AWS Resource Access Manager ()AWS RAM. *Pour plus d'informations sur les AWS Cloud Map espaces de noms partagés, consultez la section [Partage d'espaces de AWS Cloud Map noms entre comptes](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) dans le Guide du AWS Cloud Map développeur.* 1. (Facultatif) Configurez les règles d'en-tête du trafic de test pour les déploiements linéaires. Sous **Routage du trafic de test**, spécifiez les éléments suivants : 1. Sélectionnez **Activer les règles d’en-tête du trafic de test** pour acheminer des requêtes spécifiques vers la révision de service verte pendant les tests. 1. Pour **Règles de correspondance des en-têtes**, configurez les critères de routage du trafic de test suivants : + **Nom de l’en-tête** : saisissez le nom de l’en-tête HTTP correspondant (par exemple, `X-Test-Version` ou `User-Agent`). + **Type de correspondance** : choisissez les critères de correspondance : + **Correspondance exacte** : acheminer les requêtes dont la valeur d’en-tête correspond exactement à la valeur spécifiée + **En-tête présent** : acheminer les requêtes contenant l’en-tête spécifié, quelle que soit sa valeur + **Correspondance de modèle** : acheminer les requêtes dont la valeur d’en-tête correspond à un modèle spécifié + **Valeur d’en-tête** (si vous utilisez une correspondance exacte ou une correspondance de modèle) : saisissez la valeur ou le modèle à comparer. Vous pouvez ajouter plusieurs règles de correspondance d’en-têtes pour créer une logique de routage complexe. Les requêtes correspondant à l’une des règles configurées seront acheminées vers la version verte du service à des fins de test. 1. Choisissez **Ajouter une règle d’en-tête** pour configurer des conditions de correspondance d’en-tête supplémentaires. **Note** Les règles d’en-tête du trafic de test vous permettent de valider les nouvelles fonctionnalités avec un trafic contrôlé avant de procéder au déploiement complet. Cela vous permet de tester la révision de service verte avec des requêtes spécifiques (telles que celles provenant d’outils de test internes ou d’utilisateurs bêta) tout en maintenant un flux de trafic normal vers la révision de service bleue. 1. (Facultatif) Spécifiez une configuration de journal. Sélectionnez **Utiliser la collecte de journaux**. L'option par défaut envoie les journaux du conteneur à CloudWatch Logs. Les autres options du pilote de journal sont configurées à l'aide de AWS FireLens. Pour de plus amples informations, veuillez consulter [Envoyer les journaux Amazon ECS à un AWS service ou AWS Partner](using_firelens.md). Voici une description plus détaillée de chaque destination de journal de conteneur. + **Amazon CloudWatch** — Configurez la tâche pour envoyer les journaux des conteneurs à CloudWatch Logs. Les options du pilote de journal par défaut sont fournies, ce qui permet de créer un groupe de CloudWatch journaux en votre nom. Pour spécifier un autre nom de groupe de journaux, modifiez les valeurs des options de pilote. + **Amazon Data Firehose** : configurez la tâche pour envoyer des journaux de conteneur à Firehose. Les options par défaut du pilote de journalisation sont fournies. Elles envoient les journaux vers un flux de livraison Firehose. Pour spécifier un autre nom de flux de diffusion, modifiez les valeurs des options de pilote. + **Amazon Kinesis Data Streams** : configurez la tâche pour envoyer des journaux de conteneur à Kinesis Data Streams. Les options par défaut du pilote de journalisation sont fournies. Elles permettent d’envoyer les journaux vers un flux Kinesis Data Streams. Pour spécifier un autre nom de flux, modifiez les valeurs des options de pilote. + **Amazon OpenSearch Service** — Configurez la tâche pour envoyer les journaux des conteneurs vers un domaine OpenSearch de service. Les options de pilote de journal doivent être fournies. + **Simple Storage Service (Amazon S3)** : configurez la tâche pour envoyer des journaux de conteneur à un compartiment Simple Storage Service (Amazon S3). Les options de pilote de journal par défaut sont fournies, mais vous devez spécifier un nom de compartiment Simple Storage Service (Amazon S3) valide. 1. (Facultatif) Configurez l'**équilibrage** de charge pour un déploiement linéaire. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/deploy-linear-service.html) 1. (Facultatif) Pour vous aider à identifier votre service et vos tâches, développez **Tags** (balises), puis configurez vos balises. Pour qu'Amazon ECS balise automatiquement toutes les tâches nouvellement lancées avec le nom du cluster et les balises de définition des tâches, sélectionnez **Activer les balises gérées Amazon ECS**, puis pour **Propager des balises à partir de**, choisissez **Définitions de tâches**. Pour qu'Amazon ECS balise automatiquement toutes les tâches nouvellement lancées avec le nom du cluster et les balises d'un service, sélectionnez **Activer les balises gérées Amazon ECS**, puis pour **Propager des balises à partir de**, choisissez **Service**. Ajoutez ou supprimez une balise. + [Ajouter une balise] Choisissez **Add tag** (Ajouter une balise), puis procédez comme suit : + Pour **Clé**, saisissez le nom de la clé. + Pour **Valeur**, saisissez la valeur de clé. + [Supprimer une balise] En regard de la balise, choisissez **Supprimer la balise**. 1. Choisissez **Créer**. ------ #### [ AWS CLI ] 1. Créez un fichier nommé `linear-service-definition.json` avec le contenu suivant. Remplacez le *user-input* par vos valeurs. ``` { "serviceName": "myLinearService", "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster", "taskDefinition": "sample-fargate:1", "desiredCount": 5, "launchType": "FARGATE", "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "subnet-09ce6e74c116a2299", "subnet-00bb3bd7a73526788", "subnet-0048a611aaec65477" ], "securityGroups": [ "sg-09d45005497daa123" ], "assignPublicIp": "ENABLED" } }, "deploymentController": { "type": "ECS" }, "deploymentConfiguration": { "strategy": "LINEAR", "maximumPercent": 200, "minimumHealthyPercent": 100, "linearConfiguration": { "stepPercentage": 10.0, "stepBakeTimeInMinutes":6 }, "bakeTimeInMinutes": 10, "alarms": { "alarmNames": [ "myAlarm" ], "rollback": true, "enable": true } }, "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197", "containerName": "fargate-app", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199", "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-linear-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911", "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS" } } ] } ``` 1. Exécutez `create-service`. ``` aws ecs create-service --cli-input-json file://linear-service-definition.json ``` ------ ## Étapes suivantes + Mettez à jour le service pour démarrer le déploiement. Pour de plus amples informations, veuillez consulter [Mettre à jour un service Amazon ECS](update-service-console-v2.md). + Surveillez le processus de déploiement pour vous assurer qu'il suit le schéma linéaire : + La révision de service verte est créée et augmentée horizontalement + Le trafic est décalé progressivement aux intervalles spécifiés + Chaque incrément attend l'intervalle spécifié avant le prochain quart de travail + Une fois que tout le trafic est décalé, le temps de cuisson commence + Au terme de la durée de l’intégration, la révision bleue est résiliée # Déploiements canary d’Amazon ECS Les déploiements Canary acheminent d'abord un faible pourcentage du trafic vers la nouvelle version pour les tests initiaux, puis transfèrent immédiatement tout le trafic restant une fois la phase Canary terminée avec succès. Avec les déploiements Amazon ECS Canary, validez les nouvelles révisions de service avec le trafic utilisateur réel tout en minimisant l'exposition aux risques. Cette approche fournit un moyen contrôlé de déployer les modifications avec la possibilité de surveiller les performances et de revenir rapidement en arrière si des problèmes sont détectés. ## Ressources impliquées dans un déploiement de Canary Les ressources suivantes sont impliquées dans les déploiements d'Amazon ECS Canary : + Transfert de trafic : processus utilisé par Amazon ECS pour transférer le trafic de production. Pour les déploiements d'Amazon ECS Canary, le trafic est transféré en deux phases : d'abord pour atteindre le pourcentage Canary, puis pour terminer le déploiement. + Pourcentage Canary : pourcentage du trafic acheminé vers la nouvelle version pendant la période d'évaluation. + Durée de cuisson Canary : durée nécessaire pour surveiller la version Canary avant de procéder au déploiement complet. + 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. + 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 Canary exécutent simultanément les ensembles de tâches d'origine et Canary pendant la période d'évaluation, ce qui augmente l'utilisation des ressources. + Volume de trafic : assurez-vous que le pourcentage Canary génère suffisamment de trafic pour une validation significative de la nouvelle version. + Supervision de la complexité : les déploiements Canary nécessitent de surveiller et de comparer simultanément les métriques entre deux versions différentes. + Vitesse de restauration : les déploiements Canary permettent une restauration rapide en transférant le trafic vers l'ensemble de tâches initial. + Atténuation des risques : les déploiements de Canary offrent une excellente atténuation des risques en limitant l'exposition à un faible pourcentage d'utilisateurs. + Durée de déploiement : les déploiements Canary incluent des périodes d'évaluation qui prolongent le temps de déploiement global tout en offrant des opportunités de validation. ## Comment fonctionnent les déploiements Canary Le processus de déploiement d'Amazon ECS Canary 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). 1. Phase de préparation : création de l’environnement vert à côté de l’environnement bleu existant. 1. 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. 1. 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. 1. Phase de transfert du trafic Canary : transfert du pourcentage configuré du trafic vers la nouvelle révision du service écologique pendant la phase Canary, puis transfert de 100,0 % du trafic vers la révision du service vert 1. 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. 1. Phase d'achèvement : finalisez le déploiement en mettant fin à l'environnement bleu. La phase de transfert de trafic de Canary 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 de trafic aux Canaries - Il s'agit d'une stratégie de transfert de trafic en deux étapes. + Étape 1 : 10,0 % vers le vert, 90 % vers le bleu + Étape 2 : 100,0 % vers le vert, 0,0 % vers le bleu + Temps de cuisson Canary : attend une durée configurable (temps de cuisson Canary) après Canary Traffic Shift pour permettre le suivi et la validation des performances de la nouvelle révision compte tenu de l'augmentation de la charge de trafic. + 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\$1TRAFFIC\$1SHIFT seront invoqués à chaque étape du transfert du trafic de production. ### Étapes du cycle de vie du déploiement Le processus de déploiement de Canary 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. De plus, chaque étape de transfert de trafic dans PRODUCTION\$1TRAFFIC\$1SHIFT 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** | Étapes du cycle de vie | Description | Support Lifecycle Hook | | --- | --- | --- | | RECONCILE\$1SERVICE | 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\$1SCALE\$1UP | 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\$1UP | 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\$1SCALE\$1UP | 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\$1TRAFFIC\$1SHIFT | 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\$1TEST\$1TRAFFIC\$1SHIFT | Le transfert du trafic de test est terminé. La révision de service verte gère 100 % du trafic de test. | Oui | | PRODUCTION\$1TRAFFIC\$1SHIFT | Le trafic de production de Canary est acheminé vers la révision verte et le hook du cycle de vie est invoqué avec un délai d'expiration de 24 heures. La deuxième étape fait passer le trafic de production restant à la révision verte. | Oui | | POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | Le transfert du trafic de production est terminé. | Oui | | BAKE\$1TIME | Durée pendant laquelle les révisions de service bleues et vertes sont exécutées simultanément. | Non | | CLEAN\$1UP | 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 | ### Paramètres de configuration Les déploiements Canary nécessitent les paramètres de configuration suivants : + Pourcentage Canary : pourcentage du trafic à acheminer vers la nouvelle révision du service pendant la phase Canary. Cela permet de tester avec un sous-ensemble contrôlé du trafic de production. + Temps de cuisson des canaris : temps d'attente pendant la phase canari avant de transférer le trafic restant vers la nouvelle révision du service. Cela laisse le temps de contrôler et de valider la nouvelle version. ### Gestion du trafic Les déploiements Canary utilisent des groupes cibles d'équilibreurs de charge pour gérer la distribution du trafic : + Groupe cible d'origine : contient les tâches de la version stable actuelle et reçoit la majorité du trafic. + Groupe cible Canary : contient les tâches de la nouvelle version et reçoit un faible pourcentage de trafic à des fins de test. + Routage pondéré : l'équilibreur de charge utilise des règles de routage pondérées pour répartir le trafic entre les groupes cibles en fonction du pourcentage Canary configuré. ### Surveillance et validation Les déploiements Canary efficaces reposent sur une surveillance complète : + Contrôles de santé - Les deux ensembles de tâches doivent passer des tests de santé avant de recevoir du trafic. + Comparaison des indicateurs : comparez les indicateurs de performance clés entre les versions d'origine et Canary, tels que le temps de réponse, le taux d'erreur et le débit. + Annulation automatique - Configurez les CloudWatch alarmes pour déclencher automatiquement la restauration si les performances de la version Canary sont dégradées. + Validation manuelle : utilisez la période d'évaluation pour examiner manuellement les journaux, les indicateurs et les commentaires des utilisateurs avant de continuer. ### Bonnes pratiques pour les déploiements avec Canary Suivez ces bonnes pratiques pour garantir le succès des déploiements Canary avec les services. #### Choisissez les pourcentages de trafic appropriés Tenez compte des facteurs suivants lors de la sélection des pourcentages de trafic Canary : + Commencez modestement : commencez par 5 à 10 % du trafic afin de minimiser l'impact en cas de problème. + Tenez compte de la criticité des applications : utilisez des pourcentages plus faibles pour les applications critiques et des pourcentages plus élevés pour les services moins critiques. + Tenez compte du volume de trafic - Assurez-vous que le pourcentage Canary génère suffisamment de trafic pour une validation significative. #### Définissez des périodes d'évaluation appropriées Configurez les périodes d'évaluation en fonction des considérations suivantes : + Prévoyez suffisamment de temps : définissez des périodes d'évaluation suffisamment longues pour recueillir des données de performance pertinentes, généralement de 10 à 30 minutes. + Tenez compte des modèles de trafic : tenez compte des modèles de trafic de votre application et des heures de pointe d'utilisation. + Équilibre entre rapidité et sécurité - Les périodes d'évaluation plus longues fournissent davantage de données mais ralentissent la vitesse de déploiement. #### Mettre en œuvre une surveillance complète Configurez la surveillance pour suivre les performances de déploiement de Canary : + Indicateurs clés : surveillez le temps de réponse, le taux d'erreur, le débit et l'utilisation des ressources pour les deux ensembles de tâches. + Annulation basée sur les alarmes : configurez les CloudWatch alarmes pour déclencher automatiquement l'annulation lorsque les métriques dépassent les seuils. + Analyse comparative - Configurez des tableaux de bord pour comparer les indicateurs entre les versions side-by-side d'origine et Canary. + Indicateurs commerciaux - Incluez des indicateurs spécifiques à l'entreprise, tels que les taux de conversion ou l'engagement des utilisateurs, ainsi que des indicateurs techniques. #### Planifier des stratégies de réduction Préparez-vous à d'éventuels scénarios de réduction grâce aux stratégies suivantes : + Annulation automatique : configurez des déclencheurs de restauration automatique en fonction des bilans de santé et des indicateurs de performance. + Procédures d'annulation manuelles - Documentez des procédures claires pour la restauration manuelle lorsque les déclencheurs automatisés ne détectent pas tous les problèmes. + Tests de rétrogradation : testez régulièrement les procédures de rétrogradation pour vous assurer qu'elles fonctionnent correctement en cas de besoin. #### Validez minutieusement avant le déploiement Assurez-vous d'une validation complète avant de procéder aux déploiements Canary : + Tests de pré-déploiement : testez minutieusement les modifications dans les environnements de test avant le déploiement de Canary. + Configuration des contrôles de santé : assurez-vous que les contrôles de santé reflètent avec précision l'état de préparation et les fonctionnalités de l'application. + Validation des dépendances : vérifiez que les nouvelles versions sont compatibles avec les services en aval et en amont. + Cohérence des données : assurez-vous que les modifications du schéma de base de données et les migrations de données sont rétrocompatibles. #### Coordonner l'implication de l'équipe Garantissez une coordination efficace des équipes lors des déploiements Canary : + Fenêtres de déploiement : planifiez les déploiements de Canary pendant les heures ouvrables lorsque les équipes sont disponibles pour surveiller et répondre. + Canaux de communication - Établissez des canaux de communication clairs pour connaître l'état du déploiement et l'escalade des problèmes. + Attributions de rôles : définissez les rôles et les responsabilités en matière de surveillance, de prise de décision et d'exécution des annulations. # Ressources requises pour les déploiements d'Amazon ECS Canary Pour utiliser un déploiement Canary avec transfert de trafic géré, votre service doit utiliser l'une des fonctionnalités suivantes : + Elastic Load Balancing + Service Connect La liste suivante fournit un aperçu général de ce que vous devez configurer pour les déploiements Amazon ECS Canary : + Votre service utilise Application Load Balancer, Network Load Balancer ou Service Connect Configurez les ressources appropriées. + Application Load Balancer : pour plus d’informations, consultez la section [Ressources d'Application Load Balancer pour les déploiements bleu/vert, linéaires et Canary](alb-resources-for-blue-green.md). + Network Load Balancer : pour plus d’informations, consultez la section [Ressources du Network Load Balancer pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](nlb-resources-for-blue-green.md). + Service Connect : pour plus d’informations, consultez la section [Ressources Service Connect pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](service-connect-blue-green.md). + Définissez le contrôleur de déploiement de service sur `ECS`. + Configurez la stratégie de déploiement sur `canary` dans votre définition de service. + Configurez éventuellement des paramètres supplémentaires tels que : + La durée de l’intégration pour le nouveau déploiement + Pourcentage du trafic à acheminer vers la nouvelle révision du service pendant la phase Canary. + Durée d'attente pendant la phase Canary avant de transférer le trafic restant vers la nouvelle révision du service. + CloudWatch alarmes pour annulation automatique + Hooks du cycle de vie du déploiement (il s'agit de fonctions Lambda qui s'exécutent à des étapes de déploiement spécifiées) ## Bonnes pratiques Suivez ces bonnes pratiques pour réussir les déploiements Amazon ECS lcanary : + **Assurez-vous que votre application peut gérer les deux révisions de service exécutées simultanément.** + **Prévoyez une capacité de cluster suffisante pour gérer les deux révisions de service lors du déploiement.** + **Testez vos procédures de rollback avant de les mettre en œuvre en production.** + Configurez les surveillances de l’état appropriées qui reflètent précisément l’état de votre application. + Définissez une durée de l’intégration permettant de tester suffisamment le déploiement vert. + Implémentez des CloudWatch alarmes pour détecter automatiquement les problèmes et déclencher des annulations. + Utilisez les hooks de cycle de vie pour effectuer des tests automatisés à chaque étape du déploiement. + Commencez par de faibles pourcentages de canaris (5 à 10 %) afin de minimiser l'impact en cas de problème. + Définissez des périodes d'évaluation appropriées qui laissent suffisamment de temps pour une collecte significative de données de performance. + Mettez en œuvre une surveillance complète avec des CloudWatch alarmes pour les déclencheurs d'annulation automatisés. + Configurez des contrôles de santé qui reflètent avec précision l'état de préparation et les fonctionnalités de votre application. + Surveillez à la fois les indicateurs techniques (temps de réponse, taux d'erreur) et les indicateurs commerciaux pendant l'évaluation. + Assurez-vous que votre application peut gérer le partage du trafic sans problèmes de session ou d'état. + Planifiez les procédures de rollback et testez-les régulièrement pour vous assurer qu'elles fonctionnent en cas de besoin. + Planifiez les déploiements de Canary pendant les heures ouvrables, lorsque les équipes peuvent surveiller et réagir. + Validez minutieusement les modifications dans les environnements de test avant le déploiement de Canary. + Documentez des procédures claires pour les interventions manuelles et les décisions d'annulation. # Création d'un déploiement Amazon ECS Canary En utilisant les déploiements Amazon ECS Canary, vous pouvez transférer un faible pourcentage du trafic vers votre nouvelle version de service (le « canari »). Validez le déploiement, puis déplacez le trafic restant en une seule fois après un intervalle spécifié. Cette approche vous permet de tester de nouvelles fonctionnalités avec un minimum de risques avant le déploiement complet. ## Conditions préalables Effectuez les opérations suivantes avant de démarrer un déploiement Canary. 1. Configurez les autorisations appropriées. + Pour plus d’informations sur les autorisations Elastic Load Balancing, consultez la section [Rôle IAM d’infrastructure Amazon ECS pour les équilibreurs de charge](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). + Pour plus d’informations sur les autorisations Lambda, consultez la section [Autorisations requises pour les fonctions Lambda dans les déploiements Amazon ECS blue/green](blue-green-permissions.md). 1. Les déploiements Amazon ECS Canary nécessitent que votre service utilise l'une des fonctionnalités suivantes : Configurez les ressources appropriées. + Application Load Balancer : pour plus d’informations, consultez la section [Ressources d'Application Load Balancer pour les déploiements bleu/vert, linéaires et Canary](alb-resources-for-blue-green.md). + Network Load Balancer : pour plus d’informations, consultez la section [Ressources du Network Load Balancer pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](nlb-resources-for-blue-green.md). + Service Connect : pour plus d’informations, consultez la section [Ressources Service Connect pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](service-connect-blue-green.md). ## Procédure Vous pouvez utiliser la console ou le AWS CLI pour créer un service de déploiement Amazon ECS Canary. ------ #### [ Console ] 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Déterminez la ressource à partir de laquelle vous lancez le service. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/deploy-canary-service.html) La page **Créer un service** s’affiche. 1. Sous **Détails du service**, procédez comme suit : 1. Pour **Famille de définition de tâche**, choisissez la définition de tâche à utiliser. Ensuite, pour **Révision de définition de tâche**, saisissez la révision à utiliser. 1. Pour **Service name** (Nom du service), saisissez un nom pour votre service. 1. Pour exécuter le service dans un cluster existant, pour **Cluster existant**, sélectionnez le cluster. Pour exécuter le service dans un nouveau cluster, choisissez **Créer un cluster** 1. Choisissez comment vos tâches sont distribuées dans votre infrastructure de cluster. Sous **Configuration de calcul**, choisissez votre option. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/deploy-canary-service.html) 1. Sous **Configuration du déploiement**, procédez comme suit : 1. Pour **Type de service**, choisissez **Replica**. 1. Pour **Desired tasks** (Tâches souhaitées), saisissez le nombre de tâches à lancer et à conserver dans le service. 1. Pour qu’Amazon ECS surveille la répartition des tâches entre les zones de disponibilité et les redistribue en cas de déséquilibre, sous **Rééquilibrage des services entre zones de disponibilité**, sélectionnez **Rééquilibrage des services entre zones de disponibilité**. 1. Pour **Période de grâce pour la surveillance de l’état**, saisissez la durée (en secondes) pendant laquelle le planificateur de service ignore les surveillances de l’état de Elastic Load Balancing, VPC Lattice et des conteneurs qui ne sont pas saines après le démarrage initial d’une tâche. Si vous ne spécifiez aucune valeur pour la période de grâce de surveillance de l’état, la valeur par défaut 0 est utilisée. 1. Sous **Configuration du déploiement**, configurez les paramètres de déploiement de Canary : 1. Pour la **stratégie de déploiement**, choisissez **Canary**. 1. Pour le **pourcentage Canary**, entrez le pourcentage du trafic à passer à la révision du service vert lors de la première étape (par exemple, 10 % pour le trafic Canary initial). 1. Pour le **temps de cuisson aux Canaries**, entrez le temps d'attente en minutes avant de transférer le reste du trafic vers la version verte du service. 1. Pour le **temps de cuisson**, entrez le nombre de minutes pendant lesquelles les révisions du service bleu et vert seront exécutées simultanément après le dernier changement de trafic avant que la révision bleue ne soit terminée. 1. (Facultatif) Exécutez des fonctions Lambda à des étapes spécifiques du déploiement. Sous **Hooks de cycle de vie du déploiement**, sélectionnez les étapes dans lesquelles exécuter les hooks de cycle de vie. Pour ajouter un hook de cycle de vie 1. Choisissez **Ajouter**. 1. Pour **Fonction Lambda**, saisissez le nom ou l’ARN de la fonction. 1. Pour **Rôle**, sélectionnez le rôle IAM qui dispose de l’autorisation requise pour invoquer la fonction Lambda. 1. Pour **Étapes du cycle de vie**, sélectionnez les étapes dans lesquelles la fonction Lambda doit être exécutée. 1. Pour configurer la manière dont Amazon ECS détecte et gère les échecs de déploiement, développez **Deployment failure detection** (Détection des échecs de déploiement), puis choisissez vos options. 1. Pour arrêter un déploiement lorsque les tâches ne peuvent pas démarrer, sélectionnez **Use the Amazon ECS deployment circuit breaker** (Utiliser le disjoncteur de déploiement Amazon ECS). Pour que le logiciel restaure automatiquement le dernier état de déploiement terminé lorsque le disjoncteur de déploiement définit le déploiement comme ayant échoué, sélectionnez **Restauration en cas d’échec**. 1. Pour arrêter un déploiement en fonction des métriques de l'application, sélectionnez **Utiliser une ou plusieurs CloudWatch alarmes**. Ensuite, à partir du **nom de l'CloudWatch alarme**, choisissez les alarmes. Pour créer une nouvelle alarme, rendez-vous sur la CloudWatch console. Pour que le logiciel annule automatiquement le déploiement au dernier état de déploiement terminé lorsqu'une CloudWatch alarme indique que le déploiement a échoué, sélectionnez Annulation en **cas d'échec**. 1. (Facultatif) Pour interconnecter votre service à l’aide de Service Connect, développez **Service Connect**, puis spécifiez les éléments suivants : 1. Sélectionnez **Activer Service Connect**. 1. Sous **Service Connect configuration** (Configuration de Service Connect), spécifiez le mode client. + Si votre service exécute une application client réseau qui doit uniquement se connecter à d’autres services de l’espace de noms, sélectionnez **Côté client uniquement**. + Si votre service exécute une application réseau ou un service Web et doit fournir des points de terminaison pour ce service, et se connecte à d'autres services dans l'espace de noms, choisissez **Client and server** (Client et serveur). 1. Pour utiliser un espace de noms qui n'est pas l'espace de noms de cluster par défaut, dans **Namespace** (Espace de noms), choisissez l'espace de noms du service. Il peut s'agir d'un espace de noms créé séparément dans le même espace Région AWS dans votre région Compte AWS ou d'un espace de noms dans la même région qui est partagé avec votre compte en utilisant AWS Resource Access Manager ()AWS RAM. *Pour plus d'informations sur les AWS Cloud Map espaces de noms partagés, consultez la section [Partage d'espaces de AWS Cloud Map noms entre comptes](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) dans le Guide du AWS Cloud Map développeur.* 1. (Facultatif) Configurez les règles d'en-tête du trafic de test pour les déploiements Canary. Sous **Routage du trafic de test**, spécifiez les éléments suivants : 1. Sélectionnez **Activer les règles d’en-tête du trafic de test** pour acheminer des requêtes spécifiques vers la révision de service verte pendant les tests. 1. Pour **Règles de correspondance des en-têtes**, configurez les critères de routage du trafic de test suivants : + **Nom de l’en-tête** : saisissez le nom de l’en-tête HTTP correspondant (par exemple, `X-Test-Version` ou `User-Agent`). + **Type de correspondance** : choisissez les critères de correspondance : + **Correspondance exacte** : acheminer les requêtes dont la valeur d’en-tête correspond exactement à la valeur spécifiée + **En-tête présent** : acheminer les requêtes contenant l’en-tête spécifié, quelle que soit sa valeur + **Correspondance de modèle** : acheminer les requêtes dont la valeur d’en-tête correspond à un modèle spécifié + **Valeur d’en-tête** (si vous utilisez une correspondance exacte ou une correspondance de modèle) : saisissez la valeur ou le modèle à comparer. Vous pouvez ajouter plusieurs règles de correspondance d’en-têtes pour créer une logique de routage complexe. Les requêtes correspondant à l’une des règles configurées seront acheminées vers la version verte du service à des fins de test. 1. Choisissez **Ajouter une règle d’en-tête** pour configurer des conditions de correspondance d’en-tête supplémentaires. **Note** Les règles d’en-tête du trafic de test vous permettent de valider les nouvelles fonctionnalités avec un trafic contrôlé avant de procéder au déploiement complet. Cela vous permet de tester la révision de service verte avec des requêtes spécifiques (telles que celles provenant d’outils de test internes ou d’utilisateurs bêta) tout en maintenant un flux de trafic normal vers la révision de service bleue. 1. (Facultatif) Spécifiez une configuration de journal. Sélectionnez **Utiliser la collecte de journaux**. L'option par défaut envoie les journaux du conteneur à CloudWatch Logs. Les autres options du pilote de journal sont configurées à l'aide de AWS FireLens. Pour de plus amples informations, veuillez consulter [Envoyer les journaux Amazon ECS à un AWS service ou AWS Partner](using_firelens.md). Voici une description plus détaillée de chaque destination de journal de conteneur. + **Amazon CloudWatch** — Configurez la tâche pour envoyer les journaux des conteneurs à CloudWatch Logs. Les options du pilote de journal par défaut sont fournies, ce qui permet de créer un groupe de CloudWatch journaux en votre nom. Pour spécifier un autre nom de groupe de journaux, modifiez les valeurs des options de pilote. + **Amazon Data Firehose** : configurez la tâche pour envoyer des journaux de conteneur à Firehose. Les options par défaut du pilote de journalisation sont fournies. Elles envoient les journaux vers un flux de livraison Firehose. Pour spécifier un autre nom de flux de diffusion, modifiez les valeurs des options de pilote. + **Amazon Kinesis Data Streams** : configurez la tâche pour envoyer des journaux de conteneur à Kinesis Data Streams. Les options par défaut du pilote de journalisation sont fournies. Elles permettent d’envoyer les journaux vers un flux Kinesis Data Streams. Pour spécifier un autre nom de flux, modifiez les valeurs des options de pilote. + **Amazon OpenSearch Service** — Configurez la tâche pour envoyer les journaux des conteneurs vers un domaine OpenSearch de service. Les options de pilote de journal doivent être fournies. + **Simple Storage Service (Amazon S3)** : configurez la tâche pour envoyer des journaux de conteneur à un compartiment Simple Storage Service (Amazon S3). Les options de pilote de journal par défaut sont fournies, mais vous devez spécifier un nom de compartiment Simple Storage Service (Amazon S3) valide. 1. (Facultatif) Configurez l'**équilibrage** de charge pour le déploiement de Canary. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/deploy-canary-service.html) 1. (Facultatif) Pour vous aider à identifier votre service et vos tâches, développez **Tags** (balises), puis configurez vos balises. Pour qu'Amazon ECS balise automatiquement toutes les tâches nouvellement lancées avec le nom du cluster et les balises de définition des tâches, sélectionnez **Activer les balises gérées Amazon ECS**, puis pour **Propager des balises à partir de**, choisissez **Définitions de tâches**. Pour qu'Amazon ECS balise automatiquement toutes les tâches nouvellement lancées avec le nom du cluster et les balises d'un service, sélectionnez **Activer les balises gérées Amazon ECS**, puis pour **Propager des balises à partir de**, choisissez **Service**. Ajoutez ou supprimez une balise. + [Ajouter une balise] Choisissez **Add tag** (Ajouter une balise), puis procédez comme suit : + Pour **Clé**, saisissez le nom de la clé. + Pour **Valeur**, saisissez la valeur de clé. + [Supprimer une balise] En regard de la balise, choisissez **Supprimer la balise**. 1. Choisissez **Créer**. ------ #### [ AWS CLI ] 1. Créez un fichier nommé `canary-service-definition.json` avec le contenu suivant. Remplacez le *user-input* par vos valeurs. ``` { "serviceName": "myCanaryService", "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster", "taskDefinition": "sample-fargate:1", "desiredCount": 5, "launchType": "FARGATE", "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "subnet-09ce6e74c116a2299", "subnet-00bb3bd7a73526788", "subnet-0048a611aaec65477" ], "securityGroups": [ "sg-09d45005497daa123" ], "assignPublicIp": "ENABLED" } }, "deploymentController": { "type": "ECS" }, "deploymentConfiguration": { "strategy": "CANARY", "maximumPercent": 200, "minimumHealthyPercent": 100, "canaryConfiguration" : { "canaryPercent" : 5.0, "canaryBakeTime" : 10 }, "bakeTimeInMinutes": 10, "alarms": { "alarmNames": [ "myAlarm" ], "rollback": true, "enable": true } }, "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197", "containerName": "fargate-app", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199", "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-canary-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911", "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS" } } ] } ``` 1. Exécutez `create-service`. ``` aws ecs create-service --cli-input-json file://canary-service-definition.json ``` ------ ## Étapes suivantes Après avoir configuré votre déploiement de Canary, procédez comme suit : + Mettez à jour le service pour démarrer le déploiement. Pour de plus amples informations, veuillez consulter [Mettre à jour un service Amazon ECS](update-service-console-v2.md). + Surveillez le processus de déploiement pour vous assurer qu'il suit le modèle Canary : + La révision de service verte est créée et augmentée horizontalement + Un faible pourcentage du trafic (canari) passe à la version verte + Le système attend l'intervalle canari spécifié + Le trafic restant est transféré en une seule fois vers la version verte + Au terme de la durée de l’intégration, la révision bleue est résiliée ## Terminologie du déploiement Les termes suivants sont utilisés dans la documentation de déploiement d'Amazon ECS : Déploiement bleu-vert Stratégie de déploiement qui crée un nouvel environnement (vert) à côté de l'environnement existant (bleu), puis fait passer le trafic du bleu au vert après validation. Déploiement Canary Stratégie de déploiement qui achemine un faible pourcentage du trafic vers une nouvelle version tout en conservant la majorité sur la version stable à des fins de validation. Déploiement linéaire Stratégie de déploiement qui déplace progressivement le trafic de l'ancienne version vers la nouvelle version par incréments égaux au fil du temps. Déploiement progressif Stratégie de déploiement qui remplace les instances de l'ancienne version par des instances de la nouvelle version une par une. Ensemble de tâches Ensemble de tâches qui exécutent la même définition de tâche au sein d'un service lors d'un déploiement. Groupe cible Groupement logique de cibles recevant le trafic d'un équilibreur de charge lors des déploiements. Contrôleur de déploiement Méthode utilisée pour déployer de nouvelles versions de votre service, telles qu'Amazon ECS CodeDeploy, ou des contrôleurs externes. Restauration Processus qui consiste à revenir à une version précédente de votre application lorsque des problèmes sont détectés lors du déploiement. # Déploiement de services Amazon ECS à l’aide d’un contrôleur tiers Le type de déploiement *externe* vous permet d'utiliser n'importe quel contrôleur de déploiement tiers pour un contrôle complet du processus de déploiement pour un service Amazon ECS service. Les détails pour votre service sont gérés par les actions d'API de gestion de service (`CreateService`, `UpdateService` et `DeleteService`) ou par les actions d'API de gestion des tâches définies (`CreateTaskSet`, `UpdateTaskSet`, `UpdateServicePrimaryTaskSet` et `DeleteTaskSet`). Chaque action d'API gère un sous-ensemble de paramètres de définition de service. L'action d'API `UpdateService` met à jour le nombre souhaité et les paramètres de période de délai supplémentaire des surveillances de l'état pour un service. Si l’option de calcul, la version de plateforme, les détails de l’équilibreur de charge, la configuration réseau ou la définition de tâche doivent être mis à jour, vous devez créer un jeu de tâches. L'action d'API `UpdateTaskSet` met à jour uniquement le paramètre d'échelle pour un ensemble de tâches. L'action d'API `UpdateServicePrimaryTaskSet` modifie l'ensemble de tâches dans un service qui est l'ensemble de tâches principal. Lorsque vous appelez l'action d'API `DescribeServices`, elle renvoie tous les champs spécifiés pour un ensemble de tâches principal. Si l'ensemble de tâches principal d'un service est mis à jour, toutes les valeurs de paramètres de l'ensemble de tâches qui existe sur l'ensemble de tâches principal différent de l'ancienne tâche principale dans un service sont mises à jour vers la nouvelle valeur lorsqu'un ensemble de tâches principal est défini. Si aucun ensemble de tâches principale n'est défini pour un service, les champs de l'ensemble de tâches sont vides pour la description de service. ## Considérations relatives au déploiement externe Tenez compte des éléments suivants lorsque vous utilisez le type de déploiement externe : + Les types d'équilibreur de charge pris en charge sont un Application Load Balancer ou un Network Load Balancer. + Les types de contrôleurs de déploiement Fargate ou `EXTERNAL` ne prennent pas en charge la stratégie de planification `DAEMON`. + L' AutoScaling intégration des applications avec Amazon ECS prend uniquement en charge le service Amazon ECS en tant que cible. La dimension de capacité de mise à l’échelle prise en charge pour Amazon ECS est `ecs:service:DesiredCount`, soit le nombre de tâches d’un service Amazon ECS. Il n'existe aucune intégration directe entre l'application AutoScaling et les ensembles de tâches Amazon ECS. Les jeux de tâches Amazon ECS calculent le `ComputedDesiredCount` en fonction du `DesiredCount` du service Amazon ECS. ## Workflow de déploiement externe Voici le flux de travail de base pour la gestion d’un déploiement externe sur Amazon ECS. **Pour gérer un service Amazon ECS service à l'aide d'un contrôleur de déploiement externe** 1. Créez un service Amazon ECS service. Le seul paramètre requis est le nom de service. Vous pouvez spécifier les paramètres suivants lors de la création d'un service à l'aide d'un contrôleur de déploiement externe. Tous les autres paramètres de service sont spécifiés lors de la création d'un ensemble de tâches dans le service. `serviceName` Type : Chaîne Obligatoire : oui Nom de votre service. Jusqu'à 255 lettres (majuscules et minuscules), chiffres, traits d'union et traits de soulignement sont autorisés. Dans un cluster, les noms de service doivent être uniques, mais certains services peuvent avoir des noms similaires dans des clusters différents d'une même région ou de plusieurs régions. `desiredCount` Le nombre d'instances sur la définition de tâche d'ensemble de tâches spécifié à placer et à continuer d'exécuter au sein du service. `deploymentConfiguration` Paramètres de déploiement facultatifs qui contrôlent le nombre de tâches exécutées durant le déploiement et la commande d'arrêt et de démarrage des tâches. `tags` Type : tableau d'objets Obligatoire : non Métadonnées que vous appliquez au service pour faciliter le classement et l'organisation. Chaque étiquette est constituée d'une clé et d'une valeur facultative que vous définissez. Lorsqu'un service est supprimé, les étiquettes sont également supprimées. Un maximum de 50 balises peut être appliqué au service. Pour de plus amples informations, veuillez consulter [Balisage des ressources Amazon ECS](ecs-using-tags.md). Lorsque vous mettez à jour un service, ce paramètre ne déclenche pas le déploiement d’un nouveau service. `key` Type : Chaîne Contraintes de longueur : Longueur minimum de 1. Longueur maximale de 128. Obligatoire : non Partie d'une paire clé-valeur qui constitue une étiquette. Une clé est une étiquette générale qui fait office de catégorie pour les valeurs d'étiquette plus spécifiques. `value` Type : Chaîne Contraintes de longueur : Longueur minimum de 0. Longueur maximale de 256. Obligatoire : non Partie facultative d'une paire clé-valeur qui constitue une étiquette. Une valeur agit comme un descripteur au sein d'une catégorie d'étiquette (clé). `enableECSManagedTags` Spécifie si utiliser les identifications gérées par Amazon ECS pour les tâches dans le service. Pour de plus amples informations, veuillez consulter [Mise à jour des balises pour la facturation](ecs-using-tags.md#tag-resources-for-billing). `propagateTags` Type : Chaîne Valeurs valides : `TASK_DEFINITION` \$1 `SERVICE` Obligatoire : non Indique s'il faut copier les étiquettes de la définition de tâche ou du service dans les tâches du service. Si aucune valeur n'est spécifiée, les étiquettes ne sont pas copiées. Les étiquettes ne peuvent être copiées dans les tâches du service que lors de la création du service. Pour ajouter des balises à une tâche après la création du service ou de la tâche, utilisez l'action d'API `TagResource`. Lorsque vous mettez à jour un service, ce paramètre ne déclenche pas le déploiement d’un nouveau service. `schedulingStrategy` Stratégie de planification à utiliser. Les services utilisant un contrôleur de déploiement externe prennent uniquement en charge la stratégie de planification `REPLICA`. `placementConstraints` Tableau d'objets de contraintes de placement à utiliser pour les tâches de votre service. Vous pouvez spécifier un maximum de 10 contraintes par tâche (cette limite comprend les contraintes de la définition de tâche et celles spécifiées lors de l'exécution). Si vous utilisez Fargate, les contraintes de placement des tâches ne sont pas prises en charge. `placementStrategy` Objets de stratégie de placement à utiliser pour les tâches de votre service. Vous pouvez spécifier jusqu'à quatre règles de stratégie par service. Voici un exemple de définition de service pour la création d'un service qui utilise un contrôleur de déploiement externe. ``` { "cluster": "", "serviceName": "", "desiredCount": 0, "role": "", "deploymentConfiguration": { "maximumPercent": 0, "minimumHealthyPercent": 0 }, "placementConstraints": [ { "type": "distinctInstance", "expression": "" } ], "placementStrategy": [ { "type": "binpack", "field": "" } ], "schedulingStrategy": "REPLICA", "deploymentController": { "type": "EXTERNAL" }, "tags": [ { "key": "", "value": "" } ], "enableECSManagedTags": true, "propagateTags": "TASK_DEFINITION" } ``` 1. Créez un ensemble de tâches initial. L'ensemble de tâches contient les détails suivants pour votre service : `taskDefinition` La définition de tâche pour les tâches dans l'ensemble de tâches à utiliser. `launchType` Type : Chaîne Valeurs valides : `EC2` \$1 `FARGATE` \$1 `EXTERNAL` Obligatoire : non Type de lancement sur lequel vous pouvez exécuter votre service. Si aucun type de lancement n'est spécifié, the `capacityProviderStrategy` par défaut est utilisé par défaut. Lorsque vous mettez à jour un service, ce paramètre déclenche un nouveau déploiement de service. Si un `launchType` est spécifié, le paramètre `capacityProviderStrategy` doit être omis. `platformVersion` Type : chaîne Obligatoire : non Version de la plateforme sur laquelle s'exécutent vos tâches dans le service. Une version de plateforme est spécifiée uniquement pour les tâches utilisant le type de lancement Fargate. Si vous ne spécifiez aucune valeur, la dernière version (`LATEST`) est utilisée par défaut. Lorsque vous mettez à jour un service, ce paramètre déclenche un nouveau déploiement de service. AWS Les versions de la plateforme Fargate sont utilisées pour faire référence à un environnement d'exécution spécifique pour l'infrastructure de tâches Fargate. Lorsque vous spécifiez `LATEST` comme version de plateforme lors de l'exécution d'une tâche ou de la création d'un service, vous obtenez la version de plateforme la plus récente pour vos tâches. Lorsque vous mettez à l'échelle votre service, ces tâches reçoivent la version de plateforme spécifiée dans le déploiement actuel du service. Pour de plus amples informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md). Les versions de plateforme ne sont pas spécifiées pour les tâches utilisant le type de lancement EC2. `loadBalancers` Un objet d'équilibreur de charge qui représente l'équilibreur de charge à utiliser avec votre service. Lorsque vous utilisez un contrôleur de déploiement externe, seuls les équilibreurs de charge Application Load Balancer et les Network Load Balancer sont pris en charge. Si vous utilisez un équilibreur de charge Application Load Balancer, seul un groupe cible d'équilibreur de charge Application Load Balancer est autorisé par tâche. L'extrait de code suivant montre un exemple d'objet `loadBalancer` à utiliser. ``` "loadBalancers": [ { "targetGroupArn": "", "containerName": "", "containerPort": 0 } ] ``` Lorsque vous spécifiez un objet `loadBalancer`, vous devez spécifier `targetGroupArn` et omettre les paramètres `loadBalancerName`. `networkConfiguration` Configuration réseau du service. Ce paramètre est obligatoire pour les définitions de tâches qui utilisent le mode réseau `awsvpc` afin de recevoir leur propre interface réseau Elastic. Il n'est pas pris en charge avec les autres modes réseau. Pour plus d’informations sur la mise en réseau pour Fargate, consultez la section [Options de mise en réseau des tâches Amazon ECS pour Fargate](fargate-task-networking.md). `serviceRegistries` Les détails des enregistrements de découverte de service à attribuer à ce service. Pour de plus amples informations, veuillez consulter [Utilisation de la découverte de service pour connecter les services Amazon ECS avec des noms DNS](service-discovery.md). `scale` Pourcentage à virgule flottante du nombre souhaité de tâches à placer et à continuer d'exécuter dans l'ensemble de tâches. La valeur est spécifiée en tant que pourcentage total de `desiredCount` d'un service. Les valeurs acceptées sont des nombres compris entre 0 et 100. Voici un exemple JSON pour créer un ensemble de tâches pour un contrôleur de déploiement externe. ``` { "service": "", "cluster": "", "externalId": "", "taskDefinition": "", "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "" ], "securityGroups": [ "" ], "assignPublicIp": "DISABLED" } }, "loadBalancers": [ { "targetGroupArn": "", "containerName": "", "containerPort": 0 } ], "serviceRegistries": [ { "registryArn": "", "port": 0, "containerName": "", "containerPort": 0 } ], "launchType": "EC2", "capacityProviderStrategy": [ { "capacityProvider": "", "weight": 0, "base": 0 } ], "platformVersion": "", "scale": { "value": null, "unit": "PERCENT" }, "clientToken": "" } ``` 1. Lorsque des modifications de service sont nécessaires, utilisez l'action d'API `CreateTaskSet`, `UpdateService` ou `UpdateTaskSet`, en fonction des paramètres que vous mettez à jour. Si vous avez créé un ensemble de tâches, utilisez le paramètre `scale` pour chaque ensemble de tâches dans un service afin de déterminer le nombre de tâches à continuer d'exécuter dans le service. Par exemple, si vous disposez d'un service qui contient `tasksetA` et que vous créez un `tasksetB`, vous pouvez tester la validité de `tasksetB` avant de vouloir lui transférer du trafic de production. Vous pouvez régler l'`scale` pour les deux ensembles de tâches sur `100`, et une fois prêt à transférer tout le trafic de production sur `tasksetB`, vous pouvez mettre à jour l'`scale` de `tasksetA` sur `0` pour le diminuer. # CodeDeploy déploiements bleu/vert pour Amazon ECS Nous vous recommandons d'utiliser le blue/green déploiement Amazon ECS. Pour de plus amples informations, veuillez consulter [Création d'un blue/green déploiement Amazon ECS](deploy-blue-green-service.md). Le type de déploiement *bleu/vert* utilise le modèle de blue/green déploiement contrôlé par. CodeDeploy Ce type de déploiement permet de vérifier un nouveau déploiement d'un service avant d'y envoyer du trafic de production. Pour plus d'informations, consultez le [contenu](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) du *guide CodeDeploy de l'AWS CodeDeploy utilisateur*. Valider l'état d'un service Amazon ECS avant le déploiement Le trafic peut être modifié de trois manières au cours d'un blue/green déploiement : + **Canary** : le trafic est transféré en deux incréments. Vous pouvez choisir parmi les options canary prédéfinies qui définissent le pourcentage de trafic déplacé vers l'ensemble de tâches mises à jour dans le premier incrément, et l'intervalle (en minutes) avant que le trafic restant soit déplacé dans le second incrément. + **Linéaire** : le trafic est transféré en incréments égaux, avec un nombre de minutes égal entre chaque incrément. Vous pouvez choisir parmi les options linéaires prédéfinies qui définissent le pourcentage de trafic déplacé pour chaque incrément et le nombre de minutes entre chaque incrément. + **R ll-at-once** — Tout le trafic est transféré de l'ensemble de tâches d'origine à l'ensemble de tâches mis à jour en une seule fois. Les composants suivants sont utilisés par Amazon ECS lorsqu'un service utilise le type de blue/green déploiement : CodeDeploy **CodeDeploy application** Une collection de CodeDeploy ressources. Comprend un ou plusieurs groupes de déploiement. **CodeDeploy groupe de déploiement** Paramètres de déploiement. Regroupe les éléments suivants : + Cluster et service Amazon ECS + Groupe cible de l’équilibreur de charge et informations sur l’écouteur + Stratégie de restauration du déploiement + Paramètres de réacheminement du trafic + Paramètres d’arrêt de la révision initiale + Configuration de déploiement + CloudWatch configuration des alarmes pouvant être configurée pour arrêter les déploiements + Paramètres SNS ou CloudWatch Events pour les notifications Pour de plus amples informations, veuillez consulter [Utilisation des groupes de déploiement dans CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) dans le *Guide de l'utilisateur AWS CodeDeploy *. **CodeDeploy configuration de déploiement** Spécifie comment CodeDeploy achemine le trafic de production vers votre ensemble de tâches de remplacement lors d'un déploiement. Les configurations de déploiement linéaire et canary prédéfinies suivantes sont disponibles. Vous pouvez également créer des déploiements canary et linéaires personnalisés. Pour obtenir de plus amples informations, consultez [Utilisation des configurations de déploiement](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) dans le *Guide de l'utilisateur AWS CodeDeploy *. + **CodeDeployDefault. ECSAllAtOnce**: Transfère immédiatement tout le trafic vers le conteneur Amazon ECS mis à jour + **CodeDeployDefault. ECSLinear10PercentEvery1 minute** : déplace 10 % du trafic toutes les minutes jusqu'à ce que tout le trafic soit transféré. + **CodeDeployDefault. ECSLinear10PercentEvery3 minutes** : déplace 10 % du trafic toutes les 3 minutes jusqu'à ce que tout le trafic soit transféré. + **CodeDeployDefault. ECSCanary10Pourcentage de 5 minutes** : déplace 10 % du trafic dès le premier incrément. Les 90 % restants sont déployés cinq minutes plus tard. + **CodeDeployDefault. ECSCanary10Pourcentage de 15 minutes** : déplace 10 % du trafic dès le premier incrément. Les 90 % restants sont déployés 15 minutes plus tard. **Révision** Une révision est le fichier de spécification de CodeDeploy l'application (AppSpec fichier). Dans le AppSpec fichier, vous spécifiez l'ARN complet de la définition de tâche ainsi que le conteneur et le port de votre ensemble de tâches de remplacement où le trafic doit être acheminé lors de la création d'un nouveau déploiement. Le nom du conteneur doit être un des noms de conteneur référencés dans votre définition de tâche. Si la configuration réseau ou la version de plate-forme a été mise à jour dans la définition du service, vous devez également spécifier ces détails dans le AppSpec fichier. Vous pouvez également spécifier les fonctions Lambda à exécuter au cours des événements de cycle de vie du déploiement. Les fonctions Lambda vous permettent d'exécuter des tests et de renvoyer des métriques pendant le déploiement. Pour plus d'informations, consultez la section [Référence des AppSpec fichiers](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file.html) dans le *guide de AWS CodeDeploy l'utilisateur*. ## Considérations Tenez compte des points suivants lorsque vous utilisez le type de blue/green déploiement : + Lorsqu'un service Amazon ECS utilisant le type de blue/green déploiement est initialement créé, un ensemble de tâches Amazon ECS est créé. + Vous devez configurer le service pour utiliser un équilibreur de charge Application Load Balancer ou un Network Load Balancer. Les exigences de l'équilibreur de charge sont les suivantes : + Vous devez ajouter un port d'écoute de production à l'équilibreur de charge, utilisé pour acheminer le trafic de production. + Vous pouvez également ajouter à l'équilibreur de charge un port d'écoute de test, utilisé pour acheminer le trafic de test. Si vous spécifiez un écouteur de test, votre trafic de test est CodeDeploy acheminé vers l'ensemble de tâches de remplacement lors d'un déploiement. + Les ports d'écoute de production et de test doivent appartenir au même équilibreur de charge. + Vous devez définir un groupe cible pour l'équilibreur de charge. Le groupe cible achemine le trafic vers la tâche initiale dans un service via le port d'écoute de production. + Lorsqu'un Network Load Balancer est utilisé, seule la configuration de déploiement `CodeDeployDefault.ECSAllAtOnce` est prise en charge. + Pour les services configurés pour utiliser Service Auto Scaling et le type de déploiement bleu/vert, la scalabilité automatique n'est pas bloquée pendant un déploiement, mais le déploiement peut échouer dans certaines circonstances. Ce comportement est décrit plus en détail ci-dessous. + Si un service évolue et qu'un déploiement démarre, l'ensemble de tâches vertes est créé et CodeDeploy attendra jusqu'à une heure pour qu'il atteigne un état stable et ne transférera aucun trafic tant que ce n'est pas le cas. + Si un service est en cours de blue/green déploiement et qu'un événement de dimensionnement se produit, le trafic continuera de changer pendant 5 minutes. Si le service n'atteint pas son état stable dans les 5 minutes, il CodeDeploy arrêtera le déploiement et le marquera comme un échec. + Les tâches qui utilisent Fargate ou les types de contrôleur de déploiement `CODE_DEPLOY` ne prennent pas en charge la stratégie de planification `DAEMON`. + Lorsque vous créez initialement une CodeDeploy application et un groupe de déploiement, vous devez spécifier les éléments suivants : + Vous devez définir deux groupes cibles pour l'équilibreur de charge. L'un d'eux doit être le groupe cible initial défini pour l'équilibreur de charge lors de la création du service Amazon ECS service. La seule exigence relative au second groupe cible est qu'il ne peut pas être associé à un autre équilibreur de charge que celui utilisé par le service. + Lorsque vous créez un CodeDeploy déploiement pour un service Amazon ECS, CodeDeploy un ensemble de *tâches de remplacement (ou ensemble* de *tâches vertes) est créé* dans le déploiement. Si vous avez ajouté un écouteur de test à l'équilibreur de charge, votre trafic de test est CodeDeploy acheminé vers l'ensemble de tâches de remplacement. Cela indique le moment où vous pouvez exécuter les tests de validation. Ensuite, CodeDeploy réachemine le trafic de production depuis l'ensemble de tâches initial vers l'ensemble des tâches de remplacement en fonction des paramètres de redirection du trafic définis pour le groupe de déploiement. ## Autorisations IAM requises Blue/green deployments are made possible by a combination of the Amazon ECS and CodeDeploy APIs. Users must have the appropriate permissions for these services before they can use Amazon ECS blue/greendéploiements dans le AWS Management Console ou avec le bloc opératoire AWS CLI . SDKs En plus des autorisations IAM standard nécessaires à la création et à la mise à jour de services, Amazon ECS exige les autorisations suivantes. Ces autorisations ont été ajoutées à la politique IAM `AmazonECS_FullAccess`. Pour de plus amples informations, veuillez consulter [Amazon ECS\$1 FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess). + `codedeploy:CreateApplication` + `codedeploy:CreateDeployment` + `codedeploy:CreateDeploymentGroup` + `codedeploy:GetApplication` + `codedeploy:GetDeployment` + `codedeploy:GetDeploymentGroup` + `codedeploy:ListApplications` + `codedeploy:ListDeploymentGroups` + `codedeploy:ListDeployments` + `codedeploy:StopDeployment` + `codedeploy:GetDeploymentTarget` + `codedeploy:ListDeploymentTargets` + `codedeploy:GetDeploymentConfig` + `codedeploy:GetApplicationRevision` + `codedeploy:RegisterApplicationRevision` + `codedeploy:BatchGetApplicationRevisions` + `codedeploy:BatchGetDeploymentGroups` + `codedeploy:BatchGetDeployments` + `codedeploy:BatchGetApplications` + `codedeploy:ListApplicationRevisions` + `codedeploy:ListDeploymentConfigs` + `codedeploy:ContinueDeployment` + `sns:ListTopics` + `cloudwatch:DescribeAlarms` + `lambda:ListFunctions` **Note** Outre les autorisations Amazon ECS standard nécessaires pour exécuter des tâches et des services, les utilisateurs doivent également disposer d'autorisations `iam:PassRole` pour pouvoir utiliser les rôles IAM dans le cadre des tâches. CodeDeploy nécessite des autorisations pour appeler Amazon ECS APIs, modifier votre Elastic Load Balancing, invoquer des fonctions Lambda et décrire les CloudWatch alarmes, ainsi que des autorisations pour modifier le nombre souhaité pour votre service en votre nom. Avant de créer un service Amazon ECS utilisant le type de blue/green déploiement, vous devez créer un rôle IAM (`ecsCodeDeployRole`). Pour de plus amples informations, veuillez consulter [Rôle CodeDeploy IAM d'Amazon ECS](codedeploy_IAM_role.md). # Migrer les CodeDeploy blue/green deployments to Amazon ECS blue/green déploiements CodeDeploy blue/green and Amazon ECS blue/greenles déploiements fournissent des fonctionnalités similaires, mais la façon dont vous les configurez et les gérez diffère. ## CodeDeploy aperçu du déploiement bleu/vert Lorsque vous créez un service Amazon ECS à l'aide de CodeDeploy, vous : 1. créez un équilibreur de charge avec un écouteur de production et (éventuellement) un écouteur de test. Chaque écouteur est configuré avec une seule règle (par défaut) qui achemine tout le trafic vers un seul groupe cible (le groupe cible principal) ; 1. créez un service Amazon ECS, configuré pour utiliser l’écouteur et le groupe cible, avec `deploymentController` type défini sur `CODE_DEPLOY`. La création d’un service entraîne la création d’un jeu de tâches (bleu) enregistré auprès du groupe cible spécifié ; 1. Créez un groupe de CodeDeploy déploiement (dans le cadre d'une CodeDeploy application) et configurez-le avec les détails du cluster Amazon ECS, le nom du service, les écouteurs d'équilibrage de charge, deux groupes cibles (le groupe cible principal utilisé dans la règle d'écoute de production et un groupe cible secondaire à utiliser pour les tâches de remplacement), un rôle de service (pour accorder des CodeDeploy autorisations pour manipuler les ressources Amazon ECS et Elastic Load Balancing) et divers paramètres qui contrôlent le comportement de déploiement. Avec CodeDeploy, les nouvelles versions d'un service sont déployées à l'aide `CreateDeployment()` du nom de l' CodeDeploy application, du nom du groupe de déploiement et d'un AppSpec fichier fournissant les détails de la nouvelle révision et des hooks de cycle de vie facultatifs. Le CodeDeploy déploiement crée un ensemble de tâches de remplacement (vert) et enregistre ses tâches auprès du groupe cible secondaire. Lorsque celui-ci est opérationnel, il est disponible pour les tests (facultatif) et pour la production. Dans les deux cas, le réacheminement est réalisé en modifiant la règle d’écoute correspondante pour qu’elle pointe vers le groupe cible secondaire associé à le jeu de tâches vert. La restauration s’effectue en ramenant la règle d’écouteur de production au groupe cible principal. ## Présentation du blue/green déploiement d'Amazon ECS Dans le cas des blue/green déploiements Amazon ECS, la configuration du déploiement fait partie du service Amazon ECS lui-même : 1. Vous devez préconfigurer l’écouteur de production de l’équilibreur de charge avec une règle qui inclut deux groupes cibles avec des pondérations de 1 et 0. 1. Vous devez spécifier les ressources suivantes ou mettre à jour les ressources du service : + L’ARN de cette règle d’écoute + Les deux groupes cibles + Un rôle IAM pour autoriser Amazon ECS à appeler Elastic Load Balancing APIs + Un rôle IAM facultatif pour exécuter les fonctions Lambda + Définissez le type `deploymentController` sur `ECS` et `deploymentConfiguration.strategy` sur `BLUE_GREEN`. Cela entraîne la création d’un déploiement de service (bleu) dont les tâches sont enregistrées auprès du groupe cible principal. Avec le déploiement bleu/vert Amazon ECS, une nouvelle révision de service est créée en appelant Amazon ECS `UpdateService()`, en transmettant les détails de la nouvelle révision. Le déploiement de service crée des tâches de révision de service (vertes) et les enregistre auprès du groupe cible secondaire. Amazon ECS gère les opérations de réacheminement et de restauration en modifiant les pondérations selon la règle d’écoute. ## Principales différences de mise en œuvre Bien que les deux approches aboutissent à la création d’un jeu de tâches initial, la mise en œuvre sous-jacente est différente : + CodeDeploy utilise un ensemble de tâches, tandis qu'Amazon ECS utilise une révision de service. Les jeux de tâches Amazon ECS sont une ancienne structure qui a été remplacée par les révisions et les déploiements de service Amazon ECS. Ces derniers offrent une meilleure visibilité sur le processus de déploiement, ainsi que sur l’historique des déploiements et des révisions de service. + Avec CodeDeploy, les hooks du cycle de vie sont spécifiés dans le cadre du AppSpec fichier fourni à`CreateDeployment()`. Cela signifie que les hooks peuvent être modifiés d’un déploiement à l’autre. Avec Amazon ECS bleu/vert, les hooks sont spécifiés dans le cadre de la configuration du service, et toute mise à jour nécessite un appel à `UpdateService()`. + Amazon ECS CodeDeploy et Amazon ECS blue/green utilisent Lambda pour implémenter le hook, mais les entrées et sorties attendues sont différentes. Avec CodeDeploy, la fonction doit appeler `PutLifecycleEventHookExecutionStatus()` pour renvoyer le statut du hook, qui peut être `SUCCEEDED` ou`FAILED`. Avec Amazon ECS, la réponse Lambda est utilisée pour indiquer l’état du hook. + CodeDeploy invoque chaque hook en tant qu'appel ponctuel et s'attend à ce qu'un statut d'exécution final soit renvoyé dans un délai d'une heure. Les hooks Amazon ECS sont plus flexibles dans la mesure où ils peuvent renvoyer un indicateur `IN_PROGRESS`, qui spécifie que le hook doit être réinvoqué à plusieurs reprises jusqu’à ce qu’il aboutisse à `SUCCEEDED` ou `FAILED`. Pour de plus amples informations, veuillez consulter [Hooks de cycle de vie pour les déploiements de service Amazon ECS](deployment-lifecycle-hooks.md). ## Approches de migration Il existe trois approches principales pour migrer à partir de CodeDeploy blue/green to Amazon ECS blue/green déploiements. Chaque approche présente des caractéristiques différentes en termes de complexité, de risque, de capacité de restauration et de durée d’indisponibilité potentielle. ### Réutilisez les mêmes ressources Elastic Load Balancing que celles utilisées pour CodeDeploy Vous mettez à jour le service Amazon ECS existant pour utiliser le contrôleur de déploiement Amazon ECS avec une stratégie de blue/green déploiement au lieu du contrôleur de CodeDeploy déploiement. Tenez compte des éléments suivants lorsque vous adoptez cette approche : + La procédure de migration est plus simple, car vous mettez à jour le contrôleur de déploiement de service Amazon ECS et la stratégie de déploiement existants. + Il n’y a aucune durée d’indisponibilité lorsque la configuration et la migration sont correctement effectuées. + Une restauration nécessite que vous rétablissiez la révision de service. + Le risque est élevé, car il n’existe pas de configuration parallèle bleu/vert. Vous utilisez le même écouteur d'équilibrage de charge et les mêmes groupes cibles que ceux utilisés pour. CodeDeploy Si vous utilisez CloudFormation, consultez[Migration d'un modèle CloudFormation CodeDeploy blue/green deployment template to an Amazon ECS blue/green CloudFormation](migrate-codedeploy-to-ecs-bluegreen-cloudformation-template.md). 1. Modifiez la règle par défaut des production/test auditeurs pour inclure le groupe cible alternatif et définissez le poids du groupe cible principal sur 1 et du groupe cible alternatif sur 0. En CodeDeploy effet, les écouteurs de l'équilibreur de charge rattachés au service sont configurés avec une règle unique (par défaut) qui achemine tout le trafic vers un seul groupe cible. Pour le déploiement bleu/vert Amazon ECS, les écouteurs de l’équilibreur de charge doivent être préconfigurés avec une règle qui inclut les deux groupes cibles avec des pondérations. Le groupe cible principal doit être pondéré à 1 et le groupe cible alternatif doit être pondéré à 0. 1. Mettez à jour le service Amazon ECS existant en appelant l’API `UpdateService` et en définissant le paramètre `deploymentController` sur `ECS` et le paramètre `deploymentStrategy` sur `BLUE_GREEN`. Spécifiez le ARNs groupe cible, le groupe cible alternatif, l'écouteur de production et un écouteur de test facultatif. 1. Vérifiez que le service fonctionne comme prévu. 1. Supprimez la CodeDeploy configuration de ce service Amazon ECS car vous utilisez désormais Amazon ECS bleu/vert. ### Nouveau service avec équilibreur de charge existant Cette approche utilise la blue/green stratégie de migration. Tenez compte des éléments suivants lorsque vous adoptez cette approche : + La perturbation est minime. Elle ne se produit que pendant le changement de port Elastic Load Balancing. + Une restauration nécessite que vous rétablissiez l’échange de ports Elastic Load Balancing. + Le risque est faible, car il existe des configurations parallèles. Vous pouvez donc effectuer un test avant le changement de trafic. 1. Laissez les écouteurs, les groupes cibles et le service Amazon ECS intacts pour la CodeDeploy configuration afin de pouvoir facilement revenir à cette configuration si nécessaire. 1. Créez des groupes cibles et des écouteurs (avec des ports différents de ceux des écouteurs d’origine) sous l’équilibreur de charge existant. Créez ensuite un nouveau service Amazon ECS qui correspond au service Amazon ECS existant, sauf que vous l'utilisez `ECS` comme contrôleur de déploiement, `BLUE_GREEN` comme stratégie de déploiement, et transmettez les règles ARNs pour les nouveaux groupes cibles et les nouveaux auditeurs. 1. Vérifiez la nouvelle configuration en envoyant manuellement le trafic HTTP au service. Si tout se passe bien, échangez les ports des écouteurs d’origine et des nouveaux écouteurs pour acheminer le trafic vers la nouvelle configuration. 1. Vérifiez la nouvelle configuration et, si tout continue de fonctionner comme prévu, CodeDeploy supprimez-la. ### Nouveau service avec un équilibreur de charge Comme l'approche précédente, cette approche utilise la blue/green stratégie de migration. La principale différence est que le passage de la CodeDeploy configuration à la configuration Amazon ECS s'effectue au niveau blue/green d'une couche proxy inverse située au-dessus de l'équilibreur de charge. Des exemples d'implémentations pour la couche proxy inverse sont Route 53 et CloudFront. Cette approche convient aux clients qui disposent déjà de cette couche proxy inverse, et si toutes les communications avec le service passent par cette couche (par exemple, aucune communication directe au niveau de l’équilibreur de charge). Tenez compte des éléments suivants lorsque vous adoptez cette approche : + Elle nécessite une couche proxy inverse. + La procédure de migration est plus complexe, car vous devez mettre à jour le contrôleur de déploiement de service Amazon ECS et la stratégie de déploiement existants. + La perturbation est minime. Elle ne se produit que pendant le changement de port Elastic Load Balancing. + Pour effectuer une restauration, vous devez annuler les modifications apportées à la configuration du proxy. + Le risque est faible, car il existe des configurations parallèles. Vous pouvez donc effectuer un test avant le changement de trafic. 1. Ne modifiez pas la CodeDeploy configuration existante intacte (équilibreur de charge, écouteurs, groupes cibles, service Amazon ECS et groupe de CodeDeploy déploiement). 1. Créez un nouvel équilibreur de charge, des groupes cibles et des écouteurs configurés pour les déploiements Amazon ECS. blue/green Configurez les ressources appropriées. + Application Load Balancer : pour plus d’informations, consultez la section [Ressources d'Application Load Balancer pour les déploiements bleu/vert, linéaires et Canary](alb-resources-for-blue-green.md). + Network Load Balancer : pour plus d’informations, consultez la section [Ressources du Network Load Balancer pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](nlb-resources-for-blue-green.md). 1. Créez un service avec `ECS` en tant que contrôleur de déploiement et `BLUE_GREEN` en tant que stratégie de déploiement, en pointant vers les nouvelles ressources de l’équilibreur de charge. 1. Vérifiez la nouvelle configuration en la testant via le nouvel équilibreur de charge. 1. Mettez à jour la configuration du proxy inverse pour acheminer le trafic vers le nouvel équilibreur de charge. 1. Observez la nouvelle révision du service et, si tout continue de fonctionner comme prévu, supprimez la CodeDeploy configuration. ## Étapes suivantes Après la migration vers les blue/green déploiements Amazon ECS : + Mettez à jour vos scripts et CI/CD pipelines de déploiement pour utiliser l'`UpdateService`API Amazon ECS au lieu de l' CodeDeploy `CreateDeployment`API. + Mettez à jour votre surveillance et vos alertes pour suivre les déploiements de services Amazon ECS plutôt que les déploiements. CodeDeploy + Envisagez de mettre en œuvre des tests automatisés de votre nouveau processus de déploiement pour vous assurer qu’il fonctionne comme prévu. # Migration depuis un déploiement de CodeDeploy blue/green to an Amazon ECS blue/green service En utilisant les blue/green déploiements Amazon ECS, vous pouvez apporter et tester des modifications de service avant de les implémenter dans un environnement de production. Vous devez créer de nouveaux hooks de cycle de vie pour votre blue/green déploiement Amazon ECS. ## Conditions préalables Effectuez les opérations suivantes avant de démarrer un blue/green déploiement. 1. Remplacez le rôle Amazon ECS CodeDeploy IAM par les autorisations suivantes. + Pour plus d’informations sur les autorisations Elastic Load Balancing, consultez la section [Rôle IAM d’infrastructure Amazon ECS pour les équilibreurs de charge](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). + Pour plus d’informations sur les autorisations Lambda, consultez la section [Autorisations requises pour les fonctions Lambda dans les déploiements Amazon ECS blue/green](blue-green-permissions.md). 1. Désactivez CodeDeploy l'automatisation. Pour plus d'informations, consultez la section [Utilisation des groupes de déploiement CodeDeploy dans](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) le *Guide de CodeDeploy l'utilisateur*. 1. Vérifiez que vous disposez des informations suivantes issues de votre CodeDeploy blue/green deployment. You can reuse this information for the Amazon ECS blue/green déploiement : + Le groupe cible de production + L’écouteur de production + La règle de production + Le groupe cible de test. C’est le groupe cible de la révision de service verte. 1. Assurez-vous que les groupes cibles de votre Application Load Balancer sont correctement associés aux règles d’écoute : + Si vous n’utilisez pas d’écouteurs de test, les deux groupes cibles (production et test) doivent être associés aux règles d’écoute de production. + Si vous utilisez des écouteurs de test, un groupe cible doit être lié aux règles d’écoute de production et l’autre groupe cible doit être lié aux règles d’écoute de test. Si cette exigence n’est pas remplie, le déploiement de service échouera avec l’erreur suivante : `Service deployment rolled back because of invalid networking configuration. Both targetGroup and alternateTargetGroup must be associated with the productionListenerRule or testListenerRule.` 1. Vérifiez qu’aucun déploiement de service n’est en cours pour le service. Pour de plus amples informations, veuillez consulter [Affichage de l’historique d’un service à l’aide des déploiements de service Amazon ECS](service-deployment.md). 1. Les blue/green déploiements Amazon ECS nécessitent que votre service utilise l'une des fonctionnalités suivantes : Configurez les ressources appropriées. + Application Load Balancer : pour plus d’informations, consultez la section [Ressources d'Application Load Balancer pour les déploiements bleu/vert, linéaires et Canary](alb-resources-for-blue-green.md). + Network Load Balancer : pour plus d’informations, consultez la section [Ressources du Network Load Balancer pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](nlb-resources-for-blue-green.md). + Service Connect : pour plus d’informations, consultez la section [Ressources Service Connect pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](service-connect-blue-green.md). 1. Décidez si vous souhaitez exécuter les fonctions Lambda pendant les étapes du cycle de vie des étapes du déploiement d'Amazon ECS blue/green . + Avant augmentation horizontale + Après augmentation horizontale + Transfert du trafic test + Après transfert du trafic test + Transfert du trafic de production + Après transfert du trafic de production Créez des fonctions Lambda pour chaque étape du cycle de vie. Pour plus d’informations sur l’utilisation de Lambda, consultez la section [Créer une fonction Lambda avec la console](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function) dans le *Guide du développeur AWS Lambda *. Pour de plus amples informations sur la mise à jour du contrôleur de déploiement d’un service, consultez la section [Mise à jour des paramètres d’un service Amazon ECS](update-service-parameters.md). ## Procédure 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Sur la page **Clusters**, choisissez le cluster. La page des détails du cluster s’ouvre. 1. Depuis l’onglet **Services**, sélectionnez le service. La page des détails du service s’affiche. 1. Dans la bannière, choisissez **Mettre à jour le type de contrôleur de déploiement**. La page **Procéder à la migration du type de contrôleur de déploiement** s’affiche. 1. Développez **Nouveau**, puis spécifiez les paramètres suivants. 1. Pour **Type de contrôleur de déploiement**, choisissez **ECS**. 1. Pour **Stratégie de déploiement**, choisissez **Bleu/vert**. 1. Pour **Durée de l’intégration**, saisissez la durée pendant laquelle les révisions de service bleues et vertes s’exécutent. 1. Pour exécuter des fonctions Lambda pour une étape du cycle de vie, sous **Hooks de cycle de vie du déploiement**, procédez comme suit pour chaque fonction Lambda unique : 1. Choisissez **Ajouter**. Répétez l’opération pour chaque fonction que vous souhaitez exécuter. 1. Pour **Fonction Lambda**, saisissez le nom de la fonction. 1. Pour **Rôle**, choisissez le rôle que vous avez créé dans les prérequis avec les autorisations bleu/vert. Pour de plus amples informations, veuillez consulter [Autorisations requises pour les fonctions Lambda dans les déploiements Amazon ECS blue/green](blue-green-permissions.md). 1. Pour **Étapes du cycle de vie**, sélectionnez les étapes exécutées par la fonction Lambda. 1. (Facultatif) Pour **Détails du hook**, saisissez une paire clé-valeur fournissant des informations sur le hook. 1. Développez **Équilibrage de charge**, puis configurez les éléments suivants : 1. Pour **Rôle**, choisissez le rôle que vous avez créé dans les prérequis avec les blue/green autorisations. Pour de plus amples informations, veuillez consulter [Autorisations requises pour les fonctions Lambda dans les déploiements Amazon ECS blue/green](blue-green-permissions.md). 1. Pour **Listener**, choisissez l'écouteur de production dans votre déploiement CodeDeploy bleu/vert. 1. Pour **Règle de production**, choisissez la règle de production dans votre déploiement CodeDeploy bleu/vert. 1. Pour **Règle de test**, choisissez la règle de test de votre déploiement CodeDeploy bleu/vert. 1. Pour **Groupe cible**, choisissez le groupe cible de production dans votre déploiement CodeDeploy bleu/vert. 1. Pour **Groupe cible alternatif, choisissez le groupe** cible de test dans votre déploiement CodeDeploy bleu/vert. 1. Choisissez **Mettre à jour**. ## Étapes suivantes + Mettez à jour le service pour démarrer le déploiement. Pour de plus amples informations, veuillez consulter [Mettre à jour un service Amazon ECS](update-service-console-v2.md). + Surveillez le processus de déploiement pour vous assurer qu’il suit le schéma bleu/vert : + La révision de service verte est créée et augmentée horizontalement + Le trafic de test est acheminé vers la révision verte (si elle est configurée) + Le trafic de production est transféré vers la révision verte + Au terme de la durée de l’intégration, la révision bleue est résiliée # Migration d'un modèle CloudFormation CodeDeploy blue/green deployment template to an Amazon ECS blue/green CloudFormation Migrez un CloudFormation modèle qui utilise une stratégie CodeDeploy blue/green deployments for Amazon ECS services to one that uses the native Amazon ECS blue/green de déploiement. La migration suit l'approche « Réutilisez les mêmes ressources Elastic Load Balancing utilisées pour CodeDeploy ». Pour de plus amples informations, veuillez consulter [Migrer les CodeDeploy blue/green deployments to Amazon ECS blue/green déploiements](migrate-codedeploy-to-ecs-bluegreen.md). ## Modèle source. Ce modèle utilise la `AWS::CodeDeployBlueGreen` transformation et le `AWS::CodeDeploy::BlueGreen` hook pour implémenter blue/green des déploiements pour un service Amazon ECS. ### Source Il s'agit du CloudFormation modèle complet utilisant le déploiement CodeDeploy bleu/vert. Pour plus d'informations, consultez l'[exemple de modèle de déploiement bleu/vert](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/blue-green-template-example.html#blue-green-template-example.json) dans le guide de l'* AWS CloudFormation utilisateur* : ``` { "AWSTemplateFormatVersion": "2010-09-09", "Parameters": { "Vpc": { "Type": "AWS::EC2::VPC::Id" }, "Subnet1": { "Type": "AWS::EC2::Subnet::Id" }, "Subnet2": { "Type": "AWS::EC2::Subnet::Id" } }, "Transform": [ "AWS::CodeDeployBlueGreen" ], "Hooks": { "CodeDeployBlueGreenHook": { "Type": "AWS::CodeDeploy::BlueGreen", "Properties": { "TrafficRoutingConfig": { "Type": "TimeBasedCanary", "TimeBasedCanary": { "StepPercentage": 15, "BakeTimeMins": 5 } }, "Applications": [ { "Target": { "Type": "AWS::ECS::Service", "LogicalID": "ECSDemoService" }, "ECSAttributes": { "TaskDefinitions": [ "BlueTaskDefinition", "GreenTaskDefinition" ], "TaskSets": [ "BlueTaskSet", "GreenTaskSet" ], "TrafficRouting": { "ProdTrafficRoute": { "Type": "AWS::ElasticLoadBalancingV2::Listener", "LogicalID": "ALBListenerProdTraffic" }, "TargetGroups": [ "ALBTargetGroupBlue", "ALBTargetGroupGreen" ] } } } ] } } }, "Resources": { "ExampleSecurityGroup": { "Type": "AWS::EC2::SecurityGroup", "Properties": { "GroupDescription": "Security group for ec2 access", "VpcId": {"Ref": "Vpc"}, "SecurityGroupIngress": [ { "IpProtocol": "tcp", "FromPort": 80, "ToPort": 80, "CidrIp": "0.0.0.0/0" }, { "IpProtocol": "tcp", "FromPort": 8080, "ToPort": 8080, "CidrIp": "0.0.0.0/0" }, { "IpProtocol": "tcp", "FromPort": 22, "ToPort": 22, "CidrIp": "0.0.0.0/0" } ] } }, "ALBTargetGroupBlue": { "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", "Properties": { "HealthCheckIntervalSeconds": 5, "HealthCheckPath": "/", "HealthCheckPort": "80", "HealthCheckProtocol": "HTTP", "HealthCheckTimeoutSeconds": 2, "HealthyThresholdCount": 2, "Matcher": { "HttpCode": "200" }, "Port": 80, "Protocol": "HTTP", "Tags": [ { "Key": "Group", "Value": "Example" } ], "TargetType": "ip", "UnhealthyThresholdCount": 4, "VpcId": {"Ref": "Vpc"} } }, "ALBTargetGroupGreen": { "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", "Properties": { "HealthCheckIntervalSeconds": 5, "HealthCheckPath": "/", "HealthCheckPort": "80", "HealthCheckProtocol": "HTTP", "HealthCheckTimeoutSeconds": 2, "HealthyThresholdCount": 2, "Matcher": { "HttpCode": "200" }, "Port": 80, "Protocol": "HTTP", "Tags": [ { "Key": "Group", "Value": "Example" } ], "TargetType": "ip", "UnhealthyThresholdCount": 4, "VpcId": {"Ref": "Vpc"} } }, "ExampleALB": { "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer", "Properties": { "Scheme": "internet-facing", "SecurityGroups": [ {"Ref": "ExampleSecurityGroup"} ], "Subnets": [ {"Ref": "Subnet1"}, {"Ref": "Subnet2"} ], "Tags": [ { "Key": "Group", "Value": "Example" } ], "Type": "application", "IpAddressType": "ipv4" } }, "ALBListenerProdTraffic": { "Type": "AWS::ElasticLoadBalancingV2::Listener", "Properties": { "DefaultActions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 } ] } } ], "LoadBalancerArn": {"Ref": "ExampleALB"}, "Port": 80, "Protocol": "HTTP" } }, "ALBListenerProdRule": { "Type": "AWS::ElasticLoadBalancingV2::ListenerRule", "Properties": { "Actions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 } ] } } ], "Conditions": [ { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": [ "Mozilla" ] } } ], "ListenerArn": {"Ref": "ALBListenerProdTraffic"}, "Priority": 1 } }, "ECSTaskExecutionRole": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "ecs-tasks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }, "ManagedPolicyArns": [ "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy" ] } }, "BlueTaskDefinition": { "Type": "AWS::ECS::TaskDefinition", "Properties": { "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]}, "ContainerDefinitions": [ { "Name": "DemoApp", "Image": "nginxdemos/hello:latest", "Essential": true, "PortMappings": [ { "HostPort": 80, "Protocol": "tcp", "ContainerPort": 80 } ] } ], "RequiresCompatibilities": [ "FARGATE" ], "NetworkMode": "awsvpc", "Cpu": "256", "Memory": "512", "Family": "ecs-demo" } }, "ECSDemoCluster": { "Type": "AWS::ECS::Cluster", "Properties": {} }, "ECSDemoService": { "Type": "AWS::ECS::Service", "Properties": { "Cluster": {"Ref": "ECSDemoCluster"}, "DesiredCount": 1, "DeploymentController": { "Type": "EXTERNAL" } } }, "BlueTaskSet": { "Type": "AWS::ECS::TaskSet", "Properties": { "Cluster": {"Ref": "ECSDemoCluster"}, "LaunchType": "FARGATE", "NetworkConfiguration": { "AwsVpcConfiguration": { "AssignPublicIp": "ENABLED", "SecurityGroups": [ {"Ref": "ExampleSecurityGroup"} ], "Subnets": [ {"Ref": "Subnet1"}, {"Ref": "Subnet2"} ] } }, "PlatformVersion": "1.4.0", "Scale": { "Unit": "PERCENT", "Value": 100 }, "Service": {"Ref": "ECSDemoService"}, "TaskDefinition": {"Ref": "BlueTaskDefinition"}, "LoadBalancers": [ { "ContainerName": "DemoApp", "ContainerPort": 80, "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"} } ] } }, "PrimaryTaskSet": { "Type": "AWS::ECS::PrimaryTaskSet", "Properties": { "Cluster": {"Ref": "ECSDemoCluster"}, "Service": {"Ref": "ECSDemoService"}, "TaskSetId": {"Fn::GetAtt": ["BlueTaskSet", "Id"]} } } } } ``` ## Étapes de la migration ### Supprimer des CodeDeploy ressources spécifiques Vous n’avez plus besoin des propriétés suivantes : + La transformation `AWS::CodeDeployBlueGreen` + Le hook `CodeDeployBlueGreenHook` + Les ressources `GreenTaskDefinition` et `GreenTaskSet` (elles seront gérées par Amazon ECS) + La ressource `PrimaryTaskSet` (Amazon ECS gérera les jeux de tâches en interne) ### Reconfigurer l’écouteur de l’équilibreur de charge Modifiez la ressource `ALBListenerProdTraffic` pour utiliser une action directe avec deux groupes cibles : ``` { "DefaultActions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 }, { "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "Weight": 0 } ] } } ] } ``` ### Mise à jour des propriétés de déploiement Mettez à jour et ajoutez les éléments suivants : + Modifiez la propriété `DeploymentController` en remplaçant `EXTERNAL` par `ECS`. + Ajoutez la propriété `Strategy` et définissez-la sur BLUE\$1GREEN. + Ajoutez de la propriété `BakeTimeInMinutes`. ``` { "DeploymentConfiguration": { "MaximumPercent": 200, "MinimumHealthyPercent": 100, "DeploymentCircuitBreaker": { "Enable": true, "Rollback": true }, "BakeTimeInMinutes": 5, "Strategy": "BLUE_GREEN" } } ``` + Ajoutez la configuration de l’équilibreur de charge au service : ``` { "LoadBalancers": [ { "ContainerName": "DemoApp", "ContainerPort": 80, "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "AdvancedConfiguration": { "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "ProductionListenerRule": {"Ref": "ALBListenerProdRule"}, "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]} } } ] } ``` + Ajoutez la référence de définition de tâche au service : ``` { "TaskDefinition": {"Ref": "BlueTaskDefinition"} } ``` ### Création du ECSInfrastructure RolePolicyForLoadBalancers rôle Amazon Ajoutez un nouveau rôle IAM qui permet à Amazon ECS de gérer les ressources de l'équilibreur de charge. Pour de plus amples informations, consultez [Rôle IAM d’infrastructure Amazon ECS pour les équilibreurs de charge](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). ## Recommandations de test 1. Déployez le modèle migré dans un environnement hors production. 1. Vérifiez que le service se déploie correctement avec la configuration initiale. 1. Testez un déploiement en mettant à jour la définition de la tâche et en observant le processus de déploiement bleu/vert. 1. Vérifiez que le trafic est correctement transféré entre les déploiements bleu et vert. 1. Testez la fonctionnalité de restauration en forçant un échec de déploiement. ## Modèle après migration ### Modèle final Voici le CloudFormation modèle complet utilisant un blue/green déploiement Amazon ECS : ``` { "AWSTemplateFormatVersion": "2010-09-09", "Parameters": { "Vpc": { "Type": "AWS::EC2::VPC::Id" }, "Subnet1": { "Type": "AWS::EC2::Subnet::Id" }, "Subnet2": { "Type": "AWS::EC2::Subnet::Id" } }, "Resources": { "ExampleSecurityGroup": { "Type": "AWS::EC2::SecurityGroup", "Properties": { "GroupDescription": "Security group for ec2 access", "VpcId": {"Ref": "Vpc"}, "SecurityGroupIngress": [ { "IpProtocol": "tcp", "FromPort": 80, "ToPort": 80, "CidrIp": "0.0.0.0/0" }, { "IpProtocol": "tcp", "FromPort": 8080, "ToPort": 8080, "CidrIp": "0.0.0.0/0" }, { "IpProtocol": "tcp", "FromPort": 22, "ToPort": 22, "CidrIp": "0.0.0.0/0" } ] } }, "ALBTargetGroupBlue": { "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", "Properties": { "HealthCheckIntervalSeconds": 5, "HealthCheckPath": "/", "HealthCheckPort": "80", "HealthCheckProtocol": "HTTP", "HealthCheckTimeoutSeconds": 2, "HealthyThresholdCount": 2, "Matcher": { "HttpCode": "200" }, "Port": 80, "Protocol": "HTTP", "Tags": [ { "Key": "Group", "Value": "Example" } ], "TargetType": "ip", "UnhealthyThresholdCount": 4, "VpcId": {"Ref": "Vpc"} } }, "ALBTargetGroupGreen": { "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", "Properties": { "HealthCheckIntervalSeconds": 5, "HealthCheckPath": "/", "HealthCheckPort": "80", "HealthCheckProtocol": "HTTP", "HealthCheckTimeoutSeconds": 2, "HealthyThresholdCount": 2, "Matcher": { "HttpCode": "200" }, "Port": 80, "Protocol": "HTTP", "Tags": [ { "Key": "Group", "Value": "Example" } ], "TargetType": "ip", "UnhealthyThresholdCount": 4, "VpcId": {"Ref": "Vpc"} } }, "ExampleALB": { "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer", "Properties": { "Scheme": "internet-facing", "SecurityGroups": [ {"Ref": "ExampleSecurityGroup"} ], "Subnets": [ {"Ref": "Subnet1"}, {"Ref": "Subnet2"} ], "Tags": [ { "Key": "Group", "Value": "Example" } ], "Type": "application", "IpAddressType": "ipv4" } }, "ALBListenerProdTraffic": { "Type": "AWS::ElasticLoadBalancingV2::Listener", "Properties": { "DefaultActions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 }, { "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "Weight": 0 } ] } } ], "LoadBalancerArn": {"Ref": "ExampleALB"}, "Port": 80, "Protocol": "HTTP" } }, "ALBListenerProdRule": { "Type": "AWS::ElasticLoadBalancingV2::ListenerRule", "Properties": { "Actions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 }, { "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "Weight": 0 } ] } } ], "Conditions": [ { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": [ "Mozilla" ] } } ], "ListenerArn": {"Ref": "ALBListenerProdTraffic"}, "Priority": 1 } }, "ECSTaskExecutionRole": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "ecs-tasks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }, "ManagedPolicyArns": [ "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy" ] } }, "ECSInfrastructureRoleForLoadBalancers": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAccessToECSForInfrastructureManagement", "Effect": "Allow", "Principal": { "Service": "ecs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }, "ManagedPolicyArns": [ "arn:aws:iam::aws:policy/AmazonECSInfrastructureRolePolicyForLoadBalancers" ] } }, "BlueTaskDefinition": { "Type": "AWS::ECS::TaskDefinition", "Properties": { "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]}, "ContainerDefinitions": [ { "Name": "DemoApp", "Image": "nginxdemos/hello:latest", "Essential": true, "PortMappings": [ { "HostPort": 80, "Protocol": "tcp", "ContainerPort": 80 } ] } ], "RequiresCompatibilities": [ "FARGATE" ], "NetworkMode": "awsvpc", "Cpu": "256", "Memory": "512", "Family": "ecs-demo" } }, "ECSDemoCluster": { "Type": "AWS::ECS::Cluster", "Properties": {} }, "ECSDemoService": { "Type": "AWS::ECS::Service", "Properties": { "Cluster": {"Ref": "ECSDemoCluster"}, "DesiredCount": 1, "DeploymentController": { "Type": "ECS" }, "DeploymentConfiguration": { "MaximumPercent": 200, "MinimumHealthyPercent": 100, "DeploymentCircuitBreaker": { "Enable": true, "Rollback": true }, "BakeTimeInMinutes": 5, "Strategy": "BLUE_GREEN" }, "NetworkConfiguration": { "AwsvpcConfiguration": { "AssignPublicIp": "ENABLED", "SecurityGroups": [ {"Ref": "ExampleSecurityGroup"} ], "Subnets": [ {"Ref": "Subnet1"}, {"Ref": "Subnet2"} ] } }, "LaunchType": "FARGATE", "PlatformVersion": "1.4.0", "TaskDefinition": {"Ref": "BlueTaskDefinition"}, "LoadBalancers": [ { "ContainerName": "DemoApp", "ContainerPort": 80, "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "AdvancedConfiguration": { "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "ProductionListenerRule": {"Ref": "ALBListenerProdRule"}, "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]} } } ] } } } } ``` # Migration d'un service de mise à jour continue CodeDeploy bleu/vert vers un déploiement de service de mise à jour continue Amazon ECS Vous pouvez migrer vos déploiements de services d'un déploiement CodeDeploy bleu/vert vers un déploiement de mise à jour continue Amazon ECS. Cela vous permet de passer de la CodeDeploy dépendance à l'utilisation d'un déploiement intégré. Le planificateur de service Amazon ECS remplace les tâches en cours d’exécution par de nouvelles tâches. Le nombre de tâches ajoutées au service ou supprimées du service par Amazon ECS lors d'une mise à jour propagée est contrôlé par la configuration de déploiement du service. ## Conditions préalables Effectuez les opérations suivantes avant de démarrer un blue/green déploiement. 1. Vous n'avez plus besoin du rôle CodeDeploy IAM Amazon ECS. 1. Désactivez CodeDeploy l'automatisation. Pour plus d'informations, consultez la section [Utilisation des groupes de déploiement CodeDeploy dans](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) le *Guide de CodeDeploy l'utilisateur*. 1. Vérifiez qu’aucun déploiement de service n’est en cours pour le service. Pour de plus amples informations, veuillez consulter [Affichage de l’historique d’un service à l’aide des déploiements de service Amazon ECS](service-deployment.md). Pour de plus amples informations sur la mise à jour du contrôleur de déploiement d’un service, consultez la section [Mise à jour des paramètres d’un service Amazon ECS](update-service-parameters.md). ## Procédure 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Sur la page **Clusters**, choisissez le cluster. La page des détails du cluster s’ouvre. 1. Depuis l’onglet **Services**, sélectionnez le service. La page des détails du service s’affiche. 1. Dans la bannière, choisissez **Migrer**. La page **Mettre à jour la configuration du déploiement** s’affiche. 1. Développez **Options de déploiement**, puis spécifiez les paramètres suivants. 1. Pour **Type de contrôleur de déploiement**, choisissez **ECS**. 1. Pour **Stratégie de déploiement**, choisissez **Mise à jour propagée**. 1. Pour **Min running tasks** (Minimum de tâches en cours d'exécution), saisissez la limite inférieure pour le nombre de tâches du service qui doivent rester à l'état `RUNNING` lors d'un déploiement, en tant que pourcentage de nombre souhaité de tâches (arrondi au nombre entier supérieur le plus proche). Pour plus d'informations, consultez [Deployment configuration](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-deploymentconfiguration) (Configuration de déploiement). 1. Pour **Max running tasks** (Maximum de tâches en cours d'exécution), saisissez la limite supérieure pour le nombre de tâches du service qui peuvent rester à l'état `RUNNING` ou `PENDING` lors d'un déploiement, en tant que pourcentage de nombre souhaité de tâches (arrondi au nombre entier inférieur le plus proche). 1. Développez **Équilibrage de charge**, puis configurez les éléments suivants : 1. Pour **Rôle**, choisissez le rôle que vous avez créé dans les prérequis avec les blue/green autorisations. Pour de plus amples informations, veuillez consulter [Autorisations requises pour les fonctions Lambda dans les déploiements Amazon ECS blue/green](blue-green-permissions.md). 1. Pour **Listener**, choisissez l'écouteur de production dans votre déploiement CodeDeploy bleu/vert. 1. Pour **Groupe cible**, choisissez le groupe cible de production dans votre déploiement CodeDeploy bleu/vert. 1. Choisissez **Mettre à jour**. ## Étapes suivantes Vous devez mettre le service à jour pour que la modification prenne effet. Pour de plus amples informations, veuillez consulter [Mettre à jour un service Amazon ECS](update-service-console-v2.md). # Mise à jour de la stratégie de déploiement d’Amazon ECS Amazon ECS prend en charge plusieurs stratégies de déploiement pour mettre à jour vos services. Vous pouvez passer d’une stratégie à l’autre en fonction des exigences de votre application. Cette rubrique explique comment migrer entre des déploiements progressifs et des blue/green déploiements. ## Présentation des stratégies de déploiement d’Amazon ECS Avant de passer d’une stratégie de déploiement à une autre, il est important de comprendre le fonctionnement de chaque stratégie et ses principales différences : **Déploiements progressifs** Dans le cadre d’un déploiement propagé, Amazon ECS remplace la version en cours d’exécution de votre application par une nouvelle version. Le planificateur de service utilise les paramètres de pourcentage minimal et maximal de bon fonctionnement pour déterminer la stratégie de déploiement. Les déploiements propagés sont plus simples à configurer, mais offrent moins de contrôle sur le processus de déploiement et le routage du trafic. **Déploiements bleu/vert** Lors d'un blue/green déploiement, Amazon ECS crée une nouvelle version de votre service (vert) à côté de la version existante (bleu). Cela vous permet de vérifier la nouvelle version avant d’y acheminer le trafic de production. Les déploiements bleu/vert permettent de mieux contrôler le processus de déploiement, notamment les fonctionnalités de transfert du trafic, de test et de restauration. ## Bonnes pratiques Suivez ces pratiques exemplaires lors de la migration entre les stratégies de déploiement : + **Test dans un environnement hors production** : testez toujours la mise à jour dans un environnement hors production avant d’appliquer des modifications aux services de production. + **Planification de la restauration** : établissez un plan de restauration au cas où la mise à jour ne fonctionnerait pas comme prévu. + **Surveillance pendant la transition** : surveillez de près votre service pendant et après la migration pour vous assurer qu’il continue de fonctionner correctement. + **Mise à jour de la documentation** : mettez à jour votre documentation de déploiement pour refléter la nouvelle stratégie de déploiement. + **Considération de l’impact sur le trafic** : déterminez l’impact de la mise à jour sur le trafic vers votre service et planifiez en conséquence. # Mise à jour de la stratégie de déploiement, de la mise à jour propagée à Amazon ECS bleu/vert Vous pouvez passer d'un déploiement de mises à jour continues à un blue/green déploiement Amazon ECS lorsque vous souhaitez apporter et tester des modifications de service avant de les implémenter dans un environnement de production. ## Conditions préalables Avant de faire passer votre service du blue/green déploiement aux déploiements, assurez-vous de disposer des éléments suivants : + Attendez que tous les déploiements en cours soient terminés. + Un service Amazon ECS existant utilisant la stratégie de déploiement propagé. + Si plusieurs révisions de service reçoivent du trafic, Amazon ECS tente de consolider le trafic vers une seule révision pendant la migration. En cas d’échec, vous devrez peut-être mettre à jour manuellement votre service pour utiliser une seule révision avant de procéder à la migration. + Configurez les autorisations appropriées. + Pour plus d’informations sur les autorisations Elastic Load Balancing, consultez la section [Rôle IAM d’infrastructure Amazon ECS pour les équilibreurs de charge](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). + Pour plus d’informations sur les autorisations Lambda, consultez la section [Autorisations requises pour les fonctions Lambda dans les déploiements Amazon ECS blue/green](blue-green-permissions.md). + Selon la configuration, vous devez effectuer l’une des actions suivantes : + Si votre service utilise Elastic Load Balancing, mettez-le à jour avec la nouvelle « AdvancedConfiguration » et lancez un déploiement propagé. + Si votre service utilise Service Connect, mettez-le à jour et lancez un déploiement propagé. + Si votre service utilise à la fois Elastic Load Balancing et Service Connect, effectuez les deux étapes ci-dessus (vous pouvez utiliser une seule UpdateService requête). + Si votre service n’utilise aucune des solutions ci-dessus, aucune opération supplémentaire n’est nécessaire. + Les blue/green déploiements Amazon ECS nécessitent que votre service utilise l'une des fonctionnalités suivantes. Configurez les ressources appropriées. + Application Load Balancer : pour plus d’informations, consultez la section [Ressources d'Application Load Balancer pour les déploiements bleu/vert, linéaires et Canary](alb-resources-for-blue-green.md). + Network Load Balancer : pour plus d’informations, consultez la section [Ressources du Network Load Balancer pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](nlb-resources-for-blue-green.md). + Service Connect : pour plus d’informations, consultez la section [Ressources Service Connect pour les déploiements Amazon ECS bleu/vert, linéaire et Canary](service-connect-blue-green.md). ## Procédure 1. Ouvrez la console Amazon ECS à l’adresse [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Dans le panneau de navigation, choisissez **Clusters**. 1. Sur la page **Clusters**, sélectionnez le cluster qui contient le service pour lequel vous souhaitez procéder à la migration. La page des détails du cluster s’affiche. 1. Sur la page **Détails du cluster**, choisissez l’onglet **Services**, 1. Choisissez le type de rôle Service , puis **Mettre à jour**. La page de mise à jour du service s’affiche 1. Développez **Options de déploiement**, puis procédez comme suit : 1. Pour **Stratégie de déploiement**, choisissez **Bleu/vert**. 1. Configurez les paramètres de blue/green déploiement : 1. Pour **Durée de l’intégration**, saisissez le nombre de minutes pendant lesquelles les révisions de service bleues et vertes seront exécutées simultanément avant que la révision bleue ne soit résiliée. Cela laisse le temps de procéder à des vérifications et à des tests. 1. (Facultatif) Configurez les fonctions Lambda pour qu’elles s’exécutent à des étapes spécifiques du déploiement. Dans **Hooks de cycle de vie du déploiement**, configurez les fonctions Lambda pour les étapes suivantes : + **Avant augmentation horizontale** : s’exécute avant d’augmenter verticalement la révision de service verte + **Après augmentation horizontale** : s’exécute après avoir augmenté verticalement la révision de service verte + **Transfert du trafic test** : s’exécute pendant le routage du trafic test vers la révision verte du service + **Après transfert du trafic test** : s’exécute après que le trafic test a été acheminé vers la révision de service verte + **Transfert du trafic de production** : s’exécute pendant le routage du trafic de production vers la révision de service vert + **Après transfert du trafic de production** : s’exécute après que le trafic de production a été acheminé vers la révision de service vert Pour ajouter un hook de cycle de vie 1. Choisissez **Ajouter**. 1. Pour **Fonction Lambda**, saisissez le nom ou l’ARN de la fonction. 1. Pour **Rôle**, choisissez le rôle IAM qui dispose de l’autorisation d’appeler la fonction Lambda. 1. Pour **Étapes du cycle de vie**, sélectionnez les étapes dans lesquelles la fonction Lambda doit être exécutée. 1. Facultatif : pour **Détails du hook**, saisissez des paires clé-valeur pour fournir des informations supplémentaires au hook. 1. Configurez les paramètres de l’équilibreur de charge : 1. Sous **Équilibrage de charge**, vérifiez que votre service est configuré pour utiliser un équilibreur de charge. 1. Pour **Groupe cible**, choisissez le groupe cible principal pour votre environnement de production (bleu). 1. Pour **Groupe cible alternatif**, choisissez le groupe cible pour votre environnement de test (vert). 1. Pour **Règle d’écoute de production**, choisissez la règle d’écoute pour acheminer le trafic de production. 1. Facultatif : pour **Règle d’écoute de test**, choisissez une règle d’écoute pour acheminer le trafic de test vers votre environnement vert. 1. Pour **Rôle**, choisissez le rôle IAM qui permet à Amazon ECS de gérer votre équilibreur de charge. 1. Examinez vos modifications, puis choisissez **Mettre à jour**. ## Étapes suivantes + Mettez à jour le service pour démarrer le déploiement. Pour de plus amples informations, veuillez consulter [Mettre à jour un service Amazon ECS](update-service-console-v2.md). + Surveillez le processus de déploiement pour vous assurer qu'il suit le blue/green modèle : + La révision de service verte est créée et augmentée horizontalement + Le trafic de test est acheminé vers la révision verte (si elle est configurée) + Le trafic de production est transféré vers la révision verte + Au terme de la durée de l’intégration, la révision bleue est résiliée # Mise à jour de la stratégie de déploiement depuis Amazon ECS blue/green jusqu'à la mise à jour continue Vous pouvez migrer un blue/green déploiement vers un déploiement de mise à jour continue. Gardez les considérations suivantes à l’esprit lors de la migration vers des déploiements propagés : + **Gestion du trafic** : avec les déploiements propagés, les nouvelles tâches commencent à recevoir du trafic dès qu’elles passent les surveillances de l’état. Il n'y a pas de phase de test distincte comme pour les blue/green déploiements. + **Efficacité des ressources** : les déploiements progressifs utilisent généralement moins de ressources que blue/green les déploiements car ils remplacent les tâches progressivement au lieu de créer un environnement totalement dupliqué. + **Complexité du rollback** : les déploiements progressifs compliquent les rollbacks par rapport aux déploiements. blue/green Si vous devez revenir en arrière, vous devez lancer un nouveau déploiement avec la définition de tâche précédente. + **Vitesse de déploiement** : les déploiements progressifs peuvent prendre plus de temps que blue/green les déploiements, en particulier pour les services comportant de nombreuses tâches. + **Configuration de l’équilibreur de charge** : votre configuration d’équilibreur de charge existante continuera de fonctionner avec des déploiements propagés, mais le comportement de transfert du trafic sera différent. ## Conditions préalables Avant de migrer votre service blue/green vers des déploiements progressifs, assurez-vous de disposer des éléments suivants : + Un service Amazon ECS existant utilisant la stratégie blue/green de déploiement + Aucun déploiement en cours pour le service (attendez que les déploiements en cours soient terminés) + Une compréhension claire de la façon dont votre service se comportera lors de déploiements propagés **Note** Vous ne pouvez pas procéder à la migration d’un service vers un déploiement propagé s’il est en cours de déploiement. Attendez que tous les déploiements en cours soient terminés avant de continuer. ## Procédure de migration Suivez ces étapes pour migrer votre service Amazon ECS blue/green vers des déploiements progressifs : 1. Ouvrez la console Amazon ECS à l’adresse [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Dans le panneau de navigation, choisissez **Clusters**. 1. Sur la page **Clusters**, sélectionnez le cluster qui contient le service pour lequel vous souhaitez procéder à la migration. 1. Sur la page **Détails du cluster**, choisissez l’onglet **Services**, 1. Sélectionnez le service pour lequel vous souhaitez procéder à la migration, puis choisissez **Mettre à jour**. 1. Sur la page **Mettre à jour le service**, accédez à la section **Options de déploiement** et développez-la si nécessaire. 1. Pour **Stratégie de déploiement**, choisissez **Mise à jour propagée**. 1. Configurez les paramètres de déploiement propagé : 1. Pour **Pourcentage minimum sain**, saisissez une limite inférieure pour le nombre de tâches pour lesquelles votre service doit rester dans l’état `RUNNING` lors d’un déploiement. Cette valeur est exprimée en pourcentage du nombre de tâches souhaité pour le service. 1. Dans **Pourcentage maximal**, saisissez le pourcentage maximal de tâches autorisées à l’état `RUNNING` ou `PENDING` lors d’un déploiement. Cette valeur est exprimée en pourcentage du nombre de tâches souhaité pour le service. 1. Facultatif : sous **Détection des échecs de déploiement**, configurez la manière dont Amazon ECS détecte et gère les échecs de déploiement : 1. Pour activer le disjoncteur de déploiement, sélectionnez **Utiliser le disjoncteur de déploiement**. 1. Pour restaurer automatiquement les déploiements ayant échoué, choisissez **Restaurer en cas d’échec**. 1. Passez en revue vos modifications de configuration, puis choisissez **Mettre à jour** pour enregistrer vos modifications et procéder à la migration du service vers un déploiement propagé. Amazon ECS mettra à jour la configuration de votre service afin d’utiliser la stratégie de déploiement propagé. La prochaine fois que vous mettrez à jour votre service, celui-ci utilisera le processus de déploiement propagé. **Note** Lorsque vous passez d'un déploiement continu blue/green à un déploiement progressif, Amazon ECS gère la transition en : identifiant la révision de service active actuelle qui reçoit le trafic ; maintenant la configuration existante de l’équilibreur de charge, mais en modifiant la façon dont les nouveaux déploiements sont gérés ; préparant la service pour les futurs déploiements continus. ## Étapes suivantes + Mettez à jour le service pour démarrer le déploiement. Pour de plus amples informations, veuillez consulter [Mettre à jour un service Amazon ECS](update-service-console-v2.md). # Résolution des problèmes liés aux mises à jour de la stratégie de déploiement Amazon ECS Cette section fournit des solutions aux problèmes courants que vous pouvez rencontrer lors de la migration de stratégies de déploiement. ## Révisions de services ou jeux de tâches multiples Les problèmes suivants concernent le fait d’avoir plusieurs révisions de service pour un déploiement. Jeux de tâches multiples lors de la mise à jour du contrôleur de déploiement ECS *Message d’erreur* : `Updating the deployment controller is not supported when there are multiple tasksets in the service. Please ensure your service has only one taskset and try again.` *Solution* : cette erreur se produit lorsque vous tentez de modifier le type de contrôleur de déploiement d’un service comportant plusieurs jeux de tâches actifs. Pour résoudre ce problème pour le contrôleur de déploiement `CODE_DEPLOY` ou `EXTERNAL` : 1. Vérifiez les jeux de tâches actuels : ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets" ``` 1. Attendez que tous les déploiements en cours soient terminés. 1. Forcez un nouveau déploiement pour nettoyer les jeux de tâches : ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --force-new-deployment ``` 1. Si nécessaire, supprimez manuellement des jeux de tâches supplémentaires : ``` aws ecs delete-task-set --cluster your-cluster-name --service your-service-name --task-set task-set-id ``` 1. Lorsqu’il ne reste qu’un seul jeu de tâches, réessayez de mettre à jour le contrôleur de déploiement. Pour de plus amples informations, veuillez consulter [Contrôleurs et stratégies de déploiement de service Amazon ECS](ecs_service-options.md). Jeu de tâches principal manquant lors de la mise à jour du contrôleur de déploiement `ECS` *Message d’erreur* : `Updating the deployment controller requires a primary taskset in the service. Please ensure your service has a primary taskset and try again.` *Solution* : cette erreur se produit lorsque vous tentez de modifier le type de contrôleur de déploiement d’un service qui ne dispose pas d’un jeu de tâches principal. Pour résoudre ce problème : 1. Vérifiez l’état du service et les jeux de tâches. ). Si un jeu de tâches existe dans le service, il doit être marqué comme `ACTIVE`. ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets[*].[status,id] ``` S’il n’y a aucun jeu de tâches dans l’état `ACTIVE`, procédez à la migration du déploiement. Pour plus d’informations, consultez la section [Approches de migration](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/migrate-codedeploy-to-ecs-bluegreen.html#migration-paths). 1. Si aucune tâche n’est en cours d’exécution, déployez au moins une tâche en mettant à jour le service : ``` aws ecs update-service-primary-task-set --cluster your-cluster-name --service your-service-name --primary-task-set your-taskset-id ``` Cela marquera la tâche (auparavant `ACTIVE`) définie dans le service comme ayant le statut `PRIMARY`. 1. Attendez que la tâche atteigne un état d’exécution stable. Vous pouvez vérifier l’état en utilisant : ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deployments" ``` 1. Une fois que le service dispose d’un jeu de tâches principales avec des tâches en cours d’exécution, réessayez de mettre à jour le contrôleur de déploiement. Pour de plus amples informations, veuillez consulter [Contrôleurs et stratégies de déploiement de service Amazon ECS](ecs_service-options.md). ## Incompatibilité entre le type de détection des échecs de déploiement et le contrôleur de déploiement Les problèmes suivants sont liés à une incompatibilité entre le type de détection des échecs de déploiement et le contrôleur de déploiement. Disjoncteur de déploiement avec contrôleur non-ECS *Message d’erreur* : `Deployment circuit breaker feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.` *Solution* : cette erreur se produit lorsque vous tentez d’activer la fonctionnalité de disjoncteur de déploiement sur un service qui n’utilise pas le contrôleur de déploiement `ECS`. Le disjoncteur de déploiement n’est compatible qu’avec le contrôleur de déploiement `ECS`. 1. Vérifiez le contrôleur de déploiement actuel de votre service : ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController" ``` 1. Mettez à jour votre service pour utiliser le contrôleur de déploiement `ECS` : ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` 1. Une fois que le service utilise le contrôleur de déploiement `ECS`, activez le disjoncteur de déploiement : ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}" ``` Pour de plus amples informations, veuillez consulter [Détection des pannes par le disjoncteur de déploiement Amazon ECS](deployment-circuit-breaker.md). Restauration basée sur une alarme avec un contrôleur non-ECS *Message d’erreur* : `Alarm based rollback feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.` *Solution* : cette erreur se produit lors de la tentative de configuration de la restauration basée sur les alarmes sur un service qui n’utilise pas le contrôleur de déploiement `ECS`. La fonctionnalité de restauration basée sur les alarmes n’est compatible qu’avec le contrôleur de déploiement `ECS`. 1. Vérifiez le contrôleur de déploiement actuel de votre service : ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController" ``` 1. Mettez à jour votre service pour utiliser le contrôleur de déploiement `ECS` : ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` 1. Une fois que le service utilise le contrôleur de déploiement `ECS`, configurez la restauration basée sur les alarmes : ``` aws ecs update-service --cluster your-cluster-name --services your-service-name --deployment-configuration "alarms={alarmNames=[your-alarm-name],enable=true,rollback=true}" ``` Pour de plus amples informations, veuillez consulter [Comment les CloudWatch alarmes détectent les échecs de déploiement d'Amazon ECS](deployment-alarm-failure.md). ## Inadéquation entre Service Connect et le contrôleur de déploiement Les problèmes suivants sont liés à une inadéquation entre Service Connect et le contrôleur de déploiement. Contrôleur `EXTERNAL` avec Service Connect *Message d’erreur* : `The EXTERNAL deployment controller type is not supported for services using Service Connect.` *Solution* : cette erreur se produit lorsque vous tentez d’utiliser le contrôleur de déploiement `EXTERNAL` avec un service sur lequel Service Connect est activé. Le contrôleur `EXTERNAL` n’est pas compatible avec Service Connect. 1. Vérifiez si Service Connect est activé sur votre service : ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].serviceConnectConfiguration" ``` 1. Si vous devez utiliser le contrôleur de déploiement `EXTERNAL`, désactivez Service Connect en mettant à jour votre service : ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "{}" ``` 1. Sinon, si vous devez utiliser Service Connect, utilisez plutôt le contrôleur de déploiement `ECS` : ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` Pour de plus amples informations, veuillez consulter [Contrôleurs et stratégies de déploiement de service Amazon ECS](ecs_service-options.md). Service Connect avec un contrôleur non-ECS *Message d’erreur* : `Service Connect feature is only supported with ECS (rolling update) deployment controller. Update to ECS deployment controller and try again.` *Solution* : cette erreur se produit lorsque vous tentez d’activer Service Connect sur un ordinateur qui n’utilise pas le contrôleur de déploiement `ECS`. La fonctionnalité Service Connect n’est compatible qu’avec le contrôleur de déploiement `ECS`. 1. Vérifiez le contrôleur de déploiement actuel de votre service : ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController" ``` 1. Mettez à jour votre service pour utiliser le contrôleur de déploiement ECS : ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` 1. Une fois que le service utilise le contrôleur de déploiement ECS, activez Service Connect : ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "enabled=true,namespace=your-namespace" ``` Pour de plus amples informations, veuillez consulter [Contrôleurs et stratégies de déploiement de service Amazon ECS](ecs_service-options.md). ## Inadéquation entre le type de contrôleur et la stratégie de planification Les problèmes suivants concernent une inadéquation entre le type de contrôleur et la stratégie de planification. Contrôleur `CODE_DEPLOY` avec stratégie de planification `DAEMON` *Message d’erreur* : `The CODE_DEPLOY deployment controller type is not supported for services using the DAEMON scheduling strategy.` *Solution* : cette erreur se produit lorsque vous tentez d’utiliser le contrôleur de déploiement CODE\$1DEPLOY avec un service utilisant la stratégie de planification `DAEMON`. Le contrôleur `CODE_DEPLOY` n’est compatible qu’avec la stratégie de planification `REPLICA`. 1. Vérifiez la stratégie de planification actuelle de votre service : ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy" ``` 1. Si vous avez besoin de blue/green déploiements, modifiez votre service pour utiliser la stratégie de `REPLICA` planification : ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA ``` 1. Sinon, si vous devez utiliser la stratégie de planification `DAEMON`, utilisez plutôt le contrôleur de déploiement `ECS` : ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` Pour de plus amples informations, veuillez consulter [Contrôleurs et stratégies de déploiement de service Amazon ECS](ecs_service-options.md). Contrôleur EXTERNE avec stratégie de planification DÉMON *Message d’erreur* : `The EXTERNAL deployment controller type is not supported for services using the DAEMON scheduling strategy.` *Solution* : cette erreur se produit lorsque vous tentez d’utiliser le contrôleur de déploiement EXTERNE avec un service ECS utilisant la stratégie de planification DÉMON. Le contrôleur EXTERNAL n’est compatible qu’avec la stratégie de planification REPLICA. 1. Vérifiez la stratégie de planification actuelle de votre service : ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy" ``` 1. Si vous devez utiliser le contrôleur de déploiement `EXTERNAL`, modifiez votre service pour utiliser la stratégie de planification `REPLICA` : ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA ``` 1. Sinon, si vous devez utiliser la stratégie de planification `DAEMON`, utilisez plutôt le contrôleur de déploiement `ECS` : ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` Pour de plus amples informations, veuillez consulter [Contrôleurs et stratégies de déploiement de service Amazon ECS](ecs_service-options.md). Enregistrements de services avec type de lancement externe *Message d’erreur* : `Service registries are not supported for external launch type.` *Solution* : cette erreur se produit lors de la tentative de configuration de la découverte de service (registres de services) pour un service utilisant le type de lancement `EXTERNAL`. La découverte de service n’est pas compatible avec le type de lancement `EXTERNAL`. 1. Vérifiez le type de lancement actuel de votre service : ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].launchType" ``` 1. Si vous avez besoin de la découverte de service, modifiez votre service pour utiliser le type de lancement `EC2` ou `FARGATE` : ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --launch-type FARGATE ``` 1. Sinon, si vous devez utiliser le type de lancement `EXTERNAL`, supprimez la configuration du registre du service : ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --service-registries "[]" ``` Pour de plus amples informations, veuillez consulter [Contrôleurs et stratégies de déploiement de service Amazon ECS](ecs_service-options.md). ## Rétablissement d’une mise à jour du contrôleur de déploiement Si vous décidez de revenir au contrôleur de déploiement précédent, vous pouvez effectuer l’une des opérations suivantes : + Si vous l'avez utilisé CloudFormation, vous pouvez utiliser le modèle précédent pour créer une nouvelle pile. Pour plus d’informations, consultez la section [Créer une pile sous](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) dans le *Guide de l’utilisateur CloudFormation *. + Si vous avez utilisé la console Amazon ECS, ou la AWS CLI, vous pouvez mettre à jour le service. Pour de plus amples informations, veuillez consulter [Mettre à jour un service Amazon ECS](update-service-console-v2.md). Si vous utilisez la commande update-service, utilisez l’option `--deployment-controller` et définissez-la sur le contrôleur de déploiement précédent. # Affichage de l’historique d’un service à l’aide des déploiements de service Amazon ECS Les déploiements de service fournissent une vue complète de vos déploiements. Les déploiements de service fournissent les informations suivantes sur le service : + Configuration de la charge de travail actuellement déployée (révision de service source) + Configuration de la charge de travail en cours de déploiement (la révision de service cible) + Statut du déploiement + Nombre de tâches ayant échoué détectées par le disjoncteur + Les CloudWatch alarmes qui sont en alarme + Quand le déploiement de service a commencé et s’est terminé + Détails d’une restauration, le cas échéant Pour de plus amples informations sur les propriétés de déploiement de service, consultez la section [Propriétés incluses dans un déploiement de service Amazon ECS](service-deployment-property.md). Les déploiements de service sont en lecture seule et chacun possède un identifiant unique. Il existe trois étapes de déploiement de service : | Étape | Définition | États associés | | --- | --- | --- | | En attente | Un déploiement de service a été créé, mais n’a pas démarré. | PENDING | | En continu | Le déploiement de service est en cours. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/service-deployment.html) | | Terminé | Le déploiement de service est terminé (avec ou sans succès) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/service-deployment.html) | Vous utilisez les déploiements de service pour comprendre le cycle de vie de votre service et pour déterminer si des mesures doivent être prises. Par exemple, en cas de restauration, vous devrez peut-être étudier le déploiement de service et les événements du service. Vous pouvez consulter l’historique le plus récent des 90 jours des déploiements créés le 25 octobre 2024 ou après cette date à l’aide de la console, de l’API et de l’ AWS CLI. Vous pouvez arrêter un déploiement qui n’est pas terminé. Pour de plus amples informations, veuillez consulter [Arrêt de déploiements de service Amazon ECS](stop-service-deployment.md). ## Cycle de vie de déploiement de service Amazon ECS crée automatiquement un déploiement de service lorsque l’une des actions suivantes se produit : + Un utilisateur crée un service. + Un utilisateur met à jour le service et utilise l’option « Forcer un nouveau déploiement ». + Un utilisateur met à jour une ou plusieurs propriétés du service qui nécessitent un déploiement. Pendant qu’un déploiement est en cours, Amazon ECS met à jour les propriétés de déploiement de service suivantes afin de refléter la progression du déploiement de service : + L'état + Le nombre de tâches en cours Le nombre de tâches en cours indiqué dans la révision de service peut ne pas être égal au nombre réel de tâches en cours d’exécution. Ce nombre représente le nombre de tâches exécutées une fois le déploiement terminé. Par exemple, si vous avez lancé des tâches indépendamment du déploiement de service, ces tâches ne sont pas incluses dans le nombre de tâches en cours pour la révision de service. + Détection des échecs du disjoncteur : + Nombre de tâches qui n’ont pas pu démarrer + CloudWatch détection de panne d'alarme + Les alarmes actives + Informations de restauration : + L’heure de début + La raison de la restauration + L’ARN de la révision de service utilisée pour la restauration + La raison du statut Amazon ECS supprime le déploiement de service lorsque vous supprimez un service. ## États de déploiement de service Le déploiement de service démarre dans l’état `PENDING`. L’illustration suivante montre les états de déploiement de service qui peuvent se produire après l’état `PENDING` : `IN_PROGRESS`, `ROLLBACK_REQUESTED`, `SUCCESSFUL`, `STOP_REQUESTED`, `ROLLBACK_IN_PROGRESSS`, `ROLLBACK_FAILED`, `ROLLBACK_SUCCESSFUL` et `STOPPED`. ![\[Déploiement de service : états ARRÊT_DEMANDÉ, SUCCÈS et RESTAURATION_EN_COURS qui peuvent se produire après l’état EN_COURS.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/service-deployment-states.png) Les informations suivantes fournissent des informations détaillées sur les états de déploiement de service : + `PENDING` : un déploiement de service a été créé, mais n’a pas démarré L’état peut se passer à `IN_PROGRESS`, `ROLLBACK_REQUESTED`, `STOP_REQUESTED` ou `STOPPED`. + `IN_PROGRESS` : le déploiement de service est en cours. L’état peut passer à `SUCCESSFUL`, `STOP_REQUESTED`, `ROLLBACK_REQUESTED`, `ROLLBACK_IN_PROGRESS` et `STOPPED`. + `STOP_REQUESTED` : l’état du déploiement de service passe à `STOP_REQUESTED` lorsque l’une des situations suivantes se produit : + Un utilisateur lance le déploiement d’un nouveau service. + L’option de restauration n’est pas utilisée pour le mécanisme de détection des défaillances (disjoncteur ou alarme) et le service n’atteint pas l’état `SUCCESSFUL`. L’état passe à `STOPPED`. + `ROLLBACK_REQUESTED` : l’état du déploiement de service passe à `ROLLBACK_REQUESTED` lorsqu’un utilisateur requête une restauration par le biais de la console, de l’API ou de la CLI. L’état peut passer à `SUCCESSFUL`, `ROLLBACK_IN_PROGRESS` et `STOPPED`. + `SUCCESSFUL` : l’état du déploiement de service passe à `SUCCESSFUL` lorsque le déploiement de service est terminé avec succès. + `ROLLBACK_IN_PROGRESS` : l’état du déploiement de service passe à `ROLLBACK_IN_PROGRESS` lorsque l’option de restauration est utilisée pour le mécanisme de détection des échecs (disjoncteur ou basé sur les alarmes) et que le service échoue. L’état passe à `ROLLBACK_SUCCESSFUL` ou `ROLLBACK_FAILED`. # Propriétés incluses dans un déploiement de service Amazon ECS Les propriétés suivantes sont incluses dans un déploiement de service. | Propriété | Description | | --- | --- | | ARu de déploiement de service | L’ARN du déploiement de service. | | ARN du service | L’ARN du service pour ce déploiement de service. | | ARN de cluster | L’ARN du cluster qui héberge le service. | | Heure de création du déploiement de service | L’heure à laquelle le déploiement de service a été créé. | | Heure de début du déploiement de service | L’heure à laquelle le déploiement de service a commencé. | | Heure de fin du déploiement de service | L’heure à laquelle le déploiement de service s’est terminé. | | Heure d’arrêt du déploiement de service | L’heure à laquelle le déploiement de service s’est arrêté. | | Heure de mise à jour du déploiement de service | L’heure de la dernière mise à jour du déploiement de service. | | Révisions de service source | Les révisions de service actuellement en cours. Pour de plus amples informations sur les propriétés incluses, consultez la section [Propriétés incluses dans une révision de service Amazon ECS](service-revision-property.md). | | Configuration de déploiement | Les paramètres de déploiement, y compris la configuration du disjoncteur et les alarmes qui le déterminent.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/service-deployment-property.html) | | Révision du service cible | La révision de service à déployer. Une fois le déploiement terminé avec succès, la révision de service cible est la révision de service en cours. | | État du déploiement de service | L’état du déploiement de service.Les valeurs valides sont EN\$1ATTENTE, SUCCÈS, ARRETÉ, ARRÊT\$1DEMANDÉ, ARRÊT\$1EN\$1COURS, EN\$1COURS, RESTAURATION\$1EN\$1COURS, RESTAURATION\$1RÉUSSIE et RESTAURATION\$1ÉCHOUÉE. | | Informations sur les statuts de déploiement des services | Informations sur la raison pour laquelle le déploiement de service se trouve dans l’état actuel. Par exemple, le disjoncteur a détecté un échec. | | Informations de restauration | Les options de restauration utilisées par le déploiement de service en cas d’échec du déploiement. | | Options de disjoncteur de déploiement de service | Le disjoncteur qui détermine que le déploiement d’un service a échoué. | | CloudWatch alarmes pour le déploiement du service | Les CloudWatch alarmes qui déterminent l'échec du déploiement d'un service. | # Autorisations requises pour consulter les déploiements de service Amazon ECS Lorsque vous suivez la pratique exemplaire consistant à octroyer le moindre privilège, vous devez ajouter des autorisations supplémentaires afin de visualiser les déploiements de service dans la console. Vous devez avoir accès aux actions suivantes : + ListServiceDeployments + DescribeServiceDeployments + DescribeServiceRevisions Vous devez avoir accès aux ressources suivantes : + Service + Déploiements de service + Révision de service L’exemple de politique suivant contient les autorisations requises et limite les actions à un service spécifié. Remplacez `account`, `cluster-name` et `service-name` par vos propres valeurs. ------ #### [ JSON ] **** ``` { "Statement": [ { "Effect": "Allow", "Action": [ "ecs:ListServiceDeployments", "ecs:DescribeServiceDeployments", "ecs:DescribeServiceRevisions" ], "Resource": [ "arn:aws:ecs:us-east-1:123456789012:service/cluster-name/service-name", "arn:aws:ecs:us-east-1:123456789012:service-deployment/cluster-name/service-name/*", "arn:aws:ecs:us-east-1:123456789012:service-revision/cluster-name/service-name/*" ] } ] } ``` ------ # Affichage des déploiements de service Amazon ECS Vous pouvez consulter l’historique des 90 derniers jours pour les déploiements créés à partir du 25 octobre 2024. Les déploiements de service peuvent avoir l’un des états suivants : + En cours + En attente + Terminé Vous pouvez utiliser ces informations pour déterminer si vous devez mettre à jour le mode de déploiement du service ou de la révision de service. Pour de plus amples informations sur les propriétés incluses, consultez la section [Propriétés incluses dans un déploiement de service Amazon ECS](service-deployment-property.md). Avant de commencer, configurez les autorisations requises pour consulter les déploiements de service. Pour de plus amples informations, veuillez consulter [Autorisations requises pour consulter les déploiements de service Amazon ECS](service-deployment-permissions.md). ------ #### [ Amazon ECS Console ] 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Sur la page **Clusters**, choisissez le cluster. 1. Sur la page des détails du cluster, dans la section **Services**, choisissez le service. La page des détails du service s’affiche. 1. Sur la page des détails du service, choisissez **Déploiements**. 1. Choisissez le déploiement de service à afficher. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/view-service-deployment.html) La page de détails du déploiement de service s’affiche. 1. (Facultatif) Comparez les révisions de service pour voir les différences. Sous **Révisions de service**, choisissez **Comparer les révisions**, puis sélectionnez deux révisions à comparer. Les révisions du service sont affichées side-by-side avec les différences mises en évidence. ------ #### [ AWS CLI ] 1. Exécutez `list-service-deployments` pour récupérer l’ARN de déploiement de service. Remplacez les variables par vos valeurs. ``` aws ecs list-service-deployments --cluster cluster-name --service service-name ``` Notez serviceDeploymentArn le déploiement que vous souhaitez consulter. ``` { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5", "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example", "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095", "status": "SUCCESSFUL" } ] } ``` 1. Exécutez `describe-service-deployments`. Utilisez celui `serviceDeploymentArn` qui a été renvoyé par `list-service-deployments`. Remplacez les variables par vos valeurs. ``` aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 ``` ------ ## Étapes suivantes Vous pouvez afficher les détails des révisions de service lors du déploiement. Pour de plus amples informations, consultez [Affichage des détails de la révision d’Amazon ECS](view-service-revision.md). # Révisions de service Amazon ECS Une révision de service contient un enregistrement de la configuration de la charge de travail qu’Amazon ECS tente de déployer. Chaque fois que vous créez ou déployez un service, Amazon ECS crée et capture automatiquement la configuration que vous essayez de déployer dans la révision de service. Les révisions de service sont en lecture seule et possèdent des identifiants uniques. Pour de plus amples informations sur les propriétés incluses, consultez la section [Propriétés incluses dans une révision de service Amazon ECS](service-revision-property.md). Les révisions de service offrent les avantages suivants : + Lors d’un déploiement de service, vous pouvez comparer la révision de service actuellement déployée (source) avec celle en cours de déploiement (cible). + Lorsque vous utilisez l’option de restauration pour un déploiement de service, Amazon ECS restaure automatiquement le déploiement de service jusqu’à la dernière révision de service déployée avec succès. + Les révisions de service contiennent l’enregistrement de la configuration de la charge de travail dans une ressource. ## Cycle de vie de la révision de service Amazon ECS crée automatiquement une révision de service lorsque vous créez un service ou que vous mettez à jour une propriété de service qui lance un déploiement. Amazon ECS ne crée pas de révision de service pour une opération de restauration. Amazon ECS utilise la dernière révision de service réussie pour la restauration. La révision de service est immuable. Amazon ECS supprime la révision de service lorsque vous supprimez un service. Vous pouvez consulter les révisions de service créées le 25 octobre 2024 ou après cette date à l’aide de la console, de l’API et de la CLI. # Propriétés incluses dans une révision de service Amazon ECS Les propriétés suivantes sont incluses dans une révision de service. | Ressource | Description | | --- | --- | | ARN du service | ARN qui identifie le service. | | ARN de cluster | L’ARN du cluster qui héberge le service. | | ARN de définition de tâche | L’ARN de la définition de tâche utilisée pour les tâches de service. | | Enregistrements de service | Les détails des registres de service utilisés pour la découverte de service. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/service-revision-property.html) | | Fournisseurs de capacité | Les détails de la stratégie de fournisseur de capacité. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/service-revision-property.html) | | Images de conteneurs | Les détails concernant les images conteneur. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/service-revision-property.html) | | Réseaux | Configuration réseau du service. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/service-revision-property.html) | | Type de lancement | L’option de calcul utilisée pour le service. | | Propriétés spécifiques à Fargate | Lorsque vous utilisez Fargate, il s’agit d’informations sur la version de Fargate. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/service-revision-property.html) | | Volumes Amazon EBS configurés lors du déploiement | La configuration d’un volume spécifié dans la définition de tâche en tant que volume configuré au moment du lancement. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/service-revision-property.html) | | Service Connect | La configuration de Service Connect [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/service-revision-property.html) | | Équilibreur de charge de service | Les équilibreurs de charge qui acheminent le trafic de service. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/service-revision-property.html) | | Surveillance d’exécution | Indique si la surveillance d’exécution est activée. | | Date de création | La date de création de la révision de service. | | Treillis en VPC | La configuration du VPC Lattice pour la révision de service. | # Affichage des détails de la révision d’Amazon ECS Vous pouvez consulter les informations relatives aux types de révisions de service suivants qui ont été créés le 25 octobre 2024 ou après cette date : + Source : la configuration de la charge de travail actuellement déployée + Cible : la configuration de la charge de travail en cours de déploiement ------ #### [ Amazon ECS Console ] 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Sur la page **Clusters**, choisissez le cluster. 1. Sur la page des détails du cluster, dans la section **Services**, choisissez le service. La page des détails du service s’affiche. 1. Sur la page des détails du service, choisissez **Déploiements**. 1. Choisissez la révision de service à consulter. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/view-service-revision.html) ------ #### [ AWS CLI ] 1. Exécutez `describe-service-deployments` pour récupérer l’ARN de révision de service. Remplacez les variables par vos valeurs. ``` aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:account-id:service/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 ``` Notez l’`arn` des `sourceServiceRevisions` ou des `targetServiceRevisions`. ``` { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5", "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example", "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example", "updatedAt": "2024-09-10T16:49:35.572000+00:00", "sourceServiceRevision": { "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373578954", "requestedTaskCount": 0, "runningTaskCount": 0, "pendingTaskCount": 0 }, "targetServiceRevision": { "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095", "requestedTaskCount": 0, "runningTaskCount": 0, "pendingTaskCount": 0 }, "status": "IN_PROGRESS", "deploymentConfiguration": { "deploymentCircuitBreaker": { "enable": false, "rollback": false }, "maximumPercent": 200, "minimumHealthyPercent": 100 } } ], "failures": [] } ``` 1. Exécutez `describe-service-revisions`. Utilisez celui `arn` qui a été renvoyé par `describe-service-deployments`. Remplacez les variables par vos valeurs. ``` aws ecs describe-service-revisions --service-revision-arns arn:aws:ecs:region:123456789012:service-revision/cluster-name/service-name/4980306466373577095 ``` ------ # Équilibrage d’un service Amazon ECS entre les zones de disponibilité À compter du 5 septembre 2025, Amazon ECS permet le rééquilibrage des zones de disponibilité pour tous les services éligibles à cette fonctionnalité. Un service est éligible lorsque la répartition entre les zones de disponibilité est la première stratégie de placement des tâches, ou lorsqu’il n’existe aucune stratégie de placement. Pour aider vos applications à atteindre une haute disponibilité, nous vous recommandons de configurer vos services multitâches de manière à les exécuter dans plusieurs zones de disponibilité. Pour les services dont la première stratégie de placement est de répartir les zones de disponibilité, AWS faites de votre mieux pour répartir uniformément les tâches de service entre les zones de disponibilité disponibles. Toutefois, il peut arriver que le nombre de tâches exécutées dans une zone de disponibilité ne soit pas le même que dans les autres zones de disponibilité, par exemple après l’indisponibilité d’une zone de disponibilité. Pour corriger ce déséquilibre, vous pouvez activer la fonctionnalité de rééquilibrage des zones de disponibilité. Grâce au rééquilibrage des zones de disponibilité, Amazon ECS surveille en permanence la répartition des tâches entre les zones de disponibilité pour chacun de vos services. Quand Amazon ECS détecte une répartition inégale des tâches, il prend automatiquement des mesures pour rééquilibrer la charge de travail entre les zones de disponibilité. Cela implique de lancer de nouvelles tâches dans les zones de disponibilité comportant le moins de tâches et de mettre fin à des tâches dans les zones de disponibilité surchargées. Cette redistribution offre la garantie qu’aucune zone de disponibilité ne deviendra un point de défaillance, ce qui contribue à maintenir la disponibilité globale de vos applications conteneurisées. Le processus de rééquilibrage automatisé élimine la nécessité d’une intervention manuelle, réduisant ainsi le temps de reprise après un événement. Voici un aperçu du processus de rééquilibrage des zones de disponibilité : 1. Amazon ECS commence à surveiller un service une fois qu’il a atteint l’état stable et examine le nombre de tâches exécutées dans chaque zone de disponibilité. 1. Amazon ECS effectue les opérations suivantes lorsqu’il détecte un déséquilibre dans le nombre de tâches exécutées dans chaque zone de disponibilité : + Il envoie un événement de service indiquant que le rééquilibrage de la zone de disponibilité commence. + Il lance les tâches dans les zones de disponibilité ayant le plus petit nombre de tâches en cours d’exécution. + Il arrête les tâches dans les zones de disponibilité ayant le plus grand nombre de tâches en cours d’exécution. + Le planificateur attend que les tâches nouvellement lancées soient `HEALTHY` et `RUNNING` avant d’arrêter les tâches dans la zone de disponibilité surdimensionnée. + Il envoie un événement de service avec le résultat du rééquilibrage de la zone de disponibilité. ## Comment Amazon ECS détecte une répartition inégale des tâches Amazon ECS détermine un déséquilibre dans le nombre de tâches exécutées dans chaque zone de disponibilité en divisant le nombre de tâches souhaité pour le service par le nombre de zones de disponibilité configurées. Si le nombre de tâches souhaité ne se répartit pas de manière égale, Amazon ECS répartit le reste des tâches de manière égale entre les zones de disponibilité configurées. Chaque zone de disponibilité doit avoir au moins une tâche. Prenons l’exemple d’un service Amazon ECS avec un nombre souhaité de deux tâches configurées pour deux zones de disponibilité. Dans ce scénario, le nombre de tâches souhaité est réparti de manière égale. Une distribution équilibrée serait une tâche par zone de disponibilité. S’il y a deux tâches dans la zone de disponibilité 1 et aucune tâche dans la zone de disponibilité 2, Amazon ECS initie le rééquilibrage en démarrant une tâche dans la zone de disponibilité 2 avant d’arrêter une tâche dans la zone de disponibilité 1. À présent, imaginez un service Amazon ECS avec un nombre souhaité de trois tâches configurées pour deux zones de disponibilité. Dans ce scénario, le nombre de tâches souhaité ne se divise pas de manière égale. Une distribution équilibrée comporterait une tâche dans la zone de disponibilité 1 et deux tâches dans la zone de disponibilité 2, car chaque zone de disponibilité comporte au moins une tâche et le reste de la tâche est placée dans la zone de disponibilité 2. Prenons l’exemple d’un service Amazon ECS dont le nombre souhaité de cinq tâches est configuré pour trois zones de disponibilité. Dans ce scénario, le nombre de tâches souhaité ne se divise pas de manière égale. Une distribution équilibrée comporterait une tâche dans la zone de disponibilité 1 et deux tâches dans chacune des zones de disponibilité 2 et 3. Après avoir pris en compte chaque zone de disponibilité ayant une tâche chacune, les deux tâches restantes sont réparties de manière égale entre les zones de disponibilité. ## Considérations relatives à la configuration du rééquilibrage des zones de disponibilité Tenez compte des éléments suivants lorsque vous souhaitez configurer le rééquilibrage des zones de disponibilité : + Le rééquilibrage des zones de disponibilité prend en charge les fournisseurs de capacité Fargate et EC2, et est pris en charge sur les instances gérées Amazon ECS. Pour Fargate, Amazon ECS redistribuera automatiquement les tâches entre les zones de disponibilité disponibles afin de maintenir l’équilibre. Pour les fournisseurs de capacité EC2, Amazon ECS rééquilibre au mieux les tâches entre les instances de conteneur existantes, en respectant les stratégies et les contraintes de placement que vous avez définies. Toutefois, Amazon ECS ne peut pas lancer de nouvelles instances dans les zones de disponibilité sous-utilisées dans le cadre du processus de rééquilibrage, ce qui limite le rééquilibrage aux instances de conteneur existantes. + Le rééquilibrage des zones de disponibilité fonctionne dans les configurations suivantes : + Services utilisant la stratégie `Replica` + Services qui spécifient la répartition de la zone de disponibilité comme première stratégie de placement des tâches, ou qui ne spécifient pas de stratégie de placement. + Vous ne pouvez pas utiliser le rééquilibrage des zones de disponibilité avec des services répondant à l’un des critères suivants : + Utilise la stratégie `Daemon` + Utilise le type de lancement `EXTERNAL` (ECS Anywhere) + Utilise 100 % pour la valeur `maximumPercent` + Utilise un Classic Load Balancer + Utilise `attribute:ecs.availability-zone` comme contrainte de placement des tâches ## Stratégies de placement et contraintes de placement avec rééquilibrage des zones de disponibilité Les stratégies de placement déterminent la manière dont Amazon ECS sélectionne les instances de conteneur et les zones de disponibilité pour la fin du placement des tâches. Les contraintes de placement des tâches sont des règles qui déterminent si une tâche est autorisée à s’exécuter sur une instance de conteneur spécifique. Pour EC2, vous pouvez utiliser des stratégies et des contraintes de placement en même temps que le rééquilibrage des zones de disponibilité. Cependant, pour que le rééquilibrage de la zone de disponibilité fonctionne, la stratégie de placement par répartition des zones de disponibilité doit être la première stratégie spécifiée. Le rééquilibrage des zones de disponibilité est compatible avec différentes combinaisons de stratégies de placement. Par exemple, vous pouvez créer une stratégie qui distribue d’abord les tâches de manière uniforme entre les zones de disponibilité, puis regroupe les tâches par bin packing en fonction de la mémoire disponible dans chaque zone de disponibilité. Dans ce cas, le rééquilibrage de la répartition des zones de disponibilité fonctionne, car la stratégie de répartition des zones de disponibilité est spécifiée en premier. Il est important de noter que le rééquilibrage de la zone de disponibilité ne fonctionnera pas si la première stratégie dans le tableau des stratégies de placement n’est pas du type « Répartition des zones de disponibilité ». Cette exigence garantit que l’objectif principal de la distribution des tâches est de maintenir l’équilibre entre les zones de disponibilité, ce qui est crucial pour une haute disponibilité. Pour plus d’informations sur les stratégies et contraintes de placement des tâches, consultez la section [Comment Amazon ECS place les tâches sur des instances de conteneur](task-placement.md). Les stratégies et contraintes de placement des tâches ne sont pas prises en charge pour les tâches utilisant Fargate. Fargate fera de son mieux pour répartir les tâches entre les zones de disponibilité accessibles. Si le fournisseur de capacité inclut à la fois Fargate et Fargate Spot, le comportement de répartition est indépendant pour chaque fournisseur de capacité. La stratégie suivante répartit les tâches de manière uniforme entre les zones de disponibilité, puis regroupe les tâches par bin packing en fonction de la mémoire disponible dans chaque zone de disponibilité. Le rééquilibrage des zones de disponibilité est compatible avec le service, car c’est la stratégie `spread` qui prime. ``` "placementStrategy": [ { "field": "attribute:ecs.availability-zone", "type": "spread" }, { "field": "memory", "type": "binpack" } ] ``` ## Activation du rééquilibrage des zones de disponibilité Vous devez activer le rééquilibrage des zones de disponibilité pour les services nouveaux et existants. Vous pouvez activer et désactiver le rééquilibrage des zones de disponibilité à l'aide de la console APIs, AWS CLI, et CloudFormation. Le comportement par défaut de `AvailabilityZoneRebalancing` diffère entre les requêtes de création et de mise à jour : + Pour créer des requêtes de service, lorsqu’aucune valeur n’est spécifiée pour `AvailabilityZoneRebalancing`, Amazon ECS définit la valeur par défaut sur `ENABLED`. + Pour les requêtes de service de mise à jour, lorsqu’aucune valeur n’est spécifiée pour `AvailabilityZoneRebalancing`, Amazon ECS utilise par défaut la valeur de `AvailabilityZoneRebalancing` du service existant. Si le service n’a jamais défini de valeur pour `AvailabilityZoneRebalancing`, Amazon ECS la traite comme `DISABLED`. | Type de service | API | Console | INTERFACE DE LIGNE DE COMMANDE (CLI) | | --- | --- | --- | --- | | Existing | [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) | [Mettre à jour un service Amazon ECS](update-service-console-v2.md) | [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) | | Nouveau | [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html) | [Création d’un déploiement de mise à jour propagée Amazon ECS](create-service-console-v2.md) | [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) | L’exemple suivant montre comment activer le rééquilibrage des services lors de la création d’un service : ``` aws ecs create-service \ --cluster my-cluster \ --service-name my-service \ --task-definition my-task-definition:1 \ --desired-count 6 \ --availability-zone-rebalancing ENABLED ``` # Suivi du rééquilibrage des zones de disponibilité Amazon ECS Vous pouvez vérifier si le rééquilibrage des zones de disponibilité est activé pour un service dans la console ou en appelant `describe-services`. L’exemple suivant peut être utilisé pour consulter le statut à l’aide de la CLI. La réponse sera soit `ENABLED`, soit `DISABLED`. ``` aws ecs describe-services \ --services service-name \ --cluster cluster-name \ --query services[0].availabilityZoneRebalancing ``` ## Événements de service Amazon ECS envoie des événements d’action de service pour vous aider à comprendre le cycle de vie du rééquilibrage des zones de disponibilité. | Événement | Scénario | Type | En savoir plus | | --- | --- | --- | --- | | SERVICE\$1REBALANCING\$1STARTED | Amazon ECS lance une opération de rééquilibrage des zones de disponibilité | INFO | [service (*service-name*) n'est pas en équilibre avec *number-tasks* les tâches *number-tasks* dans *Availability Zone 1**Availability Zone 2*, dans et *number-tasks* dans*Availability Zone 3*. Rééquilibrage entre zones de disponibilité en cours.](service-rebalancing-event-messages-list.md#service-rebalancing-started) | | SERVICE\$1REBALANCING\$1COMPLETED | L’opération de rééquilibrage des zones de disponibilité est terminée | INFO | [service (*service-name*) est équilibré en AZ avec *number-tasks* les tâches dans*Availability Zone 1*, *number-tasks* les tâches dans *Availability Zone 2* et *number-tasks* les tâches dans*Availability Zone 3*.](service-rebalancing-event-messages-list.md#service-rebalancing-completed) | | TASKS\$1STARTED | Amazon ECS démarre avec succès les tâches dans le cadre de l’opération de rééquilibrage de la zone de disponibilité | INFO | [*service-name*a commencé *number-tasks* des tâches dans *Availability Zone* AZ Rebalance :*task-ids*.](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-started) | | TASKS\$1STOPPED | Amazon ECS arrête avec succès les tâches dans le cadre de l’opération de rééquilibrage de la zone de disponibilité | INFO | [*service-name*a cessé *number-tasks* d'exécuter des tâches en *Availability Zone* raison du rééquilibrage AZ :*task-id*.](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-stopped) | | SERVICE\$1TASK\$1PLACEMENT\$1FAILURE | Amazon ECS n’a pas pu démarrer une tâche dans le cadre de l’opération de rééquilibrage de la zone de disponibilité | ERROR | Pour EC2, consultez la section [service (*service-name*) n'est pas en mesure de placer une tâche *Availability Zone* car aucune instance de conteneur ne répond à toutes ses exigences.](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure-instance) Pour Fargate, consultez la section [service (*service-name*) ne parvient pas à placer une tâche dedans*Availability Zone*.](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure) | | TASKSET\$1SCALE\$1IN\$1FAILURE\$1BY\$1TASK\$1PROTECTION | L’opération de rééquilibrage de la zone de disponibilité est bloquée, car la protection des tâches est utilisée. | INFO | [service (*service-name*) n'a pas pu effectuer AZ Rebalance car il n'*task-set-name*a pas pu être intégré en raison de*reason*.](service-rebalancing-event-messages-list.md#service-rebalancing-task-protection-failure) | | SERVICE\$1REBALANCING\$1STOPPED | L’opération de rééquilibrage des zones de disponibilité s’est arrêtée. Amazon ECS envoie des événements supplémentaires qui fournissent davantage d’informations. | INFO | [service (*service-name*) a arrêté AZ Rebalancing.](service-rebalancing-event-messages-list.md#service-rebalancing-operation-stopped) | ## Événements de modification de l'état de la tâche Amazon ECS envoie un événement de changement d’état de tâche (`START`) pour chaque tâche qu’il démarre dans le cadre du processus de rééquilibrage. Amazon ECS envoie un événement de changement d’état de tâche (`STOPPED`) pour chaque tâche qu’il arrête dans le cadre du processus de rééquilibrage. La raison est définie sur `Availability-zone rebalancing initiated by (deployment ecs-svc/deployment-id)`. Pour plus d’informations sur les événements, consultez la section [Événements de changement d’état d’une tâche Amazon ECS](ecs_task_events.md). ## Résolution des problèmes de rééquilibrage des services Si vous rencontrez des problèmes lors du rééquilibrage des services, envisagez les étapes de résolution des problèmes suivantes : Le rééquilibrage ne démarre pas Vérifiez que : + le rééquilibrage des services est activé pour votre service ; + votre service utilise une configuration prise en charge (consultez la section [Considérations relatives à la configuration du rééquilibrage des zones de disponibilité](#service-rebalancing-configurations)) ; + votre service a atteint un état stable. Échecs de placement des tâches pendant le rééquilibrage Si vous voyez des événements `SERVICE_TASK_PLACEMENT_FAILURE` : + Pour EC2 : vérifiez si des instances de conteneur sont disponibles dans la zone de disponibilité cible. + Pour Fargate : vérifiez si des contraintes de ressources ou des quotas de service limitent le placement des tâches. + Passez en revue vos contraintes de placement des tâches pour vous assurer qu’elles n’empêchent pas une bonne répartition des tâches. Le rééquilibrage s’arrête de façon inattendue Si vous voyez des événements `SERVICE_REBALANCING_STOPPED` : + Vérifiez s’il existe une protection des tâches susceptible de bloquer l’opération. + Recherchez les déploiements de service simultanés susceptibles d’interrompre le rééquilibrage. + Consultez les événements de service pour obtenir des informations supplémentaires sur les raisons pour lesquelles le rééquilibrage a été arrêté. ## Pratiques exemplaires en matière de rééquilibrage des services Suivez ces pratiques exemplaires pour tirer le meilleur parti du rééquilibrage des services : + **Surveillez les opérations de rééquilibrage** - Configurez des CloudWatch alarmes pour surveiller les événements de service liés au rééquilibrage afin d'identifier rapidement tout problème. + **Considérer l’impact sur les performances** : sachez que les opérations de rééquilibrage peuvent augmenter temporairement l’utilisation des ressources lorsque de nouvelles tâches sont lancées avant que les anciennes ne soient arrêtées. + **Utiliser la protection des tâches de manière stratégique** : si vous avez des tâches critiques qui ne doivent pas être résiliées pendant le rééquilibrage, envisagez d’utiliser la protection des tâches. + **Planifier la capacité EC2** : pour EC2, assurez-vous de disposer de suffisamment d’instances de conteneurs dans toutes les zones de disponibilité pour permettre un rééquilibrage efficace. + **Tester le comportement du rééquilibrage** : avant de vous fier au rééquilibrage en production, testez le comportement de vos services lors des opérations de rééquilibrage dans un environnement hors production. # Utilisation de l’équilibrage de charge pour répartir le trafic des services Amazon ECS En option, votre service peut être configuré pour utiliser Elastic Load Balancing afin de répartir le trafic de manière uniforme entre les tâches de votre service. **Note** Lorsque vous utilisez des ensembles de tâches, toutes les tâches de l'ensemble doivent être configurées pour utiliser Elastic Load Balancing ou pour ne pas utiliser Elastic Load Balancing. Les services Amazon ECS hébergés sur ce site AWS Fargate prennent en charge les équilibreurs de charge d'application, les équilibreurs de charge réseau et les équilibreurs de charge de passerelle. Utilisez le tableau suivant pour savoir quel type d’équilibreur de charge utiliser. | Type d’équilibreur de charge | À utiliser dans les cas suivants | | --- | --- | | Application Load Balancer | Trafic routier HTTP/HTTPS (ou couche 7).Les équilibreurs de charge Application Load Balancer offrent plusieurs fonctions qui les rendent intéressants à utiliser avec les services Amazon ECS service : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/service-load-balancing.html) | | Network Load Balancer | Acheminer le trafic TCP ou UDP (ou couche 4). | | Passerelle équilibreur de charge | Acheminer le trafic TCP ou UDP (ou couche 4). Utiliser des appareils virtuels, tels que des pare-feu, des systèmes de détection et de prévention des intrusions et des systèmes d’inspection approfondie des paquets. | Nous vous recommandons d’utiliser des Application Load Balancer pour vos services Amazon ECS afin de pouvoir profiter des fonctions les plus récentes, sauf si votre service nécessite une fonctionnalité qui n’est fournie que par les Network Load Balancer ou les Gateway Load Balancer. Pour plus d'informations sur Elastic Load Balancing et les différences entre les types d'équilibreurs de charge, consultez le [Guide de l'utilisateur Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/). Avec votre équilibreur de charge, vous payez uniquement en fonction de votre utilisation. Pour plus d'informations, veuillez consultez [Tarification Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/pricing/). # Optimisation des paramètres de surveillance de l’état de l’équilibreur de charge pour Amazon ECS Les équilibreurs de charge n’acheminent les requêtes que vers les cibles saines dans les zones de disponibilité de l’équilibreur de charge. Chaque cible est enregistrée dans un groupe cible. Chaque nœud d’équilibreur de charge vérifie l’état de chaque cible en utilisant les paramètres de surveillance de l’état de chaque groupe cible auprès duquel la cible est enregistrée. Une fois que votre cible est enregistrée, elle doit passer avec succès une seule surveillance de l’état pour être considérée comme saine. Amazon ECS surveille l’équilibreur de charge. L’équilibreur de charge envoie régulièrement des surveillances de l’état au conteneur Amazon ECS. L’agent Amazon ECS surveille et attend que l’équilibreur de charge publie un rapport sur l’état du conteneur. Il le fait avant de considérer que le conteneur est sain. Deux paramètres de surveillance de l’état Elastic Load Balancing affectent la vitesse de déploiement : + Intervalle entre les surveillances de l’état : détermine la durée approximative, en secondes, entre les surveillances de l’état d’un conteneur individuel. Par défaut, l’équilibreur de charge vérifie toutes les 30 secondes. Ce paramètre est nommé : + `HealthCheckIntervalSeconds` dans l’API Elastic Load Balancing + **Intervalle** sur la console Amazon EC2 + Seuil de comptage de l’état sain : détermine le nombre de surveillances de l’état consécutives réussies requises avant de considérer un conteneur défectueux comme sain. Par défaut, l’équilibreur de charge nécessite cinq surveillances de l’état réussies avant de signaler que le conteneur cible est sain. Ce paramètre est nommé : + `HealthyThresholdCount` dans l’API Elastic Load Balancing + **Seuil de l’état sain** sur la console Amazon EC2 **Important :** pour les cibles nouvellement enregistrées, une seule surveillance de l’état réussie suffit pour considérer que la cible est saine, quel que soit le seuil de l’état sain défini. Le seuil de comptage de l’état sain ne s’applique que lorsqu’une cible passe d’un état défectueux à un état sain. Avec les paramètres par défaut, si une cible devient défectueuse puis se rétablit, le temps total nécessaire pour déterminer l’état d’un conteneur est de 2 minutes et 30 secondes (`30 seconds * 5 = 150 seconds`). Vous pouvez accélérer le processus de surveillance de l’état si votre service démarre et se stabilise en moins de 10 secondes. Pour accélérer le processus, réduisez l’intervalle entre les surveillances de l’état et le seuil de comptage de l’état sain. + `HealthCheckIntervalSeconds` (nom pour l’API Elastic Load Balancing) ou **Interval** (nom pour la console Amazon EC2) : 5 + `HealthyThresholdCount` (nom pour l’API Elastic Load Balancing) ou **seuil sain** (nom pour la console Amazon EC2) : 2 Avec ce paramètre, le processus de vérification de l’état prend 10 secondes, contre 2 minutes et 30 secondes par défaut. Pour plus d’informations sur les paramètres de surveillance de l’état Elastic Load Balancing, consultez la section [Surveillance de l’état de vos groupes cibles](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html) dans le *Guide de l’utilisateur Elastic Load Balancing*. # Optimisation des paramètres de drainage de la connexion de l’équilibreur de charge pour Amazon ECS Pour permettre l’optimisation, les clients maintiennent une connexion persistante au service de conteneurs. Cela permet aux requêtes ultérieures de ce client de réutiliser la connexion existante. Lorsque vous souhaitez arrêter le trafic vers un conteneur, vous devez en informer l’équilibreur de charge. L’équilibreur de charge vérifie régulièrement si le client a fermé la connexion persistante. Amazon ECS surveille l’équilibreur de charge et attend qu’il indique que la connexion persistante est fermée (la cible est dans un état `UNUSED`). La durée pendant laquelle l’équilibreur de charge attend pour faire passer la cible à l’état `UNUSED` correspond au délai d’annulation de l’enregistrement. Vous pouvez configurer le paramètre d’équilibreur de charge suivant pour accélérer vos déploiements. + `deregistration_delay.timeout_seconds` : 300 (par défaut) Lorsque vous disposez d’un service dont le temps de réponse est inférieur à une seconde, définissez le paramètre sur la valeur suivante pour que l’équilibreur de charge n’attende que cinq secondes avant de rompre la connexion entre le client et le service principal : + `deregistration_delay.timeout_seconds` : 5 **Note** Ne définissez pas la valeur sur cinq secondes lorsqu’un service comporte des requêtes de longue durée, telles que des téléchargements de fichiers lents ou des connexions de streaming. ## Réactivité à SIGTERM Amazon ECS envoie d'abord un signal d'arrêt à la tâche pour indiquer que l'application doit se terminer et s'arrêter. Ce signal peut être défini dans l'image de votre conteneur à l'aide de l'instruction STOPSIGNAL et sera défini par défaut sur SIGTERM. Amazon ECS envoie ensuite un message SIGKILL. Lorsque les applications ignorent le signal SIGTERM, le service Amazon ECS doit attendre pour envoyer le signal SIGKILL afin de terminer le processus. La durée pendant laquelle Amazon ECS attend avant d’envoyer le message SIGKILL est déterminée par l’option d’agent Amazon ECS suivante : + `ECS_CONTAINER_STOP_TIMEOUT` : 30 (par défaut) Pour plus d'informations sur le paramètre de l'agent de conteneur, consultez [Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) on GitHub. Pour accélérer le délai d’attente, définissez le paramètre de l’agent Amazon ECS sur la valeur suivante : + `ECS_CONTAINER_STOP_TIMEOUT` : 2 Si votre application prend plus d’une seconde, multipliez la valeur par deux et utilisez ce nombre comme valeur. Dans ce cas, Amazon ECS attend deux secondes que le conteneur s’arrête, puis Amazon ECS envoie un message SIGKILL lorsque l’application ne s’arrête pas. Vous pouvez également modifier le code de l’application pour intercepter le signal SIGTERM et y réagir. Voici un exemple dans JavaScript : ``` process.on('SIGTERM', function() { server.close(); }) ``` Ce code oblige le serveur HTTP à cesser d’écouter les nouvelles requêtes et à finir de répondre aux requêtes en cours. Le processus Node.js se termine alors, car la boucle d’événements n’a plus rien à faire. Cela étant, si le processus ne prend que 500 ms pour terminer ses requêtes en cours de vol, il se termine prématurément sans avoir à attendre la fin du délai d’arrêt et sans recevoir de SIGKILL. # Utilisation d’un Application Load Balancer pour Amazon ECS Un équilibreur de charge Application Load Balancer prend des décisions de routage au niveau de la couche d'application (HTTP/HTTPS), prend en charge le routage basé sur le chemin et peut acheminer les demandes vers un ou plusieurs ports de chaque instance de conteneur de votre cluster. Les équilibreurs de charge Application Load Balancer prennent en charge le mappage de port hôte dynamique. Par exemple, si la définition de conteneur de la tâche spécifie le port 80 pour un port de conteneur NGINX et le port 0 pour le port hôte, le port hôte est choisi dynamiquement à partir de la plage de ports éphémères de l'instance de conteneur (par exemple, 32768 à 61000 sur la dernière AMI optimisée pour Amazon ECS). Au lancement de la tâche, le conteneur NGINX est enregistré auprès de l’Application Load Balancer sous la forme d’une combinaison d’ID d’instance et de port, et le trafic est distribué vers l’ID d’instance et le port correspondant à ce conteneur. Ce mappage dynamique vous permet d'exécuter plusieurs tâches à partir d'un seul service sur la même instance de conteneur. Pour plus d'informations, consultez le [Guide de l'utilisateur pour les équilibreurs de charge Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/). Pour plus d’informations sur les pratiques exemplaires en matière de définition de paramètres pour accélérer vos déploiements, consultez la section : + [Optimisation des paramètres de surveillance de l’état de l’équilibreur de charge pour Amazon ECS](load-balancer-healthcheck.md) + [Optimisation des paramètres de drainage de la connexion de l’équilibreur de charge pour Amazon ECS](load-balancer-connection-draining.md) Tenez compte des éléments suivants lorsque vous utilisez des Application Load Balancer avec Amazon ECS : + Amazon ECS nécessite le rôle IAM lié au service qui fournit les autorisations nécessaires pour enregistrer et désenregistrer des cibles dans votre équilibreur de charge lors de la création ou de l'arrêt de tâches. Pour de plus amples informations, veuillez consulter [Utilisation des rôles liés à un service pour Amazon ECS](using-service-linked-roles.md). + Pour les services dans une configuration IPv6 réservée, vous devez définir le type d'adresse IP du groupe cible de l'Application Load Balancer `dualstack` sur ou. `dualstack-without-public-ipv4` + Pour les services avec des tâches utilisant le mode réseau `awsvpc`, lorsque vous créez un groupe cible pour votre service, vous devez choisir `ip` comme type de cible, pas `instance`. Cela est dû au fait que les tâches qui utilisent le mode réseau `awsvpc` sont associées à une interface réseau Elastic et non à une instance Amazon EC2. + Si votre service nécessite l'accès à plusieurs ports d'équilibrage de charge, tels que le port 80 et le port 443 pour un HTTP/HTTPS service, vous pouvez configurer deux écouteurs. Un écouteur se charge du protocole HTTPS qui transmet la demande au service et un autre écouteur est responsable de la redirection des demandes HTTP vers le port HTTPS approprié. Pour plus d'informations, consultez la section [Création d'un écouteur pour votre Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-listener.html) dans le *Guide de l'utilisateur pour les Application Load Balancers*. + La configuration de sous-réseau de votre équilibreur de charge doit inclure toutes les zones de disponibilité dans lesquels résident vos instances de conteneur. + Une fois que vous avez créé un service, la configuration de l'équilibreur de charge ne peut pas être modifiée à partir de la AWS Management Console. Vous pouvez utiliser le AWS Copilot AWS CLI ou le SDK pour modifier la configuration de l'équilibreur de charge uniquement pour le contrôleur de déploiement `ECS` évolutif, et non AWS CodeDeploy pour le bleu/vert ou externe. AWS CloudFormation Lorsque vous ajoutez, mettez à jour ou supprimez une configuration d'équilibreur de charge, Amazon ECS lance un nouveau déploiement avec la configuration mise à jour d'Elastic Load Balancing. Cela entraîne l'enregistrement et le désenregistrement des tâches auprès des équilibreurs de charge. Nous vous recommandons de vérifier cela dans un environnement de test avant de mettre à jour la configuration d'Elastic Load Balancing. Pour plus d'informations sur la manière de modifier la configuration, consultez le [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)manuel *Amazon Elastic Container Service API Reference*. + Si une tâche d’un service ne satisfait pas aux critères de surveillance de l’état de l’équilibreur de charge, la tâche est arrêtée et redémarrée. Ce processus continue jusqu'à ce que votre service atteigne le nombre souhaité de tâches en cours d'exécution. + Si vous rencontrez des problèmes avec l'équilibreur de charge utilisé par vos services, consultez [Résolution des problèmes liés aux équilibreurs de charge des services dans Amazon ECS](troubleshoot-service-load-balancers.md). + Lorsque vous utilisez le type de cible `instance`, vos tâches et votre équilibreur de charge doivent se trouver dans le même VPC. Lors de l’utilisation du type de cible `ip`, la connectivité entre VPC est prise en charge. + Utilisez un groupe cible unique pour chaque service. L’utilisation du même groupe cible pour plusieurs services peut entraîner des problèmes lors des déploiements de service. + Vous devez spécifier les groupes cibles associés à un Application Load Balancer. Pour plus d’informations sur la création d’un Application Load Balancer, consultez la section [Création d’un Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) dans *Application Load Balancer*. # Utilisation d’un Network Load Balancer pour Amazon ECS Un Network Load Balancer prend des décisions de routage au niveau de la couche de transport (TCP/SSL). Il est capable de traiter des millions de demandes par seconde. Lorsque l'équilibreur de charge reçoit une connexion, il sélectionne une cible depuis le groupe cible pour la règle par défaut à l'aide d'un algorithme de routage du hachage de flux. Il tente d'ouvrir une connexion TCP à la cible sélectionnée sur le port spécifié dans la configuration de l'écouteur. Il transmet la demande sans modifier les en-têtes. Les équilibreurs de charge Network Load Balancer prennent en charge le mappage de port hôte dynamique. Par exemple, si la définition de conteneur de la tâche spécifie le port 80 pour un port de conteneur NGINX et le port 0 pour le port hôte, le port hôte est choisi dynamiquement à partir de la plage de ports éphémères de l'instance de conteneur (par exemple, 32768 à 61000 sur la dernière AMI optimisée pour Amazon ECS). Lorsque la tâche est lancée, le conteneur NGINX est enregistré dans l'équilibreur de charge Network Load Balancer en tant que combinaison d'ID d'instance et de port, et le trafic est réparti vers l'ID d'instance et le port correspondant à ce conteneur. Ce mappage dynamique vous permet d'exécuter plusieurs tâches à partir d'un seul service sur la même instance de conteneur. Pour plus d'informations, veuillez consulter le [Guide de l'utilisateur pour les Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/). Pour plus d’informations sur les pratiques exemplaires en matière de définition de paramètres pour accélérer vos déploiements, consultez la section : + [Optimisation des paramètres de surveillance de l’état de l’équilibreur de charge pour Amazon ECS](load-balancer-healthcheck.md) + [Optimisation des paramètres de drainage de la connexion de l’équilibreur de charge pour Amazon ECS](load-balancer-connection-draining.md) Tenez compte des informations suivantes lors de l’utilisation d’un Network Load Balancer avec Amazon ECS : + Amazon ECS nécessite le rôle IAM lié au service qui fournit les autorisations nécessaires pour enregistrer et désenregistrer des cibles dans votre équilibreur de charge lors de la création ou de l'arrêt de tâches. Pour de plus amples informations, veuillez consulter [Utilisation des rôles liés à un service pour Amazon ECS](using-service-linked-roles.md). + Vous ne pouvez pas attacher plus de cinq groupes cibles à un service. + Pour les services dans une configuration IPv6 uniquement, vous devez définir le type d'adresse IP du groupe cible du Network Load `dualstack` Balancer sur. + Pour les services avec des tâches utilisant le mode réseau `awsvpc`, lorsque vous créez un groupe cible pour votre service, vous devez choisir `ip` comme type de cible, pas `instance`. Cela est dû au fait que les tâches qui utilisent le mode réseau `awsvpc` sont associées à une interface réseau Elastic et non à une instance Amazon EC2. + La configuration de sous-réseau de votre équilibreur de charge doit inclure toutes les zones de disponibilité dans lesquels résident vos instances de conteneur. + Une fois que vous avez créé un service, la configuration de l'équilibreur de charge ne peut pas être modifiée à partir de la AWS Management Console. Vous pouvez utiliser le AWS Copilot AWS CLI ou le SDK pour modifier la configuration de l'équilibreur de charge uniquement pour le contrôleur de déploiement `ECS` évolutif, et non AWS CodeDeploy pour le bleu/vert ou externe. AWS CloudFormation Lorsque vous ajoutez, mettez à jour ou supprimez une configuration d'équilibreur de charge, Amazon ECS lance un nouveau déploiement avec la configuration mise à jour d'Elastic Load Balancing. Cela entraîne l'enregistrement et le désenregistrement des tâches auprès des équilibreurs de charge. Nous vous recommandons de vérifier cela dans un environnement de test avant de mettre à jour la configuration d'Elastic Load Balancing. Pour plus d'informations sur la manière de modifier la configuration, consultez le [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)manuel *Amazon Elastic Container Service API Reference*. + Si une tâche d’un service ne satisfait pas aux critères de surveillance de l’état de l’équilibreur de charge, la tâche est arrêtée et redémarrée. Ce processus continue jusqu'à ce que votre service atteigne le nombre souhaité de tâches en cours d'exécution. + Lorsque vous utilisez un Gateway Load Balancer configuré avec des adresses IP comme cibles et la préservation de l’adresse IP du client désactivée, les requêtes sont considérées comme provenant de l’adresse IP privée du Gateway Load Balancer. Cela signifie que les services derrière un Gateway Load Balancer sont effectivement ouverts au monde dès que vous autorisez les requêtes entrantes et les surveillances de l’état dans le groupe de sécurité de la cible. + Pour les tâches Fargate, vous devez utiliser la version de plateforme `1.4.0` (Linux) ou `1.0.0` (Windows). + Si vous rencontrez des problèmes avec l'équilibreur de charge utilisé par vos services, consultez [Résolution des problèmes liés aux équilibreurs de charge des services dans Amazon ECS](troubleshoot-service-load-balancers.md). + Lorsque vous utilisez le type de cible `instance`, vos tâches et votre équilibreur de charge doivent se trouver dans le même VPC. Lors de l’utilisation du type de cible `ip`, la connectivité entre VPC est prise en charge. + La préservation des adresses IP client du Network Load Balancer est compatible avec les cibles Fargate. + Utilisez un groupe cible unique pour chaque service. L’utilisation du même groupe cible pour plusieurs services peut entraîner des problèmes lors des déploiements de service. + Vous devez spécifier les groupes cibles associés à un Network Load Balancer. Pour plus d’informations sur la création d’un Network Load Balancer, consultez la section [Création d’un Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) dans *Network Load Balancer*. **Important** Si la définition de tâche de votre service utilise le mode réseau `awsvpc` (ce qui est requis pour Fargate), vous devez choisir le type de cible `ip`, et non `instance`. Cela est dû au fait que les tâches qui utilisent le mode réseau `awsvpc` sont associées à une interface réseau Elastic et non à une instance Amazon EC2. Vous ne pouvez pas enregistrer des instances par ID d'instance si elles ont les types d'instance suivants : C1 CC1 CC2, CG1, CG2, CR1,, G1, G2, HI1, M1 HS1, M2, M3 et T1. Vous pouvez enregistrer les instances de ces types par adresse IP. # Utilisation d’un Gateway Load Balancer pour Amazon ECS Les équilibreurs Gateway Load Balancer agissent au niveau de la troisième couche du modèle OSI Open Systems Interconnection (OSI), la couche réseau. Ils écoutent tous les paquets IP sur tous les ports et transfèrent le trafic vers le groupe cible spécifié dans la règle d'écoute. Il maintient la fidélité des flux à une appliance cible spécifique en utilisant 5 tuples (pour les TCP/UDP flux) ou 3 tuples (pour les flux non TCP/UDP). Par exemple, si la définition de conteneur de la tâche spécifie le port 80 pour un port de conteneur NGINX et le port 0 pour le port hôte, le port hôte est choisi dynamiquement à partir de la plage de ports éphémères de l'instance de conteneur (par exemple, 32768 à 61000 sur la dernière AMI optimisée pour Amazon ECS). Au lancement de la tâche, le conteneur NGINX est enregistré auprès du Gateway Load Balancer sous la forme d’une combinaison d’ID d’instance et de port, et le trafic est distribué vers l’ID d’instance et le port correspondant à ce conteneur. Ce mappage dynamique vous permet d'exécuter plusieurs tâches à partir d'un seul service sur la même instance de conteneur. Pour plus d’informations, consultez la section [Qu’est-ce qu’un Gateway Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html) dans *Gateway Load Balancer*. Pour plus d’informations sur les pratiques exemplaires en matière de définition de paramètres pour accélérer vos déploiements, consultez la section : + [Optimisation des paramètres de surveillance de l’état de l’équilibreur de charge pour Amazon ECS](load-balancer-healthcheck.md) + [Optimisation des paramètres de drainage de la connexion de l’équilibreur de charge pour Amazon ECS](load-balancer-connection-draining.md) Tenez compte des informations suivantes lors de l’utilisation de Gateway Load Balancer avec Amazon ECS : + Amazon ECS nécessite le rôle IAM lié au service qui fournit les autorisations nécessaires pour enregistrer et désenregistrer des cibles dans votre équilibreur de charge lors de la création ou de l'arrêt de tâches. Pour de plus amples informations, veuillez consulter [Utilisation des rôles liés à un service pour Amazon ECS](using-service-linked-roles.md). + Pour les services dans une configuration IPv6 réservée, vous devez définir le type d'adresse IP du groupe cible du Gateway Load `dualstack` Balancer sur. + Pour les services dont les tâches utilisent un mode réseau autre que `awsvpc`, les Gateway Load Balancer ne sont pas pris en charge. + La configuration de sous-réseau de votre équilibreur de charge doit inclure toutes les zones de disponibilité dans lesquels résident vos instances de conteneur. + Une fois que vous avez créé un service, la configuration de l'équilibreur de charge ne peut pas être modifiée à partir de la AWS Management Console. Vous pouvez utiliser le AWS Copilot AWS CLI ou le SDK pour modifier la configuration de l'équilibreur de charge uniquement pour le contrôleur de déploiement `ECS` évolutif, et non AWS CodeDeploy pour le bleu/vert ou externe. AWS CloudFormation Lorsque vous ajoutez, mettez à jour ou supprimez une configuration d'équilibreur de charge, Amazon ECS lance un nouveau déploiement avec la configuration mise à jour d'Elastic Load Balancing. Cela entraîne l'enregistrement et le désenregistrement des tâches auprès des équilibreurs de charge. Nous vous recommandons de vérifier cela dans un environnement de test avant de mettre à jour la configuration d'Elastic Load Balancing. Pour plus d'informations sur la manière de modifier la configuration, consultez le [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)manuel *Amazon Elastic Container Service API Reference*. + Si une tâche d’un service ne satisfait pas aux critères de surveillance de l’état de l’équilibreur de charge, la tâche est arrêtée et redémarrée. Ce processus continue jusqu'à ce que votre service atteigne le nombre souhaité de tâches en cours d'exécution. + Lorsque vous utilisez un Gateway Load Balancer configuré avec des adresses IP comme cibles, les requêtes sont considérées comme provenant de l’adresse IP privée du Gateway Load Balancer. Cela signifie que les services derrière un Gateway Load Balancer sont effectivement ouverts au monde dès que vous autorisez les requêtes entrantes et les surveillances de l’état dans le groupe de sécurité de la cible. + Pour les tâches Fargate, vous devez utiliser la version de plateforme `1.4.0` (Linux) ou `1.0.0` (Windows). + Si vous rencontrez des problèmes avec l'équilibreur de charge utilisé par vos services, consultez [Résolution des problèmes liés aux équilibreurs de charge des services dans Amazon ECS](troubleshoot-service-load-balancers.md). + Lorsque vous utilisez le type de cible `instance`, vos tâches et votre équilibreur de charge doivent se trouver dans le même VPC. Lors de l’utilisation du type de cible `ip`, la connectivité entre VPC est prise en charge. + Utilisez un groupe cible unique pour chaque service. L’utilisation du même groupe cible pour plusieurs services peut entraîner des problèmes lors des déploiements de service. + Vous devez spécifier les groupes cibles associés à un Gateway Load Balancer. Pour plus d’informations sur la création d’un Gateway Load Balancer, consultez la section [Démarrage avec les Gateway Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html) dans *Gateway Load Balancer*. **Important** Si la définition de tâche de votre service utilise le mode réseau `awsvpc` (ce qui est requis pour Fargate), vous devez choisir le type de cible `ip`, et non `instance`. Cela est dû au fait que les tâches qui utilisent le mode réseau `awsvpc` sont associées à une interface réseau Elastic et non à une instance Amazon EC2. Vous ne pouvez pas enregistrer des instances par ID d'instance si elles ont les types d'instance suivants : C1 CC1 CC2, CG1, CG2, CR1,, G1, G2, HI1, M1 HS1, M2, M3 et T1. Vous pouvez enregistrer les instances de ces types par adresse IP. # Enregistrement de plusieurs groupes cibles auprès d’un service Amazon ECS Votre service Amazon ECS service peut desservir le trafic provenant de plusieurs équilibreurs de charge et exposer plusieurs ports à charge équilibrée en spécifiant plusieurs groupes cibles dans une définition de service. Pour créer un service spécifiant plusieurs groupes cibles, vous devez créer le service à l'aide de l'API Amazon ECS, du SDK ou d'un CloudFormation modèle. AWS CLI Une fois que le service est créé, vous pouvez afficher le service et les groupes cibles enregistrés auprès de celui-ci avec la AWS Management Console. Vous devez utiliser `[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)` pour modifier la configuration de l'équilibreur de charge d'un service existant. Plusieurs groupes cibles peuvent être spécifiés dans une définition de service à l'aide du format suivant. Pour obtenir la syntaxe complète d'une définition de service, consultez [Modèle de définition de service](sd-template.md). ``` "loadBalancers":[ { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456", "containerName":"container_name", "containerPort":container_port }, { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321", "containerName":"container_name", "containerPort":container_port } ] ``` ## Considérations Les informations suivantes doivent être prises en compte lorsque vous spécifiez plusieurs groupes cibles dans une définition de service. + Pour les services qui utilisent un équilibreur Application Load Balancer ou un Network Load Balancer, vous ne pouvez pas attacher plus de cinq groupes cibles à un service. + La spécification de plusieurs groupes cibles dans une définition de service n'est prise en charge que dans les conditions suivantes : + Le service doit utiliser un équilibreur de charge Application Load Balancer ou un Network Load Balancer. + Le service doit utiliser le type de contrôleur de déploiement (`ECS`). Il peut s'agir du déploiement native/blue écologique d'Amazon ECS ou du déploiement de mises à jour continues. + La spécification de groupes cibles multiples est prise en charge pour des services contenant des tâches qui utilisent à la fois les types de lancement Fargate et EC2. + Lors de la création d'un service qui spécifie plusieurs groupes cibles, le rôle lié à un service Amazon ECS service doit être créé. Le rôle est créé en omettant le paramètre `role` dans les demandes d'API, ou la propriété `Role` dans CloudFormation. Pour de plus amples informations, veuillez consulter [Utilisation des rôles liés à un service pour Amazon ECS](using-service-linked-roles.md). ## Exemples de définitions de service Voici quelques exemples de cas d'utilisation pour spécifier plusieurs groupes cibles dans une définition de service. Pour obtenir la syntaxe complète d'une définition de service, consultez [Modèle de définition de service](sd-template.md). ### Utilisation d’équilibreurs de charge distincts pour le trafic interne et externe Dans le cas d'utilisation suivant, un service utilise deux équilibreurs de charge distincts, l'un pour le trafic interne et l'autre pour le trafic Internet, pour le même conteneur et port. ``` "loadBalancers":[ //Internal ELB { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456", "containerName":"nginx", "containerPort":8080 }, //Internet-facing ELB { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321", "containerName":"nginx", "containerPort":8080 } ] ``` ### Exposition de plusieurs ports à partir du même conteneur Dans le cas d'utilisation suivant, un service utilise un équilibreur de charge, mais expose plusieurs ports à partir du même conteneur. Par exemple, un conteneur Jenkins expose le port 8080 pour l'interface web Jenkins et le port 50000 pour l'API. ``` "loadBalancers":[ { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456", "containerName":"jenkins", "containerPort":8080 }, { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321", "containerName":"jenkins", "containerPort":50000 } ] ``` ### Exposition de ports à partir de plusieurs conteneurs Dans le cas d'utilisation suivant, un service utilise un équilibreur de charge et deux groupes cibles pour exposer les ports de conteneurs distincts. ``` "loadBalancers":[ { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456", "containerName":"webserver", "containerPort":80 }, { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321", "containerName":"database", "containerPort":3306 } ] ``` # Mise à l’échelle automatique de votre service Amazon ECS La *mise à l’échelle automatique* est l’aptitude à augmenter ou à diminuer automatiquement le nombre souhaité de tâches dans votre service Amazon ECS. Amazon ECS utilise le service Application Auto Scaling pour fournir cette fonctionnalité. Pour de plus amples informations, veuillez consulter le [Guide de l'utilisateur Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html). Amazon ECS publie des CloudWatch statistiques indiquant l'utilisation moyenne du processeur et de la mémoire de votre service. Pour de plus amples informations, veuillez consulter [Métriques d’utilisation d’un service Amazon ECS](service_utilization.md). Vous pouvez utiliser ces CloudWatch indicateurs, ainsi que d'autres, pour étendre votre service (ajouter des tâches) afin de répondre à une forte demande aux heures de pointe, et pour étendre votre service (exécuter moins de tâches) afin de réduire les coûts pendant les périodes de faible utilisation. Amazon ECS Service Auto Scaling prend en charge les types de scalabilité automatique suivants : + [Utiliser une métrique cible pour faire évoluer les services Amazon ECS](service-autoscaling-targettracking.md) – Augmente ou réduit le nombre de tâches exécutées par votre service en fonction d'une valeur cible pour une métrique spécifique. Cette option est similaire à la façon dont votre thermostat maintient la température de votre domicile. Vous sélectionnez une température et le thermostat se charge du reste. + [Utilisez des incréments prédéfinis basés sur les CloudWatch alarmes pour dimensionner les services Amazon ECS](service-autoscaling-stepscaling.md) – Augmente ou réduit le nombre de tâches exécutées par votre service en fonction d'un ensemble d'ajustements de mise à l'échelle, appelés ajustements d'étape, qui varient en fonction de la valeur du seuil de l'alarme. + [Utilisez des actions planifiées pour faire évoluer les services Amazon ECS](service-autoscaling-schedulescaling.md) : augmente ou réduit le nombre de tâches exécutées par votre service en fonction de la date et de l’heure. + [Utilisez des modèles historiques pour faire évoluer les services Amazon ECS grâce à une mise à l'échelle prédictive](predictive-auto-scaling.md) : augmente ou réduit le nombre de tâches exécutées par votre service en fonction de l’analytique des données historiques de charge afin de détecter les tendances quotidiennes ou hebdomadaires dans les flux de trafic. ## Considérations Lorsque vous utilisez des stratégies de mise à l'échelle, tenez compte des informations suivantes : + Amazon ECS envoie des métriques toutes les 1 minute à CloudWatch. Les métriques ne sont pas disponibles tant que les clusters et les services ne les ont pas envoyées CloudWatch, et vous ne pouvez pas créer d' CloudWatch alarmes pour des métriques qui n'existent pas. + Les stratégies de mise à l'échelle prennent en charge un temps de stabilisation. Il s'agit de la durée, en secondes, à attendre qu'une activité de mise à l'échelle précédente prenne effet. + Pour les événements de montée en puissance, l'intention est de réduire continuellement (mais pas excessivement) la montée en puissance. Une fois que Service Auto Scaling a réussi une montée en puissance à l'aide d'une stratégie de mise à l'échelle, l'application commence à calculer le temps de stabilisation. La politique de mise à l'échelle n'augmente pas à nouveau la capacité souhaitée, sauf si une plus grande montée en puissance est lancée ou si le temps de stabilisation est écoulé. Tandis que le temps de stabilisation de la montée en puissance s'applique, la capacité ajoutée par l'activité de mise à l'échelle initiale est calculée dans le cadre de la capacité souhaitée pour la prochaine activité de montée en puissance. + Pour les événements de mise à l'échelle horizontale, l'objectif est de procéder à une mise à l'échelle prudente afin de protéger la disponibilité de votre application, de sorte que les activités de mise à l'échelle horizontale sont bloquées jusqu'à l'expiration du temps de stabilisation. Toutefois, si une autre alarme lance une activité de montée en puissance au cours du temps de stabilisation de la diminution de charge, Application Auto Scaling monte immédiatement en puissance la cible. Dans ce cas, le temps de stabilisation de la mise à l'échelle horizontale s'arrête et ne se termine pas. + Le planificateur de service respecte le nombre souhaité à tout moment mais, tant que vous avez des stratégies de mise à l'échelle et des alarmes actives sur un service, Service Auto Scaling peut modifier un nombre souhaité manuellement défini par vous-même. + Si le nombre souhaité d’un service est défini comme inférieur à sa valeur de capacité minimale, et si une alarme déclenche une activité de montée en puissance, Service Auto Scaling augmente le nombre souhaité pour atteindre la valeur de capacité minimale, puis continue cette augmentation le cas échéant, selon la stratégie de mise à l’échelle associée à l’alarme. Toutefois, une activité de mise à l'échelle horizontale ne modifie pas le nombre souhaité, car il est déjà inférieur à la valeur de capacité minimale. + Si le nombre souhaité d’un service est défini comme supérieur à sa valeur de capacité maximale, et si une alarme déclenche une activité de mise à l’échelle horizontale, Service Auto Scaling réduit le nombre souhaité pour atteindre la valeur de capacité maximale, puis continue cette réduction le cas échéant, selon la stratégie de mise à l’échelle associée à l’alarme. Toutefois, une activité de montée en puissance ne modifie pas le nombre souhaité, car il est déjà supérieur à la valeur de capacité maximale. + Au cours des activités de mise à l'échelle, le nombre réel de tâches en cours d'exécution dans un service correspond à la valeur utilisée par Service Auto Scaling comme point de départ, plutôt qu'au nombre souhaité. C'est ce qui est supposé représenter la capacité de traitement. Cela évite une mise à l'échelle excessive qui ne pourrait pas être satisfaite, lorsqu'il n'y a par exemple pas assez de ressources d'instances de conteneur pour placer les tâches supplémentaires. Si la capacité d'instance de conteneur est disponible ultérieurement, l'activité de mise à l'échelle en suspens peut réussir et d'autres activités de mise à l'échelle peuvent continuer après la période de stabilisation. + Si vous souhaitez que votre nombre de tâches soit réduit à zéro lorsqu'il n'y a pas de travail à effectuer, définissez une capacité minimale de 0. Avec les stratégies de suivi des objectifs et d'échelonnement, lorsque la capacité réelle est de 0 et que la métrique indique qu'il y a une requête d'application, Service Auto Scaling attend l'envoi d'un point de données avant d'effectuer la montée en puissance. Dans ce cas, la mise à l'échelle entraîne la quantité la plus petite possible comme point de départ, puis reprend la mise à l'échelle en fonction du nombre réel de tâches en cours d'exécution. + Application Auto Scaling désactive les processus évolutifs pendant que les déploiements Amazon ECS sont en cours. Toutefois, pendant les déploiements, les processus de montée en puissance se poursuivent, sauf s'ils sont suspendus. Ce comportement ne s’applique pas aux services Amazon ECS utilisant le contrôleur de déploiement externe. Pour de plus amples informations, veuillez consulter [Service Auto Scaling et déploiements](#service-auto-scaling-deployments). + Vous disposez de plusieurs options d'Application Auto Scaling pour les tâches Amazon ECS. Le suivi des cibles est le mode le plus simple à utiliser. Il vous suffit de définir une valeur cible pour une métrique, telle que l'utilisation moyenne du processeur. Ensuite, l'autoscaler gère automatiquement le nombre de tâches nécessaires pour atteindre cette valeur. Grâce à la mise à l'échelle par étapes, vous pouvez réagir plus rapidement aux variations de la demande, car vous définissez les seuils spécifiques pour vos métriques de mise à l'échelle et le nombre de tâches à ajouter ou à supprimer lorsque les seuils sont dépassés. Et surtout, vous pouvez réagir très rapidement aux variations de la demande en réduisant la durée pendant laquelle une alarme de seuil est franchie. Pour de plus amples informations sur les pratiques exemplaires en matière d’autoscaling de service, consultez la section [Optimisation de l’autoscaling d’un service Amazon ECS](capacity-autoscaling-best-practice.md). ## Service Auto Scaling et déploiements Application Auto Scaling désactive les processus évolutifs pendant que les déploiements Amazon ECS sont en cours. Toutefois, pendant les déploiements, les processus de montée en puissance se poursuivent, sauf s'ils sont suspendus. Ce comportement ne s’applique pas aux services Amazon ECS utilisant le contrôleur de déploiement externe. Si vous souhaitez suspendre les processus de montée en puissance pendant les déploiements, procédez comme suit. 1. Appelez la [describe-scalable-targets](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scalable-targets.html)commande en spécifiant l'ID de ressource du service associé à la cible évolutive dans Application Auto Scaling (Example :`service/default/sample-webapp`). Enregistrez la sortie. Vous en aurez besoin pour appeler la commande suivante. 1. Appelez la [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)commande en spécifiant l'ID de ressource, l'espace de noms et la dimension évolutive. Spécifiez `true` pour `DynamicScalingInSuspended` et `DynamicScalingOutSuspended`. 1. Une fois le déploiement terminé, vous pouvez appeler la [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)commande pour reprendre le dimensionnement. Pour de plus amples informations, veuillez consulter [Suspension et reprise de la mise à l'échelle pour Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html). # Utiliser une métrique cible pour faire évoluer les services Amazon ECS Grâce aux politiques de suivi des objectifs et d’échelonnement, vous sélectionnez une métrique et définissez une valeur cible. Amazon ECS Service Auto Scaling crée et gère les CloudWatch alarmes qui contrôlent la politique de dimensionnement et calcule l'ajustement de dimensionnement en fonction de la métrique et de la valeur cible. La politique de mise à l'échelle ajoute ou supprime des tâches de service si nécessaire pour maintenir la métrique à la valeur cible spécifiée ou proche de celle-ci. En plus de maintenir la métrique proche de la valeur cible, une politique de suivi des objectifs et d'échelonnement s'ajuste également aux fluctuations de la métrique dues à un modèle de charge fluctuant, et minimise les fluctuations rapides du nombre de tâches exécutées dans votre service. Les politiques de suivi des cibles éliminent le besoin de définir manuellement les CloudWatch alarmes et les ajustements de dimensionnement. Amazon ECS gère cela automatiquement en fonction de la cible que vous avez définie. Tenez compte des éléments suivants lorsque vous utilisez des politiques de suivi des cibles : + Une politique de suivi des objectifs et d'échelonnement suppose qu'elle doit effectuer une montée en puissance ; lorsque la métrique spécifiée est au-dessus de la valeur cible. Vous ne pouvez pas utiliser une politique de suivi des objectifs et d'échelonnement pour effectuer une montée en puissance lorsque la métrique spécifiée est en dessous de la valeur cible. + Une politique de suivi des objectifs et d'échelonnement n'effectue pas de mise à l'échelle lorsque la métrique spécifiée a des données insuffisantes. Elle n'effectue pas de mise à l'échelle horizontale car elle n'interprète pas des données insuffisantes comme une faible utilisation. + Vous pouvez constater des écarts entre la valeur cible et les points de données de métrique réels. Ceci est dû au fait que Service Auto Scaling agit toujours avec prudence en effectuant un arrondi vers le haut ou vers le bas quand il détermine la capacité à ajouter ou à enlever. Cela l'empêche d'ajouter une capacité insuffisante ou de retirer trop de capacité. + Pour garantir la disponibilité de l'application, le service augmente proportionnellement aux métriques aussi rapidement que possible, mais diminue plus progressivement. + Application Auto Scaling désactive les processus évolutifs pendant que les déploiements Amazon ECS sont en cours. Toutefois, pendant les déploiements, les processus de montée en puissance se poursuivent, sauf s'ils sont suspendus. Ce comportement ne s’applique pas aux services Amazon ECS utilisant le contrôleur de déploiement externe. Pour de plus amples informations, veuillez consulter [Service Auto Scaling et déploiements](service-auto-scaling.md#service-auto-scaling-deployments). + Vous pouvez avoir plusieurs politiques de suivi des objectifs et d'échelonnement pour un service Amazon ECS service dans la mesure où chacune d'elles utilise une métrique différente. L'objectif de Service Auto Scaling est de toujours donner la priorité à la disponibilité, afin que son comportement diffère selon que les politiques de suivi des objectifs et d'échelonnement sont prêtes pour une augmentation ou une diminution de taille. Il procèdera à la montée en puissance du service si l'une des politiques Suivi de la cible est prête pour une augmentation de taille, mais la diminuera uniquement si toutes les politiques Suivi de la cible (avec la portion de mise à l'échelle horizontale activée) sont prêtes pour une diminution de taille. + Ne modifiez ni ne supprimez les CloudWatch alarmes gérées par Service Auto Scaling dans le cadre d'une politique de dimensionnement du suivi des cibles. Service Auto Scaling supprime les alarmes automatiquement quand vous supprimez la politique de mise à l'échelle. + La `ALBRequestCountPerTarget` métrique pour les politiques de dimensionnement du suivi des cibles n'est pas prise en charge pour le type de blue/green déploiement. Pour de plus amples informations sur les politiques de dimensionnement de suivi de cible, veuillez consulter [Politiques de dimensionnement de suivi de cible](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html) dans le *Manuel de l'utilisateur Application Auto Scaling*. # Création d’une stratégie de mise à l’échelle du suivi de cible pour l’autoscaling d’un service Amazon ECS Créez une stratégie de mise à l’échelle du suivi de cible pour qu’Amazon ECS augmente ou diminue automatiquement le nombre de tâches souhaité dans votre service. Le suivi de cible fonctionne à partir d’une valeur métrique cible. ## Console 1. En plus des autorisations IAM standard pour créer et mettre à jour des services, vous avez besoin d’autorisations supplémentaires. Pour de plus amples informations, veuillez consulter [Autorisations IAM requises pour l’autoscaling d’un service Amazon ECS](auto-scaling-IAM.md). 1. Déterminez les métriques à utiliser pour la stratégie. Les mesures suivantes sont disponibles : + **ECSServiceMoyenne CPUUtilization** : utilisation moyenne du processeur que le service doit utiliser. + **ECSServiceAverageMemoryUtilization**— Utilisation moyenne de la mémoire que le service doit utiliser. + **ALBRequestCountPerTarget**— Le nombre moyen de demandes par minute que cette tâche devrait idéalement recevoir. 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Sur la page **Clusters**, choisissez le cluster. 1. Sur la page des détails du cluster, dans la section **Services**, puis choisissez le service. La page de détails du service s’affiche. 1. Choisissez **Définir le nombre de tâches**. 1. Sous **Nombre de tâches du service Amazon ECS**, sélectionnez **Utiliser l’autoscaling**. La section **Nombre de tâches** s’affiche. 1. Pour **Nombre minimum de tâches**, saisissez la limite inférieure du nombre de tâches à utiliser pour l’autoscaling du service. Le nombre souhaité ne sera pas inférieur à ce nombre. 1. Pour **Nombre maximal de tâches**, saisissez la limite supérieure du nombre de tâches à utiliser pour l’autoscaling du service. Le nombre souhaité ne sera pas supérieur à ce nombre. 1. Choisissez **Enregistrer**. La page des stratégies s’affiche. 1. Choisissez **Créer une stratégie de mise à l’échelle**. La page **Créer une stratégie** s’affiche. 1. Pour **Scaling policy type** (Type de politique de mise à l'échelle), choisissez **Target tracking** (Suivi de cible). 1. Pour **Policy name** (Nom de la politique), saisissez un nom de politique. 1. Sous **Type de métrique**, choisissez vos métriques dans la liste des options. 1. Pour **Utilisation cible**, saisissez la valeur cible pour le pourcentage de tâches qu’Amazon ECS doit gérer. L’autoscaling du service augmente horizontalement votre capacité jusqu’à ce que l’utilisation moyenne corresponde à l’objectif, ou jusqu’à ce qu’elle atteigne le nombre maximal de tâches que vous avez spécifié. 1. Sous **Paramètres supplémentaires**, procédez comme suit : 1. Pour **Temps de stabilisation de la réduction horizontale**, saisissez la durée, en secondes, devant s’écouler entre la fin d’une activité de réduction horizontale et le début d’une autre. 1. Pour **Temps de stabilisation de l’augmentation horizontale**, saisissez la durée, en secondes, à attendre avant qu’une activité d’augmentation horizontale précédente ne prenne effet. 1. Pour ne créer qu’une stratégie d’augmentation horizontale, sélectionnez **Désactiver la réduction horizontale**. 1. Choisissez **Créer une stratégie de mise à l’échelle**. ## AWS CLI 1. Enregistrez votre service Amazon ECS en tant que cible évolutive à l'aide de la [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)commande. 1. Créez une politique de dimensionnement à l'aide de la [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)commande. # Utilisez des incréments prédéfinis basés sur les CloudWatch alarmes pour dimensionner les services Amazon ECS Les politiques de dimensionnement par étapes vous permettent de créer et de gérer les CloudWatch alarmes qui déclenchent le processus de dimensionnement. Lorsqu'une alarme est violée, Amazon ECS initie la politique de dimensionnement associée à cette alarme. La stratégie de mise à l’échelle par étapes met à l’échelle les tâches à l’aide d’un ensemble d’ajustements, appelés ajustements par étapes. La taille de l’ajustement varie en fonction de l’ampleur du déclenchement de l’alarme. + Si le dépassement dépasse le premier seuil, Amazon ECS applique le premier ajustement par étapes. + Si le déclenchement dépasse le second seuil, Amazon ECS applique le deuxième ajustement par étapes, et ainsi de suite. Nous vous recommandons fortement d’utiliser une stratégie de mise à l’échelle de suivi cible pour appliquer une mise à l’échelle en fonction de métriques telles que l’utilisation moyenne de l’UC ou le nombre moyen de requêtes par cible. Les métriques qui diminuent lorsque la capacité augmente et augmentent lorsque la capacité diminue peuvent être utilisées pour augmenter ou réduire horizontalement le nombre de tâches proportionnellement en utilisant le suivi de cible. Cela permet de s’assurer qu’Amazon ECS suit de près la courbe de requêtes pour vos applications. # Création d’une stratégie de mise à l’échelle par étapes pour l’autoscaling de service Amazon ECS Créez une stratégie de mise à l’échelle par étapes pour qu’Amazon ECS augmente ou diminue automatiquement le nombre souhaité de tâches dans votre service. La mise à l’échelle d’étape est basée sur un ensemble d’ajustements de mise à l’échelle, appelés ajustements par étapes, qui varient en fonction de l’importance du dépassement du seuil d’alarme. ## Console 1. En plus des autorisations IAM standard pour créer et mettre à jour des services, vous avez besoin d’autorisations supplémentaires. Pour de plus amples informations, veuillez consulter [Autorisations IAM requises pour l’autoscaling d’un service Amazon ECS](auto-scaling-IAM.md). 1. Déterminez les métriques à utiliser pour la stratégie. Les mesures suivantes sont disponibles : + **ECSServiceMoyenne CPUUtilization** : utilisation moyenne du processeur que le service doit utiliser. + **ECSServiceAverageMemoryUtilization**— Utilisation moyenne de la mémoire que le service doit utiliser. + **ALBRequestCountPerTarget**— Le nombre moyen de demandes par minute que cette tâche devrait idéalement recevoir. 1. Créez les CloudWatch alarmes pour les métriques. Pour plus d'informations, consultez la section [Création CloudWatch d'une alarme basée sur un seuil statique](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) dans le *guide de CloudWatch l'utilisateur Amazon*. 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Sur la page **Clusters**, choisissez le cluster. 1. Sur la page des détails du cluster, dans la section **Services**, puis choisissez le service. La page de détails du service s’affiche. 1. Choisissez **Définir le nombre de tâches**. 1. Sous **Nombre de tâches du service Amazon ECS**, sélectionnez **Utiliser l’autoscaling**. La section **Nombre de tâches** s’affiche. 1. Pour **Nombre minimum de tâches**, saisissez la limite inférieure du nombre de tâches à utiliser pour l’autoscaling du service. Le nombre souhaité ne sera pas inférieur à ce nombre. 1. Pour **Nombre maximal de tâches**, saisissez la limite supérieure du nombre de tâches à utiliser pour l’autoscaling du service. Le nombre souhaité ne sera pas supérieur à ce nombre. 1. Choisissez **Enregistrer**. La page des stratégies s’affiche. 1. Choisissez **Créer une stratégie de mise à l’échelle**. La page **Créer une stratégie** s’affiche. 1. Pour **Type de stratégie de mise à l’échelle**, choisissez **Mise à l’échelle par étapes**. 1. Configurez les propriétés d’augmentation horizontale. Sous **Étapes pour ajouter des tâches**, procédez comme suit : 1. Pour **Policy name** (Nom de la politique), saisissez un nom de politique. 1. Pour le **nom de l'CloudWatch alarme**, choisissez l' CloudWatch alarme. 1. Pour **Type d’agrégation des métriques**, choisissez comment comparer la métrique sélectionnée au seuil défini. 1. Pour **Types d’ajustement**, choisissez si l’ajustement est basé sur une modification du nombre de tâches ou sur une modification du pourcentage de tâches. 1. Dans **Actions à entreprendre**, saisissez les valeurs correspondant à l’action à entreprendre. Choisissez **Ajouter une étape** pour ajouter des actions supplémentaires. 1. Configurez les propriétés de réduction horizontale. Sous **Étapes pour supprimer des tâches**, procédez comme suit : 1. Pour **Policy name** (Nom de la politique), saisissez un nom de politique. 1. Pour le **nom de l'CloudWatch alarme**, choisissez l' CloudWatchalarme. 1. Pour **Type d’agrégation des métriques**, choisissez comment comparer la métrique sélectionnée au seuil défini. 1. Pour **Types d’ajustement**, choisissez si l’ajustement est basé sur une modification du nombre de tâches ou sur une modification du pourcentage de tâches. 1. Dans **Actions à entreprendre**, saisissez les valeurs correspondant à l’action à entreprendre. Choisissez **Ajouter une étape** pour ajouter des actions supplémentaires. 1. Pour **Temps de stabilisation**, saisissez la durée, en secondes, à attendre avant qu’une activité de mise à l’échelle précédente ne prenne effet. Pour une stratégie d’ajout, il s’agit du délai après une activité d’augmentation horizontale pendant lequel la stratégie de mise à l’échelle bloque les activités de réduction horizontale et limite le nombre de tâches pouvant augmenter horizontalement simultanément. Pour une politique de suppression, il s’agit du délai qui doit s’écouler après une activité de réduction horizontale avant qu’une autre activité de réduction puisse commencer. 1. Choisissez **Créer une stratégie de mise à l’échelle**. ## AWS CLI 1. Enregistrez votre service Amazon ECS en tant que cible évolutive à l'aide de la [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)commande. 1. Créez une politique de dimensionnement à l'aide de la [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)commande. # Utilisez des actions planifiées pour faire évoluer les services Amazon ECS Avec la mise à l’échelle planifiée, vous pouvez configurer la mise à l’échelle automatique de votre application en fonction des changements de charge prévisibles en créant des actions planifiées qui augmentent ou diminuent le nombre de tâches à des moments précis. Cette procédure vous permet de mettre votre application à l’échelle de manière proactive afin qu’elle corresponde aux variations de charge prévisibles. Ces actions de mise à l’échelle planifiées vous permettent d’optimiser les coûts et les performances. Votre application dispose d’un nombre suffisant de tâches pour gérer le pic de trafic en milieu de semaine, mais ne surdimensionne pas le nombre de tâches à d’autres moments. Vous pouvez utiliser conjointement la mise à l’échelle planifiée et les stratégies de mise à l’échelle pour bénéficier des avantages des approches proactives et réactives de la mise à l’échelle. Après l’exécution d’une action de mise à l’échelle planifiée, la stratégie de mise à l’échelle peut continuer à prendre des décisions sur l’opportunité de poursuivre la mise à l’échelle du nombre de tâches. Cela vous permet de vous assurer que vous avez un nombre de tâches suffisant pour gérer la charge de votre application. Bien que votre application soit mise à l’échelle pour répondre à la demande, la capacité actuelle doit se situer dans les limites du nombre de tâches minimal et maximal qui a été fixée par votre action planifiée. Vous pouvez configurer la mise à l’échelle du calendrier à l’aide de l’ AWS CLI. Pour de plus amples informations sur l’utilisation de la mise à l’échelle planifiée, consultez la section [Mise à l’échelle planifiée](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) dans le *Guide de l’utilisateur Application Auto Scaling*. # Création d’une action planifiée pour l’autoscaling d’un service Amazon ECS Créez une action planifiée pour qu’Amazon ECS augmente ou diminue le nombre de tâches exécutées par votre service en fonction de la date et de l’heure. ## Console 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Sur la page **Clusters**, choisissez le cluster. 1. Sur la page des détails du cluster, dans la section **Services**, choisissez le service. La page de détails du service s’affiche. 1. Choisissez **Autoscaling du service**. La page d’autoscaling du service s’affiche. 1. Si vous n’avez pas configuré l’autoscaling du service, sélectionnez **Définir le nombre de tâches**. La section **Nombre de tâches du service Amazon ECS** s’affiche. Sous **Nombre de tâches du service Amazon ECS**, choisissez **Utiliser l’autoscaling du service pour ajuster le nombre de tâches souhaité pour votre service**. La section **Nombre de tâches** s’affiche. 1. Pour **Nombre minimum de tâches**, saisissez la limite inférieure du nombre de tâches à utiliser pour l’autoscaling du service. Le nombre souhaité ne sera pas inférieur à ce nombre. 1. Pour **Nombre maximal de tâches**, saisissez la limite supérieure du nombre de tâches à utiliser pour l’autoscaling du service. Le nombre souhaité ne sera pas supérieur à ce nombre. 1. Choisissez **Enregistrer**. La page des stratégies s’affiche. 1. Choisissez **Actions planifiées**, puis **Créer**. La page **Créer une action planifiée** s’affiche. 1. Pour **Nom de l’action**, saisissez un nom unique. 1. Dans le champ **Fuseau horaire**, choisissez un fuseau horaire. Tous les fuseaux horaires répertoriés proviennent de la base de données des fuseaux horaires IANA. Pour plus d’informations, consultez la section [Liste des fuseaux horaires de la base de données tz](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). 1. Pour **Heure de début**, saisissez la **date** et l’**heure** de début de l’action. Si vous avez choisi une planification récurrente, l'heure de début définit le moment où la première action planifiée de la série récurrente s'exécute. 1. Pour **Recurrence (Récurrence)**, choisissez l'une des options disponibles. + Pour effectuer des mises à l’échelle selon un calendrier récurrent, choisissez la fréquence à laquelle Amazon ECS exécute l’action planifiée. + Si vous sélectionnez une option qui commence par **Fréquence**, l’expression Cron est créée pour vous. + Si vous sélectionnez **Cron**, tapez une expression Cron qui spécifie l'heure à laquelle exécuter l'action. + Pour ne mettre à l’échelle qu’une seule fois, choisissez **Une fois**. 1. Sous **Ajustements des tâches**, procédez comme suit : + Pour **Minimum**, saisissez le nombre minimum de tâches que le service doit exécuter. + Pour **Maximum**, saisissez le nombre maximum de tâches que le service doit exécuter. 1. Choisissez **Create Scheduled Action** (Créer une action planifiée). ## INTERFACE DE LIGNE DE COMMANDE (CLI) Utilisez ce qui AWS CLI suit pour configurer les politiques de dimensionnement planifiées pour votre service. Remplacez chaque *user input placeholder* par vos propres informations. **Exemple : Pour planifier un dimensionnement unique** Utilisez la [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html)commande suivante avec les `--MaxCapacity` options `--start-time "YYYY-MM-DDThh:mm:ssZ"` et `--MinCapacity` et ou les deux. ``` aws application-autoscaling put-scheduled-action --service-namespace ecs \ --resource-id service/my-cluster/my-service \ --scheduled-action-name my-one-time-schedule \ --start-time 2021-01-30T12:00:00 \ --scalable-target-action MinCapacity=3,MaxCapacity=10 ``` **Exemple : pour planifier la mise à l’échelle selon un calendrier récurrent** Utilisez la commande [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html) suivante. Remplacez le *user input* par vos valeurs. ``` aws application-autoscaling put-scheduled-action --service-namespace ecs \ --resource-id service/my-cluster/my-service \ --scheduled-action-name my-recurring-action \ --schedule "rate(5 hours)" \ --start-time 2021-01-30T12:00:00 \ --end-time 2021-01-31T22:00:00 \ --scalable-target-action MinCapacity=3,MaxCapacity=10 ``` Le calendrier de récurrence spécifié est basé sur le fuseau horaire UTC. Pour spécifier un fuseau horaire différent, incluez l’option `--time-zone` et le nom du fuseau horaire IANA, comme dans l’exemple suivant. ``` --time-zone "America/New_York" ``` Pour plus d’informations, consultez la section [Liste des fuseaux horaires de la base de données tz](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). # Utilisez des modèles historiques pour faire évoluer les services Amazon ECS grâce à une mise à l'échelle prédictive La mise à l’échelle prédictive examine les données de charge passées issues des flux de trafic afin d’analyser les tendances quotidiennes ou hebdomadaires. Elle utilise ensuite cette analyse pour anticiper les besoins postérieurs et augmenter de manière proactive les tâches dans votre service selon les besoins. L’autoscaling prédictif est particulièrement utile dans les cas suivants. + Trafic cyclique : utilisation accrue des ressources pendant les heures normales de bureau et utilisation réduite pendant les soirées et les fins de semaine. + Modèles on-and-off de charge de travail récurrents ‐ Les exemples incluent le traitement par lots, les tests ou l'analyse périodique des données. + Applications avec des temps d’initialisation longs : cette situation peut avoir un impact sur les performances des applications lors d’événements d’augmentation horizontale, entraînant une latence notable. Si vos applications prennent beaucoup de temps à s’initialiser et que le trafic augmente de manière régulière, vous devriez envisager d’utiliser la mise à l’échelle prédictive. Elle permet d’accélérer la mise à l’échelle en augmentant de manière proactive le nombre de tâches pour les charges prévues, au lieu d’utiliser uniquement des stratégies de mise à l’échelle dynamique, telles que la stratégie de mise à l’échelle du suivi de cible ou la mise à l’échelle par étapes. En vous aidant à éviter le risque de surallocation du nombre de tâches, la mise à l’échelle prédictive peut également vous permettre de réaliser des économies. Prenons l'exemple d'une application très utilisée pendant les heures de bureau et peu utilisée la nuit. Au début de chaque journée ouvrable, la mise à l’échelle prédictive peut augmenter horizontalement les tâches avant le premier afflux de trafic. Cela permet à votre application de maintenir une disponibilité et des performances élevées lorsqu'elle passe d'une période de faible utilisation à une période d'utilisation plus intensive. Vous n'avez pas besoin d'attendre que la mise à l'échelle dynamique réagisse à l'évolution du trafic. Vous n’avez pas non plus à passer du temps à examiner les modèles de charge de votre application et à essayer de planifier le nombre adéquat de tâches à l’aide d’une mise à l’échelle planifiée. La mise à l’échelle prédictive est une fonctionnalité au niveau du service qui met à l’échelle la tâche de votre service indépendamment de la mise à l’échelle de la capacité de calcul sous-jacente (par exemple, EC2 ou Fargate). Pour Fargate AWS , gère et adapte automatiquement la capacité sous-jacente en fonction des exigences des tâches. Pour la capacité EC2, vous pouvez utiliser les fournisseurs de capacité du groupe Auto Scaling pour mettre automatiquement à l’échelle les instances EC2 sous-jacentes en fonction des exigences de dimensionnement de vos tâches. **Topics** + [Présentation de la mise à l’échelle prédictive](#predictive-auto-scaling-overview) + [Créer une stratégie de mise à l’échelle prédictive](predictive-scaling-create-policy.md) + [Évaluer vos politiques de mise à l'échelle prédictive](predictive-scaling-graphs.md) + [Remplacer la prévision](predictive-scaling-overriding-forecast-capacity.md) + [Utilisation de métriques personnalisées](predictive-scaling-custom-metrics.md) ## Fonctionnement de la mise à l’échelle prédictive dans Amazon ECS Vous trouverez ici des informations sur les considérations relatives à l’utilisation de la mise à l’échelle prédictive, son fonctionnement et ses limites. ### Considérations relatives à l’utilisation de la mise à l’échelle prédictive + Vous voulez vous assurer que la mise à l’échelle prédictive est adaptée à votre charge de travail. Vous pouvez vérifier cela en configurant les stratégies de mise à l’échelle en mode **prévisions uniquement** et en consultant les recommandations de la console. Vous devez évaluer les prévisions et les recommandations avant de commencer à utiliser la mise à l’échelle prédictive. + Avant que la mise à l’échelle prédictive puisse commencer à établir des prévisions, elle a besoin d’au moins 24 heures de données historiques. Plus il y a de données historiques disponibles, plus les prévisions sont efficaces, l’idéal étant deux semaines. Vous devrez également attendre 24 heures avant que la mise à l’échelle prédictive puisse générer de nouvelles prévisions lorsque vous supprimez un service Amazon ECS pour en recréer un. L’une des manières d’accélérer les choses consiste à utiliser des métriques personnalisées pour agréger les métriques entre l’ancien et le nouveau service Amazon ECS. + Choisissez une métrique de charge qui représente avec précision la charge complète de votre application et qui constitue l’aspect le plus important de votre application à prendre en compte. + La mise à l’échelle dynamique avec mise à l’échelle prédictive vous permet de suivre de près la demande de votre application, afin que vous puissiez l’augmenter en période d’accalmie et l’augmenter en cas d’augmentation inattendue du trafic. Lorsque plusieurs stratégies de mise à l’échelle sont actives, chaque stratégie détermine indépendamment le nombre souhaité de tâches, et le nombre souhaité de tâches est défini sur le maximum de celles-ci. + Vous pouvez utiliser la mise à l’échelle prédictive parallèlement à vos stratégies de mise à l’échelle dynamique, telles que le suivi des cibles ou la mise à l’échelle par étapes, afin que vos applications évoluent en fonction de modèles historiques et en temps réel. En soi, la mise à l’échelle prédictive ne permet pas de réduire horizontalement vos tâches. + Si vous utilisez un rôle personnalisé lorsque vous appelez l’API `register-scalable-target`, un message d’erreur peut s’afficher indiquant que la stratégie de mise à l’échelle prédictive ne peut fonctionner que si le SLR est activé. Dans ce cas, vous devez appeler `register-scalable-target` à nouveau, mais sans role-arn. Utilisez le SLR lors de l’enregistrement de la cible évolutive et appelez l’API `put-scaling-policy`. ### Fonctionnement de la mise à l'échelle prédictive Vous utilisez la mise à l'échelle prédictive en créant une politique de mise à l'échelle prédictive qui spécifie la CloudWatch métrique à surveiller et à analyser. La mise à l’échelle prédictive doit disposer d’au moins 24 heures de données pour commencer à prévoir les valeurs futures. Une fois que vous avez créé la stratégie, la mise à l’échelle prédictive commence à analyser les données métriques recueillies au cours des 14 derniers jours afin d’identifier des modèles. Cette analyse est utilisée pour générer des prévisions horaires des besoins pour les 48 prochaines heures. Les dernières CloudWatch données sont utilisées pour mettre à jour les prévisions toutes les six heures. À mesure que de nouvelles données arrivent, la mise à l’échelle prédictive améliore continuellement la précision des prévisions futures. Lorsque vous activez la mise à l’échelle prédictive pour la première fois, elle s’exécute en mode *prévision uniquement*. Elle génère des prévisions dans ce mode, mais ne met pas votre service Amazon ECS à l’échelle en fonction de ces prévisions. Cela vous permet d’évaluer la précision et la pertinence des prévisions. Vous pouvez consulter les données de prévision à l’aide de l’opération API `GetPredictiveScalingForecast` ou de l’ AWS Management Console. Lorsque vous décidez de commencer à utiliser la mise à l’échelle prédictive, passez la stratégie de mise à l’échelle en mode *prévision et mise à l’échelle*. Dans ce mode, les événements suivants se produisent. Votre service Amazon ECS est mis à l’échelle au début de chaque heure en fonction des prévisions pour cette heure, par défaut. Vous pouvez choisir de commencer plus tôt en utilisant la propriété `SchedulingBufferTime` dans l’opération d’API `PutScalingPolicy`. Cela permet de lancer de nouvelles tâches avant la demande prévue et leur donne le temps de démarrer et de se préparer à gérer le trafic. ### Limite maximum de tâches Lorsque vous enregistrez les services Amazon ECS pour la mise à l’échelle, vous définissez un nombre maximal de tâches pouvant être lancées par service. Par défaut, lorsque des politiques de mise à l’échelle sont définies, elles ne peuvent pas augmenter le nombre de tâches au-dessus de sa limite maximale. Vous pouvez également autoriser l’augmentation automatique du nombre maximum de tâches du service si les prévisions approchent ou dépassent le nombre maximum de tâches du service Amazon ECS. **Avertissement** Soyez prudent lorsque vous autorisez l’augmentation automatique du nombre maximum de tâches. Cela peut entraîner le lancement d’un plus grand nombre de tâches que prévu, si le nombre maximum de tâches augmenté n’est pas surveillé et géré. Le nombre maximum de tâches augmenté devient alors le nouveau nombre maximum normal de tâches pour le service Amazon ECS jusqu’à ce que vous le mettiez à jour manuellement. Le nombre maximum de tâches ne revient pas automatiquement au maximum initial. ### Régions prises en charge + USA Est (Virginie du Nord) + USA Est (Ohio) + USA Ouest (Californie du Nord) + USA Ouest (Oregon) + Afrique (Le Cap) + Asie-Pacifique (Hong Kong) + Asie-Pacifique (Jakarta) + Asie-Pacifique (Mumbai) + Asie-Pacifique (Osaka) + Asia Pacific (Seoul) + Asie-Pacifique (Singapour) + Asie-Pacifique (Sydney) + Asie-Pacifique (Tokyo) + Canada (Centre) + Chine (Pékin) + China (Ningxia) + Europe (Francfort) + Europe (Irlande) + Europe (Londres) + Europe (Milan) + Europe (Paris) + Europe (Stockholm) + Moyen-Orient (Bahreïn) + Amérique du Sud (São Paulo) + AWS GovCloud (USA Est) + AWS GovCloud (US-Ouest) # Création d’une stratégie de mise à l’échelle pour l’autoscaling d’un service Amazon ECS Créez une stratégie de mise à l’échelle prédictive pour qu’Amazon ECS augmente ou diminue le nombre de tâches exécutées par votre service en fonction de données historiques. **Note** Un nouveau service doit fournir au moins 24 heures de données avant de pouvoir générer une prévision. ## Console 1. En plus des autorisations IAM standard pour créer et mettre à jour des services, vous avez besoin d’autorisations supplémentaires. Pour de plus amples informations, veuillez consulter [Autorisations IAM requises pour l’autoscaling d’un service Amazon ECS](auto-scaling-IAM.md). 1. Déterminez les métriques à utiliser pour la stratégie. Les mesures suivantes sont disponibles : + **ECSServiceMoyenne CPUUtilization** : utilisation moyenne du processeur que le service doit utiliser. + **ECSServiceAverageMemoryUtilization**— Utilisation moyenne de la mémoire que le service doit utiliser. + **ALBRequestCountPerTarget**— Le nombre moyen de demandes par minute que cette tâche devrait idéalement recevoir. Vous pouvez également utiliser une métrique personnalisée. Vous devez définir les valeurs suivantes : + Charge : métrique qui représente avec précision la charge totale de votre application et qui constitue l’aspect le plus important à prendre en compte pour la mise à l’échelle de votre application. + Métrique de mise à l’échelle : le meilleur indicateur pour déterminer le niveau d’utilisation idéal pour votre application. 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Sur la page **Clusters**, choisissez le cluster. 1. Sur la page des détails du cluster, dans la section **Services**, choisissez le service. La page de détails du service s’affiche. 1. Choisissez **Autoscaling du service**, puis sélectionnez **Définir le nombre de tâches**. 1. Sous **Nombre de tâches du service Amazon ECS**, sélectionnez **Utiliser l’autoscaling**. La section **Nombre de tâches** s’affiche. 1. Pour **Nombre minimum de tâches**, saisissez la limite inférieure du nombre de tâches à utiliser pour l’autoscaling du service. Le nombre souhaité ne sera pas inférieur à ce nombre. 1. Pour **Nombre maximal de tâches**, saisissez la limite supérieure du nombre de tâches à utiliser pour l’autoscaling du service. Le nombre souhaité ne sera pas supérieur à ce nombre. 1. Choisissez **Enregistrer**. La page des stratégies s’affiche. 1. Choisissez **Créer une stratégie de mise à l’échelle**. La page **Créer une stratégie** s’affiche. 1. Pour **Type de stratégie de mise à l’échelle**, choisissez **Mise à l’échelle prédictive**. 1. Pour **Policy name** (Nom de la politique), saisissez un nom de politique. 1. Sous **Paire de métriques**, choisissez vos métriques dans la liste des options. Si vous avez choisi **Nombre de requêtes Application Load Balancer par cible**, choisissez un groupe cible dans le champ **Groupe cible**. L’option **Nombre de requêtes Application Load Balancer par cible** n’est prise en charge que si vous avez attaché un groupe cible Application Load Balancer à votre service. Si vous avez choisi **Paire de métriques personnalisées**, sélectionnez les métriques individuelles dans les listes déroulantes **Métrique de charge** et **Métrique de mise à l’échelle**. 1. Pour **Utilisation cible**, saisissez la valeur cible pour le pourcentage de tâches qu’Amazon ECS doit gérer. L’autoscaling du service augmente horizontalement votre capacité jusqu’à ce que l’utilisation moyenne corresponde à l’objectif, ou jusqu’à ce qu’elle atteigne le nombre maximal de tâches que vous avez spécifié. 1. Choisissez **Créer une stratégie de mise à l’échelle**. ## AWS CLI Utilisez ce qui AWS CLI suit pour configurer des politiques de dimensionnement prédictif pour votre service Amazon ECS. Remplacez chaque *user input placeholder* par vos propres informations. Pour plus d'informations sur les CloudWatch métriques que vous pouvez spécifier, consultez le [PredictiveScalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html)manuel *Amazon EC2 Auto Scaling API* Reference. ### Exemple 1 : stratégie de mise à l’échelle prédictive avec mémoire prédéfinie. Voici un exemple de stratégie avec une configuration mémoire prédéfinie. ``` cat policy.json { "MetricSpecifications": [ { "TargetValue": 40, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ECSServiceMemoryUtilization" } } ], "SchedulingBufferTime": 3600, "MaxCapacityBreachBehavior": "HonorMaxCapacity", "Mode": "ForecastOnly" } ``` L'exemple suivant illustre la création de la politique en exécutant la [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)commande avec le fichier de configuration spécifié. ``` aws application-autoscaling put-scaling-policy \ --service-namespace ecs \ --region us-east-1 \ --policy-name predictive-scaling-policy-example \ --resource-id service/MyCluster/test \ --policy-type PredictiveScaling \ --scalable-dimension ecs:service:DesiredCount \ --predictive-scaling-policy-configuration file://policy.json ``` Si elle aboutit, cette commande renvoie l’ARN de la stratégie. ``` { "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example", "Alarms": [] } ``` ### Exemple 2 : stratégie de mise à l’échelle prédictive avec UC prédéfinie. Voici un exemple de stratégie avec une configuration UC prédéfinie. ``` cat policy.json { "MetricSpecifications": [ { "TargetValue": 0.00000004, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ECSServiceCPUUtilization" } } ], "SchedulingBufferTime": 3600, "MaxCapacityBreachBehavior": "HonorMaxCapacity", "Mode": "ForecastOnly" } ``` L'exemple suivant illustre la création de la politique en exécutant la [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)commande avec le fichier de configuration spécifié. ``` aws aas put-scaling-policy \ --service-namespace ecs \ --region us-east-1 \ --policy-name predictive-scaling-policy-example \ --resource-id service/MyCluster/test \ --policy-type PredictiveScaling \ --scalable-dimension ecs:service:DesiredCount \ --predictive-scaling-policy-configuration file://policy.json ``` Si elle aboutit, cette commande renvoie l’ARN de la stratégie. ``` { "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example", "Alarms": [] } ``` # Évaluation de vos stratégies de mise à l’échelle prédictive pour Amazon ECS Avant d’utiliser une stratégie de mise à l’échelle prédictive pour mettre à l’échelle vos services, consultez les recommandations et autres données relatives à votre stratégie dans la console Amazon ECS. C'est une étape importante pour éviter qu'une politique de mise à l'échelle prédictive mette votre capacité réelle à l'échelle tant que vous ne savez pas si ses prévisions sont exactes. Si le service est neuf, prévoyez 24 heures pour créer la première prévision. Lors de AWS la création d'une prévision, elle utilise des données historiques. Si votre service ne dispose pas encore de beaucoup de données historiques récentes, la mise à l’échelle prédictive peut temporairement compléter les prévisions avec des agrégats créés à partir des agrégats historiques actuellement disponibles. Les prévisions sont remplies jusqu'à deux semaines avant la date de création d'une politique. ## Afficher vos recommandations de mise à l'échelle prédictive Pour une analyse efficace, l’autoscaling du service doit disposer d’au moins deux stratégies de mise à l’échelle prédictive à comparer. (Toutefois, vous pouvez toujours consulter les résultats d'une seule politique.) Lorsque vous créez plusieurs politiques, vous pouvez évaluer une politique qui utilise une seule métrique par rapport à une autre qui utilise une autre métrique. Vous pouvez également évaluer l'impact de différentes combinaisons de valeurs cibles et de métriques. Une fois les stratégies de mise à l’échelle prédictive créées, Amazon ECS commence immédiatement à évaluer la stratégie la plus appropriée pour mettre votre groupe à l’échelle. **Pour afficher vos recommandations dans la console Amazon ECS** 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Sur la page **Clusters**, choisissez le cluster. 1. Sur la page des détails du cluster, dans la section **Services**, choisissez le service. La page de détails du service s’affiche. 1. Choisissez **Autoscaling du service**. 1. Choisissez la stratégie de mise à l’échelle prédictive, puis sélectionnez **Actions**, **Mise à l’échelle prédictive**, **Afficher les recommandations**. Vous pouvez consulter les détails d’une stratégie ainsi que notre recommandation. La recommandation vous indique si la politique de mise à l'échelle prédictive est plus efficace que si vous ne l'utilisez pas. Si vous ne savez pas si une politique de mise à l'échelle prédictive convient à votre groupe, consultez les colonnes **Impact sur la disponibilité** et **Impact sur les coûts** pour choisir la politique appropriée. Les informations de chaque colonne vous indiquent l'impact de la politique. + **Impact sur la disponibilité** : indique si la stratégie permettrait d’éviter un impact négatif sur la disponibilité en provisionnant suffisamment d’instances pour gérer la charge de travail, en comparaison avec sa non-utilisation. + **Impact sur les coûts** : indique si la stratégie éviterait un impact négatif sur vos coûts en évitant une surallocation des tâches, en comparaison avec sa non-utilisation. En cas d’allocation excessive, vos services sont sous-utilisés ou inactifs, ce qui ne fait qu’augmenter l’impact sur les coûts. Si vous avez plusieurs politiques, la balise **Meilleure prévision** s'affiche à côté du nom de la politique qui offre le plus d'avantages en matière de disponibilité à moindre coût. Une plus grande importance est accordée à l'impact sur la disponibilité. 1. (Facultatif) Pour sélectionner la période souhaitée pour les résultats des recommandations, choisissez la valeur de votre choix dans le menu déroulant **Période d’évaluation** : **2 jours**, **1 semaine** ou **2 semaines**. Par défaut, la période d'évaluation est réglée sur les deux dernières semaines. Une période d'évaluation plus longue fournit davantage de points de données pour les résultats des recommandations. Toutefois, l'ajout de points de données supplémentaires risque de ne pas améliorer les résultats si vos modèles de charge ont changé, par exemple après une période de demande exceptionnelle. Dans ce cas, vous pouvez obtenir une recommandation plus ciblée en consultant des données plus récentes. **Note** Les recommandations sont générées uniquement pour les politiques qui sont en mode **Prévision uniquement**. La fonctionnalité des recommandations offre de meilleurs résultats lorsqu'une politique est en mode **Prévision uniquement** pendant toute la période d'évaluation. Si vous lancez une politique en mode **Prévision et mise à l'échelle** et que vous la passez ultérieurement en mode **Prévision uniquement**, les résultats de cette politique risquent d'être biaisés. Cela s'explique par le fait que la politique a déjà contribué à la capacité réelle. ## Consulter les graphiques de surveillance de la mise à l'échelle prédictive Dans la console, vous pouvez consulter les prévisions des jours, semaines ou mois précédents afin de visualiser les performances de la stratégie au fil du temps. Vous pouvez également utiliser ces informations pour évaluer la précision des prévisions lorsque vous décidez de laisser une stratégie mettre à l’échelle votre nombre réel de tâches. **Pour consulter les graphiques de surveillance de la mise à l’échelle prédictive dans la console Amazon ECS** 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Sur la page **Clusters**, choisissez le cluster. 1. Sur la page des détails du cluster, dans la section **Services**, choisissez le service. La page de détails du service s’affiche. 1. Choisissez **Autoscaling du service**. 1. Choisissez la stratégie de mise à l’échelle prédictive, puis sélectionnez **Actions**, **Mise à l’échelle prédictive**, **Afficher les graphiques**. 1. Dans la section **Surveillance**, vous pouvez afficher les prévisions passées et futures de votre politique concernant la charge et la capacité par rapport aux valeurs réelles. Le graphique **Charge** présente la prévision de charge et les valeurs réelles pour la métrique de charge que vous avez choisie. Le graphique **Capacité** indique le nombre de tâches prédit par la stratégie. Il inclut également le nombre réel de tâches lancées. La ligne verticale sépare les valeurs historiques des prévisions futures. Ces graphiques sont disponibles peu de temps après la création de la politique. 1. (Facultatif) Pour modifier la quantité de données historiques affichées dans le graphique, choisissez la valeur de votre choix dans la liste déroulante **Période d'évaluation** en haut de la page. La période d'évaluation ne transforme en rien les données de cette page. Elle ne fait que modifier la quantité de données historiques affichées. **Comparer les données du graphique **Charge**** Chaque ligne horizontale représente un ensemble différent de points de données rapportés à des intervalles d'une heure : 1. La **charge observée réelle** utilise la statistique SUM correspondant à la métrique de charge de votre choix afin d'afficher la charge horaire totale dans le passé. 1. La **charge prévue par la politique** indique la prévision de charge horaire. Cette prévision se base sur les observations de charge réelles des deux semaines précédentes. **Comparez les données du graphique **Capacité**** Chaque ligne horizontale représente un ensemble différent de points de données rapportés à des intervalles d'une heure : 1. Le **nombre réel de tâches observé** indique la capacité réelle de votre service Amazon ECS dans le passé, qui dépend de vos autres stratégies de mise à l’échelle et de la taille minimale du groupe en vigueur pour la période sélectionnée. 1. La **capacité prévue par la politique** indique la capacité de base à laquelle vous pouvez vous attendre au début de chaque heure lorsque la politique est en mode **Prévision et mise à l'échelle**. 1. Le **nombre de tâches requis estimé** indique le nombre idéal de tâches dans votre service pour maintenir la métrique de mise à l’échelle à la valeur cible que vous avez choisie. 1. Le **nombre minimum de tâches** indique le nombre minimum de tâches de votre service. 1. La **capacité maximale** indique le nombre maximal de tâches de votre service. Afin de calculer la capacité requise estimée, nous partons du principe que chaque tâche est utilisée de manière égale à une valeur cible spécifiée. Dans la pratique, le nombre de tâches n’est pas utilisé de manière égale. En supposant toutefois que l’utilisation est répartie uniformément entre les tâches, nous pouvons estimer la probabilité de la capacité nécessaire. Le nombre de tâches requis est alors calculé comme étant inversement proportionnel à la métrique de mise à l’échelle que vous avez utilisée pour votre stratégie de mise à l’échelle prédictive. En d’autres termes, à mesure que le nombre de tâches augmente, la métrique de mise à l’échelle diminue au même rythme. Par exemple, si le nombre de tâches double, la métrique de mise à l’échelle doit diminuer de moitié. La formule de la capacité requise déduite est la suivante : `sum of (actualServiceUnits*scalingMetricValue)/(targetUtilization)` Par exemple, nous prenons les `actualServiceUnits` (`10`) et la `scalingMetricValue` (`30`) pour une heure donnée. Nous prenons ensuite la `targetUtilization` que vous avez spécifiée dans votre politique de mise à l'échelle prédictive (`60`) et calculons la capacité requise déduite pour la même heure. Elle renvoie la valeur `5`. Cela signifie que cinq est la quantité de capacité requise déduite pour maintenir la capacité en proportion inverse directe à la valeur cible de la métrique de mise à l'échelle. **Note** Différents leviers sont à votre disposition pour ajuster et améliorer les économies de coûts et la disponibilité de votre application. Vous utilisez la mise à l'échelle prédictive pour la capacité de base et la mise à l'échelle dynamique afin de gérer la capacité supplémentaire. La mise à l'échelle dynamique fonctionne indépendamment de la mise à l'échelle prédictive, avec une mise à l'échelle horizontale et une montée en puissance en fonction de l'utilisation actuelle. Tout d’abord, Amazon ECS calcule le nombre de tâches recommandé pour chaque stratégie de mise à l’échelle non planifiée. Ensuite, il procède à la mise à l’échelle en fonction de la stratégie qui fournit le plus grand nombre de tâches. Pour permettre la réduction horizontale lorsque la charge diminue, votre service doit toujours disposer d’au moins une stratégie de mise à l’échelle dynamique avec la partie réduction horizontale activée. Vous pouvez améliorer les performances de mise à l'échelle en vous assurant que vos capacités minimale et maximale ne sont pas trop restrictives. Une stratégie avec un nombre recommandé de tâches qui ne se situe pas dans la plage de capacité minimale et maximale ne pourra pas être mise à l’échelle. # Surveillez les mesures de dimensionnement prédictif pour Amazon ECS avec CloudWatch Vous pouvez utiliser Amazon CloudWatch pour surveiller vos données à des fins de dimensionnement prédictif. Une stratégie de mise à l’échelle prédictive collecte des données qui sont utilisées pour prévoir votre charge postérieure. Les données collectées sont automatiquement stockées CloudWatch à intervalles réguliers et peuvent être utilisées pour visualiser les performances de la politique au fil du temps. Vous pouvez également créer des CloudWatch alarmes pour vous avertir lorsque les indicateurs de performance changent au-delà des limites que vous avez définies. ## Visualisez les données de prévision historiques Les données de prévision de charge pour une politique de dimensionnement prédictif peuvent être consultées CloudWatch et peuvent être utiles lors de la visualisation des prévisions par rapport à d'autres CloudWatch indicateurs dans un seul graphique. Vous pouvez également observer les tendances au fil du temps en affichant une période plus longue. Vous pouvez accéder aux métriques historiques jusqu'à 15 mois pour acquérir un meilleur point de vue de la façon dont votre politique s'exécute. **Pour consulter les données de prévision historiques à l'aide de la CloudWatch console** 1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. Dans le panneau de navigation, choisissez **Metrics** (Métriques), **All metrics** (Toutes les métriques). 1. Choisissez l’espace de noms de métrique **Application Auto Scaling**. 1. Choisissez **Prévisions de charge pour la mise à l’échelle prédictive**. 1. Dans le champ de recherche, saisissez le nom de la stratégie de mise à l’échelle prédictive ou le nom du groupe de services Amazon ECS, puis appuyez sur « Entrée » pour filtrer les résultats. 1. Pour représenter graphiquement une métrique, cochez la case en regard de la métrique. Pour modifier le nom du graphique, choisissez l'icône représentant un crayon. Pour modifier la plage de temps, sélectionnez l'une des valeurs prédéfinies ou choisissez **custom (personnalisé)**. Pour plus d'informations, consultez la section [Représentation graphique d'une métrique](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html) dans le *guide de CloudWatch l'utilisateur Amazon*. 1. Pour modifier les statistiques, choisissez l'onglet **Graphed metrics (Graphique des métriques)**. Sélectionnez l'en-tête de colonne ou une valeur individuelle et choisissez une autre valeur. Bien que vous puissiez choisir n'importe quelle statistique pour chaque métrique, toutes les statistiques ne sont pas utiles pour les **PredictiveScalingLoadForecast**métriques. Par exemple, les calculs statistiques de moyenne, minimum et maximum de l'utilisation de l'UC sont utiles, mais le calcul statistique de somme ne l'est pas. 1. (En option) Pour ajouter une autre métrique à utiliser dans l'expression mathématique, sous **Toutes les métriques**, choisissez **Tous**, recherchez la métrique spécifique, puis activez la case à cocher en regard de celle-ci. Vous pouvez ajouter jusqu'à 10 métriques. 1. (Facultatif) Pour ajouter le graphique à un CloudWatch tableau de bord, choisissez **Actions**, puis **Ajouter au tableau de bord**. ## Créer des mesures de précision à l'aide de mathématiques Avec les mathématiques métriques, vous pouvez interroger plusieurs CloudWatch métriques et utiliser des expressions mathématiques pour créer de nouvelles séries chronologiques basées sur ces métriques. Vous pouvez visualiser les séries chronologiques obtenues sur la CloudWatch console et les ajouter aux tableaux de bord. Pour plus d'informations sur les mathématiques métriques, consultez la section [Utilisation des mathématiques métriques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) dans le *guide de CloudWatch l'utilisateur Amazon*. À l’aide des mathématiques de métriques, vous pouvez représenter graphiquement les données générées par l’autoscaling du service pour la mise à l’échelle prédictive de différentes manières. Cela vous permet de surveiller les performances des politiques au fil du temps et de comprendre si votre combinaison de mesures peut être améliorée. Par exemple, vous pouvez utiliser une expression mathématique de métrique pour surveiller[erreur absolue moyenne en pourcentage](https://en.wikipedia.org/wiki/Mean_absolute_percentage_error)(MÂLE). La métrique MAPE permet de surveiller la différence entre les valeurs prévues et les valeurs réelles observées pendant une fenêtre de prévision donnée. Les modifications de la valeur de MAPE peuvent indiquer si les performances de la stratégie se dégradent au fil du temps à mesure que la nature de votre application change. Une augmentation de l'EMAP indique un écart plus important entre les valeurs prévues et les valeurs réelles. **Exemple : expressions mathématiques appliquées aux métriques** Pour commencer avec ce type de graphique, vous pouvez créer une expression mathématique de métrique comme celle présentée dans l'exemple suivant. Au lieu d'une seule métrique, il existe un tableau de structures de requêtes de données de métriques pour`MetricDataQueries`. Chaque élément de`MetricDataQueries`obtient une métrique ou exécute une expression mathématique. Le premier point,`e1`, est l'expression mathématique. L'expression désignée définit le`ReturnData`Paramètre to`true`, qui génère une seule série chronologique. Pour toutes les autres métriques, le kit`ReturnData`valeur est`false`. Dans l'exemple, l'expression désignée utilise les valeurs réelles et prévues comme entrée et renvoie la nouvelle métrique (MAPE). `m1`est la CloudWatch métrique qui contient les valeurs de charge réelles (en supposant que l'utilisation du processeur est la métrique de charge initialement spécifiée pour la politique nommée`my-predictive-scaling-policy`). `m2`est la CloudWatch métrique qui contient les valeurs de charge prévues. La syntaxe mathématique de la métrique MAPE est la suivante : *Moyenne de (abs ((Réel - Forecast)/(Réel)))* ### Visualisez vos mesures de précision et définissez des alarmes Pour visualiser les données métriques de précision, sélectionnez l'onglet **Métriques** dans la CloudWatch console. Vous pouvez représenter les données sous forme graphique à partir de là. Pour plus d'informations, consultez la section [Ajouter une expression mathématique à un CloudWatch graphique](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html#adding-metrics-expression-console) dans le *guide de CloudWatch l'utilisateur Amazon*. Vous pouvez définir une alarme sur une métrique que vous surveillez à partir de la section **Metrics** (Métriques). Pendant que vous êtes sur l'onglet **Métriques sous forme de graphique**, vous pouvez sélectionner l'icône **Créer une alarme** sous la colonne **Actions**. Le**Créer une alarme**est représentée par une petite cloche. Pour plus d'informations et pour connaître les options de notification, consultez les [sections Création CloudWatch d'une alarme basée sur une expression mathématique métrique](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html) et [Notification aux utilisateurs des modifications apportées aux alarmes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Notify_Users_Alarm_Changes.html) dans le *guide de l' CloudWatch utilisateur Amazon*. Vous pouvez également utiliser [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)et effectuer des calculs [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html)à l'aide des mathématiques métriques et créer des alarmes en fonction de la sortie. # Utilisation des actions planifiées pour remplacer les valeurs prévisionnelles pour Amazon ECS Parfois, vous pouvez disposer d'informations supplémentaires sur de futurs besoins de votre application que le calcul prédictif ne peut pas prendre en compte. Par exemple, les calculs prévisionnels pourraient sous-estimer les tâches nécessaires à la préparation d’un événement marketing à venir. Vous pouvez alors utiliser des actions planifiées pour remplacer temporairement la prévision au cours de périodes ultérieures. Les actions planifiées peuvent être exécutées de manière récurrente, ou à une date et une heure spécifiques en cas de fluctuations ponctuelles de la demande. Par exemple, vous pouvez créer une action planifiée avec un nombre de tâches supérieur à celui prévu. Au moment de l’exécution, Amazon ECS met à jour le nombre minimum de tâches de votre service. Étant donné que la mise à l’échelle prédictive optimise le nombre de tâches, une action planifiée dont le nombre minimum de tâches est supérieur aux valeurs prévues est respectée. Cela permet d’éviter que le nombre de tâches soit inférieur à celui prévu. Pour cesser de remplacer les prévisions, utilisez une deuxième action planifiée afin de rétablir le nombre minimum de tâches à son paramètre d’origine. La procédure suivante présente les étapes à suivre pour remplacer la prévision au cours de périodes ultérieures. **Topics** + [Étape 1 : (facultatif) Analyser les données en séries chronologiques](#analyzing-time-series-data) + [Étape 2 : créer deux actions planifiées](#scheduling-capacity) **Important** Cette rubrique part du principe que vous essayez de remplacer les prévisions afin d’atteindre une capacité supérieure à celle prévue. Si vous devez réduire temporairement le nombre de tâches sans interférer avec une stratégie de mise à l’échelle prédictive, utilisez plutôt le mode *prévision uniquement*. En mode « prévision uniquement », la mise à l’échelle prédictive continuera de générer des prévisions, mais elle n’augmentera pas automatiquement le nombre de tâches. Vous pouvez ensuite surveiller l’utilisation des ressources et réduire manuellement le nombre de tâches selon les besoins. ## Étape 1 : (facultatif) Analyser les données en séries chronologiques Commencez par analyser les données en séries chronologiques de la prévision. Il s'agit d'une étape facultative, mais elle permet de comprendre les détails de la prévision. 1. **Récupérer la prévision** Une fois la prévision créée, vous pouvez interroger une période spécifique au sein de celle-ci. L'objectif de la requête est d'obtenir une vue complète des données en séries chronologiques d'une période spécifique. Votre requête peut inclure jusqu'à deux jours de données de prévision ultérieures. Si vous utilisez la mise à l'échelle prédictive depuis un certain temps, vous pouvez également accéder à vos données de prévision antérieures. Toutefois, la durée maximale entre le début et la fin est de 30 jours. Pour obtenir les prévisions à l'aide de la [get-predictive-scaling-forecast](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/get-predictive-scaling-forecast.html) AWS CLI commande, entrez les paramètres suivants dans la commande : + Saisissez le nom du cluster dans le paramètre `resource-id`. + Entrez le nom de la stratégie dans le paramètre `--policy-name`. + Entrez l'heure de début dans le paramètre `--start-time` pour ne renvoyer que les données de prévision correspondant à l'heure spécifiée ou ultérieures à celle-ci. + Entrez l'heure de fin dans le paramètre `--end-time` pour ne renvoyer que les données de prévision correspondant à l'heure spécifiée ou antérieures à celle-ci. ``` aws application-autoscaling get-predictive-scaling-forecast \ --service-namespace ecs \ --resource-id service/MyCluster/test \ --policy-name cpu40-predictive-scaling-policy \ --scalable-dimension ecs:service:DesiredCount \ --start-time "2021-05-19T17:00:00Z" \ --end-time "2021-05-19T23:00:00Z" ``` Si elle aboutit, la commande renvoie des données semblables à l'exemple suivant. ``` { "LoadForecast": [ { "Timestamps": [ "2021-05-19T17:00:00+00:00", "2021-05-19T18:00:00+00:00", "2021-05-19T19:00:00+00:00", "2021-05-19T20:00:00+00:00", "2021-05-19T21:00:00+00:00", "2021-05-19T22:00:00+00:00", "2021-05-19T23:00:00+00:00" ], "Values": [ 153.0655799339254, 128.8288551285919, 107.1179447150675, 197.3601844551528, 626.4039934516954, 596.9441277518481, 677.9675713779869 ], "MetricSpecification": { "TargetValue": 40.0, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ASGCPUUtilization" } } } ], "CapacityForecast": { "Timestamps": [ "2021-05-19T17:00:00+00:00", "2021-05-19T18:00:00+00:00", "2021-05-19T19:00:00+00:00", "2021-05-19T20:00:00+00:00", "2021-05-19T21:00:00+00:00", "2021-05-19T22:00:00+00:00", "2021-05-19T23:00:00+00:00" ], "Values": [ 2.0, 2.0, 2.0, 2.0, 4.0, 4.0, 4.0 ] }, "UpdateTime": "2021-05-19T01:52:50.118000+00:00" } ``` La réponse comprend deux prévisions : `LoadForecast` et `CapacityForecast`. `LoadForecast` affiche la prévision de charge horaire. `CapacityForecast` affiche les valeurs de prévision de la capacité nécessaire sur une base horaire pour gérer la charge prévue tout en maintenant une `TargetValue` de 40 (40 % d'utilisation moyenne du processeur). 1. **Identifier la période cible** Indiquez l'heure ou les heures où la fluctuation de la demande ponctuelle devrait avoir lieu. N'oubliez pas que les dates et les heures indiquées dans la prévision sont basées sur le fuseau horaire UTC. ## Étape 2 : créer deux actions planifiées Créez ensuite deux actions planifiées pour une période spécifique où votre application devra gérer une charge plus élevée que celle prédite. Par exemple, si vous organisez un événement marketing qui va générer du trafic sur votre site pendant une période limitée, vous pouvez planifier une action ponctuelle pour mettre à jour la capacité minimale au début de cet événement. Puis vous pouvez planifier une autre action pour rétablir le paramètre d'origine de la capacité minimale à la fin de l'événement. 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Sur la page **Clusters**, choisissez le cluster. 1. Sur la page des détails du cluster, dans la section **Services**, puis choisissez le service. La page de détails du service s’affiche. 1. Choisissez **Service Auto Scaling**. La page des stratégies s’affiche. 1. Choisissez **Actions planifiées**, puis **Créer**. La page **Créer une action planifiée** s’affiche. 1. Pour **Nom de l’action**, saisissez un nom unique. 1. Dans le champ **Fuseau horaire**, choisissez un fuseau horaire. Tous les fuseaux horaires répertoriés proviennent de la base de données des fuseaux horaires IANA. Pour plus d’informations, consultez la section [Liste des fuseaux horaires de la base de données tz](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). 1. Pour **Heure de début**, saisissez la **date** et l’**heure** de début de l’action. 1. Pour **Recurrence** (Récurrence), choisissez **Once** (Une fois). 1. Sous **Ajustements des tâches**, pour « Minimum », saisissez une valeur inférieure ou égale au nombre maximum de tâches. 1. Choisissez **Create Scheduled Action** (Créer une action planifiée). La page des stratégies s’affiche. 1. Configurez une deuxième action planifiée pour rétablir le nombre minimum de tâches à la configuration d’origine à la fin de l’événement. La mise à l’échelle prédictive ne peut mettre à l’échelle le nombre de tâches que lorsque la valeur que vous avez définie pour **Minimum** est inférieure aux valeurs prévues. **Pour créer deux actions planifiées pour des événements ponctuels (AWS CLI)** Pour AWS CLI créer les actions planifiées, utilisez la commande [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html). Par exemple, définissons une action planifiée pour maintenir une capacité minimale de trois instances pendant huit heures à partir du 19 mai à 17h00. Les commandes suivantes montrent comment implémenter ce scénario. La première commande [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) demande à Amazon EC2 Auto Scaling de mettre à jour la capacité minimale du groupe Auto Scaling spécifié à 17 h 00 UTC le 19 mai 2021. ``` aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-start \ --auto-scaling-group-name my-asg --start-time "2021-05-19T17:00:00Z" --minimum-capacity 3 ``` La deuxième commande indique à Amazon EC2 Auto Scaling de définir la capacité minimale du groupe à 1h00 UTC le 20 mai 2021. ``` aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-end \ --auto-scaling-group-name my-asg --start-time "2021-05-20T01:00:00Z" --minimum-capacity 1 ``` Après l'ajout de ces actions planifiées au groupe Auto Scaling, Amazon EC2 Auto Scaling effectue les opérations suivantes : + À 17h00 UTC le 19 mai 2021, la première action planifiée s'exécute. Si le groupe compte actuellement moins de trois instances, il passe à trois instances. Pendant ce temps et pendant les huit heures suivantes, Amazon EC2 Auto Scaling peut continuer à monter en puissance si la capacité prévue est supérieure à la capacité réelle ou si une stratégie de mise à l'échelle dynamique est en vigueur. + À 1h00 UTC le 20 mai 2021, la seconde action planifiée s'exécute. Cette action rétablit le paramètre d'origine de la capacité minimale à la fin de l'événement. ### Mise à l'échelle basée sur des planifications récurrentes Pour remplacer la prévision applicable à la même période chaque semaine, créez deux actions planifiées et fournissez la logique d'heure et de date à l'aide d'une expression cron. L'expression cron est constituée de cinq champs séparés par des espaces : [Minute] [Heure] [Jour\$1du\$1Mois] [Mois\$1de\$1Année] [Jour\$1de\$1Semaine]. Ces champs peuvent contenir toutes les valeurs autorisées, y compris des caractères spéciaux. Par exemple, l'expression cron suivante exécute l'action tous les mardis à 6h30. L'astérisque est utilisé comme caractère générique pour représenter toutes les valeurs d'un champ. ``` 30 6 * * 2 ``` ### Consultez aussi Pour plus d’informations sur la gestion des actions planifiées, consultez la section [Utilisez des actions planifiées pour faire évoluer les services Amazon ECS](service-autoscaling-schedulescaling.md). # Stratégie avancée de mise à l’échelle prédictive utilisant des métriques personnalisées pour Amazon ECS Dans une stratégie de mise à l’échelle prédictive, vous pouvez utiliser des métriques prédéfinies ou personnalisées. Les métriques personnalisées sont utiles lorsque les métriques prédéfinies (UC, mémoire, etc.) ne sont pas suffisantes pour décrire suffisamment la charge de votre application. Lorsque vous créez une politique de dimensionnement prédictif avec des métriques personnalisées, vous pouvez spécifier d'autres CloudWatch métriques fournies par AWS. Vous pouvez également spécifier des métriques que vous définissez et publiez vous-même. Vous pouvez également utiliser les mathématiques des métriques pour agréger et transformer les métriques existantes en une nouvelle série chronologique qui AWS n'est pas automatiquement suivie. Un exemple consiste à combiner les valeurs de vos données en calculant de nouvelles sommes ou moyennes, ce qu’on appelle l’*agrégation*. Les données résultantes sont appelées un *agrégat*. La section suivante contient les bonnes pratiques et des exemples de construction de la structure JSON pour la politique. ## Conditions préalables Pour ajouter des métriques personnalisées à votre politique de mise à l'échelle, vous devez disposer des autorisations `cloudwatch:GetMetricData`. Pour spécifier vos propres indicateurs au lieu des indicateurs AWS fournis, vous devez d'abord les publier sur CloudWatch. Pour plus d'informations, consultez la section [Publication de métriques personnalisées](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) dans le *guide de CloudWatch l'utilisateur Amazon*. Si vous publiez vos propres métriques, veillez à publier les points de données à une fréquence minimale de cinq minutes. Les points de données sont extraits CloudWatch en fonction de la durée de la période dont ils ont besoin. Par exemple, la spécification des métriques de charge utilise des métriques horaires pour mesurer la charge de votre application. CloudWatch utilise vos données métriques publiées pour fournir une valeur de données unique pour toute période d'une heure en agrégeant tous les points de données avec des horodatages correspondant à chaque période d'une heure. ## Bonnes pratiques Les bonnes pratiques suivantes peuvent vous aider à utiliser plus efficacement les métriques personnalisées : + La métrique la plus utile pour la spécification de la métrique de charge est une métrique qui représente la charge sur un groupe Auto Scaling dans son ensemble. + La métrique la plus utile pour la spécification de la métrique de mise à l’échelle est le débit moyen ou l’utilisation moyenne par tâche. + L'utilisation cible doit correspondre au type de métrique de mise à l'échelle. Pour une configuration de stratégie qui utilise l’utilisation de l’UC, il s’agit par exemple d’un pourcentage cible. + Si ces recommandations ne sont pas suivies, les valeurs futures prédites des séries temporelles seront probablement incorrectes. Pour vérifier que les données sont correctes, vous pouvez afficher les valeurs prévues dans la console. Sinon, après avoir créé votre politique de dimensionnement prédictif, inspectez les `LoadForecast` objets renvoyés par un appel à l'[GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_GetPredictiveScalingForecast.html)API. + Nous vous recommandons vivement de configurer la mise à l’échelle prédictive en mode « prévision uniquement » de manière à pouvoir évaluer les prévisions avant que la mise à l’échelle prédictive ne commence à s’appliquer activement. ## Limitations + Vous pouvez interroger des points de données de 10 métriques au maximum dans une spécification métrique. + Dans le cadre de cette limite, une expression compte pour une métrique. ## Résolution des problèmes liés à une stratégie de mise à l’échelle prédictive avec des métriques personnalisées Si un problème survient lors de l'utilisation de métriques personnalisées, nous vous recommandons d'effectuer les opérations suivantes : + Si vous rencontrez un problème lors d'un blue/green déploiement lors de l'utilisation d'une expression de recherche, assurez-vous d'avoir créé une expression de recherche qui recherche une correspondance partielle et non une correspondance exacte. Vérifiez également que la requête ne s’applique qu’aux groupes Auto Scaling exécutés dans l’application spécifique. Pour plus d'informations sur la syntaxe des expressions de recherche, consultez la section [Syntaxe des expressions de CloudWatch recherche](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/search-expression-syntax.html) dans le *guide de CloudWatch l'utilisateur Amazon*. + La [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)commande valide une expression lorsque vous créez votre politique de dimensionnement. Cependant, il est possible que cette commande ne parvienne pas à identifier la cause exacte des erreurs détectées. Pour résoudre les problèmes, corrigez les erreurs que vous recevez en réponse à une demande de [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html)commande. Vous pouvez également résoudre les problèmes liés à l'expression depuis la CloudWatch console. + Vous devez spécifier `false` pour `ReturnData` si `MetricDataQueries` spécifie la fonction SEARCH() seule sans une fonction mathématique comme SUM(). Cela est dû au fait que les expressions de recherche peuvent renvoyer plusieurs séries temporelles et qu'une spécification métrique basée sur une expression ne peut renvoyer qu'une seule séries temporelles. + Toutes les métriques impliquées dans une expression de recherche doivent avoir la même résolution. # Structure du JSON pour les métriques personnalisées de mise à l’échelle prédictive avec Amazon ECS La section suivante contient des exemples de configuration de la mise à l'échelle prédictive pour interroger des données CloudWatch. Il existe deux méthodes pour configurer cette option, qui affecteront le format utilisé pour créer le fichier JSON de votre politique de mise à l'échelle prédictive. Lorsque vous utilisez des mathématiques de métriques, le format du fichier JSON varie davantage en fonction des mathématiques de métriques effectuées. 1. Pour créer une politique qui obtient des données directement à partir d'autres CloudWatch indicateurs fournis par AWS ou sur lesquels vous publiez CloudWatch, voir[Exemple de politique de dimensionnement prédictif avec des mesures de charge et de dimensionnement personnalisées à l'aide du AWS CLI](#predictive-scaling-custom-metrics-example1). ## Exemple de politique de dimensionnement prédictif avec des mesures de charge et de dimensionnement personnalisées à l'aide du AWS CLI Pour créer une politique de dimensionnement prédictive avec des métriques de charge et de dimensionnement personnalisées avec le AWS CLI, stockez les arguments pour `--predictive-scaling-configuration` dans un fichier JSON nommé`config.json`. Vous commencez par ajouter des métriques personnalisées en remplaçant les valeurs remplaçables de l'exemple suivant par celles de vos métriques et de votre utilisation cible. ``` { "MetricSpecifications": [ { "TargetValue": 50, "CustomizedScalingMetricSpecification": { "MetricDataQueries": [ { "Id": "scaling_metric", "MetricStat": { "Metric": { "MetricName": "MyUtilizationMetric", "Namespace": "MyNameSpace", "Dimensions": [ { "Name": "MyOptionalMetricDimensionName", "Value": "MyOptionalMetricDimensionValue" } ] }, "Stat": "Average" } } ] }, "CustomizedLoadMetricSpecification": { "MetricDataQueries": [ { "Id": "load_metric", "MetricStat": { "Metric": { "MetricName": "MyLoadMetric", "Namespace": "MyNameSpace", "Dimensions": [ { "Name": "MyOptionalMetricDimensionName", "Value": "MyOptionalMetricDimensionValue" } ] }, "Stat": "Sum" } } ] } } ] } ``` Pour plus d'informations, consultez le [MetricDataQuery](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MetricDataQuery.html)manuel *Amazon EC2 Auto Scaling API Reference*. **Note** Voici quelques ressources supplémentaires qui peuvent vous aider à trouver des noms de métriques, des espaces de noms, des dimensions et des statistiques pour les CloudWatch métriques : Pour plus d'informations sur les métriques disponibles pour les AWS services, consultez les [AWS services qui publient CloudWatch des métriques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html) dans le *guide de CloudWatch l'utilisateur Amazon*. Pour obtenir le nom, l'espace de noms et les dimensions exacts (le cas échéant) d'une CloudWatch métrique comportant le AWS CLI, consultez [list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html). Pour créer cette politique, exécutez la [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)commande en utilisant le fichier JSON comme entrée, comme illustré dans l'exemple suivant. ``` aws application-autoscaling put-scaling-policy --policy-name my-predictive-scaling-policy \ --auto-scaling-group-name my-asg --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json ``` Si elle aboutit, cette commande renvoie l'Amazon Resource Name (ARN) de la stratégie. ``` { "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-predictive-scaling-policy", "Alarms": [] } ``` # Utiliser des expressions mathématiques de métrique La section suivante fournit des informations sur l’utilisation des mathématiques de métriques avec les stratégies de mise à l’échelle prédictive dans votre stratégie. ## Comprendre les mathématiques de métrique Si vous souhaitez simplement agréger des données métriques existantes, les mathématiques CloudWatch métriques vous évitent les efforts et les coûts liés à la publication d'une autre métrique dans CloudWatch. Vous pouvez utiliser n'importe quelle métrique qui AWS fournit, et vous pouvez également utiliser des métriques que vous définissez dans le cadre de vos applications. Pour plus d'informations, consultez la section [Utilisation des mathématiques métriques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) dans le *guide de CloudWatch l'utilisateur Amazon*. Si vous choisissez d'utiliser une expression mathématique de métrique dans votre politique de mise à l'échelle prédictive, tenez compte des points suivants : + Les opérations mathématiques métriques utilisent les points de données d'une combinaison unique de keys/value paires de métriques de nom, d'espace de noms et de dimensions. + Vous pouvez utiliser n'importe quel opérateur arithmétique (\$1 - \$1/^), fonction statistique (telle que AVG ou SUM) ou toute autre fonction compatible. CloudWatch + Vous pouvez utiliser à la fois des métriques et les résultats d'autres expressions mathématiques dans les formules de l'expression mathématique. + Vos expressions mathématiques de métrique peuvent être composées de différentes agrégations. Cependant, une bonne pratique pour le résultat final de l'agrégation consiste à utiliser `Average` pour la métrique de mise à l'échelle et `Sum` pour la métrique de charge. + Toutes les expressions utilisées dans une spécification de métrique doivent finalement retourner une seule séries temporelles. Pour utiliser les mathématiques de métrique, procédez comme suit : + Choisissez un ou plusieurs CloudWatch indicateurs. Créez ensuite l'expression. Pour plus d'informations, consultez la section [Utilisation des mathématiques métriques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) dans le *guide de CloudWatch l'utilisateur Amazon*. + Vérifiez que l'expression mathématique de la métrique est valide à l'aide de la CloudWatch console ou de l' CloudWatch[GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)API. ## Exemple de politique de mise à l'échelle prédictive qui combine des métriques à l'aide des mathématiques de métriques (AWS CLI) Parfois, au lieu de spécifier la métrique directement, vous devrez d'abord traiter ses données d'une certaine manière. Par exemple, une application peut extraire le travail d'une file d'attente Amazon SQS et vous souhaitez utiliser le nombre d'éléments dans la file d'attente comme critère de mise à l'échelle prédictive. Le nombre de messages dans la file d'attente ne définit pas uniquement le nombre d'instances dont vous avez besoin. Par conséquent, un travail supplémentaire est nécessaire pour créer une métrique qui peut être utilisée pour calculer le backlog par instance. Ce qui suit est un exemple de politique de mise à l'échelle prédictive pour ce scénario. Il spécifie les métriques de mise à l'échelle et de charge qui sont basées sur la métrique `ApproximateNumberOfMessagesVisible` d'Amazon SQS, qui est le nombre de messages disponibles pour la récupération de la file d'attente. Il utilise également la métrique `GroupInServiceInstances` d'Amazon EC2 Auto Scaling et une expression mathématique pour calculer le backlog par instance pour la métrique de mise à l'échelle. ``` aws application-autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \ --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json --service-namespace ecs \ --resource-id service/MyCluster/test \ "MetricSpecifications": [ { "TargetValue": 100, "CustomizedScalingMetricSpecification": { "MetricDataQueries": [ { "Label": "Get the queue size (the number of messages waiting to be processed)", "Id": "queue_size", "MetricStat": { "Metric": { "MetricName": "ApproximateNumberOfMessagesVisible", "Namespace": "AWS/SQS", "Dimensions": [ { "Name": "QueueName", "Value": "my-queue" } ] }, "Stat": "Sum" }, "ReturnData": false }, { "Label": "Get the group size (the number of running instances)", "Id": "running_capacity", "MetricStat": { "Metric": { "MetricName": "GroupInServiceInstances", "Namespace": "AWS/AutoScaling", "Dimensions": [ { "Name": "AutoScalingGroupName", "Value": "my-asg" } ] }, "Stat": "Sum" }, "ReturnData": false }, { "Label": "Calculate the backlog per instance", "Id": "scaling_metric", "Expression": "queue_size / running_capacity", "ReturnData": true } ] }, "CustomizedLoadMetricSpecification": { "MetricDataQueries": [ { "Id": "load_metric", "MetricStat": { "Metric": { "MetricName": "ApproximateNumberOfMessagesVisible", "Namespace": "AWS/SQS", "Dimensions": [ { "Name": "QueueName", "Value": "my-queue" } ], }, "Stat": "Sum" }, "ReturnData": true } ] } } ] } ``` L'exemple renvoie l'ARN de la politique. ``` { "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-sqs-custom-metrics-policy", "Alarms": [] } ``` # Interconnexion des services Amazon ECS Les applications qui s'exécutent dans le cadre de tâches Amazon ECS ont souvent besoin de recevoir des connexions depuis Internet ou de se connecter à d'autres applications exécutées dans les services Amazon ECS. Si vous avez besoin de connexions externes depuis Internet, nous vous recommandons d'utiliser Elastic Load Balancing. Pour plus d'informations sur l'équilibrage de charge intégrée, consultez [Utilisation de l’équilibrage de charge pour répartir le trafic des services Amazon ECS](service-load-balancing.md). Si vous avez besoin d'une application pour vous connecter à d'autres applications qui s'exécutent dans les services Amazon ECS, Amazon ECS propose les méthodes suivantes pour le faire sans équilibreur de charge : + *Amazon ECS Service Connect* Nous recommandons Service Connect, qui fournit une configuration Amazon ECS pour la découverte de service, la connectivité et la surveillance du trafic. Avec Service Connect, vos applications peuvent utiliser des noms abrégés et des ports standard pour se connecter aux services Amazon ECS dans le même cluster ou à d'autres clusters, y compris entre VPCs ceux-ci Région AWS. Lorsque vous utilisez Service Connect, Amazon ECS gère toutes les étapes de la découverte de services : création des noms susceptibles d’être découverts, gestion dynamique des entrées pour chaque tâche au démarrage et à l’arrêt des tâches, exécution d’un agent dans chaque tâche configuré pour découvrir les noms. Votre application peut rechercher les noms en utilisant les fonctionnalités standard pour les noms DNS et en établissant des connexions. Si votre application le fait déjà, vous n’avez pas besoin de modifier votre application pour utiliser Service Connect. Vous fournissez la configuration complète dans chaque définition de service et de tâche. Amazon ECS gère les modifications apportées à cette configuration lors de chaque déploiement de service, afin de garantir que toutes les tâches d’un déploiement se comportent de la même manière. Par exemple, un problème courant avec le DNS en tant que découverte de service est le contrôle d’une migration. Si vous modifiez un nom DNS pour qu’il pointe vers les nouvelles adresses IP de remplacement, le délai TTL maximal peut être nécessaire avant que tous les clients commencent à utiliser le nouveau service. Avec Service Connect, le déploiement du client met à jour la configuration en remplaçant les tâches du client. Vous pouvez configurer le disjoncteur de déploiement et toute autre configuration de déploiement pour affecter les modifications de Service Connect de la même manière que pour tout autre déploiement. Pour de plus amples informations, veuillez consulter [Utilisation de Service Connect pour connecter des services Amazon ECS avec des noms abrégés](service-connect.md). + *Découverte du service Amazon ECS* Une autre approche de service-to-service communication est la communication directe à l'aide de la découverte de services. Dans cette approche, vous pouvez utiliser l’intégration de la découverte de service AWS Cloud Map avec Amazon ECS. À l'aide de la découverte de services, Amazon ECS synchronise la liste des tâches lancées avec AWS Cloud Map, ce qui permet de conserver un nom d'hôte DNS qui correspond aux adresses IP internes d'une ou de plusieurs tâches provenant de ce service en particulier. D’autres services au sein d’Amazon VPC peuvent utiliser ce nom d’hôte DNS pour envoyer le trafic directement vers un autre conteneur en utilisant son adresse IP interne. Cette approche de service-to-service communication permet une faible latence. Il n’y a aucun composant supplémentaire entre les conteneurs. Le trafic passe directement d’un conteneur à l’autre. Cette approche convient lorsque vous utilisez le mode réseau `awsvpc`, où chaque tâche possède sa propre adresse IP unique. La plupart des logiciels ne prennent en charge que l’utilisation d’enregistrements DNS `A`, qui se résolvent directement en adresses IP. Lorsque vous utilisez le mode réseau `awsvpc`, l’adresse IP de chaque tâche est un enregistrement `A`. Toutefois, si vous utilisez le mode réseau `bridge`, plusieurs conteneurs peuvent partager la même adresse IP. En outre, les mappages de ports dynamiques entraînent l’attribution aléatoire de numéros de port aux conteneurs sur cette adresse IP unique. À ce stade, un enregistrement `A` ne suffit plus pour la découverte de service. Vous devez également utiliser un enregistrement `SRV`. Ce type d’enregistrement permet de suivre à la fois les adresses IP et les numéros de port, mais nécessite que vous configuriez les applications de manière appropriée. Certaines applications prédéfinies que vous utilisez peuvent ne pas prendre en charge les enregistrements `SRV`. Un autre avantage du mode réseau `awsvpc` est que vous disposez d’un groupe de sécurité unique pour chaque service. Vous pouvez configurer ce groupe de sécurité pour autoriser les connexions entrantes provenant uniquement des services en amont spécifiques qui doivent communiquer avec ce service. Le principal inconvénient de la service-to-service communication directe utilisant la découverte de services est que vous devez implémenter une logique supplémentaire pour effectuer de nouvelles tentatives et faire face aux échecs de connexion. Les enregistrements DNS ont une période time-to-live (TTL) qui contrôle la durée pendant laquelle ils sont mis en cache. Il faut un certain temps pour que l’enregistrement DNS soit mis à jour et que le cache expire afin que vos applications puissent récupérer la dernière version de l’enregistrement DNS. Il se peut donc que votre application finisse par résoudre l’enregistrement DNS pour qu’il pointe vers un autre conteneur qui n’existe plus. Votre application doit gérer les nouvelles tentatives et avoir une logique lui permettant d’ignorer les mauvais dorsaux. Pour de plus amples informations, consultez [Utilisation de la découverte de service pour connecter les services Amazon ECS avec des noms DNS](service-discovery.md). + *Amazon VPC Lattice* Amazon VPC Lattice est un service de mise en réseau d'applications géré que les clients d'Amazon ECS utilisent pour observer, sécuriser et surveiller les applications créées à travers des services AWS informatiques et des comptes sans avoir à modifier leur code. VPCs VPC Lattice utilise des groupes cibles, qui sont un ensemble de ressources de calcul. Ces cibles exécutent votre application ou votre service et peuvent être des instances Amazon EC2, des adresses IP, des fonctions Lambda et des équilibreurs de charge d'application. En associant leurs services Amazon ECS à un groupe cible VPC Lattice, les clients peuvent désormais activer les tâches Amazon ECS en tant que cibles IP dans VPC Lattice. Amazon ECS enregistre automatiquement les tâches auprès du groupe cible VPC Lattice lorsque les tâches du service enregistré sont lancées. Pour de plus amples informations, veuillez consulter [Utilisez Amazon VPC Lattice pour connecter, observer et sécuriser vos services Amazon ECS](ecs-vpc-lattice.md). ## Tableau de compatibilité des modes réseau Le tableau suivant décrit la compatibilité entre ces options et les modes réseau des tâches. Dans le tableau, le terme « client » fait référence à l'application qui établit les connexions depuis une tâche Amazon ECS. **** | Options d'interconnexion | Pontée | `awsvpc` | Host (Hôte) | | --- | --- | --- | --- | | Découverte de service | oui, mais nécessite que les clients soient au courant des enregistrements SRV dans le DNS sans hostPort. | oui | oui, mais nécessite que les clients soient au courant des enregistrements SRV dans le DNS sans hostPort. | | Service Connect | oui | oui | non | | Treillis en VPC | oui | oui | oui | # Utilisation de Service Connect pour connecter des services Amazon ECS avec des noms abrégés Amazon ECS Service Connect permet de gérer les service-to-service communications en tant que configuration Amazon ECS. Il crée à la fois la découverte de services et un maillage de services dans Amazon ECS. Il fournit la configuration complète de chaque service que vous gérez par le biais de déploiements de services, une manière unifiée de faire référence à vos services dans des espaces de noms qui ne dépendent pas de la configuration DNS du VPC, ainsi que des métriques et des journaux normalisés pour surveiller toutes vos applications. Service Connect n’interconnecte que les services. Le schéma suivant montre un exemple de réseau Service Connect avec deux sous-réseaux dans le VPC et deux services. Un service client qui s'exécute WordPress avec une tâche dans chaque sous-réseau. Un service de serveur qui exécute MySQL avec une tâche dans chaque sous-réseau. Les deux services sont hautement disponibles et résilients aux problèmes liés aux tâches et aux zones de disponibilité, car chaque service exécute plusieurs tâches réparties sur deux sous-réseaux. Les flèches continues indiquent une connexion depuis WordPress MySQL. Par exemple, une commande `mysql --host=mysql` CLI exécutée depuis le WordPress conteneur dans la tâche avec l'adresse IP`172.31.16.1`. La commande utilise le nom abrégé `mysql` du port par défaut de MySQL. Ce nom et ce port se connectent au proxy Service Connect dans le cadre de la même tâche. Le proxy utilisé dans la WordPress tâche utilise l'équilibrage de charge circulaire et toutes les informations relatives aux défaillances précédentes pour détecter les valeurs aberrantes afin de sélectionner la tâche MySQL à laquelle se connecter. Comme le montrent les flèches pleines du schéma, le proxy se connecte au deuxième proxy de la tâche MySQL avec l'adresse IP `172.31.16.2`. Le second proxy se connecte au serveur MySQL local dans le cadre de la même tâche. Les deux proxys indiquent les performances de connexion qui sont visibles dans les graphiques des CloudWatch consoles Amazon ECS et Amazon afin que vous puissiez obtenir les mesures de performance de toutes sortes d'applications de la même manière. ![\[Exemple de réseau Service Connect affichant des services de haute disponibilité minimale\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/serviceconnect.png) Les services suivants sont utilisés avec Service Connect. **nom du port** Configuration de définition de tâche Amazon ECS qui attribue un nom à un mappage de port particulier. Cette configuration est uniquement utilisée par Amazon ECS Service Connect. **alias du client** Configuration du service Amazon ECS qui attribue le numéro de port utilisé dans le point de terminaison. L'alias du client peut également attribuer le nom DNS du point de terminaison, en remplaçant le nom de découverte. Si aucun nom de découverte n'est fourni dans le service Amazon ECS, le nom d'alias du client remplace le nom du port comme nom de point de terminaison. Pour des exemples de points de terminaison, consultez la définition de *point de terminaison*. Plusieurs alias client peuvent être attribués à un service Amazon ECS. Cette configuration est uniquement utilisée par Amazon ECS Service Connect. **nom de découverte** Nom intermédiaire facultatif que vous pouvez créer pour un port spécifié à partir de la définition de tâche. Ce nom est utilisé pour créer un AWS Cloud Map service. Si ce nom n'est pas fourni, le nom de port indiqué dans la définition de tâche est utilisé. Plusieurs noms de découverte peuvent être attribués à un port spécifique d'un service Amazon ECS. Cette configuration est uniquement utilisée par Amazon ECS Service Connect. AWS Cloud Map les noms de service doivent être uniques au sein d'un espace de noms. En raison de cette limitation, vous ne pouvez avoir qu'une seule configuration Service Connect sans nom de découverte pour une définition de tâche particulière dans chaque espace de noms. **point de terminaison** URL permettant de se connecter à une API ou à un site Web. L'URL contient le protocole, un nom DNS et le port. Pour plus d'informations sur les points de terminaison en général, veuillez consulter [point de terminaison](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#endpoint) dans le *glossaire AWS * de la Référence générale d'Amazon Web Services(langue française non garantie). Service Connect crée des points de terminaison qui se connectent aux services Amazon ECS et configure les tâches des services Amazon ECS pour se connecter aux points de terminaison. L'URL contient le protocole, un nom DNS et le port. Vous sélectionnez le protocole et le nom du port dans la définition de la tâche, car le port doit correspondre à l'application qui se trouve dans l'image du conteneur. Dans le service, vous sélectionnez chaque port par son nom et vous pouvez attribuer le nom DNS. Si vous ne spécifiez pas de nom DNS dans la configuration du service Amazon ECS, le nom de port indiqué dans la définition de tâche est utilisé par défaut. Par exemple, un point de terminaison Service Connect pourrait être `http://blog:80`, `grpc://checkout:8080` ou `http://_db.production.internal:99`. **Service Service Connect** Configuration d'un point de terminaison unique dans un service Amazon ECS. Cela fait partie de la configuration de Service Connect, qui se compose d'une seule ligne dans la **configuration de Service Connect et du nom de découverte** dans la console, ou d'un objet dans la liste `services` de la configuration JSON d'un service Amazon ECS. Cette configuration est uniquement utilisée par Amazon ECS Service Connect. Pour plus d'informations, consultez le [ServiceConnectService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)manuel Amazon Elastic Container Service API Reference. **espace de nom** Nom abrégé ou Amazon Resource Name (ARN) complet de l'espace de AWS Cloud Map noms à utiliser avec Service Connect. L'espace de noms doit être Région AWS identique à celui du service et du cluster Amazon ECS. Le type d'espace de noms dans AWS Cloud Map n'affecte pas Service Connect. L'espace de noms peut être partagé avec votre Compte AWS using AWS Resource Access Manager (AWS RAM) dans la mesure où Régions AWS il AWS RAM est disponible dans. Pour plus d’informations sur les espaces de noms partagés, consultez la section [Partage d’espaces de noms AWS Cloud Map entre comptes](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) dans le *Guide du développeur AWS Cloud Map *. Service Connect utilise l' AWS Cloud Map espace de noms comme un regroupement logique de tâches Amazon ECS qui communiquent entre elles. Chaque service Amazon ECS ne peut appartenir qu'à un seul espace de noms. Les services d’un espace de noms peuvent être répartis sur différents clusters Amazon ECS au sein d’une même Région AWS. Si l’espace de noms est un espace de noms partagé, les services peuvent être répartis entre le propriétaire et le consommateur de l’espace de noms Comptes AWS. Vous pouvez organiser librement les services selon n’importe quel critère. **service client** Un service Amazon ECS qui exécute une application client réseau. Un espace de noms doit être configuré pour ce service. Chaque tâche du service peut découvrir et se connecter à tous les points de terminaison de l'espace de noms via un conteneur de proxy Service Connect. Si l'un des conteneurs de la tâche doit se connecter à un point de terminaison à partir d'un service situé dans un espace de noms, choisissez un service client. Si une application frontend, un proxy inverse ou une application d'équilibreur de charge reçoit du trafic externe via d'autres méthodes comme Elastic Load Balancing, elle peut utiliser ce type de configuration Service Connect. **service client-serveur** Service Amazon ECS qui exécute une application service réseau ou web. Un espace de noms et au moins un point de terminaison doivent être configurés pour ce service. Chaque tâche du service est accessible à l'aide des points de terminaison. Le conteneur de proxy Service Connect écoute le nom et le port du point de terminaison pour diriger le trafic vers les conteneurs d'applications de la tâche. Si l'un des conteneurs expose et écoute le trafic réseau sur un port, choisissez un service client-serveur. Ces applications n’ont pas besoin de se connecter à d’autres services client-serveur dans le même espace de noms, mais la configuration du client est nécessaire. Un dorsal, un intergiciel, une couche entreprise ou la plupart des microservices utilisent ce type de configuration Service Connect. Si vous souhaitez qu'une application frontend, un proxy inverse ou une application d'équilibreur de charge reçoive du trafic provenant d'autres services configurés avec Service Connect dans le même espace de noms, ces services doivent utiliser ce type de configuration Service Connect. La fonctionnalité Service Connect crée un réseau virtuel de services connexes. La même configuration de service peut être utilisée sur plusieurs espaces de noms différents pour exécuter des ensembles d'applications indépendants mais identiques. Service Connect définit le conteneur de proxy dans le service Amazon ECS. Ainsi, la même définition de tâche peut être utilisée pour exécuter des applications identiques dans différents espaces de noms avec des configurations Service Connect différentes. Chaque tâche réalisée par le service exécute un conteneur de proxy dans la tâche. Service Connect convient aux connexions entre les services Amazon ECS au sein du même espace de noms. Pour les applications suivantes, vous devez utiliser une méthode d'interconnexion supplémentaire pour vous connecter à un service Amazon ECS configuré avec Service Connect : + Tâches configurées dans d’autres espaces de noms + Tâches qui ne sont pas configurées pour Service Connect + Autres applications en dehors d’Amazon ECS Ces applications peuvent se connecter via le proxy Service Connect mais ne peuvent pas résoudre les noms des points de terminaison Service Connect. Pour que ces applications puissent résoudre les adresses IP des tâches Amazon ECS, vous devez utiliser une autre méthode d’interconnexion. **Topics** + [Tarification](#service-connect-pricing) + [Composants d’Amazon ECS Service Connect](service-connect-concepts-deploy.md) + [Vue d’ensemble de la configuration d’Amazon ECS Service Connect](service-connect-concepts.md) + [Amazon ECS Service Connect avec espaces de AWS Cloud Map noms partagés](service-connect-shared-namespaces.md) + [Journaux d'accès Amazon ECS Service Connect](service-connect-envoy-access-logs.md) + [Chiffrement du trafic Amazon ECS Service Connect](service-connect-tls.md) + [Configuration d'Amazon ECS Service Connect avec AWS CLI](create-service-connect.md) ## Tarification + La tarification d'Amazon ECS Service Connect varie selon que vous utilisez AWS Fargate ou non l'infrastructure Amazon EC2 pour héberger vos charges de travail conteneurisées. Lorsque vous utilisez Amazon ECS sur AWS Outposts, la tarification suit le même modèle que lorsque vous utilisez directement Amazon EC2. Pour plus d'informations, consultez [Tarification Amazon ECS](https://aws.amazon.com/ecs/pricing). + L’utilisation d’Amazon ECS Service Connect n’entraîne pas de frais supplémentaires. + Il n'y a aucun frais d' AWS Cloud Map utilisation supplémentaire lorsqu'il est utilisé par Service Connect. + Les clients paient pour les ressources de calcul utilisées par Amazon ECS Service Connect, notamment le vCPU et la mémoire. Étant donné que l’agent Amazon ECS Service Connect s’exécute dans une tâche client, son utilisation n’entraîne pas de frais supplémentaires. Les ressources de tâche sont partagées entre la charge de travail du client et l’agent Amazon ECS Service Connect. + Lorsqu'ils utilisent la fonctionnalité de chiffrement du trafic Amazon ECS Service Connect avec AWS CA privée, les clients paient pour l'autorité de certification privée qu'ils créent et pour chaque certificat TLS émis. Pour plus d’informations, consultez la section [Tarification AWS Autorité de certification privée](https://aws.amazon.com/private-ca/pricing/). Pour estimer le coût mensuel des certificats TLS, les clients doivent connaître le nombre de services Amazon ECS sur lesquels le protocole TLS est activé, le multiplier par le coût du certificat, puis le multiplier par six. Amazon ECS Service Connect faisant automatiquement alterner les certificats TLS tous les cinq jours, six certificats sont émis par service Amazon ECS, par mois, en moyenne. # Composants d’Amazon ECS Service Connect Lorsque vous utilisez Amazon ECS Service Connect, vous configurez chaque service Amazon ECS pour exécuter une application serveur qui reçoit des requêtes réseau (service client-serveur) ou pour exécuter une application cliente qui fait les requêtes (service client). Lorsque vous vous préparez à utiliser Service Connect, commencez par un service client-serveur. Vous pouvez ajouter une configuration Service Connect à un nouveau service ou à un service existant. Amazon ECS crée un point de terminaison Service Connect dans l’espace de noms. En outre, Amazon ECS crée un nouveau déploiement dans le service pour remplacer les tâches en cours d'exécution. Les tâches existantes et les autres applications peuvent continuer à se connecter aux points de terminaison existants et aux applications externes. Si un service client-serveur ajoute des tâches par augmentation horizontale, les nouvelles connexions provenant des clients seront réparties de manière équilibrée entre toutes les tâches. Si un service client-serveur est mis à jour, les nouvelles connexions provenant des clients seront réparties de manière équilibrée entre les tâches de la nouvelle version. Les tâches existantes ne peuvent pas être résolues et se connecter au nouveau point de terminaison. Seules les nouvelles tâches disposant d’une configuration Service Connect dans le même espace de noms et qui commencent à s’exécuter après ce déploiement peuvent résoudre et se connecter à ce point de terminaison. Cela signifie que l'opérateur de l'application cliente détermine quand la configuration de son application change, même si l'opérateur de l'application serveur peut modifier sa configuration à tout moment. La liste des points de terminaison dans l’espace de noms peut changer à chaque fois qu’un service de cet espace de noms est déployé. Les tâches existantes et les tâches de remplacement continuent de se comporter comme elles le faisaient après le déploiement le plus récent. Considérez les exemples suivants. Tout d'abord, supposons que vous créez une application disponible sur Internet public dans un seul AWS CloudFormation modèle et une seule CloudFormation pile. La découverte publique et l'accessibilité doivent être créées en dernier lieu CloudFormation, y compris le service client frontal. Les services doivent être créés dans cet ordre afin d'éviter toute période pendant laquelle le service client frontend fonctionne et est accessible au public, alors que le backend ne l'est pas. Cela permet d'éliminer l'envoi de messages d'erreur au public pendant cette période. Dans AWS CloudFormation, vous devez utiliser le `dependsOn` pour indiquer CloudFormation que plusieurs services Amazon ECS ne peuvent pas être créés en parallèle ou simultanément. Vous devez ajouter la valeur `dependsOn` au service client frontal pour chaque service backend client-serveur auquel les tâches clientes se connectent. Ensuite, supposons qu'un service frontal existe sans configuration Service Connect. Les tâches se connectent à un service backend existant. Ajoutez d'abord une configuration Service Connect client-serveur au service backend, en utilisant le même nom dans le **DNS** ou `clientAlias` que celui utilisé par le frontend. Cela crée un nouveau déploiement, donc toutes les détections d'annulation du déploiement ou AWS Management Console AWS CLI, AWS SDKs et d'autres méthodes pour annuler et rétablir le service principal au déploiement et à la configuration précédents. Si vous êtes satisfait des performances et du comportement du service backend, ajoutez une configuration Service Connect client ou client-serveur au service frontal. Seules les tâches du nouveau déploiement utilisent le proxy Service Connect qui est ajouté à ces nouvelles tâches. Si vous rencontrez des problèmes avec cette configuration, vous pouvez revenir en arrière et revenir à votre configuration précédente en utilisant la détection de l'annulation du déploiement ou AWS Management Console d'autres méthodes pour restaurer et rétablir le service principal à son déploiement et à sa configuration précédents. AWS CLI AWS SDKs Si vous utilisez un autre système de découverte de services basé sur le DNS au lieu de Service Connect, toutes les applications frontales ou clientes commencent à utiliser de nouveaux points de terminaison et à modifier la configuration des points de terminaison après l'expiration du cache DNS local, ce qui prend généralement plusieurs heures. ## Réseaux Par défaut, le proxy Service Connect écoute sur le `containerPort` à partir du mappage de port de la définition de tâche. Les règles de votre groupe de sécurité doivent autoriser le trafic entrant (ingress) vers ce port depuis les sous-réseaux où les clients seront exécutés. Même si vous définissez un numéro de port dans la configuration du service Service Connect, cela ne modifie pas le port du service client-serveur écouté par le proxy Service Connect. Lorsque vous définissez ce numéro de port, Amazon ECS modifie le port du point de terminaison auquel les services clients se connectent, sur le proxy Service Connect au sein de ces tâches. Le proxy du service client se connecte au proxy du service client-serveur à l'aide du `containerPort`. Si vous souhaitez modifier le port sur lequel le proxy Service Connect écoute, modifiez le `ingressPortOverride` dans la configuration Service Connect du service client-serveur. Si vous modifiez ce numéro de port, vous devez autoriser le trafic entrant sur ce port utilisé par le trafic vers ce service. Le trafic que vos applications envoient aux services Amazon ECS configurés pour Service Connect nécessite qu'Amazon VPC et les sous-réseaux disposent de règles de table de routage et de règles d'ACL réseau qui autorisent les numéros de port `containerPort` et `ingressPortOverride` que vous utilisez. Vous pouvez utiliser Service Connect pour envoyer du trafic entre deux VPCs. Les mêmes exigences relatives aux règles de table de routage, au réseau ACLs et aux groupes de sécurité s'appliquent aux deux VPCs. Par exemple, deux clusters créent des tâches différentes VPCs. Un service dans chaque cluster est configuré pour utiliser le même espace de noms. Les applications dans ces deux services peuvent résoudre tous les points de terminaison de l'espace de noms sans aucune configuration DNS VPC. Cependant, les proxys ne peuvent pas se connecter à moins que les tables de routage VPC, le VPC ou les tables de routage de sous-réseau et le réseau ACLs VPC n'autorisent le trafic sur les numéros de port et. `containerPort` `ingressPortOverride` Pour les tâches utilisant le mode réseau `bridge`, vous devez créer un groupe de sécurité doté d’une règle entrante autorisant le trafic sur la plage de ports dynamiques supérieure. Attribuez ensuite le groupe de sécurité à toutes les instances EC2 du cluster Service Connect. ## Proxy Service Connect Si vous créez ou mettez à jour un service avec la configuration Service Connect, Amazon ECS ajoute un nouveau conteneur à chaque nouvelle tâche au moment où elle est lancée. Ce modèle d'utilisation d'un conteneur séparé est nommé `sidecar`. Ce conteneur n'est pas présent dans la définition de la tâche et vous ne pouvez pas le configurer. Amazon ECS gère la configuration des conteneurs dans le service. Cela vous permet de réutiliser les mêmes définitions de tâches entre plusieurs services, espaces de noms et tâches sans Service Connect. **Ressource de proxy** + Pour les définitions de tâches, vous devez définir les paramètres d’UC et de mémoire. Nous vous recommandons d’ajouter 256 unités d’UC supplémentaires et au moins 64 Mio de mémoire à votre UC et à votre mémoire de tâche pour le conteneur proxy Service Connect. Dans AWS Fargate, la quantité de mémoire la plus faible que vous pouvez définir est de 512 Mio de mémoire. Sur Amazon EC2, la mémoire de définition des tâches est requise. + Pour le service, vous définissez la configuration du journal dans la configuration Service Connect. + Si vous prévoyez que les tâches de ce service reçoivent plus de 500 demandes par seconde à leur charge maximale, nous vous recommandons d'ajouter 512 unités de processeur à votre processeur de tâches dans cette définition de tâche pour le conteneur de proxy Service Connect. + Si vous prévoyez de créer plus de 100 services Service Connect dans l'espace de noms ou 2 000 tâches au total pour tous les services Amazon ECS dans l'espace de noms, nous vous recommandons d'ajouter 128 Mio de mémoire à votre mémoire de tâche pour le conteneur de proxy Service Connect. Vous devez le faire dans chaque définition de tâche utilisée par tous les services Amazon ECS dans l'espace de noms. **Configuration du proxy** Vos applications se connectent au proxy dans le conteneur sidecar dans le cadre de la même tâche dans laquelle se trouve l'application. Amazon ECS configure la tâche et les conteneurs de telle sorte que les applications ne se connectent au proxy que lorsque l’application est connectée aux noms des points de terminaison dans le même espace de noms. Tout le reste du trafic n'utilise pas le proxy. L'autre trafic inclut les adresses IP du même VPC, les points de terminaison AWS de service et le trafic externe. **Équilibrage de charge** Service Connect configure le proxy pour qu'il utilise la stratégie alternée pour équilibrer la charge entre les tâches d'un point de terminaison Service Connect. Le proxy local présent dans la tâche d'où provient la connexion choisit l'une des tâches du service client-serveur qui fournit le point de terminaison. Prenons l'exemple d'une tâche exécutée WordPress dans un service configuré en tant que *service client* dans un espace de noms appelé *local*. Il existe un autre service avec deux tâches qui exécutent la base de données MySQL. Ce service est configuré pour fournir un point de terminaison appelé `mysql` via Service Connect dans le même espace de noms. Dans WordPress cette tâche, l' WordPress application se connecte à la base de données en utilisant le nom du point de terminaison. Les connexions à ce nom sont redirigées vers le proxy qui s’exécute dans un conteneur sidecar dans la même tâche. Le proxy peut ensuite se connecter à l'une ou l'autre des tâches MySQL en utilisant la stratégie alternée. Stratégies d'équilibrage de charge : alternance **Détection des valeurs aberrantes** Cette fonctionnalité utilise les données dont dispose le proxy concernant les échecs de connexion précédents pour éviter d'envoyer de nouvelles connexions aux hôtes dont les connexions ont échoué. Service Connect configure la fonctionnalité de détection des valeurs aberrantes du proxy afin de fournir des surveillances de l'état passives. En reprenant l’exemple précédent, le proxy peut se connecter à l’une ou l’autre des tâches MySQL. Si le proxy a établi plusieurs connexions à une tâche MySQL spécifique et que 5 connexions ou plus ont échoué au cours des 30 dernières secondes, le proxy évite cette tâche MySQL pendant 30 à 300 secondes. **Nouvelles tentatives** Service Connect configure le proxy pour qu'il tente à nouveau la connexion qui passe par le proxy et échoue, et la deuxième tentative évite d'utiliser l'hôte de la connexion précédente. Cela garantit que chaque connexion via Service Connect n'échoue pas pour des raisons ponctuelles. Nombre de nouvelles tentatives : 2 **Timeout** Service Connect configure le proxy pour qu'il attende au maximum que vos applications client-serveur répondent. La valeur de délai d’attente par défaut est de 15 secondes, mais elle peut être mise à jour. Paramètres facultatifs : **idleTimeout** : durée en secondes pendant laquelle une connexion reste active lorsqu’elle est au repos. Une valeur de `0` désactive `idleTimeout`. La valeur par défaut de `idleTimeout` pour `HTTP`/`HTTP2`/`GRPC` est de cinq minutes. La valeur par défaut de `idleTimeout` pour `TCP` est d’une heure. **perRequestTimeout**‐ Le temps d'attente pour que l'amont réponde avec une réponse complète par demande. Une valeur de `0` désactive `perRequestTimeout`. Ce paramètre ne peut être défini que lorsque le protocole `appProtocol` du conteneur d’application est `HTTP`/`HTTP2`/`GRPC`. La valeur par défaut est de 15 secondes. Si `idleTimeout` est défini sur une durée inférieure à `perRequestTimeout`, la connexion se ferme lorsque le `idleTimeout` est atteint et non le `perRequestTimeout`. ## Considérations Tenez compte des éléments suivants lorsque vous utilisez Service Connect : + Les tâches exécutées dans Fargate doivent utiliser la version de plateforme Linux Fargate `1.4.0` ou supérieure pour pouvoir utiliser Service Connect. + La version de l’agent Amazon ECS sur l’instance de conteneur doit être la version `1.67.2` ou supérieure. + Les instances de conteneur doivent exécuter la version `20230428` ou une version ultérieure d'AMI Amazon Linux 2023 optimisée pour Amazon ECS, ou la version `2.0.20221115` d'AMI Amazon Linux 2 optimisée pour Amazon ECS pour utiliser Service Connect. Ces versions disposent de l'agent Service Connect en plus de l'agent de conteneur Amazon ECS. Pour plus d'informations sur l'agent Service Connect, consultez [Amazon ECS Service Connect Agent](https://github.com/aws/amazon-ecs-service-connect-agent) sur GitHub. + Les instances de conteneur doivent disposer de l'autorisation `ecs:Poll` pour la ressource `arn:aws:ecs:region:0123456789012:task-set/cluster/*`. Si vous utilisez le `ecsInstanceRole`, vous n'avez pas besoin d'ajouter d'autorisations supplémentaires. La stratégie gérée par `AmazonEC2ContainerServiceforEC2Role` dispose de ces autorisations. Pour de plus amples informations, veuillez consulter [Rôle IAM d'instance de conteneur Amazon ECS](instance_IAM_role.md). + Les tâches qui utilisent le mode réseau `bridge` et utilisent Service Connect ne prennent pas en charge le paramètre de définition du conteneur `hostname`. + Les définitions de tâches doivent définir la limite de mémoire des tâches pour utiliser Service Connect. Pour de plus amples informations, veuillez consulter [Proxy Service Connect](#service-connect-concepts-proxy). + Les définitions de tâches qui définissent les limites de mémoire des conteneurs ne sont pas prises en charge. Vous pouvez définir des limites de mémoire de conteneur sur vos conteneurs, mais vous devez définir la limite de mémoire des tâches sur un nombre supérieur à la somme des limites de mémoire des conteneurs. Le processeur et la mémoire supplémentaires inclus dans les limites de tâches que vous n'allouez pas dans les limites de conteneur sont utilisés par le conteneur de proxy Service Connect et les autres conteneurs qui ne définissent pas de limites de conteneur. Pour de plus amples informations, veuillez consulter [Proxy Service Connect](#service-connect-concepts-proxy). + Vous pouvez configurer Service Connect pour utiliser n'importe quel AWS Cloud Map espace de noms de la même région qui se trouve dans la même région Compte AWS ou qui est partagé avec vous Compte AWS . AWS Resource Access Manager Pour plus d’informations sur l’utilisation d’espaces de nom partagés, consultez la section [Amazon ECS Service Connect avec espaces de AWS Cloud Map noms partagés](service-connect-shared-namespaces.md). + Chaque service ne peut appartenir qu’à un seul espace de noms. + Seules les tâches créées par les services sont prises en charge. + Tous les points de terminaison doivent être uniques dans un espace de noms. + Tous les noms de découverte doivent être uniques dans un espace de noms. + Vous devez redéployer les services existants avant que les applications puissent résoudre les nouveaux points de terminaison. Les nouveaux points de terminaison ajoutés à l'espace de noms après le déploiement le plus récent ne seront pas ajoutés à la configuration de la tâche. Pour de plus amples informations, veuillez consulter [Composants d’Amazon ECS Service Connect](#service-connect-concepts-deploy). + Service Connect ne supprime pas les espaces de noms lorsque les clusters sont supprimés. Vous devez supprimer les espaces de noms dans. AWS Cloud Map + Le trafic de l’Application Load Balancer est acheminé par défaut via l’agent Service Connect en mode réseau `awsvpc`. Si vous souhaitez que le trafic non lié au service contourne l’agent Service Connect, utilisez le paramètre `[ingressPortOverride](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)` dans la configuration de votre service Service Connect. + Service Connect avec TLS ne prend pas en charge le mode réseau `bridge`. Seul le mode réseau `awsvpc` est pris en charge. + En `awsvpc` mode, le proxy Service Connect transmet le trafic vers l' IPv4 hôte local `127.0.0.1` pour les services dans des IPv4 configurations à double pile ou uniquement. Pour les services en configuration « IPv6 -only », le proxy transmet le trafic vers l'hôte IPv6 local`::1`. Nous vous recommandons de configurer vos applications de manière à écouter les deux hôtes locaux pour une expérience fluide lorsqu'un service passe d'une configuration IPv4 -only ou dualstack à -only. IPv6 Pour plus d’informations, consultez [Options de mise en réseau des tâches Amazon ECS pour EC2](task-networking.md) et [Options de mise en réseau des tâches Amazon ECS pour Fargate](fargate-task-networking.md). **Service Connect ne prend pas en charge les fonctionnalités suivantes :** + Conteneurs Windows + HTTP 1.0 + Tâches autonomes + Services utilisant les types de déploiement blue/green alimenté par CodeDeploy et externe + L'instance de conteneur `External` pour Amazon ECS Anywhere n'est pas prise en charge par Service Connect. + PPv2 + Mode FIPS # Vue d’ensemble de la configuration d’Amazon ECS Service Connect Lorsque vous utilisez Service Connect, vous devez configurer certains paramètres dans vos ressources. Le tableau suivant décrit les paramètres de configuration pour les ressources Amazon ECS. | Emplacement des paramètres | Type d'application | Description | Obligatoire | | --- | --- | --- | --- | | Définition de tâche | Client | Aucune modification n'est disponible pour Service Connect dans les définitions des tâches du client. | N/A | | Définition de tâche | Client-serveur | Les serveurs doivent ajouter des champs de name aux ports dans les portMappings des conteneurs. Pour de plus amples informations, consultez [portMappings](task_definition_parameters.md#ContainerDefinition-portMappings). | Oui | | Définition de tâche | Client-serveur | Les serveurs peuvent éventuellement fournir un protocole d'application (par exemple, HTTP) pour recevoir des métriques spécifiques au protocole pour leurs applications serveur (par exemple, HTTP 5xx). | Non | | Définition des services | Client | Les services clients doivent ajouter une serviceConnectConfiguration pour configurer l'espace de noms à rejoindre. Cet espace de noms doit contenir tous les services de serveur que ce service doit découvrir. Pour de plus amples informations, veuillez consulter [serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration). | Oui | | Définition des services | Client-serveur | Les services de serveur doivent ajouter une serviceConnectConfiguration pour configurer les noms DNS, les numéros de port et l'espace de noms à partir desquels le service est disponible. Pour de plus amples informations, veuillez consulter [serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration). | Oui | | Cluster | Client | Les clusters peuvent ajouter un espace de noms Service Connect par défaut. Les nouveaux services du cluster héritent de l'espace de noms lorsque Service Connect est configuré dans un service. | Non | | Cluster | Client-serveur | Aucune modification n'est disponible pour Service Connect dans les clusters qui s'appliquent aux services de serveur. Les définitions de tâches de serveur et les services doivent définir la configuration correspondante. | N/A | **Vue d'ensemble des étapes de configuration de Service Connect** Les étapes suivantes présentent la configuration de Service Connect. **Important** Service Connect crée AWS Cloud Map des services dans votre compte. La modification manuelle de ces AWS Cloud Map ressources par le biais d' registering/deregistering instances, la modification des attributs d'instance ou la suppression d'un service peuvent entraîner un comportement inattendu pour le trafic de votre application ou pour les déploiements ultérieurs. Service Connect ne prend pas en charge les liens dans la définition des tâches. 1. Ajoutez des noms de port aux mappages de port dans vos définitions de tâches. Vous pouvez également identifier le protocole de couche 7 de l'application afin d'obtenir des métriques supplémentaires. 1. Créez un cluster avec un espace de AWS Cloud Map noms, utilisez un espace de noms partagé ou créez l'espace de noms séparément. Pour simplifier l’organisation, créez un cluster avec le nom que vous souhaitez pour l’espace de noms et spécifiez le même nom pour l’espace de noms. Dans ce cas, Amazon ECS crée un nouvel espace de noms HTTP avec la configuration nécessaire. Service Connect n’utilise ni ne crée de zones hébergées DNS dans Amazon Route 53. 1. Configurez les services pour créer des points de terminaison Service Connect dans l'espace de noms. 1. Déployez des services pour créer les points de terminaison. Amazon ECS ajoute un conteneur de proxy Service Connect à chaque tâche et crée les points de terminaison Service Connect dans AWS Cloud Map. Ce conteneur n'est pas configuré dans la définition de tâche, et cette dernière peut être réutilisée sans modification pour créer plusieurs services dans le même espace de noms ou dans plusieurs espaces de noms. 1. Déployez des applications clientes en tant que services pour vous connecter aux points de terminaison. Amazon ECS les connecte aux points de terminaison Service Connect par le proxy Service Connect dans chaque tâche. Les applications utilisent le proxy uniquement pour se connecter aux points de terminaison Service Connect. Il n'existe aucune configuration supplémentaire pour utiliser le proxy. Le proxy effectue un équilibrage de charge alterné, une détection des valeurs aberrantes et de nouvelles tentatives. Pour plus d'informations sur le proxy, veuillez consulter [Proxy Service Connect](service-connect-concepts-deploy.md#service-connect-concepts-proxy). 1. Surveillez le trafic via le proxy Service Connect sur Amazon CloudWatch. ## Configuration du cluster Vous pouvez définir un espace de noms par défaut pour Service Connect lorsque vous créez ou mettez à jour le cluster. Le nom de l'espace de noms que vous spécifiez par défaut peut se trouver soit dans le même Région AWS compte, soit dans le même Région AWS et partagé par un autre utilisateur Compte AWS . AWS Resource Access Manager Si vous créez un cluster et que vous spécifiez un espace de noms Service Connect par défaut, le cluster attend dans l'état `PROVISIONING` pendant qu'Amazon ECS crée l'espace de noms. Vous pouvez voir un `attachment` dans l'état du cluster qui indique l'état de l'espace de noms. Les pièces jointes ne sont pas affichées par défaut dans le AWS CLI, vous devez les ajouter `--include ATTACHMENTS` pour les voir. Si vous souhaitez utiliser un espace de noms partagé avec vos Compte AWS utilisateurs AWS RAM, spécifiez l'Amazon Resource Name (ARN) de l'espace de noms dans la configuration du cluster. Pour plus d'informations sur les AWS Cloud Map espaces de noms partagés, consultez[Amazon ECS Service Connect avec espaces de AWS Cloud Map noms partagés](service-connect-shared-namespaces.md). ## Configuration du service Service Connect est conçu pour nécessiter une configuration minimale. Vous devez définir un nom pour chaque mappage de port que vous souhaitez utiliser avec Service Connect dans la définition de tâche. Dans le service, vous devez activer Service Connect et sélectionner un espace de noms dans votre espace de noms Compte AWS ou un espace de noms partagé pour créer un service client. Pour créer un service client-serveur, vous devez ajouter une configuration de service Service Connect unique qui correspond au nom de l'un des mappages de port. Amazon ECS réutilise le numéro de port et le nom de port figurant dans la définition de tâche pour définir le service et le point de terminaison Service Connect. Pour remplacer ces valeurs, vous pouvez utiliser les autres paramètres **Discovery** (Découverte), **DNS** et **Port** dans la console ou `discoveryName` et `clientAliases`, respectivement, dans l'API Amazon ECS. ## Configuration initiale du Health Check Service Connect garantit l'intégrité des tâches avant d'acheminer le trafic vers celles-ci. Lorsqu'une tâche est lancée (lors des déploiements, du dimensionnement ou des remplacements), Service Connect surveille l'état de votre tâche pour s'assurer qu'elle est prête à accepter du trafic. Vous devez définir des contrôles de santé pour le conteneur essentiel dans votre définition de tâche pour activer ce comportement. Le comportement du bilan de santé initial tient compte des retards potentiels avant d'atteindre l'état où une tâche est prête à accepter du trafic : + Si une tâche l'est`HEALTHY`, elle est immédiatement disponible pour le trafic. + Si l'état d'une tâche est bon`UNKNOWN`, Service Connect suit la configuration de vérification de l'état des conteneurs (voir[Surveillance de l'état](task_definition_parameters.md#container_definition_healthcheck)) des conteneurs essentiels de la tâche afin de calculer un délai d'attente, jusqu'à`8 minutes`, avant de le mettre à la disposition du trafic, même s'il persiste`UNKNOWN`. + Si c'est le cas`UNHEALTHY`, Amazon ECS peut lancer des tâches de remplacement. Si aucune tâche saine n'est disponible, votre déploiement peut être annulé en fonction de la configuration de votre service. Pour l'ensemble du trafic en cours, Service Connect utilise des contrôles de santé passifs basés sur la détection des valeurs aberrantes afin d'acheminer le trafic de manière efficace. # Amazon ECS Service Connect avec espaces de AWS Cloud Map noms partagés Amazon ECS Service Connect prend en charge l'utilisation d' AWS Cloud Map espaces de noms partagés sur plusieurs sites Comptes AWS au sein d'un même Région AWS site. Cette fonctionnalité vous permet de créer des applications distribuées dans lesquelles des services exécutés dans différents environnements Comptes AWS peuvent se découvrir et communiquer entre eux via Service Connect. Les espaces de noms partagés sont gérés à l’aide d’ AWS Resource Access Manager (AWS RAM), qui permet un partage sécurisé des ressources entre comptes. *Pour plus d'informations sur les espaces de noms partagés, consultez la section [Partage d'espaces de AWS Cloud Map noms entre comptes](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) dans le Guide du AWS Cloud Map développeur.* **Important** Vous devez utiliser l’autorisation gérée `AWSRAMPermissionCloudMapECSFullPermission` pour partager l’espace de noms afin que Service Connect fonctionne correctement avec l’espace de noms. Lorsque vous utilisez des AWS Cloud Map espaces de noms partagés avec Service Connect, les services de plusieurs utilisateurs Comptes AWS peuvent participer au même espace de noms de service. Cela est particulièrement utile pour les organisations qui en ont plusieurs et Comptes AWS qui ont besoin de maintenir service-to-service la communication au-delà des limites de leurs comptes tout en préservant la sécurité et l'isolation. **Note** Pour communiquer avec des services situés dans des environnements différents VPCs, vous devez configurer la connectivité inter-VPC. Cela peut être réalisé à l’aide d’une connexion d’appairage de VPC. Pour plus d’informations, consultez la section [Création ou suppression d’une connexion d’appairage de VPC](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html) dans le *Guide d’appairage de VPC Amazon Virtual Private Cloud*. # Utilisation d' AWS Cloud Map espaces de noms partagés avec Amazon ECS Service Connect La configuration d' AWS Cloud Map espaces de noms partagés pour Service Connect implique les étapes suivantes : le propriétaire de l'espace de noms crée l'espace de noms, le propriétaire le partage via AWS Resource Access Manager (AWS RAM), le consommateur accepte le partage des ressources et le consommateur configure Service Connect pour utiliser l'espace de noms partagé. ## Étape 1 : Création de l'espace de AWS Cloud Map noms Le propriétaire de l'espace de noms crée un AWS Cloud Map espace de noms qui sera partagé avec d'autres comptes. **Pour créer un espace de noms à partager à l'aide du AWS Management Console** 1. Ouvrez la AWS Cloud Map console à l'adresse [https://console.aws.amazon.com/cloudmap/](https://console.aws.amazon.com/cloudmap/). 1. Choisissez **Create namespace (Créer un espace de noms)**. 1. Saisissez un **Nom d’espace de noms**. Ce nom sera utilisé par les services sur tous les comptes participants. 1. Pour **Type d’espace de noms**, choisissez le type adapté à votre cas d’utilisation : + **Appels d’API** : espaces de noms HTTP pour la découverte de service sans fonctionnalité DNS. + **Appels d'API et requêtes DNS dans VPCs** des espaces de noms DNS privés pour la découverte de services avec des requêtes DNS privées dans un VPC. + **Appels d’API et requêtes DNS publiques** : espaces de noms DNS publics pour la découverte de service avec des requêtes DNS publiques. 1. Choisissez **Create namespace (Créer un espace de noms)**. ## Étape 2 : partager l'espace de noms en utilisant AWS RAM Le propriétaire de l'espace de noms utilise AWS RAM pour partager l'espace de noms avec d'autres. Comptes AWS **Pour partager un espace de noms à l'aide de la console AWS RAM** 1. Ouvrez la AWS RAM console à l'adresse [https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/). 1. Choisissez **Créer une ressource**. 1. Sous **Nom**, saisissez un nom descriptif pour le partage de ressources. 1. Dans la section **Ressources** : 1. Pour **Type de ressource**, choisissez **Espaces de noms Cloud Map**. 1. Sélectionnez l’espace de noms que vous avez créé à l’étape précédente. 1. Dans la section **Autorisations gérées**, spécifiez **AWSRAMPermissionCloudMapECSFullAutorisation**. **Important** Vous devez utiliser l’autorisation gérée `AWSRAMPermissionCloudMapECSFullPermission` pour partager l’espace de noms afin que Service Connect fonctionne correctement avec l’espace de noms. 1. Dans la section **Principaux**, spécifiez l’ Comptes AWS avec lequel vous souhaitez partager l’espace de noms. Vous pouvez saisir un compte IDs ou une unité organisationnelle IDs. 1. Choisissez **Créer une ressource**. ## Étape 3 : accepter le partage de ressources Les comptes consommateurs d’espaces de noms doivent accepter l’invitation de partage de ressources pour utiliser l’espace de noms partagé. **Pour accepter une invitation de partage de ressources à l'aide de la AWS RAM console** 1. Dans le compte client, ouvrez la AWS RAM console à l'adresse [https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/). 1. Dans le volet de navigation, choisissez **Partagé avec moi**, puis **Partages de ressources**. 1. Sélectionnez l’invitation au partage de ressources, puis choisissez **Accepter le partage de ressources**. 1. Après avoir accepté, notez l’ARN de l’espace de noms partagé dans les détails de la ressource. Vous utiliserez cet ARN lors de la configuration des services Service Connect. ## Étape 4 : configurer un service Amazon ECS avec un espace de noms partagé Après avoir accepté l’espace de noms partagé, le consommateur de l’espace de noms peut configurer les services Amazon ECS pour utiliser l’espace de noms partagé. La configuration est similaire à l’utilisation d’un espace de noms normal, mais vous devez spécifier l’ARN de l’espace de noms au lieu du nom. Pour une procédure détaillée de création de service, consultez la section [Création d’un déploiement de mise à jour propagée Amazon ECS](create-service-console-v2.md). **Pour créer un service avec un espace de noms partagé à l'aide du AWS Management Console** 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Sur la page **Clusters**, sélectionnez le cluster dans lequel créer le service. 1. Sous **Services**, choisissez **Créer**. 1. Après avoir renseigné d’autres informations en fonction de votre charge de travail, dans la section **Service Connect**, sélectionnez **Utiliser Service Connect**. 1. Pour **Espace de noms**, saisissez l’ARN complet de l’espace de noms partagé. Le format ARN est le suivant : `arn:aws:servicediscovery:region:account-id:namespace/namespace-id` 1. Configurez les autres paramètres Service Connect selon les besoins de votre type de service (client ou client-serveur). 1. Terminez le processus de création de service. Vous pouvez également configurer les services à l'aide du AWS CLI ou AWS SDKs en spécifiant l'ARN de l'espace de noms partagé dans le `namespace` paramètre du`serviceConnectConfiguration`. ``` aws ecs create-service \ --cluster my-cluster \ --service-name my-service \ --task-definition my-task-def \ --service-connect-configuration '{ "enabled": true, "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-abcdef1234567890", "services": [{ "portName": "web", "discoveryName": "my-service", "clientAliases": [{ "port": 80, "dnsName": "my-service" }] }] }' ``` ## Considérations Tenez compte des points suivants lorsque vous utilisez des AWS Cloud Map espaces de noms partagés avec Service Connect : + AWS RAM doit être disponible dans l' Région AWS endroit où vous souhaitez utiliser l'espace de noms partagé. + L'espace de noms partagé doit être Région AWS identique à celui de vos services et clusters Amazon ECS. + Vous devez utiliser l’ARN de l’espace de noms, et non l’ID, lorsque vous configurez Service Connect avec un espace de noms partagé. + Tous les types d’espaces de noms sont pris en charge : espaces de noms HTTP, DNS privé et DNS public. + Si l’accès à un espace de noms partagé est révoqué, les opérations Amazon ECS qui nécessitent une interaction avec l’espace de noms (telles que `CreateService`, `UpdateService` et `ListServicesByNamespace`) échoueront. Pour plus d’informations sur la résolution des problèmes d’autorisation liés aux espaces de noms partagés, consultez la section [Résolution des problèmes liés à Amazon ECS Service Connect avec des espaces de AWS Cloud Map noms partagés](service-connect-shared-namespaces-troubleshooting.md). + Pour la découverte de service à l’aide de requêtes DNS dans un espace de noms DNS privé partagé : + Le propriétaire de l’espace de noms devra appeler `create-vpc-association-authorization` avec l’ID de la zone hébergée privée associée à l’espace de noms et le VPC du consommateur. ``` aws route53 create-vpc-association-authorization --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678 ``` + Le consommateur de l’espace de noms devra appeler `associate-vpc-with-hosted-zone` avec l’ID de la zone hébergée privée. ``` aws route53 associate-vpc-with-hosted-zone --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678 ``` + Seul le propriétaire de l’espace de noms peut gérer le partage des ressources. + Les consommateurs de l’espace de noms peuvent créer et gérer des services au sein de l’espace de noms partagé, mais ne peuvent pas modifier l’espace de noms lui-même. + Les noms de découverte doivent être uniques dans l’espace de noms partagé, quel que soit le compte qui crée le service. + Les services de l'espace de noms partagé peuvent découvrir les services d'autres AWS comptes ayant accès à l'espace de noms et s'y connecter. + Lorsque vous activez TLS pour Service Connect et utilisez un espace de noms partagé, l’autorité de certification (CA) AWS CA privée est limitée à l’espace de noms. Lorsque l’accès à l’espace de noms partagé est révoqué, l’accès à l’autorité de certification est interrompu. + Lorsqu'ils travaillent avec un espace de noms partagé, les propriétaires et les consommateurs d'espaces de noms n'ont pas accès par défaut aux métriques CloudWatch Amazon entre comptes. Les métriques cibles sont publiées uniquement pour les comptes qui possèdent des services clients. Un compte propriétaire de services client n'a pas accès aux statistiques reçues par un compte propriétaire de services client-serveur, et inversement. Pour permettre l'accès aux métriques entre comptes, configurez l'observabilité CloudWatch entre comptes. *Pour plus d'informations sur la configuration de l'observabilité entre comptes, consultez la section Observabilité [CloudWatch entre comptes dans le guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html) de l'utilisateur Amazon. CloudWatch * Pour plus d'informations sur les CloudWatch métriques de Service Connect, consultez[CloudWatch Métriques Amazon ECS](available-metrics.md). # Résolution des problèmes liés à Amazon ECS Service Connect avec des espaces de AWS Cloud Map noms partagés Utilisez les informations suivantes pour résoudre les problèmes liés aux AWS Cloud Map espaces de noms partagés et à Service Connect. Pour plus d’informations sur la localisation des messages d’erreur, consultez la section [Résolution des problèmes liés à Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html). Des messages d’erreur liés à des problèmes d’autorisations apparaissent en raison d’autorisations manquantes ou si l’accès à l’espace de noms est révoqué. **Important** Vous devez utiliser l’autorisation gérée `AWSRAMPermissionCloudMapECSFullPermission` pour partager l’espace de noms afin que Service Connect fonctionne correctement avec l’espace de noms. Le message d’erreur apparaît dans l’un des formats suivants : Une erreur s'est produite (ClientException) lors de l'appel de l'opération < OperationName > : L'utilisateur : arn:aws:iam : ::user/ n'est pas autorisé à effectuer : < > sur la ressource : < > ResourceArn car aucune politique basée ActionName sur les ressources n'autorise l'action < > ActionName
If you see this page, the nginx web server is successfully installed and working. Further configuration is required.
For online documentation and support please refer to
nginx.org.
Commercial support is available at
nginx.com.
Thank you for using nginx.
``` **Pour consulter les métriques de Service Connect** Le proxy Service Connect crée des métriques d'application (connexion HTTP HTTP2, gRPC ou TCP) dans des métriques. CloudWatch Lorsque vous utilisez la CloudWatch console, consultez les dimensions métriques supplémentaires de **DiscoveryName**, (**DiscoveryName, ServiceName, ClusterName**) et (**TargetDiscoveryName**, **TargetDiscoveryName ServiceName, ClusterName**) dans l'espace de noms Amazon ECS. Pour plus d'informations sur ces statistiques et les dimensions, consultez la section [Afficher les mesures disponibles](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html) dans le guide de l'utilisateur Amazon CloudWatch Logs. # Utilisation de la découverte de service pour connecter les services Amazon ECS avec des noms DNS Vous pouvez éventuellement configurer votre Amazon ECS service afin d'utiliser la découverte de service Amazon ECS. La découverte de services utilise des actions d' AWS Cloud Map API pour gérer les espaces de noms HTTP et DNS pour vos services Amazon ECS. Pour plus d'informations, consultez [Présentation de AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/Welcome.html) dans le *Manuel du développeur AWS Cloud Map *. La découverte de services est disponible dans les AWS régions suivantes : | Nom de la région | Région | | --- | --- | | USA Est (Virginie du Nord) | us-east-1 | | USA Est (Ohio) | us-east-2 | | USA Ouest (Californie du Nord) | us-west-1 | | US West (Oregon) | us-west-2 | | Afrique (Le Cap) | af-south-1 | | Asie-Pacifique (Hong Kong) | ap-east-1 | | Asie-Pacifique (Taipei) | ap-east-2 | | Asie-Pacifique (Mumbai) | ap-south-1 | | Asie-Pacifique (Hyderabad) | ap-south-2 | | Asie-Pacifique (Tokyo) | ap-northeast-1 | | Asie-Pacifique (Séoul) | ap-northeast-2 | | Asie-Pacifique (Osaka) | ap-northeast-3 | | Asie-Pacifique (Singapour) | ap-southeast-1 | | Asie-Pacifique (Sydney) | ap-southeast-2 | | Asie-Pacifique (Jakarta) | ap-southeast-3 | | Asie-Pacifique (Melbourne) | ap-southeast-4 | | Asie-Pacifique (Malaisie) | ap-southeast-5 | | Asie-Pacifique (Nouvelle-Zélande) | ap-southeast-6 | | Asie-Pacifique (Thaïlande) | ap-southeast-7 | | Canada (Centre) | ca-central-1 | | Canada-Ouest (Calgary) | ca-west-1 | | Chine (Beijing) | cn-north-1 | | China (Ningxia) | cn-northwest-1 | | Europe (Francfort) | eu-central-1 | | Europe (Zurich) | eu-central-2 | | Europe (Irlande) | eu-west-1 | | Europe (Londres) | eu-west-2 | | Europe (Paris) | eu-west-3 | | Europe (Milan) | eu-south-1 | | Europe (Stockholm) | eu-north-1 | | Israël (Tel Aviv) | il-central-1 | | Europe (Espagne) | eu-south-2 | | Moyen-Orient (EAU) | me-central-1 | | Mexique (Centre) | mx-central-1 | | Moyen-Orient (Bahreïn) | me-south-1 | | Amérique du Sud (São Paulo) | sa-east-1 | | AWS GovCloud (USA Est) | us-gov-east-1 | | AWS GovCloud (US-Ouest) | us-gov-west-1 | ## Concepts associés à la découverte de service La découverte de service se compose des éléments suivants : + **Espace de noms de découverte de services** : groupe logique de services de découverte de services qui partagent le même nom de domaine, tel que `example.com`, vers lequel vous souhaitez acheminer le trafic. Vous pouvez créer un espace de noms avec un appel à la commande `aws servicediscovery create-private-dns-namespace` ou dans la console Amazon ECS. Vous pouvez utiliser la commande `aws servicediscovery list-namespaces` pour afficher les informations récapitulatives concernant les espaces de noms créés par le compte actuel. Pour plus d'informations sur les commandes de découverte de services, consultez `[create-private-dns-namespace](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/create-private-dns-namespace.html)` et consultez `[list-namespaces](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/list-namespaces.html)` le *Guide de AWS CLI référence AWS Cloud Map (de découverte de services)*. + **Service de découverte de service** : présent dans l'espace de noms de la découverte de service, il se compose du nom du service et de la configuration DNS correspondant à l'espace de noms. Il fournit les principaux composants suivants : + **Registre des services** : vous permet de rechercher un service via des actions DNS ou AWS Cloud Map API et de récupérer un ou plusieurs points de terminaison disponibles pouvant être utilisés pour vous connecter au service. + **Instance de découverte de service** : existe dans le service de découverte de service et comprend les attributs associés à chaque service Amazon ECS service dans le répertoire de services. + **Attributs de l'instance** : les métadonnées suivantes sont ajoutées en tant qu'attributs personnalisés pour chaque service Amazon ECS service qui est configuré pour utiliser la découverte de service : + **`AWS_INSTANCE_IPV4`**— Pour `A` mémoire, l' IPv4 adresse renvoyée par Route 53 en réponse aux requêtes DNS et AWS Cloud Map lorsqu'elle découvre les détails de l'instance, par exemple,`192.0.2.44`. + **`AWS_INSTANCE_IPV6`**— Pour `AAAA` mémoire, l' IPv6 adresse renvoyée par Route 53 en réponse aux requêtes DNS et AWS Cloud Map lorsqu'elle découvre les détails de l'instance, par exemple,` 2001:0db8:85a3:0000:0000:abcd:0001:2345`. `AWS_INSTANCE_IPv4` et `AWS_INSTANCE_IPv6` sont ajoutés pour les services Amazon ECS à double pile. Seul `AWS_INSTANCE_IPv6` est ajouté pour les services Amazon ECS IPv6 uniquement. + **`AWS_INSTANCE_PORT`** – La valeur de port associées au service de découverte de service. + **`AVAILABILITY_ZONE`** – La zone de disponibilité dans laquelle la tâche a été lancée. Pour les tâches qui utilisent EC2, il s’agit de la zone de disponibilité dans laquelle l’instance de conteneur existe. Pour les tâches qui utilisent Fargate, il s’agit de la zone de disponibilité dans laquelle l’interface réseau Elastic existe. + **`REGION`** – La région dans laquelle la tâche existe. + **`ECS_SERVICE_NAME`** – Le nom du service Amazon ECS service auquel la tâche appartient. + **`ECS_CLUSTER_NAME`** – Le nom du cluster Amazon ECS auquel la tâche appartient. + **`EC2_INSTANCE_ID`** – L'ID de l'instance de conteneur sur laquelle la tâche a été placée. Cet attribut personnalisé n’est pas ajouté si la tâche utilise Fargate. + **`ECS_TASK_DEFINITION_FAMILY`** – La famille de définition de tâche que la tâche utilise. + **`ECS_TASK_SET_EXTERNAL_ID`** – Si un ensemble de tâches est créé pour un déploiement externe et est associé à un registre de découverte de service, alors l'attribut `ECS_TASK_SET_EXTERNAL_ID` contiendra l'ID externe de l'ensemble de tâches. + **Surveillances de l'état Amazon ECS** : Amazon ECS permet d'effectuer des surveillances d'état régulières au niveau du conteneur. Si un point de terminaison échoue à la surveillance de l'état, il est supprimé du routage DNS et marqué comme défectueux. ## Remarques relatives à la découverte de service Les informations suivantes doivent être prises en compte lors de l'utilisation de la découverte de service : + La découverte de service est prise en charge pour les tâches sur Fargate qui utilisent la version de plateforme 1.1.0 ou supérieure. Pour de plus amples informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md). + Les services configurés pour utiliser la découverte de service sont limités à 1 000 tâches par service. Cela est dû à un quota de service Route 53. + Le flux de travail créer un service dans la console Amazon ECS prend uniquement en charge l'enregistrement des services dans des espaces de noms DNS privés. Lorsqu'un espace de noms DNS AWS Cloud Map privé est créé, une zone hébergée privée Route 53 est créée automatiquement. + Les attributs DNS du VPC doivent être configurés pour une résolution DNS réussie. Pour plus d'informations sur la configuration des attributs, consultez [Attributs DNS dans votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support) dans le *Guide de l'utilisateur Amazon VPC*. + Amazon ECS ne prend pas en charge l'enregistrement de services dans des AWS Cloud Map espaces de noms partagés. + Les registres DNS créés pour un service de découverte de service sont toujours enregistrés avec l'adresse IP privée de la tâche et non pas l'adresse IP publique, même lorsque des espaces de noms publics sont utilisés. + La découverte de service exige que les tâches spécifient le mode réseau `awsvpc`, `bridge` ou `host` (`none` n'est pas pris en charge). + Si la définition de tâche du service utilise le mode réseau `awsvpc`, vous pouvez créer n’importe quelle combinaison d’enregistrements `A` ou `SRV` pour chaque tâche de service. Si vous utilisez des enregistrements `SRV`, un port est requis. Vous pouvez également créer des enregistrements `AAAA` si le service utilise des sous-réseaux à double pile. Si le service utilise IPv6 uniquement des sous-réseaux, vous ne pouvez pas créer `A` d'enregistrements. + Si la définition de tâche du service utilise le mode réseau `bridge` ou `host`, un registre SRV est le seul type de registre DNS pris en charge. Créez un registre SRV pour chaque tâche de service. Le registre SRV doit spécifier une combinaison de nom de conteneur et de port de conteneur à partir de la définition de tâche. + Vous pouvez interroger les registres DNS pour un service de découverte de service au sein de votre VPC. Ces enregistrements utilisent le format suivant : `Your application is now running on a container in Amazon ECS.