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 :
-
disableNetworking
-
dnsSearchDomains
-
dnsServers
-
dockerSecurityOptions
-
extraHosts
-
gpu
-
ipcMode
-
links
-
placementConstraints
-
privileged
-
maxSwap
-
swappiness
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 :
-
linuxParameters
: lorsque vous spécifiez des options propres à Linux appliquées au conteneur, pourcapabilities
, la seule fonctionnalité que vous pouvez ajouter estCAP_SYS_PTRACE
. Les paramètresdevices
,sharedMemorySize
ettmpfs
ne sont pas pris en charge. Pour plus d’informations, consultez Paramètres Linux. -
volumes
: les tâches Fargate prennent en charge uniquement les volumes hôtes de montage lié, le paramètredockerVolumeConfiguration
n'est donc pas pris en charge. Pour plus d’informations, consultez Volumes. -
cpu
- Pour les conteneurs Windows sur AWS Fargate, la valeur ne peut pas être inférieure à 1 vCPU.
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 :
-
Dans le champ AWS Management Console, dans le champ Compatibilités requises, spécifiez
FARGATE
. -
Dans le AWS CLI, spécifiez l'
--requires-compatibilities
option. -
Dans l'API Amazon ECS, spécifiez l'indicateur
requiresCompatibilities
.
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 :
-
Amazon Linux 2
Note
Les conteneurs Linux utilisent uniquement le noyau et la configuration du noyau du système d'exploitation hôte. Par exemple, la configuration du noyau inclut les commandes du système
sysctl
. Une image de conteneur Linux peut être créée à partir d'une image de base contenant les fichiers et les programmes de n'importe quelle distribution Linux. Si l'architecture du processeur correspond, vous pouvez exécuter des conteneurs à partir de n'importe quelle image de conteneur Linux sur n'importe quel système d'exploitation. -
Windows Server 2019 Full
-
Windows Server 2019 Core
-
Windows Server 2022 Full
-
Windows Server 2022 Core
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.
Valeur d'UC |
Valeur de mémoire |
Systèmes d'exploitation pris en charge pour AWS Fargate |
---|---|---|
256 (0,25 vCPU) |
512 Mio, 1 Go, 2 Go |
Linux |
512 (0,5 vCPU) |
1 Go, 2 Go, 3 Go, 4 Go |
Linux |
1 024 (1 vCPU) |
2 Go, 3 Go, 4 Go, 5 Go, 6 Go, 7 Go, 8 Go |
Linux, Windows |
2 048 (2 vCPU) |
Entre 4 Go et 16 Go par incréments de 1 Go |
Linux, Windows |
4 096 (4 vCPU) |
Entre 8 Go et 30 Go par incréments de 1 Go |
Linux, Windows |
8192 (8 vCPU) NoteCette option nécessite la plateforme Linux |
Entre 16 Go et 60 Go par incréments de 4 Go |
Linux |
16384 (16vCPU) NoteCette option nécessite la plateforme Linux |
Entre 32 Go et 120 Go par incréments de 8 Go |
Linux |
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 65535
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 :
-
Les volumes Amazon EBS fournissent un stockage par blocs rentable, durable et performant pour les charges de travail conteneurisées gourmandes en données. Pour plus d’informations, consultez Utiliser des volumes Amazon EBS avec Amazon ECS.
-
Volumes Amazon EFS pour le stockage permanent. Pour plus d’informations, consultez Utiliser les volumes Amazon EFS avec Amazon ECS.
-
Supports de liaison pour un stockage éphémère. Pour plus d’informations, consultez Utiliser des montages par liaison avec Amazon ECS.
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 :
-
Seules les tâches exécutées sur une version de plateforme Linux
1.4.0
peuvent utiliser les index SOCI. Les tâches exécutées sur des conteneurs Windows sur Fargate ne sont pas prises en charge. -
Les tâches exécutées sur une architecture de processeur X86_64 ou ARM64 sont prises en charge. Les tâches Linux avec l'architecture ARM64 ne prennent pas en charge le fournisseur de capacité Fargate Spot.
-
Les images de conteneur incluses dans la définition de tâche doivent avoir des index SOCI dans le même registre de conteneurs que l'image.
-
Les images de conteneur incluses dans la définition de tâche doivent être stockées dans un registre d'images compatible. Voici une liste des registres compatibles :
-
Registres privés Amazon ECR.
-
-
Seules les images de conteneur qui utilisent la compression gzip ou qui ne sont pas compressées sont prises en charge. Les images de conteneur qui utilisent la compression zstd ne sont pas prises en charge.
-
Nous vous recommandons d'essayer le chargement différé avec des images de conteneur dont la taille est supérieure à 250 MiB compressés. Il est moins probable que le temps nécessaire pour charger des images plus petites soit réduit.
-
Le chargement différé pouvant modifier le temps de démarrage de vos tâches, vous devrez peut-être modifier différents délais, tels que le délai de grâce de surveillance de l'état pour Elastic Load Balancing.
-
Si vous souhaitez empêcher le chargement différé d'une image de conteneur, supprimez l'index SOCI du registre des conteneurs. Si une image de conteneur dans la tâche ne répond pas à l'un des critères, cette image de conteneur est téléchargée selon la méthode par défaut.
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
Note
Pour que l'index SOCI soit créé pour une image, celle-ci doit exister dans le magasin d'images containerd de l'ordinateur exécutant soci-snapshotter
. Si l'image se trouve dans le magasin d'images Docker, elle est introuvable.
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é.