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.
# Dépannage d'Amazon ECS
Vous devrez peut-être résoudre des problèmes liés à vos équilibreurs de charge, tâches, services ou instances de conteneur. Ce chapitre vous aide à trouver les informations de diagnostic à partir de l'agent de conteneur Amazon ECS, du démon Docker sur l'instance de conteneur et du journal des événements de service de la console Amazon ECS.
Pour plus d’informations sur les tâches arrêtées, consultez l’une des rubriques suivantes.
| Action | En savoir plus |
| --- | --- |
| Résoudre les erreurs liées aux tâches arrêtées. | [Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md) |
| Afficher les erreurs liées aux tâches arrêtées. | [Résolution des erreurs liées aux tâches Amazon ECS arrêtées](resolve-stopped-errors.md) |
| Vérifier les codes d’erreur des tâches arrêtées. | [Messages d’erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-error-codes.md) |
| Vérifiez les erreurs liées aux CannotPullContainer tâches. | [CannotPullContainer erreurs de tâche dans Amazon ECS](task_cannot_pull_image.md) |
| Afficher les requêtes de rôle IAM de tâche. | [Affichage des requêtes de rôle IAM pour des tâches Amazon ECS](task_iam_roles-logs.md) |
| Résoudre les problèmes liés à l'utilisation d'événements de tâches. | [Capture d'événements Amazon ECS dans la console](task-lifecycle-events.md) |
Pour plus d’informations sur les erreurs de service, consultez l’une des rubriques suivantes.
| Action | En savoir plus |
| --- | --- |
| Afficher les messages d’événements de service. | [Affichage des messages d’événement d’un service Amazon ECS](service-event-messages.md) |
| Vérifier les messages d’événements de service. | [Messages d’événement de service Amazon ECS](service-event-messages-list.md) |
| Vérifier les problèmes liés à l’équilibreur de charge. | [Résolution des problèmes liés aux équilibreurs de charge des services dans Amazon ECS](troubleshoot-service-load-balancers.md) |
| Vérifier les problèmes liés à l’autoscaling du service. | [Résolution des problèmes d’autoscaling du service dans Amazon ECS](troubleshoot-service-auto-scaling.md) |
Pour plus d’informations sur les erreurs de définition de tâche, consultez l’une des rubriques suivantes.
| Action | En savoir plus |
| --- | --- |
| Résoudre l’erreur de mémoire liée à la de définition de tâche. | [Résolution des erreurs d’UC ou de mémoire non valides liées à la définition des tâches Amazon ECS](task-cpu-memory-error.md) |
Pour plus d’informations sur les erreurs d’agent Amazon ECS, consultez l’une des rubriques suivantes.
| Action | En savoir plus |
| --- | --- |
| Afficher le journal d’agent de conteneur Amazon ECS | [Affichage du journal d’agent de conteneur Amazon ECS](logs.md) |
| Découvrir comment collecter les journaux Amazon ECS. | [Collecte des journaux de conteneur avec collecteur de journaux Amazon ECS](ecs-logs-collector.md) |
| Récupérer les informations de diagnostic avec l’agent Amazon ECS. | [Récupération des informations de diagnostic d’Amazon ECS avec l’introspection d’agent](introspection-diag.md) |
Pour plus d’informations sur les erreurs Docker, consultez l’une des rubriques suivantes.
| Action | En savoir plus |
| --- | --- |
| Utiliser les diagnostics Docker. | [Diagnostic Docker dans Amazon ECS](docker-diags.md) |
| Activer le mode de débogage Docker. | [Configuration de la sortie détaillée du démon Docker dans Amazon ECS](docker-debug-mode.md) |
| Résoudre l’erreur 500 de l’API Docker. | [Résolution des problèmes liés à `API error (500): devmapper` de Docker dans Amazon ECS](CannotCreateContainerError.md) |
Pour plus d’informations sur les erreurs d’ECS Exec et d’Amazon ECS Anywhere, consultez l’une des rubriques suivantes.
| Action | En savoir plus |
| --- | --- |
| Résoudre les problèmes liés à ECS Exec. | [Résolution des problèmes liés à Amazon ECS Exec](ecs-exec-troubleshooting.md) |
| Résoudre les problèmes liés à Amazon ECS Anywhere. | [Résolution des problèmes liés à Amazon ECS Anywhere](ecs-anywhere-troubleshooting.md) |
Pour plus d’informations sur les problèmes liés à l’association de volumes Amazon EBS à des tâches Amazon ECS, consultez l’un des points suivants :
| Action | En savoir plus |
| --- | --- |
| Résolution des problèmes liés à l’association de volumes Amazon EBS à des tâches Amazon ECS. | [Résolution des problèmes liés à l’attachement de volumes Amazon EBS aux tâches Amazon ECS](troubleshoot-ebs-volumes.md) |
| Raisons du statut des volumes Amazon EBS associés aux tâches Amazon ECS. | [Raisons du statut de l’attachement d’un volume Amazon EBS aux tâches Amazon ECS](troubleshoot-ebs-volumes-scenarios.md) |
Pour plus d'informations sur les problèmes liés à l'utilisation d' AWS Cloud Map espaces de noms partagés avec Amazon ECS Service Connect, consultez l'un des sites suivants :
| Action | En savoir plus |
| --- | --- |
| Résolution des problèmes liés à Amazon ECS Service Connect avec des AWS Cloud Map espaces de noms partagés. | [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 plus d’informations sur les problèmes de limitation, consultez l’une des rubriques suivantes :
| Action | En savoir plus |
| --- | --- |
| En savoir plus sur les quotas de limitation de Fargate. | [AWS Fargate limitation des quotas](throttling.md) |
| Découvrir les pratiques exemplaires en matière de limitation pour Amazon ECS. | [Gestion des problèmes de limitation d’Amazon ECS](operating-at-scale-dealing-with-throttles.md) |
Pour plus d’informations sur les erreurs d’API, consultez l’une des rubriques suivantes.
| Action | En savoir plus |
| --- | --- |
| Résoudre les erreurs d’API. | [Motifs d’échec d’API Amazon ECS](api_failures_messages.md) |
Pour plus d'informations sur le dépannage basé sur l'IA, consultez les rubriques suivantes :
| Action | En savoir plus |
| --- | --- |
| Résolvez les problèmes avec Amazon Q Developer dans la console. | [Résolution des problèmes avec Amazon Q Developer](troubleshooting-with-Q.md) |
| Résolvez les problèmes liés aux assistants IA à l'aide du serveur Amazon ECS MCP. | [Serveur Amazon ECS MCP](ecs-mcp-introduction.md) |
# Résolution des erreurs liées aux tâches Amazon ECS arrêtées
Lorsque votre tâche ne démarre pas, un message d’erreur s’affiche dans la console et dans les paramètres de sortie `describe-tasks` (`stoppedReason` et `stopCode`).
Vous pouvez consulter les tâches arrêtées dans la console pendant une heure. Pour voir les tâches arrêtées, vous devez modifier l’option de filtre. Pour de plus amples informations, veuillez consulter [Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md).
Les pages suivantes fournissent des informations sur les tâches arrêtées.
+ Découvrez les modifications apportées aux messages d’erreur relatifs aux tâches arrêtées.
[Mises à jour des messages d’erreurs liées aux tâches Amazon ECS arrêtées](stopped-tasks-error-messages-updates.md)
+ Afficher vos tâches arrêtées afin d’obtenir des informations sur la cause.
[Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md)
+ En savoir plus sur les messages d’erreur liés aux tâches arrêtées et les causes possibles de ces erreurs.
[Messages d’erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-error-codes.md)
+ Découvrir comment vérifier la connectivité des tâches arrêtées et corriger les erreurs.
[Vérification de la connectivité de la tâche Amazon ECS arrêtée](verify-connectivity.md)
# Mises à jour des messages d’erreurs liées aux tâches Amazon ECS arrêtées
À compter du 14 juin 2024, l’équipe Amazon ECS modifiera les messages d’erreur relatifs aux tâches arrêtées, comme décrit dans les tableaux suivants. Les `stopCode` ne changeront pas. Si vos applications sont basées sur une correspondance exacte des chaînes de messages d’erreur, vous devez les mettre à jour avec les nouvelles chaînes. Pour obtenir de l'aide en cas de questions ou de problèmes, contactez AWS Support.
**Note**
Nous vous recommandons de ne pas vous fier aux messages d’erreur pour votre automatisation, car ils sont susceptibles de changer.
## CannotPullContainerError
| Ancien message d’erreur | Nouveau messages d’erreur |
| --- | --- |
| CannotPullContainerError: Réponse d'erreur du démon : accès au pull refusé pourrepository, le référentiel n'existe pas ou peut nécessiter une « connexion docker » : refusé : utilisateur : roleARN | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/stopped-tasks-error-messages-updates.html) |
| CannotPullContainerError: Réponse d'erreur du démon : Get imageURI : net/http : demande annulée en attendant la connexion | CannotPullContainerError: La tâche ne peut pas extraire l'image. Vérifiez la configuration de votre réseau. Réponse d'erreur du démon : Get : net/http image : demande annulée en attendant la connexion (Client.Timeout dépassé pendant l'attente des en-têtes) |
| CannotPullContainerError: ref pull a été réessayé 5 fois : échec de la copie : échec de l'ouverture httpReadSeeker : échec de la demande : Get : dial tcp registry-uri : timeout i/o | CannotPullContainerError: La tâche ne peut pas être image-uri extraite du registreregistry-uri. Il existe un problème de connexion entre la tâche et le registre. Vérifiez la configuration de votre réseau de tâches. : échec de la copie httpReadSeeker : échec de l'ouverture : échec de la demande : Get registry-uri : dial tcp : timeout i/o |
## ResourceNotFoundException
| Ancien message d’erreur | Nouveau messages d’erreur |
| --- | --- |
| Récupération de données secrètes depuis AWS Secrets Manager la region région : secret sercretARN : ResourceNotFoundException : Secrets Manager ne trouve pas le secret spécifié. | ResourceNotFoundException: La tâche ne peut pas récupérer le secret dont l'ARN est « sercretARN » à partir de AWS Secrets Manager. Vérifiez si le secret existe dans la région spécifiée. ResourceNotFoundException: Récupération de données secrètes depuis AWS Secrets Manager la région region : secret sercretARN : ResourceNotFoundException : Secrets Manager ne trouve pas le secret spécifié. |
## ResourceInitializationError
| Ancien message d’erreur | Nouveau messages d’erreur |
| --- | --- |
| ResourceInitializationError: impossible d'extraire les secrets ou l'authentification du registre : échec de la récupération de la ressource d'exécution : impossible de récupérer l'authentification du registre ECR : l'appel de service a été retenté 3 fois : : échec de la demande d'envoi dû à RequestError : Post «https://api.ecr.us-east-1.amazonaws.com/» : dial tcp : : timeout. i/o Veuillez vérifier la configuration réseau de votre tâche. | ResourceInitializationError: impossible d'extraire les secrets ou l'authentification du registre : la tâche ne peut pas extraire l'authentification du registre depuis Amazon ECR : il y a un problème de connexion entre la tâche et Amazon ECR. Vérifiez la configuration de votre réseau de tâches. RequestError: échec de la demande d'envoi dû à : Post "https://api.ecr.us-east-1.amazonaws.com« : dial tcp : : timeout i/o |
| ResourceInitializationError: impossible d'extraire les secrets ou l'authentification du registre : échec de la récupération des ressources d'exécution : impossible de récupérer les secrets de ssm : l'appel de service a été retenté 5 fois : : le contexte de la demande a été annulé en raison du RequestCanceled dépassement de la date limite du contexte | ResourceInitializationError: impossible d'extraire les secrets ou l'authentification du registre : impossible de récupérer les secrets de SSM : la tâche ne peut pas extraire les secrets de. AWS Systems Manager Il existe un problème de connexion entre la tâche et le magasin de paramètres AWS Systems Manager . Vérifiez la configuration de votre réseau de tâches. RequestCanceled: contexte de demande annulé en raison de : date limite de contexte dépassée |
| ResourceInitializationError: échec du téléchargement des fichiers env : commande de téléchargement de fichier : flux d'erreur non vide : RequestCanceled : contexte de demande annulé en raison du dépassement de la date limite du contexte | ResourceInitializationError: échec du téléchargement des fichiers env : la tâche ne peut pas télécharger les fichiers de variables d'environnement depuis Amazon S3. Il existe un problème de connexion entre la tâche et Amazon S3. Vérifiez la configuration de votre réseau de tâches. L'appel de service a été réessayé 5 fois : RequestCanceled : le contexte de la demande a été annulé en raison du dépassement de la date limite du contexte |
| ResourceInitializationError: échec de la validation du logger args : :signal:killed | ResourceInitializationError: échec de la validation des arguments de l'enregistreur : la tâche ne trouve pas le groupe de CloudWatch journaux Amazon défini dans la définition de la tâche. Il existe un problème de connexion entre la tâche et Amazon CloudWatch. Vérifiez la configuration de votre réseau. : signal : supprimé |
| ResourceInitializationError: impossible d'extraire les secrets ou l'authentification du registre : échec de la commande pull : signal : tué | ResourceInitializationError: impossible d'extraire les secrets ou l'authentification du registre : vérifiez la configuration de votre réseau de tâches. : signal : tué |
# Affichage des erreurs liées aux tâches Amazon ECS arrêtées
Si vous avez des difficultés à démarrer une tâche, cette dernière peut avoir été arrêtée en raison d'une application ou d'erreurs de configuration. Par exemple, vous exécutez la tâche et elle affiche un statut `PENDING`, puis disparaît.
Si votre tâche a été créée par un service Amazon ECS, les actions entreprises par Amazon ECS pour gérer le service sont publiées dans les événements du service. Vous pouvez consulter les événements dans AWS Management Console AWS CLI l' AWS SDKsAPI Amazon ECS ou dans les outils utilisant l'API SDKs et. Ces événements incluent l'arrêt et le remplacement d'une tâche par Amazon ECS parce que les conteneurs de la tâche ont cessé de s'exécuter ou parce qu'un trop grand nombre de surveillances de l'état effectuées par Elastic Load Balancing ont échoué.
Si votre tâche a été exécutée sur une instance de conteneur sur Amazon EC2 ou sur des ordinateurs externes, vous pouvez également consulter les journaux de l’environnement d’exécution du conteneur et de l’agent Amazon ECS. Ces journaux se trouvent sur l’instance Amazon EC2 hôte ou sur un ordinateur externe. Pour de plus amples informations, veuillez consulter [Affichage du journal d’agent de conteneur Amazon ECS](logs.md).
## Procédure
------
#### [ Console ]
**AWS Management Console**
Les étapes suivantes peuvent être utilisées pour rechercher des erreurs dans les tâches arrêtées à l’aide de la console. Pour voir les tâches arrêtées, vous devez modifier l’option de filtre.
Les tâches arrêtées n’apparaissent dans la console que pendant une heure.
1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2).
1. Dans le panneau de navigation, choisissez **Clusters**.
1. Sur la page **Clusters**, choisissez le cluster.
1. Sur la *name* page **Cluster :**, choisissez l'onglet **Tâches**.
1. Configurez le filtre pour afficher les tâches arrêtées. Pour **Filtrer selon le statut souhaité**, choisissez **Arrêté**.
L'option **Arrêté** affiche vos tâches arrêtées et l'option **Tout statut souhaité** affiche toutes vos tâches.
1. Choisissez la tâche arrêtée à inspecter.
1. Dans la ligne correspondant à votre tâche arrêtée, dans la colonne **Dernier statut**, choisissez **Arrêté**.
Une fenêtre contextuelle affiche le motif de l’arrêt.
------
#### [ AWS CLI ]
1. Répertoriez les tâches arrêtées d'un cluster. La sortie contient l'Amazon Resource Name (ARN) de la tâche, dont vous avez besoin pour décrire la tâche.
```
aws ecs list-tasks \
--cluster cluster_name \
--desired-status STOPPED \
--region region
```
1. Décrivez la tâche arrêtée pour récupérer les informations. *Pour plus d'informations, consultez la section [describe-tasks](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-tasks.html) dans la AWS Command Line Interface référence.*
```
aws ecs describe-tasks \
--cluster cluster_name \
--tasks arn:aws:ecs:region:account_id:task/cluster_name/task_ID \
--region region
```
Utilisez les paramètres de sortie suivants.
+ `stopCode`- Le code d'arrêt indique pourquoi une tâche a été arrêtée, par exemple ResourceInitializationError
+ `StoppedReason` : la raison pour laquelle la tâche s’est arrêtée.
+ `reason` (dans la structure `containers`) : la raison fournit des détails supplémentaires sur le conteneur arrêté.
------
## Étapes suivantes
Afficher vos tâches arrêtées afin d’obtenir des informations sur la cause. Pour de plus amples informations, veuillez consulter [Messages d’erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-error-codes.md).
# Messages d’erreurs liées aux tâches Amazon ECS arrêtées
Voici les messages d’erreur possibles que vous pouvez recevoir lorsque votre tâche est arrêtée de façon inattendue.
Pour vérifier la présence d'un message d'erreur dans vos tâches arrêtées à l'aide du AWS Management Console, voir[Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md).
**Astuce**
Vous pouvez utiliser les assistants [Serveur Amazon ECS MCP](ecs-mcp-introduction.md) dotés d'IA pour analyser les échecs de tâches et les journaux de conteneurs en langage naturel.
Les codes d'erreur des tâches arrêtées sont associés à une catégorie, par exemple « ResourceInitializationError ». Pour plus d’informations sur chaque catégorie, consultez les rubriques suivantes :
| Catégorie | En savoir plus |
| --- | --- |
| TaskFailedToStart | [Résolution des TaskFailedToStart erreurs Amazon ECS](failed-to-start-error.md) |
| ResourceInitializationError | [Résolution des ResourceInitializationError erreurs Amazon ECS](resource-initialization-error.md) |
| ResourceNotFoundException | [Résolution des ResourceNotFoundException erreurs Amazon ECS](resource-not-found-error.md) |
| SpotInterruptionError | [Résolution des SpotInterruption erreurs Amazon ECS](spot-interruption-errors.md) |
| InternalError | [Résolution des InternalError erreurs Amazon ECS](internal-error.md) |
| OutOfMemoryError | [Résolution des OutOfMemoryError erreurs Amazon ECS](out-of-memory.md) |
| ContainerRuntimeError | [Résolution des ContainerRuntimeError erreurs Amazon ECS](container-runtime-error.md) |
| ContainerRuntimeTimeoutError | [Résolution des ContainerRuntimeTimeoutError erreurs Amazon ECS](container-runtime-timeout-error.md) |
| CannotStartContainerError | [Résolution des CannotStartContainerError erreurs Amazon ECS](cannot-start-container.md) |
| CannotStopContainerError | [Résolution des CannotStopContainerError erreurs Amazon ECS](cannot-stop-container.md) |
| CannotInspectContainerError | [Résolution des CannotInspectContainerError erreurs Amazon ECS](cannot-inspect-container.md) |
| CannotCreateVolumeError | [Résolution des CannotCreateVolumeError erreurs Amazon ECS](cannot-create-volume.md) |
| CannotPullContainer | [CannotPullContainer erreurs de tâche dans Amazon ECS](task_cannot_pull_image.md) |
# Résolution des TaskFailedToStart erreurs Amazon ECS
Vous trouverez ci-dessous quelques messages d’erreur `TaskFailedToStart` et les actions que vous pouvez entreprendre pour corriger ces erreurs.
Pour vérifier la présence d'un message d'erreur dans vos tâches arrêtées à l'aide du AWS Management Console, voir[Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md).
## Erreur EC2 inattendue lors de la tentative de création d'une interface réseau avec l'attribution d'adresses IP publiques activée dans le sous-réseau '*subnet-id*
Cela se produit lorsqu’une tâche Fargate utilisant le mode réseau `awsvpc` s’exécute dans un sous-réseau doté d’une adresse IP publique et que le sous-réseau ne possède pas suffisamment d’adresses IP.
Le nombre d’adresses IP disponibles est indiqué sur la page des détails du sous-réseau dans la console Amazon EC2 ou en utilisant `[describe-subnets](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-subnets.html)`. Pour plus d’informations, consultez la section [Afficher votre sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#view-subnet) dans le *Guide de l’utilisateur Amazon VPC*.
Pour résoudre ce problème, vous pouvez créer un sous-réseau dans lequel exécuter votre tâche.
## InternalError: **
Cette erreur se produit lorsqu'une pièce jointe ENI est demandée. Amazon EC2 gère de manière asynchrone le provisionnement de l'ENI. Le processus de provisionnement prend du temps. Amazon ECS dispose d'un délai d'expiration au cas où les temps d'attente seraient longs ou les défaillance non signalées. Parfois, l'ENI est provisionnée, mais le rapport arrive à Amazon ECS après l'expiration du délai de défaillance. Dans ce cas, Amazon ECS détecte la défaillance de la tâche signalée avec un ENI en cours d'utilisation.
## La définition de tâche sélectionnée n’est pas compatible avec la stratégie de calcul sélectionnée
Cette erreur se produit lorsque vous avez choisi une définition de tâche dont le type de lancement ne correspond pas au type de capacité du cluster. Vous devez sélectionner une définition de tâche qui correspond au fournisseur de capacité attribué à votre cluster.
## Impossible de connecter l’interface réseau à l’index des appareils non utilisés
Cette erreur se produit lorsque vous utilisez le type `awsvpc` de réseau et qu'il n'y en a pas assez CPU/memory pour la tâche. Tout d’abord, vérifiez que les instances sont bien présentes sur l’UC. Pour plus d’informations, consultez la section [Spécifications des types d’instances Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-instance-type-specifications.html) dans les *Types d’instances Amazon EC2*. Prenez la valeur du processeur pour l'instance et multipliez-la par le nombre de ENIs pour l'instance. Utilisez cette valeur e dans la définition de tâche.
## AGENT
L'instance de conteneur avec laquelle vous avez essayé de lancer une tâche comporte un agent qui est actuellement déconnecté. Afin d'éviter de longs délais d'attente pour le placement de la tâche, la demande a été rejetée.
Pour plus d'informations sur la résolution problèmes des agents déconnectés, consultez [Comment résoudre les problèmes liés à un agent Amazon ECS déconnecté ?](https://repost.aws/knowledge-center/ecs-agent-disconnected-linux2-ami).
# Résolution des ResourceInitializationError erreurs Amazon ECS
Vous trouverez ci-dessous quelques messages d’erreur `ResourceInitialization` et les actions que vous pouvez entreprendre pour corriger ces erreurs.
Pour vérifier la présence d'un message d'erreur dans vos tâches arrêtées à l'aide du AWS Management Console, voir[Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md).
**Topics**
+ [La tâche ne peut pas extraire l’authentification du registre depuis Amazon ECR. Il existe un problème de connexion entre la tâche et Amazon ECR. Vérifiez la configuration réseau de votre tâche.](#unable-to-pull-secrets-ecr)
+ [La tâche ne peut pas télécharger les fichiers de variables d’environnement à partir d’Amazon S3. Il existe un problème de connexion entre la tâche et Amazon S3. Vérifiez la configuration réseau de votre tâche.](#failed-to-download-env-files)
+ [La tâche ne peut pas extraire les secrets du AWS Systems Manager Parameter Store. Vérifiez votre connexion réseau entre la tâche et AWS Systems Manager.](#unable-to-pull-secrets-sys-manager)
+ [La tâche ne peut pas en extraire des secrets AWS Secrets Manager. Il existe un problème de connexion entre la tâche et Secrets Manager. Vérifiez la configuration réseau de votre tâche.](#unable-to-pull-secrets-asm-no-arn)
+ [La tâche ne peut pas extraire le secret depuis Secrets Manager. La tâche ne peut pas récupérer le secret avec l'ARN « *secretARN* » dans Secrets Manager. Vérifiez si le secret existe dans la région spécifiée.](#unable-to-pull-secrets-asm)
+ [échec de la commande d’extraction : impossible d’extraire les secrets ou l’authentification du registre Vérifiez la configuration réseau de votre tâche.](#pull-command-failed)
+ [La tâche ne trouve pas le groupe de CloudWatch journaux Amazon défini dans la définition de la tâche. Il existe un problème de connexion entre la tâche et Amazon CloudWatch. Vérifiez la configuration de votre réseau.](#failed-to-initialize-logging-network)
+ [échec de l’initialisation du pilote de journalisation](#failed-to-initialize-logging)
+ [échec de l’invocation des commandes EFS utils pour configurer les volumes EFS](#efs-utils-failed)
## La tâche ne peut pas extraire l’authentification du registre depuis Amazon ECR. Il existe un problème de connexion entre la tâche et Amazon ECR. Vérifiez la configuration réseau de votre tâche.
Cette erreur indique que la tâche ne peut pas se connecter à Amazon ECR.
Vérifiez la connexion entre la tâche et Amazon ECR. Pour plus d'informations, consultez [Vérification de la connectivité de la tâche Amazon ECS arrêtée](verify-connectivity.md).
## La tâche ne peut pas télécharger les fichiers de variables d’environnement à partir d’Amazon S3. Il existe un problème de connexion entre la tâche et Amazon S3. Vérifiez la configuration réseau de votre tâche.
Cette erreur se produit lorsque votre tâche ne parvient pas à télécharger votre fichier d’environnement depuis Amazon S3.
Vérifiez la connexion entre la tâche et le point de terminaison de VPC Amazon S3. Pour plus d'informations, consultez [Vérification de la connectivité de la tâche Amazon ECS arrêtée](verify-connectivity.md).
## La tâche ne peut pas extraire les secrets du AWS Systems Manager Parameter Store. Vérifiez votre connexion réseau entre la tâche et AWS Systems Manager.
Cette erreur se produit lorsque votre tâche ne parvient pas à extraire l’image définie dans la définition de tâche à l’aide des informations d’identification dans Systems Manager.
Vérifiez la connexion entre la tâche et le point de terminaison de VPC Systems Manager. Pour plus d'informations, consultez [Vérification de la connectivité de la tâche Amazon ECS arrêtée](verify-connectivity.md).
## La tâche ne peut pas en extraire des secrets AWS Secrets Manager. Il existe un problème de connexion entre la tâche et Secrets Manager. Vérifiez la configuration réseau de votre tâche.
Cette erreur se produit lorsque votre tâche ne parvient pas à extraire l’image définie dans la définition de tâche à l’aide des informations d’identification dans Secrets Manager.
L’erreur indique qu’il existe un problème de connectivité réseau entre le point de terminaison de VPC Systems Manager et la tâche.
Pour en savoir plus sur la vérification de la connectivité entre la tâche et le point de terminaison, consultez la section [Vérification de la connectivité de la tâche Amazon ECS arrêtée](verify-connectivity.md).
## La tâche ne peut pas extraire le secret depuis Secrets Manager. La tâche ne peut pas récupérer le secret avec l'ARN « *secretARN* » dans Secrets Manager. Vérifiez si le secret existe dans la région spécifiée.
Cette erreur se produit lorsque votre tâche ne parvient pas à extraire l’image définie dans la définition de tâche à l’aide des informations d’identification dans Secrets Manager.
Cela peut être dû à l’une des raisons suivantes.
| Cause de l’erreur. | Faites ceci... |
| --- | --- |
| Problème de connectivité réseau entre le point de terminaison de VPC Secrets Manager et la tâche. Le problème est lié au réseau lorsque l’une des chaînes suivantes apparaît dans le message d’erreur : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/resource-initialization-error.html) | Vérifiez la connectivité entre la tâche et le point de terminaison Secrets Manager. Pour de plus amples informations, veuillez consulter [Vérification de la connectivité de la tâche Amazon ECS arrêtée](verify-connectivity.md). |
| Le rôle d’exécution de la tâche défini dans la définition de la tâche ne dispose pas des autorisations nécessaires pour Secrets Manager. | Ajoutez les autorisations requises pour Secrets Manager au rôle d’exécution de tâche. Pour de plus amples informations, veuillez consulter [Autorisations Secrets Manager ou Systems Manager](task_execution_IAM_role.md#task-execution-secrets). |
| L’ARN secret n’existe pas | Vérifiez que l’ARN existe dans Secrets Manager. Pour plus d’informations sur l’affichage de vos images, consultez la section [Rechercher des secrets dans Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_search-secret.html) du Guide du développeur Secrets Manager. |
## échec de la commande d’extraction : impossible d’extraire les secrets ou l’authentification du registre Vérifiez la configuration réseau de votre tâche.
Cette erreur se produit lorsque votre tâche ne parvient pas à se connecter à Amazon ECR, Systems Manager ou Secrets Manager. Cela est dû à une mauvaise configuration de votre réseau.
Pour résoudre ce problème, vérifiez la connectivité entre la tâche et Amazon ECR. Vous devez également vérifier la connectivité entre votre tâche et le service qui stocke votre secret (Systems Manager ou Secrets Manager). Pour de plus amples informations, veuillez consulter [Vérification de la connectivité de la tâche Amazon ECS arrêtée](verify-connectivity.md).
## La tâche ne trouve pas le groupe de CloudWatch journaux Amazon défini dans la définition de la tâche. Il existe un problème de connexion entre la tâche et Amazon CloudWatch. Vérifiez la configuration de votre réseau.
Cette erreur se produit lorsque votre tâche ne trouve pas le groupe de CloudWatch journaux que vous avez défini dans la définition de la tâche.
L'erreur indique qu'il existe un problème de connectivité réseau entre le point de terminaison du CloudWatch VPC et la tâche.
Pour en savoir plus sur la vérification de la connectivité entre la tâche et le point de terminaison, consultez la section [Vérification de la connectivité de la tâche Amazon ECS arrêtée](verify-connectivity.md).
## échec de l’initialisation du pilote de journalisation
Cette erreur se produit lorsque votre tâche ne trouve pas le groupe de CloudWatch journaux que vous avez défini dans la définition de la tâche.
L'erreur indique que le CloudWatch groupe dans la définition de tâche n'existe pas.
Suivez les étapes ci-dessous pour trouver les éléments manquants CloudWatch.
1. Exécutez la commande suivante pour obtenir les informations de définition de la tâche.
```
aws ecs describe-task-definition \
--task-definition task-def-name
```
Examinez le résultat pour chaque conteneur et notez la valeur `awslogs-group`.
```
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/example-group",
"awslogs-create-group": "true",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
},
```
1. Vérifiez que le groupe existe. CloudWatch Pour plus d'informations, consultez la section [Utilisation des groupes de journaux et des flux de journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html) dans le *guide de l'utilisateur Amazon CloudWatch Logs*.
Le problème est soit que le groupe spécifié dans la définition de la tâche est incorrect, soit que le groupe de journaux n’existe pas.
1. Résolvez le problème.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/resource-initialization-error.html)
## échec de l’invocation des commandes EFS utils pour configurer les volumes EFS
Les problèmes suivants peuvent vous empêcher de monter vos volumes Amazon EFS selon vos demandes :
+ Le système de fichiers Amazon EFS n’est pas configuré correctement.
+ La tâche ne dispose pas des autorisations requises.
+ Certains problèmes sont liés à la configuration réseau et VPC.
Pour plus d'informations sur la façon de déboguer et de résoudre ce problème, consultez [Pourquoi ne puis-je pas monter mes volumes Amazon EFS sur mes AWS Fargate tâches sur](https://repost.aws/knowledge-center/fargate-unable-to-mount-efs) AWS Re:post.
# Résolution des ResourceNotFoundException erreurs Amazon ECS
Vous trouverez ci-dessous quelques messages d’erreur ` ResourceNotFoundException` et les actions que vous pouvez entreprendre pour corriger ces erreurs.
Pour vérifier la présence d'un message d'erreur dans vos tâches arrêtées à l'aide du AWS Management Console, voir[Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md).
## La tâche ne peut pas récupérer le secret dont l'ARN est *sercretARN* « » de AWS Secrets Manager. Vérifiez si le secret existe dans la région spécifiée.
Cette erreur se produit lorsque la tâche ne parvient pas à extraire le secret depuis Secrets Manager. Cela signifie que le secret spécifié dans la définition de la tâche (et contenu dans le message d’erreur) n’existe pas dans Secrets Manager.
La région figure dans le message d’erreur.
Récupération de données secrètes depuis AWS Secrets Manager la région *region* : secret *sercretARN* : ResourceNotFoundException : Secrets Manager ne trouve pas le secret spécifié.
Pour en savoir plus sur la recherche de Secrets Manager, consultez la section [Rechercher des secrets dans AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_search-secret.html) dans le *Guide de l’utilisateur AWS Secrets Manager *.
Utilisez le tableau suivant pour déterminer et corriger l’erreur.
| Problème | Actions |
| --- | --- |
| Le secret se trouve dans une région différente de celle de la définition de la tâche. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/resource-not-found-error.html) |
| L’ARN secret de la définition de tâche est incorrect. Le secret correct existe dans Secrets Manager. | Mettez à jour la définition de la tâche avec le secret correct. Pour plus d'informations, consultez [Mise à jour d’une définition de tâche Amazon ECS à l’aide de la console](update-task-definition-console-v2.md) ou consultez le [RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html)manuel Amazon Elastic Container Service API Reference. |
| Le secret n’existe plus. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/resource-not-found-error.html) |
# Résolution des SpotInterruption erreurs Amazon ECS
L'`SpotInterruption`erreur a différentes raisons pour Fargate et. EC2s
Pour vérifier la présence d'un message d'erreur dans vos tâches arrêtées à l'aide du AWS Management Console, voir[Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md).
## Fargate
L’erreur `SpotInterruption` se produit lorsqu’il n’y a pas de capacité Fargate Spot ou lorsque Fargate récupère la capacité de Fargate Spot.
Vous pouvez exécuter vos tâches dans plusieurs zones de disponibilité pour augmenter la capacité.
## EC2
Cette erreur se produit lorsqu’aucune instance Spot n’est disponible ou lorsqu’EC2 récupère la capacité de l’instance Spot.
Vous pouvez exécuter vos instances dans plusieurs zones de disponibilité pour augmenter la capacité.
# Résolution des InternalError erreurs Amazon ECS
**S’applique à** : Fargate
Pour vérifier la présence d'un message d'erreur dans vos tâches arrêtées à l'aide du AWS Management Console, voir[Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md).
L’erreur `InternalError` se produit lorsque l’agent rencontre une erreur interne inattendue, non liée à l’exécution.
Cette erreur se produit uniquement si vous utilisez la version `1.4` ou ultérieure de la plateforme.
Pour plus d’informations sur la manière de déboguer et de résoudre ce problème, consultez la section [Messages d’erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-error-codes.md).
# Résolution des OutOfMemoryError erreurs Amazon ECS
Vous trouverez ci-dessous des messages OutOfMemoryError d'erreur et des actions que vous pouvez entreprendre pour corriger les erreurs.
Pour vérifier la présence d'un message d'erreur dans vos tâches arrêtées à l'aide du AWS Management Console, voir[Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md).
## conteneur supprimé en raison de l’utilisation de la mémoire
Cette erreur se produit lorsqu’un conteneur est fermé parce que les processus qu’il contient consomment plus de mémoire que celle allouée dans la définition de la tâche, ou en raison de contraintes liées à l’hôte ou au système d’exploitation.
# Résolution des ContainerRuntimeError erreurs Amazon ECS
Vous trouverez ci-dessous des messages ContainerRuntimeError d'erreur et des actions que vous pouvez entreprendre pour corriger les erreurs.
Pour vérifier la présence d'un message d'erreur dans vos tâches arrêtées à l'aide du AWS Management Console, voir[Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md).
## ContainerRuntimeError
Cette erreur se produit lorsque l'agent reçoit une erreur inattendue de `containerd` pour une opération spécifique à l'exécution. Cette erreur est généralement causée par une défaillance interne de l'agent ou de l'environnement d'exécution `containerd`.
Cette erreur se produit uniquement si vous utilisez la version `1.4.0` ou ultérieure de la plateforme (Linux) ou `1.0.0`ou une version ultérieure (Windows).
Pour plus d'informations sur la façon de déboguer et de résoudre ce problème, consultez [Pourquoi ma tâche Amazon ECS est-elle arrêtée](https://repost.aws/knowledge-center/ecs-task-stopped) sur AWS Re:Post.
# Résolution des ContainerRuntimeTimeoutError erreurs Amazon ECS
Vous trouverez ci-dessous des messages ContainerRuntimeTimeoutError d'erreur et des actions que vous pouvez entreprendre pour corriger les erreurs.
Pour vérifier la présence d'un message d'erreur dans vos tâches arrêtées à l'aide du AWS Management Console, voir[Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md).
## Impossible de passer à l’exécution ; délai d’attente expiré après une minute ou erreur de délai d’attente Docker.
Cette erreur se produit lorsqu'un conteneur n'a pas pu passer à l'état `RUNNING` ou `STOPPED` dans le délai d'expiration. La raison et la valeur du délai d'expiration sont fournies dans le message d'erreur.
# Résolution des CannotStartContainerError erreurs Amazon ECS
Vous trouverez ci-dessous des messages CannotStartContainerError d'erreur et des actions que vous pouvez entreprendre pour corriger les erreurs.
Pour vérifier la présence d'un message d'erreur dans vos tâches arrêtées à l'aide du AWS Management Console, voir[Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md).
## Impossible d'obtenir le statut du conteneur : **
Cette erreur se produit lorsqu'un conteneur ne peut pas être démarré.
Si votre conteneur tente de dépasser la mémoire spécifiée ici, il est arrêté. Augmentez la mémoire présentée au conteneur. Il s’agit du paramètre `memory` figurant dans la définition de la tâche. Pour de plus amples informations, veuillez consulter [Mémoire](task_definition_parameters.md#container_definition_memory).
# Résolution des CannotStopContainerError erreurs Amazon ECS
Vous trouverez ci-dessous des messages CannotStopContainerError d'erreur et des actions que vous pouvez entreprendre pour corriger les erreurs.
Pour vérifier la présence d'un message d'erreur dans vos tâches arrêtées à l'aide du AWS Management Console, voir[Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md).
## CannotStopContainerError
Cette erreur se produit lorsqu'un conteneur ne peut pas être arrêté.
Pour plus d'informations sur la façon de déboguer et de résoudre ce problème, consultez [Pourquoi ma tâche Amazon ECS est-elle arrêtée](https://repost.aws/knowledge-center/ecs-task-stopped) sur AWS Re:Post.
# Résolution des CannotInspectContainerError erreurs Amazon ECS
Vous trouverez ci-dessous des messages CannotInspectContainerError d'erreur et des actions que vous pouvez entreprendre pour corriger les erreurs.
Pour vérifier la présence d'un message d'erreur dans vos tâches arrêtées à l'aide du AWS Management Console, voir[Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md).
## CannotInspectContainerError
Cette erreur se produit lorsque l'agent de conteneur ne peut pas décrire le conteneur via son environnement d'exécution.
Lors de l’utilisation de la version de plateforme `1.3` ou d’une version antérieure, l’agent ECS renvoie le motif de l’erreur à partir de Docker.
Lors de l’utilisation de la version de plateforme `1.4.0` ou ultérieure (Linux) ou de la version de plateforme `1.0.0` ou ultérieure (Windows), l’agent Fargate renvoie le motif de l’erreur depuis `containerd`.
Pour plus d'informations sur la façon de déboguer et de résoudre ce problème, consultez [Pourquoi ma tâche Amazon ECS est-elle arrêtée](https://repost.aws/knowledge-center/ecs-task-stopped) sur AWS Re:Post.
# Résolution des CannotCreateVolumeError erreurs Amazon ECS
Vous trouverez ci-dessous des messages CannotCreateVolumeError d'erreur et des actions que vous pouvez entreprendre pour corriger les erreurs.
Pour vérifier la présence d'un message d'erreur dans vos tâches arrêtées à l'aide du AWS Management Console, voir[Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md).
## CannotCreateVolumeError
Cette erreur se produit lorsque l'agent ne parvient pas à créer le montage de volume spécifié dans la définition de tâche.
Cette erreur se produit uniquement si vous utilisez la version `1.4.0` ou ultérieure de la plateforme (Linux) ou `1.0.0`ou une version ultérieure (Windows).
Pour plus d'informations sur la façon de déboguer et de résoudre ce problème, consultez [Pourquoi ma tâche Amazon ECS est-elle arrêtée](https://repost.aws/knowledge-center/ecs-task-stopped) sur AWS Re:Post.
# CannotPullContainer erreurs de tâche dans Amazon ECS
Les erreurs suivantes indiquent que la tâche n’a pas pu démarrer, car Amazon ECS ne parvient pas à récupérer l’image de conteneur spécifiée.
**Note**
La version 1.4 de la plateforme Fargate tronque les messages d'erreur longs.
Pour vérifier la présence d'un message d'erreur dans vos tâches arrêtées à l'aide du AWS Management Console, voir[Affichage des erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-errors.md).
**Astuce**
Vous pouvez utiliser les assistants dotés [Serveur Amazon ECS MCP](ecs-mcp-introduction.md) d'IA pour étudier les erreurs d'extraction d'images à l'aide du langage naturel.
**Topics**
+ [La tâche ne peut pas extraire l’image. Vérifiez que le rôle dispose des autorisations nécessaires pour extraire des images du registre.](#pull-request-image-not-found)
+ [La tâche ne peut pas extraire *image-name* « » du référentiel Amazon ECR « *repository URI* ». Il existe un problème de connexion entre la tâche et Amazon ECR. Vérifiez la configuration réseau de votre tâche.](#pull-image-io-timeout)
+ [La tâche ne peut pas extraire l’image. Vérification de la configuration de votre réseau](#pull-request-image-not-found-network)
+ [CannotPullContainerError: le manifeste pull image a été réessayé 5 fois : échec de la résolution de la référence](#pull-request-image-tag)
+ [Erreur API (500) : demande Get https://111122223333.dkr.ecr.us-east-1.amazonaws.com/v2/ : net/http : annulée en attendant la connexion](#request-canceled)
+ [Erreur d'API](#pull-request-api-error)
+ [write/var/lib/docker/tmp/*GetImageBlob111111111*: il ne reste plus d'espace sur l'appareil](#pull-request-write-error)
+ [ERREUR : toomanyrequests : trop de requêtes ou vous avez atteint votre limite de taux d’extraction.](#container-pull-too-many-requests)
+ [Réponse d'erreur du démon : Get *url* : net/http : demande annulée en attendant la connexion](#container-pull-request-canceled-connection)
+ [ref pull a été réessayé 1 fois : échec de la copie : échec de l'ouverture httpReaderSeeker : code d'état inattendu](#container-pull-failed-open)
+ [accès en extraction refusé](#container-pull-access-denied.title)
+ [échec de la commande d’extraction : panique : erreur d’exécution : adresse mémoire non valide ou déréférencement de pointeur nul](#container-pull-runtime-error.title)
+ [erreur lors de l' conf/error extraction de l'image lors de la configuration](#container-pull-pulling-image.title)
+ [Contexte annulé](#container-pull-context-canceled)
## La tâche ne peut pas extraire l’image. Vérifiez que le rôle dispose des autorisations nécessaires pour extraire des images du registre.
Cette erreur indique que la tâche ne peut pas extraire l’image spécifiée dans la définition de la tâche en raison de problèmes d’autorisation.
Pour résoudre ce problème :
1. Vérifiez que l'image existe dans le*repository*. Pour plus d’informations sur l’affichage de vos images, consultez la section [Affichage des détails des images dans Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-info.html) dans le *guide de l’utilisateur d’Amazon Elastic Container Registry*.
1. Vérifiez que vous disposez des autorisations appropriées pour extraire l'image. *role-arn*
Pour plus d’informations sur la mise à jour des rôles, consultez la section [Mettre à jour les autorisations d’un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) dans le *Guide d’utilisation Gestion des identités et des accès AWS *.
La tâche utilise l’un des rôles suivants :
+ Pour les tâches utilisant Fargate, il s’agit du rôle d’exécution des tâches. Pour plus d’informations sur les autorisations supplémentaires pour Amazon ECR, consultez la section [Tâches Fargate extrayant des images Amazon ECR via les autorisations des points de terminaison d’interface](task_execution_IAM_role.md#task-execution-ecr-conditionkeys).
+ Pour les tâches avec EC2, il s’agit du rôle d’instance de conteneur. Pour plus d’informations sur les autorisations supplémentaires pour Amazon ECR, consultez la section [Autorisations Amazon ECR](instance_IAM_role.md#container-instance-role-ecr).
## La tâche ne peut pas extraire *image-name* « » du référentiel Amazon ECR « *repository URI* ». Il existe un problème de connexion entre la tâche et Amazon ECR. Vérifiez la configuration réseau de votre tâche.
Cette erreur indique que la tâche ne peut pas se connecter à Amazon ECR. Vérifiez la connexion au *repository URI* référentiel.
Pour plus d’informations sur la manière de vérifier et de résoudre le problème, consultez la section [Vérification de la connectivité de la tâche Amazon ECS arrêtée](verify-connectivity.md).
## La tâche ne peut pas extraire l’image. Vérification de la configuration de votre réseau
Cette erreur indique que la tâche ne peut pas se connecter à Amazon ECR.
Pour plus d’informations sur la manière de vérifier et de résoudre le problème, consultez la section [Vérification de la connectivité de la tâche Amazon ECS arrêtée](verify-connectivity.md).
## CannotPullContainerError: le manifeste pull image a été réessayé 5 fois : échec de la résolution de la référence
Cette erreur indique que la tâche ne peut pas extraire l’image.
Pour résoudre cela, vous pouvez :
+ Vérifiez que l’image spécifiée dans la définition de tâche correspond à l’image du référentiel.
+ Amazon ECS impose la stabilité de la version de l’image. Si l’image d’origine n’est plus disponible, vous recevez ce message d’erreur. La balise d’image permet de renforcer ce comportement. Modifiez l’image dans la définition de la tâche en remplaçant la balise « :latest » par une version spécifique. Pour de plus amples informations, veuillez consulter [Résolution des images de conteneurs](deployment-type-ecs.md#deployment-container-image-stability).
Pour plus d’informations sur la manière de vérifier et de résoudre le problème, consultez la section [Vérification de la connectivité de la tâche Amazon ECS arrêtée](verify-connectivity.md).
## Erreur API (500) : demande Get https://111122223333.dkr.ecr.us-east-1.amazonaws.com/v2/ : net/http : annulée en attendant la connexion
Cette erreur indique qu’une connexion a expiré, car il n’existe pas d’itinéraire vers Internet.
Pour résoudre ce problème, vous pouvez :
+ Pour des tâches de sous-réseaux publics, spécifiez **ENABLED** (Activé) pour **Auto-assign public IP** (Attribuer automatiquement l'adresse IP publique) lors du lancement de la tâche. Pour de plus amples informations, veuillez consulter [Exécution d’une application en tant que tâche Amazon ECS](standalone-task-create.md).
+ Pour des tâches de sous-réseaux privés, spécifiez **Désactivé** pour **Attribuer automatiquement l'adresse IP publique** lors du lancement de la tâche, puis configurez une passerelle NAT dans votre VPC pour acheminer les demandes vers Internet. Pour plus d'informations, consultez [Passerelles NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) dans le *Guide de l'utilisateur Amazon VPC*.
## Erreur d'API
Cette erreur indique l’existence d’un problème de connexion avec le point de terminaison Amazon ECR.
Pour plus d'informations sur la manière de résoudre ce problème, consultez l'[article Comment puis-je résoudre l'erreur Amazon ECR « CannotPullContainerError : erreur d'API » dans Amazon ECS](https://aws.amazon.com/premiumsupport/knowledge-center/ecs-pull-container-api-error-ecr/) sur le Support site Web.
## write/var/lib/docker/tmp/*GetImageBlob111111111*: il ne reste plus d'espace sur l'appareil
Cette erreur indique que l’espace disque est insuffisant.
Pour résoudre ce problème, vous devez libérer de l'espace disque.
Si vous utilisez l’AMI optimisée pour Amazon ECS, vous pouvez utiliser la commande suivante pour récupérer les 20 fichiers les plus volumineux de votre système de fichiers :
```
du -Sh / | sort -rh | head -20
```
Exemple de sortie :
```
5.7G /var/lib/docker/containers/50501b5f4cbf90b406e0ca60bf4e6d4ec8f773a6c1d2b451ed8e0195418ad0d2
1.2G /var/log/ecs
594M /var/lib/docker/devicemapper/mnt/c8e3010e36ce4c089bf286a623699f5233097ca126ebd5a700af023a5127633d/rootfs/data/logs
...
```
Dans certains cas, le volume racine peut être saturé par un conteneur en cours d’exécution. Si le conteneur utilise le pilote de journal `json-file` par défaut sans limite `max-size`, le fichier journal est peut-être responsable de la plupart de l'utilisation de cet espace. Vous pouvez utiliser la commande `docker ps` pour vérifier quel conteneur utilise l'espace en mappant le nom du répertoire dans la sortie ci-dessus à l'ID de conteneur. Par exemple :
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
50501b5f4cbf amazon/amazon-ecs-agent:latest "/agent" 4 days ago Up 4 days ecs-agent
```
Par défaut, lorsque vous utilisez le pilote de journal `json-file`, Docker capture la sortie standard (et l'erreur standard) de tous vos conteneurs et les écrit dans les fichiers au format JSON. Vous pouvez définir l'option `max-size` comme une option de pilote de journal, ce qui empêche le fichier journal d'occuper trop d'espace. Pour plus d’informations, consultez la section [Pilote de journalisation](https://docs.docker.com/engine/logging/drivers/json-file/) dans la documentation Docker.
Voici un extrait de définition de conteneur illustrant la manière d'utiliser cette option :
```
{
"log-driver": "json-file",
"log-opts": {
"max-size": "256m"
}
}
```
Si vos journaux de conteneur occupent trop d’espace disque, vous pouvez également utiliser le pilote de journal `awslogs`. Le pilote de `awslogs` journal envoie les journaux à CloudWatch, ce qui libère de l'espace disque qui serait autrement utilisé pour vos journaux de conteneur sur l'instance de conteneur. Pour de plus amples informations, veuillez consulter [Envoyez les journaux Amazon ECS à CloudWatch](using_awslogs.md).
Vous devrez peut-être mettre à jour la taille du disque auquel Docker peut accéder.
Pour plus d'informations, voir [CannotPullContainerError: il ne reste plus d'espace sur l'appareil](https://repost.aws/questions/QUx6Ix1R1SSNisYSs1Sw8EBA/cannotpullcontainererror-no-space-left-on-device).
## ERREUR : toomanyrequests : trop de requêtes ou vous avez atteint votre limite de taux d’extraction.
Cette erreur indique l’existence d’une limite de débit Docker Hub.
Si vous recevez un message pour l'une des erreurs suivantes, vous êtes probablement en train d'atteindre les limites de débit Docker Hub :
Pour en savoir plus sur les limites de débit Docker Hub, consultez [Understanding Docker Hub rate limiting](https://www.docker.com/increase-rate-limits).
Si vous avez augmenté la limite de débit Docker Hub et que vous devez authentifier vos extractions Docker pour vos instances de conteneur, consultez la section [Authentification de registre privé pour les instances de conteneur](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth-container-instances.html).
## Réponse d'erreur du démon : Get *url* : net/http : demande annulée en attendant la connexion
Cette erreur indique qu’une connexion a expiré, car il n’existe pas d’itinéraire vers Internet.
Pour résoudre ce problème, vous pouvez :
+ Pour des tâches de sous-réseaux publics, spécifiez **ENABLED** (Activé) pour **Auto-assign public IP** (Attribuer automatiquement l'adresse IP publique) lors du lancement de la tâche. Pour de plus amples informations, veuillez consulter [Exécution d’une application en tant que tâche Amazon ECS](standalone-task-create.md).
+ Pour des tâches de sous-réseaux privés, spécifiez **Désactivé** pour **Attribuer automatiquement l'adresse IP publique** lors du lancement de la tâche, puis configurez une passerelle NAT dans votre VPC pour acheminer les demandes vers Internet. Pour plus d'informations, consultez [Passerelles NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) dans le *Guide de l'utilisateur Amazon VPC*.
## ref pull a été réessayé 1 fois : échec de la copie : échec de l'ouverture httpReaderSeeker : code d'état inattendu
Cette erreur indique un échec lors de la copie d’une image.
Pour résoudre ce problème, consultez l’un des articles suivants :
+ Pour les tâches Fargate, consultez [Comment puis-je corriger l'erreur « cannotpullcontainererror » pour mes tâches Amazon ECS sur Fargate ?](https://aws.amazon.com/premiumsupport/knowledge-center/ecs-fargate-pull-container-error/).
+ Pour les autres tâches, consultez [Comment puis-je corriger l'erreur « cannotpullcontainererror » pour mes tâches Amazon ECS ?](https://aws.amazon.com/premiumsupport/knowledge-center/ecs-pull-container-error/).
## accès en extraction refusé
Cette erreur indique l’impossibilité d’accéder à l’image.
Pour résoudre ce problème, vous devrez peut-être authentifier votre client Docker auprès d’Amazon ECR. Pour plus d’informations, consultez la section [Authentification de registre privé](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry_auth.html) dans le *Guide de l’utilisateur Amazon ECR*.
## échec de la commande d’extraction : panique : erreur d’exécution : adresse mémoire non valide ou déréférencement de pointeur nul
Cette erreur indique qu’il n’est pas possible d’accéder à l’image en raison d’une adresse mémoire non valide ou d’un déréférencement de pointeur nul.
Pour résoudre ce problème :
+ Vérifiez que vous disposez des règles du groupe de sécurité pour accéder à Amazon S3.
+ Lorsque vous utilisez des points de terminaison de passerelle, vous devez ajouter une route dans la table de routage pour accéder au point de terminaison.
## erreur lors de l' conf/error extraction de l'image lors de la configuration
Cette erreur indique qu’une limite de débit a été atteinte ou qu’il y a une erreur réseau :
Pour résoudre ce problème, consultez [Comment puis-je résoudre l'erreur « CannotPullContainerError » dans ma tâche de type de lancement Amazon ECS EC2](https://repost.aws/knowledge-center/ecs-pull-container-error).
## Contexte annulé
Cette erreur indique que le contexte a été annulé.
La cause courante de cette erreur est que le VPC utilisé par votre tâche n'a pas de route pour extraire l'image d'Amazon ECR.
# Vérification de la connectivité de la tâche Amazon ECS arrêtée
Il arrive qu’une tâche s’arrête en raison d’un problème de connectivité réseau. Il peut s’agir d’un problème intermittent, mais il est probablement dû au fait que la tâche ne peut pas se connecter à un point de terminaison.
## Test de la connectivité de la tâche
Vous pouvez utiliser le dossier d’exploitation `AWSSupport-TroubleshootECSTaskFailedToStart` pour tester la connectivité de la tâche. Lorsque vous utilisez le dossier d’exploitation, vous avez besoin des informations suivantes sur les ressources :
+ ID de la tâche
Utilisez l’ID de la dernière tâche ayant échoué.
+ Le cluster dans lequel se trouvait la tâche
Pour plus d’informations sur l’utilisation du dossier d’exploitation, consultez la section [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-troubleshootecstaskfailedtostart.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-troubleshootecstaskfailedtostart.html) de la *Référence du dossier d’exploitation d’AWS Systems Manager Automation*.
Le dossier d’exploitation analyse la tâche. Vous pouvez consulter les résultats dans la section **Sortie** pour les problèmes suivants susceptibles d’empêcher le démarrage d’une tâche :
+ Connectivité réseau avec le registre de conteneurs configuré
+ Connectivité au point de terminaison de VPC
+ Configuration des règles de groupe de sécurité
## Résolution des problèmes liés aux points de terminaison du VPC
Lorsque le résultat du dossier d’exploitation `AWSSupport-TroubleshootECSTaskFailedToStart` indique le problème du point de terminaison de VPC, vérifiez la configuration suivante :
+ Le VPC dans lequel vous créez le point de terminaison et le point de terminaison du VPC doivent utiliser le DNS privé.
+ Assurez-vous que vous disposez d'un AWS PrivateLink point de terminaison pour le service auquel la tâche ne peut pas se connecter dans le même VPC que la tâche. Pour plus d’informations, consultez l’un des points suivants :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/verify-connectivity.html)
+ Configurez une règle de sortie pour le sous-réseau de tâches qui autorise le protocole HTTPS sur le trafic DNS (TCP) du port 443. Pour plus d’informations, consultez la section [Configurer les règles de groupe de sécurité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/changing-security-group.html#add-remove-security-group-rules) dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.
+ Si vous utilisez un serveur de noms de domaine personnalisé, confirmez les paramètres de la requête DNS. La requête doit avoir un accès sortant sur le port 53 et utiliser les protocoles UDP et TCP. Il doit également disposer d’un accès HTTPS sur le port 443. Pour plus d’informations, consultez la section [Configurer les règles de groupe de sécurité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/changing-security-group.html#add-remove-security-group-rules) dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.
+ Si le sous-réseau possède une ACL réseau, les règles ACL suivantes sont requises :
+ Une règle sortante qui autorise le trafic sur les ports 1 024 à 65 535.
+ Une règle entrante qui autorise le trafic TCP sur le port 443.
Pour plus d'informations sur la configuration des règles, consultez la section [Contrôler le trafic vers les sous-réseaux à l'aide du réseau ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) dans le *guide de l'utilisateur d'Amazon Virtual Private Cloud*.
## Résolution des problèmes réseau
Lorsque le résultat du dossier d’exploitation `AWSSupport-TroubleshootECSTaskFailedToStart` indique le problème réseau, vérifiez la configuration suivante :
### Tâches utilisant le mode réseau awsvpc dans un sous-réseau public
Effectuez la configuration suivante en fonction du dossier d’exploitation :
+ Pour des tâches de sous-réseaux publics, spécifiez **ENABLED** (Activé) pour **Auto-assign public IP** (Attribuer automatiquement l'adresse IP publique) lors du lancement de la tâche. Pour de plus amples informations, veuillez consulter [Exécution d’une application en tant que tâche Amazon ECS](standalone-task-create.md).
+ Vous avez besoin d’une passerelle pour gérer le trafic Internet. La table de routage du sous-réseau de tâches doit contenir une route pour le trafic vers la passerelle.
Pour en savoir plus, consultez la section [Ajout et suppression d’itinéraires d’une table de routage](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes) du *Guide de l’utilisateur Amazon Virtual Private Cloud*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/verify-connectivity.html)
+ Si le sous-réseau de la tâche possède une ACL réseau, les règles ACL suivantes sont requises :
+ Une règle sortante qui autorise le trafic sur les ports 1 024 à 65 535.
+ Une règle entrante qui autorise le trafic TCP sur le port 443.
Pour plus d'informations sur la configuration des règles, consultez la section [Contrôler le trafic vers les sous-réseaux à l'aide du réseau ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) dans le *guide de l'utilisateur d'Amazon Virtual Private Cloud*.
### Tâches utilisant le mode réseau awsvpc dans un sous-réseau privé
Effectuez la configuration suivante en fonction du dossier d’exploitation :
+ Choisissez **DÉSACTIVÉ** pour **Attribuer automatiquement l’adresse IP publique** lors du lancement de la tâche.
+ Configurez une passerelle NAT dans votre VPC pour acheminer les requêtes vers Internet. Pour plus d’informations, consultez la section [Passerelles NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.
+ La table de routage du sous-réseau de tâches doit contenir une route pour le trafic vers la passerelle NAT.
Pour en savoir plus, consultez la section [Ajout et suppression d’itinéraires d’une table de routage](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes) du *Guide de l’utilisateur Amazon Virtual Private Cloud*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/verify-connectivity.html)
+ Si le sous-réseau de la tâche possède une ACL réseau, les règles ACL suivantes sont requises :
+ Une règle sortante qui autorise le trafic sur les ports 1 024 à 65 535.
+ Une règle entrante qui autorise le trafic TCP sur le port 443.
Pour plus d'informations sur la configuration des règles, consultez la section [Contrôler le trafic vers les sous-réseaux à l'aide du réseau ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) dans le *guide de l'utilisateur d'Amazon Virtual Private Cloud*.
### Tâches n’utilisant pas le mode réseau awsvpc dans un sous-réseau public
Effectuez la configuration suivante en fonction du dossier d’exploitation :
+ Choisissez **Activer** pour **Attribuer automatiquement l’adresse IP** sous **Mise en réseau pour les instances Amazon EC2** lorsque vous créez le cluster.
Cette option attribue une adresse IP publique à l’interface réseau principale de l’instance.
+ Vous avez besoin d’une passerelle pour gérer le trafic Internet. La table de routage du sous-réseau de l’instance doit contenir une route pour le trafic vers la passerelle.
Pour en savoir plus, consultez la section [Ajout et suppression d’itinéraires d’une table de routage](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes) du *Guide de l’utilisateur Amazon Virtual Private Cloud*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/verify-connectivity.html)
+ Si le sous-réseau de l’instance possède une ACL réseau, les règles ACL suivantes sont requises :
+ Une règle sortante qui autorise le trafic sur les ports 1 024 à 65 535.
+ Une règle entrante qui autorise le trafic TCP sur le port 443.
Pour plus d'informations sur la configuration des règles, consultez la section [Contrôler le trafic vers les sous-réseaux à l'aide du réseau ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) dans le *guide de l'utilisateur d'Amazon Virtual Private Cloud*.
### Tâches n’utilisant pas le mode réseau awsvpc dans un sous-réseau privé
Effectuez la configuration suivante en fonction du dossier d’exploitation :
+ Choisissez **Désactiver** pour **Attribuer automatiquement l’adresse IP** sous **Mise en réseau pour les instances Amazon EC2** lorsque vous créez le cluster.
+ Configurez une passerelle NAT dans votre VPC pour acheminer les requêtes vers Internet. Pour plus d'informations, veuillez consulter [NAT Gateways (Passerelles NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) dans le *Guide de l'utilisateur Amazon VPC*.
+ La table de routage du sous-réseau de l’instance doit contenir une route pour le trafic vers la passerelle NAT.
Pour en savoir plus, consultez la section [Ajout et suppression d’itinéraires d’une table de routage](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes) du *Guide de l’utilisateur Amazon Virtual Private Cloud*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/verify-connectivity.html)
+ Si le sous-réseau de la tâche possède une ACL réseau, les règles ACL suivantes sont requises :
+ Une règle sortante qui autorise le trafic sur les ports 1 024 à 65 535.
+ Une règle entrante qui autorise le trafic TCP sur le port 443.
Pour plus d'informations sur la configuration des règles, consultez la section [Contrôler le trafic vers les sous-réseaux à l'aide du réseau ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) dans le *guide de l'utilisateur d'Amazon Virtual Private Cloud*.
# Affichage des requêtes de rôle IAM pour des tâches Amazon ECS
Lorsque vous utilisez un fournisseur pour vos informations d’identification de tâche dans un rôle IAM, les requêtes du fournisseur sont enregistrées dans un journal d’audit. Le journal d'audit hérite des mêmes paramètres de rotation du journal que le journal de l'agent de conteneur. Les variables `ECS_LOG_ROLLOVER_TYPE`, `ECS_LOG_MAX_FILE_SIZE_MB` et `ECS_LOG_MAX_ROLL_COUNT` de configuration de l'agent de conteneur peuvent être définies de façon à affecter le comportement du journal d'audit. Pour de plus amples informations, veuillez consulter [Paramètres de configuration du journal de l’agent de conteneur Amazon ECS](ecs-agent-versions.md#agent-logs).
Pour l'agent de conteneur version 1.36.0 et ultérieure, le journal d'audit se trouve à l'adresse `/var/log/ecs/audit.log`. Lorsque le journal est tourné, un horodatage au format `YYYY-MM-DD-HH` est ajouté à la fin du nom du fichier journal.
Pour l'agent de conteneur version 1.35.0 et antérieure, le journal d'audit se trouve à l'adresse `/var/log/ecs/audit.log.YYYY-MM-DD-HH`.
Le format d'entrée de journal est le suivant :
+ Horodatage
+ Code de réponse HTTP
+ Numéro de port et adresse IP d'origine de la demande
+ URI relative du fournisseur d'informations d'identification
+ L'agent utilisateur qui a effectué la demande
+ L'ARN de la tâche à laquelle appartient le conteneur demandeur
+ Le nom d'API `GetCredentials` et son numéro de version
+ Le nom du cluster Amazon ECS dans lequel l'instance de conteneur est enregistrée
+ L'ARN d'instance de conteneur
Vous pouvez utiliser la commande suivante pour visualiser les fichiers journaux.
```
cat /var/log/ecs/audit.log.2016-07-13-16
```
Sortie :
```
2016-07-13T16:11:53Z 200 172.17.0.5:52444 "/v1/credentials" "python-requests/2.7.0 CPython/2.7.6 Linux/4.4.14-24.50.amzn1.x86_64" TASK_ARN GetCredentials 1 CLUSTER_NAME CONTAINER_INSTANCE_ARN
```
# Affichage des messages d’événement d’un service Amazon ECS
Lorsque vous voulez résoudre un problème lié à un service, le premier endroit à consulter pour obtenir des informations est le journal des événements du service. Vous pouvez consulter les événements de service à l'aide de l'`DescribeServices`API AWS CLI, du, ou en utilisant le AWS Management Console.
Lorsque vous affichez des messages d'événements de service à l'aide de l'API Amazon ECS, seuls les événements du planificateur de service sont renvoyés. Ceux-ci comprennent le placement des tâches les plus récents et les événements d'état de l'instance. Toutefois, la console Amazon ECS affiche les événements de service à partir des sources suivantes.
+ Placement des tâches et événements d'état de l'instance à partir du planificateur de service Amazon ECS service. Ces événements ont pour préfixe « **service *(service-name)*** ». Pour que cette vue des événements soit utile, seuls les `100` événements les plus récents sont affichés. Les messages d’événement en double sont omis jusqu’à ce que la cause soit résolue ou que six heures se soient écoulées. Si la cause n’est pas résolue dans les six heures, vous recevez un autre message d’événement de service.
+ Événements de service Auto Scaling. Ces événements ont pour préfixe **Message** et ne se produisent que lorsqu’un service est configuré avec une stratégie de mise à l’échelle automatique des applications.
**Astuce**
Vous pouvez utiliser les assistants [Serveur Amazon ECS MCP](ecs-mcp-introduction.md) dotés d'intelligence artificielle pour analyser les événements de service en langage naturel.
Procédez comme suit pour afficher vos messages d'événement de service actuels.
------
#### [ Console ]
1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2).
1. Dans le panneau de navigation, choisissez **Clusters**.
1. Sur la page **Clusters**, choisissez le cluster.
1. Choisissez le service à inspecter.
1. Dans l'onglet **Événements**, consultez les messages.
------
#### [ AWS CLI ]
Utilisez la commande [describe-services](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-services.html) pour afficher les messages d'événement de service pour un service spécifié.
L' AWS CLI exemple suivant décrit le *service-name* service du *default* cluster, qui fournira les derniers messages d'événements de service.
```
aws ecs describe-services \
--cluster default \
--services service-name \
--region us-west-2
```
------
# Messages d’événement de service Amazon ECS
Voici quelques exemples de messages d'événement de service que vous pouvez rencontrer dans la console Amazon ECS.
## service (*service-name*) a atteint un état stable.
Le planificateur de service envoie un événement de service `service (service-name) has reached a steady state.` lorsque le service est sain et au nombre de tâches souhaité, atteignant ainsi un état stable.
Le planificateur de service rapporte l'état de façon régulière, vous pouvez donc recevoir ce message plusieurs fois.
## service (*service-name*) n'a pas pu placer de tâche car aucune instance de conteneur ne répondait à toutes ses exigences.
Le planificateur de service envoie ce message d’événement lorsqu’il n’a pas trouvé les ressources disponibles pour ajouter une autre tâche. Les causes possibles sont les suivantes :
Utilisez des fournisseurs de capacité pour mettre automatiquement à l’échelle vos instances EC2. Pour de plus amples informations, veuillez consulter [Fournisseurs de capacité Amazon ECS pour les charges de travail EC2](asg-capacity-providers.md).
Si vous aviez l’intention de faire appel à un fournisseur de capacité, assurez-vous que vous adoptez une stratégie de fournisseur de capacité ou que vous avez une stratégie de fournisseur de capacité par défaut associée à votre cluster, et que vous ne transmettez pas le type de lancement et la stratégie du fournisseur de capacité en entrée
Aucune instance de conteneur n'a été trouvée dans votre cluster
Si aucune instance de conteneur n’est enregistrée dans le cluster dans lequel vous tentez d’exécuter une tâche, vous recevez cette erreur. Vous devez ajouter des instances de conteneur à votre cluster. Pour de plus amples informations, veuillez consulter [Lancement d'une instance de conteneur Amazon ECS Linux](launch_container_instance.md).
Nombre de ports insuffisant
Si votre tâche utilise le mappage de port hôte fixe (si, par exemple, elle emploie le port 80 sur l'hôte pour un serveur web), vous devez avoir au moins une instance de conteneur par tâche, car un seul conteneur peut utiliser un même port hôte à la fois. Vous devez ajouter des instances de conteneur à votre cluster ou réduire votre nombre de tâches souhaitées.
Nombre de ports enregistrés trop important
L’instance de conteneur correspondante la plus proche pour le placement des tâches ne peut pas dépasser la limite maximale autorisée de ports réservés, soit 100 ports hôtes par instance de conteneur. L'utilisation du mappage de port hôte dynamique peut résoudre le problème.
Port déjà utilisé
La définition de cette tâche utilise le même port dans son mappage de ports qu’une tâche en cours d’exécution sur l’instance de conteneur qui a été choisie. Le message d'événement de service devrait contenir l'ID d'instance de conteneur choisie dans le message ci-dessous.
```
The closest matching container-instance is already using a port required by your task.
```
Mémoire insuffisante
Si votre définition de tâche spécifie 1 000 Mio de mémoire et que les instances de conteneur de votre cluster ont chacune 1 024 Mio de mémoire, vous ne pouvez exécuter qu'une seule copie de cette tâche par instance de conteneur. Vous pouvez essayer avec moins de mémoire dans votre définition de tâche afin de pouvoir lancer plusieurs tâches par instance de conteneur, ou lancer plusieurs instances de conteneur dans votre cluster.
Si vous essayez d'optimiser l'utilisation de vos ressources en fournissant à vos tâches autant de mémoire que possible pour un type d'instance particulier, consultez [Réservation de mémoire pour une instance de conteneur Amazon ECS Linux](memory-management.md).
UC insuffisante
Une instance de conteneur comporte 1 024 unités d'UC pour chaque cœur de processeur. Si votre définition de tâche spécifie 1 000 unités d'UC, et que les instances de conteneur de votre cluster ont chacune 1 024 unités d'UC, vous ne pouvez exécuter qu'une seule copie de cette tâche par instance de conteneur. Vous pouvez essayer avec moins d'unités d'UC dans votre définition de tâche pour pouvoir lancer plusieurs tâches par instance de conteneur ou plusieurs instances de conteneur dans votre cluster.
Pas suffisamment de points d'attache ENI disponibles
Les tâches qui utilisent le mode réseau `awsvpc` reçoivent chacune leur propre interface réseau Elastic (ENI), qui est attachée à l'instance de conteneur qui l'héberge. Le nombre d'instances Amazon EC2 ENIs pouvant y être associées est limité et aucune instance de conteneur du cluster ne dispose d'une capacité ENI disponible.
La limite ENI pour les instances de conteneur individuelles varie selon les conditions suivantes :
+ Si vous n'**avez pas** opté pour le paramètre de compte `awsvpcTrunking`, la limite ENI pour chaque instance de conteneur dépend du type de l'instance. Pour de plus amples informations, consultez [Adresses IP par interface réseau et par type d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) dans le *Guide de l'utilisateur Amazon EC2*.
+ Si vous **avez** opté pour le paramètre de compte `awsvpcTrunking`, mais que vous **n’avez pas** lancé de nouvelles instances de conteneur utilisant un type d’instance pris en charge après ce choix, la limite ENI pour chaque instance de conteneur reste la valeur par défaut. Pour de plus amples informations, consultez [Adresses IP par interface réseau et par type d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) dans le *Guide de l'utilisateur Amazon EC2*.
+ Si vous **avez activé** les paramètres du `awsvpcTrunking` compte et que vous **avez** lancé de nouvelles instances de conteneur à l'aide d'un type d'instance pris en charge après votre inscription, d'autres ENIs sont disponibles. Pour de plus amples informations, veuillez consulter [Instances prises en charge pour augmenter le nombre d’interfaces réseau de conteneurs Amazon ECS](eni-trunking-supported-instance-types.md).
Pour en savoir plus sur l'acceptation du paramètre de compte `awsvpcTrunking`, consultez [Augmentation des interfaces réseau d’une instance de conteneur Amazon ECS Linux](container-instance-eni.md).
Vous pouvez ajouter des instances de conteneur à votre cluster afin de mettre à disposition davantage de cartes réseau.
Attribut requis manquant dans l'instance de conteneur
Certains paramètres de définition de tâche nécessitent l'installation d'une version spécifique de l'API Docker à distance sur l'instance de conteneur. D'autres, telles que les options du pilote de journalisation, exigent que les instances de conteneur enregistrent ces pilotes de journal avec la variable de configuration d'agent `ECS_AVAILABLE_LOGGING_DRIVERS`. Si votre définition de tâche contient un paramètre qui nécessite un attribut d’instance de conteneur spécifique, et que vous ne disposez pas d’instances de conteneur répondant à cette exigence, la tâche en question ne peut pas être placée.
Cette erreur est souvent due au fait que votre service utilise des tâches utilisant le mode réseau `awsvpc` et EC2. Aucune instance de conteneur n’est enregistrée sur le cluster dans le même sous-réseau que celui spécifié dans `awsvpcConfiguration` lors de la création du service.
Vous pouvez utiliser le AWSSupport-TroubleshootECSContainerInstance runbook pour résoudre les problèmes. Le dossier d’exploitation vérifie si les données utilisateur de l’instance contiennent les informations de cluster correctes, si le profil d’instance contient les autorisations requises et vérifie les problèmes de configuration réseau. Pour plus d’informations, consultez [AWSSupport-TroubleshootECSContainerInstance](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-troubleshoot-ecs-container-instance.html) dans le *AWS Systems Manager Guide de l’utilisateur de la référence du dossier d’exploitation d’automatisation*.
Pour plus d'informations sur les attributs nécessaires pour les paramètres de définition de tâche spécifiques et les variables de configuration d'agent, consultez [Paramètres de définition de tâche Amazon ECS pour Fargate](task_definition_parameters.md) et [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md).
## service (*service-name*) n'a pas pu placer de tâche car aucune instance de conteneur ne répondait à toutes ses exigences. L'instance de conteneur correspondante la plus proche ne *container-instance-id* dispose pas d'un nombre suffisant d'unités CPU disponibles.
L’instance de conteneur qui correspond le mieux au placement de la tâche ne contient pas suffisamment d’unités d’UC pour répondre aux exigences de la définition de la tâche. Vérifiez les exigences en matière d'UC dans les paramètres de définition de conteneur et de taille de tâche de la définition de tâche.
## service (*service-name*) n'a pas pu placer de tâche car aucune instance de conteneur ne répondait à toutes ses exigences. L'instance de conteneur correspondante la plus proche *container-instance-id* a rencontré l'erreur « AGENT ».
L'agent de conteneur Amazon ECS de l'instance de conteneur correspondante la plus proche pour le placement des tâches est déconnecté. Si vous pouvez vous connecter à l'instance de conteneur avec SSH, vous pouvez examiner les journaux d'agent. Pour plus d'informations, consultez [Paramètres de configuration du journal de l’agent de conteneur Amazon ECS](ecs-agent-versions.md#agent-logs). Vous devez également vérifier que l'agent est en cours d'exécution sur l'instance. Si vous utilisez l'AMI optimisée pour Amazon ECS, vous pouvez essayer d'arrêter et de redémarrer l'agent avec la commande suivante.
+ Pour l’AMI Amazon Linux 2 optimisée pour Amazon ECS et l’AMI Amazon Linux 2023 optimisée pour Amazon ECS
```
sudo systemctl restart ecs
```
+ Pour l'AMI Amazon Linux optimisée pour Amazon ECS
```
sudo stop ecs && sudo start ecs
```
## le service (*service-name*) (tâche*task-id*) (instance*instance-id*) est défectueux dans (elb*elb-name*) en raison de (raison pour laquelle l'instance a échoué à au moins un UnhealthyThreshold certain nombre de contrôles de santé consécutifs.)
Ce service est enregistré avec un équilibreur de charge et les surveillances de l'état de cet équilibreur échouent. Le message inclut l’ID de tâche pour aider à identifier la tâche spécifique pour laquelle les surveillances de l’état échouent. Pour de plus amples informations, veuillez consulter [Résolution des problèmes liés aux équilibreurs de charge des services dans Amazon ECS](troubleshoot-service-load-balancers.md).
## service (*service-name*) ne parvient pas à démarrer régulièrement les tâches avec succès.
Ce service contient des tâches qui n'ont pas pu démarrer après plusieurs tentatives consécutives. À ce stade, le planificateur de service commence à augmenter progressivement le délai entre les tentatives. Vous devez déterminer pourquoi le lancement de vos tâches échoue. Pour de plus amples informations, veuillez consulter [Logique de limitation d’un service Amazon ECS](service-throttle-logic.md).
Une fois le service mis à jour (mise à jour de la définition de tâche, par exemple), le planificateur de service se comporte de nouveau normalement.
## les opérations de service (*service-name*) sont limitées. Réessayez ultérieurement.
Ce service ne peut pas lancer plus de tâches à cause des limitations de l'API. Lorsque le planificateur de service peut lancer plus de tâches, il reprend.
Pour demander une augmentation de quota de limite de débit d'API, ouvrez la page du [Centre AWS Support](https://console.aws.amazon.com/support/home#/), connectez-vous si nécessaire et choisissez **Create case (Créer une demande)**. Sélectionnez **Service Limit increase** (Augmentation des limites de service). Remplissez et envoyez le formulaire.
## 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.
Ce service ne peut pas arrêter ou démarrer des tâches pendant un déploiement de service en raison de la configuration du déploiement. La configuration de déploiement se compose des valeurs `minimumHealthyPercent` et `maximumPercent` qui sont définies lorsque le service est créé. Ces valeurs peuvent également être mises à jour sur un service existant.
`minimumHealthyPercent` représente la limite inférieure du nombre de tâches qui doivent être exécutées pour un service pendant un déploiement ou lorsqu’une instance de conteneur est drainée. Il s’agit d’un pourcentage du nombre de tâches souhaité pour le service. Cette valeur est arrondie à la valeur supérieure. Par exemple, si le pourcentage minimum sain 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 inférieure du nombre de tâches qui doivent être exécutées pour un service pendant un déploiement ou lorsqu’une instance de conteneur est drainée. Il s’agit d’un pourcentage du nombre de tâches souhaité pour un service. Cette valeur est arrondie à la valeur inférieure. Par exemple, si le pourcentage maximal est `200` et que le nombre de tâches souhaitées est 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.
Lorsque vous définissez un pourcentage d'état minimum ou un pourcentage maximal, 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é.
## service (*service-name*) n'a pas pu placer de tâche. Motif : Vous avez atteint la limite du nombre de tâches que vous pouvez exécuter simultanément
Vous pouvez demander une augmentation de quota pour la ressource qui a provoqué l'erreur. Pour de plus amples informations, veuillez consulter [Quotas de service Amazon ECS service](service-quotas.md). Pour demander une augmentation de quota, consultez [Demande d'augmentation de quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) dans le *Guide de l'utilisateur Service Quotas*.
## service (*service-name*) n'a pas pu placer de tâche. Motif : Erreur interne.
Voici la raison possible de cette erreur :
Le service ne peut pas démarrer une tâche car un sous-réseau se trouve dans une zone de disponibilité non prise en charge.
Pour plus d'informations sur les Régions Fargate et les zones de disponibilités prises en charge, consultez [Régions prises en charge pour Amazon ECS sur AWS Fargate](AWS_Fargate-Regions.md).
Pour plus d'informations sur la façon d'afficher la zone de disponibilité de sous-réseau, consultez [Afficher votre sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#view-subnet) dans le *Guide de l'utilisateur Amazon VPC*.
## service (*service-name*) n'a pas pu placer de tâche. Motif : la configuration CPU demandée est supérieure à votre limite.
Vous pouvez demander une augmentation de quota pour la ressource qui a provoqué l'erreur. Pour de plus amples informations, veuillez consulter [Quotas de service Amazon ECS service](service-quotas.md). Pour demander une augmentation de quota, consultez [Demande d'augmentation de quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) dans le *Guide de l'utilisateur Service Quotas*.
## service (*service-name*) n'a pas pu placer de tâche. Motif : la configuration MEMORY demandée est supérieure à votre limite.
Vous pouvez demander une augmentation de quota pour la ressource qui a provoqué l'erreur. Pour de plus amples informations, veuillez consulter [Quotas de service Amazon ECS service](service-quotas.md). Pour demander une augmentation de quota, consultez [Demande d'augmentation de quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) dans le *Guide de l'utilisateur Service Quotas*.
## service (*service-name*) n'a pas pu placer de tâche. Raison : vous avez atteint la limite du nombre de v CPUs que vous pouvez exécuter simultanément
AWS Fargate est en train de passer de quotas basés sur le nombre de tâches à des quotas basés sur le vCPU.
Vous pouvez demander une augmentation de quota pour le quota basé sur le VCPU Fargate. Pour de plus amples informations, veuillez consulter [Quotas de service Amazon ECS service](service-quotas.md). Pour demander une augmentation de quota Fargate, consultez [Demande d'augmentation de quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) dans le *Guide de l'utilisateur Service Quotas*.
## service (*service-name*) n'a pas pu atteindre l'état d'équilibre car task set (*taskSet-ID*) n'a pas pu évoluer. Raison : le nombre de tâches protégées est supérieur au nombre souhaité de tâches.
Le service a plus de tâches protégées que le nombre souhaité de tâches. Vous pouvez effectuer l'une des actions suivantes :
+ Attendez que la protection des tâches en cours expire pour pouvoir y mettre fin.
+ Déterminez les tâches qui peuvent être arrêtées et utilisez l’API `UpdateTaskProtection` avec l’option `protectionEnabled` définie sur `false` pour désactiver la protection de ces tâches.
+ Augmentez le nombre de tâches souhaité pour le service à un nombre supérieur au nombre de tâches protégées.
## service (*service-name*) n'a pas pu atteindre l'état d'équilibre. Motif : aucune instance de conteneur n'a été trouvée dans votre fournisseur de capacité.
Le planificateur de service envoie ce message d’événement lorsqu’il n’a pas trouvé les ressources disponibles pour ajouter une autre tâche. Les causes possibles sont les suivantes :
Aucun fournisseur de capacité n’est associé au cluster
Utilisez `describe-services` pour vérifier qu’un fournisseur de capacité est associé au cluster. Vous pouvez mettre à jour la stratégie du fournisseur de capacité pour le service.
Vérifiez que le fournisseur de capacité dispose de capacité. Dans le cas d’EC2, assurez-vous que les instances de conteneur répondent aux exigences de définition des tâches.
Aucune instance de conteneur n'a été trouvée dans votre cluster
Si aucune instance de conteneur n’est enregistrée dans le cluster dans lequel vous tentez d’exécuter une tâche, vous recevez cette erreur. Vous devez ajouter des instances de conteneur à votre cluster. Pour de plus amples informations, veuillez consulter [Lancement d'une instance de conteneur Amazon ECS Linux](launch_container_instance.md).
Nombre de ports insuffisant
Si votre tâche utilise le mappage de port hôte fixe (si, par exemple, elle emploie le port 80 sur l’hôte pour un serveur Web), vous devez avoir au moins une instance de conteneur par tâche. Un seul conteneur peut utiliser un même port hôte à la fois. Vous devez ajouter des instances de conteneur à votre cluster ou réduire votre nombre de tâches souhaitées.
Nombre de ports enregistrés trop important
L’instance de conteneur correspondante la plus proche pour le placement des tâches ne peut pas dépasser la limite maximale autorisée de ports réservés, soit 100 ports hôtes par instance de conteneur. L'utilisation du mappage de port hôte dynamique peut résoudre le problème.
Port déjà utilisé
La définition de cette tâche utilise le même port dans son mappage de ports qu’une tâche en cours d’exécution sur l’instance de conteneur qui a été choisie. Le message d'événement de service devrait contenir l'ID d'instance de conteneur choisie dans le message ci-dessous.
```
The closest matching container-instance is already using a port required by your task.
```
Mémoire insuffisante
Si votre définition de tâche spécifie 1 000 Mio de mémoire et que les instances de conteneur de votre cluster ont chacune 1 024 Mio de mémoire, vous ne pouvez exécuter qu'une seule copie de cette tâche par instance de conteneur. Vous pouvez essayer avec moins de mémoire dans votre définition de tâche afin de pouvoir lancer plusieurs tâches par instance de conteneur, ou lancer plusieurs instances de conteneur dans votre cluster.
Si vous essayez d'optimiser l'utilisation de vos ressources en fournissant à vos tâches autant de mémoire que possible pour un type d'instance particulier, consultez [Réservation de mémoire pour une instance de conteneur Amazon ECS Linux](memory-management.md).
Pas suffisamment de points d'attache ENI disponibles
Les tâches qui utilisent le mode réseau `awsvpc` reçoivent chacune leur propre interface réseau Elastic (ENI), qui est attachée à l'instance de conteneur qui l'héberge. Le nombre d'instances Amazon EC2 ENIs pouvant y être associées est limité, et aucune instance de conteneur du cluster ne dispose d'une capacité ENI disponible.
La limite ENI pour les instances de conteneur individuelles varie selon les conditions suivantes :
+ Si vous n'**avez pas** opté pour le paramètre de compte `awsvpcTrunking`, la limite ENI pour chaque instance de conteneur dépend du type de l'instance. Pour de plus amples informations, consultez [Adresses IP par interface réseau et par type d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) dans le *Guide de l'utilisateur Amazon EC2*.
+ Si vous **avez** opté pour le paramètre de compte `awsvpcTrunking`, mais que vous **n’avez pas** lancé de nouvelles instances de conteneur utilisant un type d’instance pris en charge après ce choix, la limite ENI pour chaque instance de conteneur reste la valeur par défaut. Pour de plus amples informations, consultez [Adresses IP par interface réseau et par type d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) dans le *Guide de l'utilisateur Amazon EC2*.
+ Si vous **avez activé** les paramètres du `awsvpcTrunking` compte et que vous **avez** lancé de nouvelles instances de conteneur à l'aide d'un type d'instance pris en charge après votre inscription, d'autres ENIs sont disponibles. Pour de plus amples informations, veuillez consulter [Instances prises en charge pour augmenter le nombre d’interfaces réseau de conteneurs Amazon ECS](eni-trunking-supported-instance-types.md).
Pour en savoir plus sur l'acceptation du paramètre de compte `awsvpcTrunking`, consultez [Augmentation des interfaces réseau d’une instance de conteneur Amazon ECS Linux](container-instance-eni.md).
Vous pouvez ajouter des instances de conteneur à votre cluster afin de mettre à disposition davantage de cartes réseau.
Attribut requis manquant dans l'instance de conteneur
Certains paramètres de définition de tâche nécessitent l'installation d'une version spécifique de l'API Docker à distance sur l'instance de conteneur. D'autres, telles que les options du pilote de journalisation, exigent que les instances de conteneur enregistrent ces pilotes de journal avec la variable de configuration d'agent `ECS_AVAILABLE_LOGGING_DRIVERS`. Si votre définition de tâche contient un paramètre qui nécessite un attribut d’instance de conteneur spécifique, et que vous ne disposez pas d’instances de conteneur répondant à cette exigence, la tâche en question ne peut pas être placée.
Cette erreur survient souvent si votre service a recours à des tâches qui utilisent le mode réseau `awsvpc` et EC2, et si aucune instance de conteneur n’est enregistrée sur le cluster dans le même sous-réseau que celui spécifié dans `awsvpcConfiguration` lors de la création du service.
Vous pouvez utiliser le AWSSupport-TroubleshootECSContainerInstance runbook pour résoudre les problèmes. Le dossier d’exploitation vérifie si les données utilisateur de l’instance contiennent les informations de cluster correctes, si le profil d’instance contient les autorisations requises et vérifie les problèmes de configuration réseau. Pour plus d’informations, consultez [AWSSupport-TroubleshootECSContainerInstance](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-troubleshoot-ecs-container-instance.html) dans le *AWS Systems Manager Guide de l’utilisateur de la référence du dossier d’exploitation d’automatisation*.
Pour plus d'informations sur les attributs nécessaires pour les paramètres de définition de tâche spécifiques et les variables de configuration d'agent, consultez [Paramètres de définition de tâche Amazon ECS pour Fargate](task_definition_parameters.md) et [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md).
## service (*service-name*) n'a pas pu placer de tâche. Motif : la capacité n'est pas disponible pour le moment. Veuillez réessayer ultérieurement ou dans une autre zone de disponibilité.
Il n'y a actuellement aucune capacité disponible pour exécuter votre service.
Vous pouvez effectuer l'une des actions suivantes :
+ Attendez que la capacité Fargate ou les instances de conteneur EC2 soient disponibles.
+ Relancez le service et spécifiez des sous-réseaux supplémentaires.
## échec du déploiement de service (*service-name*) : les tâches n'ont pas pu démarrer.
Les tâches de votre service n’ont pas pu démarrer.
Pour plus d’informations sur le débogage des tâches arrêtées, consultez la section [Messages d’erreurs liées aux tâches Amazon ECS arrêtées](stopped-task-error-codes.md).
## service (*service-name*) Le délai d'attente du démarrage de l'agent Amazon ECS a expiré. Veuillez consulter les journaux à l'adresse «/var/log/ecs/ecs-agent.log ».
L'agent de conteneur Amazon ECS de l'instance de conteneur correspondante la plus proche pour le placement des tâches est déconnecté. Si vous pouvez vous connecter à l’instance de conteneur avec SSH, vous pouvez examiner les journaux d’agent. Pour de plus amples informations, veuillez consulter [Paramètres de configuration du journal de l’agent de conteneur Amazon ECS](ecs-agent-versions.md#agent-logs). Vous devez également vérifier que l'agent est en cours d'exécution sur l'instance. Si vous utilisez l'AMI optimisée pour Amazon ECS, vous pouvez essayer d'arrêter et de redémarrer l'agent avec la commande suivante.
+ Pour l'AMI Amazon Linux 2 optimisée pour Amazon ECS
```
sudo systemctl restart ecs
```
+ Pour l'AMI Amazon Linux optimisée pour Amazon ECS
```
sudo stop ecs && sudo start ecs
```
## service (*service-name*) task set (*taskSet-ID*) (task*task-id*) n'est pas sain dans le groupe cible (*targetGroup-ARN)*) en raison de. `TARGET GROUP IS NOT FOUND`
La tâche définie pour le service échoue aux surveillances de l’état, car le groupe cible est introuvable. Le message inclut l’ID de tâche pour aider à identifier la tâche spécifique pour laquelle les surveillances de l’état échouent. Vous devez supprimer et recréer le service. Ne supprimez aucun groupe cible Elastic Load Balancing, à moins que le service Amazon ECS correspondant ne soit déjà supprimé.
## service (*service-name*) task set (*taskSet-ID*) (task*task-id*) n'est pas sain dans le groupe cible (*targetGroup-ARN)*) en raison de. `TARGET IS NOT FOUND`
La tâche définie pour le service échoue aux surveillances de l’état, car la cible est introuvable. Le message inclut l’ID de tâche pour aider à identifier la tâche spécifique pour laquelle les surveillances de l’état échouent.
## Les politiques d’autorisation IAM ont été mal configurées ou modifiées, et ECS ne peut plus maintenir votre service
Le service n’est pas en mesure de gérer les tâches en raison de politiques d’autorisation IAM mal configurées ou modifiées. Le rôle IAM associé à votre service ou à vos tâches ECS ne dispose peut-être pas des autorisations requises.
Pour résoudre ce problème, ajoutez les autorisations nécessaires au rôle IAM. Pour plus d’informations sur la gestion des autorisations, consultez la section [Ajout et suppression d’authorisations IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) dans le *Guide de l’utilisateur IAM*.
## La relation de confiance IAM a été mal configurée ou modifiée, et ECS ne peut plus maintenir votre service.
Le service n’est pas en mesure de gérer les tâches en raison d’une relation de confiance IAM mal configurée ou modifiée. Le rôle IAM associé à votre service ou à vos tâches ECS peut avoir une stratégie d’approbation incorrecte.
Pour résoudre ce problème, configurez une stratégie d’approbation pour le rôle utilisé dans la définition de votre tâche. Pour plus d’informations sur la création de politiques de confiance pour les rôles personnalisés, consultez la section [Création d’un rôle pour un cas d’utilisation personnalisé](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) dans le *Guide de l’utilisateur IAM*.
## service (*service-name*) n'a pas pu lancer *number* les tâches de déploiement*deployment-id*.
Le planificateur de services envoie ce message d'événement lorsqu'un flux de travail de déploiement démarre avec succès certaines tâches mais ne parvient pas à lancer toutes les tâches demandées en raison d'erreurs de capacité insuffisante. Cela se produit généralement lorsque le disjoncteur est activé et permet de comprendre pourquoi les déploiements peuvent échouer ou revenir en arrière.
Le message inclut la raison spécifique de la panne, telle que l'insuffisance du processeur, de la mémoire ou d'autres contraintes de ressources. Cela vous permet de comprendre quelles ressources doivent être utilisées pour résoudre le problème de déploiement.
Pour de plus amples informations, veuillez consulter [service (*service-name*) n'a pas pu placer de tâche car aucune instance de conteneur ne répondait à toutes ses exigences.](#service-event-messages-1).
## service (*service-name*) n'a pas pu placer de tâches dans votre cluster car la limite de capacité de provisionnement des tâches a été dépassée.
Le planificateur de services envoie ce message d'événement lorsque votre cluster a atteint la limite de 500 tâches pouvant être dans l'`PROVISIONING`état simultanément. Il s'agit d'une limite au niveau du cluster et non d'un problème spécifique au service.
Cela se produit généralement lorsque vous démarrez un service avec un grand nombre de tâches souhaitées avec une capacité préprovisionnée limitée, ou lorsque plusieurs services sont démarrés simultanément, ce qui entraîne une perte de tâches élevée.
Pour résoudre ce problème :
+ Attendez que les tâches existantes soient terminées et passent à l'`RUNNING`état.
+ Envisagez de faire évoluer vos services de manière plus progressive pour éviter d'atteindre la limite de provisionnement.
+ Passez en revue la configuration du fournisseur de capacité de votre cluster pour vous assurer que les ressources adéquates sont disponibles.
Pour plus d'informations sur les quotas de service Amazon ECS, consultez la section [Points de terminaison et quotas Amazon Elastic Container Service](https://docs.aws.amazon.com/general/latest/gr/ecs-service.html) dans le manuel *Amazon Web Services General Reference*.
# Messages d’événement relatifs à un dysfonctionnement d’un service Amazon ECS
Voici des exemples de messages d’événements de dysfonctionnement du service.
## EC2 : (service*service-name*) (tâche) (instance*task-id*) (port *instance-id**port-number*) ne fonctionne pas correctement dans (groupe cible) en raison de (raison*target-group-name*) *failure-reason*
Ce message indique qu’une tâche exécutée sur une instance EC2 échoue aux surveillances de l’état. Pour plus d’informations, consultez les ressources suivantes :
+ [Comment puis-je faire en sorte que mes tâches Amazon ECS qui utilisent EC2 réussissent la surveillance de l’état de l’Application Load Balancer ?](https://repost.aws/knowledge-center/troubleshoot-unhealthy-checks-ecs)
## EC2 avec TaskSet : (service*service-name*, TaskSet*taskSet-id*) (tâche) (instance*task-id*) (port*instance-id*) ne fonctionne pas *port-number* correctement dans (groupe cible) en raison de (raison*target-group-name*) *failure-reason*
Ce message indique qu’une tâche d’un jeu de tâches exécutée sur une instance EC2 échoue aux surveillances de l’état. Pour plus d’informations, consultez les ressources suivantes :
+ [Comment puis-je faire en sorte que mes tâches Amazon ECS qui utilisent EC2 réussissent la surveillance de l’état de l’Application Load Balancer ?](https://repost.aws/knowledge-center/troubleshoot-unhealthy-checks-ecs)
## Fargate : (*service-name*service) (*task-id*tâche) (*port-number*port) ne fonctionne pas correctement dans (*target-group-name*groupe cible) en raison de (raison) *failure-reason*
Ce message indique qu’une tâche Fargate échoue aux surveillances de l’état.
Pour plus d’informations sur la résolution des échecs de surveillance de l’état dans les tâches Fargate, consultez la section [Comment résoudre les échecs de surveillance de l’état pour les tâches Amazon ECS sur Fargate ?](https://repost.aws/knowledge-center/ecs-fargate-health-check-failures).
## Fargate avec TaskSet : (*service-name*service, *taskSet-id* TaskSet) (*task-id*tâche) (*port-number*port) ne fonctionne pas correctement dans (groupe *target-group-name* cible) en raison de (raison) *failure-reason*
Ce message indique qu’une tâche d’un jeu de tâches exécuté sur Fargate échoue aux surveillances de l’état.
Pour plus d’informations sur la résolution des échecs de surveillance de l’état dans les tâches Fargate, consultez la section [Comment résoudre les échecs de surveillance de l’état pour les tâches Amazon ECS sur Fargate ?](https://repost.aws/knowledge-center/ecs-fargate-health-check-failures).
# Messages d’événement de rééquilibrage de service entre zones de disponibilité Amazon ECS
Voici quelques exemples de messages d’événement de service que vous pouvez rencontrer :
## 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.
Le planificateur de service envoie un événement de service `service (service-name) is not AZ balanced` lorsque le nombre de tâches n’est pas réparti uniformément entre les zones de disponibilité. Il n’y a aucune mesure à prendre. Il s’agit d’un événement d’information.
## 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*.
Le planificateur de service envoie un événement de service `service (service-name) is AZ balanced` lorsque le rééquilibrage des services entre zones de disponibilité est terminé. Il n’y a aucune mesure à prendre. Il s’agit d’un événement d’information.
## *service-name*a commencé *number-tasks* des tâches dans *Availability Zone* AZ Rebalance :*task-ids*.
Le planificateur de services envoie un événement*service-name*/*task-set-name*a démarré *number* des tâches dans le *Availability Zone* service lorsqu'il démarre des tâches dans une zone de disponibilité en raison du rééquilibrage des services. Il n’y a aucune mesure à prendre. Il s’agit d’un événement d’information.
## *service-name*a cessé *number-tasks* d'exécuter des tâches en *Availability Zone* raison du rééquilibrage AZ :*task-id*.
Le planificateur de services envoie un événement*service-name*/*task-set-name*a arrêté les *number* tâches dans le *Availability Zone* service lorsqu'il arrête des tâches dans une zone de disponibilité en raison du rééquilibrage des services. Il n’y a aucune mesure à prendre. Il s’agit d’un événement d’information.
## 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.
Le planificateur de services envoie un *service-name* événement Impossible de placer une tâche dans le *Availability Zone* service car aucune instance de conteneur ne répond à toutes ses exigences. Pour résoudre ce problème, lancez des instances dans la zone de disponibilité.
## service (*service-name*) ne parvient pas à placer une tâche dedans*Availability Zone*.
Le planificateur de services envoie un *service-name* événement « Impossible de placer une tâche dans le *Availability Zone* service » lorsque vous utilisez le Fargate et qu'aucune capacité n'est disponible.
Vous pouvez ajouter des sous-réseaux supplémentaires dans la zone de disponibilité dans le message d'erreur, ou contacter Support pour obtenir de la capacité supplémentaire.
## 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*.
Le planificateur de services envoie un *service-name* message « Impossible » à AZ Rebalance car celui-ci n'*task-set-name*a pas pu être redimensionné en raison d'un événement de *reason* service lorsque vous utilisez la protection intégrée des tâches.
Vous pouvez effectuer l'une des actions suivantes :
+ Attendez que la protection des tâches en cours expire pour pouvoir y mettre fin.
+ Déterminez les tâches qui peuvent être arrêtées et utilisez l’API `UpdateTaskProtection` avec l’option `protectionEnabled` définie sur `false` pour désactiver la protection de ces tâches.
+ Augmentez le nombre de tâches souhaité pour le service à un nombre supérieur au nombre de tâches protégées.
## service (*service-name*) a arrêté AZ Rebalancing.
Le planificateur de services envoie un événement d'*service-name*arrêt du service AZ Rebalancing lorsque l'opération de rééquilibrage de la zone de disponibilité s'arrête. Il s’agit d’un événement d’information. Amazon ECS envoie des événements supplémentaires qui fournissent davantage d’informations.
# Résolution des problèmes liés aux équilibreurs de charge des services dans Amazon ECS
Les services Amazon ECS service peuvent enregistrer des tâches auprès d'un équilibreur de charge Elastic Load Balancing. Les erreurs de configuration d'équilibreur de charge sont des causes courantes de l'arrêt des tâches. Si vos tâches arrêtées ont été lancées par des services qui utilisent un équilibreur de charge, pensez aux causes possibles suivantes.
**Le rôle lié à un service Amazon ECS n’existe pas**
Le rôle lié à un service Amazon ECS service permet aux services Amazon ECS service d'enregistrer des instances de conteneur avec des équilibreurs de charge Elastic Load Balancing. Le rôle lié à un service doit être créé dans votre compte. Pour de plus amples informations, veuillez consulter [Utilisation des rôles liés à un service pour Amazon ECS](using-service-linked-roles.md).
**Groupe de sécurité des instances de conteneur**
Si votre conteneur est mappé au port 80 sur votre instance de conteneur, votre groupe de sécurité d'instance de conteneur doit autoriser le trafic entrant sur le port 80 pour que les surveillances de l'état de l'équilibreur de charge réussissent.
**L'équilibreur de charge Elastic Load Balancing n'est pas configuré pour toutes les zones de disponibilité**
Votre équilibreur de charge doit être configuré pour utiliser toutes les zones de disponibilité d'une région, ou au moins toutes les zones de disponibilité dans lesquelles se trouvent vos instances de conteneur. Si un service utilise un équilibreur de charge et lance une tâche sur une instance de conteneur qui réside dans une zone de disponibilité pour laquelle l’équilibreur de charge n’est pas configuré, la tâche en question ne réussira jamais la surveillance de l’état. La tâche est alors supprimée.
**Le bilan de santé de l'équilibreur de charge Elastic Load Balancing est mal configuré**
Les paramètres de surveillance de l'état de l'équilibreur de charge peuvent être trop restrictifs ou pointer vers des ressources qui n'existent pas. Si une instance de conteneur n’est pas considérée comme saine, elle est supprimée de l’équilibreur de charge. Veillez à vérifier si les paramètres suivants sont correctement configurés pour votre équilibreur de charge de service.
Ping Port
La valeur **Ping Port** pour une surveillance de l'état d'équilibreur de charge correspond au port des instances de conteneur vérifiées par l'équilibreur de charge pour en déterminer l'état. Si ce port n'est pas correctement configuré, l'équilibreur de charge est susceptible d'annuler l'enregistrement de votre instance de conteneur. Ce port doit être configuré de manière à utiliser la valeur `hostPort` correspondant au conteneur dans la définition de tâche de votre service que vous utilisez avec la surveillance de l'état.
Ping Path
Cela fait partie de la surveillance de l’état de l’équilibreur de charge. Il s’agit d’un point de terminaison de votre application qui peut renvoyer un code d’état valide (par exemple, 200) lorsque l’application est saine. Cette valeur est souvent définie sur `index.html`, mais si votre service ne répond pas à cette demande, la surveillance de l'état échoue. Si votre conteneur n'a pas de fichier `index.html`, vous pouvez définir la valeur `/` afin de cibler l'URL de base pour l'instance de conteneur.
Response Timeout
Cette valeur correspond au délai dont dispose votre conteneur pour renvoyer une réponse à la commande ping de surveillance de l'état. Si cette valeur est inférieure à la durée nécessaire pour une réponse, la surveillance de l'état échoue.
Health Check Interval
Il s'agit de la durée entre les pings de surveillance de l'état. Plus vos intervalles de surveillance de l'état sont courts, plus votre instance de conteneur peut atteindre rapidement le **seuil de défectuosité**.
Unhealthy Threshold
Il s'agit du nombre d'échecs possibles des surveillances de l'état avant que votre instance de conteneur ne soit considérée comme étant défectueuse. Si vous avez un seuil de défectuosité de 2 et un intervalle de surveillance de l’état de 30 secondes, votre tâche a 60 secondes pour répondre au ping de surveillance de l’état avant d’être considérée comme défectueuse. Vous pouvez augmenter le seuil de défectuosité ou l'intervalle de surveillance de l'état afin de donner à vos tâches plus de temps pour répondre.
**Impossible de mettre à jour le service *servicename* : le** **nom ou le port du conteneur de l'équilibreur de charge ont été modifiés dans la définition de la tâche**
Si votre service utilise un équilibreur de charge, vous pouvez utiliser le SDK AWS CLI ou le SDK pour modifier la configuration de l'équilibreur de charge. Pour plus d'informations sur la façon 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 vous mettez à jour la définition de tâche pour le service, le nom et le port de conteneur spécifiés dans la configuration de l'équilibreur de charge doivent rester dans la définition de tâche.
**Vous avez atteint la limite du nombre de tâches que vous pouvez exécuter simultanément.**
Pour un nouveau compte, vos quotas peuvent être inférieurs aux Service Quotas. Le quota de service de votre compte peut être affiché dans la console Service Quotas. Pour demander une augmentation de quota, consultez [Demande d'augmentation de quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) dans le *Guide de l'utilisateur Service Quotas*.
# Résolution des problèmes d’autoscaling du service dans Amazon ECS
L’autoscaling de l’application désactive les processus de réduction horizontale pendant que les déploiements Amazon ECS sont en cours. Ces processus reprennent une fois le déploiement terminé. Toutefois, pendant les déploiements, les processus de montée en puissance se poursuivent, sauf s'ils sont suspendus. 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).
# Capture d'événements Amazon ECS dans la console
La console Amazon ECS fournit une fonctionnalité de capture d'événements qui stocke les événements générés par Amazon ECS, tels que les actions de service et les modifications de l'état des tâches, dans Amazon Logs par le biais d'Amazon CloudWatch Logs. EventBridge Cette fonctionnalité inclut une interface d’interrogation dotée de filtres pour la surveillance et la résolution des problèmes.
Les événements fournissent des informations détaillées sur le fonctionnement de vos déploiements de service, services, tâches et instances. Vous pouvez utiliser ces informations pour résoudre les problèmes de déploiement de vos tâches et services.
Lorsque vous activez la capture d'événements, vous avez accès à tous les événements générés par Amazon ECS pendant une période de rétention de votre choix, allant au-delà des limites natives des 100 derniers événements non filtrés ou tâches arrêtées visibles pendant une heure seulement.
## Comment ça marche
La capture d'événements permet EventBridge de stocker les événements dans un groupe de CloudWatch journaux Amazon Logs prédéfini. La console Amazon ECS fournit des requêtes prédéfinies et des options de filtrage, et met en corrélation les événements afin de présenter les cycles de vie des tâches dans un format intuitif.
Vous pouvez interroger et récupérer les types d’événements suivants :
+ **Événements liés aux actions de service** : permettent d’identifier les problèmes de provisionnement ou d’allocation des ressources
+ **Événements liés au cycle de vie des tâches** : permettent d’identifier les raisons pour lesquelles les tâches ou les conteneurs ne parviennent pas à démarrer ou cessent de fonctionner.
La console Amazon ECS vous permet de configurer la capture d'événements en un clic et fournit des requêtes et des filtres couramment utilisés sans que vous ayez à apprendre les langages de requête ou à naviguer entre plusieurs consoles.
## Types d’événements
La capture des événements stocke tous les événements générés par Amazon ECS dans les catégories suivantes :
Événements de modification de l'état de la tâche
Arrêts de conteneurs et autres événements de terminaison, que vous pouvez utiliser pour le dépannage ou pour surveiller le cycle de vie des tâches.
Actions de service
Atteinte d’un état stable, échec d’un placement de tâche, contraintes en matière de ressources, etc.
Changement d’état du déploiement du service
Des événements tels que des déploiements en cours, terminés ou échoués, déclenchés par les paramètres du disjoncteur et de l'annulation, pour surveiller l'état du déploiement d'un service.
Changement d’état des instances de conteneur
Pour les charges de travail sur les instances gérées EC2 et Amazon ECS, les événements indiquent l'état connecté et déconnecté.
## Configuration du groupe de journaux
Lorsque vous activez la capture d'événements, Amazon ECS crée automatiquement les ressources suivantes :
+ Un groupe de CloudWatch journaux Amazon Logs nommé `/aws/events/ecs/containerinsights/${clusterName}/performance`
+ EventBridge Règle qui ingère tous les événements de la `aws.ecs` source et les transmet au groupe de journaux
Vous pouvez définir une période de conservation pour le groupe de journaux comprise entre 1 jour et 10 ans. La période de conservation par défaut est de 7 jours.
## Considérations
Lorsque vous utilisez la capture d'événements, tenez compte des points suivants :
+ La capture d'événements enregistre tous les événements pour plus de simplicité. Vous ne pouvez pas configurer de règles dans la console Amazon ECS pour capturer uniquement des événements spécifiques.
+ La console Amazon ECS fournit des critères de requête prédéfinis. Pour les requêtes avancées, utilisez Amazon CloudWatch Logs Logs Insights pour interroger directement le groupe de journaux.
+ La fonctionnalité Live Tail n'est pas disponible dans la console Amazon ECS. Utilisez Amazon CloudWatch Logs directement pour suivre en direct.
+ Lorsque vous désactivez la capture d'événements, la EventBridge règle est supprimée.
+ La capture d'événements entraîne des coûts supplémentaires liés à l'ingestion des EventBridge données, au stockage d'Amazon CloudWatch Logs et à l'exécution des requêtes.
Pour plus d'informations sur la EventBridge tarification, consultez la section [EventBridge tarification](https://aws.amazon.com/eventbridge/pricing/).
Pour plus d'informations sur la CloudWatch tarification, consultez la section [CloudWatch tarification](https://aws.amazon.com/cloudwatch/pricing/).
## Dépannage basé sur les événements
Utilisez les événements générés par Amazon ECS pour répondre aux questions de dépannage courantes.
### Analyse des échecs de tâches
Vous pouvez consulter les événements de modification de l'état des `STOPPED` tâches, les codes d'arrêt et les codes de sortie des conteneurs afin de déterminer pourquoi une tâche n'a pas pu être lancée ou a échoué pendant son exécution.
Vous pouvez consulter les événements liés aux actions de service pour détecter les échecs de placement et les informations relatives aux contraintes de ressources afin de déterminer pourquoi une tâche n'a pas pu être placée en raison de contraintes de ressources.
### Scénarios d'échec de tâches courants
Les échecs de tâches anormaux les plus courants sont liés aux problèmes suivants :
+ Défaillances du déploiement du service CI/CD
+ Défaillances du dimensionnement automatique
+ Défaillances du rééquilibrage des tâches
+ Sorties anormales du conteneur, telles que des erreurs out-of-memory (OOM)
Les échecs de tâches anormaux produisent des événements de modification de l'état des `STOPPED` tâches avec un code `EssentialContainerExited` ou un code d'`TaskFailedToStart`arrêt. Vous pouvez filtrer en fonction de ces codes d'arrêt pour examiner les comportements d'exécution et d'arrêt des conteneurs.
# Activer la capture d'événements pour un cluster Amazon ECS existant
Vous pouvez activer la capture d'événements sur un cluster Amazon ECS existant pour stocker les événements générés par Amazon ECS dans Amazon CloudWatch Logs via. EventBridge Cette fonctionnalité vous permet de surveiller et de résoudre les échecs de tâches, les déploiements de services et les autres activités du cluster.
Après avoir activé la capture d'événements, Amazon ECS crée les ressources suivantes :
+ Un groupe de CloudWatch journaux Amazon Logs nommé `/aws/events/ecs/containerinsights/${clusterName}/performance`
+ EventBridge Règle qui capture tous les événements depuis la `aws.ecs` source
Un onglet **Historique** s'affiche dans la vue du cluster, vous permettant d'interroger les événements du cycle de vie des tâches et les actions de service. La capture des événements commence immédiatement et stocke tous les événements générés par Amazon ECS conformément à la période de conservation que vous avez spécifiée.
## Conditions préalables
+ Un cluster Amazon ECS existant
+ Autorisations IAM appropriées pour modifier les paramètres du cluster et créer des ressources Amazon CloudWatch Logs
## Activer la capture d'événements à l'aide de la console
1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2).
1. Dans le panneau de navigation, choisissez **Clusters**.
1. Sélectionnez le cluster dans lequel vous souhaitez activer la capture d'événements.
La page des détails du cluster s’ouvre.
1. Choisissez **Configuration**.
1. Dans la section **des événements ECS**, choisissez **Activer la capture des événements**.
La boîte de dialogue **Activer la capture d'événements** s'affiche.
1. Pour l'**événement Expire**, choisissez la période de rétention pour le groupe de CloudWatch journaux Amazon Logs. La valeur par défaut est de 7 jours.
1. Choisissez **Activer**.
# Affichage des événements de modification de l'état du service et des tâches Amazon ECS
La console Amazon ECS fournit une fonctionnalité de capture d'événements qui stocke les événements générés par Amazon ECS, tels que les actions de service et les modifications de l'état des tâches, dans Amazon Logs par le biais d'Amazon CloudWatch Logs. EventBridge Cette fonctionnalité inclut une interface de requête dotée de fonctionnalités de filtrage pour améliorer la surveillance et le dépannage.
Les événements fournissent des informations détaillées sur le fonctionnement de vos déploiements de service, services, tâches et instances. Vous pouvez utiliser ces informations pour résoudre les problèmes de déploiement de vos tâches et services.
Vous pouvez utiliser l'un des critères suivants pour filtrer les événements :
+ ID de déploiement (disponible uniquement sur la page détaillée du service)
+ L’heure de début
+ L’heure de fin
+ Nom du service (applicable uniquement sur la page détaillée du cluster, sur la page de détail du service, ce sera le service actuel par défaut)
+ ID de tâche
+ Dernier état de la tâche
+ Famille de définitions de tâches
+ Révision de la définition des tâches
## Affichage des événements au niveau du cluster
1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2).
1. Choisissez **Clusters**.
La page de liste des clusters s'affiche.
1. Choisissez le cluster .
La page des détails du cluster s’ouvre.
1. Sous **Historique**, déterminez les événements à consulter.
1. Pour afficher les événements d'action de service, choisissez **Événements d'action de service**.
1. Pour afficher les événements de changement d'état de **tâche, choisissez Événements de changement d'état** de tâche.
1. (Facultatif) Dans **Critères de requête**, entrez les filtres pour les événements que vous souhaitez afficher.
1. Choisissez **Exécuter la requête**.
Les événements s'affichent sous forme de liste.
1. Pour consulter tous les détails de l'événement, sélectionnez-le.
## Visualisation au niveau du service
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. Sous **Historique**, déterminez les événements à consulter.
1. Pour afficher les événements d'action de service, choisissez **Événements d'action de service**.
1. Pour afficher les événements de changement d'état de **tâche, choisissez Événements de changement d'état** de tâche.
1. (Facultatif) Dans **Critères de requête**, entrez les filtres pour les événements que vous souhaitez afficher.
1. Choisissez **Exécuter la requête**.
Les événements s'affichent sous forme de liste.
1. Pour consulter tous les détails de l'événement, sélectionnez-le.
# Résolution des erreurs d’UC ou de mémoire non valides liées à la définition des tâches Amazon ECS
Lorsque vous enregistrez une définition de tâche à l'aide de l'API Amazon ECS ou AWS CLI, si vous spécifiez une `memory` valeur `cpu` ou une valeur non valide, l'erreur suivante est renvoyée.
```
An error occurred (ClientException) when calling the RegisterTaskDefinition operation: Invalid 'cpu' setting for task.
```
**Note**
Si vous utilisez Terraform, l’erreur suivante peut être renvoyée.
```
Error: ClientException: No Fargate configuration exists for given values.
```
Pour résoudre ce problème, vous devez spécifier une valeur prise en charge pour l'UC et la mémoire de la tâche dans votre définition de tâche. La `cpu` valeur peut être exprimée en unités CPU ou CPUs en v dans une définition de tâche. Elle est convertie en un nombre entier indiquant le nombre d’unités d’UC lorsque la définition de la tâche est enregistrée. La valeur `memory` peut être exprimée en Mio ou en Go dans une définition de tâche. Elle est convertie en un entier indiquant le nombre de Mio lorsque la définition de la tâche est enregistrée.
Pour les définitions de tâches qui spécifient `FARGATE` pour le paramètre `requiresCompatibilities` (même si `EC2` est également spécifié), vous devez utiliser l’une des valeurs indiquées dans le tableau suivant. Ces valeurs déterminent votre plage de valeurs prises en charge pour le paramètre d’UC et de mémoire.
Pour les tâches hébergées sur Fargate, le tableau suivant indique les combinaisons de processeur et de mémoire valides. Les valeurs de mémoire du fichier JSON sont spécifiées en Mio. Vous pouvez convertir la valeur en Go en Mio en la multipliant par 1 024. Par exemple, 1 Go = 1 024 Mio.
| Valeur d'UC | Valeur de mémoire | Systèmes d'exploitation pris en charge pour AWS Fargate |
| --- | --- | --- |
| 256 (0,25 vCPU) | 512 Mio, 1 Go, 2 Go | Linux |
| 512 (0,5 vCPU) | 1 Go, 2 Go, 3 Go, 4 Go | Linux |
| 1 024 (1 vCPU) | 2 Go, 3 Go, 4 Go, 5 Go, 6 Go, 7 Go, 8 Go | Linux, Windows |
| 2 048 (2 vCPU) | Entre 4 Go et 16 Go par incréments de 1 Go | Linux, Windows |
| 4 096 (4 vCPU) | Entre 8 Go et 30 Go par incréments de 1 Go | Linux, Windows |
| 8192 (8 vCPU) Cette option nécessite la plateforme Linux `1.4.0` ou ultérieure | Entre 16 Go et 60 Go par incréments de 4 Go | Linux |
| 16384 (16vCPU) Cette option nécessite la plateforme Linux `1.4.0` ou ultérieure | Entre 32 Go et 120 Go par incréments de 8 Go | Linux |
Pour les tâches hébergées sur Amazon EC2, les valeurs du processeur des tâches prises en charge sont comprises entre 0,25 v CPUs et 192 v. CPUs
Le mécanisme de contrôle de l’UC diffère entre EC2 et Fargate :
+ Pour les tâches hébergées sur Amazon EC2 : Amazon ECS utilise la période d’UC et le quota d’UC pour contrôler les limites strictes de taille des tâches en termes d’UC. Lorsque vous spécifiez le vCPU dans votre définition de tâche, Amazon ECS traduit la valeur en période d’UC et en paramètres de quota d’UC qui s’appliquent au `cgroup`.
+ Pour les tâches hébergées sur Fargate : Amazon ECS utilise des partages d’UC pour contrôler l’allocation de l’UC. Les valeurs de quota et de période d’UC ne sont pas utilisées pour limiter l’UC dans les tâches Fargate.
Pour les tâches Amazon EC2, le quota d’UC contrôle le temps processeur accordé à un `cgroup` pendant une période d’UC donnée. Les deux paramètres sont exprimés en microsecondes. Lorsque le quota de processeur est égal à la période du processeur, cela signifie que a `cgroup` peut exécuter jusqu'à 100 % sur un vCPU (ou toute autre fraction totalisant 100 % pour plusieurs v). CPUs Le quota d’UC est au maximum de 1 000 000 us et la période d’UC est d’au moins 1 ms. Vous pouvez utiliser ces valeurs pour définir les limites de votre nombre d’UC. Lorsque vous modifiez la période d’UC sans modifier le quota d’UC, vous disposez de limites effectives différentes de celles que vous avez spécifiées dans votre définition de tâche.
La période de 100 ms permet un v CPUs compris entre 0,125 et 10.
**Note**
Les paramètres d'UC et de mémoire de niveau tâche sont ignorés pour les conteneurs Windows.
# Affichage du journal d’agent de conteneur Amazon ECS
Amazon ECS stocke les journaux dans le dossier `/var/log/ecs` de vos instances de conteneur. Des journaux sont disponibles à partir de l'agent de conteneur Amazon ECS et du service `ecs-init` qui contrôle l'état de l'agent (démarrage/arrêt) sur l'instance de conteneur. Vous pouvez afficher ces fichiers journaux en vous connectant à une instance de conteneur à l'aide de SSH.
**Note**
Si vous n'êtes pas sûr de savoir comment collecter tous les journaux de vos instances de conteneur, vous pouvez utiliser le collecteur de journaux d'Amazon ECS. Pour de plus amples informations, veuillez consulter [Collecte des journaux de conteneur avec collecteur de journaux Amazon ECS](ecs-logs-collector.md).
## Système d'exploitation Linux
Le processus `ecs-init` stocke les journaux à l'emplacement `/var/log/ecs/ecs-init.log`.
Le fichier `ecs-init.log` contient des informations sur la gestion du cycle de vie, la configuration et l’amorçage de l’agent conteneur.
Vous pouvez utiliser la commande suivante pour visualiser les fichiers journaux.
```
cat /var/log/ecs/ecs-init.log
```
Sortie :
```
2018-02-16T18:13:54Z [INFO] pre-start
2018-02-16T18:13:56Z [INFO] start
2018-02-16T18:13:56Z [INFO] No existing agent container to remove.
2018-02-16T18:13:56Z [INFO] Starting Amazon Elastic Container Service Agent
```
## Système d'exploitation Windows
Vous pouvez utiliser le collecteur de journaux Amazon ECS pour Windows. Pour plus d’informations, consultez la section [Amazon ECS Logs Collector pour Windows](https://github.com/awslabs/aws-ecs-logs-collector-for-windows?tab=readme-ov-file#aws-ecs-logs-collector-for-windows) sur Github.
1. Connectez-vous à votre instance.
1. Ouvrez PowerShell puis exécutez les commandes suivantes avec des privilèges administratifs. Les commandes téléchargent le script et collectent les journaux.
```
Invoke-WebRequest -OutFile ecs-logs-collector.ps1 https://raw.githubusercontent.com/awslabs/aws-ecs-logs-collector-for-windows/master/ecs-logs-collector.ps1
.\ecs-logs-collector.ps1
```
Vous pouvez activer la journalisation de débogage pour l’agent Amazon ECS et le démon Docker. Cette option permet au script de collecter les journaux avant d’activer le mode de débogage. Le script redémarre le démon Docker et l’agent Amazon ECS, puis met fin à tous les conteneurs exécutés sur l’instance. Avant d’exécuter la commande suivante, videz l’instance de conteneur et déplacez les tâches importantes vers d’autres instances de conteneur.
Exécutez la commande suivante pour activer la journalisation.
```
.\ecs-logs-collector.ps1 -RunMode debug
```
# Collecte des journaux de conteneur avec collecteur de journaux Amazon ECS
**Note**
Vous ne pouvez pas utiliser le collecteur de journaux Amazon ECS sur les instances gérées Amazon ECS.
Si vous n'êtes pas sûr de savoir comment de collecter les différents journaux de vos instances de conteneur, vous pouvez utiliser le collecteur de journaux d'Amazon ECS. Il est disponible GitHub pour [Linux](https://github.com/awslabs/ecs-logs-collector) et [Windows](https://github.com/awslabs/aws-ecs-logs-collector-for-windows). Le script collecte les journaux généraux du système d'exploitation ainsi que les journaux des agents de conteneur Docker et Amazon ECS, ce qui peut être utile pour les AWS Support cas de dépannage. Puis, il compresse et archive les informations collectées dans un seul fichier qui peut être facilement partagé à des fins de diagnostic. Il prend également en charge l'activation du mode de débogage pour le démon Docker et l'agent de conteneur Amazon ECS sur les variantes d'Amazon Linux (AMI optimisée pour Amazon ECS, par exemple).
**Note**
Sur Amazon Linux, AMIs version optimisée pour Amazon ECS 20250909 et versions ultérieures, le collecteur de journaux Amazon ECS est préinstallé `/opt/amazon/ecs/ecs-logs-collector.sh` et prêt à être utilisé sans téléchargement depuis. GitHub Pour plus d'informations, consultez [ECS Logs Collector](https://github.com/aws/amazon-ecs-ami?tab=readme-ov-file#ecs-logs-collector) dans la documentation de l'AMI optimisée pour ECS.
Actuellement, le collecteur de journaux Amazon ECS prend en charge les systèmes d'exploitation suivants :
+ Amazon Linux
+ Utilisation de Red Hat Enterprise Linux
+ Ubuntu
+ Windows Server
**Pour exécuter le collecteur de logs Amazon ECS pour Linux (AMI optimisée pour ECS)**
1. Connectez-vous à votre instance de conteneur.
1. Exécutez le script pour collecter les journaux et créer l'archive.
**Note**
Pour activer le mode de débogage pour le démon Docker et l’agent de conteneur Amazon ECS, ajoutez l’option `--mode=enable-debug` à la commande suivante. Cela pourrait redémarrer le démon Docker, ce qui entraînerait la suppression de tous les conteneurs en cours d’exécution sur l’instance. Pensez à drainer l'instance de conteneur et à transférer les tâches importantes vers d'autres instances de conteneur avant d'activer le mode de débogage. Pour de plus amples informations, veuillez consulter [Drainage des instances de conteneur Amazon ECS](container-instance-draining.md).
```
[ec2-user ~]$ sudo /opt/amazon/ecs/ecs-logs-collector.sh
```
Une fois que vous avez exécuté le script, vous pouvez examiner les journaux collectés dans le dossier `collect` créé par le script. Le `collect.tgz` fichier est une archive compressée de tous les journaux, que vous pouvez partager AWS Support pour obtenir de l'aide au diagnostic.
**Pour télécharger et exécuter le collecteur de journaux Amazon ECS pour Linux**
1. Connectez-vous à votre instance de conteneur.
1. Téléchargez le script de collecteur de journaux Amazon ECS.
```
curl -O https://raw.githubusercontent.com/awslabs/ecs-logs-collector/master/ecs-logs-collector.sh
```
1. Exécutez le script pour collecter les journaux et créer l'archive.
```
$ sudo bash ./ecs-logs-collector.sh
```
**Pour télécharger et exécuter le collecteur de journaux Amazon ECS pour Windows**
1. Connectez-vous à votre instance de conteneur. Pour plus d’informations, consultez la section [Connexion à votre instance Windows à l’aide de RDP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html) dans le *Guide de l’utilisateur Amazon EC2*.
1. Téléchargez le script du collecteur de journaux Amazon ECS à l'aide de PowerShell.
```
Invoke-WebRequest -OutFile ecs-logs-collector.ps1 https://raw.githubusercontent.com/awslabs/aws-ecs-logs-collector-for-windows/master/ecs-logs-collector.ps1
```
1. Exécutez le script pour collecter les journaux et créer l'archive.
**Note**
Pour activer le mode de débogage pour le démon Docker et l’agent de conteneur Amazon ECS, ajoutez l’option `-RunMode debug` à la commande suivante. Cette action redémarre le démon Docker, ce qui supprime tous les conteneurs qui s'exécutent sur l'instance. Pensez à drainer l'instance de conteneur et à transférer les tâches importantes vers d'autres instances de conteneur avant d'activer le mode de débogage. Pour de plus amples informations, veuillez consulter [Drainage des instances de conteneur Amazon ECS](container-instance-draining.md).
```
.\ecs-logs-collector.ps1
```
Une fois que vous avez exécuté le script, vous pouvez examiner les journaux collectés dans le dossier `collect` créé par le script. Le `collect.tgz` fichier est une archive compressée de tous les journaux, que vous pouvez partager avec le AWS Support pour obtenir de l'aide au diagnostic.
# Récupération des informations de diagnostic d’Amazon ECS avec l’introspection d’agent
L’API d’introspection d’agent Amazon ECS fournit des informations sur l’état général de l’agent Amazon ECS et des instances de conteneur.
Vous pouvez utiliser l’API d’introspection d’agent pour obtenir l’ID Docker d’un conteneur dans votre tâche. Vous pouvez aussi utiliser l'API d'introspection d'agent en vous connectant à une instance de conteneur à l'aide de SSH.
**Important**
Votre instance de conteneur doit avoir un rôle IAM qui autorise l'accès à Amazon ECS afin d'atteindre l'API d'introspection. Pour de plus amples informations, veuillez consulter [Rôle IAM d'instance de conteneur Amazon ECS](instance_IAM_role.md).
L’exemple suivant illustre deux tâches : une en cours d’exécution et une qui a été arrêtée.
**Note**
La commande suivante est redirigée via **python -mjson.tool** pour une lecture plus facile.
```
curl http://localhost:51678/v1/tasks | python -mjson.tool
```
Sortie :
```
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1095 100 1095 0 0 117k 0 --:--:-- --:--:-- --:--:-- 133k
{
"Tasks": [
{
"Arn": "arn:aws:ecs:us-west-2:aws_account_id:task/090eff9b-1ce3-4db6-848a-a8d14064fd24",
"Containers": [
{
"DockerId": "189a8ff4b5f04affe40e5160a5ffadca395136eb5faf4950c57963c06f82c76d",
"DockerName": "ecs-console-sample-app-static-6-simple-app-86caf9bcabe3e9c61600",
"Name": "simple-app"
},
{
"DockerId": "f7f1f8a7a245c5da83aa92729bd28c6bcb004d1f6a35409e4207e1d34030e966",
"DockerName": "ecs-console-sample-app-static-6-busybox-ce83ce978a87a890ab01",
"Name": "busybox"
}
],
"Family": "console-sample-app-static",
"KnownStatus": "STOPPED",
"Version": "6"
},
{
"Arn": "arn:aws:ecs:us-west-2:aws_account_id:task/1810e302-eaea-4da9-a638-097bea534740",
"Containers": [
{
"DockerId": "dc7240fe892ab233dbbcee5044d95e1456c120dba9a6b56ec513da45c38e3aeb",
"DockerName": "ecs-console-sample-app-static-6-simple-app-f0e5859699a7aecfb101",
"Name": "simple-app"
},
{
"DockerId": "096d685fb85a1ff3e021c8254672ab8497e3c13986b9cf005cbae9460b7b901e",
"DockerName": "ecs-console-sample-app-static-6-busybox-92e4b8d0ecd0cce69a01",
"Name": "busybox"
}
],
"DesiredStatus": "RUNNING",
"Family": "console-sample-app-static",
"KnownStatus": "RUNNING",
"Version": "6"
}
]
}
```
Dans l'exemple précédent, la tâche arrêtée (*090eff9b-1ce3-4db6-848a-a8d14064fd24*) possède deux conteneurs. Vous pouvez utiliser **docker inspect *container-ID*** pour afficher des informations détaillées sur chaque conteneur. Pour de plus amples informations, veuillez consulter [Introspection de conteneur Amazon ECS](ecs-agent-introspection.md).
# Diagnostic Docker dans Amazon ECS
Docker fournit plusieurs outils de diagnostic qui peuvent vous aider à résoudre les problèmes que vous rencontrez avec vos conteneurs et vos tâches. Pour plus d’informations sur tous les utilitaires de ligne de commande Docker disponibles, consultez la [Référence de la CLI Docker](https://docs.docker.com/reference/cli/docker/) dans la documentation Docker. Vous pouvez accéder aux utilitaires de ligne de commande Docker en vous connectant à une instance de conteneur à l'aide de SSH.
Les codes de sortie fournis par les conteneurs Docker peuvent également offrir des informations de diagnostic (par exemple, le code de sortie 137 signifie que le conteneur a reçu un signal `SIGKILL`). Pour plus d'informations, consultez la rubrique [Exit Status](https://docs.docker.com/reference/cli/docker/container/run/#exit-status) de la documentation Docker.
## Recensement des conteneurs Docker dans Amazon ECS
Vous pouvez utiliser la commande **docker ps** de votre instance de conteneur pour dresser la liste des conteneurs en cours d'exécution. Dans l’exemple suivant, seul l’agent de conteneur Amazon ECS est en cours d’exécution. Pour plus d'informations, consultez la rubrique [docker ps](https://docs.docker.com/reference/cli/docker/#ps) de la documentation Docker.
```
docker ps
```
Sortie :
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
cee0d6986de0 amazon/amazon-ecs-agent:latest "/agent" 22 hours ago Up 22 hours 127.0.0.1:51678->51678/tcp ecs-agent
```
Vous pouvez utiliser la commande **docker ps -a** pour afficher tous les conteneurs (même ceux qui ont été arrêtés ou supprimés). Cela peut s'avérer utile pour répertorier les conteneurs qui s'arrêtent inopinément. Dans l'exemple suivant, le conteneur `f7f1f8a7a245` a disparu il y a 9 secondes. Il n'est donc pas visible dans une sortie **docker ps** sans l'indicateur `-a`.
```
docker ps -a
```
Sortie :
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
db4d48e411b1 amazon/ecs-emptyvolume-base:autogenerated "not-applicable" 19 seconds ago ecs-console-sample-app-static-6-internalecs-emptyvolume-source-c09288a6b0cba8a53700
f7f1f8a7a245 busybox:buildroot-2014.02 "\"sh -c '/bin/sh -c 22 hours ago Exited (137) 9 seconds ago ecs-console-sample-app-static-6-busybox-ce83ce978a87a890ab01
189a8ff4b5f0 httpd:2 "httpd-foreground" 22 hours ago Exited (137) 40 seconds ago ecs-console-sample-app-static-6-simple-app-86caf9bcabe3e9c61600
0c7dca9321e3 amazon/ecs-emptyvolume-base:autogenerated "not-applicable" 22 hours ago ecs-console-sample-app-static-6-internalecs-emptyvolume-source-90fefaa68498a8a80700
cee0d6986de0 amazon/amazon-ecs-agent:latest "/agent" 22 hours ago Up 22 hours 127.0.0.1:51678->51678/tcp ecs-agent
```
## Affichage des journaux Docker dans Amazon ECS
Vous pouvez consulter les flux `STDOUT` et `STDERR` d'un conteneur avec la commande **docker logs**. Dans cet exemple, les journaux sont affichés pour le *dc7240fe892a* conteneur et transmis via la **head** commande par souci de concision. Pour plus d'informations, consultez [docker logs](https://docs.docker.com/reference/cli/docker/#logs) dans la documentation Docker.
**Note**
Les journaux Docker ne sont disponibles que sur l'instance de conteneur si vous utilisez le pilote de journal `json` par défaut. Si vous avez configuré vos tâches pour utiliser le pilote de `awslogs` journal, les journaux de vos conteneurs sont disponibles dans CloudWatch Logs. Pour de plus amples informations, veuillez consulter [Envoyez les journaux Amazon ECS à CloudWatch](using_awslogs.md).
```
docker logs dc7240fe892a | head
```
Sortie :
```
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.11. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.11. Set the 'ServerName' directive globally to suppress this message
[Thu Apr 23 19:48:36.956682 2015] [mpm_event:notice] [pid 1:tid 140327115417472] AH00489: Apache/2.4.12 (Unix) configured -- resuming normal operations
[Thu Apr 23 19:48:36.956827 2015] [core:notice] [pid 1:tid 140327115417472] AH00094: Command line: 'httpd -D FOREGROUND'
10.0.1.86 - - [23/Apr/2015:19:48:59 +0000] "GET / HTTP/1.1" 200 348
10.0.0.154 - - [23/Apr/2015:19:48:59 +0000] "GET / HTTP/1.1" 200 348
10.0.1.86 - - [23/Apr/2015:19:49:28 +0000] "GET / HTTP/1.1" 200 348
10.0.0.154 - - [23/Apr/2015:19:49:29 +0000] "GET / HTTP/1.1" 200 348
10.0.1.86 - - [23/Apr/2015:19:49:50 +0000] "-" 408 -
10.0.0.154 - - [23/Apr/2015:19:49:50 +0000] "-" 408 -
10.0.1.86 - - [23/Apr/2015:19:49:58 +0000] "GET / HTTP/1.1" 200 348
10.0.0.154 - - [23/Apr/2015:19:49:59 +0000] "GET / HTTP/1.1" 200 348
10.0.1.86 - - [23/Apr/2015:19:50:28 +0000] "GET / HTTP/1.1" 200 348
10.0.0.154 - - [23/Apr/2015:19:50:29 +0000] "GET / HTTP/1.1" 200 348
time="2015-04-23T20:11:20Z" level="fatal" msg="write /dev/stdout: broken pipe"
```
## Inspection des conteneurs Docker dans Amazon ECS
Si vous avez l'ID Docker d'un conteneur, vous pouvez l'examiner avec la commande **docker inspect**. L'inspection des conteneurs offre la vue la plus détaillée de l'environnement dans lequel un conteneur a été lancé. Pour plus d'informations, consultez la rubrique [docker inspect](https://docs.docker.com/reference/cli/docker/#inspect) de la documentation Docker.
```
docker inspect dc7240fe892a
```
Sortie :
```
[{
"AppArmorProfile": "",
"Args": [],
"Config": {
"AttachStderr": false,
"AttachStdin": false,
"AttachStdout": false,
"Cmd": [
"httpd-foreground"
],
"CpuShares": 10,
"Cpuset": "",
"Domainname": "",
"Entrypoint": null,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/apache2/bin",
"HTTPD_PREFIX=/usr/local/apache2",
"HTTPD_VERSION=2.4.12",
"HTTPD_BZ2_URL=https://www.apache.org/dist/httpd/httpd-2.4.12.tar.bz2"
],
"ExposedPorts": {
"80/tcp": {}
},
"Hostname": "dc7240fe892a",
...
```
# Configuration de la sortie détaillée du démon Docker dans Amazon ECS
Si vous rencontrez des difficultés avec des conteneurs ou des images Docker, vous pouvez activer le mode de débogage sur votre démon Docker. L’utilisation du débogage fournit une sortie plus détaillée du démon. Vous pouvez l’utiliser pour récupérer les messages d’erreur envoyés depuis des registres de conteneurs, tels qu’Amazon ECR.
**Important**
Cette procédure a été écrite pour l'AMI Amazon Linux optimisée pour Amazon ECS. Pour les autres systèmes d’exploitation, consultez les sections [Activation du débogage](https://docs.docker.com/engine/admin/#enable-debugging) et [Contrôle et configuration de Docker avec systemd]() dans la documentation Docker.
**Pour activer le démon Docker en mode débogage sur l’AMI Amazon Linux optimisée pour Amazon ECS**
1. Connectez-vous à votre instance de conteneur.
1. Ouvrez le fichier d'options Docker dans un éditeur de texte, tel que **vi**. Pour l'AMI Amazon Linux optimisée pour Amazon ECS, le fichier d'options Docker se trouve sous `/etc/sysconfig/docker`.
1. Recherchez l'instruction d'options Docker, puis ajoutez l'option `-D` à la chaîne, à l'intérieur des guillemets.
**Note**
Si l'instruction d'options Docker commence par le signe `#`, supprimez ce caractère pour supprimer la mise en commentaire de l'instruction et activer les options.
Pour l'AMI optimisée pour Amazon ECS, l'instruction d'options Docker s'appelle `OPTIONS`. Par exemple :
```
# Additional startup options for the Docker daemon, for example:
# OPTIONS="--ip-forward=true --iptables=true"
# By default we limit the number of open files per container
OPTIONS="-D --default-ulimit nofile=1024:4096"
```
1. Enregistrez le fichier et quittez votre éditeur de texte.
1. Redémarrez le démon Docker.
```
sudo service docker restart
```
La sortie est la suivante :
```
Stopping docker: [ OK ]
Starting docker: . [ OK ]
```
1. Redémarrez l'agent Amazon ECS.
```
sudo service ecs restart
```
Vos journaux Docker doivent désormais présenter des informations plus détaillées.
```
time="2015-12-30T21:48:21.907640838Z" level=debug msg="Unexpected response from server: \"{\\\"errors\\\":[{\\\"code\\\":\\\"DENIED\\\",\\\"message\\\":\\\"User: arn:aws:sts::1111:assumed-role/ecrReadOnly/i-abcdefg is not authorized to perform: ecr:InitiateLayerUpload on resource: arn:aws:ecr:us-east-1:1111:repository/nginx_test\\\"}]}\\n\" http.Header{\"Connection\":[]string{\"keep-alive\"}, \"Content-Type\":[]string{\"application/json; charset=utf-8\"}, \"Date\":[]string{\"Wed, 30 Dec 2015 21:48:21 GMT\"}, \"Docker-Distribution-Api-Version\":[]string{\"registry/2.0\"}, \"Content-Length\":[]string{\"235\"}}"
```
# Résolution des problèmes liés à `API error (500): devmapper` de Docker dans Amazon ECS
L'erreur Docker suivante indique que le stockage par groupe mince sur votre instance de conteneur est saturé et que le démon Docker ne peut pas créer de nouveaux conteneurs :
```
CannotCreateContainerError: API error (500): devmapper: Thin Pool has 4350 free data blocks which is less than minimum required 4454 free data blocks. Create more free space in thin pool or use dm.min_free_space option to change behavior
```
Par défaut, Amazon Linux optimisé pour Amazon ECS, AMIs à partir des versions `2015.09.d` et versions ultérieures, est lancé avec un volume de 8 Go pour le système d'exploitation connecté `/dev/xvda` et monté en tant que racine du système de fichiers. Un volume supplémentaire de 22 Gio est attaché à `/dev/xvdcz`, qui est utilisé par Docker pour le stockage des métadonnées et des images. Si cet espace de stockage est saturé, le démon Docker ne peut pas créer de nouveaux conteneurs.
La manière la plus simple d'ajouter du stockage à vos instances de conteneur est de résilier les instances existantes et d'en lancer de nouvelles avec de plus grands volumes de stockage de données. Toutefois, si vous ne pouvez pas procéder de cette façon, vous pouvez ajouter du stockage au groupe de volumes utilisé par Docker et étendre son volume logique en suivant les procédures indiquées dans [Linux optimisé pour Amazon ECS AMIs](ecs-optimized_AMI.md).
Si votre stockage d'instance de conteneur se remplit trop vite, vous pouvez limiter cela de la façon suivante :
+ Pour afficher les informations par groupe mince, exécutez la commande suivante sur votre instance de conteneur :
```
docker info
```
+ (Agent de conteneur Amazon ECS 1.8.0 et version ultérieure) Vous pouvez réduire la durée pendant laquelle les conteneurs arrêtés ou fermés restent sur vos instances de conteneur. La variable de configuration de l'agent `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION` définit la durée d'attente entre l'arrêt d'une tâche et la suppression du conteneur Docker (par défaut, cette valeur est de 3 heures). Cette opération supprime les données du conteneur Docker. Si la valeur est trop basse, il est possible que vous ne puissiez pas examiner les conteneurs arrêtés ou afficher les journaux avant leur suppression. Pour de plus amples informations, veuillez consulter [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md).
+ Vous pouvez supprimer les conteneurs qui ne sont pas en cours d’exécution et les images inutilisées de vos instances de conteneurs. Vous pouvez utiliser les exemples de commande suivants pour supprimer manuellement les conteneurs arrêtés et les images inutilisées. Les conteneurs supprimés ne peuvent pas être examinés par la suite et les images supprimées doivent être extraites à nouveau avant d'être utilisées pour lancer de nouveaux conteneurs.
Pour supprimer les conteneurs qui ne sont pas en cours d'exécution, exécutez la commande suivante sur votre instance de conteneur :
```
docker rm $(docker ps -aq)
```
Pour supprimer les images non utilisées, exécutez la commande suivante sur votre instance de conteneur :
```
docker rmi $(docker images -q)
```
+ Vous pouvez supprimer les blocs de données inutilisés dans les conteneurs. Vous pouvez utiliser la commande suivante pour exécuter **fstrim** sur un conteneur en cours d'exécution et ignorer les blocs de données inutilisés par le système de fichiers du conteneur.
```
sudo sh -c "docker ps -q | xargs docker inspect --format='{{ .State.Pid }}' | xargs -IZ fstrim /proc/Z/root/"
```
# Résolution des problèmes liés à Amazon ECS Exec
Voici des notes de résolution pour vous aider à diagnostiquer d'où viennent les erreurs lorsque vous utilisez ECS Exec.
## Vérification à l’aide d’Exec Checker
Le script ECS Exec Checker permet de vérifier que votre cluster et votre tâche Amazon ECS satisfont aux conditions préalables à l’utilisation de la fonctionnalité ECS Exec. Le script ECS Exec Checker vérifie à la fois votre AWS CLI environnement et votre cluster et vérifie que les tâches sont prêtes pour ECS Exec, en appelant divers APIs en votre nom. L'outil nécessite la dernière version du AWS CLI et doit être `jq` disponible. Pour plus d'informations, consultez [ECS Exec Checker activé](https://github.com/aws-containers/amazon-ecs-exec-checker). GitHub
## Erreur lors de l'appel à `execute-command`
Si une erreur `The execute command failed` se produit, les éléments suivants peuvent en être à l'origine.
+ La tâche ne dispose pas des autorisations requises. Vérifiez que la définition de tâche utilisée pour lancer votre tâche a un rôle IAM de tâche défini et que le rôle dispose des autorisations requises. Pour de plus amples informations, veuillez consulter [Autorisations ECS Exec](task-iam-roles.md#ecs-exec-required-iam-permissions).
+ L’agent SSM n’est ni installé ni en cours d’exécution.
+ Il existe un point de terminaison Amazon VPC d’interface pour Amazon ECS, mais il n’y en a pas pour le gestionnaire de session Systems Manager.
# Résolution des problèmes liés à Amazon ECS Anywhere
Amazon ECS Anywhere fournit une assistance pour l’enregistrement d’une *instance externe*, telle qu’un serveur sur site ou une machine virtuelle (VM), sur votre cluster Amazon ECS. Voici les problèmes courants que vous pouvez rencontrer et les recommandations générales pour leur résolution.
**Topics**
+ [Problèmes d'enregistrement d'instance externe](#ecs-anywhere-troubleshooting-registration)
+ [Problèmes de réseau d'instance externe](#ecs-anywhere-troubleshooting-networking)
+ [Problèmes d'exécution de tâches sur votre instance externe](#ecs-anywhere-troubleshooting-runtask)
## Problèmes d'enregistrement d'instance externe
Lorsque vous enregistrez une instance externe auprès de votre cluster Amazon ECS, les conditions suivantes doivent être remplies :
+ Une AWS Systems Manager activation, qui consiste en un *ID d'activation* et un *code d'activation*, doit être récupérée. Vous l'utilisez pour enregistrer l'instance externe en tant qu'instance gérée par Systems Manager. Lorsqu’une activation de Systems Manager est demandée, spécifiez une limite d’enregistrement et une date d’expiration. La limite d'enregistrement spécifie le nombre maximal d'instances qui peuvent être enregistrées à l'aide de l'activation. La valeur par défaut pour la limite d’enregistrement est de `1` instance. La date d'expiration spécifie la date à laquelle l'activation expire. La valeur par défaut est 24 heures. Si l'activation de Systems Manager que vous utilisez pour enregistrer votre instance externe n'est pas valide, demandez-en une nouvelle. Pour de plus amples informations, veuillez consulter [Enregistrement d’une instance externe dans un cluster Amazon ECS](ecs-anywhere-registration.md).
+ Une politique IAM est utilisée pour fournir à votre instance externe les autorisations dont elle a besoin pour communiquer avec les opérations AWS d'API. Si cette stratégie gérée n'est pas créée correctement et ne contient pas les autorisations requises, l'enregistrement d'instance externe échoue. Pour de plus amples informations, veuillez consulter [Rôle IAM Amazon ECS Anywhere](iam-role-ecsanywhere.md).
+ Amazon ECS fournit un script d'installation qui installe Docker, l'agent de conteneur Amazon ECS et le Systems Manager Agent sur votre instance externe. Si le script d'installation échoue, il est probable qu'il ne puisse plus être exécuté sur la même instance sans qu'une erreur ne se produise. Dans ce cas, suivez le processus de nettoyage pour effacer les AWS ressources de l'instance afin de pouvoir réexécuter le script d'installation. Pour de plus amples informations, veuillez consulter [Annulation de l’enregistrement d’une instance externe Amazon ECS](ecs-anywhere-deregistration.md).
**Note**
Sachez que si le script d'installation a demandé et utilisé avec succès l'activation de Systems Manager, toute autre exécution du script d'installation utilise à nouveau l'activation de Systems Manager. Cela peut à son tour vous amener à atteindre la limite d'enregistrement pour cette activation. Si cette limite est atteinte, vous devez recréer une activation.
+ Lorsque vous exécutez le script d’installation sur une instance externe pour des charges de travail GPU, si le pilote NVIDIA n’est pas détecté ou configuré correctement, une erreur se produit. Le script d'installation utilise la commande `nvidia-smi` pour confirmer l'existence du pilote NVIDIA.
## Problèmes de réseau d'instance externe
Pour communiquer toute modification, votre instance externe nécessite une connexion réseau à AWS. Si votre instance externe perd sa connexion réseau AWS, les tâches exécutées sur vos instances continuent de s'exécuter de toute façon, sauf si elles sont arrêtées manuellement. Une fois la connexion rétablie, les AWS informations d'identification utilisées par l'agent de conteneur Amazon ECS et l'agent Systems Manager sur l'instance externe sont renouvelées automatiquement. AWS Pour plus d'informations sur les AWS domaines utilisés pour la communication entre votre instance externe et AWS, consultez[Réseaux](ecs-anywhere.md#ecs-anywhere-networking).
## Problèmes d'exécution de tâches sur votre instance externe
Si vos tâches ou conteneurs ne parviennent pas à s'exécuter sur votre instance externe, cela est généralement dû au réseau ou aux autorisations. Si vos conteneurs extraient leurs images d'Amazon ECR ou sont configurés pour envoyer des journaux de conteneurs à Logs, votre définition de tâche doit spécifier un rôle IAM d'exécution de tâche valide. CloudWatch Sans un rôle IAM d'exécution de tâche valide, vos conteneurs ne démarrent pas. Pour en savoir plus sur les problèmes liés au réseau, consultez [Problèmes de réseau d'instance externe](#ecs-anywhere-troubleshooting-networking).
**Important**
Amazon ECS fournit l'outil de collecte des journaux Amazon ECS. Vous pouvez l'utiliser pour collecter des journaux de vos instances externes à des fins de dépannage. Pour de plus amples informations, veuillez consulter [Collecte des journaux de conteneur avec collecteur de journaux Amazon ECS](ecs-logs-collector.md).
# Résolution des problèmes de chargement des classes Java sur Fargate
Les applications Java exécutées sur Fargate peuvent rencontrer des problèmes de chargement de classes après les mises à jour de la plateforme, en particulier lorsque l’application utilise un comportement de chargement de classe non déterministe. Cela peut se manifester par des erreurs d’injection de dépendances, des échecs de Spring Boot ou d’autres exceptions d’exécution qui n’étaient pas présentes dans les déploiements précédents.
## Symptômes
Vous pourriez observer les symptômes suivants :
+ Erreurs d’injection de dépendance avec Spring Boot
+ ClassNotFoundException ou NoClassDefFoundError exceptions
+ Les applications qui fonctionnaient auparavant sur Fargate échouent désormais par intermittence
+ La même image de conteneur fonctionne sur Amazon EC2, mais échoue sur Fargate
+ Comportement incohérent entre les déploiements avec des images de conteneur identiques
## Causes
Ces problèmes se produisent généralement pour les raisons suivantes :
+ **Chargement de classes non déterministe :** les applications Java qui dépendent de l’ordre dans lequel les classes sont chargées à partir des fichiers JAR peuvent échouer lorsque la plateforme sous-jacente modifie le mode d’accès ou de mise en cache des fichiers.
+ **Mises à jour de la plateforme :** les mises à jour de la version de plateforme Fargate peuvent modifier le comportement du système de fichiers sous-jacent, affectant ainsi l’ordre dans lequel les classes sont découvertes et chargées.
+ **Dépendances relatives à l’ordre des fichiers JAR :** applications qui s’appuient implicitement sur des séquences de chargement JAR spécifiques sans gestion explicite des dépendances.
## Résolution
Pour résoudre les problèmes de chargement de classes Java sur Fargate, implémentez des pratiques de chargement de classes déterministes :
### Correction immédiate
Si vous avez besoin d’une solution immédiate :
1. **Imposition de l’ordre de chargement des fichiers JAR :** spécifiez explicitement l’ordre dans lequel les fichiers JAR doivent être chargés dans la configuration du chemin de classe de votre application.
1. **Utilisation d’une gestion explicite des dépendances :** assurez-vous que toutes les dépendances sont explicitement déclarées dans votre configuration de build (Maven, Gradle, etc.) plutôt que de vous fier à des dépendances transitives.
### Pratiques exemplaires à long terme
Mettez en œuvre les pratiques suivantes pour éviter les futurs problèmes de chargement des classes :
1. **Application d’un chargement des classes déterministe :**
+ Utilisez des déclarations de dépendance explicites dans vos fichiers de construction
+ Évitez de vous fier à l’ordre d’analyse des chemins de classe
+ Utiliser des outils de gestion des dépendances pour résoudre les conflits de versions
+ Utilisez les options de la machine virtuelle Java (JVM), par exemple `-verbose:class` pour obtenir des informations sur les classes chargées par la machine virtuelle Java.
1. **Applications Spring Boot :**
+ Utilisation `@ComponentScan` avec des packages de base explicites
+ Évitez les conflits de configuration automatique en configurant explicitement les beans
+ Utiliser des annotations `@DependsOn` pour contrôler l’ordre d’initialisation des beans
1. **Configuration de compilation :**
+ Utiliser les sections de gestion des dépendances dans Maven ou Gradle
+ Exclure les dépendances transitives qui provoquent des conflits
+ Utilisez des outils tels que le plug-in Maven Enforcer pour détecter les problèmes de dépendance
1. **Test :**
+ Testez votre application avec différentes implémentations de JVM
+ Exécutez des tests d’intégration qui simulent différents environnements de déploiement
+ Utiliser des outils pour analyser les conflits de chemins de classe pendant le développement
## Prévention
Pour éviter les problèmes de chargement des classes Java lors de futurs déploiements, procédez comme suit :
+ **Suivez les pratiques déterministes de chargement des classes :** concevez votre application de manière à ce qu’elle ne dépende pas de l’ordre dans lequel les classes sont chargées à partir du chemin de classe.
+ **Utilisez une gestion explicite des dépendances :** déclarez toujours explicitement toutes les dépendances requises et leurs versions dans votre configuration de compilation.
+ **Testez plusieurs environnements :** testez régulièrement vos applications dans différents environnements et versions de plateforme afin d’identifier rapidement les problèmes potentiels.
+ **Surveillez les mises à jour de la plateforme :** restez informé des mises à jour de la plateforme Fargate et testez vos applications avec les nouvelles versions de la plateforme avant qu’elles n’affectent les charges de travail de production.
# AWS Fargate limitation des quotas
AWS Fargate limite les taux de lancement des tâches Amazon ECS et des pods Amazon EKS à des quotas (anciennement appelés limites) à l'aide d'un [algorithme de bucket à jetons](https://en.wikipedia.org/wiki/Token_bucket) pour chaque AWS compte, région par région. Avec cet algorithme, votre compte dispose d'un compartiment contenant un nombre spécifique de jetons. Le nombre de jetons dans le compartiment représente votre quota de taux à une seconde donnée. Chaque compte client dispose d'un compartiment de jetons de tâches et de pods qui s'épuise en fonction du nombre de tâches et de pods lancés par le compte client. Ce compartiment de jetons affiche un maximum de compartiment qui vous permet d'effectuer périodiquement un nombre plus élevé de demandes, et un taux de recharge qui vous permet de maintenir un taux de demande stable aussi longtemps que nécessaire.
Par exemple, la taille du compartiment de jetons de tâches et de pods pour un compte client Fargate est de 100 jetons et le taux de recharge est de 20 jetons par seconde. Par conséquent, vous pouvez lancer immédiatement jusqu'à 100 tâches Amazon ECS et pods Amazon EKS par compte client, avec un taux de lancement soutenu de 20 tâches Amazon ECS et pods Amazon EKS par seconde.
| Actions | Capacité maximale du compartiment (ou taux en rafale) | Taux de recharge du compartiment (ou taux soutenu) |
| --- | --- | --- |
| Quota de taux de ressources Fargate pour les tâches Amazon ECS à la demande et les pods Amazon EKS[1](#fargate-throttling-note-1) | 100 | 20 |
| Quota de taux de ressources Fargate pour les tâches Spot Amazon ECS | 100 | 20 |
1Les comptes qui lancent uniquement des pods Amazon EKS ont un taux en rafale de 20 avec un taux de lancement soutenu de 20 pods par seconde lors de l'utilisation des versions de plateforme décrites dans les [Versions de la plateforme Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html).
## Limitation de l’API `RunTask` dans Fargate
En outre, Fargate limite le taux de requêtes lors du lancement de tâches à l'aide de l'API `RunTask` d'Amazon ECS à l'aide d'un quota distinct. Fargate limite les demandes d'API `RunTask` Amazon ECS AWS pour chaque compte par région. Chaque requête que vous effectuez supprime un jeton du compartiment. Le but est de favoriser la performance du service et d'assurer une utilisation équitable pour tous les clients Fargate. Les appels d'API sont soumis aux quotas de requêtes, qu'ils proviennent de la console Amazon Elastic Container Service, d'un outil de ligne de commande ou d'une application tierce. Le quota de taux pour les appels à l'API `RunTask` d'Amazon ECS est de 20 appels par seconde (rafale et soutenu). Chaque appel à cette API peut cependant lancer jusqu'à 10 tâches. Cela signifie que vous pouvez lancer 100 tâches en une seconde en effectuant 10 appels à cette API, demandant que 10 tâches soient lancées dans chaque appel. De même, vous pouvez également effectuer 20 appels à cette API, demandant que 5 tâches soient lancées dans chaque appel. Pour plus d’informations sur la limitation d’API pour l’API `RunTask` d’Amazon ECS, consultez la section [Limitation des requêtes d’API](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/request-throttling.html) dans la Référence de l’API Amazon ECS.
Dans la pratique, les taux de lancement des tâches et des pods dépendent également d'autres considérations telles que les images de conteneur à télécharger et à décompresser, les surveillances de l'état et d'autres intégrations activées, telles que l'enregistrement des tâches ou des pods auprès d'un équilibreur de charge. Les clients constatent des variations dans les taux de lancement des tâches et des pods par rapport aux quotas indiqués précédemment, en fonction des fonctionnalités qu’ils activent.
## Ajustement des quotas de taux dans Fargate
Vous pouvez demander une augmentation des quotas de limitation de taux pour votre compte AWS . Pour plus d'informations, consultez [Demande d'augmentation de quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) dans le *Guide de l'utilisateur Service Quotas *.
# Résolution des problèmes liés aux instances gérées Amazon ECS
Utilisez les procédures suivantes pour résoudre les problèmes liés aux instances gérées Amazon ECS, notamment les problèmes courants, les techniques de diagnostic et les étapes de résolution.
## Conditions préalables
Avant de dépanner les instances gérées Amazon ECS, assurez-vous de respecter les exigences suivantes.
+ AWS CLI est installé et configuré avec les autorisations appropriées
Pour plus d’informations, consultez la section [Installation ou mise à jour vers la version la plus récente de l’ AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) dans le *Guide de l’utilisateur AWS Command Line Interface *.
+ Accès à un cluster avec le fournisseur de capacité Amazon ECS Managed Instances. Pour de plus amples informations, veuillez consulter [Création d’un cluster pour les instances gérées Amazon ECS](create-cluster-managed-instances.md).
## Scénarios courants de résolution des problèmes
### Afficher les journaux des agents de conteneur Amazon ECS Managed Instances
Vous pouvez consulter ces fichiers journaux Amazon ECS dans les instances gérées Amazon ECS en vous connectant à un conteneur privilégié exécuté dans l'instance.
#### Étapes de diagnostic
**Déployez un conteneur de débogage doté de privilèges et de fonctionnalités Linux en tant que tâche Amazon ECS :**
Définissez les variables d'environnement suivantes.
Remplacez le *user-input* par vos valeurs.
```
export ECS_CLUSTER_NAME="your-cluster-name"
export AWS_REGION="your-region"
export ACCOUNT_ID="your-account-id"
```
Créez une définition de tâche à l'aide d'un fichier JSON CLI appelé`node-debugger.json`.
```
cat << EOF > node-debugger.json
{
"family": "node-debugger",
"taskRoleArn": "arn:aws:iam::${ACCOUNT_ID}:role/ecsTaskExecutionRole",
"executionRoleArn": "arn:aws:iam::${ACCOUNT_ID}:role/ecsTaskExecutionRole",
"cpu": "256",
"memory": "1024",
"networkMode": "host",
"pidMode": "host",
"requiresCompatibilities": ["MANAGED_INSTANCES", "EC2"],
"containerDefinitions": [
{
"name": "node-debugger",
"image": "public.ecr.aws/amazonlinux/amazonlinux:2023",
"essential": true,
"privileged": true,
"command": ["sleep", "infinity"],
"healthCheck": {
"command": ["CMD-SHELL", "echo debugger || exit 1"],
"interval": 30,
"retries": 3,
"timeout": 5
},
"linuxParameters": {
"initProcessEnabled": true
},
"mountPoints": [
{
"sourceVolume": "host-root",
"containerPath": "/host",
"readOnly": false
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/aws/ecs/node-debugger",
"awslogs-create-group": "true",
"awslogs-region": "${AWS_REGION}",
"awslogs-stream-prefix": "ecs"
}
}
}
],
"volumes": [
{
"name": "host-root",
"host": {
"sourcePath": "/"
}
}
]
}
EOF
```
Enregistrez-vous, puis exécutez la tâche. Exécutez les commandes suivantes.
```
aws ecs register-task-definition --cli-input-json file://node-debugger.json
TASK_ARN=$(aws ecs run-task \
--cluster $ECS_CLUSTER_NAME \
--task-definition node-debugger \
--enable-execute-command \
--capacity-provider-strategy capacityProvider=managed-instances-default,weight=1 \
--query 'tasks[0].taskArn' --output text)
# Wait for task to be running
aws ecs wait tasks-running --cluster $ECS_CLUSTER_NAME --tasks $TASK_ARN
```
Connect au conteneur. Exécutez la commande suivante.
```
aws ecs execute-command \
--cluster $ECS_CLUSTER_NAME \
--task $TASK_ARN \
--container node-debugger \
--interactive \
--command "/bin/sh"
```
**Consultez les journaux de l'agent Amazon ECS :**
Dans la session interactive du conteneur, exécutez les commandes suivantes :
```
# Install required tools
yum install -y util-linux-core
# View ECS agent logs
nsenter -t 1 -m -p cat /var/log/ecs/ecs-agent.log | tail -50
# Check agent registration
nsenter -t 1 -m -p grep "Registered container instance" /var/log/ecs/ecs-agent.log
Example Output:
{"level":"info","time":"2025-10-16T12:39:37.665","msg":"Registered container instance with cluster!"}
# Verify capabilities
nsenter -t 1 -m -p grep "Response contained expected value for attribute" /var/log/ecs/ecs-agent.log
```
**Vérifiez les statistiques des agents :**
Exécutez la commande suivante pour afficher les journaux.
```
# View metrics logs
nsenter -t 1 -m -p cat /var/log/ecs/metrics.log | tail -20
```
### Problèmes liés au placement des tâches
Les symptômes des problèmes de placement des tâches sont les suivants :
+ Tâches bloquées dans l'état EN ATTENTE
+ Les tâches ne démarrent pas sur les instances gérées Amazon ECS
+ Erreurs liées à l'insuffisance des ressources
#### Étapes de diagnostic
Exécutez les commandes suivantes pour diagnostiquer les problèmes de placement des tâches et recueillir des informations sur la capacité du cluster, les instances de conteneur et les services système :
```
# Check cluster capacity
aws ecs describe-clusters --clusters cluster-name --include STATISTICS
# Check cluster capacity providers
aws ecs describe-clusters --clusters cluster-name --include STATISTICS --query 'clusters[].capacityProviders'
# List container instances
aws ecs list-container-instances --cluster cluster-name
# Check container instance details
aws ecs describe-container-instances --cluster cluster-name --container-instances container-instance-arn
# Check container instance remaining resources CPU/Mem
aws ecs describe-container-instances --cluster $ECS_CLUSTER_NAME --container-instances container-instance-arn --query 'containerInstances[].remainingResources'
# Check container instance Security Group
aws ecs describe-container-instances --cluster $ECS_CLUSTER_NAME --container-instances container-instance-arn --query 'containerInstances[].ec2InstanceId' --output text
aws ec2 describe-instances --instance-ids instance-id --query 'Reservations[0].Instances[0].SecurityGroups'
aws ec2 describe-security-groups --group-ids security-group-id
```
**Surveillance des services du système :**
```
# Check Containerd status
nsenter -t 1 -m -p systemctl status containerd.service
# Check Amazon ECS container agent status
nsenter -t 1 -m -p systemctl status ecs
```
#### Résolution
Pour résoudre les problèmes de placement des tâches, procédez comme suit afin de garantir une configuration et une capacité appropriées :
+ Vérifier les besoins en ressources des tâches par rapport à la capacité disponible
+ Vérifiez les contraintes et les stratégies de placement
+ Assurez-vous que le fournisseur de capacité des instances gérées Amazon ECS est configuré
+ Assurez-vous que le groupe de sécurité de la tâche et de l'instance de conteneur dispose d'une règle sortante qui autorise le trafic vers les points de terminaison de gestion des agents Amazon ECS
### Problèmes de mise en réseau
Les symptômes des problèmes de réseau sont les suivants :
+ Les tâches ne peuvent pas atteindre les services externes
+ Problèmes de résolution DNS
#### Étapes de diagnostic
**Tests de connectivité réseau :**
À partir du conteneur de débogage, exécutez les commandes suivantes :
**Note**
Vérifiez que le groupe de sécurité attaché à votre fournisseur de capacité ou à votre tâche Amazon ECS autorise le trafic.
```
# Install DNS Utility
yum install bind-utils -y
# Test DNS resolution
nslookup amazon.com
# Test external connectivity
curl -I https://amazon.com
```
### Contraintes liées aux ressources
Les symptômes des problèmes de réseau sont les suivants :
+ Tâches supprimées en raison de limites de mémoire
+ Régulation du processeur
+ Problèmes d'espace disque
#### Étapes de diagnostic
Exécutez des commandes pour surveiller les ressources et les limites des conteneurs.
**Surveillance des ressources :**
```
# Check memory usage
nsenter -t 1 -m -p free -h
# Check disk usage
nsenter -t 1 -m -p lsblk
# Check disk usage
nsenter -t 1 -m -p df -h
```
**Limites de conteneurs :**
```
# Check OOM kills
nsenter -t 1 -m -p dmesg | grep -i "killed process"
```
### Problème de déconnexion de l'agent d'instance de conteneur
Les symptômes des problèmes de déconnexion de l'agent d'instance de conteneur sont les suivants :
+ Instances de conteneur affichées comme étant déconnectées dans la console Amazon ECS
+ Tâches ne pouvant pas être attribuées à des instances spécifiques
+ Défaillances d'enregistrement de l'agent dans les journaux
#### Étapes de diagnostic
Si une tâche de privilège est en cours d'exécution sur l'hôte auquel ECS Exec peut accéder, exécutez les commandes suivantes pour diagnostiquer les problèmes de connectivité de l'agent :
```
# check service status
nsenter -t 1 -m -p systemctl restart ecs
nsenter -t 1 -m -p systemctl restart containerd
# restart stopped services
nsenter -t 1 -m -p systemctl restart ecs
nsenter -t 1 -m -p systemctl restart containerd
```
Sinon, désenregistrez de force les instances gérées Amazon ECS. Exécutez la commande suivante :
```
# list ECS Managed Instance container
aws ecs list-container-instances --cluster managed-instances-cluster --query 'containerInstanceArns' --output text
# deregister the specific container instance
aws ecs deregister-container-instance \
--cluster $ECS_CLUSTER_NAME \
--container-instance container-instance-arn \
--force
```
#### Résolution
Pour résoudre les problèmes de déconnexion de l'agent, procédez comme suit :
+ Vérifier les autorisations du rôle IAM pour l'instance de conteneur
+ Vérifiez que les règles du groupe de sécurité autorisent le trafic HTTPS sortant vers les points de terminaison ECS
+ Garantir la connectivité réseau aux AWS services
+ Redémarrez le service de l'agent ECS si nécessaire : `nsenter -t 1 -m -p systemctl restart ecs`
+ Vérifiez que la configuration ECS\$1CLUSTER dans/etc/ecs/ecs.config correspond au nom de votre cluster
## Analyse des journaux dans les instances gérées Amazon ECS
### Journaux du système
Utilisez les commandes suivantes pour examiner les journaux système et identifier les problèmes potentiels liés à l'instance gérée :
```
# Check system messages
nsenter -t 1 -m -p journalctl --no-pager -n 50
# Check kernel logs
nsenter -t 1 -m -p dmesg | tail -20
# Check for disk space errors
nsenter -t 1 -m -p journalctl --no-pager | grep -i "no space\|disk full\|enospc"
```
## Utilisez l'EC2 AWS CLI pour obtenir la sortie de console à partir d'une instance gérée Amazon ECS
Utilisez l'ID d'instance Amazon EC2 pour récupérer la sortie de la console.
Remplacez le *user-input* par vos valeurs.
```
aws ec2 get-console-output --instance-id instance-id --latest --output text
```
## Nettoyage
Exécutez ce qui suit pour arrêter la tâche de débogage et annuler l'enregistrement de la définition de tâche.
```
# Stop debug task
aws ecs stop-task --cluster $ECS_CLUSTER_NAME --task $TASK_ARN
# Deregister task definition (optional)
aws ecs deregister-task-definition --task-definition node-debugger
```
## Ressources supplémentaires
Pour plus d'informations sur le dépannage des instances gérées Amazon ECS, consultez les ressources suivantes :
+ [Résolution des erreurs liées aux instances gérées Amazon ECS](managed-instances-errors.md)
+ [Dépannage d'Amazon ECS](troubleshooting.md)
+ [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md)
+ [Surveillance des conteneurs Amazon ECS avec ECS Exec](ecs-exec.md)
# Résolution des problèmes liés aux instances gérées Amazon ECS
Lors du lancement de tâches avec des instances gérées Amazon ECS, Amazon ECS tente d’abord de placer les tâches sur la capacité existante et demande une capacité supplémentaire pour les tâches qui ne peuvent pas être placées. Si l’allocation de l’instance échoue, l’ID de requête Amazon EC2 est inclus dans le message de défaillance de la tâche. Vous pouvez utiliser cet ID de demande pour consulter les détails de la demande ayant échoué afin CloudTrail de poursuivre le dépannage.
**Note**
Si vous choisissez d'appliquer des autorisations de moindre privilège et de spécifier vos propres autorisations pour le profil d'instance au lieu d'utiliser la politique `AmazonECSInstanceRolePolicyForManagedInstances` gérée, vous pouvez ajouter les autorisations suivantes pour aider à résoudre les problèmes liés aux tâches avec les instances gérées Amazon ECS :
`ecs:StartTelemetrySession`
`ecs:PutSystemLogEvents`
## Définition des tâches incompatible avec les instances gérées Amazon ECS
### Cause courante
Cette erreur se produit lorsque votre définition de tâche contient des paramètres ou des configurations qui ne sont pas pris en charge par les instances gérées Amazon ECS. Les incompatibilités courantes incluent des modes réseau, des rôles de tâches ou des besoins en ressources non pris en charge.
### Résolution
1. Vérifiez que votre définition de tâche utilise `requiresCompatibilities` défini sur `MANAGED_INSTANCES`.
1. Assurez-vous que votre définition de tâche utilise le mode réseau `awsvpc`.
1. Vérifiez que les valeurs d’UC et de mémoire se situent dans les plages prises en charge pour les instances gérées Amazon ECS.
1. Consultez le message d’erreur détaillé pour obtenir des informations spécifiques sur les incompatibilités.
## Fournisseur de capacité non associé au cluster
### Cause courante
Cette erreur se produit lorsque le fournisseur de capacité spécifié dans votre stratégie de fournisseur de capacité n’est pas associé au cluster ou n’existe pas.
### Résolution
1. Vérifiez que le fournisseur de capacité existe dans votre compte et dans votre région.
1. Associez le fournisseur de capacité à votre cluster à l’aide de la console ou de la CLI Amazon ECS.
1. Assurez-vous que le statut du fournisseur de capacité est `ACTIVE` avant de l’utiliser.
## Erreurs d’autorisation liées aux rôles d’infrastructure
### Cause courante
Cette erreur se produit lorsque le rôle d’infrastructure Amazon ECS ne dispose pas des autorisations nécessaires pour effectuer des opérations Amazon EC2 en votre nom, ou lorsque le rôle ne peut pas être assumé en raison de problèmes de relation de confiance.
### Résolution
1. Vérifiez que votre rôle d’infrastructure entretient une relation de confiance appropriée avec Amazon ECS.
1. Assurez-vous que le rôle dispose des autorisations Amazon EC2 requises, notamment`ec2:RunInstances`, `ec2:DescribeInstances` et. `iam:PassRole`
1. Consultez le message d'échec d'autorisation codé CloudTrail pour obtenir des détails d'autorisation spécifiques.
1. Mettez à jour la politique de rôle pour inclure les autorisations manquantes identifiées dans le message d’erreur.
## VcpuLimitExceeded erreur
### Cause courante
Cette erreur se produit lorsque vous avez atteint votre quota de service vCPU pour la famille de types d’instances dans la région actuelle. Les instances gérées Amazon ECS ne peuvent pas lancer d’instances supplémentaires tant que la capacité n’est pas disponible.
### Résolution
1. Demandez une augmentation du quota de service pour la famille de types d'instances concernée par le biais du AWS Support Center.
1. Envisagez d’utiliser différents types d’instances relevant d’une catégorie de quotas de vCPU différente.
1. Mettez fin aux instances Amazon EC2 inutilisées pour libérer de la capacité vCPU.
1. Passez en revue la configuration de votre fournisseur de capacité afin d’utiliser des types d’instances nécessitant moins de vCPU.
## InsufficientCapacity et les erreurs de capacité associées
### Cause courante
Ces erreurs se produisent lorsque la capacité AWS n'est pas suffisante pour répondre à votre demande d'instance. Cela peut inclure une capacité d’instance, une capacité d’adresse ou une capacité de volume insuffisantes dans la zone de disponibilité demandée.
### Résolution
1. Essayez de lancer des instances dans différentes zones de disponibilité en configurant plusieurs sous-réseaux dans votre fournisseur de capacité.
1. Envisagez d’utiliser différents types d’instances susceptibles de disposer d’une plus grande capacité disponible.
1. Attendez et recommencez l’opération, car la disponibilité des capacités change fréquemment.
1. Pour des besoins de capacité persistants, pensez à utiliser des instances réservées ou des Savings Plans.
## UnauthorizedOperation erreur
### Cause courante
Cette erreur se produit lorsque le service Amazon ECS ne dispose pas des autorisations nécessaires pour effectuer des opérations Amazon EC2 ou transmettre des rôles IAM. Les scénarios courants incluent des autorisations `ec2:RunInstances` manquantes ou des autorisations `iam:PassRole` pour le profil d’instance.
### Résolution
1. Vérifiez que votre rôle d’infrastructure Amazon ECS dispose des autorisations nécessaires pour lancer des instances Amazon EC2.
1. Assurez-vous que le rôle d’infrastructure dispose d’autorisations `iam:PassRole` pour le profil d’instance utilisé par vos instances gérées Amazon ECS.
1. Consultez le message d'échec d'autorisation codé CloudTrail pour obtenir des informations d'autorisation spécifiques.
1. Mettez à jour la politique de rôle pour inclure les autorisations manquantes identifiées dans le message d’erreur.
## La tâche a expiré pendant l’attente de la capacité.
### Cause courante
Cette erreur se produit lorsque le lancement et l’enregistrement des instances auprès du cluster prennent plus de temps que prévu. Cela peut être dû à des contraintes de capacité Amazon EC2, à des échecs de lancement d’instance ou à des problèmes de connectivité réseau.
### Résolution
1. Vérifiez l’état du service Amazon EC2 dans votre région pour tout problème persistant.
1. Vérifiez que vos sous-réseaux disposent de suffisamment d’adresses IP disponibles.
1. Assurez-vous que vos groupes de sécurité autorisent le trafic nécessaire à la communication avec les agents Amazon ECS.
1. Envisagez d’utiliser plusieurs zones de disponibilité pour améliorer la disponibilité des capacités.
1. Réessayez l’opération de lancement de la tâche, car les contraintes de capacité sont souvent temporaires.
## Erreurs de configuration réseau
### Cause courante
Ces erreurs se produisent lorsqu’il existe des incohérences entre les exigences réseau de votre tâche et la configuration réseau du fournisseur de capacité, telles que des incompatibilités VPC ou une configuration réseau manquante.
### Résolution
1. Vérifiez que votre fournisseur de capacité est configuré avec le VPC et les sous-réseaux appropriés.
1. Assurez-vous que les groupes de sécurité et les sous-réseaux appartiennent au même VPC.
1. Vérifiez que la configuration réseau de votre définition de tâche est compatible avec le fournisseur de capacité.
1. Mettez à jour la configuration de votre fournisseur de capacité avec les paramètres réseau appropriés.
## Le fournisseur de capacité ne peut pas être supprimé en raison d'instances bloquées
### Cause courante
Ces erreurs se produisent lorsque les instances gérées Amazon ECS sont bloquées dans un `DRAINING` état `ACTIVE` ou alors qu'aucune tâche n'est en cours d'exécution sur les instances.
### Résolution
Pour autoriser la suppression du fournisseur de capacité, vous pouvez forcer le désenregistrement des instances bloquées à l'aide de la commande suivante.
```
aws ecs deregister-container-instance \
--cluster arn:aws:ecs:us-east-1:111122223333:cluster/MyCluster \
--container-instance arn:aws:ecs:us-east-1:111122223333:container-instance/a1b2c3d4-5678-90ab-cdef-11111EXAMPLE \
--force
```
# Résolution des erreurs liées aux instances gérées Amazon ECS
Vous trouverez ci-dessous quelques messages d’erreur relatifs aux instances gérées Amazon ECS et les mesures que vous pouvez prendre pour corriger ces erreurs.
## Le fournisseur d’instances gérées Amazon ECS n’est pas pris en charge sans nom de cluster
Cette erreur se produit lorsque vous essayez de créer un fournisseur de capacité avec un paramètre de fournisseur d’instances gérées Amazon ECS, mais aucun champ de cluster.
Pour résoudre ce problème, spécifiez un nom de cluster valide lors de la création du fournisseur de capacité.
## Les informations relatives au fournisseur d’instances gérées Amazon ECS sont requises lors de la création d’un fournisseur de capacité d’instances gérées Amazon ECS.
Cette erreur apparaît lorsque vous essayez de créer un fournisseur de capacité avec le fournisseur d’instances gérées Amazon ECS, mais que vous ne fournissez pas l’objet réel.
Pour résoudre ce problème, spécifiez des informations valides sur le fournisseur d’instances gérées Amazon ECS et réessayez.
## Le fournisseur de capacité des instances gérées Amazon ECS doit spécifier un profil d’instance
Cette erreur s'affiche lorsque vous essayez de créer un fournisseur de capacité avec le fournisseur d'instances gérées Amazon ECS mais que vous ne fournissez pas l'Ec2InstanceProfile.
Pour résoudre ce problème, spécifiez un profil d’instance EC2 valide pour votre fournisseur de capacité d’instances gérées Amazon ECS. Pour de plus amples informations, veuillez consulter [Profil d’instance des instances gérées Amazon ECS](managed-instances-instance-profile.md).
## Le fournisseur de capacité des instances gérées Amazon ECS doit spécifier un InfrastructureRole
Ce message apparaît lorsque vous essayez de créer un fournisseur de capacité avec le fournisseur d'instances gérées Amazon ECS mais que vous ne fournissez pas le InfrastructureRole.
Pour corriger cela, spécifiez un rôle d’infrastructure valide pour votre fournisseur de capacité d’instances gérées Amazon ECS. Pour de plus amples informations, veuillez consulter [Rôle IAM d’infrastructure Amazon ECS](infrastructure_IAM_role.md).
## Le fournisseur de capacité des instances gérées Amazon ECS doit spécifier une configuration réseau
Cette erreur se produit lorsque vous essayez de créer un fournisseur de capacité avec le fournisseur Amazon ECS Managed Instances sans fournir de configuration réseau.
Pour résoudre ce problème, spécifiez une configuration réseau valide avec des sous-réseaux non vides pour votre fournisseur de capacité d’instances gérées Amazon ECS. Pour de plus amples informations, veuillez consulter [Mise en réseau des tâches Amazon ECS pour les instances gérées Amazon ECS](managed-instance-networking.md).
## Aucun type d’instance ne répond aux exigences d’instance spécifiées dans le fournisseur de capacité d’instances gérées Amazon ECS
Cela se produit lorsque vous essayez de créer un fournisseur de capacité avec le fournisseur d’instances gérées Amazon ECS, mais qu’aucun type d’instance EC2 ne répond aux exigences d’instance.
Pour résoudre ce problème, passez en revue et ajustez les exigences de vos instances pour qu’elles correspondent aux types d’instances EC2 disponibles.
## L’ARN du rôle d’infrastructure spécifié n’est pas valide
Cette erreur se produit lorsque le format ARN InfrastructureRole n'est pas respecté.
Format attendu : `arn:partition:iam::account-id:role/role-name`. Spécifiez un ARN de rôle valide et réessayez. Pour de plus amples informations, veuillez consulter [Rôle IAM d’infrastructure Amazon ECS](infrastructure_IAM_role.md).
## L’ARN du rôle de profil d’instance spécifié n’est pas valide.
Cette erreur se produit lorsque le profil d’instance ne suit pas le format ARN spécifique.
Format attendu : `arn:partition:iam::account-id:instance-profile/profile-name`. Spécifiez un ARN de rôle valide et réessayez. Pour de plus amples informations, veuillez consulter [Profil d’instance des instances gérées Amazon ECS](managed-instances-instance-profile.md).
## L’identifiant du groupe de sécurité spécifié n’est pas valide
Cette erreur se produit lorsque le groupe de sécurité ne suit pas le format ARN spécifique.
Format attendu : `sg-xxxxxxxx` ou `sg-xxxxxxxxxxxxxxxxxx` (8 ou 17 caractères, y compris des lettres (minuscules) et des chiffres après « subnet- »). Spécifiez un ID de groupe de sécurité et réessayez.
## L’identifiant de sous-réseau spécifié n’est pas valide
Cette erreur se produit lorsque l’ID de sous-réseau ne suit pas le format spécifique.
Format attendu : `subnet-xxxxxxxx` ou `subnet-xxxxxxxxxxxxxxxxxx` (8 ou 17 caractères, y compris des lettres (minuscules) et des chiffres après « subnet- »). Spécifiez un ID de sous-réseau et réessayez.
## Le fournisseur de capacité des instances gérées Amazon ECS doit spécifier une configuration réseau avec des sous-réseaux non vides
Cette erreur se produit lorsque vous essayez de créer un fournisseur de capacité avec le fournisseur d’instances gérées Amazon ECS et une configuration réseau avec des sous-réseaux vides.
Pour résoudre ce problème, spécifiez une configuration réseau valide avec des sous-réseaux non vides pour votre fournisseur de capacité d’instances gérées Amazon ECS.
## Le fournisseur de capacité des instances gérées Amazon ECS ne peut pas avoir un nombre de balises supérieur à la valeur maximale autorisée
Cette erreur se produit lorsque vous essayez de créer un fournisseur de capacité avec un nombre de balises supérieur au maximum autorisé (45).
Pour résoudre ce problème, réduisez le nombre de balises à 45 ou moins et réessayez.
## Valeur non valide pour les propagateTags
Cette erreur se produit lorsque vous essayez de créer un fournisseur de capacité avec une valeur propagateTags incorrecte.
La valeur doit être l’une des valeurs propagateTags valides. Spécifiez une valeur valide et réessayez.
## Le fournisseur de capacité spécifié existe déjà au niveau de l’étendue du cluster
Cette erreur se produit lorsque vous essayez de créer, de mettre à jour ou de supprimer un fournisseur de capacité d’instances gérées Amazon ECS sans nom de cluster, mais qu’il existe un fournisseur de capacité au niveau du cluster.
Pour modifier la configuration ou supprimer le fournisseur de capacité, mettez à jour ou supprimez le fournisseur de capacité avec le paramètre de cluster.
## Le fournisseur de capacité spécifié existe déjà au niveau du compte ou d’un autre cluster
Cette erreur se produit lorsque vous essayez de créer, de mettre à jour ou de supprimer un fournisseur de capacité d’instances gérées Amazon ECS avec un champ cluster, alors qu’il existe déjà un fournisseur de capacité au niveau du compte ou un fournisseur de capacité au niveau du cluster pour un autre cluster.
Pour résoudre ce problème, utilisez un autre nom de fournisseur de capacité ou utilisez le fournisseur de capacité existant.
## Le nom du cluster actif du fournisseur de capacité ne correspond pas au nom du cluster indiqué dans la requête
Cette erreur se produit lorsque le nom du cluster actif du fournisseur de capacité ne correspond pas au nom du cluster spécifié dans la requête.
Assurez-vous que le nom du cluster indiqué dans votre requête correspond au cluster associé au fournisseur de capacité.
## Le fournisseur de capacité n’est pas le fournisseur de capacité des instances gérées Amazon ECS
Cette erreur se produit lorsque vous essayez d’utiliser un fournisseur de capacité qui n’est pas un fournisseur de capacité d’instances gérées Amazon ECS dans un contexte qui en nécessite un.
Assurez-vous d’utiliser un fournisseur de capacité d’instances gérées Amazon ECS valide pour votre requête.
## CapacityProvider le nom ne doit pas être vide
Cette erreur se produit lorsque vous essayez de créer un fournisseur de capacité sans spécifier de nom de fournisseur de capacité.
Spécifiez un nom de fournisseur de capacité valide et réessayez.
## Un nom est requis lors de la mise à jour d’un fournisseur de capacité
Cette erreur se produit lorsque vous essayez de mettre à jour un fournisseur de capacité sans spécifier de nom de fournisseur de capacité.
Spécifiez un nom valide et réessayez.
## Les balises ne peuvent pas être nulles ou comporter des éléments nuls
Cette erreur se produit lorsque vous essayez d’étiqueter un fournisseur de capacité avec des valeurs nulles.
Assurez-vous que toutes les valeurs des balises sont correctement spécifiées et qu’elles ne sont pas nulles.
# Motifs d’échec d’API Amazon ECS
Si une action API que vous avez déclenchée via l’API Amazon ECS, la console ou la AWS CLI renvoie un message d’erreur `failures`, les éléments suivants peuvent aider à résoudre la cause. L’échec renvoie un motif et l’Amazon Resource Name (ARN) de la ressource associée à l’échec.
De nombreuses ressources sont spécifiques à la région. Lorsque vous utilisez la console, assurez-vous donc de définir la région correspondant à vos ressources. Lorsque vous utilisez le AWS CLI, assurez-vous que vos AWS CLI commandes sont envoyées à la bonne région avec le `--region region` paramètre.
Pour plus d'informations sur la structure du type de données `Failure`, consultez [Failure](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Failure.html) (Échec) dans la *Référence d'API Amazon Elastic Container Service*.
Voici des exemples de messages d’échec que vous pouvez recevoir lors de l’exécution de commandes API.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/api_failures_messages.html)
**Note**
Outre les scénarios d’échecs décrits ici, les opérations d’API peuvent également échouer en raison d’exceptions, ce qui entraîne des réponses d’erreur. Pour obtenir la liste de ces exceptions, consultez la section [Erreurs courantes](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/CommonErrors.html).
# Résolution des problèmes avec Amazon Q Developer
Vous pouvez utiliser [Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html) dans la console Amazon ECS pour diagnostiquer et résoudre les problèmes liés à vos ressources Amazon ECS. Pour certaines erreurs et certains messages d'état relatifs aux conteneurs, aux tâches, aux services, aux déploiements et aux définitions de tâches, la console affiche une option **Inspect with Amazon Q Developer**. Lorsque vous choisissez cette option, Amazon Q Developer analyse le problème dans son contexte et suggère des causes possibles ainsi que des mesures correctives.
## Autorisations requises
+ Autorisations permettant de consulter les ressources Amazon ECS que vous souhaitez dépanner, telles que les clusters, les services, les tâches et les définitions de tâches.
+ [Autorisations pour utiliser Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/security_iam_permissions.html) dans la console.
+ (Recommandé) Autorisations permettant d'afficher les journaux et les statistiques connexes, tels que :
+ CloudWatch Journaux
+ CloudWatch
## Procédure
1. Ouvrez la console à l'adresse[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).
1. Déterminez la ressource que vous souhaitez dépanner.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/troubleshooting-with-Q.html)
1. Sur la page des détails de la ressource, recherchez l'état ou la raison de santé qui décrit le problème.
1. Cliquez sur le motif du statut pour ouvrir la fenêtre contextuelle.
1. Si disponible, choisissez **Inspect with Amazon Q Developer**.
1. Consultez les explications et les étapes de correction suggérées par Amazon Q Developer. Appliquez des modifications de configuration ou opérationnelles en fonction de votre environnement.
## Considérations
Tenez compte des points suivants lorsque vous utilisez Amazon Q Developer avec Amazon ECS :
+ **Disponibilité des boutons : le bouton** « Inspecter avec Amazon Q Developer » n'est affiché que pour les ressources rencontrant des problèmes potentiels. Cette option n'est pas disponible pour les ressources saines.
+ **Opérations en lecture seule** : l'intégration Amazon Q Developer n'effectue que des opérations de lecture. Il n'effectue aucune action de mutation ou d'écriture.
+ **Traitement entre régions** : Amazon Q Developer peut traiter les données entre les AWS régions afin de fournir une analyse basée sur l'IA. Pour plus d'informations sur le traitement interrégional, consultez Traitement [interrégional dans Amazon Q](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/cross-region-processing.html) Developer.
+ **Console uniquement** : cette intégration n'est disponible que par le biais de la console. Il n'est pas disponible via le AWS CLI AWS APIs, ou l'infrastructure en tant qu'outils de code.
## En savoir plus
Pour plus d'informations sur l'utilisation d'Amazon Q Developer, consultez [Discuter avec Amazon Q Developer à propos de AWS](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/chat-with-q.html).