# Monitoramento de contêineres do Amazon ECS com o ECS Exec Com o Amazon ECS Exec, você pode interagir diretamente com contêineres sem precisar interagir primeiro com o sistema operacional do contêiner do host, abrir portas de entrada ou gerenciar chaves SSH. É possível usar o ECS Exec para executar comandos em ou obter um shell para um contêiner em execução em uma instância do Amazon EC2 ou no AWS Fargate. Isso facilita a coleta de informações de diagnóstico e a solução rápida de problemas. Por exemplo, em um contexto de desenvolvimento, você pode usar o ECS Exec para interagir facilmente com vários processos nos contêineres e solucionar problemas das aplicações. Além disso, em cenários de produção, você pode usá-lo para obter acesso imediato aos contêineres para depurar problemas. É possível executar comandos em um contêiner Linux ou Windows em execução usando o ECS Exec na API do Amazon ECS, no AWS Command Line Interface (AWS CLI), nos AWS SDKs ou na CLI do AWS Copilot. Para obter detalhes sobre como usar o ECS Exec, além de uma demonstração em vídeo, utilizando a CLI do AWS Copilot, consulte a [documentação do GitHub sobre o Copilot](https://aws.github.io/copilot-cli/docs/commands/svc-exec/). Além disso, é possível usar o ECS Exec para manter as políticas de controle de acesso mais rígidas. Ao ativar seletivamente esse recurso, você pode controlar quem pode executar comandos e em quais tarefas eles podem executar estes comandos. Com um log de cada comando e a saída correspondente, é possível usar o ECS Exec para visualizar quais tarefas foram executadas e usar o CloudTrail para auditar as pessoas que acessaram um contêiner. ## Considerações Considere o seguinte ao usar o ECS Exec: + O ECS Exec pode não funcionar conforme o esperado quando executado em sistemas operacionais que não são compatíveis com o Systems Manager. Para obter mais informações sobre os sistemas operacionais compatíveis, consulte [Tipos de sistemas operacionais](https://docs.aws.amazon.com/systems-manager/latest/userguide/operating-systems-and-machine-types.html#prereqs-os-linux) no *Guia do usuário do AWS Systems Manager*. + Há suporte para o ECS Exec para tarefas executadas na infraestrutura a seguir: + Contêineres Linux no Amazon EC2 em qualquer AMI otimizada para Amazon ECS, incluindo Bottlerocket + Contêineres do Linux e Windows em instâncias externas (Amazon ECS Anywhere) + Contêineres Linux e Windows no AWS Fargate + Contêineres Windows no Amazon EC2 nas AMIs otimizadas para Amazon ECS do Windows (com a versão do agente de contêiner `1.56` ou posterior): + AMI do Windows Server 2022 Full otimizada para Amazon ECS + AMI do Windows Server 2022 Core otimizada para Amazon ECS + AMI do Windows Server 2019 Full otimizada para Amazon ECS + AMI do Windows Server 2019 Core otimizada para Amazon ECS + AMI do Windows Server 20H2 Core otimizada para Amazon ECS + Se você configurou um proxy HTTP para sua tarefa, defina a variável de ambiente `NO_PROXY` como `"NO_PROXY=169.254.169.254,169.254.170.2"` para ignorar o proxy para metadados da instância do EC2 e tráfego de perfil do IAM. Se você não configurar a variável de ambiente `NO_PROXY`, poderá haver falhas ao recuperar metadados da instância ou credenciais do perfil do IAM do endpoint de metadados dentro do contêiner. Definir a variável de ambiente `NO_PROXY` conforme recomendado filtra os metadados e o tráfego do IAM para que as solicitações a `169.254.169.254 and 169.254.170.2` não passem pelo proxy `HTTP`. + ECS Exec e Amazon VPC + Se você estiver usando endpoints da Amazon VPC de interface com o Amazon ECS, deverá criar os endpoints da Amazon VPC da interface para o Gerenciador de Sessões do Systems Manager (`ssmmessages`). Para obter mais informações sobre endpoints da VPC do Systems Manager, consulte [Uso de AWS PrivateLink para configurar um endpoint da VPC para o Gerenciador de Sessões](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-privatelink.html) no *Guia do usuário do AWS Systems Manager*. + Se você estiver usando endpoints do Amazon VPC de interface com o Amazon ECS e estiver usando o AWS KMS key para criptografia, deverá criar o endpoint do Amazon VPC da interface para o AWS KMS key. Para obter mais informações, consulte [Conexão com o AWS KMS key usando um endpoint da VPC](https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html) no *Guia do desenvolvedor do AWS Key Management Service*. + Quando tiver tarefas executadas em instâncias do Amazon EC2, use o modo de rede `awsvpc`. Caso não tenha acesso à internet, como ausência de configuração para usar um gateway NAT, você deve criar os endpoints de interface da Amazon VPC para o Gerenciador de Sessões do Systems Manager (`ssmmessages`). Para obter mais informações sobre considerações a respeito do modo de rede `awsvpc`, consulte [Considerações](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking-awsvpc.html#linux). Para obter mais informações sobre endpoints da VPC do Systems Manager, consulte [Uso de AWS PrivateLink para configurar um endpoint da VPC para o Gerenciador de Sessões](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-privatelink.html) no *Guia do usuário do AWS Systems Manager*. + Não há suporte para o Amazon ECS Exec em tarefas executadas em uma configuração somente IPv6. Para obter mais informações sobre a execução de tarefas em uma configuração somente IPv6, consulte [Opções de redes de tarefas do Amazon ECS para o Fargate](fargate-task-networking.md) e [Opções da rede de tarefas do Amazon ECS para o EC2](task-networking.md). + ECS Exec e SSM + Quando um usuário executa comandos em um contêiner usando o ECS Exec, estes comandos são executados como o usuário `root`. O SSM Agent e seus processos filho são executados como raiz mesmo quando você especifica um ID de usuário para o contêiner. + O agente SSM exige que o sistema de arquivos de contêiner possa ser gravado para criar os diretórios e arquivos necessários. Portanto, não existe suporte para a ação de tornar o sistema de arquivos raiz somente leitura usando o parâmetro de definição de tarefa `readonlyRootFilesystem` ou qualquer outro método. + Embora iniciar sessões do SSM fora da ação `execute-command` seja possível, isso fará com que as sessões não sejam registradas e contadas em relação ao limite da sessão. Recomendamos limitar esse acesso ao negar a ação `ssm:start-session` usando uma política do IAM. Para obter mais informações, consulte [Limitar o acesso à ação Iniciar sessão](#ecs-exec-limit-access-start-session). + Os recursos a seguir são executados como contêiner auxiliar. Portanto, você deve especificar o nome do contêiner no qual executar o comando. + Monitoramento de runtime + Service Connect + Os usuários podem executar todos os comandos disponíveis no contexto do contêiner. As seguintes ações podem resultar em processos órfãos e zumbis: encerramento do processo principal do contêiner, encerramento do agente de comando e exclusão de dependências. Para limpar os processos zumbis, recomendamos a adição do sinalizador `initProcessEnabled` à definição da tarefa. + O ECS Exec usa um pouco de CPU e memória. Recomendamos que isso seja previsto quando você especificar as alocações de recursos de CPU e memória na definição da tarefa. + Você deve estar usando a AWS CLI versão `1.22.3` ou posterior ou a AWS CLI versão `2.3.6` ou posterior. Para obter informações sobre como atualizar a AWS CLI, consulte [Instalação ou atualização da versão mais recente da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) no *Guia do usuário da AWS Command Line Interface versão 2*. + É possível ter somente uma sessão do ECS Exec por namespace de ID de processo (PID). Se você estiver [compartilhando um namespace de PID em uma tarefa](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#other_task_definition_params), só poderá iniciar sessões do ECS Exec em um contêiner. + A sessão do ECS Exec tem um tempo limite de ociosidade de 20 minutos. Esse valor não pode ser alterado. + Não é possível ativar o ECS Exec para tarefas existentes. Ele só pode ser ativado para novas tarefas. + Não é possível usar o ECS Exec ao utilizar `run-task` para executar uma tarefa em um cluster que usa escalabilidade gerenciada com posicionamento assíncrono (executar uma tarefa sem instância). + Não é possível executar o ECS Exec em contêineres do Microsoft Nano Server. ## Arquitetura O ECS Exec faz uso do gerenciador de sessão do AWS Systems Manager (SSM) para estabelecer uma conexão com o contêiner em execução e usa políticas do AWS Identity and Access Management (IAM) para controlar o acesso a comandos em execução em um contêiner em execução. Isso é possível por meio de uma montagem bind dos binários necessários do SSM Agent no contêiner. O Amazon ECS ou o agente do AWS Fargate é responsável por iniciar o agente central do SSM no interior do contêiner juntamente com o código da aplicação. Para obter mais informações, consulte [Gerenciador de sessão do Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html). É possível auditar qual usuário acessou o contêiner por meio do evento `ExecuteCommand` no AWS CloudTrail e registrar em log cada comando (e suas saídas) no Amazon S3 ou no Amazon CloudWatch Logs. Para criptografar dados entre o cliente local e o contêiner com sua própria chave de criptografia, você deve fornecer a chave do AWS Key Management Service (AWS KMS). ## Configurar o ECS Exec Para usar o ECS Exec, primeiro é necessário ativar o recurso para suas tarefas e serviços e, em seguida, executar comandos em seus contêineres. ### Alterações opcionais de definição de tarefa Se você definir o parâmetro de definição de tarefa `initProcessEnabled` como `true`, o processo de inicialização dentro do contêiner será iniciado. Isso remove todos os processos filho do agente SSM zumbi encontrados. A seguir, é fornecido um exemplo. ``` { "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" } ``` ### Ativar o ECS Exec para tarefas e serviços É possível ativar o recurso ECS Exec para seus serviços e tarefas autônomas especificando o sinalizador `--enable-execute-command` quando usar um dos comandos a seguir da AWS CLI: [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), [https://docs.aws.amazon.com/cli/latest/reference/ecs/start-task.html](https://docs.aws.amazon.com/cli/latest/reference/ecs/start-task.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). Por exemplo, se você executar o comando a seguir, o recurso ECS Exec será ativado em um serviço recém-criado executado no Fargate. Para obter mais informações sobre como criar serviços, consulte [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 ``` Depois de ativar o ECS Exec para uma tarefa, execute o comando a seguir para confirmar se a tarefa está pronta para ser usada. Se a propriedade `lastStatus` do `ExecuteCommandAgent` estiver listada como `RUNNING` e a propriedade `enableExecuteCommand` estiver definida como `true`, a tarefa estará pronta. ``` aws ecs describe-tasks \ --cluster cluster-name \ --tasks task-id ``` O seguinte trecho de saída é um exemplo do que pode ser visualizado. ``` { "tasks": [ { ... "containers": [ { ... "managedAgents": [ { "lastStartedAt": "2021-03-01T14:49:44.574000-06:00", "name": "ExecuteCommandAgent", "lastStatus": "RUNNING" } ] } ], ... "enableExecuteCommand": true, ... } ] } ``` ### Executar comandos usando ECS Exec ## Registro em log usando o ECS Exec É possível configurar o registro em log para sessões do ECS Exec para capturar comandos e suas saídas para fins de auditoria e solução de problemas. ### Ativação do registro em log em tarefas e serviços **Importante** Para obter mais informações sobre os preços do CloudWatch, consulte [Preço do CloudWatch](https://aws.amazon.com/cloudwatch/pricing/). O Amazon ECS também fornece métricas de monitoramento, fornecidas sem custo adicional. Para obter mais informações, consulte [Monitoramento do Amazon ECS usando o CloudWatch](cloudwatch-metrics.md). O Amazon ECS fornece uma configuração padrão para registrar em log os comandos executados usando o ECS Exec. O padrão é enviar logs ao CloudWatch Logs utilizando o driver de log `awslogs` configurado na definição da tarefa. Se você quiser fornecer uma configuração personalizada, a AWS CLI oferecerá suporte ao sinalizador `--configuration` para os comandos `create-cluster` e `update-cluster`. A imagem de contêiner exige que `script` e `cat` estejam instalados para que os logs de comando sejam carregados corretamente no Amazon S3 ou no CloudWatch Logs. Para obter mais informações sobre como criar clusters, consulte [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-cluster.html). **nota** Essa configuração só lida com o registro da sessão `execute-command`. Isso não afeta o registro da aplicação. O exemplo a seguir cria um cluster e, em seguida, registra a saída no seu LogGroup do CloudWatch Logs denominado `cloudwatch-log-group-name` e no bucket do Amazon S3 denominado `s3-bucket-name`. Você deve usar uma chave gerenciada pelo cliente do AWS KMS para criptografar o grupo de log quando definir a opção `CloudWatchEncryptionEnabled` como `true`. Para obter informações sobre como criptografar o grupo de log, consulte [Criptografe dados de log no CloudWatch Logs usando AWS Key Management Service](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html#encrypt-log-data-kms-policy), no *Manual usuário do Amazon CloudWatch Logs*. ``` 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 \ } \ }" ``` A propriedade `logging` determina o comportamento da capacidade de registro do ECS Exec: + `NONE`: o registro em log está desativado. + `DEFAULT`: os logs são enviados ao driver `awslogs` configurado. Se o driver não estiver configurado, nenhum log será salvo. + `OVERRIDE`: os logs são enviados ao LogGroup do Amazon CloudWatch Logs fornecido, ao bucket do Amazon S3 ou a ambos. ### Permissões do IAM necessárias para registros no Amazon CloudWatch Logs ou no Amazon S3 Para ativar o registro, a função de tarefa do Amazon ECS referenciada na definição de tarefa precisa ter permissões adicionais. Essas permissões adicionais podem ser acrescentadas como uma política para o perfil de tarefa. Elas são diferentes, dependendo de você direcionar seus logs para o Amazon CloudWatch Logs ou para o Amazon S3. ------ #### [ Amazon CloudWatch Logs ] O exemplo de política a seguir adiciona as permissões necessárias do Amazon CloudWatch Logs. **** ``` { "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 ] O exemplo de política a seguir adiciona as permissões necessárias do Amazon S3. **** ``` { "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/*" } ] } ``` ------ ### Permissões do IAM necessárias para criptografia usando sua própria AWS KMS key (chave do KMS) Por padrão, os dados transferidos entre o cliente local e o contêiner usam a criptografia TLS 1.2 que a AWS fornece. Para criptografar ainda mais os dados usando sua própria chave do KMS, crie uma chave do KMS e adicione a permissão `kms:Decrypt` à função do IAM da tarefa. Essa permissão é usada pelo contêiner para descriptografar os dados. Para obter mais informações sobre a criação de uma chave do KMS, consulte [Criar chaves](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html). Você adiciona a seguinte política em linha ao perfil do IAM de tarefa, que requer as permissões AWS KMS. Para obter mais informações, consulte [Permissões do 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" } ] } ``` ------ Para que os dados sejam criptografados com a própria chave do KMS, o usuário ou grupo que está usando a ação `execute-command` deve receber a permissão `kms:GenerateDataKey`. O exemplo de política a seguir para o usuário ou grupo contém a permissão necessária pra o uso da própria chave do KMS. É necessário especificar o nome do recurso da Amazon (ARN) da chave do 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" } ] } ``` ------ ## Uso de políticas do IAM para limitar o acesso ao ECS Exec Você limita o acesso do usuário à ação da API execute-command usando uma ou mais das seguintes chaves de condição de política do IAM: + `aws:ResourceTag/clusterTagKey` + `ecs:ResourceTag/clusterTagKey` + `aws:ResourceTag/taskTagKey` + `ecs:ResourceTag/taskTagKey` + `ecs:container-name` + `ecs:cluster` + `ecs:task` + `ecs:enable-execute-command` Com o exemplo de política do IAM a seguir, os usuários podem executar comandos em contêineres que estão sendo executados em tarefas com uma etiqueta que tenha a chave `environment` e o valor `development` em um cluster denominado `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" } } } ] } ``` ------ Com o exemplo de política do IAM a seguir, os usuários não podem usar a API `execute-command` quando o nome do contêiner é `production-app`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "ecs:ExecuteCommand" ], "Resource": "*", "Condition": { "StringEquals": { "ecs:container-name": "production-app" } } } ] } ``` ------ Com a seguinte política do IAM, os usuários só podem iniciar tarefas quando o ECS Exec estiver desativado. ------ #### [ 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" } } } ] } ``` ------ **nota** Como ação da API `execute-command` contém apenas recursos de tarefa e cluster em uma solicitação, somente etiquetas de cluster e tarefa são avaliadas. Para obter mais informações sobre essas chaves de condição de política do IAM, consulte [Ações, recursos e chaves de condição do Amazon Elastic Container Service](/service-authorization/latest/reference/list_amazonelasticcontainerservice.html) na *Referência de autorização do serviço*. ### Limitar o acesso à ação Iniciar sessão Embora seja possível iniciar sessões do SSM no contêiner fora do ECS Exec, isso poderá fazer com que as sessões não sejam registradas. As sessões iniciadas fora do ECS Exec também são consideradas na cota de sessão. Recomendamos que esse acesso seja limitado negando diretamente a ação `ssm:start-session` para as tarefas do Amazon ECS que usam uma política do IAM. É possível negar acesso a todas as tarefas do Amazon ECS ou a tarefas específicas com base nas etiquetas usadas. Veja a seguir um exemplo de política do IAM que nega acesso à ação `ssm:start-session` para tarefas em todas as regiões com um nome de cluster especificado. Opcionalmente, é possível incluir um curinga com o `cluster-name`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ssm:StartSession", "Resource": [ "arn:aws:ecs:us-east-1:111122223333:task/cluster-name/*" ] } ] } ``` ------ Veja a seguir um exemplo de política do IAM que nega acesso à ação `ssm:start-session` em recursos em todas as regiões marcadas com chave de etiqueta `Task-Tag-Key` e valor de etiqueta `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" } } } ] } ``` ------ ## Solucionar problemas do ECS Exec Para procedimentos adicionais de soluções de problemas, consulte [Solucionar problemas do Exec](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec-troubleshooting.html). # Executar comandos usando ECS Exec É possível usar o Amazon ECS Exec para coletar informações de diagnóstico relacionadas aos contêineres e solucionar erros encontrados durante todo o ciclo de vida dos contêineres. ## Pré-requisitos Antes de começar a usar o ECS Exec, conclua as seguintes ações: + Revise as considerações. Para obter mais informações, consulte . [Considerações](ecs-exec.md#ecs-exec-considerations) + Configure o ECS Exec para tarefas e serviços. Para obter mais informações, consulte . [Configurar o ECS Exec](ecs-exec.md#ecs-exec-enabling-and-using) + **Instale e configure a AWS CLI**. Para obter mais informações, consulte [Conceitos básicos do AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html). + **Instale o plugin do gerenciador de sessão para a AWS CLI**. Para obter mais informações, consulte [Instalar o plugin do gerenciador de sessão para a AWS CLI](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html). + **Configure um perfil de tarefa com as permissões apropriadas**. Você deve usar um perfil de tarefa com as permissões apropriadas para o ECS Exec. Para obter mais informações, consulte [Perfil do IAM de tarefa](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html). + **Verifique os requisitos da versão**. O ECS Exec tem requisitos de versão que dependem das suas tarefas estarem hospedadas no Amazon EC2 ou no AWS Fargate: + Se você estiver usando o Amazon EC2, deverá usar uma AMI otimizada para Amazon ECS que tenha sido lançada após 20 de janeiro de 2021, com a versão 1.50.2 ou superior do agente. Para obter mais informações consulte [AMIs otimizadas para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html). + Se você estiver usando o AWS Fargate, deverá usar a versão `1.4.0` ou superior (Linux) ou `1.0.0` (Windows) da plataforma. Para obter mais informações, consulte [Versões da plataforma do AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform-fargate.html). ## Usar o console para tarefas de serviço É possível usar o console para executar comandos com o ECS Exec. 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, escolha o cluster. 1. Na página de detalhes do cluster, na seção **Serviços**, escolha o serviço. A página de detalhes do serviço é exibida. 1. Na página de detalhes da implantação, escolha **Tarefas**. Em seguida, escolha a função. 1. Em **Contêineres**, escolha o contêiner em que deseja usar o ECS Exec. 1. Para executar comandos, siga uma destas opções: + Selecione **Conectar**. Uma sessão do CloudShell mostra onde você pode executar seus comandos. + Escolha a seta e, em seguida, escolha **Copiar comando da AWS CLI**. Você poderá então executar os comandos localmente. **Resultados esperados** Se a conexão for bem-sucedida, você deverá ver um prompt de shell interativo do contêiner. Você agora pode executar comandos diretamente no ambiente do contêiner. Para sair da sessão, escolha o botão **Encerrar sessão**. ## Usar o console para tarefas autônomas É possível usar o console para executar comandos com o ECS Exec. 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, escolha o cluster. 1. Na página de detalhes do cluster, na seção **Tarefas**, escolha a tarefa. A página de detalhes da tarefa é exibida. 1. Em **Contêineres**, escolha o contêiner em que deseja usar o ECS Exec. 1. Para executar comandos, siga uma destas opções: + Selecione **Conectar**. Uma sessão do CloudShell mostra onde você pode executar seus comandos. + Escolha a seta e, em seguida, escolha **Copiar comando da AWS CLI**. Você poderá então executar os comandos localmente. **Resultados esperados** Se a conexão for bem-sucedida, você deverá ver um prompt de shell interativo do contêiner. Você agora pode executar comandos diretamente no ambiente do contêiner. Para sair da sessão, escolha o botão **Encerrar sessão**. ## Usar o shell de comandos É possível usar o shell de comandos para executar comandos com o ECS Exec. Depois de ter confirmado que o `ExecuteCommandAgent` está em execução, você pode abrir um shell interativo no contêiner usando o comando a seguir. Se a tarefa contiver vários contêineres, você deverá especificar o nome do contêiner usando o sinalizador `--container`. O Amazon ECS só oferece suporte à inicialização de sessões interativas Portanto, você deve usar o sinalizador `--interactive`. O comando a seguir executará um comando `/bin/sh` interativo em um contêiner denominado **container-name** para uma tarefa com o ID *task-id*. O *task-id* é o nome do recurso da Amazon (ARN) da tarefa. ``` aws ecs execute-command --cluster cluster-name \ --task task-id \ --container container-name \ --interactive \ --command "/bin/sh" ``` **Resultados esperados** Se o comando for bem-sucedido, você deverá ver um prompt de shell interativo do contêiner. Você agora pode executar comandos diretamente no ambiente do contêiner. Para sair da sessão, digite `exit` ou pressione `Ctrl+D`.