Pourquoi ma tâche Amazon ECS est-elle arrêtée ?

Brève description

Vos tâches Amazon ECS peuvent s'arrêter pour diverses raisons. Les raisons les plus courantes sont les suivantes :

• Conteneur essentiel a quitté
• Échec des surveillances de l'état d'Elastic Load Balancing (ELB)
• Échec des surveillances de l'état des conteneurs
• Instance de conteneur non sain
• Maintenance de l'infrastructure sous-jacente
• Événement de mise à l'échelle du service déclenché
• ResourceInitializationError
• CannotPullContainerError
• Tâche arrêtée par l'utilisateur

Comprendre la corrélation entre une tâche arrêtée et la raison de l'arrêt peut aider à réduire les efforts nécessaires au dépannage.

Solution

Vous pouvez consulter les détails d'une tâche arrêtée à l'aide de l'API DescribeTasks. Toutefois, les détails de la tâche arrêtée n'apparaissent que pendant une heure dans les résultats renvoyés. Pour afficher les détails de la tâche arrêtée plus longtemps, vous pouvez utiliser ce modèle AWS CloudFormation pour stocker les journaux Amazon CloudWatch Logs à partir d'un événement EventBridge qui est déclenché lorsqu'une tâche est arrêtée.

Raisons de l'arrêt

Conteneur essentiel dans la tâche à quitté

Toutes les tâches doivent comporter au moins un conteneur essentiel. Si le paramètre essentiel d'un conteneur est marqué comme vrai et que ce conteneur échoue ou s'arrête pour une raison quelconque, tous les autres conteneurs qui font partie de cette tâche sont arrêtés. Pour comprendre pourquoi une tâche à quitté avec cette raison, identifiez le code de sortie à l'aide de l'API DescribeTasks et accédez à la section Codes de sortie courants de cet article.

Échec des surveillances de l'état d'ELB

Lorsqu'une tâche échoue en raison de surveillances de l'état ELB, confirmez que votre groupe de sécurité de conteneur autorise le trafic en provenance d'ELB. Éléments à prendre en compte :

• Définissez une période de grâce minimale pour la surveillance de l'état. Celle-ci demande au planificateur de service d'ignorer les surveillances de l'état d'Elastic Load Balancing pendant une période prédéfinie après l'instanciation d'une tâche.
• Par défaut, une cible commence à recevoir sa part complète de demandes dès qu'elle est enregistrée auprès d'un groupe cible et qu'elle passe une surveillance de l'état initiale. L'utilisation du mode de démarrage lent donne aux cibles le temps de se réchauffer avant que l'équilibreur de charge ne leur envoie une part complète de demandes.
• Surveillez les métriques du processeur et de la mémoire du service. Par exemple, un processeur élevé peut empêcher votre application de répondre et entraîner une erreur 502.
• Vérifiez les erreurs d'application dans vos journaux d'application.
• Vérifiez si le port ping et le chemin de surveillance de l'état sont correctement configurés.
• Faites un curl du chemin de la surveillance de l'état à partir d'Amazon Elastic Compute Cloud (Amazon EC2) et confirmez le code de réponse.

Échec des surveillances de l'état des conteneurs

Les surveillances de l'état peuvent être définis dans l'API TaskDefinition ou Dockerfile.

Vous pouvez afficher l'état de santé des conteneurs individuels et de la tâche à l'aide de l'opération d'API DescribeTasks.

Assurez-vous que l'état de sortie de la commande de surveillance de l'état indique que le conteneur est en bon état. Vérifiez les erreurs d'application dans vos journaux de conteneur à l'aide des paramètres du pilote de journal spécifiés dans la définition de la tâche. Les valeurs possibles sont les suivantes :

• 0 : success (succès) : le conteneur est sain et prêt à être utilisé.
• 1 : unhealthy (non sain) : le conteneur ne fonctionne pas correctement.
• 2 : reserved (réservé) : n'utilisez pas ce code de sortie.

