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 de l'intégration correspond à la période après qu'une nouvelle version d'un service ait monté en puissance et que l'ancienne version ait fait l'objet d'une mise à l'échelle horizontale. Pendant cette période, Amazon ECS continue de surveiller l'alarme associée au déploiement. Amazon ECS calcule cette période en fonction de la configuration d'alarme associée au déploiement.

• 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 CreateServicemanuel 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 plus d’informations, consultez Événements de changement d'état du déploiement du service Amazon ECS.

• 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 du AWS CLI. Pour plus d'informations, consultez Créer un service à l'aide de paramètres définis et create-service 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 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 appellentDescribeAlarms, Amazon ECS risque d'avoir un impact sur le fait d'interroger les alarmes. Par exemple, si un autre service effectue suffisamment d'DescribeAlarmsappels pour atteindre le quota, ce service est limité et Amazon ECS est également limité et ne peut pas interroger les alarmes. Si une alarme est générée pendant la période de régulation, Amazon ECS risque de rater l'alarme et de ne pas procéder à la restauration. 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 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 permet de résoudre le cas où vous souhaitez démarrer un nouveau déploiement pour corriger un échec de déploiement 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 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 plus d’informations, consultez Considérations.

• 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 Simple Queue Service Developer Guide.