Wie behebe ich Fehler, die ich erhalte, wenn ich ECS Exec für meine Fargate-Aufgaben verwende?

Kurzbeschreibung

Wenn du ECS Exec für Fargate-Aufgaben verwendest, erhältst du möglicherweise eine der folgenden Fehlermeldungen:

• „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.“

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Um häufig auftretende Fehler zu beheben, die auftreten, wenn du ECS Exec für Fargate-Aufgaben verwendest, empfiehlt es sich, AWS CloudShell zu verwenden. CloudShell ist beim AWS Systems Manager Session Manager Agent (SSM Agent) und bei der AWS CLI vorinstalliert.

InvalidParameterException-Fehler

Wenn die Option ExecuteCommand für Fargate-Aufgabe deaktiviert ist, erhältst du den InvalidParameterException-Fehler.

Gehe wie folgt vor, um dieses Problem zu beheben:

1. Führe den Befehl describe-tasks aus, um zu überprüfen, ob der Parameter enableExecuteCommand auf true (wahr) oder false (falsch) gesetzt ist:

   aws ecs describe-tasks --cluster example-cluster-name --tasks example-task-id| grep enableExecuteCommand

   Hinweis: Ersetze example-cluster-name durch deinen Cluster und example-task-id durch deine Aufgaben-ID.
2. Wenn der Parameter enableExecuteCommand den Wert false hat, führe den folgenden update-service-Befehl aus, um den Parameter auf true zu aktualisieren:

   aws ecs update-service --cluster example-cluster-name --service example-service --region example-region --enable-execute-command --force-new-deployment

   Hinweis: Ersetze example-cluster-name durch deinen Cluster, example-service durch deinen Service und example-region durch deine AWS-Region. Die Option force-new-deployment erstellt eine neue Bereitstellung, bei der neue Aufgaben gestartet und frühere Aufgaben auf der Grundlage der Bereitstellungskonfiguration des Service beendet werden. Wenn die Services eine Blau/Grün-Bereitstellung über AWS CodeDeploy verwenden, initiiere statt force-new-deployment eine CODE_DEPLOY-Bereitstellung. Du kannst force-new-deployment nicht für die Blau/Grün-Bereitstellung verwenden, da diese Option ein fortlaufendes Update startet.
3. Führe den folgenden Befehl describe-tasks aus, um den Status von ExecuteCommandAgent zu überprüfen:

   aws ecs describe-tasks --cluster example-cluster-name --tasks example-task-id | grep -A 6 managedAgents

   Hinweis: Ersetze example-cluster-name durch deinen Cluster und example-task-id durch deine Aufgaben-ID.
4. Überprüfe die Ausgabe des Befehls, um den Status des ExecuteCommand-Agent zu überprüfen. Wenn der lastStatus von ExecuteCommandAgent nicht RUNNING lautet, überprüfe die ExecuteCommandAgent-Agent-Protokolle, um die Ursache zu ermitteln. Fahre mit dem Abschnitt Generieren von Protokollen für ECS Exec fort, um Schritte zur Problembehandlung zu identifizieren und die ExecuteCommandAgent-Protokolle zu generieren.
   Wenn ExecuteCommandAgent keine Anmeldeinformationen abrufen kann, weil du einen Proxy im Container konfiguriert hast, füge die folgende NO_PROXY-Option zu den Container-Instance-Konfigurationsdateien hinzu:

   env no_proxy=169.254.169.254,169.254.170.2

TargetNotConnectedExceptionerror

Gehe wie folgt vor, um einen TargetNotConnectionException-Fehler zu beheben.

Erforderliche Berechtigungen hinzufügen und bestätigen, dass die Netzwerkkonfiguration korrekt ist

Führe die folgenden Schritte aus:

