Comment puis-je résoudre les erreurs que je reçois lorsque j'utilise ECS Exec sur mes tâches Fargate ?

Lecture de 7 minute(s)
0

Je souhaite résoudre les erreurs que je reçois lorsque j’exécute Amazon Elastic Container Service (Amazon ECS) Exec sur mes tâches AWS Fargate.

Brève description

Lorsque vous utilisez ECS Exec sur des tâches Fargate, l'un des messages d'erreur suivants peut s'afficher :

  • « An error occurred (InvalidParameterException) when calling the ExecuteCommand operation: The execute command failed because execute command was not enabled when the task was run or the execute command agent isn't running. Wait and try again or run a new task with execute command enabled and try again. »
  • « An error occurred (TargetNotConnectedException) when calling the ExecuteCommand operation: The execute command failed due to an internal error. Try again later ».

Résolution

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

Pour résoudre les erreurs courantes qui se produisent lorsque vous utilisez ECS Exec sur des tâches Fargate, il est recommandé d'utiliser AWS CloudShell. CloudShell est préinstallé avec AWS Systems Manager Session Manager Agent (SSM Agent) et l'interface de ligne de commande AWS.

Erreur InvalidParameterException

Si l’option ExecuteCommand pour votre tâche Fargate est désactivée, vous recevez l’erreur InvalidParameterException.

Pour résoudre ce problème, procédez comme suit :

  1. Exécutez la commande describe-tasks pour vérifier si le paramètre enableExecuteCommand est défini sur vrai ou sur faux :
    aws ecs describe-tasks --cluster example-cluster-name --tasks example-task-id| grep enableExecuteCommand
    Remarque : Remplacez example-cluster-name par votre cluster et example-task-id par votre ID de tâche.
  2. Si le paramètre enableExecuteCommand est défini sur faux, exécutez la commande update-service suivante pour mettre à jour le paramètre sur vrai :
    aws ecs update-service --cluster example-cluster-name --service example-service --region example-region --enable-execute-command --force-new-deployment
    Remarque : Remplacez example-cluster-name par votre cluster, example-service par votre service et example-region par votre région AWS. L’option force-new-deployment crée un nouveau déploiement qui lance de nouvelles tâches et arrête les anciennes en fonction de la configuration de déploiement du service. Si vos services utilisent un déploiement bleu/vert via AWS CodeDeploy, au lieu de forcer un nouveau déploiement, lancez un déploiement CODE_DEPLOY. Vous ne pouvez pas utiliser force-new-deployment pour un déploiement bleu/vert car cette option lance une mise à jour continue.
  3. Exécutez la commande describe-tasks suivante pour vérifier l'état de ExecuteCommandAgent :
    aws ecs describe-tasks --cluster example-cluster-name --tasks example-task-id | grep -A 6 managedAgents
    Remarque : Remplacez example-cluster-name par votre cluster et example-task-id par votre ID de tâche.
  4. Vérifiez la sortie de la commande pour vérifier l'état de l'agent ExecuteCommand. Si le paramètre lastStatus de ExecuteCommandAgent n'est pas EN COURS D'EXÉCUTION, consultez les journaux de l'agent ExecuteCommandAgent pour en identifier la cause racine. Passez aux étapes de dépannage de la section Générer des journaux pour ECS Exec afin d'identifier les problèmes pour générer les journaux ExecuteCommandAgent.
    Si ExecuteCommandAgent ne peut pas récupérer les informations d'identification parce que vous avez configuré un proxy dans le conteneur, ajoutez l'option NO_PROXY suivante aux fichiers de configuration de votre instance de conteneur :
    env no_proxy=169.254.169.254,169.254.170.2

TargetNotConnectedExceptionerror

Pour résoudre une erreur TargetNotConnectedException, effectuez les actions ci-dessous.

Ajoutez les autorisations requises et confirmez que la configuration de mise en réseau est correcte

