Pourquoi ma tâche Amazon ECS est-elle bloquée à l'état EN ATTENTE ?

Brève description

Les scénarios suivants entraînent le blocage des tâches Amazon ECS à l'état EN ATTENTE :

• Le démon Docker ne répond pas.
• Il existe une contrainte de ressource dans le cluster.
• L'image Docker est volumineuse.
• L'agent de conteneur Amazon ECS a perdu la connectivité avec le service Amazon ECS en plein lancement d'une tâche.
• L'agent de conteneur Amazon ECS met longtemps à arrêter une tâche existante
• Vous n'avez pas correctement configuré votre routage Amazon Virtual Private Cloud (Amazon VPC).
• Un conteneur essentiel dépend de conteneurs non essentiels qui ne sont pas à l’état SAIN.
• Le rôle AWS Identity and Access Management (IAM) que vous avez associé à vos tâches Amazon ECS est manquant ou incorrect.
• Il existe des problèmes de compatibilité d’images avec la version de Windows que vous avez sélectionnée.

Résolution

Remarque : Si des erreurs surviennent lorsque vous exécutez des commandes de l'interface de la ligne de commande AWS (AWS CLI), consultez la section Résoudre des erreurs liées à l’AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l’AWS CLI.

Le démon Docker ne répond pas ou il existe une contrainte de ressource dans le cluster

Dans la définition de tâche, vérifiez si la tâche demande plus de mémoire ou de processeur que ce que l'instance ne peut supporter. Ajustez vos ressources d’instance de conteneur en fonction de vos besoins.

Pour les problèmes liés au processeur, procédez comme suit :

1. Utilisez les métriques Amazon CloudWatch pour vérifier si votre instance de conteneur a dépassé le quota maximal de processeurs.
2. Augmentez la taille de votre instance de conteneur selon vos besoins.

Pour les problèmes de mémoire, procédez comme suit :

1. Exécutez la commande free pour connaître la quantité de mémoire disponible pour votre système.
2. Augmentez la taille de votre instance de conteneur selon vos besoins.

Pour les problèmes d'E/S, procédez comme suit :

1. Exécutez la commande iotop.
2. Identifiez les tâches de chaque service qui utilisent le plus d'opérations d'entrée/sortie par seconde (IOPS).
3. Utilisez des contraintes et stratégies de placement des tâches pour répartir ces tâches sur des instances de conteneur distinctes.
   -ou-
   Utilisez CloudWatch pour créer une alarme pour vos métriques d’équilibrage des rafales Amazon Elastic Block Store (Amazon EBS). Puis, utilisez une fonction AWS Lambda ou votre logique personnalisée pour équilibrer les tâches.

L'image Docker est volumineuse

Le téléchargement d'images plus volumineuses prend plus de temps et augmente la durée pendant laquelle la tâche est à l’état EN ATTENTE.

Pour accélérer le temps de transition, définissez le paramètre ECS_IMAGE_PULL_BEHAVIOR pour utiliser la mise en cache des images. Par exemple, définissez le paramètre ECS_IMAGE_PULL_BEHAVIOR sur prefer-cached dans /etc/ecs/ecs.config. Si vous utilisez prefer-cached, Amazon ECS extrait l'image à distance lorsqu'aucune image n'est mise en cache. Dans le cas contraire, Amazon ECS utilise l'image mise en cache sur l'instance.

L'agent de conteneur Amazon ECS a perdu la connectivité avec le service Amazon ECS au milieu d'un lancement

Pour vérifier l'état et la connectivité de l'agent de conteneur Amazon ECS, exécutez les commandes suivantes sur votre instance de conteneur en fonction de votre version Amazon Linux.

Amazon Linux 1 :

sudo status ecs
sudo docker ps -f name=ecs-agent

Amazon Linux 2 :

sudo systemctl status ecs
sudo docker ps -f name=ecs-agent

Si l'état de la sortie est inactif, l'agent est déconnecté. Pour résoudre ce problème, exécutez les commandes suivantes pour redémarrer votre agent de conteneur.

Amazon Linux 1 :

