Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Différences entre les définitions de tâches Amazon ECS pour le type de lancement Fargate

Pour utiliser Fargate, vous devez configurer votre définition de tâche pour utiliser le type de lancement Fargate. Des considérations supplémentaires doivent être prises en compte lors de l'utilisation de Fargate.

Paramètres de définition de tâche

Les tâches qui utilisent le type de lancement Fargate ne prennent pas en charge tous les paramètres de définition de tâche Amazon ECS disponibles. Certains paramètres ne sont pas du tout pris en charge, tandis que d'autres se comportent différemment pour les tâches Fargate.

Les paramètres de définition de tâche suivants ne sont pas valides dans les tâches Fargate :

Les paramètres de définition de tâche suivants sont valides dans les tâches Fargate, mais avec des limitations à prendre en considération :

Afin que votre définition de tâche puisse être utilisée avec Fargate, vous pouvez spécifier ce qui suit lors de l'enregistrement de la définition de tâche :

Systèmes d'exploitation et architectures

Lorsque vous configurez une tâche et une définition du conteneur pour AWS Fargate, vous devez spécifier le système d'exploitation exécuté par le conteneur. Les systèmes d'exploitation suivants sont pris en charge pour AWS Fargate :

Lorsque vous exécutez des conteneurs Windows sur AWS Fargate, vous devez disposer de l'architecture de processeur X86_64.

Lorsque vous exécutez des conteneurs Linux sur AWS Fargate, vous pouvez utiliser l'architecture de processeur X86_64 ou l'architecture ARM64 pour vos applications ARM. Pour plus d’informations, consultez Définitions de tâches Amazon ECS pour les charges de travail ARM 64 bits.

UC et mémoire au niveau de la tâche

Pour les définitions de tâche Amazon ECS pour AWS Fargate, le CPU et la mémoire doivent être spécifiés au niveau de la tâche. Bien que vous puissiez également spécifier l'UC et la mémoire au niveau du conteneur pour les tâches Fargate, cette opération est facultative. La plupart des cas d'utilisation requièrent uniquement la spécification de ces ressources au niveau de la tâche. Le tableau suivant indique les combinaisons valides d'UC et de mémoire au niveau de la tâche. Vous pouvez spécifier des valeurs de mémoire dans la définition de tâche sous forme de chaîne en MiB ou en Go. Par exemple, vous pouvez spécifier une valeur de mémoire 3072 en MiB ou 3 GB en Go. Vous pouvez spécifier les valeurs du processeur dans le fichier JSON sous forme de chaîne en unités de processeur ou en processeurs virtuels (vCPU). Par exemple, vous pouvez spécifier une valeur de processeur 1024 sous forme d'unités de processeur ou 1 vCPU de vCPU.

Mise en réseau des tâches

Les tâches Amazon ECS pour AWS Fargate nécessitent le mode réseau awsvpc, qui fournit à chaque tâche une interface réseau Elastic. Lorsque vous exécutez une tâche ou créez un service avec ce mode réseau, vous devez spécifier un ou plusieurs sous-réseaux pour attacher l'interface réseau et un ou plusieurs groupes de sécurité à appliquer à l'interface réseau.

Si vous utilisez des sous-réseaux publics, déterminez s'il est nécessaire de fournir une adresse IP publique pour l'interface réseau. Pour qu'une tâche Fargate dans un sous-réseau public puisse extraire des images des conteneurs, une adresse IP publique doit être attribuée à l'interface réseau Elastic de la tâche, avec une route vers Internet ou une passerelle NAT pouvant acheminer les demandes vers Internet. Le sous-réseau nécessite qu'une passerelle NAT soit attachée aux demandes d'acheminement à Internet pour qu'une tâche Fargate dans un sous-réseau privé puisse extraire des images de conteneur. Lorsque vous hébergez vos images de conteneur dans Amazon ECR, vous pouvez configurer Amazon ECR pour utiliser un point de terminaison VPC d'interface. Dans ce cas, l'adresse IPv4 privée de la tâche est utilisée pour l'extraction de l'image. Pour plus d'informations sur les points de terminaison d'interface Amazon ECR, consultez Points de terminaison d'un VPC d'interface Amazon ECR (AWS PrivateLink) dans le Guide de l'utilisateur Amazon Elastic Container Registry.