Procédez comme suit :

  1. Ajoutez les autorisations requises au rôle AWS Identity and Access Management (IAM) de votre tâche Amazon ECS. Si le rôle IAM de la tâche possède déjà les autorisations requises, vérifiez si des politiques de contrôle des services (SCP) bloquent la connexion de la tâche à SSM Agent.
  2. Si vous utilisez des points de terminaison d'interface Amazon Virtual Private Cloud (Amazon VPC) avec Amazon ECS, créez les points de terminaison suivants :
    ec2messages.region.amazonaws.com
    ssm.region.amazonaws.com
    ssmmessages.region.amazonaws.com
    Remarque : Remplacez region par votre région.
  3. Pour confirmer que votre environnement AWS CLI et votre cluster ou votre tâche Amazon ECS sont prêts pour l’exécution d’ECS Exec, exécutez le script check-ecs-exec.sh. Pour plus d'informations sur les prérequis et l'utilisation, consultez la page Amazon ECS Exec Checker sur le site Web de GitHub.
    Le résultat du script check-ecs-exec.sh indique ce que vous devez résoudre avant d'utiliser ECS Exec. Exemple de sortie :
    Prerequisites for check-ecs-exec.sh v0.7-------------------------------------------------------------  jq      | OK (/usr/bin/jq)
      AWS CLI | OK (/usr/local/bin/aws)
    
    -------------------------------------------------------------
    Prerequisites for the AWS CLI to use ECS Exec
    -------------------------------------------------------------
      AWS CLI Version        | OK (aws-cli/2.11.0 Python/3.11.2 Linux/4.14.255-291-231.527.amzn2.x86_64 exec-env/CloudShell exe/x86_64.amzn.2 prompt/off)
      Session Manager Plugin | OK (1.2.398.0)
    
    -------------------------------------------------------------
    Checks on ECS task and other resources
    -------------------------------------------------------------
    Region : us-east-1
    Cluster: Fargate-Testing
    Task   : ca27e41ea3f54fd1804ca00feffa178d
    -------------------------------------------------------------
      Cluster Configuration  | Audit Logging Not Configured
      Can I ExecuteCommand?  | arn:aws:iam::12345678:role/Admin
         ecs:ExecuteCommand: allowed
         ssm:StartSession denied?: allowed
      Task Status            | RUNNING
      Launch Type            | Fargate
      Platform Version       | 1.4.0
      Exec Enabled for Task  | NO
      Container-Level Checks |
        ----------
          Managed Agent Status - SKIPPED
        ----------
        ----------
          Init Process Enabled (Exec-check:2)
        ----------
             1. Disabled - "nginx"
        ----------
          Read-Only Root Filesystem (Exec-check:2)
        ----------
             1. Disabled - "nginx"
      Task Role Permissions  | arn:aws:iam::12345678:role/L3-session
         ssmmessages:CreateControlChannel: implicitDeny
         ssmmessages:CreateDataChannel: implicitDeny
         ssmmessages:OpenControlChannel: implicitDeny
         ssmmessages:OpenDataChannel: implicitDeny
      VPC Endpoints          | SKIPPED (vpc-abcd - No additional VPC endpoints required)
      Environment Variables  | (Exec-check:2)
           1. container "nginx"
           - AWS_ACCESS_KEY: not defined
           - AWS_ACCESS_KEY_ID: not defined
           - AWS_SECRET_ACCESS_KEY: not defined
    Le résultat précédent montre qu'ECS Exec est désactivé pour la tâche et que le rôle de tâche ne dispose pas des autorisations de Systems Manager requises. Remarque : Vous devez définir le paramètre ReadonlyRootFilesystem sur faux dans la définition de tâche pour exécuter ECS Exec. Si ReadOnlyRootFileSystem a la valeur vrai, SSM Agent ne peut pas créer les répertoires requis.

Vérifiez si vous avez configuré les informations d’identification utilisateur IAM au niveau du conteneur, par exemple en spécifiant une clé d’accès ou une clé d’accès secrète. SSM Agent utilise le SDK AWS pour Java lorsqu'il vérifie l'authentification. Si vous configurez la clé d'accès ou la clé d'accès secrète de l'instance de conteneur en tant que variables d'environnement, vous remplacez les autorisations au niveau des tâches. Pour utiliser ECS Exec, les informations d'identification IAM au niveau du conteneur doivent fournir des autorisations pour SSM Agent.

Utilisez ECS Exec pour accéder au conteneur avec le shell approprié

Les différentes images de base peuvent contenir différents shells. Si vous utilisez le shell inapproprié, des erreurs s'affichent. Assurez-vous que vous utilisez le shell correspondant à l’image de votre application.

Pour utiliser ECS Exec pour accéder au conteneur, exécutez la commande execute-command :

aws ecs execute-command --region example-region --cluster example-cluster --container example-container --task example-task --command "example_shell" --interactive

Remarque : Remplacez example-region par votre région, example-cluster par le nom de votre cluster, example-container par le nom de l’instance de votre conteneur et example-task par le nom de votre tâche.

Générez des journaux pour ECS Exec afin d’identifier les problèmes

Pour déterminer pourquoi ECS Exec ne fonctionne pas, exécutez la commande suivante dans la section environnement de la définition du conteneur afin de générer les journaux de SSM Agent :

Console :

bin/bash,-c,sleep 2m && cat /var/log/amazon/ssm/amazon-ssm-agent.log

JSON :

"/bin/bash","-c","sleep 2m && cat /var/log/amazon/ssm/amazon-ssm-agent.log"

Remarque : Différentes applications ont des shells et des éditeurs différents. Modifiez les paramètres de commande précédents en fonction des besoins de votre application.

Si vous utilisez le pilote de journal awslogs, les commandes précédentes génèrent des journaux de SSM Agent et les transfèrent vers le groupe de journaux Amazon CloudWatch. Si vous utilisez d’autres pilotes de journal ou des points de terminaison de journalisation, SSM Agent capture le transfert vers ces emplacements.

Exemple JSON :

"entryPoint": [],      "portMappings": [],      "command": [
        "bin/bash",
        "-c",
        "sleep 2m && cat /var/log/amazon/ssm/amazon-ssm-agent.log"
      ],

Informations connexes

Utilisation d’ECS Exec

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 2 mois