1. Füge die erforderlichen Berechtigungen zur AWS Identity and Access Management (IAM, Identitäts- und Zugriffsmanagement)-Rolle der Amazon ECS-Aufgabe hinzu. Wenn die Aufgaben-IAM-Rolle bereits über die erforderlichen Berechtigungen verfügt, überprüfe, ob Service-Kontrollrichtlinien (Service Control Policies, SCPs) die Verbindung der Aufgabe zum SSM-Agent blockieren.
2. Wenn du Amazon Virtual Private Cloud (Amazon VPC)-Schnittstellenendpunkte mit Amazon ECS verwendest, erstelle die folgenden Endpunkte:
   ec2messages.region.amazonaws.com
   ssm.region.amazonaws.com
   ssmmessages.region.amazonaws.com
   Hinweis: Ersetze region durch deine Region.
3. Führe das Skript check-ecs-exec.sh aus, um zu bestätigen, dass die AWS CLI-Umgebung und Amazon ECS-Cluster oder -Aufgaben für Amazon ECS Exec bereit sind. Informationen zu Voraussetzungen und zur Verwendung findest du unter Amazon ECS Exec Checker auf der GitHub-Website.
   Die Ausgabe des Skripts check-ecs-exec.sh zeigt, was du lösen musst, bevor du ECS Exec verwendest. Beispielausgabe:

   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

   Die vorherige Ausgabe zeigt, dass ECS Exec für die Aufgabe deaktiviert ist und dass die Aufgabenrolle nicht über die erforderlichen Systems Manager-Berechtigungen verfügt. Hinweis: Du musst den Parameter ReadonlyRootFilesystem in der Aufgabendefinition auf false setzen, um ECS Exec auszuführen. Wenn ReadonlyRootFileSystem den Wert true hat, kann der SSM-Agent die erforderlichen Verzeichnisse nicht erstellen.

Prüfe, ob du IAM-Benutzeranmeldeinformationen auf Container-Ebene konfiguriert hast, z. B. einen Zugriffsschlüssel oder einen geheimen Zugriffsschlüssel. Der SSM-Agent verwendet das AWS SDK für Java, wenn er die Authentifizierung überprüft. Wenn du den Zugriffsschlüssel oder den geheimen Zugriffsschlüssel in der Container-Instance als Umgebungsvariablen konfigurierst, setze die Berechtigungen auf Aufgabenebene außer Kraft. Um ECS Exec verwenden zu können, müssen die IAM-Anmeldeinformationen auf Container-Ebene Berechtigungen für den SSM-Agent bereitstellen.

ECS Exec verwenden, um mit der richtigen Shell in den Container zu gelangen

Verschiedene Basis-Images können unterschiedliche Shells enthalten. Wenn du die falsche Shell verwendest, erhältst du Fehlermeldungen. Stelle sicher, dass du die richtige Shell gemäß deinem Anwendungs-Image verwendest.

Um ECS Exec zu verwenden, um in den Container zu gelangen, führe den Befehl execute-command aus:

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

Hinweis: Ersetze example-region durch deine Region, example-cluster durch deinen Cluster-Namen, example-container durch deinen Container-Instance-Namen und example-task durch deinen Aufgabennamen.

Protokolle für ECS Exec generieren, um Probleme zu identifizieren

Um festzustellen, warum ECS Exec nicht funktioniert, führe den folgenden Befehl im Umgebungsabschnitt der Container-Definition aus, um SSM Agent-Protokolle zu generieren:

Konsole:

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"

Hinweis: Unterschiedliche Anwendungen verfügen über unterschiedliche Shells und Editoren. Passe die obigen Befehlsparameter an die Anforderungen deiner Anwendung an.

Wenn du den Protokolltreiber awslogs verwendest, generieren die vorherigen Befehle SSM-Agent-Protokolle und übertragen sie an die Amazon CloudWatch-Protokollgruppe. Wenn du andere Protokolltreiber oder Protokollierungsendpunkte verwendest, werden die Protokolle des SSM-Agent an diese Speicherorte übertragen.

Beispiel JSON:

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

Ähnliche Informationen

Verwenden von ECS Exec