sudo stop ecs
sudo start ecs

Amazon Linux 2 :

sudo systemctl stop ecs
sudo systemctl start ecs

Exemple de sortie :

ecs start/running, process abcd

Pour déterminer la connectivité de l’agent, consultez les journaux suivants pendant la période concernée pour y rechercher des mots-clés comme erreur, avertir ou état de transition de l’agent :

• Consultez le journal de l'agent de conteneur Amazon ECS dans le fichier /var/log/ecs/ecs-agent.log.yyyy-mm-dd-hh.
• Consultez le journal init Amazon ECS dans le fichier /var/log/ecs/ecs-init.log.
• Consultez les journaux Docker dans le fichier /var/log/docker.

Utilisez les informations contenues dans les journaux pour identifier la cause racine des problèmes de connectivité.

Remarque : Vous pouvez également utiliser le collecteur de journaux Amazon ECS pour collecter les journaux généraux du système d'exploitation, les journaux Docker et les journaux de l’agent de conteneur Amazon ECS.

Pour extraire l'état des tâches locales en temps réel dans l'instance de conteneur, exécutez la commande suivante pour afficher les métadonnées des tâches en cours d'exécution dans votre instance de conteneur :

curl http://localhost:51678/v1/metadata

Vous obtenez une sortie similaire à l’exemple suivant :

{  "Cluster": "CLUSTER_ID",
  "ContainerInstanceArn": "arn:aws:ecs:REGION:ACCOUNT_ID:container-instance/TASK_ID",
  "Version": "Amazon ECS Agent - AGENT "
}

Dans la sortie, assurez-vous que les variables d'environnement des tâches, le processeur, la mémoire et la configuration des rôles IAM sont corrects. Assurez-vous également que la tâche contient les secrets requis.

Pour afficher des informations détaillées sur toutes les tâches exécutées dans le service, exécutez la commande suivante :

curl http://localhost:51678/v1/tasks

Vous obtenez une sortie similaire à l’exemple suivant :

{  "Tasks": [
    {
      "Arn": "arn:aws:ecs:REGION:ACCOUNT_ID:task/TASK_ID",
      "DesiredStatus": "RUNNING",
      "KnownStatus": "RUNNING",
      ... ...
    }
  ]
}

Dans les sorties de commande précédentes, vérifiez s'il existe des différences entre l'agent local et le service Amazon ECS. Utilisez ces informations pour identifier où et pourquoi la tâche est bloquée.

L'agent de conteneur Amazon ECS met beaucoup de temps pour arrêter une tâche existante

Lorsqu'Amazon ECS envoie de nouvelles tâches pour passer de l'état EN ATTENTE à l'état EN COURS D’EXÉCUTION, l'agent de conteneur peut avoir des tâches existantes à arrêter. Dans ce cas, l'agent ne démarre les nouvelles tâches que lorsqu'il arrête d'abord les tâches existantes.

Pour contrôler le délai d'arrêt et de démarrage du conteneur au niveau de l'instance du conteneur, ajustez les variables d'environnement pour les variables ECS_CONTAINER_STOP_TIMEOUT et ECS_CONTAINER_START_TIMEOUT dans /etc/ecs/ecs.config. ECS_CONTAINER_STOP_TIMEOUT définit le délai qui s'écoule avant qu'Amazon ECS arrête de force vos conteneurs s'ils ne sortent pas d'eux-mêmes. La valeur du délai d'arrêt par défaut pour Linux et Windows est de 30 secondes. ECS_CONTAINER_START_TIMEOUT définit le délai qui s'écoule avant que l'agent de conteneur Amazon ECS n'essaie plus de démarrer le conteneur. La valeur du délai de démarrage par défaut est de 3 minutes pour Linux et de 8 minutes pour Windows.

Si la version de votre agent est 1.26.0 ou version ultérieure, vous pouvez définir les paramètres de délai d'arrêt et de démarrage précédents pour chaque tâche. Notez que lorsque vous modifiez le paramètre, la tâche peut passer à l'état ARRÊTÉ. Par exemple, l'instance de conteneur A dépend de l'état TERMINÉ, RÉUSSITE ou SAIN de l'instance de conteneur B. Vous n'avez pas spécifié de valeur startTimeout pour l'instance de conteneur B. Si l'instance de conteneur B n'atteint pas l'état requis dans le délai imparti, l'instance de conteneur A ne démarre pas.

