# Definiciones de tareas de Amazon ECS Una *definición de tarea* es un esquema de la aplicación. Se trata de un archivo de texto en formato JSON que describe los parámetros y uno o varios contenedores que forman la aplicación. Entre los parámetros que se pueden especificar en una definición de tareas se incluyen los siguientes: + La capacidad que se debe utilizar, que determina la infraestructura en la que se alojan las tareas + La imagen de Docker que se va a utilizar con cada contenedor en su tarea + La cantidad de CPU y de memoria que se va a utilizar con cada tarea o cada contenedor dentro de una tarea + Los requisitos de memoria y CPU + El sistema operativo del contenedor en el que se ejecuta la tarea + El modo de red de Docker que utilizar para los contenedores en la tarea + La configuración de registros que se va a utilizar para sus tareas + Si la tarea se sigue ejecutando si el contenedor finaliza o falla + El comando que el contenedor ejecuta al iniciarse + Los volúmenes de datos que se utilizan con los contenedores en la tarea + El rol de IAM que las tareas utilizan Para obtener una lista completa de parámetros de definición de tareas, consulte [Parámetros en la definición de tareas de Amazon ECS para Fargate](task_definition_parameters.md). Tras crear una definición de tarea, puede ejecutarla como una tarea o un servicio. + Una *tarea* es la instancia creada de una definición de tarea dentro de un clúster. Después de crear una definición de tareas para la aplicación dentro de Amazon ECS, puede especificar el número de tareas que se ejecutarán en el clúster. + Un *servicio* de Amazon ECS ejecuta y mantiene simultáneamente el número deseado de tareas en un clúster de Amazon ECS. El funcionamiento es que, en caso de que alguna de las tareas falle o se pare por algún motivo, el programador de servicio de Amazon ECS lanza otra instancia en función de la definición de tarea. Lo hace para reemplazarlo y así mantener el número deseado de tareas en el servicio. **Topics** + [Estados de definiciones de tareas de Amazon ECS](task-definition-state.md) + [Diseño de la arquitectura de su aplicación para Amazon ECS](application_architecture.md) + [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md) + [Uso de Amazon Q Developer para proporcionar recomendaciones de la definición de tareas en la consola de Amazon ECS](using-amazon-q.md) + [Actualización de una definición de tareas de Amazon ECS mediante la consola](update-task-definition-console-v2.md) + [Anulación del registro de la revisión de una definición de tareas de Amazon ECS mediante la consola](deregister-task-definition-v2.md) + [Eliminación de una revisión de definición de tareas de Amazon ECS con la consola](delete-task-definition-v2.md) + [Casos de uso de definiciones de tareas de Amazon ECS](use-cases.md) + [Parámetros de la definición de tareas de Amazon ECS para instancias administradas de Amazon ECS](task_definition_parameters-managed-instances.md) + [Parámetros en la definición de tareas de Amazon ECS para Fargate](task_definition_parameters.md) + [Parámetros de definición de tareas de Amazon ECS para Amazon EC2](task_definition_parameters_ec2.md) + [Plantilla de definición de tareas de Amazon ECS](task-definition-template.md) + [Ejemplo de definiciones de tareas de Amazon ECS](example_task_definitions.md) # Estados de definiciones de tareas de Amazon ECS Una definición de tareas cambia de estado al crearla, anular su registro o eliminarla. Puede ver el estado de la definición de tareas en la consola, o mediante `DescribeTaskDefinition`. A continuación, se muestran los posibles estados de una definición de tareas: ACTIVE La definición de tareas está `ACTIVE` después de registrarla en Amazon ECS. Puede utilizar las definiciones de tareas en el estado `ACTIVE` para ejecutar tareas o crear servicios. INACTIVE La definición de tareas pasa del estado `ACTIVE` al estado `INACTIVE` cuando se anula su registro. Puede recuperar una definición de tareas en estado `INACTIVE` llamando a `DescribeTaskDefinition`. No puede ejecutar nuevas tareas ni crear nuevos servicios con una definición de tareas en estado `INACTIVE`. No afecta a los servicios ni las tareas existentes. DELETE\$1IN\$1PROGRESS La definición de tareas pasa del estado `INACTIVE` al estado `DELETE_IN_PROGRESS` después de enviarla para su eliminación. Una vez que la definición de tareas está en el estado `DELETE_IN_PROGRESS`, Amazon ECS verifica periódicamente que ninguna tarea ni implementación activa haga referencia a la definición de tareas de destino y, a continuación, la elimina de forma permanente. No puede ejecutar nuevas tareas ni crear nuevos servicios con una definición de tareas en estado `DELETE_IN_PROGRESS`. Se puede enviar una definición de tareas para su eliminación en cualquier momento sin que ello repercuta en las tareas ni los servicios existentes. Las definiciones de tareas que se encuentran en el estado `DELETE_IN_PROGRESS` se pueden consultar en la consola y se puede recuperar la definición de tareas haciendo una llamada a `DescribeTaskDefinition`. Al eliminar todas las revisiones de la definición de tareas `INACTIVE`, el nombre de la definición de tareas no se muestra en la consola ni se devuelve en la API. Si una revisión de definición de tareas tiene el estado `DELETE_IN_PROGRESS`, el nombre de la definición de tareas se muestra en la consola y se devuelve en la API. Amazon ECS retiene el nombre de la definición de tarea y la revisión se incrementa la próxima vez que cree una definición de tarea con ese nombre. Si utiliza AWS Config para administrar las definiciones de tareas, AWS Config le cobrará todos los registros de definiciones de tareas. Solo se le cobrará por anular el registro de la última definición de tareas en estado `ACTIVE`. No se aplica ningún cargo por eliminar una definición de tareas. Para obtener más información sobre los precios, consulte [Precios de AWS Config](https://aws.amazon.com/config/pricing/). ## Recursos de Amazon ECS que pueden bloquear una eliminación Una solicitud de eliminación de definición de tareas no se completará cuando haya recursos de Amazon ECS que dependan de la revisión de la definición de tareas. Los siguientes recursos pueden impedir que se elimine una definición de tareas: + Tareas independientes de Amazon ECS: la definición de la tarea es necesaria para que la tarea se mantenga en buen estado. + Tareas de servicio de Amazon ECS: la definición de la tarea es necesaria para que la tarea se mantenga en buen estado. + Implementaciones de servicio y conjuntos de tareas de Amazon ECS: la definición de la tarea es necesaria cuando se inicia un evento de escalado para una implementación o conjunto de tareas de Amazon ECS. Si la definición de la tarea permanece en el estado `DELETE_IN_PROGRESS`, puede utilizar la consola o la AWS CLI para identificar y, a continuación, detener los recursos que bloquean la eliminación de la definición de la tarea. ### Eliminación de la definición de tareas después de eliminar el recurso bloqueado Las siguientes reglas se aplican después de eliminar los recursos que bloquean la eliminación de la definición de tarea: + Tareas de Amazon ECS: la eliminación de la definición de tareas puede tardar hasta 1 hora en completarse una vez detenida la tarea. + Implementaciones de servicio y conjuntos de tareas de Amazon ECS: la eliminación de la definición de tareas puede tardar hasta 24 horas en completarse una vez que se haya eliminado la implementación o el conjunto de tareas. # Diseño de la arquitectura de su aplicación para Amazon ECS La arquitectura de la aplicación se hace mediante la creación de una definición de tareas para la aplicación. La definición de tareas contiene los parámetros que definen la información acerca de la aplicación, entre los que se incluyen los siguientes: + La capacidad que se debe utilizar, que determina la infraestructura en la que se alojan las tareas. Cuando se utiliza EC2, también se elige el tipo de instancia. Cuando utiliza el proveedor de capacidad de instancias administradas de Amazon ECS, puede proporcionar los requisitos de instancia para que Amazon ECS administre la capacidad de computación. Para algunos tipos de instancias, como la GPU, debe configurar parámetros concretos. Para obtener más información, consulte [Casos de uso de definiciones de tareas de Amazon ECS](use-cases.md). + Imagen del contenedor que contiene el código de la aplicación y todas las dependencias que el código de la aplicación requiere para ejecutarse. + El modo de red que se debe utilizar para los contenedores en la tarea. El modo de red determina cómo se comunica la tarea a través de la red. En el caso de las tareas que se ponen en marcha en instancias de EC2 y de instancias administradas de Amazon ECS, hay varias opciones, pero recomendamos utilizar el modo de red de `awsvpc`. El modo de red de `awsvpc` simplifica las redes de contenedores, ya que proporciona mayor control sobre la comunicación de las aplicaciones entre sí y con los demás servicios de las VPC. En el caso de las tareas que se ejecutan en Fargate, debe utilizar el modo de red de `awsvpc`. + Configuración de registros que se va a utilizar para las tareas. + Volúmenes de datos que se utilizan con los contenedores en la tarea. Para obtener una lista completa de parámetros de definición de tareas, consulte [Parámetros en la definición de tareas de Amazon ECS para Fargate](task_definition_parameters.md). Utilice las siguientes pautas al crear las definiciones de tareas: + Utilice cada familia de definiciones de tareas para un solo propósito empresarial. Si agrupa varios tipos de contenedores de aplicaciones en la misma definición de tarea, no puede escalar esos contenedores de manera independiente. Por ejemplo, en el caso de un sitio web y una API suelen ser necesarios patrones de escalado distintos. A medida que aumente el tráfico, es posible que sea necesario un número distinto de contenedores web que de contenedores de API. Si estos dos contenedores se implementan en la misma definición de tarea, cada tarea ejecuta la misma cantidad de contenedores web y contenedores de API. + Haga coincidir cada versión de la aplicación con una revisión de la definición de tareas dentro de una familia de definiciones de tareas. En una familia de definiciones de tareas, cada revisión de la definición de tareas representa una instantánea a partir de un momento específico de la configuración de una imagen de contenedor concreta. Es similar a cómo el contenedor es una instantánea de todos los componentes necesarios para ejecutar una versión concreta del código de la aplicación. Cree una asignación con correspondencia entre una versión del código de la aplicación, una etiqueta de imagen del contenedor y una revisión de la definición de la tarea. Un proceso de publicación típico implica una confirmación de git que se convierte en una imagen de contenedor etiquetada con el código SHA de la confirmación de git. Luego, esa etiqueta de imagen del contenedor recibe su propia revisión de la definición de tareas de Amazon ECS. Por último, se actualiza el servicio de Amazon ECS para implementar la nueva revisión de la definición de tareas. + Utilice diferentes roles de IAM para cada familia de definiciones de tareas. Defina cada definición de tarea con su propio rol de IAM. Implemente esta práctica y proporcione a cada componente empresarial su propia familia de definiciones de tareas. Al implementar estas dos prácticas recomendadas, puede limitar el acceso de cada servicio a los recursos de la cuenta de AWS. Por ejemplo, puede dar acceso al servicio de autenticación para que se conecte a la base de datos de contraseñas. Al mismo tiempo, puede asegurarse de que solo el servicio de pedidos tenga acceso a la información de pago con tarjeta de crédito. # Prácticas recomendadas para los tamaños de las tareas de Amazon ECS El tamaño del contenedor y el tamaño de las tareas son esenciales para planificar el escalado y la capacidad. En Amazon ECS, se utilizan dos métricas de recursos para la capacidad: CPU y memoria. La CPU se mide en unidades de 1/1024 de una vCPU completa (donde 1024 unidades equivalen a 1 vCPU completa). La memoria se mide en megabibytes. En la definición de la tarea, puede configurar las reservas y los límites de los recursos. Cuando configura una reserva, se establece la cantidad mínima de recursos que requiere una tarea. La tarea recibe como mínimo la cantidad de recursos solicitada. Es posible que la aplicación pueda utilizar más CPU o memoria que la reserva que se declare. Sin embargo, esto está sujeto a los límites que también se hayan declarado. Utilizar una cantidad superior a la reserva se conoce como ampliación. En Amazon ECS, las reservas están garantizadas. Por ejemplo, si utiliza instancias de Amazon EC2 para proporcionar capacidad, Amazon ECS no coloca una tarea en una instancia en la que no se pueda gestionar la reserva. Un límite es la cantidad máxima de unidades de CPU o memoria que pueden utilizar el contenedor o la tarea. Cualquier intento de utilizar más CPU por encima de este límite provoca una limitación. Cualquier intento de utilizar más memoria provocará que el contenedor se detenga. Elegir estos valores puede resultar difícil. Esto se debe a que los valores más adecuados para la aplicación dependen en gran medida de los requisitos de los recursos de la aplicación. Las pruebas de carga de la aplicación son la clave para planificar correctamente los requisitos de recursos y comprender mejor los requisitos de la aplicación. ## Aplicaciones sin estado En el caso de las aplicaciones sin estado que se escalan horizontalmente, como una aplicación detrás de un equilibrador de carga, recomendamos primero determinar la cantidad de memoria que consume la aplicación cuando atiende las solicitudes. Para ello, puede utilizar las herramientas tradicionales, como `ps` o `top`, o las soluciones de supervisión, como Información de contenedores de CloudWatch. Al determinar la reserva de CPU, tenga en cuenta cómo quiere escalar la aplicación para que cumpla con los requisitos de su empresa. Puede utilizar reservas de CPU más pequeñas, como 256 unidades de CPU (o 1/4 de vCPU), para escalar horizontalmente de manera detallada y minimizar los costos. Sin embargo, es posible que no se escalen lo suficientemente rápido como para satisfacer los picos significativos de la demanda. Puede utilizar reservas de CPU más grandes para reducir horizontalmente y escalar horizontalmente con mayor rapidez y, por lo tanto, adaptarse a los picos de la demanda en menor tiempo. Sin embargo, las reservas de CPU más grandes son más costosas. ## Otras aplicaciones En el caso de las aplicaciones que no se escalan horizontalmente, como los trabajos singleton o los servidores de bases de datos, las consideraciones más importantes son la capacidad disponible y el costo. Debe elegir la cantidad de memoria y CPU en función de lo que las pruebas de carga indiquen que se necesita para atender el tráfico y cumplir su objetivo de nivel de servicio. Amazon ECS garantiza que la aplicación se coloque en un host que tenga la capacidad adecuada. # Red de tareas de Amazon ECS para instancias administradas de Amazon ECS El comportamiento de las redes de las tareas de Amazon ECS que se ponen en marcha en instancias administradas de Amazon ECS se determina mediante el *modo de red* especificado en la definición de tareas. Debe especificar un modo de red en la definición de la tarea. No podrá poner en marcha tareas en instancias administradas de Amazon ECS mediante una definición de tareas que no especifique un modo de red. Instancias administradas de Amazon ECS admite los modos de red siguientes, lo que garantiza la compatibilidad con versiones anteriores para la migración de cargas de trabajo desde Fargate o Amazon ECS a Amazon EC2: | Modo de red | Descripción | | --- | --- | | `awsvpc` | Cada tarea recibe su propia interfaz de red elástica (ENI) y dirección IPv4 privada. Proporciona las mismas propiedades de redes que las instancias de Amazon EC2 y es compatible con las tareas de Fargate tradicionales. Utiliza el sistema troncal ENI para una alta densidad de tareas. | | `host` | Las tareas comparten directamente el espacio de nombres de la red del anfitrión. La red de contenedores está vinculada a la instancia del host subyacente. | ## Uso de VPC en modo de solo IPv6 En una configuración de solo IPv6, las tareas de Amazon ECS se comunican exclusivamente a través de IPv6. Para configurar VPC y subredes para una configuración de solo IPv6, debe agregar un bloque de CIDR IPv6 a la VPC y crear subredes que incluyan solo un bloque de CIDR IPv6. Para obtener más información, consulte [Adición de la compatibilidad de IPv6 con su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-add.html) y [Crear una subred](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) en la *Guía del usuario de Amazon VPC*. También debe actualizar las tablas de enrutamiento con destinos de IPv6 y configurar los grupos de seguridad con reglas de IPv6. Para obtener más información, consulte [Configurar tablas de enrutamiento](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) y [Configuración de reglas de grupos de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) en la *Guía del usuario de Amazon VPC*. Tenga en cuenta las siguientes consideraciones: + Puede actualizar un servicio de Amazon ECS solo para IPv4 o de doble pila a una configuración de solo IPv6. Para ello, actualice el servicio directamente para utilizar subredes de solo para IPv6 o cree un servicio paralelo solo para IPv6 y mediante las implementaciones azul-verde de Amazon ECS para transferir el tráfico al nuevo servicio. Para obtener más información acerca de las implementaciones azul-verde de Amazon ECS, consulte [Implementaciones “blue/green” de Amazon ECS](deployment-type-blue-green.md). + Un servicio de Amazon ECS de solo IPv6 debe utiliza equilibradores de carga de doble pila con grupos de destino de IPv6. Si va a migrar un servicio de Amazon ECS existente que esté detrás de un equilibrador de carga de aplicación o un equilibrador de carga de red, puede crear un nuevo equilibrador de carga de doble pila y transferir el tráfico del anterior, o bien actualizar el tipo de dirección IP del equilibrador de carga existente. Para obtener más información acerca de los equilibradores de carga de red, consulte [Create a Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) y [Update the IP address types for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-ip-address-type.html) en la *Guía del usuario de Equilibrador de carga de red*. Para obtener más información acerca de los equilibradores de carga de aplicación, consulte [Create an Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) y [Update the IP address types for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-ip-address-type.html) en la *Guía del usuario de Equilibrador de carga de aplicación*. + Para que las tareas de Amazon ECS en una configuración de solo IPv6 se comuniquen con puntos de conexión de solo IPv4, puede configurar DNS64 y NAT64 para traducir direcciones de red de IPv6 a IPv4. Para obtener más información, consulte [DNS64 y NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-nat64-dns64.html) en la *Guía del usuario de Amazon VPC*. + Las cargas de trabajo de Amazon ECS en una configuración de solo IPv6 deben utilizar puntos de conexión de URI de imagen de doble pila de Amazon ECR al extraer imágenes de Amazon ECR. Para obtener más información, consulte [Getting started with making requests over IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) en la *Guía del usuario de Amazon Elastic Container Registry* **nota** Amazon ECR no admite puntos de conexión de VPC con interfaz de doble pila que puedan utilizar las tareas en una configuración de solo IPv6. Para obtener más información, consulte [Getting started with making requests over IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) en la *Guía del usuario de Amazon Elastic Container Registry* + Amazon ECS Exec no es compatible en una configuración de solo IPv6. # Asignación de una interfaz de red para tareas en instancias administradas de Amazon ECS Con el modo de red de `awsvpc` en instancias administradas de Amazon ECS se simplifican las redes de contenedores, porque proporciona mayor control sobre la comunicación de las aplicaciones entre sí y con los demás servicios de las VPC. El modo de red `awsvpc` también proporciona mayor seguridad para los contenedores, ya que permite utilizar grupos de seguridad y herramientas de supervisión de red de forma más pormenorizada dentro de las tareas. De manera predeterminada, cada instancia de instancias administradas de Amazon ECS tiene una interfaz de red elástica (ENI) troncal conectada durante el lanzamiento como ENI principal cuando el tipo de instancia admite el enlace troncal. Para obtener más información acerca de los tipos de instancias que admiten el enlace troncal de ENI, consulte [Instancias admitidas para un aumento de las interfaces de red de contenedores de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/eni-trunking-supported-instance-types.html). **nota** Si el tipo de instancia elegido no admite las ENI troncales, la instancia se lanzará con una ENI normal. Cada tarea que se pone en marcha en la instancia recibe su propio ENI adjunto al ENI troncal, con una dirección IP privada principal. Si la VPC está configurada para el modo de pila doble y utiliza una subred con un bloque de CIDR IPv6, la ENI también recibe una dirección IPv6. Al utilizar una subred pública, es posible asignar, de manera opcional, una dirección IP pública a la ENI principal de Amazon ECS Managed Instance. Para ello, se habilita el direccionamiento público IPv4 para la subred. Para obtener más información, consulte [Modificación de los atributos de las direcciones IP de sus subredes](https://docs.aws.amazon.com//vpc/latest/userguide/subnet-public-ip.html) de la *Guía del usuario de Amazon VPC*. Una tarea solo puede tener una ENI asociada a ella por vez. Los contenedores que pertenecen a la misma tarea también pueden comunicarse a través de la interfaz `localhost`. Para obtener más información acerca de las VPC y subredes, consulte [Funcionamiento de Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html) en la *Guía del usuario de Amazon VPC*. Las operaciones siguientes utilizan la ENI principal adjunto a la instancia: + **Descargas de imágenes**: las imágenes de los contenedores se descargan de Amazon ECR a través de la ENI principal. + **Recuperación de secretos**: los secretos y otras credenciales de Secrets Manager se recuperan a través de la ENI principal. + **Cargas de registros:** los registros se cargan en CloudWatch a través de la ENI principal. + **Descargas de archivos de entorno**: los archivos de entorno se descargan a través de la ENI principal. El tráfico de aplicaciones fluye a través de la ENI de tareas. Dado que cada tarea obtiene su propia ENI, puede utilizar características de integración en red, como los registros de flujo de VPC, para monitorear el tráfico entrante y saliente de las tareas. Para obtener más información, consulte [Registros de flujo de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) en la *Guía del usuario de Amazon VPC*. También puede aprovechar AWS PrivateLink. Puede configurar un punto de conexión de interfaz de VPC para poder acceder a las API de Amazon ECS a través de direcciones IP privadas. AWS PrivateLink restringe todo el tráfico de red entre su VPC y Amazon ECS a la red de Amazon. No necesita una gateway de Internet, un dispositivo NAT ni una gateway privada virtual. Para obtener más información, consulte [Puntos de enlace de la VPC de interfaz de Amazon ECS (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html). El modo de red `awsvpc` también le permite utilizar Creación de reflejo de tráfico de Amazon VPC para la seguridad y la supervisión del tráfico de la red al utilizar tipos de instancias que no tienen ENI troncales conectados. Para obtener más información, consulte [What is Traffic Mirroring?](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) en la *Guía de Creación de reflejo de tráfico de Amazon VPC*. ## Consideraciones para el modo `awsvpc` + Las tareas requieren el rol vinculado al servicio de Amazon ECS para la administración de ENI. Este rol se crea automáticamente al crear un clúster o servicio. + Amazon ECS administra las ENI de tareas, por lo que no se pueden separar ni modificar manualmente. + No se admite la asignación de una dirección IP pública a la ENI de la tarea mediante `assignPublicIp` al poner en marcha una tarea independiente (`RunTask`) o al crear o actualizar un servicio (`CreateService`/`UpdateService`). + Al configurar las redes de `awsvpc` por tarea, debe utilizar la misma VPC que especificó como parte de la plantilla de lanzamiento del proveedor de capacidad de instancias administradas de Amazon ECS. Puede utilizar subredes y grupos de seguridad distintos de los especificados en la plantilla de lanzamiento. + Para las tareas en modo de red `awsvpc`, utilice el tipo de destino `ip` al configurar los grupos de destino del equilibrador de carga. Amazon ECS administra automáticamente el registro de grupos de destinos para los modos de red compatibles. ## Utilización de una VPC en modo de pila doble Cuando se utiliza una VPC en modo de pila doble, las tareas se pueden comunicar mediante IPv4, IPv6 o ambos. Las direcciones IPv4 e IPv6 son independientes entre sí. Por lo tanto, debe configurar el enrutamiento y la seguridad en su VPC por separado para IPv4 e IPv6. Para obtener más información acerca de cómo configurar la VPC para el modo de pila doble, consulte [Migración a IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) en la *Guía del usuario de Amazon VPC*. Si configuró la VPC con una puerta de enlace de Internet o una puerta de enlace de Internet de solo salida, puede utilizar la VPC en modo de pila doble. De este modo, las tareas a las que se les asigna una dirección IPv6 pueden acceder a Internet a través de una puerta de enlace de Internet o una puerta de enlace de Internet de solo salida. Las puertas de enlace NAT son opcionales. Para obtener más información, consulte [Gateways de Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) y [Gateways de Internet de solo salida](https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html) en la *Guía del usuario de Amazon VPC*. Se asigna una dirección IPv6 a las tareas de Amazon ECS si se cumplen las siguientes condiciones: + La instancia de instancias administradas de Amazon ECS que aloja la tarea utiliza la versión `1.45.0` del agente de contenedor o una posterior. Para obtener información sobre cómo comprobar la versión del agente que está utilizando la instancia y actualizarla si es necesario, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md). + La configuración de cuenta `dualStackIPv6` está habilitada. Para obtener más información, consulte [Acceso a las características de Amazon ECS con la configuración de la cuenta](ecs-account-settings.md). + Su tarea está utilizando el modo de red `awsvpc`. + La VPC y la subred están configuradas para IPv6. La configuración incluye las interfaces de red creadas en la subred especificada. Para obtener más información sobre cómo configurar la VPC para el modo de pila doble, consulte [Migración a IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) y [Modificación del atributo de direcciones IPv6 de su subred](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-ipv6) en la *Guía del usuario de Amazon VPC*. # Modo de red host En el modo `host`, las tareas comparten directamente el espacio de nombres de la red del anfitrión. La configuración de red del contenedor está vinculada a la instancia de host de instancias administradas de Amazon ECS subyacente que especifique mediante el parámetro `networkConfiguration` al crear un proveedor de capacidad de instancias administradas de Amazon ECS. `` El uso de este modo de red presenta importantes inconvenientes. No puede ejecutar más de una instancia de una tarea en cada host. Esto se debe a que solo la primera tarea puede vincularse al puerto requerido en la instancia de Amazon EC2. Tampoco hay forma de volver a asignar un puerto de contenedor cuando se utiliza el modo de red `host`. Por ejemplo, si una aplicación necesita escuchar un número de puerto concreto, no puede volver a asignar el número de puerto directamente. En su lugar, debe administrar cualquier conflicto de puertos cambiando la configuración de la aplicación. El uso del modo de red `host` también tiene consecuencias en la seguridad. Este modo permite que los contenedores se hagan pasar por el host y que los contenedores se conecten a los servicios de red de bucle invertido privados del host. Utilice el modo host solo cuando necesite acceso directo a la red host o cuando migre aplicaciones que requieran acceso a la red a nivel de host. # Opciones de red de tareas de Amazon ECS para EC2 El comportamiento de las redes de tareas de Amazon ECS alojadas en instancias de Amazon EC2 depende del *modo de red* que se definió en la definición de tareas. Le recomendamos que utilice el modo de red `awsvpc`, salvo que, por una necesidad específica, deba utilizar otro. Estos son los modos de red disponibles. | Modo de red | Contenedores de Linux en EC2 | Contenedores de Windows en EC2 | Descripción | | --- | --- | --- | --- | | `awsvpc` | Sí | Sí | A la tarea se asigna su propia interfaz de red elástica (ENI) y una dirección IPv4 o IPv6 privada principal. Esto otorga a la tarea las mismas propiedades de redes que las instancias de Amazon EC2. | | `bridge` | Sí | No | La tarea usa la red virtual integrada de Docker en Linux que se ejecuta dentro de cada instancia de Amazon EC2 que aloja la tarea. La red virtual integrada en Linux usa el controlador de red `bridge` Docker. Este es el modo de red predeterminado en Linux si no se especifica un modo de red en la definición de la tarea. | | `host` | Sí | No | La tarea usa la red del host que omite la red virtual integrada de Docker al asignar los puertos del contenedor directamente a la ENI de la instancia de Amazon EC2 que aloja la tarea. Las asignaciones de puertos dinámicas no se pueden usar en este modo de red. Un contenedor de una definición de tarea que use este modo debe especificar un número de `hostPort` específico. Varias tareas no pueden usar el número de puerto de un host. Por lo tanto, no se pueden ejecutar varias tareas de la misma definición de tarea en una instancia de Amazon EC2 única. | | `none` | Sí | No | La tarea no tiene conectividad de red externa. | | `default` | No | Sí | La tarea usa la red virtual integrada de Docker en Windows que se ejecuta dentro de cada instancia de Amazon EC2 que aloja la tarea. La red virtual integrada en Windows usa el controlador de red `nat` Docker. Este es el modo de red predeterminado en Windows si no se especifica un modo de red en la definición de la tarea. | Para obtener más información acerca de las redes de Docker en Linux, consulte [Networking overview](https://docs.docker.com/engine/network/) en la *documentación de Docker*. Para obtener más información acerca de las redes de Docker en Windows, consulte [Red de contenedores de Windows](https://learn.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture) en la *documentación de contenedores en Windows* de Microsoft. ## Uso de VPC en modo de solo IPv6 En una configuración de solo IPv6, las tareas de Amazon ECS se comunican exclusivamente a través de IPv6. Para configurar VPC y subredes para una configuración de solo IPv6, debe agregar un bloque de CIDR IPv6 a la VPC y crear subredes nuevas que incluyan solo un bloque de CIDR IPv6. Para obtener más información, consulte [Adición de la compatibilidad de IPv6 con su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-add.html) y [Crear una subred](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) en la *Guía del usuario de Amazon VPC*. También debe actualizar las tablas de enrutamiento con destinos de IPv6 y configurar los grupos de seguridad con reglas de IPv6. Para obtener más información, consulte [Configurar tablas de enrutamiento](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) y [Configuración de reglas de grupos de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) en la *Guía del usuario de Amazon VPC*. Tenga en cuenta las siguientes consideraciones: + Puede actualizar un servicio de Amazon ECS solo para IPv4 o de doble pila a una configuración de solo IPv6. Para ello, actualice el servicio directamente para utilizar subredes de solo para IPv6 o cree un servicio paralelo solo para IPv6 y mediante las implementaciones azul-verde de Amazon ECS para transferir el tráfico al nuevo servicio. Para obtener más información acerca de las implementaciones azul-verde de Amazon ECS, consulte [Implementaciones “blue/green” de Amazon ECS](deployment-type-blue-green.md). + Un servicio de Amazon ECS de solo IPv6 debe utiliza equilibradores de carga de doble pila con grupos de destino de IPv6. Si va a migrar un servicio de Amazon ECS existente que esté detrás de un equilibrador de carga de aplicación o un equilibrador de carga de red, puede crear un nuevo equilibrador de carga de doble pila y transferir el tráfico del anterior, o bien actualizar el tipo de dirección IP del equilibrador de carga existente. Para obtener más información acerca de los equilibradores de carga de red, consulte [Create a Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) y [Update the IP address types for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-ip-address-type.html) en la *Guía del usuario de Equilibrador de carga de red*. Para obtener más información acerca de los equilibradores de carga de aplicación, consulte [Create an Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) y [Update the IP address types for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-ip-address-type.html) en la *Guía del usuario de Equilibrador de carga de aplicación*. + No se admite la configuración solo para IPv6 en Windows. Debe utilizar las AMI de Linux optimizadas para Amazon ECS para poner en marcha tareas en una configuración de solo IPv6. Para obtener más información acerca de la AMI de Linux optimizadas para Amazon ECS, consulte [AMI de Linux optimizadas para Amazon ECS](ecs-optimized_AMI.md). + Al lanzar una instancia de contenedor para poner en marcha tareas en una configuración de solo IPv6, debe establecer una dirección IPv6 principal para la instancia mediante el parámetro de EC2 `--enable-primary-ipv6`. **nota** Sin una dirección IPv6 principal, las tareas que se pongan en marcha en la instancia de contenedor en los modos de red host o puente no se registrarán con los equilibradores de carga ni con AWS Cloud Map. Para obtener más información acerca de las `--enable-primary-ipv6` para poner en marcha instancias de Amazon EC2, consulte [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) en la *Referencia de comandos de AWS CLI*. Para obtener más información acerca del lanzamiento de instancias de contenedor mediante Consola de administración de AWS, consulte [Lanzamiento de una instancia de contenedor de Linux de Amazon ECS](launch_container_instance.md). + De forma predeterminada, el agente de contenedor de Amazon ECS intentará detectar la compatibilidad de la instancia de contenedor con una configuración de solo IPv6 observando las rutas IPv4 e IPv6 predeterminadas de la instancia. Para anular este comportamiento, puede establecer el parámetro ` ECS_INSTANCE_IP_COMPATIBILITY` en `ipv4` o `ipv6` en el archivo `/etc/ecs/ecs.config` de la instancia. + Las tareas deben utilizar la versión `1.99.1` o posterior del agente del contenedor. Para obtener información acerca de cómo comprobar la versión del agente que utiliza la instancia y actualizarla si es necesario, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md). + Para que las tareas de Amazon ECS en una configuración de solo IPv6 se comuniquen con puntos de conexión de solo IPv4, puede configurar DNS64 y NAT64 para traducir direcciones de red de IPv6 a IPv4. Para obtener más información, consulte [DNS64 y NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-nat64-dns64.html) en la *Guía del usuario de Amazon VPC*. + Las cargas de trabajo de Amazon ECS en una configuración de solo IPv6 deben utilizar puntos de conexión de URI de imagen de doble pila de Amazon ECR al extraer imágenes de Amazon ECR. Para obtener más información, consulte [Getting started with making requests over IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) en la *Guía del usuario de Amazon Elastic Container Registry* **nota** Amazon ECR no admite puntos de conexión de VPC con interfaz de doble pila que puedan utilizar las tareas en una configuración de solo IPv6. Para obtener más información, consulte [Getting started with making requests over IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) en la *Guía del usuario de Amazon Elastic Container Registry* + Amazon ECS Exec no es compatible en una configuración de solo IPv6. ### Regiones de AWS que admiten el modo de solo IPv6 para Amazon ECS Puede poner en marcha tareas en una configuración de solo IPv6 en las siguientes regiones de AWS en las que está disponible Amazon ECS: + Este de EE. UU. (Ohio) + Este de EE. UU. (Norte de Virginia) + Oeste de EE. UU. (Norte de California) + Oeste de EE. UU. (Oregón) + África (Ciudad del Cabo) + Asia-Pacífico (Hong Kong) + Asia-Pacífico (Hyderabad) + Asia-Pacífico (Yakarta) + Asia-Pacífico (Melbourne) + Asia-Pacífico (Mumbai) + Asia-Pacífico (Osaka) + Asia-Pacífico (Seúl) + Asia-Pacífico (Singapur) + Asia-Pacífico (Sídney) + Asia-Pacífico (Tokio) + Canadá (centro) + Oeste de Canadá (Calgary) + China (Pekín) + China (Ningxia) + Europa (Fráncfort) + Europa (Londres) + Europa (Milán) + Europa (París) + Europa (España) + Israel (Tel Aviv) + Medio Oriente (Baréin) + Medio Oriente (EAU) + América del Sur (São Paulo) + AWS GovCloud (Este de EE. UU.) + AWS GovCloud (Oeste de EE. UU.) # Asignación de una interfaz de red para una tarea de Amazon ECS Las características de integración en red de las tareas que ofrece el modo de red `awsvpc` proporcionan a las tareas de Amazon ECS las mismas propiedades de redes que poseen las instancias de Amazon EC2. Con el modo de red de `awsvpc` se simplifican las redes de contenedores, porque proporciona mayor control sobre la comunicación de las aplicaciones entre sí y con los demás servicios de las VPC. El modo de red `awsvpc` también proporciona mayor seguridad para los contenedores, ya que permite utilizar grupos de seguridad y herramientas de supervisión de red de forma más pormenorizada dentro de las tareas. También puede utilizar otras características de las redes de Amazon EC2, como los registros de flujo de VPC, para supervisar el tráfico entrante y saliente de las tareas. Además, los contenedores que pertenecen a la misma tarea puede comunicarse a través de la interfaz `localhost`. La interfaz de red elástica (ENI) de la tarea es una característica completamente administrada de Amazon ECS. Amazon ECS crea la ENI y la asocia a la instancia de Amazon EC2 del host con el grupo de seguridad especificado. La tarea envía y recibe el tráfico de red en la ENI, tal y como lo hacen las instancias de Amazon EC2 con sus principales interfaces de red. A cada tarea ENI se le asigna una dirección IPv4 privada de forma predeterminada. Si la VPC está habilitada para el modo de pila doble y utiliza una subred con un bloque de CIDR IPv6, la ENI de la tarea también recibirá una dirección IPv6. Cada tarea puede tener una sola ENI. Estas ENI se pueden ver en la consola de Amazon EC2 de su cuenta. Su cuenta no puede separar ni modificar las ENI. De este modo, se evita la eliminación accidental de una ENI que esté asociada a una tarea en ejecución. Puede consultar la información de asociación de las ENI de las tareas en la consola de Amazon ECS o con la operación de la API [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html). Cuando la tarea se detiene o se reduce la escala del servicio, la ENI de tareas se desvincula y se elimina. Cuando necesite aumentar la densidad de las ENI, utilice la configuración de la cuenta de `awsvpcTrunking`. Amazon ECS también crea y asocia una interfaz de red troncal para la instancia de contenedor. La red troncal está completamente administrada por Amazon ECS. La ENI troncal se elimina al terminar o al anular el registro de la instancia de contenedor del clúster de Amazon ECS. Para más información acerca de la configuración de la cuenta de `awsvpcTrunking`, consulte [Requisitos previos](container-instance-eni.md#eni-trunking-launching). Especifica `awsvpc` en el parámetro `networkMode` de la definición de la tarea. Para obtener más información, consulte [Modo de red](task_definition_parameters.md#network_mode). A continuación, cuando ejecute una tarea o cree un servicio, utilice el parámetro `networkConfiguration` que incluya una o varias subredes en las que deban colocarse las tareas y uno o varios grupos de seguridad que deban vincularse a una ENI. Para obtener más información, consulte [Configuración de red](service_definition_parameters.md#sd-networkconfiguration). Las tareas se colocan en instancias de Amazon EC2 válidas en las mismas zonas de disponibilidad que esas subredes; por su parte, los grupos de seguridad especificados se asocian con la ENI que se aprovisiona para la tarea. ## Consideraciones acerca de Linux Tenga en cuenta lo siguiente cuando utilice el sistema operativo Linux: + Si utiliza una instancia p5.48xlarge en modo `awsvpc`, no puede ejecutar más de 1 tarea en la instancia. + Las tareas y los servicios que utilizan el modo de red `awsvpc` requieren el rol vinculado al servicio de Amazon ECS con el fin de proporcionar a Amazon ECS los permisos necesarios para realizar llamadas a otros servicios de AWS en su nombre. Este rol se crea automáticamente al crear un clúster, o bien al crear o actualizar un servicio en la Consola de administración de AWS. Para obtener más información, consulte [Uso de roles vinculados al servicio para Amazon ECS](using-service-linked-roles.md). También puede crear el rol vinculado a servicio con el comando siguiente de la AWS CLI: ``` aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name ecs.amazonaws.com ``` + La instancia de Linux de Amazon EC2 requiere la versión `1.15.0` del agente de contenedor o una posterior para ejecutar tareas que utilizan el modo de red `awsvpc`. Si utiliza una AMI optimizada para Amazon ECS, la instancia también necesita al menos la versión `1.15.0-4` del paquete `ecs-init`. + Amazon ECS rellena el nombre de host de la tarea con un nombre de host DNS (interno) que proporciona Amazon cuando las opciones `enableDnsHostnames` y `enableDnsSupport`están habilitadas en la VPC. Si estas opciones no están habilitadas, el nombre de host DNS de la tarea se establece en un nombre de host aleatorio. Para obtener más información acerca de la configuración de DNS de una VPC, consulte [Utilización de DNS con su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) en la *Guía del usuario de Amazon VPC*. + Cada tarea de Amazon ECS que utiliza el modo de red `awsvpc` recibe su propia interfaz de red elástica (INE), la cual se asocia a la instancia de Amazon EC2 que la aloja. Existe una cuota predeterminada para el número de interfaces de red que se pueden asociar a una instancia de Linux de Amazon EC2. La interfaz de red principal cuenta como una para esa cuota. Por ejemplo, de forma predeterminada, una instancia de `c5.large` podría tener solo hasta tres ENI asociadas a ella. La interfaz de red principal de la instancia cuenta como una. Puede asociar dos ENI adicionales a la instancia. Dado que cada tarea que utiliza el modo de red `awsvpc` requiere una ENI, normalmente solo puede ejecutar dos de esas tareas en este tipo de instancia. Para obtener más información acerca de los límites de ENI predeterminados para cada tipo de instancia, consulte [Direcciones IP por interfaz de red por tipo de instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI) en la *Guía del usuario de Amazon EC2*. + Amazon ECS admite el lanzamiento de instancias de Linux de Amazon EC2 que utilizan tipos de instancias con mayor densidad de ENI compatibles. Al optar por incluir la configuración de cuenta `awsvpcTrunking` y registrar instancias de Linux de Amazon EC2 con estos tipos de instancias en el clúster, estas instancias tienen cuotas de ENI más altas. Si se utilizan estas instancias con una cuota más alta, es posible colocar más tareas en cada instancia de Linux de Amazon EC2. Para utilizar la mayor densidad de ENI con la característica de enlace troncal, la instancia de Amazon EC2 requiere al menos la versión `1.28.1` del agente de contenedor. Si utiliza una AMI optimizada para Amazon ECS, la instancia también requiere al menos la versión `1.28.1-2` del paquete `ecs-init`. Para obtener más información acerca de la inscripción en el ajuste de cuenta `awsvpcTrunking`, consulte [Acceso a las características de Amazon ECS con la configuración de la cuenta](ecs-account-settings.md). Para obtener más información acerca del enlace troncal de ENI, consulte [Aumento de las interfaces de red de instancias de contenedor de Linux de Amazon ECS](container-instance-eni.md). + Cuando se alojan tareas que utilizan el modo de red `awsvpc` en instancias de Linux de Amazon EC2, las ENI de tareas no reciben direcciones IP públicas. Para obtener acceso a Internet, las tareas deben lanzarse en una subred privada configurada para utilizar una puerta de enlace NAT. Para obtener información, consulte [Gateways NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) en la *Guía del usuario de Amazon VPC*. El acceso de red entrante debe tener lugar desde el interior de la VPC mediante la dirección IP privada o dirigirse a través del equilibrador de carga desde dentro de la VPC. Las tareas iniciadas en subredes públicas no tienen acceso a Internet. + Amazon ECS solo reconoce las ENI que asocia a sus instancias de Linux de Amazon EC2. Si asoció ENI a sus instancias de forma manual, Amazon ECS podría intentar agregar una tarea a una instancia que no tiene suficientes adaptadores de red. Esto puede hacer que se agote el tiempo de espera de la tarea, que la tarea pase a un estado de desaprovisionamiento y, a continuación, a un estado detenido. Recomendamos no asociar ENI manualmente a las instancias. + Las instancias de Linux de Amazon EC2 deben estar registradas en la función `ecs.capability.task-eni` para que se las tenga en cuenta en la ubicación de tareas con el modo de red `awsvpc`. Las instancias que ejecutan la versión `1.15.0-4` o una posterior de `ecs-init` se registran automáticamente con este atributo. + La cuenta no puede separar manualmente ni modificar las ENI que se crean y asocian a las instancias de Linux de Amazon EC2. De este modo, se evita la eliminación accidental de una ENI asociada a una tarea en ejecución. Para liberar las ENI de una tarea, detenga la tarea. + Existe un límite de 16 subredes y 5 grupos de seguridad que se puede especificar en `awsVpcConfiguration` cuando se ejecuta una tarea o se crea un servicio que utilice el modo de red `awsvpc`. Para obtener más información, consulte [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html) en la *Referencia de la API de Amazon Elastic Container Service*. + Cuando se inicia una tarea con el modo de red `awsvpc`, el agente de contenedor de Amazon ECS crea un contenedor `pause` adicional para cada tarea antes de iniciar los contenedores en la definición de tareas. Luego, configura el espacio de nombres de red del contenedor `pause` mediante la ejecución de los complementos de CNI [amazon-ecs-cni-plugins](https://github.com/aws/amazon-ecs-cni-plugins). A continuación, el agente inicia el resto de los contenedores en la tarea para que ellos compartan la pila de red del contenedor `pause`. Esto significa que todos los contenedores de una tarea son direccionables mediante las direcciones IP de la ENI y que se pueden comunicar entre sí a través de la interfaz `localhost`. + Los servicios con tareas que utilizan el modo de red `awsvpc` solo admiten equilibradores de carga de aplicación y equilibradores de carga de red. Cuando crea grupos de destino para estos servicios, debe elegir `ip` como tipo de destino. No utilizar `instance`. Esto se debe a que las tareas que utilizan el modo de red `awsvpc` se asocian con una ENI, no con una instancia de Linux de Amazon EC2. Para obtener más información, consulte [Uso del equilibrador de carga para distribuir el tráfico de servicio de Amazon ECS](service-load-balancing.md). + Si la VPC se actualiza para cambiar el conjunto de opciones DHCP que utiliza, no es posible aplicar estos cambios a las tareas existentes. Inicie tareas nuevas con estos cambios aplicados, compruebe que funcionan correctamente y, luego, detenga las tareas existentes para cambiar de manera segura estas configuraciones de red. ## Consideraciones acerca de Windows A continuación, se detallan consideraciones que se deben tener en cuenta cuando se utiliza el sistema operativo Windows: + Las instancias de contenedor que utilizan la AMI de Windows Server 2016 optimizada para Amazon ECS no pueden alojar tareas que utilizan el modo de red `awsvpc`. Si tiene un clúster que contiene AMI de Windows Server 2016 y AMI de Windows optimizadas para Amazon ECS que sí admiten el modo de red `awsvpc`, las tareas que utilizan el modo de red `awsvpc` no se lanzan en las instancias de Windows Server 2016. En cambio, se lanzarán en las instancias que admiten el modo de red `awsvpc`. + Su instancia de Windows de Amazon EC2 requiere la versión `1.57.1` del agente de contenedor o una posterior para usar las métricas de CloudWatch para los contenedores de Windows que utilizan el modo de red `awsvpc`. + Las tareas y los servicios que utilizan el modo de red `awsvpc` requieren el rol vinculado al servicio de Amazon ECS con el fin de proporcionar a Amazon ECS los permisos necesarios para realizar llamadas a otros servicios de AWS en su nombre. Este rol se crea automáticamente al crear un clúster, o bien al crear o actualizar un servicio, en la Consola de administración de AWS. Para obtener más información, consulte [Uso de roles vinculados al servicio para Amazon ECS](using-service-linked-roles.md). También puede crear el rol vinculado a un servicio con el siguiente comando de la AWS CLI: ``` aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name ecs.amazonaws.com ``` + Su instancia de Windows de Amazon EC2 requiere la versión `1.54.0` del agente de contenedor o una posterior para ejecutar tareas que utilizan el modo de red `awsvpc`. Al arrancar la instancia, debe configurar las opciones requeridas para el modo de red `awsvpc`. Para obtener más información, consulte [Arranque de instancias de contenedor de Windows de Amazon ECS para la transferencia de datos](bootstrap_windows_container_instance.md). + Amazon ECS rellena el nombre de host de la tarea con un nombre de host DNS (interno) que proporciona Amazon cuando las opciones `enableDnsHostnames` y `enableDnsSupport` están habilitadas en la VPC. Si estas opciones no están habilitadas, el nombre de host DNS de la tarea es un nombre de host aleatorio. Para obtener más información acerca de la configuración de DNS de una VPC, consulte [Utilización de DNS con su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) en la *Guía del usuario de Amazon VPC*. + Cada tarea de Amazon ECS que utiliza el modo de red `awsvpc` recibe su propia interfaz de red elástica (INE), la cual se asocia a la instancia de Windows de Amazon EC2 que la aloja. Existe una cuota predeterminada para el número de interfaces de red que se pueden asociar a una instancia de Windows de Amazon EC2. La interfaz de red principal cuenta como una para esta cuota. Por ejemplo, de forma predeterminada, una instancia de `c5.large` puede tener asociadas hasta tres ENI. La interfaz de red principal de la instancia cuenta como una de ellas. Puede asociar dos ENI adicionales a la instancia. Dado que cada tarea que utiliza el modo de red `awsvpc` requiere una ENI, normalmente solo puede ejecutar dos de esas tareas en este tipo de instancia. Para obtener más información acerca de los límites de ENI predeterminados para cada tipo de instancia, consulte [Direcciones IP por interfaz de red por tipo de instancia](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI) en la *Guía del usuario de Amazon EC2*. + Cuando se alojan tareas que utilizan el modo de red `awsvpc` en instancias de Windows de Amazon EC2, las ENI de tareas no reciben direcciones IP públicas. Para obtener acceso a Internet, lance las tareas en una subred privada configurada para utilizar una puerta de enlace NAT. Para obtener información, consulte [Gateways NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) en la *Guía del usuario de Amazon VPC*. El acceso de red entrante debe tener lugar desde el interior de la VPC mediante la dirección IP privada o dirigirse a través del equilibrador de carga desde dentro de la VPC. Las tareas iniciadas en subredes públicas no tienen acceso a Internet. + Amazon ECS solo reconoce las ENI que asoció a sus instancias de Windows de Amazon EC2. Si asoció ENI a sus instancias de forma manual, Amazon ECS podría intentar agregar una tarea a una instancia que no tiene suficientes adaptadores de red. Esto puede hacer que se agote el tiempo de espera de la tarea, que la tarea pase a un estado de desaprovisionamiento y, a continuación, a un estado detenido. Recomendamos no asociar ENI manualmente a las instancias. + Las instancias de Windows de Amazon EC2 deben estar registradas en la función `ecs.capability.task-eni` para que se las tenga en cuenta en la ubicación de tareas con el modo de red `awsvpc`. + No es posible separar manualmente ni modificar las ENI que se crean y asocian a las instancias de Windows de Amazon EC2. De este modo, se evita que elimine accidentalmente una ENI que esté asociada a una tarea en ejecución. Para liberar las ENI de una tarea, detenga la tarea. + Solo es posible especificar hasta 16 subredes y 5 grupos de seguridad en `awsVpcConfiguration` cuando se ejecuta una tarea o se crea un servicio que utiliza el modo de red `awsvpc`. Para obtener más información, consulte [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html) en la *Referencia de la API de Amazon Elastic Container Service*. + Cuando se inicia una tarea con el modo de red `awsvpc`, el agente de contenedor de Amazon ECS crea un contenedor `pause` adicional para cada tarea antes de iniciar los contenedores en la definición de tareas. Luego, configura el espacio de nombres de red del contenedor `pause` mediante la ejecución de los complementos de CNI [amazon-ecs-cni-plugins](https://github.com/aws/amazon-ecs-cni-plugins). A continuación, el agente inicia el resto de los contenedores en la tarea para que ellos compartan la pila de red del contenedor `pause`. Esto significa que todos los contenedores de una tarea son direccionables mediante las direcciones IP de la ENI y que se pueden comunicar entre sí a través de la interfaz `localhost`. + Los servicios con tareas que utilizan el modo de red `awsvpc` solo admiten equilibradores de carga de aplicación y equilibradores de carga de red. Al crear grupos de destino para estos servicios, se debe elegir `ip` como tipo de destino, no `instance`. Esto se debe a que las tareas que utilizan el modo de red `awsvpc` se asocian con una ENI, no con una instancia de Windows de Amazon EC2. Para obtener más información, consulte [Uso del equilibrador de carga para distribuir el tráfico de servicio de Amazon ECS](service-load-balancing.md). + Si la VPC se actualiza para cambiar el conjunto de opciones DHCP que utiliza, no es posible aplicar estos cambios a las tareas existentes. Inicie tareas nuevas con estos cambios aplicados, compruebe que funcionan correctamente y, luego, detenga las tareas existentes para cambiar de manera segura estas configuraciones de red. + Cuando se utiliza el modo de red `awsvpc` en una configuración de EC2 Windows, no se admite lo siguiente: + Configuración de pila doble + IPv6 + Enlace troncal de ENI ## Utilización de una VPC en modo de pila doble Cuando se utiliza una VPC en modo de pila doble, las tareas se pueden comunicar mediante IPv4, IPv6 o ambos. Las direcciones IPv4 e IPv6 son independientes entre sí. Por lo tanto, debe configurar el enrutamiento y la seguridad en su VPC por separado para IPv4 e IPv6. Para obtener más información acerca de cómo configurar la VPC para el modo de pila doble, consulte [Migración a IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) en la *Guía del usuario de Amazon VPC*. Si configuró la VPC con una puerta de enlace de Internet o una puerta de enlace de Internet de solo salida, puede utilizar la VPC en modo de pila doble. De este modo, las tareas a las que se les asigna una dirección IPv6 pueden acceder a Internet a través de una puerta de enlace de Internet o una puerta de enlace de Internet de solo salida. Las puertas de enlace NAT son opcionales. Para obtener más información, consulte [Gateways de Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) y [Gateways de Internet de solo salida](https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html) en la *Guía del usuario de Amazon VPC*. Se asigna una dirección IPv6 a las tareas de Amazon ECS si se cumplen las siguientes condiciones: + La instancia de Linux de Amazon EC2 que aloja la tarea está utilizando la versión `1.45.0` del agente de contenedor o una posterior. Para obtener información sobre cómo comprobar la versión del agente que está utilizando la instancia y actualizarla si es necesario, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md). + La configuración de cuenta `dualStackIPv6` está habilitada. Para obtener más información, consulte [Acceso a las características de Amazon ECS con la configuración de la cuenta](ecs-account-settings.md). + Su tarea está utilizando el modo de red `awsvpc`. + La VPC y la subred están configuradas para IPv6. La configuración incluye las interfaces de red creadas en la subred especificada. Para obtener más información sobre cómo configurar la VPC para el modo de pila doble, consulte [Migración a IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) y [Modificación del atributo de direcciones IPv6 de su subred](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-ipv6) en la *Guía del usuario de Amazon VPC*. # Asignación de los puertos del contenedor de Amazon ECS a la interfaz de red de la instancia de EC2 El modo de red `host` solo se admite para las tareas de Amazon ECS alojadas en instancias de Amazon EC2. No es compatible cuando se utiliza Fargate en Amazon ECS. El modo de red `host` es el modo de red más básico compatible con Amazon ECS. Con el modo host, la red del contenedor está vinculada directamente al host subyacente que está ejecutando el contenedor. ![\[Diagrama que muestra la arquitectura de una red con contenedores que utilizan el modo de red del host.\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/networkmode-host.png) Suponga que está ejecutando un contenedor de Node.js con una aplicación Express que escucha en un puerto `3000` similar a la que se muestra en el diagrama anterior. Cuando se utiliza el modo de red `host`, el contenedor recibe tráfico en el puerto 3000 mediante la dirección IP de la instancia de Amazon EC2 del host subyacente. Le recomendamos que no utilice este modo. El uso de este modo de red presenta importantes inconvenientes. No puede ejecutar más de una instancia de una tarea en cada host. Esto se debe a que solo la primera tarea puede vincularse al puerto requerido en la instancia de Amazon EC2. Tampoco hay forma de volver a asignar un puerto de contenedor cuando se utiliza el modo de red `host`. Por ejemplo, si una aplicación necesita escuchar un número de puerto concreto, no puede volver a asignar el número de puerto directamente. En su lugar, debe administrar cualquier conflicto de puertos cambiando la configuración de la aplicación. El uso del modo de red `host` también tiene consecuencias en la seguridad. Este modo permite que los contenedores se hagan pasar por el host y que los contenedores se conecten a los servicios de red de bucle invertido privados del host. # Uso de la red virtual de Docker para las tareas de Linux de Amazon ECS El modo de red `bridge` solo se admite para las tareas de Amazon ECS alojadas en instancias de Amazon EC2. Con el modo `bridge`, utiliza un puente de red virtual para crear una capa entre el host y la red del contenedor. De esta forma, puede crear asignaciones de puertos que reasignen un puerto de host a un puerto de contenedor. Las asignaciones pueden ser estáticas o dinámicas. ![\[Diagrama que muestra la arquitectura de una red que utiliza el modo de red puente con asignación de puertos estática.\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/networkmode-bridge.png) Con una asignación de puertos estática, puede definir de forma explícita qué puerto de host desea asignar a un puerto de contenedor. En el ejemplo anterior, el puerto `80` del host se asigna al puerto `3000` del contenedor. Para comunicarse con la aplicación en contenedor, debe enviar el tráfico al puerto `80` a la dirección IP de la instancia de Amazon EC2. Desde la perspectiva de la aplicación en contenedor, se ve el tráfico entrante en el puerto `3000`. Si solo desea cambiar el puerto de tráfico, las asignaciones de puertos estáticas son adecuadas. Sin embargo, esto sigue teniendo la misma desventaja que usar el modo de red `host`. No puede ejecutar más de una instancia de una tarea en cada host. Esto se debe a que una asignación de puertos estática solo permite asignar un único contenedor al puerto 80. Para resolver este problema, considere la posibilidad de utilizar el modo de red `bridge` con una asignación dinámica de puertos, como se muestra en el siguiente diagrama. ![\[Diagrama que muestra la arquitectura de una red que utiliza el modo de red puente con asignación de puertos dinámica.\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/networkmode-bridge-dynamic.png) Al no especificar un puerto de host en la asignación de puertos, puede hacer que Docker elija un puerto aleatorio y no utilizado del rango de puertos efímeros y lo asigne como puerto de host público del contenedor. Por ejemplo, a la aplicación Node.js que escucha en el puerto `3000` del contenedor se le puede asignar un puerto aleatorio con un número alto, como `47760` en el host de Amazon EC2. Esto significa que puede ejecutar varias copias de ese contenedor en el host. Además, a cada contenedor se le puede asignar su propio puerto en el host. Cada copia del contenedor recibe tráfico en el puerto `3000`. Sin embargo, los clientes que envían tráfico a estos contenedores utilizan los puertos de host asignados aleatoriamente. Amazon ECS ayuda a realizar un seguimiento de los puertos asignados de forma aleatoria para cada tarea. Para ello, actualiza automáticamente los grupos de destino del equilibrador de carga y la detección de servicios de AWS Cloud Map para disponer de la lista de puertos y direcciones IP de las tareas. Esto facilita el uso de los servicios que funcionan en modo `bridge` con puertos dinámicos. Sin embargo, una desventaja de usar el modo de red `bridge` es que es difícil bloquear las comunicaciones entre servicios. Como los servicios pueden asignarse a cualquier puerto aleatorio y no utilizado, es necesario abrir rangos de puertos amplios entre los hosts. Sin embargo, no es fácil crear reglas específicas para que un servicio en particular solo pueda comunicarse con otro servicio específico. Los servicios no tienen puertos específicos para utilizarlos en las reglas de red de los grupos de seguridad. ## Configuración del modo de redes puente para cargas de trabajo de solo IPv6 Para configurar el modo `bridge` de comunicación a través de IPv6, debe actualizar la configuración del daemon de Docker. Actualice `/etc/docker/daemon.json` con los siguiente: ``` { "ipv6": true, "fixed-cidr-v6": "2001:db8:1::/64", "ip6tables": true, "experimental": true } ``` Tras actualizar la configuración del daemon de Docker, tendrá que reiniciarlo. **nota** Al actualizar y reiniciar el daemon, Docker habilita el reenvío de IPv6 en la instancia, lo que puede provocar la pérdida de las rutas predeterminadas en las instancias que utilizan una AMI de Amazon Linux 2. Para evitarlo, utilice el comando siguiente para agregar una ruta predeterminada a través de la puerta de enlace IPv6 de la subred. ``` ip route add default via FE80:EC2::1 dev eth0 metric 100 ``` # Opciones de red de tareas de Amazon ECS para Fargate De forma predeterminada, a todas las tareas de Amazon ECS alojadas en Fargate se les proporciona una interfaz de red elástica (ENI) con una dirección IP privada principal. Cuando se utiliza una subred pública, es posible asignar opcionalmente una dirección IP pública a la ENI de la tarea. Si la VPC está configurada para el modo de pila doble y utiliza una subred con un bloque de CIDR IPv6, la ENI de la tarea también recibe una dirección IPv6. Una tarea solo puede tener una ENI asociada a ella por vez. Los contenedores que pertenecen a la misma tarea también pueden comunicarse a través de la interfaz `localhost`. Para obtener más información acerca de las VPC y subredes, consulte [Funcionamiento de Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html) en la *Guía del usuario de Amazon VPC*. Para que una tarea alojada en Fargate extraiga una imagen de contenedor, la tarea debe tener una ruta a Internet. A continuación, se describe cómo puede comprobar que su tarea tiene una ruta a Internet. + Cuando se utiliza una subred pública, se puede asignar una dirección IP pública a la ENI de la tarea. + Cuando se utiliza una subred privada, la subred puede tener una gateway NAT conectada. + Cuando se utilizan imágenes de contenedor alojadas en Amazon ECR, se puede configurar Amazon ECR para que utilice un punto de conexión de VPC de interfaz y la extracción de imágenes se realiza en la dirección IPv4 privada de la tarea. Para obtener más información, consulte [Puntos de conexión de VCP de la interfaz de Amazon ECR (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) en la *Guía del usuario de Amazon Elastic Container Registry*. Dado que cada tarea obtiene su propia ENI, puede utilizar características de integración en red, como los registros de flujo de VPC, para monitorear el tráfico entrante y saliente de las tareas. Para obtener más información, consulte [Registros de flujo de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) en la *Guía del usuario de Amazon VPC*. También puede aprovechar AWS PrivateLink. Puede configurar un punto de conexión de interfaz de VPC para poder acceder a las API de Amazon ECS a través de direcciones IP privadas. AWS PrivateLink restringe todo el tráfico de red entre su VPC y Amazon ECS a la red de Amazon. No necesita una gateway de Internet, un dispositivo NAT ni una gateway privada virtual. Para obtener más información, consulte [Puntos de enlace de la VPC de interfaz de Amazon ECS (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html). Para ver ejemplos de cómo utilizar el recurso `NetworkConfiguration` con CloudFormation, consulte [Plantillas de CloudFormation de ejemplo para Amazon ECS](working-with-templates.md). Las ENI que se crean están completamente administradas por AWS Fargate. Además, existe una política de IAM asociada que se utiliza para conceder permisos a Fargate. En el caso de las tareas que utilizan la versión `1.4.0` de la plataforma de Fargate o una posterior, la tarea recibe una única ENI (que se conoce como la ENI de la tarea) y todo el tráfico de red fluye a través de esa ENI dentro de la VPC. Este tráfico se registra en los registros de flujo de la VPC. En el caso de las tareas que utilizan la versión `1.3.0` de la plataforma de Fargate o una anterior, además de la ENI de la tarea, la tarea también recibe otra ENI distinta de propiedad de Fargate que se utiliza para cierto tráfico de red que no puede verse en los registros de flujo de la VPC. En la tabla que se muestra a continuación, se describe el comportamiento del tráfico de red y la política de IAM requerida para cada versión de la plataforma. | Action | Flujo de tráfico con la versión `1.3.0` y anterior de la plataforma Linux | Flujo de tráfico con la versión de la plataforma Linux `1.4.0` | Flujo de tráfico con la versión de la plataforma Windows `1.0.0` | Permiso de IAM | | --- | --- | --- | --- | --- | | Recuperación de credenciales de inicio de sesión de Amazon ECR | ENI de propiedad de Fargate | ENI de la tarea | ENI de la tarea | Rol de IAM de ejecución de tareas | | Extracción de imágenes | ENI de la tarea | ENI de la tarea | ENI de la tarea | Rol de IAM de ejecución de tareas | | Enviar registros a través de un controlador de registro | ENI de la tarea | ENI de la tarea | ENI de la tarea | Rol de IAM de ejecución de tareas | | Envío de registros a través de FireLens para Amazon ECS | ENI de la tarea | ENI de la tarea | ENI de la tarea | Rol de IAM para la tarea | | Recuperación de secretos de Secrets Manager o Systems Manager | ENI de propiedad de Fargate | ENI de la tarea | ENI de la tarea | Rol de IAM de ejecución de tareas | | Tráfico del sistema de archivos de Amazon EFS | No disponible | ENI de la tarea | ENI de la tarea | Rol de IAM para la tarea | | Tráfico de la aplicación | ENI de la tarea | ENI de la tarea | ENI de la tarea | Rol de IAM para la tarea | ## Consideraciones Tenga en cuenta lo siguiente al utilizar la integración en red de las tareas. + El rol vinculado al servicio de Amazon ECS se requiere para proporcionar a Amazon ECS los permisos para realizar llamadas a otros servicios de AWS de en su nombre. Este rol se crea al crear un clúster, o bien al crear o actualizar un servicio en la Consola de administración de AWS. Para obtener más información, consulte [Uso de roles vinculados al servicio para Amazon ECS](using-service-linked-roles.md). También puede crear el rol vinculado a un servicio con el siguiente comando de la AWS CLI: ``` aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name ecs.amazonaws.com ``` + Amazon ECS rellena el nombre de host de la tarea con un nombre de host DNS que proporciona Amazon cuando las opciones `enableDnsHostnames` y `enableDnsSupport` están habilitadas en la VPC. Si estas opciones no están habilitadas, el nombre de host DNS de la tarea se establece en un nombre de host aleatorio. Para obtener más información acerca de la configuración de DNS de una VPC, consulte [Utilización de DNS con su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) en la *Guía del usuario de Amazon VPC*. + Solo se pueden especificar hasta 16 subredes y 5 grupos de seguridad para `awsVpcConfiguration`. Para obtener más información, consulte [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html) en la *Referencia de la API de Amazon Elastic Container Service*. + No es posible separar manualmente ni modificar las ENI que Fargate crea y asocia. De este modo, se evita la eliminación accidental de una ENI asociada a una tarea en ejecución. Para liberar las ENI de una tarea, detenga la tarea. + Si se actualiza una subred de la VPC para cambiar el conjunto de opciones DHCP que utiliza, no es posible aplicar estos cambios también a las tareas existentes que usan la VPC. Inicie tareas nuevas, que recibirán la nueva configuración para migrar sin problemas mientras prueba el nuevo cambio y, a continuación, detenga las anteriores, si no es necesario realizar ninguna reversión. + Lo siguiente se aplica a las tareas que se ejecutan en la versión `1.4.0` o posterior de la plataforma Fargate para Linux o `1.0.0` para Windows. Las tareas que se ejecuten en subredes de doble pila se les asignará una dirección IPv4 e IPv6. Las tareas que se pongan en marcha en subredes de solo IPv6 reciben una dirección IPv6. + En el caso de las tareas que utilizan la versión `1.4.0` o posterior de Linux o `1.0.0` de Windows de la plataforma, las ENI de la tarea admiten tramas gigantes. Las interfaces de red se configuran con una unidad de transmisión máxima (MTU), que es el tamaño de la carga útil más grande que cabe en una sola trama. Cuanto mayor sea la MTU, mayor será la carga de la aplicación que cabe en una sola trama, lo que reduce la sobrecarga por trama y aumenta la eficiencia. Esta compatibilidad con las tramas gigantes reduce la sobrecarga cuando la ruta de red entre la tarea y el destino admite el uso de estas tramas. + Los servicios con tareas que utilizan Fargate solo admiten el equilibrador de carga de aplicación y el equilibrador de carga de red. No se admiten los equilibradores de carga clásicos. Cuando crea grupos de destino, debe elegir `ip` como tipo de destino, no `instance`. Para obtener más información, consulte [Uso del equilibrador de carga para distribuir el tráfico de servicio de Amazon ECS](service-load-balancing.md). ## Utilización de una VPC en modo de pila doble Cuando se utiliza una VPC en modo de pila doble, las tareas se pueden comunicar mediante IPv4, IPv6 o ambos. Las direcciones IPv4 e IPv6 son independientes entre sí. Por lo tanto, debe configurar el enrutamiento y la seguridad de su VPC de forma individual para IPv4 e IPv6. Para obtener más información acerca de la configuración de la VPC para el modo de pila doble, consulte [Migración a IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) en la *Guía del usuario de Amazon VPC*. Si se cumplen las siguientes condiciones, a las tareas de Amazon ECS alojadas en Fargate se les asigna una dirección IPv6: + La configuración de la cuenta `dualStackIPv6` de Amazon ECS está activada (`enabled`) para la entidad principal de IAM que lanza las tareas en la región en la que las va a lanzar. Esta configuración solo se puede modificar con la API o AWS CLI. Tiene la opción de activar esta configuración para una entidad principal de IAM específica de su cuenta o para toda su cuenta mediante la configuración predeterminada de su cuenta. Para obtener más información, consulte [Acceso a las características de Amazon ECS con la configuración de la cuenta](ecs-account-settings.md). + La VPC y la subred están habilitadas para IPv6. Para obtener más información acerca de cómo configurar la VPC para el modo de pila doble, consulte [Migración a IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) en la *Guía del usuario de Amazon VPC*. + La subred está habilitada para la asignación automática de direcciones IPv6. Para obtener más información sobre cómo configurar la subred, consulte [Modificar el atributo de direccionamiento IPv6 de la subred](https://docs.aws.amazon.com/vpc/latest/userguide/modify-subnets.html) en la *Guía del usuario de Amazon VPC*. + La tarea o servicio utiliza la versión `1.4.0` o posterior para Linux de la plataforma de Fargate. Para las tareas de Amazon ECS en Fargate que se ejecutan en una VPC en modo de doble pila, para comunicarse con los servicios de dependencia que se utilizan en el proceso de inicio de tareas, como ECR, SSM y SecretManager, la tabla de enrutamiento de la subred pública necesita una ruta IPv4 (0.0.0.0/0) a una puerta de enlace de Internet y la tabla de enrutamiento de la subred privada necesita una ruta IPv4 (0.0.0.0/0) a una puerta de enlace NAT. Para obtener más información, consulte [Puertas de enlace de Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) y [Puertas de enlace NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) en la *Guía del usuario de Amazon VPC*. Para ver ejemplos de cómo configurar una VPC de doble pila, consulte [Ejemplo de configuración de VPC de doble pila](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-example.html). ## Uso de VPC en modo de solo IPv6 En una configuración de solo IPv6, las tareas de Amazon ECS se comunican exclusivamente a través de IPv6. Para configurar VPC y subredes para una configuración de solo IPv6, debe agregar un bloque de CIDR IPv6 a la VPC y crear subredes que incluyan solo un bloque de CIDR IPv6. Para obtener más información, consulte [Adición de la compatibilidad de IPv6 con su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-add.html) y [Crear una subred](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) en la *Guía del usuario de Amazon VPC*. También debe actualizar las tablas de enrutamiento con destinos de IPv6 y configurar los grupos de seguridad con reglas de IPv6. Para obtener más información, consulte [Configurar tablas de enrutamiento](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) y [Configuración de reglas de grupos de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) en la *Guía del usuario de Amazon VPC*. Tenga en cuenta las siguientes consideraciones: + Puede actualizar un servicio de Amazon ECS solo para IPv4 o de doble pila a una configuración de solo IPv6. Para ello, actualice el servicio directamente para utilizar subredes de solo para IPv6 o cree un servicio paralelo solo para IPv6 y mediante las implementaciones azul-verde de Amazon ECS para transferir el tráfico al nuevo servicio. Para obtener más información acerca de las implementaciones azul-verde de Amazon ECS, consulte [Implementaciones “blue/green” de Amazon ECS](deployment-type-blue-green.md). + Un servicio de Amazon ECS de solo IPv6 debe utiliza equilibradores de carga de doble pila con grupos de destino de IPv6. Si va a migrar un servicio de Amazon ECS existente que esté detrás de un equilibrador de carga de aplicación o un equilibrador de carga de red, puede crear un nuevo equilibrador de carga de doble pila y transferir el tráfico del anterior, o bien actualizar el tipo de dirección IP del equilibrador de carga existente. Para obtener más información acerca de los equilibradores de carga de red, consulte [Create a Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) y [Update the IP address types for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-ip-address-type.html) en la *Guía del usuario de Equilibrador de carga de red*. Para obtener más información acerca de los equilibradores de carga de aplicación, consulte [Create an Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) y [Update the IP address types for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-ip-address-type.html) en la *Guía del usuario de Equilibrador de carga de aplicación*. + No se admite la configuración solo para IPv6 en Windows. + Para que las tareas de Amazon ECS en una configuración de solo IPv6 se comuniquen con puntos de conexión de solo IPv4, puede configurar DNS64 y NAT64 para traducir direcciones de red de IPv6 a IPv4. Para obtener más información, consulte [DNS64 y NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-nat64-dns64.html) en la *Guía del usuario de Amazon VPC*. + La configuración de solo IPv6 se admite en la versión de la plataforma de Fargate `1.4.0` o posterior. + Las cargas de trabajo de Amazon ECS en una configuración de solo IPv6 deben utilizar puntos de conexión de URI de imagen de doble pila de Amazon ECR al extraer imágenes de Amazon ECR. Para obtener más información, consulte [Getting started with making requests over IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) en la *Guía del usuario de Amazon Elastic Container Registry* **nota** Amazon ECR no admite puntos de conexión de VPC con interfaz de doble pila que puedan utilizar las tareas en una configuración de solo IPv6. Para obtener más información, consulte [Getting started with making requests over IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) en la *Guía del usuario de Amazon Elastic Container Registry* + Amazon ECS Exec no es compatible en una configuración de solo IPv6. + Amazon CloudWatch no admite un punto de conexión FIPS de doble pila que se pueda utilizar para supervisar las tareas de Amazon ECS en una configuración de solo IPv6 que cumpla con la norma FIPS-140. Para obtener más información acerca de FIPS-140, consulte [AWS Fargate Estándar de procesamiento de la información federal (FIPS, Federal Information Processing Standard 140)](ecs-fips-compliance.md). ### Regiones de AWS que admiten el modo de solo IPv6 para Amazon ECS Puede poner en marcha tareas en una configuración de solo IPv6 en Regiones de AWS siguientes en las que está disponible Amazon ECS: + Este de EE. UU. (Ohio) + Este de EE. UU. (Norte de Virginia) + Oeste de EE. UU. (Norte de California) + Oeste de EE. UU. (Oregón) + África (Ciudad del Cabo) + Asia-Pacífico (Hong Kong) + Asia-Pacífico (Hyderabad) + Asia-Pacífico (Yakarta) + Asia-Pacífico (Melbourne) + Asia-Pacífico (Mumbai) + Asia-Pacífico (Osaka) + Asia-Pacífico (Seúl) + Asia-Pacífico (Singapur) + Asia-Pacífico (Sídney) + Asia-Pacífico (Tokio) + Canadá (centro) + Oeste de Canadá (Calgary) + China (Pekín) + China (Ningxia) + Europa (Fráncfort) + Europa (Londres) + Europa (Milán) + Europa (París) + Europa (España) + Israel (Tel Aviv) + Medio Oriente (Baréin) + Medio Oriente (EAU) + América del Sur (São Paulo) + AWS GovCloud (Este de EE. UU.) + AWS GovCloud (Oeste de EE. UU.) # Opciones de almacenamiento para las tareas de Amazon ECS Amazon ECS ofrece opciones de almacenamiento de datos flexibles, rentables y de uso fácil según sus necesidades. Amazon ECS admite las opciones siguientes de volumen de datos para contenedores: | Volumen de datos | Capacidad compatible | Sistemas operativos compatibles | Persistencia del almacenamiento | Casos de uso | | --- | --- | --- | --- | --- | | Amazon Elastic Block Store (Amazon EBS) | Fargate, Amazon EC2 e instancias administradas de Amazon ECS | Linux, Windows (solo en Amazon EC2) | Se puede mantener cuando se adjunta a una tarea independiente. Efímero cuando se adjunta a una tarea que mantiene un servicio. | Los volúmenes de Amazon EBS proporcionan almacenamiento en bloques rentable, duradero y de alto rendimiento para cargas de trabajo en contenedores con uso intensivo de datos. Entre los casos de uso más comunes se incluyen cargas de trabajo transaccionales, como bases de datos, escritorios virtuales y volúmenes raíz, y cargas de trabajo con un rendimiento intensivo, como las cargas de trabajo de procesamiento de registros y ETL. Para obtener más información, consulte [Uso de volúmenes de Amazon EBS con Amazon ECS](ebs-volumes.md). | | Amazon Elastic File System (Amazon EFS) | Fargate, Amazon EC2 e instancias administradas de Amazon ECS | Linux | Persistente | Los volúmenes de Amazon EFS proporcionan almacenamiento compartido de archivos sencillo, escalable y persistente para utilizarlo con las tareas de Amazon ECS. Dicho almacenamiento aumenta y se reduce automáticamente a medida que agrega o elimina archivos. Los volúmenes de Amazon EFS admiten la simultaneidad y son útiles para las aplicaciones en contenedores que se escalan horizontalmente y necesitan funcionalidades de almacenamiento como baja latencia, rendimiento alto y coherencia de lectura tras escritura. Entre los casos de uso más comunes se incluyen las cargas de trabajo como el análisis de datos, el procesamiento multimedia, la administración de contenido y los servidores web. Para obtener más información, consulte [Uso de volúmenes de Amazon EFS con Amazon ECS](efs-volumes.md). | | Amazon FSx para Windows File Server | Amazon EC2 | Windows | Persistente | Los volúmenes FSx para Windows File Server proporcionan servidores de archivos de Windows completamente administrados que pueden utilizarse para aprovisionar las tareas de Windows que necesitan almacenamiento de archivos persistente, distribuido, compartido y estático. Entre los casos de uso más comunes se incluyen aplicaciones de .NET que pueden requerir carpetas locales, como el almacenamiento persistente para guardar los resultados de las aplicaciones. Amazon FSx para Windows File Server ofrece una carpeta local en el contenedor que permite la lectura y escritura de varios contenedores en el mismo sistema de archivos respaldado por un recurso compartido de archivos SMB. Para obtener más información, consulte [Uso de volúmenes de FSx para Windows File Server con Amazon ECS](wfsx-volumes.md). | | Amazon FSx para NetApp ONTAP | Amazon EC2 | Linux | Persistente | Los volúmenes de Amazon FSx para NetApp ONTAP proporcionan sistemas de archivos NetApp ONTAP totalmente administrados que puede utilizar para aprovisionar sus tareas de Linux que necesitan un almacenamiento de archivos compartido persistente, de alto rendimiento y rico en características. Amazon FSx para NetApp ONTAP es compatible con los protocolos NFS y SMB, y proporciona características de nivel empresarial, como instantáneas, clonación y deduplicación de datos. Los casos de uso comunes incluyen cargas de trabajo de computación de alto rendimiento, repositorios de contenido y aplicaciones que requieren un almacenamiento compartido compatible con POSIX. Para obtener más información, consulte [Mounting Amazon FSx for NetApp ONTAP file systems from Amazon ECS containers](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/mount-ontap-ecs-containers.html). | | Volúmenes de Docker | Amazon EC2 | Windows, Linux | Persistente | Los volúmenes de Docker son una característica del tiempo de ejecución de contenedores de Docker que permite a los contenedores conservar los datos mediante el montaje de un directorio desde el sistema de archivos del host. Los controladores de volúmenes de Docker (también se les conocen como complementos) se utilizan para integrar los volúmenes de contenedores con sistemas de almacenamiento externos. Los volúmenes de Docker se pueden administrar mediante controladores de terceros o mediante el controlador integrado local. Entre los casos de uso más comunes de los volúmenes de Docker se incluyen proporcionar volúmenes de datos persistentes o compartir volúmenes en distintas ubicaciones de contenedores diferentes en la misma instancia de contenedor. Para obtener más información, consulte [Uso de volúmenes de Docker con Amazon ECS](docker-volumes.md). | | Montajes de enlace | Fargate, Amazon EC2 e instancias administradas de Amazon ECS | Windows, Linux | Efímero | Los montajes de unión consisten en un archivo o directorio del host, por ejemplo, una instancia de Amazon EC2 o AWS Fargate, que se monta en un contenedor. Entre los casos de uso más comunes de los montajes de unión se incluyen compartir un volumen de un contenedor de origen con otros contenedores en la misma tarea o montar un volumen del host o un volumen vacío en uno o varios contenedores. Para obtener más información, consulte [Uso de montajes de unión con Amazon ECS](bind-mounts.md). | # Uso de volúmenes de Amazon EBS con Amazon ECS Los volúmenes de Amazon Elastic Block Store (Amazon EBS) proporcionan almacenamiento en bloque de alta disponibilidad, rentable, duradero y de alto rendimiento para las cargas de trabajo con un uso intensivo de datos. Los volúmenes de Amazon EBS se pueden utilizar con las tareas de Amazon ECS para las aplicaciones de alto rendimiento y con un uso intensivo de transacciones. Para obtener más información sobre los volúmenes de Amazon EBS, consulte [Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) en la *Guía del usuario de Amazon EBS*. Amazon ECS administra los volúmenes de Amazon EBS que se adjuntan a las tareas de Amazon ECS en su nombre. Durante el lanzamiento de una tarea independiente, puede proporcionar la configuración que se utilizará para adjuntar un volumen de EBS a la tarea. Durante la creación o la actualización del servicio, puede proporcionar la configuración que se utilizará para adjuntar un volumen de EBS por tarea a cada tarea administrada por el servicio de Amazon ECS. Puede configurar volúmenes nuevos y vacíos para adjuntarlos o puede utilizar instantáneas para cargar los datos de los volúmenes existentes. **nota** Cuando utiliza instantáneas para configurar los volúmenes, puede especificar un valor de `volumeInitializationRate`, en MiB/s, que indica la velocidad la que se obtienen los datos de la instantánea para crear volúmenes que se inicialicen por completo en un período de tiempo predecible. Para obtener más información sobre la inicialización de volúmenes, consulte [Inicialización de volúmenes de Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/initalize-volume.html) en la *Guía del usuario de Amazon EBS*. Para obtener más información sobre la configuración de los volúmenes de Amazon EBS, consulte [Aplazamiento de la configuración del volumen a la hora de lanzamiento en la definición de la tarea de Amazon ECS](specify-ebs-config.md) y [Especificación de la configuración del volumen de Amazon EBS durante la implementación de Amazon ECS](configure-ebs-volume.md). La configuración del volumen se aplaza hasta el momento del lanzamiento mediante el parámetro `configuredAtLaunch` de la definición de la tarea. Al proporcionar la configuración del volumen en el momento del lanzamiento y no en la definición de la tarea, se logran crear definiciones de tareas que no se limitan a un tipo de volumen de datos específico ni a una configuración de volumen de EBS específica. A continuación, puede reutilizar las definiciones de tareas en distintos tiempos de ejecución. Por ejemplo, durante la implementación, puede proporcionar un mayor rendimiento para las cargas de trabajo de producción que para los entornos de preproducción. Los volúmenes de Amazon EBS adjuntos a las tareas se pueden cifrar con claves de AWS Key Management Service (AWS KMS) para proteger los datos. Para obtener más información, consulte [Datos cifrados almacenados en volúmenes de Amazon EBS adjuntos a tareas de Amazon ECS](ebs-kms-encryption.md). Para supervisar el rendimiento del volumen, también puede utilizar las métricas de Amazon CloudWatch. Para obtener más información acerca de las métricas de Amazon ECS correspondientes a los volúmenes de Amazon EBS, consulte [Métricas de CloudWatch de Amazon ECS](available-metrics.md) y [Amazon ECS Container Insights metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html). Se admite adjuntar un volumen de Amazon EBS a una tarea en todas las [Regiones de AWS](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html?icmpid=docs_homepage_addtlrcs#region) comerciales y de China que admiten Amazon ECS. ## Sistemas operativos y capacidad compatibles En la siguiente tabla se proporcionan las configuraciones de sistema operativo y la capacidad compatibles. | Capacidad | Linux | Windows | | --- | --- | --- | | Fargate | Los volúmenes de Amazon EBS son compatibles con la versión de la plataforma 1.4.0 o posterior (Linux). Para obtener más información, consulte [Versiones de la plataforma Fargate para Amazon ECS](platform-fargate.md). | No admitido | | EC2 | Los volúmenes de Amazon EBS son compatibles para tareas alojadas en instancias basadas en Nitro con imágenes de máquina de Amazon (AMI) optimizadas para Amazon ECS. Para más información acerca de los tipos de instancias, consulte [Instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) en la Guía del usuario de Amazon EC2. Los volúmenes de Amazon EBS son compatibles con una AMI optimizada para ECS `20231219` o posterior. Para obtener más información, consulte [Recuperación de los metadatos de la AMI optimizada para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_AMI.html). | Tareas alojadas en instancias basadas en Nitro con imágenes de máquina de Amazon (AMI) optimizadas para Amazon ECS. Para más información acerca de los tipos de instancias, consulte [Instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) en la Guía del usuario de Amazon EC2. Los volúmenes de Amazon EBS son compatibles con una AMI optimizada para ECS `20241017` o posterior. Para obtener más información, consulte [Recuperación de los metadatos de la AMI de Windows optimizada para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_windows_AMI.html). | | Instancias administradas de Amazon ECS | Los volúmenes de Amazon EBS son compatibles con las tareas alojadas en instancias de instancias administradas de Amazon ECS en Linux. | No admitido | ## Consideraciones Al utilizar los volúmenes de Amazon EBS, tenga en cuenta lo siguiente: + No puede configurar los volúmenes de Amazon EBS para adjuntarlos a las tareas de Amazon ECS en Fargate en la zona de disponibilidad `use1-az3`. + No se admite el tipo de volumen magnético (`standard`) de Amazon EBS para las tareas de Fargate. Para obtener más información sobre los volúmenes de Amazon EBS, consulte [Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) en la *Guía del usuario de Amazon EC2*. + Se requiere un rol de IAM en la infraestructura de Amazon ECS al crear un servicio o una tarea independiente que consiste en configurar un volumen en el momento de la implementación. Puede adjuntar la política de IAM `AmazonECSInfrastructureRolePolicyForVolumes` administrada por AWS al rol, o puede utilizar la política administrada como guía para crear y adjuntar su propia política con los permisos que cumplan sus necesidades específicas. Para obtener más información, consulte [Rol de IAM de infraestructura de Amazon ECS](infrastructure_IAM_role.md). + Puede adjuntar como máximo un volumen de Amazon EBS a cada tarea de Amazon ECS y debe ser un volumen nuevo. No se puede adjuntar un volumen existente de Amazon EBS a una tarea. Sin embargo, puede configurar un volumen nuevo de Amazon EBS en el momento de la implementación mediante la instantánea de un volumen existente. + Para utilizar los volúmenes de Amazon EBS con los servicios de Amazon ECS, el controlador de implementación debe ser `ECS`. Cuando se utiliza este controlador de implementación, se admiten estrategias de implementación azul/verde y continua. + Para que un contenedor de la tarea escriba en el volumen de Amazon EBS montado, el contenedor debe tener los permisos de sistema de archivos adecuados. Cuando especifica un usuario que no es usuario raíz en la definición del contenedor, Amazon ECS configura automáticamente el volumen con permisos basados en grupos que permiten al usuario especificado leer y escribir en el volumen. Si no se especifica ningún usuario, el contenedor se pone en marcha como raíz y tiene acceso total al volumen. + Amazon ECS agrega automáticamente las etiquetas reservadas `AmazonECSCreated` y `AmazonECSManaged` al volumen adjunto. Si elimina estas etiquetas del volumen, Amazon ECS no podrá administrar el volumen en su nombre. Para obtener más información acerca del etiquetado de volúmenes de Amazon EBS, consulte [Tagging Amazon EBS volumes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specify-ebs-config.html#ebs-volume-tagging). Para obtener más información acerca del etiquetado de recursos de Amazon ECS, consulte [Tagging your Amazon ECS resources](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html). + No se admite el aprovisionamiento de volúmenes a partir de una instantánea de un volumen de Amazon EBS que contiene particiones. + Los volúmenes adjuntos a tareas administradas por un servicio no se conservan y siempre se eliminan al terminar la tarea. + No puede configurar los volúmenes de Amazon EBS para adjuntarlos a las tareas de Amazon ECS que se ejecutan en AWS Outposts. # Comportamiento de usuarios no raíz Cuando especifica un usuario que no es usuario raíz en la definición del contenedor, Amazon ECS configura automáticamente el volumen de Amazon EBS con permisos basados en grupos que permiten al usuario especificado leer y escribir en el volumen. El volumen se monta con las características siguientes: + El volumen es propiedad del usuario raíz y del grupo raíz. + Los permisos de grupo están configurados para permitir el acceso de lectura y escritura. + El usuario que no es raíz se agrega al grupo correspondiente para acceder al volumen. Siga estas prácticas recomendadas cuando utilice los volúmenes de Amazon EBS con contenedores que no sean raíz: + Utilice id. de usuario (UID) e id. de grupo (GID) coherentes en las imágenes del contenedor para garantizar la coherencia de los permisos. + Cree previamente los directorios de puntos de montaje en la imagen del contenedor y establezca la propiedad y los permisos adecuados. + Pruebe los contenedores con volúmenes de Amazon EBS en un entorno de desarrollo para confirmar que los permisos del sistema de archivos funcionan según lo previsto. + Si varios contenedores de la misma tarea comparten un volumen, asegúrese de que utilizan UID/GID compatibles o que montan el volumen con unas expectativas de acceso coherentes. # Aplazamiento de la configuración del volumen a la hora de lanzamiento en la definición de la tarea de Amazon ECS Para configurar un volumen de Amazon EBS para adjuntarlo a la tarea, debe indicar la configuración del punto de montaje en la definición de la tarea y asignar un nombre al volumen. También debe establecer `configuredAtLaunch` en `true` porque los volúmenes de Amazon EBS no se pueden configurar para adjuntarlos en la definición de la tarea. En su lugar, los volúmenes de Amazon EBS se configuran para que se adjunten durante la implementación. Para registrar la definición de la tarea mediante la AWS Command Line Interface (AWS CLI), guarde la plantilla como archivo JSON y, luego, pase el archivo como entrada para el comando `[register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html)`. Para crear y registrar una definición de tarea mediante la Consola de administración de AWS, consulte [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md). La definición de la tarea siguiente muestra la sintaxis de los objetos `mountPoints` y `volumes` en la definición de la tarea. Para más información acerca de los parámetros de la definición de la tarea, consulte [Parámetros en la definición de tareas de Amazon ECS para Fargate](task_definition_parameters.md). Para utilizar este ejemplo, sustituya `user input placeholders` por su propia información. ## Linux ``` { "family": "mytaskdef", "containerDefinitions": [ { "name": "nginx", "image": "public.ecr.aws/nginx/nginx:latest", "networkMode": "awsvpc", "portMappings": [ { "name": "nginx-80-tcp", "containerPort": 80, "hostPort": 80, "protocol": "tcp", "appProtocol": "http" } ], "mountPoints": [ { "sourceVolume": "myEBSVolume", "containerPath": "/mount/ebs", "readOnly": true } ] } ], "volumes": [ { "name": "myEBSVolume", "configuredAtLaunch": true } ], "requiresCompatibilities": [ "FARGATE", "EC2" ], "cpu": "1024", "memory": "3072", "networkMode": "awsvpc" } ``` ## Windows ``` { "family": "mytaskdef", "memory": "4096", "cpu": "2048", "family": "windows-simple-iis-2019-core", "executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole", "runtimePlatform": {"operatingSystemFamily": "WINDOWS_SERVER_2019_CORE"}, "requiresCompatibilities": ["EC2"] "containerDefinitions": [ { "command": ["New-Item -Path C:\\inetpub\\wwwroot\\index.html -Type file -Value ' Amazon ECS Sample App

Amazon ECS Sample App

Congratulations!

Your application is now running on a container in Amazon ECS.

'; C:\\ServiceMonitor.exe w3svc"], "entryPoint": [ "powershell", "-Command" ], "essential": true, "cpu": 2048, "memory": 4096, "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019", "name": "sample_windows_app", "portMappings": [ { "hostPort": 443, "containerPort": 80, "protocol": "tcp" } ], "mountPoints": [ { "sourceVolume": "myEBSVolume", "containerPath": "drive:\ebs", "readOnly": true } ] } ], "volumes": [ { "name": "myEBSVolume", "configuredAtLaunch": true } ], "requiresCompatibilities": [ "FARGATE", "EC2" ], "cpu": "1024", "memory": "3072", "networkMode": "awsvpc" } ``` `mountPoints` Tipo: matriz de objetos Obligatorio: no Puntos de montaje para los volúmenes de datos del contenedor. Este parámetro asigna a `Volumes` en la API create-container de Docker y la opción `--volume` a docker run. Los contenedores de Windows pueden montar directorios completos en la misma unidad que `$env:ProgramData`. Los contenedores de Windows no pueden montar directorios en una unidad diferente y los puntos de montaje no se pueden utilizar entre unidades. Debe especificar los puntos de montaje para adjuntar un volumen de Amazon EBS directamente a una tarea de Amazon ECS. `sourceVolume` Tipo: cadena Obligatorio: sí, si se utilizan `mountPoints`. El nombre del volumen a montar. `containerPath` Tipo: cadena Obligatorio: sí, si se utilizan `mountPoints`. La ruta del contenedor donde se montará el volumen. `readOnly` Tipo: Booleano Obligatorio: no Si este valor es `true`, el acceso del contenedor al volumen es de solo lectura. Si este valor es `false`, el contenedor puede escribir en el volumen. El valor predeterminado es `false`. Para las tareas que se ejecutan en instancias de EC2 que ejecutan el sistema operativo Windows, deje el valor predeterminado de `false`. `name` Tipo: cadena Requerido: no El nombre del volumen. Se admiten hasta 255 letras (mayúsculas y minúsculas), números, guiones (`-`) y caracteres de subrayado (`_`). Se hace referencia a este nombre en el parámetro `sourceVolume` del objeto `mountPoints` de la definición de contenedor. `configuredAtLaunch` Tipo: booleano Obligatorio: sí, cuando quiera adjuntar un volumen de EBS directamente a una tarea. Indica si un volumen se puede configurar durante el lanzamiento. Cuando se establece en `true`, puede configurarlo se ejecuta una tarea independiente o cuando se crea o actualiza un servicio. Cuando se establece en `false`, no podrá proporcionar otra configuración de volumen en la definición de la tarea. Este parámetro debe proporcionarse y establecerse en `true` para configurar un volumen de Amazon EBS para adjuntarlo a una tarea. # Datos cifrados almacenados en volúmenes de Amazon EBS adjuntos a tareas de Amazon ECS Puede utilizar AWS Key Management Service (AWS KMS) para crear y administrar claves criptográficas que protejan los datos. Los volúmenes de Amazon EBS se cifran en reposo mediante AWS KMS keys. Se cifran los tipos de datos siguientes: + Datos almacenados en reposo en el volumen + E/S de disco + Instantáneas creadas a partir del volumen + Volúmenes nuevos creados a partir de las instantáneas cifradas Los volúmenes de Amazon EBS adjuntos a las tareas se pueden cifrar mediante una Clave administrada de AWS predeterminada con el alias `alias/aws/ebs` o una clave simétrica administrada por el cliente especificada en la configuración del volumen. Las Claves administradas por AWS predeterminadas son exclusivas de cada Cuenta de AWS por Región de AWS y se crean automáticamente. Para crear una clave simétrica administrada por el cliente, siga los pasos que se indican en la sección [Creating symmetric encryption KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) en *AWS KMS Developer Guide*. Puede configurar el cifrado de Amazon EBS de manera predeterminada para que todos los volúmenes nuevos creados y adjuntos a una tarea en una Región de AWS específica se cifren mediante la clave de KMS que configure para su cuenta. Para obtener más información acerca del cifrado de Amazon EBS y el cifrado de manera predeterminada, consulte [Cifrado de Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) en la *Guía del usuario de Amazon EBS*. ## Comportamiento de instancias administradas de Amazon ECS Puede cifrar los volúmenes de Amazon EBS. Para ello, habilite el cifrado, ya sea mediante el cifrado de forma predeterminada o habilite el cifrado al crear un volumen que quiera cifrar. Para obtener información acerca de cómo habilitar el cifrado de manera predeterminada (a nivel de cuenta), consulte [Cifrado de manera predeterminada](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html) en la *Guía del usuario de Amazon EBS*. Puede configurar cualquier combinación de estas claves. El orden de prioridad de las claves de KMS es el siguiente: 1. La clave de KMS especificada en la configuración del volumen. Al especificar una clave de KMS en la configuración del volumen, esta anula la clave predeterminada de Amazon EBS y cualquier clave de KMS que se especifique de la cuenta. 1. La clave de KMS especificada de la cuenta. Cuando especifica una clave de KMS para el cifrado a nivel de clúster del almacenamiento administrado de Amazon ECS, esta anula el cifrado predeterminado de Amazon EBS, pero no anula ninguna clave de KMS que se especifique en la configuración del volumen. 1. Cifrado predeterminado de Amazon EBS. El cifrado predeterminado se aplica cuando no se especifica una clave de KMS por cuenta ni una clave en la configuración del volumen. Si activa el cifrado de Amazon EBS de forma predeterminada, el valor predeterminado es la clave de KMS que especifique para el cifrado predeterminado. De lo contrario, el valor predeterminado es la Clave administrada de AWS con el alias `alias/aws/ebs`. **nota** Si establece `encrypted` en `false` en la configuración del volumen, no especifica ninguna clave de KMS a nivel de cuenta y activa el cifrado de Amazon EBS de forma predeterminada, el volumen seguirá estando cifrado con la clave especificada para el cifrado de Amazon EBS predeterminado. ## Comportamiento de instancias administradas no relacionadas con Amazon ECS También puede configurar el cifrado a nivel de clúster de Amazon ECS para el almacenamiento administrado de Amazon ECS al crear o actualizar un clúster. El cifrado del clúster se aplica a la tarea y se puede utilizar para cifrar los volúmenes de Amazon EBS asociados a cada tarea que se pone en marcha en un clúster específico mediante la clave KMS especificada. Para obtener más información acerca de la configuración del cifrado del clúster para cada tarea, consulte [ManagedStorageConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedStorageConfiguration.html) en la *Referencia de la API de Amazon ECS*. Puede configurar cualquier combinación de estas claves. El orden de prioridad de las claves de KMS es el siguiente: 1. La clave de KMS especificada en la configuración del volumen. Al especificar una clave de KMS en la configuración del volumen, esta anula la clave predeterminada de Amazon EBS y cualquier clave de KMS que se especifique a nivel de clúster. 1. La clave de KMS especificada a nivel de clúster. Cuando especifica una clave de KMS para el cifrado a nivel de clúster del almacenamiento administrado de Amazon ECS, esta anula el cifrado predeterminado de Amazon EBS, pero no anula ninguna clave de KMS que se especifique en la configuración del volumen. 1. Cifrado predeterminado de Amazon EBS. El cifrado predeterminado se aplica cuando no se especifica una clave de KMS a nivel de clúster ni una clave en la configuración del volumen. Si activa el cifrado de Amazon EBS de forma predeterminada, el valor predeterminado es la clave de KMS que especifique para el cifrado predeterminado. De lo contrario, el valor predeterminado es la Clave administrada de AWS con el alias `alias/aws/ebs`. **nota** Si establece `encrypted` como `false` en su configuración de volumen, no especifica ninguna clave de KMS a nivel de clúster y activa el cifrado de Amazon EBS de forma predeterminada, el volumen seguirá estando cifrado con la clave especificada para el cifrado de Amazon EBS predeterminado. ## Política de claves de KMS administradas por el cliente Para cifrar un volumen de EBS adjunto a la tarea mediante una clave administrada por el cliente, debe configurar su política de claves de KMS para garantizar que el rol de IAM que utiliza para la configuración del volumen tenga los permisos necesarios para utilizar la clave. La política de claves debe incluir los permisos `kms:CreateGrant` y `kms:GenerateDataKey*`. Los permisos `kms:ReEncryptTo` y `kms:ReEncryptFrom` son necesarios para cifrar los volúmenes que se crean mediante instantáneas. Si quiere configurar y cifrar solo los volúmenes nuevos y vacíos para adjuntarlos, puede excluir los permisos `kms:ReEncryptTo` y `kms:ReEncryptFrom`. En el fragmento de código siguiente de JSON se muestran la instrucciones de la política de claves que puede adjuntar a la política de claves de KMS. El uso de estas instrucciones proporcionará acceso para que Amazon ECS utilice la clave para cifrar el volumen de EBS. Para utilizar las instrucciones de la política de ejemplo, sustituya `user input placeholders` por su propia información. Como siempre, configure únicamente los permisos que necesite. ``` { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/ecsInfrastructureRole" }, "Action": "kms:DescribeKey", "Resource":"*" }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/ecsInfrastructureRole" }, "Action": [ "kms:GenerateDataKey*", "kms:ReEncryptTo", "kms:ReEncryptFrom" ], "Resource":"*", "Condition": { "StringEquals": { "kms:CallerAccount": "aws_account_id", "kms:ViaService": "ec2.region.amazonaws.com" }, "ForAnyValue:StringEquals": { "kms:EncryptionContextKeys": "aws:ebs:id" } } }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/ecsInfrastructureRole" }, "Action": "kms:CreateGrant", "Resource":"*", "Condition": { "StringEquals": { "kms:CallerAccount": "aws_account_id", "kms:ViaService": "ec2.region.amazonaws.com" }, "ForAnyValue:StringEquals": { "kms:EncryptionContextKeys": "aws:ebs:id" }, "Bool": { "kms:GrantIsForAWSResource": true } } } ``` Para más información acerca de los permisos y las políticas de claves, consulte [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) y [AWS KMS permissions](https://docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html) en la *Guía para desarrolladores de AWS KMS*. Para solucionar los problemas de la conexión de volúmenes de EBS relacionados con los permisos de claves, consulte [Solución de problemas de conexión de volúmenes de Amazon EBS a las tareas de Amazon ECS](troubleshoot-ebs-volumes.md). # Especificación de la configuración del volumen de Amazon EBS durante la implementación de Amazon ECS Tras registrar una definición de la tarea con el parámetro `configuredAtLaunch` establecido en `true`, puede configurar un volumen de Amazon EBS durante la implementación cuando ejecute una tarea independiente o cuando cree o actualice un servicio. Para obtener más información acerca de cómo aplazar la configuración del volumen hasta el momento del lanzamiento mediante el parámetro `configuredAtLaunch`, consulte [Aplazamiento de la configuración del volumen a la hora de lanzamiento en la definición de la tarea de Amazon ECS](specify-ebs-config.md). Para configurar un volumen, puede utilizar las API de Amazon ECS o pasar un archivo JSON como entrada para los comandos siguientes de la AWS CLI: + `[run-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html)` para ejecutar una tarea de ECS independiente. + `[start-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/start-task.html)` para ejecutar una tarea de ECS independiente en una instancia de contenedor específica. Este comando no se aplica a las tareas de Fargate. + `[create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)` para crear un nuevo servicio de ECS. + `[update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html)` para actualizar un servicio existente. **nota** Para que un contenedor de la tarea escriba en el volumen de Amazon EBS montado, el contenedor debe tener los permisos de sistema de archivos adecuados. Cuando especifica un usuario que no es usuario raíz en la definición del contenedor, Amazon ECS configura automáticamente el volumen con permisos basados en grupos que permiten al usuario especificado leer y escribir en el volumen. Si no se especifica ningún usuario, el contenedor se pone en marcha como raíz y tiene acceso total al volumen. También puede configurar un volumen de Amazon EBS mediante Consola de administración de AWS. Para obtener más información, consulte [Ejecución de una aplicación como tarea de Amazon ECS](standalone-task-create.md), [Creación de una implementación de actualización continua de Amazon ECS](create-service-console-v2.md) y [Actualización de un servicio de Amazon ECS](update-service-console-v2.md). El siguiente fragmento de código JSON muestra todos los parámetros de un volumen de Amazon EBS que se pueden configurar durante la implementación. Para utilizar estos parámetros en la configuración el volumen, sustituya `user input placeholders` por su propia información. Para más información acerca de estos parámetros, consulte [Volume configurations](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-volumeConfigurations). ``` "volumeConfigurations": [ { "name": "ebs-volume", "managedEBSVolume": { "encrypted": true, "kmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "volumeType": "gp3", "sizeInGiB": 10, "snapshotId": "snap-12345", "volumeInitializationRate":100, "iops": 3000, "throughput": 125, "tagSpecifications": [ { "resourceType": "volume", "tags": [ { "key": "key1", "value": "value1" } ], "propagateTags": "NONE" } ], "roleArn": "arn:aws:iam::1111222333:role/ecsInfrastructureRole", "terminationPolicy": { "deleteOnTermination": true//can't be configured for service-managed tasks, always true }, "filesystemType": "ext4" } } ] ``` **importante** Asegúrese de que la propiedad `volumeName` que indicó en la configuración sea la misma que la propiedad `volumeName` que indicó en la definición de la tarea. Para obtener información acerca de la comprobación del estado conexión de volúmenes, consulte [Solución de problemas de conexión de volúmenes de Amazon EBS a las tareas de Amazon ECS](troubleshoot-ebs-volumes.md). Para obtener información acerca del rol de AWS Identity and Access Management (IAM) de la infraestructura de Amazon ECS necesaria para adjuntar volúmenes de EBS, consulte [Rol de IAM de infraestructura de Amazon ECS](infrastructure_IAM_role.md). A continuación, se muestran ejemplos de fragmentos de código de JSON que muestran la configuración de los volúmenes de Amazon EBS. Estos ejemplos se pueden utilizar si se guardan los fragmentos de código en archivos JSON y si se pasan como parámetros (con el parámetro `--cli-input-json file://filename`) para los comandos de la AWS CLI. Sustituya `user input placeholders` por su propia información. ## Configuración de un volumen para una tarea independiente En el siguiente fragmento de código se muestra la sintaxis para configurar los volúmenes de Amazon EBS para adjuntarlos a una tarea independiente. En el siguiente fragmento de código de JSON se muestra la sintaxis para configurar los valores `volumeType`, `sizeInGiB`, `encrypted` y `kmsKeyId`. La configuración indicada en el archivo JSON se utiliza para crear y adjuntar un volumen de EBS a la tarea independiente. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "volumeConfigurations": [ { "name": "datadir", "managedEBSVolume": { "volumeType": "gp3", "sizeInGiB": 100, "roleArn":"arn:aws:iam::1111222333:role/ecsInfrastructureRole", "encrypted": true, "kmsKeyId": "arn:aws:kms:region:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" } } ] } ``` ## Configuración de un volumen durante la creación del servicio En el siguiente fragmento de código se muestra la sintaxis para configurar los volúmenes de Amazon EBS para adjuntarlos a tareas administradas por un servicio. Los volúmenes se obtienen de la instantánea especificada mediante el parámetro `snapshotId` a una velocidad de 200 MiB/s. La configuración indicada en el archivo JSON se utiliza para crear y adjuntar un volumen de EBS a cada tarea administrada por el servicio. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "serviceName": "mysvc", "desiredCount": 2, "volumeConfigurations": [ { "name": "myEbsVolume", "managedEBSVolume": { "roleArn":"arn:aws:iam::1111222333:role/ecsInfrastructureRole", "snapshotId": "snap-12345", "volumeInitializationRate": 200 } } ] } ``` ## Configuración de un volumen durante la actualización del servicio El siguiente fragmento de código JSON muestra la sintaxis para actualizar un servicio que anteriormente no tenía los volúmenes de Amazon EBS configurados para adjuntarlos a las tareas. Debe proporcionar el ARN de una revisión de la definición de las tareas con el parámetro `configuredAtLaunch` establecido en `true`. En el siguiente fragmento de código de JSON se muestra la sintaxis para configurar los valores `volumeType`, `sizeInGiB`, `throughput`, `iops` y `filesystemType`. Esta configuración se utiliza para crear y adjuntar un volumen de EBS a cada tarea administrada por el servicio. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "service": "mysvc", "desiredCount": 2, "volumeConfigurations": [ { "name": "myEbsVolume", "managedEBSVolume": { "roleArn":"arn:aws:iam::1111222333:role/ecsInfrastructureRole", "volumeType": "gp3", "sizeInGiB": 100, "iops": 3000, "throughput": 125, "filesystemType": "ext4" } } ] } ``` ### Configuración de un servicio para que deje de utilizar los volúmenes de Amazon EBS El siguiente fragmento de código JSON muestra la sintaxis para actualizar un servicio para que deje de utilizar los volúmenes de Amazon EBS. Debe proporcionar el ARN de una definición de tareas con el parámetro `configuredAtLaunch` establecido en `false` o una definición de tareas sin el parámetro `configuredAtLaunch`. También debe proporcionar un objeto `volumeConfigurations` vacío. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "service": "mysvc", "desiredCount": 2, "volumeConfigurations": [] } ``` ## Política de finalización para volúmenes de Amazon EBS Cuando termina una tarea de Amazon ECS, dicho servicio utiliza el valor `deleteOnTermination` para determinar si se debe eliminar el volumen de Amazon EBS asociado a la tarea terminada. De manera predeterminada, los volúmenes de EBS asociados a las tareas se eliminan al finalizar la tarea. En el caso de las tareas independientes, puede cambiar esta configuración para conservar el volumen al terminar la tarea. **nota** Los volúmenes adjuntos a tareas administradas por un servicio no se conservan y siempre se eliminan al terminar la tarea. ## Etiquetar volúmenes de Amazon EBS Puede etiquetar los volúmenes de Amazon EBS mediante el objeto `tagSpecifications`. Con el objeto, puede proporcionar sus propias etiquetas y establecer la propagación de las etiquetas a partir de la definición de la tarea o del servicio, en función de si el volumen está adjunto a una tarea independiente o a una tarea de un servicio. La cantidad máxima de etiquetas que puede adjuntarse a un volumen es 50. **importante** Amazon ECS adjunta automáticamente las etiquetas reservadas `AmazonECSCreated` y `AmazonECSManaged` a un volumen de Amazon EBS. Esto significa que puede controlar la conexión de un máximo de 48 etiquetas adicionales a un volumen. Estas etiquetas adicionales pueden ser etiquetas definidas por el usuario, administradas por ECS o propagadas. Si quiere agregar etiquetas administradas por Amazon ECS al volumen, debe establecer `enableECSManagedTags` en `true` en la llamada de `UpdateService`, `CreateService`, `RunTask` o `StartTask`. Si activa las etiquetas administradas por Amazon ECS, este servicio etiquetará el volumen automáticamente con información del clúster y del servicio (`aws:ecs:clusterName` y `aws:ecs:serviceName`). Para obtener más información acerca del etiquetado de recursos de Amazon ECS, consulte [Tagging your Amazon ECS resources](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html). El siguiente fragmento de código JSON muestra la sintaxis para etiquetar cada volumen de Amazon EBS adjunto a cada tarea de un servicio con una etiqueta definida por el usuario. Para utilizar este ejemplo y crear un servicio, sustituya `user input placeholders` por su propia información. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "serviceName": "mysvc", "desiredCount": 2, "enableECSManagedTags": true, "volumeConfigurations": [ { "name": "datadir", "managedEBSVolume": { "volumeType": "gp3", "sizeInGiB": 100, "tagSpecifications": [ { "resourceType": "volume", "tags": [ { "key": "key1", "value": "value1" } ], "propagateTags": "NONE" } ], "roleArn":"arn:aws:iam:1111222333:role/ecsInfrastructureRole", "encrypted": true, "kmsKeyId": "arn:aws:kms:region:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" } } ] } ``` **importante** Debe indicar un tipo de recurso `volume` para etiquetar los volúmenes de Amazon EBS. # Rendimiento de los volúmenes de Amazon EBS para las tareas bajo demanda de Fargate El IOPS y el rendimiento de los volúmenes de referencia de Amazon EBS disponibles para una tarea bajo demanda de Fargate varían en función del total de unidades de CPU que solicite para la tarea. Si solicita 0,25, 0,5 o 1 unidad de CPU virtual (vCPU) para la tarea de Fargate, recomendamos configurar un volumen SSD de uso general (`gp2` o `gp3`) o un volumen de unidad de disco duro (HDD) (`st1` o `sc1`). Si solicita más de 1 vCPU para la tarea de Fargate, se aplicarán los siguientes límites de rendimiento básico a un volumen de Amazon EBS adjunto a la tarea. Es posible que obtenga temporalmente un rendimiento de EBS superior a los límites siguientes. Sin embargo, recomendamos planificar la carga de trabajo en función de estos límites. | Unidades de CPU solicitadas (en vCPU) | IOPS de referencia de Amazon EBS (E/S de 16 KiB) | Rendimiento de referencia de Amazon EBS (en MiBps, E/S de 128 KiB) | Ancho de banda de referencia (en Mbps) | | --- | --- | --- | --- | | 2 | 3000 | 75 | 360 | | 4 | 5 000 | 120 | 1.150 | | 8 | 10 000 | 250 | 2.300 | | 16 | 15.000 | 500 | 4500 | **nota** Al configurar un volumen de Amazon EBS para adjuntarlo a una tarea de Fargate, el límite de rendimiento de Amazon EBS de la tarea de Fargate se comparte entre el almacenamiento efímero de la tarea y el volumen adjunto. # Rendimiento de los volúmenes de Amazon EBS para tareas de EC2 Amazon EBS proporciona tipos de volúmenes, que difieren en cuanto a rendimiento y precio, para que pueda adaptar el rendimiento y el costo del almacenamiento a las necesidades de las aplicaciones. Para obtener información sobre el rendimiento, incluidas las IOPS por volumen y el rendimiento por volumen, consulte [Tipos de volumen de Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) en la *Guía del usuario de Amazon Elastic Block Store*. # Rendimiento de los volúmenes de Amazon EBS para tareas de instancias administradas de Amazon ECS Amazon EBS proporciona tipos de volúmenes, que difieren en cuanto a rendimiento y precio, para que pueda adaptar el rendimiento y el costo del almacenamiento a las necesidades de las aplicaciones. Para obtener información sobre el rendimiento, incluidas las IOPS por volumen y el rendimiento por volumen, consulte [Tipos de volumen de Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) en la *Guía del usuario de Amazon Elastic Block Store*. # Solución de problemas de conexión de volúmenes de Amazon EBS a las tareas de Amazon ECS Es posible que deba solucionar los problemas de conexión de los volúmenes de Amazon EBS a las tareas de Amazon ECS, o comprobarla. ## Compruebe el estado de conexión de volúmenes Puede utilizar la Consola de administración de AWS para ver el estado de conexión de un volumen de Amazon EBS a una tarea de Amazon ECS. Si la tarea se inicia y se produce un error al adjuntar el volumen, también verá un motivo de estado que podrá utilizar para solucionar el problema. El volumen creado se eliminará y la tarea se detendrá. Para más información acerca de los motivos de estado, consulte [Motivos del estado de la conexión de volúmenes de Amazon EBS a las tareas de Amazon ECS](troubleshoot-ebs-volumes-scenarios.md). **Para ver el estado de conexión de un volumen y el motivo del estado mediante la consola** 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En la página **Clústeres**, elija el clúster en el que se ejecuta la tarea. Se abrirá la página de detalles del clúster. 1. En la página de detalles del clúster, elija la pestaña **Tareas**. 1. Elija la tarea para ver el estado de conexión de volúmenes. Puede que tenga que utilizar **Filtrar estado deseado** y elegir **Detenido** si la tarea que quiere examinar se ha detenido. 1. En la página de detalles de la tarea, elija la pestaña **Volúmenes**. Podrá ver el estado de la conexión de Amazon EBS en **Estado de la conexión**. Si el volumen no se puede conectar a la tarea, puede elegir el estado en **Estado de la conexión** para mostrar la causa del error. También puede ver el estado de la conexión del volumen de una tarea y el motivo del estado asociado mediante la API [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html). ## Errores en las tareas y los servicios Es posible que se produzcan errores en el servicio o en las tareas que no sean específicos de los volúmenes de Amazon EBS y que puedan afectar a la conexión de volúmenes. Para más información, consulte + [Mensajes de eventos de servicio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-event-messages.html) + [Códigos de error de tareas detenidas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/stopped-task-error-codes.html) + [Motivos de los errores de la API](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/api_failures_messages.html) # El contenedor no puede escribir en el volumen de Amazon EBS Usuario no raíz sin los permisos adecuados Cuando especifica un usuario que no es usuario raíz en la definición del contenedor, Amazon ECS configura automáticamente el volumen con permisos basados en grupos que permiten acceso de escritura. Sin embargo, si sigue teniendo problemas con los permisos, haga lo siguiente: + Compruebe que el parámetro `user` esté especificado de manera correcta en la definición del contenedor mediante el formato `uid:gid` (por ejemplo, `1001:1001`). + Asegúrese de que la imagen del contenedor no anule los permisos de usuario una vez montado el volumen. + Compruebe que la aplicación se pone en marcha con el id. de usuario esperado. Para ello, examine los registros del contenedor o utilice Amazon ECS Exec para inspeccionar el contenedor en marcha. Usuario raíz con problemas de permisos Si no se especifica ningún usuario en la definición del contenedor, este se pone en marcha como raíz y debe tener acceso total al volumen. Si tiene problemas, haga lo siguiente: + Compruebe que el volumen esté montado de manera correcta. Compruebe los puntos de montaje dentro del contenedor. + Asegúrese de que el volumen no esté configurado como de solo lectura en la configuración del punto de montaje. Tareas de varios contenedores con diferentes usuarios En las tareas en las que varios contenedores se ponen en marcha como usuarios diferentes, Amazon ECS administra automáticamente los permisos de grupo para permitir que todos los usuarios especificados escriban en el volumen. Si los contenedores no pueden escribir, haga lo siguiente: + Compruebe que todos los contenedores que requieren acceso de escritura tengan el parámetro `user` configurado de manera correcta. + Compruebe que el volumen esté montado en todos los contenedores que necesiten acceder a este. Para obtener más información acerca de la configuración de los usuarios en las definiciones de contenedores, consulte [Parámetros de la definición de tareas de Amazon ECS para Fargate](https://docs.aws.amazon.com/./task_definition_parameters.html). # Motivos del estado de la conexión de volúmenes de Amazon EBS a las tareas de Amazon ECS Utilice la siguiente referencia para solucionar los problemas que puedan surgir como motivos de estado en la Consola de administración de AWS cuando configure los volúmenes de Amazon EBS para adjuntarlos a las tareas de Amazon ECS. Para obtener más información sobre la ubicación de estos motivos de estado, consulte [Compruebe el estado de conexión de volúmenes](troubleshoot-ebs-volumes.md#troubleshoot-ebs-volumes-location). ECS no pudo suponer el rol de la infraestructura de ECS configurado “arn:aws:iam::*111122223333*:role/*ecsInfrastructureRole*”. Compruebe que el rol que se va a transferir tenga la relación de confianza adecuada con Amazon ECS Este motivo de estado aparece en los escenarios siguientes. + Usted proporciona un rol de IAM sin adjuntar la política de confianza necesaria. Amazon ECS no puede acceder al rol de IAM de la infraestructura de Amazon ECS que proporciona si el rol no tiene la política de confianza necesaria. La tarea puede bloquearse en el estado `DEPROVISIONING`. Para más información acerca de la política de confianza necesaria, consulte [Rol de IAM de infraestructura de Amazon ECS](infrastructure_IAM_role.md). + El usuario de IAM no tiene permiso para transferir el rol de infraestructura de Amazon ECS a Amazon ECS. La tarea puede bloquearse en el estado `DEPROVISIONING`. Para evitar este problema, puede adjuntar el permiso `PassRole` a su usuario. Para obtener más información, consulte [Rol de IAM de infraestructura de Amazon ECS](infrastructure_IAM_role.md). + Su rol de IAM no tiene los permisos necesarios para adjuntar los volúmenes de Amazon EBS. La tarea puede bloquearse en el estado `DEPROVISIONING`. Para más información acerca de los permisos específicos necesarios para adjuntar los volúmenes de Amazon EBS a las tareas, consulte [Rol de IAM de infraestructura de Amazon ECS](infrastructure_IAM_role.md). Es posible que también vea este mensaje de error debido a un retraso en la propagación de los roles. Si volver a usar el rol después de esperar unos minutos no soluciona el problema, es posible que la política de confianza del rol este mal configurada. ECS no pudo configurar el volumen de EBS. Se encontró IdempotentParameterMismatch”; “El token de cliente que ha proporcionado está asociado a un recurso que ya se eliminó. Utilice otro token de cliente." Los siguientes escenarios de la clave de AWS KMS pueden provocar la aparición de un mensaje `IdempotentParameterMismatch`: + Indica un ARN, identificador o alias de la clave de KMS que no es válido. En este escenario, puede parecer que la tarea se ha iniciado correctamente, pero finalmente se produce un error porque AWS autentica la clave de KMS de forma asíncrona. Para más información, consulte [Amazon EBS encryption](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) en *Amazon EC2 User Guide*. + Proporciona una clave administrada por el cliente que carece de los permisos que permiten que el rol de IAM de la infraestructura de Amazon ECS utilice la clave para el cifrado. Para evitar problemas de permisos relacionados con la política de claves, consulte la política de claves de AWS KMS de ejemplo en [Data encryption for Amazon EBS volumes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html#ebs-kms-encryption). Puede configurar Amazon EventBridge para enviar eventos de volumen de Amazon EBS y eventos de cambio de estado de las tareas de Amazon ECS a un destino, como los grupos de Amazon CloudWatch. A continuación, puede utilizar estos eventos para identificar el problema específico relacionado con las claves administradas por el cliente que afectó a la conexión del volumen. Para más información, consulte + [¿Cómo se puede crear un grupo de registro de CloudWatch para utilizarlo como destino de una regla de EventBridge?](https://repost.aws/knowledge-center/cloudwatch-log-group-eventbridge) en AWS re:Post. + [Task state change events](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html#ecs_task_events). + [Eventos de Amazon EventBridge para Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-cloud-watch-events.html) en la *Guía del usuario de Amazon EBS*. Se agotó el tiempo de espera de ECS al configurar la conexión del volumen de EBS a la tarea. Los escenarios siguientes de formato del sistema de archivos dan lugar a este mensaje. + El formato del sistema de archivos que indique durante la configuración no es compatible con el [sistema operativo de la tarea](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RuntimePlatform.html). + Usted configura la creación de un volumen de Amazon EBS a partir de una instantánea y el formato del sistema de archivos de la instantánea no es compatible con el sistema operativo de la tarea. En el caso de los volúmenes creados a partir de una instantánea, debe especificar el mismo tipo de sistema de archivos que utilizaba el volumen cuando se creó la instantánea. Puede utilizar los registros del agente del contenedor de Amazon ECS para solucionar este mensaje en las tareas de EC2. Para más información, consulte [Amazon ECS log file locations](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/logs.html) y [Amazon ECS log collector](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-logs-collector.html). # Uso de volúmenes de Amazon EFS con Amazon ECS Amazon Elastic File System (Amazon EFS) proporciona almacenamiento de archivos sencillo y escalable para usarlo con tareas de Amazon ECS. Con Amazon EFS, la capacidad de almacenamiento es elástica. Aumenta y disminuye automáticamente a medida que se agregan o eliminan archivos. Las aplicaciones disponen del almacenamiento que necesitan, cuando lo necesitan. Puede utilizar sistemas de archivos de Amazon EFS con Amazon ECS para exportar los datos del sistema de archivos a través de la flota de instancias de contenedor. De esa forma, las tareas tienen acceso al mismo almacenamiento persistente, con independencia de la instancia en la que aterricen. Las definiciones de tareas deben hacer referencia a montajes de volúmenes en la instancia de contenedor para utilizar el sistema de archivos. Para ver un tutorial, consulte [Configuración de sistemas de archivos de Amazon EFS para Amazon ECS mediante la consola](tutorial-efs-volumes.md). ## Consideraciones Al utilizar volúmenes de Amazon EFS, tenga en cuenta lo siguiente: + Para las tareas que utilizan EC2, se agregó compatibilidad con el sistema de archivos de Amazon EFS como vista previa pública en la AMI optimizada para Amazon ECS versión `20191212` con el agente de contenedor versión 1.35.0. Sin embargo, el sistema de archivos de Amazon EFS está disponible con carácter general a partir de la versión `20200319` de la AMI optimizada para Amazon ECS con el agente de contenedor versión 1.38.0, que contenía las características de punto de acceso de Amazon EFS y autorización de IAM. Recomendamos utilizar la AMI optimizada para Amazon ECS versión `20200319` o una posterior para usar estas características. Para obtener más información, consulte [AMI de Linux optimizadas para Amazon ECS](ecs-optimized_AMI.md). **nota** Si crea su propia AMI, debe usar el agente de contenedor 1.38.0 o posterior, `ecs-init` versión 1.38.0-1 o una posterior, y ejecutar los siguientes comandos en su instancia de Amazon EC2 para habilitar el complemento de volúmenes de Amazon ECS. Los comandos dependen de si utiliza Amazon Linux 2 o Amazon Linux como imagen base. Amazon Linux 2 ``` yum install amazon-efs-utils systemctl enable --now amazon-ecs-volume-plugin ``` Amazon Linux ``` yum install amazon-efs-utils sudo shutdown -r now ``` + Para las tareas que están alojadas en Fargate, los sistemas de archivos de Amazon EFS son compatibles con la versión 1.4.0 o una posterior (Linux) de la plataforma. Para obtener más información, consulte [Versiones de la plataforma Fargate para Amazon ECS](platform-fargate.md). + Cuando se utilizan volúmenes de Amazon EFS para tareas alojadas en Fargate, Fargate crea un contenedor supervisor que es responsable de administrar el volumen de Amazon EFS. El contenedor supervisor utiliza una pequeña cantidad de la memoria de la tarea y de CPU. El contenedor supervisor puede verse al consultar la versión 4 del punto de conexión de metadatos de la tarea. Además, está visible en CloudWatch Container Insights (Información de contenedores de CloudWatch) como el nombre del contenedor `aws-fargate-supervisor`. Para obtener más información acerca del uso de EC2, consulte [Versión 4 del punto de conexión de metadatos de tareas de Amazon ECS](task-metadata-endpoint-v4.md). Para obtener más información acerca del uso de Fargate, consulte [Versión 4 del punto de conexión de los metadatos de tareas de Amazon ECS para tareas en Fargate](task-metadata-endpoint-v4-fargate.md). + No se admite la utilización de volúmenes de Amazon EFS ni la especificación de un `EFSVolumeConfiguration` en instancias externas. + Se admite el uso de volúmenes de Amazon EFS para las tareas que se ponen en marcha en instancias administradas de Amazon ECS. + Se recomienda establecer el parámetro `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION` del archivo de configuración del agente en un valor inferior al predeterminado (aproximadamente 1 hora). Este cambio ayuda a evitar que caduquen las credenciales de montaje de EFS y permite limpiar los montajes que no están en uso. Para obtener más información, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md). ## Uso de puntos de acceso de Amazon EFS Los puntos de acceso de Amazon EFS son puntos de entrada específicos de la aplicación a un sistema de archivos de EFS para administrar el acceso de las aplicaciones a conjuntos de datos compartidos. Para obtener más información acerca de los puntos de acceso de Amazon EFS y cómo controla el acceso a ellos, consulte [Uso de puntos de acceso de Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) en la *Guía del usuario de Amazon Elastic File System*. Los puntos de acceso pueden imponer una identidad de usuario, incluidos los grupos POSIX del usuario, para todas las solicitudes del sistema de archivos que se realizan a través de ellos. Los puntos de acceso también pueden aplicar un directorio raíz diferente para el sistema de archivos. Esto permite que los clientes solo puedan acceder a los datos del directorio especificado o de sus subdirectorios. **nota** Cuando se crea un punto de acceso EFS, especifique una ruta en el sistema de archivos para que sirva como directorio raíz. Cuando se hace referencia al sistema de archivos de EFS con un ID de punto de acceso en la definición de tareas de Amazon ECS, el directorio raíz se debe omitir o establecer en `/`, lo que aplicará la ruta establecida en el punto de acceso de EFS. Puede utilizar un rol de IAM para la tarea de Amazon ECS y exigir que determinadas aplicaciones utilicen un punto de acceso específico. Al combinar políticas de IAM con puntos de acceso, puede proporcionar acceso seguro a conjuntos de datos específicos para sus aplicaciones. Para obtener más información acerca de cómo utilizar los roles de IAM, consulte [Rol de IAM de tarea de Amazon ECS](task-iam-roles.md). # Prácticas recomendadas para utilizar los volúmenes de Amazon EFS con Amazon ECS Tome nota de las siguientes de prácticas recomendadas cuando utilice Amazon EFS con Amazon ECS. ## Controles de seguridad y acceso para los volúmenes de Amazon EFS Amazon EFS ofrece características de control de acceso que puede utilizar para garantizar que los datos almacenados en un sistema de archivos de Amazon EFS estén seguros y solo se pueda acceder a ellos desde las aplicaciones que los necesiten. Para proteger los datos, habilite el cifrado en reposo y en tránsito. Para obtener más información, consulte [Cifrado de datos en Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) en la *Guía del usuario de Amazon Elastic File System*. Además del cifrado de datos, también puede utilizar Amazon EFS para restringir el acceso a un sistema de archivos. Hay tres formas de implementar el control de acceso en EFS. + **Grupos de seguridad**: con los destinos de montaje de Amazon EFS, puede configurar un grupo de seguridad que se utilice para permitir y denegar el tráfico de red. Puede configurar el grupo de seguridad adjunto a Amazon EFS para permitir el tráfico de NFS (puerto 2049) desde el grupo de seguridad conectado a las instancias de Amazon ECS o, si utiliza el modo de red `awsvpc`, desde la tarea de Amazon ECS. + **IAM**: puede restringir el acceso a un sistema de archivos de Amazon EFS mediante IAM. Cuando se configuran, las tareas de Amazon ECS requieren un rol de IAM para acceder al sistema de archivos a fin de montar un sistema de archivos de EFS. Para más información, consulte [Uso de IAM para controlar el acceso a los datos del sistema de archivos](https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html) en la *Guía del usuario de Amazon Elastic File System*. Las políticas de IAM también pueden imponer condiciones predefinidas, como exigir a un cliente que utilice TLS al conectarse a un sistema de archivos de Amazon EFS. Para más información, consulte [Amazon EFS condition keys for clients](https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html#efs-condition-keys-for-nfs) en *Amazon Elastic File System User Guide*. + **Puntos de acceso de Amazon EFS**: los puntos de acceso de Amazon EFS son puntos de entrada específicos de la aplicación a un sistema de archivos de Amazon EFS. Puede utilizar los puntos de acceso para imponer una identidad de usuario, incluidos los grupos POSIX del usuario, para todas las solicitudes del sistema de archivos que se hacen a través del punto de acceso. Los puntos de acceso también pueden aplicar un directorio raíz diferente para el sistema de archivos. Esto permite que los clientes solo puedan acceder a los datos del directorio especificado o de sus subdirectorios. ### Políticas de IAM Puede utilizar políticas de IAM para controlar el acceso al sistema de archivos de Amazon EFS. Puede especificar las siguientes acciones para clientes que acceden a un sistema de archivos mediante una política de sistema de archivos. | Action | Descripción | | --- | --- | | `elasticfilesystem:ClientMount` | Proporciona acceso de solo lectura a un sistema de archivos. | | `elasticfilesystem:ClientWrite` | Proporciona permisos de escritura en un sistema de archivos. | | `elasticfilesystem:ClientRootAccess` | Proporciona la capacidad de utilizar el usuario raíz al acceder a un sistema de archivos. | Debe especificar cada acción en una política. Las políticas pueden definirse de las siguientes maneras: + Basado en cliente: adjunte la política al rol de tareas. Defina la opción de **autorización de IAM** al crear la definición de la tarea. + Basado en recursos: adjunte la política al sistema de archivos de Amazon EFS. Si la política basada en recursos no existe, de forma predeterminada, al crear el sistema de archivos, el acceso se concede a todas las entidades principales (\$1). Al configurar la opción de **autorización de IAM**, combinamos la política asociada al rol de la tarea y la política basada en recursos de Amazon EFS. La opción de **autorización de IAM** transfiere la identidad de la tarea (el rol de la tarea) con la política a Amazon EFS. Esto permite que la política basada en recursos de Amazon EFS tenga contexto para el rol o usuario de IAM especificado en la política. Si no establece la opción, la política de nivel de recursos de Amazon EFS identifica al usuario de IAM como “anónimo”. Considere la posibilidad de implementar los tres controles de acceso en un sistema de archivos de Amazon EFS para obtener la máxima seguridad. Por ejemplo, puede configurar el grupo de seguridad adjunto a un punto de montaje de Amazon EFS para que solo permita la entrada de tráfico de NFS desde un grupo de seguridad asociado a la instancia de contenedor o tarea de Amazon ECS. Además, puede configurar que Amazon EFS requiera un rol de IAM para acceder al sistema de archivos, incluso si la conexión se origina en un grupo de seguridad permitido. Por último, puede utilizar los puntos de acceso de Amazon EFS para aplicar los permisos de usuario de POSIX e indicar los directorios raíz de las aplicaciones. El siguiente fragmento de código de la definición de tareas muestra cómo montar un sistema de archivos de Amazon EFS mediante un punto de acceso. ``` "volumes": [ { "efsVolumeConfiguration": { "fileSystemId": "fs-1234", "authorizationConfig": { "accessPointId": "fsap-1234", "iam": "ENABLED" }, "transitEncryption": "ENABLED", "rootDirectory": "" }, "name": "my-filesystem" } ] ``` ## Desempeño de los volúmenes de Amazon EFS Amazon EFS ofrece dos modos de rendimiento: Uso general y E/S máx. Uso general es adecuado para las aplicaciones sensibles a la latencia, como los sistemas de administración de contenido y las herramientas de CI/CD. Por el contrario, los sistemas de archivos de E/S máx. son adecuados para las cargas de trabajo como el análisis de datos, el procesamiento multimedia y el machine learning. Estas cargas de trabajo deben hacer operaciones en paralelo desde cientos o incluso miles de contenedores y requieren el mayor rendimiento agregado e IOPS posibles. Para más información, consulte [Amazon EFS performance modes](https://docs.aws.amazon.com/efs/latest/ug/performance.html#performancemodes) en *Amazon Elastic File System User Guide*. Algunas cargas de trabajo sensibles a la latencia requieren los niveles de E/S más altos proporcionados por el modo de rendimiento de E/S máximo y la latencia más baja proporcionada por el modo de rendimiento de uso general. Para este tipo de carga de trabajo, recomendamos crear varios sistemas de archivos en modo de desempeño de uso general. De ese modo, puede distribuir la carga de trabajo de la aplicación entre todos estos sistemas de archivos, siempre que la carga de trabajo y las aplicaciones lo admitan. ## Rendimiento de los volúmenes de Amazon EFS Todos los sistemas de archivos de Amazon EFS tienen un rendimiento medido asociado que se determina mediante la cantidad del rendimiento aprovisionado para los sistemas de archivos que utilizan el *rendimiento aprovisionado* o la cantidad de datos almacenados en la clase de almacenamiento EFS Standard o One Zone para los sistemas de archivos que utilizan *rendimiento por ráfagas*. Para más información, consulte [Understanding metered throughput](https://docs.aws.amazon.com/efs/latest/ug/performance.html#read-write-throughput) en *Amazon Elastic File System User Guide*. El modo de rendimiento predeterminado de los sistemas de archivos de Amazon EFS es el modo por ráfagas. Con el modo por ráfagas, el rendimiento disponible para un sistema de archivos aumenta o disminuye a medida que el sistema de archivos crece. Dado que las cargas de trabajo basadas en archivos suelen tener picos, lo que requiere altos niveles de rendimiento durante periodos y bajos niveles de rendimiento el resto del tiempo, Amazon EFS se ha diseñado para permitir altos niveles de rendimiento durante periodos de tiempo. Además, dado que muchas cargas de trabajo son de lectura intensiva, las operaciones de lectura se miden en una proporción de 1:3 con respecto a otras operaciones de NFS (como la escritura). Todos los sistemas de archivos de Amazon EFS ofrecen un rendimiento de referencia coherente de 50 MB/s por cada TB de almacenamiento de Amazon EFS Standard o Amazon EFS One Zone. Todos los sistemas de archivos (con independencia de su tamaño), pueden transmitir por ráfagas hasta 100 MB/s. Los sistemas de archivos con más de 1 TB de almacenamiento EFS Standard o EFS One Zone pueden alcanzar los 100 MB/s por cada TB. Como las operaciones de lectura se miden en una proporción de 1:3, puede generar hasta 300 MiB/s por cada TiB de rendimiento de lectura. A medida que agrega los datos al sistema de archivos, el rendimiento máximo disponible para el sistema de archivos se escala lineal y automáticamente con el almacenamiento en la clase de almacenamiento de Amazon EFS Standard. Si es necesario un rendimiento superior al que se puede lograr con la cantidad de datos almacenados, puede configurar el rendimiento aprovisionado en función de la cantidad específica que requiera la carga de trabajo. El rendimiento del sistema de archivos se comparte entre todas las instancias de Amazon EC2 conectadas a un sistema de archivos. Por ejemplo, un sistema de archivos de 1 TB que puede transmitir por ráfagas hasta 100 MB/s de rendimiento puede generar 100 MB/s desde una sola instancia de Amazon EC2, cada una de las cuales puede generar 10 MB/s. Para obtener más información, consulte [Rendimiento de Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/performance.html) en la *Guía del usuario de Amazon Elastic File System*. ## Optimización de costos de los volúmenes de Amazon EFS Amazon EFS simplifica el escalado del almacenamiento. Los sistemas de archivos de Amazon EFS crecen automáticamente a medida que se agregan más datos. Sobre todo con el modo *Rendimiento por ráfagas* de Amazon EFS, el rendimiento de Amazon EFS se escala cuando aumenta el tamaño del sistema de archivos en la clase de almacenamiento estándar. Para mejorar el rendimiento sin pagar un costo adicional por el rendimiento aprovisionado en un sistema de archivos de EFS, puede compartir un sistema de archivos de Amazon EFS con varias aplicaciones. Con puntos de acceso de Amazon EFS, puede implementar el aislamiento del almacenamiento en sistemas de archivos de Amazon EFS compartidos. De este modo, aunque las aplicaciones sigan compartiendo el mismo sistema de archivos, no podrán acceder a los datos a menos que usted lo autorice. A medida que sus datos crecen, Amazon EFS ayuda a mover automáticamente los archivos de acceso poco frecuente a una clase de almacenamiento inferior. La clase de almacenamiento Standard-Infrequent Access (IA) de Amazon EFS Standard reduce los costos de almacenamiento de los archivos a los que no se accede todos los días. Todo ello, sin que se afecte a la alta disponibilidad, alta durabilidad, elasticidad y acceso al sistema de archivos POSIX que proporciona Amazon EFS. Para obtener más información, consulte [Clases de almacenamiento de EFS](https://docs.aws.amazon.com/efs/latest/ug/features.html) en la *Guía del usuario de Amazon Elastic File System*. Considere la posibilidad de utilizar las políticas de ciclo de vida de Amazon EFS para ahorrar dinero de forma automática al mover los archivos de acceso poco frecuente al almacenamiento de acceso poco frecuente de Amazon EFS. Para obtener más información, consulte [Amazon EFS lifecycle management](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html) (Administración del ciclo de vida de Amazon EFS) en la *Guía del usuario de Amazon Elastic File System*. Al crear un sistema de archivos de Amazon EFS, puede elegir si Amazon EFS replica los datos en varias zonas de disponibilidad (estándar) o los almacena de forma redundante en una única zona de disponibilidad. La clase de almacenamiento Amazon EFS One Zone puede reducir los costos de almacenamiento en un margen significativo en comparación con las clases de almacenamiento Amazon EFS Standard. Considere la posibilidad de utilizar la clase de almacenamiento Amazon EFS One Zone para las cargas de trabajo que no requieren resiliencia multi-AZ. Para reducir aún más el costo del almacenamiento de Amazon EFS One Zone, mueva los archivos a los que se accede con poca frecuencia a Amazon EFS One Zone de acceso poco frecuente. Para obtener más información, consulte [Acceso poco frecuente de Amazon EFS](https://aws.amazon.com/efs/features/infrequent-access/). ## Protección de los datos de volúmenes de Amazon EFS Amazon EFS almacena los datos de manera redundante en varias zonas de disponibilidad de los sistemas de archivos mediante las clases de almacenamiento estándar. Si selecciona las clases de almacenamiento Amazon EFS One Zone, los datos se almacenan de manera redundante en una única zona de disponibilidad. Además, Amazon EFS se ha diseñado para ofrecer una durabilidad del 99,999999999 % (11 9) durante un año concreto. Como ocurre con cualquier entorno, se recomienda disponer de una copia de seguridad y crear medidas de protección contra la eliminación accidental. En el caso de los datos de Amazon EFS, esa práctica recomendada incluye una copia de seguridad que funcione y se pruebe periódicamente con AWS Backup. Los sistemas de archivos que utilizan las clases de almacenamiento Amazon EFS One Zone están configurados para hacer copias de seguridad automáticas de los archivos de manera predeterminada al crear el sistema de archivos, a menos que decida deshabilitar esta funcionalidad. Para obtener más información, consulte [Realización de copias de seguridad de sistemas de archivos EFS](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html) en la *Guía del usuario de Amazon Elastic File System*. # Especificación de un sistema de archivos de Amazon EFS en la definición de tareas de Amazon ECS Para usar volúmenes del sistema de archivos de Amazon EFS para sus contenedores, debe especificar las configuraciones de volumen y punto de montaje en su definición de tarea. El siguiente fragmento de JSON de definición de tareas muestra la sintaxis de los objetos `volumes` y `mountPoints` para un contenedor. ``` { "containerDefinitions": [ { "name": "container-using-efs", "image": "public.ecr.aws/amazonlinux/amazonlinux:latest", "entryPoint": [ "sh", "-c" ], "command": [ "ls -la /mount/efs" ], "mountPoints": [ { "sourceVolume": "myEfsVolume", "containerPath": "/mount/efs", "readOnly": true } ] } ], "volumes": [ { "name": "myEfsVolume", "efsVolumeConfiguration": { "fileSystemId": "fs-1234", "rootDirectory": "/path/to/my/data", "transitEncryption": "ENABLED", "transitEncryptionPort": integer, "authorizationConfig": { "accessPointId": "fsap-1234", "iam": "ENABLED" } } } ] } ``` `efsVolumeConfiguration` Tipo: objeto Obligatorio: no Este parámetro se especifica cuando se usan volúmenes de Amazon EFS. `fileSystemId` Tipo: cadena Obligatorio: sí El ID del sistema de archivos de Amazon EFS que se va a usar. `rootDirectory` Tipo: cadena Obligatorio: no Directorio del sistema de archivos de Amazon EFS que se va a montar como directorio raíz dentro del host. Si se omite este parámetro, se utiliza la raíz del volumen de Amazon EFS. Si se especifica `/`, se obtiene el mismo efecto que si se omite este parámetro. Si se especifica un punto de acceso de EFS en el `authorizationConfig`, se debe omitir el parámetro del directorio raíz o establecerlo en `/`, lo que aplicará la ruta establecida en el punto de acceso de EFS. `transitEncryption` Tipo: cadena Valores válidos: `ENABLED` \$1 `DISABLED` Obligatorio: no Especifica si se habilita el cifrado para los datos en tránsito de Amazon EFS entre el host de Amazon ECS y el servidor de Amazon EFS. Si se utiliza la autorización de IAM en Amazon EFS, el cifrado en tránsito debe estar habilitado. Si se omite este parámetro, se usa el valor predeterminado de `DISABLED`. Para obtener más información, consulte [Cifrado de datos en tránsito](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html) en la *Guía del usuario de Amazon Elastic File System*. `transitEncryptionPort` Tipo: entero Obligatorio: no El puerto que se utilizará al enviar datos cifrados entre el host de Amazon ECS y el servidor de Amazon EFS. Si no se especifica un puerto de cifrado en tránsito, se emplea la estrategia de selección de puertos que utiliza el ayudante de montaje de Amazon EFS. Para obtener más información, consulte [Ayudante de montaje de EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html) en la *Guía del usuario de Amazon Elastic File System*. `authorizationConfig` Tipo: objeto Obligatorio: no Los detalles de configuración de autorización en el sistema de archivos de Amazon EFS. `accessPointId` Tipo: cadena Requerido: no ID de punto de acceso que se va a utilizar. Si se especifica un punto de acceso, el valor del directorio raíz en `efsVolumeConfiguration` se debe omitir o establecer en `/`, lo que aplica la ruta establecida en el punto de acceso EFS. Si se utiliza un punto de acceso, el cifrado de tránsito debe estar habilitado en el `EFSVolumeConfiguration`. Para obtener más información, consulte [Trabajo con puntos de acceso de Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) en la *Guía del usuario de Amazon Elastic File System*. `iam` Tipo: cadena Valores válidos: `ENABLED` \$1 `DISABLED` Obligatorio: no Especifica si utilizar el rol de IAM de tarea de Amazon ECS definido en una definición de tareas al montar el sistema de archivos de Amazon EFS. Si está habilitado, el cifrado de tránsito debe estar habilitado en el `EFSVolumeConfiguration`. Si se omite este parámetro, se usa el valor predeterminado de `DISABLED`. Para obtener más información, consulte [Roles de IAM para las tareas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html). # Configuración de sistemas de archivos de Amazon EFS para Amazon ECS mediante la consola Obtenga información sobre cómo utilizar los sistemas de archivos de Amazon Elastic File System (Amazon EFS) con Amazon ECS. ## Paso 1: Crear un clúster de Amazon ECS Siga estos pasos para crear un clúster de Amazon ECS. **Para crear un nuevo clúster (consola de Amazon ECS)** Antes de empezar, asigne el permiso de IAM correspondiente. Para obtener más información, consulte [Ejemplos de clústeres de Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies). 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En la barra de navegación, seleccione la región a utilizar. 1. En el panel de navegación, seleccione **Clusters (Clústeres)**. 1. En la página **Clusters** (Clústeres), elija **Create Cluster** (Crear clúster). 1. En **Configuración de clúster**, para **Nombre del clúster**, ingrese `EFS-tutorial`. 1. (Opcional) Para cambiar la VPC y las subredes donde se inician sus tareas y servicios, en **Networking** (Redes), realice cualquiera de las siguientes operaciones: + Para eliminar una subred, en **Subnets** (Subredes), elija **X**para cada subred que desea eliminar. + Para cambiar a una VPC distinta de la VPC **predeterminada**, en **VPC**, elija una **VPC** existente y, a continuación, en **Subredes**, seleccione cada subred. 1. Para agregar instancias de Amazon EC2 al clúster, expanda **Infraestructura** y, a continuación, seleccione **Instancias de Amazon EC2**. A continuación, configure el grupo de Auto Scaling que actúa como proveedor de capacidad: 1. Para crear un grupo de Auto Scaling, desde **Auto Scaling group (ASG)** (Grupo de Auto Scaling), seleccione **Create new group** (Crear nuevo grupo) y, a continuación, proporcione los siguientes detalles sobre el grupo: + En **Sistema operativo/arquitectura**, elija Amazon Linux 2. + En **EC2 instance type (Tipo de instancia EC2)**, elija `t2.micro`. Para **Par de clave de SSH**, elija el par que demuestre su identidad cuando se conecta a la instancia. + En **Capacidad**, escriba `1`. 1. Seleccione **Crear**. ## Paso 2: Crear un grupo de seguridad para las instancias de Amazon EC2 y el sistema de archivos de Amazon EFS En este paso, se crea un grupo de seguridad para las instancias de Amazon EC2 que permiten el tráfico de red entrante en el puerto 80 y para el sistema de archivos de Amazon EFS que permite obtener acceso de entrada desde las instancias de contenedor. Cree un grupo de seguridad para las instancias de Amazon EC2 con las siguientes opciones: + **Nombre del grupo de seguridad**: un nombre único para el grupo de seguridad. + **VPC**: la VPC que identificó anteriormente para el clúster. + **Regla de entrada** + **Tipo**: **HTTP** + **Fuente** - **0.0.0.0/0**. Cree un grupo de seguridad para el sistema de archivos de Amazon EFS con las siguientes opciones: + **Nombre del grupo de seguridad**: un nombre único para el grupo de seguridad. Por ejemplo, `EFS-access-for-sg-dc025fa2`. + **VPC**: la VPC que identificó anteriormente para el clúster. + **Regla de entrada** + **Tipo**: **NFS** + **Fuente**: **personalizada** con el ID del grupo de seguridad que creó para las instancias. Para obtener información sobre cómo crear un grupo de seguridad, consulte [Creación de un grupo de seguridad para instancias de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-security-group.html) en la *Guía del usuario de Amazon EC2*. ## Paso 3: Crear un sistema de archivos de Amazon EFS En este paso, se crea un sistema de archivos de Amazon EFS. **Para crear un sistema de archivos de Amazon EFS para tareas de Amazon ECS.** 1. Abra la consola de Amazon Elastic File System en [https://console.aws.amazon.com/efs/](https://console.aws.amazon.com/efs/). 1. Seleccione **Create file system (Crear sistema de archivos)**. 1. Introduzca un nombre para el sistema de archivos y, a continuación, elija la VPC en la que están alojadas las instancias de contenedor. De forma predeterminada, cada subred de la VPC especificada recibe un destino de montaje que utiliza el grupo de seguridad predeterminado para dicha VPC. A continuación, seleccione **Personalizar**. **nota** Este tutorial asume que su sistema de archivos de Amazon EFS, el clúster de Amazon ECS, las instancias de contenedor y las tareas deben estar en la misma VPC. Para más información sobre cómo montar un sistema de archivos desde una VPC diferente, consulte [Walkthrough: Mount a file system from a different VPC](https://docs.aws.amazon.com/efs/latest/ug/efs-different-vpc.html) en la *Guía del usuario de Amazon EFS*. 1. En la página de **Configuración del sistema de archivos**, configure los ajustes opcionales y, a continuación, en **Configuración de rendimiento**, elija el modo de rendimiento **Por ráfagas** para el sistema de archivos. Una vez que haya configurado los ajustes, seleccione **Siguiente**. 1. Añada etiquetas para su sistema de archivos. Este paso es opcional. Por ejemplo, es posible especificar un nombre único para el sistema de archivos al escribirlo en la columna **Value** situada junto a la clave **Name**. 1. (Opcional) Habilite la administración del ciclo de vida para ahorrar dinero en el almacenamiento al que se accede con poca frecuencia. Para obtener más información, consulte [Administración del ciclo de vida de EFS](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html) en la *Guía del usuario de Amazon Elastic File System*. 1. (Opcional) Habilite el cifrado. Seleccione la casilla de verificación para habilitar el cifrado del sistema de archivos de Amazon EFS en reposo. 1. En la página **Acceso a la red**, en **Destinos de montaje**, reemplace la configuración del grupo de seguridad existente para cada zona de disponibilidad con el grupo de seguridad que creó para el sistema de archivos en [Paso 2: Crear un grupo de seguridad para las instancias de Amazon EC2 y el sistema de archivos de Amazon EFS](#efs-security-group) y, a continuación, seleccione **Siguiente**. 1. No necesita configurar la **Política del sistema de archivos** para este tutorial, por lo que puede omitir la sección seleccionando **Siguiente**. 1. Revise las opciones del sistema de archivos y elija **Crear** para completar el proceso. 1. Desde la pantalla **Sistemas de archivos**, registre el **ID del sistema de archivos**. En el siguiente paso, hará referencia a este valor en la definición de tareas de Amazon ECS. ## Paso 4: Agregar contenido al sistema de archivos de Amazon EFS En este paso, se va a montar el sistema de archivos de Amazon EFS en una instancia de Amazon EC2 y a agregar contenido en ella. Esto se hace para realizar pruebas en este tutorial e ilustrar la naturaleza persistente de los datos. Por lo general, cuando se utiliza estas características, se cuenta con una aplicación u otro método de escritura de datos en el sistema de archivos de Amazon EFS. **Para crear una instancia de Amazon EC2 y montar el sistema de archivos de Amazon EFS** 1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Elija **Iniciar instancia**. 1. En **Imágenes de aplicaciones y sistema operativo (Imagen de máquina de Amazon)**, seleccione la **AMI de Linux 2 de Amazon (HVM)**. 1. En **Tipo de instancia**, mantenga el tipo de instancia predeterminado, `t2.micro`. 1. En **Par de claves (inicio de sesión)**, seleccione un par de claves para el acceso SSH a la instancia. 1. En **Configuración de red**, seleccione la VPC que especificó en el sistema de archivos de Amazon EFS y el clúster de Amazon ECS. Seleccione una subred y el grupo de seguridad de la instancia que se creó en [Paso 2: Crear un grupo de seguridad para las instancias de Amazon EC2 y el sistema de archivos de Amazon EFS](#efs-security-group). Configure el grupo de seguridad de la instancia. Asegúrese de que **Asignar automáticamente IP pública** esté habilitado. 1. En **Configurar almacenamiento**, pulse el botón **Editar** para los sistemas de archivos y, a continuación, elija **EFS**. Seleccione el sistema de archivos que creó en [Paso 3: Crear un sistema de archivos de Amazon EFS](#efs-create-filesystem). Si lo desea, puede cambiar el punto de montaje o dejar el valor predeterminado. **importante** Debe seleccionar una subred antes de poder agregar un sistema de archivos a la instancia. 1. Desactive **Crear y adjuntar grupos de seguridad automáticamente**. Deje seleccionada la otra casilla de verificación. Elija **Agregar sistema de archivos compartidos**. 1. En **Advanced Details** (Detalles avanzados), asegúrese de que el script de datos del usuario se rellene automáticamente con los pasos de montaje del sistema de archivos de Amazon EFS. 1. En **Resumen**, asegúrese de que el **Número de instancias** sea **1**. Seleccione **Iniciar instancia**. 1. En la página **Lanzar una instancia**, seleccione **Ver todas las instancias** para ver el estado de las instancias. Al principio, el estado del **Estado de instancia** es `PENDING`. Una vez que el estado cambie a `RUNNING` y la instancia supere todas las comprobaciones de estado, la instancia estará lista para su uso. Ahora, se conecta a la instancia de Amazon EC2 y agrega contenido al sistema de archivos de Amazon EFS. **Para conectarse a la instancia de Amazon EC2 y agregar contenido al sistema de archivos de Amazon EFS** 1. SSH a la instancia de Amazon EC2 que creó. Para obtener más información, consulte [Conexión a la instancia de Linux mediante SSH](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html) en la *Guía del usuario de Amazon EC2*. 1. Desde la ventana del terminal, ejecute el comando **df -T** para comprobar que el sistema de archivos de Amazon EFS esté montado. En el siguiente resultado, hemos resaltado el montaje del sistema de archivos de Amazon EFS. ``` $ df -T Filesystem Type 1K-blocks Used Available Use% Mounted on devtmpfs devtmpfs 485468 0 485468 0% /dev tmpfs tmpfs 503480 0 503480 0% /dev/shm tmpfs tmpfs 503480 424 503056 1% /run tmpfs tmpfs 503480 0 503480 0% /sys/fs/cgroup /dev/xvda1 xfs 8376300 1310952 7065348 16% / 127.0.0.1:/ nfs4 9007199254739968 0 9007199254739968 0% /mnt/efs/fs1 tmpfs tmpfs 100700 0 100700 0% /run/user/1000 ``` 1. Vaya al directorio en el que está montado el sistema de archivos de Amazon EFS. En el ejemplo anterior, es `/mnt/efs/fs1`. 1. Cree un archivo denominado `index.html` con el siguiente contenido: ```

It Works!

You are using an Amazon EFS file system for persistent container storage.

``` ## Paso 5: Crear una definición de tarea La siguiente definición de tarea crea un volumen de datos llamado `efs-html`. El contenedor `nginx` monta el volumen de datos host en raíz de NGINX, `/usr/share/nginx/html`. **Para crear una nueva definición de tareas utilizando la consola de Amazon ECS** 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En el panel de navegación, elija **Task Definitions** (Definiciones de tareas). 1. Elija **Create new task definition** (Crear nueva definición de tarea) y **Create new task definition with JSON** (Crear nueva definición de tarea con JSON). 1. En el cuadro editor de JSON, copie y pegue el siguiente texto JSON, sustituyendo `fileSystemId` por el ID del sistema de archivos de Amazon EFS. ``` { "containerDefinitions": [ { "memory": 128, "portMappings": [ { "hostPort": 80, "containerPort": 80, "protocol": "tcp" } ], "essential": true, "mountPoints": [ { "containerPath": "/usr/share/nginx/html", "sourceVolume": "efs-html" } ], "name": "nginx", "image": "public.ecr.aws/docker/library/nginx:latest" } ], "volumes": [ { "name": "efs-html", "efsVolumeConfiguration": { "fileSystemId": "fs-1324abcd", "transitEncryption": "ENABLED" } } ], "family": "efs-tutorial", "executionRoleArn":"arn:aws:iam::111122223333:role/ecsTaskExecutionRole" } ``` **nota** Para el rol de IAM de ejecución de tareas de Amazon ECS no es necesario ningún permiso específico relacionado con Amazon EFS para montar un sistema de archivos de Amazon EFS. De manera predeterminada, si no existe la política basada en recursos de Amazon EFS, al crear el sistema de archivos, el acceso se concede a todas las entidades principales (\$1). El rol de tarea de Amazon ECS solo es necesario si la “autorización de IAM de EFS” está habilitada en la definición de tareas de Amazon ECS. Cuando está habilitada, la identidad del rol de la tarea debe poder acceder al sistema de archivos de Amazon EFS en la política basada en recursos de Amazon EFS, y el acceso anónimo debe estar inhabilitado. 1. Seleccione **Crear**. ## Paso 6: Ejecutar una tarea y ver los resultados Ahora que se creó el sistema de archivos de Amazon EFS y hay contenido web para que el contenedor de NGINX lo sirva, puede ejecutar una tarea mediante la definición de tareas que creó. Los servidores web de NGINX dan servicio a su sencilla página HTML. Si actualiza el contenido en el sistema de archivos de Amazon EFS, esos cambios se propagan a cualquier contenedor que también haya montado ese sistema de archivos. La tarea se ejecuta en la subred que definió para el clúster. **Para ejecutar una tarea y ver los resultados mediante la consola** 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), seleccione el clúster que va a ejecutar la tarea independiente. Determine el recurso desde el que lanza el servicio. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/tutorial-efs-volumes.html) 1. (Opcional) Elija cómo se distribuye la tarea programada en su infraestructura de clúster. Expanda **Compute configuration** (Configuración de computación) y, a continuación, haga lo siguiente: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/tutorial-efs-volumes.html) 1. En **Application type** (Tipo de aplicación), elija **Task** (Tarea). 1. En **Definición de tarea**, elija la definición de tarea `efs-tutorial` que creó anteriormente. 1. En **Tareas deseadas**, ingrese `1`. 1. Seleccione **Crear**. 1. En la página **Clúster**, elija **Infraestructura**. 1. En **Instancias de contenedor**, elija la instancia de contenedor a la que se va a conectar. 1. En la página **Instancia de contenedor**, en **Redes** registre la **IP pública** para la instancia. 1. Abra un navegador e ingrese la dirección IP pública. Debería ver el siguiente mensaje: ``` It works! You are using an Amazon EFS file system for persistent container storage. ``` **nota** Si no ve el mensaje, asegúrese de que el grupo de seguridad de la instancia de contenedor permita el tráfico de red entrante en el puerto 80 y que el grupo de seguridad del sistema de archivos permita el acceso entrante desde la instancia de contenedor. # Uso de volúmenes de FSx para Windows File Server con Amazon ECS FSx para Windows File Server proporciona servidores de archivos de Windows completamente administrados y respaldados por un sistema de archivos de Windows. Cuando se utiliza FSx for Windows File Server junto con ECS, las tareas de Windows se pueden aprovisionar con almacenamiento de archivos estático, compartido, distribuido y persistente. Para obtener más información, consulte [¿Qué es FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html). **nota** Las instancias EC2 que utilizan la AMI completa de Windows Server 2016 optimizada para Amazon ECS no admiten volúmenes de tareas de ECS de FSx for Windows File Server. No se pueden utilizar los volúmenes de FSx para Windows File Server en contenedores de Windows en la configuración de Fargate. En su lugar, puede [modificar los contenedores para montarlos al inicio](https://aws.amazon.com/blogs/containers/use-smb-storage-with-windows-containers-on-aws-fargate/). Puede utilizar FSx for Windows File Server para implementar cargas de trabajo de Windows que requieren acceso a almacenamiento externo compartido, almacenamiento regional de alta disponibilidad o almacenamiento de alto rendimiento. Puede montar uno o varios volúmenes del sistema de archivos de FSx para Windows File Server en un contenedor de Amazon ECS que se ejecute en una instancia de Windows de Amazon ECS. Puede compartir volúmenes del sistema de archivos de FSx para Windows File Server entre varios contenedores de Amazon ECS en una sola tarea de Amazon ECS. Para habilitar el uso de FSx for Windows File Server con ECS, incluya el ID del sistema de archivos FSx for Windows File Server y la información relacionada en una definición de tareas. Esto se muestra en el siguiente fragmento JSON de definición de tareas de ejemplo. Antes de crear y ejecutar una definición de tareas, necesita lo siguiente. + Una instancia de EC2 de Windows ECS unida a un dominio válido. Puede alojarla [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html), Active Directory en las instalaciones o Active Directory con alojamiento propio en Amazon EC2. + Un parámetro de Systems Manager o secreto de AWS Secrets Manager que contenga las credenciales que se utilizan para unir el dominio de Active Directory y asociar el sistema de archivos de FSx para Windows File Server. Las credenciales son el nombre y la contraseña que especificó al crear el Active Directory. Para ver un tutorial relacionado, consulte [Obtenga información sobre cómo configurar FSx para sistemas de archivos de Windows File Server para Amazon ECS.](tutorial-wfsx-volumes.md). ## Consideraciones Tenga en cuenta lo siguiente al utilizar volúmenes de FSx for Windows File Server: + Los volúmenes de FSx para Windows File Server son compatibles de forma nativa con Amazon ECS en las instancias de Amazon EC2 de Windows: Amazon ECS administra de manera automática el montaje mediante la configuración de definición de tareas. En las instancias de Amazon EC2 de Linux, Amazon ECS no puede montar de manera automática los volúmenes de FSx para Windows File Server mediante definiciones de tareas. Sin embargo, puede montar de forma manual un recurso compartido de archivos de FSx para Windows File Server en una instancia de EC2 de Linux a nivel de host y, a continuación, realizar un montaje vinculado de esa ruta en sus contenedores de Amazon ECS. Para obtener más información, consulte [Montaje de archivos compartidos de Amazon FSx desde Linux](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/map-shares-linux.html). **importante** Esta es una configuración autoadministrada. Para obtener instrucciones sobre el montaje y el mantenimiento de recursos compartidos de archivos de FSx para Windows File Server en Linux, consulte [la documentación de FSx para Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/). **importante** Cuando se utiliza un recurso compartido de FSx para Windows File Server montado de forma manual en instancias de EC2 de Linux, Amazon ECS y FSx para Windows File Server funcionan de forma independiente: Amazon ECS no supervisa el montaje de Amazon FSx y FSx para Windows File Server no rastrea la ubicación de las tareas de Amazon ECS ni los eventos del ciclo de vida. Usted es responsable de garantizar la accesibilidad de la red entre sus instancias de contenedor de Amazon ECS y el sistema de archivos Amazon FSx, implementar comprobaciones de estado de montaje y gestionar la lógica de reconexión para tolerar los eventos de conmutación por error. + FSx for Windows File Server con Amazon ECS no admite AWS Fargate. + FSx para Windows File Server con Amazon ECS no se admite en instancias administradas de Amazon ECS. + FSx for Windows File Server con Amazon ECS y modo de red `awsvpc` requiere la versión `1.54.0` o posterior del agente de contenedor. + Para una tarea de Amazon ECS, se pueden utilizar 23 letras de unidad, como máximo. A cada tarea con un volumen de FSx for Windows File Server se le asigna una letra de unidad. + De forma predeterminada, el tiempo de limpieza de los recursos de tareas es de tres horas una vez finalizada la tarea. Incluso si no hay tareas que lo utilicen, una asignación de archivos creado por una tarea persiste durante tres horas. Para configurar el tiempo de limpieza predeterminado, se puede usar la variable de entorno de Amazon ECS `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`. Para obtener más información, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md). + Por lo general, las tareas solo se ejecutan en la misma VPC que el sistema de archivos FSx for Windows File Server. Sin embargo, es posible que exista compatibilidad entre VPC si hay una conectividad de red establecida entre la VPC del clúster de Amazon ECS y el sistema de archivos FSx for Windows File Server mediante interconexión de VPC. + Para controlar el acceso a un sistema de archivos FSx for Windows File Server en el nivel de red, se configuran los grupos de seguridad de VPC. Solo las tareas alojadas en instancias de EC2 unidas al dominio de Active Directory con grupos de seguridad de Active Directory correctamente configurados podrán acceder al uso compartido de archivos de FSx para Windows File Server. Si los grupos de seguridad están mal configurados, Amazon ECS no lanza la tarea y se muestra el mensaje de error siguiente: “”.: `unable to mount file system fs-id`.” + FSx for Windows File Server está integrado con AWS Identity and Access Management (IAM) para controlar las acciones que los usuarios y grupos de IAM pueden realizar en los recursos específicos de FSx for Windows File Server. Con autorización de cliente, los clientes pueden definir roles de IAM que permiten o deniegan el acceso a sistemas de archivos FSx for Windows File Server específicos, que opcionalmente requieren acceso de solo lectura y que opcionalmente permiten o no permiten el acceso raíz al sistema de archivos desde el cliente. Para obtener más información, consulte [Seguridad](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/security.html) en la Guía del usuario de Windows para Amazon FSx. # Prácticas recomendadas para el uso de FSx para Windows File Server con Amazon ECS Tome nota de las siguientes de prácticas recomendadas cuando utilice FSx para Windows File Server con Amazon ECS. ## Controles de seguridad y acceso de FSx para Windows File Server FSx para Windows File Server ofrece las siguientes características de control de acceso que puede utilizar para garantizar que los datos almacenados en un sistema de archivos de FSx para Windows File Server estén seguros y solo se pueda acceder a ellos desde las aplicaciones que los necesiten. ### Cifrado de datos para volúmenes de FSx para Windows File Server FSx para Windows File Server admite dos formas de cifrado para sistemas de archivos. Estas son el cifrado de datos en tránsito y cifrado en reposo. El cifrado de los datos en tránsito se admite en los recursos compartidos de archivos que están asignados en una instancia de contenedor compatible con el protocolo SMB 3.0 o posterior. El cifrado de los datos en reposo se activa de forma automática al crear un sistema de archivos Amazon FSx. Amazon FSx cifra de manera automática los datos en tránsito con el cifrado SMB, cuando el usuario accede al sistema de archivos, sin necesidad de modificar las aplicaciones. Para más información, consulte [Data encryption in Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/encryption.html) en la *Guía del usuario de Amazon FSx para Windows File Server*. ### Uso de las ACL de Windows para el control de acceso a carpetas La instancia de Amazon EC2 de Windows accede a los recursos compartidos de archivos de Amazon FSx con las credenciales de Active Directory. Utiliza las listas de control de acceso (ACL) estándar de Windows para tener un control de acceso detallado a archivos y carpetas. Puede crear varias credenciales, cada una para una carpeta específica del recurso compartido que se asigne a una tarea específica. En el ejemplo siguiente, la tarea tiene acceso a la carpeta `App01` mediante una credencial guardada en Secrets Manager. Su nombre de recurso de Amazon (ARN) es `1234`. ``` "rootDirectory": "\\path\\to\\my\\data\App01", "credentialsParameter": "arn-1234", "domain": "corp.fullyqualified.com", ``` En otro ejemplo, una tarea tiene acceso a la carpeta `App02` mediante una credencial guardada en Secrets Manager. Su ARN es `6789`. ``` "rootDirectory": "\\path\\to\\my\\data\App02", "credentialsParameter": "arn-6789", "domain": "corp.fullyqualified.com", ``` # Especificación de un sistema de archivos de FSx para Windows File Server en la definición de tareas de Amazon ECS Para usar volúmenes del sistema de archivos de FSx for Windows File Server para sus contenedores, especifique las configuraciones de volumen y punto de montaje en la definición de tarea. El siguiente fragmento de JSON de definición de tareas muestra la sintaxis de los objetos `volumes` y `mountPoints` para un contenedor. ``` { "containerDefinitions": [ { "entryPoint": [ "powershell", "-Command" ], "portMappings": [], "command": ["New-Item -Path C:\\fsx-windows-dir\\index.html -ItemType file -Value ' Amazon ECS Sample App

Amazon ECS Sample App

It Works!

You are using Amazon FSx for Windows File Server file system for persistent container storage.

' -Force"], "cpu": 512, "memory": 256, "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019", "essential": false, "name": "container1", "mountPoints": [ { "sourceVolume": "fsx-windows-dir", "containerPath": "C:\\fsx-windows-dir", "readOnly": false } ] }, { "entryPoint": [ "powershell", "-Command" ], "portMappings": [ { "hostPort": 443, "protocol": "tcp", "containerPort": 80 } ], "command": ["Remove-Item -Recurse C:\\inetpub\\wwwroot\\* -Force; Start-Sleep -Seconds 120; Move-Item -Path C:\\fsx-windows-dir\\index.html -Destination C:\\inetpub\\wwwroot\\index.html -Force; C:\\ServiceMonitor.exe w3svc"], "mountPoints": [ { "sourceVolume": "fsx-windows-dir", "containerPath": "C:\\fsx-windows-dir", "readOnly": false } ], "cpu": 512, "memory": 256, "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019", "essential": true, "name": "container2" } ], "family": "fsx-windows", "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole", "volumes": [ { "name": "fsx-windows-dir", "fsxWindowsFileServerVolumeConfiguration": { "fileSystemId": "fs-0eeb5730b2EXAMPLE", "authorizationConfig": { "domain": "example.com", "credentialsParameter": "arn:arn-1234" }, "rootDirectory": "share" } } ] } ``` `FSxWindowsFileServerVolumeConfiguration` Tipo: objeto Obligatorio: no Este parámetro se especifica cuando se utiliza el sistema de archivos [FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) para el almacenamiento de tareas. `fileSystemId` Tipo: cadena Obligatorio: sí ID del sistema de archivos FSx for Windows File Server que se va a utilizar. `rootDirectory` Tipo: cadena Obligatorio: sí Directorio dentro del sistema de archivos de FSx for Windows File Server que se va a montar como directorio raíz dentro del host. `authorizationConfig` `credentialsParameter` Tipo: cadena Obligatorio: sí Opciones de credenciales de autorización: + Nombre de recurso de Amazon (ARN) de un secreto de [Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html). + Nombre de recurso de Amazon (ARN) de un parámetro de [Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html). `domain` Tipo: cadena Obligatorio: sí Nombre de dominio completo alojado por un directorio de [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html)(AWS Managed Microsoft AD) o un directorio de Active Directory de EC2 con alojamiento propio. ## Métodos para almacenar credenciales de volúmenes de FSx para Windows File Server Existen dos métodos diferentes de almacenamiento de credenciales que se utilizan con el parámetro de credenciales. + **AWS Secrets Manager secret** Esta credencial se puede crear en la consola de AWS Secrets Manager en la categoría *Other type of secret* (Otro tipo de secreto). Agregue una fila para cada par clave/valor, nombre de usuario/administrador y contraseña/*contraseña*. + **Parámetro de Systems Manager** Para crear esta credencial en la consola de parámetros de Systems Manager, ingrese texto en el formulario que se muestra en el siguiente fragmento de código de ejemplo. ``` { "username": "admin", "password": "password" } ``` El `credentialsParameter` del parámetro `FSxWindowsFileServerVolumeConfiguration` de la definición de tarea contiene el ARN secreto o el ARN del parámetro de Systems Manager. Para obtener más información, consulte[¿Qué es AWS Secrets Manager?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) en la *Guía del usuario de Secrets Manager* y [Parameter Store de Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) en la *Guía del usuario de Systems Manager*. # Obtenga información sobre cómo configurar FSx para sistemas de archivos de Windows File Server para Amazon ECS. Obtenga información sobre cómo lanzar una instancia de Windows optimizada para Amazon ECS que aloje un sistema de archivos de FSx para Windows File Server y contenedores que puedan acceder al sistema de archivos. Para hacerlo, primero debe crear un Microsoft Active Directory Directory Service administrado por AWS. A continuación, cree un sistema de archivos de FSx para Windows File Server y un clúster con una instancia de Amazon EC2 y una definición de tareas. Configure la definición de tareas de los contenedores para que utilicen el sistema de archivos FSx for Windows File Server. Por último, pruebe el sistema de archivos. Cada vez que se lanza o se elimina el sistema de archivos Active Directory o FSx for Windows File Server, el proceso tarda entre 20 y 45 minutos. Prepárese para dedicar al menos 90 minutos a completar el tutorial o complételo en varias sesiones. ## Requisitos previos para el tutorial + Un usuario administrativo. Consulte [Configuración para utilizar Amazon ECS](get-set-up-for-amazon-ecs.md). + (Opcional) Un par de claves `PEM` para conectarse a la instancia EC2 de Windows a través del acceso RDP. Para obtener información acerca de cómo crear pares de claves, consulte [Pares de claves de Amazon EC2 e instancias de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) en la *Guía del usuario de Amazon EC2*. + Una VPC con al menos una subred pública y una subred privada, y un grupo de seguridad. Puede utilizar la VPC predeterminada. No necesita una gateway ni un dispositivo NAT. Directory Service no admite la traducción de direcciones de red (NAT) en Active Directory. Para que esto funcione, Active Directory, el sistema de archivos FSx para Windows File Server, el clúster de ECS y la instancia de EC2 deben ubicarse dentro de la VPC. Para obtener más información sobre las VPC y Active Directories, consulte [Crear una VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) y [Requisitos previos para crear un AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html#ms_ad_getting_started_prereqs). + Los permisos ecsInstanceRole y ecsTaskExecutionRole de IAM están asociados a la cuenta. Estos roles vinculados a servicios permiten que los servicios realicen llamadas a la API y accedan a los contenedores, los secretos, los directorios y los servidores de archivos en su nombre. ## Paso 1: Crear roles de IAM de acceso **Cree un clúster desde la Consola de administración de AWS.** 1. Consulte [Rol de IAM de instancia de contenedor de Amazon ECS](instance_IAM_role.md) para comprobar si dispone de un ecsInstanceRole y, si no dispone de ninguno, ver cómo puede crear uno. 1. Recomendamos personalizar las políticas de roles con permisos mínimos en un entorno de producción real. Para poder trabajar con este tutorial, compruebe que la siguiente política administrada por AWS esté asociada a ecsInstanceRole. Si la política aún no está asociada, asóciela ahora. + AmazonEC2ContainerServiceforEC2Role + AmazonSSMManagedInstanceCore + AmazonSSMDirectoryServiceAccess Para asociar una política administrada por AWS 1. Abra la [consola de IAM](https://console.aws.amazon.com//iam/). 1. Seleccione **Roles** en el panel de navegación. 1. Elija un **Rol administrado de AWS**. 1. Elija **Permisos y Asociar políticas**. 1. Para reducir la lista de políticas disponibles a asociar, utilice la función **Filter** (Filtro). 1. Seleccione la política pertinente y, a continuación, elija **Attach Policy** (Asociar política). 1. Consulte [Rol de IAM de ejecución de tareas de Amazon ECS](task_execution_IAM_role.md) para comprobar si dispone de un ecsTaskExecutionRole y, si no dispone de ninguno, ver cómo puede crear uno. Recomendamos personalizar las políticas de roles con permisos mínimos en un entorno de producción real. Para poder trabajar con este tutorial, compruebe que las siguientes políticas administradas por AWS estén asociadas a ecsTaskExecutionRole. Si las políticas no están asociadas, asócielas ahora. Para asociar las políticas administradas por AWS, utilice el procedimiento indicado en la sección anterior. + SecretsManagerReadWrite + AmazonFSxReadOnlyAccess + AmazonSSMReadOnlyAccess + AmazonECSTaskExecutionRolePolicy ## Paso 2: Crear Windows Active Directory (AD) 1. Siga los pasos que se indican en [Creación del directorio de Microsoft AD administrado por AWS](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html#ms_ad_getting_started_create_directory) en la *Guía de administración de AWS Directory Service*. Utilice la VPC que haya designado para este tutorial. En el paso 3 de *Creación de AWS Managed Microsoft AD*, guarde el nombre de usuario y la contraseña del administrador para utilizarlos en el siguiente paso. Además, tenga en cuenta el nombre de DNS del directorio calificado completo para futuros pasos. Puede completar el siguiente paso mientras se crea Active Directory. 1. Cree un secreto de AWS Secrets Manager para utilizarlo en los siguientes pasos. Para obtener más información, consulte [Introducción a Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html#get-started) en la *Guía del usuario de AWS Secrets Manager*. 1. Abra la [consola de Secrets Manager](https://console.aws.amazon.com//secretsmanager/). 1. Haga clic en **Store a new secret** (Almacenar un nuevo secreto). 1. Seleccione **Other type of secrets** (Otro tipo de secretos). 1. En **Secret key/value** (Clave/valor secreto), cree una clave **username**con el valor **admin** en la primera fila. Haga clic en.**\$1 Add a row** (\$1 Agregar una fila). 1. En la nueva fila, cree una clave **password**. Para el valor, escriba la contraseña que ingresó en el paso 3 de *Creación del Directorio de AD administrado por AWS*. 1. Haga clic en el botón **Next** (Siguiente). 1. Proporcione un nombre y una descripción para el secreto. Haga clic en **Next (Siguiente)**. 1. Haga clic en **Next (Siguiente)**. Haga clic en **Store** (Almacenar). 1. En la lista que aparece en la página **Secrets** (Secretos), haga clic en el secreto que acaba de crear. 1. Guarde el ARN del nuevo secreto para utilizarlo en los pasos siguientes. 1. Puede continuar con el paso siguiente mientras se crea Active Directory. ## Paso 3: Comprobar y actualizar el grupo de seguridad En este paso, compruebe y actualice las reglas del grupo de seguridad que está utilizando. Para eso, puede utilizar el grupo de seguridad predeterminado que se creó para la VPC. **Verifique y actualice el grupo de seguridad.** Debe crear o editar el grupo de seguridad para que envíe datos a través de los puertos, que se describen en [Grupos de seguridad de Amazon VPC](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/limit-access-security-groups.html#fsx-vpc-security-groups) en la *Guía del usuario de FSx for Windows File Server*. Para hacerlo, puede crear la regla de entrada del grupo de seguridad que se muestra en la primera fila de la siguiente tabla de reglas de entrada. Esta regla permite el tráfico entrante procedente de las interfaces de red (y las instancias asociadas) asignadas al mismo grupo de seguridad. Todos los recursos en la nube que cree están dentro de la misma VPC y asociados al mismo grupo de seguridad. Por lo tanto, esta regla permite que el tráfico se envíe a través del sistema de archivos FSx for Windows File Server, Active Directory y la instancia de ECS, según corresponda. Las otras reglas de entrada permiten que el tráfico atienda al sitio web y al acceso RDP para conectarse a la instancia de ECS. En la tabla siguiente, se muestran las reglas de entrada del grupo de seguridad requeridas para este tutorial. | Tipo | Protocolo | Intervalo de puertos | Origen | | --- | --- | --- | --- | | Todo el tráfico | Todos | Todos | *sg-securitygroup* | | HTTPS | TCP | 443 | 0.0.0.0/0 | | RDP | TCP | 3389 | Dirección IP de la computadora portátil | En la tabla siguiente, se muestran las reglas de salida del grupo de seguridad requeridas para este tutorial. | Tipo | Protocolo | Rango de puerto | Destino | | --- | --- | --- | --- | | Todo el tráfico | Todos | Todos | 0.0.0.0/0 | 1. Abra la [consola de EC2](https://console.aws.amazon.com//ec2/) y seleccione **Security Groups** (Grupos de seguridad) en el menú de la izquierda. 1. En la lista de grupos de seguridad que se muestra ahora, seleccione la casilla de verificación situada a la izquierda del grupo de seguridad que está utilizando para este tutorial. Se muestran los detalles del grupo de seguridad. 1. Para editar las reglas de entrada y salida, seleccione las pestañas **Reglas de entrada** o **Reglas de salida** y elija los botones **Editar reglas de entrada** o **Editar reglas de salida**. Edite las reglas para que coincidan con las que se muestran en las tablas anteriores. Después de crear la instancia de EC2 más adelante en este tutorial, edite el origen RDP de la regla de entrada con la dirección IP pública de la instancia de EC2 como se describe en [Conectarse a una instancia de Windows mediante RDP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html) en la *Guía del usuario de Amazon EC2*. ## Paso 4: Crear un sistema de archivos FSx for Windows File Server Después de comprobar y actualizar el grupo de seguridad y de crear Active Directory y dejarlo en estado activo, cree el sistema de archivos FSx for Windows File Server en la misma VPC en la que se encuentra Active Directory. Siga estos pasos para crear un sistema de archivos FSx for Windows File Server para las tareas de Windows. **Cree el primer sistema de archivos.** 1. Abra la [consola de Amazon FSx](https://console.aws.amazon.com//fsx/). 1. En el panel, elija **Create file system** (Crear sistema de archivos) para iniciar el asistente de creación de sistemas de archivos. 1. En la página **Seleccionar tipo de sistema de archivos**, elija **FSx para Windows File Server** y, a continuación, elija **Siguiente**. Aparece la página **Crear sistema de archivos**. 1. En la sección **File system details** (Detalles del sistema de archivos), proporcione un nombre para el sistema de archivos. Dar nombre a los sistemas de archivos hace que sea más fácil encontrarlos y administrarlos. Puede usar hasta 256 caracteres Unicode. Los caracteres permitidos son letras, números, espacios y los caracteres especiales signo más (\$1), signo menos (-), signo igual (=), punto (.), guion bajo (\$1), dos puntos (:) y barra inclinada (/). 1. En **Deployment type** (Tipo de implementación), elija **Single-AZ** (Zona de disponibilidad única) para implementar un sistema de archivos que se implemente en una sola zona de disponibilidad. *Single-AZ 2* es la última generación de sistemas de archivos de zona de disponibilidad única y admite almacenamiento SSD y HDD. 1. En **Storage type** (Tipo de almacenamiento), elija **HDD**. 1. En **Storage capacity** (Capacidad de almacenamiento), ingrese la capacidad de almacenamiento mínima. 1. En el campo **Throughput capacity** (Capacidad de rendimiento), mantenga la configuración predeterminada. 1. En la sección **Network & security** (Red y seguridad), elija la misma Amazon VPC que eligió para el directorio Directory Service. 1. En **VPC Security Groups** (Grupos de seguridad de la VPC), elija el grupo de seguridad que verificó en el *Paso 3: Comprobar y actualizar el grupo de seguridad*. 1. En **Autenticación de Windows**, elija **AWS Managed Microsoft Active Directory** y, a continuación, elija el directorio Directory Service de la lista. 1. En **Encryption** (Cifrado), conserve el valor predeterminado **aws/fsx (default)** en el campo **Encryption key** (Clave de cifrado). 1. En **Maintenance preferences** (Preferencias de mantenimiento), conserve la configuración predeterminada. 1. Haga clic en el botón **Next** (Siguiente). 1. Revise la configuración del sistema de archivos que se muestra en la página **Create File System** (Crear sistema de archivos). Para su referencia, anote qué configuración del sistema de archivos puede modificar después de crear el sistema de archivos. Seleccione **Crear sistema de archivos**. 1. Anote el ID del sistema de archivos. Lo utilizará en un paso posterior. Vaya a los pasos siguientes para crear un clúster y una instancia EC2 mientras se crea el sistema de archivos FSx for Windows File Server. ## Paso 5: Crear un clúster de Amazon ECS **Crear un clúster mediante la consola clásica de Amazon ECS** 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En la barra de navegación, seleccione la región a utilizar. 1. En el panel de navegación, seleccione **Clusters (Clústeres)**. 1. En la página **Clusters** (Clústeres), elija **Create Cluster** (Crear clúster). 1. En **Configuración de clúster**, en **Nombre del clúster**, ingrese **windows-fsx-cluster**. 1. Expanda **Infraestructura**, desactive AWS Fargate (sin servidor) y, a continuación, seleccione **Instancias de Amazon EC2**. 1. Para crear un grupo de Auto Scaling, desde **Auto Scaling group (ASG)** (Grupo de Auto Scaling), seleccione **Create new group** (Crear nuevo grupo) y, a continuación, proporcione los siguientes detalles sobre el grupo: + En **Sistema operativo/arquitectura**, elija **Windows Server 2019 Core**. + Para el **Tipo de instancia de EC2**, seleccione t2.medium o t2.micro. 1. Seleccione **Crear**. ## Paso 6: Crear una instancia de Amazon EC2 optimizada para Amazon ECS Cree una instancia de contenedor de Amazon ECS para Windows. **Para crear una instancia de Amazon ECS** 1. Utilice el comando `aws ssm get-parameters` para recuperar el nombre de la AMI de la región que aloja la VPC. Para obtener más información, consulte [Recuperación de los metadatos de la AMI optimizada para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_windows_AMI.html). 1. Utilice la consola de Amazon EC2 para lanzar la instancia. 1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. En la barra de navegación, seleccione la región a utilizar. 1. En el **panel de EC2**, elija **Launch Instance** (Lanzar instancia). 1. En **Name (Nombre)**, escriba un nombre único. 1. En **Imágenes de aplicaciones y SO (Imagen de máquina de Amazon)**, en el campo **Buscar**, introduzca la AMI que recuperó. 1. En **Tipo de instancia**, seleccione t2.medium o t2.micro. 1. En **Key pair (login)** (Par de claves [inicio de sesión]), elija un par de claves. Si no especifica ningún para de clave 1. En **Configuración de red**, para **VPC** y **Subred**, elija su VPC y una subred pública. 1. En **Network settings** (Configuración de red), para **Security groups** (Grupo de seguridad), seleccione un grupo de seguridad existente o cree uno nuevo. Asegurarse de que el grupo de seguridad que elija tenga las reglas de entrada y salida definidas en [Requisitos previos para el tutorial](#wfsx-prerequisites) 1. En **Network settings** (Configuración de red), para **Auto-assign Public IP** (Asignar automáticamente una IP pública), selecciona **Enable** (Activar). 1. Expanda **Detalles avanzados** y, a continuación, en **Directorio de unión a dominios**, seleccione el ID del Active Directory que creó. Este dominio opcional se une al AD cuando se lanza la instancia EC2. 1. En **Advanced details** (Detalles avanzados), en **IAM instance profile** (Perfil de instancia de IAM), elija **ecsInstanceRole**. 1. Configure su instancia de contenedor de Amazon ECS con los siguientes datos de usuario. En **Advanced details** (Detalles avanzados), pegue el siguiente script en el campo **User data** (Datos de usuario), reemplazando *cluster\$1name* con el nombre de su clúster. ``` Initialize-ECSAgent -Cluster windows-fsx-cluster -EnableTaskIAMRole ``` 1. Cuando esté listo, seleccione el campo de confirmación y después elija **Launch Instances**. 1. Verá una página de confirmación que indicará que la instancia se está lanzando. Elija **View instances** para cerrar la página de confirmación y volver a la consola. 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En el panel de navegación, seleccione **Clústeres** y, luego, seleccione **windows-fsx-cluster**. 1. Seleccione la pestaña **Infraestructura** y compruebe que la instancia se haya registrado en el clúster **windows-fsx-cluster**. ## Paso 7: Registrar una definición de tareas de Windows Antes de poder ejecutar los contenedores de Windows en el clúster de Amazon ECS, debe registrar una definición de tarea. El siguiente ejemplo de definición de tareas muestra una página web sencilla. La tarea lanza dos contenedores que tienen acceso al sistema de archivos FSx. El primer contenedor escribe un archivo HTML en el sistema de archivos. El segundo contenedor descarga el archivo HTML del sistema de archivos y atiende la página web. 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En el panel de navegación, elija **Task Definitions** (Definiciones de tareas). 1. Elija **Create new task definition** (Crear nueva definición de tarea) y **Create new task definition with JSON** (Crear nueva definición de tarea con JSON). 1. En el cuadro del editor JSON, sustituya los valores del rol de ejecución de tareas y los detalles del sistema de archivos FSx y, a continuación, elija **Guardar**. ``` { "containerDefinitions": [ { "entryPoint": [ "powershell", "-Command" ], "portMappings": [], "command": ["New-Item -Path C:\\fsx-windows-dir\\index.html -ItemType file -Value ' Amazon ECS Sample App

Amazon ECS Sample App

It Works!

You are using Amazon FSx for Windows File Server file system for persistent container storage.

' -Force"], "cpu": 512, "memory": 256, "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019", "essential": false, "name": "container1", "mountPoints": [ { "sourceVolume": "fsx-windows-dir", "containerPath": "C:\\fsx-windows-dir", "readOnly": false } ] }, { "entryPoint": [ "powershell", "-Command" ], "portMappings": [ { "hostPort": 443, "protocol": "tcp", "containerPort": 80 } ], "command": ["Remove-Item -Recurse C:\\inetpub\\wwwroot\\* -Force; Start-Sleep -Seconds 120; Move-Item -Path C:\\fsx-windows-dir\\index.html -Destination C:\\inetpub\\wwwroot\\index.html -Force; C:\\ServiceMonitor.exe w3svc"], "mountPoints": [ { "sourceVolume": "fsx-windows-dir", "containerPath": "C:\\fsx-windows-dir", "readOnly": false } ], "cpu": 512, "memory": 256, "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019", "essential": true, "name": "container2" } ], "family": "fsx-windows", "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole", "volumes": [ { "name": "fsx-windows-dir", "fsxWindowsFileServerVolumeConfiguration": { "fileSystemId": "fs-0eeb5730b2EXAMPLE", "authorizationConfig": { "domain": "example.com", "credentialsParameter": "arn:arn-1234" }, "rootDirectory": "share" } } ] } ``` ## Paso 8: Ejecutar una tarea y ver los resultados Antes de ejecutar la tarea, compruebe que el estado del sistema de archivos FSx for Windows File Server sea **Available** (Disponible). Una vez que esté disponible, puede ejecutar una tarea mediante la definición de tareas que creó. La tarea comienza por crear contenedores que mezclan un archivo HTML entre ellos mediante el sistema de archivos. Después de la mezcla, un servidor web atiende la página HTML simple. **nota** Es posible que no pueda conectarse al sitio web desde una VPN. **Ejecute una tarea y observe los resultados con la consola de Amazon ECS.** 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En el panel de navegación, seleccione **Clústeres** y, luego, seleccione **windows-fsx-cluster**. 1. Elija la pestaña de **Tareas** y, a continuación, **Ejecutar nueva tarea**. 1. En **Launch Type**, elija **EC2**. 1. En configuración de la implementación, en **Definición de tareas**, elija **fsx-windows** y, a continuación, elija **Crear**. 1. Cuando el estado de la tarea sea **EN EJECUCIÓN**, haga clic en el ID de la tarea. 1. En **Contenedores**, cuando el estado del contenedor1 sea **DETENIDO**, seleccione el contenedor 2 para ver los detalles del contenedor. 1. En **Detalles del contenedor para container2**, seleccione **Enlaces de red** y, a continuación, haga clic en la dirección IP externa asociada al contenedor. Se abrirá el navegador y mostrará el siguiente mensaje. ``` Amazon ECS Sample App It Works! You are using Amazon FSx for Windows File Server file system for persistent container storage. ``` **nota** Puede que transcurran unos minutos hasta que se muestre el mensaje. Si no ve este mensaje después de unos minutos, compruebe que no se esté ejecutando en una VPN y asegúrese de que el grupo de seguridad de la instancia de contenedor permita el tráfico HTTP de red entrante en el puerto 443. ## Paso 9: limpiar **nota** El proceso de eliminación del sistema de archivos FSx for Windows File Server o el AD tarda entre 20 y 45 minutos. Debe esperar hasta que se hayan completado las operaciones de eliminación del sistema de archivos FSx for Windows File Server antes de iniciar las operaciones de eliminación de AD. **Elimine el sistema de archivos de FSx para Windows File Server.** 1. Abra la [consola de Amazon FSx](https://console.aws.amazon.com//fsx/). 1. Elija el botón de la radio a la izquierda del sistema de archivos FSx para Windows File Server que acaba de crear. 1. Elija **Acciones**. 1. Seleccione **Delete file system** (Eliminar sistema de archivos). **Eliminar AD.** 1. Abra la [consola de Directory Service](https://console.aws.amazon.com//directoryservicev2/). 1. Haga clic en el botón de radio situado a la izquierda del AD que acaba de crear. 1. Elija **Acciones**. 1. Seleccione **Delete directory** (Eliminar directorio). **Elimine el clúster.** 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En el panel de navegación, seleccione **Clústeres** y, luego, seleccione **windows-fsx-cluster**. 1. Seleccione **Delete cluster (Eliminar clúster)**. 1. Escriba la frase y, a continuación, elija **Eliminar**. **Termine la instancia de EC2.** 1. Abra la [consola de Amazon EC2](https://console.aws.amazon.com//ec2/). 1. En el menú de la izquierda, seleccione **Instances** (Instancias). 1. Marque la casilla de verificación situada a la izquierda de la instancia de EC2 que creó. 1. Haga clic en el botón **Estado de instancia** y en **Terminar instancia**. **Elimine el secreto.** 1. Abra la [consola de Secrets Manager](https://console.aws.amazon.com//secretsmanager/). 1. Seleccione el secreto que creó para este ejercicio. 1. Haga clic en **Actions** (Acciones). 1. Seleccione **Delete secret** (Eliminar secreto). # Uso de volúmenes de Docker con Amazon ECS Cuando se utilizan volúmenes de Docker, se puede usar el controlador `local` integrado o un controlador de volumen de terceros. Los volúmenes de Docker los administra Docker, y se crea un directorio en `/var/lib/docker/volumes` en la instancia de contenedor que contiene los datos del volumen. Para utilizar volúmenes de Docker, especifique `dockerVolumeConfiguration` en su definición de tarea. Para obtener más información, consulte [Volúmenes](https://docs.docker.com/engine/storage/volumes/) en la documentación de Docker. Algunos casos de uso comunes de volúmenes de Docker son los siguientes: + Proporción de volúmenes de datos persistentes para su uso con contenedores + Uso compartido de un volumen de datos definido en distintas ubicaciones de distintos contenedores en la misma instancia de contenedor + Definición de un volumen de datos no persistentes vacío y montaje en varios contenedores dentro de la misma tarea + Proporcionar un volumen de datos a la tarea que está administrado por un controlador de terceros ## Consideraciones sobre el uso de volúmenes de Docker Al utilizar volúmenes de Amazon Docker, tenga en cuenta lo siguiente: + Los volúmenes de Docker solo se admiten cuando se utiliza el tipo de lanzamiento de EC2 o instancias externas. + Los contenedores de Windows solo admiten el uso del controlador `local`. + Si se utiliza un controlador de terceros, asegúrese de que está instalado y activo en la instancia de contenedor antes de iniciar el agente de contenedor. Si el controlador de terceros no está activo antes de iniciar el agente, puede reiniciar el agente de contenedor con uno de los siguientes comandos: + Para la AMI de Amazon Linux 2 optimizada para Amazon ECS: ``` sudo systemctl restart ecs ``` + Para la AMI de Amazon Linux optimizada para Amazon ECS: ``` sudo stop ecs && sudo start ecs ``` Para obtener información sobre cómo especificar un volumen de Docker en una definición de tarea, consulte [Especificación de un volumen de Docker en la definición de tareas de Amazon ECS](specify-volume-config.md). # Especificación de un volumen de Docker en la definición de tareas de Amazon ECS Para que los contenedores puedan utilizar volúmenes de datos, debe especificar las configuraciones del volumen y el punto de montaje en su definición de tarea. En esta sección se describe la configuración de volumen para un contenedor. Para las tareas que usan un volumen de Docker, especifique `dockerVolumeConfiguration`. Para las tareas que usan un volumen de host de montaje vinculado, especifique `host` y, si lo desea, `sourcePath`. El siguiente JSON de definición de tareas muestra la sintaxis de los objetos `volumes` y `mountPoints` para un contenedor. ``` { "containerDefinitions": [ { "mountPoints": [ { "sourceVolume": "string", "containerPath": "/path/to/mount_volume", "readOnly": boolean } ] } ], "volumes": [ { "name": "string", "dockerVolumeConfiguration": { "scope": "string", "autoprovision": boolean, "driver": "string", "driverOpts": { "key": "value" }, "labels": { "key": "value" } } } ] } ``` `name` Tipo: cadena Requerido: no El nombre del volumen. Se admiten hasta 255 letras (mayúsculas y minúsculas), números, guiones (`-`) y caracteres de subrayado (`_`). Se hace referencia a este nombre en el parámetro `sourceVolume` del objeto `mountPoints` de la definición de contenedor. `dockerVolumeConfiguration` Type: objeto de [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html) Obligatorio: no Este parámetro se especifica cuando se usan volúmenes de Docker. Los volúmenes de Docker se admiten solo cuando se ejecutan tareas en instancias de EC2. Los contenedores de Windows admiten solo el uso del controlador `local`. Para utilizar montajes vinculados, especifique `host` en su lugar. `scope` Tipo: cadena Valores válidos: `task` \$1 `shared` Obligatorio: no El ámbito del volumen de Docker, que determina su ciclo de vida. Los volúmenes de Docker con un ámbito de `task` se aprovisionan automáticamente cuando se inicia la tarea y se destruyen cuando la tarea se detiene. Los volúmenes de Docker cuyo ámbito es `shared` se conservan una vez detenida la tarea. `autoprovision` Tipo: booleano Valor predeterminado: \$1: `false` Obligatorio: no Si este valor es `true`, el volumen de Docker se crea si aún no existe. Este campo se usa solo si `scope` es `shared`. Si el `scope` es `task`, este parámetro debe omitirse. `driver` Tipo: cadena Requerido: no El controlador del volumen de Docker que se va a usar. El valor de controlador debe coincidir con el nombre del controlador proporcionado por Docker, ya que se utiliza para la colocación de tareas. Si el controlador se instaló mediante la CLI del complemento de Docker, utilice `docker plugin ls` para recuperar el nombre de controlador de la instancia de contenedor. Si el controlador se instaló con otro método, utilice la detección de complementos de Docker para recuperar el nombre del controlador. `driverOpts` Tipo: cadena Requerido: no Un mapa de las opciones específicas del controlador de Docker que se deben transferir. Este parámetro se corresponde con `DriverOpts` en la sección Crear un volumen de Docker. `labels` Tipo: cadena Requerido: no Metadatos personalizados que se añaden al volumen de Docker. `mountPoints` Tipo: matriz de objetos Obligatorio: no Puntos de montaje para los volúmenes de datos del contenedor. Este parámetro asigna a `Volumes` en la API create-container de Docker y la opción `--volume` a docker run. Los contenedores de Windows pueden montar directorios completos en la misma unidad que `$env:ProgramData`. Los contenedores de Windows no pueden montar directorios en una unidad diferente y los puntos de montaje no se pueden utilizar entre unidades. Debe especificar los puntos de montaje para adjuntar un volumen de Amazon EBS directamente a una tarea de Amazon ECS. `sourceVolume` Tipo: cadena Obligatorio: sí, si se utilizan `mountPoints`. El nombre del volumen a montar. `containerPath` Tipo: cadena Obligatorio: sí, si se utilizan `mountPoints`. La ruta del contenedor donde se montará el volumen. `readOnly` Tipo: Booleano Obligatorio: no Si este valor es `true`, el acceso del contenedor al volumen es de solo lectura. Si este valor es `false`, el contenedor puede escribir en el volumen. El valor predeterminado es `false`. Para las tareas que se ejecutan en instancias de EC2 con sistema operativo Windows, deje el valor predeterminado `false`. # Ejemplos de volúmenes de Docker para Amazon ECS En los ejemplos siguientes se muestra cómo proporcionar almacenamiento efímero para un contenedor, cómo proporcionar un volumen compartido para varios contenedores y cómo proporcionar almacenamiento persistente de NFS para un contenedor. **Para proporcionar almacenamiento efímero para un contenedor con un volumen de Docker** En este ejemplo, un contenedor utiliza un volumen de datos vacío que se elimina después de finalizar la tarea. Como caso de uso de ejemplo, podría tener un contenedor que necesita obtener acceso a una ubicación de almacenamiento de archivos scratch durante una tarea. Esta tarea se puede lograr utilizando un volumen de Docker. 1. En sección de definición de tarea de `volumes`, defina un volumen de datos con los valores `name` y `DockerVolumeConfiguration`. En este ejemplo, especifique el ámbito como `task` para que el volumen se elimine una vez que se detenga la tarea y utilice el controlador `local` integrado. ``` "volumes": [ { "name": "scratch", "dockerVolumeConfiguration" : { "scope": "task", "driver": "local", "labels": { "scratch": "space" } } } ] ``` 1. En la sección `containerDefinitions`, defina un contenedor con valores `mountPoints` que hagan referencia al nombre del volumen definido y el valor `containerPath` en el que desea montar el volumen en el contenedor. ``` "containerDefinitions": [ { "name": "container-1", "mountPoints": [ { "sourceVolume": "scratch", "containerPath": "/var/scratch" } ] } ] ``` **Para proporcionar almacenamiento persistente para varios contenedores con un volumen de Docker** En este ejemplo, desea usar un volumen compartido para varios contenedores y desea que se conserve una vez que se detenga cualquiera de las tareas que lo usa. El controlador `local` integrado se está utilizando. Esto es para que el volumen siga vinculado al ciclo de vida de la instancia de contenedor. 1. En sección de definición de tarea de `volumes`, defina un volumen de datos con los valores `name` y `DockerVolumeConfiguration`. En este ejemplo, especifique un alcance `shared` para que el volumen persista, establezca el aprovisionamiento automático en `true`. Esto es para que el volumen se cree para su uso. A continuación, utilice también el controlador `local` integrado. ``` "volumes": [ { "name": "database", "dockerVolumeConfiguration" : { "scope": "shared", "autoprovision": true, "driver": "local", "labels": { "database": "database_name" } } } ] ``` 1. En la sección `containerDefinitions`, defina un contenedor con valores `mountPoints` que hagan referencia al nombre del volumen definido y el valor `containerPath` en el que desea montar el volumen en el contenedor. ``` "containerDefinitions": [ { "name": "container-1", "mountPoints": [ { "sourceVolume": "database", "containerPath": "/var/database" } ] }, { "name": "container-2", "mountPoints": [ { "sourceVolume": "database", "containerPath": "/var/database" } ] } ] ``` **Para proporcionar almacenamiento persistente de NFS para un contenedor con un volumen de Docker** En este ejemplo, un contenedor utiliza un volumen de datos de NFS que se monta automáticamente cuando inicia la tarea y se desmonta cuando la tarea finaliza. Utiliza el controlador integrado `local` de Docker. Un caso de uso de ejemplo es que puede tener un almacenamiento de NFS local y necesita acceder a él desde una tarea de ECS Anywhere. Esto se puede lograr con un volumen de Docker con la opción de controlador de NFS. 1. En sección de definición de tarea de `volumes`, defina un volumen de datos con los valores `name` y `DockerVolumeConfiguration`. En este ejemplo, especifique un alcance `task` para que el volumen se desmonte cuando finaliza la tarea. Utilice el controlador `local` y configure `driverOpts` con las opciones `type`, `device` y `o` en consecuencia. Sustituya `NFS_SERVER` por el punto de conexión del servidor de NFS. ``` "volumes": [ { "name": "NFS", "dockerVolumeConfiguration" : { "scope": "task", "driver": "local", "driverOpts": { "type": "nfs", "device": "$NFS_SERVER:/mnt/nfs", "o": "addr=$NFS_SERVER" } } } ] ``` 1. En la sección `containerDefinitions`, defina un contenedor con valores `mountPoints` que hagan referencia al nombre del volumen definido y el valor `containerPath` en el que desea montar el volumen en el contenedor. ``` "containerDefinitions": [ { "name": "container-1", "mountPoints": [ { "sourceVolume": "NFS", "containerPath": "/var/nfsmount" } ] } ] ``` # Uso de montajes de unión con Amazon ECS Con los montajes de unión, se monta un archivo o directorio de un host en un contenedor, como, por ejemplo, una instancia de Amazon EC2. Se admiten montajes de enlace para tareas que están alojadas en instancias de Fargate y Amazon EC2. Los montajes de unión están vinculados al ciclo de vida del contenedor que los utiliza. Una vez que se detienen todos los contenedores que utilizan un montaje de enlace, como cuando se detiene una tarea, se eliminan los datos. En el caso de las tareas que están alojadas en instancias de Amazon EC2, para vincular los datos al ciclo de vida de la instancia de Amazon EC2 del host, se puede especificar un `host` y un valor de `sourcePath` opcional en la definición de tareas. Para obtener más información, consulte [Montajes vinculados](https://docs.docker.com/engine/storage/bind-mounts/) en la documentación de Docker. A continuación, se indican algunos casos de uso comunes de los montajes de enlace. + Para proporcionar un volumen de datos vacío y montarlo en uno o más contenedores. + Para montar un volumen de datos del host en uno o más contenedores. + Para compartir un volumen de datos de un contenedor de origen con otros contenedores de la misma tarea. + Para exponer una ruta de acceso y su contenido desde un Dockerfile a uno o más contenedores. ## Consideraciones acerca del uso de los montajes de enlace Al utilizar montajes de enlace, tenga en cuenta lo siguiente. + De manera predeterminada, las tareas alojadas en AWS Fargate que utilizan la versión de la plataforma `1.4.0` o una posterior (Linux) o `1.0.0` o una posterior (Windows) reciben un mínimo de 20 GiB de almacenamiento efímero para los montajes de unión. Para aumentar la cantidad total de almacenamiento efímero, hasta un máximo de 200 GiB, indique el parámetro `ephemeralStorage` en la definición de tareas. + Para exponer los archivos de un Dockerfile a un volumen de datos cuando se ejecuta una tarea, el plano de datos de Amazon ECS busca una directiva `VOLUME`. Si la ruta absoluta especificada en la directiva `VOLUME` es la misma que la `containerPath` especificada en la definición de tarea, los datos de la ruta de la directiva `VOLUME` se copian en el volumen de datos. En el siguiente ejemplo de Dockerfile, un archivo con el nombre `examplefile` en el directorio `/var/log/exported` se escribe en el host y, a continuación, se monta dentro del contenedor. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN mkdir -p /var/log/exported RUN touch /var/log/exported/examplefile VOLUME ["/var/log/exported"] ``` De forma predeterminada, los permisos de los volúmenes se establecen en`0755` y el propietario como `root`. Puede personalizar estos permisos en el Dockerfile. En el siguiente ejemplo, se define al propietario del directorio como `node`. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN yum install -y shadow-utils && yum clean all RUN useradd node RUN mkdir -p /var/log/exported && chown node:node /var/log/exported RUN touch /var/log/exported/examplefile USER node VOLUME ["/var/log/exported"] ``` + Para las tareas que están alojadas en instancias de Amazon EC2, cuando no se especifica el valor de `host` ni de `sourcePath`, es el daemon de Docker el que administra el montaje de enlace. Cuando ningún contenedor hace referencia a este montaje de enlace, el servicio de limpieza de tareas del agente de contenedor de Amazon ECS lo elimina finalmente. De forma predeterminada, esto sucede tres horas después de que el contenedor se cierre. Sin embargo, es posible configurar esta duración con la variable de agente `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`. Para obtener más información, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md). Si necesita que estos datos persistan más allá del ciclo de vida del contenedor, especifique un valor de `sourcePath` para el montaje de enlace. + En el caso de las tareas alojadas en instancias administradas por Amazon ECS, algunas partes del sistema de archivos del host son de solo lectura. Los montajes de enlace de lectura/escritura deben utilizar directorios que admitan escritura, por ejemplo, `/var` para datos persistentes o `/tmp` para datos temporales. Si se intenta crear montajes de enlace de lectura y escritura en otros directorios, la tarea no se podrá iniciar y se producirá un error similar al siguiente: ``` error creating empty volume: error while creating volume path '/path': mkdir /path: read-only file system ``` Los montajes de enlace de solo lectura (configurados con `"readOnly": true` en el parámetro `mountPoints`) pueden apuntar a cualquier directorio accesible del host. Para ver una lista completa de rutas que admiten escritura, puede ejecutar una tarea en una instancia administrada por Amazon ECS y utilizarla para inspeccionar la tabla de montaje de la instancia. Cree una definición de tarea con los siguientes ajustes para acceder al sistema de archivos del host: ``` { "pidMode": "host", "containerDefinitions": [{ "privileged": true, ... }] } ``` A continuación, ejecute los siguientes comandos desde dentro del contenedor: ``` # List writable mounts cat /proc/1/root/proc/1/mounts | awk '$4 ~ /^rw,/ || $4 == "rw" {print $2}' | sort # List read-only mounts cat /proc/1/root/proc/1/mounts | awk '$4 ~ /^ro,/ || $4 == "ro" {print $2}' | sort ``` **importante** La configuración `privileged` otorga al contenedor capacidades ampliadas en el host, equivalentes al acceso raíz. En este ejemplo, se utiliza para inspeccionar la tabla de montaje del host con fines de diagnóstico. Para obtener más información, consulte [Evitar ejecutar contenedores con privilegios (Amazon EC2)](security-tasks-containers.md#security-tasks-containers-recommendations-avoid-privileged-containers). Para obtener más información sobre la ejecución de comandos interactivos en contenedores, consulte [Supervisión de los contenedores de Amazon ECS con ECS Exec](ecs-exec.md). # Especificación de un montaje de unión en la definición de tareas de Amazon ECS En el siguiente fragmento de JSON de definición de tareas, se muestra la sintaxis de los objetos `volumes`, `mountPoints` y `ephemeralStorage` para una definición de las tareas de Amazon ECS alojadas en instancias de Amazon EC2 o Fargate. ``` { "family": "", ... "containerDefinitions" : [ { "mountPoints" : [ { "containerPath" : "/path/to/mount_volume", "sourceVolume" : "string" } ], "name" : "string" } ], ... "volumes" : [ { "name" : "string" } ], "ephemeralStorage": { "sizeInGiB": integer } } ``` Para las tareas de Amazon ECS que están alojadas en instancias de Amazon EC2, puede utilizar el parámetro `host` opcional y un `sourcePath` al especificar los detalles del volumen de tareas. Cuando se especifica, vincula el montaje de enlace al ciclo de vida de la tarea en lugar del contenedor. ``` "volumes" : [ { "host" : { "sourcePath" : "string" }, "name" : "string" } ] ``` A continuación, se describe en más detalle cada uno de los parámetros de la definición de tarea. `name` Tipo: cadena Requerido: no El nombre del volumen. Se admiten hasta 255 letras (mayúsculas y minúsculas), números, guiones (`-`) y caracteres de subrayado (`_`). Se hace referencia a este nombre en el parámetro `sourceVolume` del objeto `mountPoints` de la definición de contenedor. `host` Obligatorio: no El parámetro `host` se utiliza para vincular el ciclo de vida del montaje de enlace a la instancia de Amazon EC2 del host, en lugar de a la tarea, y donde se almacena. Si el parámetro `host` está vacío, entonces el daemon de Docker asigna una ruta de host a su volumen de datos, pero no se garantiza que los datos persistan después de que los contenedores asociados dejen de funcionar. Los contenedores de Windows pueden montar directorios completos en la misma unidad que `$env:ProgramData`. El parámetro `sourcePath` se admite solo cuando se utilizan las tareas que se alojan en instancias de Amazon EC2 o instancias administradas de Amazon ECS. `sourcePath` Tipo: cadena Requerido: no Cuando utilice el parámetro `host`, especifique una `sourcePath` para declarar la ruta de la instancia de Amazon EC2 del host que se presenta al contenedor. Si este parámetro está vacío, el daemon de Docker asigna una ruta de host. Si el parámetro `host` contiene una ubicación de archivos `sourcePath`, el volumen de datos persiste en la ubicación especificada en la instancia de Amazon EC2 del host hasta que la elimine manualmente. Si el valor `sourcePath` no existe en la instancia de Amazon EC2 del host, el daemon de Docker lo crea. Si la ubicación existe, el contenido de la carpeta de la ruta de origen se exporta. `mountPoints` Tipo: matriz de objetos Obligatorio: no Puntos de montaje para los volúmenes de datos del contenedor. Este parámetro asigna a `Volumes` en la API create-container de Docker y la opción `--volume` a docker run. Los contenedores de Windows pueden montar directorios completos en la misma unidad que `$env:ProgramData`. Los contenedores de Windows no pueden montar directorios en una unidad diferente y los puntos de montaje no se pueden utilizar entre unidades. Debe especificar los puntos de montaje para adjuntar un volumen de Amazon EBS directamente a una tarea de Amazon ECS. `sourceVolume` Tipo: cadena Obligatorio: sí, si se utilizan `mountPoints`. El nombre del volumen a montar. `containerPath` Tipo: cadena Obligatorio: sí, si se utilizan `mountPoints`. La ruta del contenedor donde se montará el volumen. `readOnly` Tipo: Booleano Obligatorio: no Si este valor es `true`, el acceso del contenedor al volumen es de solo lectura. Si este valor es `false`, el contenedor puede escribir en el volumen. El valor predeterminado es `false`. Para las tareas que se ejecutan en instancias de EC2 con sistema operativo Windows, deje el valor predeterminado `false`. `ephemeralStorage` Tipo: objeto Obligatorio: no Cantidad de almacenamiento efímero que se asignará a la tarea. Este parámetro se utiliza para expandir la cantidad total de almacenamiento efímero disponible, más allá de la cantidad predeterminada, para las tareas alojadas en AWS Fargate que utilizan la versión `1.4.0` o posterior (Linux) o `1.0.0` o posterior (Windows) de la plataforma. Se puede utilizar la CLI de Copilot, CloudFormation, el SDK de AWS o la CLI para especificar almacenamiento efímero para un montaje de enlace. # Ejemplos de montajes vinculados para Amazon ECS En los siguientes ejemplos se cubren los casos de uso más comunes de montaje vinculado para los contenedores. **Para asignar una mayor cantidad de espacio de almacenamiento efímero a una tarea de Fargate** Para las tareas de Amazon ECS alojadas en Fargate que utilizan la versión `1.4.0` o posterior (Linux) o `1.0.0` (Windows) de la plataforma, se puede asignar una cantidad mayor de almacenamiento efímero que la predeterminada para que la utilicen los contenedores de la tarea. Este ejemplo se puede incorporar a los otros ejemplos para asignar un almacenamiento más efímero para sus tareas de Fargate. + En la definición de tarea, defina un objeto `ephemeralStorage`. El valor de `sizeInGiB` se expresa en GiB y debe ser un número entero entre `21` y `200`. ``` "ephemeralStorage": { "sizeInGiB": integer } ``` **Para proporcionar un volumen de datos vacío para uno o más contenedores** En algunos casos, es posible que desee proporcionar a los contenedores de una tarea algo de espacio de almacenamiento temporal. Por ejemplo, podría tener dos contenedores de base de datos que deben acceder a la misma ubicación de almacenamiento de archivos scratch durante una tarea. Esto se puede lograr con un montaje de enlace. 1. En la sección de definición de tarea `volumes`, defina un montaje vinculado con el nombre `database_scratch`. ``` "volumes": [ { "name": "database_scratch" } ] ``` 1. En la sección `containerDefinitions`, cree las definiciones de contenedor de base de datos. Esto es para que monten el volumen. ``` "containerDefinitions": [ { "name": "database1", "image": "my-repo/database", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "database_scratch", "containerPath": "/var/scratch" } ] }, { "name": "database2", "image": "my-repo/database", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "database_scratch", "containerPath": "/var/scratch" } ] } ] ``` **Para exponer una ruta y su contenido en un Dockerfile a un contenedor** En este ejemplo, tiene un Dockerfile que escribe los datos que va a montar dentro de un contenedor. Este ejemplo funciona para tareas que están alojadas en instancias de Fargate o Amazon EC2. 1. Cree un Dockerfile. En el siguiente ejemplo, se utiliza la imagen de contenedor pública de Amazon Linux 2 y se crea un archivo con el nombre `examplefile` en el directorio `/var/log/exported` que queremos montar dentro del contenedor. La directiva `VOLUME` debe especificar una ruta absoluta. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN mkdir -p /var/log/exported RUN touch /var/log/exported/examplefile VOLUME ["/var/log/exported"] ``` De forma predeterminada, los permisos de los volúmenes se establecen en`0755` y el propietario como `root`. Estos permisos se pueden cambiar en el Dockerfile. En el ejemplo siguiente, el propietario del directorio `/var/log/exported` se establece como `node`. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN yum install -y shadow-utils && yum clean all RUN useradd node RUN mkdir -p /var/log/exported && chown node:node /var/log/exported USER node RUN touch /var/log/exported/examplefile VOLUME ["/var/log/exported"] ``` 1. En la sección de definición de tarea de `volumes`, defina un volumen con el nombre `application_logs`. ``` "volumes": [ { "name": "application_logs" } ] ``` 1. En la sección `containerDefinitions`, cree las definiciones de contenedor de aplicaciones. Esto es para que monten el almacenamiento. El valor de `containerPath` debe coincidir con la ruta absoluta especificada en la directiva `VOLUME` del Dockerfile. ``` "containerDefinitions": [ { "name": "application1", "image": "my-repo/application", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "application_logs", "containerPath": "/var/log/exported" } ] }, { "name": "application2", "image": "my-repo/application", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "application_logs", "containerPath": "/var/log/exported" } ] } ] ``` **Para proporcionar un volumen de datos vacío para un contenedor que está vinculado al ciclo de vida de la instancia de Amazon EC2 del host** Para las tareas que están alojadas en instancias de Amazon EC2, se pueden utilizar montajes de enlace y vincular los datos al ciclo de vida de la instancia de Amazon EC2 del host. Para ello, se utiliza el parámetro `host` y se especifica un valor de `sourcePath`. Cualquier archivo que exista en `sourcePath` se presenta a los contenedores con el valor `containerPath`. Cualquier archivo que se escriba en el valor `containerPath`, se escribe en el valor `sourcePath` en la instancia de Amazon EC2 del host. **importante** Amazon ECS no sincroniza el almacenamiento en todas las instancias de Amazon EC2. Las tareas que utilizan almacenamiento persistente se pueden colocar en cualquier instancia de Amazon EC2 del clúster que tenga capacidad disponible. Si las tareas requieren almacenamiento persistente después de detenerse y reiniciarse, especifique siempre la misma instancia de Amazon EC2 en el momento de lanzar la tarea con el comando [start-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/start-task.html) de la AWS CLI. También puede utilizar volúmenes de Amazon EFS para el almacenamiento persistente. Para obtener más información, consulte [Uso de volúmenes de Amazon EFS con Amazon ECS](efs-volumes.md). 1. En la sección de la definición de tarea `volumes`, defina un montaje vinculado con los valores de `name` y `sourcePath`. En el ejemplo siguiente, la instancia de Amazon EC2 del host contiene datos de `/ecs/webdata` que va a montar dentro del contenedor. ``` "volumes": [ { "name": "webdata", "host": { "sourcePath": "/ecs/webdata" } } ] ``` 1. En la sección `containerDefinitions`, defina un contenedor con un valor de `mountPoints` que haga referencia al nombre del montaje de enlace y el valor de `containerPath` en el que va a realizar el montaje de enlace en el contenedor. ``` "containerDefinitions": [ { "name": "web", "image": "public.ecr.aws/docker/library/nginx:latest", "cpu": 99, "memory": 100, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "essential": true, "mountPoints": [ { "sourceVolume": "webdata", "containerPath": "/usr/share/nginx/html" } ] } ] ``` **Para montar un volumen definido en varios contenedores en diferentes ubicaciones** Puede definir un volumen de datos en una definición de tarea y montarlo en diferentes ubicaciones en distintos contenedores. Por ejemplo, el contenedor del host tiene una carpeta de datos del sitio web en `/data/webroot`. Es posible que desee montar ese volumen de datos como de solo lectura en dos servidores web diferentes que tengan diferentes raíces de documentos. 1. En la sección de definición de tarea de `volumes`, defina un volumen de datos con el nombre `webroot` y la ruta de origen `/data/webroot`. ``` "volumes": [ { "name": "webroot", "host": { "sourcePath": "/data/webroot" } } ] ``` 1. En la sección `containerDefinitions`, defina un contenedor para cada servidor web con valores de `mountPoints` que permitan asociar el volumen de `webroot` con el valor de `containerPath` apuntando a la raíz de documentos para ese contenedor. ``` "containerDefinitions": [ { "name": "web-server-1", "image": "my-repo/ubuntu-apache", "cpu": 100, "memory": 100, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "essential": true, "mountPoints": [ { "sourceVolume": "webroot", "containerPath": "/var/www/html", "readOnly": true } ] }, { "name": "web-server-2", "image": "my-repo/sles11-apache", "cpu": 100, "memory": 100, "portMappings": [ { "containerPort": 8080, "hostPort": 8080 } ], "essential": true, "mountPoints": [ { "sourceVolume": "webroot", "containerPath": "/srv/www/htdocs", "readOnly": true } ] } ] ``` **Para montar volúmenes desde otro contenedor con `volumesFrom`** Para las tareas alojadas en instancias de Amazon EC2, puede definir uno o más volúmenes en un contenedor y, a continuación, utilizar el parámetro `volumesFrom` en una definición de contenedor diferente dentro de la misma tarea para montar todos los volúmenes de `sourceContainer` en sus puntos de montaje definidos originalmente. El parámetro `volumesFrom` se aplica a volúmenes definidos en la definición de tarea, y a los que están integrados en la imagen con un Dockerfile. 1. (Opcional) Para compartir un volumen integrado en una imagen, utilice la instrucción `VOLUME` del Dockerfile. En el siguiente ejemplo de Dockerfile se utiliza una imagen `httpd` y, a continuación, se agrega un volumen y se lo monta en `dockerfile_volume` en la raíz de documentos de Apache. Es la carpeta que utiliza el servidor web `httpd`. ``` FROM httpd VOLUME ["/usr/local/apache2/htdocs/dockerfile_volume"] ``` Puede crear una imagen con este Dockerfile y enviarla a un repositorio, como Docker Hub, y utilizarla en su definición de tarea. La imagen de ejemplo `my-repo/httpd_dockerfile_volume` que se utiliza en los pasos siguientes se diseñó con el Dockerfile anterior. 1. Cree una definición de tarea que defina los otros volúmenes y puntos de montaje para los contenedores. En esta sección de ejemplo `volumes`, se crea un volumen vacío llamado `empty`, que será administrado por el daemon de Docker. También hay un volumen de host definido denominado `host_etc`. Exporta la carpeta `/etc` en la instancia de contenedor del host. ``` { "family": "test-volumes-from", "volumes": [ { "name": "empty", "host": {} }, { "name": "host_etc", "host": { "sourcePath": "/etc" } } ], ``` En la sección de definiciones de contenedor, cree un contenedor para montar los volúmenes definidos anteriormente. En este ejemplo, el contenedor `web` monta los volúmenes `empty` y `host_etc`. Este es el contenedor que utiliza la imagen creada con un volumen en el Dockerfile. ``` "containerDefinitions": [ { "name": "web", "image": "my-repo/httpd_dockerfile_volume", "cpu": 100, "memory": 500, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "mountPoints": [ { "sourceVolume": "empty", "containerPath": "/usr/local/apache2/htdocs/empty_volume" }, { "sourceVolume": "host_etc", "containerPath": "/usr/local/apache2/htdocs/host_etc" } ], "essential": true }, ``` Cree otro contenedor que utiliza `volumesFrom` para montar todos los volúmenes que están asociados con el contenedor `web`. Todos los volúmenes del contenedor `web` se montan también en el contenedor `busybox`. Esto incluye el volumen especificado en el Dockerfile que se utilizó para crear la imagen `my-repo/httpd_dockerfile_volume`. ``` { "name": "busybox", "image": "busybox", "volumesFrom": [ { "sourceContainer": "web" } ], "cpu": 100, "memory": 500, "entryPoint": [ "sh", "-c" ], "command": [ "echo $(date) > /usr/local/apache2/htdocs/empty_volume/date && echo $(date) > /usr/local/apache2/htdocs/host_etc/date && echo $(date) > /usr/local/apache2/htdocs/dockerfile_volume/date" ], "essential": false } ] } ``` Cuando esta tarea se ejecuta, los dos contenedores montan los volúmenes y el `command` en el contenedor `busybox` escribe la fecha y la hora en un archivo. Este archivo se denomina `date` en cada una de las carpetas de volumen. Las carpetas se pueden ver en el sitio web mostrado por el contenedor `web`. **nota** Como el contenedor `busybox` ejecuta un comando rápido y, a continuación, se cierra, debe establecerse como `"essential": false` en la definición de contenedor. De no ser así, detiene toda la tarea cuando se cierra. # Administración del espacio de memoria de intercambio de contenedores en Amazon ECS Con Amazon ECS, es posible controlar el uso del espacio de memoria de intercambio en las instancias de Amazon EC2 basadas en Linux en el nivel de contenedor. Con la configuración de intercambio por contenedor, cada contenedor dentro de una definición de tareas puede tener el intercambio habilitado o deshabilitado. Para aquellos que lo tienen habilitado, es posible limitar la cantidad máxima de espacio de intercambio que se utiliza. Por ejemplo, los contenedores de latencia crítica pueden tener el intercambio deshabilitado. En cambio, los contenedores con una gran demanda de memoria transitoria pueden tener activado el intercambio para reducir las posibilidades de errores de memoria insuficiente cuando el contenedor opera con carga. La configuración de intercambio de un contenedor se administra mediante los siguientes parámetros de definición de contenedor: `maxSwap` La cantidad total de memoria de intercambio (en MiB) que puede utilizar un contenedor. Este parámetro se traduce en la opción `--memory-swap` de docker run donde el valor es la suma de la memoria del contenedor más el valor de `maxSwap`. Si se especifica un valor `maxSwap` para `0`, el contenedor no utiliza el intercambio. Los valores aceptados son `0` o cualquier entero positivo. Si se omite el parámetro `maxSwap`, el contenedor utiliza la configuración de intercambio de la instancia de contenedor en la que se está ejecutando. Debe establecerse un valor de `maxSwap` para el parámetro `swappiness`. `swappiness` Puede utilizar esta opción para ajustar el comportamiento de intercambio de memoria de un contenedor. Con un valor `swappiness` de `0`, no se produce el intercambio a menos que sea necesario. Un valor `swappiness` de `100` aumenta al máximo el intercambio de páginas. Los valores aceptados son números enteros comprendidos entre `0` y `100`. Si no se especifica el parámetro `swappiness`, se utiliza el valor predeterminado de `60`. Si no se especifica ningún valor para `maxSwap`, este parámetro se omite. Este parámetro se corresponde con la opción `--memory-swappiness` con docker run. En el siguiente ejemplo, se proporciona la sintaxis JSON. ``` "containerDefinitions": [{ ... "linuxParameters": { "maxSwap": integer, "swappiness": integer }, ... }] ``` ## Consideraciones Tenga en cuenta lo siguiente cuando utilice una configuración de intercambio por contenedor. + El espacio de intercambio debe estar habilitado y asignado a la instancia de Amazon EC2 que aloja las tareas para que las utilicen los contenedores. De forma predeterminada, las AMI optimizadas para Amazon ECS no tienen habilitado el intercambio. Debe habilitar el intercambio en la instancia para utilizar esta característica. Para obtener más información, consulte [Volúmenes de intercambio de almacén de instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-store-swap-volumes.html) en la *Guía del usuario de Amazon EC2* o [¿Cómo asigno memoria para que funcione como espacio de intercambio en una instancia de Amazon EC2?](https://repost.aws/knowledge-center/ec2-memory-swap-file). + Los parámetros de definición de contenedores de espacio de intercambio solo se admiten para las definiciones de tareas que especifican EC2. Estos parámetros no se admiten en las definiciones de tareas destinadas únicamente al uso de Amazon ECS en Fargate. + Esta característica solo se admite para los contenedores de Linux. Los contenedores de Windows actualmente no se admiten. + Si en una definición de tareas se omiten los parámetros de definición de contenedor `maxSwap` y `swappiness`, cada contenedor tiene un valor `swappiness` predeterminado de `60`. Además, el uso total de intercambio se limita al doble de la memoria del contenedor. + Si utiliza tareas en Amazon Linux 2023, no se admite el parámetro `swappiness`. # Diferencias en la definición de tareas de Amazon ECS para instancias administradas de Amazon ECS Para utilizar instancias administradas de Amazon ECS, debe configurar la definición de tareas para utilizar el tipo de lanzamiento de instancias administradas de Amazon ECS. Hay algunas consideraciones adicionales al utilizar instancias administradas de Amazon ECS. ## Parámetros de definición de tarea Las tareas que utilizan instancias administradas de Amazon ECS admiten la mayoría de los parámetros de definición de tareas de Amazon ECS disponibles. Sin embargo, algunos parámetros tienen comportamientos o limitaciones específicos cuando se utilizan con las tareas de instancias administradas de Amazon ECS. Los siguientes parámetros de definición de tareas no son válidos en tareas de instancias administradas de Amazon ECS: + `disableNetworking` + `dnsSearchDomains` + `dnsServers` + `dockerLabels` + `dockerSecurityOptions` + `dockerVolumeConfiguration` + `ephemeralStorage` + `extraHosts` + `fsxWindowsFileServerVolumeConfiguration` + `hostname` + `inferenceAccelerator` + `ipcMode` + `links` + `maxSwap` + `proxyConfiguration` + `sharedMemorySize` + `sourcepath`Volúmenes de + `swappiness` + `tmpfs` Los siguientes parámetros de definición de tarea son válidos en tareas de instancias administradas de Amazon ECS, pero tienen limitaciones que hay que tener en cuenta: + `networkConfiguration`: las tareas de instancias administradas de Amazon ECS utilizan el modo de red `awsvpc` y `host`. + `placementConstraints`: los atributos siguientes de restricción son compatibles. + `ecs.subnet-id` + `ecs.availability-zone` + `ecs.instance-type` + `ecs.cpu-architecture` + `requiresCompatibilities`: debe incluir `MANAGED_INSTANCES` para garantizar que la definición de la tarea sea compatible con instancias administradas de Amazon ECS. + `resourceRequirement`: `InferenceAccelerator` no se admite. + `operatingSystemFamily`: instancias administradas de Amazon ECS utiliza `LINUX`. + `volumes`: cuando se utilizan montajes de enlace con una `sourcePath`, la ruta debe apuntar a un directorio que admita escritura en el host. Algunas partes del sistema de archivos de instancias administradas por Amazon ECS son de solo lectura. Los directorios en los que se puede escribir incluyen `/var` y `/tmp`. Para obtener más información, consulte [Uso de montajes de unión con Amazon ECS](bind-mounts.md). Para garantizar que la definición de tareas sea válida para su uso con instancias administradas de Amazon ECS, puede especificar lo siguiente al registrar la definición de tarea: + En la Consola de administración de AWS, en el campo **Requires Compatibilities (Requiere compatibilidades)**, especifique `MANAGED_INSTANCES`. + En la AWS CLI, especifique la opción `--requires-compatibilities`. + En la API de Amazon ECS, especifique el indicador `requiresCompatibilities`. # Diferencias en la definición de tareas de Amazon ECS para Fargate Para utilizar Fargate, se debe configurar la definición de tareas para utilizar el tipo de lanzamiento de Fargate. Hay algunas consideraciones adicionales a la hora de utilizar Fargate. ## Parámetros de definición de tarea Las tareas que utilizan Fargate no admiten todos los parámetros de definición de tareas de Amazon ECS que están disponibles. Algunos parámetros directamente no son compatibles, y otros se comportan de forma distinta para tareas de Fargate. Los siguientes parámetros de definición de tareas no son válidos en tareas de Fargate: + `disableNetworking` + `dnsSearchDomains` + `dnsServers` + `dockerSecurityOptions` + `extraHosts` + `gpu` + `ipcMode` + `links` + `placementConstraints` + `privileged` + `maxSwap` + `swappiness` Los siguientes parámetros de definición de tareas son válidos en tareas de Fargate, pero presentan limitaciones que se deben tener en cuenta: + `linuxParameters`: al especificar opciones específicas de Linux que se aplican al contenedor, la única capacidad que se puede agregar en `capabilities` es `CAP_SYS_PTRACE`. No se admiten los parámetros `devices`, `sharedMemorySize` y `tmpfs`. Para obtener más información, consulte [Parámetros de Linux](task_definition_parameters.md#container_definition_linuxparameters). + `volumes`: las tareas de Fargate solo admiten volúmenes de host de montaje vinculado, por lo que no se admite el parámetro `dockerVolumeConfiguration`. Para obtener más información, consulte [Volúmenes](task_definition_parameters.md#volumes). + `cpu`: para contenedores Windows en AWS Fargate, el valor no puede ser inferior a 1 vCPU. + `networkConfiguration`: las tareas de Fargate siempre utilizan el modo de red `awsvpc`. A fin de garantizar que la definición de tareas sea válida para su utilización con Fargate, puede especificar lo siguiente al registrar la definición de tareas: + En la Consola de administración de AWS, en el campo **Requires Compatibilities (Requiere compatibilidades)**, especifique `FARGATE`. + En la AWS CLI, especifique la opción `--requires-compatibilities`. + En la API de Amazon ECS, especifique el indicador `requiresCompatibilities`. ## Arquitecturas y sistemas operativos Al configurar una definición de tarea y contenedor para AWS Fargate, debe especificar el sistema operativo que ejecuta el contenedor. Se admiten los siguientes sistemas operativos para AWS Fargate: + Amazon Linux 2 **nota** Los contenedores de Linux utilizan únicamente el kernel y la configuración del kernel del sistema operativo del host. Por ejemplo, la configuración del kernel incluye los controles del sistema `sysctl`. Se puede crear una imagen de contenedor de Linux a partir de una imagen base que contenga los archivos y programas de cualquier distribución de Linux. Si la arquitectura de la CPU coincide, puede ejecutar contenedores desde cualquier imagen de contenedor de Linux en cualquier sistema operativo. + Windows Server 2019 Full + Windows Server 2019 Core + Windows Server 2022 Full + Windows Server 2022 Core Cuando ejecuta contenedores de Windows en AWS Fargate, debe tener la arquitectura de CPU X86\$164. Cuando ejecuta contenedores Linux en AWS Fargate, puede utilizar la arquitectura de CPU X86\$164 o la arquitectura ARM64 para las aplicaciones basadas en ARM. Para obtener más información, consulte [Definiciones de tareas de Amazon ECS para cargas de trabajo de ARM de 64 bits](ecs-arm64.md). ## Memoria y CPU de tarea Las definiciones de tareas de Amazon ECS para AWS Fargate requieren que especifique la CPU y la memoria en el nivel de tarea. La mayoría de casos de uso solo se cumplen especificando estos recursos en el nivel de tarea. En la siguiente tabla se muestran las combinaciones válidas de CPU y memoria de nivel de tarea. Puede indicar los valores de memoria en la definición de tarea como una cadena en MiB o GB. Por ejemplo, puede especificar un valor de memoria `3072` en MiB o `3 GB` en GB. Puede indicar los valores de la CPU en el archivo JSON como una cadena en unidades de CPU o CPU virtuales (vCPU). Por ejemplo, puede especificar un valor de CPU `1024` en unidades de CPU o `1 vCPU` en vCPU. | Valor de CPU | Valor de memoria | Sistemas operativos admitidos por AWS Fargate | | --- | --- | --- | | 256 (0,25 vCPU) | 512 MiB, 1 GB, 2 GB | Linux | | 512 (0,5 vCPU) | 1 GB, 2 GB, 3 GB, 4 GB | Linux | | 1024 (1 vCPU) | 2 GB, 3 GB, 4 GB, 5 GB, 6 GB, 7 GB, 8 GB | Linux, Windows | | 2048 (2 vCPU) | Entre 4 GB y 16 GB en incrementos de 1 GB | Linux, Windows | | 4096 (4 vCPU) | Entre 8 GB y 30 GB en incrementos de 1 GB | Linux, Windows | | 8192 (8 vCPU) Esta opción requiere una plataforma Linux `1.4.0` o posterior. | Entre 16 GB y 60 GB en incrementos de 4 GB | Linux | | 16 384 (16 vCPU) Esta opción requiere una plataforma Linux `1.4.0` o posterior. | Entre 32 GB y 120 GB en incrementos de 8 GB | Linux | ## Integración en red de las tareas Las tareas de Amazon ECS para AWS Fargate requieren el modo de red `awsvpc`, que proporciona a cada tarea una interfaz de red elástica. Cuando se ejecuta una tarea o se crea un servicio con este modo de red, debe especificar una o más subredes para asociar la interfaz de red y uno o más grupos de seguridad para aplicarlo a la interfaz de red. Si va a usar subredes públicas, decida si desea proporcionar una dirección IP pública para la interfaz de red. Para que las tareas de Fargate de una subred pública extraigan imágenes de contenedor, es necesario asignar una dirección IP pública a la interfaz de red elástica de la tarea con una ruta a Internet o una gateway NAT que pueda dirigir las solicitudes a Internet. Para que las tareas de Fargate de una subred privada extraigan imágenes de contenedor, debe haber una gateway NAT en la subred para dirigir las solicitudes a Internet. Cuando aloja las imágenes de contenedor en Amazon ECR, puede configurar Amazon ECR para que utilice un punto de enlace de la VPC de interfaz. En este caso, la dirección IPv4 privada de la tarea se utiliza para extraer la imagen. Para obtener más información acerca de los puntos de conexión de la interfaz de Amazon ECR, consulte [Puntos de conexión de VCP de la interfaz de Amazon ECR (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) en la *Guía del usuario de Amazon Elastic Container Registry*. A continuación, se muestra un ejemplo de la sección `networkConfiguration` de un servicio de Fargate: ``` "networkConfiguration": { "awsvpcConfiguration": { "assignPublicIp": "ENABLED", "securityGroups": [ "sg-12345678" ], "subnets": [ "subnet-12345678" ] } } ``` ## Límites de recursos de tareas Las definiciones de tareas de Amazon ECS para contenedores Linux en AWS Fargate admiten el parámetro `ulimits` para definir los límites de recursos que se van a establecer en un contenedor. Las definiciones de tareas de Amazon ECS para Windows en AWS Fargate admiten el parámetro `ulimits` para definir los límites de recursos que se van a establecer en un contenedor. Las tareas de Amazon ECS alojadas en Fargate utilizan los valores límite de recursos predeterminados que establece el sistema operativo, a excepción del parámetro límite de recursos `nofile`. El límite de recursos `nofile` define una restricción en el número de archivos abiertos que puede utilizar un contenedor. En Fargate, el límite flexible `nofile` predeterminado es ` 65535` y el límite invariable es `65535`. Puede establecer los valores de ambos límites en un valor máximo de `1048576`. El siguiente es un fragmento de código de definición de tareas de ejemplo que muestra cómo definir un límite `nofile` personalizado que se ha duplicado: ``` "ulimits": [ { "name": "nofile", "softLimit": 2048, "hardLimit": 8192 } ] ``` Para obtener más información acerca de los otros límites de recursos que se pueden ajustar, consulte [Límites de recursos](task_definition_parameters.md#container_definition_limits). ## Registro ### Registro de eventos Amazon ECS registra las acciones que realiza en EventBridge. Puede utilizar eventos de Amazon ECS para EventBridge con el fin de recibir notificaciones casi en tiempo real sobre el estado actual de los clústeres, servicios y tareas de Amazon ECS. Además, puede automatizar acciones para responder a estos eventos. Para obtener más información, consulte [Automaticzación de las respuestas a los errores de Amazon ECS mediante EventBridge](cloudwatch_event_stream.md). ### Registro del ciclo de vida de tareas Las tareas que se ejecutan en Fargate publican marcas temporales para realizar un seguimiento de la tarea a través de los estados de su ciclo de vida. Puede ver las marcas temporales en los detalles de la tarea en la Consola de administración de AWS y describiendo la tarea en la AWS CLI y en los SDK. Por ejemplo, puedes utilizar las marcas de temporales para evaluar cuánto tiempo ha dedicado la tarea a descargar las imágenes del contenedor y decidir si debe optimizar el tamaño de las imágenes del contenedor o utilizar índices Seekable OCI. Para obtener más información acerca de las prácticas de imágenes de contenedor, consulte [Prácticas recomendadas para las imágenes de contenedores de Amazon ECS](container-considerations.md). ### Registro de la aplicación Las definiciones de tareas de Amazon ECS para AWS Fargate admiten los controladores de registros `awslogs`, `splunk` y `awsfirelens` para la configuración de registros. El controlador de registros `awslogs` configura las tareas de Fargate para que envíen información de registro a Amazon CloudWatch Logs. A continuación se muestra un fragmento de definición de tarea donde se configura el controlador de registros `awslogs`: ``` "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-group" : "/ecs/fargate-task-definition", "awslogs-region": "us-east-1", "awslogs-stream-prefix": "ecs" } } ``` Para obtener más información acerca de la utilización del controlador de registros `awslogs` en una definición de tareas para que envíe sus registros de contenedor a CloudWatch Logs, consulte [Envío de registros de Amazon ECS a CloudWatch](using_awslogs.md). Para obtener más información acerca de cómo utilizar el controlador de registros de `awsfirelens` en una definición de tarea, consulte [Envío de registros de Amazon ECS a un servicio de AWS o AWS Partner](using_firelens.md). Para obtener más información acerca de cómo utilizar el controlador de registros de `splunk` en una definición de tarea, consulte [Controlador de registros de `splunk`](example_task_definitions.md#example_task_definition-splunk). ## Almacenamiento de tareas Para las tareas de Amazon ECS alojadas en Fargate, se admiten los siguientes tipos de almacenamiento: + Los volúmenes de Amazon EBS proporcionan almacenamiento en bloques rentable, duradero y de alto rendimiento para cargas de trabajo en contenedores con uso intensivo de datos. Para obtener más información, consulte [Uso de volúmenes de Amazon EBS con Amazon ECS](ebs-volumes.md). + Volúmenes de Amazon EFS para almacenamiento persistente. Para obtener más información, consulte [Uso de volúmenes de Amazon EFS con Amazon ECS](efs-volumes.md). + Montajes vinculados para almacenamiento efímero. Para obtener más información, consulte [Uso de montajes de unión con Amazon ECS](bind-mounts.md). ## Carga diferida de imágenes de contenedores mediante Seekable OCI (SOCI) Las tareas de Amazon ECS en Fargate que utilizan la versión de la plataforma Linux `1.4.0` pueden utilizar Seekable OCI (SOCI) para iniciar las tareas con mayor rapidez. Con los SOCI, los contenedores solo tardan unos segundos en extraer la imagen antes de empezar, lo que proporciona tiempo para configurar el entorno y crear instancias de la aplicación mientras la imagen se descarga en segundo plano. Esto se denomina *carga diferida*. Cuando Fargate inicia una tarea de Amazon ECS, Fargate detecta automáticamente si existe un índice SOCI para una imagen de la tarea e inicia el contenedor sin esperar a que se descargue la imagen completa. En el caso de los contenedores que se ejecutan sin índices SOCI, las imágenes del contenedor se descargan completamente antes de iniciar el contenedor. Sucede lo mismo en todas las otras versiones de la plataforma de Fargate y en las AMI optimizadas para Amazon ECS en instancias de Amazon EC2. Seekable OCI (SOCI) es una tecnología de código abierto desarrollada por AWS que puede lanzar contenedores más rápido al cargar la imagen del contenedor en diferido. SOCI funciona creando un índice (índice SOCI) de los archivos dentro de una imagen de contenedor existente. Este índice ayuda a lanzar los contenedores con mayor rapidez, lo que permite extraer un archivo individual de una imagen del contenedor antes de descargar la imagen completa. El índice SOCI debe almacenarse como un artefacto en el mismo repositorio de la imagen en el registro del contenedor. Solo debe utilizar índices SOCI de fuentes confiables, ya que el índice es la fuente autorizada del contenido de la imagen. Para obtener más información, consulte [Introducción a Seekable OCI para imágenes de contenedores de carga diferida](https://aws.amazon.com/about-aws/whats-new/2022/09/introducing-seekable-oci-lazy-loading-container-images/). Los clientes que deseen utilizar SOCI solo podrán utilizar el manifiesto v2 de índices SOCI. Los clientes que hayan utilizado anteriormente SOCI en Fargate pueden seguir utilizando el manifiesto v1 de índices SOCI; sin embargo, les recomendamos encarecidamente que migren al manifiesto v2 de índices SOCI. El manifiesto v2 de índices SOCI crea una relación explícita entre las imágenes de los contenedores y sus índices SOCI para garantizar una implementación coherente. **Consideraciones** Si desea que Fargate utilice un índice SOCI para cargar imágenes de contenedores en diferido en una tarea, tenga en cuenta lo siguiente: + Solo las tareas que se ejecutan en la versión de la plataforma de Linux `1.4.0` pueden usar índices SOCI. No se admiten tareas que ejecutan contenedores de Windows en Fargate. + Se admiten tareas que se ejecutan en las arquitecturas de CPU X86\$164 o ARM64. + Las imágenes del contenedor de la definición de la tarea deben almacenarse en un registro de imágenes compatible. A continuación se enumeran los registros compatibles: + Registros privados de Amazon ECR + Solo se admiten las imágenes de contenedor que utilizan compresión gzip o que no están comprimidas. No se admiten las imágenes de contenedor que utilizan compresión zstd. + En el caso del manifiesto v2 de índices SOCI, al generar un manifiesto de índice SOCI, se modifica el manifiesto de la imagen del contenedor al agregar una anotación para el índice SOCI. Esto resulta en un nuevo resumen de la imagen del contenedor. El contenido de las capas del sistema de archivos de las imágenes del contenedor no cambia. + En el caso del manifiesto v2 de índices SOCI, si la imagen del contenedor ya se ha almacenado en el repositorio de imágenes del contenedor, después de generar un índice SOCI, es necesario volver a enviar la imagen del contenedor. El reenvío de una imagen de contenedor no aumentará los costos de almacenamiento mediante la duplicación de las capas del sistema de archivos, solo se cargará un nuevo archivo de manifiesto. + Recomendamos que pruebe la carga diferida con imágenes de contenedores con un tamaño superior a 250 MiB comprimido. Es menos probable que se reduzca el tiempo de carga de imágenes más pequeñas. + Como la carga diferida puede cambiar el tiempo que tardan en empezar las tareas, es posible que deba que cambiar varios tiempos de espera, como el período de gracia de las comprobaciones de estado de Elastic Load Balancing. + Si desea evitar que la imagen de un contenedor se cargue de manera diferida, la imagen del contenedor deberá ser reenviada sin un índice SOCI adjunto. **Crear un índice Seekable OCI** Para que una imagen de un contenedor se cargue de forma progresiva, es necesario crear un índice SOCI (un archivo de metadatos) y almacenarlo en el repositorio de imágenes del contenedor junto con la imagen del contenedor. Para crear y enviar un índice SOCI, puede utilizar la herramienta de código abierto [soci-snapshotter CLI](https://github.com/awslabs/soci-snapshotter) en GitHub. O bien, puede implementar CloudFormation AWS SOCI Index Builder. Se trata de una solución sin servidor que crea y envía automáticamente un índice SOCI cuando se envía una imagen de contenedor a Amazon ECR. Para más información sobre la solución y los pasos de instalación, consulte [CloudFormation AWS SOCI Index Builder](https://awslabs.github.io/cfn-ecr-aws-soci-index-builder/) en GitHub. CloudFormation AWS SOCI Index Builder es una manera más sencilla de automatizar la introducción a SOCI, mientras que la herramienta SOCI de código abierto ofrece más flexibilidad en cuanto a la generación de índices y permite integrar la generación de índices en los procesos de integración continua y entrega continua (CI/CD). **nota** Para crear el índice SOCI para una imagen, esta debe existir en el almacén de imágenes containerd del `soci-snapshotter`de la computadora en ejecución. Si la imagen está en el almacén de imágenes de Docker, esta no se puede encontrar. **Verificar que una tarea utilizó la carga diferida** Para verificar que una tarea se cargó en diferido mediante SOCI, compruebe el punto de conexión de los metadatos de la tarea desde dentro de la tarea. Cuando ejecuta una consulta a la versión 4 del punto de conexión de los metadatos de la tarea, hay un campo de `Snapshotter` en la ruta predeterminada para el contenedor desde el que se ejecuta la consulta. Además, hay campos de `Snapshotter` para cada contenedor en la ruta `/task`. El valor predeterminado de este campo es `overlayfs`, y este campo se establece en `soci` si se utiliza SOCI. Para verificar que una imagen de contenedor tiene un manifiesto v2 de índices SOCI adjunto, puede recuperar el índice de imágenes de Amazon ECR mediante la AWS CLI. ``` IMAGE_REPOSITORY=r IMAGE_TAG=latest aws ecr batch-get-image \ --repository-name=$IMAGE_REPOSITORY \ --image-ids imageTag=$IMAGE_TAG \ --query 'images[0].imageManifest' --output text | jq -r '.manifests[] | select(.artifactType=="application/vnd.amazon.soci.index.v2+json")' ``` Para comprobar que una imagen de contenedor tiene un manifiesto v1 de índices SOCI adjunto, puede utilizar la API de referencia de OCI. ``` ACCOUNT_ID=111222333444 AWS_REGION=us-east-1 IMAGE_REPOSITORY=nginx-demo IMAGE_TAG=latest IMAGE_DIGEST=$(aws ecr describe-images --repository-name $IMAGE_REPOSITORY --image-ids imageTag=$IMAGE_TAG --query 'imageDetails[0].imageDigest' --output text) ECR_PASSWORD=$(aws ecr get-login-password) curl \ --silent \ --user AWS:$ECR_PASSWORD \ https://$ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/v2/$IMAGE_REPOSITORY/referrers/$IMAGE_DIGEST?artifactType=application%2Fvnd.amazon.soci.index.v1%2Bjson | jq -r '.' ``` # Diferencias en la definición de tareas de Amazon ECS para instancias de EC2 que ejecutan Windows Las tareas que se ejecutan en instancias de Windows de EC2 no admiten todos los parámetros de definición de tareas de Amazon ECS disponibles. Algunos parámetros directamente no son compatibles, y otros se comportan de manera distinta. Los siguientes parámetros de la definición de tareas no se admiten para las definiciones de tareas de Windows de Amazon EC2: + `containerDefinitions` + `disableNetworking` + `dnsServers` + `dnsSearchDomains` + `extraHosts` + `links` + `linuxParameters` + `privileged` + `readonlyRootFilesystem` + `user` + `ulimits` + `volumes` + `dockerVolumeConfiguration` + `cpu` Le recomendamos que especifique la CPU de nivel de contenedor para los contenedores de Windows. + `memory` Le recomendamos que especifique la memoria de nivel de contenedor para los contenedores de Windows. + `proxyConfiguration` + `ipcMode` + `pidMode` + `taskRoleArn` Los roles de IAM para las tareas en instancias de Windows de EC2 requieren una configuración adicional, pero gran parte de esta configuración es similar a la de los roles de IAM para las tareas en instancias de contenedor de Linux. Para obtener más información consulte () [Configuración adicional de las instancias de Amazon EC2 de Windows](task-iam-roles.md#windows_task_IAM_roles). # Creación de una definición de tareas de Amazon ECS mediante la consola Cree una definición de tarea de forma que pueda definir la aplicación que se ejecuta como tarea o servicio. Al crear una definición de tarea para el tipo de lanzamiento externo, debe crear la definición de tarea mediante el editor JSON y establecer el parámetro `requireCapabilities` en `EXTERNAL`. Para crear una definición de tarea, utilice la consola o especifique un archivo JSON. Puede hacer que Amazon Q dé recomendaciones cuando utilice el editor JSON. Para obtener más información, consulte [Uso de Amazon Q Developer para proporcionar recomendaciones de la definición de tareas en la consola de Amazon ECS](using-amazon-q.md) ## Validación de JSON El editor JSON de la consola de Amazon ECS valida lo siguiente en el archivo JSON: + El archivo es un archivo JSON válido. + El archivo no contiene claves extrañas. + El archivo contiene el parámetro `familyName`. + Hay por lo menos una entrada en `containerDefinitions`. ## CloudFormationPilas de El siguiente comportamiento se aplica a las definiciones de tareas que se crearon en la nueva consola de Amazon ECS antes del 12 de enero de 2023. Al crear una definición de tareas, la consola de Amazon ECS crea automáticamente una pila de CloudFormation cuyo nombre comienza por `ECS-Console-V2-TaskDefinition-`. Si utilizó la AWS CLI o el AWS SDK para anular el registro de la definición de tareas, debe eliminar manualmente la pila de la definición de tareas. Para obtener más información, consulte [Elimina una pila](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html) en la *Guía del usuario de CloudFormation*. Para las definiciones de tareas creadas después del 12 de enero de 2023, no se crea automáticamente una pila de CloudFormation. ## Procedimiento ------ #### [ Amazon ECS console ] 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En el panel de navegación, elija **Task Definitions** (Definiciones de tareas). 1. En el menú **Crear una nueva definición de tarea**, elija **Crear una nueva definición de tarea**. 1. Para **Task definition family** (Familia de definiciones de tareas), especifique un nombre único para la definición de tareas. 1. En **Tipo de lanzamiento, elija el entorno de** la aplicación. El valor predeterminado de la consola es **AWS Fargate** (que es sin servidor). Amazon ECS utiliza este valor para la validación y garantizar que los parámetros de la definición de tareas sean válidos para el tipo de infraestructura. 1. Para **Operating system/Architecture** (Arquitectura y sistema operativo), elija el sistema operativo y la arquitectura de CPU para la tarea. Para ejecutar la tarea en una arquitectura ARM de 64 bits, elija **Linux/ARM64**. Para obtener más información, consulte [Plataforma de tiempo de ejecución](task_definition_parameters.md#runtime-platform). Para ejecutar sus tareas de **AWS Fargate** en contenedores de Windows, elija un sistema operativo compatible con Windows. Para obtener más información, consulte [Arquitecturas y sistemas operativos](fargate-tasks-services.md#fargate-task-os). 1. En **Task size** (Tamaño de tarea), elija los valores de CPU y memoria que desea reservar para la tarea. El valor de CPU se especifica como vCPU y la memoria se especifica como GB. Para las tareas alojadas en Fargate, en la siguiente tabla, se muestran las combinaciones de CPU y memoria válidas. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/create-task-definition.html) En el caso de las tareas que utilizan instancias de EC2, o instancias externas, los valores de CPU para tareas admitidos están comprendidos entre 128 unidades de CPU (0,125 vCPU) y 196 608 unidades de CPU (192 vCPU). Para indicar el valor de memoria en GB, ingrese **GB** después del valor. Por ejemplo, para establecer **Memory value** en 3 GB, ingrese **3GB**. **nota** Los parámetros de CPU y memoria de nivel de tarea se omiten para los contenedores de Windows. 1. Para **Network mode** (Modo de red), elija el modo de red que desea utilizar. El valor predeterminado es el modo **awsvpc**. Para obtener más información, consulte [redes de tareas de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html). Si elige **Puente**, en **Asignaciones de puertos**, para **Puerto del host**, ingrese el número de puerto en la instancia de contenedor que se debe reservar para el contenedor. 1. (Opcional) Amplíe la sección **Roles de tareas** para configurar los roles de AWS Identity and Access Management (IAM) de la tarea: 1. En **Task role** (Rol de la tarea), elija el rol de IAM para asignar a la tarea. Un rol de IAM de tarea proporciona permisos para los contenedores de una tarea para llamar a las operaciones de la API de AWS. 1. En **Rol de ejecución de tareas**, elija rol. Para obtener más información sobre cuándo utilizar el rol de ejecución de tareas, consulte [Rol de IAM de ejecución de tareas de Amazon ECS](task_execution_IAM_role.md). Si no necesita el rol, elija **Ninguno**. 1. (Opcional) Amplíe la sección **Ubicación de tareas** para agregar restricciones de ubicación. Las restricciones de ubicación de tareas permiten filtrar las instancias de contenedores utilizadas para la ubicación de las tareas mediante atributos integrados o personalizados. 1. (Opcional) Amplíe la sección **Inyección de errores** para habilitar la inyección de errores. La inyección de errores permite probar cómo la aplicación responde a determinados escenarios de deterioro. 1. Para definir a cada contenedor en su definición de tareas, siga los pasos que se describen a continuación. 1. En **Name** (Nombre), escriba un nombre para el contenedor. 1. En **Image URI** (URI de imagen), ingrese la imagen que se va a usar para iniciar un contenedor. Las imágenes del registro de Galería pública de Amazon ECR se pueden especificar solo mediante el uso del nombre de registro público de Amazon ECR. Por ejemplo, si se indica `public.ecr.aws/ecs/amazon-ecs-agent:latest`, se utiliza el contenedor de Amazon Linux alojado en Galería pública de Amazon ECR. Para todos los demás repositorios, indique el repositorio mediante los formatos `repository-url/image:tag` o `repository-url/image@digest`. 1. Si la imagen se encuentra en un registro privado ajeno a Amazon ECR, en **Registro privado**, active la **Autenticación del registro privado**. A continuación, en **nombre o ARN de Secrets Manager**, introduzca el nombre de recurso de Amazon (ARN) del secreto. 1. En **Contenedor esencial**, si la definición de tarea tiene dos o varios contenedores definidos, puede especificar si el contenedor debe considerarse esencial. Cuando un contenedor está marcado como **Esencial**, si se detiene, la tarea se detiene. Cada definición de tarea debe contener al menos un contenedor esencial. 1. Las asignaciones de puertos permiten a los contenedores acceder a puertos en el host para enviar o recibir tráfico. En **Port mappings** (Asignaciones de puertos), realice una de las siguientes operaciones: + Cuando usa el modo de red **awsvpc**, en **Container port** (Puerto del contenedor) y **Protocol** (Protocolo), elija la asignación de puertos que se va a usar para el contenedor. + Cuando usa el modo de red **bridge** (puente), en **Container port** (Puerto del contenedor) y **Protocol** (Protocolo), elija la asignación de puertos que se va a usar para el contenedor. Elija **Add more port mappings** (Agregar más asignaciones de puertos) para especificar asignaciones de puertos de contenedores adicionales. 1. Para conceder al contenedor acceso de solo lectura a su sistema de archivos raíz, en **Sistema de archivos raíz de solo lectura**, seleccione **Solo lectura**. 1. (Opcional) Para definir los límites de CPU, GPU y memoria a nivel de contenedor que sean diferentes de los valores a nivel de tarea incluidos en **Resource allocation limits**, haga lo siguiente: + En **CPU**, ingrese el número de unidades de CPU que el agente de contenedor de Amazon ECS reserva para el contenedor. + En **GPU**, ingrese el número de unidades de GPU para la instancia de contenedor. Una instancia de Amazon EC2 compatible con GPU tiene 1 unidad de GPU por cada GPU. Para obtener más información, consulte [Definiciones de tareas de Amazon ECS para cargas de trabajo de GPU](ecs-gpu.md). + En **Límite estricto de memoria**, ingrese la cantidad de memoria, en GB, para presentarla al contenedor. Si el contenedor intenta superar el límite duro, se cancela el contenedor. + El daemon de Docker 20.10.0 o posterior reserva un mínimo de 6 mebibytes (MiB) de memoria para un contenedor, por tanto no indique menos de 6 MiB de memoria para los contenedores. El daemon de Docker 19.03.13-ce o anterior reserva un mínimo de 4 MiB de memoria para un contenedor, por tanto no indique menos de 4 MiB de memoria para los contenedores. + En **Límite flexible de memoria**, ingrese el límite flexible (en GB) de memoria que reservar para el contenedor. Cuando la memoria del sistema está en conflicto, Docker intenta mantener la memoria del contenedor en este límite flexible. Si no especifica memoria de nivel de tarea, debe especificar un entero distinto de cero para el **Límite duro de memoria** y el **Límite flexible de memoria**, o para ambos. Si especifica ambos, el **Límite duro de memoria** debe ser mayor que el **Límite flexible de memoria**. Esta característica no es compatible con los contenedores de Windows. 1. (Opcional) Expanda la sección **Variables de entorno** para especificar variables de entorno que se van a inyectar en el contenedor. Puede indicar variables de entorno individualmente mediante pares clave-valor o de forma masiva si indica un archivo de variable de entorno alojado en un bucket de Amazon S3. Para obtener información sobre cómo dar formato a un archivo de variable de entorno, consulte [Transferencia de una variable de entorno individual a un contenedor de Amazon ECS](taskdef-envfiles.md). Cuando especifique una variable de entorno para el almacenamiento de secretos, en **Clave**, ingrese el nombre del secreto. A continuación, en **ValueFrom**, indique el ARN completo del secreto de Almacén de parámetros de Systems Manager o del secreto de Secrets Manager. 1. (Opcional) Seleccione la opción **Use log collection** (Utilizar colección de registros) para especificar una configuración de registro. Para cada controlador de registro disponible, hay opciones de controladores de registro que se deben especificar. La opción predeterminada envía registros de contenedor a Registros de Amazon CloudWatch. Las demás opciones del controlador de registros se configuran mediante AWS FireLens. Para obtener más información, consulte [Envío de registros de Amazon ECS a un servicio de AWS o AWS Partner](using_firelens.md). A continuación, se describe con más detalle cada uno de los destinos de registro de contenedor. + **Amazon CloudWatch**: configure la tarea para enviar registros de contenedor a CloudWatch Logs. Se proporcionan las opciones de controlador de registro predeterminadas que crean un grupo de registros de CloudWatch en su nombre. Para especificar otro nombre de grupo de registros, cambie los valores de las opciones del controlador. + **Exportar registros a Splunk**: configure la tarea para enviar los registros del contenedor al controlador de Splunk que envía los registros a un servicio remoto. Debe ingresar la URL del servicio web de Splunk. El token de Splunk se indica como una opción secreta, ya que puede tratarse como información confidencial. + **Exportar registros a Amazon Data Firehose**: configure la tarea para enviar registros de contenedor a Firehose. Se proporcionan las opciones de controlador de registro predeterminadas, que envían registros a un flujo de entrega de Firehose. Para especificar un nombre de flujo de entrega distinto, cambie los valores de las opciones del controlador. + **Exportar registros a Amazon Kinesis Data Streams**: configure la tarea para enviar registros de contenedores a Kinesis Data Streams. Se proporcionan las opciones de controlador de registro predeterminadas que envían registros a un flujo de Kinesis Data Streams. Para especificar otro nombre de transmisión, cambie los valores de las opciones del controlador. + **Exportar registros a Amazon OpenSearch Service**: configure la tarea para enviar registros de contenedor a un dominio de OpenSearch Service. Se deben proporcionar las opciones del controlador de registros. + **Exportar registros a Amazon S3**: configure la tarea para enviar registros de contenedor a un bucket de Amazon S3. Se proporcionan las opciones de controlador de registro predeterminadas, pero debe especificar un nombre de bucket de Amazon S3 válido. 1. (Opcional) Configure parámetros de contenedor adicionales. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/create-task-definition.html) 1. (Opcional) Elija **Add more containers** (Agregar más contenedores) para agregar contenedores adicionales a la definición de tareas. 1. (Opcional) La sección **Almacenamiento** se utiliza para ampliar la cantidad de almacenamiento efímero de las tareas alojadas en Fargate. También puede utilizar esta sección para agregar una configuración de volumen de datos para la tarea. 1. Para ampliar el almacenamiento efímero disponible más allá del valor predeterminado de 20 gibibytes (GiB) para las tareas de Fargate, en **Amount** (Cantidad), ingrese un valor de hasta 200 GiB. 1. (Opcional) Para agregar una configuración de volumen de datos para la definición de tareas, elija **Agregar volumen** y, a continuación, siga estos pasos. 1. En **Volume name** (Nombre del volumen), ingrese un nombre para el volumen de datos. El nombre del volumen de datos se utiliza al crear un punto de montaje de contenedor. 1. En **Configuración de volumen**, seleccione si quiere configurar el volumen al crear la definición de la tarea o durante la implementación. **nota** Entre los volúmenes que se pueden configurar al crear una definición de tareas se incluyen Montaje de enlace, Docker, Amazon EFS y Amazon FSx para Windows File Server. Entre los volúmenes que se pueden configurar en el momento de la implementación, al ejecutar una tarea o al crear o actualizar un servicio, se incluye Amazon EBS. 1. En **Tipo de volumen**, seleccione un tipo de volumen compatible con el tipo de configuración que seleccionó y, luego, configure el tipo de volumen. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/create-task-definition.html) 1. Para agregar un volumen desde otro contenedor, seleccione **Agregar volumen desde** y, a continuación, configure lo siguiente: + En **Contenedor**, elija el contenedor. + En **Origen**, elija el contenedor que tiene el volumen que desea montar. + En **Solo lectura**, seleccione si el contenedor tiene acceso de solo lectura al volumen. 1. (Opcional) Para configurar los valores de seguimiento y recopilación de métricas de la aplicación mediante la integración de AWS Distro for OpenTelemetry, expanda **Supervisión** y, luego, seleccione **Utilizar recopilación de métricas** para recopilar y enviar las métricas de las tareas a Amazon CloudWatch o Amazon Managed Service para Prometheus. Cuando se selecciona esta opción, Amazon ECS crea un sidecar de contenedor de AWS Distro for OpenTelemetry que está preconfigurado para enviar las métricas de la aplicación. Para obtener más información, consulte [Correlacionar el rendimiento de las aplicaciones de Amazon ECS mediante métricas de aplicaciones](metrics-data.md). 1. Cuando se selecciona **Amazon CloudWatch**, las métricas de aplicaciones personalizadas se enrutan a CloudWatch como métricas personalizadas. Para obtener más información, consulte [Exportación de métricas de aplicaciones a Amazon CloudWatch](application-metrics-cloudwatch.md). **importante** Al exportar métricas de aplicaciones a Amazon CloudWatch, la definición de tarea requiere un rol de IAM de tarea con los permisos necesarios. Para obtener más información, consulte [Permisos de IAM necesarios para la integración de AWS Distro for OpenTelemetry Amazon CloudWatch](application-metrics-cloudwatch.md#application-metrics-cloudwatch-iam). 1. Cuando se selecciona **Amazon Managed Service for Prometheus (Prometheus libraries instrumentation)** (Amazon Managed Service for Prometheus [instrumentación de bibliotecas Prometheus]), las métricas de CPU, memoria, red y almacenamiento de nivel de tarea y las métricas de aplicaciones personalizadas se enrutan a Amazon Managed Service for Prometheus. En **Punto de enlace de escritura remota del espacio del espacio de trabajo**, ingrese la URL de punto de conexión de escritura remota del espacio de trabajo de Prometheus. En **Destino de raspado**, ingrese el host y el puerto que el recopilador de AWS Distro for OpenTelemetry puede utilizar para extraer los datos de métricas. Para obtener más información, consulte [Exportación de métricas de aplicaciones a Amazon Managed Service for Prometheus](application-metrics-prometheus.md). **importante** Al exportar métricas de aplicaciones a Amazon Managed Service for Prometheus, la definición de tarea requiere un rol de IAM de tarea con los permisos necesarios. Para obtener más información, consulte [Permisos de IAM necesarios para la integración de AWS Distro for OpenTelemetry con Amazon Managed Service for Prometheus](application-metrics-prometheus.md#application-metrics-prometheus-iam). 1. Cuando selecciona **Amazon Managed Service para Prometheus (instrumentación de OpenTelemetry)**, las métricas de CPU, memoria, red y almacenamiento de nivel de tarea y las métricas de aplicaciones personalizadas se dirigen a Amazon Managed Service para Prometheus. En **Punto de enlace de escritura remota del espacio del espacio de trabajo**, ingrese la URL de punto de conexión de escritura remota del espacio de trabajo de Prometheus. Para obtener más información, consulte [Exportación de métricas de aplicaciones a Amazon Managed Service for Prometheus](application-metrics-prometheus.md). **importante** Al exportar métricas de aplicaciones a Amazon Managed Service for Prometheus, la definición de tarea requiere un rol de IAM de tarea con los permisos necesarios. Para obtener más información, consulte [Permisos de IAM necesarios para la integración de AWS Distro for OpenTelemetry con Amazon Managed Service for Prometheus](application-metrics-prometheus.md#application-metrics-prometheus-iam). 1. (Opcional) Expanda la sección **Tags** (Etiquetas) para agregar etiquetas, como pares clave-valor, a la definición de tarea. + [Agregar una etiqueta] Seleccione **Add tag** (Agregar etiqueta), y, a continuación, haga lo siguiente: + En **Clave**, escriba el nombre de la clave. + En **Valor**, escriba el valor de la clave. + [Eliminar una etiqueta] Junto a la etiqueta, elija **Remove tag (Quitar etiqueta)**. 1. Elija **Crear** para registrar la definición de tarea. ------ #### [ Amazon ECS console JSON editor ] 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En el panel de navegación, elija **Task Definitions** (Definiciones de tareas). 1. Elija **Crear una nueva definición de tarea** y **Crear una nueva definición de tarea con JSON**. 1. En el cuadro del editor de JSON, edite su archivo JSON, El JSON debe pasar las comprobaciones de validación especificadas en [Validación de JSON](#json-validate-for-create). 1. Seleccione **Crear**. ------ # Uso de Amazon Q Developer para proporcionar recomendaciones de la definición de tareas en la consola de Amazon ECS Al utilizar el editor JSON de la consola de Amazon ECS para crear una definición de tareas, puede utilizar Amazon Q Developer para proporcionar sugerencias de código generadas por IA para las definiciones de tareas. Puede utilizar la funcionalidad de chat insertada para pedirle a Amazon Q Developer que genere, explique o refactorice el JSON de definición de tareas con una interfaz conversacional. Puede introducir las sugerencias generadas en cualquier punto de la definición de la tarea y aceptar o rechazar los cambios propuestos. Amazon ECS también ha mejorado la característica de sugerencias insertada existente para utilizar Amazon Q Developer. Al crear una definición de tarea con el editor JSON, puede pedir a Amazon Q Developer que le dé recomendaciones para crear una definición de tarea de manera más rápida. Puede tener sugerencias insertadas basadas en propiedades o utilizar las sugerencias de Amazon Q Developer para completar automáticamente bloques enteros de código de muestra. Puedes utilizar esta característica en las regiones en las que se admite Amazon Q Developer. Para obtener más información, consulte [AWS Services by Regions](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/). ## Requisitos previos A continuación, se indican los requisitos previos: + Además de los permisos de la consola, el usuario que cree la definición de tareas en la consola debe tener el permiso `codewhisperer:GenerateRecommendations` para hacer recomendaciones y `q:SendMessage`para utilizar el chat insertado. Para obtener más información, consulte [Permisos necesarios para utilizar Amazon Q Developer a fin de ofrecer recomendaciones en la consola](console-permissions.md#amazon-q-permission). ## Procedimiento 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En el panel de navegación, elija **Task Definitions** (Definiciones de tareas). 1. Elija **Crear una nueva definición de tarea** y **Crear una nueva definición de tarea con JSON**. Se abre la página **Crear definición de tarea**. La consola proporciona la plantilla predeterminada siguiente. ``` { "requiresCompatibilities": [ "FARGATE" ], "family": "", "containerDefinitions": [ { "name": "", "image": "", "essential": true } ], "volumes": [], "networkMode": "awsvpc", "memory": "3 GB", "cpu": "1 vCPU", "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole" } ``` 1. En el elemento emergente de sugerencias insertadas de Amazon Q, elija **Permitir**. Si cierra el elemento emergente, puede activar Amazon Q en el icono del engranaje. 1. En el cuadro del editor de JSON, edite el documento JSON. Para que Amazon Q cree y complete los parámetros, escriba un comentario con lo que quiera agregar. En el siguiente ejemplo, el comentario hace que Amazon Q genere las líneas en negrita. ``` { "requiresCompatibilities": [ "FARGATE" ], "family": "", "containerDefinitions": [ { "name": "", "image": "", "essential": true }, // add an nginx container using an image from Public ECR, with port 80 open, and send logs to CloudWatch log group "myproxy" { "name": "nginx", "image": "public.ecr.aws/nginx/nginx:latest", "essential": true, "portMappings": [ { "containerPort": 80, "hostPort": 80, "protocol": "tcp" } ], "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-group": "myproxy", "awslogs-region": "us-east-1", "awslogs-stream-prefix": "nginx" } } } ], "volumes": [], "networkMode": "awsvpc", "memory": "3 GB", "cpu": "1 vCPU", "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole" } ``` 1. Para utilizar la característica de chat insertado, puede resaltar las líneas y, a continuación, elegir el icono de estrella. Aparece el cuadro de chat de Amazon Q Developer. Escriba la solicitud. Amazon Q Developer genera y, a continuación, actualiza el JSON. Para aceptar los cambios, elija **Aceptar todo** 1. Seleccione **Crear**. # Actualización de una definición de tareas de Amazon ECS mediante la consola Una *revisión de definición de tareas* es una copia de la definición de tarea actual con los nuevos valores de parámetro que sustituyen a los existentes. Todos los parámetros que no modifica se encuentran en la nueva revisión. Para actualizar una definición de tarea, cree una revisión de definición de tarea. Si la definición de tarea se utiliza en un servicio, debe actualizar ese servicio para usar la definición de tarea actualizada. Al crear una revisión, puede modificar las siguientes propiedades de contenedor y de entorno. + ID de imagen de contenedor + Mapeos de puertos + Variables de entorno + Requisitos de infraestructura + Tamaño de tarea + Tamaño del contenedor + Rol de de la tarea + Rol de ejecución de tareas + Volúmenes y puntos de montaje de contenedores + Registro privado Puede hacer que Amazon Q dé recomendaciones cuando utilice el editor JSON. Para obtener más información, consulte [Uso de Amazon Q Developer para proporcionar recomendaciones de la definición de tareas en la consola de Amazon ECS](using-amazon-q.md) ## Validación de JSON El editor JSON de la consola de Amazon ECS valida lo siguiente en el archivo JSON: + El archivo es un archivo JSON válido + El archivo no contiene claves extrañas + El archivo contiene el parámetro `familyName` + Hay por lo menos una entrada en `containerDefinitions` ## Procedimiento ------ #### [ Amazon ECS console ] 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En la barra de navegación, seleccione la Región que contiene la definición de tarea. 1. En el panel de navegación, elija **Task Definitions** (Definiciones de tareas). 1. Elija la definición de tareas. 1. Seleccione la revisión de las definiciones de tareas y, a continuación, elija **Crear nueva revisión** y **Crear nueva revisión**. 1. En la página **Create new task definition revision** (Crear nueva revisión de definición de tarea), realice cambios. Por ejemplo, para cambiar las definiciones de contenedor existentes (como la imagen de contenedor, los límites de memoria, o las asignaciones de puertos), seleccione el contenedor, realice los cambios. Puede actualizar la compatibilidad de las definiciones de tareas a una de las instancias de **AWS Fargate**, **Managed Instances** o **Amazon EC2**. 1. Verifique la información y, luego, seleccione **Actualizar**. 1. Si la definición de tarea se utiliza en un servicio, actualice su servicio con la definición de tarea actualizada. Para obtener más información, consulte [Actualización de un servicio de Amazon ECS](update-service-console-v2.md). ------ #### [ Amazon ECS console JSON editor ] 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En el panel de navegación, elija **Task Definitions** (Definiciones de tareas). 1. Elija **Create new revision** (Crear nueva revisión) y **Create new revision with JSON** (Crear nueva revisión con JSON). 1. En el cuadro del editor de JSON, edite su archivo JSON, El JSON debe pasar las comprobaciones de validación especificadas en [Validación de JSON](#json-validate-for-update). 1. Seleccione **Crear**. ------ # Anulación del registro de la revisión de una definición de tareas de Amazon ECS mediante la consola Puede anular el registro de la revisión de la definición de la tarea para que ya no se muestre en las llamadas a la API de `ListTaskDefinition` ni en la consola cuando quiera ejecutar una tarea o actualizar un servicio. Cuando se cancela el registro de una revisión de definición de tarea, se marca de inmediato como `INACTIVE`. Las tareas y servicios existentes que hacen referencia a una revisión de la definición de tarea `INACTIVE` continúan ejecutándose sin interrupciones. Para ajustar la escala de los servicios existentes que hacen referencia a una revisión de la definición de tarea `INACTIVE`, puede modificar el recuento deseado del servicio. No se puede utilizar una revisión de la definición de tarea `INACTIVE` para ejecutar nuevas tareas ni crear nuevos servicios. Tampoco se puede actualizar un servicio existente para hacer referencia a una revisión de la definición de tarea `INACTIVE` (aunque podría haber una ventana de hasta 10 minutos después de la anulación del registro en la que estas restricciones aún no hayan surtido efecto). **nota** Cuando se anulan los registros de todas las revisiones de una familia de tareas, la familia de definición de tareas se traslada a la lista `INACTIVE`. Al agregar una nueva revisión de una definición de tarea `INACTIVE`, la familia de definiciones de tareas vuelve a aparecer en la lista `ACTIVE`. En este momento, las revisiones de la definición de tarea `INACTIVE` permanecen visibles en su cuenta indefinidamente. Sin embargo, este comportamiento está sujeto a cambio en el futuro. Por lo tanto, no debe confiar en que las revisiones de la definición de tarea `INACTIVE` persistan más allá del ciclo de vida de las tareas y servicios asociados. ## CloudFormationPilas de El siguiente comportamiento se aplica a las definiciones de tareas que se crearon en la nueva consola de Amazon ECS antes del 12 de enero de 2023. Al crear una definición de tareas, la consola de Amazon ECS crea automáticamente una pila de CloudFormation cuyo nombre comienza por `ECS-Console-V2-TaskDefinition-`. Si utilizó la AWS CLI o el AWS SDK para anular el registro de la definición de tareas, debe eliminar manualmente la pila de la definición de tareas. Para obtener más información, consulte [Elimina una pila](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html) en la *Guía del usuario de CloudFormation*. Para las definiciones de tareas creadas después del 12 de enero de 2023, no se crea automáticamente una pila de CloudFormation. ## Procedimiento **Para anular el registro de una nueva definición de tareas (consola de Amazon ECS)** 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En la barra de navegación, seleccione la región que contiene la definición de tarea. 1. En el panel de navegación, elija **Task Definitions** (Definiciones de tareas). 1. En la página **Task Definitions** (Definiciones de tareas), elija la familia de definiciones de tareas que contiene una o más revisiones para las que desea anular el registro. 1. En la página **Nombre de la definición de tarea**, seleccione las revisiones que desee eliminar y, a continuación, elija **Acciones**, **Anular registro**. 1. Verifique la información en la ventana **Deregister** (Anular registro) y elija **Deregister** (Anular registro) para finalizar. # Eliminación de una revisión de definición de tareas de Amazon ECS con la consola Cuando ya no necesite una revisión de definición de tarea específica en Amazon ECS, puede eliminarla. Cuando se elimina una revisión de definición de tareas, de inmediato pasa del estado `INACTIVE` al `DELETE_IN_PROGRESS`. Las tareas y los servicios existentes que hacen referencia a una revisión de definición de tareas en estado `DELETE_IN_PROGRESS` continúan ejecutándose sin interrupciones. No se puede utilizar una revisión de definición de tareas en estado `DELETE_IN_PROGRESS` para ejecutar nuevas tareas ni crear nuevos servicios. Tampoco se puede actualizar un servicio existente para hacer referencia a una revisión de definición de tareas en estado `DELETE_IN_PROGRESS`. Al eliminar todas las revisiones de la definición de tareas `INACTIVE`, el nombre de la definición de tareas no se muestra en la consola ni se devuelve en la API. Si una revisión de definición de tareas tiene el estado `DELETE_IN_PROGRESS`, el nombre de la definición de tareas se muestra en la consola y se devuelve en la API. Amazon ECS retiene el nombre de la definición de tarea y la revisión se incrementa la próxima vez que cree una definición de tarea con ese nombre. ## Recursos de Amazon ECS que pueden bloquear una eliminación Una solicitud de eliminación de definición de tareas no se completará cuando haya recursos de Amazon ECS que dependan de la revisión de la definición de tareas. Los siguientes recursos pueden impedir que se elimine una definición de tareas: + Tareas independientes de Amazon ECS: la definición de la tarea es necesaria para que la tarea se mantenga en buen estado. + Tareas de servicio de Amazon ECS: la definición de la tarea es necesaria para que la tarea se mantenga en buen estado. + Implementaciones de servicio y conjuntos de tareas de Amazon ECS: la definición de la tarea es necesaria cuando se inicia un evento de escalado para una implementación o conjunto de tareas de Amazon ECS. Si la definición de la tarea permanece en el estado `DELETE_IN_PROGRESS`, puede utilizar la consola o la AWS CLI para identificar y, a continuación, detener los recursos que bloquean la eliminación de la definición de la tarea. ### Eliminación de la definición de tareas después de eliminar el recurso bloqueado Las siguientes reglas se aplican después de eliminar los recursos que bloquean la eliminación de la definición de tarea: + Tareas de Amazon ECS: la eliminación de la definición de tareas puede tardar hasta 1 hora en completarse una vez detenida la tarea. + Implementaciones de servicio y conjuntos de tareas de Amazon ECS: la eliminación de la definición de tareas puede tardar hasta 24 horas en completarse una vez que se haya eliminado la implementación o el conjunto de tareas. ## Procedimiento **Para eliminar definiciones de tareas (consola de Amazon ECS)** Debe anular el registro de la revisión de la definición de tareas antes de eliminarla. Para obtener más información, consulte [Anulación del registro de la revisión de una definición de tareas de Amazon ECS mediante la consola](deregister-task-definition-v2.md). 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En la barra de navegación, seleccione la región que contiene la definición de tarea. 1. En el panel de navegación, elija **Task Definitions** (Definiciones de tareas). 1. En la página **Definiciones de tareas**, elija la familia de definiciones de tareas que contenga una o más revisiones que desee eliminar. 1. En la página **Nombre de la definición de tarea**, seleccione las revisiones que quiere eliminar y, a continuación, elija **Acciones**, **Eliminar**. Si la opción **Eliminar** no está disponible, debe anular el registro de la definición de tarea. 1. Compruebe la información en el cuadro de confirmación **Eliminar** y, luego, elija **Eliminar** para finalizar. # Casos de uso de definiciones de tareas de Amazon ECS Obtenga más información sobre cómo escribir definiciones de tareas para varios servicios y características de AWS. En función de la carga de trabajo, hay parámetros determinados de la definición de tareas que deben configurarse. Además para EC2, debe elegir instancias específicas que están diseñadas para la carga de trabajo. **Topics** + [Definiciones de tareas de Amazon ECS para cargas de trabajo de GPU](ecs-gpu.md) + [Definiciones de tareas de Amazon ECS para cargas de trabajo de transcodificación de video](ecs-vt1.md) + [Definiciones de tareas de Amazon ECS para cargas de trabajo de machine learning de AWS Neuron](ecs-inference.md) + [Definiciones de tareas de Amazon ECS para instancias de aprendizaje profundo](ecs-dl1.md) + [Definiciones de tareas de Amazon ECS para cargas de trabajo de ARM de 64 bits](ecs-arm64.md) + [Envío de registros de Amazon ECS a CloudWatch](using_awslogs.md) + [Envío de registros de Amazon ECS a un servicio de AWS o AWS Partner](using_firelens.md) + [Uso de imágenes de contenedor que no sean de AWS en Amazon ECS](private-auth.md) + [Reinicio de contenedores individuales en tareas de Amazon ECS con políticas de reinicio de contenedores](container-restart-policy.md) + [Transferencia de datos confidenciales a un contenedor de Amazon ECS](specifying-sensitive-data.md) # Definiciones de tareas de Amazon ECS para cargas de trabajo de GPU Amazon ECS admite cargas de trabajo que utilizan unidades GPU cuando se crean clústeres con instancias de contenedor que admiten GPU. Las instancias de contenedor de Amazon EC2 basadas en GPU que utilizan los tipos de instancia p2, p3, p5, g3, g4 y g5 proporcionan acceso a las GPU NVIDIA. Para obtener más información, consulte [Instancias de computación acelerada de Linux](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html) en la *Guía de tipos de instancias de Amazon EC2*. Amazon ECS proporciona una AMI optimizada para GPU que está preconfigurada con controladores de kernel de NVIDIA y un tiempo de ejecución de GPU de Docker. Para obtener más información, consulte [AMI de Linux optimizadas para Amazon ECS](ecs-optimized_AMI.md). Puede designar un número de GPU en su definición de tareas para la ubicación de tareas en el nivel de contenedor. Amazon ECS programa las tareas de acuerdo con las instancias de contenedor que admiten GPU disponibles y fija las GPU físicas en los contenedores correspondientes para conseguir un rendimiento óptimo. Se admiten los siguientes tipos de instancias de Amazon EC2 basadas en GPU. Para obtener más información, consulte [Instancias P2 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/p2/), [Instancias P3 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/p3/), [Instancias P4d de Amazon EC2](https://aws.amazon.com/ec2/instance-types/p4/), [Instancias P5 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/p5/), [Instancias G3 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/g3/), [Instancias G4 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/g4/), [Instancias G5 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/g5/), [Instancias G6 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/g6/) e [Instancias G6e de Amazon EC2](https://aws.amazon.com/ec2/instance-types/g6e/). | Tipo de instancia | GPU | Memoria de GPU (GiB) | vCPU | Memoria (GiB) | | --- | --- | --- | --- | --- | | p3.2xlarge | 1 | 16 | 8 | 61 | | p3.8xlarge | 4 | 64 | 32 | 244 | | p3.16xlarge | 8 | 128 | 64 | 488 | | p3dn.24xlarge | 8 | 256 | 96 | 768 | | p4d.24xlarge | 8 | 320 | 96 | 1152 | | p5.48xlarge | 8 | 640 | 192 | 2048 | | g3s.xlarge | 1 | 8 | 4 | 30,5 | | g3.4xlarge | 1 | 8 | 16 | 122 | | g3.8xlarge | 2 | 16 | 32 | 244 | | g3.16xlarge | 4 | 32 | 64 | 488 | | g4dn.xlarge | 1 | 16 | 4 | 16 | | g4dn.2xlarge | 1 | 16 | 8 | 32 | | g4dn.4xlarge | 1 | 16 | 16 | 64 | | g4dn.8xlarge | 1 | 16 | 32 | 128 | | g4dn.12xlarge | 4 | 64 | 48 | 192 | | g4dn.16xlarge | 1 | 16 | 64 | 256 | | g5.xlarge | 1 | 24 | 4 | 16 | | g5.2xlarge | 1 | 24 | 8 | 32 | | g5.4xlarge | 1 | 24 | 16 | 64 | | g5.8xlarge | 1 | 24 | 32 | 128 | | g5.16xlarge | 1 | 24 | 64 | 256 | | g5.12xlarge | 4 | 96 | 48 | 192 | | g5.24xlarge | 4 | 96 | 96 | 384 | | g5.48xlarge | 8 | 192 | 192 | 768 | | g6.xlarge | 1 | 24 | 4 | 16 | | g6.2xlarge | 1 | 24 | 8 | 32 | | g6.4xlarge | 1 | 24 | 16 | 64 | | g6.8xlarge | 1 | 24 | 32 | 128 | | g6.16.xlarge | 1 | 24 | 64 | 256 | | g6.12xlarge | 4 | 96 | 48 | 192 | | g6.24xlarge | 4 | 96 | 96 | 384 | | g6.48xlarge | 8 | 192 | 192 | 768 | | g6.metal | 8 | 192 | 192 | 768 | | gr6.4xlarge | 1 | 24 | 16 | 128 | | g6e.xlarge | 1 | 48 | 4 | 32 | | g6e.2xlarge | 1 | 48 | 8 | 64 | | g6e.4xlarge | 1 | 48 | 16 | 128 | | g6g.8xlarge | 1 | 48 | 32 | 256 | | g6e16.xlarge | 1 | 48 | 64 | 512 | | g6e12.xlarge | 4 | 192 | 48 | 384 | | g6e24.xlarge | 4 | 192 | 96 | 768 | | g6e48.xlarge | 8 | 384 | 192 | 1536 | | gr6.8xlarge | 1 | 24 | 32 | 256 | Puede recuperar el ID de Imagen de máquina de Amazon (AMI) de las AMI optimizadas para Amazon ECS al consultar la API de Parameter Store de AWS Systems Manager. Al utilizar este parámetro, no necesita buscar de manera manual los ID de la AMI optimizada para Amazon ECS. Para obtener más información acerca de la API de Systems Manager Parameter Store, consulte [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). El usuario que utiliza debe tener el permiso de IAM `ssm:GetParameter` para recuperar los metadatos de la AMI optimizada para Amazon ECS. ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1 ``` # Uso de GPU con instancias administradas de Amazon ECS Instancias administradas de Amazon ECS admite la computación acelerada por GPU para las cargas de trabajo como el machine learning, la computación de alto rendimiento y el procesamiento de video a través de los tipos de instancias de Amazon EC2 siguientes. Para obtener más información acerca de los tipos de instancias compatibles con instancias administradas de Amazon ECS, consulte [Tipos de instancias de instancias administradas de Amazon ECS](managed-instances-instance-types.md). A continuación, se muestra un subconjunto de tipos de instancias basadas en GPU compatibles con instancias administradas de Amazon ECS: + `g4dn`: con tecnología de NVIDIA T4 GPUs, adecuado para aplicaciones de machine learning, inferencia, visión artificial y uso intensivo de gráficos. + `g5`: con tecnología de NVIDIA A10G GPUs, ofrece un mayor rendimiento para las aplicaciones con uso intensivo de gráficos y cargas de trabajo de machine learning. + `p3`: con tecnología de NVIDIA V100 GPUs, diseñado la computación de alto rendimiento y el entrenamiento de aprendizaje profundo. + `p4d`: con tecnología de NVIDIA A100 GPUs, ofrece el más alto rendimiento para el entrenamiento de machine learning y la computación de alto rendimiento. Cuando utiliza tipos de instancias habilitadas para GPU con instancias administradas de Amazon ECS, los controladores de NVIDIA y el kit de herramientas de CUDA vienen preinstalados en la instancia, lo que facilita la puesta en marcha de cargas de trabajo aceleradas por GPU. ## Selección de instancias habilitadas para GPU Para seleccionar tipos de instancias habilitadas para GPU para las cargas de trabajo de instancias administradas de Amazon ECS, utilice el objeto `instanceRequirements` de la plantilla de lanzamiento del proveedor de capacidad. En el siguiente fragmento se muestran los atributos que se pueden usar para seleccionar instancias habilitadas para GPU. ``` { "instanceRequirements": { "acceleratorTypes": "gpu", "acceleratorCount": 1, "acceleratorManufacturers": ["nvidia"] } } ``` En el siguiente fragmento se muestran los atributos que se pueden utilizar para especificar los tipos de instancias habilitadas para la GPU en la plantilla de lanzamiento. ``` { "instanceRequirements": { "allowedInstanceTypes": ["g4dn.xlarge", "p4de.24xlarge"] } } ``` ## Imágenes de contenedores habilitadas para GPU Para utilizar las GPU en los contenedores, debe utilizar imágenes de contenedor que contengan las bibliotecas y herramientas de GPU necesarias. NVIDIA proporciona varias imágenes de contenedor prediseñadas que puede utilizar como base para las cargas de trabajo de GPU, incluidas las siguientes: + `nvidia:cuda`: imágenes base con el kit de herramientas de CUDA para la computación mediante GPU. + `tensorflow/tensorflow:latest-gpu`: TensorFlow con compatibilidad con GPU. + `pytorch/pytorch:latest-cuda`: PyTorch con compatibilidad con GPU. Para ver un ejemplo de definición de tareas para Amazon ECS en instancias administradas de Amazon ECS que implique el uso de GPU, consulte [Especificación de GPU en una definición de tareas de Amazon ECS](ecs-gpu-specifying.md). ## Consideraciones **nota** La compatibilidad con el tipo de familia de instancias g2 ha quedado obsoleta. El tipo de familia de instancias p2 es compatible solo con versiones anteriores a `20230912` de la AMI de Amazon ECS optimizada para GPU. Si necesita seguir usando instancias p2, consulte [Qué hacer si necesita una instancia P2](#p2-instance). Las actualizaciones locales de los controladores NVIDIA/CUDA en estos dos tipos de familia de instancias pueden provocar posibles errores en la carga de trabajo de la GPU. Le recomendamos que tenga en cuenta lo siguiente antes de comenzar a trabajar con GPU en Amazon ECS. + Sus clústeres pueden contener una combinación de instancias de contenedor habilitadas para GPU y no habilitadas para GPU. + Puede ejecutar cargas de trabajo de GPU en instancias externas. Cuando se registra una instancia externa en el clúster, asegúrese de que la marca `--enable-gpu` se incluya en el script de instalación. Para obtener más información, consulte [Registro de una instancia externa en un clúster de Amazon ECS](ecs-anywhere-registration.md). + Debe establecer `ECS_ENABLE_GPU_SUPPORT` en `true` en el archivo de configuración del agente. Para obtener más información, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md). + Cuando ejecuta una tarea o crea un servicio, puede utilizar los atributos de tipo de instancia al configurar las restricciones de colocación de tareas para determinar las instancias de contenedor que se lanzan en la tarea. Esto le permite utilizar sus recursos de manera más eficiente. Para obtener más información, consulte [Cómo coloca Amazon ECS las tareas en las instancias de contenedor](task-placement.md). El siguiente ejemplo lanza una tarea en una instancia de contenedor `g4dn.xlarge` en el clúster predeterminado. ``` aws ecs run-task --cluster default --task-definition ecs-gpu-task-def \ --placement-constraints type=memberOf,expression="attribute:ecs.instance-type == g4dn.xlarge" --region us-east-2 ``` + Para cada contenedor que tiene un requisito de recursos de GPU especificado en la definición de contenedor, Amazon ECS establece el tiempo de ejecución del contenedor en el tiempo de ejecución del contenedor de NVIDIA. + Para que el tiempo de ejecución del contenedor NVIDIA funcione correctamente, es preciso establecer algunas variables de entorno en el contenedor. Para obtener una lista de estas variables de entorno, consulte [Specialized Configurations with Docker](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html?highlight=environment%20variable). Amazon ECS establece el valor de las variables de entorno `NVIDIA_VISIBLE_DEVICES` en una lista de los ID de dispositivo de GPU que Amazon ECS asigna al contenedor. Amazon ECS no establece las demás variables de entorno necesarias. Por tanto, asegúrese de que la imagen del contenedor las establezca o que estén configuradas en la definición de contenedor. + La familia del tipo de instancias p5 es compatible con la versión `20230929` y versiones posteriores de la AMI de Amazon ECS optimizada para GPU. + La familia de tipo de instancias g4 es compatible con la versión `20230913` y versiones posteriores de la AMI de Amazon ECS optimizada para GPU. Para obtener más información, consulte [AMI de Linux optimizadas para Amazon ECS](ecs-optimized_AMI.md). No es admitido en el flujo de trabajo de Create Cluster (Crear clúster) en la consola de Amazon ECS. Para utilizar estos tipos de instancias, debe utilizar la consola de Amazon EC2, la AWS CLI o la API, y registrar manualmente las instancias en el clúster. + El tipo de instancias p4d.24xlarge solo funciona con CUDA 11 o posterior. + La AMI de Amazon ECS optimizada para GPU está habilitada para IPv6, lo que provoca problemas cuando se utiliza `yum`. Para resolverlo, puede configurar que `yum` utilice IPv4 con el siguiente comando. ``` echo "ip_resolve=4" >> /etc/yum.conf ``` + Cuando crea una imagen de contenedor que no utiliza las imágenes base NVIDIA/CUDA, debe establecer la variable de tiempo de ejecución de contenedor `NVIDIA_DRIVER_CAPABILITIES` en uno de los siguientes valores: + `utility,compute` + `all` Para obtener información acerca de cómo establecer la variable, consulte [Control del tiempo de ejecución del contenedor NVIDIA](https://sarus.readthedocs.io/en/stable/user/custom-cuda-images.html#controlling-the-nvidia-container-runtime) en el sitio web de NVIDIA. + Las GPU no son compatibles con los contenedores de Windows. # Lanzamiento de una instancia de contenedor de GPU para Amazon ECS Para utilizar una instancia de GPU en Amazon ECS en Amazon EC2, debe crear una plantilla de lanzamiento, un archivo de datos de usuario y lanzar la instancia. A continuación, puede ejecutar una tarea que utilice una definición de tarea configurada para la GPU. ## Uso de una plantilla de inicialización Puede crear una plantilla de lanzamiento. + Cree una plantilla de lanzamiento que utilice el identificador de AMI de GPU optimizado para Amazon ECS para la AMI. Para obtener información sobre cómo crear una plantilla de lanzamiento, consulte [Create a new launch template using parameters you define](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#create-launch-template-define-parameters) en la *Guía del usuario de Amazon EC2*. Utilice el ID de AMI del paso anterior para la **imagen de máquina de Amazon**. Para información sobre cómo especificar el identificador de AMI con el parámetro de Systems Manager, consulte [Specify a Systems Manager parameter in a launch template](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#use-an-ssm-parameter-instead-of-an-ami-id) en la *Guía del usuario de Amazon EC2*. Agregue lo siguiente a **Datos de usuario** en la plantilla de lanzamiento. Sustituya *cluster-name* por el nombre de su clúster. ``` #!/bin/bash echo ECS_CLUSTER=cluster-name >> /etc/ecs/ecs.config; echo ECS_ENABLE_GPU_SUPPORT=true >> /etc/ecs/ecs.config ``` ## Utilizar AWS CLI Puede utilizar la AWS CLI para iniciar una instancia de contenedor. 1. Cree un archivo denominado `userdata.toml`. Este archivo se utiliza para los datos de usuario de la instancia. Sustituya *cluster-name* por el nombre de su clúster. ``` #!/bin/bash echo ECS_CLUSTER=cluster-name >> /etc/ecs/ecs.config; echo ECS_ENABLE_GPU_SUPPORT=true >> /etc/ecs/ecs.config ``` 1. Ejecute el siguiente comando para obtener el identificador de la IAM de la GPU. Utilice esto en el siguiente paso. ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1 ``` 1. Ejecute el siguiente comando para lanzar una instancia de la GPU. Recuerde reemplazar los siguientes parámetros: + Sustituya la *subred* por el ID de la subred pública o privada en la que se lanzará la instancia. + Sustituya *gpu\$1ami* por el identificador de la AMI del paso anterior. + Sustituya *t3.large* por el tipo de instancia que desee usar. + Sustituya *región* por su código de región. ``` aws ec2 run-instances --key-name ecs-gpu-example \ --subnet-id subnet \ --image-id gpu_ami \ --instance-type t3.large \ --region region \ --tag-specifications 'ResourceType=instance,Tags=[{Key=GPU,Value=example}]' \ --user-data file://userdata.toml \ --iam-instance-profile Name=ecsInstanceRole ``` 1. Ejecute el siguiente comando para comprobar que la instancia de contenedor está registrada en el clúster. Al ejecutar este comando, recuerde reemplazar los siguientes parámetros: + Sustituya *clúster* por el nombre del clúster. + Sustituya *región* por el código de región. ``` aws ecs list-container-instances --cluster cluster-name --region region ``` # Especificación de GPU en una definición de tareas de Amazon ECS Para utilizar las GPU en una instancia de contenedor y el tiempo de ejecución de GPU de Docker, asegúrese de designar el número de GPU que requiere el contenedor en la definición de tareas. Cuando haya contenedores que admiten GPU, el agente de contenedores de Amazon ECS fijará el número deseado de GPU físicas en el contenedor correspondiente. El número de unidades GPU reservadas para todos los contenedores de una tarea no puede superar el número de GPU disponibles en la instancia de contenedor en la que se lanza la tarea. Para obtener más información, consulte [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md). **importante** Si los requisitos de GPU no se especifican en la definición de tareas, la tarea utilizará el tiempo de ejecución predeterminado de Docker. A continuación, se muestra el formato JSON de los requisitos de GPU en una definición de tareas: ``` { "containerDefinitions": [ { ... "resourceRequirements" : [ { "type" : "GPU", "value" : "2" } ], }, ... } ``` El ejemplo siguiente muestra la sintaxis de un contenedor Docker que especifica un requisito de GPU. Este contenedor utiliza dos GPU, ejecuta la utilidad `nvidia-smi` y, luego, se cierra. ``` { "containerDefinitions": [ { "memory": 80, "essential": true, "name": "gpu", "image": "nvidia/cuda:11.0.3-base", "resourceRequirements": [ { "type":"GPU", "value": "2" } ], "command": [ "sh", "-c", "nvidia-smi" ], "cpu": 100 } ], "family": "example-ecs-gpu" } ``` El siguiente ejemplo de definición de tarea muestra un contenedor de TensorFlow que imprime el número de GPU disponibles. La tarea se pone en marcha en instancias administradas de Amazon ECS, requiere una GPU y utiliza una instancia de `g4dn.xlarge`. ``` { "family": "tensorflow-gpu", "networkMode": "awsvpc", "executionRoleArn": "arn:aws:iam::account-id:role/ecsTaskExecutionRole", "containerDefinitions": [ { "name": "tensorflow", "image": "tensorflow/tensorflow:latest-gpu", "essential": true, "command": [ "python", "-c", "import tensorflow as tf; print('Num GPUs Available: ', len(tf.config.list_physical_devices('GPU')))" ], "resourceRequirements": [ { "type": "GPU", "value": "1" } ], "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-group": "/ecs/tensorflow-gpu", "awslogs-region": "region", "awslogs-stream-prefix": "ecs" } } } ], "requiresCompatibilities": [ "MANAGED_INSTANCES" ], "cpu": "4096", "memory": "8192", } ``` ## Uso compartido de GPU Si quiere compartir las GPU, tiene que configurar lo siguiente: 1. Elimine los requisitos de recursos de GPU de las definiciones de tareas para que Amazon ECS no reserve ninguna GPU que deba compartirse. 1. Agregue los siguientes datos de usuario a las instancias cuando quiera compartir las GPU. Esto hará que nvidia sea el tiempo de ejecución predeterminado del contenedor de Docker en la instancia de contenedor, de modo que todos los contenedores de Amazon ECS puedan usar las GPU. Para obtener más información acerca de los scripts de datos de usuario, consulte [Ejecución de comandos al lanzar una instancia de EC2 con la entrada de datos de usuario](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) en la *Guía del usuario de Amazon EC2*. ``` const userData = ec2.UserData.forLinux(); userData.addCommands( 'sudo rm /etc/sysconfig/docker', 'echo DAEMON_MAXFILES=1048576 | sudo tee -a /etc/sysconfig/docker', 'echo OPTIONS="--default-ulimit nofile=32768:65536 --default-runtime nvidia" | sudo tee -a /etc/sysconfig/docker', 'echo DAEMON_PIDFILE_TIMEOUT=10 | sudo tee -a /etc/sysconfig/docker', 'sudo systemctl restart docker', ); ``` 1. Configure la variable de entorno `NVIDIA_VISIBLE_DEVICES` en el contenedor. Para hacerlo, especifique la variable de entorno en la definición de tareas. Para obtener información sobre los valores válidos, consulte la [Enumeración de GPU](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html#gpu-enumeration) en el sitio de documentación de NVIDIA. ## Qué hacer si necesita una instancia P2 Si necesita utilizar la instancia P2, puede usar una de las siguientes opciones para continuar usando las instancias. Debe modificar los datos de usuario de la instancia para ambas opciones. Para obtener más información acerca de los scripts de datos de usuario, consulte [Ejecución de comandos al lanzar una instancia de EC2 con la entrada de datos de usuario](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) en la *Guía del usuario de Amazon EC2*. **Utilizar la última AMI optimizada para GPU compatible** Puede usar la versión `20230906` de la AMI optimizada para GPU y agregar lo siguiente a los datos de usuario de la instancia. Sustituya cluster-name por el nombre de su clúster. ``` #!/bin/bash echo "exclude=*nvidia* *cuda*" >> /etc/yum.conf echo "ECS_CLUSTER=cluster-name" >> /etc/ecs/ecs.config ``` **Utilizar la última AMI optimizada para GPU y actualizar los datos de usuario** Puede agregar lo siguiente a los datos de usuario de la instancia. Esto desinstala los controladores Nvidia 535/Cuda12.2 y, a continuación, instala los controladores Nvidia 470/Cuda11.4 y corrige la versión. ``` #!/bin/bash yum remove -y cuda-toolkit* nvidia-driver-latest-dkms* tmpfile=$(mktemp) cat >$tmpfile <> /etc/yum.conf nvidia-smi ``` **Crear su propia AMI optimizada para GPU compatible con P2** Puede crear su propia AMI optimizada para la GPU de Amazon ECS personalizada que sea compatible con las instancias P2 y, a continuación, lanzar las instancias P2 mediante la AMI. 1. Ejecute el siguiente comando para clonar el `amazon-ecs-ami repo`. ``` git clone https://github.com/aws/amazon-ecs-ami ``` 1. Configure el agente de Amazon ECS requerido y las versiones de la AMI de Amazon Linux de origen en `release.auto.pkrvars.hcl` o `overrides.auto.pkrvars.hcl`. 1. Ejecute el siguiente comando para crear una AMI de EC2 privada compatible con P2. Sustituya la región por la región de la instancia. ``` REGION=region make al2keplergpu ``` 1. Utilice la AMI con los siguientes datos de usuario de la instancia para conectarse al clúster de Amazon ECS. Sustituya cluster-name por el nombre de su clúster. ``` #!/bin/bash echo "ECS_CLUSTER=cluster-name" >> /etc/ecs/ecs.config ``` # Definiciones de tareas de Amazon ECS para cargas de trabajo de transcodificación de video Para utilizar cargas de trabajo de transcodificación de video en Amazon ECS, registre las instancias [VT1 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/vt1/). Una vez registradas estas instancias, puede ejecutar cargas de trabajo de transcodificación de video en directo preprocesadas como tareas en Amazon ECS. Las instancias VT1 de Amazon EC2 utilizan tarjetas de transcodificación multimedia Xilinx U30 para acelerar las cargas de trabajo de transcodificación de video en directo preprocesadas. **nota** Para obtener instrucciones sobre cómo ejecutar cargas de trabajo de transcodificación de video en contenedores que no sean de Amazon ECS, consulte la [documentación de Xilinx](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#working-with-docker-vt1). ## Consideraciones Antes de comenzar a implementar instancias VT1 en Amazon ECS, considere lo siguiente: + Los clústeres pueden contener instancias VT1 y no VT1 combinadas. + Necesita una aplicación Linux que utilice tarjetas de transcodificación multimedia Xilinx U30 con códecs AVC (H.264) y HEVC (H.265) acelerados. **importante** Es posible que las aplicaciones que utilizan otros códecs no tengan un rendimiento mejorado en las instancias VT1. + En una tarjeta U30 solo se puede ejecutar una tarea de transcodificación. Cada tarjeta tiene dos dispositivos asociados a ella. Puede ejecutar tantas tareas de transcodificación como tarjetas haya para cada instancia VT1. + Cuando cree un servicio o ejecute una tarea independiente, puede utilizar los atributos de tipo de instancia al configurar las restricciones de ubicación de tareas. Esto garantiza que la tarea se lance en la instancia de contenedor que especifique. Al hacerlo, puede asegurarse de que utiliza los recursos de forma eficaz y de que las tareas de las cargas de trabajo de transcodificación de video se encuentran en las instancias VT1. Para obtener más información, consulte [Cómo coloca Amazon ECS las tareas en las instancias de contenedor](task-placement.md). En el ejemplo siguiente, se ejecuta una tarea en una instancia `vt1.3xlarge` del clúster `default`. ``` aws ecs run-task \ --cluster default \ --task-definition vt1-3xlarge-xffmpeg-processor \ --placement-constraints type=memberOf,expression="attribute:ecs.instance-type == vt1.3xlarge" ``` + Configura un contenedor para que utilice la tarjeta U30 específica disponible en la instancia de contenedor del host. Para ello, utilice el parámetro `linuxParameters` y especifique los detalles del dispositivo. Para obtener más información, consulte [Requisitos de definición de tareas](#ecs-vt1-requirements). ## Uso de una AMI VT1 Tiene dos opciones para ejecutar una AMI en Amazon EC2 para instancias de contenedores de Amazon ECS. La primera opción es utilizar la AMI oficial de Xilinx en AWS Marketplace. La segunda opción es crear su propia AMI desde el repositorio de muestra. + [Xilinx ofrece AMI en AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-phvk6d4mq3hh6). + Amazon ECS proporciona un repositorio de muestra que puede utilizar para crear una AMI para cargas de trabajo de transcodificación de video. Esta AMI viene con los controladores Xilinx U30. Puede encontrar el repositorio que contiene scripts de Packer en [GitHub](https://github.com/aws-samples/aws-vt-baseami-pipeline). Para obtener más información sobre Packer, consulte la [documentación de Packer](https://developer.hashicorp.com/packer/docs). ## Requisitos de definición de tareas Para ejecutar contenedores de transcodificación de video en Amazon ECS, la definición de tareas debe contener una aplicación de transcodificación de video que utilice los códecs H.264/AVC y H.265/HEVC acelerados. Para crear una imagen de contenedor, siga los pasos que se indican en el [GitHub de Xilinx](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#creating-a-docker-image-for-vt1-usage). La definición de tareas debe ser específica del tipo de instancia. Los tipos de instancias son 3xlarge, 6xlarge y 24xlarge. Debe configurar un contenedor para que utilice los dispositivos Xilinx U30 específicos disponibles en la instancia de contenedor del host. Para ello, utilice el parámetro `linuxParameters`. En la tabla que se muestra a continuación se detallan las tarjetas y los SoC de dispositivos específicos de cada tipo de instancia. | Tipo de instancia | vCPU | RAM (GiB) | Tarjetas aceleradoras U30 | Dispositivos SoC XCU30 direccionables | Rutas del dispositivo | | --- | --- | --- | --- | --- | --- | | vt1.3xlarge | 12 | 24 | 1 | 2 | /dev/dri/renderD128,/dev/dri/renderD129 | | vt1.6xlarge | 24 | 48 | 2 | 4 | /dev/dri/renderD128,/dev/dri/renderD129,/dev/dri/renderD130,/dev/dri/renderD131 | | vt1.24xlarge | 96 | 182 | 8 | 16 | /dev/dri/renderD128,/dev/dri/renderD129,/dev/dri/renderD130,/dev/dri/renderD131,/dev/dri/renderD132,/dev/dri/renderD133,/dev/dri/renderD134,/dev/dri/renderD135,/dev/dri/renderD136,/dev/dri/renderD137,/dev/dri/renderD138,/dev/dri/renderD139,/dev/dri/renderD140,/dev/dri/renderD141,/dev/dri/renderD142,/dev/dri/renderD143 | **importante** Si la definición de tareas enumera los dispositivos que la instancia de EC2 no tiene, la tarea no se ejecuta. Cuando se produce·un·error·en la tarea, aparece el siguiente mensaje de error en `stoppedReason`: `CannotStartContainerError: Error response from daemon: error gathering device information while adding custom device "/dev/dri/renderD130": no such file or directory`. # Especificación de la transcodificación de video en una definición de tareas de Amazon ECS En el siguiente ejemplo, se proporciona la sintaxis que se utiliza para la definición de tareas de un contenedor de Linux en Amazon EC2. Esta definición de tareas se usa para imágenes de contenedor que se crean siguiendo el procedimiento proporcionado en la [documentación de Xilinx](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#creating-a-docker-image-for-vt1-usage). Si utiliza este ejemplo, reemplace `image` con su propia imagen y copie los archivos de video en la instancia del directorio `/home/ec2-user`. ------ #### [ vt1.3xlarge ] 1. Cree un archivo de texto denominado `vt1-3xlarge-ffmpeg-linux.json` con el siguiente contenido. ``` { "family": "vt1-3xlarge-xffmpeg-processor", "requiresCompatibilities": ["EC2"], "placementConstraints": [ { "type": "memberOf", "expression": "attribute:ecs.os-type == linux" }, { "type": "memberOf", "expression": "attribute:ecs.instance-type == vt1.3xlarge" } ], "containerDefinitions": [ { "entryPoint": [ "/bin/bash", "-c" ], "command": ["/video/ecs_ffmpeg_wrapper.sh"], "linuxParameters": { "devices": [ { "containerPath": "/dev/dri/renderD128", "hostPath": "/dev/dri/renderD128", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD129", "hostPath": "/dev/dri/renderD129", "permissions": [ "read", "write" ] } ] }, "mountPoints": [ { "containerPath": "/video", "sourceVolume": "video_file" } ], "cpu": 0, "memory": 12000, "image": "0123456789012.dkr.ecr.us-west-2.amazonaws.com/aws/xilinx-xffmpeg", "essential": true, "name": "xilinix-xffmpeg" } ], "volumes": [ { "name": "video_file", "host": {"sourcePath": "/home/ec2-user"} } ] } ``` 1. Registre la definición de tareas. ``` aws ecs register-task-definition --family vt1-3xlarge-xffmpeg-processor --cli-input-json file://vt1-3xlarge-xffmpeg-linux.json --region us-east-1 ``` ------ #### [ vt1.6xlarge ] 1. Cree un archivo de texto denominado `vt1-6xlarge-ffmpeg-linux.json` con el siguiente contenido. ``` { "family": "vt1-6xlarge-xffmpeg-processor", "requiresCompatibilities": ["EC2"], "placementConstraints": [ { "type": "memberOf", "expression": "attribute:ecs.os-type == linux" }, { "type": "memberOf", "expression": "attribute:ecs.instance-type == vt1.6xlarge" } ], "containerDefinitions": [ { "entryPoint": [ "/bin/bash", "-c" ], "command": ["/video/ecs_ffmpeg_wrapper.sh"], "linuxParameters": { "devices": [ { "containerPath": "/dev/dri/renderD128", "hostPath": "/dev/dri/renderD128", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD129", "hostPath": "/dev/dri/renderD129", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD130", "hostPath": "/dev/dri/renderD130", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD131", "hostPath": "/dev/dri/renderD131", "permissions": [ "read", "write" ] } ] }, "mountPoints": [ { "containerPath": "/video", "sourceVolume": "video_file" } ], "cpu": 0, "memory": 12000, "image": "0123456789012.dkr.ecr.us-west-2.amazonaws.com/aws/xilinx-xffmpeg", "essential": true, "name": "xilinix-xffmpeg" } ], "volumes": [ { "name": "video_file", "host": {"sourcePath": "/home/ec2-user"} } ] } ``` 1. Registre la definición de tareas. ``` aws ecs register-task-definition --family vt1-6xlarge-xffmpeg-processor --cli-input-json file://vt1-6xlarge-xffmpeg-linux.json --region us-east-1 ``` ------ #### [ vt1.24xlarge ] 1. Cree un archivo de texto denominado `vt1-24xlarge-ffmpeg-linux.json` con el siguiente contenido. ``` { "family": "vt1-24xlarge-xffmpeg-processor", "requiresCompatibilities": ["EC2"], "placementConstraints": [ { "type": "memberOf", "expression": "attribute:ecs.os-type == linux" }, { "type": "memberOf", "expression": "attribute:ecs.instance-type == vt1.24xlarge" } ], "containerDefinitions": [ { "entryPoint": [ "/bin/bash", "-c" ], "command": ["/video/ecs_ffmpeg_wrapper.sh"], "linuxParameters": { "devices": [ { "containerPath": "/dev/dri/renderD128", "hostPath": "/dev/dri/renderD128", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD129", "hostPath": "/dev/dri/renderD129", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD130", "hostPath": "/dev/dri/renderD130", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD131", "hostPath": "/dev/dri/renderD131", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD132", "hostPath": "/dev/dri/renderD132", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD133", "hostPath": "/dev/dri/renderD133", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD134", "hostPath": "/dev/dri/renderD134", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD135", "hostPath": "/dev/dri/renderD135", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD136", "hostPath": "/dev/dri/renderD136", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD137", "hostPath": "/dev/dri/renderD137", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD138", "hostPath": "/dev/dri/renderD138", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD139", "hostPath": "/dev/dri/renderD139", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD140", "hostPath": "/dev/dri/renderD140", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD141", "hostPath": "/dev/dri/renderD141", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD142", "hostPath": "/dev/dri/renderD142", "permissions": [ "read", "write" ] }, { "containerPath": "/dev/dri/renderD143", "hostPath": "/dev/dri/renderD143", "permissions": [ "read", "write" ] } ] }, "mountPoints": [ { "containerPath": "/video", "sourceVolume": "video_file" } ], "cpu": 0, "memory": 12000, "image": "0123456789012.dkr.ecr.us-west-2.amazonaws.com/aws/xilinx-xffmpeg", "essential": true, "name": "xilinix-xffmpeg" } ], "volumes": [ { "name": "video_file", "host": {"sourcePath": "/home/ec2-user"} } ] } ``` 1. Registre la definición de tareas. ``` aws ecs register-task-definition --family vt1-24xlarge-xffmpeg-processor --cli-input-json file://vt1-24xlarge-xffmpeg-linux.json --region us-east-1 ``` ------ # Definiciones de tareas de Amazon ECS para cargas de trabajo de machine learning de AWS Neuron Puede registrar instancias [Trn1 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/trn1/), [Trn2 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/trn2/), [Inf1 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/inf1/) e [Inf2 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/inf2/) en los clústeres para cargas de trabajo de machine learning. Las instancias Trn1 y Trn2 de Amazon EC2 funcionan con chips de [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/). Estas instancias proporcionan capacitación de alto rendimiento y bajo costo para el machine learning en la nube. Puede entrenar un modelo de inferencia de machine learning mediante un marco de machine learning con AWS Neuron en una instancia de Trn1 y Trn2. A continuación, puede ejecutar el modelo en una instancia de Inf1 o de Inf2 para usar la aceleración de los chips de AWS Inferentia. Las instancias Inf1 e Inf2 de Amazon EC2 funcionan con chips de [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/), que proporcionan un alto rendimiento y una inferencia de menor costo en la nube. Los modelos de machine learning se implementan en contenedores mediante [AWS Neuron](https://aws.amazon.com/ai/machine-learning/neuron/), que es un kit de desarrollo de software (SDK) especializado. SDK consiste en un compilador, tiempo de ejecución y herramientas de perfilado que optimizan el rendimiento de machine learning de los chips de AWS. AWS Neuron admite marcos de machine learning populares como TensorFlow, PyTorch y Apache MXNet. ## Consideraciones Antes de comenzar a implementar Neuron en Amazon ECS, tenga en cuenta lo siguiente: + Los clústeres pueden contener una combinación de instancias Trn1, Trn2, Inf1, Inf2 y otras instancias. + Necesita una aplicación de Linux en un contenedor que use un marco de machine learning compatible con AWS Neuron. **importante** Es posible que las aplicaciones que utilizan otros marcos no tengan un rendimiento mejorado en las instancias Trn1, Trn2, Inf1 e Inf2. + Solo se puede ejecutar una tarea de inferencia o entrenamiento de inferencias en cada chip [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/) o [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/). Para Inf1, cada chip tiene 4 NeuronCore. Para Trn1, Trn2 e Inf2, cada chip tiene 2 NeuronCore. Puede ejecutar tantas tareas como chips haya para cada instancia de Trn1, Trn2, Inf1 e Inf2. + Cuando cree un servicio o ejecute una tarea independiente, puede utilizar los atributos de tipo de instancia al configurar las restricciones de ubicación de tareas. Esto garantiza que la tarea se lance en la instancia de contenedor que especifique. Al hacerlo, puede optimizar la utilización general de los recursos y garantizar que las tareas de las cargas de trabajo de inferencia se encuentren en las instancias Trn1, Trn2, Inf1 e Inf2. Para obtener más información, consulte [Cómo coloca Amazon ECS las tareas en las instancias de contenedor](task-placement.md). En el ejemplo siguiente, se ejecuta una tarea en una instancia `Inf1.xlarge` del clúster `default`. ``` aws ecs run-task \ --cluster default \ --task-definition ecs-inference-task-def \ --placement-constraints type=memberOf,expression="attribute:ecs.instance-type == Inf1.xlarge" ``` + Los requisitos de recursos de Neuron no se pueden definir en una definición de tareas. En su lugar, configure un contenedor para que use chips de AWS Trainium o de AWS Inferentia específicos disponibles en la instancia de contenedor del host. Para ello, use el parámetro `linuxParameters` y especifique los detalles del dispositivo. Para obtener más información, consulte [Requisitos de definición de tareas](#ecs-inference-requirements). ## Uso de la AMI de Amazon Linux 2023 (Neuron) optimizada para Amazon ECS Amazon ECS proporciona una AMI optimizada para Amazon ECS que se basa en Amazon Linux 2023 para cargas de trabajo de AWS Trainium y AWS Inferentia. Viene con los controladores AWS Neuron y el tiempo de ejecución para Docker. Esta AMI facilita la ejecución de cargas de trabajo de inferencia de machine learning en Amazon ECS. Recomendamos utilizar la AMI de Amazon Linux 2023 (Neuron) optimizada para Amazon ECS cuando se lanzan las instancias Trn1, Inf1 e Inf2 de Amazon EC2. Puede recuperar la AMI actual de Amazon Linux 2023 (Neuron) optimizada para Amazon ECS a través de la AWS CLI con el siguiente comando. ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/recommended ``` ## Requisitos de definición de tareas Para implementar Neuron en Amazon ECS, la definición de tareas debe contener la definición de contenedor correspondiente a un contenedor prefabricado que atienda al modelo de inferencia para TensorFlow. Este es proporcionado por AWS Deep Learning Containers. Dentro del contenedor, se incluye el tiempo de ejecución de AWS Neuron y la aplicación TensorFlow Serving. Al iniciarse, este contenedor obtiene su modelo de Amazon S3, lanza Neuron TensorFlow Serving con el modelo guardado y espera las solicitudes de predicción. En el ejemplo a continuación, la imagen de contenedor contiene TensorFlow 1.15 y Ubuntu 18.04. Se conserva una lista completa de Deep Learning Containers prefabricados optimizados para Neuron en GitHub. Para obtener más información, consulte [Utilizar AWS Neuron TensorFlow Serving](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-inferentia-tf-neuron-serving.html). ``` 763104351884.dkr.ecr.us-east-1.amazonaws.com/tensorflow-inference-neuron:1.15.4-neuron-py37-ubuntu18.04 ``` Como alternativa, puede crear su propia imagen de contenedor de sidecar de Neuron. Para obtener más información, consulte [Tutorial: Neuron TensorFlow Serving](https://github.com/aws-neuron/aws-neuron-sdk/blob/master/frameworks/tensorflow/tensorflow-neuron/tutorials/tutorials-tensorflow-utilizing-neuron-capabilities.rst) en la *Guía para desarrolladores de AWS Deep Learning AMIs*. La definición de la tarea debe ser específica para un único tipo de instancia. Debe configurar un contenedor para que use los dispositivos AWS Trainium o AWS Inferentia específicos disponibles en la instancia de contenedor del host. Para ello, utilice el parámetro `linuxParameters`. Para una definición de una tarea de ejemplo, consulte [Especificación de machine learning de AWS Neuron en una definición de tareas de Amazon ECS](ecs-inference-task-def.md). En la tabla que se muestra a continuación se detallan los chips específicos de cada tipo de instancia. | Tipo de instancia | vCPU | RAM (GiB) | Chips de aceleradores AWS ML | Rutas del dispositivo | | --- | --- | --- | --- | --- | | trn1.2xlarge | 8 | 32 | 1 | /dev/neuron0 | | trn1.32xlarge | 128 | 512 | 16 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11, /dev/neuron12, /dev/neuron13, /dev/neuron14, /dev/neuron15 | | trn2.48xlarge | 192 | 1536 | 16 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11, /dev/neuron12, /dev/neuron13, /dev/neuron14, /dev/neuron15 | | inf1.xlarge | 4 | 8 | 1 | /dev/neuron0 | | inf1.2xlarge | 8 | 16 | 1 | /dev/neuron0 | | inf1.6xlarge | 24 | 48 | 4 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3 | | inf1.24xlarge | 96 | 192 | 16 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11, /dev/neuron12, /dev/neuron13, /dev/neuron14, /dev/neuron15 | | inf2.xlarge | 8 | 16 | 1 | /dev/neuron0 | | inf2.8xlarge | 32 | 64 | 1 | /dev/neuron0 | | inf2.24xlarge | 96 | 384 | 6 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, | | inf2.48xlarge | 192 | 768 | 12 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11 | # Especificación de machine learning de AWS Neuron en una definición de tareas de Amazon ECS A continuación, se muestra un ejemplo de definición de tarea de Linux para `inf1.xlarge` en el que se muestra la sintaxis que se va a usar. ``` { "family": "ecs-neuron", "requiresCompatibilities": ["EC2"], "placementConstraints": [ { "type": "memberOf", "expression": "attribute:ecs.os-type == linux" }, { "type": "memberOf", "expression": "attribute:ecs.instance-type == inf1.xlarge" } ], "executionRoleArn": "${YOUR_EXECUTION_ROLE}", "containerDefinitions": [ { "entryPoint": [ "/usr/local/bin/entrypoint.sh", "--port=8500", "--rest_api_port=9000", "--model_name=resnet50_neuron", "--model_base_path=s3://amzn-s3-demo-bucket/resnet50_neuron/" ], "portMappings": [ { "hostPort": 8500, "protocol": "tcp", "containerPort": 8500 }, { "hostPort": 8501, "protocol": "tcp", "containerPort": 8501 }, { "hostPort": 0, "protocol": "tcp", "containerPort": 80 } ], "linuxParameters": { "devices": [ { "containerPath": "/dev/neuron0", "hostPath": "/dev/neuron0", "permissions": [ "read", "write" ] } ], "capabilities": { "add": [ "IPC_LOCK" ] } }, "cpu": 0, "memoryReservation": 1000, "image": "763104351884.dkr.ecr.us-east-1.amazonaws.com/tensorflow-inference-neuron:1.15.4-neuron-py37-ubuntu18.04", "essential": true, "name": "resnet50" } ] } ``` # Definiciones de tareas de Amazon ECS para instancias de aprendizaje profundo Para utilizar cargas de trabajo de aprendizaje profundo en Amazon ECS, registre las instancias [DL1 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/dl1/) en los clústeres. Las instancias DL1 de Amazon EC2 funcionan con aceleradores Gaudi de Habana Labs (una empresa de Intel). Utilice el SDK de Habana SynapseAI para conectarse a los aceleradores Gaudi de Habana. El SDK admite los marcos de machine learning populares TensorFlow y PyTorch. ## Consideraciones Antes de comenzar a implementar instancias DL1 en Amazon ECS, tenga en cuenta lo siguiente: + Los clústeres pueden contener instancias DL1 y no DL1 combinadas. + Cuando crea un servicio o ejecuta una tarea independiente, puede utilizar los atributos de tipo de instancias concretamente al configurar las restricciones de ubicación de tareas para asegurarse de que la tarea se lance en la instancia de contenedor que especifique. Al hacerlo, se asegura de que los recursos se utilizan de manera eficaz y de que las tareas de las cargas de trabajo de aprendizaje profundo se encuentran en las instancias DL1. Para obtener más información, consulte [Cómo coloca Amazon ECS las tareas en las instancias de contenedor](task-placement.md). En el ejemplo siguiente, se ejecuta una tarea en una instancia `dl1.24xlarge` del clúster `default`. ``` aws ecs run-task \ --cluster default \ --task-definition ecs-dl1-task-def \ --placement-constraints type=memberOf,expression="attribute:ecs.instance-type == dl1.24xlarge" ``` ## Uso de una AMI DL1 Tiene tres opciones para ejecutar una AMI en instancias DL1 de Amazon EC2 para Amazon ECS: + AMI de AWS Marketplace proporcionadas por Habana [aquí](https://aws.amazon.com/marketplace/pp/prodview-h24gzbgqu75zq). + AMI de aprendizaje profundo de Habana proporcionadas por Amazon Web Services. Como no está incluido, debe instalar el agente de contenedor de Amazon ECS por separado. + Utilice Packer para crear una AMI personalizada proporcionada por el [repositorio de GitHub](https://github.com/aws-samples/aws-habana-baseami-pipeline). Para obtener más información, consulte la [documentación de Packer](https://developer.hashicorp.com/packer/docs). # Especificación del aprendizaje profundo en una definición de tareas de Amazon ECS Para ejecutar contenedores de aprendizaje profundo acelerados Gaudi de Habana en Amazon ECS, la definición de tareas debe contener la definición de contenedor de un contenedor prefabricado que atienda el modelo de aprendizaje profundo de TensorFlow o PyTorch utilizando el software SynapseAI de Habana proporcionado por AWS Deep Learning Containers. La siguiente imagen de contenedor contiene TensorFlow 2.7.0 y Ubuntu 20.04. En GitHub se conserva una lista completa de contenedores de aprendizaje profundo prefabricados optimizados para aceleradores Gaudi de Habana. Para obtener más información, consulte [Habana Training Containers](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#habana-training-containers) (Contenedores de capacitación de Habana). ``` 763104351884.dkr.ecr.us-east-1.amazonaws.com/tensorflow-training-habana:2.7.0-hpu-py38-synapseai1.2.0-ubuntu20.04 ``` A continuación, se muestra un ejemplo de definición de tareas de contenedores Linux en Amazon EC2 en el que se muestra la sintaxis que se va a utilizar. En este ejemplo se utiliza una imagen que contiene la herramienta de interfaz de administración del sistema de Habana Labs (HL-SMI) que se encuentra aquí: `vault.habana.ai/gaudi-docker/1.1.0/ubuntu20.04/habanalabs/tensorflow-installer-tf-cpu-2.6.0:1.1.0-614` ``` { "family": "dl-test", "requiresCompatibilities": ["EC2"], "placementConstraints": [ { "type": "memberOf", "expression": "attribute:ecs.os-type == linux" }, { "type": "memberOf", "expression": "attribute:ecs.instance-type == dl1.24xlarge" } ], "networkMode": "host", "cpu": "10240", "memory": "1024", "containerDefinitions": [ { "entryPoint": [ "sh", "-c" ], "command": ["hl-smi"], "cpu": 8192, "environment": [ { "name": "HABANA_VISIBLE_DEVICES", "value": "all" } ], "image": "vault.habana.ai/gaudi-docker/1.1.0/ubuntu20.04/habanalabs/tensorflow-installer-tf-cpu-2.6.0:1.1.0-614", "essential": true, "name": "tensorflow-installer-tf-hpu" } ] } ``` # Definiciones de tareas de Amazon ECS para cargas de trabajo de ARM de 64 bits Amazon ECS admite el uso de aplicaciones ARM de 64 bits. Puede ejecutar las aplicaciones en la plataforma con la tecnología de los [procesadores de AWS Graviton](https://aws.amazon.com/ec2/graviton/). Es adecuada para una gran variedad de cargas de trabajo. Entre ellas se incluyen cargas de trabajo tales como servidores de aplicaciones, microservicios, computación de alto rendimiento, inferencia de machine learning basada en CPU, codificación de video, automatización de diseño electrónico, juegos, bases de datos de código abierto y cachés en memoria. ## Consideraciones Antes de comenzar a implementar definiciones de tareas que utilizan la arquitectura de ARM de 64 bits, tenga en cuenta lo siguiente: + Las aplicaciones pueden utilizar Fargate o EC2. + Las aplicaciones solo pueden utilizar el sistema operativo Linux. + Para el tipo Fargate, las aplicaciones deben utilizar la versión de plataforma Fargate `1.4.0` o posterior. + Las aplicaciones pueden utilizar Fluent Bit o CloudWatch para supervisión. + Para Fargate, las siguientes Regiones de AWS no admiten cargas de trabajo ARM de 64 bits: + Este de EE. UU. (Norte de Virginia), la zona de disponibilidad `use1-az3` + Para EC2, consulte lo siguiente para comprobar que la región en la que se encuentra admite el tipo de instancia que desea utilizar: + [Instancias M6g de Amazon EC2](https://aws.amazon.com/ec2/instance-types/m6) + [Instancias T4g de Amazon EC2](https://aws.amazon.com/ec2/instance-types/t4/) + [Instancias C6g de Amazon EC2](https://aws.amazon.com/ec2/instance-types/c6g/) + [Instancias R6gd de Amazon EC2](https://aws.amazon.com/ec2/instance-types/r6/) + [Instancias X2gd de Amazon EC2](https://aws.amazon.com/ec2/instance-types/x2/) También puede utilizar el comando `describe-instance-type-offerings` de Amazon EC2 con un filtro para ver la oferta de instancias de su región. ``` aws ec2 describe-instance-type-offerings --filters Name=instance-type,Values=instance-type --region region ``` En el siguiente ejemplo, se comprueba la disponibilidad del tipo de instancia M6 en la región Este de EE. UU. (Norte de Virginia) (us-east-1). ``` aws ec2 describe-instance-type-offerings --filters "Name=instance-type,Values=m6*" --region us-east-1 ``` Para obtener más información, consulte [describe-instance-type-offerings](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html) en la *Referencia de la línea de comandos de Amazon EC2*. # Especificación de la arquitectura de ARM en la definición de tareas de Amazon ECS Para utilizar la arquitectura de ARM, especifique `ARM64` para el parámetro de definición de tareas `cpuArchitecture`. En el siguiente ejemplo, la arquitectura de ARM se especifica en una definición de tareas. Está en formato JSON. ``` { "runtimePlatform": { "operatingSystemFamily": "LINUX", "cpuArchitecture": "ARM64" }, ... } ``` En el siguiente ejemplo, una definición de tarea para la arquitectura de ARM muestra “hello world”. ``` { "family": "arm64-testapp", "networkMode": "awsvpc", "containerDefinitions": [ { "name": "arm-container", "image": "public.ecr.aws/docker/library/busybox:latest", "cpu": 100, "memory": 100, "essential": true, "command": [ "echo hello world" ], "entryPoint": [ "sh", "-c" ] } ], "requiresCompatibilities": [ "EC2" ], "cpu": "256", "memory": "512", "runtimePlatform": { "operatingSystemFamily": "LINUX", "cpuArchitecture": "ARM64" }, "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole" } ``` # Envío de registros de Amazon ECS a CloudWatch Puede configurar los contenedores de las tareas para que envíen información de registro a CloudWatch Logs. Si utiliza Fargate para las tareas, puede ver los registros de los contenedores. Si utiliza EC2, esto le permite ver distintos registros desde los contenedores en una ubicación cómoda y evita que los registros de contenedor ocupen espacio en disco en las instancias de contenedor. **nota** El tipo de información que registran los contenedores de la tarea depende en gran medida del comando `ENTRYPOINT`. De forma predeterminada, los registros que se capturan muestran la salida del comando que aparecería normalmente en un terminal interactivo si el contenedor se ejecutara localmente, que son los flujos de E/S `STDOUT` y `STDERR`. El controlador del registros `awslogs` simplemente transfiere estos registros de Docker a CloudWatch Logs. Para obtener más información acerca de cómo se procesan los registros de Docker, incluidas formas alternativas de capturar diferentes datos de archivo o flujos, consulte la página sobre cómo [Ver los registros de un contenedor o servicio](https://docs.docker.com/engine/logging/) en la documentación de Docker. Para enviar registros del sistema desde las instancias de contenedor de Amazon ECS a CloudWatch Logs, consulte [Supervisar archivos de registro](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchLogs.html) y [Cuotas de registros de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html) en la *Guía del usuario de registros de Amazon CloudWatch*. ## Fargate Si utiliza de Fargate para las tareas, debe agregar los parámetros `logConfiguration` necesarios a la definición de tareas para activar el controlador de registros `awslogs`. Para obtener más información, consulte [Definición de tareas de Amazon ECS de ejemplo: enrutar registros a CloudWatch](specify-log-config.md). Para el contenedor de Windows en Fargate, siga una de las siguientes opciones cuando alguno de los parámetros de definición de tareas tenga caracteres especiales como, por ejemplo, `& \ < > ^ |`: + Agregue un carácter de escape (`\`) con comillas dobles alrededor de toda la cadena de parámetros. Ejemplo ``` "awslogs-multiline-pattern": "\"^[|DEBUG|INFO|WARNING|ERROR\"", ``` + Agregue un carácter de escape (`^`) alrededor de cada carácter especial. Ejemplo ``` "awslogs-multiline-pattern": "^^[^|DEBUG^|INFO^|WARNING^|ERROR", ``` ## EC2 Si utiliza EC2 para las tareas y desea activar el controlador de registros `awslogs`, las instancias de contenedor de Amazon ECS requieren al menos la versión 1.9.0 del agente de contenedor. Para obtener información acerca de cómo comprobar la versión del agente y actualizar a la versión más reciente, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md). **nota** Debe utilizar una AMI optimizada para Amazon ECS o una AMI personalizada con al menos la versión `1.9.0-1` del paquete `ecs-init`. Cuando utilice una AMI personalizada, debe especificar que el controlador del registro `awslogs` esté disponible en la instancia de Amazon EC2 al iniciar el agente mediante la siguiente variable de entorno en la instrucción **docker run** o el archivo de variables de entorno. ``` ECS_AVAILABLE_LOGGING_DRIVERS=["json-file","awslogs"] ``` Las instancias de contenedor de Amazon ECS también requieren el permiso `logs:CreateLogStream` y `logs:PutLogEvents` en el rol de IAM con el que se pueden lanzar las instancias de contenedor. Si creó el rol de instancia de contenedor de Amazon ECS antes de que se habilitara la compatibilidad con el controlador de registros `awslogs` en Amazon ECS, es posible que tenga que agregar este permiso. El `ecsTaskExecutionRole` se utiliza cuando se asigna a la tarea y probablemente contenga los permisos correctos. Para obtener información acerca del rol de ejecución de tareas, consulte [Rol de IAM de ejecución de tareas de Amazon ECS](task_execution_IAM_role.md). Si las instancias de contenedor utilizan la política de IAM administrada para instancias de contenedor, probablemente tengan los permisos correctos. Para obtener información acerca de la política de IAM administrada para las instancias de contenedor, consulte [Rol de IAM de instancia de contenedor de Amazon ECS](instance_IAM_role.md). # Definición de tareas de Amazon ECS de ejemplo: enrutar registros a CloudWatch Antes de que los contenedores puedan enviar registros a CloudWatch, debe especificar el controlador de registros `awslogs` para los contenedores de la definición de tarea. Para obtener más información sobre los parámetros de registros, consulte [Almacenamiento y registro](task_definition_parameters.md#container_definition_storage). El JSON de definición de tareas a continuación tiene un objeto `logConfiguration` especificado para cada contenedor. Uno es para el contenedor de WordPress que envía registros a un grupo de registro denominado `awslogs-wordpress`. El otro es para un contenedor MySQL que envía registros a un grupo de registro denominado `awslogs-mysql`. Ambos contenedores utilizan el prefijo de flujo de registros `awslogs-example`. ``` { "containerDefinitions": [ { "name": "wordpress", "links": [ "mysql" ], "image": "public.ecr.aws/docker/library/wordpress:latest", "essential": true, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-create-group": "true", "awslogs-group": "awslogs-wordpress", "awslogs-region": "us-west-2", "awslogs-stream-prefix": "awslogs-example" } }, "memory": 500, "cpu": 10 }, { "environment": [ { "name": "MYSQL_ROOT_PASSWORD", "value": "password" } ], "name": "mysql", "image": "public.ecr.aws/docker/library/mysql:latest", "cpu": 10, "memory": 500, "essential": true, "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-create-group": "true", "awslogs-group": "awslogs-mysql", "awslogs-region": "us-west-2", "awslogs-stream-prefix": "awslogs-example", "mode": "non-blocking", "max-buffer-size": "25m" } } } ], "family": "awslogs-example" } ``` ## Siguientes pasos + Si lo desea, puede establecer una política de retención para el grupo de registros mediante la AWS CLI de CloudWatch o la API. Para obtener más información, consulte [put-retention-policy](https://docs.aws.amazon.com/cli/latest/reference/logs/put-retention-policy.html) en la *Referencia de comandos de la AWS Command Line Interface*. + Después de haber registrado una definición de tarea con el controlador de registros `awslogs` en una configuración de registros de definición de contenedor, puede ejecutar una tarea o crear un servicio con dicha definición de tarea para comenzar a enviar registros a CloudWatch Logs. Para obtener más información, consulte [Ejecución de una aplicación como tarea de Amazon ECS](standalone-task-create.md) y [Creación de una implementación de actualización continua de Amazon ECS](create-service-console-v2.md). # Envío de registros de Amazon ECS a un servicio de AWS o AWS Partner Puede utilizar FireLens para Amazon ECS para utilizar parámetros de definición de tareas para dirigir registros a un servicio de AWS o a un destino de AWS Partner Network (APN) para el almacenamiento y el análisis de registros. La AWS Partner Network es una comunidad global de socios que aprovecha los programas, el conocimiento técnico y los recursos para crear, comercializar y vender ofertas para los clientes. Para obtener más información, consulte [AWS Partner](https://aws.amazon.com/partners/work-with-partners/). FireLens trabaja con [Fluentd](https://www.fluentd.org/) y [Fluent Bit](https://fluentbit.io/). Proporcionamos AWS para la imagen de Fluent Bit o puede utilizar su propia imagen de Fluentd o Fluent Bit. De forma predeterminada, Amazon ECS configura la dependencia del contenedor para que el contenedor Firelens se inicie antes que cualquier contenedor que lo utilice. El contenedor Firelens también se detiene después de que se detengan todos los contenedores que lo utilizan. Para utilizar esta característica, debe crear un rol de IAM para las tareas, que proporcione los permisos necesarios para utilizar los servicios de AWS que las tareas requieran. Por ejemplo, si un contenedor dirige los registros a Firehose, la tarea necesita permiso para llamar a la API `firehose:PutRecordBatch`. Para obtener más información, consulte [Adición y eliminación de permisos de identidad de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) en la *Guía del usuario de IAM*. Es posible que la tarea también requiera el rol de ejecución de tareas de Amazon ECS en las condiciones que se describen a continuación. Para obtener más información, consulte [Rol de IAM de ejecución de tareas de Amazon ECS](task_execution_IAM_role.md). + Si la tarea está alojada en Fargate y se están extrayendo imágenes de contenedor de Amazon ECR o haciendo referencia a información confidencial de AWS Secrets Manager en la configuración de registro, debe incluir el rol de IAM de ejecución de tareas. + Si utiliza un archivo de configuración personalizado alojado en Amazon S3, el rol de IAM de ejecución de tareas debe incluir el permiso `s3:GetObject`. Al utilizar FireLens para Amazon ECS, tenga en cuenta lo siguiente: + Se recomienda agregar `my_service_` al nombre del contenedor de registros para poder distinguir fácilmente los nombres de los contenedores en la consola. + Amazon ECS agrega una dependencia de orden de contenedores inicial entre los contenedores de la aplicación y el contenedor de FireLens de manera predeterminada. Al especificar un orden de contenedores entre los contenedores de la aplicación y el contenedor de FireLens, se anula el orden de contenedores inicial predeterminado. + FireLens para Amazon ECS es compatible con tareas que están alojadas en AWS Fargate en Linux y Amazon EC2 en Linux. Los contenedores de Windows no son compatibles con FireLens. Para obtener información sobre cómo configurar el registro centralizado para contenedores de Windows, consulte [Centralized logging for Windows containers on Amazon ECS using Fluent Bit](https://aws.amazon.com/blogs/containers/centralized-logging-for-windows-containers-on-amazon-ecs-using-fluent-bit/) (Registro centralizado para contenedores de Windows en Amazon ECS con Fluent Bit). + Puede utilizar plantillas de CloudFormation para configurar FireLens para Amazon ECS. Para obtener más información, consulte [FirelensConfiguration de ::ECS::TaskDefinition](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-firelensconfiguration.html) en la *Guía del usuario de AWS CloudFormation*. + FireLens escucha en el puerto `24224`, para asegurarse de que el direccionador de registros FireLens no sea accesible fuera de la tarea, no debe permitir la entrada de tráfico en el puerto `24224` en el grupo de seguridad que utiliza la tarea. Para tareas que utilizan el modo de red `awsvpc`, es el grupo de seguridad asociado a la tarea. Para tareas que utilizan el modo de red `host`, es el grupo de seguridad asociado a la instancia de Amazon EC2 que aloja la tarea. Para tareas que utilizan el modo de red `bridge`, no cree asignaciones de puertos que utilicen el puerto `24224`. + Para las tareas que utilizan el modo de red `bridge`, el contenedor con la configuración de FireLens debe iniciarse antes de que se inicie cualquier contenedor de aplicación que se base en él. Para controlar el orden de inicio de los contenedores, utilice las condiciones de dependencia en la definición de la tarea. Para obtener más información, consulte [Dependencia de contenedor](task_definition_parameters.md#container_definition_dependson). **nota** Si utiliza parámetros de condición de dependencia en definiciones de contenedor con una configuración de FireLens, asegúrese de que cada contenedor tenga un requisito de condición `START` o `HEALTHY`. + Por defecto, FireLens agrega el nombre de definición de clúster y tarea y el nombre de recurso de Amazon (ARN) del clúster como claves de metadatos a los registros de contenedor de stdout/stderr. A continuación se muestra un ejemplo del formato de los metadatos. ``` "ecs_cluster": "cluster-name", "ecs_task_arn": "arn:aws:ecs:region:111122223333:task/cluster-name/f2ad7dba413f45ddb4EXAMPLE", "ecs_task_definition": "task-def-name:revision", ``` Si no quiere que los metadatos estén en los registros, establezca `enable-ecs-log-metadata` en `false` en la `firelensConfiguration` de la definición de tareas. ``` "firelensConfiguration":{ "type":"fluentbit", "options":{ "enable-ecs-log-metadata":"false", "config-file-type":"file", "config-file-value":"/extra.conf" } ``` Puede configurar el contenedor FireLens para que se ponga en marcha como usuario no raíz. Considere lo siguiente: + Para configurar el contenedor FireLens para que se ponga en marcha como un usuario no raíz, debe especificar el usuario en uno de los formatos siguientes: + `uid` + `uid:gid` + `uid:group` Para obtener más información acerca de la especificación de un usuario en una definición de contenedor, consulte [ContainerDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html) en la *Referencia de la API de Amazon Elastic Container Service*. El contenedor FireLens recibe los registros de la aplicación a través de un socket UNIX. El agente de Amazon ECS utiliza el parámetro `uid` para asignar la responsabilidad del directorio de sockets al contenedor FireLens. + La configuración del contenedor FireLens para que se ponga en marcha como un usuario no raíz se admite en la versión `1.96.0` del agente de Amazon ECS y posteriores, y en la versión `v20250716` de AMI optimizada para Amazon ECS y posteriores. + Al especificar un usuario para el contenedor FireLens, el parámetro `uid` debe ser único y no se debe utilizar para otros procesos que pertenezcan a otros contenedores de la tarea o de la instancia de contenedor. Para obtener información sobre cómo usar varios archivos de configuración con Amazon ECS, incluidos los archivos que usted aloja o los archivos en Amazon S3, consulte [Init process for Fluent Bit on ECS, multi-config support](https://github.com/aws/aws-for-fluent-bit/tree/mainline/use_cases/init-process-for-fluent-bit). Para obtener información acerca de las configuraciones de ejemplo, consulte [Definición de tareas de Amazon ECS de ejemplo: enrutar registros a FireLens](firelens-taskdef.md). Para obtener más información acerca de la configuración de registros de rendimiento alto, consulte [Configuración de los registros de Amazon ECS para conseguir un alto rendimiento](firelens-docker-buffer-limit.md). # Configuración de los registros de Amazon ECS para conseguir un alto rendimiento Para escenarios de alto rendimiento de registros, recomendamos utilizar el controlador de registro `awsfirelens` con Firelens y Fluent Bit. Fluent Bit es un procesador de registro ligero que es eficiente con los recursos y puede gestionar millones de registros. Sin embargo, para lograr un rendimiento óptimo a escala es necesario ajustar su configuración. En esta sección se describen las técnicas de optimización de Fluent Bit avanzadas para gestionar un alto rendimiento de los registros y, al mismo tiempo, mantener la estabilidad del sistema y garantizar que no se pierdan datos. Para obtener información acerca de cómo utilizar archivos de configuración personalizados con FireLens, consulte [Uso de un archivo de configuración personalizado](firelens-taskdef.md#firelens-taskdef-customconfig). Para ver más ejemplos, consulte [Ejemplos de FireLens en Amazon ECS](https://github.com/aws-samples/amazon-ecs-firelens-examples) en GitHub. **nota** Algunas opciones de configuración de esta sección, como `workers` y `threaded`, requieren AWS para la versión 3 o posterior de Fluent Bit. Para obtener información sobre las versiones disponibles, consulte [Versiones de AWS para Fluent Bit](https://github.com/aws/aws-for-fluent-bit/releases). ## Utilizar el almacenamiento en búfer del sistema de archivos De forma predeterminada, Fluent Bit almacena en búfer todos los datos de la memoria. Cuando los datos se ingieren más rápido de lo que pueden transferirse a las salidas, el búfer se llena. Una vez lleno, el complemento de entrada se detiene hasta que hay espacio disponible en el búfer, lo que puede provocar una contrapresión y ralentizar la aplicación. Para escenarios de alto rendimiento, recomendamos utilizar el almacenamiento en búfer del sistema de archivos. Para obtener más información sobre cómo Fluent Bit gestiona el almacenamiento en búfer y el almacenamiento, consulte [Almacenamiento en búfer y almacenamiento en la documentación](https://docs.fluentbit.io/manual/administration/buffering-and-storage) de Fluent Bit. El uso del almacenamiento en búfer del sistema de archivos proporciona los siguientes beneficios: + **Mayor capacidad de búfer**: el espacio en disco suele ser más abundante que la memoria. + **Persistencia**: los datos almacenados en búfer sobreviven a los reinicios de Fluent Bit. + **Degradación gradual**: durante los errores de salida, los datos se acumulan en el disco en lugar de agotar la memoria. Para activar el almacenamiento en búfer del sistema de archivos, proporciona un archivo de configuración personalizado de Fluent Bit. A continuación se muestra un ejemplo de configuración recomendada: ``` [SERVICE] # Flush logs every 1 second Flush 1 # Wait 120 seconds during shutdown to flush remaining logs Grace 120 # Directory for filesystem buffering storage.path /var/log/flb-storage/ # Limit chunks stored 'up' in memory (reduce for memory-constrained environments) storage.max_chunks_up 32 # Flush backlog chunks to destinations during shutdown (prevents log loss) storage.backlog.flush_on_shutdown On [INPUT] Name forward unix_path /var/run/fluent.sock # Run input in separate thread to prevent blocking threaded true # Enable filesystem buffering for persistence storage.type filesystem [OUTPUT] Name cloudwatch_logs Match * region us-west-2 log_group_name /aws/ecs/my-app log_stream_name $(ecs_task_id) # Use multiple workers for parallel processing workers 2 # Retry failed flushes up to 15 times retry_limit 15 # Maximum disk space for buffered data for this output storage.total_limit_size 10G ``` Parámetros principales de configuración: `storage.path` El directorio donde Fluent Bit almacena los fragmentos almacenados en búfer en el disco. `storage.backlog.flush_on_shutdown` Cuando está activado, Fluent Bit intenta vaciar todos los fragmentos del sistema de archivos pendientes y llevarlos a sus destinos durante el apagado. Esto ayuda a garantizar la entrega de los datos antes de que Fluent Bit se detenga, pero puede aumentar el tiempo de apagado. `storage.max_chunks_up` El número de fragmentos que permanecen en la memoria. El valor predeterminado es de 128 fragmentos, que pueden consumir más de 500 MB de memoria, ya que cada bloque puede utilizar entre 4 y 5 MB. En entornos con limitaciones de memoria, reduzca este valor. Por ejemplo, si tiene 50 MB disponibles para almacenar en búfer, configúrelo entre 8 y 10 fragmentos. `storage.type filesystem` Active el almacenamiento en el sistema de archivos para el complemento de entrada. A pesar del nombre, Fluent Bit utiliza `mmap` para asignar fragmentos tanto en la memoria como en el disco, lo que proporciona persistencia sin sacrificar el rendimiento. `threaded true` Ejecuta la entrada en su propio hilo, separado del bucle de eventos principal de Fluent Bit. Esto evita que las entradas lentas bloqueen toda la canalización. ## Optimizar configuración de salida Los problemas de red, las interrupciones del servicio y la limitación del destino pueden impedir que se entreguen los registros. La configuración de salida adecuada garantiza la resiliencia sin pérdida de datos. Cuando se produce un error al vaciar la salida, Fluent Bit puede volver a intentar la operación. Los clústeres de la región pueden obtener los siguientes beneficios. `retry_limit` El número máximo de reintentos antes de eliminar registros. El valor predeterminado es 1. Para los entornos de producción, recomendamos 15 o más, lo que cubre varios minutos de interrupción con un retraso exponencial. `scheduler.base` El mínimo de segundos entre reintentos. Recomendamos 10 segundos. `scheduler.cap` El máximo de segundos entre reintentos cuando se utiliza un retroceso exponencial. Recomendamos 60 segundos. `workers` El número de hilos para el procesamiento de salida en paralelo. Varios trabajos permiten vaciados concurrentes, lo que mejora el rendimiento al procesar muchos fragmentos. El parámetro `Grace` de la sección `[SERVICE]` establece el tiempo de espera de Fluent Bit durante el apagado para vaciar los datos almacenados en el búfer. El período de `Grace` debe coordinarse con el valor de `stopTimeout` del contenedor. Asegúrese de que el valor `stopTimeout` supere el período `Grace` para permitir que Fluent Bit complete la descarga antes de recibir `SIGKILL`. Por ejemplo, si el valor de `Grace` es de 120 segundos, establezca el de `stopTimeout` en 150 segundos. El siguiente ejemplo muestra una configuración de Fluent Bit completa con todos los ajustes recomendados para escenarios de alto rendimiento: ``` [SERVICE] # Flush logs every 1 second Flush 1 # Wait 120 seconds during shutdown to flush remaining logs Grace 120 # Directory for filesystem buffering storage.path /var/log/flb-storage/ # Limit chunks stored 'up' in memory (reduce for memory-constrained environments) storage.max_chunks_up 32 # Flush backlog chunks to destinations during shutdown (prevents log loss) storage.backlog.flush_on_shutdown On # Minimum seconds between retries scheduler.base 10 # Maximum seconds between retries (exponential backoff cap) scheduler.cap 60 [INPUT] Name forward unix_path /var/run/fluent.sock # Run input in separate thread to prevent blocking threaded true # Enable filesystem buffering for persistence storage.type filesystem [OUTPUT] Name cloudwatch_logs Match * region us-west-2 log_group_name /aws/ecs/my-app log_stream_name $(ecs_task_id) # Use multiple workers for parallel processing workers 2 # Retry failed flushes up to 15 times retry_limit 15 # Maximum disk space for buffered data for this output storage.total_limit_size 10G ``` ## Utilice el registro multidestino para garantizar la fiabilidad El envío de registros a varios destinos elimina los puntos únicos de error. Por ejemplo, si Registros de CloudWatch sufre una interrupción, los registros seguirán llegando a Amazon S3. El registro multidestino ofrece los siguientes beneficios. El complemento de salida de Amazon S3 también admite opciones de compresión como los formatos .gzip y Parquet, lo que puede reducir los costos de almacenamiento. Para obtener más información, consulte [Compresión de S3](https://docs.fluentbit.io/manual/pipeline/outputs/s3#compression) en la documentación de Fluent Bit. El registro multidestino puede ofrecer los siguientes beneficios: + **Redundancia**: si un destino falla, los registros siguen llegando al otro. + **Recuperación**: reconstruya las brechas en un sistema respecto al otro. + **Durabilidad**: archive registros en Amazon S3 para la retención a largo plazo. + **Optimización de costos**: guarde los registros recientes en un servicio de consultas rápido como Registros de CloudWatch con una retención más corta y, al mismo tiempo, archive todos los registros en un almacenamiento de Amazon S3 de menor costo para conservarlos a largo plazo. La siguiente configuración de Fluent Bit envía registros tanto a Registros de CloudWatch como a Amazon S3: ``` [OUTPUT] Name cloudwatch_logs Match * region us-west-2 log_group_name /aws/ecs/my-app log_stream_name $(ecs_task_id) workers 2 retry_limit 15 [OUTPUT] Name s3 Match * bucket my-logs-bucket region us-west-2 total_file_size 100M s3_key_format /fluent-bit-logs/$(ecs_task_id)/%Y%m%d/%H/%M/$UUID upload_timeout 10m # Maximum disk space for buffered data for this output storage.total_limit_size 5G ``` Ambas salidas utilizan el mismo patrón de `Match *`, por lo que todos los registros se envían a ambos destinos de forma independiente. Durante una interrupción en un destino, los registros siguen fluyendo hacia el otro, mientras que las descargas fallidas se acumulan en el búfer del sistema de archivos para volver a intentarlo más adelante. ## Utilice el registro basado en archivos con el complemento de entrada trasera Para escenarios de alto rendimiento en los que la pérdida de registros es un problema fundamental, puede utilizar un enfoque alternativo: haga que la aplicación escriba los registros en los archivos del disco y configure Fluent Bit para leerlos mediante el complemento de entrada `tail`. Este enfoque evita por completo la capa del controlador de registro de Docker. El registro basado en archivos con el complemento de entrada trasera proporciona los siguientes beneficios: + **Seguimiento del desplazamiento**: el complemento de entrada trasera puede almacenar los desplazamientos de los archivos en un archivo de base de datos (mediante la opción `DB`), lo que proporciona durabilidad tras los reinicios de Fluent Bit. Esto ayuda a evitar la pérdida de registros al reiniciar el contenedor. + **Almacenamiento en búfer a nivel de entrada**: puede configurar los límites del búfer de memoria directamente en el complemento de entrada mediante `Mem_Buf_Limit`, lo que proporciona un control más detallado del uso de la memoria. + **Evita la sobrecarga de Docker**: los registros pasan directamente de un archivo a Fluent Bit, sin pasar por los búferes de registro de Docker. Para utilizar este enfoque, la aplicación debe escribir los registros en los archivos en lugar de hacerlo `stdout`. Tanto el contenedor de aplicaciones como el contenedor de Fluent Bit montan un volumen compartido donde se almacenan los archivos de registro. El siguiente ejemplo muestra una configuración de entrada secundaria con las mejores prácticas: ``` [INPUT] Name tail # File path or glob pattern to tail Path /var/log/app.log # Database file for storing file offsets (enables resuming after restart) DB /var/log/flb_tail.db # when true, controls that only fluent-bit will access the database (improves performance) DB.locking true # Skip long lines instead of skipping the entire file Skip_Long_Lines On # How often (in seconds) to check for new files matching the glob pattern Refresh_Interval 10 # Extra seconds to monitor a file after rotation to account for pending flush Rotate_Wait 30 # Maximum size of the buffer for a single line Buffer_Max_Size 10MB # Initial allocation size for reading file data Buffer_Chunk_Size 1MB # Maximum memory buffer size (tail pauses when full) Mem_Buf_Limit 75MB ``` Cuando utilice el complemento de entrada trasera, tenga en cuenta lo siguiente: + Implemente la rotación de registros en los registros de sus aplicaciones para evitar que se agote el disco. Supervise las métricas de volumen subyacentes para medir el rendimiento. + Considere configuraciones como `Ignore_Older`, `Read_from_Head` y analizadores multilínea según el formato de registro. Para obtener más información, consulte [Entrada trasera](https://docs.fluentbit.io/manual/pipeline/inputs/tail) en la documentación de Fluent Bit. Si desea conocer las prácticas recomendadas, consulte la sección [Configuración de entrada trasera con las prácticas recomendadas](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#tail-config-with-best-practices) en la guía de solución de problemas de AWS para Fluent Bit. ## Iniciar sesión directamente en FireLens Cuando se especifica el controlador de registros `awsfirelens` en una definición de tarea, el agente de contenedor de Amazon ECS introduce las siguientes variables de entorno en el contenedor: `FLUENT_HOST` La dirección IP que está asignada al contenedor FireLens. Si utiliza EC2 con el modo de red `bridge`, la variable de entorno `FLUENT_HOST` del contenedor de aplicaciones puede dejar de ser precisa tras reiniciar el contenedor del router de registro de FireLens (el contenedor con el objeto `firelensConfiguration` en su definición de contenedor). Esto se debe a que `FLUENT_HOST` es una dirección IP dinámica y puede cambiar tras un reinicio. El registro directo desde el contenedor de la aplicación en la dirección IP `FLUENT_HOST` puede empezar a fallar después de que la dirección cambie. Para obtener más información acerca de cómo reiniciar contenedores individuales, consulte [Reinicio de contenedores individuales en tareas de Amazon ECS con políticas de reinicio de contenedores](container-restart-policy.md). `FLUENT_PORT` El puerto en el que se está escuchando el protocolo Fluent Forward. Puede utilizar estas variables de entorno para enviar registros directamente al enrutador de registro de Fluent Bit desde el código de su aplicación mediante el protocolo Fluent Forward, en lugar de escribir en `stdout`. Este enfoque evita la capa de controladores de registro de Docker, lo que proporciona las siguientes ventajas: + **Menor latencia**: los registros se transfieren directamente a Fluent Bit sin pasar por la infraestructura de registro de Docker. + **Registro estructurado**: envíe datos de registro estructurados de forma nativa sin sobrecargas de codificación JSON. + **Mejor control**: su aplicación puede implementar su propia lógica de almacenamiento en búfer y gestión de errores. Las siguientes bibliotecas de registradores de Fluent son compatibles con el protocolo Fluent Forward y se pueden utilizar para enviar los registros directamente a Fluent Bit: + **Go**: [fluent-logger-golang](https://github.com/fluent/fluent-logger-golang) + **Python**: [fluent-logger-python](https://github.com/fluent/fluent-logger-python) + **Java**: [fluent-logger-java](https://github.com/fluent/fluent-logger-java) + **Node.js**: [fluent-logger-node](https://github.com/fluent/fluent-logger-node) + **Ruby**: [fluent-logger-ruby](https://github.com/fluent/fluent-logger-ruby) ## Configurar el límite de búfer de Docker Al crear una definición de tareas, puede indicar el número de líneas de registro que se almacenan en búfer en la memoria mediante la especificación del valor en `log-driver-buffer-limit`. Esto controla el búfer entre Docker y Fluent Bit. Para obtener más información, consulte [Controladores de registro Fluentd](https://docs.docker.com/engine/logging/drivers/fluentd/) en la documentación de Docker. Utilice esta opción cuando haya un alto rendimiento, ya que Docker podría quedarse sin memoria de búfer y descartar mensajes de búfer para poder agregar nuevos mensajes. Tenga en cuenta lo siguiente cuando utilice esta opción: + Esta opción se admite en el tipo de EC2 y de Fargate con la versión de la plataforma `1.4.0` o posterior. + La opción solo es válida cuando `logDriver` se establece en `awsfirelens`. + El límite de búfer predeterminado es de `1048576` líneas de registro. + El límite del búfer debe ser igual o mayor que `0` y menor que las líneas de registro `536870912`. + La cantidad máxima de memoria utilizada para este búfer es el producto del tamaño de cada línea de registro y el tamaño del búfer. Por ejemplo, si las líneas de registro de la aplicación tienen un promedio de `2` KiB, un límite de búfer de 4096 utilizaría como máximo `8` MiB. La cantidad total de memoria asignada a nivel de tarea debe ser superior a la cantidad de memoria asignada a todos los contenedores, además del búfer de memoria del controlador de registro. La siguiente definición de tarea muestra cómo configurar `log-driver-buffer-limit`: ``` { "containerDefinitions": [ { "name": "my_service_log_router", "image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3", "cpu": 0, "memoryReservation": 51, "essential": true, "firelensConfiguration": { "type": "fluentbit" } }, { "essential": true, "image": "public.ecr.aws/docker/library/httpd:latest", "name": "app", "logConfiguration": { "logDriver": "awsfirelens", "options": { "Name": "firehose", "region": "us-west-2", "delivery_stream": "my-stream", "log-driver-buffer-limit": "52428800" } }, "dependsOn": [ { "containerName": "my_service_log_router", "condition": "START" } ], "memoryReservation": 100 } ] } ``` # AWS para repositorios de imágenes de Fluent Bit para Amazon ECS AWS proporciona una imagen de Fluent Bit con complementos para Registros de CloudWatch y Firehose. Recomendamos usar Fluent Bit como router de registro porque tiene una tasa de utilización de recursos más baja que Fluentd. Para obtener más información, consulte [CloudWatch Logs para Fluent Bit](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) y [Amazon Kinesis Firehose para Fluent Bit](https://github.com/aws/amazon-kinesis-firehose-for-fluent-bit). La imagen de **AWS para Fluent Bit** está disponible en Galería pública de Amazon ECR y en un repositorio de Amazon ECR para lograr una alta disponibilidad. ## Galería pública de Amazon ECR La imagen de AWS para Fluent Bit está disponible en la galería pública de Amazon ECR. Esta es la ubicación recomendada para descargar la imagen de AWS para Fluent Bit, ya que es un repositorio público y está disponible para su uso desde todas las Regiones de AWS. Para obtener más información, consulte [aws-por-fluent-bit](https://gallery.ecr.aws/aws-observability/aws-for-fluent-bit) en la galería pública de Amazon ECR. ### Linux La imagen de AWS para Fluent Bit de la galería pública de Amazon ECR es compatible con el sistema operativo Amazon Linux con la arquitectura `ARM64` o `x86-64`. Para extraer la imagen de AWS para Fluent Bit de la galería pública de Amazon ECR, puede especificar la URL del repositorio con la etiqueta de imagen deseada. Para ver las etiquetas de imágenes disponibles, consulte la pestaña **Image tags** (Etiquetas de imágenes) en la galería pública de Amazon ECR. A continuación, se muestra la sintaxis que se debe usar para la CLI de Docker. ``` docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag ``` Por ejemplo, puede extraer la imagen más reciente de la familia “3.x” de versiones de AWS para Fluent Bit mediante este comando de la CLI de Docker. ``` docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3 ``` **nota** Se permiten extracciones sin autenticación, pero tienen un límite de tasa inferior al de las extracciones autenticadas. Para autenticar el uso de la cuenta de AWS antes de la extracción, utilice el comando a continuación. ``` aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws ``` #### AWS para Fluent Bit 3.0.0 Además de las versiones `2.x` existentes de AWS para Fluent Bit, AWS para Fluent Bit admite una nueva versión `3.x` principal. La nueva versión principal incluye la actualización de imágenes de Amazon Linux 2 a Amazon Linux 2023 y de la versión de Fluent Bit `1.9.10` a la `4.1.1`. Para obtener más información, consulte el [repositorio de AWS para Fluent Bit](https://github.com/aws/aws-for-fluent-bit/blob/mainline/VERSIONS.md) en GitHub. En los ejemplos siguientes se muestran las etiquetas actualizadas de las imágenes de AWS para Fluent Bit `3.x`. Puede utilizar etiquetas de la arquitectura múltiple para la imagen de AWS para Fluent Bit. ``` docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3 ``` ### Windows La imagen Fluent Bit de AWS de la galería pública de Amazon ECR es compatible con la arquitectura `AMD64` con los siguientes sistemas operativos: + Windows Server 2022 Full + Windows Server 2022 Core + Windows Server 2019 Full + Windows Server 2019 Core Los contenedores de Windows que están en AWS Fargate no admiten FireLens. Para extraer la imagen de AWS para Fluent Bit de la galería pública de Amazon ECR, puede especificar la URL del repositorio con la etiqueta de imagen deseada. Para ver las etiquetas de imágenes disponibles, consulte la pestaña **Image tags** (Etiquetas de imágenes) en la galería pública de Amazon ECR. A continuación, se muestra la sintaxis que se debe usar para la CLI de Docker. ``` docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag ``` Por ejemplo, para extraer la imagen de AWS para Fluent Bit estable más nueva, puede utilizar este comando de la CLI de Docker. ``` docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:windowsservercore-stable ``` **nota** Se permiten extracciones sin autenticación, pero tienen un límite de tasa inferior al de las extracciones autenticadas. Para autenticar el uso de la cuenta de AWS antes de la extracción, utilice el comando a continuación. ``` aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws ``` ## Amazon ECR La imagen de AWS para Fluent Bit está disponible en Amazon ECR para lograr alta disponibilidad. Los comandos siguientes se pueden utilizar para recuperar los URI de las imágenes y establecer la disponibilidad de las imágenes en una Región de AWS determinada. ### Linux Para recuperar la URI de la imagen de AWS para Fluent Bit más estable, utilice el siguiente comando. ``` aws ssm get-parameters \ --names /aws/service/aws-for-fluent-bit/stable \ --region us-east-1 ``` Para obtener una lista de todas las versiones de la imagen de AWS para Fluent Bit y consultar el parámetro del Parameter Store de Systems Manager, utilice el siguiente comando. ``` aws ssm get-parameters-by-path \ --path /aws/service/aws-for-fluent-bit \ --region us-east-1 ``` Para consultar la imagen de AWS para Fluent Bit estable más nueva en una plantilla de CloudFormation, puede hacer referencia al nombre del almacén de parámetros de Systems Manager. A continuación, se muestra un ejemplo: ``` Parameters: FireLensImage: Description: Fluent Bit image for the FireLens Container Type: AWS::SSM::Parameter::Value Default: /aws/service/aws-for-fluent-bit/stable ``` **nota** Si se produce un error en el comando o no hay ningún resultado, la imagen no está disponible en la Región de AWS en la que se llama al comando. ### Windows Para recuperar la URI de la imagen de AWS para Fluent Bit más estable, utilice el siguiente comando. ``` aws ssm get-parameters \ --names /aws/service/aws-for-fluent-bit/windowsservercore-stable \ --region us-east-1 ``` Para obtener una lista de todas las versiones de la imagen de AWS para Fluent Bit y consultar el parámetro del Parameter Store de Systems Manager, utilice el siguiente comando. ``` aws ssm get-parameters-by-path \ --path /aws/service/aws-for-fluent-bit/windowsservercore \ --region us-east-1 ``` Para consultar la imagen de AWS para Fluent Bit más estable en una plantilla de CloudFormation, puede hacer referencia al nombre del Parameter Store de Systems Manager. A continuación, se muestra un ejemplo: ``` Parameters: FireLensImage: Description: Fluent Bit image for the FireLens Container Type: AWS::SSM::Parameter::Value Default: /aws/service/aws-for-fluent-bit/windowsservercore-stable ``` # Definición de tareas de Amazon ECS de ejemplo: enrutar registros a FireLens Para utilizar el enrutamiento de registros personalizado con FireLens, debe especificar lo siguiente en la definición de tareas: + Un contenedor del enrutador de registros que incluye una configuración de FireLens. Recomendamos que el contenedor se marque como `essential`. + Uno o varios contenedores de aplicaciones que incluyen una configuración de registro que especifica el controlador de registros `awsfirelens`. + Un nombre de recurso de Amazon (ARN) de rol de IAM de tarea que incluya los permisos necesarios para que la tarea envíe los registros. Al crear una nueva definición de tarea mediante la Consola de administración de AWS, hay una sección de integración de FireLens que permite añadir fácilmente un contenedor de router de registros. Para obtener más información, consulte [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md). Amazon ECS convierte la configuración de registros y genera la configuración de salida de Fluentd o Fluent Bit. La configuración de salida se monta en el contenedor de enrutamiento de registros en `/fluent-bit/etc/fluent-bit.conf` para Fluent Bit y `/fluentd/etc/fluent.conf` para Fluentd. **importante** FireLens escucha en el puerto `24224`. Por lo tanto, para asegurarse de que el direccionador de registros FireLens no sea accesible fuera de la tarea, debe permitir la entrada de tráfico en el puerto `24224` en el grupo de seguridad que utiliza la tarea. Para tareas que utilizan el modo de red `awsvpc`, es el grupo de seguridad asociado a la tarea. Para tareas que utilizan el modo de red `host`, es el grupo de seguridad asociado a la instancia de Amazon EC2 que aloja la tarea. Para tareas que utilizan el modo de red `bridge`, no cree asignaciones de puertos que utilicen el puerto `24224`. De forma predeterminada, Amazon ECS agrega campos adicionales a las entradas de registro, que ayudan a identificar su origen. + `ecs_cluster`: el nombre del clúster del que forma parte la tarea. + `ecs_task_arn`: nombre de recurso de Amazon (ARN) de la tarea de la que el contenedor forma parte. + `ecs_task_definition`: el nombre y la revisión de la definición de tareas que utiliza la tarea. + `ec2_instance_id`: el ID de la instancia de Amazon EC2 en la que está alojado el contenedor. Este campo solo es válido para las tareas que utilizan el tipo de lanzamiento EC2. Puede establecer `enable-ecs-log-metadata` en `false` si no quiere los metadatos. En el siguiente ejemplo de definición de tarea, se define un contenedor de enrutamiento de registros que utiliza Fluent Bit para enrutar sus registros a CloudWatch Logs. También define un contenedor de aplicaciones que utiliza una configuración de registros para dirigirlos a Amazon Data Firehose y establecer en 2 MiB la memoria que se utiliza para guardar en búfer los eventos. **nota** Para ver más ejemplos de definiciones de tareas, consulte [Ejemplos de FireLens en Amazon ECS](https://github.com/aws-samples/amazon-ecs-firelens-examples) en GitHub. ``` { "family": "firelens-example-firehose", "taskRoleArn": "arn:aws:iam::123456789012:role/ecs_task_iam_role", "containerDefinitions": [ { "name": "log_router", "image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3", "cpu": 0, "memoryReservation": 51, "portMappings": [], "essential": true, "environment": [], "mountPoints": [], "volumesFrom": [], "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-group": "/ecs/ecs-aws-firelens-sidecar-container", "mode": "non-blocking", "awslogs-create-group": "true", "max-buffer-size": "25m", "awslogs-region": "us-east-1", "awslogs-stream-prefix": "firelens" }, "secretOptions": [] }, "systemControls": [], "firelensConfiguration": { "type": "fluentbit" } }, { "essential": true, "image": "public.ecr.aws/docker/library/httpd:latest", "name": "app", "logConfiguration": { "logDriver": "awsfirelens", "options": { "Name": "firehose", "region": "us-west-2", "delivery_stream": "my-stream", "log-driver-buffer-limit": "1048576" } }, "memoryReservation": 100 } ] } ``` Los pares de clave-valor especificados como opciones en el objeto `logConfiguration` se utilizan para generar la configuración de salida de Fluentd o Fluent Bit. A continuación, se muestra un ejemplo de código de una definición de salida de Fluent Bit. ``` [OUTPUT] Name firehose Match app-firelens* region us-west-2 delivery_stream my-stream ``` **nota** FireLens administra la configuración `match`. No se especifica la configuración de `match` en la definición de tarea. ## Uso de un archivo de configuración personalizado Puede especificar un archivo de configuración personalizado. El formato del archivo de configuración es el formato nativo del enrutador de registros que está utilizando. Para obtener más información, consulte [Fluentd Config File Syntax](https://docs.fluentd.org/configuration/config-file) y [YAML Configuration](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/yaml). En el archivo de configuración personalizado, en el caso de las tareas que utilizan el modo de red `bridge` o `awsvpc`, no establezca una entrada directa Fluentd o Fluent Bit a través de TCP porque FireLens la agrega a la configuración de entrada. La configuración de FireLens debe incluir las siguientes opciones para especificar un archivo de configuración personalizado: `config-file-type` La ubicación de origen del archivo de configuración personalizado. Las opciones disponibles son `s3` o `file`. Las tareas que están alojadas en AWS Fargate solo admiten el tipo de archivo de configuración `file`. Sin embargo, puede usar los archivos de configuración alojados en Amazon S3 en AWS Fargate mediante el contenedor init de AWS para Fluent Bit. Para obtener más información, consulte [Proceso de init para Fluent Bit en ECS, compatibilidad con configuraciones múltiples](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md) en GitHub. `config-file-value` El origen del archivo de configuración personalizado. Si se utiliza el tipo de archivo de configuración `s3`, el valor del archivo de configuración es el ARN completo del bucket y el archivo de Amazon S3. Si se utiliza el tipo de archivo de configuración `file`, el valor del archivo de configuración es la ruta completa del archivo de configuración que existe en la imagen del contenedor o en un volumen que se monta en el contenedor. Cuando se utilice un archivo de configuración personalizado, se debe especificar una ruta diferente a la que utiliza FireLens. Amazon ECS reserva la ruta de archivo `/fluent-bit/etc/fluent-bit.conf` para Fluent Bit y la `/fluentd/etc/fluent.conf` para Fluentd. En el ejemplo siguiente se muestra la sintaxis necesaria al especificar una configuración personalizada. **importante** Para especificar un archivo de configuración personalizado alojado en Amazon S3, asegúrese de haber creado un rol de IAM de ejecución de tareas con los permisos adecuados. A continuación se muestra la sintaxis necesaria al especificar una configuración personalizada. ``` { "containerDefinitions": [ { "essential": true, "image": "906394416424.dkr.ecr.us-west-2.amazonaws.com/aws-for-fluent-bit:3", "name": "log_router", "firelensConfiguration": { "type": "fluentbit", "options": { "config-file-type": "s3 | file", "config-file-value": "arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf | filepath" } } } ] } ``` **nota** Las tareas alojadas en AWS Fargate solo admiten el tipo de archivo de configuración `file`. Sin embargo, puede usar los archivos de configuración alojados en Amazon S3 en AWS Fargate mediante el contenedor init de AWS para Fluent Bit. Para obtener más información, consulte [Proceso de init para Fluent Bit en ECS, compatibilidad con configuraciones múltiples](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md) en GitHub. # Uso de imágenes de contenedor que no sean de AWS en Amazon ECS Utilice el registro privado para almacenar las credenciales en AWS Secrets Manager y hacer referencia a ellas en la definición de tarea. Esto proporciona una forma de hacer referencia a las imágenes de contenedores que existen en registros privados fuera de AWS que requieren autenticación en las definiciones de tareas. Esta función es compatible con tareas alojadas en Fargate, Amazon EC2 instances (Instancias de Amazon EC2) e instancias externas que utilizan Amazon ECS Anywhere. **importante** Si la definición de la tarea hace referencia a una imagen que está almacenada en Amazon ECR, este tema no es válido. Para obtener más información, consulte [Utilización de imágenes de Amazon ECR con Amazon ECS](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) en la *Guía del usuario de Amazon Elastic Container Registry*. Para las tareas alojadas en instancias de Amazon EC2, esta característica requiere la versión `1.19.0` del agente de contenedor o una posterior. No obstante, recomendamos utilizar la versión del agente de contenedor más reciente. Para obtener información acerca de cómo comprobar la versión del agente y actualizar a la versión más reciente, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md). Para las tareas alojadas en Fargate, esta función requiere la versión de plataforma `1.2.0` o posterior. Para obtener más información, consulte [Versiones de la plataforma Fargate para Amazon ECS](platform-fargate.md). En la definición de contenedor, especifique el objeto `repositoryCredentials` con los detalles del secreto que ha creado. El secreto al que se hace referencia puede proceder de una Región de AWS o cuenta distintas de la tarea que lo utiliza. **nota** Cuando se utiliza la API de Amazon ECS, la AWS CLI o el SDK de AWS, si el secreto existe en la misma Región de AWS que la tarea que se va a lanzar, se puede utilizar el ARN completo o el nombre del secreto. Si el secreto existe en otra cuenta, debe especificarse el ARN completo del secreto. Cuando se utiliza la Consola de administración de AWS, siempre debe especificarse el ARN completo del secreto. A continuación, se incluye un fragmento de definición de tareas que muestra los parámetros necesarios: Sustituya los siguientes parámetros: + *private-repo* con el nombre de host del repositorio privado + *private-image* con el nombre de la imagen + *arn:aws:secretsmanager:region:aws\$1account\$1id:secret:secret\$1name* con el nombre de recurso de Amazon (ARN) secreto ``` "containerDefinitions": [ { "image": "private-repo/private-image", "repositoryCredentials": { "credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name" } } ] ``` **nota** Otro método para habilitar la autenticación de registros privados consiste en utilizar las variables de entorno del agente de contenedor de Amazon ECS para la autenticación en registros privados. Este método solo se admite para tareas alojadas en Amazon EC2 instances (Instancias de Amazon EC2). Para obtener más información, consulte [Configuración de instancias de contenedor de Amazon ECS para imágenes de Docker privadas](private-auth-container-instances.md). **Para utilizar el registro privado** 1. La definición de tareas debe tener un rol de ejecución de tareas. Esto permite que el agente de contenedor extraiga la imagen del contenedor. Para obtener más información, consulte [Rol de IAM de ejecución de tareas de Amazon ECS](task_execution_IAM_role.md). La autenticación de registro privado permite que sus tareas de Amazon ECS obtengan imágenes de contenedores de registros privados externos a AWS (como Docker Hub, Quay.io, o su propio registro privado) que requieren credenciales de autenticación. Esta característica utiliza Secrets Manager para almacenar de forma segura las credenciales de registro, que luego se referencian en la definición de la tarea mediante el parámetro `repositoryCredentials`. Para obtener más información sobre la configuración de la autenticación de registro privado, consulte [Uso de imágenes de contenedor no AWS en Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html). Para proporcionar acceso a los secretos que contienen las credenciales de su registro privado, agregue los siguientes permisos como una política insertada al rol de ejecución de tareas. Para obtener más información, consulte [Adición y eliminación de políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html). + `secretsmanager:GetSecretValue`: obligatorio para recuperar las credenciales de registro privado de Secrets Manager. + `kms:Decrypt`: obligatorio solo si el secreto utiliza una clave de KMS personalizada y no la clave predeterminada. Se debe agregar el nombre de recurso de Amazon (ARN) de la clave de personalizada como un recurso. Es siguiente es un ejemplo de política insertada que agrega los permisos. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Decrypt", "secretsmanager:GetSecretValue" ], "Resource": [ "arn:aws:secretsmanager:us-east-1:111122223333:secret:secret_name", "arn:aws:kms:us-east-1:111122223333:key/key_id" ] } ] } ``` ------ 1. Utilice AWS Secrets Manager para crear un secreto para sus credenciales de registros privados. Para obtener información acerca de la creación de un secreto, consulte [Create an AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) en la *Guía del usuario de AWS Secrets Manager*. Ingrese las credenciales de registros privados con el siguiente formato: ``` { "username" : "privateRegistryUsername", "password" : "privateRegistryPassword" } ``` 1. Registre una definición de tareas. Para obtener más información, consulte [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md). # Reinicio de contenedores individuales en tareas de Amazon ECS con políticas de reinicio de contenedores Puede habilitar las políticas de reinicio para los contenedores esenciales y no esenciales definidas en la definición de su tarea para superar los errores transitorios con mayor rapidez y mantener la disponibilidad de las tareas. Al habilitar una política de reinicio para un contenedor, Amazon ECS puede reiniciar el contenedor si se cierra, sin necesidad de reemplazar la tarea. Las políticas de reinicio no están habilitadas para los contenedores de forma predeterminada. Al habilitar una política de reinicio para un contenedor, puede especificar códigos de salida en los que no se reiniciará el contenedor. Pueden ser códigos de salida que indican que la realización ha sido correcta, como códigos de salida `0`, que no requieren un reinicio. También puede especificar durante cuánto tiempo debe funcionar correctamente un contenedor antes de intentar su reinicio. Para obtener más información sobre estos parámetros, consulte [Política de reinicio](task_definition_parameters.md#container_definition_restart_policy). Para ver un ejemplo de definición de tarea que especifique estos valores, consulte [Especificación de una política de reinicio de contenedor en una definición de tarea de Amazon ECS](container-restart-policy-example.md). Puede utilizar el punto de conexión de metadatos de tareas de Amazon ECS o CloudWatch Container Insights para supervisar el número de veces que se ha reiniciado un contenedor. Para más información sobre el punto de conexión de los metadatos de la tarea, consulte [Versión 4 del punto de conexión de metadatos de tareas de Amazon ECS](task-metadata-endpoint-v4.md) y [Versión 4 del punto de conexión de los metadatos de tareas de Amazon ECS para tareas en Fargate](task-metadata-endpoint-v4-fargate.md). Para obtener más información sobre las métricas de Container Insights, consulte [Métricas de Amazon ECS Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html) en la *Guía del usuario de Amazon CloudWatch*. Las políticas de reinicio del contenedor son compatibles con tareas alojadas en Fargate, Instancias de Amazon EC2 e instancias externas que utilizan Amazon ECS Anywhere. ## Consideraciones Tenga en cuenta lo siguiente antes de habilitar una política de reinicio para su contenedor: + Las políticas de reinicio no son compatibles con contenedores de Windows en Fargate. + Para las tareas alojadas en instancias de Amazon EC2, esta característica requiere la versión `1.86.0` del agente de contenedor o una posterior. No obstante, recomendamos utilizar la versión del agente de contenedor más reciente. Para obtener información acerca de cómo comprobar la versión del agente y actualizar a la versión más reciente, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md). + Si utiliza EC2 con el modo de red `bridge`, la variable de entorno `FLUENT_HOST` del contenedor de aplicaciones puede dejar de ser precisa tras reiniciar el contenedor del router de registro de FireLens (el contenedor con el objeto `firelensConfiguration` en su definición de contenedor). Esto se debe a que `FLUENT_HOST` es una dirección IP dinámica y puede cambiar tras un reinicio. El registro directo desde el contenedor de la aplicación en la dirección IP `FLUENT_HOST` puede empezar a fallar después de que la dirección cambie. Para obtener más información acerca de `FLUENT_HOST`, consulte [Configuración de los registros de Amazon ECS para conseguir un alto rendimiento](firelens-docker-buffer-limit.md). + El agente de Amazon ECS gestiona las políticas de reinicio de contenedores. Si, por alguna razón inesperada, el agente de Amazon ECS falla o deja de ejecutarse, el contenedor no se reiniciará. + El período de intento de reinicio definido en su política determina el período de tiempo (en segundos) que debe funcionar el contenedor antes de que Amazon ECS lo reinicie. # Especificación de una política de reinicio de contenedor en una definición de tarea de Amazon ECS Para especificar una política de reinicio para un contenedor en una definición de tarea, dentro de la definición del contenedor, se debe especificar el objeto `restartPolicy`. Para obtener más información sobre el objeto de nodo `restartPolicy`, consulte [Política de reinicio](task_definition_parameters.md#container_definition_restart_policy). A continuación, se muestra una definición de tarea que utiliza los contenedores Linux en Fargate y que configura un servidor web. La definición del contenedor incluye el objeto `restartPolicy`, y `enabled` establecido en verdadero para habilitar una política de reinicio para el contenedor. El contenedor debe funcionar durante 180 segundos antes del reinicio y no se reiniciará si sale con el código de salida `0`, lo que indica éxito. ``` { "containerDefinitions": [ { "command": [ "/bin/sh -c \"echo ' Amazon ECS Sample App

Amazon ECS Sample App

Congratulations!

Your application is now running on a container in Amazon ECS.

' > /usr/local/apache2/htdocs/index.html && httpd-foreground\"" ], "entryPoint": ["sh", "-c"], "essential": true, "image": "public.ecr.aws/docker/library/httpd:2.4", "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-group": "/ecs/fargate-task-definition", "awslogs-region": "us-east-1", "awslogs-stream-prefix": "ecs" } }, "name": "sample-fargate-app", "portMappings": [ { "containerPort": 80, "hostPort": 80, "protocol": "tcp" } ], "restartPolicy": { "enabled": true, "ignoredExitCodes": [0], "restartAttemptPeriod": 180 } } ], "cpu": "256", "executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole", "family": "fargate-task-definition", "memory": "512", "networkMode": "awsvpc", "runtimePlatform": { "operatingSystemFamily": "LINUX" }, "requiresCompatibilities": ["FARGATE"] } ``` Después de haber registrado una definición de tarea con el objeto `restartPolicy` en una definición de contenedor, puede ejecutar una tarea o crear un servicio con dicha definición de tarea. Para obtener más información, consulte [Ejecución de una aplicación como tarea de Amazon ECS](standalone-task-create.md) y [Creación de una implementación de actualización continua de Amazon ECS](create-service-console-v2.md). # Transferencia de datos confidenciales a un contenedor de Amazon ECS Puede transferir de forma segura datos confidenciales, como las credenciales de una base de datos, a su contenedor. Las aplicaciones suelen utilizar secretos, como las claves de API y las credenciales de las bases de datos, para acceder a otros sistemas. Suelen consistir en un nombre de usuario y una contraseña, un certificado o una clave de API. El acceso a estos secretos debe restringirse a las entidades principales de IAM específicas que utilizan IAM e deben inyectarse en los contenedores durante el tiempo de ejecución. Los secretos se pueden introducir sin problemas en los contenedores desde AWS Secrets Manager y Parameter Store de Amazon EC2 Systems Manager. Puede hacer referencia a estos secretos en su tarea mediante cualquiera de las siguientes formas. 1. Se hace referencia a ellos como variables de entorno que utilizan el parámetro de definición del contenedor de `secrets`. 1. Se hace referencia a ellos como `secretOptions` si su plataforma de registro requiriera autenticación. Para obtener más información, consulte las [opciones de configuración del registro](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html#API_LogConfiguration_Contents). 1. Se hace referencia a ellos como secretos y se extraen mediante imágenes que utilizan el parámetro de definición del contenedor `repositoryCredentials` si el registro del que se extrae el contenedor requiere autenticación. Utilice este método cuando extraiga imágenes de la galería pública de Amazon ECR. Para obtener más información, consulte [Autenticación de registros privados para tareas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html). Se recomienda que realice las siguientes acciones al configurar la administración de secretos. ## Utilización del almacén de parámetros AWS Secrets Manager o AWS Systems Manager para el almacenamiento de materiales secretos Debe almacenar de forma segura las claves de la API, las credenciales de bases de datos y otros materiales secretos en Secrets Manager o como un parámetro cifrado en el almacén de parámetros de Systems Manager. Estos servicios son similares porque ambos son almacenes clave-valor administrados que utilizan AWS KMS para cifrar información confidencial. Secrets Manager, sin embargo, también incluye la capacidad de rotar de forma automática los secretos, generar secretos aleatorios y compartirlos entre las cuentas. Para utilizar estas características, use Secrets Manager. De lo contrario, utilice parámetros cifrados en el Almacén de parámetros de Systems Manager. **importante** Si su secreto cambia, debe forzar una nueva implementación o iniciar una nueva tarea para recuperar el valor secreto más reciente. Para obtener más información, consulte los temas siguientes: Tareas: detenga la tarea y, luego, iníciela. Para obtener más información, consulte [Detención de una tarea de Amazon ECS](standalone-task-stop.md) y [Ejecución de una aplicación como tarea de Amazon ECS](standalone-task-create.md). Servicio: actualice el servicio y utilice la opción de forzar una nueva implementación. Para obtener más información, consulte [Actualización de un servicio de Amazon ECS](update-service-console-v2.md). ## Recuperación de datos de un bucket cifrado de Amazon S3 Debe almacenar los secretos en un bucket cifrado de Amazon S3 y utilizar roles de tareas para restringir el acceso a esos secretos. Esto evita que los valores de las variables de entorno se filtre de manera inadvertida en los registros y se revelen al ejecutar `docker inspect`. De este modo, la aplicación debe escribirse para leer el secreto del bucket de Amazon S3. Para obtener instrucciones, consulte [Establecer el comportamiento predeterminado de cifrado del lado del servidor para buckets de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-encryption.html). ## Montar el secreto en un volumen utilizando un contenedor sidecar Dado que existe un riesgo elevado de filtración de datos con las variables de entorno, debe utilizar un contenedor sidecar que lea sus secretos de AWS Secrets Manager y los escriba en un volumen compartido. Este contenedor puede ejecutarse y salir antes que el contenedor de la aplicación mediante [pedidos de contenedores de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html). De este modo, el contenedor de la aplicación monta posteriormente el volumen en el que se escribió el secreto. Al igual que el método de bucket de Amazon S3, la aplicación debe escribirse para leer el secreto del volumen compartido. Como el volumen se limita a la tarea, este se elimina automáticamente cuando la tarea se detiene. Para ver un ejemplo, consulte el proyecto [task-def.json](https://github.com/aws-samples/aws-secret-sidecar-injector/blob/master/ecs-task-def/task-def.json). En Amazon EC2, el volumen en el que está escrito el secreto se puede cifrar con una clave administrada por el cliente de AWS KMS. En AWS Fargate, el almacenamiento por volumen se cifra automáticamente mediante una clave administrada por el servicio. # Transferencia de una variable de entorno individual a un contenedor de Amazon ECS **importante** Recomendamos almacenar la información confidencial en cualquiera de los secretos de AWS Secrets Manager o en los parámetros AWS Systems Manager Parameter Store. Para obtener más información, consulte [Transferencia de datos confidenciales a un contenedor de Amazon ECS](specifying-sensitive-data.md). Las variables de entorno especificadas en la definición de tarea son aptas para que las lean todos los usuarios y roles a los que se les permite la acción `DescribeTaskDefinition` para la definición de tareas. Puede transferir variables de entorno a sus contenedores de las siguientes maneras: + Individualmente con el parámetro de definición de contenedor `environment`. Se asigna a la opción `--env` de [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/). + En bloque, mediante el parámetro de definición de contenedor de `environmentFiles` para enumerar uno o más archivos que contienen las variables de entorno. El archivo debe estar alojado en Amazon S3. Se asigna a la opción `--env-file` de [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/). A continuación, se presenta un fragmento de una definición de tarea que muestra cómo especificar variables de entorno individuales. ``` { "family": "", "containerDefinitions": [ { "name": "", "image": "", ... "environment": [ { "name": "variable", "value": "value" } ], ... } ], ... } ``` # Transferencia de variables de entorno a un contenedor de Amazon ECS **importante** Recomendamos almacenar la información confidencial en cualquiera de los secretos de AWS Secrets Manager o en los parámetros AWS Systems Manager Parameter Store. Para obtener más información, consulte [Transferencia de datos confidenciales a un contenedor de Amazon ECS](specifying-sensitive-data.md). Los archivos de variables de entorno son objetos de Amazon S3 y se aplican todas las consideraciones de seguridad de Amazon S3. No puede utilizar el parámetro `environmentFiles` en los contenedores de Windows ni en los contenedores de Windows en Fargate. Puede crear un archivo de variables de entorno y almacenarlo en Amazon S3 para pasar las variables de entorno a su contenedor. Al especificar variables de entorno en un archivo, puede introducir variables de entorno en bloque. En la definición de contenedor, especifique el objeto `environmentFiles` con una lista de buckets de Amazon S3 con los archivos de variables de entorno. Amazon ECS no aplica un límite de tamaño a las variables de entorno, pero un archivo de variables de entorno grande podría llenar el espacio en el disco. Cada tarea que utiliza un archivo de variables de entorno hace que se descargue una copia del archivo en el disco. Amazon ECS elimina el archivo como parte de la limpieza de tareas. Para obtener información sobre las variables de entorno compatibles, consulte [Parámetros de definición avanzada de contenedores: entorno](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_environment). Tenga en cuenta lo siguiente al especificar un archivo de variable de entorno en una definición de contenedor. + Para las tareas de Amazon ECS en Amazon EC2, las instancias de contenedor requieren la versión `1.39.0` del agente de contenedor o una posterior para utilizar esta característica. Para obtener información acerca de cómo comprobar la versión del agente y actualizar a la versión más reciente, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md). + Para realizar tareas de Amazon ECS en AWS Fargate, sus tareas deben utilizar la versión `1.4.0` de la plataforma o una posterior (para Linux) a fin de utilizar esta característica. Para obtener más información, consulte [Versiones de la plataforma Fargate para Amazon ECS](platform-fargate.md). Compruebe que la variable sea compatible con la plataforma del sistema operativo. Para obtener más información, consulte [Definiciones de contenedores](task_definition_parameters.md#container_definitions) y [Otros parámetros de definición de tarea](task_definition_parameters.md#other_task_definition_params). + El archivo debe usar la extensión de archivo `.env` y la codificación UTF-8. + Se requiere el rol de ejecución de tareas para utilizar esta característica con los permisos adicionales para Amazon S3. De este modo el agente de contenedor puede extraer el archivo de variables de entorno de Amazon S3. Para obtener más información, consulte [Rol de IAM de ejecución de tareas de Amazon ECS](task_execution_IAM_role.md). + Hay un límite de 10 archivos por definición de tarea. + Cada línea de un archivo de entorno debe contener una variable de entorno con el formato `VARIABLE=VALUE`. Los espacios o las comillas **se incluyen** como parte de los valores para los archivos de Amazon ECS. Las líneas que comienzan por `#` se tratan como comentarios y se ignoran. Para obtener más información acerca de la sintaxis del archivo de variables de entorno, consulte [Establecimiento de variables de entorno (-e, --env, --env-file)](https://docs.docker.com/reference/cli/docker/container/run/#env) en la documentación de Docker. A continuación, se presenta la sintaxis adecuada. ``` #This is a comment and will be ignored VARIABLE=VALUE ENVIRONMENT=PRODUCTION ``` + Si hay variables de entorno especificadas mediante el parámetro `environment` en una definición de contenedor, tienen prioridad sobre las variables incluidas en un archivo de entorno. + Si se especifican varios archivos de entorno que contienen la misma variable, se procesan en orden de entrada. Esto significa que se utiliza el primer valor de la variable y se ignoran los valores posteriores de las variables duplicadas. Le recomendamos que utilice nombres de variables únicos. + Si se especifica un archivo de entorno como anulación de un contenedor, se utiliza. Además, se omite cualquier otro archivo de entorno especificado en la definición de contenedor. + Las siguientes reglas se aplican a Fargate: + El archivo se gestiona como un archivo .env-file nativo de Docker. + Las definiciones de contenedor que hacen referencia a variables de entorno que están en blanco y almacenadas en Amazon S3 no aparecen en el contenedor. + No se admite la gestión del escape del intérprete de comandos. + El punto de entrada del contenedor interpreta los valores `VARIABLE`. ## Ejemplo A continuación, se presenta un fragmento de una definición de tarea que muestra cómo especificar un archivo de variable de entorno. ``` { "family": "", "containerDefinitions": [ { "name": "", "image": "", ... "environmentFiles": [ { "value": "arn:aws:s3:::amzn-s3-demo-bucket/envfile_object_name.env", "type": "s3" } ], ... } ], ... } ``` # Transmisión de secretos de Secrets Manager mediante programación en Amazon ECS En lugar de codificar la información confidencial en texto sin formato en la aplicación, puede utilizar Secrets Manager para almacenar los datos confidenciales. Recomendamos este método para recuperar datos confidenciales porque si el secreto de Secrets Manager se actualiza luego, la aplicación recuperará automáticamente la versión más reciente del secreto. Cree un secreto en Secrets Manager. Después de crear un secreto de Secrets Manager, actualice el código de la aplicación para recuperar el secreto. Revise las siguientes consideraciones antes de proteger datos confidenciales en Secrets Manager. + Solo se admiten los secretos que almacenan datos de texto, que son secretos creados con el parámetro `SecretString` de la API [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html). No son compatibles los secretos que almacenan datos binarios, que son secretos creados con el parámetro `SecretBinary` de la API [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html). + Utilice los puntos de conexión de VPC de interfaz para mejorar los controles de seguridad. Debe crear los puntos de conexión de VPC de interfaz para Secrets Manager. Para obtener información sobre el punto de conexión de VPC, consulte [Crear puntos de conexión de VPC](https://docs.aws.amazon.com/secretsmanager/latest/userguide/setup-create-vpc.html) en la *Guía del usuario de AWS Secrets Manager*. + La VPC que utiliza la tarea debe usar la resolución de DNS. + En la definición de tareas se debe utilizar un rol de tareas con los permisos adicionales para Secrets Manager. Para obtener más información, consulte [Rol de IAM de tarea de Amazon ECS](task-iam-roles.md). ## Creación de secretos de Secrets Manager Puede utilizar la consola de Secrets Manager para crear un secreto con su información confidencial. Para obtener información acerca de la creación de secretos, consulte [Crear un secreto de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) en la *Guía del usuario de AWS Secrets Manager*. ## Actualice la aplicación para que recupere secretos de Secrets Manager mediante programación Puede recuperar secretos mediante una llamada a las API de Secrets Manager directamente desde la aplicación. Para información, consulte [Retrieve secrets from AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) en la *Guía del usuario de AWS Secrets Manager*. Para recuperar los datos confidenciales almacenados en el AWS Secrets Manager, consulte [Ejemplos de código para AWS Secrets Manager mediante SDK de AWS](https://docs.aws.amazon.com/code-library/latest/ug/secrets-manager_code_examples.html) en la *Biblioteca de ejemplos de código del SDK de AWS*. # Transmisión de secretos de Almacén de parámetros de Systems Manager mediante programación en Amazon ECS El almacén de parámetros de Systems Manager proporciona almacenamiento y administración seguros de secretos. Puede almacenar datos como contraseñas, cadenas de base de datos, ID de instancias de EC2 e ID de AMI y códigos de licencia como valores de parámetros, en lugar de integrar con codificación rígida esta información en la aplicación. Puede almacenar valores como texto sin formato o como datos cifrados. Recomendamos este método para recuperar datos confidenciales porque si el parámetro del Almacén de parámetros de Systems Manager se actualiza posteriormente, la aplicación recuperará automáticamente la versión más reciente. Revise las siguientes consideraciones antes de proteger datos confidenciales en el almacén de parámetros de Systems Manager. + Solo se admiten secretos que almacenan datos de texto. No se admiten los secretos que almacenan datos binarios. + Utilice los puntos de conexión de VPC de interfaz para mejorar los controles de seguridad. + La VPC que utiliza la tarea debe usar la resolución de DNS. + En el caso de las tareas que utilizan EC2, debe utilizar la variable `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true` de configuración del agente de Amazon ECS para utilizar esta característica. Puede añadirla al archivo `/etc/ecs/ecs.config` durante la creación de la instancia de contenedor o puede añadirla a una instancia existente y, a continuación, reiniciar el agente de ECS. Para obtener más información, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md). + En la definición de tareas se debe utilizar un rol de tareas con los permisos adicionales para el almacén de parámetros de Systems Manager. Para obtener más información, consulte [Rol de IAM de tarea de Amazon ECS](task-iam-roles.md). ## Cree el parámetro de Puede utilizar la consola de Systems Manager para crear un parámetro del almacén de parámetros de Systems Manager para la información confidencial. Para obtener más información, consulte [Creación de un parámetro de Systems Manager (consola)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) o [Creación de un parámetro de Systems Manager (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html) en la *Guía del usuario de AWS Systems Manager*. ## Actualice la aplicación para que recupere secretos del almacén de parámetros de Systems Manager mediante programación Para recuperar los datos confidenciales almacenados en el parámetro de Parameter Store de Systems Manager, consulte [Ejemplos de código de Systems Manager mediante SDK de AWS](https://docs.aws.amazon.com/code-library/latest/ug/ssm_code_examples.html) en la *Biblioteca de ejemplos de código del SDK de AWS*. # Transmisión de secretos de Secrets Manager a través de variables de entorno de Amazon ECS Cuando introduce un secreto como una variable de entorno, puede especificar el contenido completo de un secreto, una clave JSON específica dentro de un secreto. Este proceso ayuda a controlar la información confidencial expuesta al contenedor. Para obtener más información sobre el control de versiones secreto, consulte [¿Qué hay en un secreto de Secrets Manager?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/whats-in-a-secret.html#term_version) en la *Guía del usuario de AWS Secrets Manager*. Al utilizar una variable de entorno para introducir un secreto de Secrets Manager en un contenedor, se debe tener en cuenta lo siguiente. + Los datos confidenciales se inyectan en el contenedor al iniciar el contenedor. Si el secreto se actualiza posteriormente o se rota, el contenedor no recibirá automáticamente el valor actualizado. Debe lanzar una nueva tarea o, si su tarea forma parte de un servicio, puede actualizar el servicio y utilizar la opción **Force new deployment (Forzar nueva implementación)** para forzar que el servicio lance una nueva tarea. + Las aplicaciones que se ejecutan en el contenedor, los registros del contenedor y las herramientas de depuración tienen acceso a las variables de entorno. + Para las tareas de Amazon ECS alojadas en AWS Fargate, tenga en cuenta lo siguiente: + Para introducir el contenido completo de un secreto como variable de entorno o en una configuración de registro, debe usar la versión `1.3.0` de la plataforma o una posterior. Para obtener más información, consulte [Versiones de la plataforma Fargate para Amazon ECS](platform-fargate.md). + Para introducir una versión o clave JSON específica de un secreto como variable de entorno o en una configuración de registro, debe usar la versión `1.4.0` o posterior (Linux) o `1.0.0` (Windows) de la plataforma. Para obtener más información, consulte [Versiones de la plataforma Fargate para Amazon ECS](platform-fargate.md). + Para las tareas de Amazon ECS alojadas en EC2, se debe tener en cuenta lo siguiente: + Para introducir un secreto utilizando una versión o clave JSON específica de un secreto, la instancia de contenedor debe tener la versión `1.37.0` del agente de contenedor o una posterior. No obstante, recomendamos utilizar la versión del agente de contenedor más reciente. Para obtener información sobre la comprobación de la versión del agente y la actualización a la versión más reciente, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md). Para introducir el contenido completo de un secreto como variable de entorno o un secreto en una configuración de registro, la instancia de contenedor debe tener la versión `1.22.0` del agente de contenedor o una posterior. + Utilice los puntos de conexión de VPC de interfaz para mejorar los controles de seguridad y conectarse a Secrets Manager a través de una subred privada. Debe crear los puntos de conexión de VPC de interfaz para Secrets Manager. Para obtener información sobre el punto de conexión de VPC, consulte [Crear puntos de conexión de VPC](https://docs.aws.amazon.com/secretsmanager/latest/userguide/setup-create-vpc.html) en la *Guía del usuario de AWS Secrets Manager*. Para obtener más información sobre el uso de Secrets Manager y Amazon VPC, consulte [How to connect to Secrets Manager service within a Amazon VPC](https://aws.amazon.com/blogs//security/how-to-connect-to-aws-secrets-manager-service-within-a-virtual-private-cloud/). + Para las tareas de Windows configuradas para utilizar el controlador de registros `awslogs`, debe también establecer la variable de entorno `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE` en la instancia del contenedor. Utilice la siguiente sintaxis: ``` [Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine") Initialize-ECSAgent -Cluster -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]' ``` + En la definición de tareas se debe utilizar un rol de ejecución de tareas con los permisos adicionales para Secrets Manager. Para obtener más información, consulte [Rol de IAM de ejecución de tareas de Amazon ECS](task_execution_IAM_role.md). ## Cree el secreto de AWS Secrets Manager Puede utilizar la consola de Secrets Manager para crear un secreto con su información confidencial. Para obtener más información, consulte [Crear un secreto de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) en la *Guía del usuario de AWS Secrets Manager*. ## Adición de la variable de entorno a la definición del contenedor Dentro de la definición de contenedor, puede especificar lo siguiente: + El objeto `secrets` que contiene el nombre de la variable de entorno que se va a establecer en el contenedor + Nombre de recurso de Amazon (ARN) del secreto de Secrets Manager + Parámetros adicionales que contienen información confidencial que se debe presentar al contenedor En el ejemplo siguiente, se muestra la sintaxis completa que se debe especificar para el secreto de Secrets Manager. ``` arn:aws:secretsmanager:region:aws_account_id:secret:secret-name:json-key:version-stage:version-id ``` En la siguiente sección se describen los parámetros adicionales. Estos parámetros son opcionales, pero si no los utiliza, debe incluir los dos puntos y coma `:` para utilizar los valores predeterminados. A continuación se ofrecen ejemplos para obtener más contexto. `json-key` Especifica el nombre de la clave en un par clave-valor con el valor que desea establecer como valor de variable de entorno. Solo se admiten valores en formato JSON. Si no especifica una clave JSON, se usa el contenido completo del secreto. `version-stage` Especifica la etiqueta de ensayo de la versión de un secreto que desea utilizar. Si se especifica una etiqueta de ensayo de versión, no se puede especificar un ID de versión. Si no se especifica ninguna etapa de versión, el comportamiento predeterminado consiste en recuperar el secreto con la etiqueta de ensayo `AWSCURRENT`. Las etiquetas de ensayo se utilizan para realizar un seguimiento de las distintas versiones de un secreto cuando se actualizan o rotan. Cada versión de un secreto tiene una o varias etiquetas de ensayo y un ID. `version-id` Especifica el identificador único de la versión del secreto que desea utilizar. Si se especifica un ID de versión, no se puede especificar una etiqueta de ensayo de versión. Si no se especifica ningún ID de versión, el comportamiento predeterminado consiste en recuperar el secreto con la etiqueta de ensayo `AWSCURRENT`. Los ID de versión se utilizan para realizar un seguimiento de las distintas versiones de un secreto cuando se actualizan o rotan. Cada versión de un secreto tiene un ID. Para obtener más información, consulte [Términos y conceptos clave para AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/terms-concepts.html#term_secret) en la *Guía del usuario de AWS Secrets Manager*. ### Definiciones de contenedor de ejemplo En los siguientes ejemplos, se muestran las formas en las que se pueden referenciar secretos de Secrets Manager en las definiciones de contenedor. **Example hacer referencia a un secreto completo** A continuación, se incluye un fragmento de código de una definición de tarea que muestra el formato cuando se referencia el texto completo de un secreto de Secrets Manager. ``` { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf" }] }] } ``` Para acceder al valor de este secreto desde el contenedor, deberá llamar a `$environment_variable_name`. **Example referencia de secretos completos** A continuación, se incluye un fragmento de código de una definición de tarea que muestra el formato cuando se referencia el texto completo de múltiples secretos de Secrets Manager. ``` { "containerDefinitions": [{ "secrets": [ { "name": "environment_variable_name1", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf" }, { "name": "environment_variable_name2", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-abcdef" }, { "name": "environment_variable_name3", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-ABCDEF" } ] }] } ``` Para acceder al valor de este secreto desde el contenedor, deberá llamar a `$environment_variable_name1`, `$environment_variable_name2` y `$environment_variable_name3`. **Example hacer referencia a una clave específica dentro de un secreto** A continuación se muestra un ejemplo de salida de un comando [get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html) que muestra el contenido de un secreto junto con la etiqueta de ensayo de versión y el ID de versión asociados con ella. ``` { "ARN": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf", "Name": "appauthexample", "VersionId": "871d9eca-18aa-46a9-8785-981ddEXAMPLE", "SecretString": "{\"username1\":\"password1\",\"username2\":\"password2\",\"username3\":\"password3\"}", "VersionStages": [ "AWSCURRENT" ], "CreatedDate": 1581968848.921 } ``` Haga referencia a una clave específica de la salida anterior en una definición de contenedor especificando el nombre de clave al final del ARN. ``` { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1::" }] }] } ``` **Example hacer referencia a una versión de secreto específica** A continuación se muestra una salida de ejemplo de un comando [describe-secret](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/describe-secret.html) que muestra el contenido sin cifrar de un secreto junto con los metadatos de todas las versiones del secreto. ``` { "ARN": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf", "Name": "appauthexample", "Description": "Example of a secret containing application authorization data.", "RotationEnabled": false, "LastChangedDate": 1581968848.926, "LastAccessedDate": 1581897600.0, "Tags": [], "VersionIdsToStages": { "871d9eca-18aa-46a9-8785-981ddEXAMPLE": [ "AWSCURRENT" ], "9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE": [ "AWSPREVIOUS" ] } } ``` Haga referencia a una etiqueta de ensayo de versión específica de la salida anterior en una definición de contenedor especificando el nombre de clave al final del ARN. ``` { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf::AWSPREVIOUS:" }] }] } ``` Haga referencia a un ID de versión específico de la salida anterior en una definición de contenedor especificando el nombre de clave al final del ARN. ``` { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:::9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE" }] }] } ``` **Example hacer referencia a una clave específica y una etiqueta de ensayo de versión de un secreto** A continuación se muestra cómo hacer referencia tanto a una clave específica dentro de un secreto como a una etiqueta de ensayo de versión específica. ``` { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1:AWSPREVIOUS:" }] }] } ``` Para especificar una clave y un ID de versión específicos, utilice la sintaxis siguiente. ``` { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1::9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE" }] }] } ``` Para obtener información sobre cómo crear una definición de tareas con el secreto especificado en una variable de entorno, consulte [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md). # Transmisión de parámetros de Systems Manager a través de variables de entorno de Amazon ECS Amazon ECS le permite ingresar información confidencial en los contenedores al almacenarla en parámetros de Almacén de parámetros de AWS Systems Manager y, a continuación, hacer referencia a ella en la definición de los contenedores. Tenga en cuenta lo siguiente cuando utilice una variable de entorno para ingresar un secreto de Systems Manager en un contenedor. + Los datos confidenciales se inyectan en el contenedor al iniciar el contenedor. Si el secreto se actualiza posteriormente o se rota, el contenedor no recibirá automáticamente el valor actualizado. Debe lanzar una nueva tarea o, si su tarea forma parte de un servicio, puede actualizar el servicio y utilizar la opción **Force new deployment (Forzar nueva implementación)** para forzar que el servicio lance una nueva tarea. + Para las tareas de Amazon ECS alojadas en AWS Fargate, se debe tener en cuenta lo siguiente: + Para introducir el contenido completo de un secreto como variable de entorno o en una configuración de registro, debe usar la versión `1.3.0` de la plataforma o una posterior. Para obtener más información, consulte [Versiones de la plataforma Fargate para Amazon ECS](platform-fargate.md). + Para introducir una versión o clave JSON específica de un secreto como variable de entorno o en una configuración de registro, debe usar la versión `1.4.0` o posterior (Linux) o `1.0.0` (Windows) de la plataforma. Para obtener más información, consulte [Versiones de la plataforma Fargate para Amazon ECS](platform-fargate.md). + Para las tareas de Amazon ECS alojadas en EC2, se debe tener en cuenta lo siguiente: + Para introducir un secreto utilizando una versión o clave JSON específica de un secreto, la instancia de contenedor debe tener la versión `1.37.0` del agente de contenedor o una posterior. No obstante, recomendamos utilizar la versión del agente de contenedor más reciente. Para obtener información sobre la comprobación de la versión del agente y la actualización a la versión más reciente, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md). Para introducir el contenido completo de un secreto como variable de entorno o un secreto en una configuración de registro, la instancia de contenedor debe tener la versión `1.22.0` del agente de contenedor o una posterior. + Utilice los puntos de conexión de VPC de interfaz para mejorar los controles de seguridad. Debe crear los puntos de conexión de VPC de interfaz para Systems Manager. Para obtener información sobre cómo crear un punto de conexión de VPC, consulte [Mejora de la seguridad de las instancias de EC2 mediante puntos de conexión de VPC para Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html) en la *Guía del usuario de AWS Systems Manager*. + En la definición de tareas se debe utilizar un rol de ejecución de tareas con los permisos adicionales para el almacén de parámetros de Systems Manager. Para obtener más información, consulte [Rol de IAM de ejecución de tareas de Amazon ECS](task_execution_IAM_role.md). + Para las tareas de Windows configuradas para utilizar el controlador de registros `awslogs`, debe también establecer la variable de entorno `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE` en la instancia del contenedor. Utilice la siguiente sintaxis: ``` [Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine") Initialize-ECSAgent -Cluster -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]' ``` ## Creación del parámetro de Systems Manager Puede utilizar la consola de Systems Manager para crear un parámetro del almacén de parámetros de Systems Manager para la información confidencial. Para obtener más información, consulte [Creación de un parámetro de Systems Manager (consola)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) o [Creación de un parámetro de Systems Manager (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html) en la *Guía del usuario de AWS Systems Manager*. ## Adición de la variable de entorno a la definición del contenedor Dentro de la definición de contenedor en la definición de tareas, especifique `secrets` con el nombre de la variable de entorno que se va a establecer en el contenedor y el ARN completo del parámetro del almacén de parámetros de Systems Manager que contiene la información confidencial que se va a presentar al contenedor. Para obtener más información, consulte [secrets](task_definition_parameters.md#ContainerDefinition-secrets). A continuación, se incluye un fragmento de código de una definición de tarea que muestra el formato cuando se hace referencia a un parámetro del Parameter Store de Systems Manager. Si el parámetro del Parameter Store de Systems Manager está en la misma región que la tarea que se va a lanzar, se puede utilizar el ARN completo o el nombre del parámetro. Si el parámetro existe en una región distinta, debe especificar el ARN completo. ``` { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name" }] }] } ``` Para obtener información sobre cómo crear una definición de tareas con el secreto especificado en una variable de entorno, consulte [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md). ## Actualice la aplicación para que recupere secretos del almacén de parámetros de Systems Manager mediante programación Para recuperar los datos confidenciales almacenados en el parámetro de Parameter Store de Systems Manager, consulte [Ejemplos de código de Systems Manager mediante SDK de AWS](https://docs.aws.amazon.com/code-library/latest/ug/ssm_code_examples.html) en la *Biblioteca de ejemplos de código del SDK de AWS*. # Transmisión de secretos para la configuración de registro de Amazon ECS Puede utilizar el parámetro `secretOptions` en `logConfiguration` para transferir los datos confidenciales que se utilizan para los registros. Puede almacenar el secreto en Secrets Manager o Systems Manager. ## Uso de Secrets Manager En la definición de contenedor, al especificar una `logConfiguration`, puede especificar `secretOptions` con el nombre de la opción del controlador de registros para definir el contenedor y el ARN completo del secreto de Secrets Manager que contiene la información confidencial que se va a presentar al contenedor. Para obtener más información acerca de cómo crear secretos, consulte [Creación de un AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html). A continuación, se incluye un fragmento de código de una definición de tarea que muestra el formato cuando se referencia un secreto de Secrets Manager. ``` { "containerDefinitions": [{ "logConfiguration": [{ "logDriver": "splunk", "options": { "splunk-url": "https://your_splunk_instance:8088" }, "secretOptions": [{ "name": "splunk-token", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf" }] }] }] } ``` ## Adición de la variable de entorno a la definición del contenedor En la definición de contenedor, especifique `secrets` con el nombre de la variable de entorno que se va a establecer en el contenedor y el ARN completo del parámetro del Parameter Store de Systems Manager que contiene la información confidencial que se va a presentar al contenedor. Para obtener más información, consulte [secrets](task_definition_parameters.md#ContainerDefinition-secrets). A continuación, se incluye un fragmento de código de una definición de tarea que muestra el formato cuando se hace referencia a un parámetro del Parameter Store de Systems Manager. Si el parámetro del Parameter Store de Systems Manager está en la misma región que la tarea que se va a lanzar, se puede utilizar el ARN completo o el nombre del parámetro. Si el parámetro existe en una región distinta, debe especificar el ARN completo. ``` { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name" }] }] } ``` Para obtener información sobre cómo crear una definición de tareas con el secreto especificado en una variable de entorno, consulte [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md). ## Uso de Systems Manager Puede introducir información confidencial en una configuración de registros. En la definición de contenedor, al especificar una `logConfiguration`, puede especificar `secretOptions` con el nombre de la opción del controlador de registros que va a definir en el contenedor y el ARN completo del parámetro del Parameter Store de Systems Manager que contiene la información confidencial que se va a presentar al contenedor. **importante** Si el parámetro del Parameter Store de Systems Manager está en la misma región que la tarea que se va a lanzar, se puede utilizar el ARN completo o el nombre del parámetro. Si el parámetro existe en una región distinta, debe especificar el ARN completo. A continuación, se incluye un fragmento de código de una definición de tarea que muestra el formato cuando se hace referencia a un parámetro del Parameter Store de Systems Manager. ``` { "containerDefinitions": [{ "logConfiguration": [{ "logDriver": "fluentd", "options": { "tag": "fluentd demo" }, "secretOptions": [{ "name": "fluentd-address", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter:/parameter_name" }] }] }] } ``` # Especificación de información confidencial mediante secretos de Secrets Manager en Amazon ECS Amazon ECS permite introducir información confidencial en los contenedores, la almacena en secretos de AWS Secrets Manager y, a continuación, la referencia en la definición de contenedor. Para obtener más información, consulte [Transferencia de datos confidenciales a un contenedor de Amazon ECS](specifying-sensitive-data.md). Obtenga información sobre cómo crear un secreto de Secrets Manager, hacer referencia al secreto en una definición de tareas de Amazon ECS y, luego, comprobar que funciona al consultar la variable de entorno dentro de un contenedor que muestra el contenido del secreto. ## Requisitos previos En este tutorial se supone que los siguientes requisitos previos se han completado: + Se han completado los pasos que se indican en [Configuración para utilizar Amazon ECS](get-set-up-for-amazon-ecs.md). + El usuario dispone de los permisos de IAM requeridos para crear los recursos de Secrets Manager y Amazon ECS. ## Paso 1: Crear un secreto de Secrets Manager Puede utilizar la consola de Secrets Manager para crear un secreto con su información confidencial. En este tutorial se creará un secreto básico para almacenar un nombre de usuario y una contraseña para referencia futura en un contenedor. Para obtener más información, consulte [Creación de un secreto de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) en la *Guía del usuario de AWS Secrets Manager*. Los pares clave/valor que se almacenarán en este secreto (**key/value pairs to be stored in this secret**) son el valor de la variable de entorno en el contenedor al final del tutorial. Guarde el **Secret ARN** (ARN del secreto) para hacer referencia en su política de IAM de ejecución de tareas y la definición de tarea en pasos posteriores. ## Paso 2: agregue los permisos secretos al rol de ejecución de tareas. Para que Amazon ECS recupere la información confidencial de su secreto de Secrets Manager, debe contar con los permisos secretos para el rol de ejecución de tareas. Para obtener más información, consulte [Permisos de Secrets Manager o Systems Manager](task_execution_IAM_role.md#task-execution-secrets). ## Paso 3: Cree una definición de tarea Puede utilizar la consola de Amazon ECS para crear una definición de tareas que haga referencia a un secreto de Secrets Manager. **Para crear una definición de tarea que especifique un secreto** Utilice la consola de IAM para actualizar el rol de ejecución de tareas con los permisos requeridos. 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En el panel de navegación, elija **Task Definitions** (Definiciones de tareas). 1. Elija **Create new task definition** (Crear nueva definición de tarea) y **Create new task definition with JSON** (Crear nueva definición de tarea con JSON). 1. En el cuadro del editor JSON, ingrese el siguiente texto JSON de definición de tareas y asegúrese de especificar el ARN completo del secreto de Secrets Manager que creó en el paso 1 y el rol de ejecución de tareas que actualizó en el paso 2. Seleccione **Save**. 1. ``` { "executionRoleArn": "arn:aws:iam::aws_account_id:role/ecsTaskExecutionRole", "containerDefinitions": [ { "entryPoint": [ "sh", "-c" ], "portMappings": [ { "hostPort": 80, "protocol": "tcp", "containerPort": 80 } ], "command": [ "/bin/sh -c \"echo ' Amazon ECS Sample App

Amazon ECS Sample App

Congratulations!

Your application is now running on a container in Amazon ECS.

' > /usr/local/apache2/htdocs/index.html && httpd-foreground\"" ], "cpu": 10, "secrets": [ { "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:username_value", "name": "username_value" } ], "memory": 300, "image": "public.ecr.aws/docker/library/httpd:2.4", "essential": true, "name": "ecs-secrets-container" } ], "family": "ecs-secrets-tutorial" } ``` 1. Seleccione **Crear**. ## Paso 4: cree un clúster Puede utilizar la consola de Amazon ECS para crear un clúster que contenga una instancia de contenedor en la que se va a ejecutar la tarea. Si tiene un clúster existente con al menos una instancia de contenedor registrada en ella, con los recursos disponibles para ejecutar una instancia de la definición de tarea creada para este tutorial, puede pasar al siguiente paso. Para este tutorial, vamos a crear un clúster con una instancia de contenedor `t2.micro` mediante la AMI de Amazon Linux 2 optimizada para Amazon ECS. Para obtener información acerca de cómo crear un clúster para EC2, consulte [Creación de un clúster de Amazon ECS para cargas de trabajo de Amazon EC2](create-ec2-cluster-console-v2.md). ## Paso 5: ejecute una tarea Puede utilizar la consola de Amazon ECS para ejecutar una tarea mediante la definición de tareas creada. En este tutorial, pondremos en marcha una tarea mediante EC2, con el clúster que creamos en el paso anterior. Para obtener información sobre cómo ejecutar una tarea, consulte [Ejecución de una aplicación como tarea de Amazon ECS](standalone-task-create.md). ## Paso 6: Verificar Puede verificar que todos los pasos se han completado correctamente y que la variable de entorno se ha creado correctamente en el contenedor con los pasos que se describen a continuación. **Para verificar que se ha creado la variable de entorno** 1. Busque la dirección IP o DNS pública para su instancia de contenedor. 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En el panel de navegación, elija **Clústeres** y, a continuación, elija el clúster que creó. 1. Elija **Infraestructura** y, a continuación, elija la instancia de contenedor. 1. Registre la **IP pública** o el **DNS público** para su instancia. 1. Si está utilizando un equipo con macOS o Linux, conéctese a la instancia con el siguiente comando, sustituyendo la ruta por su clave privada y la dirección pública para su instancia: ``` $ ssh -i /path/to/my-key-pair.pem ec2-user@ec2-198-51-100-1.compute-1.amazonaws.com ``` Para obtener más información acerca del uso de una computadora con Windows, consulte [Conexión a la instancia de Linux con PuTTY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-from-windows.html) en la *Guía del usuario de Amazon EC2*. **importante** Para obtener más información acerca de los problemas que pueden surgir al conectarse a la instancia, consulte [Solucione el problema de conectar la instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html) en la *Guía del usuario de Amazon EC2*. 1. Obtenga la lista de los contenedores que se ejecutan en la instancia. Anote el ID del contenedor `ecs-secrets-tutorial`. ``` docker ps ``` 1. Conéctese al contenedor `ecs-secrets-tutorial` con el ID de contenedor desde la salida del paso anterior. ``` docker exec -it container_ID /bin/bash ``` 1. Utilice el comando `echo` para imprimir el valor de la variable del entorno. ``` echo $username_value ``` Si el tutorial no se ha realizado correctamente, debería ver el siguiente resultado: ``` password_value ``` **nota** Si lo prefiere, puede mostrar todas las variables de entorno en su contenedor con el comando `env` (o `printenv`). ## Paso 7: limpiar Cuando termine este tutorial, debe limpiar los recursos asociados para evitar incurrir en cargos generados por recursos sin utilizar. **Para limpiar los recursos.** 1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. En el panel de navegación, seleccione **Clusters (Clústeres)**. 1. En la página **Clusters** (Clústeres), elija el clúster. 1. Elija **Delete cluster**. 1. En el cuadro de confirmación, ingrese **Eliminar *cluster-name*** y, a continuación, elija **Eliminar**. 1. Abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Seleccione **Roles** en el panel de navegación. 1. En la lista de roles, busque `ecsTaskExecutionRole` y selecciónelo. 1. Elija **Permisos** y, a continuación, elija la **X** junto a **ECSSecretsTutorial**. Elija **Eliminar**. 1. Abra la consola de Secrets Manager en[https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/). 1. Seleccione el secreto **username\$1value** creado y elija **Actions (Acciones)**, **Delete secret (Eliminar secreto)**. # Parámetros de la definición de tareas de Amazon ECS para instancias administradas de Amazon ECS Las definiciones de tareas se dividen en partes independientes: la familia de tareas, el rol de tarea de AWS Identity and Access Management (IAM), el modo de red, las definiciones de contenedor, los volúmenes y la capacidad. En una definición de tareas, son necesarias las definiciones de familia y contenedor. En cambio, el rol de tarea, el modo de red, los volúmenes y la capacidad son opcionales. Puede utilizar estos parámetros en un archivo JSON para configurar la definición de tarea. A continuación, se muestran las descripciones detalladas de cada parámetro de definición de tareas para instancias administradas de Amazon ECS. ## Familia `family` Tipo: cadena Obligatorio: sí Cuando se registra una definición de tarea, se le da una familia, que es similar a un nombre para varias versiones de la definición de tarea, especificado con un número de revisión. A la primera definición de tareas que se registra en una familia particular se le da una revisión de 1 y a cualquier definición de tarea registrada después se le da un número de revisión secuencial. ## Capacidad Cuando se registre una definición de tareas, puede especificar la capacidad que con respecto a la cual Amazon ECS debe validar la definición de tareas. Si la definición de tareas no se valida con respecto a las compatibilidades especificadas, se devuelve una excepción de cliente. Para obtener más información, consulte [Tipos de lanzamiento de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/launch_types.html). El parámetro a continuación está permitido en una definición de tareas. `requiresCompatibilities` Tipo: matriz de cadenas Obligatorio: no Valores válidos: `MANAGED_INSTANCES` La capacidad con la que se validó la definición de tareas. Esto inicia una comprobación para garantizar que todos los parámetros utilizados en la definición de tareas cumplan los requisitos de instancias administradas de Amazon ECS. ## Rol de de la tarea `taskRoleArn` Tipo: cadena Requerido: no Cuando se registra una definición de tareas, se puede proporcionar un rol de tarea para un rol de IAM que permita a los contenedores del permiso de tareas llamar en su nombre a las API de AWS especificadas en sus políticas asociadas. Para obtener más información, consulte [Rol de IAM de tarea de Amazon ECS](task-iam-roles.md). ## Rol de ejecución de tareas `executionRoleArn` Tipo: cadena Obligatorio: condicional El nombre de recurso de Amazon (ARN) del rol de ejecución de tarea que concede permiso al agente de contenedor de Amazon ECS para realizar llamadas a la API de AWS en su nombre. Para obtener más información, consulte [Rol de IAM de ejecución de tareas de Amazon ECS](task_execution_IAM_role.md). El rol de IAM de ejecución de tareas es necesario en función de los requisitos de la tarea. El rol es obligatorio para extraer la imagen de ECR privada y utilizar el controlador de registro de `awslogs`. ## Modo de red `networkMode` Tipo: cadena Requerido: no Valor predeterminado: `awsvpc` El modo de red que se debe utilizar para los contenedores en la tarea. Para las tareas de Amazon ECS alojadas en instancias administradas de Amazon ECS, los valores válidos son `awsvpc` y `host`. Si no se especifica ningún modo de red, el modo de red predeterminado es `awsvpc`. Si el modo de red es `host`, la tarea omite el aislamiento de la red y los contenedores utilizan la pila de red del host directamente. Para mayor seguridad, cuando ejecute tareas utilizando el modo de red `host`, no debe ejecutar contenedores con el usuario raíz (UID 0). Como práctica recomendada de seguridad, utilice siempre un usuario que no sea usuario raíz. Si el modo de red es `awsvpc`, a la tarea se le asigna una interfaz de red elástica y debe especificar `NetworkConfiguration` al crear un servicio o ejecutar una tarea con la definición de tarea. Para obtener más información, consulte [Red de tareas de Amazon ECS para instancias administradas de Amazon ECS](managed-instance-networking.md). Los modos de red `host` y `awsvpc` ofrecen el rendimiento de redes más alto para contenedores dado que estos utilizan la pila de la red de Amazon EC2. Con los modos de red `host` y `awsvpc`, los puertos de contenedor expuestos se asignan directamente al puerto de host correspondiente (para el modo de red `host`) o al puerto de interfaz de red elástica asociado (para el modo de red `awsvpc`). Por este motivo, no se pueden utilizar asignaciones de puerto de host dinámico. ## Plataforma de tiempo de ejecución `operatingSystemFamily` Tipo: cadena Requerido: no Predeterminado: LINUX Cuando se registra una definición de tarea, especifica la familia de sistemas operativos. El valor válido para este campo es `LINUX`. Todas las definiciones de tareas que se utilizan en un servicio deben tener el mismo valor para este parámetro. Cuando una definición de tarea forma parte de un servicio, este valor debe coincidir con el valor `platformFamily` de servicio. `cpuArchitecture` Tipo: cadena Obligatorio: condicional Cuando se registra una definición de tarea, especifica la arquitectura de CPU. Los valores válidos son `X86_64` y `ARM64`. Si no especifica un valor, Amazon ECS intenta colocar las tareas en la arquitectura de CPU disponible según la configuración del proveedor de capacidad. Para asegurarse de que las tareas se colocan en una arquitectura de CPU específica, especifique un valor para `cpuArchitecture` en la definición de la tarea. Todas las definiciones de tareas que se utilizan en un servicio deben tener el mismo valor para este parámetro. Para obtener más información acerca de `ARM64`, consulte [Definiciones de tareas de Amazon ECS para cargas de trabajo de ARM de 64 bits](ecs-arm64.md). ## Tamaño de tarea Cuando se registra una definición de tareas, puede especificar la cantidad total de CPU y memoria usada para la tarea. Es distinto de los valores `cpu` y `memory` en el nivel de definición de contenedor. Para las tareas que están alojadas en instancias de Amazon EC2, estos campos son opcionales. **nota** Los parámetros de CPU y memoria de nivel de tarea se omiten para los contenedores de Windows. Le recomendamos que especifique recursos de nivel de contenedor para los contenedores de Windows. `cpu` Tipo: cadena Obligatorio: condicional El límite máximo de unidades de CPU que presentar para la tarea. Puede indicar los valores de la CPU en el archivo JSON como una cadena en unidades de CPU o CPU virtuales (vCPU). Por ejemplo, puede especificar un valor de CPU `1024` en unidades de CPU o `1 vCPU` en vCPU. Cuando se registra la definición de tarea, el valor de una CPU virtual se convierte en un entero que indica las unidades de CPU. Este campo es opcional. Si el clúster no tiene registradas instancias de contenedor con las unidades de CPU solicitadas disponibles, la tarea no funciona. Los valores admitidos se encuentran entre `0.125` y `10` vCPU. `memory` Tipo: cadena Obligatorio: condicional El límite máximo de memoria para presentar a la tarea. Puede especificar los valores de memoria en la definición de tareas como una cadena en mebibytes (MiB) o gigabytes (GB). Por ejemplo, puede especificar un valor de memoria `3072` en MiB o `3 GB` en GB. Cuando se registra la definición de tarea, el valor de GB se convierte en un entero que indica el número de MiB. Este campo es opcional y se puede utilizar cualquier valor. Si se especifica un valor de memoria de nivel de tarea, el valor de memoria de nivel de contenedor es opcional. Si el clúster no tiene registradas instancias de contenedor con la memoria solicitada disponible, la tarea no funciona. Puede maximizar la utilización de los recursos proporcionando a las tareas la mayor cantidad de memoria posible para un tipo de instancia determinado. Para obtener más información, consulte [Reserva de la memoria de instancias de contenedor de Linux de Amazon ECS](memory-management.md). ## Otros parámetros de definición de tarea Los siguientes parámetros de definición de tareas se pueden utilizar cuando se registran definiciones de tareas en la consola de Amazon ECS mediante la opción **Configure via JSON** (Configurar mediante JSON). Para obtener más información, consulte [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md). **Topics** + [Almacenamiento efímero](#task_definition_ephemeralStorage-managed-instances) + [Modo IPC](#task_definition_ipcmode-managed-instances) + [Modo PID](#task_definition_pidmode-managed-instances) + [Configuración del proxy](#proxyConfiguration-managed-instances) + [Etiquetas](#tags-managed-instances) + [Acelerador de Elastic Inference (en desuso)](#elastic-Inference-accelerator-managed-instances) + [Restricciones para la ubicación](#constraints-managed-instances) + [Volúmenes](#volumes-managed-instances) ### Almacenamiento efímero `ephemeralStorage` Este parámetro no es compatible con las tareas que se ponen en marcha en instancias administradas de Amazon ECS. Tipo: objeto de [EphemeralStorage](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EphemeralStorage.html) Obligatorio: no Cantidad de almacenamiento efímero (en GB) que se va a asignar para la tarea. Este parámetro se utiliza para expandir la cantidad total de almacenamiento efímero disponible, más allá de la cantidad predeterminada, para las tareas que están alojadas en AWS Fargate. Para obtener más información, consulte [Uso de montajes de unión con Amazon ECS](bind-mounts.md). ### Modo IPC `ipcMode` Este parámetro no es compatible con las tareas que se ponen en marcha en instancias administradas de Amazon ECS. Tipo: cadena Requerido: no El espacio de nombres de recurso de IPC que usarán los contenedores de la tarea. Los valores válidos son `host`, `task` o `none`. Si se especifica `host`, todos los contenedores que están dentro de las tareas que tienen especificado el modo de IPC `host` en la misma instancia de contenedor comparten los mismos recursos de IPC con la instancia Amazon EC2 del host. Si se especifica `task`, todos los contenedores que están dentro de la tarea especificada comparten los mismos recursos de IPC. Si se especifica `none`, los recursos de IPC dentro de los contenedores de una tarea son privados y no se comparten con otros contenedores en una tarea o en la instancia de contenedor. Si no se especifica ningún valor, el uso compartido del espacio de nombres de recursos de IPC depende de la configuración del tiempo de ejecución del contenedor. ### Modo PID `pidMode` Tipo: cadena Requerido: no El espacio de nombres del proceso que usarán los contenedores de la tarea. Los valores válidos son `host` o `task`. Si se especifica `host`, todos los contenedores que se encuentran en las tareas que tienen especificado el modo de PID `host` en la misma instancia de contenedor comparten el mismo espacio de nombres del proceso con la instancia Amazon EC2 del host. Si se especifica `task`, todos los contenedores que se encuentran en la tarea especificada comparten el mismo espacio de nombres del proceso. Si no se especifica ningún valor, el valor predeterminado es un espacio de nombres privado. Si se utiliza el modo de PID `host`, existe un mayor riesgo de exposición de espacio de nombres del proceso no deseada. ### Configuración del proxy `proxyConfiguration` Este parámetro no es compatible con las tareas que se ponen en marcha en instancias administradas de Amazon ECS. Tipo: objeto [ProxyConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ProxyConfiguration.html) Obligatorio: no Los detalles de configuración del proxy App Mesh. ### Etiquetas Los metadatos que se aplican a una definición de tareas para categorizarla y organizarla. Cada etiqueta consta de una clave y un valor opcional. Los define a los dos. Se aplican las siguientes restricciones básicas a las etiquetas: + Cantidad máxima de etiquetas por recurso: 50. + Para cada recurso, cada clave de etiqueta debe ser única y solo puede tener un valor. + Longitud máxima de la clave: 128 caracteres Unicode en UTF-8 + Longitud máxima del valor: 256 caracteres Unicode en UTF-8 + Si se utiliza su esquema de etiquetado en múltiples servicios y recursos, recuerde que otros servicios pueden tener otras restricciones sobre caracteres permitidos. Los caracteres permitidos generalmente son: letras, números y espacios representables en UTF-8, además de los siguientes caracteres: \$1 - = . \$1 : / @. + Las claves y los valores de las etiquetas distinguen entre mayúsculas y minúsculas. + No utilice `aws:`, `AWS:` ni ninguna combinación de mayúsculas o minúsculas del mismo como prefijo para claves o valores, ya que está reservado para uso de AWS. Las claves y valores de etiquetas que tienen este prefijo no se pueden editar. Las etiquetas que tengan este prefijo no cuentan para el límite de etiquetas por recurso. `key` Tipo: cadena Requerido: no Una parte de un par clave-valor que compone una etiqueta. Un clave es una etiqueta general que actúa como una categoría para valores de etiqueta más específicos. `value` Tipo: cadena Requerido: no La parte opcional de un par clave-valor que compone una etiqueta. Un valor actúa como un descriptor en una categoría de etiquetas (clave). ### Acelerador de Elastic Inference (en desuso) **nota** Amazon Elastic Inference (EI) ya no está disponible para los clientes. `inferenceAccelerator` Este parámetro no es compatible con las tareas que se ponen en marcha en instancias administradas de Amazon ECS. Tipo: objeto [InferenceAccelerator](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_InferenceAccelerator.html) Obligatorio: no Los aceleradores de Elastic Inference que se van a utilizar en los contenedores de la tarea. ### Restricciones para la ubicación `placementConstraints` Tipo: matriz de objetos [TaskDefinitionPlacementConstraint](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_TaskDefinitionPlacementConstraint.html) Obligatorio: no Una matriz de objetos de restricción de ubicación que se usarán para la tarea. Puede especificar 10 restricciones como máximo por tarea (este límite incluye restricciones en la definición de tareas y las especificadas en el tiempo de ejecución). Amazon ECS admite las restricciones de ubicación `distinctInstace` y `memberOf` de las tareas que se ponen en marcha en instancias administradas de Amazon ECS. Las tareas que utilizan la restricción de ubicación `memberOf` admiten los atributos siguientes: + `ecs.subnet-id` + `ecs.availability-zone` + `ecs.cpu-architecture` + `ecs.instance-type` Para obtener más información acerca de las restricciones de ubicación, consulte [Definición de las instancias de contenedor que utiliza Amazon ECS para las tareas](task-placement-constraints.md). ### Volúmenes Cuando se registra una definición de tareas, se puede especificar, de manera opcional, una lista de volúmenes para las tareas. Esto le permite utilizar volúmenes de datos en las tareas. Para obtener más información acerca de los tipos de volúmenes y otros parámetros, consulte [Opciones de almacenamiento para las tareas de Amazon ECS](using_data_volumes.md). `name` Tipo: cadena Obligatorio: sí El nombre del volumen. Se admiten hasta 255 letras (mayúsculas y minúsculas), números y guiones. Se hace referencia a este nombre en el parámetro `sourceVolume` de la definición de contenedor `mountPoints`. `host` Type: objeto [HostVolumeProperties](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_HostVolumeProperties.html) Obligatorio: no Este parámetro se especifica al utilizar volúmenes de host de montaje vinculado. El contenido del parámetro `host` determina si el volumen de host de montaje vinculado persiste en la instancia de contenedor del host y dónde se almacena. Si el parámetro `host` está vacío, el sistema le asigna una ruta de host al volumen de datos. Sin embargo, no se garantiza que los datos persistan después de que los contenedores asociados dejen de funcionar. `sourcePath` Tipo: cadena Requerido: no Cuando utilice el parámetro `host`, especifique una `sourcePath` para declarar la ruta de la instancia del host que se presenta al contenedor. Si este parámetro está vacío, el sistema le asignará una ruta de host. Si el parámetro `host` contiene una ubicación de ubicación de archivos `sourcePath`, el volumen de datos persiste en la ubicación especificada en la instancia de host hasta que la elimine manualmente. Si el valor `sourcePath` no existe en la instancia del host, el sistema lo crea. Si la ubicación existe, el contenido de la carpeta de la ruta de origen se exporta. En las instancias administradas por Amazon ECS, algunas partes del sistema de archivos del host son de solo lectura. La `sourcePath` debe apuntar a un directorio en el que se pueda escribir, como `/var` o `/tmp`. Para obtener más información, consulte [Uso de montajes de unión con Amazon ECS](bind-mounts.md). `dockerVolumeConfiguration` Este parámetro no es compatible con las tareas que se ponen en marcha en instancias administradas de Amazon ECS. Type: objeto [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html) Obligatorio: no Este parámetro se especifica al utilizar volúmenes de Docker. `efsVolumeConfiguration` Tipo: objeto [EFSVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSVolumeConfiguration.html) Obligatorio: no Este parámetro se especifica cuando al utilizar un sistema de archivos de Amazon EFS para el almacenamiento de tareas. `fsxWindowsFileServerVolumeConfiguration` Este parámetro no es compatible con las tareas que se ponen en marcha en instancias administradas de Amazon ECS. Tipo: objeto [FSXWindowsFileServerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FSxWindowsFileServerVolumeConfiguration.html) Obligatorio: no Este parámetro se indica al utilizar el sistema de archivos Amazon FSx para Windows File Server para el almacenamiento de tareas. `configuredAtLaunch` Tipo: Booleano Obligatorio: no Indica si el volumen debe configurarse en el momento del lanzamiento. Se utiliza para crear volúmenes de Amazon EBS para tareas independientes o tareas creadas como parte de un servicio. Cada revisión de la definición de tareas solo puede tener un volumen configurado en el momento del lanzamiento en la configuración de volumen. ## Definiciones de contenedores Al registrar una definición de tarea, debe especificar una lista de definiciones de contenedor que se transfieren al daemon de Docker en una instancia de contenedor. Los siguientes parámetros están permitidos en una definición de contenedor. **Topics** + [Nombre](#container_definition_name-managed-instances) + [Image](#container_definition_image-managed-instances) + [Memoria](#container_definition_memory-managed-instances) + [CPU](#container_definition_cpu-managed-instances) + [Mapeos de puertos](#container_definition_portmappings-managed-instances) + [Credenciales de repositorio privado](#container_definition_repositoryCredentials-managed-instances) + [Essential](#container_definition_essential-managed-instances) + [Punto de entrada](#container_definition_entrypoint-managed-instances) + [Comando](#container_definition_command-managed-instances) + [Directorio de trabajo](#container_definition_workingdirectory-managed-instances) + [Parámetros de definición de contenedor avanzados](#advanced_container_definition_params-managed-instances) + [Parámetros de Linux](#container_definition_linuxparameters-managed-instances) ### Nombre `name` Tipo: cadena Obligatorio: sí El nombre de un contenedor. Se admiten hasta 255 letras (mayúsculas y minúsculas), números, guiones y caracteres de subrayado. Si está vinculando varios contenedores en una definición de tareas, el `name` de un contenedor se puede introducir en los `links` de otro contenedor. Esto sirve para conectar los contenedores. ### Image `image` Tipo: cadena Obligatorio: sí La imagen que se utiliza para iniciar un contenedor. Esta cadena se transfiere directamente al daemon de Docker. De manera predeterminada, las imágenes del registro de Docker Hub están disponibles. También puede especificar otros repositorios con `repository-url/image:tag` o `repository-url/image@digest`. Se permiten hasta 255 letras (mayúsculas y minúsculas), números, guiones, caracteres de subrayado, comas, puntos, barras diagonales y signos numéricos. Este parámetro se corresponde con `Image` en el comando create-container de docker y el parámetro `IMAGE` del comando de docker run. + Cuando se inicia una tarea nueva, el agente de contenedor de Amazon ECS extrae la última versión de la imagen y la etiqueta especificadas para que las utilice el contenedor. Sin embargo, las actualizaciones realizadas posteriormente en un repositorio de imágenes no se propagan a las tareas en ejecución. + Cuando no se especifica una etiqueta ni un resumen en la ruta de la imagen en la definición de la tarea, el agente de contenedores de Amazon ECS utiliza la etiqueta `latest` para extraer la imagen especificada. + Las actualizaciones que se hacen posteriormente en un repositorio de imágenes no se propagan a las tareas en marcha. + Se admiten las imágenes de registros privados. Para obtener más información, consulte [Uso de imágenes de contenedor que no sean de AWS en Amazon ECS](private-auth.md). + Para especificar imágenes de los repositorios de Amazon ECR, se puede utilizar la convención de nomenclatura completa `registry/repository:tag` o `registry/repository@digest` (por ejemplo, `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app:latest` o `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE`). + Las imágenes de los repositorios oficiales de Docker Hub utilizan un solo nombre (por ejemplo, `ubuntu` o `mongo`). + Las imágenes de otros repositorios de Docker Hub se clasifican con un nombre de organización (por ejemplo, `amazon/amazon-ecs-agent`). + Las imágenes de otros repositorios online se cualifican más con un nombre de dominio (por ejemplo, `quay.io/assemblyline/ubuntu`). `versionConsistency` Tipo: cadena Valores válidos: `enabled`\$1`disabled` Obligatorio: no Especifica si Amazon ECS convertirá la etiqueta de imagen de contenedores proporcionada en la definición de contenedores en un resumen de imágenes. De manera predeterminada, el comportamiento es `enabled`. Si establece `disabled` como valor de un contenedor, Amazon ECS no convertirá la etiqueta de imagen del contenedor en un resumen y utilizará el URI de imagen original especificado en la definición del contenedor para la implementación. Para obtener más información acerca de la conversión de imagen de contenedor, consulte [Resolución de imagen de contenedor](deployment-type-ecs.md#deployment-container-image-stability). ### Memoria `memory` Tipo: entero Obligatorio: no La cantidad (en MiB) de memoria que se presenta al contenedor. Si su contenedor intenta superar la memoria especificada aquí, el contenedor se cancela. La cantidad total de memoria reservada para todos los contenedores dentro de una tarea debe ser menor que el valor `memory` de la tarea, si se especifica. Este parámetro se corresponde con `Memory` en el comando create-container de docker y la opción `--memory` se corresponde con docker run. El daemon de Docker 20.10.0 o posterior reserva un mínimo de 6 MiB de memoria para un contenedor. Por lo tanto, no debe especificar menos de 6 MiB de memoria para los contenedores. El daemon de Docker 19.03.13-ce o anterior reserva un mínimo de 4 MiB de memoria para un contenedor. Por lo tanto, no debe especificar menos de 4 MiB de memoria para los contenedores. Si intenta maximizar la utilización de los recursos proporcionando a las tareas la mayor cantidad de memoria posible para un tipo de instancia determinado, consulte [Reserva de la memoria de instancias de contenedor de Linux de Amazon ECS](memory-management.md). `memoryReservation` Tipo: entero Obligatorio: no El límite flexible (en MiB) de memoria que reservar para el contenedor. Cuando la memoria del sistema está en conflicto, Docker intenta mantener la memoria del contenedor en este límite flexible. Sin embargo, el contenedor puede utilizar más memoria cuando sea necesario. El contenedor puede utilizar hasta el límite invariable especificado con el parámetro de `memory` (si procede) o toda la memoria disponible en la instancia de contenedor, lo que ocurra primero. Este parámetro se corresponde con `MemoryReservation` en el comando create-container de docker y la opción `--memory-reservation` se corresponde con docker run. Si no se especifica un valor de memoria de nivel de tarea, debe especificar un entero distinto de cero para `memory` o `memoryReservation`, o para ambos, en una definición de contenedor. Si especifica ambos, `memory` debe ser mayor que `memoryReservation`. Si especifica `memoryReservation`, el valor se resta de los recursos de memoria disponibles para la instancia de contenedor en la que se coloca el contenedor. De lo contrario, se utiliza el valor de `memory`. Por ejemplo, supongamos que el contenedor utiliza normalmente 128 MiB de memoria, pero con ráfagas ocasionales de hasta 256 MiB durante períodos de tiempo breves. Puede establecer una `memoryReservation` de 128 MiB y un límite invariable de `memory` de 300 MiB. Esta configuración permite al contenedor reservar solo 128 MiB de memoria de los recursos restantes en la instancia de contenedor. Al mismo tiempo, esta configuración también permite que el contenedor consuma más recursos de memoria en caso de ser necesario. El daemon de Docker 20.10.0 o posterior reserva un mínimo de 6 MiB de memoria para un contenedor. Por lo tanto, no debe especificar menos de 6 MiB de memoria para los contenedores. El daemon de Docker 19.03.13-ce o anterior reserva un mínimo de 4 MiB de memoria para un contenedor. Por lo tanto, no debe especificar menos de 4 MiB de memoria para los contenedores. Si intenta maximizar la utilización de los recursos proporcionando a las tareas la mayor cantidad de memoria posible para un tipo de instancia determinado, consulte [Reserva de la memoria de instancias de contenedor de Linux de Amazon ECS](memory-management.md). ### CPU `cpu` Tipo: entero Obligatorio: no El número de unidades `cpu` reservadas para el contenedor. Este parámetro se corresponde con `CpuShares` en el comando create-container de docker y la opción `--cpu-shares` con docker run. Este campo es opcional para las tareas que utilizan los proveedores de capacidad de EC2. El único requisito es que la cantidad total de CPU reservada para todos los contenedores de una tarea sea menor que el valor `cpu` en el nivel de tarea. Puede determinar el número de unidades CPU disponibles por tipo de instancia de EC2 multiplicando las vCPU listadas para dicho tipo de instancia en la página de detalles [instancias de Amazon EC2](https://aws.amazon.com/ec2/instance-types/) por 1024. Los contenedores de Linux comparten unidades de CPU no asignadas con otros contenedores en la instancia de contenedor en la misma proporción que la cantidad asignada. Por ejemplo, si pone en marcha una tarea de contenedor único en un tipo de instancia de un solo núcleo con 512 unidades de CPU especificadas para dicho contenedor y esta es la única tarea que se pone en marcha en la instancia de contenedor, dicho contenedor podría utilizar las 1024 unidades de CPU en su totalidad en un momento dado. Sin embargo, si se lanza otra copia de la misma tarea en esa instancia de contenedor, cada tarea tiene garantizado un mínimo de 512 unidades de CPU cuando sea necesario. Además, cada contenedor podría aumentar el uso de la CPU si el otro contenedor no lo estuviera utilizando. Si ambas tareas estuvieran 100 % activas todo el tiempo, estarían limitadas a 512 unidades de la CPU. En las instancias de contenedor de Linux, el daemon de Docker en la instancia de contenedor utiliza el valor de CPU para calcular las proporciones de cuota de CPU relativas para los contenedores en ejecución. Para obtener más información, consulte la sección [CPU share constraint](https://docs.docker.com/engine/reference/run/#cpu-share-constraint) de la documentación de Docker. El valor de cuota de CPU válido mínimo que permite el kernel de Linux es 2. Sin embargo, el parámetro de la CPU no es obligatorio, y puede utilizar valores de la CPU por debajo de 2 en sus definiciones de contenedor. Para valores de CPU por debajo de 2 (incluido el valor nulo), el comportamiento varía en función de su versión de agente de contenedor de Amazon ECS: + **Versiones del agente inferiores o iguales a 1.1.0:** los valores de CPU nulo y cero se pasan a Docker como 0, y Docker los convierte a continuación a 1024 cuotas de CPU. Los valores de CPU de 1 se transfieren a Docker como 1, que el kernel de Linux convierte a 2 cuotas de CPU. + **Versiones del agente superiores o iguales a 1.2.0:** nulo, cero y los valores de CPU de 1 se transfieren a Docker como 2. En las instancias de contenedor de Windows, el límite de CPU se aplica como un límite absoluto o una cuota. Los contenedores de Windows solo tienen acceso a la cantidad de CPU especificada que se describe en la definición de tarea. Un valor de CPU nulo o cero se pasa a Docker como `0`, que Windows interpreta como 1 % de una CPU. ### Mapeos de puertos `portMappings` Tipo: matriz de objetos Obligatorio: no Las asignaciones de puertos exponen los puertos de red del contenedor al mundo exterior, lo que permite a los clientes acceder a su aplicación. También se utilizan para la comunicación entre contenedores dentro de la misma tarea. Para las definiciones de tareas que utilizan el modo de red `awsvpc`, solo especifique `containerPort`. El `hostPort` siempre se ignora y el puerto del contenedor se asigna automáticamente a un puerto aleatorio con un número alto del host. La mayoría de los campos de este parámetro (incluidos `containerPort`, `hostPort`, `protocol`) se corresponden con `PortBindings` en el comando create-container de docker y con la opción `--publish` para docker run. Si el modo de red de una definición de tareas se establece en `host`, los puertos de host deben estar sin definir o deben corresponder al puerto de contenedor en la asignación de puerto. Después de que una tarea alcanza el estado `RUNNING`, las asignaciones manuales y automáticas de puertos de contenedor y de host se pueden ver en las siguientes ubicaciones: + Consola: la sección **Network Bindings** (Conexiones de red) de la descripción de un contenedor para una tarea seleccionada. + AWS CLI: la sección `networkBindings` de la salida del comando **describe-tasks**. + API: la respuesta de `DescribeTasks`. + Metadatos: el punto de conexión de metadatos de la tarea. `appProtocol` Tipo: cadena Requerido: no El protocolo de aplicación que se utiliza para la asignación de puertos. Este parámetro solo se aplica a Service Connect. Recomendamos que defina este parámetro para que sea coherente con el protocolo que utiliza la aplicación. Si se establece este parámetro, Amazon ECS agrega la administración de la conexión específica del protocolo al proxy de Service Connect. Si se establece este parámetro, Amazon ECS agrega telemetría específica del protocolo en la consola de Amazon ECS y CloudWatch. Si no establece un valor para este parámetro, se utilizará TCP. Sin embargo, Amazon ECS no agrega telemetría específica del protocolo para TCP. Para obtener más información, consulte [Uso de Service Connect para conectar los servicios de Amazon ECS con nombres abreviados](service-connect.md). Valores de protocolo válidos: `"HTTP" | "HTTP2" | "GRPC" ` `containerPort` Tipo: número entero Obligatorio: sí, si se utilizan `portMappings`. El número de puerto en el contenedor que está vinculado al puerto de host especificado por el usuario o asignado automáticamente. Para las tareas que utilizan el modo de red `awsvpc`, debe utilizar `containerPort` para especificar los puertos expuestos. `containerPortRange` Tipo: cadena Requerido: no El rango de números de puerto en el contenedor que está vinculado al rango de puertos de host asignado de manera dinámica. Solo puede configurar este parámetro mediante la API `register-task-definition`. La opción está disponible en el parámetro `portMappings`. Para obtener más información, consulte [register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html) en la *Referencia de AWS Command Line Interface*. Las siguientes reglas se aplican al especificar un `containerPortRange`: + Debe usar el modo de red `awsvpc`. + La instancia de contenedor debe tener al menos la versión 1.67.0 del agente de contenedor y al menos la versión 1.67.0-1 del paquete `ecs-init` + Puede especificar 100 rangos de puertos como máximo por cada contenedor. + No especifica un `hostPortRange`. El valor de `hostPortRange` se establece de la siguiente manera: + Para los contenedores de una tarea con el modo de red `awsvpc`, `hostPort` se establece en el mismo valor que `containerPort`. Se trata de una estrategia de asignación estática. + Los valores válidos de `containerPortRange` se encuentran entre 1 y 65 535. + Un puerto solo puede incluirse en una asignación de puertos por cada contenedor. + No puede especificar rangos de puertos superpuestos. + El primer puerto del rango debe ser menor que el último puerto del rango. + Docker recomienda desactivar el docker-proxy en el archivo de configuración del daemon de Docker cuando haya una gran cantidad de puertos. Para más información, consulte [Issue \$111185](https://github.com/moby/moby/issues/11185) en GitHub. Para obtener información sobre cómo desactivar el docker-proxy en el archivo de configuración del daemon de Docker, consulte Daemon de [https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon) en la *Guía para desarrolladores de Amazon ECS*. Puede llamar a [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) para ver el valor de `hostPortRange`, es decir, los puertos del host que están vinculados a los puertos del contenedor. Los rangos de puertos no se incluyen en los eventos de tareas de Amazon ECS que se envían a EventBridge. Para obtener más información, consulte [Automaticzación de las respuestas a los errores de Amazon ECS mediante EventBridge](cloudwatch_event_stream.md). `hostPortRange` Tipo: string Requerido: no El rango de números de puerto del host que se usa con el enlace de red. Docker lo asigna y el agente de Amazon ECS lo entrega. `hostPort` Tipo: entero Obligatorio: no El número de puerto en la instancia de contenedor que reservar para el contenedor. El valor de `hostPort` puede dejarse en blanco o debe ser el mismo valor que `containerPort`. La versión 1.6.0 de Docker y posteriores para el rango de puertos efímeros predeterminado se puede ver en la instancia en `/proc/sys/net/ipv4/ip_local_port_range`. Si este parámetro de kernel no está disponible, se usa el intervalo de puertos efímeros predeterminado, de `49153–65535`. No intente especificar un puerto de host en el rango de puertos efímeros. Esto se debe a que están reservados para la asignación automática. En general, los puertos bajo `32768` están fuera del rango de puertos efímeros. Los puertos reservados predeterminados son el `22` para SSH; los puertos de Docker `2375` y `2376` y los puertos `51678-51680` del agente de contenedor de Amazon ECS. Cualquier puerto de host especificado por el usuario con anterioridad para una tarea en ejecución también se reserva mientras la tarea está en ejecución. Cuando se detiene una tarea, se libera el puerto del host. Los puertos reservados actuales se muestran en los `remainingResources` de la salida de **describe-container-instances**. Es posible que una instancia de contenedor tenga hasta 100 puertos reservados por vez, incluidos los puertos reservados predeterminados. Los puertos asignados automáticamente no se contabilizan para la cuota de 100 puertos reservados. `name` Tipo: cadena Obligatorio: no, es obligatorio para configurar Service Connect y VPC Lattice en un servicio El nombre que se utiliza para la asignación de puertos. Este parámetro solo se aplica a Service Connect y VPC Lattice. Este parámetro es el nombre que se utiliza en la configuración de Service Connect y VPC Lattice de un servicio. Para obtener más información, consulte [Uso de Service Connect para conectar los servicios de Amazon ECS con nombres abreviados](service-connect.md). En el siguiente ejemplo, se utilizan los dos campos obligatorios de Service Connect y VPC Lattice. ``` "portMappings": [ { "name": string, "containerPort": integer } ] ``` `protocol` Tipo: cadena Requerido: no El protocolo que se utiliza para la asignación de puertos. Los valores válidos son `tcp` y `udp`. El valor predeterminado es `tcp`. Solo `tcp` es compatible con Service Connect. Recuerde que `tcp` está implícito si este campo no está configurado. Utilice la sintaxis a continuación para especificar un puerto de host. ``` "portMappings": [ { "containerPort": integer, "hostPort": integer } ... ] ``` Use la siguiente sintaxis si desea asignar automáticamente un puerto de host. ``` "portMappings": [ { "containerPort": integer } ... ] ``` ### Credenciales de repositorio privado `repositoryCredentials` Tipo: objeto de [RepositoryCredentials](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RepositoryCredentials.html) Obligatorio: no Las credenciales del repositorio para la autenticación de registros privados. Para obtener más información, consulte [Uso de imágenes de contenedor que no sean de AWS en Amazon ECS](private-auth.md). `credentialsParameter` Tipo: cadena Obligatorio: sí, si se utilizan `repositoryCredentials`. El nombre de recurso de Amazon (ARN) del secreto que contiene las credenciales del repositorio privado. Para obtener más información, consulte [Uso de imágenes de contenedor que no sean de AWS en Amazon ECS](private-auth.md). Cuando se utiliza la API de Amazon ECS, la AWS CLI o los SDK de AWS, si el secreto existe en la misma región que la tarea que se va a lanzar, se puede utilizar el ARN completo o el nombre del secreto. Cuando se utiliza la Consola de administración de AWS, debe especificar el ARN completo del secreto. A continuación, se incluye un fragmento de definición de tareas que muestra los parámetros necesarios: ``` "containerDefinitions": [ { "image": "private-repo/private-image", "repositoryCredentials": { "credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name" } } ] ``` ### Essential `essential` Tipo: Booleano Obligatorio: no Si el parámetro `essential` de un contenedor se marca como `true` y dicho contenedor falla o se detiene por algún motivo, se detienen todos los demás contenedores que forman parte de la tarea. Si el parámetro `essential` de un contenedor se marca como `false`, su error no afecta al resto de los contenedores en una tarea. Si este parámetro se omite, se supone que un contenedor es esencial. Todas las tareas deben tener al menos un contenedor esencial. Si tiene una tarea que está compuesta por varios contenedores, agrupe los contenedores que se utilizan para un fin común en componentes y separe los distintos componentes en diversas definiciones de tareas. Para obtener más información, consulte [Diseño de la arquitectura de su aplicación para Amazon ECS](application_architecture.md). ### Punto de entrada `entryPoint` Tipo: matriz de cadenas Obligatorio: no El punto de entrada que se transfiere al contenedor. Este parámetro se corresponde con `Entrypoint` en el comando create-container de docker y la opción `--entrypoint` con docker run. ``` "entryPoint": ["string", ...] ``` ### Comando `command` Tipo: matriz de cadenas Obligatorio: no El comando que se transfiere al contenedor. Este parámetro se corresponde con `Cmd` en el comando docker create-container y el parámetro `COMMAND` con la puesta en marcha de docker. Si hay varios argumentos, cada uno de ellos es una cadena separada en la matriz. ``` "command": ["string", ...] ``` ### Directorio de trabajo `workingDirectory` Tipo: cadena Requerido: no El directorio de trabajo para ejecutar los comandos dentro del contenedor. Este parámetro se corresponde con `WorkingDir` en el comando create-container de docker y la opción `--workdir` con docker run. ### Parámetros de definición de contenedor avanzados Los siguientes parámetros avanzados de definición de contenedor ofrecen capacidades ampliadas para el comando de docker run que se utiliza para lanzar contenedores en las instancias de contenedor de Amazon ECS. **Topics** + [Política de reinicio](#container_definition_restart_policy-managed-instances) + [Comprobación de estado](#container_definition_healthcheck-managed-instances) + [Entorno](#container_definition_environment-managed-instances) + [Seguridad](#container_definition_security-managed-instances) + [Configuración de red](#container_definition_network-managed-instances) + [Almacenamiento y registro](#container_definition_storage-managed-instances) + [Requisitos de recursos](#container_definition_resourcerequirements-managed-instances) + [Tiempos de espera de contenedor](#container_definition_timeout-managed-instances) + [Dependencia de contenedor](#container_definition_dependency-managed-instances) + [Controles del sistema](#container_definition_systemcontrols-managed-instances) + [Interactivo](#container_definition_interactive-managed-instances) + [Pseudo terminal](#container_definition_pseudoterminal-managed-instances) #### Política de reinicio `restartPolicy` La política de reinicio del contenedor y los parámetros de configuración asociados. Al configurar una política de reinicio para un contenedor, Amazon ECS puede reiniciar el contenedor sin necesidad de reemplazar la tarea. Para obtener más información, consulte [Reinicio de contenedores individuales en tareas de Amazon ECS con políticas de reinicio de contenedores](container-restart-policy.md). `enabled` Tipo: booleano Obligatorio: sí Especifica si una política de reinicio está habilitada para el contenedor. `ignoredExitCodes` Tipo: matriz de enteros Obligatorio: no Una lista de códigos de salida que Amazon ECS ignorará y no intentará reiniciar. Puede especificar un máximo de 50 códigos de salida de contenedor. De forma predeterminada, Amazon ECS no ignora ningún código de salida. `restartAttemptPeriod` Tipo: entero Obligatorio: no La cantidad de tiempo (en segundos) que debe ejecutarse el contenedor antes de que se pueda intentar un reinicio. Un contenedor solo se puede reiniciar una vez cada `restartAttemptPeriod` segundos. Si un contenedor no puede ejecutarse durante este período de tiempo y se cierra antes, no se reiniciará. Puede especificar un mínimo `restartAttemptPeriod` de 60 segundos y un `restartAttemptPeriod` máximo de 1.800 segundos. De forma predeterminada, un contenedor debe ejecutarse durante 300 segundos antes de poder reiniciarse. #### Comprobación de estado `healthCheck` El parámetro de comprobación de estado del contenedor y los parámetros de configuración asociados para el contenedor. Para obtener más información, consulte [Determine el estado de las tareas de Amazon ECS mediante comprobaciones de estado de los contenedores](healthcheck.md). `command` Una matriz de cadenas que representa el comando que ejecuta el contenedor para determinar si está en buen estado. La matriz de cadenas puede comenzar por `CMD` para ejecutar los argumentos del comando directamente, o por `CMD-SHELL` para ejecutar el comando con el shell predeterminado del contenedor. Si no se especifica ninguno, se utiliza `CMD`. Al registrar una definición de tarea en la Consola de administración de AWS, utilice una lista de comandos separados por comas. Estos comandos se convierten en una cadena una vez que se cree la definición de tareas. A continuación, se muestra un ejemplo de entrada de comprobación de estado. ``` CMD-SHELL, curl -f http://localhost/ || exit 1 ``` Cuando registre una definición de tarea mediante el panel de JSON de la Consola de administración de AWS, la AWS CLI o las API, incluya la lista de comandos entre corchetes. A continuación, se muestra un ejemplo de entrada de comprobación de estado. ``` [ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ] ``` Un código de salida de 0, sin salida `stderr`, indica una ejecución correcta y cualquier código de salida distinto de cero indica un error. `interval` El periodo de tiempo (en segundos) entre cada comprobación de estado. Es posible especificar entre 5 y 300 segundos. El valor predeterminado es de 30 segundos. `timeout` El periodo de tiempo (en segundos) que hay que esperar para que una comprobación de estado se realice correctamente antes de que se considere un error. Puede especificar entre 2 y 60 segundos. El valor predeterminado es 5 segundos. `retries` Es el número de veces que se reintenta una comprobación de estado fallida antes de que se considere que el contenedor está en mal estado. Puede especificar entre 1 y 10 reintentos. El valor predeterminado es tres reintentos. `startPeriod` El periodo de gracia opcional dentro del cual se puede proporcionar tiempo a los contenedores para el arranque antes de que una comprobación de estado fallida se cuente para el número máximo de reintentos. Puede especificar un valor comprendido entre 0 y 300 segundos. De forma predeterminada, `startPeriod` está deshabilitado. Si una comprobación de estado se realiza correctamente dentro del periodo indicado en `startPeriod`, se considera que el estado del contenedor es correcto y los errores posteriores se contabilizan al calcular el número máximo de intentos. #### Entorno `cpu` Tipo: entero Obligatorio: no El número de unidades de `cpu` que el agente de contenedor de Amazon ECS reserva para el contenedor. En Linux, este parámetro se corresponde con `CpuShares` en la sección [Crear un contenedor](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate). Este campo es opcional para las tareas que se ponen en marcha en instancias administradas de Amazon ECS. La cantidad total de CPU reservada para todos los contenedores dentro de una tarea debe ser menor que el valor `cpu` de la tarea. Los contenedores de Linux comparten unidades de CPU no asignadas con otros contenedores en la instancia de contenedor en la misma proporción que la cantidad asignada. Por ejemplo, supongamos que ejecuta una tarea de contenedor único en un tipo de instancia de un solo núcleo con 512 unidades de CPU especificadas para dicho contenedor. Además, esa tarea es la única que se ejecuta en la instancia de contenedor. En este ejemplo, el contenedor puede utilizar la cuota completa de 1024 unidades de CPU en un momento dado. Sin embargo, supongamos que lanzó otra copia de la misma tarea en esa instancia de contenedor. Cada tarea tiene garantizado un mínimo de 512 unidades de CPU cuando sea necesario. Del mismo modo, si el otro contenedor no utiliza la CPU restante, cada contenedor puede aumentar el uso de la CPU. Sin embargo, si ambas tareas estuvieran 100 % activas todo el tiempo, están limitadas a 512 unidades de CPU. En las instancias de contenedor de Linux, el daemon de Docker en la instancia de contenedor utiliza el valor de CPU para calcular las proporciones de cuota de CPU relativas para los contenedores en ejecución. El valor de cuota de CPU válido mínimo que permite el kernel de Linux es 2 y el valor de cuota de CPU válido máximo que permite el kernel de Linux es 262144. Sin embargo, el parámetro de CPU no es obligatorio y puede utilizar valores de CPU por debajo de 2 y por encima de 262144 en las definiciones de contenedor. Para valores de CPU por debajo de 2 (incluido el valor nulo) y por encima de 262144, el comportamiento varía en función de la versión de agente de contenedor de Amazon ECS: Para ver otros ejemplos, consulte [Cómo administra Amazon ECS los recursos de CPU y memoria](https://aws.amazon.com/blogs/containers/how-amazon-ecs-manages-cpu-and-memory-resources/). `gpu` Tipo: objeto [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obligatorio: no El número de `GPUs` físicas que el agente de contenedor de Amazon ECS reserva para el contenedor. El número de GPU reservadas para todos los contenedores de una tarea no debe superar el número de GPU disponibles en la instancia de contenedor en la que se lanza la tarea. Para obtener más información, consulte [Definiciones de tareas de Amazon ECS para cargas de trabajo de GPU](ecs-gpu.md). `Elastic Inference accelerator` Este parámetro no es compatible con los contenedores alojados en instancias administradas de Amazon ECS. Tipo: objeto [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obligatorio: no Para el tipo `InferenceAccelerator`, el `value` coincide con el `deviceName` para un `InferenceAccelerator` especificado en una definición de tareas. Para obtener más información, consulte [Nombre del acelerador de Elastic Inference (en desuso)](task_definition_parameters.md#elastic-Inference-accelerator). `essential` Tipo: Booleano Obligatorio: no Supongamos que el parámetro `essential` de un contenedor se marca como `true` y dicho contenedor falla o se detiene por algún motivo. A continuación, se detienen todos los demás contenedores que forman parte de la tarea. Si el parámetro `essential` de un contenedor se marca como `false`, su error no afecta al resto de los contenedores en una tarea. Si este parámetro se omite, se supone que un contenedor es esencial. Todas las tareas deben tener al menos un contenedor esencial. Supongamos que tiene una aplicación compuesta por varios contenedores. Agrupe los contenedores que se utilizan para un fin común en componentes y sepárelos en diversas definiciones de tareas. Para obtener más información, consulte [Diseño de la arquitectura de su aplicación para Amazon ECS](application_architecture.md). ``` "essential": true|false ``` `entryPoint` Las primeras versiones del agente de contenedor de Amazon ECS no tratan correctamente los parámetros `entryPoint`. Si tiene problemas al utilizar `entryPoint` , actualice el agente de contenedor o introduzca los comandos y argumentos como elementos de matriz de `command` en su lugar. Tipo: matriz de cadenas Obligatorio: no El punto de entrada que se transfiere al contenedor. ``` "entryPoint": ["string", ...] ``` `command` Tipo: matriz de cadenas Obligatorio: no El comando que se transfiere al contenedor. Este parámetro se corresponde con `Cmd` en el comando create-container y el parámetro `COMMAND` para ejecutar el docker. Si hay varios argumentos, asegúrese de que cada uno de ellos sea una cadena distinta en la matriz. ``` "command": ["string", ...] ``` `workingDirectory` Tipo: cadena Requerido: no El directorio de trabajo para ejecutar los comandos dentro del contenedor. Este parámetro se corresponde con `WorkingDir` en la sección [Crear un contenedor](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) de la [API remota de Docker](https://docs.docker.com/reference/api/engine/version/v1.38/) y con la opción `--workdir` de [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/). ``` "workingDirectory": "string" ``` `environmentFiles` Tipo: matriz de objetos Obligatorio: no Una lista de archivos que contienen las variables de entorno que transferir a un contenedor. Este parámetro se corresponde con la opción `--env-file` del comando de docker run. Puede especificar hasta diez archivos de entorno. El archivo debe tener una extensión de archivo `.env` Cada línea de un archivo de entorno contiene una variable de entorno con el formato `VARIABLE=VALUE`. Las líneas que comienzan por `#` se tratan como comentarios y se ignoran. Si hay variables de entorno individuales especificadas en la definición del contenedor, tienen prioridad sobre las variables que contiene un archivo de entorno. Si se especifican varios archivos de entorno que contienen la misma variable, se procesan en orden descendente. Le recomendamos que utilice nombres de variables únicos. Para obtener más información, consulte [Transferencia de una variable de entorno individual a un contenedor de Amazon ECS](taskdef-envfiles.md). `value` Tipo: cadena Obligatorio: sí Nombre de recurso de Amazon (ARN) del objeto Amazon S3 que contiene el archivo de variable de entorno. `type` Tipo: cadena Obligatorio: sí Tipo de archivo que se utilizará. El único valor admitido es `s3`. `environment` Tipo: matriz de objetos Obligatorio: no Las variables de entorno a transferir a un contenedor. Este parámetro se corresponde con `Env` en el comando create-container de docker y la opción `--env` con el comando de docker run. No es recomendable que utilice variables del entorno en texto sin formato para información confidencial, como los datos de las credenciales. `name` Tipo: cadena Obligatorio: sí, si se utiliza `environment` El nombre de la variable de entorno. `value` Tipo: cadena Obligatorio: sí, si se utiliza `environment` El valor de la variable de entorno. ``` "environment" : [ { "name" : "string", "value" : "string" }, { "name" : "string", "value" : "string" } ] ``` `secrets` Tipo: matriz de objetos Obligatorio: no Un objeto que representa el secreto que se expone en el contenedor. Para obtener más información, consulte [Transferencia de datos confidenciales a un contenedor de Amazon ECS](specifying-sensitive-data.md). `name` Tipo: cadena Obligatorio: sí El valor que se ha de establecer como la variable de entorno en el contenedor. `valueFrom` Tipo: cadena Obligatorio: sí El secreto para exponer en el contenedor. Los valores admitidos son el nombre de recurso de Amazon (ARN) completo del secreto de AWS Secrets Manager o el ARN completo del parámetro en el almacén de parámetros de AWS Systems Manager. Si el parámetro del Almacén de parámetros de Systems Manager o el parámetro de Secrets Manager existe en la misma Región de AWS que la tarea que se va a lanzar, se puede utilizar el ARN completo o el nombre del secreto. Si el parámetro existe en una región distinta, el ARN completo debe especificarse. ``` "secrets": [ { "name": "environment_variable_name", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name" } ] ``` #### Seguridad `privileged` Tipo: Booleano Obligatorio: no Cuando este parámetro es `true`, al contenedor se le conceden privilegios elevados en la instancia de contenedor de host, (similares a los de un usuario `root`) Este parámetro se corresponde con `Privileged` en el comando create-container de docker y la opción `--privileged` se corresponde con docker run. `user` Tipo: cadena Requerido: no El usuario que se utiliza dentro del contenedor. Este parámetro se corresponde con `User` en el comando create-container de docker y la opción `--user` con docker run. Cuando ejecute tareas utilizando el modo de red `host`, no ejecute contenedores con el usuario raíz (UID 0). Se recomienda utilizar un usuario que no sea usuario raíz para aumentar la seguridad. Puede especificar el elemento `user` utilizando los siguientes formatos. Si se especifica un UID o GID, debe especificarlo como número entero positivo. + `user` + `user:group` + `uid` + `uid:gid` + `user:gid` + `uid:group` `readonlyRootFilesystem` Tipo: Booleano Obligatorio: no Cuando este parámetro es `true`, al contenedor se le concede un sistema de archivos raíz de solo lectura. Este parámetro se corresponde con `ReadonlyRootfs` en el comando create-container de docker y la opción `--read-only` con docker run. `dockerSecurityOptions` Este parámetro no es compatible con las tareas que se ponen en marcha en instancias administradas de Amazon ECS. Tipo: matriz de cadenas Obligatorio: no Una lista de cadenas para proporcionar etiquetas para sistemas de seguridad multinivel SELinux y AppArmor. Este campo no es válido para contenedores en tareas que utilizan Fargate. `ulimits` Tipo: matriz de objetos [Ulimit](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html) Obligatorio: no Una lista de `ulimits` que definir en el contenedor. Si se especifica un valor ulimit en la definición de una tarea, anula los valores predeterminados establecidos por Docker. Este parámetro se corresponde con `Ulimits` en el comando create-container de docker y la opción `--ulimit` se corresponde con docker run. Los valores de nomenclatura válidos se muestran en el tipo de datos [Ulimit](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html). Las tareas de Amazon ECS que se alojan en Fargate utilizan los valores de los límites de recursos predeterminados que establece el sistema, salvo el parámetro de límite de recursos `nofile` que anula Fargate. El límite de recursos `nofile` define una restricción en el número de archivos abiertos que puede utilizar un contenedor. El límite flexible `nofile` predeterminado es `1024` y el límite invariable predeterminado es `65535`. Este parámetro requiere la versión 1.18 de la API remota de Docker o superior en su instancia de contenedor. Para comprobar la versión de la API remota de Docker en su instancia de contenedor, inicie sesión en su instancia de contenedor y ejecute el comando siguiente: .: `sudo docker version --format '{{.Server.APIVersion}}'` `dockerLabels` Tipo: mapa de cadena a cadena Obligatorio: no Un mapa de clave/valor de etiquetas que agregar al contenedor. Este parámetro se corresponde con `Labels` en el comando create-container de docker y la opción `--label` se corresponde con docker run. Este parámetro requiere la versión 1.18 de la API remota de Docker o superior en su instancia de contenedor. ``` "dockerLabels": {"string": "string" ...} ``` #### Configuración de red `disableNetworking` Este parámetro no es compatible con las tareas que se ponen en marcha en instancias administradas de Amazon ECS. Tipo: Booleano Obligatorio: no Cuando este parámetro es verdadero, la conexión en red está apagada dentro del contenedor. El valor predeterminado es `false`. ``` "disableNetworking": true|false ``` `links` Este parámetro no es compatible con las tareas que se ponen en marcha en instancias administradas de Amazon ECS. Tipo: matriz de cadenas Obligatorio: no El parámetro `link` permite a los contenedores comunicarse entre sí sin la necesidad de mapeos de puerto. Este parámetro solo se admite si el modo de red de una definición de tarea se establece en `bridge`. El constructo `name:internalName` es análogo a `name:alias` en enlaces de Docker. Se admiten hasta 255 letras (mayúsculas y minúsculas), números, guiones y caracteres de subrayado. Es posible que los contenedores que se colocan en la misma instancia de contenedor puedan comunicarse entre sí sin necesidad de enlaces ni asignaciones de puerto de host. El aislamiento de red en una instancia de contenedor se controla mediante los grupos de seguridad y la configuración de VPC. ``` "links": ["name:internalName", ...] ``` `hostname` Este parámetro no es compatible con las tareas que se ponen en marcha en instancias administradas de Amazon ECS. Tipo: cadena Requerido: no El nombre de host que utilizar para el contenedor. Este parámetro se asigna a `Hostname` en el comando create-container de docker y la opción `--hostname` con docker run. ``` "hostname": "string" ``` `dnsServers` Este parámetro no es compatible con las tareas que se ponen en marcha en instancias administradas de Amazon ECS. Tipo: matriz de cadenas Obligatorio: no Una lista de servidores DNS que se presentan al contenedor. ``` "dnsServers": ["string", ...] ``` `extraHosts` Este parámetro no es compatible con los contenedores que utilizan el modo de red `awsvpc`. Tipo: matriz de objetos Obligatorio: no Una lista de nombres de host y mapeos de direcciones IP que añadir al archivo `/etc/hosts` en el contenedor. Este parámetro se corresponde con `ExtraHosts` en el comando create-container de docker y la opción `--add-host` se corresponde con docker run. ``` "extraHosts": [ { "hostname": "string", "ipAddress": "string" } ... ] ``` `hostname` Tipo: cadena Obligatorio: sí, si se utilizan `extraHosts`. El nombre de host para utilizar en la entrada `/etc/hosts`. `ipAddress` Tipo: cadena Obligatorio: sí, si se utilizan `extraHosts`. La dirección IP para utilizar en la entrada `/etc/hosts`. #### Almacenamiento y registro `readonlyRootFilesystem` Tipo: Booleano Obligatorio: no Cuando este parámetro es verdadero, al contenedor se le concede acceso de solo lectura a su sistema de archivos raíz. Este parámetro se corresponde con `ReadonlyRootfs` en el comando create-container de docker y la opción `--read-only` con docker run. El valor predeterminado es `false`. ``` "readonlyRootFilesystem": true|false ``` `mountPoints` Tipo: matriz de objetos Obligatorio: no Puntos de montaje para los volúmenes de datos del contenedor. Este parámetro asigna a `Volumes` en la API create-container de Docker y la opción `--volume` a docker run. Los contenedores de Windows pueden montar directorios completos en la misma unidad que `$env:ProgramData`. Los contenedores de Windows no pueden montar directorios en una unidad diferente y los puntos de montaje no se pueden utilizar entre unidades. Debe especificar los puntos de montaje para adjuntar un volumen de Amazon EBS directamente a una tarea de Amazon ECS. `sourceVolume` Tipo: cadena Obligatorio: sí, si se utilizan `mountPoints`. El nombre del volumen a montar. `containerPath` Tipo: cadena Obligatorio: sí, si se utilizan `mountPoints`. La ruta del contenedor donde se montará el volumen. `readOnly` Tipo: Booleano Obligatorio: no Si este valor es `true`, el acceso del contenedor al volumen es de solo lectura. Si este valor es `false`, el contenedor puede escribir en el volumen. El valor predeterminado es `false`. Para las tareas que se ejecutan en instancias de EC2 con sistema operativo Windows, deje el valor predeterminado `false`. `volumesFrom` Tipo: matriz de objetos Obligatorio: no Volúmenes de datos que montar desde otro contenedor. Este parámetro se corresponde con `VolumesFrom` en el comando create-container de docker y la opción `--volumes-from` se corresponde con docker run. `sourceContainer` Tipo: cadena Obligatorio: sí, si se utiliza `volumesFrom` El nombre del volumen contenedor desde el que montar los volúmenes. `readOnly` Tipo: Booleano Obligatorio: no Si este valor es `true`, el acceso del contenedor al volumen es de solo lectura. Si este valor es `false`, el contenedor puede escribir en el volumen. El valor predeterminado es `false`. ``` "volumesFrom": [ { "sourceContainer": "string", "readOnly": true|false } ] ``` `logConfiguration` Tipo: objeto [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html) Obligatorio: no La especificación de configuración de registros para el contenedor. Para obtener ejemplos de definiciones de tareas que utilizan una configuración de registro, consulte [Ejemplo de definiciones de tareas de Amazon ECS](example_task_definitions.md). Este parámetro se corresponde con `LogConfig` en el comando create-container de docker y la opción `--log-driver` se corresponde con docker run. De forma predeterminada, los contenedores utilizan el mismo controlador de registro que el daemon de Docker. No obstante, el contenedor podría utilizar un controlador de registro diferente al daemon de Docker especificando un controlador de registro con este parámetro en la definición de contenedor. Para utilizar un controlador de registro distinto para un contenedor, el sistema de registro se debe configurar correctamente en la instancia de contenedor (o en un servidor de registro distinto para opciones de registro remotas). Tenga cuenta lo siguiente al especificar una configuración de registros para los contenedores: + Amazon ECS admite un subconjunto de controladores de registro disponibles para el daemon de Docker. + Este parámetro requiere la versión 1.18 o posterior de la API remota de Docker en la instancia de contenedor. ``` "logConfiguration": { "logDriver": "awslogs",""splunk", "awsfirelens", "options": {"string": "string" ...}, "secretOptions": [{ "name": "string", "valueFrom": "string" }] } ``` `logDriver` Tipo: cadena Valores válidos: `"awslogs","splunk","awsfirelens"` Obligatorio: sí, si se utiliza `logConfiguration` El controlador de registro que utilizar para el contenedor. De forma predeterminada, los valores válidos mostrados anteriormente son controladores de registro con los que el agente de contenedor de Amazon ECS se puede comunicar. Los controladores de registro admitidos son `awslogs`, `splunk` y `awsfirelens`. Para obtener más información acerca del uso del controlador de registro `awslogs` en las definiciones de tareas para enviar los registros de contenedor a CloudWatch Logs, consulte [Envío de registros de Amazon ECS a CloudWatch](using_awslogs.md). Para obtener más información acerca del uso del controlado de registros de `awsfirelens`, consulte [Envío de registros de Amazon ECS a un servicio de AWS o AWS Partner](using_firelens.md). Si tiene un controlador personalizado que no figura en la lista, puede adaptar el proyecto del agente de contenedor de Amazon ECS que está [disponible en GitHub](https://github.com/aws/amazon-ecs-agent) y personalizarlo para que funcione con dicho controlador. Le recomendamos enviar solicitudes de inserción para los cambios que desea que incluyamos. No obstante, actualmente no admitimos la ejecución de copias modificadas de este software. Este parámetro requiere la versión 1.18 de la API remota de Docker o superior en su instancia de contenedor. `options` Tipo: mapa de cadena a cadena Obligatorio: no Las opciones de configuración de asignación clave/valor para enviar al controlador de registro. Las opciones que puede especificar dependen del controlador de registro. Algunas de las opciones que puede especificar cuando utiliza el router `awslogs` para enrutar los registros a Amazon CloudWatch son las siguientes: `awslogs-create-group` Obligatorio: no Especifique si desea que el grupo de registro se cree automáticamente. Si no se especifica esta opción, el valor predeterminado es `false`. Su política de IAM debe incluir el permiso `logs:CreateLogGroup` antes de intentar utilizar `awslogs-create-group`. `awslogs-region` Obligatorio: sí Especifique la Región de AWS a la que el controlador de registro `awslogs` enviará los registros de Docker. Puede elegir enviar todos los registros desde clústeres de diferentes regiones a una única región de CloudWatch Logs. Esto es para que todos sean visibles en una sola ubicación. De lo contrario, puede separarlos por región para obtener un mayor grado de detalle. Asegúrese de que el grupo de registro especificado exista en la región que especifique con esta opción. `awslogs-group` Obligatorio: sí Asegúrese de especificar un grupo de registro al que el controlador de registros `awslogs` envíe sus flujos de registros. `awslogs-stream-prefix` Obligatorio: sí Utilice esta opción `awslogs-stream-prefix` para asociar un flujo de registro con el prefijo especificado, el nombre del contenedor y el ID de la tarea de Amazon ECS a la que pertenece el contenedor. Si especifica un prefijo con esta opción, el flujo de registro adopta el siguiente formato. ``` prefix-name/container-name/ecs-task-id ``` Si no especifica un prefijo con esta opción, el flujo de registro se nombra según el ID del contenedor que asigna el daemon de Docker en la instancia de contenedor. Dado que es difícil realizar un seguimiento de los registros hasta el contenedor que los envió solo con el ID de contenedor de Docker (que solo está disponible en la instancia de contenedor), le recomendamos que especifique un prefijo con esta opción. En el caso de los servicios de Amazon ECS, puede utilizar el nombre del servicio como prefijo. De este modo, puede realizar un seguimiento de flujos de registros hasta el servicio al que pertenece el contenedor, el nombre del contenedor que los envió y el ID de la tarea a la que pertenece el contenedor. Debe especificar un prefijo de flujo para los registros para que aparezcan en el panel de registros al utilizar la consola de Amazon ECS. `awslogs-datetime-format` Obligatorio: no Esta opción define un patrón de inicio de varias líneas en formato `strftime` de Python. Un mensaje de registro consta de una línea que coincide con el patrón y de líneas siguientes que no coinciden con el patrón. La línea coincidente es el delimitador entre los mensajes de registro. Un ejemplo de caso de uso de este formato es para analizar la salida como un volcado de pila, que de lo contrario podría registrarse en varias entradas. El patrón correcto permite capturarla en una sola entrada. Para obtener más información, consulte [awslogs-datetime-format](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-datetime-format). No puede configurar las opciones `awslogs-datetime-format` y `awslogs-multiline-pattern` a la vez. El registro de varias líneas realiza análisis de las expresiones regulares y correspondencia de todos los mensajes de registro. Esto puede tener un impacto negativo sobre el rendimiento de registro. `awslogs-multiline-pattern` Obligatorio: no Esta opción define un patrón de inicio de varias líneas que utiliza una expresión regular. Un mensaje de registro consta de una línea que coincide con el patrón y de líneas siguientes que no coinciden con el patrón. La línea coincidente es el delimitador entre los mensajes de registro. Para obtener más información, consulte [awslogs-multiline-pattern](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-multiline-pattern). Esta opción se pasa por alto si también se ha configurado `awslogs-datetime-format`. No puede configurar las opciones `awslogs-datetime-format` y `awslogs-multiline-pattern` a la vez. El registro de varias líneas realiza análisis de las expresiones regulares y correspondencia de todos los mensajes de registro. Esto puede tener un impacto negativo sobre el rendimiento de registro. `mode` Obligatorio: no Valores válidos: `non-blocking` \$1 `blocking` Esta opción define el modo de entrega de los mensajes de registro del contenedor al controlador de registro de `awslogs`. El modo de entrega que elige afecta la disponibilidad de las aplicaciones cuando se interrumpe el flujo de registros desde el contenedor. Si utiliza el modo `blocking` y se interrumpe el flujo de registros a CloudWatch, se bloquearán las llamadas desde el código del contenedor para escribir en los flujos `stdout` y `stderr`. Como resultado, el hilo del registro de la aplicación se bloqueará. Esto puede provocar que la aplicación deje de responder y que se produzca un error en la comprobación del estado del contenedor. Si utiliza el modo `non-blocking`, los registros del contenedor se almacenan en un búfer intermedio en memoria configurado con la opción. `max-buffer-size` Esto evita que la aplicación deje de responder cuando los registros no se puedan enviar a CloudWatch. Le recomendamos que utilice este modo si quiere garantizar la disponibilidad del servicio y si no hay problema con la pérdida de registros. Para obtener más información, consulte [Evitar la pérdida de registros con el modo sin bloqueo en el controlador `awslogs` de registros del contenedor](https://aws.amazon.com/blogs/containers/preventing-log-loss-with-non-blocking-mode-in-the-awslogs-container-log-driver/). `max-buffer-size` Obligatorio: no Valor predeterminado: \$1: `1m` Cuando se utiliza el modo `non-blocking`, la opción de registro `max-buffer-size` controla el tamaño del búfer que se utiliza para el almacenamiento intermedio de mensajes. Asegúrese de especificar un tamaño de búfer adecuado en función de su aplicación. Cuando el búfer se llene, no se podrán almacenar más registros. Los registros que no se pueden almacenar se pierden. Para enrutar los registros mediante el enrutador de registros `splunk`, debe especificar un `splunk-token` y un `splunk-url`. Cuando utiliza el enrutador de registros `awsfirelens` para enrutar a un destino de Servicio de AWS o AWS Partner Network para el almacenamiento y análisis de registros, puede configurar la opción `log-driver-buffer-limit` hasta el límite del número de eventos almacenados en búfer en la memoria antes de enviarlos al contenedor del enrutador de registros. Puede ayudar a resolver el posible problema de pérdida de registros porque un alto rendimiento podría provocar que se quede sin memoria para el búfer dentro de Docker. Para obtener más información, consulte [Configuración de los registros de Amazon ECS para conseguir un alto rendimiento](firelens-docker-buffer-limit.md). Otras opciones que puede especificar cuando se utiliza `awsfirelens` para enrutar los registros dependen del destino. Al exportar registros a Amazon Data Firehose, puede especificar la Región de AWS con `region` y el nombre del flujo de registros con `delivery_stream`. Al exportar registros a Amazon Kinesis Data Streams, puede especificar una Región de AWS con `region` y un nombre de flujo de datos con `stream`. Al exportar registros a Amazon OpenSearch Service, puede especificar opciones como `Name`, `Host` (punto final de OpenSearch Service sin protocolo), `Port`, `Index`, `Type`, `Aws_auth`, `Aws_region`, `Suppress_Type_Name` y `tls`. Al exportar registros a Amazon S3, puede especificar el bucket mediante la opción `bucket`. También puede especificar `region`, `total_file_size`, `upload_timeout` y `use_put_object` como opciones. Este parámetro requiere la versión 1.19 de la API remota de Docker o superior en su instancia de contenedor. `secretOptions` Tipo: matriz de objetos Obligatorio: no Un objeto que representa el secreto que transferir a la configuración de registro. Los secretos utilizados en la configuración de registros pueden incluir un token de autenticación, un certificado o una clave de cifrado. Para obtener más información, consulte [Transferencia de datos confidenciales a un contenedor de Amazon ECS](specifying-sensitive-data.md). `name` Tipo: cadena Obligatorio: sí El valor que se ha de establecer como la variable de entorno en el contenedor. `valueFrom` Tipo: cadena Obligatorio: sí El secreto que exponer a la configuración de registro del contenedor. ``` "logConfiguration": { "logDriver": "splunk", "options": { "splunk-url": "https://cloud.splunk.com:8080", "splunk-token": "...", "tag": "...", ... }, "secretOptions": [{ "name": "splunk-token", "valueFrom": "/ecs/logconfig/splunkcred" }] } ``` `firelensConfiguration` Tipo: objeto [FirelensConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FirelensConfiguration.html) Obligatorio: no La configuración de FireLens para el contenedor. Esto se utiliza para especificar y configurar un enrutador de registro para registros de contenedores. Para obtener más información, consulte [Envío de registros de Amazon ECS a un servicio de AWS o AWS Partner](using_firelens.md). ``` { "firelensConfiguration": { "type": "fluentd", "options": { "KeyName": "" } } } ``` `options` Tipo: mapa de cadena a cadena Obligatorio: no Las opciones de asignación de clave/valor que se deben usar al configurar el enrutador de registros. Este campo es opcional y se puede utilizar para especificar un archivo de configuración personalizado o agregar metadatos adicionales, como la tarea, la definición de tareas, el clúster y detalles de la instancia de contenedor al evento de registro. Si se especifica, la sintaxis que se va a utilizar es `"options":{"enable-ecs-log-metadata":"true|false","config-file-type:"s3|file","config-file-value":"arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf|filepath"}`. Para obtener más información, consulte [Definición de tareas de Amazon ECS de ejemplo: enrutar registros a FireLens](firelens-taskdef.md). `type` Tipo: cadena Obligatorio: sí El router de registros que se va a utilizar. Los valores válidos son `fluentd` o `fluentbit`. #### Requisitos de recursos `resourceRequirements` Tipo: matriz de objetos [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obligatorio: no El tipo y la cantidad de un recurso para asignar a un contenedor. Actualmente, el único recurso admitido es una GPU. `type` Tipo: cadena Obligatorio: sí El tipo de recurso para asignar a un contenedor. El valor admitido es `GPU`. `value` Tipo: cadena Obligatorio: sí El valor del tipo de recurso especificado. Si se utiliza el tipo `GPU`, el valor es el número de `GPUs` físicas que el agente de contenedor de Amazon ECS reserva para el contenedor. El número de unidades GPU reservadas para todos los contenedores de una tarea no puede superar al número de GPU disponibles en la instancia de contenedor en la que se lanza la tarea. Las GPU no están disponibles para las tareas que se ponen en marcha en Fargate. #### Tiempos de espera de contenedor `startTimeout` Tipo: entero Obligatorio: no Valores de ejemplo: : `120` Tiempo que hay que esperar (en segundos) antes de desistir en resolver dependencias para un contenedor. Por ejemplo, se especifican dos contenedores en una definición de tareas donde `containerA` tenga una dependencia en `containerB` que alcance un estado `COMPLETE`, `SUCCESS` o `HEALTHY`. Si se especifica un valor `startTimeout` para `containerB` y este no alcanza el estado deseado en ese tiempo, `containerA` no se inicia. Si un contenedor no cumple una restricción de dependencia o agota el tiempo de espera antes de cumplir la restricción, Amazon ECS no adelanta los contenedores dependientes a su siguiente estado. El valor máximo es de 600 segundos (10 minutos). `stopTimeout` Tipo: entero Obligatorio: no Valores de ejemplo: : `120` Duración de tiempo (en segundos) que esperar a que el contenedor se cancelen de forma forzada si no sale de forma normal por sí mismo. Si no se especifica el parámetro, se utiliza el valor predeterminado de 30 segundos. El valor máximo es de 86,400 segundos (24 horas). #### Dependencia de contenedor `dependsOn` Tipo: matriz de objetos [ContainerDependency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html) Obligatorio: no Las dependencias definidas para el inicio y apagado del contenedor. Un contenedor puede contener varias dependencias. Cuando una dependencia se define para el inicio del contenedor, se invierte para el apagado del contenedor. Para ver un ejemplo, consulta [Dependencia de contenedor](example_task_definitions.md#example_task_definition-containerdependency). Si un contenedor no cumple una restricción de dependencia o agota el tiempo de espera antes de cumplir la restricción, Amazon ECS no adelanta los contenedores dependientes a su siguiente estado. Este parámetro requiere que la tarea o el servicio utilicen la versión de la plataforma `1.3.0` o una posterior (Linux) o `1.0.0` (Windows). ``` "dependsOn": [ { "containerName": "string", "condition": "string" } ] ``` `containerName` Tipo: cadena Obligatorio: sí El nombre del contenedor que debe cumplir la condición especificada. `condition` Tipo: cadena Obligatorio: sí La condición de dependencia del contenedor. Están disponibles las siguientes condiciones y su comportamiento: + `START`: esta condición simula el comportamiento de enlaces y volúmenes en la actualidad. La condición valida que un contenedor dependiente se inicia antes de permitir que se inicien otros contenedores. + `COMPLETE`: esta condición valida que un contenedor dependiente se ejecute hasta su finalización (se cierre) antes de permitir que otros contenedores se inicien. Esto puede resultar útil para contenedores no esenciales que ejecutan un script y, a continuación, se cierran. Esta condición no se puede establecer en un contenedor esencial. + `SUCCESS`: esta condición es la misma que `COMPLETE`, pero además requiere que el contenedor se cierre con un estado `zero`. Esta condición no se puede establecer en un contenedor esencial. + `HEALTHY`: esta condición valida que el contenedor dependiente pase su comprobación de estado de contenedor antes de permitir que otros contenedores se inicien. Esto requiere que el contenedor dependiente tenga configuradas las comprobaciones de estado en la definición de tarea. Esta condición solo se confirma durante el inicio de tarea. #### Controles del sistema `systemControls` Tipo: objeto [SystemControl](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_SystemControl.html) Obligatorio: no Una lista de parámetros de kernel del espacio de nombres que se van a establecer en el contenedor. Este parámetro se corresponde con `Sysctls` en el comando create-container de docker y la opción `--sysctl` con docker run. Por ejemplo, puede configurar la configuración `net.ipv4.tcp_keepalive_time` para mantener conexiones de mayor duración. No se recomienda especificar parámetros `systemControls` relacionados con la red para varios contenedores en una única tarea que también utilice el modo de red `awsvpc` u `host`. De ese modo, se obtienen las siguientes desventajas: + Si establece `systemControls` en cualquier contenedor, se aplicará a todos los contenedores de la tarea. Si establece diferentes parámetros `systemControls` para varios contenedores en una sola tarea, el contenedor que se inicie en último lugar determinará qué `systemControls` se aplicará. Si configura un espacio de nombres de recursos de IPC para usarlo para los contenedores de la tarea, se aplican las siguientes condiciones a los controles del sistema. Para obtener más información, consulte [Modo IPC](task_definition_parameters.md#task_definition_ipcmode). + Para las tareas que usan el modo de IPC `host`, no se admiten los `systemControls` del espacio de nombres IPC. + Para las tareas que utilizan el modo de IPC `task`, los valores de `systemControls` del espacio de nombres IPC se aplican a todos los contenedores de una tarea. ``` "systemControls": [ { "namespace":"string", "value":"string" } ] ``` `namespace` Tipo: cadena Requerido: no El parámetro de kernel del espacio de nombres para el que se va a establecer un `value`. Valores de espacio de nombres IPC válidos: `"kernel.msgmax" | "kernel.msgmnb" | "kernel.msgmni" | "kernel.sem" | "kernel.shmall" | "kernel.shmmax" | "kernel.shmmni" | "kernel.shm_rmid_forced"` y `Sysctls` que comiencen por `"fs.mqueue.*"` Valores de espacio de nombre de red válidos: `Sysctls` que comiencen con `"net.*"`. En Fargate solo se aceptan los `Sysctls` con espacios de nombre que existen dentro del contenedor. Todos estos valores son compatibles con Fargate. `value` Tipo: cadena Requerido: no El valor del parámetro de kernel del espacio de nombres especificado en `namespace`. #### Interactivo `interactive` Tipo: Booleano Obligatorio: no Si este parámetro es `true`, puede implementar aplicaciones en contenedores que requieran la asignación de `stdin` o un `tty`. Este parámetro se corresponde con `OpenStdin` en el comando create-container de docker y la opción `--interactive` con docker run. El valor predeterminado es `false`. #### Pseudo terminal `pseudoTerminal` Tipo: Booleano Obligatorio: no Cuando este parámetro es `true`, se asigna un TTY. Este parámetro se corresponde con `Tty` en el comando create-container de docker y la opción `--tty` con docker run. El valor predeterminado es `false`. ### Parámetros de Linux `linuxParameters` Tipo: objeto [LinuxParameters](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LinuxParameters.html) Obligatorio: no Modificaciones específicas de Linux que se aplican al contenedor, como las capacidades de kernel de Linux. `capabilities` Tipo: objeto [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html) Obligatorio: no Las capacidades de Linux para el contenedor que se añaden a la configuración predeterminada proporcionada por Docker o se eliminan de ella. `devices` Tipo: matriz de objetos [Dispositivo](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Device.html) Obligatorio: no Cualquier dispositivo host que exponer en el contenedor. Este parámetro se corresponde con `Devices` en el comando create-container de docker y la opción `--device` con docker run. `initProcessEnabled` Tipo: Booleano Obligatorio: no Ejecute un proceso `init` dentro del contenedor que reenvíe señales y aproveche procesos. Este parámetro se corresponde con la opción `--init` con docker run. `maxSwap` Este parámetro no es compatible con las tareas que se ponen en marcha en instancias administradas de Amazon ECS. Tipo: entero Obligatorio: no La cantidad total de memoria de intercambio (en MiB) que puede utilizar un contenedor. Este parámetro se traduce en la opción `--memory-swap` de docker run donde el valor es la suma de la memoria del contenedor más el valor de `maxSwap`. `swappiness` Este parámetro no es compatible con las tareas que se ponen en marcha en instancias administradas de Amazon ECS. Tipo: entero Obligatorio: no Esta opción le permite ajustar el comportamiento de intercambio de memoria de un contenedor. Un valor `swappiness` de `0` impide que ocurra el intercambio a menos que sea absolutamente necesario. Un valor de `swappiness` de `100` incrementa al máximo el intercambio de páginas. Los valores válidos son números enteros comprendidos entre `0` y `100`. Si no se especifica el parámetro `swappiness`, se utiliza el valor predeterminado de `60`. Si no se especifica ningún valor para `maxSwap`, este parámetro se omite. Este parámetro se corresponde con la opción `--memory-swappiness` con docker run. `sharedMemorySize` Este parámetro no es compatible con las tareas que se ponen en marcha en instancias administradas de Amazon ECS. Tipo: entero Obligatorio: no El tamaño (en MiB) del volumen `/dev/shm`. Este parámetro se corresponde con la opción `--shm-size` con docker run. `tmpfs` Tipo: matriz de objetos [Tmpfs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Tmpfs.html) Obligatorio: no La ruta del contenedor, las opciones de montaje y el tamaño (en MiB) del tmpfs montado. Este parámetro se corresponde con la opción `--tmpfs` con docker run. # Parámetros en la definición de tareas de Amazon ECS para Fargate Las definiciones de tareas se dividen en partes independientes: la familia de tareas, el rol de tarea de AWS Identity and Access Management (IAM), el modo de red, las definiciones de contenedor, los volúmenes y los tipos de lanzamiento. En una definición de tareas, son necesarias las definiciones de familia y contenedor. En cambio, el rol de tarea, el modo de red, los volúmenes y el tipo de lanzamiento son opcionales. Puede utilizar estos parámetros en un archivo JSON para configurar la definición de tarea. A continuación, se muestran las descripciones de cada parámetro de la definición de tareas para Fargate. ## Familia `family` Tipo: cadena Obligatorio: sí Cuando se registra una definición de tarea, se le da una familia, que es similar a un nombre para varias versiones de la definición de tarea, especificado con un número de revisión. A la primera definición de tareas que se registra en una familia particular se le da una revisión de 1 y a cualquier definición de tarea registrada después se le da un número de revisión secuencial. ## Capacidad Cuando se registre una definición de tareas, puede especificar la capacidad que con respecto a la cual Amazon ECS debe validar la definición de tareas. Si la definición de tareas no se valida con respecto a las compatibilidades especificadas, se devuelve una excepción de cliente. El parámetro a continuación está permitido en una definición de tareas. `requiresCompatibilities` Tipo: matriz de cadenas Obligatorio: no Valores válidos: `FARGATE` La capacidad con la que se validó la definición de tareas. Esto inicia una comprobación para garantizar que todos los parámetros que se utilizan en la definición de tareas cumplan los requisitos de Fargate. ## Rol de de la tarea `taskRoleArn` Tipo: cadena Requerido: no Cuando se registra una definición de tareas, se puede proporcionar un rol de tarea para un rol de IAM que permita a los contenedores del permiso de tareas llamar en su nombre a las API de AWS especificadas en sus políticas asociadas. Para obtener más información, consulte [Rol de IAM de tarea de Amazon ECS](task-iam-roles.md). ## Rol de ejecución de tareas `executionRoleArn` Tipo: cadena Obligatorio: condicional El nombre de recurso de Amazon (ARN) del rol de ejecución de tarea que concede permiso al agente de contenedor de Amazon ECS para realizar llamadas a la API de AWS en su nombre. El rol de IAM de ejecución de tareas es necesario en función de los requisitos de la tarea. Para obtener más información, consulte [Rol de IAM de ejecución de tareas de Amazon ECS](task_execution_IAM_role.md). ## Modo de red `networkMode` Tipo: cadena Obligatorio: sí El modo de red de Docker que utilizar para los contenedores en la tarea. Para las tareas de Amazon ECS alojadas en Fargate, se requiere el modo de red `awsvpc`. ## Plataforma de tiempo de ejecución `operatingSystemFamily` Tipo: cadena Obligatorio: condicional Predeterminado: LINUX Este parámetro es necesario para las tareas de Amazon ECS que están alojadas en Fargate. Cuando se registra una definición de tarea, especifica la familia de sistemas operativos. Los valores válidos son `LINUX`, `WINDOWS_SERVER_2025_FULL`, `WINDOWS_SERVER_2025_CORE`, `WINDOWS_SERVER_2022_FULL`, `WINDOWS_SERVER_2022_CORE`, `WINDOWS_SERVER_2019_FULL` y `WINDOWS_SERVER_2019_CORE`. Todas las definiciones de tareas que se utilizan en un servicio deben tener el mismo valor para este parámetro. Cuando una definición de tarea forma parte de un servicio, este valor debe coincidir con el valor `platformFamily` de servicio. `cpuArchitecture` Tipo: cadena Obligatorio: condicional Predeterminado: X86\$164 Si el parámetro se deja como `null`, el valor predeterminado se asigna automáticamente al iniciar una tarea alojada en Fargate. Cuando se registra una definición de tarea, especifica la arquitectura de CPU. Los valores válidos son `X86_64` y `ARM64`. Todas las definiciones de tareas que se utilizan en un servicio deben tener el mismo valor para este parámetro. Si tiene tareas de Linux, puede establecer el valor en `ARM64`. Para obtener más información, consulte [Definiciones de tareas de Amazon ECS para cargas de trabajo de ARM de 64 bits](ecs-arm64.md). ## Tamaño de tarea Cuando se registra una definición de tareas, puede especificar la cantidad total de CPU y memoria usada para la tarea. Es distinto de los valores `cpu` y `memory` en el nivel de definición de contenedor. Para las tareas que están alojadas en Fargate (tanto en Linux como en Windows), estos campos son obligatorios y se admiten valores específicos para `cpu` y `memory`. El siguiente parámetro está permitido en una definición de tarea: `cpu` Tipo: cadena Obligatorio: sí Los parámetros de CPU y memoria a nivel de tarea son necesarios y se utilizan para determinar el tipo y el tamaño de la instancia en la que se ejecutan las tareas. En el caso de las tareas de Windows, estos valores no se aplican en tiempo de ejecución, ya que Windows no tiene un mecanismo nativo que pueda imponer fácilmente límites de recursos colectivos a un grupo de contenedores. Si desea imponer límites de recursos, le recomendamos que utilice los recursos a nivel de contenedor para los contenedores de Windows. El límite máximo de unidades de CPU que presentar para la tarea. Puede indicar los valores de la CPU en el archivo JSON como una cadena en unidades de CPU o CPU virtuales (vCPU). Por ejemplo, puede especificar un valor de CPU `1024` en unidades de CPU o `1 vCPU` en vCPU. Cuando se registra la definición de tarea, el valor de una CPU virtual se convierte en un entero que indica las unidades de CPU. Este campo es obligatorio y debe utilizar uno de los siguientes valores, lo que determina el intervalo de valores válidos para el parámetro `memory`. En la siguiente tabla se muestran las combinaciones válidas de CPU y memoria de nivel de tarea. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/task_definition_parameters.html) `memory` Tipo: cadena Obligatorio: sí Los parámetros de CPU y memoria a nivel de tarea son necesarios y se utilizan para determinar el tipo y el tamaño de la instancia en la que se ejecutan las tareas. En el caso de las tareas de Windows, estos valores no se aplican en tiempo de ejecución, ya que Windows no tiene un mecanismo nativo que pueda imponer fácilmente límites de recursos colectivos a un grupo de contenedores. Si desea imponer límites de recursos, le recomendamos que utilice los recursos a nivel de contenedor para los contenedores de Windows. El límite máximo de memoria para presentar a la tarea. Puede especificar los valores de memoria en la definición de tareas como una cadena en mebibytes (MiB) o gigabytes (GB). Por ejemplo, puede especificar un valor de memoria `3072` en MiB o `3 GB` en GB. Cuando se registra la definición de tarea, el valor de GB se convierte en un entero que indica el número de MiB. Este campo es obligatorio y debe utilizar uno de los siguientes valores, lo que determina el intervalo de valores válidos para el parámetro `cpu`: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/task_definition_parameters.html) ## Definiciones de contenedores Al registrar una definición de tarea, debe especificar una lista de definiciones de contenedor que se transfieren al daemon de Docker en una instancia de contenedor. Los siguientes parámetros están permitidos en una definición de contenedor. **Topics** + [Parámetros de definición de contenedor estándar](#standard_container_definition_params) + [Parámetros de definición de contenedor avanzados](#advanced_container_definition_params) + [Otros parámetros de definición de contenedor](#other_container_definition_params) ### Parámetros de definición de contenedor estándar Los siguientes parámetros de definición de tarea son obligatorios o utilizados en la mayoría de definiciones de contenedor. **Topics** + [Nombre](#container_definition_name) + [Image](#container_definition_image) + [Memoria](#container_definition_memory) + [Mapeos de puertos](#container_definition_portmappings) + [Credenciales de repositorio privado](#container_definition_repositoryCredentials) #### Nombre `name` Tipo: cadena Obligatorio: sí El nombre de un contenedor. Se admiten hasta 255 letras (mayúsculas y minúsculas), números, guiones y caracteres de subrayado. Si está vinculando varios contenedores en una definición de tareas, el `name` de un contenedor se puede introducir en los `links` de otro contenedor. Esto sirve para conectar los contenedores. #### Image `image` Tipo: cadena Obligatorio: sí La imagen que se utiliza para iniciar un contenedor. Esta cadena se transfiere directamente al daemon de Docker. De manera predeterminada, las imágenes del registro de Docker Hub están disponibles. También puede especificar otros repositorios con `repository-url/image:tag` o `repository-url/image@digest`. Se permiten hasta 255 letras (mayúsculas y minúsculas), números, guiones, caracteres de subrayado, comas, puntos, barras diagonales y signos numéricos. Este parámetro se corresponde con `Image` en el comando create-container de docker y el parámetro `IMAGE` del comando de docker run. + Cuando se inicia una tarea nueva, el agente de contenedor de Amazon ECS extrae la última versión de la imagen y la etiqueta especificadas para que las utilice el contenedor. Sin embargo, las actualizaciones realizadas posteriormente en un repositorio de imágenes no se propagan a las tareas en ejecución. + Cuando no se especifica una etiqueta ni un resumen en la ruta de la imagen en la definición de la tarea, el agente de contenedores de Amazon ECS utiliza la etiqueta `latest` para extraer la imagen especificada. + Las actualizaciones que se hacen posteriormente en un repositorio de imágenes no se propagan a las tareas en marcha. + Se admiten las imágenes de registros privados. Para obtener más información, consulte [Uso de imágenes de contenedor que no sean de AWS en Amazon ECS](private-auth.md). + Para especificar imágenes de los repositorios de Amazon ECR, se puede utilizar la convención de nomenclatura completa `registry/repository:tag` o `registry/repository@digest` (por ejemplo, `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app:latest` o `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE`). + Las imágenes de los repositorios oficiales de Docker Hub utilizan un solo nombre (por ejemplo, `ubuntu` o `mongo`). + Las imágenes de otros repositorios de Docker Hub se clasifican con un nombre de organización (por ejemplo, `amazon/amazon-ecs-agent`). + Las imágenes de otros repositorios online se cualifican más con un nombre de dominio (por ejemplo, `quay.io/assemblyline/ubuntu`). `versionConsistency` Tipo: cadena Valores válidos: `enabled`\$1`disabled` Obligatorio: no Especifica si Amazon ECS convertirá la etiqueta de imagen de contenedores proporcionada en la definición de contenedores en un resumen de imágenes. De manera predeterminada, el comportamiento es `enabled`. Si establece `disabled` como valor de un contenedor, Amazon ECS no convertirá la etiqueta de imagen del contenedor en un resumen y utilizará el URI de imagen original especificado en la definición del contenedor para la implementación. Para obtener más información acerca de la conversión de imagen de contenedor, consulte [Resolución de imagen de contenedor](deployment-type-ecs.md#deployment-container-image-stability). #### Memoria `memory` Tipo: entero Obligatorio: no La cantidad (en MiB) de memoria que se presenta al contenedor. Si su contenedor intenta superar la memoria especificada aquí, el contenedor se cancela. La cantidad total de memoria reservada para todos los contenedores dentro de una tarea debe ser menor que el valor `memory` de la tarea, si se especifica. Este parámetro se corresponde con `Memory` en el comando create-container de docker y la opción `--memory` se corresponde con docker run. El daemon de Docker 20.10.0 o posterior reserva un mínimo de 6 MiB de memoria para un contenedor. Por lo tanto, no debe especificar menos de 6 MiB de memoria para los contenedores. El daemon de Docker 19.03.13-ce o anterior reserva un mínimo de 4 MiB de memoria para un contenedor. Por lo tanto, no debe especificar menos de 4 MiB de memoria para los contenedores. Si intenta maximizar la utilización de los recursos proporcionando a las tareas la mayor cantidad de memoria posible para un tipo de instancia determinado, consulte [Reserva de la memoria de instancias de contenedor de Linux de Amazon ECS](memory-management.md). `memoryReservation` Tipo: entero Obligatorio: no El límite flexible (en MiB) de memoria que reservar para el contenedor. Cuando la memoria del sistema está en conflicto, Docker intenta mantener la memoria del contenedor en este límite flexible. Sin embargo, el contenedor puede utilizar más memoria cuando sea necesario. El contenedor puede utilizar hasta el límite invariable especificado con el parámetro de `memory` (si procede) o toda la memoria disponible en la instancia de contenedor, lo que ocurra primero. Este parámetro se corresponde con `MemoryReservation` en el comando create-container de docker y la opción `--memory-reservation` se corresponde con docker run. Si no se especifica un valor de memoria de nivel de tarea, debe especificar un entero distinto de cero para `memory` o `memoryReservation`, o para ambos, en una definición de contenedor. Si especifica ambos, `memory` debe ser mayor que `memoryReservation`. Si especifica `memoryReservation`, el valor se resta de los recursos de memoria disponibles para la instancia de contenedor en la que se coloca el contenedor. De lo contrario, se utiliza el valor de `memory`. Por ejemplo, supongamos que el contenedor utiliza normalmente 128 MiB de memoria, pero con ráfagas ocasionales de hasta 256 MiB durante períodos de tiempo breves. Puede establecer una `memoryReservation` de 128 MiB y un límite invariable de `memory` de 300 MiB. Esta configuración permite al contenedor reservar solo 128 MiB de memoria de los recursos restantes en la instancia de contenedor. Al mismo tiempo, esta configuración también permite que el contenedor consuma más recursos de memoria en caso de ser necesario. Este parámetro no es compatible con los contenedores de Windows. El daemon de Docker 20.10.0 o posterior reserva un mínimo de 6 MiB de memoria para un contenedor. Por lo tanto, no debe especificar menos de 6 MiB de memoria para los contenedores. El daemon de Docker 19.03.13-ce o anterior reserva un mínimo de 4 MiB de memoria para un contenedor. Por lo tanto, no debe especificar menos de 4 MiB de memoria para los contenedores. Si intenta maximizar la utilización de los recursos proporcionando a las tareas la mayor cantidad de memoria posible para un tipo de instancia determinado, consulte [Reserva de la memoria de instancias de contenedor de Linux de Amazon ECS](memory-management.md). #### Mapeos de puertos `portMappings` Tipo: matriz de objetos Obligatorio: no Las asignaciones de puertos exponen los puertos de red del contenedor al mundo exterior, lo que permite a los clientes acceder a su aplicación. También se utilizan para la comunicación entre contenedores dentro de la misma tarea. Para las definiciones de tareas que utilizan el modo de red `awsvpc`, solo especifique `containerPort`. El `hostPort` siempre se ignora y el puerto del contenedor se asigna automáticamente a un puerto aleatorio con un número alto del host. Las asignaciones de puertos en Windows utilizan la dirección de puerto de enlace `NetNAT` en lugar de `localhost`. No existe ningún bucle invertido para el mapeo de puertos en Windows, por lo que no puede acceder a un puerto mapeado del contenedor desde el propio host. La mayoría de los campos de este parámetro (incluidos `containerPort`, `hostPort`, `protocol`) se corresponden con `PortBindings` en el comando create-container de docker y con la opción `--publish` para docker run. Si el modo de red de una definición de tareas se establece en `host`, los puertos de host deben estar sin definir o deben corresponder al puerto de contenedor en la asignación de puerto. Después de que una tarea alcanza el estado `RUNNING`, las asignaciones manuales y automáticas de puertos de contenedor y de host se pueden ver en las siguientes ubicaciones: + Consola: la sección **Network Bindings** (Conexiones de red) de la descripción de un contenedor para una tarea seleccionada. + AWS CLI: la sección `networkBindings` de la salida del comando **describe-tasks**. + API: la respuesta de `DescribeTasks`. + Metadatos: el punto de conexión de metadatos de la tarea. `appProtocol` Tipo: cadena Requerido: no El protocolo de aplicación que se utiliza para la asignación de puertos. Este parámetro solo se aplica a Service Connect. Recomendamos que defina este parámetro para que sea coherente con el protocolo que utiliza la aplicación. Si se establece este parámetro, Amazon ECS agrega la administración de la conexión específica del protocolo al proxy de Service Connect. Si se establece este parámetro, Amazon ECS agrega telemetría específica del protocolo en la consola de Amazon ECS y CloudWatch. Si no establece un valor para este parámetro, se utilizará TCP. Sin embargo, Amazon ECS no agrega telemetría específica del protocolo para TCP. Para obtener más información, consulte [Uso de Service Connect para conectar los servicios de Amazon ECS con nombres abreviados](service-connect.md). Valores de protocolo válidos: `"http" | "http2" | "grpc" ` `containerPort` Tipo: número entero Obligatorio: sí, si se utilizan `portMappings`. El número de puerto en el contenedor que está vinculado al puerto de host especificado por el usuario o asignado automáticamente. Para las tareas que utilizan el modo de red `awsvpc`, debe utilizar `containerPort` para especificar los puertos expuestos. Para los contenedores de Windows en Fargate, no se puede utilizar el puerto 3150 para el `containerPort`. Esto se debe a que está reservado. `containerPortRange` Tipo: cadena Requerido: no El rango de números de puerto en el contenedor que está vinculado al rango de puertos de host asignado de manera dinámica. Solo puede configurar este parámetro mediante la API `register-task-definition`. La opción está disponible en el parámetro `portMappings`. Para obtener más información, consulte [register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html) en la *Referencia de AWS Command Line Interface*. Las siguientes reglas se aplican al especificar un `containerPortRange`: + Debe usar el modo de red `awsvpc`. + Este parámetro está disponible tanto para sistemas operativos Windows como Linux. + La instancia de contenedor debe tener al menos la versión 1.67.0 del agente de contenedor y al menos la versión 1.67.0-1 del paquete `ecs-init` + Puede especificar 100 rangos de puertos como máximo por cada contenedor. + No especifica un `hostPortRange`. El valor de `hostPortRange` se establece de la siguiente manera: + Para los contenedores de una tarea con el modo de red `awsvpc`, `hostPort` se establece en el mismo valor que `containerPort`. Se trata de una estrategia de asignación estática. + Los valores válidos de `containerPortRange` se encuentran entre 1 y 65 535. + Un puerto solo puede incluirse en una asignación de puertos por cada contenedor. + No puede especificar rangos de puertos superpuestos. + El primer puerto del rango debe ser menor que el último puerto del rango. + Docker recomienda desactivar el docker-proxy en el archivo de configuración del daemon de Docker cuando haya una gran cantidad de puertos. Para más información, consulte [Issue \$111185](https://github.com/moby/moby/issues/11185) en GitHub. Para obtener información sobre cómo desactivar el docker-proxy en el archivo de configuración del daemon de Docker, consulte Daemon de [https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon) en la *Guía para desarrolladores de Amazon ECS*. Puede llamar a [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) para ver el valor de `hostPortRange`, es decir, los puertos del host que están vinculados a los puertos del contenedor. Los rangos de puertos no se incluyen en los eventos de tareas de Amazon ECS que se envían a EventBridge. Para obtener más información, consulte [Automaticzación de las respuestas a los errores de Amazon ECS mediante EventBridge](cloudwatch_event_stream.md). `hostPortRange` Tipo: string Requerido: no El rango de números de puerto del host que se usa con el enlace de red. Docker lo asigna y el agente de Amazon ECS lo entrega. `hostPort` Tipo: entero Obligatorio: no El número de puerto en la instancia de contenedor que reservar para el contenedor. El valor de `hostPort` puede dejarse en blanco o debe ser el mismo valor que `containerPort`. La versión 1.6.0 de Docker y posteriores para el rango de puertos efímeros predeterminado se puede ver en la instancia en `/proc/sys/net/ipv4/ip_local_port_range`. Si este parámetro de kernel no está disponible, se usa el intervalo de puertos efímeros predeterminado, de `49153–65535`. No intente especificar un puerto de host en el rango de puertos efímeros. Esto se debe a que están reservados para la asignación automática. En general, los puertos bajo `32768` están fuera del rango de puertos efímeros. Los puertos reservados predeterminados son el `22` para SSH; los puertos de Docker `2375` y `2376` y los puertos `51678-51680` del agente de contenedor de Amazon ECS. Cualquier puerto de host especificado por el usuario con anterioridad para una tarea en ejecución también se reserva mientras la tarea está en ejecución. Cuando se detiene una tarea, se libera el puerto del host. Los puertos reservados actuales se muestran en los `remainingResources` de la salida de **describe-container-instances**. Es posible que una instancia de contenedor tenga hasta 100 puertos reservados por vez, incluidos los puertos reservados predeterminados. Los puertos asignados automáticamente no se contabilizan para la cuota de 100 puertos reservados. `name` Tipo: cadena Obligatorio: no, es obligatorio para configurar Service Connect y VPC Lattice en un servicio El nombre que se utiliza para la asignación de puertos. Este parámetro solo se aplica a Service Connect y VPC Lattice. Este parámetro es el nombre que se utiliza en la configuración de Service Connect y VPC Lattice de un servicio. Para obtener más información, consulte [Uso de Service Connect para conectar los servicios de Amazon ECS con nombres abreviados](service-connect.md). En el siguiente ejemplo, se utilizan los dos campos obligatorios de Service Connect y VPC Lattice. ``` "portMappings": [ { "name": string, "containerPort": integer } ] ``` `protocol` Tipo: cadena Requerido: no El protocolo que se utiliza para la asignación de puertos. Los valores válidos son `tcp` y `udp`. El valor predeterminado es `tcp`. Solo `tcp` es compatible con Service Connect. Recuerde que `tcp` está implícito si este campo no está configurado. Utilice la sintaxis a continuación para especificar un puerto de host. ``` "portMappings": [ { "containerPort": integer, "hostPort": integer } ... ] ``` Use la siguiente sintaxis si desea asignar automáticamente un puerto de host. ``` "portMappings": [ { "containerPort": integer } ... ] ``` #### Credenciales de repositorio privado `repositoryCredentials` Tipo: objeto de [RepositoryCredentials](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RepositoryCredentials.html) Obligatorio: no Las credenciales del repositorio para la autenticación de registros privados. Para obtener más información, consulte [Uso de imágenes de contenedor que no sean de AWS en Amazon ECS](private-auth.md). `credentialsParameter` Tipo: cadena Obligatorio: sí, si se utilizan `repositoryCredentials`. El nombre de recurso de Amazon (ARN) del secreto que contiene las credenciales del repositorio privado. Para obtener más información, consulte [Uso de imágenes de contenedor que no sean de AWS en Amazon ECS](private-auth.md). Cuando se utiliza la API de Amazon ECS, la AWS CLI o los SDK de AWS, si el secreto existe en la misma región que la tarea que se va a lanzar, se puede utilizar el ARN completo o el nombre del secreto. Cuando se utiliza la Consola de administración de AWS, debe especificar el ARN completo del secreto. A continuación, se incluye un fragmento de definición de tareas que muestra los parámetros necesarios: ``` "containerDefinitions": [ { "image": "private-repo/private-image", "repositoryCredentials": { "credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name" } } ] ``` ### Parámetros de definición de contenedor avanzados Los siguientes parámetros avanzados de definición de contenedor ofrecen capacidades ampliadas para el comando de docker run que se utiliza para lanzar contenedores en las instancias de contenedor de Amazon ECS. **Topics** + [Política de reinicio](#container_definition_restart_policy) + [Comprobación de estado](#container_definition_healthcheck) + [Entorno](#container_definition_environment) + [Configuración de red](#container_definition_network) + [Almacenamiento y registro](#container_definition_storage) + [Seguridad](#container_definition_security) + [Límites de recursos](#container_definition_limits) + [Etiquetas de Docker](#container_definition_labels) #### Política de reinicio `restartPolicy` La política de reinicio del contenedor y los parámetros de configuración asociados. Al configurar una política de reinicio para un contenedor, Amazon ECS puede reiniciar el contenedor sin necesidad de reemplazar la tarea. Para obtener más información, consulte [Reinicio de contenedores individuales en tareas de Amazon ECS con políticas de reinicio de contenedores](container-restart-policy.md). `enabled` Tipo: booleano Obligatorio: sí Especifica si una política de reinicio está habilitada para el contenedor. `ignoredExitCodes` Tipo: matriz de enteros Obligatorio: no Una lista de códigos de salida que Amazon ECS ignorará y no intentará reiniciar. Puede especificar un máximo de 50 códigos de salida de contenedor. De forma predeterminada, Amazon ECS no ignora ningún código de salida. `restartAttemptPeriod` Tipo: entero Obligatorio: no La cantidad de tiempo (en segundos) que debe ejecutarse el contenedor antes de que se pueda intentar un reinicio. Un contenedor solo se puede reiniciar una vez cada `restartAttemptPeriod` segundos. Si un contenedor no puede ejecutarse durante este período de tiempo y se cierra antes, no se reiniciará. Puede especificar un mínimo `restartAttemptPeriod` de 60 segundos y un `restartAttemptPeriod` máximo de 1.800 segundos. De forma predeterminada, un contenedor debe ejecutarse durante 300 segundos antes de poder reiniciarse. #### Comprobación de estado `healthCheck` El parámetro de comprobación de estado del contenedor y los parámetros de configuración asociados para el contenedor. Para obtener más información, consulte [Determine el estado de las tareas de Amazon ECS mediante comprobaciones de estado de los contenedores](healthcheck.md). `command` Una matriz de cadenas que representa el comando que ejecuta el contenedor para determinar si está en buen estado. La matriz de cadenas puede comenzar por `CMD` para ejecutar los argumentos del comando directamente, o por `CMD-SHELL` para ejecutar el comando con el shell predeterminado del contenedor. Si no se especifica ninguno, se utiliza `CMD`. Al registrar una definición de tarea en la Consola de administración de AWS, utilice una lista de comandos separados por comas. Estos comandos se convierten en una cadena una vez que se cree la definición de tareas. A continuación, se muestra un ejemplo de entrada de comprobación de estado. ``` CMD-SHELL, curl -f http://localhost/ || exit 1 ``` Cuando registre una definición de tarea mediante el panel de JSON de la Consola de administración de AWS, la AWS CLI o las API, incluya la lista de comandos entre corchetes. A continuación, se muestra un ejemplo de entrada de comprobación de estado. ``` [ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ] ``` Un código de salida de 0, sin salida `stderr`, indica una ejecución correcta y cualquier código de salida distinto de cero indica un error. `interval` El periodo de tiempo (en segundos) entre cada comprobación de estado. Es posible especificar entre 5 y 300 segundos. El valor predeterminado es de 30 segundos. `timeout` El periodo de tiempo (en segundos) que hay que esperar para que una comprobación de estado se realice correctamente antes de que se considere un error. Puede especificar entre 2 y 60 segundos. El valor predeterminado es 5 segundos. `retries` Es el número de veces que se reintenta una comprobación de estado fallida antes de que se considere que el contenedor está en mal estado. Puede especificar entre 1 y 10 reintentos. El valor predeterminado es tres reintentos. `startPeriod` El periodo de gracia opcional dentro del cual se puede proporcionar tiempo a los contenedores para el arranque antes de que una comprobación de estado fallida se cuente para el número máximo de reintentos. Puede especificar un valor comprendido entre 0 y 300 segundos. De forma predeterminada, `startPeriod` está deshabilitado. Si una comprobación de estado se realiza correctamente dentro del periodo indicado en `startPeriod`, se considera que el estado del contenedor es correcto y los errores posteriores se contabilizan al calcular el número máximo de intentos. #### Entorno `cpu` Tipo: entero Obligatorio: no El número de unidades de `cpu` que el agente de contenedor de Amazon ECS reserva para el contenedor. En Linux, este parámetro se corresponde con `CpuShares` en la sección [Crear un contenedor](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate). Este campo es opcional para las tareas que utilizan Fargate. La cantidad total de CPU reservada para todos los contenedores dentro de una tarea debe ser menor que el valor `cpu` de la tarea. Los contenedores de Linux comparten unidades de CPU no asignadas con otros contenedores en la instancia de contenedor en la misma proporción que la cantidad asignada. Por ejemplo, supongamos que ejecuta una tarea de contenedor único en un tipo de instancia de un solo núcleo con 512 unidades de CPU especificadas para dicho contenedor. Además, esa tarea es la única que se ejecuta en la instancia de contenedor. En este ejemplo, el contenedor puede utilizar la cuota completa de 1024 unidades de CPU en un momento dado. Sin embargo, supongamos que lanzó otra copia de la misma tarea en esa instancia de contenedor. Cada tarea tiene garantizado un mínimo de 512 unidades de CPU cuando sea necesario. Del mismo modo, si el otro contenedor no utiliza la CPU restante, cada contenedor puede aumentar el uso de la CPU. Sin embargo, si ambas tareas estuvieran 100 % activas todo el tiempo, están limitadas a 512 unidades de CPU. En las instancias de contenedor de Linux, el daemon de Docker en la instancia de contenedor utiliza el valor de CPU para calcular las proporciones de cuota de CPU relativas para los contenedores en ejecución. El valor de cuota de CPU válido mínimo que permite el kernel de Linux es 2 y el valor de cuota de CPU válido máximo que permite el kernel de Linux es 262144. Sin embargo, el parámetro de CPU no es obligatorio y puede utilizar valores de CPU por debajo de 2 y por encima de 262144 en las definiciones de contenedor. Para valores de CPU por debajo de 2 (incluido el valor nulo) y por encima de 262144, el comportamiento varía en función de la versión de agente de contenedor de Amazon ECS: En las instancias de contenedor de Windows, la cuota de CPU se aplica como una cuota absoluta. Los contenedores de Windows solo tienen acceso a la cantidad de CPU especificada que se establece en la definición de tareas. Un valor de CPU nulo o cero se pasa a Docker como`0`. A continuación, Windows interpreta este valor como el 1 % de una CPU. Para ver otros ejemplos, consulte [Cómo administra Amazon ECS los recursos de CPU y memoria](https://aws.amazon.com/blogs/containers/how-amazon-ecs-manages-cpu-and-memory-resources/). `gpu` Este parámetro no es compatible con los contenedores que están alojados en Fargate. Tipo: objeto [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obligatorio: no El número de `GPUs` físicas que el agente de contenedor de Amazon ECS reserva para el contenedor. El número de GPU reservadas para todos los contenedores de una tarea no debe superar el número de GPU disponibles en la instancia de contenedor en la que se lanza la tarea. Para obtener más información, consulte [Definiciones de tareas de Amazon ECS para cargas de trabajo de GPU](ecs-gpu.md). `Elastic Inference accelerator` Este parámetro no es compatible con los contenedores que están alojados en Fargate. Tipo: objeto [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obligatorio: no Para el tipo `InferenceAccelerator`, el `value` coincide con el `deviceName` para un `InferenceAccelerator` especificado en una definición de tareas. Para obtener más información, consulte [Nombre del acelerador de Elastic Inference (en desuso)](#elastic-Inference-accelerator). `essential` Tipo: Booleano Obligatorio: no Supongamos que el parámetro `essential` de un contenedor se marca como `true` y dicho contenedor falla o se detiene por algún motivo. A continuación, se detienen todos los demás contenedores que forman parte de la tarea. Si el parámetro `essential` de un contenedor se marca como `false`, su error no afecta al resto de los contenedores en una tarea. Si este parámetro se omite, se supone que un contenedor es esencial. Todas las tareas deben tener al menos un contenedor esencial. Supongamos que tiene una aplicación compuesta por varios contenedores. Agrupe los contenedores que se utilizan para un fin común en componentes y sepárelos en diversas definiciones de tareas. Para obtener más información, consulte [Diseño de la arquitectura de su aplicación para Amazon ECS](application_architecture.md). ``` "essential": true|false ``` `entryPoint` Las primeras versiones del agente de contenedor de Amazon ECS no tratan correctamente los parámetros `entryPoint`. Si tiene problemas al utilizar `entryPoint` , actualice el agente de contenedor o introduzca los comandos y argumentos como elementos de matriz de `command` en su lugar. Tipo: matriz de cadenas Obligatorio: no El punto de entrada que se transfiere al contenedor. ``` "entryPoint": ["string", ...] ``` `command` Tipo: matriz de cadenas Obligatorio: no El comando que se transfiere al contenedor. Este parámetro se corresponde con `Cmd` en el comando create-container y el parámetro `COMMAND` para ejecutar el docker. Si hay varios argumentos, asegúrese de que cada uno de ellos sea una cadena distinta en la matriz. ``` "command": ["string", ...] ``` `workingDirectory` Tipo: cadena Requerido: no El directorio de trabajo para ejecutar los comandos dentro del contenedor. Este parámetro se corresponde con `WorkingDir` en la sección [Crear un contenedor](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) de la [API remota de Docker](https://docs.docker.com/reference/api/engine/version/v1.38/) y con la opción `--workdir` de [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/). ``` "workingDirectory": "string" ``` `environmentFiles` No está disponible para los contenedores de Windows en Fargate. Tipo: matriz de objetos Obligatorio: no Una lista de archivos que contienen las variables de entorno que transferir a un contenedor. Este parámetro se corresponde con la opción `--env-file` del comando de docker run. Puede especificar hasta diez archivos de entorno. El archivo debe tener una extensión de archivo `.env` Cada línea de un archivo de entorno contiene una variable de entorno con el formato `VARIABLE=VALUE`. Las líneas que comienzan por `#` se tratan como comentarios y se ignoran. Si hay variables de entorno individuales especificadas en la definición del contenedor, tienen prioridad sobre las variables que contiene un archivo de entorno. Si se especifican varios archivos de entorno que contienen la misma variable, se procesan en orden descendente. Le recomendamos que utilice nombres de variables únicos. Para obtener más información, consulte [Transferencia de una variable de entorno individual a un contenedor de Amazon ECS](taskdef-envfiles.md). `value` Tipo: cadena Obligatorio: sí Nombre de recurso de Amazon (ARN) del objeto Amazon S3 que contiene el archivo de variable de entorno. `type` Tipo: cadena Obligatorio: sí Tipo de archivo que se utilizará. El único valor admitido es `s3`. `environment` Tipo: matriz de objetos Obligatorio: no Las variables de entorno a transferir a un contenedor. Este parámetro se corresponde con `Env` en el comando create-container de docker y la opción `--env` con el comando de docker run. No es recomendable que utilice variables del entorno en texto sin formato para información confidencial, como los datos de las credenciales. `name` Tipo: cadena Obligatorio: sí, si se utiliza `environment` El nombre de la variable de entorno. `value` Tipo: cadena Obligatorio: sí, si se utiliza `environment` El valor de la variable de entorno. ``` "environment" : [ { "name" : "string", "value" : "string" }, { "name" : "string", "value" : "string" } ] ``` `secrets` Tipo: matriz de objetos Obligatorio: no Un objeto que representa el secreto que se expone en el contenedor. Para obtener más información, consulte [Transferencia de datos confidenciales a un contenedor de Amazon ECS](specifying-sensitive-data.md). `name` Tipo: cadena Obligatorio: sí El valor que se ha de establecer como la variable de entorno en el contenedor. `valueFrom` Tipo: cadena Obligatorio: sí El secreto para exponer en el contenedor. Los valores admitidos son el nombre de recurso de Amazon (ARN) completo del secreto de AWS Secrets Manager o el ARN completo del parámetro en el almacén de parámetros de AWS Systems Manager. Si el parámetro del Almacén de parámetros de Systems Manager o el parámetro de Secrets Manager existe en la misma Región de AWS que la tarea que se va a lanzar, se puede utilizar el ARN completo o el nombre del secreto. Si el parámetro existe en una región distinta, el ARN completo debe especificarse. ``` "secrets": [ { "name": "environment_variable_name", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name" } ] ``` #### Configuración de red `disableNetworking` Este parámetro no es compatible con las tareas que se ejecutan en Fargate. Tipo: Booleano Obligatorio: no Cuando este parámetro es verdadero, la conexión en red está apagada dentro del contenedor. El valor predeterminado es `false`. ``` "disableNetworking": true|false ``` `links` Este parámetro no es compatible con las tareas que utilizan el modo de red `awsvpc`. Tipo: matriz de cadenas Obligatorio: no El parámetro `link` permite a los contenedores comunicarse entre sí sin la necesidad de mapeos de puerto. Este parámetro solo se admite si el modo de red de una definición de tarea se establece en `bridge`. El constructo `name:internalName` es análogo a `name:alias` en enlaces de Docker. Se admiten hasta 255 letras (mayúsculas y minúsculas), números, guiones y caracteres de subrayado. Es posible que los contenedores que se colocan en la misma instancia de contenedor puedan comunicarse entre sí sin necesidad de enlaces ni asignaciones de puerto de host. El aislamiento de red en una instancia de contenedor se controla mediante los grupos de seguridad y la configuración de VPC. ``` "links": ["name:internalName", ...] ``` `hostname` Tipo: cadena Requerido: no El nombre de host que utilizar para el contenedor. Este parámetro se asigna a `Hostname` en el comando create-container de docker y la opción `--hostname` con docker run. Si utiliza el modo de red `awsvpc`, el parámetro `hostname` no se admite. ``` "hostname": "string" ``` `dnsServers` Esto no es compatible con las tareas que se ejecutan en Fargate. Tipo: matriz de cadenas Obligatorio: no Una lista de servidores DNS que se presentan al contenedor. ``` "dnsServers": ["string", ...] ``` `extraHosts` Este parámetro no es compatible con los contenedores que utilizan el modo de red `awsvpc`. Tipo: matriz de objetos Obligatorio: no Una lista de nombres de host y mapeos de direcciones IP que añadir al archivo `/etc/hosts` en el contenedor. Este parámetro se corresponde con `ExtraHosts` en el comando create-container de docker y la opción `--add-host` se corresponde con docker run. ``` "extraHosts": [ { "hostname": "string", "ipAddress": "string" } ... ] ``` `hostname` Tipo: cadena Obligatorio: sí, si se utilizan `extraHosts`. El nombre de host para utilizar en la entrada `/etc/hosts`. `ipAddress` Tipo: cadena Obligatorio: sí, si se utilizan `extraHosts`. La dirección IP para utilizar en la entrada `/etc/hosts`. #### Almacenamiento y registro `readonlyRootFilesystem` Tipo: Booleano Obligatorio: no Cuando este parámetro es verdadero, al contenedor se le concede acceso de solo lectura a su sistema de archivos raíz. Este parámetro se corresponde con `ReadonlyRootfs` en el comando create-container de docker y la opción `--read-only` con docker run. Este parámetro no es compatible con contenedores Windows. El valor predeterminado es `false`. ``` "readonlyRootFilesystem": true|false ``` `mountPoints` Tipo: matriz de objetos Obligatorio: no Puntos de montaje para los volúmenes de datos del contenedor. Este parámetro asigna a `Volumes` en la API create-container de Docker y la opción `--volume` a docker run. Los contenedores de Windows pueden montar directorios completos en la misma unidad que `$env:ProgramData`. Los contenedores de Windows no pueden montar directorios en una unidad diferente y los puntos de montaje no se pueden utilizar entre unidades. Debe especificar los puntos de montaje para adjuntar un volumen de Amazon EBS directamente a una tarea de Amazon ECS. `sourceVolume` Tipo: cadena Obligatorio: sí, si se utilizan `mountPoints`. El nombre del volumen a montar. `containerPath` Tipo: cadena Obligatorio: sí, si se utilizan `mountPoints`. La ruta del contenedor donde se montará el volumen. `readOnly` Tipo: Booleano Obligatorio: no Si este valor es `true`, el acceso del contenedor al volumen es de solo lectura. Si este valor es `false`, el contenedor puede escribir en el volumen. El valor predeterminado es `false`. Para las tareas que se ejecutan en instancias de EC2 con sistema operativo Windows, deje el valor predeterminado `false`. `volumesFrom` Tipo: matriz de objetos Obligatorio: no Volúmenes de datos que montar desde otro contenedor. Este parámetro se corresponde con `VolumesFrom` en el comando create-container de docker y la opción `--volumes-from` se corresponde con docker run. `sourceContainer` Tipo: cadena Obligatorio: sí, si se utiliza `volumesFrom` El nombre del volumen contenedor desde el que montar los volúmenes. `readOnly` Tipo: Booleano Obligatorio: no Si este valor es `true`, el acceso del contenedor al volumen es de solo lectura. Si este valor es `false`, el contenedor puede escribir en el volumen. El valor predeterminado es `false`. ``` "volumesFrom": [ { "sourceContainer": "string", "readOnly": true|false } ] ``` `logConfiguration` Tipo: objeto [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html) Obligatorio: no La especificación de configuración de registros para el contenedor. Para obtener ejemplos de definiciones de tareas que utilizan una configuración de registro, consulte [Ejemplo de definiciones de tareas de Amazon ECS](example_task_definitions.md). Este parámetro se corresponde con `LogConfig` en el comando create-container de docker y la opción `--log-driver` se corresponde con docker run. De forma predeterminada, los contenedores utilizan el mismo controlador de registro que el daemon de Docker. No obstante, el contenedor podría utilizar un controlador de registro diferente al daemon de Docker especificando un controlador de registro con este parámetro en la definición de contenedor. Para utilizar un controlador de registro distinto para un contenedor, el sistema de registro se debe configurar correctamente en la instancia de contenedor (o en un servidor de registro distinto para opciones de registro remotas). Tenga cuenta lo siguiente al especificar una configuración de registros para los contenedores: + Amazon ECS admite un subconjunto de controladores de registro disponibles para el daemon de Docker. + Este parámetro requiere la versión 1.18 o posterior de la API remota de Docker en la instancia de contenedor. + Debe instalar cualquier software adicional fuera de la tarea. Por ejemplo, los agregadores de salida de Fluentd o un host remoto que ejecute Logstash adonde se envían los registros de Gelf. ``` "logConfiguration": { "logDriver": "awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens", "options": {"string": "string" ...}, "secretOptions": [{ "name": "string", "valueFrom": "string" }] } ``` `logDriver` Tipo: cadena Valores válidos: `"awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens"` Obligatorio: sí, si se utiliza `logConfiguration` El controlador de registro que utilizar para el contenedor. De forma predeterminada, los valores válidos mostrados anteriormente son controladores de registro con los que el agente de contenedor de Amazon ECS se puede comunicar. Los controladores de registro admitidos son `awslogs`, `splunk` y `awsfirelens`. Para obtener más información acerca del uso del controlador de registro `awslogs` en las definiciones de tareas para enviar los registros de contenedor a CloudWatch Logs, consulte [Envío de registros de Amazon ECS a CloudWatch](using_awslogs.md). Para obtener más información sobre el uso del controlador del registro `awsfirelens`, consulte [Envío de registros personalizados](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html). Si tiene un controlador personalizado que no figura en la lista, puede adaptar el proyecto del agente de contenedor de Amazon ECS que está [disponible en GitHub](https://github.com/aws/amazon-ecs-agent) y personalizarlo para que funcione con dicho controlador. Le recomendamos enviar solicitudes de inserción para los cambios que desea que incluyamos. No obstante, actualmente no admitimos la ejecución de copias modificadas de este software. Este parámetro requiere la versión 1.18 de la API remota de Docker o superior en su instancia de contenedor. `options` Tipo: mapa de cadena a cadena Obligatorio: no Las opciones de configuración de asignación clave/valor para enviar al controlador de registro. Las opciones que puede especificar dependen del controlador de registro. Algunas de las opciones que puede especificar cuando utiliza el router `awslogs` para enrutar los registros a Amazon CloudWatch son las siguientes: `awslogs-create-group` Obligatorio: no Especifique si desea que el grupo de registro se cree automáticamente. Si no se especifica esta opción, el valor predeterminado es `false`. Su política de IAM debe incluir el permiso `logs:CreateLogGroup` antes de intentar utilizar `awslogs-create-group`. `awslogs-region` Obligatorio: sí Especifique la Región de AWS a la que el controlador de registro `awslogs` enviará los registros de Docker. Puede elegir enviar todos los registros desde clústeres de diferentes regiones a una única región de CloudWatch Logs. Esto es para que todos sean visibles en una sola ubicación. De lo contrario, puede separarlos por región para obtener un mayor grado de detalle. Asegúrese de que el grupo de registro especificado exista en la región que especifique con esta opción. `awslogs-group` Obligatorio: sí Asegúrese de especificar un grupo de registro al que el controlador de registros `awslogs` envíe sus flujos de registros. `awslogs-stream-prefix` Obligatorio: sí Utilice esta opción `awslogs-stream-prefix` para asociar un flujo de registro con el prefijo especificado, el nombre del contenedor y el ID de la tarea de Amazon ECS a la que pertenece el contenedor. Si especifica un prefijo con esta opción, el flujo de registro adopta el siguiente formato. ``` prefix-name/container-name/ecs-task-id ``` Si no especifica un prefijo con esta opción, el flujo de registro se nombra según el ID del contenedor que asigna el daemon de Docker en la instancia de contenedor. Dado que es difícil realizar un seguimiento de los registros hasta el contenedor que los envió solo con el ID de contenedor de Docker (que solo está disponible en la instancia de contenedor), le recomendamos que especifique un prefijo con esta opción. En el caso de los servicios de Amazon ECS, puede utilizar el nombre del servicio como prefijo. De este modo, puede realizar un seguimiento de flujos de registros hasta el servicio al que pertenece el contenedor, el nombre del contenedor que los envió y el ID de la tarea a la que pertenece el contenedor. Debe especificar un prefijo de flujo para los registros para que aparezcan en el panel de registros al utilizar la consola de Amazon ECS. `awslogs-datetime-format` Obligatorio: no Esta opción define un patrón de inicio de varias líneas en formato `strftime` de Python. Un mensaje de registro consta de una línea que coincide con el patrón y de líneas siguientes que no coinciden con el patrón. La línea coincidente es el delimitador entre los mensajes de registro. Un ejemplo de caso de uso de este formato es para analizar la salida como un volcado de pila, que de lo contrario podría registrarse en varias entradas. El patrón correcto permite capturarla en una sola entrada. Para obtener más información, consulte [awslogs-datetime-format](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-datetime-format). No puede configurar las opciones `awslogs-datetime-format` y `awslogs-multiline-pattern` a la vez. El registro de varias líneas realiza análisis de las expresiones regulares y correspondencia de todos los mensajes de registro. Esto puede tener un impacto negativo sobre el rendimiento de registro. `awslogs-multiline-pattern` Obligatorio: no Esta opción define un patrón de inicio de varias líneas que utiliza una expresión regular. Un mensaje de registro consta de una línea que coincide con el patrón y de líneas siguientes que no coinciden con el patrón. La línea coincidente es el delimitador entre los mensajes de registro. Para obtener más información, consulte [awslogs-multiline-pattern](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-multiline-pattern). Esta opción se pasa por alto si también se ha configurado `awslogs-datetime-format`. No puede configurar las opciones `awslogs-datetime-format` y `awslogs-multiline-pattern` a la vez. El registro de varias líneas realiza análisis de las expresiones regulares y correspondencia de todos los mensajes de registro. Esto puede tener un impacto negativo sobre el rendimiento de registro. Las siguientes opciones se aplican a todos los controladores de registro compatibles. `mode` Obligatorio: no Valores válidos: `non-blocking` \$1 `blocking` Esta opción define el modo de entrega de los mensajes de registro del contenedor al controlador de registro especificado con `logDriver`. El modo de entrega que elige afecta la disponibilidad de las aplicaciones cuando se interrumpe el flujo de registros desde el contenedor. Si utiliza el modo `blocking` y se interrumpe el flujo de registros, se bloquearán las llamadas desde el código del contenedor para escribir en los flujos `stdout` y `stderr`. Como resultado, el hilo del registro de la aplicación se bloqueará. Esto puede provocar que la aplicación deje de responder y que se produzca un error en la comprobación del estado del contenedor. Si utiliza el modo `non-blocking`, los registros del contenedor se almacenan en un búfer intermedio en memoria configurado con la opción. `max-buffer-size` Esto evita que la aplicación deje de responder cuando los registros no se puedan enviar. Le recomendamos que utilice este modo si quiere garantizar la disponibilidad del servicio y si no hay problema con la pérdida de registros. Para obtener más información, consulte [Evitar la pérdida de registros con el modo sin bloqueo en el controlador `awslogs` de registros del contenedor](https://aws.amazon.com/blogs/containers/preventing-log-loss-with-non-blocking-mode-in-the-awslogs-container-log-driver/). Puede establecer un `mode` predeterminado para todos los contenedores de una Región de AWS específica mediante la configuración de la cuenta de `defaultLogDriverMode`. Si no especifica la opción `mode` en `logConfiguration` ni configura los ajustes de la cuenta, Amazon ECS utilizará el modo `non-blocking` de manera predeterminada. Para obtener más información acerca de la configuración de la cuenta, consulte [Modo de controlador de registro predeterminado](ecs-account-settings.md#default-log-driver-mode). Cuando se utiliza el modo `non-blocking`, la opción de registro `max-buffer-size` controla el tamaño del búfer que se utiliza para el almacenamiento intermedio de mensajes. Asegúrese de especificar un tamaño de búfer adecuado en función de su aplicación. La cantidad total de memoria asignada a nivel de tarea debe ser superior a la cantidad de memoria asignada a todos los contenedores, además del búfer de memoria del controlador de registro. El 25 de junio de 2025, Amazon ECS cambió el modo de controlador de registro predeterminado de `blocking` a `non-blocking` a fin de priorizar la disponibilidad de las tareas sobre el registro. Para seguir utilizando el modo `blocking` después de este cambio, realice una de las siguientes acciones: + Establezca la opción `mode` en la `logConfiguration` de su definición de contenedor como `blocking`. + Establezca el ajuste de cuenta `defaultLogDriverMode` en `blocking`. `max-buffer-size` Obligatorio: no Valor predeterminado: \$1: `10m` Cuando se utiliza el modo `non-blocking`, la opción de registro `max-buffer-size` controla el tamaño del búfer que se utiliza para el almacenamiento intermedio de mensajes. Asegúrese de especificar un tamaño de búfer adecuado en función de su aplicación. Cuando el búfer se llene, no se podrán almacenar más registros. Los registros que no se pueden almacenar se pierden. Para enrutar los registros mediante el enrutador de registros `splunk`, debe especificar un `splunk-token` y un `splunk-url`. Cuando utiliza el enrutador de registros `awsfirelens` para enrutar a un destino de Servicio de AWS o AWS Partner Network para el almacenamiento y análisis de registros, puede configurar la opción `log-driver-buffer-limit` hasta el límite del número de líneas de registro almacenadas en búfer en la memoria antes de enviarlas al contenedor del enrutador de registros. Puede ayudar a resolver el posible problema de pérdida de registros porque un alto rendimiento podría provocar que se quede sin memoria para el búfer dentro de Docker. Para obtener más información, consulte [Configuración de los registros de Amazon ECS para conseguir un alto rendimiento](firelens-docker-buffer-limit.md). Otras opciones que puede especificar cuando se utiliza `awsfirelens` para enrutar los registros dependen del destino. Al exportar registros a Amazon Data Firehose, puede especificar la Región de AWS con `region` y el nombre del flujo de registros con `delivery_stream`. Al exportar registros a Amazon Kinesis Data Streams, puede especificar una Región de AWS con `region` y un nombre de flujo de datos con `stream`. Al exportar registros a Amazon OpenSearch Service, puede especificar opciones como `Name`, `Host` (punto final de OpenSearch Service sin protocolo), `Port`, `Index`, `Type`, `Aws_auth`, `Aws_region`, `Suppress_Type_Name` y `tls`. Al exportar registros a Amazon S3, puede especificar el bucket mediante la opción `bucket`. También puede especificar `region`, `total_file_size`, `upload_timeout` y `use_put_object` como opciones. Este parámetro requiere la versión 1.19 de la API remota de Docker o superior en su instancia de contenedor. `secretOptions` Tipo: matriz de objetos Obligatorio: no Un objeto que representa el secreto que transferir a la configuración de registro. Los secretos utilizados en la configuración de registros pueden incluir un token de autenticación, un certificado o una clave de cifrado. Para obtener más información, consulte [Transferencia de datos confidenciales a un contenedor de Amazon ECS](specifying-sensitive-data.md). `name` Tipo: cadena Obligatorio: sí El valor que se ha de establecer como la variable de entorno en el contenedor. `valueFrom` Tipo: cadena Obligatorio: sí El secreto que exponer a la configuración de registro del contenedor. ``` "logConfiguration": { "logDriver": "splunk", "options": { "splunk-url": "https://cloud.splunk.com:8080", "splunk-token": "...", "tag": "...", ... }, "secretOptions": [{ "name": "splunk-token", "valueFrom": "/ecs/logconfig/splunkcred" }] } ``` `firelensConfiguration` Tipo: objeto [FirelensConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FirelensConfiguration.html) Obligatorio: no La configuración de FireLens para el contenedor. Esto se utiliza para especificar y configurar un enrutador de registro para registros de contenedores. Para obtener más información, consulte [Envío de registros de Amazon ECS a un servicio de AWS o AWS Partner](using_firelens.md). ``` { "firelensConfiguration": { "type": "fluentd", "options": { "KeyName": "" } } } ``` `options` Tipo: mapa de cadena a cadena Obligatorio: no Las opciones de asignación de clave/valor que se deben usar al configurar el enrutador de registros. Este campo es opcional y se puede utilizar para especificar un archivo de configuración personalizado o agregar metadatos adicionales, como la tarea, la definición de tareas, el clúster y detalles de la instancia de contenedor al evento de registro. Si se especifica, la sintaxis que se va a utilizar es `"options":{"enable-ecs-log-metadata":"true|false","config-file-type:"s3|file","config-file-value":"arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf|filepath"}`. Para obtener más información, consulte [Definición de tareas de Amazon ECS de ejemplo: enrutar registros a FireLens](firelens-taskdef.md). `type` Tipo: cadena Obligatorio: sí El router de registros que se va a utilizar. Los valores válidos son `fluentd` o `fluentbit`. #### Seguridad Para obtener más información sobre la seguridad del contenedor, consulte [Prácticas recomendadas de seguridad para las tareas y contenedores de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-tasks-containers.html). `credentialSpecs` Tipo: matriz de cadenas Obligatorio: no Una lista de los ARN de SSM o Amazon S3 en un archivo de especificaciones de credenciales (`CredSpec`) que configura el contenedor para la autenticación de Active Directory. Le recomendamos que utilice este parámetro en lugar de `dockerSecurityOptions`. El número máximo de ARN es 1. Hay dos formatos para cada ARN. Especificación de credenciales sin dominio: MyARN Utiliza `credentialspecdomainless:MyARN` para proporcionar a la `CredSpec` una sección adicional para un secreto en Secrets Manager. Proporciona las credenciales de inicio de sesión al dominio en el secreto. Cada tarea que se ejecute en cualquier instancia de contenedor puede unirse a diferentes dominios. Puede utilizar este formato sin unir la instancia de contenedor a un dominio. Especificación de credenciales: MyARN Utiliza `credentialspec:MyARN` para proporcionar una `CredSpec` para un solo dominio. Debe unir la instancia de contenedor al dominio antes de iniciar cualquier tarea que utilice esta definición de tarea. En ambos formatos, sustituya `MyARN` por el ARN en SSM o Amazon S3. La `credspec` debe proporcionar un ARN en Secrets Manager para un secreto que contenga el nombre de usuario, la contraseña y el dominio para conectarse. Para mayor seguridad, la instancia no está unida al dominio para la autenticación sin dominio. Las demás aplicaciones de la instancia no pueden utilizar las credenciales sin dominio. Puede utilizar este parámetro para ejecutar tareas en la misma instancia, incluso si las tareas necesitan unirse a dominios diferentes. Para obtener más información, consulte [Uso de gMSA para contenedores de Windows](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/windows-gmsa.html) y [Uso de gMSA para contenedores de Linux](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/linux-gmsa.html). `user` Tipo: cadena Requerido: no El usuario que se utiliza dentro del contenedor. Este parámetro se corresponde con `User` en el comando create-container de docker y la opción `--user` con docker run. Al ejecutar tareas que utilizan el modo de red de `host`, no debe ejecutar contenedores con el usuario raíz (UID 0). Como práctica recomendada de seguridad, utilice siempre un usuario que no sea usuario raíz. Puede especificar el elemento `user` utilizando los siguientes formatos. Si se especifica un UID o GID, debe especificarlo como número entero positivo. + `user` + `user:group` + `uid` + `uid:gid` + `user:gid` + `uid:group` Este parámetro no es compatible con contenedores Windows. ``` "user": "string" ``` #### Límites de recursos `ulimits` Tipo: matriz de objetos Obligatorio: no Lista de valores `ulimit` a definir para un contenedor. Este valor sobrescribe la configuración predeterminada de la cuota de recursos para el sistema operativo. Este parámetro se corresponde con `Ulimits` en el comando create-container de docker y la opción `--ulimit` se corresponde con docker run. Las tareas de Amazon ECS alojadas en Fargate utilizan los valores límite de recursos predeterminados que establece el sistema operativo, a excepción del parámetro límite de recursos `nofile`. El límite de recursos `nofile` define una restricción en el número de archivos abiertos que puede utilizar un contenedor. En Fargate, el límite flexible `nofile` predeterminado es ` 65535` y el límite invariable es `65535`. Puede establecer los valores de ambos límites en un valor máximo de `1048576`. Para obtener más información, consulte [Límites de recursos de tareas](fargate-tasks-services.md#fargate-resource-limits). Este parámetro requiere la versión 1.18 de la API remota de Docker o superior en su instancia de contenedor. Este parámetro no es compatible con contenedores Windows. ``` "ulimits": [ { "name": "core"|"cpu"|"data"|"fsize"|"locks"|"memlock"|"msgqueue"|"nice"|"nofile"|"nproc"|"rss"|"rtprio"|"rttime"|"sigpending"|"stack", "softLimit": integer, "hardLimit": integer } ... ] ``` `name` Tipo: cadena Valores válidos: `"core" | "cpu" | "data" | "fsize" | "locks" | "memlock" | "msgqueue" | "nice" | "nofile" | "nproc" | "rss" | "rtprio" | "rttime" | "sigpending" | "stack"` Obligatorio: sí, si se utilizan `ulimits`. El valor `type` de `ulimit`. `hardLimit` Tipo: número entero Obligatorio: sí, si se utilizan `ulimits`. El límite máximo para el tipo de `ulimit`. El valor se puede especificar en bytes, segundos o como un conteo, según el `type` del `ulimit`. `softLimit` Tipo: número entero Obligatorio: sí, si se utilizan `ulimits`. El límite flexible para el tipo de `ulimit`. El valor se puede especificar en bytes, segundos o como un conteo, según el `type` del `ulimit`. #### Etiquetas de Docker `dockerLabels` Tipo: mapa de cadena a cadena Obligatorio: no Un mapa de clave/valor de etiquetas que agregar al contenedor. Este parámetro se corresponde con `Labels` en el comando create-container de docker y la opción `--label` se corresponde con docker run. Este parámetro requiere la versión 1.18 de la API remota de Docker o superior en su instancia de contenedor. ``` "dockerLabels": {"string": "string" ...} ``` ### Otros parámetros de definición de contenedor Los siguientes parámetros de definición de contenedor se pueden utilizar al registrar definiciones de tareas en la consola de Amazon ECS mediante la opción **Configure via JSON** (Configurar mediante JSON). Para obtener más información, consulte [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md). **Topics** + [Parámetros de Linux](#container_definition_linuxparameters) + [Dependencia de contenedor](#container_definition_dependson) + [Tiempos de espera de contenedor](#container_definition_timeout) + [Controles del sistema](#container_definition_systemcontrols) + [Interactivo](#container_definition_interactive) + [Pseudo terminal](#container_definition_pseudoterminal) #### Parámetros de Linux `linuxParameters` Tipo: objeto [LinuxParameters](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LinuxParameters.html) Obligatorio: no Opciones específicas de Linux que se aplican al contenedor, como [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html). Este parámetro no es compatible con los contenedores de Windows. ``` "linuxParameters": { "capabilities": { "add": ["string", ...], "drop": ["string", ...] } } ``` `capabilities` Tipo: objeto [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html) Obligatorio: no Las capacidades de Linux para el contenedor que se eliminan de la configuración predeterminada proporcionada por Docker. Para obtener más información sobre estas capacidades de Linux, consulte la página del manual de Linux sobre [capacidades(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html). `add` Tipo: matriz de cadenas Valores válidos: -.: `"SYS_PTRACE"` Obligatorio: no Las capacidades de Linux para el contenedor que se deben agregar a la configuración predeterminada proporcionada por Docker. Este parámetro se corresponde con `CapAdd` en el comando create-container de docker y la opción `--cap-add` se corresponde con docker run. `drop` Tipo: matriz de cadenas Valores válidos: -.: `"ALL" | "AUDIT_CONTROL" | "AUDIT_WRITE" | "BLOCK_SUSPEND" | "CHOWN" | "DAC_OVERRIDE" | "DAC_READ_SEARCH" | "FOWNER" | "FSETID" | "IPC_LOCK" | "IPC_OWNER" | "KILL" | "LEASE" | "LINUX_IMMUTABLE" | "MAC_ADMIN" | "MAC_OVERRIDE" | "MKNOD" | "NET_ADMIN" | "NET_BIND_SERVICE" | "NET_BROADCAST" | "NET_RAW" | "SETFCAP" | "SETGID" | "SETPCAP" | "SETUID" | "SYS_ADMIN" | "SYS_BOOT" | "SYS_CHROOT" | "SYS_MODULE" | "SYS_NICE" | "SYS_PACCT" | "SYS_PTRACE" | "SYS_RAWIO" | "SYS_RESOURCE" | "SYS_TIME" | "SYS_TTY_CONFIG" | "SYSLOG" | "WAKE_ALARM"` Obligatorio: no Las capacidades de Linux para el contenedor que se deben eliminar de la configuración predeterminada proporcionada por Docker. Este parámetro se corresponde con `CapDrop` en el comando create-container de docker y la opción `--cap-drop` con docker run. `devices` Cualquier dispositivo host que exponer en el contenedor. Este parámetro se corresponde con `Devices` en el comando create-container de docker y la opción `--device` con docker run. El parámetro `devices` no se admite cuando se utiliza el tipo de lanzamiento de Fargate. Tipo: matriz de objetos [Dispositivo](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Device.html) Obligatorio: no `hostPath` La ruta del dispositivo de la instancia de contenedor del host. Tipo: cadena Obligatorio: sí `containerPath` La ruta dentro del contenedor en la cual exponer el dispositivo host. Tipo: cadena Requerido: no `permissions` Los permisos explícitos que proporcionar al contenedor para el dispositivo. De forma predeterminada, el contenedor tiene permisos para `read`, `write` y `mknod` en el dispositivo. Tipo: matriz de cadenas Valores válidos: `read` \$1 `write` \$1 `mknod` `initProcessEnabled` Ejecute un proceso `init` dentro del contenedor que reenvíe señales y aproveche procesos. Este parámetro se corresponde con la opción `--init` con docker run. Este parámetro requiere la versión 1.25 de la API remota de Docker o superior en su instancia de contenedor. `maxSwap` Esto no es compatible con las tareas que se ejecutan en Fargate. La cantidad total de memoria de intercambio (en MiB) que puede utilizar un contenedor. Este parámetro se traduce en la opción `--memory-swap` de docker run donde el valor es la suma de la memoria del contenedor más el valor de `maxSwap`. Si se especifica un valor `maxSwap` para `0`, el contenedor no utiliza el intercambio. Los valores aceptados son `0` o cualquier entero positivo. Si se omite el parámetro `maxSwap`, el contenedor utiliza la configuración de intercambio de la instancia de contenedor en la que se está ejecutando. Debe establecerse un valor de `maxSwap` para el parámetro `swappiness`. `sharedMemorySize` El valor del tamaño (en MiB) del volumen `/dev/shm`. Este parámetro se corresponde con la opción `--shm-size` con docker run. Si utiliza tareas que utilizan Fargate, no se admite el parámetro `sharedMemorySize`. Tipo: número entero `tmpfs` La ruta del contenedor, las opciones de montaje y el tamaño máximo (en MiB) del montaje tmpfs. Este parámetro se corresponde con la opción `--tmpfs` con docker run. Tipo: matriz de objetos [Tmpfs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Tmpfs.html) Obligatorio: no `containerPath` La ruta de archivo absoluta en la que se montará el volumen tmpfs. Tipo: cadena Obligatorio: sí `mountOptions` La lista de opciones de montaje del volumen tmpfs. Tipo: matriz de cadenas Obligatorio: no Valores válidos: `"defaults" | "ro" | "rw" | "suid" | "nosuid" | "dev" | "nodev" | "exec" | "noexec" | "sync" | "async" | "dirsync" | "remount" | "mand" | "nomand" | "atime" | "noatime" | "diratime" | "nodiratime" | "bind" | "rbind" | "unbindable" | "runbindable" | "private" | "rprivate" | "shared" | "rshared" | "slave" | "rslave" | "relatime" | "norelatime" | "strictatime" | "nostrictatime" | "mode" | "uid" | "gid" | "nr_inodes" | "nr_blocks" | "mpol"` `size` El tamaño máximo (en MiB) del volumen tmpfs. Tipo: número entero Obligatorio: sí #### Dependencia de contenedor `dependsOn` Tipo: matriz de objetos [ContainerDependency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html) Obligatorio: no Las dependencias definidas para el inicio y apagado del contenedor. Un contenedor puede contener varias dependencias. Cuando una dependencia se define para el inicio del contenedor, se invierte para el apagado del contenedor. Para ver un ejemplo, consulta [Dependencia de contenedor](example_task_definitions.md#example_task_definition-containerdependency). Si un contenedor no cumple una restricción de dependencia o agota el tiempo de espera antes de cumplir la restricción, Amazon ECS no adelanta los contenedores dependientes a su siguiente estado. Este parámetro requiere que la tarea o el servicio utilicen la versión de la plataforma `1.3.0` o una posterior (Linux) o `1.0.0` (Windows). ``` "dependsOn": [ { "containerName": "string", "condition": "string" } ] ``` `containerName` Tipo: cadena Obligatorio: sí El nombre del contenedor que debe cumplir la condición especificada. `condition` Tipo: cadena Obligatorio: sí La condición de dependencia del contenedor. Están disponibles las siguientes condiciones y su comportamiento: + `START`: esta condición simula el comportamiento de enlaces y volúmenes en la actualidad. La condición valida que un contenedor dependiente se inicia antes de permitir que se inicien otros contenedores. + `COMPLETE`: esta condición valida que un contenedor dependiente se ejecute hasta su finalización (se cierre) antes de permitir que otros contenedores se inicien. Esto puede resultar útil para contenedores no esenciales que ejecutan un script y, a continuación, se cierran. Esta condición no se puede establecer en un contenedor esencial. + `SUCCESS`: esta condición es la misma que `COMPLETE`, pero además requiere que el contenedor se cierre con un estado `zero`. Esta condición no se puede establecer en un contenedor esencial. + `HEALTHY`: esta condición valida que el contenedor dependiente pase su comprobación de estado de contenedor antes de permitir que otros contenedores se inicien. Esto requiere que el contenedor dependiente tenga configuradas las comprobaciones de estado en la definición de tarea. Esta condición solo se confirma durante el inicio de tarea. #### Tiempos de espera de contenedor `startTimeout` Tipo: entero Obligatorio: no Valores de ejemplo: : `120` Tiempo que hay que esperar (en segundos) antes de desistir en resolver dependencias para un contenedor. Por ejemplo, se especifican dos contenedores en una definición de tareas donde `containerA` tenga una dependencia en `containerB` que alcance un estado `COMPLETE`, `SUCCESS` o `HEALTHY`. Si se especifica un valor `startTimeout` para `containerB` y este no alcanza el estado deseado en ese tiempo, `containerA` no se inicia. Si un contenedor no cumple una restricción de dependencia o agota el tiempo de espera antes de cumplir la restricción, Amazon ECS no adelanta los contenedores dependientes a su siguiente estado. Este parámetro requiere que la tarea o el servicio utilicen la versión de la plataforma `1.3.0` o una posterior (Linux). El valor máximo es 120 segundos. `stopTimeout` Tipo: entero Obligatorio: no Valores de ejemplo: : `120` Duración de tiempo (en segundos) que esperar a que el contenedor se cancelen de forma forzada si no sale de forma normal por sí mismo. Este parámetro requiere que la tarea o el servicio utilicen la versión de la plataforma `1.3.0` o una posterior (Linux). Si no se especifica el parámetro, se utiliza el valor predeterminado de 30 segundos. El valor máximo es 120 segundos. #### Controles del sistema `systemControls` Tipo: objeto [SystemControl](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_SystemControl.html) Obligatorio: no Una lista de parámetros de kernel del espacio de nombres que se van a establecer en el contenedor. Este parámetro se corresponde con `Sysctls` en el comando create-container de docker y la opción `--sysctl` con docker run. Por ejemplo, puede configurar la configuración `net.ipv4.tcp_keepalive_time` para mantener conexiones de mayor duración. No se recomienda especificar parámetros `systemControls` relacionados con la red para varios contenedores en una única tarea que también utilice el modo de red `awsvpc` u `host`. De ese modo, se obtienen las siguientes desventajas: + Si establece `systemControls` en cualquier contenedor, se aplicará a todos los contenedores de la tarea. Si establece diferentes parámetros `systemControls` para varios contenedores en una sola tarea, el contenedor que se inicie en último lugar determinará qué `systemControls` se aplicará. Si configura un espacio de nombres de recursos de IPC para usarlo para los contenedores de la tarea, se aplican las siguientes condiciones a los controles del sistema. Para obtener más información, consulte [Modo IPC](#task_definition_ipcmode). + Para las tareas que usan el modo de IPC `host`, no se admiten los `systemControls` del espacio de nombres IPC. + Para las tareas que utilizan el modo de IPC `task`, los valores de `systemControls` del espacio de nombres IPC se aplican a todos los contenedores de una tarea. Este parámetro no es compatible con contenedores Windows. Este parámetro solo se admite para las tareas que están alojadas en AWS Fargate si utilizan la versión de la plataforma `1.4.0` o una posterior (Linux). Este parámetro no es compatible con contenedores de Windows en Fargate. ``` "systemControls": [ { "namespace":"string", "value":"string" } ] ``` `namespace` Tipo: cadena Requerido: no El parámetro de kernel del espacio de nombres para el que se va a establecer un `value`. Valores de espacio de nombres IPC válidos: `"kernel.msgmax" | "kernel.msgmnb" | "kernel.msgmni" | "kernel.sem" | "kernel.shmall" | "kernel.shmmax" | "kernel.shmmni" | "kernel.shm_rmid_forced"` y `Sysctls` que comiencen por `"fs.mqueue.*"` Valores de espacio de nombre de red válidos: `Sysctls` que comiencen con `"net.*"`. En Fargate solo se aceptan los `Sysctls` con espacios de nombre que existen dentro del contenedor. Todos estos valores son compatibles con Fargate. `value` Tipo: cadena Requerido: no El valor del parámetro de kernel del espacio de nombres especificado en `namespace`. #### Interactivo `interactive` Tipo: Booleano Obligatorio: no Si este parámetro es `true`, puede implementar aplicaciones en contenedores que requieran la asignación de `stdin` o un `tty`. Este parámetro se corresponde con `OpenStdin` en el comando create-container de docker y la opción `--interactive` con docker run. El valor predeterminado es `false`. #### Pseudo terminal `pseudoTerminal` Tipo: Booleano Obligatorio: no Cuando este parámetro es `true`, se asigna un TTY. Este parámetro se corresponde con `Tty` en el comando create-container de docker y la opción `--tty` con docker run. El valor predeterminado es `false`. ## Nombre del acelerador de Elastic Inference (en desuso) El requisito de recursos del acelerador de Elastic Inference para la definición de tareas. **nota** Amazon Elastic Inference (EI) ya no está disponible para los clientes. Los siguientes parámetros están permitidos en una definición de tarea: `deviceName` Tipo: cadena Obligatorio: sí Nombre del dispositivo del acelerador de inferencia elástica. También debe hacerse referencia a `deviceName` en una definición de contenedor. Consulte [Elastic Inference accelerator](#ContainerDefinition-elastic-inference). `deviceType` Tipo: cadena Obligatorio: sí El tipo de acelerador de Elastic Inference que se va a utilizar. ## Configuración del proxy `proxyConfiguration` Tipo: objeto [ProxyConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ProxyConfiguration.html) Obligatorio: no Los detalles de configuración del proxy App Mesh. Este parámetro no es compatible con contenedores Windows. ``` "proxyConfiguration": { "type": "APPMESH", "containerName": "string", "properties": [ { "name": "string", "value": "string" } ] } ``` `type` Tipo: cadena Valores válidos: `APPMESH` Obligatorio: no El tipo de proxy. El único valor admitido es `APPMESH`. `containerName` Tipo: cadena Obligatorio: sí El nombre del contenedor que sirve como proxy de App Mesh. `properties` Tipo: matriz de objetos [KeyValuePair](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KeyValuePair.html) Obligatorio: no El conjunto de parámetros de configuración de red para proporcionar el complemento Container Network Interface (CNI), especificado como pares clave-valor. + `IgnoredUID`: (obligatorio) el ID de usuario (UID) del contenedor proxy tal y como lo define el parámetro `user` en una definición de contenedor. Se utiliza para garantizar que el proxy pasa por alto su propio tráfico. Si se especifica `IgnoredGID`, este campo puede estar vacío. + `IgnoredGID`: (obligatorio) el ID de grupo (GID) del contenedor proxy tal y como lo define el parámetro `user` en una definición de contenedor. Se utiliza para garantizar que el proxy pasa por alto su propio tráfico. Si se especifica `IgnoredUID`, este campo puede estar vacío. + `AppPorts`: (obligatorio) la lista de los puertos que utiliza la aplicación. El tráfico de red hacia estos puertos se reenvía a `ProxyIngressPort` y `ProxyEgressPort`. + `ProxyIngressPort`: (obligatorio) especifica el puerto al que se dirige el tráfico que ingresa a `AppPorts`. + `ProxyEgressPort`: (obligatorio) especifica el puerto al que se dirige el tráfico que sale de `AppPorts`. + `EgressIgnoredPorts`: (obligatorio) el tráfico de salida que se dirige a estos puertos especificados se pasa por alto y no se redirige a `ProxyEgressPort`. Puede ser una lista vacía. + `EgressIgnoredIPs`: (obligatorio) el tráfico de salida que se dirige a estas direcciones IP especificadas se pasa por alto y no se redirige a `ProxyEgressPort`. Puede ser una lista vacía. `name` Tipo: cadena Requerido: no El nombre del par clave-valor. `value` Tipo: cadena Requerido: no El valor del par clave-valor. ## Volúmenes Al registrar una definición de tareas, se puede especificar una lista de los volúmenes que se transferirán al daemon de Docker en una instancia de contenedor, que estará disponible para otros contenedores en la misma instancia de contenedor. A continuación se indican los tipos de volúmenes de datos que se pueden usar: + Volúmenes de Amazon EBS: proporciona almacenamiento en bloques rentable, duradero y de alto rendimiento para cargas de trabajo en contenedores con uso intensivo de datos. Puede adjuntar un volumen de Amazon EBS por tarea de Amazon ECS cuando ejecute una tarea independiente o cuando cree o actualice un servicio. Se admiten volúmenes de Amazon EBS para tareas de Linux alojadas en Fargate. Para obtener más información, consulte [Uso de volúmenes de Amazon EBS con Amazon ECS](ebs-volumes.md). + Volúmenes de Amazon EFS: proporciona almacenamiento de archivos sencillo, escalable y persistente para usarlo con tareas de Amazon ECS. Con Amazon EFS, la capacidad de almacenamiento es elástica. Aumenta y disminuye automáticamente a medida que se agregan o eliminan archivos. Sus aplicaciones disponen del almacenamiento que necesitan, cuando lo necesitan. Se admiten volúmenes de Amazon EFS para tareas que están alojadas en Fargate. Para obtener más información, consulte [Uso de volúmenes de Amazon EFS con Amazon ECS](efs-volumes.md). + Volúmenes de FSx for Windows File Server: proporciona servidores de archivos de Microsoft Windows completamente administrados. Estos servidores de archivos están respaldados por un sistema de archivos de Windows. Cuando utiliza FSx for Windows File Server junto con Amazon ECS, puede aprovisionar sus tareas de Windows con almacenamiento persistente, distribuido, compartido y estático de archivos. Para obtener más información, consulte [Uso de volúmenes de FSx para Windows File Server con Amazon ECS](wfsx-volumes.md). Los contenedores Windows de Fargate no admiten esta opción. + Montajes de unión: un archivo o directorio de la máquina host que se monta en un contenedor. Se admiten volúmenes de host de montaje vinculado cuando se ejecutan tareas. Para utilizar volúmenes de host de montaje vinculado, especifique `host` y un valor de `sourcePath` opcional en su definición de tarea. Para obtener más información, consulte [Opciones de almacenamiento para las tareas de Amazon ECS](using_data_volumes.md). Los siguientes parámetros están permitidos en una definición de contenedor. `name` Tipo: cadena Requerido: no El nombre del volumen. Se admiten hasta 255 letras (mayúsculas y minúsculas), números, guiones (`-`) y caracteres de subrayado (`_`). Se hace referencia a este nombre en el parámetro `sourceVolume` del objeto `mountPoints` de la definición de contenedor. `host` Obligatorio: no El parámetro `host` se utiliza para vincular el ciclo de vida del montaje de enlace a la instancia de Amazon EC2 del host, en lugar de a la tarea, y donde se almacena. Si el parámetro `host` está vacío, entonces el daemon de Docker asigna una ruta de host a su volumen de datos, pero no se garantiza que los datos persistan después de que los contenedores asociados dejen de funcionar. Los contenedores de Windows pueden montar directorios completos en la misma unidad que `$env:ProgramData`. El parámetro `sourcePath` se admite solo cuando se utilizan las tareas que se alojan en instancias de Amazon EC2 o instancias administradas de Amazon ECS. `sourcePath` Tipo: cadena Requerido: no Cuando utilice el parámetro `host`, especifique una `sourcePath` para declarar la ruta de la instancia de Amazon EC2 del host que se presenta al contenedor. Si este parámetro está vacío, el daemon de Docker asigna una ruta de host. Si el parámetro `host` contiene una ubicación de archivos `sourcePath`, el volumen de datos persiste en la ubicación especificada en la instancia de Amazon EC2 del host hasta que la elimine manualmente. Si el valor `sourcePath` no existe en la instancia de Amazon EC2 del host, el daemon de Docker lo crea. Si la ubicación existe, el contenido de la carpeta de la ruta de origen se exporta. `configuredAtLaunch` Tipo: Booleano Obligatorio: no Indica si un volumen se puede configurar durante el lanzamiento. Cuando se establece en `true`, puede configurarlo al ejecutar una tarea independiente o al crear o actualizar un servicio. Cuando se establece en `true`, no podrá proporcionar otra configuración de volumen en la definición de la tarea. Este parámetro se debe establecer en `true` para configurar un volumen de Amazon EBS para adjuntarlo a una tarea. Establecer `configuredAtLaunch` en `true` y aplazar la configuración del volumen hasta la fase de lanzamiento permite crear definiciones de tareas que no se limitan a un tipo de volumen o a una configuración de volumen específica. De este modo, la definición de la tarea se puede reutilizar en distintos entornos de ejecución. Para obtener más información, consulte [Volúmenes de Amazon EBS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html). `dockerVolumeConfiguration` Type: objeto de [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html) Obligatorio: no Este parámetro se especifica cuando se usan volúmenes de Docker. Los volúmenes de Docker se admiten solo cuando se ejecutan tareas en instancias de EC2. Los contenedores de Windows admiten solo el uso del controlador `local`. Para utilizar montajes vinculados, especifique `host` en su lugar. `scope` Tipo: cadena Valores válidos: `task` \$1 `shared` Obligatorio: no El ámbito del volumen de Docker, que determina su ciclo de vida. Los volúmenes de Docker con un ámbito de `task` se aprovisionan automáticamente cuando se inicia la tarea y se destruyen cuando la tarea se detiene. Los volúmenes de Docker cuyo ámbito es `shared` se conservan una vez detenida la tarea. `autoprovision` Tipo: booleano Valor predeterminado: \$1: `false` Obligatorio: no Si este valor es `true`, el volumen de Docker se crea si aún no existe. Este campo se usa solo si `scope` es `shared`. Si el `scope` es `task`, este parámetro debe omitirse. `driver` Tipo: cadena Requerido: no El controlador del volumen de Docker que se va a usar. El valor de controlador debe coincidir con el nombre del controlador proporcionado por Docker, ya que se utiliza para la colocación de tareas. Si el controlador se instaló mediante la CLI del complemento de Docker, utilice `docker plugin ls` para recuperar el nombre de controlador de la instancia de contenedor. Si el controlador se instaló con otro método, utilice la detección de complementos de Docker para recuperar el nombre del controlador. `driverOpts` Tipo: cadena Requerido: no Un mapa de las opciones específicas del controlador de Docker que se deben transferir. Este parámetro se corresponde con `DriverOpts` en la sección Crear un volumen de Docker. `labels` Tipo: cadena Requerido: no Metadatos personalizados que se añaden al volumen de Docker. `efsVolumeConfiguration` Tipo: objeto de [EFSVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSVolumeConfiguration.html) Obligatorio: no Este parámetro se especifica cuando se usan volúmenes de Amazon EFS. `fileSystemId` Tipo: cadena Obligatorio: sí El ID del sistema de archivos de Amazon EFS que se va a usar. `rootDirectory` Tipo: cadena Obligatorio: no Directorio del sistema de archivos de Amazon EFS que se va a montar como directorio raíz dentro del host. Si se omite este parámetro, se utilizará la raíz del volumen de Amazon EFS. Si se especifica `/`, se obtiene el mismo efecto que si se omite este parámetro. Si se especifica un punto de acceso de EFS en `authorizationConfig`, se debe omitir el parámetro del directorio raíz o establecerlo en `/`, lo que aplicará la ruta establecida en el punto de acceso de EFS. `transitEncryption` Tipo: cadena Valores válidos: `ENABLED` \$1 `DISABLED` Obligatorio: no Especifica si se habilita el cifrado para los datos en tránsito de Amazon EFS entre el host de Amazon ECS y el servidor de Amazon EFS. Si se utiliza la autorización de IAM en Amazon EFS, el cifrado en tránsito debe estar habilitado. Si se omite este parámetro, se usa el valor predeterminado de `DISABLED`. Para obtener más información, consulte [Cifrado de datos en tránsito](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html) en la *Guía del usuario de Amazon Elastic File System*. `transitEncryptionPort` Tipo: entero Obligatorio: no El puerto que se utilizará al enviar datos cifrados entre el host de Amazon ECS y el servidor de Amazon EFS. Si no se especifica un puerto de cifrado en tránsito, la tarea utilizará la estrategia de selección de puertos que utiliza el ayudante de montaje de Amazon EFS. Para obtener más información, consulte [Ayudante de montaje de EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html) en la *Guía del usuario de Amazon Elastic File System*. `authorizationConfig` Tipo: objeto de [EFSAuthorizationConfig](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSAuthorizationConfig.html) Obligatorio: no Los detalles de configuración de autorización en el sistema de archivos de Amazon EFS. `accessPointId` Tipo: cadena Requerido: no ID de punto de acceso que se va a utilizar. Si se especifica un punto de acceso, el valor del directorio raíz en `efsVolumeConfiguration` se debe omitir o establecer en `/`, lo que aplicará la ruta establecida en el punto de acceso de EFS. Si se utiliza un punto de acceso, el cifrado de tránsito debe estar habilitado en el `EFSVolumeConfiguration`. Para obtener más información, consulte [Trabajo con puntos de acceso de Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) en la *Guía del usuario de Amazon Elastic File System*. `iam` Tipo: cadena Valores válidos: `ENABLED` \$1 `DISABLED` Obligatorio: no Indica si se debe utilizar el rol de IAM de tarea de Amazon ECS definido en una definición de tareas al montar el sistema de archivos de Amazon EFS. Si está habilitado, el cifrado de tránsito debe estar habilitado en el `EFSVolumeConfiguration`. Si se omite este parámetro, se usa el valor predeterminado de `DISABLED`. Para obtener más información, consulte [Roles de IAM para las tareas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html). `FSxWindowsFileServerVolumeConfiguration` Tipo: objeto de [FSXWindowsFileServerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FSxWindowsFileServerVolumeConfiguration.html) Obligatorio: sí Este parámetro se indica cuando se utiliza el sistema de archivos [Amazon FSx para Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) para el almacenamiento de tareas. `fileSystemId` Tipo: cadena Obligatorio: sí ID del sistema de archivos FSx for Windows File Server que se va a utilizar. `rootDirectory` Tipo: cadena Obligatorio: sí Directorio dentro del sistema de archivos de FSx for Windows File Server que se va a montar como directorio raíz dentro del host. `authorizationConfig` `credentialsParameter` Tipo: cadena Obligatorio: sí Opciones de credenciales de autorización. **opciones:** + Nombre de recurso de Amazon (ARN) del secreto de [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html). + ARN de un parámetro de [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html). `domain` Tipo: cadena Obligatorio: sí Nombre de dominio completo alojado por un directorio de [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html)(AWS Managed Microsoft AD) o un directorio de Active Directory de EC2 con alojamiento propio. ## Etiquetas Cuando se registra una definición de tareas, se pueden especificar etiquetas de metadatos que se aplican a la definición de tareas. Las etiquetas ayudan a clasificar y organizar la definición de tareas. Cada etiqueta consta de una clave y un valor opcional. Los define a los dos. Para obtener más información, consulte [Etiquetado de los recursos de Amazon ECS](ecs-using-tags.md). **importante** No agregue información de identificación personal ni otra información confidencial en las etiquetas. Las etiquetas son accesibles para muchos servicios de AWS, incluida la facturación. Las etiquetas no se diseñaron para utilizarse con información privada o confidencial. Los siguientes parámetros se admiten en un objeto de etiqueta. `key` Tipo: cadena Requerido: no Una parte de un par clave-valor que compone una etiqueta. Un clave es una etiqueta general que actúa como una categoría para valores de etiqueta más específicos. `value` Tipo: cadena Requerido: no La parte opcional de un par clave-valor que compone una etiqueta. Un valor actúa como un descriptor en una categoría de etiquetas (clave). ## Otros parámetros de definición de tarea Los siguientes parámetros de definición de tareas se pueden utilizar cuando se registran definiciones de tareas en la consola de Amazon ECS mediante la opción **Configure via JSON** (Configurar mediante JSON). Para obtener más información, consulte [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md). **Topics** + [Almacenamiento efímero](#task_definition_ephemeralStorage) + [Modo IPC](#task_definition_ipcmode) + [Modo PID](#task_definition_pidmode) + [Inyección de errores](#task_definition_faultInjection) ### Almacenamiento efímero `ephemeralStorage` Tipo: objeto de [EphemeralStorage](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EphemeralStorage.html) Obligatorio: no Cantidad de almacenamiento efímero (en GB) que se va a asignar para la tarea. Este parámetro se utiliza para expandir la cantidad total de almacenamiento efímero disponible, más allá de la cantidad predeterminada, para las tareas que están alojadas en AWS Fargate. Para obtener más información, consulte [Uso de montajes de unión con Amazon ECS](bind-mounts.md). Este parámetro solo se admite en la versión `1.4.0` de la plataforma o posterior para Linux, o `1.0.0` o posterior para Windows. ### Modo IPC `ipcMode` Esto no es compatible con las tareas que se ejecutan en Fargate. Tipo: cadena Requerido: no El espacio de nombres de recurso de IPC que usarán los contenedores de la tarea. Los valores válidos son `host`, `task` o `none`. Si se especifica `host`, todos los contenedores que están dentro de las tareas que tienen especificado el modo de IPC `host` en la misma instancia de contenedor comparten los mismos recursos de IPC con la instancia Amazon EC2 del host. Si se especifica `task`, todos los contenedores que están dentro de la tarea especificada comparten los mismos recursos de IPC. Si se especifica `none`, los recursos de IPC dentro de los contenedores de una tarea son privados y no se comparten con otros contenedores en una tarea o en la instancia de contenedor. Si no se especifica ningún valor, el uso compartido del espacio de nombre de recursos de IPC depende de la configuración del daemon de Docker en la instancia de contenedor. Si se utiliza el modo de IPC `host`, existe un mayor riesgo de exposición de espacio de nombres de IPC no deseada. Si configura parámetros del kernel del espacio de nombres mediante `systemControls` para los contenedores de la tarea, se aplica lo siguiente a su espacio de nombres de recursos de IPC. + Para las tareas que utilizan el modo de IPC `host`, no se admiten los `systemControls` relacionados con el espacio de nombres de IPC. + Para las tareas que utilizan el modo de IPC `task`, los `systemControls` relacionados con el espacio de nombres de IPC se aplican a todos los contenedores de una tarea. **nota** Este parámetro no es compatible con contenedores Windows o tareas con el tipo de lanzamiento Fargate. ### Modo PID `pidMode` Tipo: cadena Valores válidos: `host` \$1 `task` Obligatorio: no El espacio de nombres del proceso que usarán los contenedores de la tarea. Los valores válidos son `host` o `task`. En los contenedores de Linux, el único valor válido es `task`. Por ejemplo, la supervisión de los archivos sidecar puede necesitar `pidMode` para acceder a información sobre otros contenedores que se ejecutan en la misma tarea. Si se especifica `task`, todos los contenedores dentro de la tarea especificada comparten el mismo espacio de nombres del proceso. Si no se especifica ningún valor, el valor predeterminado es un espacio de nombre privado para cada contenedor. **nota** Este parámetro solo se admite para las tareas que están alojadas en AWS Fargate si utilizan la versión de la plataforma `1.4.0` o una posterior (Linux). Este parámetro no es compatible con contenedores de Windows en Fargate. ### Inyección de errores `enableFaultInjection` Tipo: booleano Valores válidos: `true` \$1 `false` Obligatorio: no Si este parámetro se establece en `true`, en la carga útil de una tarea, Amazon ECS y Fargate aceptarán solicitudes de inyección de errores de los contenedores de la tarea. Este parámetro está establecido en de forma predeterminada `false`. # Parámetros de definición de tareas de Amazon ECS para Amazon EC2 Las definiciones de tareas se dividen en partes independientes: la familia de tareas, el rol de tarea de AWS Identity and Access Management (IAM), el modo de red, las definiciones de contenedor, los volúmenes, las restricciones de ubicación de tareas y la capacidad. En una definición de tareas, son necesarias las definiciones de familia y contenedor. En cambio, el rol de tarea, el modo de red, los volúmenes, las restricciones de ubicación de tareas y el tipo de lanzamiento son opcionales. Puede utilizar estos parámetros en un archivo JSON para configurar la definición de tarea. A continuación, se muestran las descripciones de cada parámetro de definición de tareas para Amazon EC2. ## Familia `family` Tipo: cadena Obligatorio: sí Cuando se registra una definición de tarea, se le da una familia, que es similar a un nombre para varias versiones de la definición de tarea, especificado con un número de revisión. A la primera definición de tareas que se registra en una familia particular se le da una revisión de 1 y a cualquier definición de tarea registrada después se le da un número de revisión secuencial. ## Capacidad Cuando se registre una definición de tareas, puede especificar la capacidad que con respecto a la cual Amazon ECS debe validar la definición de tareas. Si la definición de tareas no se valida con respecto a las compatibilidades especificadas, se devuelve una excepción de cliente. El parámetro a continuación está permitido en una definición de tareas. `requiresCompatibilities` Tipo: matriz de cadenas Obligatorio: no Valores válidos: `EC2` La capacidad con la que se validó la definición de tareas. Esto inicia una comprobación para garantizar que todos los parámetros que se utilizan en la definición de tareas cumplan los requisitos de Amazon EC2. ## Rol de de la tarea `taskRoleArn` Tipo: cadena Requerido: no Cuando se registra una definición de tareas, se puede proporcionar un rol de tarea para un rol de IAM que permita a los contenedores del permiso de tareas llamar en su nombre a las API de AWS especificadas en sus políticas asociadas. Para obtener más información, consulte [Rol de IAM de tarea de Amazon ECS](task-iam-roles.md). Al lanzar la AMI de Windows Server optimizada para Amazon ECS, los roles de IAM para las tareas de Windows requieren que se haya establecido la opción `-EnableTaskIAMRole`. Los contenedores deben ejecutar también código de configuración para utilizar la característica. Para obtener más información, consulte [Configuración adicional de las instancias de Amazon EC2 de Windows](task-iam-roles.md#windows_task_IAM_roles). ## Rol de ejecución de tareas `executionRoleArn` Tipo: cadena Obligatorio: condicional El nombre de recurso de Amazon (ARN) del rol de ejecución de tarea que concede permiso al agente de contenedor de Amazon ECS para realizar llamadas a la API de AWS en su nombre. El rol de IAM de ejecución de tareas es necesario en función de los requisitos de la tarea. Para obtener más información, consulte [Rol de IAM de ejecución de tareas de Amazon ECS](task_execution_IAM_role.md). ## Modo de red `networkMode` Tipo: cadena Requerido: no El modo de red de Docker que utilizar para los contenedores en la tarea. Para las tareas de Amazon ECS que están alojadas en instancias de Linux de Amazon EC2, los valores válidos son `none`, `bridge`, `awsvpc` y `host`. Si no se especifica ningún modo de red, el modo de red predeterminado es `bridge`. Para las tareas de Amazon ECS alojadas en instancias de Windows de Amazon EC2, los valores válidos son `default` y `awsvpc`. Si no se especifica ningún modo de red, se utiliza el modo de red `default`. Si el modo de red se establece en `none`, los contenedores de tarea no tienen conectividad externa y no es posible especificar la asignación de puertos en la definición del contenedor. Si el modo de red es `bridge`, la tarea usa la red virtual integrada de Docker en Linux, la cual se ejecuta dentro de cada instancia de Amazon EC2 que aloja la tarea. La red virtual integrada en Linux usa el controlador de red `bridge` Docker. Si el modo de red es `host`, la tarea usa la red del host que omite la red virtual integrada de Docker al asignar los puertos del contenedor directamente a la ENI de la instancia de Amazon EC2 que aloja la tarea. Las asignaciones de puertos dinámicas no se pueden usar en este modo de red. Un contenedor de una definición de tarea que use este modo debe especificar un número de `hostPort` específico. Varias tareas no pueden usar el número de puerto de un host. Por lo tanto, no se pueden ejecutar varias tareas de la misma definición de tarea en una instancia de Amazon EC2 única. Para mayor seguridad, cuando ejecute tareas utilizando el modo de red `host`, no debe ejecutar contenedores con el usuario raíz (UID 0). Como práctica recomendada de seguridad, utilice siempre un usuario que no sea usuario raíz. Si el modo de red es `awsvpc`, a la tarea se le asigna una interfaz de red elástica y debe especificar `NetworkConfiguration` al crear un servicio o ejecutar una tarea con la definición de tarea. Para obtener más información, consulte [Opciones de red de tareas de Amazon ECS para EC2](task-networking.md). Si el modo de red es `default`, la tarea usa la red virtual integrada de Docker en Windows, la cual se ejecuta dentro de cada instancia de Amazon EC2 que aloja la tarea. La red virtual integrada en Windows usa el controlador de red `nat` Docker. Los modos de red `host` y `awsvpc` ofrecen el rendimiento de redes más alto para contenedores dado que estos utilizan la pila de la red de Amazon EC2. Con los modos de red `host` y `awsvpc`, los puertos de contenedor expuestos se asignan directamente al puerto de host correspondiente (para el modo de red `host`) o al puerto de interfaz de red elástica asociado (para el modo de red `awsvpc`). Por este motivo, no se pueden utilizar asignaciones de puerto de host dinámico. El modo de red permitido depende del sistema operativo de la instancia de EC2 subyacente. Si es Linux, se puede usar cualquier modo de red. Si es Windows, se pueden usar los modos `default` y `awsvpc`. ## Plataforma de tiempo de ejecución `operatingSystemFamily` Tipo: cadena Obligatorio: condicional Predeterminado: LINUX Cuando se registra una definición de tarea, especifica la familia de sistemas operativos. Los valores válidos son `LINUX`, `WINDOWS_SERVER_2025_FULL`, `WINDOWS_SERVER_2025_CORE`, `WINDOWS_SERVER_2022_CORE`, `WINDOWS_SERVER_2022_FULL`, `WINDOWS_SERVER_2019_FULL`, `WINDOWS_SERVER_2019_CORE`, `WINDOWS_SERVER_2016_FULL`, `WINDOWS_SERVER_2004_CORE` y `WINDOWS_SERVER_20H2_CORE`. Todas las definiciones de tareas que se utilizan en un servicio deben tener el mismo valor para este parámetro. Cuando una definición de tarea forma parte de un servicio, este valor debe coincidir con el valor `platformFamily` de servicio. `cpuArchitecture` Tipo: cadena Obligatorio: condicional Cuando se registra una definición de tarea, se puede especificar la arquitectura de CPU. Los valores válidos son `X86_64` y `ARM64`. Si no especifica un valor, Amazon ECS intenta colocar las tareas en la arquitectura de CPU disponible según la configuración del proveedor de capacidad. Para asegurarse de que las tareas se colocan en una arquitectura de CPU específica, especifique un valor para `cpuArchitecture` en la definición de la tarea. Todas las definiciones de tareas que se utilizan en un servicio deben tener el mismo valor para este parámetro. Si tiene tareas de Linux, puede establecer el valor en `ARM64`. Para obtener más información, consulte [Definiciones de tareas de Amazon ECS para cargas de trabajo de ARM de 64 bits](ecs-arm64.md). ## Tamaño de tarea Cuando se registra una definición de tareas, puede especificar la cantidad total de CPU y memoria usada para la tarea. Es distinto de los valores `cpu` y `memory` en el nivel de definición de contenedor. Para las tareas que están alojadas en instancias de Amazon EC2, estos campos son opcionales. **nota** Los parámetros de CPU y memoria de nivel de tarea se omiten para los contenedores de Windows. Le recomendamos que especifique recursos de nivel de contenedor para los contenedores de Windows. `cpu` Tipo: cadena Obligatorio: condicional Este parámetro no es compatible con contenedores Windows. El límite máximo de unidades de CPU que presentar para la tarea. Puede indicar los valores de la CPU en el archivo JSON como una cadena en unidades de CPU o CPU virtuales (vCPU). Por ejemplo, puede especificar un valor de CPU `1024` en unidades de CPU o `1 vCPU` en vCPU. Cuando se registra la definición de tarea, el valor de una CPU virtual se convierte en un entero que indica las unidades de CPU. Este campo es opcional. Si el clúster no tiene registradas instancias de contenedor con las unidades de CPU solicitadas disponibles, la tarea no funciona. Los valores admitidos se encuentran entre `0.125` y `192` vCPU. `memory` Tipo: cadena Obligatorio: condicional Este parámetro no es compatible con contenedores Windows. El límite máximo de memoria para presentar a la tarea. Puede especificar los valores de memoria en la definición de tareas como una cadena en mebibytes (MiB) o gigabytes (GB). Por ejemplo, puede especificar un valor de memoria `3072` en MiB o `3 GB` en GB. Cuando se registra la definición de tarea, el valor de GB se convierte en un entero que indica el número de MiB. Este campo es opcional y se puede utilizar cualquier valor. Si se especifica un valor de memoria de nivel de tarea, el valor de memoria de nivel de contenedor es opcional. Si el clúster no tiene registradas instancias de contenedor con la memoria solicitada disponible, la tarea no funciona. Puede maximizar la utilización de los recursos proporcionando a las tareas la mayor cantidad de memoria posible para un tipo de instancia determinado. Para obtener más información, consulte [Reserva de la memoria de instancias de contenedor de Linux de Amazon ECS](memory-management.md). ## Definiciones de contenedores Al registrar una definición de tarea, debe especificar una lista de definiciones de contenedor que se transfieren al daemon de Docker en una instancia de contenedor. Los siguientes parámetros están permitidos en una definición de contenedor. **Topics** + [Parámetros de definición de contenedor estándar](#standard_container_definition_params_ec2) + [Parámetros de definición de contenedor avanzados](#advanced_container_definition_params_ec2) + [Otros parámetros de definición de contenedor](#other_container_definition_params_ec2) ### Parámetros de definición de contenedor estándar Los siguientes parámetros de definición de tarea son obligatorios o utilizados en la mayoría de definiciones de contenedor. **Topics** + [Nombre](#container_definition_name_ec2) + [Image](#container_definition_image_ec2) + [Memoria](#container_definition_memory_ec2) + [Mapeos de puertos](#container_definition_portmappings_ec2) + [Credenciales de repositorio privado](#container_definition_repositoryCredentials_ec2) #### Nombre `name` Tipo: cadena Obligatorio: sí El nombre de un contenedor. Se admiten hasta 255 letras (mayúsculas y minúsculas), números, guiones y caracteres de subrayado. Si está vinculando varios contenedores en una definición de tareas, el `name` de un contenedor se puede introducir en los `links` de otro contenedor. Esto sirve para conectar los contenedores. #### Image `image` Tipo: cadena Obligatorio: sí La imagen que se utiliza para iniciar un contenedor. Esta cadena se transfiere directamente al daemon de Docker. De manera predeterminada, las imágenes del registro de Docker Hub están disponibles. También puede especificar otros repositorios con `repository-url/image:tag` o `repository-url/image@digest`. Se permiten hasta 255 letras (mayúsculas y minúsculas), números, guiones, caracteres de subrayado, comas, puntos, barras diagonales y signos numéricos. Este parámetro se corresponde con `Image` en el comando create-container de docker y el parámetro `IMAGE` del comando de docker run. + Cuando se inicia una tarea nueva, el agente de contenedor de Amazon ECS extrae la última versión de la imagen y la etiqueta especificadas para que las utilice el contenedor. Sin embargo, las actualizaciones realizadas posteriormente en un repositorio de imágenes no se propagan a las tareas en ejecución. + Cuando no se especifica una etiqueta ni un resumen en la ruta de la imagen en la definición de la tarea, el agente de contenedores de Amazon ECS utiliza la etiqueta `latest` para extraer la imagen especificada. + Las actualizaciones que se hacen posteriormente en un repositorio de imágenes no se propagan a las tareas en marcha. + Se admiten las imágenes de registros privados. Para obtener más información, consulte [Uso de imágenes de contenedor que no sean de AWS en Amazon ECS](private-auth.md). + Para especificar imágenes de los repositorios de Amazon ECR, se puede utilizar la convención de nomenclatura completa `registry/repository:tag` o `registry/repository@digest` (por ejemplo, `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app:latest` o `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE`). + Las imágenes de los repositorios oficiales de Docker Hub utilizan un solo nombre (por ejemplo, `ubuntu` o `mongo`). + Las imágenes de otros repositorios de Docker Hub se clasifican con un nombre de organización (por ejemplo, `amazon/amazon-ecs-agent`). + Las imágenes de otros repositorios online se cualifican más con un nombre de dominio (por ejemplo, `quay.io/assemblyline/ubuntu`). `versionConsistency` Tipo: cadena Valores válidos: `enabled`\$1`disabled` Obligatorio: no Especifica si Amazon ECS convertirá la etiqueta de imagen de contenedores proporcionada en la definición de contenedores en un resumen de imágenes. De manera predeterminada, el comportamiento es `enabled`. Si establece `disabled` como valor de un contenedor, Amazon ECS no convertirá la etiqueta de imagen del contenedor en un resumen y utilizará el URI de imagen original especificado en la definición del contenedor para la implementación. Para obtener más información acerca de la conversión de imagen de contenedor, consulte [Resolución de imagen de contenedor](deployment-type-ecs.md#deployment-container-image-stability). #### Memoria `memory` Tipo: entero Obligatorio: no La cantidad (en MiB) de memoria que se presenta al contenedor. Si su contenedor intenta superar la memoria especificada aquí, el contenedor se cancela. La cantidad total de memoria reservada para todos los contenedores dentro de una tarea debe ser menor que el valor `memory` de la tarea, si se especifica. Este parámetro se corresponde con `Memory` en el comando create-container de docker y la opción `--memory` se corresponde con docker run. Debe especificar un valor de memoria de nivel de tarea o un valor de memoria de nivel de contenedor. Si especifica un valor de `memory` y un valor de `memoryReservation` en el nivel de contenedor, el valor de `memory` debe ser mayor que el valor de `memoryReservation`. Si especifica `memoryReservation`, el valor se resta de los recursos de memoria disponibles para la instancia de contenedor en la que se coloca el contenedor. De lo contrario, se utiliza el valor de `memory`. El daemon de Docker 20.10.0 o posterior reserva un mínimo de 6 MiB de memoria para un contenedor. Por lo tanto, no debe especificar menos de 6 MiB de memoria para los contenedores. El daemon de Docker 19.03.13-ce o anterior reserva un mínimo de 4 MiB de memoria para un contenedor. Por lo tanto, no debe especificar menos de 4 MiB de memoria para los contenedores. Si intenta maximizar la utilización de los recursos proporcionando a las tareas la mayor cantidad de memoria posible para un tipo de instancia determinado, consulte [Reserva de la memoria de instancias de contenedor de Linux de Amazon ECS](memory-management.md). `memoryReservation` Tipo: entero Obligatorio: no El límite flexible (en MiB) de memoria que reservar para el contenedor. Cuando la memoria del sistema está en conflicto, Docker intenta mantener la memoria del contenedor en este límite flexible. Sin embargo, el contenedor puede utilizar más memoria cuando sea necesario. El contenedor puede utilizar hasta el límite invariable especificado con el parámetro de `memory` (si procede) o toda la memoria disponible en la instancia de contenedor, lo que ocurra primero. Este parámetro se corresponde con `MemoryReservation` en el comando create-container de docker y la opción `--memory-reservation` se corresponde con docker run. Si no se especifica un valor de memoria de nivel de tarea, debe especificar un entero distinto de cero para `memory` o `memoryReservation`, o para ambos, en una definición de contenedor. Si especifica ambos, `memory` debe ser mayor que `memoryReservation`. Si especifica `memoryReservation`, el valor se resta de los recursos de memoria disponibles para la instancia de contenedor en la que se coloca el contenedor. De lo contrario, se utiliza el valor de `memory`. Por ejemplo, supongamos que el contenedor utiliza normalmente 128 MiB de memoria, pero con ráfagas ocasionales de hasta 256 MiB durante períodos de tiempo breves. Puede establecer una `memoryReservation` de 128 MiB y un límite invariable de `memory` de 300 MiB. Esta configuración permite al contenedor reservar solo 128 MiB de memoria de los recursos restantes en la instancia de contenedor. Al mismo tiempo, esta configuración también permite que el contenedor consuma más recursos de memoria en caso de ser necesario. Este parámetro no es compatible con los contenedores de Windows. El daemon de Docker 20.10.0 o posterior reserva un mínimo de 6 MiB de memoria para un contenedor. Por lo tanto, no debe especificar menos de 6 MiB de memoria para los contenedores. El daemon de Docker 19.03.13-ce o anterior reserva un mínimo de 4 MiB de memoria para un contenedor. Por lo tanto, no debe especificar menos de 4 MiB de memoria para los contenedores. Si intenta maximizar la utilización de los recursos proporcionando a las tareas la mayor cantidad de memoria posible para un tipo de instancia determinado, consulte [Reserva de la memoria de instancias de contenedor de Linux de Amazon ECS](memory-management.md). #### Mapeos de puertos `portMappings` Tipo: matriz de objetos Obligatorio: no Las asignaciones de puertos exponen los puertos de red del contenedor al mundo exterior, lo que permite a los clientes acceder a su aplicación. También se utilizan para la comunicación entre contenedores dentro de la misma tarea. Para las definiciones de tareas que utilizan el modo de red `awsvpc`, solo especifique `containerPort`. El `hostPort` siempre se ignora y el puerto del contenedor se asigna automáticamente a un puerto aleatorio con un número alto del host. Las asignaciones de puertos en Windows utilizan la dirección de puerto de enlace `NetNAT` en lugar de `localhost`. No existe ningún bucle invertido para el mapeo de puertos en Windows, por lo que no puede acceder a un puerto mapeado del contenedor desde el propio host. La mayoría de los campos de este parámetro (incluidos `containerPort`, `hostPort`, `protocol`) se corresponden con `PortBindings` en el comando create-container de docker y con la opción `--publish` para docker run. Si el modo de red de una definición de tareas se establece en `host`, los puertos de host deben estar sin definir o deben corresponder al puerto de contenedor en la asignación de puerto. Después de que una tarea alcanza el estado `RUNNING`, las asignaciones manuales y automáticas de puertos de contenedor y de host se pueden ver en las siguientes ubicaciones: + Consola: la sección **Network Bindings** (Conexiones de red) de la descripción de un contenedor para una tarea seleccionada. + AWS CLI: la sección `networkBindings` de la salida del comando **describe-tasks**. + API: la respuesta de `DescribeTasks`. + Metadatos: el punto de conexión de metadatos de la tarea. `appProtocol` Tipo: cadena Requerido: no El protocolo de aplicación que se utiliza para la asignación de puertos. Este parámetro solo se aplica a Service Connect. Recomendamos que defina este parámetro para que sea coherente con el protocolo que utiliza la aplicación. Si se establece este parámetro, Amazon ECS agrega la administración de la conexión específica del protocolo al proxy de Service Connect. Si se establece este parámetro, Amazon ECS agrega telemetría específica del protocolo en la consola de Amazon ECS y CloudWatch. Si no establece un valor para este parámetro, se utilizará TCP. Sin embargo, Amazon ECS no agrega telemetría específica del protocolo para TCP. Para obtener más información, consulte [Uso de Service Connect para conectar los servicios de Amazon ECS con nombres abreviados](service-connect.md). Valores de protocolo válidos: `"http" | "http2" | "grpc" ` `containerPort` Tipo: número entero Obligatorio: sí, si se utilizan `portMappings`. El número de puerto en el contenedor que está vinculado al puerto de host especificado por el usuario o asignado automáticamente. Para las tareas que utilizan el modo de red `awsvpc`, debe utilizar `containerPort` para especificar los puertos expuestos. Suponga que utiliza contenedores en una tarea con los proveedores de capacidad de EC2 y especifica un puerto de contenedor y no un puerto de host. A continuación, el contenedor recibe automáticamente un puerto de host en el rango de puertos efímeros. Para obtener más información, consulte `hostPort`. Las asignaciones de puerto que se asignan automáticamente de esta manera no se contabilizan en la cuota de 100 puertos reservados de una instancia de contenedor. `containerPortRange` Tipo: cadena Requerido: no El rango de números de puerto en el contenedor que está vinculado al rango de puertos de host asignado de manera dinámica. Solo puede configurar este parámetro mediante la API `register-task-definition`. La opción está disponible en el parámetro `portMappings`. Para obtener más información, consulte [register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html) en la *Referencia de AWS Command Line Interface*. Las siguientes reglas se aplican al especificar un `containerPortRange`: + Debe utilizar el modo de red `bridge` o el modo de red `awsvpc`. + Este parámetro está disponible tanto para sistemas operativos Windows como Linux. + La instancia de contenedor debe tener al menos la versión 1.67.0 del agente de contenedor y al menos la versión 1.67.0-1 del paquete `ecs-init` + Puede especificar 100 rangos de puertos como máximo por cada contenedor. + No especifica un `hostPortRange`. El valor de `hostPortRange` se establece de la siguiente manera: + Para los contenedores de una tarea con el modo de red `awsvpc`, `hostPort` se establece en el mismo valor que `containerPort`. Se trata de una estrategia de asignación estática. + Para los contenedores en una tarea con el modo de red `bridge`, el agente de Amazon ECS busca los puertos de host abiertos del rango efímero predeterminado y los pasa a un docker para vincularlos a los puertos del contenedor. + Los valores válidos de `containerPortRange` se encuentran entre 1 y 65 535. + Un puerto solo puede incluirse en una asignación de puertos por cada contenedor. + No puede especificar rangos de puertos superpuestos. + El primer puerto del rango debe ser menor que el último puerto del rango. + Docker recomienda desactivar el docker-proxy en el archivo de configuración del daemon de Docker cuando haya una gran cantidad de puertos. Para más información, consulte [Issue \$111185](https://github.com/moby/moby/issues/11185) en GitHub. Para obtener información sobre cómo desactivar el docker-proxy en el archivo de configuración del daemon de Docker, consulte Daemon de [https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon) en la *Guía para desarrolladores de Amazon ECS*. Puede llamar a [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) para ver el valor de `hostPortRange`, es decir, los puertos del host que están vinculados a los puertos del contenedor. Los rangos de puertos no se incluyen en los eventos de tareas de Amazon ECS que se envían a EventBridge. Para obtener más información, consulte [Automaticzación de las respuestas a los errores de Amazon ECS mediante EventBridge](cloudwatch_event_stream.md). `hostPortRange` Tipo: string Requerido: no El rango de números de puerto del host que se usa con el enlace de red. Docker lo asigna y el agente de Amazon ECS lo entrega. `hostPort` Tipo: entero Obligatorio: no El número de puerto en la instancia de contenedor que reservar para el contenedor. Puede especificar un puerto de host no reservado para la asignación de puertos de su contenedor. Esto se conoce como asignación *estática* de puertos de host. O bien, puede omitir el `hostPort` (o configurarlo en `0`) al especificar un `containerPort`. El contenedor recibe automáticamente un puerto en el rango de puertos efímeros del sistema operativo de la instancia de contenedor y la versión de Docker. Esto se conoce como asignación *dinámica* de puertos de host. La versión 1.6.0 de Docker y posteriores para el rango de puertos efímeros predeterminado se puede ver en la instancia en `/proc/sys/net/ipv4/ip_local_port_range`. Si este parámetro de kernel no está disponible, se usa el intervalo de puertos efímeros predeterminado, de `49153–65535`. No intente especificar un puerto de host en el rango de puertos efímeros. Esto se debe a que están reservados para la asignación automática. En general, los puertos bajo `32768` están fuera del rango de puertos efímeros. Puede utilizar `ECS_DYNAMIC_HOST_PORT_RANGE` en la configuración del agente de contenedor de ECS a fin de especificar un rango personalizado para los puertos host asignados dinámicamente. Esto puede resultar útil si sus tareas no se inician debido a conflictos de puertos con otros procesos de la instancia de contenedor, como las conexiones salientes que también utilizan puertos del rango de puertos efímeros. Para obtener más información, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md). Los puertos reservados predeterminados son el `22` para SSH; los puertos de Docker `2375` y `2376` y los puertos `51678-51680` del agente de contenedor de Amazon ECS. Cualquier puerto de host especificado por el usuario con anterioridad para una tarea en ejecución también se reserva mientras la tarea está en ejecución. Cuando se detiene una tarea, se libera el puerto del host. Los puertos reservados actuales se muestran en los `remainingResources` de la salida de **describe-container-instances**. Es posible que una instancia de contenedor tenga hasta 100 puertos reservados por vez, incluidos los puertos reservados predeterminados. Los puertos asignados automáticamente no se contabilizan para la cuota de 100 puertos reservados. `name` Tipo: cadena Obligatorio: no, es obligatorio para configurar Service Connect y VPC Lattice en un servicio El nombre que se utiliza para la asignación de puertos. Este parámetro solo se aplica a Service Connect y VPC Lattice. Este parámetro es el nombre que se utiliza en la configuración de Service Connect y VPC Lattice de un servicio. Para obtener más información, consulte [Uso de Service Connect para conectar los servicios de Amazon ECS con nombres abreviados](service-connect.md). En el siguiente ejemplo, se utilizan los dos campos obligatorios de Service Connect y VPC Lattice. ``` "portMappings": [ { "name": string, "containerPort": integer } ] ``` `protocol` Tipo: cadena Requerido: no El protocolo que se utiliza para la asignación de puertos. Los valores válidos son `tcp` y `udp`. El valor predeterminado es `tcp`. Solo `tcp` es compatible con Service Connect. Recuerde que `tcp` está implícito si este campo no está configurado. UDP solo se admite en las instancias de contenedor que se lanzaron con la versión 1.2.0 del agente de contenedor de Amazon ECS (como, por ejemplo, la AMI `amzn-ami-2015.03.c-amazon-ecs-optimized`) o una posterior, o con los agentes de contenedor que se han actualizado a la versión 1.3.0 o una posterior. Para actualizar el agente de contenedor a la versión más reciente, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md). Utilice la sintaxis a continuación para especificar un puerto de host. ``` "portMappings": [ { "containerPort": integer, "hostPort": integer } ... ] ``` Use la siguiente sintaxis si desea asignar automáticamente un puerto de host. ``` "portMappings": [ { "containerPort": integer } ... ] ``` #### Credenciales de repositorio privado `repositoryCredentials` Tipo: objeto de [RepositoryCredentials](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RepositoryCredentials.html) Obligatorio: no Las credenciales del repositorio para la autenticación de registros privados. Para obtener más información, consulte [Uso de imágenes de contenedor que no sean de AWS en Amazon ECS](private-auth.md). `credentialsParameter` Tipo: cadena Obligatorio: sí, si se utilizan `repositoryCredentials`. El nombre de recurso de Amazon (ARN) del secreto que contiene las credenciales del repositorio privado. Para obtener más información, consulte [Uso de imágenes de contenedor que no sean de AWS en Amazon ECS](private-auth.md). Cuando se utiliza la API de Amazon ECS, la AWS CLI o los SDK de AWS, si el secreto existe en la misma región que la tarea que se va a lanzar, se puede utilizar el ARN completo o el nombre del secreto. Cuando se utiliza la Consola de administración de AWS, debe especificar el ARN completo del secreto. A continuación, se incluye un fragmento de definición de tareas que muestra los parámetros necesarios: ``` "containerDefinitions": [ { "image": "private-repo/private-image", "repositoryCredentials": { "credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name" } } ] ``` ### Parámetros de definición de contenedor avanzados Los siguientes parámetros avanzados de definición de contenedor ofrecen capacidades ampliadas para el comando de docker run que se utiliza para lanzar contenedores en las instancias de contenedor de Amazon ECS. **Topics** + [Política de reinicio](#container_definition_restart_policy_ec2) + [Comprobación de estado](#container_definition_healthcheck_ec2) + [Entorno](#container_definition_environment_ec2) + [Configuración de red](#container_definition_network_ec2) + [Almacenamiento y registro](#container_definition_storage_ec2) + [Seguridad](#container_definition_security_ec2) + [Límites de recursos](#container_definition_limits_ec2) + [Etiquetas de Docker](#container_definition_labels_ec2) #### Política de reinicio `restartPolicy` La política de reinicio del contenedor y los parámetros de configuración asociados. Al configurar una política de reinicio para un contenedor, Amazon ECS puede reiniciar el contenedor sin necesidad de reemplazar la tarea. Para obtener más información, consulte [Reinicio de contenedores individuales en tareas de Amazon ECS con políticas de reinicio de contenedores](container-restart-policy.md). `enabled` Tipo: booleano Obligatorio: sí Especifica si una política de reinicio está habilitada para el contenedor. `ignoredExitCodes` Tipo: matriz de enteros Obligatorio: no Una lista de códigos de salida que Amazon ECS ignorará y no intentará reiniciar. Puede especificar un máximo de 50 códigos de salida de contenedor. De forma predeterminada, Amazon ECS no ignora ningún código de salida. `restartAttemptPeriod` Tipo: entero Obligatorio: no La cantidad de tiempo (en segundos) que debe ejecutarse el contenedor antes de que se pueda intentar un reinicio. Un contenedor solo se puede reiniciar una vez cada `restartAttemptPeriod` segundos. Si un contenedor no puede ejecutarse durante este período de tiempo y se cierra antes, no se reiniciará. Puede especificar un mínimo `restartAttemptPeriod` de 60 segundos y un `restartAttemptPeriod` máximo de 1.800 segundos. De forma predeterminada, un contenedor debe ejecutarse durante 300 segundos antes de poder reiniciarse. #### Comprobación de estado `healthCheck` El parámetro de comprobación de estado del contenedor y los parámetros de configuración asociados para el contenedor. Para obtener más información, consulte [Determine el estado de las tareas de Amazon ECS mediante comprobaciones de estado de los contenedores](healthcheck.md). `command` Una matriz de cadenas que representa el comando que ejecuta el contenedor para determinar si está en buen estado. La matriz de cadenas puede comenzar por `CMD` para ejecutar los argumentos del comando directamente, o por `CMD-SHELL` para ejecutar el comando con el shell predeterminado del contenedor. Si no se especifica ninguno, se utiliza `CMD`. Al registrar una definición de tarea en la Consola de administración de AWS, utilice una lista de comandos separados por comas. Estos comandos se convierten en una cadena una vez que se cree la definición de tareas. A continuación, se muestra un ejemplo de entrada de comprobación de estado. ``` CMD-SHELL, curl -f http://localhost/ || exit 1 ``` Cuando registre una definición de tarea mediante el panel de JSON de la Consola de administración de AWS, la AWS CLI o las API, incluya la lista de comandos entre corchetes. A continuación, se muestra un ejemplo de entrada de comprobación de estado. ``` [ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ] ``` Un código de salida de 0, sin salida `stderr`, indica una ejecución correcta y cualquier código de salida distinto de cero indica un error. `interval` El periodo de tiempo (en segundos) entre cada comprobación de estado. Es posible especificar entre 5 y 300 segundos. El valor predeterminado es de 30 segundos. `timeout` El periodo de tiempo (en segundos) que hay que esperar para que una comprobación de estado se realice correctamente antes de que se considere un error. Puede especificar entre 2 y 60 segundos. El valor predeterminado es 5 segundos. `retries` Es el número de veces que se reintenta una comprobación de estado fallida antes de que se considere que el contenedor está en mal estado. Puede especificar entre 1 y 10 reintentos. El valor predeterminado es tres reintentos. `startPeriod` El periodo de gracia opcional dentro del cual se puede proporcionar tiempo a los contenedores para el arranque antes de que una comprobación de estado fallida se cuente para el número máximo de reintentos. Es posible especificar entre 0 y 300 segundos. De forma predeterminada, `startPeriod` está deshabilitado. Si una comprobación de estado se realiza correctamente dentro del periodo indicado en `startPeriod`, se considera que el estado del contenedor es correcto y los errores posteriores se contabilizan al calcular el número máximo de intentos. #### Entorno `cpu` Tipo: entero Obligatorio: no El número de unidades de `cpu` que el agente de contenedor de Amazon ECS reserva para el contenedor. En Linux, este parámetro se corresponde con `CpuShares` en la sección [Crear un contenedor](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate). Puede determinar el número de unidades de CPU disponibles para cada tipo de instancia de Amazon EC2. Para ello, multiplique el número de vCPU listadas para dicho tipo de instancia en la página de detalles sobre [instancias de Amazon EC2](https://aws.amazon.com/ec2/instance-types/) por 1024. Los contenedores de Linux comparten unidades de CPU no asignadas con otros contenedores en la instancia de contenedor en la misma proporción que la cantidad asignada. Por ejemplo, supongamos que ejecuta una tarea de contenedor único en un tipo de instancia de un solo núcleo con 512 unidades de CPU especificadas para dicho contenedor. Además, esa tarea es la única que se ejecuta en la instancia de contenedor. En este ejemplo, el contenedor puede utilizar la cuota completa de 1024 unidades de CPU en un momento dado. Sin embargo, supongamos que lanzó otra copia de la misma tarea en esa instancia de contenedor. Cada tarea tiene garantizado un mínimo de 512 unidades de CPU cuando sea necesario. Del mismo modo, si el otro contenedor no utiliza la CPU restante, cada contenedor puede aumentar el uso de la CPU. Sin embargo, si ambas tareas estuvieran 100 % activas todo el tiempo, están limitadas a 512 unidades de CPU. En las instancias de contenedor de Linux, el daemon de Docker en la instancia de contenedor utiliza el valor de CPU para calcular las proporciones de cuota de CPU relativas para los contenedores en ejecución. El valor de cuota de CPU válido mínimo que permite el kernel de Linux es 2 y el valor de cuota de CPU válido máximo que permite el kernel de Linux es 262144. Sin embargo, el parámetro de CPU no es obligatorio y puede utilizar valores de CPU por debajo de 2 y por encima de 262144 en las definiciones de contenedor. Para valores de CPU por debajo de 2 (incluido el valor nulo) y por encima de 262144, el comportamiento varía en función de la versión de agente de contenedor de Amazon ECS: + **Versiones del agente <= 1.1.0:** los valores de CPU nulo y cero se pasan a Docker como 0, que Docker convierte a continuación a 1024 cuotas de CPU. Los valores de CPU de uno se transfieren a Docker como uno, que el kernel de Linux convierte a dos cuotas de CPU. + **Versiones del agente >= 1.2.0:** nulo, cero y los valores de CPU de uno se transfieren a Docker como dos cuotas de CPU. + **Versiones del agente >= 1.84.0:** los valores de CPU superiores a 256 vCPU se transfieren a Docker como 256, lo que equivale a 262144 cuotas de CPU. En las instancias de contenedor de Windows, la cuota de CPU se aplica como una cuota absoluta. Los contenedores de Windows solo tienen acceso a la cantidad de CPU especificada que se establece en la definición de tareas. Un valor de CPU nulo o cero se pasa a Docker como`0`. A continuación, Windows interpreta este valor como el 1 % de una CPU. Para ver otros ejemplos, consulte [Cómo administra Amazon ECS los recursos de CPU y memoria](https://aws.amazon.com/blogs/containers/how-amazon-ecs-manages-cpu-and-memory-resources/). `gpu` Tipo: objeto [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obligatorio: no El número de `GPUs` físicas que el agente de contenedor de Amazon ECS reserva para el contenedor. El número de GPU reservadas para todos los contenedores de una tarea no debe superar el número de GPU disponibles en la instancia de contenedor en la que se lanza la tarea. Para obtener más información, consulte [Definiciones de tareas de Amazon ECS para cargas de trabajo de GPU](ecs-gpu.md). Este parámetro no es compatible con los contenedores de Windows. `Elastic Inference accelerator` Tipo: objeto [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obligatorio: no Para el tipo `InferenceAccelerator`, el `value` coincide con el `deviceName` para un `InferenceAccelerator` especificado en una definición de tareas. Para obtener más información, consulte [Nombre del acelerador de Elastic Inference (en desuso)](task_definition_parameters.md#elastic-Inference-accelerator). Este parámetro no es compatible con los contenedores de Windows. `essential` Tipo: Booleano Obligatorio: no Supongamos que el parámetro `essential` de un contenedor se marca como `true` y dicho contenedor falla o se detiene por algún motivo. A continuación, se detienen todos los demás contenedores que forman parte de la tarea. Si el parámetro `essential` de un contenedor se marca como `false`, su error no afecta al resto de los contenedores en una tarea. Si este parámetro se omite, se supone que un contenedor es esencial. Todas las tareas deben tener al menos un contenedor esencial. Supongamos que tiene una aplicación compuesta por varios contenedores. Agrupe los contenedores que se utilizan para un fin común en componentes y sepárelos en diversas definiciones de tareas. Para obtener más información, consulte [Diseño de la arquitectura de su aplicación para Amazon ECS](application_architecture.md). ``` "essential": true|false ``` `entryPoint` Las primeras versiones del agente de contenedor de Amazon ECS no tratan correctamente los parámetros `entryPoint`. Si tiene problemas al utilizar `entryPoint` , actualice el agente de contenedor o introduzca los comandos y argumentos como elementos de matriz de `command` en su lugar. Tipo: matriz de cadenas Obligatorio: no El punto de entrada que se transfiere al contenedor. ``` "entryPoint": ["string", ...] ``` `command` Tipo: matriz de cadenas Obligatorio: no El comando que se transfiere al contenedor. Este parámetro se corresponde con `Cmd` en el comando create-container y el parámetro `COMMAND` para ejecutar el docker. Si hay varios argumentos, asegúrese de que cada uno de ellos sea una cadena distinta en la matriz. ``` "command": ["string", ...] ``` `workingDirectory` Tipo: cadena Requerido: no El directorio de trabajo para ejecutar los comandos dentro del contenedor. Este parámetro se corresponde con `WorkingDir` en la sección [Crear un contenedor](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) de la [API remota de Docker](https://docs.docker.com/reference/api/engine/version/v1.38/) y con la opción `--workdir` de [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/). ``` "workingDirectory": "string" ``` `environmentFiles` Tipo: matriz de objetos Obligatorio: no Una lista de archivos que contienen las variables de entorno que transferir a un contenedor. Este parámetro se corresponde con la opción `--env-file` del comando de docker run. Cuando se habilita FIPS, los nombres de los buckets que tienen puntos (.) (por ejemplo, amzn-s3-demo-bucket1.name.example) no son compatibles. Tener puntos (.) en el nombre del bucket impide que la tarea se inicie porque el agente no puede extraer el archivo de variables de entorno de Amazon S3. Esto no está disponible para los contenedores de Windows. Puede especificar hasta diez archivos de entorno. El archivo debe tener una extensión de archivo `.env` Cada línea de un archivo de entorno contiene una variable de entorno con el formato `VARIABLE=VALUE`. Las líneas que comienzan por `#` se tratan como comentarios y se ignoran. Si hay variables de entorno individuales especificadas en la definición del contenedor, tienen prioridad sobre las variables que contiene un archivo de entorno. Si se especifican varios archivos de entorno que contienen la misma variable, se procesan en orden descendente. Le recomendamos que utilice nombres de variables únicos. Para obtener más información, consulte [Transferencia de una variable de entorno individual a un contenedor de Amazon ECS](taskdef-envfiles.md). `value` Tipo: cadena Obligatorio: sí Nombre de recurso de Amazon (ARN) del objeto Amazon S3 que contiene el archivo de variable de entorno. `type` Tipo: cadena Obligatorio: sí Tipo de archivo que se utilizará. El único valor admitido es `s3`. `environment` Tipo: matriz de objetos Obligatorio: no Las variables de entorno a transferir a un contenedor. Este parámetro se corresponde con `Env` en el comando create-container de docker y la opción `--env` con el comando de docker run. No es recomendable que utilice variables del entorno en texto sin formato para información confidencial, como los datos de las credenciales. `name` Tipo: cadena Obligatorio: sí, si se utiliza `environment` El nombre de la variable de entorno. `value` Tipo: cadena Obligatorio: sí, si se utiliza `environment` El valor de la variable de entorno. ``` "environment" : [ { "name" : "string", "value" : "string" }, { "name" : "string", "value" : "string" } ] ``` `secrets` Tipo: matriz de objetos Obligatorio: no Un objeto que representa el secreto que se expone en el contenedor. Para obtener más información, consulte [Transferencia de datos confidenciales a un contenedor de Amazon ECS](specifying-sensitive-data.md). `name` Tipo: cadena Obligatorio: sí El valor que se ha de establecer como la variable de entorno en el contenedor. `valueFrom` Tipo: cadena Obligatorio: sí El secreto para exponer en el contenedor. Los valores admitidos son el nombre de recurso de Amazon (ARN) completo del secreto de AWS Secrets Manager o el ARN completo del parámetro en el almacén de parámetros de AWS Systems Manager. Si el parámetro del Almacén de parámetros de Systems Manager o el parámetro de Secrets Manager existe en la misma Región de AWS que la tarea que se va a lanzar, se puede utilizar el ARN completo o el nombre del secreto. Si el parámetro existe en una región distinta, el ARN completo debe especificarse. ``` "secrets": [ { "name": "environment_variable_name", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name" } ] ``` #### Configuración de red `disableNetworking` Tipo: Booleano Obligatorio: no Cuando este parámetro es verdadero, la conexión en red está apagada dentro del contenedor. Este parámetro no es compatible con los contenedores o las tareas de Windows que utilizan el modo de red `awsvpc`. El valor predeterminado es `false`. ``` "disableNetworking": true|false ``` `links` Tipo: matriz de cadenas Obligatorio: no El parámetro `link` permite a los contenedores comunicarse entre sí sin la necesidad de mapeos de puerto. Este parámetro solo se admite si el modo de red de una definición de tarea se establece en `bridge`. El constructo `name:internalName` es análogo a `name:alias` en enlaces de Docker. Se admiten hasta 255 letras (mayúsculas y minúsculas), números, guiones y caracteres de subrayado. Este parámetro no es compatible con los contenedores o las tareas de Windows que utilizan el modo de red `awsvpc`. Es posible que los contenedores que se colocan en la misma instancia de contenedor puedan comunicarse entre sí sin necesidad de enlaces ni asignaciones de puerto de host. El aislamiento de red en una instancia de contenedor se controla mediante los grupos de seguridad y la configuración de VPC. ``` "links": ["name:internalName", ...] ``` `hostname` Tipo: cadena Requerido: no El nombre de host que utilizar para el contenedor. Este parámetro se asigna a `Hostname` en el comando create-container de docker y la opción `--hostname` con docker run. Si utiliza el modo de red `awsvpc`, el parámetro `hostname` no se admite. ``` "hostname": "string" ``` `dnsServers` Tipo: matriz de cadenas Obligatorio: no Una lista de servidores DNS que se presentan al contenedor. Este parámetro no es compatible con los contenedores o las tareas de Windows que utilizan el modo de red `awsvpc`. ``` "dnsServers": ["string", ...] ``` `dnsSearchDomains` Tipo: matriz de cadenas Obligatorio: no Patrón: ^[a-zA-Z0-9-.]\$10,253\$1[a-zA-Z0-9]\$1 Una lista de dominios de búsqueda DNS que se presentan al contenedor. Este parámetro se corresponde con `DnsSearch` en el comando create-container de docker y la opción `--dns-search` con docker run. Este parámetro no es compatible con los contenedores o las tareas de Windows que utilizan el modo de red `awsvpc`. ``` "dnsSearchDomains": ["string", ...] ``` `extraHosts` Tipo: matriz de objetos Obligatorio: no Una lista de nombres de host y mapeos de direcciones IP que añadir al archivo `/etc/hosts` en el contenedor. Este parámetro se corresponde con `ExtraHosts` en el comando create-container de docker y la opción `--add-host` se corresponde con docker run. Este parámetro no es compatible con los contenedores o las tareas de Windows que utilizan el modo de red `awsvpc`. ``` "extraHosts": [ { "hostname": "string", "ipAddress": "string" } ... ] ``` `hostname` Tipo: cadena Obligatorio: sí, si se utilizan `extraHosts`. El nombre de host para utilizar en la entrada `/etc/hosts`. `ipAddress` Tipo: cadena Obligatorio: sí, si se utilizan `extraHosts`. La dirección IP para utilizar en la entrada `/etc/hosts`. #### Almacenamiento y registro `readonlyRootFilesystem` Tipo: Booleano Obligatorio: no Cuando este parámetro es verdadero, al contenedor se le concede acceso de solo lectura a su sistema de archivos raíz. Este parámetro se corresponde con `ReadonlyRootfs` en el comando create-container de docker y la opción `--read-only` con docker run. Este parámetro no es compatible con contenedores Windows. El valor predeterminado es `false`. ``` "readonlyRootFilesystem": true|false ``` `mountPoints` Tipo: matriz de objetos Obligatorio: no Puntos de montaje para los volúmenes de datos del contenedor. Este parámetro asigna a `Volumes` en la API create-container de Docker y la opción `--volume` a docker run. Los contenedores de Windows pueden montar directorios completos en la misma unidad que `$env:ProgramData`. Los contenedores de Windows no pueden montar directorios en una unidad diferente y los puntos de montaje no se pueden utilizar entre unidades. Debe especificar los puntos de montaje para adjuntar un volumen de Amazon EBS directamente a una tarea de Amazon ECS. `sourceVolume` Tipo: cadena Obligatorio: sí, si se utilizan `mountPoints`. El nombre del volumen a montar. `containerPath` Tipo: cadena Obligatorio: sí, si se utilizan `mountPoints`. La ruta del contenedor donde se montará el volumen. `readOnly` Tipo: Booleano Obligatorio: no Si este valor es `true`, el acceso del contenedor al volumen es de solo lectura. Si este valor es `false`, el contenedor puede escribir en el volumen. El valor predeterminado es `false`. Para las tareas que ejecutan el sistema operativo Windows, deje el valor predeterminado `false`. `volumesFrom` Tipo: matriz de objetos Obligatorio: no Volúmenes de datos que montar desde otro contenedor. Este parámetro se corresponde con `VolumesFrom` en el comando create-container de docker y la opción `--volumes-from` se corresponde con docker run. `sourceContainer` Tipo: cadena Obligatorio: sí, si se utiliza `volumesFrom` El nombre del volumen contenedor desde el que montar los volúmenes. `readOnly` Tipo: Booleano Obligatorio: no Si este valor es `true`, el acceso del contenedor al volumen es de solo lectura. Si este valor es `false`, el contenedor puede escribir en el volumen. El valor predeterminado es `false`. ``` "volumesFrom": [ { "sourceContainer": "string", "readOnly": true|false } ] ``` `logConfiguration` Tipo: objeto [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html) Obligatorio: no La especificación de configuración de registros para el contenedor. Para obtener ejemplos de definiciones de tareas que utilizan una configuración de registro, consulte [Ejemplo de definiciones de tareas de Amazon ECS](example_task_definitions.md). Este parámetro se corresponde con `LogConfig` en el comando create-container de docker y la opción `--log-driver` se corresponde con docker run. De forma predeterminada, los contenedores utilizan el mismo controlador de registro que el daemon de Docker. No obstante, el contenedor podría utilizar un controlador de registro diferente al daemon de Docker especificando un controlador de registro con este parámetro en la definición de contenedor. Para utilizar un controlador de registro distinto para un contenedor, el sistema de registro se debe configurar correctamente en la instancia de contenedor (o en un servidor de registro distinto para opciones de registro remotas). Tenga cuenta lo siguiente al especificar una configuración de registros para los contenedores: + Amazon ECS admite un subconjunto de controladores de registro disponibles para el daemon de Docker. + Este parámetro requiere la versión 1.18 o posterior de la API remota de Docker en la instancia de contenedor. + El agente de contenedor de Amazon ECS que se ejecuta en una instancia de contenedor debe registrar los controladores de registro disponibles en dicha instancia con la variable de entorno `ECS_AVAILABLE_LOGGING_DRIVERS` antes de que los contenedores situados en dicha instancia puedan utilizar estas opciones de configuración de registro. Para obtener más información, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md). ``` "logConfiguration": { "logDriver": "awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens", "options": {"string": "string" ...}, "secretOptions": [{ "name": "string", "valueFrom": "string" }] } ``` `logDriver` Tipo: cadena Valores válidos: `"awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens"` Obligatorio: sí, si se utiliza `logConfiguration` El controlador de registro que utilizar para el contenedor. De forma predeterminada, los valores válidos mostrados anteriormente son controladores de registro con los que el agente de contenedor de Amazon ECS se puede comunicar. Los controladores de registro admitidos son `awslogs`, `fluentd`, `gelf`, `json-file`, `journald`, `syslog`, `splunk` y `awsfirelens`. Para obtener más información acerca del uso del controlador de registro `awslogs` en las definiciones de tareas para enviar los registros de contenedor a CloudWatch Logs, consulte [Envío de registros de Amazon ECS a CloudWatch](using_awslogs.md). Para obtener más información sobre el uso del controlador del registro `awsfirelens`, consulte [Envío de registros personalizados](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html). Si tiene un controlador personalizado que no figura en la lista, puede adaptar el proyecto del agente de contenedor de Amazon ECS que está [disponible en GitHub](https://github.com/aws/amazon-ecs-agent) y personalizarlo para que funcione con dicho controlador. Le recomendamos enviar solicitudes de inserción para los cambios que desea que incluyamos. No obstante, actualmente no admitimos la ejecución de copias modificadas de este software. Este parámetro requiere la versión 1.18 de la API remota de Docker o superior en su instancia de contenedor. `options` Tipo: mapa de cadena a cadena Obligatorio: no Las opciones de configuración de asignación clave/valor para enviar al controlador de registro. Las opciones que puede especificar dependen del controlador de registro. Algunas de las opciones que puede especificar cuando utiliza el router `awslogs` para enrutar los registros a Amazon CloudWatch son las siguientes: `awslogs-create-group` Obligatorio: no Especifique si desea que el grupo de registro se cree automáticamente. Si no se especifica esta opción, el valor predeterminado es `false`. Su política de IAM debe incluir el permiso `logs:CreateLogGroup` antes de intentar utilizar `awslogs-create-group`. `awslogs-region` Obligatorio: sí Especifique la Región de AWS a la que el controlador de registro `awslogs` enviará los registros de Docker. Puede elegir enviar todos los registros desde clústeres de diferentes regiones a una única región de CloudWatch Logs. Esto es para que todos sean visibles en una sola ubicación. De lo contrario, puede separarlos por región para obtener un mayor grado de detalle. Asegúrese de que el grupo de registro especificado exista en la región que especifique con esta opción. `awslogs-group` Obligatorio: sí Asegúrese de especificar un grupo de registro al que el controlador de registros `awslogs` envíe sus flujos de registros. `awslogs-stream-prefix` Obligatorio: opcional Utilice esta opción `awslogs-stream-prefix` para asociar un flujo de registro con el prefijo especificado, el nombre del contenedor y el ID de la tarea de Amazon ECS a la que pertenece el contenedor. Si especifica un prefijo con esta opción, el flujo de registro adopta el siguiente formato. ``` prefix-name/container-name/ecs-task-id ``` Si no especifica un prefijo con esta opción, el flujo de registro se nombra según el ID del contenedor que asigna el daemon de Docker en la instancia de contenedor. Dado que es difícil realizar un seguimiento de los registros hasta el contenedor que los envió solo con el ID de contenedor de Docker (que solo está disponible en la instancia de contenedor), le recomendamos que especifique un prefijo con esta opción. En el caso de los servicios de Amazon ECS, puede utilizar el nombre del servicio como prefijo. De este modo, puede realizar un seguimiento de flujos de registros hasta el servicio al que pertenece el contenedor, el nombre del contenedor que los envió y el ID de la tarea a la que pertenece el contenedor. Debe especificar un prefijo de flujo para los registros para que aparezcan en el panel de registros al utilizar la consola de Amazon ECS. `awslogs-datetime-format` Obligatorio: no Esta opción define un patrón de inicio de varias líneas en formato `strftime` de Python. Un mensaje de registro consta de una línea que coincide con el patrón y de líneas siguientes que no coinciden con el patrón. La línea coincidente es el delimitador entre los mensajes de registro. Un ejemplo de caso de uso de este formato es para analizar la salida como un volcado de pila, que de lo contrario podría registrarse en varias entradas. El patrón correcto permite capturarla en una sola entrada. Para obtener más información, consulte [awslogs-datetime-format](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-datetime-format). No puede configurar las opciones `awslogs-datetime-format` y `awslogs-multiline-pattern` a la vez. El registro de varias líneas realiza análisis de las expresiones regulares y correspondencia de todos los mensajes de registro. Esto puede tener un impacto negativo sobre el rendimiento de registro. `awslogs-multiline-pattern` Obligatorio: no Esta opción define un patrón de inicio de varias líneas que utiliza una expresión regular. Un mensaje de registro consta de una línea que coincide con el patrón y de líneas siguientes que no coinciden con el patrón. La línea coincidente es el delimitador entre los mensajes de registro. Para obtener más información, consulte [awslogs-multiline-pattern](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-multiline-pattern). Esta opción se pasa por alto si también se ha configurado `awslogs-datetime-format`. No puede configurar las opciones `awslogs-datetime-format` y `awslogs-multiline-pattern` a la vez. El registro de varias líneas realiza análisis de las expresiones regulares y correspondencia de todos los mensajes de registro. Esto puede tener un impacto negativo sobre el rendimiento de registro. Las siguientes opciones se aplican a todos los controladores de registro compatibles. `mode` Obligatorio: no Valores válidos: `non-blocking` \$1 `blocking` Esta opción define el modo de entrega de los mensajes de registro del contenedor al controlador de registro especificado con `logDriver`. El modo de entrega que elige afecta la disponibilidad de las aplicaciones cuando se interrumpe el flujo de registros desde el contenedor. Si utiliza el modo `blocking` y se interrumpe el flujo de registros, se bloquearán las llamadas desde el código del contenedor para escribir en los flujos `stdout` y `stderr`. Como resultado, el hilo del registro de la aplicación se bloqueará. Esto puede provocar que la aplicación deje de responder y que se produzca un error en la comprobación del estado del contenedor. Si utiliza el modo `non-blocking`, los registros del contenedor se almacenan en un búfer intermedio en memoria configurado con la opción. `max-buffer-size` Esto evita que la aplicación deje de responder cuando los registros no se puedan enviar. Le recomendamos que utilice este modo si quiere garantizar la disponibilidad del servicio y si no hay problema con la pérdida de registros. Para obtener más información, consulte [Evitar la pérdida de registros con el modo sin bloqueo en el controlador `awslogs` de registros del contenedor](https://aws.amazon.com/blogs/containers/preventing-log-loss-with-non-blocking-mode-in-the-awslogs-container-log-driver/). Puede establecer un `mode` predeterminado para todos los contenedores de una Región de AWS específica mediante la configuración de la cuenta de `defaultLogDriverMode`. Si no especifica la opción `mode` en `logConfiguration` ni configura los ajustes de la cuenta, Amazon ECS utilizará el modo `non-blocking` de manera predeterminada. Para obtener más información acerca de la configuración de la cuenta, consulte [Modo de controlador de registro predeterminado](ecs-account-settings.md#default-log-driver-mode). Cuando se utiliza el modo `non-blocking`, la opción de registro `max-buffer-size` controla el tamaño del búfer que se utiliza para el almacenamiento intermedio de mensajes. Asegúrese de especificar un tamaño de búfer adecuado en función de su aplicación. La cantidad total de memoria asignada a nivel de tarea debe ser superior a la cantidad de memoria asignada a todos los contenedores, además del búfer de memoria del controlador de registro. El 25 de junio de 2025, Amazon ECS cambió el modo de controlador de registro predeterminado de `blocking` a `non-blocking` a fin de priorizar la disponibilidad de las tareas sobre el registro. Para seguir utilizando el modo `blocking` después de este cambio, realice una de las siguientes acciones: + Establezca la opción `mode` en la `logConfiguration` de su definición de contenedor como `blocking`. + Establezca el ajuste de cuenta `defaultLogDriverMode` en `blocking`. `max-buffer-size` Obligatorio: no Valor predeterminado: \$1: `10 m` Cuando se utiliza el modo `non-blocking`, la opción de registro `max-buffer-size` controla el tamaño del búfer que se utiliza para el almacenamiento intermedio de mensajes. Asegúrese de especificar un tamaño de búfer adecuado en función de su aplicación. Cuando el búfer se llene, no se podrán almacenar más registros. Los registros que no se pueden almacenar se pierden. Para enrutar los registros mediante el enrutador de registros `splunk`, debe especificar un `splunk-token` y un `splunk-url`. Cuando utiliza el enrutador de registros `awsfirelens` para enrutar a un destino de Servicio de AWS o AWS Partner Network para el almacenamiento y análisis de registros, puede configurar la opción `log-driver-buffer-limit` hasta el límite del número de líneas de registro almacenadas en búfer en la memoria antes de enviarlas al contenedor del enrutador de registros. Puede ayudar a resolver el posible problema de pérdida de registros porque un alto rendimiento podría provocar que se quede sin memoria para el búfer dentro de Docker. Para obtener más información, consulte [Configuración de los registros de Amazon ECS para conseguir un alto rendimiento](firelens-docker-buffer-limit.md). Otras opciones que puede especificar cuando se utiliza `awsfirelens` para enrutar los registros dependen del destino. Al exportar registros a Amazon Data Firehose, puede especificar la Región de AWS con `region` y el nombre del flujo de registros con `delivery_stream`. Al exportar registros a Amazon Kinesis Data Streams, puede especificar una Región de AWS con `region` y un nombre de flujo de datos con `stream`. Al exportar registros a Amazon OpenSearch Service, puede especificar opciones como `Name`, `Host` (punto final de OpenSearch Service sin protocolo), `Port`, `Index`, `Type`, `Aws_auth`, `Aws_region`, `Suppress_Type_Name` y `tls`. Al exportar registros a Amazon S3, puede especificar el bucket mediante la opción `bucket`. También puede especificar `region`, `total_file_size`, `upload_timeout` y `use_put_object` como opciones. Este parámetro requiere la versión 1.19 de la API remota de Docker o superior en su instancia de contenedor. `secretOptions` Tipo: matriz de objetos Obligatorio: no Un objeto que representa el secreto que transferir a la configuración de registro. Los secretos utilizados en la configuración de registros pueden incluir un token de autenticación, un certificado o una clave de cifrado. Para obtener más información, consulte [Transferencia de datos confidenciales a un contenedor de Amazon ECS](specifying-sensitive-data.md). `name` Tipo: cadena Obligatorio: sí El valor que se ha de establecer como la variable de entorno en el contenedor. `valueFrom` Tipo: cadena Obligatorio: sí El secreto que exponer a la configuración de registro del contenedor. ``` "logConfiguration": { "logDriver": "splunk", "options": { "splunk-url": "https://cloud.splunk.com:8080", "splunk-token": "...", "tag": "...", ... }, "secretOptions": [{ "name": "splunk-token", "valueFrom": "/ecs/logconfig/splunkcred" }] } ``` `firelensConfiguration` Tipo: objeto [FirelensConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FirelensConfiguration.html) Obligatorio: no La configuración de FireLens para el contenedor. Esto se utiliza para especificar y configurar un enrutador de registro para registros de contenedores. Para obtener más información, consulte [Envío de registros de Amazon ECS a un servicio de AWS o AWS Partner](using_firelens.md). ``` { "firelensConfiguration": { "type": "fluentd", "options": { "KeyName": "" } } } ``` `options` Tipo: mapa de cadena a cadena Obligatorio: no Las opciones de asignación de clave/valor que se deben usar al configurar el enrutador de registros. Este campo es opcional y se puede utilizar para especificar un archivo de configuración personalizado o agregar metadatos adicionales, como la tarea, la definición de tareas, el clúster y detalles de la instancia de contenedor al evento de registro. Si se especifica, la sintaxis que se va a utilizar es `"options":{"enable-ecs-log-metadata":"true|false","config-file-type:"s3|file","config-file-value":"arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf|filepath"}`. Para obtener más información, consulte [Definición de tareas de Amazon ECS de ejemplo: enrutar registros a FireLens](firelens-taskdef.md). `type` Tipo: cadena Obligatorio: sí El router de registros que se va a utilizar. Los valores válidos son `fluentd` o `fluentbit`. #### Seguridad Para obtener más información sobre la seguridad del contenedor, consulte [Prácticas recomendadas de seguridad para las tareas y contenedores de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-tasks-containers.html). `credentialSpecs` Tipo: matriz de cadenas Obligatorio: no Una lista de los ARN de SSM o Amazon S3 en un archivo de especificaciones de credenciales (`CredSpec`) que configura el contenedor para la autenticación de Active Directory. Le recomendamos que utilice este parámetro en lugar de `dockerSecurityOptions`. El número máximo de ARN es 1. Hay dos formatos para cada ARN. Especificación de credenciales sin dominio: MyARN Utiliza `credentialspecdomainless:MyARN` para proporcionar a la `CredSpec` una sección adicional para un secreto en Secrets Manager. Proporciona las credenciales de inicio de sesión al dominio en el secreto. Cada tarea que se ejecute en cualquier instancia de contenedor puede unirse a diferentes dominios. Puede utilizar este formato sin unir la instancia de contenedor a un dominio. Especificación de credenciales: MyARN Utiliza `credentialspec:MyARN` para proporcionar una `CredSpec` para un solo dominio. Debe unir la instancia de contenedor al dominio antes de iniciar cualquier tarea que utilice esta definición de tarea. En ambos formatos, sustituya `MyARN` por el ARN en SSM o Amazon S3. La `credspec` debe proporcionar un ARN en Secrets Manager para un secreto que contenga el nombre de usuario, la contraseña y el dominio para conectarse. Para mayor seguridad, la instancia no está unida al dominio para la autenticación sin dominio. Las demás aplicaciones de la instancia no pueden utilizar las credenciales sin dominio. Puede utilizar este parámetro para ejecutar tareas en la misma instancia, incluso si las tareas necesitan unirse a dominios diferentes. Para obtener más información, consulte [Uso de gMSA para contenedores de Windows](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/windows-gmsa.html) y [Uso de gMSA para contenedores de Linux](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/linux-gmsa.html). `privileged` Tipo: Booleano Obligatorio: no Cuando este parámetro es verdadero, al contenedor se le conceden privilegios elevados en la instancia de contenedor de host, similares a los de un usuario `root`. Recomendamos no utilizar contenedores con `privileged`. En la mayoría de los casos, puede especificar los privilegios exactos que necesita mediante los parámetros específicos en lugar de usar `privileged`. Este parámetro se corresponde con `Privileged` en el comando create-container de docker y la opción `--privileged` con docker run. Este parámetro no es compatible con contenedores Windows o tareas con el tipo de lanzamiento Fargate. El valor predeterminado es `false`. ``` "privileged": true|false ``` `user` Tipo: cadena Requerido: no El usuario que se utiliza dentro del contenedor. Este parámetro se corresponde con `User` en el comando create-container de docker y la opción `--user` con docker run. Al ejecutar tareas que utilizan el modo de red de `host`, no debe ejecutar contenedores con el usuario raíz (UID 0). Como práctica recomendada de seguridad, utilice siempre un usuario que no sea usuario raíz. Puede especificar el elemento `user` utilizando los siguientes formatos. Si se especifica un UID o GID, debe especificarlo como número entero positivo. + `user` + `user:group` + `uid` + `uid:gid` + `user:gid` + `uid:group` Este parámetro no es compatible con contenedores Windows. ``` "user": "string" ``` `dockerSecurityOptions` Tipo: matriz de cadenas Valores válidos: “no-new-privileges” \$1 “apparmor:PROFILE” \$1 “label:*value*” \$1 “credentialspec:*CredentialSpecFilePath*” Obligatorio: no Una lista de cadenas para proporcionar una configuración personalizada para varios sistemas de seguridad. Para las tareas de Linux, este parámetro se puede utilizar para hacer referencia a etiquetas personalizadas para SELinux y sistemas de seguridad de varios niveles de AppArmor . Este parámetro se puede utilizar para hacer referencia a un archivo de especificación de credenciales que configure un contenedor para la autenticación de Active Directory. Para obtener más información, consulte [Obtenga información sobre cómo utilizar gMSA para contenedores de EC2 para Windows en Amazon ECS.](windows-gmsa.md) y [Uso de gMSA para contenedores de EC2 Linux en Amazon ECS](linux-gmsa.md). Este parámetro se corresponde con `SecurityOpt` en el comando create-container de docker y la opción `--security-opt` se corresponde con docker run. ``` "dockerSecurityOptions": ["string", ...] ``` El agente de contenedor de Amazon ECS que se ejecuta en una instancia de contenedor se debe registrar con las variables de entorno `ECS_SELINUX_CAPABLE=true` o `ECS_APPARMOR_CAPABLE=true` antes de que los contenedores situados en dicha instancia puedan utilizar estas opciones de seguridad. Para obtener más información, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md). #### Límites de recursos `ulimits` Tipo: matriz de objetos Obligatorio: no Lista de valores `ulimit` a definir para un contenedor. Este valor sobrescribe la configuración predeterminada de la cuota de recursos para el sistema operativo. Este parámetro se corresponde con `Ulimits` en el comando create-container de docker y la opción `--ulimit` se corresponde con docker run. Este parámetro requiere la versión 1.18 de la API remota de Docker o superior en su instancia de contenedor. Este parámetro no es compatible con contenedores Windows. ``` "ulimits": [ { "name": "core"|"cpu"|"data"|"fsize"|"locks"|"memlock"|"msgqueue"|"nice"|"nofile"|"nproc"|"rss"|"rtprio"|"rttime"|"sigpending"|"stack", "softLimit": integer, "hardLimit": integer } ... ] ``` `name` Tipo: cadena Valores válidos: `"core" | "cpu" | "data" | "fsize" | "locks" | "memlock" | "msgqueue" | "nice" | "nofile" | "nproc" | "rss" | "rtprio" | "rttime" | "sigpending" | "stack"` Obligatorio: sí, si se utilizan `ulimits`. El valor `type` de `ulimit`. `hardLimit` Tipo: número entero Obligatorio: sí, si se utilizan `ulimits`. El límite máximo para el tipo de `ulimit`. El valor se puede especificar en bytes, segundos o como un conteo, según el `type` del `ulimit`. `softLimit` Tipo: número entero Obligatorio: sí, si se utilizan `ulimits`. El límite flexible para el tipo de `ulimit`. El valor se puede especificar en bytes, segundos o como un conteo, según el `type` del `ulimit`. #### Etiquetas de Docker `dockerLabels` Tipo: mapa de cadena a cadena Obligatorio: no Un mapa de clave/valor de etiquetas que agregar al contenedor. Este parámetro se corresponde con `Labels` en el comando create-container de docker y la opción `--label` se corresponde con docker run. Este parámetro requiere la versión 1.18 de la API remota de Docker o superior en su instancia de contenedor. ``` "dockerLabels": {"string": "string" ...} ``` ### Otros parámetros de definición de contenedor Los siguientes parámetros de definición de contenedor se pueden utilizar al registrar definiciones de tareas en la consola de Amazon ECS mediante la opción **Configure via JSON** (Configurar mediante JSON). Para obtener más información, consulte [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md). **Topics** + [Parámetros de Linux](#container_definition_linuxparameters_ec2) + [Dependencia de contenedor](#container_definition_dependson_ec2) + [Tiempos de espera de contenedor](#container_definition_timeout_ec2) + [Controles del sistema](#container_definition_systemcontrols_ec2) + [Interactivo](#container_definition_interactive_ec2) + [Pseudo terminal](#container_definition_pseudoterminal_ec2) #### Parámetros de Linux `linuxParameters` Tipo: objeto [LinuxParameters](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LinuxParameters.html) Obligatorio: no Opciones específicas de Linux que se aplican al contenedor, como [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html). Este parámetro no es compatible con los contenedores de Windows. ``` "linuxParameters": { "capabilities": { "add": ["string", ...], "drop": ["string", ...] } } ``` `capabilities` Tipo: objeto [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities_ec2.html) Obligatorio: no Las capacidades de Linux para el contenedor que se agregan a la configuración predeterminada proporcionada por Docker o se eliminan de ella. Para obtener más información sobre estas capacidades de Linux, consulte la página del manual de Linux sobre [capacidades(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html). `add` Tipo: matriz de cadenas Valores válidos: -.: `"ALL" | "AUDIT_CONTROL" | "AUDIT_READ" | "AUDIT_WRITE" | "BLOCK_SUSPEND" | "CHOWN" | "DAC_OVERRIDE" | "DAC_READ_SEARCH" | "FOWNER" | "FSETID" | "IPC_LOCK" | "IPC_OWNER" | "KILL" | "LEASE" | "LINUX_IMMUTABLE" | "MAC_ADMIN" | "MAC_OVERRIDE" | "MKNOD" | "NET_ADMIN" | "NET_BIND_SERVICE" | "NET_BROADCAST" | "NET_RAW" | "SETFCAP" | "SETGID" | "SETPCAP" | "SETUID" | "SYS_ADMIN" | "SYS_BOOT" | "SYS_CHROOT" | "SYS_MODULE" | "SYS_NICE" | "SYS_PACCT" | "SYS_PTRACE" | "SYS_RAWIO" | "SYS_RESOURCE" | "SYS_TIME" | "SYS_TTY_CONFIG" | "SYSLOG" | "WAKE_ALARM"` Obligatorio: no Las capacidades de Linux para el contenedor que se deben añadir a la configuración predeterminada proporcionada por Docker. Este parámetro se corresponde con `CapAdd` en el comando create-container de docker y la opción `--cap-add` se corresponde con docker run. `add` Tipo: matriz de cadenas Valores válidos: -.: `"SYS_PTRACE"` Obligatorio: no Las capacidades de Linux para el contenedor que se deben agregar a la configuración predeterminada proporcionada por Docker. Este parámetro se corresponde con `CapAdd` en el comando create-container de docker y la opción `--cap-add` se corresponde con docker run. `drop` Tipo: matriz de cadenas Valores válidos: -.: `"ALL" | "AUDIT_CONTROL" | "AUDIT_WRITE" | "BLOCK_SUSPEND" | "CHOWN" | "DAC_OVERRIDE" | "DAC_READ_SEARCH" | "FOWNER" | "FSETID" | "IPC_LOCK" | "IPC_OWNER" | "KILL" | "LEASE" | "LINUX_IMMUTABLE" | "MAC_ADMIN" | "MAC_OVERRIDE" | "MKNOD" | "NET_ADMIN" | "NET_BIND_SERVICE" | "NET_BROADCAST" | "NET_RAW" | "SETFCAP" | "SETGID" | "SETPCAP" | "SETUID" | "SYS_ADMIN" | "SYS_BOOT" | "SYS_CHROOT" | "SYS_MODULE" | "SYS_NICE" | "SYS_PACCT" | "SYS_PTRACE" | "SYS_RAWIO" | "SYS_RESOURCE" | "SYS_TIME" | "SYS_TTY_CONFIG" | "SYSLOG" | "WAKE_ALARM"` Obligatorio: no Las capacidades de Linux para el contenedor que se deben eliminar de la configuración predeterminada proporcionada por Docker. Este parámetro se corresponde con `CapDrop` en el comando create-container de docker y la opción `--cap-drop` con docker run. `devices` Cualquier dispositivo host que exponer en el contenedor. Este parámetro se corresponde con `Devices` en el comando create-container de docker y la opción `--device` con docker run. Tipo: matriz de objetos [Dispositivo](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Device.html) Obligatorio: no `hostPath` La ruta del dispositivo de la instancia de contenedor del host. Tipo: cadena Obligatorio: sí `containerPath` La ruta dentro del contenedor en la cual exponer el dispositivo host. Tipo: cadena Requerido: no `permissions` Los permisos explícitos que proporcionar al contenedor para el dispositivo. De forma predeterminada, el contenedor tiene permisos para `read`, `write` y `mknod` en el dispositivo. Tipo: matriz de cadenas Valores válidos: `read` \$1 `write` \$1 `mknod` `initProcessEnabled` Ejecute un proceso `init` dentro del contenedor que reenvíe señales y aproveche procesos. Este parámetro se corresponde con la opción `--init` con docker run. Este parámetro requiere la versión 1.25 de la API remota de Docker o superior en su instancia de contenedor. `maxSwap` La cantidad total de memoria de intercambio (en MiB) que puede utilizar un contenedor. Este parámetro se traduce en la opción `--memory-swap` de docker run donde el valor es la suma de la memoria del contenedor más el valor de `maxSwap`. Si se especifica un valor `maxSwap` para `0`, el contenedor no utiliza el intercambio. Los valores aceptados son `0` o cualquier entero positivo. Si se omite el parámetro `maxSwap`, el contenedor utiliza la configuración de intercambio de la instancia de contenedor en la que se está ejecutando. Debe establecerse un valor de `maxSwap` para el parámetro `swappiness`. `sharedMemorySize` El valor del tamaño (en MiB) del volumen `/dev/shm`. Este parámetro se corresponde con la opción `--shm-size` con docker run. Tipo: número entero `swappiness` Puede utilizar este parámetro para ajustar el comportamiento de intercambio de memoria de un contenedor. Un valor `swappiness` de `0` evita que se produzca el intercambio a menos que sea necesario. Un valor `swappiness` de `100` hace que las páginas se intercambien con frecuencia. Los valores aceptados son números enteros comprendidos entre `0` y `100`. Si no especifica un valor, se utiliza el valor predeterminado de `60`. Además, si no se especifica un valor para `maxSwap`, este parámetro se omite. Este parámetro se corresponde con la opción `--memory-swappiness` con docker run. Si utiliza tareas en Amazon Linux 2023, no se admite el parámetro `swappiness`. `tmpfs` La ruta del contenedor, las opciones de montaje y el tamaño máximo (en MiB) del montaje tmpfs. Este parámetro se corresponde con la opción `--tmpfs` con docker run. Tipo: matriz de objetos [Tmpfs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Tmpfs.html) Obligatorio: no `containerPath` La ruta de archivo absoluta en la que se montará el volumen tmpfs. Tipo: cadena Obligatorio: sí `mountOptions` La lista de opciones de montaje del volumen tmpfs. Tipo: matriz de cadenas Obligatorio: no Valores válidos: `"defaults" | "ro" | "rw" | "suid" | "nosuid" | "dev" | "nodev" | "exec" | "noexec" | "sync" | "async" | "dirsync" | "remount" | "mand" | "nomand" | "atime" | "noatime" | "diratime" | "nodiratime" | "bind" | "rbind" | "unbindable" | "runbindable" | "private" | "rprivate" | "shared" | "rshared" | "slave" | "rslave" | "relatime" | "norelatime" | "strictatime" | "nostrictatime" | "mode" | "uid" | "gid" | "nr_inodes" | "nr_blocks" | "mpol"` `size` El tamaño máximo (en MiB) del volumen tmpfs. Tipo: número entero Obligatorio: sí #### Dependencia de contenedor `dependsOn` Tipo: matriz de objetos [ContainerDependency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html) Obligatorio: no Las dependencias definidas para el inicio y apagado del contenedor. Un contenedor puede contener varias dependencias. Cuando una dependencia se define para el inicio del contenedor, se invierte para el apagado del contenedor. Para ver un ejemplo, consulta [Dependencia de contenedor](example_task_definitions.md#example_task_definition-containerdependency). Si un contenedor no cumple una restricción de dependencia o agota el tiempo de espera antes de cumplir la restricción, Amazon ECS no adelanta los contenedores dependientes a su siguiente estado. Las instancias requieren al menos la versión `1.26.0` del agente de contenedor para activar las dependencias de contenedor. No obstante, recomendamos utilizar la versión del agente de contenedor más reciente. Para obtener información sobre la comprobación de la versión del agente y la actualización a la versión más reciente, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md). Si utiliza una AMI de Amazon Linux optimizada para Amazon ECS, la instancia necesita al menos la versión `1.26.0-1` del paquete `ecs-init`. Si las instancias de contenedor se lanzan desde la versión `20190301` o posterior, contienen las versiones requeridas del agente de contenedor y `ecs-init`. Para obtener más información, consulte [AMI de Linux optimizadas para Amazon ECS](ecs-optimized_AMI.md). ``` "dependsOn": [ { "containerName": "string", "condition": "string" } ] ``` `containerName` Tipo: cadena Obligatorio: sí El nombre del contenedor que debe cumplir la condición especificada. `condition` Tipo: cadena Obligatorio: sí La condición de dependencia del contenedor. Están disponibles las siguientes condiciones y su comportamiento: + `START`: esta condición simula el comportamiento de enlaces y volúmenes en la actualidad. La condición valida que un contenedor dependiente se inicia antes de permitir que se inicien otros contenedores. + `COMPLETE`: esta condición valida que un contenedor dependiente se ejecute hasta su finalización (se cierre) antes de permitir que otros contenedores se inicien. Esto puede resultar útil para contenedores no esenciales que ejecutan un script y, a continuación, se cierran. Esta condición no se puede establecer en un contenedor esencial. + `SUCCESS`: esta condición es la misma que `COMPLETE`, pero además requiere que el contenedor se cierre con un estado `zero`. Esta condición no se puede establecer en un contenedor esencial. + `HEALTHY`: esta condición valida que el contenedor dependiente pase su comprobación de estado de contenedor antes de permitir que otros contenedores se inicien. Esto requiere que el contenedor dependiente tenga configuradas las comprobaciones de estado en la definición de tarea. Esta condición solo se confirma durante el inicio de tarea. #### Tiempos de espera de contenedor `startTimeout` Tipo: entero Obligatorio: no Valores de ejemplo: : `120` Tiempo que hay que esperar (en segundos) antes de desistir en resolver dependencias para un contenedor. Por ejemplo, se especifican dos contenedores en una definición de tareas donde `containerA` tenga una dependencia en `containerB` que alcance un estado `COMPLETE`, `SUCCESS` o `HEALTHY`. Si se especifica un valor `startTimeout` para `containerB` y este no alcanza el estado deseado en ese tiempo, `containerA` no se inicia. Si un contenedor no cumple una restricción de dependencia o agota el tiempo de espera antes de cumplir la restricción, Amazon ECS no adelanta los contenedores dependientes a su siguiente estado. El valor máximo es 120 segundos. `stopTimeout` Tipo: entero Obligatorio: no Valores de ejemplo: : `120` Duración de tiempo (en segundos) que esperar a que el contenedor se cancelen de forma forzada si no sale de forma normal por sí mismo. Si no se especifica el parámetro `stopTimeout`, se utiliza el valor establecido para la variable de configuración del agente de contenedor de Amazon ECS `ECS_CONTAINER_STOP_TIMEOUT`. Si no se establece ni el parámetro `stopTimeout` ni la variable de configuración del agente `ECS_CONTAINER_STOP_TIMEOUT`, se utilizan los valores predeterminados de 30 segundos para los contenedores Linux y de 30 segundos en contenedores de Windows. Las instancias de contenedor requieren al menos la versión 1.26.0 del agente de contenedor para habilitar un valor de tiempo de espera de parada de contenedor. No obstante, recomendamos utilizar la versión del agente de contenedor más reciente. Para obtener información acerca de cómo comprobar la versión del agente y actualizar a la versión más reciente, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md). Si utiliza la AMI de Amazon Linux optimizada para Amazon ECS, la instancia necesita al menos la versión 1.26.0-1 del paquete `ecs-init`. Si las instancias de contenedor se lanzan desde la versión `20190301` o posterior, contienen las versiones requeridas del agente de contenedor y `ecs-init`. Para obtener más información, consulte [AMI de Linux optimizadas para Amazon ECS](ecs-optimized_AMI.md). #### Controles del sistema `systemControls` Tipo: objeto [SystemControl](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_SystemControl.html) Obligatorio: no Una lista de parámetros de kernel del espacio de nombres que se van a establecer en el contenedor. Este parámetro se corresponde con `Sysctls` en el comando create-container de docker y la opción `--sysctl` con docker run. Por ejemplo, puede configurar la configuración `net.ipv4.tcp_keepalive_time` para mantener conexiones de mayor duración. No se recomienda especificar parámetros `systemControls` relacionados con la red para varios contenedores en una única tarea que también utilice el modo de red `awsvpc` u `host`. De ese modo, se obtienen las siguientes desventajas: + En las tareas que utilicen el modo de red `awsvpc`, si establece `systemControls` en cualquier contenedor, esto se aplicará a todos los contenedores de la tarea. Si establece diferentes parámetros `systemControls` para varios contenedores en una sola tarea, el contenedor que se inicie en último lugar determinará qué `systemControls` se aplicará. + Para las tareas que utilizan el modo de red `host`, no se admiten los `systemControls` del espacio de nombres de la red. Si configura un espacio de nombres de recursos de IPC para usarlo para los contenedores de la tarea, se aplican las siguientes condiciones a los controles del sistema. Para obtener más información, consulte [Modo IPC](task_definition_parameters.md#task_definition_ipcmode). + Para las tareas que usan el modo de IPC `host`, no se admiten los `systemControls` del espacio de nombres IPC. + Para las tareas que utilizan el modo de IPC `task`, los valores de `systemControls` del espacio de nombres IPC se aplican a todos los contenedores de una tarea. Este parámetro no es compatible con contenedores Windows. ``` "systemControls": [ { "namespace":"string", "value":"string" } ] ``` `namespace` Tipo: cadena Requerido: no El parámetro de kernel del espacio de nombres para el que se va a establecer un `value`. Valores de espacio de nombres IPC válidos: `"kernel.msgmax" | "kernel.msgmnb" | "kernel.msgmni" | "kernel.sem" | "kernel.shmall" | "kernel.shmmax" | "kernel.shmmni" | "kernel.shm_rmid_forced"` y `Sysctls` que comiencen por `"fs.mqueue.*"` Valores de espacio de nombres de red válidos: `Sysctls` que comience por `"net.*"` `value` Tipo: cadena Requerido: no El valor del parámetro de kernel del espacio de nombres especificado en `namespace`. #### Interactivo `interactive` Tipo: Booleano Obligatorio: no Si este parámetro es `true`, puede implementar aplicaciones en contenedores que requieran la asignación de `stdin` o un `tty`. Este parámetro se corresponde con `OpenStdin` en el comando create-container de docker y la opción `--interactive` con docker run. El valor predeterminado es `false`. #### Pseudo terminal `pseudoTerminal` Tipo: Booleano Obligatorio: no Cuando este parámetro es `true`, se asigna un TTY. Este parámetro se corresponde con `Tty` en el comando create-container de docker y la opción `--tty` con docker run. El valor predeterminado es `false`. ## Nombre del acelerador de Elastic Inference (en desuso) El requisito de recursos del acelerador de Elastic Inference para la definición de tareas. **nota** Amazon Elastic Inference (EI) ya no está disponible para los clientes. Los siguientes parámetros están permitidos en una definición de tarea: `deviceName` Tipo: cadena Obligatorio: sí Nombre del dispositivo del acelerador de inferencia elástica. También debe hacerse referencia a `deviceName` en una definición de contenedor. Consulte [Elastic Inference accelerator](task_definition_parameters.md#ContainerDefinition-elastic-inference). `deviceType` Tipo: cadena Obligatorio: sí El tipo de acelerador de Elastic Inference que se va a utilizar. ## Restricciones para ubicación de tareas Cuando se registra una definición de tareas, se pueden proporcionar restricciones de ubicación de tareas que personalizan la forma en la que Amazon ECS las coloca. Puede usar las restricciones para ubicar tareas basadas en zona de disponibilidad, tipo de instancia o atributos personalizados. Para obtener más información, consulte [Definición de las instancias de contenedor que utiliza Amazon ECS para las tareas](task-placement-constraints.md). Los siguientes parámetros están permitidos en una definición de contenedor: `expression` Tipo: cadena Requerido: no Una expresión de lenguaje de consulte de clúster que aplicar a la restricción. Para obtener más información, consulte [Creación de expresiones para definir instancias de contenedor para las tareas de Amazon ECS](cluster-query-language.md). `type` Tipo: cadena Obligatorio: sí El tipo de restricción. Utilice `memberOf` para restringir la selección a un grupo de candidatos válidos. ## Configuración del proxy `proxyConfiguration` Tipo: objeto [ProxyConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ProxyConfiguration.html) Obligatorio: no Los detalles de configuración del proxy App Mesh. Para las tareas que utilizan EC2, las instancias de contenedor requieren al menos la versión 1.26.0 del agente de contenedor y al menos la versión 1.26.0-1 del paquete `ecs-init` para habilitar una configuración de proxy. Si las instancias de contenedor se lanzan desde la versión de AMI optimizada para Amazon ECS `20190301` o posterior, entonces contienen las versiones requeridas del agente de contenedor y `ecs-init`. Para obtener más información, consulte [AMI de Linux optimizadas para Amazon ECS](ecs-optimized_AMI.md). Este parámetro no es compatible con contenedores Windows. ``` "proxyConfiguration": { "type": "APPMESH", "containerName": "string", "properties": [ { "name": "string", "value": "string" } ] } ``` `type` Tipo: cadena Valores válidos: `APPMESH` Obligatorio: no El tipo de proxy. El único valor admitido es `APPMESH`. `containerName` Tipo: cadena Obligatorio: sí El nombre del contenedor que sirve como proxy de App Mesh. `properties` Tipo: matriz de objetos [KeyValuePair](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KeyValuePair.html) Obligatorio: no El conjunto de parámetros de configuración de red para proporcionar el complemento Container Network Interface (CNI), especificado como pares clave-valor. + `IgnoredUID`: (obligatorio) el ID de usuario (UID) del contenedor proxy tal y como lo define el parámetro `user` en una definición de contenedor. Se utiliza para garantizar que el proxy pasa por alto su propio tráfico. Si se especifica `IgnoredGID`, este campo puede estar vacío. + `IgnoredGID`: (obligatorio) el ID de grupo (GID) del contenedor proxy tal y como lo define el parámetro `user` en una definición de contenedor. Se utiliza para garantizar que el proxy pasa por alto su propio tráfico. Si se especifica `IgnoredUID`, este campo puede estar vacío. + `AppPorts`: (obligatorio) la lista de los puertos que utiliza la aplicación. El tráfico de red hacia estos puertos se reenvía a `ProxyIngressPort` y `ProxyEgressPort`. + `ProxyIngressPort`: (obligatorio) especifica el puerto al que se dirige el tráfico que ingresa a `AppPorts`. + `ProxyEgressPort`: (obligatorio) especifica el puerto al que se dirige el tráfico que sale de `AppPorts`. + `EgressIgnoredPorts`: (obligatorio) el tráfico de salida que se dirige a estos puertos especificados se pasa por alto y no se redirige a `ProxyEgressPort`. Puede ser una lista vacía. + `EgressIgnoredIPs`: (obligatorio) el tráfico de salida que se dirige a estas direcciones IP especificadas se pasa por alto y no se redirige a `ProxyEgressPort`. Puede ser una lista vacía. `name` Tipo: cadena Requerido: no El nombre del par clave-valor. `value` Tipo: cadena Requerido: no El valor del par clave-valor. ## Volúmenes Al registrar una definición de tareas, se puede especificar una lista de los volúmenes que se transferirán al daemon de Docker en una instancia de contenedor, que estará disponible para otros contenedores en la misma instancia de contenedor. A continuación se indican los tipos de volúmenes de datos que se pueden usar: + Volúmenes de Amazon EBS: proporciona almacenamiento en bloques rentable, duradero y de alto rendimiento para cargas de trabajo en contenedores con uso intensivo de datos. Puede adjuntar un volumen de Amazon EBS por tarea de Amazon ECS cuando ejecute una tarea independiente o cuando cree o actualice un servicio. Se admiten volúmenes de Amazon EBS para tareas de Linux. Para obtener más información, consulte [Uso de volúmenes de Amazon EBS con Amazon ECS](ebs-volumes.md). + Volúmenes de Amazon EFS: proporciona almacenamiento de archivos sencillo, escalable y persistente para usarlo con tareas de Amazon ECS. Con Amazon EFS, la capacidad de almacenamiento es elástica. Aumenta y disminuye automáticamente a medida que se agregan o eliminan archivos. Sus aplicaciones disponen del almacenamiento que necesitan, cuando lo necesitan. Se admiten volúmenes de Amazon EFS. Para obtener más información, consulte [Uso de volúmenes de Amazon EFS con Amazon ECS](efs-volumes.md). + Volúmenes de FSx for Windows File Server: proporciona servidores de archivos de Microsoft Windows completamente administrados. Estos servidores de archivos están respaldados por un sistema de archivos de Windows. Cuando utiliza FSx for Windows File Server junto con Amazon ECS, puede aprovisionar sus tareas de Windows con almacenamiento persistente, distribuido, compartido y estático de archivos. Para obtener más información, consulte [Uso de volúmenes de FSx para Windows File Server con Amazon ECS](wfsx-volumes.md). Los contenedores Windows de Fargate no admiten esta opción. + Volúmenes de Docker: un volumen administrado por Docker que se crea en `/var/lib/docker/volumes` en la instancia de Amazon EC2 del host. Los controladores de volúmenes de Docker (también llamados complementos) se usan para integrar los volúmenes con sistemas de almacenamiento externos como Amazon EBS. Se puede usar el controlador de volumen `local` integrado o un controlador de volumen de terceros. Los volúmenes de Docker se admiten solo cuando se ejecutan tareas en instancias de Amazon EC2. Los contenedores de Windows admiten solo el uso del controlador `local`. Para utilizar volúmenes de Docker, especifique `dockerVolumeConfiguration` en su definición de tarea. + Montajes de unión: un archivo o directorio de la máquina host que se monta en un contenedor. Se admiten volúmenes de host de montaje vinculado. Para utilizar volúmenes de host de montaje vinculado, especifique `host` y un valor de `sourcePath` opcional en su definición de tarea. Para obtener más información, consulte [Opciones de almacenamiento para las tareas de Amazon ECS](using_data_volumes.md). Los siguientes parámetros están permitidos en una definición de contenedor. `name` Tipo: cadena Requerido: no El nombre del volumen. Se admiten hasta 255 letras (mayúsculas y minúsculas), números, guiones (`-`) y caracteres de subrayado (`_`). Se hace referencia a este nombre en el parámetro `sourceVolume` del objeto `mountPoints` de la definición de contenedor. `host` Obligatorio: no El parámetro `host` se utiliza para vincular el ciclo de vida del montaje de enlace a la instancia de Amazon EC2 del host, en lugar de a la tarea, y donde se almacena. Si el parámetro `host` está vacío, entonces el daemon de Docker asigna una ruta de host a su volumen de datos, pero no se garantiza que los datos persistan después de que los contenedores asociados dejen de funcionar. Los contenedores de Windows pueden montar directorios completos en la misma unidad que `$env:ProgramData`. El parámetro `sourcePath` se admite solo cuando se utilizan las tareas que se alojan en instancias de Amazon EC2 o instancias administradas de Amazon ECS. `sourcePath` Tipo: cadena Requerido: no Cuando utilice el parámetro `host`, especifique una `sourcePath` para declarar la ruta de la instancia de Amazon EC2 del host que se presenta al contenedor. Si este parámetro está vacío, el daemon de Docker asigna una ruta de host. Si el parámetro `host` contiene una ubicación de archivos `sourcePath`, el volumen de datos persiste en la ubicación especificada en la instancia de Amazon EC2 del host hasta que la elimine manualmente. Si el valor `sourcePath` no existe en la instancia de Amazon EC2 del host, el daemon de Docker lo crea. Si la ubicación existe, el contenido de la carpeta de la ruta de origen se exporta. `configuredAtLaunch` Tipo: Booleano Obligatorio: no Indica si un volumen se puede configurar durante el lanzamiento. Cuando se establece en `true`, puede configurarlo al ejecutar una tarea independiente o al crear o actualizar un servicio. Cuando se establece en `true`, no podrá proporcionar otra configuración de volumen en la definición de la tarea. Este parámetro se debe establecer en `true` para configurar un volumen de Amazon EBS para adjuntarlo a una tarea. Establecer `configuredAtLaunch` en `true` y aplazar la configuración del volumen hasta la fase de lanzamiento permite crear definiciones de tareas que no se limitan a un tipo de volumen o a una configuración de volumen específica. De este modo, la definición de la tarea se puede reutilizar en distintos entornos de ejecución. Para obtener más información, consulte [Volúmenes de Amazon EBS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html). `dockerVolumeConfiguration` Type: objeto de [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html) Obligatorio: no Este parámetro se especifica cuando se usan volúmenes de Docker. Los volúmenes de Docker se admiten solo cuando se ejecutan tareas en instancias de EC2. Los contenedores de Windows admiten solo el uso del controlador `local`. Para utilizar montajes vinculados, especifique `host` en su lugar. `scope` Tipo: cadena Valores válidos: `task` \$1 `shared` Obligatorio: no El ámbito del volumen de Docker, que determina su ciclo de vida. Los volúmenes de Docker con un ámbito de `task` se aprovisionan automáticamente cuando se inicia la tarea y se destruyen cuando la tarea se detiene. Los volúmenes de Docker cuyo ámbito es `shared` se conservan una vez detenida la tarea. `autoprovision` Tipo: booleano Valor predeterminado: \$1: `false` Obligatorio: no Si este valor es `true`, el volumen de Docker se crea si aún no existe. Este campo se usa solo si `scope` es `shared`. Si el `scope` es `task`, este parámetro debe omitirse. `driver` Tipo: cadena Requerido: no El controlador del volumen de Docker que se va a usar. El valor de controlador debe coincidir con el nombre del controlador proporcionado por Docker, ya que se utiliza para la colocación de tareas. Si el controlador se instaló mediante la CLI del complemento de Docker, utilice `docker plugin ls` para recuperar el nombre de controlador de la instancia de contenedor. Si el controlador se instaló con otro método, utilice la detección de complementos de Docker para recuperar el nombre del controlador. `driverOpts` Tipo: cadena Requerido: no Un mapa de las opciones específicas del controlador de Docker que se deben transferir. Este parámetro se corresponde con `DriverOpts` en la sección Crear un volumen de Docker. `labels` Tipo: cadena Requerido: no Metadatos personalizados que se añaden al volumen de Docker. `efsVolumeConfiguration` Tipo: objeto de [EFSVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSVolumeConfiguration.html) Obligatorio: no Este parámetro se especifica cuando se usan volúmenes de Amazon EFS. `fileSystemId` Tipo: cadena Obligatorio: sí El ID del sistema de archivos de Amazon EFS que se va a usar. `rootDirectory` Tipo: cadena Obligatorio: no Directorio del sistema de archivos de Amazon EFS que se va a montar como directorio raíz dentro del host. Si se omite este parámetro, se utilizará la raíz del volumen de Amazon EFS. Si se especifica `/`, se obtiene el mismo efecto que si se omite este parámetro. Si se especifica un punto de acceso de EFS en `authorizationConfig`, se debe omitir el parámetro del directorio raíz o establecerlo en `/`, lo que aplicará la ruta establecida en el punto de acceso de EFS. `transitEncryption` Tipo: cadena Valores válidos: `ENABLED` \$1 `DISABLED` Obligatorio: no Especifica si se habilita el cifrado para los datos en tránsito de Amazon EFS entre el host de Amazon ECS y el servidor de Amazon EFS. Si se utiliza la autorización de IAM en Amazon EFS, el cifrado en tránsito debe estar habilitado. Si se omite este parámetro, se usa el valor predeterminado de `DISABLED`. Para obtener más información, consulte [Cifrado de datos en tránsito](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html) en la *Guía del usuario de Amazon Elastic File System*. `transitEncryptionPort` Tipo: entero Obligatorio: no El puerto que se utilizará al enviar datos cifrados entre el host de Amazon ECS y el servidor de Amazon EFS. Si no se especifica un puerto de cifrado en tránsito, la tarea utilizará la estrategia de selección de puertos que utiliza el ayudante de montaje de Amazon EFS. Para obtener más información, consulte [Ayudante de montaje de EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html) en la *Guía del usuario de Amazon Elastic File System*. `authorizationConfig` Tipo: objeto de [EFSAuthorizationConfig](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSAuthorizationConfig.html) Obligatorio: no Los detalles de configuración de autorización en el sistema de archivos de Amazon EFS. `accessPointId` Tipo: cadena Requerido: no ID de punto de acceso que se va a utilizar. Si se especifica un punto de acceso, el valor del directorio raíz en `efsVolumeConfiguration` se debe omitir o establecer en `/`, lo que aplicará la ruta establecida en el punto de acceso de EFS. Si se utiliza un punto de acceso, el cifrado de tránsito debe estar habilitado en el `EFSVolumeConfiguration`. Para obtener más información, consulte [Trabajo con puntos de acceso de Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) en la *Guía del usuario de Amazon Elastic File System*. `iam` Tipo: cadena Valores válidos: `ENABLED` \$1 `DISABLED` Obligatorio: no Indica si se debe utilizar el rol de IAM de tarea de Amazon ECS definido en una definición de tareas al montar el sistema de archivos de Amazon EFS. Si está habilitado, el cifrado de tránsito debe estar habilitado en el `EFSVolumeConfiguration`. Si se omite este parámetro, se usa el valor predeterminado de `DISABLED`. Para obtener más información, consulte [Roles de IAM para las tareas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html). `FSxWindowsFileServerVolumeConfiguration` Tipo: objeto de [FSXWindowsFileServerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FSxWindowsFileServerVolumeConfiguration.html) Obligatorio: sí Este parámetro se indica cuando se utiliza el sistema de archivos [Amazon FSx para Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) para el almacenamiento de tareas. `fileSystemId` Tipo: cadena Obligatorio: sí ID del sistema de archivos FSx for Windows File Server que se va a utilizar. `rootDirectory` Tipo: cadena Obligatorio: sí Directorio dentro del sistema de archivos de FSx for Windows File Server que se va a montar como directorio raíz dentro del host. `authorizationConfig` `credentialsParameter` Tipo: cadena Obligatorio: sí Opciones de credenciales de autorización. **opciones:** + Nombre de recurso de Amazon (ARN) del secreto de [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html). + ARN de un parámetro de [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html). `domain` Tipo: cadena Obligatorio: sí Nombre de dominio completo alojado por un directorio de [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html)(AWS Managed Microsoft AD) o un directorio de Active Directory de EC2 con alojamiento propio. ## Etiquetas Cuando se registra una definición de tareas, se pueden especificar etiquetas de metadatos que se aplican a la definición de tareas. Las etiquetas ayudan a clasificar y organizar la definición de tareas. Cada etiqueta consta de una clave y un valor opcional. Los define a los dos. Para obtener más información, consulte [Etiquetado de los recursos de Amazon ECS](ecs-using-tags.md). **importante** No agregue información de identificación personal ni otra información confidencial en las etiquetas. Las etiquetas son accesibles para muchos servicios de AWS, incluida la facturación. Las etiquetas no se diseñaron para utilizarse con información privada o confidencial. Los siguientes parámetros se admiten en un objeto de etiqueta. `key` Tipo: cadena Requerido: no Una parte de un par clave-valor que compone una etiqueta. Un clave es una etiqueta general que actúa como una categoría para valores de etiqueta más específicos. `value` Tipo: cadena Requerido: no La parte opcional de un par clave-valor que compone una etiqueta. Un valor actúa como un descriptor en una categoría de etiquetas (clave). ## Otros parámetros de definición de tarea Los siguientes parámetros de definición de tareas se pueden utilizar cuando se registran definiciones de tareas en la consola de Amazon ECS mediante la opción **Configure via JSON** (Configurar mediante JSON). Para obtener más información, consulte [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md). **Topics** + [Modo IPC](#task_definition_ipcmode_ec2) + [Modo PID](#task_definition_pidmode_ec2) + [Inyección de errores](#task_definition_faultInjection_ec2) ### Modo IPC `ipcMode` Tipo: cadena Requerido: no El espacio de nombres de recurso de IPC que usarán los contenedores de la tarea. Los valores válidos son `host`, `task` o `none`. Si se especifica `host`, todos los contenedores que están dentro de las tareas que tienen especificado el modo de IPC `host` en la misma instancia de contenedor comparten los mismos recursos de IPC con la instancia Amazon EC2 del host. Si se especifica `task`, todos los contenedores que están dentro de la tarea especificada comparten los mismos recursos de IPC. Si se especifica `none`, los recursos de IPC dentro de los contenedores de una tarea son privados y no se comparten con otros contenedores en una tarea o en la instancia de contenedor. Si no se especifica ningún valor, el uso compartido del espacio de nombre de recursos de IPC depende de la configuración del daemon de Docker en la instancia de contenedor. Si se utiliza el modo de IPC `host`, existe un mayor riesgo de exposición de espacio de nombres de IPC no deseada. Si configura parámetros del kernel del espacio de nombres mediante `systemControls` para los contenedores de la tarea, se aplica lo siguiente a su espacio de nombres de recursos de IPC. + Para las tareas que utilizan el modo de IPC `host`, no se admiten los `systemControls` relacionados con el espacio de nombres de IPC. + Para las tareas que utilizan el modo de IPC `task`, los `systemControls` relacionados con el espacio de nombres de IPC se aplican a todos los contenedores de una tarea. ### Modo PID `pidMode` Tipo: cadena Valores válidos: `host` \$1 `task` Obligatorio: no El espacio de nombres del proceso que usarán los contenedores de la tarea. Los valores válidos son `host` o `task`. Por ejemplo, la supervisión de los archivos sidecar puede necesitar `pidMode` para acceder a información sobre otros contenedores que se ejecutan en la misma tarea. Si se especifica `host`, todos los contenedores dentro de las tareas que tienen especificado el modo de PID `host` en la misma instancia de contenedor comparten el mismo espacio de nombres del proceso con la instancia Amazon EC2 del host. Si se especifica `task`, todos los contenedores dentro de la tarea especificada comparten el mismo espacio de nombres del proceso. Si no se especifica ningún valor, el valor predeterminado es un espacio de nombre privado para cada contenedor. Si se utiliza el modo de PID `host`, existe un mayor riesgo de exposición de espacio de nombres del proceso no deseada. **nota** Este parámetro no es compatible con contenedores Windows. ### Inyección de errores `enableFaultInjection` Tipo: booleano Valores válidos: `true` \$1 `false` Obligatorio: no Si este parámetro se establece en `true`, en la carga útil de una tarea, Amazon ECS aceptará solicitudes de inyección de errores de los contenedores de la tarea. Este parámetro está establecido en de forma predeterminada `false`. # Plantilla de definición de tareas de Amazon ECS Una plantilla de definición de tareas vacía se ve así. Utilice esta plantilla para crear la definición de la tarea, que posteriormente se puede pegar en el área de entrada JSON de la consola o guardar en un archivo y utilizarse con la opción de la AWS CLI `--cli-input-json`. Para obtener más información, consulte [Parámetros en la definición de tareas de Amazon ECS para Fargate](task_definition_parameters.md). **Plantilla de EC2** ``` { "family": "", "taskRoleArn": "", "executionRoleArn": "", "networkMode": "none", "containerDefinitions": [ { "name": "", "image": "", "repositoryCredentials": { "credentialsParameter": "" }, "cpu": 0, "memory": 0, "memoryReservation": 0, "links": [""], "portMappings": [ { "containerPort": 0, "hostPort": 0, "protocol": "tcp" } ], "restartPolicy": { "enabled": true, "ignoredExitCodes": [0], "restartAttemptPeriod": 180 }, "essential": true, "entryPoint": [""], "command": [""], "environment": [ { "name": "", "value": "" } ], "environmentFiles": [ { "value": "", "type": "s3" } ], "mountPoints": [ { "sourceVolume": "", "containerPath": "", "readOnly": true } ], "volumesFrom": [ { "sourceContainer": "", "readOnly": true } ], "linuxParameters": { "capabilities": { "add": [""], "drop": [""] }, "devices": [ { "hostPath": "", "containerPath": "", "permissions": ["read"] } ], "initProcessEnabled": true, "sharedMemorySize": 0, "tmpfs": [ { "containerPath": "", "size": 0, "mountOptions": [""] } ], "maxSwap": 0, "swappiness": 0 }, "secrets": [ { "name": "", "valueFrom": "" } ], "dependsOn": [ { "containerName": "", "condition": "COMPLETE" } ], "startTimeout": 0, "stopTimeout": 0, "hostname": "", "user": "", "workingDirectory": "", "disableNetworking": true, "privileged": true, "readonlyRootFilesystem": true, "dnsServers": [""], "dnsSearchDomains": [""], "extraHosts": [ { "hostname": "", "ipAddress": "" } ], "dockerSecurityOptions": [""], "interactive": true, "pseudoTerminal": true, "dockerLabels": { "KeyName": "" }, "ulimits": [ { "name": "nofile", "softLimit": 0, "hardLimit": 0 } ], "logConfiguration": { "logDriver": "splunk", "options": { "KeyName": "" }, "secretOptions": [ { "name": "", "valueFrom": "" } ] }, "healthCheck": { "command": [""], "interval": 0, "timeout": 0, "retries": 0, "startPeriod": 0 }, "systemControls": [ { "namespace": "", "value": "" } ], "resourceRequirements": [ { "value": "", "type": "InferenceAccelerator" } ], "firelensConfiguration": { "type": "fluentbit", "options": { "KeyName": "" } } } ], "volumes": [ { "name": "", "host": { "sourcePath": "" }, "configuredAtLaunch": true, "dockerVolumeConfiguration": { "scope": "shared", "autoprovision": true, "driver": "", "driverOpts": { "KeyName": "" }, "labels": { "KeyName": "" } }, "efsVolumeConfiguration": { "fileSystemId": "", "rootDirectory": "", "transitEncryption": "DISABLED", "transitEncryptionPort": 0, "authorizationConfig": { "accessPointId": "", "iam": "ENABLED" } }, "fsxWindowsFileServerVolumeConfiguration": { "fileSystemId": "", "rootDirectory": "", "authorizationConfig": { "credentialsParameter": "", "domain": "" } } } ], "placementConstraints": [ { "type": "memberOf", "expression": "" } ], "requiresCompatibilities": ["EC2"], "cpu": "", "memory": "", "tags": [ { "key": "", "value": "" } ], "pidMode": "task", "ipcMode": "task", "proxyConfiguration": { "type": "APPMESH", "containerName": "", "properties": [ { "name": "", "value": "" } ] }, "inferenceAccelerators": [ { "deviceName": "", "deviceType": "" } ], "ephemeralStorage": { "sizeInGiB": 0 }, "runtimePlatform": { "cpuArchitecture": "X86_64", "operatingSystemFamily": "WINDOWS_SERVER_20H2_CORE" } } ``` **Plantilla de Fargate** **importante** En el caso de Fargate, debe incluir el parámetro `operatingSystemFamily` con uno de los valores siguientes: `LINUX` `WINDOWS_SERVER_2019_FULL` `WINDOWS_SERVER_2019_CORE` `WINDOWS_SERVER_2022_FULL` `WINDOWS_SERVER_2022_CORE` ``` { "family": "", "runtimePlatform": {"operatingSystemFamily": ""}, "taskRoleArn": "", "executionRoleArn": "", "networkMode": "awsvpc", "platformFamily": "", "containerDefinitions": [ { "name": "", "image": "", "repositoryCredentials": {"credentialsParameter": ""}, "cpu": 0, "memory": 0, "memoryReservation": 0, "links": [""], "portMappings": [ { "containerPort": 0, "hostPort": 0, "protocol": "tcp" } ], "essential": true, "entryPoint": [""], "command": [""], "environment": [ { "name": "", "value": "" } ], "environmentFiles": [ { "value": "", "type": "s3" } ], "mountPoints": [ { "sourceVolume": "", "containerPath": "", "readOnly": true } ], "volumesFrom": [ { "sourceContainer": "", "readOnly": true } ], "linuxParameters": { "capabilities": { "add": [""], "drop": [""] }, "devices": [ { "hostPath": "", "containerPath": "", "permissions": ["read"] } ], "initProcessEnabled": true, "sharedMemorySize": 0, "tmpfs": [ { "containerPath": "", "size": 0, "mountOptions": [""] } ], "maxSwap": 0, "swappiness": 0 }, "secrets": [ { "name": "", "valueFrom": "" } ], "dependsOn": [ { "containerName": "", "condition": "HEALTHY" } ], "startTimeout": 0, "stopTimeout": 0, "hostname": "", "user": "", "workingDirectory": "", "disableNetworking": true, "privileged": true, "readonlyRootFilesystem": true, "dnsServers": [""], "dnsSearchDomains": [""], "extraHosts": [ { "hostname": "", "ipAddress": "" } ], "dockerSecurityOptions": [""], "interactive": true, "pseudoTerminal": true, "dockerLabels": {"KeyName": ""}, "ulimits": [ { "name": "msgqueue", "softLimit": 0, "hardLimit": 0 } ], "logConfiguration": { "logDriver": "awslogs", "options": {"KeyName": ""}, "secretOptions": [ { "name": "", "valueFrom": "" } ] }, "healthCheck": { "command": [""], "interval": 0, "timeout": 0, "retries": 0, "startPeriod": 0 }, "systemControls": [ { "namespace": "", "value": "" } ], "resourceRequirements": [ { "value": "", "type": "GPU" } ], "firelensConfiguration": { "type": "fluentd", "options": {"KeyName": ""} } } ], "volumes": [ { "name": "", "host": {"sourcePath": ""}, "configuredAtLaunch":true, "dockerVolumeConfiguration": { "scope": "task", "autoprovision": true, "driver": "", "driverOpts": {"KeyName": ""}, "labels": {"KeyName": ""} }, "efsVolumeConfiguration": { "fileSystemId": "", "rootDirectory": "", "transitEncryption": "ENABLED", "transitEncryptionPort": 0, "authorizationConfig": { "accessPointId": "", "iam": "ENABLED" } } } ], "requiresCompatibilities": ["FARGATE"], "cpu": "", "memory": "", "tags": [ { "key": "", "value": "" } ], "ephemeralStorage": {"sizeInGiB": 0}, "pidMode": "task", "ipcMode": "none", "proxyConfiguration": { "type": "APPMESH", "containerName": "", "properties": [ { "name": "", "value": "" } ] }, "inferenceAccelerators": [ { "deviceName": "", "deviceType": "" } ] } ``` Puede generar esta plantilla de definición de tareas utilizando el comando de la AWS CLI a continuación. ``` aws ecs register-task-definition --generate-cli-skeleton ``` # Ejemplo de definiciones de tareas de Amazon ECS Puede copiar los ejemplos y fragmentos de código para comenzar a crear sus propias definiciones de tareas. Puede copiar los ejemplos y, a continuación, pegarlos cuando utilice la opción **Configurar mediante JSON** en la consola. Asegúrese de personalizar los ejemplos, como usar el ID de su cuenta. Puede incluir los fragmentos en el JSON de definición de tareas. Para obtener más información, consulte [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md) y [Parámetros en la definición de tareas de Amazon ECS para Fargate](task_definition_parameters.md). Para obtener más ejemplos de definición de tareas, consulte [Definiciones de tareas de muestra de AWS](https://github.com/aws-samples/aws-containers-task-definitions) en GitHub. **Topics** + [Servidor web](#example_task_definition-webserver) + [Controlador de registros de `splunk`](#example_task_definition-splunk) + [Controlador de registros de `fluentd`](#example_task_definition-fluentd) + [Controlador de registros de `gelf`](#example_task_definition-gelf) + [Cargas de trabajo en instancias externas](#ecs-anywhere-runtask) + [Rol de IAM de definición de tarea e imagen de Amazon ECR](#example_task_definition-iam) + [Punto de entrada con comando](#example_task_definition-ping) + [Dependencia de contenedor](#example_task_definition-containerdependency) + [Volúmenes en definiciones de tareas](#volume_sample_task_defs) + [Definiciones de tareas de muestra de Windows](#windows_sample_task_defs) ## Servidor web A continuación, se muestra una definición de tarea de ejemplo con contenedores Linux en Fargate que configura un servidor web: ``` { "containerDefinitions": [ { "command": [ "/bin/sh -c \"echo ' Amazon ECS Sample App

Amazon ECS Sample App

Congratulations!

Your application is now running on a container in Amazon ECS.

' > /usr/local/apache2/htdocs/index.html && httpd-foreground\"" ], "entryPoint": [ "sh", "-c" ], "essential": true, "image": "public.ecr.aws/docker/library/httpd:2.4", "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-group" : "/ecs/fargate-task-definition", "awslogs-region": "us-east-1", "awslogs-stream-prefix": "ecs" } }, "name": "sample-fargate-app", "portMappings": [ { "containerPort": 80, "hostPort": 80, "protocol": "tcp" } ] } ], "cpu": "256", "executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole", "family": "fargate-task-definition", "memory": "512", "networkMode": "awsvpc", "runtimePlatform": { "operatingSystemFamily": "LINUX" }, "requiresCompatibilities": [ "FARGATE" ] } ``` A continuación, se muestra una definición de tarea de ejemplo con contenedores Windows en Fargate que configura un servidor web: ``` { "containerDefinitions": [ { "command": ["New-Item -Path C:\\inetpub\\wwwroot\\index.html -Type file -Value ' Amazon ECS Sample App

Amazon ECS Sample App

Congratulations!

Your application is now running on a container in Amazon ECS.

'; C:\\ServiceMonitor.exe w3svc"], "entryPoint": [ "powershell", "-Command" ], "essential": true, "cpu": 2048, "memory": 4096, "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019", "name": "sample_windows_app", "portMappings": [ { "hostPort": 80, "containerPort": 80, "protocol": "tcp" } ] } ], "memory": "4096", "cpu": "2048", "networkMode": "awsvpc", "family": "windows-simple-iis-2019-core", "executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole", "runtimePlatform": {"operatingSystemFamily": "WINDOWS_SERVER_2019_CORE"}, "requiresCompatibilities": ["FARGATE"] } ``` ## Controlador de registros de `splunk` En el fragmento siguiente se muestra cómo utilizar el controlador de registros `splunk` en una definición de tarea que envía los registros a un servicio remoto. El parámetro de token Splunk se especifica como una opción secreta, ya que puede tratarse como información confidencial. Para obtener más información, consulte [Transferencia de datos confidenciales a un contenedor de Amazon ECS](specifying-sensitive-data.md). ``` "containerDefinitions": [{ "logConfiguration": { "logDriver": "splunk", "options": { "splunk-url": "https://cloud.splunk.com:8080", "tag": "tag_name", }, "secretOptions": [{ "name": "splunk-token", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:splunk-token-KnrBkD" }], ``` ## Controlador de registros de `fluentd` En el fragmento siguiente se muestra cómo utilizar el controlador de registros `fluentd` en una definición de tarea que envía los registros a un servicio remoto. El valor `fluentd-address` se especifica como una opción secreta, ya que puede ser tratado como información confidencial. Para obtener más información, consulte [Transferencia de datos confidenciales a un contenedor de Amazon ECS](specifying-sensitive-data.md). ``` "containerDefinitions": [{ "logConfiguration": { "logDriver": "fluentd", "options": { "tag": "fluentd demo" }, "secretOptions": [{ "name": "fluentd-address", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:fluentd-address-KnrBkD" }] }, "entryPoint": [], "portMappings": [{ "hostPort": 80, "protocol": "tcp", "containerPort": 80 }, { "hostPort": 24224, "protocol": "tcp", "containerPort": 24224 }] }], ``` ## Controlador de registros de `gelf` En el fragmento siguiente se muestra cómo utilizar el controlador de registros `gelf` en una definición de tarea que envía los registros a un host remoto que ejecuta Logstash que toma los registros de Gelf como entrada. Para obtener más información, consulte [logConfiguration](task_definition_parameters.md#ContainerDefinition-logConfiguration). ``` "containerDefinitions": [{ "logConfiguration": { "logDriver": "gelf", "options": { "gelf-address": "udp://logstash-service-address:5000", "tag": "gelf task demo" } }, "entryPoint": [], "portMappings": [{ "hostPort": 5000, "protocol": "udp", "containerPort": 5000 }, { "hostPort": 5000, "protocol": "tcp", "containerPort": 5000 } ] }], ``` ## Cargas de trabajo en instancias externas Cuando registre una definición de tareas de Amazon ECS, utilice el parámetro `requiresCompatibilities` y especifique `EXTERNAL` a fin de validar la compatibilidad de la definición de tareas para su utilización al ejecutar cargas de trabajo de Amazon ECS en las instancias externas. Si utiliza la consola para registrar una definición de tarea, debe utilizar el editor de JSON. Para obtener más información, consulte [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md). **importante** Si las tareas requieren un rol de IAM de ejecución de tareas, asegúrese de que esté especificado en la definición de tareas. Cuando implemente la carga de trabajo, utilice el tipo de lanzamiento `EXTERNAL` al crear el servicio o ejecutar la tarea independiente. A continuación, se muestra una definición de tareas de ejemplo. ------ #### [ Linux ] ``` { "requiresCompatibilities": [ "EXTERNAL" ], "containerDefinitions": [{ "name": "nginx", "image": "public.ecr.aws/nginx/nginx:latest", "memory": 256, "cpu": 256, "essential": true, "portMappings": [{ "containerPort": 80, "hostPort": 8080, "protocol": "tcp" }] }], "networkMode": "bridge", "family": "nginx" } ``` ------ #### [ Windows ] ``` { "requiresCompatibilities": [ "EXTERNAL" ], "containerDefinitions": [{ "name": "windows-container", "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019", "memory": 256, "cpu": 512, "essential": true, "portMappings": [{ "containerPort": 80, "hostPort": 8080, "protocol": "tcp" }] }], "networkMode": "bridge", "family": "windows-container" } ``` ------ ## Rol de IAM de definición de tarea e imagen de Amazon ECR El fragmento siguiente utiliza una imagen de Amazon ECR denominada `aws-nodejs-sample` con la etiqueta `v1` del registro `123456789012.dkr.ecr.us-west-2.amazonaws.com`. El contenedor de esta tarea hereda los permisos de IAM del rol `arn:aws:iam::123456789012:role/AmazonECSTaskS3BucketRole`. Para obtener más información, consulte [Rol de IAM de tarea de Amazon ECS](task-iam-roles.md). ``` { "containerDefinitions": [ { "name": "sample-app", "image": "123456789012.dkr.ecr.us-west-2.amazonaws.com/aws-nodejs-sample:v1", "memory": 200, "cpu": 10, "essential": true } ], "family": "example_task_3", "taskRoleArn": "arn:aws:iam::123456789012:role/AmazonECSTaskS3BucketRole" } ``` ## Punto de entrada con comando El fragmento siguiente muestra la sintaxis de un contenedor de Docker que utiliza un punto de entrada y un argumento de comando. Este contenedor realiza ping a `example.com` cuatro veces y, a continuación, se cierra. ``` { "containerDefinitions": [ { "memory": 32, "essential": true, "entryPoint": ["ping"], "name": "alpine_ping", "readonlyRootFilesystem": true, "image": "alpine:3.4", "command": [ "-c", "4", "example.com" ], "cpu": 16 } ], "family": "example_task_2" } ``` ## Dependencia de contenedor Este fragmento muestra la sintaxis de una definición de tareas con varios contenedores donde se especifica la dependencia de contenedores. En la siguiente definición de tarea, el contenedor `envoy` debe llegar a un estado de funcionamiento correcto, determinado por los parámetros necesarios de comprobación de estado del contenedor, antes de que el contenedor `app` se inicie. Para obtener más información, consulte [Dependencia de contenedor](task_definition_parameters.md#container_definition_dependson). ``` { "family": "appmesh-gateway", "runtimePlatform": { "operatingSystemFamily": "LINUX" }, "proxyConfiguration":{ "type": "APPMESH", "containerName": "envoy", "properties": [ { "name": "IgnoredUID", "value": "1337" }, { "name": "ProxyIngressPort", "value": "15000" }, { "name": "ProxyEgressPort", "value": "15001" }, { "name": "AppPorts", "value": "9080" }, { "name": "EgressIgnoredIPs", "value": "169.254.170.2,169.254.169.254" } ] }, "containerDefinitions": [ { "name": "app", "image": "application_image", "portMappings": [ { "containerPort": 9080, "hostPort": 9080, "protocol": "tcp" } ], "essential": true, "dependsOn": [ { "containerName": "envoy", "condition": "HEALTHY" } ] }, { "name": "envoy", "image": "840364872350.dkr.ecr.region-code.amazonaws.com/aws-appmesh-envoy:v1.15.1.0-prod", "essential": true, "environment": [ { "name": "APPMESH_VIRTUAL_NODE_NAME", "value": "mesh/meshName/virtualNode/virtualNodeName" }, { "name": "ENVOY_LOG_LEVEL", "value": "info" } ], "healthCheck": { "command": [ "CMD-SHELL", "echo hello" ], "interval": 5, "timeout": 2, "retries": 3 } } ], "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole", "networkMode": "awsvpc" } ``` ## Volúmenes en definiciones de tareas Utilice lo siguiente para entender cómo especificar los volúmenes en las tareas. + Para obtener información acerca de cómo configurar un volumen de Amazon EBS, consulte [Especificación de la configuración del volumen de Amazon EBS durante la implementación de Amazon ECS](configure-ebs-volume.md). + Para obtener información acerca de cómo configurar un volumen de Amazon EFS, consulte [Configuración de sistemas de archivos de Amazon EFS para Amazon ECS mediante la consola](tutorial-efs-volumes.md). + Para obtener información acerca de cómo configurar un volumen de FSx for Windows File Server, consulte [Obtenga información sobre cómo configurar FSx para sistemas de archivos de Windows File Server para Amazon ECS.](tutorial-wfsx-volumes.md). + Para obtener información acerca de cómo configurar un volumen de Docker, consulte [Ejemplos de volúmenes de Docker para Amazon ECS](docker-volume-examples.md). + Para obtener información acerca de cómo configurar un montaje vinculado, consulte [Ejemplos de montajes vinculados para Amazon ECS](bind-mount-examples.md). ## Definiciones de tareas de muestra de Windows A continuación, se muestra una definición de tareas de muestra que lo ayudará a familiarizarse con los contenedores de Windows en Amazon ECS. **Example Aplicación de muestra de consola de Amazon ECS para Windows** La siguiente definición de tareas corresponde a la aplicación de muestra de la consola de Amazon ECS que se observa en el asistente de primer uso de Amazon ECS; se ha transferido para que utilice la imagen de contenedor de Windows `microsoft/iis`. ``` { "family": "windows-simple-iis", "containerDefinitions": [ { "name": "windows_sample_app", "image": "mcr.microsoft.com/windows/servercore/iis", "cpu": 1024, "entryPoint":["powershell", "-Command"], "command":["New-Item -Path C:\\inetpub\\wwwroot\\index.html -Type file -Value ' Amazon ECS Sample App

Amazon ECS Sample App

Congratulations!

Your application is now running on a container in Amazon ECS.

'; C:\\ServiceMonitor.exe w3svc"], "portMappings": [ { "protocol": "tcp", "containerPort": 80 } ], "memory": 1024, "essential": true } ], "networkMode": "awsvpc", "memory": "1024", "cpu": "1024" } ```