Voici un exemple de networkConfiguration section pour un service Fargate :

"networkConfiguration": { 
   "awsvpcConfiguration": { 
      "assignPublicIp": "ENABLED",
      "securityGroups": [ "sg-12345678" ],
      "subnets": [ "subnet-12345678" ]
   }
}

Limites des ressources de tâche

Les définitions de tâche Amazon ECS pour Linux sur AWS Fargate prennent en charge le paramètre ulimits permettant de définir les limites de ressources d'un conteneur.

Les définitions de tâche Amazon ECS pour Windows sur AWS Fargate ne prennent pas en charge le paramètre ulimits permettant de définir les limites de ressources d'un conteneur.

Les tâches Amazon ECS hébergées sur Fargate utilisent les valeurs de limite définies par défaut par le système d'exploitation, à l'exception du paramètre de limite de ressources nofile. La limite de ressources nofile restreint le nombre de fichiers ouverts qu'un conteneur peut utiliser. Sur Fargate, la limite flexible par défaut nofile est 1024 et la limite stricte est 65535. Vous pouvez définir les valeurs des deux limites jusqu'à 1048576.

L'exemple suivant présente un extrait de définition de tâche qui montre comment définir une limite nofile personnalisée qui a été doublée :

"ulimits": [
    {
       "name": "nofile",
       "softLimit": 2048,
       "hardLimit": 8192
    }
]

Pour plus d'informations sur les autres limites de ressources pouvant être ajustées, consultez Limites des ressources.

Journalisation

Journalisation des événements

Amazon ECS enregistre les actions qu'il entreprend EventBridge. Vous pouvez utiliser les événements Amazon ECS EventBridge pour recevoir des notifications en temps quasi réel concernant l'état actuel de vos clusters, services et tâches Amazon ECS. Vous pouvez également automatiser des actions pour répondre à ces événements. Pour plus d’informations, consultez Automatisez les réponses aux erreurs Amazon ECS à l'aide de EventBridge.

Journalisation du cycle de vie des tâches

Les tâches exécutées sur Fargate publient des horodatages pour suivre l'état de la tâche au cours de son cycle de vie. Vous pouvez voir les horodatages dans les détails de la tâche dans le AWS Management Console et en décrivant la tâche dans les SDK AWS CLI et. Par exemple, vous pouvez utiliser les horodatages pour évaluer le temps passé par la tâche à télécharger les images du conteneur et décider si vous devez optimiser la taille de l'image du conteneur ou utiliser des index Seekable OCI. Pour plus d'informations sur les pratiques relatives aux images de conteneur, veuillez consulter Bonnes pratiques pour les images de conteneurs Amazon ECS.

Journalisation d'applications

Les définitions de tâche Amazon ECS pour AWS Fargate prennent en charge uniquement les pilotes de journal awslogs, splunk et awsfirelens pour la configuration de journal.

Le pilote de awslogs journal configure vos tâches Fargate pour envoyer des informations de journal à Amazon Logs. CloudWatch L'exemple suivant montre un extrait d'une définition de tâche dans lequel le pilote de journal awslogs est configuré :

"logConfiguration": { 
   "logDriver": "awslogs",
   "options": { 
      "awslogs-group" : "/ecs/fargate-task-definition",
      "awslogs-region": "us-east-1",
      "awslogs-stream-prefix": "ecs"
   }
}

Pour plus d'informations sur l'utilisation du pilote de awslogs journal dans une définition de tâche pour envoyer les journaux de vos conteneurs à CloudWatch Logs, consultezEnvoyez les journaux Amazon ECS à CloudWatch .

Pour plus d'informations sur l'utilisation du pilote de journal awsfirelens dans une définition de tâche, consultez Envoyer les journaux Amazon ECS à un AWS service ou AWS Partner.

