# Supervisión de los contenedores de Amazon ECS con ECS Exec Con Amazon ECS Exec, puede interactuar directamente con los contenedores sin necesidad de interactuar primero con el sistema operativo del contenedor host, abrir puertos entrantes o administrar claves SSH. Puede utilizar ECS Exec para ejecutar comandos en un contenedor u obtener un shell en un contenedor que se ejecute en una instancia de Amazon EC2 o en AWS Fargate. Esto facilita la recopilación de información de diagnóstico y la rápida resolución de problemas. Por ejemplo, en un contexto de desarrollo, puede utilizar ECS Exec para interactuar fácilmente con varios procesos de los contenedores y solucionar problemas de las aplicaciones. Y, en escenarios de producción, puede utilizarlo para obtener acceso a los contenedores con el fin de depurar problemas. Para ejecutar comandos en un contenedor de Linux o Windows en ejecución, puede utilizar ECS Exec desde la API de Amazon ECS, la AWS Command Line Interface (AWS CLI), el SDK de AWS o la CLI de AWS Copilot. Para obtener más información acerca del uso de ECS Exec, así como una explicación en video de cómo se utiliza la CLI de AWS Copilot, consulte la [Documentación de GitHub sobre Copilot](https://aws.github.io/copilot-cli/docs/commands/svc-exec/). ECS Exec también se puede utilizar para mantener políticas de control de acceso más estrictas. Al activar selectivamente esta función, puede controlar quiénes puede ejecutar comandos y en qué tareas pueden hacerlo. Con un registro de cada comando y su salida, puede utilizar ECS Exec para ver qué tareas se ejecutaron y CloudTrail para auditar quiénes accedieron a un contenedor. ## Consideraciones Tenga en cuenta lo siguiente al usar ECS Exec: + Es posible que ECS Exec no funcione como se esperaba cuando se ejecuta en sistemas operativos no compatibles con Systems Manager. Para obtener más información acerca de los sistemas operativos compatibles, consulte [Tipos de sistemas operativos](https://docs.aws.amazon.com/systems-manager/latest/userguide/operating-systems-and-machine-types.html#prereqs-os-linux) en la *AWS Systems Manager Guía del usuario*. + ECS Exec es compatible con las tareas que se ejecutan en la siguiente infraestructura: + Contenedores de Linux en Amazon EC2 en cualquier AMI optimizada para Amazon ECS, incluida Bottlerocket + Contenedores de Linux y Windows en instancias externas (Amazon ECS Anywhere) + Contenedores de Linux y Windows en AWS Fargate + Los contenedores de Windows de Amazon EC2 de las siguientes AMI optimizadas para Amazon ECS de Windows (con la versión `1.56` del agente de contenedor o una posterior): + AMI de Windows Server 2022 Full optimizada para Amazon ECS + AMI de Windows Server 2022 Core optimizada para Amazon ECS + AMI de Windows Server 2019 Full optimizada para Amazon ECS + AMI de Windows Server 2019 Core optimizada para Amazon ECS + AMI de Windows Server 20H2 Core optimizada para Amazon ECS + Si ha configurado un proxy HTTP para la tarea, defina la variable de entorno `NO_PROXY` como `"NO_PROXY=169.254.169.254,169.254.170.2"` para evitar el proxy para los metadatos de la instancia de EC2 y el tráfico del rol de IAM. Si no configura la variable de entorno `NO_PROXY`, es posible que se produzcan errores al recuperar los metadatos de la instancia o las credenciales del rol de IAM del punto de conexión de los metadatos del contenedor. Si se establece la variable de entorno en `NO_PROXY` como se recomienda, se filtran los metadatos y el tráfico de IAM para que las solicitudes `169.254.169.254 and 169.254.170.2` no pasen por el proxy `HTTP`. + ECS Exec y Amazon VPC + Si utiliza puntos de conexión de VPC de interfaz de Amazon ECS, debe crear los puntos de conexión de la interfaz de Amazon VPC para Systems Manager Session Manager (`ssmmessages`). Para obtener más información sobre los puntos de conexión de VPC de Systems Manager, consulte [Utilización de AWS PrivateLink para configurar un punto de conexión de VPC para Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-privatelink.html) en la *Guía del usuario de AWS Systems Manager*. + Si utiliza puntos de conexión de Amazon VPC de la interfaz con Amazon ECS y está utilizando AWS KMS key para el cifrado, debe crear el punto de conexión de Amazon VPC de la interfaz para AWS KMS key. Para obtener más información, consulte [Conexión a AWS KMS key a través de un punto de conexión de VPC](https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html) en la *Guía para desarrolladores de AWS Key Management Service*. + Cuando tenga tareas que se ejecuten en instancias de Amazon EC2, utilice el modo de red `awsvpc`. Si no tiene acceso a Internet (por ejemplo, no están configuradas para usar una puerta de enlace de NAT), debe crear los puntos de conexión de Amazon VPC de interfaz para el Administrador de sesiones de Systems Manager (`ssmmessages`). Para obtener más información sobre las consideraciones del modo de red `awsvpc`, consulte [Consideraciones](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking-awsvpc.html#linux). Para obtener más información sobre los puntos de conexión de VPC de Systems Manager, consulte [Utilización de AWS PrivateLink para configurar un punto de conexión de VPC para Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-privatelink.html) en la *Guía del usuario de AWS Systems Manager*. + Amazon ECS Exec no es compatible con las tareas que se ponen en marcha en una configuración de solo IPv6. Para obtener más información acerca de la puesta en marcha de tareas en una configuración de solo IPv6, consulte [Opciones de red de tareas de Amazon ECS para Fargate](fargate-task-networking.md) y [Opciones de red de tareas de Amazon ECS para EC2](task-networking.md). + ECS Exec y SSM + Cuando un usuario ejecuta comandos en un contenedor mediante ECS Exec, estos comandos se ejecutan como usuario `root`. SSM Agent y sus procesos secundarios se ejecutan como raíz incluso cuando se especifica un ID de usuario para el contenedor. + SSM Agent requiere que se pueda escribir en el sistema de archivos del contenedor para crear los directorios y archivos requeridos. Por lo tanto, no se admite que el sistema de archivos raíz se haga de solo lectura mediante el parámetro de definición de tareas `readonlyRootFilesystem` o cualquier otro método. + Si bien es posible iniciar sesiones de SSM fuera de la acción `execute-command`, esto hace que las sesiones no se registren ni se cuenten para el límite de sesiones. Recomendamos limitar este acceso a través de la denegación de la acción `ssm:start-session` mediante una política de IAM. Para obtener más información, consulte [Limitación del acceso a la acción Iniciar sesión](#ecs-exec-limit-access-start-session). + Las siguientes características funcionan como un contenedor sidecar. Por lo tanto, debe especificar el nombre del contenedor en el que se ejecutará el comando. + Supervisión en tiempo de ejecución + Service Connect + Los usuarios pueden ejecutar todos los comandos que están disponibles en el contexto del contenedor. Las siguientes acciones pueden dar lugar a procesos huérfanos y zombis: terminar el proceso principal del contenedor, terminar el agente de comando y eliminar dependencias. Para limpiar los procesos zombies, recomendamos agregar el indicador `initProcessEnabled` a la definición de tareas. + ECS Exec usa parte de la CPU y de la memoria. Deberá tenerlo en cuenta al especificar las asignaciones de recursos de memoria y CPU en la definición de tareas. + Debe utilizar la version de AWS CLI `1.22.3` o posterior o la version de AWS CLI `2.3.6` o posterior. Para obtener más información sobre como actualizar la AWS CLI, consulte [Instalación o actualización de la última versión de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) en la *Guía del usuario de AWS Command Line Interface versión 2*. + Solo puede tener una sesión de ECS Exec por espacio de nombres de ID de proceso (PID). Si [comparte un espacio de nombres PID en una tarea](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#other_task_definition_params), solo puede iniciar sesiones de ECS Exec en un contenedor. + La sesión de ECS Exec tiene un tiempo de espera de inactividad de 20 minutos. Este valor no se puede cambiar. + No se puede activar ECS Exec para tareas existentes. Solo se puede activar para tareas nuevas. + No puede utilizar ECS Exec cuando usa `run-task` para lanzar una tarea en un clúster que utiliza escalado administrado con ubicación asíncrona (lanzar una tarea sin instancia). + No se puede ejecutar ECS Exec en contenedores de Microsoft Nano Server. ## Arquitectura ECS Exec utiliza AWS Systems Manager Session Manager (SSM) para establecer una conexión con el contenedor en ejecución y las políticas de AWS Identity and Access Management (IAM) para controlar el acceso a comandos en ejecución en un contenedor en ejecución. Esto se logra mediante el montaje vinculado de los binarios de SSM Agent necesarios en el contenedor. El agente de Amazon ECS o de AWS Fargate es responsable de iniciar el agente principal de SSM dentro del contenedor junto con el código de la aplicación. Para obtener más información, consulte [Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html). Puede auditar qué usuarios accedieron al contenedor mediante el evento `ExecuteCommand` en AWS CloudTrail y registrar cada comando (y su resultado) en Amazon S3 o en los registros de Amazon CloudWatch. Para cifrar datos entre el cliente local y el contenedor con su propia clave de cifrado, debe proporcionar la clave de AWS Key Management Service (AWS KMS). ## Configuración de ECS Exec Para utilizar ECS Exec, primero debe activar la característica para sus tareas y servicios y, a continuación, puede ejecutar comandos en sus contenedores. ### Cambios opcionales en la definición de tareas Si establece el parámetro de definición de tareas `initProcessEnabled` en `true`, se inicia el proceso de inicio dentro del contenedor. Esto elimina cualquier proceso secundario zombi del agente de SSM encontrado. A continuación, puede ver un ejemplo. ``` { "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" } ``` ### Activación de ECS Exec para las tareas y los servicios Para activar la característica ECS Exec para los servicios y las tareas independientes, puede especificar el indicador `--enable-execute-command` cuando se utiliza uno de los siguientes comandos de la 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) o [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 ejemplo, si ejecuta el siguiente comando, la característica ECS Exec se activa para un servicio recién creado que se ejecuta en Fargate. Para obtener más información acerca de la creación de servicios, 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 ``` Después de activar ECS Exec para una tarea, puede ejecutar el siguiente comando para confirmar que la tarea está lista para utilizarse. Si la propiedad `lastStatus` del `ExecuteCommandAgent` se aparece como `RUNNING` y la propiedad `enableExecuteCommand`se establece en `true`, su tarea está lista. ``` aws ecs describe-tasks \ --cluster cluster-name \ --tasks task-id ``` El siguiente fragmento de código resultante es un ejemplo de lo que puede ver. ``` { "tasks": [ { ... "containers": [ { ... "managedAgents": [ { "lastStartedAt": "2021-03-01T14:49:44.574000-06:00", "name": "ExecuteCommandAgent", "lastStatus": "RUNNING" } ] } ], ... "enableExecuteCommand": true, ... } ] } ``` ### Ejecución de comandos mediante ECS Exec ## Registro mediante ECS Exec Puede configurar el registro de las sesiones de ECS Exec para capturar los comandos y sus resultados con fines de auditoría y solución de problemas. ### Activación del registro en las tareas y los servicios **importante** Para obtener más información acerca de los precios de CloudWatch, consulte [Precios de CloudWatch](https://aws.amazon.com/cloudwatch/pricing/). Amazon ECS también proporciona métricas de monitoreo sin costo adicional. Para obtener más información, consulte [Supervisión de Amazon ECS con CloudWatch](cloudwatch-metrics.md). Amazon ECS proporciona una configuración predeterminada para registrar los comandos que se ejecutan con ECS Exec. Esta configuración predeterminada consiste en enviar registros a CloudWatch Logs mediante el uso del controlador de registros `awslogs` configurado en la definición de la tarea. Si desea utilizar una configuración personalizada, la AWS CLI admite un indicador `--configuration` para los comandos `create-cluster` y `update-cluster`. La imagen de contenedor requiere la instalación de `script` y `cat` para que los registros de comandos se carguen correctamente en Amazon S3 o CloudWatch Logs. Para obtener más información acerca de cómo crear clústeres, consulte [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-cluster.html). **nota** Esta configuración solo maneja el registro de la sesión `execute-command`. No afecta el registro de la aplicación. En el ejemplo siguiente, se crea un clúster y, a continuación, se registra el resultado en el LogGroup del registro de CloudWatch con el nombre `cloudwatch-log-group-name` y en el bucket de Amazon S3 con el nombre `s3-bucket-name`. Debe utilizar una clave AWS KMS administrada por el cliente para cifrar el grupo de registro cuando establece la opción `CloudWatchEncryptionEnabled` en `true`. Para obtener información acerca de cómo cifrar el grupo de registros, consulte [Cifrado de datos de registro en CloudWatch Logs mediante AWS Key Management Service](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html#encrypt-log-data-kms-policy) en la *Guía del usuario de 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 \ } \ }" ``` La propiedad `logging` determina el comportamiento de la capacidad de registro de ECS Exec: + `NONE`: el registro está desactivado. + `DEFAULT`: los registros se envían al controlador `awslogs` configurado. Si el controlador no está configurado, no se guarda ningún registro. + `OVERRIDE`: los registros se envían al LogGroup de Registros de Amazon CloudWatch proporcionado, al bucket de Amazon S3 o a ambos. ### Se requieren permisos de IAM para generar registros en Amazon CloudWatch Logs o Amazon S3 Para habilitar el registro, el rol de tareas de Amazon ECS al que se hace referencia en la definición de tareas debe tener permisos adicionales. Estos permisos adicionales se pueden agregar como política al rol de tareas. Difieren en función de si dirige sus registros a Registros de Amazon CloudWatch o a Amazon S3. ------ #### [ Amazon CloudWatch Logs ] La siguiente política de ejemplo agrega los permisos de Registros de Amazon CloudWatch requeridos. **** ``` { "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 ] La siguiente política de ejemplo agrega los permisos de Amazon S3 requeridos. **** ``` { "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/*" } ] } ``` ------ ### Permisos de IAM requeridos para el cifrado con su propia AWS KMS key (clave de KMS) De forma predeterminada, los datos transferidos entre el cliente local y el contenedor utilizan el cifrado TLS 1.2 que proporciona AWS. Para cifrar aún más los datos con su propia clave de KMS, debe crear una clave deKMS y agregar el permiso `kms:Decrypt` al rol de IAM para tareas. El contenedor utiliza este permiso para descifrar los datos. Para obtener más información acerca de cómo crear una clave de KMS, consulte [Creación de claves](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html). Agregue la siguiente política insertada al rol de IAM para tareas que requiere los permisos de AWS KMS. Para obtener más información, consulte [Permisos de 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 los datos se cifren con su propia clave de KMS, se debe conceder al usuario o el grupo que utiliza la acción `execute-command` el permiso `kms:GenerateDataKey`. La siguiente política de ejemplo para su usuario o grupo contiene el permiso requerido para utilizar su propia clave de KMS. Debe especificar el nombre de recurso de Amazon (ARN) de la clave de 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" } ] } ``` ------ ## Utilización de políticas de IAM para limitar el acceso a ECS Exec Limite el acceso de los usuarios a la acción de la API execute-command mediante una o varias de las siguientes claves de condición de la política de IAM: + `aws:ResourceTag/clusterTagKey` + `ecs:ResourceTag/clusterTagKey` + `aws:ResourceTag/taskTagKey` + `ecs:ResourceTag/taskTagKey` + `ecs:container-name` + `ecs:cluster` + `ecs:task` + `ecs:enable-execute-command` Con la siguiente política de IAM de ejemplo, los usuarios pueden ejecutar comandos en contenedores que se ejecutan dentro de tareas con una etiqueta que contiene una clave `environment` y un valor `development`, y en un clúster con el nombre `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" } } } ] } ``` ------ Con la siguiente política de IAM de ejemplo, los usuarios no pueden utilizar la API `execute-command` cuando el nombre del contenedor es `production-app`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "ecs:ExecuteCommand" ], "Resource": "*", "Condition": { "StringEquals": { "ecs:container-name": "production-app" } } } ] } ``` ------ Con la siguiente política de IAM, los usuarios solo pueden lanzar tareas cuando ECS Exec está desactivado. ------ #### [ 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** Debido a que la acción de la API `execute-command` solo contiene recursos de tareas y clústeres en una solicitud, solo se evalúan las etiquetas de clústeres y tareas. Para obtener más información acerca de las claves de condición de la política de IAM, consulte [Acciones, recursos y claves de condición de Amazon Elastic Container Service](/service-authorization/latest/reference/list_amazonelasticcontainerservice.html) en la *Referencia de autorizaciones de servicio*. ### Limitación del acceso a la acción Iniciar sesión Si bien es posible iniciar sesiones de SSM en el contenedor fuera de ECS Exec, esto podría provocar que las sesiones no se registraran. Las sesiones iniciadas fuera de ECS Exec también cuentan para la cuota de sesiones. Recomendamos limitar este acceso directamente mediante la denegación de la acción `ssm:start-session` para las tareas de Amazon ECS que utilizan una política de IAM. Según las etiquetas que utilice, puede denegar el acceso a todas las tareas de Amazon ECS o a tareas específicas. A continuación, se muestra una política de IAM de ejemplo que deniega el acceso a la acción `ssm:start-session` para las tareas de todas las regiones con un nombre de clúster especificado. Si lo desea, puede incluir un comodín con el `cluster-name`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ssm:StartSession", "Resource": [ "arn:aws:ecs:us-east-1:111122223333:task/cluster-name/*" ] } ] } ``` ------ A continuación, se muestra una política de IAM de ejemplo que deniega el acceso a la acción `ssm:start-session` sobre recursos en todas las regiones etiquetadas con clave de etiqueta `Task-Tag-Key` y el 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" } } } ] } ``` ------ ## Solución de problemas de ECS Exec Para obtener ayuda adicional con la solución de problemas, consulte [Solución de problemas con Exec](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec-troubleshooting.html). # Ejecución de comandos mediante ECS Exec Puede utilizar Amazon ECS Exec para recopilar información de diagnóstico relacionada con los contenedores y solucionar los errores detectados a lo largo del ciclo de vida de los contenedores. ## Requisitos previos Antes de comenzar a utilizar ECS Exec, asegúrese de haber completado estas acciones: + Consulte las consideraciones. Para obtener más información, consulte [Consideraciones](ecs-exec.md#ecs-exec-considerations) + Configure ECS Exec para sus tareas y servicios. Para obtener más información, consulte [Configuración de ECS Exec](ecs-exec.md#ecs-exec-enabling-and-using) + **Instale y configure la AWS CLI**. Para obtener más información, consulte [Introducción a la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html). + **Instale el complemento de Session Manager para la AWS CLI**. Para obtener más información, consulte [Instalación del complemento de Session Manager para la AWS CLI](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html). + **Configure un rol de tarea con los permisos adecuados**. Debe utilizar un rol de tarea con los permisos adecuados para ECS Exec. Para obtener más información, consulte [Rol de IAM de tarea](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html). + **Compruebe los requisitos de la versión**. ECS Exec tiene requisitos de versión dependiendo de si las tareas están alojadas en Amazon EC2 o en AWS Fargate: + Si utiliza Amazon EC2, debe usar una AMI optimizada para Amazon ECS que se publicó después del 20 de enero de 2021, con un agente versión 1.50.2 o superior. Para obtener más información, consulte [AMI optimizadas para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html). + Si utiliza AWS Fargate, debe utilizar la versión `1.4.0` de la plataforma o una superior (Linux) o `1.0.0` (Windows). Para obtener más información, consulte [Versiones de la plataforma de AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform-fargate.html). ## Uso de la consola para tareas de servicio Puede utilizar la consola para ejecutar comandos mediante ECS Exec. 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En la página **Clusters** (Clústeres), elija el clúster. 1. En la página de detalles del clúster, en la sección **Servicios**, elija el servicio. Aparecerá la página de detalles del servicio. 1. En la página de detalles del servicio, elija **Tareas**. A continuación, elija la tarea. 1. En **Contenedores**, elija el contenedor en el que desee utilizar ECS Exec. 1. Para ejecutar comandos, siga uno de los siguientes pasos: + Elija **Conectar**. Aparecerá una sesión de CloudShell en la que puede ejecutar sus comandos. + Seleccione la flecha y, a continuación, elija **Copiar comando de la AWS CLI**. Luego podrá ejecutar los comandos localmente. **Resultados esperados** Si la conexión se realiza correctamente, debería ver una petición del intérprete de comandos interactiva desde el contenedor. Ahora puede ejecutar comandos directamente en el entorno del contenedor. Para dejar la sesión, seleccione **Finalizar sesión**. ## Uso de la consola para tareas independientes Puede utilizar la consola para ejecutar comandos mediante ECS Exec. 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En la página **Clusters** (Clústeres), elija el clúster. 1. En la página de detalles del clúster, en la sección **Tareas**, elija la tarea. Se muestra la página de detalles de la tarea. 1. En **Contenedores**, elija el contenedor en el que desee utilizar ECS Exec. 1. Para ejecutar comandos, siga uno de los siguientes pasos: + Elija **Conectar**. Aparecerá una sesión de CloudShell en la que puede ejecutar sus comandos. + Seleccione la flecha y, a continuación, elija **Copiar comando de la AWS CLI**. Luego podrá ejecutar los comandos localmente. **Resultados esperados** Si la conexión se realiza correctamente, debería ver una petición del intérprete de comandos interactiva desde el contenedor. Ahora puede ejecutar comandos directamente en el entorno del contenedor. Para dejar la sesión, seleccione **Finalizar sesión**. ## Uso del intérprete de comandos Puede utilizar el intérprete de comandos para ejecutar comandos mediante ECS Exec. Después de confirmar que `ExecuteCommandAgent` se está ejecutando, puede abrir un shell interactivo en el contenedor mediante el siguiente comando. Si la tarea contiene varios contenedores, debe especificar el nombre del contenedor mediante el indicador `--container`. Amazon ECS solo admite la iniciación de sesiones interactivas, por lo que debe utilizar el indicador `--interactive`. El siguiente comando ejecutará un comando `/bin/sh` interactivo en un contenedor denominado **container-name** para una tarea con un ID de *task-id*. El *task-id* es el nombre de recurso de Amazon (ARN) de la tarea. ``` aws ecs execute-command --cluster cluster-name \ --task task-id \ --container container-name \ --interactive \ --command "/bin/sh" ``` **Resultados esperados** Si el comando se ejecuta correctamente, debería ver una petición del intérprete de comandos interactiva desde el contenedor. Ahora puede ejecutar comandos directamente en el entorno del contenedor. Para salir de la sesión, escriba `exit` o pulse `Ctrl+D`.