Diferencias en la definición de tareas de Amazon ECS para el tipo de lanzamiento de Fargate

Para utilizar Fargate, 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 el tipo de lanzamiento 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.

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

• cpu: para contenedores Windows en AWS Fargate, el valor no puede ser inferior a 1 vCPU.

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 AWS Management Console, 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_64.

Cuando ejecuta contenedores Linux en AWS Fargate, puede utilizar la arquitectura de CPU X86_64 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.

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. Si bien también puede especificar la CPU y la memoria en el nivel de contenedor para tareas de Fargate, es opcional. 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) nota 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) nota 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) 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.

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.

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 AWS Management Console 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.

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 .

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.

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.

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.

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

• Montajes vinculados para almacenamiento efímero. Para obtener más información, consulte Uso de montajes de unión con Amazon ECS.

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 ECS.

Índices Seekable OCI

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.

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_64 o ARM64.

• Las imágenes de contenedor de la definición de la tarea deben tener índices SOCI en el mismo registro de contenedores que utiliza la imagen.

• 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 no están comprimidas. No se admiten las imágenes de contenedor que utilizan compresión zstd.

• 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 quiere evitar que la imagen de un contenedor se cargue en diferido, elimine el índice SOCI del registro del contenedor. Si una imagen de contenedor de la tarea no cumple alguna de las consideraciones, esa imagen de contenedor se descargan mediante el método predeterminado.

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 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 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-snapshotterde 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.