Salta al contenuto

Come posso risolvere gli errori che ricevo quando utilizzo ECS Exec nelle mie attività Fargate?

7 minuti di lettura
0

Desidero risolvere gli errori che ricevo quando utilizzo Amazon Elastic Container Service (Amazon ECS) Exec nelle mie attività AWS Fargate.

Risoluzione

Nota: se ricevi errori quando esegui i comandi dell'Interfaccia della linea di comando AWS (AWS CLI), consulta Risoluzione degli errori per AWS CLI. Inoltre, assicurati di utilizzare la versione più recente di AWS CLI.

Quando utilizzi ECS Exec in attività Fargate, potresti ricevere uno dei seguenti messaggi di errore:

  • "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."

È consigliabile utilizzare AWS CloudShell per risolvere i problemi relativi a ECS Exec in attività Fargate. CloudShell è preinstallato con l'Agente AWS Systems Manager (Agente SSM) e AWS CLI.

Errore InvalidParameterException

Se l'opzione ExecuteCommand per l'attività Fargate è disattivata, ricevi l'errore InvalidParameterException.

Per risolvere il problema, completa i seguenti passaggi:

  1. Esegui il comando describe-tasks per verificare se il parametro enableExecuteCommand è impostato su true o false:

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

    Nota: sostituisci example-cluster-name con il tuo cluster e example-task-id con l'ID della tua attività.

  2. Se il parametro enableExecuteCommand è impostato su false, esegui questo comando update-service per impostarlo su true:

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

    Nota: sostituisci example-cluster-name con il tuo cluster, example-service con il tuo servizio ed example-region con la tua Regione AWS. L'opzione force-new-deployment crea una nuova distribuzione che avvia nuove attività e interrompe quelle precedenti in base alla configurazione di distribuzione del servizio. Se i servizi utilizzano un'implementazione blu/verde tramite AWS CodeDeploy, avvia una distribuzione CODE_DEPLOY invece di force-new-deployment. Non puoi utilizzare **force-new-deployment ** per un'implementazione blu/verde perché una distribuzione forzata avvia un aggiornamento progressivo.

  3. Esegui questo comando describe-tasks per verificare lo stato di ExecuteCommandAgent:

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

    Nota: sostituisci example-cluster-name con il tuo cluster e example-task-id con l'ID della tua attività.

  4. Controlla nell'output del comando lo stato dell'agente ExecuteCommand. Se l'ultimo stato (lastStatus) di ExecuteCommandAgent non è RUNNING (In esecuzione), controlla i log dell'agente ExecuteCommandAgent per identificare la causa principale. Procedi con i passaggi di risoluzione riportati in Identifica i problemi generando log per ECS Exec per generare i log di ExecuteCommandAgent.

    Se ExecuteCommandAgent non riesce a recuperare le credenziali perché hai configurato un proxy nel container, aggiungi la seguente opzione NO_PROXY ai file di configurazione dell'istanza di container:

    env no_proxy=169.254.169.254,169.254.170.2

Errore TargetNotConnectedException

Per risolvere un errore TargetNotConnectionException, intraprendi le seguenti azioni.

Aggiungi le autorizzazioni richieste e convalida la configurazione di rete

Completa i seguenti passaggi:

  1. Aggiungi le autorizzazioni richieste al ruolo AWS Identity and Access Management (AWS IAM) dell'attività Amazon ECS. Se il ruolo IAM dell'attività ha già le autorizzazioni richieste, assicurati che le policy di controllo dei servizi (SCP) non blocchino la connessione dell'attività all'Agente SSM.
  2. Se con Amazon ECS utilizzi endpoint Amazon Virtual Private Cloud (Amazon VPC) di interfaccia, crea i seguenti endpoint:
    ec2messages.region.amazonaws.com
    ssm.region.amazonaws.com
    ssmmessages.region.amazonaws.com
    Nota: sostituisci region con la tua Regione.
  3. Per verificare che l'ambiente di AWS CLI e il cluster o l'attività Amazon ECS siano pronti per ECS Exec, esegui lo script check-ecs-exec.sh. L'output dello script check-ecs-exec.sh mostra cosa devi risolvere prima di utilizzare ECS Exec. Per informazioni sui prerequisiti e sull'utilizzo, consulta Amazon ECS Exec Checker sul sito web GitHub.
    L'esempio di output mostra che ECS Exec è disattivato per l'attività e che il ruolo dell'attività non ha le autorizzazioni di Systems Manager richieste:
    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
    Nota: per eseguire ECS Exec, devi impostare il parametro ReadonlyRootFilesystem su false nella definizione dell'attività. Se ReadonlyRootFileSystem è impostato su true, l'Agente SSM non può creare le directory richieste.
  4. Verifica se hai configurato le credenziali dell'utente IAM a livello di container, ad esempio una chiave di accesso o una chiave di accesso segreta.
    Nota: l'Agente SSM utilizza AWS SDK per Java quando verifica l'autenticazione. Se configuri la chiave di accesso o la chiave di accesso segreta nell'istanza di container come variabili di ambiente, escludi le autorizzazioni a livello di attività. Per utilizzare ECS Exec, le credenziali IAM a livello di container devono fornire le autorizzazioni per l'Agente SSM.
  5. Nella definizione dell'attività, verifica che pidMode non sia impostato su task.
    Nota: puoi avere una sola sessione ECS Exec per ogni namespace degli ID di processo (PID). Se condividi un namespace PID in un'attività, puoi avviare le sessioni ECS Exec in un solo container.

Utilizza Amazon ECS Exec per entrare nel container con la shell corretta

Immagini di base diverse possono avere al loro interno shell diverse. Se utilizzi la shell sbagliata, ricevi errori. Assicurati di utilizzare la shell corretta in base all'immagine dell'applicazione.

Per accedere al container utilizzando ECS Exec, esegui il comando execute-command:

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

Nota: sostituisci example-region con la tua Regione, example-cluster con il nome del tuo cluster, example-container con il nome della tua istanza di container e example-task con il nome della tua attività.

Identifica i problemi generando log per ECS Exec

Per generare i log dell'Agente SSM con informazioni sul motivo per cui ECS Exec non funziona, esegui questo comando nella sezione ambiente della definizione del container.

Comando da console:

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

Comando JSON:

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

Nota: applicazioni diverse hanno shell ed editor diversi. Modifica i parametri del comando precedente in base ai requisiti dell'applicazione.

Se utilizzi il driver di log awslogs, i comandi precedenti generano i log dell'Agente SSM e li trasferiscono al gruppo di log di Amazon CloudWatch. Se utilizzi altri driver di log o endpoint di registrazione, i log dell'Agente SSM vengono trasferiti a tali posizioni.

Esempio di JSON:

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