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. # Surveillance des conteneurs Amazon ECS avec ECS Exec Avec Amazon ECS Exec, vous pouvez interagir directement avec les conteneurs sans avoir besoin d'interagir avec le système d'exploitation du conteneur hôte, d'ouvrir des ports entrants ou de gérer les clés SSH au préalable. Vous pouvez utiliser ECS Exec pour exécuter des commandes dans ou obtenir un shell vers un conteneur s'exécutant sur une instance Amazon EC2 ou sur AWS Fargate. Cela facilite la collecte des informations de diagnostic et la résolution rapide des erreurs. Par exemple, dans le cadre d'un développement, vous pouvez utiliser ECS Exec pour interagir facilement avec différents processus dans vos conteneurs et dépanner vos applications. Et dans les scénarios de production, vous pouvez l’utiliser pour obtenir un accès d’urgence à vos conteneurs afin de déboguer les problèmes. Vous pouvez exécuter des commandes dans un conteneur Linux ou Windows en cours d'exécution à l'aide d'ECS Exec à partir de l'API Amazon ECS AWS Command Line Interface (AWS CLI) ou de la AWS SDKs CLI AWS Copilot. [Pour plus de détails sur l'utilisation d'ECS Exec, ainsi qu'une présentation vidéo sur l'utilisation de la CLI AWS Copilot, consultez la documentation Copilot. GitHub](https://aws.github.io/copilot-cli/docs/commands/svc-exec/) Vous pouvez également utiliser ECS Exec pour appliquer des politiques de contrôle d’accès plus strictes. En activant cette fonction de manière sélective, vous pouvez contrôler qui peut exécuter des commandes et sur quelles tâches. Avec un journal de chaque commande et de ses résultats, vous pouvez utiliser ECS Exec pour voir quelles tâches ont été exécutées et CloudTrail pour vérifier qui a accédé à un conteneur. ## Considérations Tenez compte des éléments suivants lorsque vous utilisez ECS Exec : + ECS Exec risque de ne pas fonctionner comme prévu s’il est exécuté sur des systèmes d’exploitation non pris en charge par Systems Manager. Pour plus d’informations sur les systèmes d’exploitation pris en charge, consultez la section [Types de systèmes d’exploitation](https://docs.aws.amazon.com/systems-manager/latest/userguide/operating-systems-and-machine-types.html#prereqs-os-linux) dans le *Guide de l’utilisateur AWS Systems Manager *. + ECS Exec est pris en charge pour les tâches exécutées sur l'infrastructure suivante : + Conteneurs Linux sur Amazon EC2 sur n'importe quelle AMI optimisée pour Amazon ECS, y compris Bottlerocket + Conteneurs Linux et Windows sur des instances externes (Amazon ECS Anywhere) + Conteneurs Linux et Windows sur AWS Fargate + Conteneurs Windows sur Amazon EC2 sur les modèles Windows suivants optimisés pour Amazon ECS AMIs (avec la version `1.56` de l'agent de conteneur ou ultérieure) : + AMI de Windows Server 2022 Full optimisée pour Amazon ECS + AMI de Windows Server 2022 Core optimisée pour Amazon ECS + AMI de Windows Server 2019 Full optimisée pour Amazon ECS + AMI de Windows Server 2019 Core optimisée pour Amazon ECS + AMI de Windows Server 20H2 Core optimisée pour Amazon ECS + Si vous avez configuré un proxy HTTP pour votre tâche, définissez la variable d’environnement `NO_PROXY` sur `"NO_PROXY=169.254.169.254,169.254.170.2"` afin de contourner le proxy pour les métadonnées de l’instance EC2 et le trafic des rôles IAM. Si vous ne configurez pas la variable d’environnement `NO_PROXY`, des échecs peuvent survenir lors de la récupération des métadonnées de l’instance ou des informations d’identification du rôle IAM à partir du point de terminaison des métadonnées du conteneur. La définition de la variable d’environnement `NO_PROXY` comme recommandé filtre les métadonnées et le trafic IAM afin que les requêtes `169.254.169.254 and 169.254.170.2` ne passent pas par le proxy `HTTP`. + ECS Exec et Amazon VPC + Si vous utilisez l'interface des points de terminaison Amazon VPC avec Amazon ECS, vous devez créer l'interface des points de terminaison Amazon VPC pour le Gestionnaire de sessions Systems Manager (`ssmmessages`). *Pour plus d'informations sur les points de terminaison VPC de Systems Manager, consultez la section [Utiliser AWS PrivateLink pour configurer un point de terminaison VPC pour Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-privatelink.html) dans le guide de l'utilisateur.AWS Systems Manager * + Si vous utilisez des points de terminaison Amazon VPC avec Amazon ECS à des fins de chiffrement, vous devez créer l'interface AWS KMS key pour laquelle le point de terminaison Amazon VPC est utilisé. AWS KMS key Pour plus d'informations, consultez [Configuration à AWS KMS key via un point de terminaison de VPC](https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html) dans le *Guide du développeur AWS Key Management Service *. + Lorsque vous avez des tâches exécutées sur des instances Amazon EC2, utilisez le mode réseau `awsvpc`. Si vous n’avez pas accès à Internet (par exemple, si vous n’êtes pas configuré pour utiliser une passerelle NAT), vous devez créer les points de terminaison Amazon VPC d’interface pour le Gestionnaire de session Systems Manager (`ssmmessages`). Pour plus d'informations sur les considérations relatives au mode réseau `awsvpc`, veuillez consulter [Considérations](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking-awsvpc.html#linux) (langue française non garantie). *Pour plus d'informations sur les points de terminaison VPC de Systems Manager, consultez la section [Utiliser AWS PrivateLink pour configurer un point de terminaison VPC pour Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-privatelink.html) dans le guide de l'utilisateur.AWS Systems Manager * + Amazon ECS Exec n'est pas pris en charge pour les tâches exécutées dans une IPv6 configuration uniquement. Pour plus d'informations sur l'exécution de tâches dans une configuration IPv6 uniquement, consultez [Options de mise en réseau des tâches Amazon ECS pour Fargate](fargate-task-networking.md) et[Options de mise en réseau des tâches Amazon ECS pour EC2](task-networking.md). + ECS Exec et SSM + Lorsqu'un utilisateur exécute des commandes sur un conteneur à l'aide d'ECS Exec, ces commandes sont exécutées en tant qu'utilisateur `root`. Le SSM Agent et ses processus enfants s'exécutent en tant qu'utilisateur racine même lorsque vous spécifiez un ID d'utilisateur pour le conteneur. + L’agent SSM exige qu’il soit possible d’écrire dans le système de fichiers du conteneur pour créer les répertoires et fichiers requis. Par conséquent, il n'est pas possible de rendre le système de fichiers racine en lecture seule à l'aide du paramètre de définition de tâche `readonlyRootFilesystem` ou de toute autre méthode. + Il est possible de démarrer des sessions SSM en dehors de l'action `execute-command`, mais les sessions ne sont pas journalisées et sont comptabilisées afin de vérifier qu'elles ne dépassent pas la limite de session. Nous vous recommandons de limiter cet accès en refusant l'action `ssm:start-session` à l'aide d'une stratégie IAM. Pour de plus amples informations, veuillez consulter [Limitation de l'accès à l'action StartSession](#ecs-exec-limit-access-start-session). + Les fonctionnalités suivantes s’exécutent en tant que conteneur sidecar. Par conséquent, vous devez spécifier le nom du conteneur sur lequel exécuter la commande. + Surveillance d’exécution + Service Connect + Les utilisateurs peuvent exécuter toutes les commandes qui sont disponibles dans le contexte de conteneur. Les actions suivantes peuvent entraîner des processus orphelins et zombies : arrêt du processus principal du conteneur, arrêt de l'agent de commande et suppression des dépendances. Pour nettoyer les processus zombie, nous vous recommandons d'ajouter l'indicateur `initProcessEnabled` à votre définition de tâche. + ECS Exec utilise une partie de l’UC et de la mémoire. Vous devez en tenir compte lorsque vous spécifiez les allocations de ressources CPU et mémoire dans votre définition de tâche. + Vous devez utiliser la AWS CLI version `1.22.3` ou une version ultérieure ou une AWS CLI version `2.3.6` ou une version ultérieure. Pour plus d'informations sur la mise à jour du AWS CLI, voir [Installation ou mise à jour de la AWS CLI dernière version du](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) *Guide de l'AWS Command Line Interface utilisateur, version 2*. + Vous ne pouvez avoir qu'une seule session ECS Exec par espace de noms d'ID de processus (PID). Si vous [partagez un espace de noms PID dans une tâche](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#other_task_definition_params), vous ne pouvez démarrer des sessions ECS Exec que dans un seul conteneur. + La session ECS Exec a une valeur de délai d'inactivité de 20 minutes. Cette valeur ne peut pas être modifiée. + Vous ne pouvez pas activer ECS Exec pour les tâches existantes. Vous ne pouvez l'activer que pour les nouvelles tâches. + Vous ne pouvez pas utiliser ECS Exec lorsque vous utilisez `run-task` pour lancer une tâche sur un cluster qui utilise la mise à l’échelle gérée avec placement asynchrone (lancement d’une tâche sans instance). + Vous ne pouvez pas exécuter ECS Exec sur des conteneurs Microsoft Nano Server. ## Architecture ECS Exec utilise le gestionnaire de session AWS Systems Manager (SSM) pour établir une connexion avec le conteneur en cours d'exécution et utilise des politiques Gestion des identités et des accès AWS (IAM) pour contrôler l'accès aux commandes en cours d'exécution dans un conteneur en cours d'exécution. Ceci est rendu possible par le montage lié des fichiers binaires du SSM Agent nécessaires dans le conteneur. L'Amazon ECS ou l' AWS Fargate agent est chargé de démarrer l'agent principal SSM dans le conteneur en même temps que le code de votre application. Pour plus d'informations, consultez [ Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html). Vous pouvez vérifier quel utilisateur a accédé au conteneur à l'aide de l'`ExecuteCommand`événement AWS CloudTrail et enregistrer chaque commande (et sa sortie) dans Amazon S3 ou Amazon CloudWatch Logs. Pour chiffrer les données entre le client local et le conteneur avec votre propre clé de chiffrement, vous devez fournir la clé AWS Key Management Service (AWS KMS). ## Configuration d’ECS Exec Pour utiliser ECS Exec, vous devez d’abord activer la fonctionnalité pour vos tâches et services. Vous pouvez ensuite exécuter des commandes dans vos conteneurs. ### Modifications facultatives de la définition de tâche Si vous définissez le paramètre de définition de tâche `initProcessEnabled` sur `true`, le processus init démarre à l’intérieur du conteneur. Cela supprime tous les processus enfants de l’agent SSM zombie trouvés. Voici un exemple. ``` { "taskRoleArn": "ecsTaskRole", "networkMode": "awsvpc", "requiresCompatibilities": [ "EC2", "FARGATE" ], "executionRoleArn": "ecsTaskExecutionRole", "memory": ".5 gb", "cpu": ".25 vcpu", "containerDefinitions": [ { "name": "amazon-linux", "image": "amazonlinux:latest", "essential": true, "command": ["sleep","3600"], "linuxParameters": { "initProcessEnabled": true } } ], "family": "ecs-exec-task" } ``` ### Activation d'ECS Exec pour vos tâches et services Vous pouvez activer la fonctionnalité ECS Exec pour vos services et tâches autonomes en spécifiant l'`--enable-execute-command`indicateur lorsque vous utilisez l'une des AWS CLI commandes suivantes : [https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html), [https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html), ou. [https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html) Par exemple, si vous exécutez la commande suivante, la fonctionnalité ECS Exec est activée pour un service nouvellement créé. Pour plus d'informations sur la création de services, consultez [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html). ``` aws ecs create-service \ --cluster cluster-name \ --task-definition task-definition-name \ --enable-execute-command \ --service-name service-name \ --launch-type FARGATE \ --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}" \ --desired-count 1 ``` Après avoir activé ECS Exec pour une tâche, vous pouvez exécuter la commande suivante pour confirmer que la tâche est prête à être utilisée. Si la propriété `lastStatus` de `ExecuteCommandAgent` est répertoriée comme `RUNNING` et que la propriété `enableExecuteCommand` est définie sur `true`, alors votre tâche est prête. ``` aws ecs describe-tasks \ --cluster cluster-name \ --tasks task-id ``` L'extrait de sortie suivant est un exemple de ce que vous pouvez voir. ``` { "tasks": [ { ... "containers": [ { ... "managedAgents": [ { "lastStartedAt": "2021-03-01T14:49:44.574000-06:00", "name": "ExecuteCommandAgent", "lastStatus": "RUNNING" } ] } ], ... "enableExecuteCommand": true, ... } ] } ``` ### Exécution de commandes avec ECS Exec ## Journalisation à l’aide d’ECS Exec Vous pouvez configurer la journalisation des sessions ECS Exec afin de capturer les commandes et leur sortie à des fins d’audit et de résolution des problèmes. ### Activation de la journalisation et de l’audit dans vos tâches et services **Important** Pour plus d'informations sur la CloudWatch tarification, consultez la section [CloudWatch Tarification](https://aws.amazon.com/cloudwatch/pricing/). Amazon ECS propose également des métriques de surveillance sans coûts supplémentaires. Pour de plus amples informations, veuillez consulter [Surveillez Amazon ECS à l'aide de CloudWatch](cloudwatch-metrics.md). Amazon ECS fournit une configuration par défaut pour les commandes de journalisation exécutées à l’aide d’ECS Exec. Par défaut, les journaux sont envoyés à CloudWatch Logs à l'aide du pilote de `awslogs` journal configuré dans la définition de votre tâche. Si vous souhaitez fournir une configuration personnalisée, le AWS CLI support inclut un `--configuration` indicateur pour les `update-cluster` commandes `create-cluster` et. L'image du conteneur nécessite `script` et `cat` doit être installée afin que les journaux de commandes soient correctement chargés sur Amazon S3 ou CloudWatch Logs. Pour de plus amples informations sur la création de clusters, consultez [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-cluster.html). **Note** Cette configuration ne gère que la journalisation de la session `execute-command`. Cela n'affecte pas la journalisation de votre application. L'exemple suivant crée un cluster, puis enregistre la sortie dans vos CloudWatch journaux LogGroup nommés `cloudwatch-log-group-name` et dans votre compartiment Amazon S3 nommé`s3-bucket-name`. Vous devez utiliser une clé gérée par le AWS KMS client pour chiffrer le groupe de journaux lorsque vous définissez l'`CloudWatchEncryptionEnabled`option sur. `true` Pour plus d'informations sur le chiffrement du groupe de journaux, voir [Chiffrer les données des CloudWatch journaux dans Logs using AWS Key Management Service, dans](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html#encrypt-log-data-kms-policy) le Guide de l'*Amazon CloudWatch Logs utilisateur*. ``` aws ecs create-cluster \ --cluster-name cluster-name \ --configuration executeCommandConfiguration="{ \ kmsKeyId=string, \ logging=OVERRIDE, \ logConfiguration={ \ cloudWatchLogGroupName=cloudwatch-log-group-name, \ cloudWatchEncryptionEnabled=true, \ s3BucketName=s3-bucket-name, \ s3EncryptionEnabled=true, \ s3KeyPrefix=demo \ } \ }" ``` La propriété `logging` détermine le comportement de la capacité de journalisation d'ECS Exec : + `NONE` : la journalisation est désactivée. + `DEFAULT` : les journaux sont envoyés au pilote `awslogs` configuré. Si le pilote n’est pas configuré, aucun journal n’est enregistré. + `OVERRIDE`: les journaux sont envoyés au compartiment Amazon CloudWatch Logs fourni LogGroup, au compartiment Amazon S3, ou aux deux. ### Autorisations IAM requises pour Amazon CloudWatch Logs ou Amazon S3 Logging Pour activer la journalisation, le rôle de tâche Amazon ECS référencé dans votre définition de tâche doit disposer d'autorisations supplémentaires. Ces autorisations supplémentaires peuvent être ajoutées en tant que stratégie au rôle de tâche. Ils sont différents selon que vous dirigez vos journaux vers Amazon CloudWatch Logs ou Amazon S3. ------ #### [ Amazon CloudWatch Logs ] L'exemple de politique suivant ajoute les autorisations Amazon CloudWatch Logs requises. **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:DescribeLogGroups" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "logs:CreateLogStream", "logs:DescribeLogStreams", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:us-east-1:111122223333:log-group:/aws/ecs/cloudwatch-log-group-name:*" } ] } ``` ------ #### [ Amazon S3 ] L'exemple suivant de stratégie ajoute les autorisations Amazon S3 requises. **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetBucketLocation" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetEncryptionConfiguration" ], "Resource": "arn:aws:s3:::s3-bucket-name" }, { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::s3-bucket-name/*" } ] } ``` ------ ### Autorisations IAM requises pour le chiffrement à l'aide des vôtres AWS KMS key (clé KMS) Par défaut, les données transférées entre votre client local et le conteneur utilisent le cryptage TLS 1.2 qui AWS fournit. Pour chiffrer davantage les données à l'aide de votre propre clé KMS, vous devez créer une clé KMS et ajouter l'autorisation `kms:Decrypt` à votre rôle IAM de tâche. Votre conteneur utilise cette autorisation pour déchiffrer les données. Pour plus d'informations sur la création d'une clé KMS, consultez [Création de clés](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html). Vous ajoutez la politique en ligne suivante à votre rôle IAM de tâche qui nécessite les autorisations AWS KMS . Pour de plus amples informations, veuillez consulter [Autorisations ECS Exec](task-iam-roles.md#ecs-exec-required-iam-permissions). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": "arn:aws:kms:us-east-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" } ] } ``` ------ Pour que les données soient chiffrées à l'aide de votre propre clé KMS, l'utilisateur ou le groupe utilisant l'action `execute-command` doit être accordée à l'autorisation `kms:GenerateDataKey`. L'exemple de stratégie suivant pour votre utilisateur ou groupe contient l'autorisation requise pour utiliser votre propre clé KMS. Vous devez spécifier l'Amazon Resource Name (ARN) de votre clé KMS. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:GenerateDataKey" ], "Resource": "arn:aws:kms:us-east-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" } ] } ``` ------ ## Utilisation de stratégies IAM pour limiter l'accès à ECS Exec Vous limitez l’accès utilisateur à l’action d’API execute-command en utilisant une ou plusieurs des clés de condition de politique IAM suivantes : + `aws:ResourceTag/clusterTagKey` + `ecs:ResourceTag/clusterTagKey` + `aws:ResourceTag/taskTagKey` + `ecs:ResourceTag/taskTagKey` + `ecs:container-name` + `ecs:cluster` + `ecs:task` + `ecs:enable-execute-command` Avec l'exemple de stratégie IAM suivant, les utilisateurs peuvent exécuter des commandes dans des conteneurs qui s'exécutent dans des tâches avec une balise qui possède une clé `environment` et une valeur `development`, dans un cluster nommé `cluster-name`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecs:ExecuteCommand", "ecs:DescribeTasks" ], "Resource": [ "arn:aws:ecs:us-east-1:111122223333:task/cluster-name/*", "arn:aws:ecs:us-east-1:111122223333:cluster/cluster-name" ], "Condition": { "StringEquals": { "ecs:ResourceTag/environment": "development" } } } ] } ``` ------ Avec l'exemple de politique IAM suivant, les utilisateurs ne peuvent pas utiliser l'API `execute-command` lorsque le nom du conteneur est `production-app`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "ecs:ExecuteCommand" ], "Resource": "*", "Condition": { "StringEquals": { "ecs:container-name": "production-app" } } } ] } ``` ------ Avec la stratégie IAM suivante, les utilisateurs ne peuvent lancer des tâches que lorsque ECS Exec est désactivé. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecs:RunTask", "ecs:StartTask", "ecs:CreateService", "ecs:UpdateService" ], "Resource": "*", "Condition": { "StringEquals": { "ecs:enable-execute-command": "false" } } } ] } ``` ------ **Note** Étant donné que l'action d'API `execute-command` contient uniquement des ressources de tâche et de cluster dans une reqûete, seules les balises de cluster et de tâche sont évaluées. Pour plus d'informations sur les clés de condition de stratégie IAM, consultez [Actions, ressources et clés de condition pour Amazon Elastic Container Service](/service-authorization/latest/reference/list_amazonelasticcontainerservice.html) dans la *Référence de l'autorisation de service*. ### Limitation de l'accès à l'action StartSession Bien qu'il soit possible de démarrer des sessions SSM sur votre conteneur en dehors d'ECS Exec, cela pourrait entraîner la non-journalisation des sessions. Les sessions démarrées en dehors d'ECS Exec sont également comptabilisées dans le quota de session. Nous vous recommandons de limiter cet accès en refusant l'action `ssm:start-session` directement pour vos tâches Amazon ECS à l'aide d'une stratégie IAM. Vous pouvez refuser l'accès à toutes les tâches Amazon ECS ou à des tâches spécifiques en fonction des balises utilisées. Voici un exemple de stratégie IAM qui refuse l'accès à l'action `ssm:start-session` pour les tâches dans toutes les régions avec un nom de cluster spécifié. Si vous le souhaitez, vous pouvez inclure un caractère générique avec l'option `cluster-name`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ssm:StartSession", "Resource": [ "arn:aws:ecs:us-east-1:111122223333:task/cluster-name/*" ] } ] } ``` ------ Voici un exemple de stratégie IAM qui refuse l'accès à l'action `ssm:start-session` sur les ressources dans toutes les régions étiquetées avec la clé de balise `Task-Tag-Key` et la valeur de balise`Exec-Task`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ssm:StartSession", "Resource": "arn:aws:ecs:*:*:task/*", "Condition": { "StringEquals": { "aws:ResourceTag/Task-Tag-Key": "Exec-Task" } } } ] } ``` ------ ## Résolution des problèmes ECS Exec Pour aller plus loin dans la résolution, consultez la section [Résolution des problèmes avec Exec](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec-troubleshooting.html). # Exécution de commandes avec ECS Exec Vous pouvez utiliser Amazon ECS Exec pour collecter des informations de diagnostic relatives à vos conteneurs et résoudre les erreurs rencontrées tout au long du cycle de vie de vos conteneurs. ## Conditions préalables Avant de commencer à utiliser ECS Exec, assurez-vous que vous avez effectué les actions suivantes : + Prenez connaissance des considérations. Pour de plus amples informations, consultez [Considérations](ecs-exec.md#ecs-exec-considerations). + Configurez ECS Exec pour vos tâches et services. Pour de plus amples informations, consultez [Configuration d’ECS Exec](ecs-exec.md#ecs-exec-enabling-and-using). + **Installez et configurez l’ AWS CLI**. Pour plus d’informations, consultez la section [Démarrage avec l’ AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html). + **Installez le plugin Session Manager pour AWS CLI**. Pour de plus amples informations, veuillez consulter [Install the Session Manager plugin for the AWS CLI](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html). + **Configurez un rôle de tâche avec les autorisations appropriées**. Vous devez utiliser un rôle de tâche doté des autorisations appropriées pour ECS Exec. Pour plus d'informations, veuillez consulter [Rôle IAM de tâche](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) (langue française non garantie). + **Vérifiez les exigences de version**. ECS Exec a des exigences de version selon que vos tâches sont hébergées sur Amazon EC2 ou AWS Fargate : + Si vous utilisez Amazon EC2, vous devez utiliser une AMI optimisée pour Amazon ECS publiée après le 20 janvier 2021 avec une version 1.50.2 ou supérieure de l'agent. Pour plus d'informations, consultez [Amazon ECS optimisé AMIs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html). + Si vous utilisez AWS Fargate, vous devez utiliser une version de plate-forme `1.4.0` ou supérieure (Linux) ou `1.0.0` (Windows). Pour plus d'informations, consultez [Versions de plateforme AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform-fargate.html). ## Utilisation de la console pour les tâches de service Vous pouvez utiliser la console pour exécuter des commandes à l’aide d’ECS Exec. 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. Sur la page des détails du service, choisissez **Tâches**. Puis choisissez la tâche. 1. Sous **Conteneurs**, choisissez le conteneur dans lequel vous souhaitez utiliser ECS Exec. 1. Pour exécuter des commandes, procédez de l’une des manières suivantes : + Choisissez **Se connecter**. Une CloudShell session s'affiche dans laquelle vous pouvez exécuter vos commandes. + Cliquez sur la flèche, puis choisissez **Copier la commande AWS CLI **. Vous pouvez ensuite exécuter les commandes localement. **Résultats attendus** Si la connexion est établie, vous devriez voir une invite shell interactive provenant de votre conteneur. Vous pouvez désormais exécuter des commandes directement dans l’environnement du conteneur. Pour mettre fin à la session, choisissez **Arrêter la session**. ## Utilisation de la console pour des tâches autonomes Vous pouvez utiliser la console pour exécuter des commandes à l’aide d’ECS Exec. 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 **Tâches**, choisissez la tâche. La page des détails de la tâche s’affiche. 1. Sous **Conteneurs**, choisissez le conteneur dans lequel vous souhaitez utiliser ECS Exec. 1. Pour exécuter des commandes, procédez de l’une des manières suivantes : + Choisissez **Se connecter**. Une CloudShell session s'affiche dans laquelle vous pouvez exécuter vos commandes. + Cliquez sur la flèche, puis choisissez **Copier la commande AWS CLI **. Vous pouvez ensuite exécuter les commandes localement. **Résultats attendus** Si la connexion est établie, vous devriez voir une invite shell interactive provenant de votre conteneur. Vous pouvez désormais exécuter des commandes directement dans l’environnement du conteneur. Pour mettre fin à la session, choisissez **Arrêter la session**. ## Utilisation du shell de commande Vous pouvez utiliser le shell de commande pour exécuter des commandes à l’aide d’ECS Exec. Une fois que vous avez confirmé que `ExecuteCommandAgent` est en cours d'exécution, vous pouvez ouvrir un shell interactif sur votre conteneur à l'aide de la commande suivante. Si votre tâche contient plusieurs conteneurs, vous devez spécifier le nom du conteneur à l'aide de l'indicateur `--container`. Amazon ECS ne prend en charge que le lancement de sessions interactives. Vous devez donc utiliser l'indicateur `--interactive`. La commande suivante exécutera une `/bin/sh` commande interactive sur un conteneur nommé **container-name** d'après une tâche avec un ID de*task-id*. *task-id*Il s'agit du nom de ressource Amazon (ARN) de la tâche. ``` aws ecs execute-command --cluster cluster-name \ --task task-id \ --container container-name \ --interactive \ --command "/bin/sh" ``` **Résultats attendus** Si la commande aboutit, vous devriez voir une invite shell interactive provenant de votre conteneur. Vous pouvez désormais exécuter des commandes directement dans l’environnement du conteneur. Pour quitter la session, tapez `exit` ou appuyez sur `Ctrl+D`.