Pour un exemple de dépendance entre conteneurs, consultez la page Exemple : Dépendance de conteneur sur le site Web de GitHub.

Vous n'avez pas correctement configuré votre routage Amazon VPC

Vérifiez la configuration du sous-réseau VPC dans lequel vos tâches Amazon ECS ou AWS Fargate s'exécutent. Votre sous-réseau doit avoir accès à Amazon ECS ou à Amazon Elastic Container Registry (Amazon ECR). Pour résoudre les problèmes de configuration, assurez-vous que la table de routage de votre sous-réseau possède une passerelle Internet ou une passerelle NAT. Si vous lancez une tâche dans un sous-réseau qui n’utilise pas de route sortante vers Internet, utilisez AWS PrivateLink. Cette configuration vous permet d'accéder aux API Amazon ECS avec des adresses IP privées.

Assurez-vous également que les règles de votre groupe de sécurité autorisent les communications entrantes et sortantes via les ports requis de votre configuration.

Une instance de conteneur essentielle dépend d'instances de conteneurs non essentielles qui ne se trouvent pas à l'état SAIN

Si une instance de conteneur non essentielle dont dépend une instance de conteneur essentielle n'est pas à l’état SAIN, votre tâche reste bloquée à l’état EN ATTENTE. Le message « stoppedReason » : « Service ABCXYZ: task last status remained in PENDING too long » (Service ABCXYZ : le dernier état de la tâche est resté EN ATTENTE trop longtemps) s'affiche.

Pour résoudre ce problème, assurez-vous que votre conteneur non essentiel fonctionne comme prévu. Si vous ne parvenez pas à résoudre le problème sous-jacent, mettez à jour la définition de tâche pour les instances de conteneur et définissez le paramètre essentiel sur vrai. Si la tâche est toujours arrêtée, vérifiez la raison de l'arrêt. Pour plus d'étapes de résolution des problèmes, consultez la section Pourquoi ma tâche Amazon ECS est-elle arrêtée ?

Le rôle IAM est manquant ou mal configuré

Si la tâche se trouve dans une instance de conteneur ne disposant pas des autorisations requises, vous recevez une erreur similaire à l'exemple suivant :

« (service test) failed to launch a task with (error ECS was unable to assume the role 'arn:aws:iam::111111111111:role/test-fTa-T3J4hVnyL53E' that was provided for this task. Please verify that the role being passed has the proper trust relationship and permissions and that your IAM user has permissions to pass this role.) ((test de service) n'a pas pu lancer une tâche avec (erreur) ECS n'a pas pu assumer le rôle 'arn:aws:iam::111111111111:role/test-fTa-T3J4hVnyL53E' qui a été fourni pour cette tâche. Vérifiez que le rôle transmis possède la relation de confiance et les autorisations appropriées et que votre utilisateur IAM est autorisé à transmettre ce rôle)

Pour résoudre ce problème, assurez-vous que l'instance de conteneur dispose des autorisations requises.

De plus, si vous n'utilisez pas d'Amazon Machine Image (AMI) optimisée pour Amazon ECS pour vos instances de conteneur, vérifiez les configurations de votre agent Amazon ECS.

Il existe des problèmes de compatibilité des images avec la version de Windows que vous avez sélectionnée

Les tâches échouent lorsque l'image que vous utilisez dans les tâches Windows Fargate n'est pas compatible avec votre plateforme. Pour vérifier si votre image est compatible avec l'hôte du serveur Windows, consultez la page Compatibilité des versions du conteneur Windows sur le site Web de Microsoft. Puis, vérifiez les prérequis pour exécuter les tâches Windows.

Assurez-vous également que l'URL de l'image que vous avez définie est exacte.

Informations connexes

Dépendance du conteneur

amazon-ecs-agent sur le site Web de GitHub