Uno de los problemas potenciales para ResourceInitializationError: unable to pull secrets or registry auth: pull command failed: : signal: killed está deshabilitado Asignación automática de IP pública . Después de que lo habilité (recreando el servicio desde cero), la tarea se ejecutó correctamente sin problemas.

Resulta que no tenía habilitado el soporte de DNS para la VPC. Una vez que esto está habilitado, funciona.

No vi el soporte de DNS mencionado explícitamente en ningún documento para Fargate; supongo que es bastante obvio o de qué otra manera buscará los diversos servicios de AWS que necesita. Pero pensé que valía la pena señalarlo en una respuesta contra este mensaje de error.

El ejecutor de contenedores de AWS necesita acceder a los repositorios de contenedores y al servicio de AWS.

Si está en una subred pública, lo más fácil es "Asignar automáticamente la IP pública" para que sus contenedores accedan a Internet, incluso si su aplicación no necesita acceso de salida a Internet.

De lo contrario, si usa solo los servicios de AWS (ECR y no se extraen imágenes de docker.io), podría usar los puntos de enlace de la VPC para acceder a ECR/S3/Cloudwatch y habilitar las opciones de DNS en su VPC.

Para la subred privada, es lo mismo.

Si está utilizando imágenes docker.io, entonces necesita acceso de salida a Internet en su subred de todos modos.

Estaba enfrentando el mismo problema. Pero en mi caso, estaba activando Fargate Container desde la función Lambda usando la operación RunTask. Entonces, en la operación RunTask, no estaba pasando el siguiente parámetro:

asignarPublicIp: HABILITADO

Después de agregar esto, Container se activaba sin problemas.

Respuesta editada basada en comentarios de @nathan y @howard-swope

Lista de Verificación:

• La VPC tiene "nombres de host DNS" y "resolución DNS" habilitados
• El "rol de ejecución de tareas" tiene acceso a ECR. por ejemplo, tiene el rol AmazonECSTaskExecutionRolePolicy

si la tarea se ejecuta en una subred PÚBLICA:

• Las subredes tienen acceso a Internet. es decir, asignando la puerta de enlace de Internet a las subredes.

• Habilite "asignar IP pública" al crear la tarea.

si la tarea se ejecuta en una subred PRIVADA:

• Las subredes tienen acceso a Internet. es decir, asignando la puerta de enlace NAT a las subredes. ... La puerta de enlace NAT reside en una subred pública

Para esas almas desafortunadas, hay una cosa más que verificar.

Ya tenía una puerta de enlace de Internet en mi VPC, el DNS estaba habilitado para esa VPC, todos los contenedores obtenían direcciones IP públicas y el rol de ejecución ya tenía acceso a ECR. Pero aun así, seguía recibiendo el mismo error.

Resulta que el problema era sobre la tabla de enrutamiento . La tabla de enrutamiento de mi VPC no incluía una ruta para dirigir el tráfico saliente a la puerta de enlace de Internet, por lo que mi subred no tenía acceso a Internet.

Agregar la segunda línea a la tabla que enruta el tráfico 0.0.0.0/0 a la puerta de enlace de Internet resolvió el problema.

Para AWS Batch que usa Fargate, este error se desencadenó al deshabilitar la configuración "Asignar IP pública".

Esta configuración se puede configurar durante el paso de Definición del trabajo . Sin embargo, no se puede configurar en la interfaz de usuario después de que ya se haya creado la definición de trabajo .

En mi caso de lidiar con el error anterior, mientras ejecutaba el comando run-task (sí, no a través de la ruta del servicio), no estaba especificando el grupo de seguridad en aws ecs run-task --network-configuration . Esto resultó en que el SG predeterminado se eligiera de la VPC de la tarea. Mi SG predeterminado en esa VPC no tenía definidas reglas de entrada/salida. Agregué SOLAMENTE la regla de salida para permitir todo el tráfico a todas partes y el error desapareció.

Mi configuración es que la tarea ECS/Fargate se ejecutará en una subred privada con conectividad ECR a través de los puntos finales de la interfaz VPC. Hice revisar la lista de verificación mencionada anteriormente y, además, agregué la regla SG.