Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Retrait et maintenance des tâches pour AWS Fargate sur Amazon ECS
AWS est responsable de la maintenance de l'infrastructure sous-jacente de AWS Fargate. AWS détermine à quel moment une révision de version de plate-forme doit être remplacée par une nouvelle révision de l'infrastructure. C'est ce que l'on appelle la retraite des tâches. AWS envoie une notification de retrait de tâche lorsqu'une révision de version de plateforme est supprimée. Nous mettons régulièrement à jour les versions de nos plateformes prises en charge pour introduire une nouvelle révision contenant des mises à jour du logiciel d’exécution Fargate et des dépendances sous-jacentes telles que le système d’exploitation et l’environnement d’exécution du conteneur. Une fois qu’une nouvelle version est disponible, nous mettons hors service l’ancienne version afin de garantir que toutes les charges de travail des clients s’exécutent sur la version la plus récente de la version de plateforme Fargate. Lorsqu'une révision est retirée, toutes les tâches exécutées sur cette révision sont arrêtées.
Les tâches Amazon ECS peuvent être classées en tant que tâches de service ou tâches autonomes. Les tâches de service sont déployées dans le cadre d’un service et planifiées par le planificateur Amazon ECS. Pour de plus amples informations, veuillez consulter [Services Amazon ECS](ecs_services.md). Les tâches autonomes sont des tâches démarrées par l'`RunTask`API Amazon ECS, soit directement, soit par un planificateur externe, telles que les tâches planifiées (lancées par Amazon EventBridge), AWS Batch ou. AWS Step Functions Aucune action n’est requise de votre part en réponse à la mise hors service de vos tâches de service, car le planificateur Amazon ECS remplace automatiquement les tâches.
Pour les tâches autonomes, il se peut que vous deviez effectuer une manipulation supplémentaire en réponse à la mise hors service des tâches. Pour de plus amples informations, veuillez consulter [Amazon ECS peut-il gérer automatiquement des tâches autonomes ?](#task-retirement-standalone-tasks).
Pour les tâches de service, il n'est pas nécessaire de prendre des mesures pour les supprimer, sauf si vous souhaitez remplacer ces tâches au AWS préalable. Lorsque le planificateur Amazon ECS arrête les tâches, il utilise le paramètre `maximumPercent` et lance une nouvelle tâche afin de maintenir le nombre souhaité pour le service. Suivez les pratiques exemplaires pour minimiser l’impact de la mise hors service des tâches. La valeur par défaut du paramètre `maximumPercent` pour un service utilisant le planificateur de service RÉPLICA est de 200 %. Par conséquent, lorsqu'il AWS Fargate commence à retirer des tâches, Amazon ECS planifie d'abord une nouvelle tâche, puis attend qu'elle soit exécutée avant de retirer une ancienne tâche. Lorsque vous définissez la valeur de `maximumPercent` sur 100 %, Amazon ECS arrête d’abord la tâche, puis la remplace.
Pour le retrait d'une tâche autonome, AWS arrête la tâche à la date de retrait de la tâche ou après cette date. Amazon ECS ne lance pas de tâche de remplacement lorsqu’une tâche est arrêtée. Si vous souhaitez que ces tâches continuent de s’exécuter, vous devez arrêter les tâches en cours d’exécution et lancer une tâche de remplacement avant l’heure indiquée dans la notification. Nous recommandons donc aux clients de surveiller l'état des tâches autonomes et, si nécessaire, d'implémenter une logique pour remplacer les tâches interrompues.
Lorsqu'une tâche est arrêtée dans l'un des scénarios ci-dessus, vous pouvez exécuter `describe-tasks`. La `stoppedReason` de la réponse est `ECS is performing maintenance on the underlying infrastructure hosting the task`.
La maintenance des tâches s’applique lorsqu’une nouvelle version de plateforme doit être remplacée par une nouvelle révision. En cas de problème avec un hôte Fargate sous-jacent, Amazon ECS remplace l’hôte sans préavis de mise hors service de tâche.
## Aperçu des avis de mise hors service de tâches
Lorsqu' AWS une révision de version de plate-forme doit être supprimée, nous identifions toutes les tâches en cours d'exécution sur cette révision de version de plate-forme dans toutes les régions.
L’illustration suivante montre le cycle de vie d’une révision de version de plateforme Fargate, depuis le lancement d’une nouvelle révision à la mise hors service de la révision de plateforme.
![\[Diagramme illustrant le cycle de vie de la mise hors service des tâches Fargate.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/fargate-task-retirement.png)
Les informations suivantes fournissent des détails.
+ Après le lancement d’une nouvelle révision de la version de plateforme, toutes les nouvelles tâches sont planifiées sur cette révision.
+ Les tâches existantes qui ont été planifiées et exécutées restent dans la version dans laquelle elles ont été initialement placées pendant toute la durée de la tâche et ne sont pas migrées vers la nouvelle révision.
+ Les nouvelles tâches, par exemple dans le cadre d’une mise à jour d’un service ou de la mise hors service d’une tâche Fargate, sont placées sur la dernière version de plateforme disponible au moment du lancement.
Les notifications de retrait de tâches sont envoyées via le tableau de AWS Health bord ainsi que par e-mail à l'adresse e-mail enregistrée et incluent les informations suivantes :
+ Date de retrait de la tâche : la tâche est arrêtée à cette date ou après.
+ Pour les tâches autonomes, IDs les tâches.
+ Pour les tâches de service, l'ID du cluster sur lequel le service s'exécute et IDs celui du service.
+ Les prochaines étapes que vous devez suivre.
En règle générale, nous envoyons une notification pour chaque tâche de service et chaque tâche autonome dans chaque Région AWS. Toutefois, dans certains cas, vous pouvez recevoir plusieurs événements pour chaque type de tâche, par exemple lorsqu’un trop grand nombre de tâches dépassent les limites fixées par nos mécanismes de notification pour être mises hors service.
Vous pouvez identifier les tâches planifiées pour le retrait en procédant ainsi :
+ Le Tableau de bord Health
AWS Health les notifications peuvent être envoyées via Amazon EventBridge vers un système de stockage d'archives tel qu'Amazon Simple Storage Service, effectuer des actions automatisées telles que l'exécution d'une AWS Lambda fonction, ou vers d'autres systèmes de notification tels qu'Amazon Simple Notification Service. Pour plus d'informations, consultez la section [Surveillance AWS Health des événements avec Amazon EventBridge](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html). Pour un exemple de configuration permettant d'envoyer des notifications à Amazon Chime, Slack ou Microsoft Teams, consultez le référentiel [AWS Health Aware](https://github.com/aws-samples/aws-health-aware) sur. GitHub
Voici un exemple d' EventBridge événement.
```
{
"version": "0",
"id": "3c268027-f43c-0171-7425-1d799EXAMPLE",
"detail-type": "AWS Health Event",
"source": "aws.health",
"account": "123456789012",
"time": "2023-08-16T23:18:51Z",
"region": "us-east-1",
"resources": [
"cluster|service",
"cluster|service"
],
"detail": {
"eventArn": "arn:aws:health:us-east-1::event/ECS/AWS_ECS_TASK_PATCHING_RETIREMENT/AWS_ECS_TASK_PATCHING_RETIREMENT_test1",
"service": "ECS",
"eventScopeCode": "ACCOUNT_SPECIFIC",
"communicationId": "7988399e2e6fb0b905ddc88e0e2de1fd17e4c9fa60349577446d95a18EXAMPLE",
"lastUpdatedTime": "Wed, 16 Aug 2023 23:18:52 GMT",
"eventRegion": "us-east-1",
"eventTypeCode": "AWS_ECS_TASK_PATCHING_RETIREMENT",
"eventTypeCategory": "scheduledChange",
"startTime": "Wed, 16 Aug 2023 23:18:51 GMT",
"endTime": "Fri, 18 Aug 2023 23:18:51 GMT",
"eventDescription": [
{
"language": "en_US",
"latestDescription": "\\nA software update has been deployed to Fargate which includes CVE patches or other critical patches. No action is required on your part. All new tasks launched automatically uses the latest software version. For existing tasks, your tasks need to be restarted in order for these updates to apply. Your tasks running as part of the following ECS Services will be automatically updated beginning Wed, 16 Aug 2023 23:18:51 GMT.\\n\\nAfter Wed, 16 Aug 2023 23:18:51 GMT, the ECS scheduler will gradually replace these tasks, respecting the deployment settings for your service. Typically, services should see little to no interruption during the update and no action is required. When AWS stops tasks, AWS uses the minimum healthy percent (1) and launches a new task in an attempt to maintain the desired count for the service. By default, the minimum healthy percent of a service is 100 percent, so a new task is started first before a task is stopped. Service tasks are routinely replaced in the same way when you scale the service or deploy configuration changes or deploy task definition revisions. If you would like to control the timing of this restart you can update the service before Wed, 16 Aug 2023 23:18:51 GMT, by running the update-service command from the ECS command-line interface specifying force-new-deployment for services using Rolling update deployment type. For example:\\n\\n$ aws ecs update-service -service service_name \\\n--cluster cluster_name -force-new-deployment\\n\\nFor services using Blue/Green deployment type with AWS CodeDeploy:\\nPlease refer to create-deployment document (2) and create new deployment using same task definition revision.\\n\\nFor further details on ECS deployment types, please refer to ECS Deployment Developer Guide (1).\\nFor further details on Fargate's update process, please refer to the AWS Fargate User Guide (3).\\nIf you have any questions or concerns, please contact AWS Support (4).\\n\\n(1) https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-types.html\\n(2) https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html\\n(3) https://docs.aws.amazon.com/AmazonECS/latest/userguide/task-maintenance.html\\n(4) https://aws.amazon.com/support\\n\\nA list of your affected resources(s) can be found in the 'Affected resources' tab in the 'Cluster/ Service' format in the AWS Health Dashboard. \\n\\n"
}
],
"affectedEntities": [
{
"entityValue": "arn:aws:ecs:eu-west-1:111222333444:task/examplecluster/00805ce1d81940b5a37398e5a2c23333"
},
{
"entityValue": "arn:aws:ecs:eu-west-1:111222333444:task/examplecluster/00805ce1d81940b5a37398e5a2c25555"
}
}
]
}
}
```
+ E-mail
Un e-mail est envoyé à l'adresse e-mail enregistrée pour l' Compte AWS identifiant.
Pour plus d’informations sur la manière de préparer la mise hors service d’une tâche, consultez la section[Préparez-vous à la AWS suppression des tâches Fargate sur Amazon ECS](prepare-task-retirement.md).
## Puis-je refuser la mise hors service d’une tâche ?
Non. Dans le cadre du modèle de responsabilité AWS partagée, AWS est responsable de la gestion et de la maintenance de l'infrastructure sous-jacente pour AWS Fargate. Cela inclut l’exécution de mises à jour périodiques de la plateforme pour garantir la sécurité et la stabilité. Ces mises à jour sont automatiquement appliquées par les clients AWS et ne peuvent pas s'y soustraire. Il s'agit d'un avantage clé de l'utilisation d'une AWS Fargate par rapport à l'exécution de vos charges de travail sur des instances EC2, la responsabilité de la maintenance de la plate-forme sous-jacente étant prise en charge par. AWS Ce modèle vous permet de vous concentrer sur vos applications plutôt que sur la maintenance de l’infrastructure. En appliquant automatiquement ces mises à jour de la plateforme, AWS vous êtes en mesure de maintenir l' up-to-dateenvironnement Fargate et de le sécuriser, sans qu'aucune action ne soit requise de votre part en tant que client. Cela permet de fournir un environnement conteneurisé fiable et sécurisé pour exécuter vos charges de travail sur Fargate.
## Puis-je recevoir des notifications de retrait de tâches par le biais d'autres AWS services ?
AWS envoie une notification de retrait de tâche au Tableau de bord Health et au contact e-mail principal sur le Compte AWS. Tableau de bord Health Il fournit un certain nombre d'intégrations dans d'autres AWS services, notamment EventBridge. Vous pouvez l'utiliser EventBridge pour automatiser la visibilité des notifications (par exemple, transférer le message vers un ChatOps outil). Pour plus d’informations, consultez la section [Présentation de la solution : capture des notifications de mise hors service de tâches](https://aws.amazon.com/blogs/containers/improving-operational-visibility-with-aws-fargate-task-retirement-notifications/).
## Puis-je modifier la mise hors service d’une tâche une fois qu’elle a été planifiée ?
Non. Le calendrier est basé sur le temps d'attente pour la cessation des tâches, qui est par défaut de 7 jours. Si vous avez besoin de plus de temps, vous pouvez choisir de configurer le délai d’attente à 14 jours. Pour de plus amples informations, veuillez consulter [Étape 2 : capturer les notifications de mise hors service de tâche pour alerter les équipes et prendre des mesures](prepare-task-retirement.md#prepare-task-retirement-capture-task-events).
Depuis le 18/12/2025, Amazon ECS vous permet de configurer les fenêtres d'[événements Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html) pour vos tâches Fargate. Si vous avez besoin d'un contrôle précis sur le moment exact des interruptions de tâches, par exemple en les planifiant le week-end pour éviter toute interruption pendant les heures ouvrables, vous pouvez configurer les fenêtres d'événements Amazon EC2 pour vos tâches, services ou clusters, voir. [Étape 1 : définir le temps d'attente des tâches ou utiliser les fenêtres d'événements Amazon EC2](prepare-task-retirement.md#prepare-task-retirement-set-time) Notez que la modification apportée à cette configuration s'applique aux mises à la retraite qui seront planifiées dans le futur. Les mises hors service prévues actuellement ne sont pas concernées. En outre, lorsque vous configurez une fenêtre d'événements Amazon EC2 pour vos tâches Fargate, elle a priorité sur la configuration du temps d'attente pour la mise hors service des tâches. Si vous avez d'autres préoccupations, contactez Support.
## Comment Amazon ECS gère-t-il les tâches faisant partie d’un service ?
Pour les tâches de service, il n'est pas nécessaire de prendre des mesures en réponse à la suppression des tâches, sauf si vous souhaitez remplacer ces tâches au AWS préalable. Lorsque le planificateur Amazon ECS arrête les tâches, il utilise le pourcentage minimum sain et lance une nouvelle tâche afin de maintenir le nombre souhaité pour le service. Afin de minimiser l’impact de la mise hors service des tâches Fargate, les charges de travail doivent être déployées conformément aux pratiques exemplaires Amazon ECS. Par exemple, lors du déploiement d'une application sans état en tant que service Amazon ECS, tel qu'un serveur Web ou API, les clients doivent déployer plusieurs répliques de tâches et définir la valeur minimumHealthyPercent à 100 %. La valeur par défaut pour le pourcentage minimum sain est 100 %. Par conséquent, lorsque Fargate commence à mettre des tâches hors service, Amazon ECS planifie d’abord une nouvelle tâche et attend qu’elle soit exécutée, avant de mettre une ancienne tâche hors service. Les tâches de service sont systématiquement remplacées dans le cadre de la mise hors service des tâches, de la même manière que lorsque vous adaptez le service, déployez des modifications de configuration ou déployez des révisions de définition de tâches. Pour plus d’informations sur la mise hors service d’une définition de tâche, consultez la section [Préparez-vous à la AWS suppression des tâches Fargate sur Amazon ECS](prepare-task-retirement.md).
## Amazon ECS peut-il gérer automatiquement des tâches autonomes ?
Non. AWS ne peut pas créer de tâche de remplacement pour les tâches autonomes démarrées par `RunTask` des tâches planifiées (par exemple via le EventBridge planificateur) ou. AWS Batch AWS Step Functions Amazon ECS ne gère que les tâches faisant partie d’un service.
## Résolution des problèmes de disponibilité du service pendant la mise hors service d’une tâche
Si Amazon ECS ne peut pas démarrer une tâche de remplacement pendant la mise hors service d’une tâche, la disponibilité de votre service peut être affectée. Cela peut être dû à une configuration client incorrecte, telle que :
+ Rôles IAM manquants ou configurés de façon incorrecte
+ Capacité insuffisante dans les sous-réseaux cibles
+ Mauvaises configurations des groupes de sécurité
+ Erreurs de définition des tâches
Lorsqu’Amazon ECS ne peut pas lancer de tâches de remplacement, les tâches mises hors service sont arrêtées sans remplacement, ce qui réduit la capacité disponible de votre service et peut entraîner une interruption du service. Surveillez le nombre de tâches de votre service et les CloudWatch indicateurs Amazon pour vous assurer que les tâches de remplacement sont lancées avec succès lors des événements de mise hors service.
# Préparez-vous à la AWS suppression des tâches Fargate sur Amazon ECS
Afin d’être prêt à la mise hors service de tâche, effectuez les opérations suivantes :
1. Définissez la période d'attente pour la suppression des tâches ou utilisez les fenêtres d'événements Amazon EC2.
1. Capturez les notifications de mise hors service de tâche pour avertir les membres de l’équipe.
1. Vous pouvez vous assurer que toutes les tâches de vos services sont exécutées sur la dernière version de la plateforme en mettant à jour le service avec l'option de déploiement forcé. Cette étape est facultative.
## Étape 1 : définir le temps d'attente des tâches ou utiliser les fenêtres d'événements Amazon EC2
Vous disposez de deux options de paramètres de compte pour configurer l'heure à laquelle Fargate commence à supprimer des tâches : et. `fargateTaskRetirementWaitPeriod` `fargateEventWindows`
**Utilisation des paramètres fargateTaskRetirement WaitPeriod du compte**
Vous pouvez configurer l'heure à laquelle Fargate commence le retrait des tâches. Le délai d'attente par défaut est de 7 jours. Pour les charges de travail qui nécessitent l'application immédiate des mises à jour, choisissez le paramètre immédiat (`0`). Si vous avez besoin de plus de temps, configurez l'`7`option ou `14` day.
Nous vous recommandons de choisir une période d'attente plus courte afin de pouvoir accéder plus rapidement aux nouvelles versions de plateforme.
Configurez la période d’attente en exécutant `put-account-setting-default` ou `put-account-setting` en tant qu’utilisateur racine ou utilisateur administratif. Utilisez l'option `fargateTaskRetirementWaitPeriod` pour le `name` et l'option `value` définie sur l'une des valeurs suivantes :
+ `0`- AWS envoie la notification et commence immédiatement à supprimer les tâches concernées.
+ `7`- AWS envoie la notification et attend 7 jours calendaires avant de commencer à supprimer les tâches concernées. Il s’agit de l’option par défaut.
+ `14` : AWS envoie la notification et attend 14 jours calendaires avant de commencer à retirer les tâches concernées.
Pour plus d'informations, consultez [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html)et consultez le [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)manuel *Amazon Elastic Container Service API Reference*.
**Utilisation des paramètres fargateEventWindows du compte**
Depuis le 18/12/2025, Amazon ECS vous permet de configurer les fenêtres d'[événements Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html) pour vos tâches Fargate. Si vous avez besoin d'un contrôle précis sur le moment exact des interruptions de tâches, par exemple en les planifiant le week-end pour éviter toute interruption pendant les heures ouvrables, vous pouvez configurer les fenêtres d'événements Amazon EC2 pour vos tâches, services ou clusters.
Lorsque vous utilisez des fenêtres d'événements, Fargate veille à ce que vos tâches soient exécutées pendant au moins 3 jours avant d'être supprimées dans la prochaine fenêtre disponible, sauf si elles sont interrompues par des actions initiées par l'utilisateur ou par des événements de santé critiques tels que la dégradation du matériel sous-jacent.
Réglez le paramètre du compte `fargateEventWindows` sur `enabled`. Vous pouvez utiliser l'une des options suivantes APIs : `put-account-setting-default` ou `put-account-setting` en tant qu'utilisateur root ou en tant qu'utilisateur administratif.
Chaque fenêtre d'événements Amazon EC2 doit être ouverte au moins 4 heures par semaine, et chaque plage horaire doit être d'au moins 2 heures. Pour les clusters et les services de grande taille, nous recommandons de configurer des fenêtres d'événements de longue durée (8 heures ou plus) ou de plages de temps plus fréquentes qui se produisent au moins une fois tous les 3 jours. Vous pouvez consulter plus en détail les considérations relatives aux fenêtres d'événements Amazon EC2 dans le [guide de l'utilisateur](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html#event-windows-considerations) pour AWS Fargate garantir que vos tâches s'exécutent pendant au moins 3 jours avant d'être supprimées, sauf si elles sont interrompues par des actions initiées par l'utilisateur ou par des événements de santé critiques tels que la dégradation du matériel sous-jacent.
**Important**
Il est préférable de remplacer les tâches dans la fenêtre d'événements. Si vous remarquez que des tâches sont supprimées en dehors des fenêtres de vos événements, envisagez d'en prolonger la durée (8 heures ou plus) ou d'augmenter la fréquence (au moins une fois tous les 3 jours).
Pour appliquer les fenêtres d'événements Amazon EC2 aux mises hors service de vos tâches Fargate :
+ Réglez le paramètre du compte `fargateEventWindows` sur `enabled`. Vous pouvez utiliser l'une des options suivantes APIs : `put-account-setting-default` ou `put-account-setting` en tant qu'utilisateur root ou en tant qu'utilisateur administratif. Notez qu'il s'agit d'une activation ponctuelle pour l'utilisation de la fonctionnalité de fenêtres d'événements Amazon EC2 pour vos tâches Fargate.
+ Créez une fenêtre d'événement Amazon EC2 via la console AWS ou l'interface de ligne de commande AWS. Pour créer une fenêtre d'événements à l'aide de la CLI, utilisez l'`create-instance-event-window`API EC2 avec des plages de temps ou des expressions cron. Prenez note du contenu `InstanceEventWindowId` de la réponse.
```
aws ec2 create-instance-event-window \
--time-range StartWeekDay=monday,StartHour=2,EndWeekDay=wednesday,EndHour=8 \
--tag-specifications "ResourceType=instance-event-window,Tags=[{Key=K1,Value=V1" \
--name myEventWindowName
```
Vous pouvez également utiliser des expressions cron lors de la création de fenêtres d'événements EC2.
```
aws ec2 create-instance-event-window \
--cron-expression "* 21-23 * * 2,3" \
--tag-specifications "ResourceType=instance-event-window,Tags=[{Key=K1,Value=V1" \
--name myEventWindowName
```
+ Vous pouvez ensuite associer la fenêtre d'événements à des services spécifiques, à des clusters ou à toutes les tâches de votre compte à l'aide de l'`associate-instance-event-window`API EC2.
+ Pour les tâches de service ECS
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:serviceArn,Value=your-service-arn}]"
```
+ Pour les clusters ECS
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:clusterArn,Value=your-cluster-arn}]"
```
+ Pour associer une fenêtre d'événements à toutes les tâches du compte
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:fargateTask,Value=true}]"
```
Vous pouvez utiliser plusieurs paires clé-valeur pour associer une fenêtre d'événements à plusieurs services ou clusters.
Fargate choisira la fenêtre d'événements pour chaque tâche dans l'ordre suivant :
+ Si une fenêtre d'événements est associée au service de la tâche, elle sera utilisée. Cela ne s'applique pas aux tâches autonomes ou non gérées.
+ Si une fenêtre d'événements est associée au cluster de la tâche, elle sera utilisée.
+ Si une fenêtre d'événements est définie pour toutes les tâches Fargate, elle sera utilisée.
+ Le `fargateTaskRetirementWaitPeriod` paramètre sera utilisé si aucune des fenêtres d'événements ne correspond à la tâche.
**Configuration des fenêtres d'événements pour la maintenance des tâches de Fargate**
Prenons le cas où vous exécutez plusieurs services ECS sur Fargate avec des exigences de disponibilité différentes. Vous voulez avoir un contrôle précis sur les abandons de tâches. Vous pouvez configurer plusieurs fenêtres d'événements comme suit :
+ **Maintenance par défaut pour toutes les tâches Fargate** : créez une fenêtre d'événements pour la maintenance de routine pendant les heures creuses (de 12 h à 4 h du matin tous les jours) et associez-la à toutes les tâches Fargate à l'aide de la balise. ` aws:ecs:fargateTask`
+ **Maintenance du cluster de développement uniquement le week-end** : pour un cluster de développement dont les services peuvent tolérer des interruptions le week-end, créez une fenêtre de week-end de 24 heures (samedi et dimanche, toute la journée) et associez-la au cluster à l'aide de la `aws:ecs:clusterArn` balise associée à l'ARN de votre cluster.
+ **Période restreinte pour les services critiques : pour un service** de traitement des paiements essentiel nécessitant une disponibilité élevée en semaine, limitez la maintenance aux heures du week-end tôt le matin (samedi et dimanche, de minuit à 4 h) et associez-le au service spécifique en utilisant le tag associé à l'ARN de votre service. `aws:ecs:serviceArn`
Avec cette configuration, le service de paiement utilise sa fenêtre spécifique réservée au week-end, les services et tâches du cluster de développement utilisent la fenêtre de 24 heures du week-end, et toutes les autres tâches Fargate utilisent la fenêtre de maintenance quotidienne par défaut.
Pour plus d'informations, consultez [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html)et consultez le [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)manuel *Amazon Elastic Container Service API Reference*.
## Étape 2 : capturer les notifications de mise hors service de tâche pour alerter les équipes et prendre des mesures
En cas de retrait imminent d'une tâche, AWS envoie une notification de retrait de tâche au AWS Health tableau de bord et au contact e-mail principal sur le Compte AWS. Le AWS Health tableau de bord propose un certain nombre d'intégrations dans d'autres AWS services, notamment Amazon EventBridge. Vous pouvez l'utiliser EventBridge pour créer des automatisations à partir d'une notification de retrait de tâche, par exemple en augmentant la visibilité du prochain retrait en transférant le message vers un ChatOps outil. AWS Health Aware est une ressource qui montre la puissance du AWS Health tableau de bord et montre comment les notifications peuvent être distribuées au sein d'une organisation. Vous pouvez transférer une notification de mise hors service de tâche vers une application de chat, telle que Slack.
L’illustration suivante présente une vue d’ensemble de la solution.
![\[Schéma illustrant la solution Fargate permettant de capturer les notifications de mise hors service de tâche Fargate.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/fargate-task-retirement-solution.png)
Les informations suivantes fournissent des détails.
+ Fargate envoie la notification de mise hors service de la tâche au tableau de bord AWS Health .
+ Le AWS Health tableau de bord envoie un e-mail au contact e-mail principal sur le Compte AWS, et le notifie EventBridge.
+ EventBridge possède une règle qui capture la notification de départ à la retraite.
La règle qui recherche les événements avec le type de détail de l’événement : `"AWS Health Event" and the Event Detail Type Code: "AWS_ECS_TASK_PATCHING_RETIREMENT"`
+ La règle déclenche une fonction Lambda qui transmet les informations à Slack à l’aide d’un Webhook entrant Slack. Pour plus d’informations, consultez la section [Webhooks entrants](https://slack.com/marketplace/A0F7XDUAZ-incoming-webhooks).
Pour un exemple de code, consultez [Capture des notifications de retrait de AWS Fargate tâches](https://github.com/aws-samples/capturing-aws-fargate-task-retirement-notifications/tree/main) sur Github.
## Étape 3 : contrôler le remplacement des tâches
Vous ne pouvez pas contrôler le moment exact de la mise hors service d’une tâche, mais vous pouvez définir un temps d’attente. Si vous souhaitez contrôler le remplacement des tâches selon votre propre calendrier, vous pouvez enregistrer l’avis de mise hors service d’une tâche afin de comprendre d’abord la date de mise hors service de la tâche. Vous pouvez ensuite redéployer votre service pour lancer des tâches de remplacement, ainsi que pour remplacer toutes les tâches autonomes. Pour les services utilisant un déploiement continu, vous devez mettre à jour le service à l’aide de `update-service` avec l’option `force-deployment` avant l’heure de début de la mise hors service.
L’exemple suivant `update-service` utilise l’option `force-deployment`.
```
aws ecs update-service —-service service_name \
--cluster cluster_name \
--force-new-deployment
```
Pour les services qui utilisent le blue/green déploiement, vous devez créer un nouveau déploiement dans AWS CodeDeploy. Pour plus d’informations sur la façon de créer le déploiement, consultez la section [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) dans la *Référence AWS Command Line Interface *.