Pour plus d'informations sur l'utilisation du pilote de journal splunk dans une définition de tâche, consultez splunkpilote de journal.

Stockage de tâche

Pour les tâches Amazon ECS hébergées sur Fargate, les types de stockage suivants sont pris en charge :

Chargement différé d'images de conteneurs à l'aide de Seekable OCI (SOCI)

Les tâches Amazon ECS sur Fargate qui utilisent la version de plateforme 1.4.0 de Linux peuvent utiliser Seekable OCI (SOCI) pour accélérer le démarrage des tâches. Avec SOCI, les conteneurs ne passent que quelques secondes à extraire l'image avant de pouvoir démarrer, ce qui laisse le temps de configurer l'environnement et d'instancier l'application pendant que l'image est téléchargée en arrière-plan. C'est ce qu'on appelle le chargement différé. Lorsque Fargate lance une tâche Amazon ECS, il détecte automatiquement si un index SOCI existe pour une image de la tâche et démarre le conteneur sans attendre que l'image complète soit téléchargée.

Pour les conteneurs qui s'exécutent sans index SOCI, les images des conteneurs sont entièrement téléchargées avant le démarrage du conteneur. Ce comportement est le même sur toutes les autres versions de plateforme de Fargate et sur l'AMI optimisée pour Amazon ECS sur les instances Amazon EC2.

Index Seekable OCI

Seekable OCI (SOCI) est une technologie open source développée par AWS qui permet de lancer des conteneurs plus rapidement en chargeant paresseusement l'image du conteneur. SOCI fonctionne en créant un index (index SOCI) des fichiers dans une image de conteneur existante. Cet index permet de lancer les conteneurs plus rapidement, en offrant la possibilité d'extraire un fichier individuel d'une image de conteneur avant de télécharger l'image complète. L'index SOCI doit être stocké sous forme d'artefact dans le même référentiel que l'image dans le registre des conteneurs. Vous ne devez utiliser que les index SOCI provenant de sources fiables, car l'index est la source officielle du contenu de l'image. Pour plus d'informations, veuillez consulter Présentation de Seekable OCI pour les images de conteneur à chargement différé.

Considérations

Si vous souhaitez que Fargate utilise un index SOCI pour charger des images de conteneur de manière différée dans une tâche, prenez en compte les éléments suivants :

Création d'un index Seekable OCI

Pour qu'une image de conteneur soit chargée en différé, un index SOCI (un fichier de métadonnées) doit être créé et stocké dans le référentiel d'images de conteneur à côté de l'image de conteneur. Pour créer et envoyer un index SOCI, vous pouvez utiliser l'outil open source soci-snapshotter CLI sur. GitHub Vous pouvez également déployer le générateur d'index CloudFormation AWS SOCI. Il s'agit d'une solution sans serveur qui crée et transmet automatiquement un index SOCI lorsqu'une image de conteneur est transmise à Amazon ECR. Pour plus d'informations sur la solution et les étapes d'installation, consultez CloudFormation AWS SOCI Index Builder sur GitHub. Le CloudFormation AWS SOCI Index Builder est un moyen d'automatiser le démarrage avec SOCI, tandis que l'outil SOCI open source offre une plus grande flexibilité en matière de génération d'index et permet d'intégrer la génération d'index dans vos pipelines d'intégration continue et de livraison continue (CI/CD).

Vérification de l'utilisation du chargement différé par une tâche

Pour vérifier qu'une tâche a été chargée en différé à l'aide de SOCI, vérifiez le point de terminaison des métadonnées de la tâche depuis cette dernière. Lorsque vous interrogez le point de terminaison des métadonnées de tâche version 4, il existe un champ Snapshotter dans le chemin par défaut du conteneur à partir duquel vous interrogez. De plus, il existe des champs Snapshotter pour chaque conteneur du chemin /task. La valeur par défaut de ce champ estoverlayfs, et ce champ est défini sur soci si SOCI est utilisé.