(instance i-xx) (port x) est non sain dans (raison : échec des surveillances de l'état)

Cela indique que l'état du conteneur est non sain. Pour résoudre ce problème :

• Vérifiez que le groupe de sécurité attaché à l'instance de conteneur autorise le trafic.
• Confirmez que le backend répond avec succès sans retard.
• Définissez correctement la valeur du temps de réponse.
• Consultez les journaux d'accès de votre équilibreur de charge pour plus d'informations.

Service ABCService : ECS effectue la maintenance de l'infrastructure sous-jacente hébergeant la tâche

Cela indique que la tâche a été arrêtée en raison d'un problème de maintenance des tâches. Pour plus d'informations, consultez Maintenance des tâches AWS Fargate.

Un service s'assure que la stratégie de planification spécifiée est suivie et que les tâches sont replanifiées lorsqu'elles sont arrêtées ou échouées. Si l'instance de conteneur fait partie d'un groupe Auto Scaling. Une nouvelle instance de conteneur doit être lancée et des tâches placées. Pour plus d'informations, consultez Vérification d'une activité de mise à l'échelle pour un groupe Auto Scaling.

Événement de mise à l’échelle du service ECS déclenché

Il s'agit d'un message de service standard. Amazon ECS utilise le service Application Auto Scaling pour fournir cette fonctionnalité. Le service ECS a la capacité d'augmenter ou de réduire automatiquement le nombre de tâches souhaité. Envisagez les actions suivantes :

• Vérifier Cloudwatch Alarms.
• Vérifier si des déploiements ont été planifiés.

ResourceInitializationError : impossible d'extraire les secrets ou l'authentification du registre : échec de la récupération des ressources d'exécution

Pour résoudre cette erreur, consultez Comment résoudre l'erreur « Unable to pull secrets or registry auth » (Impossible d'extraire les secrets ou l'authentification du registre) dans Amazon ECS ?

CannotPullContainerError

Cette erreur indique que le rôle d'exécution des tâches utilisé n'est pas autorisé à communiquer avec Amazon ECS. Pour résoudre ce problème :

• Vérifiez que le rôle d'exécution des tâches possède les autorisations nécessaires. Amazon ECS fournit la politique gérée nommée AmazonECSTaskExecutionRolePolicy qui contient les autorisations pour la plupart des cas d'utilisation.
• Vérifiez que le point de terminaison de service ECR est accessible à :ecr.region.amazonaws.com et dkr.ecr.region.amazonaws.com
• Pour les images privées nécessitant une authentification, assurez-vous que les paramètres repositoryCredentials et credentialsParameter sont définis avec les informations correctes. Pour plus d'informations, consultez Authentification du registre privé pour les tâches.

Tâche arrêtée par l'utilisateur

Cela indique que la tâche a reçu un StopTask. Vous pouvez identifier qui a initié l'appel en consultant StopTask dans CloudTrail pour obtenir des informations sur userIdentity.

Codes de sortie courants

• 0 : le point d'entrée, le succès ou le CMD termine son exécution et le conteneur est donc arrêté.
• 1 : fait référence à une erreur d'application. Pour plus d'informations, consultez les journaux de l'application.
• 137 : se produit lorsque la tâche a été forcée de quitter (SIGKILL) pour le conteneur :
  Ne pas répondre à un SIGTERM dans un délai par défaut de 30 secondes après lequel la valeur SIGKILL est envoyée et les conteneurs sont arrêtés de force. La période de 30 secondes par défaut peut être configurée sur l'agent de conteneur ECS avec le paramètre ECS_CONTAINER_STOP_TIMEOUT.
  Cela peut également se produire dans une situation de mémoire insuffisante (OOM, Out-of-Memory). Passez en revue vos métriques CloudWatch pour vérifier si OOM s'est produit.
• 139 : se produit lorsqu'une erreur de segmentation se produit. Il est probable que l'application ait essayé d'accéder à une région de mémoire qui n'était pas disponible, ou qu'il existe une variable d'environnement non définie ou non valide.
• 255 : se produit lorsque la commande ENTRYPOINT CMD dans votre conteneur a échoué en raison d'une erreur. Consultez vos journaux CloudWatch Logs pour le confirmer.

Messages d'erreur courants

Aucune instance de conteneur n’a été trouvée dans votre cluster

Consultez la section Instances de conteneur pour votre cluster. Si nécessaire, vous pouvez lancer une instance de conteneur.

InvalidParameterException

Vérifiez que tous les paramètres définis dans TaskDefinition sont présents et que l'ARN est correct. Vérifiez que le rôle de tâche et le rôle d'exécution des tâches disposent d'autorisations suffisantes.

Vous avez atteint la limite du nombre de tâches que vous pouvez exécuter simultanément

Pour plus d'informations sur les limites, consultez ECS Service Quotas.

Pour toutes les autres demandes d'augmentation de quota, créez une demande dans la console AWS Support, puis choisissez Service Limit Increase (Augmentation de la limite de service).

---