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. # Définitions de tâche Amazon ECS Une *définition de tâche* est le plan de votre application. Il s'agit d'un fichier texte au format JSON qui décrit les paramètres et un ou plusieurs conteneurs qui forment votre application. Voici certains des paramètres que vous pouvez spécifier dans une définition de tâche : + La capacité à utiliser, qui détermine l’infrastructure sur laquelle vos tâches sont hébergées + L'image Docker à utiliser avec chaque conteneur dans la tâche + Les ressources d'UC et de mémoire à utiliser avec chaque tâche ou chaque conteneur au sein d'une tâche + Les exigences en matière de mémoire et d’UC + Le système d’exploitation du conteneur sur lequel la tâche s’exécute + Le mode réseau Docker à utiliser pour les conteneurs dans votre tâche + La configuration de journalisation à utiliser pour les tâches + Si la tâche continue à s'exécuter en cas d'arrêt ou d'échec du conteneur + La commande que le conteneur exécute au démarrage + Les volumes de données utilisés avec les conteneurs dans la tâche + Le rôle IAM que les tâches utilisent Pour obtenir la liste complète des paramètres de définition de tâche, veuillez consulter [Paramètres de définition de tâche Amazon ECS pour Fargate](task_definition_parameters.md). Après avoir créé une définition de tâche, vous pouvez l'exécuter en tant que tâche ou service. + Une *tâche* est l'instanciation d'une définition de tâche au sein d'un cluster. Après avoir créé une définition de tâche pour votre application dans Amazon ECS, vous pouvez spécifier le nombre de tâches à exécuter sur votre cluster. + Un service Amazon ECS *service* exécute et conserve simultanément le nombre souhaité de tâches dans un cluster Amazon ECS. Le principe est le suivant : si l'une de vos tâches échoue ou s'arrête pour une raison quelconque, le planificateur de service d'Amazon ECS service lance une autre instance en fonction de votre définition de tâche. Il procède ainsi pour le remplacer et donc maintenir le nombre de tâches souhaité dans le service. **Topics** + [ # États de définition de tâche Amazon ECS ](task-definition-state.md) + [ # Architecture de votre application pour Amazon ECS ](application_architecture.md) + [ # Création d’une définition de tâche Amazon ECS à l’aide de la console ](create-task-definition.md) + [ # Utilisation d’Amazon Q Developer pour proposer des recommandations de définition de tâche dans la console Amazon ECS ](using-amazon-q.md) + [ # Mise à jour d’une définition de tâche Amazon ECS à l’aide de la console ](update-task-definition-console-v2.md) + [ # Annulation de l’enregistrement d’une révision de définition de tâche Amazon ECS à l’aide de la console ](deregister-task-definition-v2.md) + [ # Suppression de l’enregistrement d’une révision de définition de tâche Amazon ECS à l’aide de la console ](delete-task-definition-v2.md) + [ # Cas d’utilisation de définition de tâche Amazon ECS ](use-cases.md) + [ # Paramètres de définition de tâche Amazon ECS pour les instances gérées Amazon ECS ](task_definition_parameters-managed-instances.md) + [ # Paramètres de définition de tâche Amazon ECS pour Fargate ](task_definition_parameters.md) + [ # Paramètres de définition de tâche Amazon ECS pour Amazon EC2 ](task_definition_parameters_ec2.md) + [ # Modèle de définition de tâche Amazon ECS ](task-definition-template.md) + [ # Exemple de définitions de tâches Amazon ECS ](example_task_definitions.md) # États de définition de tâche Amazon ECS La définition d’une tâche change d’état lorsque vous la créez, annulez son enregistrement ou la supprimez. Vous pouvez afficher l’état de la définition de tâche dans la console ou en utilisant `DescribeTaskDefinition`. Les états possibles pour une définition de tâche sont les suivants : ACTIF La définition d'une tâche est `ACTIVE` après son enregistrement auprès d'Amazon ECS. Les définitions de tâches à l'état `ACTIVE` vous permettent d’exécuter des tâches ou de créer des services. INACTIVE Une définition de tâche passe de l'état `ACTIVE` à l'état `INACTIVE` lorsque vous annulez l'enregistrement d'une définition de tâche. Vous pouvez récupérer la définition d'une tâche `INACTIVE` en appelant `DescribeTaskDefinition`. Vous ne pouvez pas exécuter de nouvelles tâches ou créer de nouveaux services avec une définition de tâche à l’état `INACTIVE`. Il n'y a aucun impact sur les services ou les tâches existants. DELETE\$1IN\$1PROGRESS Une définition de tâche passe de l'état `INACTIVE` à l'état `DELETE_IN_PROGRESS` une fois que vous l'avez soumise pour suppression. Une fois que la définition de tâche est à l’état `DELETE_IN_PROGRESS`, Amazon ECS vérifie régulièrement que la définition de tâche cible n'est référencée par aucune tâche ou déploiement actif, puis supprime définitivement la définition de tâche. Vous ne pouvez pas exécuter de nouvelles tâches ou créer de nouveaux services avec une définition de tâche à l’état `DELETE_IN_PROGRESS`. Une définition de tâche peut être soumise pour suppression à tout moment sans que cela n’ait d’impact sur les tâches et les services existants. Les définitions de tâches dont l'état est `DELETE_IN_PROGRESS` peuvent être consultées dans la console et vous pouvez récupérer la définition de tâche en appelant `DescribeTaskDefinition`. Lorsque vous supprimez toutes les révisions de définition de tâche `INACTIVE`, le nom de la définition de tâche n'est pas affiché dans la console et n'est pas renvoyé dans l'API. Si une révision de définition de tâche est à l’état `DELETE_IN_PROGRESS`, le nom de la définition de tâche est affiché dans la console et renvoyé dans l’API. Le nom de la définition de tâche est conservé par Amazon ECS et la révision est incrémentée la prochaine fois que vous créerez une définition de tâche portant ce nom. Si vous avez l' AWS Config habitude de gérer vos définitions de tâches, tous les enregistrements de définitions de tâches vous sont AWS Config facturés. Vous n'êtes facturé que pour la désinscription de la dernière définition de tâche `ACTIVE`. La suppression d'une définition de tâche est gratuite. Pour plus d’informations sur la tarification, consultez [Tarification d’AWS Config](https://aws.amazon.com/config/pricing/). ## Ressources Amazon ECS pouvant bloquer une suppression Aucune requête de suppression de définition de tâche ne sera traitée tant qu’il existe des ressources Amazon ECS qui dépendent de la révision de la définition de tâche. Les ressources suivantes peuvent empêcher la suppression d'une définition de tâche : + Tâches autonomes Amazon ECS : la définition de tâche est nécessaire pour que la tâche reste saine. + Tâches d’un service Amazon ECS : la définition de tâche est nécessaire pour que la tâche reste saine. + Déploiements et jeux de tâches d’un service Amazon ECS : la définition de tâche est nécessaire lorsqu’un événement de mise à l’échelle est lancé pour un déploiement ou un jeu de tâches Amazon ECS. Si votre définition de tâche reste `DELETE_IN_PROGRESS` inchangée, vous pouvez utiliser la console ou le AWS CLI pour identifier, puis arrêter les ressources qui bloquent la suppression de la définition de tâche. ### Suppression de la définition de tâche après la suppression de la ressource bloquée Les règles suivantes s'appliquent une fois que vous avez supprimé les ressources bloquant la suppression de la définition de tâche : + Tâches Amazon ECS : la suppression de la définition de tâche peut prendre jusqu'à une heure après l'arrêt de la tâche. + Déploiements et jeux de tâches d’un service Amazon ECS : la suppression de la définition de tâche peut prendre jusqu’à 24 heures après la suppression du déploiement ou du jeu de tâches. # Architecture de votre application pour Amazon ECS Vous élaborez votre application en créant une définition de tâche pour votre application. La définition de tâche contient les paramètres qui définissent les informations relatives à l’application, notamment : + La capacité à utiliser, qui détermine l’infrastructure sur laquelle vos tâches sont hébergées. Lorsque vous utilisez le fournisseur de capacité EC2, vous choisissez également le type d’instance. Lorsque vous utilisez le fournisseur de capacité d’instances gérées Amazon ECS, vous pouvez définir les exigences relatives aux instances pour qu’Amazon ECS gère la capacité de calcul. Pour certains types d’instances, tels que le GPU, vous devez définir des paramètres spécifiques. Pour de plus amples informations, veuillez consulter [Cas d’utilisation de définition de tâche Amazon ECS](use-cases.md). + L’image de conteneur, qui contient le code de votre application et toutes les dépendances nécessaires à son exécution. + Le mode réseau à utiliser pour les conteneurs dans votre tâche. Le mode réseau détermine la manière dont votre tâche communique sur le réseau. Pour les tâches exécutées sur des instances EC2 et des instances gérées Amazon ECS, plusieurs options sont disponibles, mais nous vous recommandons d’utiliser le mode réseau `awsvpc`. Le mode `awsvpc` réseau simplifie la mise en réseau des conteneurs en vous permettant de mieux contrôler la manière dont vos applications communiquent entre elles et avec les autres services au sein de votre entreprise VPCs. Pour les tâches exécutées sur Fargate, vous devez utiliser le mode réseau `awsvpc`. + La configuration de journalisation à utiliser pour les tâches + Les volumes de données utilisés avec les conteneurs dans la tâche. Pour obtenir la liste complète des paramètres de définition de tâche, veuillez consulter [Paramètres de définition de tâche Amazon ECS pour Fargate](task_definition_parameters.md). Suivez ces recommandations lors de la création de vos définitions de tâche : + Utilisez chaque famille de définitions de tâches pour un seul objectif métier. Si vous regroupez plusieurs types de conteneurs d’applications dans la même définition de tâche, vous ne pouvez pas mettre à l’échelle ces conteneurs indépendamment. Par exemple, un site Web et une API nécessitent généralement des modèles de mise à l’échelle différents. À mesure que le trafic augmente, le nombre de conteneurs Web dont vous aurez besoin pourra différer de celui des conteneurs API. Si ces deux conteneurs sont déployés dans la même définition de tâche, chaque tâche exécute le même nombre de conteneurs Web et de conteneurs d’API. + Associez chaque version d'application à une révision de définition de tâche au sein d'une famille de définitions de tâches. Au sein d'une famille de définitions de tâches, chaque révision de définition de tâche représente un point-in-time instantané des paramètres d'une image de conteneur particulière. De la même manière, le conteneur est un instantané de tous les composants nécessaires à l’exécution d’une version particulière du code de votre application. Créez un one-to-one mappage entre une version du code de l'application, une balise d'image de conteneur et une révision de définition de tâche. Un processus de publication typique implique une validation git qui est transformée en une image de conteneur balisée avec le SHA de validation git. Cette balise d'image de conteneur reçoit ensuite sa propre révision de définition de tâche Amazon ECS. Enfin, le service Amazon ECS est mis à jour afin de déployer la nouvelle révision de la définition de tâche. + Utilisez différents rôles IAM pour chaque famille de définitions de tâches. Définissez chaque définition de tâche avec son propre rôle IAM. Mettez cette pratique en œuvre tout en fournissant à chaque composante métier sa propre famille de définitions de tâches. En mettant en œuvre ces deux meilleures pratiques, vous pouvez limiter l'accès de chaque service aux ressources de votre AWS compte. Par exemple, vous pouvez autoriser votre service d'authentification à accéder à votre base de données de mots de passe. Dans le même temps, vous pouvez vous assurer que seul votre service de commande a accès aux informations de paiement par carte de crédit. # Bonnes pratique en matière de taille des tâches Amazon ECS La taille de vos conteneurs et de vos tâches est essentielle pour la mise à l’échelle et la planification de la capacité. Dans Amazon ECS, l’UC et la mémoire sont deux indicateurs de ressources utilisés pour déterminer la capacité. L’UC est mesuré en unités de 1/1 024 d’un vCPU complet (1 024 unités étant égales à 1 vCPU entier). La mémoire est mesurée en mébioctets. Dans la définition de votre tâche, vous pouvez configurer les réserves et les limites des ressources. Lorsque vous configurez une réserve, vous définissez la quantité minimale de ressources requise par une tâche. Votre tâche reçoit au minimum la quantité de ressources demandée. Votre application pourrait être en mesure d’utiliser une quantité d’UC ou de mémoire supérieure à la réserve que vous avez déclarée. Toutefois, les limites que vous avez également déclarées s’appliquent. L’utilisation d’une quantité supérieure à la réserve est appelée éclatement (bursting). Dans Amazon ECS, les réserves sont garanties. Par exemple, si vous utilisez des instances Amazon EC2 pour fournir de la capacité, Amazon ECS ne place aucune tâche sur une instance où la réserve ne peut pas être honorée. Une limite est la quantité maximale d’unités d’UC ou de mémoire que votre conteneur ou votre tâche peut utiliser. Toute tentative d’utiliser davantage d’UC que cette limite entraîne un ralentissement. Toute tentative d’utiliser davantage de mémoire entraîne l’arrêt de votre conteneur. Choisir ces valeurs peut s’avérer difficile. En effet, les valeurs les mieux adaptées à votre application dépendent dans une large mesure des besoins en ressources de celle-ci. Le test de charge de votre application est la clé d’une planification réussie des besoins en ressources et d’une meilleure compréhension des exigences de votre application. ## Applications sans état Pour les applications sans état soumises à une mise à l’échelle horizontale, telles que les applications derrière un équilibreur de charge, nous vous recommandons de déterminer au préalable la quantité de mémoire consommée par votre application lorsqu’elle traite les requêtes. Pour ce faire, vous pouvez utiliser des outils traditionnels tels que `ps` ou `top` des solutions de surveillance telles que CloudWatch Container Insights. Lorsque vous déterminez une réserve d’UC, considérez de quelle manière votre application doit être mise à l’échelle pour répondre aux besoins de votre entreprise. Vous pouvez utiliser des réserves d’UC plus petites, telles que 256 unités d’UC (soit 1/4 de vCPU), pour procéder à une augmentation horizontale précise tout en minimisant les coûts. Cependant, leur mise à l’échelle peut ne pas être assez rapide pour répondre à des pics de demande importants. Vous pouvez utiliser des réserves d’UC plus importantes pour procéder plus rapidement à des augmentations ou à des réductions horizontales et ainsi répondre plus rapidement aux pics de demande. Cependant, les réserves d’UC plus importantes sont plus coûteuses. ## Autres applications Pour les applications qui ne subissent pas de mise à l’échelle horizontale, telles que les travailleurs uniques ou les serveurs de base de données, la capacité disponible et les coûts constituent vos considérations les plus importantes. Vous devez choisir la quantité de mémoire et d’UC en fonction des résultats des tests de charge, qui indiquent les ressources nécessaires pour traiter le trafic et atteindre votre objectif de niveau de service. Amazon ECS garantit que l’application est placée sur un hôte doté d’une capacité adéquate. # Mise en réseau des tâches Amazon ECS pour les instances gérées Amazon ECS Le comportement de mise en réseau des tâches Amazon ECS exécutées sur des instances gérées Amazon ECS est déterminé par le *mode réseau* spécifié dans la définition de tâche. Vous devez spécifier un mode réseau dans la définition de tâche. Vous ne pourrez exécuter aucune tâche sur les instances gérées Amazon ECS en utilisant une définition de tâche qui ne spécifie pas de mode réseau. Les instances gérées Amazon ECS prennent en charge les modes réseau suivants, garantissant ainsi la rétrocompatibilité pour la migration de charges de travail depuis Fargate ou Amazon ECS vers Amazon EC2 : | Mode réseau | Description | | --- | --- | | `awsvpc` | Chaque tâche reçoit sa propre interface réseau Elastic (ENI) et son adresse IPv4 privée. Ce mode offre les mêmes propriétés réseau que les instances Amazon EC2 et est compatible avec les tâches Fargate traditionnelles. Utilise la jonction ENI pour une densité de tâches élevée. | | `host` | Les tâches partagent directement l’espace de noms réseau de l’hôte. Le réseau de conteneurs est lié à l’instance hôte sous-jacente. | ## Utilisation d'un VPC en mode -only IPv6 Dans une configuration IPv6 uniquement, vos tâches Amazon ECS communiquent exclusivement via IPv6. Pour configurer VPCs des sous-réseaux pour une configuration IPv6 uniquement, vous devez ajouter un bloc d'adresse IPv6 CIDR au VPC et créer des sous-réseaux qui incluent uniquement un bloc d'adresse CIDR. IPv6 Pour plus d'informations, consultez [Ajouter un IPv6 support pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-add.html) et [Créer un sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) dans le guide de l'utilisateur Amazon *VPC*. Vous devez également mettre à jour les tables de routage avec IPv6 les cibles et configurer les groupes de sécurité avec des IPv6 règles. Pour plus d’informations, consultez les sections [Configuration des tables de routage](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) et [Configuration des règles des groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) dans le *Guide de l’utilisateur Amazon VPC*. Les considérations suivantes s'appliquent : + Vous pouvez mettre à jour un service Amazon ECS IPv4 uniquement ou à double pile vers IPv6 une configuration uniquement en mettant à jour le service directement pour IPv6 utiliser des sous-réseaux uniquement ou en créant un service parallèle IPv6 uniquement et en utilisant les déploiements bleu-vert d'Amazon ECS pour transférer le trafic vers le nouveau service. Pour plus d’informations sur les déploiements bleu-vert Amazon ECS, consultez la section [blue/green Déploiements Amazon ECS](deployment-type-blue-green.md). + Un service Amazon ECS IPv6 réservé uniquement doit utiliser des équilibreurs de charge à double pile avec des groupes cibles. IPv6 Si vous procédez à la migration d’un service Amazon ECS existant qui repose sur un Application Load Balancer ou un Network Load Balancer, vous pouvez créer un équilibreur de charge à double pile et lui transférer le trafic depuis l’ancien équilibreur de charge, ou mettre à jour le type d’adresse IP de l’équilibreur de charge existant. Pour plus d’informations sur les Network Load Balancer, consultez les sections [Création d’un Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) et [Mise à jour des types d’adresses IP pour votre Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-ip-address-type.html) dans le *Guide de l’utilisateur des Network Load Balancer*. Pour plus d’informations sur les Application Load Balancer, consultez les sections [Création d’un Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) et [Mise à jour des types d’adresses IP pour votre Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-ip-address-type.html) dans le *Guide de l’utilisateur des Application Load Balancer*. + Pour les tâches Amazon ECS dans une configuration IPv6 uniquement destinées à communiquer avec des points de IPv4 terminaison uniquement, vous pouvez configurer DNS64 et effectuer la traduction NAT64 d'adresses réseau de vers. IPv6 IPv4 Pour plus d'informations, consultez [DNS64 et](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-nat64-dns64.html) consultez NAT64 le guide de l'*utilisateur Amazon VPC*. + Les charges de travail Amazon ECS dans une configuration IPv6 réservée doivent utiliser les points de terminaison d'URI d'image à double pile Amazon ECR lors de l'extraction d'images depuis Amazon ECR. Pour plus d'informations, consultez [Getting started with making requests over IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) dans le *guide de l'utilisateur d'Amazon Elastic Container Registry*. **Note** Amazon ECR ne prend pas en charge les points de terminaison VPC à interface double pile que les tâches d'une configuration réservée peuvent utiliser. IPv6 Pour plus d'informations, consultez [Getting started with making requests over IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) dans le *guide de l'utilisateur d'Amazon Elastic Container Registry*. + Amazon ECS Exec n'est pas pris en charge dans une IPv6 configuration uniquement. # Allocation d’une interface réseau pour les tâches sur les instances gérées Amazon ECS L'utilisation du mode `awsvpc` réseau dans les instances gérées Amazon ECS simplifie la mise en réseau des conteneurs, car vous avez un meilleur contrôle sur la façon dont vos applications communiquent entre elles et avec les autres services au sein de votre entreprise VPCs. Le mode réseau `awsvpc` fournit également une sécurité accrue pour vos conteneurs en vous permettant d’utiliser des groupes de sécurité et des outils de surveillance réseau à un niveau plus détaillé dans les tâches ECS. Par défaut, chaque instance d’instances gérées Amazon ECS possède une interface réseau Elastic (ENI) de jonction attachée lors du lancement en tant qu’ENI principale lorsque le type d’instance prend en charge la jonction. Pour plus d’informations sur les types d’instances qui prennent en charge la jonction ENI, consultez la section [Instances prises en charge pour augmenter le nombre d’interfaces réseau de conteneurs Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/eni-trunking-supported-instance-types.html). **Note** Lorsque le type d'instance choisi ne prend pas en charge le trunk ENIs, l'instance sera lancée avec un ENI normal. Chaque tâche exécutée sur l’instance reçoit sa propre ENI attachée à l’ENI de jonction, avec une adresse IP privée principale. Si votre VPC est configuré pour le mode double pile et que vous utilisez un sous-réseau avec un bloc IPv6 CIDR, l'ENI reçoit également une adresse. IPv6 Lorsque vous utilisez un sous-réseau public, vous pouvez éventuellement attribuer une adresse IP publique à l'ENI principal de l'instance gérée Amazon ECS en activant l'adressage IPv4 public pour le sous-réseau. Pour plus d’informations, consultez la section [Modification des attributs d’adressage IP de votre sous-réseau](https://docs.aws.amazon.com//vpc/latest/userguide/subnet-public-ip.html) dans le *Guide de l’utilisateur Amazon VPC*. Une tâche ne peut avoir qu'une seule ENI associée à la fois. Les conteneurs qui appartiennent à la même tâche peuvent également communiquer via l'interface `localhost`. Pour plus d'informations sur les sous-réseaux VPCs et les sous-réseaux, consultez [Comment fonctionne Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html) dans le guide de l'utilisateur *Amazon VPC* Les opérations suivantes utilisent l’ENI principale attachée à l’instance : + **Téléchargements d’images** : les images des conteneurs sont téléchargées depuis Amazon ECR via l’ENI principale. + **Récupération des secrets** : les secrets et autres informations d’identification de Secrets Manager sont récupérés via l’ENI principale. + **Téléchargements** de journaux - Les journaux sont téléchargés CloudWatch via l'ENI principal. + **Téléchargements de fichiers d’environnement** : les fichiers d’environnement sont téléchargés via l’ENI principale. Le trafic de l’application passe par l’ENI de tâche. Dans la mesure où chaque tâche obtient sa propre ENI, vous pouvez utiliser des fonctionnalités de mise en réseau telles que les journaux de flux VPC, que vous pouvez utiliser pour surveiller le trafic vers et depuis vos tâches. Pour plus d’informations, consultez [Journaux de flux VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) dans le *Guide de l’utilisateur Amazon VPC*. Vous pouvez également en profiter AWS PrivateLink. Vous pouvez configurer un point de terminaison d'interface VPC afin de pouvoir accéder à Amazon ECS APIs via des adresses IP privées. AWS PrivateLink restreint tout le trafic réseau entre votre VPC et Amazon ECS vers le réseau Amazon. Vous n'avez pas besoin d'une passerelle Internet, d'un périphérique NAT ni d'une passerelle privée virtuelle. Pour plus d’informations, consultez la section [Points de terminaison de VPC d’interface Amazon ECS (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html). Le mode `awsvpc` réseau vous permet également de tirer parti d'Amazon VPC Traffic Mirroring à des fins de sécurité et de surveillance du trafic réseau lorsque vous utilisez des types d'instances auxquels aucune liaison de jonction n'est attachée. ENIs Pour plus d’informations, consultez la section [Qu’est-ce que la mise en miroir du trafic ?](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) dans le *Guide de mise en miroir du trafic Amazon VPC*. ## Considérations relatives au mode `awsvpc` + Les tâches nécessitent le rôle lié au service Amazon ECS pour la gestion ENI. Ce rôle est automatiquement créé lorsque vous créez un cluster ou un service. + ENIs Les tâches sont gérées par Amazon ECS et ne peuvent pas être détachées ou modifiées manuellement. + L’attribution d’une adresse IP publique à l’ENI de tâche à l’aide de `assignPublicIp` lors de l’exécution d’une tâche autonome (`RunTask`) ou de la création ou de la mise à jour d’un service (`CreateService`/`UpdateService`) n’est pas prise en charge. + Lorsque vous configurez le réseau `awsvpc` au niveau des tâches, vous devez utiliser le même VPC que celui que vous avez spécifié dans le modèle de lancement du fournisseur de capacité d’instances gérées Amazon ECS. Vous pouvez utiliser des sous-réseaux et des groupes de sécurité différents de ceux spécifiés dans le modèle de lancement. + Pour les tâches en mode réseau `awsvpc`, utilisez le type de cible `ip` lors de la configuration des groupes cibles de l’équilibreur de charge. Amazon ECS gère automatiquement l’enregistrement des groupes cibles pour les modes réseau pris en charge. ## Utilisation d'un VPC en mode double pile Lorsque vous utilisez un VPC en mode double pile, vos tâches peuvent communiquer par ou IPv6 par IPv4 les deux. IPv4 et IPv6 les adresses sont indépendantes les unes des autres. Vous devez donc configurer le routage et la sécurité dans votre VPC séparément pour IPv4 et. IPv6 Pour plus d'informations sur la configuration de votre VPC pour le mode double pile, consultez la section [Migration vers le guide de l'utilisateur IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) Amazon *VPC*. Si vous avez configuré votre VPC avec une passerelle Internet ou une passerelle Internet sortante uniquement, vous pouvez utiliser votre VPC en mode double pile. Ainsi, les tâches auxquelles une IPv6 adresse est attribuée peuvent accéder à Internet via une passerelle Internet ou une passerelle Internet de sortie uniquement. Les passerelles NAT sont facultatives. Pour plus d'informations, veuillez consulter les rubriques [Passerelles Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) et [Passerelle Internet en sortie uniquement](https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html) dans le *Guide de l'utilisateur Amazon VPC*. Une IPv6 adresse est attribuée aux tâches Amazon ECS si les conditions suivantes sont remplies : + L’instance gérée Amazon ECS qui héberge la tâche utilise la version `1.45.0` ou une version ultérieure de l’agent de conteneur. Pour plus d'informations sur la vérification de la version de l'agent utilisée par votre instance et la mise à jour si nécessaire, veuillez consulter [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md). + Le paramètre de compte `dualStackIPv6` est activé. Pour de plus amples informations, veuillez consulter [Accès aux fonctionnalités d’Amazon ECS avec les paramètres du compte](ecs-account-settings.md). + Votre tâche utilise le mode réseau `awsvpc`. + Votre VPC et votre sous-réseau sont configurés pour. IPv6 La configuration inclut les interfaces réseau créées dans le sous-réseau spécifié. Pour plus d'informations sur la configuration de votre VPC pour le mode double pile, consultez la section [Migration vers IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) et [modification de l'attribut d' IPv6 adressage de votre sous-réseau dans le guide de l'utilisateur](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-ipv6) *Amazon* VPC. # Mode réseau hôte En mode `host`, les tâches partagent directement l’espace de noms réseau de l’hôte. La configuration réseau du conteneur est liée à l’instance hôte des instances gérées Amazon ECS sous-jacente que vous spécifiez à l’aide du paramètre `networkConfiguration` lorsque vous créez un fournisseur de capacité d’instances gérées Amazon ECS.`` L'utilisation de ce mode réseau présente des inconvénients importants. Vous ne pouvez exécuter qu'une seule instanciation d'une tâche sur chaque hôte. Cela est dû au fait que seule la première tâche peut se lier au port requis sur l'instance Amazon EC2. Il est également impossible de remapper un port de conteneur lorsqu'il utilise le mode réseau `host`. Par exemple, si une application doit écouter un numéro de port spécifique, vous ne pouvez pas remapper le numéro de port directement. Vous devez plutôt gérer les conflits de ports en modifiant la configuration de l'application. L'utilisation du mode réseau `host` a également des implications en termes de sécurité. Ce mode permet aux conteneurs de se faire passer pour l'hôte et de se connecter à des services réseau privés en boucle sur l'hôte. N’utilisez le mode hôte que lorsque vous avez besoin d’un accès direct au réseau hôte ou lors de la migration d’applications nécessitant un accès réseau au niveau de l’hôte. # Options de mise en réseau des tâches Amazon ECS pour EC2 Le comportement de mise en réseau des tâches Amazon ECS hébergées sur des instances Amazon EC2 dépend du *mode réseau* défini dans la définition de tâche. Nous vous recommandons d'utiliser le mode réseau `awsvpc`, à moins que vous n'ayez besoin d'utiliser un mode réseau différent. Les modes réseau disponibles sont les suivants. | Mode réseau | Conteneurs Linux sur EC2 | Conteneurs Windows sur EC2 | Description | | --- | --- | --- | --- | | `awsvpc` | Oui | Oui | La tâche reçoit sa propre interface réseau Elastic (ENI) et une adresse IPv4 ou IPv6 privée principale. Cela confère à la tâche les mêmes propriétés de réseaux que les instances Amazon EC2. | | `bridge` | Oui | Non | La tâche utilise le réseau virtuel intégré de Docker sous Linux, qui s'exécute à l'intérieur de chaque instance Amazon EC2 hébergeant la tâche. Le réseau virtuel intégré sous Linux utilise le pilote réseau Docker `bridge`. Ceci est le mode réseau par défaut sous Linux si aucun mode réseau n'est spécifié dans la définition de la tâche. | | `host` | Oui | Non | La tâche utilise le réseau de l'hôte qui contourne le réseau virtuel intégré de Docker en mappant les ports de conteneur directement à l'ENI de l'instance Amazon EC2 qui héberge la tâche. Les mappages de ports dynamiques ne peuvent pas être utilisés dans ce mode réseau. Dans une définition de tâche qui utilise ce mode, un conteneur doit spécifier un numéro `hostPort` spécifique. Un numéro de port sur un hôte ne peut pas être utilisé par plusieurs tâches. Dans ce mode, vous ne pouvez pas exécuter plusieurs tâches de la même définition de tâche sur une instance Amazon EC2 unique. | | `none` | Oui | Non | La tâche n'a pas de connectivité réseau externe. | | `default` | Non | Oui | La tâche utilise le réseau virtuel intégré de Docker sous Windows, qui s'exécute à l'intérieur de chaque instance Amazon EC2 hébergeant la tâche. Le réseau virtuel intégré sous Windows utilise le pilote réseau Docker `nat`. Ceci est le mode réseau par défaut sous Windows si aucun mode réseau n'est spécifié dans la définition de la tâche. | Pour plus d’informations sur la mise en réseau Docker sous Linux, consultez la section [Présentation de la mise en réseau](https://docs.docker.com/engine/network/) dans la *Documentation Docker*. Pour plus d’informations sur la mise en réseau Docker sous Windows, consultez la section [Mise en réseau des conteneurs Windows](https://learn.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture) dans la *Documentation relative aux conteneurs sous Windows* de Microsoft. ## Utilisation d'un VPC en mode -only IPv6 Dans une configuration IPv6 uniquement, vos tâches Amazon ECS communiquent exclusivement via IPv6. Pour configurer VPCs des sous-réseaux pour une configuration IPv6 uniquement, vous devez ajouter un bloc d'adresse IPv6 CIDR au VPC et créer de nouveaux sous-réseaux qui incluent uniquement un bloc d'adresse CIDR. IPv6 Pour plus d'informations, consultez [Ajouter un IPv6 support pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-add.html) et [Créer un sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) dans le guide de l'utilisateur Amazon *VPC*. Vous devez également mettre à jour les tables de routage avec IPv6 les cibles et configurer les groupes de sécurité avec des IPv6 règles. Pour plus d’informations, consultez les sections [Configuration des tables de routage](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) et [Configuration des règles des groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) dans le *Guide de l’utilisateur Amazon VPC*. Les considérations suivantes s'appliquent : + Vous pouvez mettre à jour un service Amazon ECS IPv4 uniquement ou à double pile vers IPv6 une configuration uniquement en mettant à jour le service directement pour IPv6 utiliser des sous-réseaux uniquement ou en créant un service parallèle IPv6 uniquement et en utilisant les déploiements bleu-vert d'Amazon ECS pour transférer le trafic vers le nouveau service. Pour plus d’informations sur les déploiements bleu-vert Amazon ECS, consultez la section [blue/green Déploiements Amazon ECS](deployment-type-blue-green.md). + Un service Amazon ECS IPv6 réservé uniquement doit utiliser des équilibreurs de charge à double pile avec des groupes cibles. IPv6 Si vous procédez à la migration d’un service Amazon ECS existant qui repose sur un Application Load Balancer ou un Network Load Balancer, vous pouvez créer un équilibreur de charge à double pile et lui transférer le trafic depuis l’ancien équilibreur de charge, ou mettre à jour le type d’adresse IP de l’équilibreur de charge existant. Pour plus d’informations sur les Network Load Balancer, consultez les sections [Création d’un Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) et [Mise à jour des types d’adresses IP pour votre Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-ip-address-type.html) dans le *Guide de l’utilisateur des Network Load Balancer*. Pour plus d’informations sur les Application Load Balancer, consultez les sections [Création d’un Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) et [Mise à jour des types d’adresses IP pour votre Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-ip-address-type.html) dans le *Guide de l’utilisateur des Application Load Balancer*. + IPv6la configuration -only n'est pas prise en charge surWindows. Vous devez utiliser Linux optimisé pour Amazon ECS AMIs pour exécuter des tâches dans une configuration uniquement IPv6. Pour plus d'informations sur Linux optimisé pour Amazon ECS AMIs, consultez. [Linux optimisé pour Amazon ECS AMIs](ecs-optimized_AMI.md) + Lorsque vous lancez une instance de conteneur pour exécuter des tâches dans une configuration IPv6 uniquement, vous devez définir une IPv6 adresse principale pour l'instance à l'aide du paramètre `--enable-primary-ipv6` EC2. **Note** Sans IPv6 adresse principale, les tâches exécutées sur l'instance de conteneur en mode réseau hôte ou pont ne pourront pas être enregistrées auprès des équilibreurs de charge ou auprès AWS Cloud Map de. Pour plus d’informations sur l’option `--enable-primary-ipv6` pour l’exécution d’instances Amazon EC2, consultez la section [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) dans la *Référence des commandes AWS CLI *. Pour plus d'informations sur le lancement d'instances de conteneur à l'aide du AWS Management Console, consultez[Lancement d'une instance de conteneur Amazon ECS Linux](launch_container_instance.md). + Par défaut, l'agent de conteneur Amazon ECS essaiera de détecter la compatibilité de l'instance de conteneur pour une configuration réservée à une configuration IPv6 uniquement en examinant la valeur par défaut IPv4 et IPv6 les itinéraires de l'instance. Pour annuler ce comportement, vous pouvez définir le paramètre ` ECS_INSTANCE_IP_COMPATIBILITY` sur `ipv4` ou `ipv6` dans le fichier `/etc/ecs/ecs.config` de l’instance. + Les tâches doivent utiliser la version `1.99.1` ou une version ultérieure de l’agent de conteneur. Pour plus d’informations sur la vérification de la version de l’agent utilisée par votre instance et la mise à jour si nécessaire, consultez la section [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md). + Pour les tâches Amazon ECS dans une configuration IPv6 uniquement destinées à communiquer avec des points de IPv4 terminaison uniquement, vous pouvez configurer DNS64 et effectuer la traduction NAT64 d'adresses réseau de vers. IPv6 IPv4 Pour plus d'informations, consultez [DNS64 et](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-nat64-dns64.html) consultez NAT64 le guide de l'*utilisateur Amazon VPC*. + Les charges de travail Amazon ECS dans une configuration IPv6 réservée doivent utiliser les points de terminaison d'URI d'image à double pile Amazon ECR lors de l'extraction d'images depuis Amazon ECR. Pour plus d'informations, consultez [Getting started with making requests over IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) dans le *guide de l'utilisateur d'Amazon Elastic Container Registry*. **Note** Amazon ECR ne prend pas en charge les points de terminaison VPC à interface double pile que les tâches d'une configuration réservée peuvent utiliser. IPv6 Pour plus d'informations, consultez [Getting started with making requests over IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) dans le *guide de l'utilisateur d'Amazon Elastic Container Registry*. + Amazon ECS Exec n'est pas pris en charge dans une IPv6 configuration uniquement. ### Régions AWS qui prennent en charge le mode IPv6 uniquement pour Amazon ECS Vous pouvez exécuter des tâches dans une configuration IPv6 réservée aux AWS régions suivantes dans lesquelles Amazon ECS est disponible : + USA Est (Ohio) + USA Est (Virginie du Nord) + USA Ouest (Californie du Nord) + USA Ouest (Oregon) + Afrique (Le Cap) + Asie-Pacifique (Hong Kong) + Asie-Pacifique (Hyderabad) + Asie-Pacifique (Jakarta) + Asie-Pacifique (Melbourne) + Asie-Pacifique (Mumbai) + Asie-Pacifique (Osaka) + Asia Pacific (Seoul) + Asie-Pacifique (Singapour) + Asie-Pacifique (Sydney) + Asie-Pacifique (Tokyo) + Canada (Centre) + Canada Ouest (Calgary) + Chine (Pékin) + China (Ningxia) + Europe (Francfort) + Europe (Londres) + Europe (Milan) + Europe (Paris) + Europe (Espagne) + Israël (Tel Aviv) + Middle East (Bahrain) + Moyen-Orient (EAU) + Amérique du Sud (São Paulo) + AWS GovCloud (USA Est) + AWS GovCloud (US-Ouest) # Allocation d’une interface réseau à une tâche Amazon ECS Les fonctions de mise en réseau des tâches fournies par le mode réseau `awsvpc` attribuent aux tâches Amazon ECS les mêmes propriétés de mise en réseau que les instances Amazon EC2. L'utilisation du mode `awsvpc` réseau simplifie la mise en réseau des conteneurs, car vous avez un meilleur contrôle sur la façon dont vos applications communiquent entre elles et avec les autres services au sein de votre entreprise VPCs. Le mode réseau `awsvpc` fournit également une sécurité accrue pour vos conteneurs en vous permettant d’utiliser des groupes de sécurité et des outils de surveillance réseau à un niveau plus détaillé dans les tâches ECS. Vous pouvez également utiliser d’autres fonctionnalités réseau Amazon EC2, telles que les journaux de flux VPC, pour surveiller le trafic entrant et sortant de vos tâches. De plus, les conteneurs qui appartiennent à la même tâche peuvent communiquer via l'interface `localhost`. L’interface réseau Elastic (ENI) est une fonctionnalité entièrement gérée d’Amazon ECS. Amazon ECS crée l'ENI et l'attache à l'instance Amazon EC2 hôte avec le groupe de sécurité spécifié. La tâche envoie et reçoit le trafic réseau sur l'ENI de la même manière que les instances Amazon EC2 avec leurs interfaces réseau principales. Une IPv4 adresse privée est attribuée par défaut à chaque tâche ENI. Si votre VPC est activé pour le mode double pile et que vous utilisez un sous-réseau avec un bloc IPv6 CIDR, la tâche ENI recevra également une adresse. IPv6 Chaque tâche ne peut avoir qu'une seule ENI. Ces ENI sont visibles dans la console Amazon EC2 de votre compte. Votre compte ne peut pas détacher ou modifier le ENIs. L'objectif est d'empêcher la suppression accidentelle de toute ENI associée à une tâche en cours d'exécution. Vous pouvez consulter les informations de pièce jointe ENI pour les tâches dans la console Amazon ECS ou lors du fonctionnement de l'[DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html)API. Lorsque la tâche s'arrête ou si le service est réduit, l'ENI de la tâche est détachée et supprimée. Lorsque vous avez besoin d’une densité ENI accrue, utilisez les paramètres du compte `awsvpcTrunking`. Amazon ECS crée et attache également une interface réseau « de jonction » pour votre instance de conteneur. Le réseau « de jonction » est entièrement géré par Amazon ECS. L'ENI « de jonction » est supprimée lorsque vous résiliez votre instance de conteneur ou lorsque vous annulez son enregistrement dans le cluster Amazon ECS. Pour plus d’informations sur le paramètre de compte `awsvpcTrunking`, consultez la section [Conditions préalables](container-instance-eni.md#eni-trunking-launching). Vous le spécifiez `awsvpc` dans le paramètre `networkMode` de la définition de tâche. Pour de plus amples informations, veuillez consulter [Mode réseau](task_definition_parameters.md#network_mode). Ensuite, lorsque vous exécutez une tâche ou créez un service, utilisez le paramètre `networkConfiguration` qui comprend un ou plusieurs sous-réseaux dans lesquels placer vos tâches et un ou plusieurs groupes de sécurité à attacher à une ENI. Pour de plus amples informations, veuillez consulter [Configuration réseau](service_definition_parameters.md#sd-networkconfiguration). Les tâches sont placées sur des instances Amazon EC2 compatibles dans les mêmes zones de disponibilité que ces sous-réseaux et les groupes de sécurité spécifiés sont associés à l'ENI qui est allouée pour la tâche. ## Considérations relatives à Linux Tenez compte des éléments suivants lorsque vous utilisez le système d'exploitation Linux. + Si vous utilisez une instance p5.48xlarge en mode `awsvpc`, vous ne pouvez pas exécuter plus d’une tâche sur l’instance. + Les tâches et les services qui utilisent le mode `awsvpc` réseau nécessitent le rôle lié au service Amazon ECS pour fournir à Amazon ECS les autorisations nécessaires pour passer des appels vers d'autres AWS services en votre nom. Ce rôle est généré automatiquement lorsque vous créez un cluster, ou si vous créez ou mettez à jour un service dans la AWS Management Console. Pour de plus amples informations, veuillez consulter [Utilisation des rôles liés à un service pour Amazon ECS](using-service-linked-roles.md). Vous pouvez également créer le rôle lié à un service à l'aide de la commande suivante : 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 ``` + Votre instance Linux Amazon EC2 Linux nécessite une version `1.15.0` ou une version ultérieure de l'agent de conteneur pour exécuter des tâches qui utilisent le mode réseau `awsvpc`. Si vous utilisez l'AMI Linux optimisée pour Amazon ECS, votre instance doit également au moins disposer de la version `1.15.0-4` du package `ecs-init`. + Amazon ECS remplit le nom d'hôte d'une tâche avec un nom d'hôte DNS (interne) fourni par Amazon lorsque les options `enableDnsHostnames` et `enableDnsSupport` sont toutes deux activées sur votre VPC. Si ces options ne sont pas activées, le nom d'hôte DNS de la tâche est un nom d'hôte aléatoire. Pour plus d'informations sur les paramètres DNS d'un VPC, veuillez consulter la rubrique [Utilisation de DNS avec votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) dans le *Guide de l'utilisateur Amazon VPC*. + Les tâches Amazon ECS qui utilisent le mode réseau `awsvpc` reçoivent chacune leur propre interface réseau Elastic (ENI), qui est attachée à l'instance Amazon EC2 qui l'héberge. Il existe un quota par défaut pour le nombre d'interfaces réseau qui peuvent être attachées à une instance Amazon EC2 Linux. L'interface réseau principale est considérée comme une seule pour ce quota. Par exemple, par défaut, une `c5.large` instance peut n'en avoir ENIs que trois qui peuvent être attachées. L'interface réseau principale de l'instance est considérée comme une interface réseau. Vous pouvez en attacher deux autres ENIs à l'instance. Dans la mesure où chaque tâche utilisant le mode réseau `awsvpc` nécessite une ENI, vous ne pouvez généralement exécuter que deux tâches sur ce type d'instance. Pour de plus amples informations sur les limites d’ENI par défaut pour chaque type d’instance, consultez la section [Adresses IP privées par interface réseau et par type d’instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI) dans le *Guide de l’utilisateur Amazon EC2*. + Amazon ECS prend en charge le lancement d'instances Amazon EC2 Linux avec une augmentation de la densité ENI et utilisant des types d'instances pris en charge. Lorsque vous activez le paramètre de compte `awsvpcTrunking` et enregistrez les instances Linux Amazon EC2 à l'aide de ces types d'instance dans votre cluster, ces instances ont des quotas ENI plus élevés. L'utilisation de ces instances avec ce quota plus élevé signifie que vous pouvez placer davantage de tâches sur chaque instance Amazon EC2 Linux. Pour utiliser une densité ENI supérieure avec la fonctionnalité de jonction, vos instances Amazon EC2 doivent utiliser la version `1.28.1` ou ultérieure de l'agent de conteneur. Si vous utilisez une AMI optimisée pour Amazon ECS, votre instance doit également au moins disposer de la version `1.28.1-2` du package `ecs-init`. Pour en savoir plus sur l'acceptation du paramètre de compte `awsvpcTrunking`, consultez [Accès aux fonctionnalités d’Amazon ECS avec les paramètres du compte](ecs-account-settings.md). Pour en savoir plus sur la jonction ENI, consultez [Augmentation des interfaces réseau d’une instance de conteneur Amazon ECS Linux](container-instance-eni.md). + Lorsque vous hébergez des tâches utilisant le mode `awsvpc` réseau sur des instances Linux Amazon EC2, aucune adresse IP publique ENIs n'est attribuée à votre tâche. Pour accéder à Internet, les tâches doivent être lancées dans un sous-réseau privé configuré pour utiliser une passerelle NAT. Pour plus d’informations, veuillez consulter [NAT Gateways (Passerelles NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) dans le *Guide de l’utilisateur Amazon VPC*. L'accès entrant au réseau doit se faire depuis un VPC avec l'adresse IP privée ou doit transiter par un équilibreur de charge au sein du VPC. Les tâches lancées dans les sous-réseaux publics n'ont pas accès à Internet. + Amazon ECS reconnaît uniquement les ENI qu'il attache à vos instances Amazon EC2 Linux. Si vous vous connectez manuellement ENIs à vos instances, Amazon ECS peut tenter d'ajouter une tâche à une instance qui ne dispose pas de suffisamment d'adaptateurs réseau. Cela peut entraîner l'expiration de la tâche et le passage à un état de déprovisionnement, puis à un état d'arrêt. Nous vous recommandons de ne pas vous connecter manuellement ENIs à vos instances. + Les instances Amazon EC2 Linux doivent être enregistrées avec la capacité `ecs.capability.task-eni` pour pouvoir faire l'objet d'un placement des tâches avec le mode réseau `awsvpc`. Les instances exécutant la version `1.15.0-4` ou une version ultérieure d'`ecs-init` sont automatiquement enregistrées avec cet attribut. + Les ENI créées et attachées à vos instances Amazon EC2 Linux ne peuvent pas être détachées manuellement ni modifiées par votre compte. L'objectif est d'empêcher la suppression accidentelle de toute ENI associée à une tâche en cours d'exécution. Pour libérer le ENIs pour une tâche, arrêtez la tâche. + Il existe une limite de 16 sous-réseaux et 5 groupes de sécurité pouvant être spécifiés dans `awsVpcConfiguration` lors de l'exécution d'une tâche ou de la création d'un service qui utilise le mode réseau `awsvpc`. Pour plus d'informations, consultez le [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html)manuel *Amazon Elastic Container Service API Reference*. + Lorsqu'une tâche est démarrée avec le mode réseau `awsvpc`, l'agent de conteneur Amazon ECS crée un conteneur `pause` supplémentaire pour chaque tâche avant de démarrer les conteneurs dans la définition de tâche. Il configure ensuite l'espace de noms réseau du `pause` conteneur en exécutant les plugins [amazon-ecs-cni-plugins ](https://github.com/aws/amazon-ecs-cni-plugins)CNI. L'agent démarre ensuite le reste des conteneurs dans la tâche afin qu'ils partagent la pile réseau du conteneur `pause`. Cela signifie que tous les conteneurs d'une tâche peuvent être adressés par les adresses IP de l'ENI et qu'ils peuvent communiquer entre eux via l'interface `localhost`. + Les services avec des tâches qui utilisent le mode réseau `awsvpc` prennent uniquement en charge Application Load Balancer et Network Load Balancer. Lorsque vous créez des groupes cibles pour ces services, vous devez choisir `ip` comme type de cible. N'utilisez pas  `instance`. En effet, les tâches qui utilisent le mode réseau `awsvpc` sont associées à une ENI, et non à une instance Amazon EC2 Linux. Pour de plus amples informations, veuillez consulter [Utilisation de l’équilibrage de charge pour répartir le trafic des services Amazon ECS](service-load-balancing.md). + Si votre VPC est mis à jour pour modifier le jeu d'options DHCP qu'il utilise, vous ne pouvez pas appliquer ces modifications aux tâches existantes. Commencez de nouvelles tâches en leur appliquant ces modifications, vérifiez qu'elles fonctionnent correctement, puis arrêtez les tâches existantes afin de modifier ces configurations réseau en toute sécurité. ## Considérations relatives à Windows Voici quelques points à prendre en compte lorsque vous utilisez le système d'exploitation Windows : + Les instances de conteneur utilisant l'AMI Windows Server 2016 optimisée pour Amazon ECS ne peuvent pas héberger des tâches qui utilisent le mode réseau `awsvpc`. Si vous avez un cluster contenant Windows Server 2016 optimisé pour Amazon ECS AMIs et Windows AMIs prenant en charge le mode `awsvpc` réseau, les tâches utilisant le mode `awsvpc` réseau ne sont pas lancées sur les instances de Windows 2016 Server. Elles sont plutôt lancées sur des instances qui prennent en charge le mode réseau `awsvpc`. + Votre instance Windows Amazon EC2 nécessite une version `1.57.1` ou une version ultérieure de l'agent de conteneur pour utiliser CloudWatch les métriques pour les conteneurs Windows qui utilisent le mode `awsvpc` réseau. + Les tâches et les services qui utilisent le mode `awsvpc` réseau nécessitent le rôle lié au service Amazon ECS pour fournir à Amazon ECS les autorisations nécessaires pour passer des appels vers d'autres AWS services en votre nom. Ce rôle est généré automatiquement lorsque vous créez un cluster, ou si vous créez ou mettez à jour un service dans AWS Management Console. Pour de plus amples informations, veuillez consulter [Utilisation des rôles liés à un service pour Amazon ECS](using-service-linked-roles.md). Vous pouvez également créer le rôle lié à un service à l'aide de la commande suivante 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 ``` + Votre instance Amazon EC2 Windows nécessite une version `1.54.0` ou une version ultérieure de l'agent de conteneur pour exécuter des tâches qui utilisent le mode réseau `awsvpc`. Lorsque vous amorcez l'instance, vous devez configurer les options requises pour le mode réseau `awsvpc`. Pour de plus amples informations, veuillez consulter [Amorçage des instances de conteneurs Windows Amazon ECS pour transmettre des données](bootstrap_windows_container_instance.md). + Amazon ECS remplit le nom d'hôte d'une tâche avec un nom d'hôte DNS (interne) fourni par Amazon lorsque les options `enableDnsHostnames` et `enableDnsSupport` sont toutes deux activées sur votre VPC. Si ces options ne sont pas activées, le nom d'hôte DNS de la tâche est un nom d'hôte aléatoire. Pour plus d'informations sur les paramètres DNS d'un VPC, veuillez consulter la rubrique [Utilisation de DNS avec votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) dans le *Guide de l'utilisateur Amazon VPC*. + Les tâches Amazon ECS qui utilisent le mode réseau `awsvpc` reçoivent chacune leur propre interface réseau Elastic (ENI), qui est attachée à l'instance Amazon EC2 Windows qui l'héberge. Il existe un quota par défaut pour le nombre d'interfaces réseau pouvant être attachées à une instance Amazon EC2 Windows. L'interface réseau principale est considérée comme une seule pour ce quota. Par exemple, par défaut, une `c5.large` instance peut n'avoir que trois pièces ENIs associées. L'interface réseau principale de l'instance compte parmi celles-ci. Vous pouvez en attacher deux autres ENIs à l'instance. Dans la mesure où chaque tâche utilisant le mode réseau `awsvpc` nécessite une ENI, vous ne pouvez généralement exécuter que deux tâches sur ce type d'instance. Pour de plus amples informations sur les limites d’ENI par défaut pour chaque type d’instance, consultez la section [Adresses IP privées par interface réseau et par type d’instance](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI) dans le *Guide de l’utilisateur Amazon EC2*. + Lorsque vous hébergez des tâches utilisant le mode `awsvpc` réseau sur des instances Windows Amazon EC2, aucune adresse IP publique ENIs n'est attribuée à votre tâche. Pour accéder à Internet, lancez les tâches dans un sous-réseau privé configuré pour utiliser une passerelle NAT. Pour plus d’informations, veuillez consulter [NAT Gateways (Passerelles NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) dans le *Guide de l’utilisateur Amazon VPC*. L'accès entrant au réseau doit se faire depuis le VPC avec l'adresse IP privée ou doit transiter par un équilibreur de charge au sein du VPC. Les tâches lancées dans les sous-réseaux publics n'ont pas accès à Internet. + Amazon ECS reconnaît uniquement les ENI qu'il a attachées à votre instance Windows Amazon EC2. Si vous vous connectez manuellement ENIs à vos instances, Amazon ECS peut tenter d'ajouter une tâche à une instance qui ne dispose pas de suffisamment d'adaptateurs réseau. Cela peut entraîner l'expiration de la tâche et le passage à un état de déprovisionnement, puis à un état d'arrêt. Nous vous recommandons de ne pas vous connecter manuellement ENIs à vos instances. + Les instances Amazon EC2 Windows doivent être enregistrées avec l'interface réseau `ecs.capability.task-eni` pour pouvoir faire l'objet d'un placement des tâches avec le mode réseau `awsvpc`. + Vous ne pouvez pas modifier ou détacher manuellement les ENI créées et attachées à vos instances Windows Amazon EC2. Cela vous évite de supprimer accidentellement une ENI associée à une tâche en cours d'exécution. Pour libérer le ENIs pour une tâche, arrêtez la tâche. + Vous pouvez uniquement spécifier jusqu'à 16 sous-réseaux et 5 groupes de sécurité dans `awsVpcConfiguration`, lorsque vous exécutez une tâche ou créez un service qui utilise le mode réseau `awsvpc`. Pour plus d'informations, consultez le [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html)manuel *Amazon Elastic Container Service API Reference*. + Lorsqu'une tâche est démarrée avec le mode réseau `awsvpc`, l'agent de conteneur Amazon ECS crée un conteneur `pause` supplémentaire pour chaque tâche avant de démarrer les conteneurs dans la définition de tâche. Il configure ensuite l'espace de noms réseau du `pause` conteneur en exécutant les plugins [amazon-ecs-cni-plugins ](https://github.com/aws/amazon-ecs-cni-plugins)CNI. L'agent démarre ensuite le reste des conteneurs dans la tâche afin qu'ils partagent la pile réseau du conteneur `pause`. Cela signifie que tous les conteneurs d'une tâche peuvent être adressés par les adresses IP de l'ENI et qu'ils peuvent communiquer entre eux via l'interface `localhost`. + Les services avec des tâches qui utilisent le mode réseau `awsvpc` prennent uniquement en charge Application Load Balancer et Network Load Balancer. Lorsque vous créez des groupes cibles pour ces services, vous devez choisir le type de cible `ip`, et non `instance`. En effet, les tâches qui utilisent le mode réseau `awsvpc` sont associées à une ENI, et non à une instance Amazon EC2 Windows. Pour de plus amples informations, veuillez consulter [Utilisation de l’équilibrage de charge pour répartir le trafic des services Amazon ECS](service-load-balancing.md). + Si votre VPC est mis à jour pour modifier le jeu d'options DHCP qu'il utilise, vous ne pouvez pas appliquer ces modifications aux tâches existantes. Commencez de nouvelles tâches en leur appliquant ces modifications, vérifiez qu'elles fonctionnent correctement, puis arrêtez les tâches existantes afin de modifier ces configurations réseau en toute sécurité. + Les éléments suivants ne sont pas pris en charge lorsque vous utilisez le mode réseau `awsvpc` dans une configuration Windows EC2 : + Configuration à double pile + IPv6 + Jonction ENI ## Utilisation d'un VPC en mode double pile Lorsque vous utilisez un VPC en mode double pile, vos tâches peuvent communiquer par ou IPv6 par IPv4 les deux. IPv4 et IPv6 les adresses sont indépendantes les unes des autres. Vous devez donc configurer le routage et la sécurité dans votre VPC séparément pour IPv4 et. IPv6 Pour plus d'informations sur la configuration de votre VPC pour le mode double pile, consultez la section [Migration vers le guide de l'utilisateur IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) Amazon *VPC*. Si vous avez configuré votre VPC avec une passerelle Internet ou une passerelle Internet sortante uniquement, vous pouvez utiliser votre VPC en mode double pile. Ainsi, les tâches auxquelles une IPv6 adresse est attribuée peuvent accéder à Internet via une passerelle Internet ou une passerelle Internet de sortie uniquement. Les passerelles NAT sont facultatives. Pour plus d'informations, veuillez consulter les rubriques [Passerelles Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) et [Passerelle Internet en sortie uniquement](https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html) dans le *Guide de l'utilisateur Amazon VPC*. Une IPv6 adresse est attribuée aux tâches Amazon ECS si les conditions suivantes sont remplies : + L'instance Linux Amazon EC2 hébergeant la tâche utilise la version `1.45.0` ou version ultérieure de l'agent de conteneur. Pour plus d'informations sur la vérification de la version de l'agent utilisée par votre instance et la mise à jour si nécessaire, veuillez consulter [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md). + Le paramètre de compte `dualStackIPv6` est activé. Pour de plus amples informations, veuillez consulter [Accès aux fonctionnalités d’Amazon ECS avec les paramètres du compte](ecs-account-settings.md). + Votre tâche utilise le mode réseau `awsvpc`. + Votre VPC et votre sous-réseau sont configurés pour. IPv6 La configuration inclut les interfaces réseau créées dans le sous-réseau spécifié. Pour plus d'informations sur la configuration de votre VPC pour le mode double pile, consultez la section [Migration vers IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) et [modification de l'attribut d'IPv6 adressage de votre sous-réseau dans le guide de l'utilisateur](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-ipv6) *Amazon* VPC. # Mappage des ports de conteneurs Amazon ECS vers l’interface réseau de l’instance EC2 Le mode réseau `host` est uniquement pris en charge pour les tâches Amazon ECS hébergées sur des instances Amazon EC2. Il n'est pas pris en charge lors de l'utilisation d'Amazon ECS sur Fargate. Le mode réseau `host` est le mode réseau le plus basique pris en charge dans Amazon ECS. En mode hôte, la mise en réseau du conteneur est liée directement à l'hôte sous-jacent qui exécute le conteneur. ![\[Schéma illustrant l'architecture d'un réseau avec des conteneurs utilisant le mode réseau hôte.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/networkmode-host.png) Supposons que vous exécutez un conteneur Node.js avec une application Express qui écoute sur un port `3000` similaire à celui illustré dans le schéma précédent. Lorsque le mode réseau `host` est utilisé, le conteneur reçoit le trafic sur le port 3 000 en utilisant l'adresse IP de l'instance Amazon EC2 de l'hôte sous-jacent. Nous vous recommandons de ne pas utiliser ce mode. L'utilisation de ce mode réseau présente des inconvénients importants. Vous ne pouvez exécuter qu'une seule instanciation d'une tâche sur chaque hôte. Cela est dû au fait que seule la première tâche peut se lier au port requis sur l'instance Amazon EC2. Il est également impossible de remapper un port de conteneur lorsqu'il utilise le mode réseau `host`. Par exemple, si une application doit écouter un numéro de port spécifique, vous ne pouvez pas remapper le numéro de port directement. Vous devez plutôt gérer les conflits de ports en modifiant la configuration de l'application. L'utilisation du mode réseau `host` a également des implications en termes de sécurité. Ce mode permet aux conteneurs de se faire passer pour l'hôte et de se connecter à des services réseau privés en boucle sur l'hôte. # Utilisation du réseau virtuel de Docker pour les tâches Amazon ECS Linux Le mode réseau `bridge` est uniquement pris en charge pour les tâches Amazon ECS hébergées sur des instances Amazon EC2. Avec le mode `bridge`, vous utilisez un pont réseau virtuel pour créer une couche entre l'hôte et la mise en réseau du conteneur. De cette façon, vous pouvez créer des mappages de ports qui remappent un port hôte à un port de conteneur. Les mappages peuvent être statiques ou dynamiques. ![\[Schéma illustrant l'architecture d'un réseau utilisant le mode réseau pont avec mappage statique des ports.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/networkmode-bridge.png) Avec un mappage statique des ports, vous pouvez définir explicitement le port hôte que vous souhaitez mapper à un port de conteneur. À l'aide de l'exemple ci-dessus, le port `80` de l'hôte est mappé au port `3000` du conteneur. Pour communiquer avec l'application conteneurisée, vous envoyez le trafic au port `80` vers l'adresse IP de l'instance Amazon EC2. Du point de vue de l'application conteneurisée, le trafic entrant est visible sur le port `3000`. Si vous souhaitez uniquement modifier le port de trafic, les mappages statiques de ports conviennent. Cependant, cela présente toujours le même inconvénient que l'utilisation du mode réseau `host`. Vous ne pouvez exécuter qu'une seule instanciation d'une tâche sur chaque hôte. Cela est dû au fait qu'un mappage statique de port ne permet de mapper qu'un seul conteneur sur le port 80. Pour résoudre ce problème, pensez à utiliser le mode réseau `bridge` avec un mappage dynamique des ports, comme indiqué dans le schéma suivant. ![\[Schéma illustrant l'architecture d'un réseau utilisant le mode réseau pont avec mappage dynamique des ports.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/networkmode-bridge-dynamic.png) En ne spécifiant pas de port hôte dans le mappage des ports, vous pouvez demander à Docker de choisir un port aléatoire inutilisé dans la plage de ports éphémères et de l’attribuer comme port hôte public pour le conteneur. Par exemple, l'application Node.js qui écoute sur le port `3000` du conteneur peut se voir attribuer un numéro de port aléatoire élevé, comme `47760`, sur l'hôte Amazon EC2. Cela signifie que vous pouvez exécuter plusieurs copies de ce conteneur sur l'hôte. De plus, chaque conteneur peut se voir attribuer son propre port sur l'hôte. Chaque copie du conteneur reçoit du trafic au port `3000`. Toutefois, les clients qui envoient du trafic vers ces conteneurs utilisent les ports hôtes assignés de manière aléatoire. Amazon ECS vous aide à suivre les ports assignés de manière aléatoire pour chaque tâche. Pour ce faire, il met automatiquement à jour les groupes cibles de l'équilibreur de charge et la découverte des AWS Cloud Map services afin d'obtenir la liste des adresses IP et des ports des tâches. Cela facilite l'utilisation des services fonctionnant en mode `bridge` utilisant des ports dynamiques. Cependant, l'un des inconvénients de l'utilisation du mode réseau `bridge` est qu'il est difficile de verrouiller les communications de service à service. Comme les services peuvent être affectés à n'importe quel port aléatoire et inutilisé, il est nécessaire d'ouvrir de larges plages de ports entre les hôtes. Cependant, il n'est pas facile de créer des règles spécifiques afin qu'un service particulier ne puisse communiquer qu'avec un autre service spécifique. Les services ne disposent d'aucun port spécifique à utiliser pour les règles de mise en réseau des groupes de sécurité. ## Configuration du mode réseau en pont pour les charges IPv6 de travail uniquement Pour configurer `bridge` le mode de communication IPv6, vous devez mettre à jour les paramètres du Docker démon. Mettez à jour `/etc/docker/daemon.json` les éléments suivants : ``` { "ipv6": true, "fixed-cidr-v6": "2001:db8:1::/64", "ip6tables": true, "experimental": true } ``` Après avoir mis à jour les paramètres du démon Docker, vous devez le redémarrer. **Note** Lorsque vous mettez à jour et redémarrez le daemonDocker, le IPv6 transfert est activé sur l'instance, ce qui peut entraîner la perte des routes par défaut sur les instances qui utilisent une AMI Amazon Linux 2. Pour éviter cela, utilisez la commande suivante pour ajouter une route par défaut via la IPv6 passerelle du sous-réseau. ``` ip route add default via FE80:EC2::1 dev eth0 metric 100 ``` # Options de mise en réseau des tâches Amazon ECS pour Fargate Par défaut, chaque tâche Amazon ECS sur Fargate reçoit une interface réseau Elastic (ENI) avec une adresse IP privée principale. Lorsque vous utilisez un sous-réseau public, vous pouvez éventuellement attribuer une adresse IP publique à l'ENI de la tâche. Si votre VPC est configuré pour le mode double pile et que vous utilisez un sous-réseau avec un bloc IPv6 CIDR, l'ENI de votre tâche reçoit également une adresse. IPv6 Une tâche ne peut avoir qu'une seule ENI associée à la fois. Les conteneurs qui appartiennent à la même tâche peuvent également communiquer via l'interface `localhost`. Pour plus d'informations sur les sous-réseaux VPCs et les sous-réseaux, consultez [Comment fonctionne Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html) dans le guide de l'utilisateur *Amazon VPC*. Pour qu'une tâche sur Fargate puisse extraire une image de conteneur, la tâche doit avoir un routage vers Internet. L'exemple suivant décrit également comment vous pouvez vérifier le routage vers Internet pour votre tâche. + Lorsque vous utilisez un sous-réseau public, vous pouvez attribuer une adresse IP publique à l'ENI de la tâche. + Lorsque vous utilisez un sous-réseau privé, une passerelle NAT peut être attachée au sous-réseau. + Lorsque vous utilisez des images de conteneur hébergées dans Amazon ECR, vous pouvez configurer Amazon ECR pour utiliser un point de terminaison VPC d'interface et l'extraction de l'image se fait via l'adresse privée de la tâche. IPv4 Pour plus d'informations, consultez [Points de terminaison d’un VPC d'interface Amazon ECR (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) dans le *Guide de l'utilisateur Amazon Elastic Container Registry*. Dans la mesure où chaque tâche obtient sa propre ENI, vous pouvez utiliser des fonctionnalités de mise en réseau telles que les journaux de flux VPC, que vous pouvez utiliser pour surveiller le trafic vers et depuis vos tâches. Pour plus d’informations, consultez [Journaux de flux VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) dans le *Guide de l’utilisateur Amazon VPC*. Vous pouvez également en profiter AWS PrivateLink. Vous pouvez configurer un point de terminaison d'interface VPC afin de pouvoir accéder à Amazon ECS APIs via des adresses IP privées. AWS PrivateLink restreint tout le trafic réseau entre votre VPC et Amazon ECS vers le réseau Amazon. Vous n'avez pas besoin d'une passerelle Internet, d'un périphérique NAT ni d'une passerelle privée virtuelle. Pour plus d’informations, consultez la section [Points de terminaison de VPC d’interface Amazon ECS (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html). Pour des exemples d'utilisation de la `NetworkConfiguration` ressource avec CloudFormation, voir[CloudFormation exemples de modèles pour Amazon ECS](working-with-templates.md). Les ENIs qui sont créés sont entièrement gérés par AWS Fargate. De plus, une politique IAM associée est utilisée pour accorder des autorisations pour Fargate. Pour les tâches utilisant la version `1.4.0` de la plateforme Fargate ou une version ultérieure, la tâche reçoit une seule ENI (appelée ENI de tâche) et tout le trafic réseau passe par cette ENI au sein de votre VPC. Ce trafic est enregistré dans les journaux de flux de votre VPC. Pour les tâches qui utilisent la version `1.3.0` de la plateforme Fargate et les versions antérieures, en plus de l'ENI de la tâche, la tâche reçoit également une ENI distincte détenue par Fargate, qui est utilisée pour certains trafics réseau qui ne sont pas visibles dans les journaux de flux VPC. Le tableau suivant décrit le comportement du trafic réseau et la stratégie IAM requise pour chaque version de plateforme. | Action | Flux de trafic avec les versions `1.3.0` et antérieures de la plateforme Linux | Flux de trafic avec la version `1.4.0` de la plateforme Linux | Flux de trafic avec la version `1.0.0` de la plateforme Windows | Autorisation IAM | | --- | --- | --- | --- | --- | | Récupération des informations d'identification de connexion Amazon ECR | ENI Fargate | ENI de tâche | ENI de tâche | Rôle IAM d'exécution de tâche | | Extraction d'image | ENI de tâche | ENI de tâche | ENI de tâche | Rôle IAM d'exécution de tâche | | Envoi de journaux via un pilote de journal | ENI de tâche | ENI de tâche | ENI de tâche | Rôle IAM d'exécution de tâche | | Envoi de journaux FireLens pour Amazon ECS | ENI de tâche | ENI de tâche | ENI de tâche | Rôle IAM de tâche | | Récupération de secrets à partir de Secrets Manager ou de Systems Manager | ENI Fargate | ENI de tâche | ENI de tâche | Rôle IAM d'exécution de tâche | | Trafic du système de fichiers Amazon EFS | Non disponible | ENI de tâche | ENI de tâche | Rôle IAM de tâche | | Trafic d'application | ENI de tâche | ENI de tâche | ENI de tâche | Rôle IAM de tâche | ## Considérations Tenez compte des éléments suivants lorsque vous utilisez le réseau de tâches. + Le rôle lié au service Amazon ECS est requis pour fournir à Amazon ECS les autorisations nécessaires pour passer des appels vers d'autres AWS services en votre nom. Ce rôle est généré lorsque vous créez un cluster, ou si vous créez ou mettez à jour un service dans la AWS Management Console. Pour de plus amples informations, veuillez consulter [Utilisation des rôles liés à un service pour Amazon ECS](using-service-linked-roles.md). Vous pouvez également créer le rôle lié à un service à l'aide de la commande suivante 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 remplit le nom d'hôte de la tâche avec un nom d'hôte DNS fourni par Amazon lorsque les options `enableDnsHostnames` et `enableDnsSupport` sont activées sur votre VPC. Si ces options ne sont pas activées, le nom d'hôte DNS de la tâche est un nom d'hôte aléatoire. Pour plus d'informations sur les paramètres DNS d'un VPC, veuillez consulter la rubrique [Utilisation de DNS avec votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) dans le *Guide de l'utilisateur Amazon VPC*. + Vous pouvez uniquement spécifier jusqu'à 16 sous-réseaux et 5 groupes de sécurité pour `awsVpcConfiguration`. Pour plus d'informations, consultez le [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html)manuel *Amazon Elastic Container Service API Reference*. + Vous ne pouvez pas détacher ou modifier manuellement ceux ENIs créés et attachés par Fargate. L'objectif est d'empêcher la suppression accidentelle de toute ENI associée à une tâche en cours d'exécution. Pour libérer le ENIs pour une tâche, arrêtez la tâche. + Si un sous-réseau VPC est mis à jour pour modifier l'ensemble d'options DHCP qu'il utilise, vous ne pouvez pas également appliquer ces modifications aux tâches existantes qui utilisent le VPC. Démarrez de nouvelles tâches, qui recevront le nouveau paramètre pour migrer en douceur tout en testant la nouvelle modification, puis arrêtez les anciennes, si aucune restauration n'est requise. + Ce qui suit s’applique aux tâches exécutées sur la version de plateforme Fargate `1.4.0` ou ultérieure pour Linux ou `1.0.0` pour Windows. Les tâches lancées dans des sous-réseaux à double pile reçoivent une IPv4 adresse et une IPv6 adresse. Les tâches lancées dans des sous-réseaux réservés IPv6 ne reçoivent qu'une IPv6 adresse. + Pour les tâches qui utilisent une version de plate-forme `1.4.0` ou ultérieure pour Linux ou `1.0.0` Windows, la tâche ENIs prend en charge les cadres jumbo. Les interfaces réseau sont configurées avec une unité de transmission maximale (MTU), qui correspond à la taille de la charge utile la plus élevée possible dans une seule trame. Plus la MTU est importante, plus la charge utile de l'application peut s'intégrer dans une seule trame. Cela réduit les frais généraux par trame et augmente l'efficacité. La prise en charge des trames jumbo limite la surcharge lorsque le chemin réseau entre votre tâche et la destination prend en charge les trames jumbo. + Les services comportant des tâches qui utilisent Fargate ne prennent en charge que les équilibreurs de charge Application Load Balancer et Network Load Balancer. L'équilibreur de charge Classic Load Balancer n'est pas pris en charge. Lorsque vous créez des groupes cibles pour ces services, vous devez choisir le type de cible `ip`, et non `instance`. Pour de plus amples informations, veuillez consulter [Utilisation de l’équilibrage de charge pour répartir le trafic des services Amazon ECS](service-load-balancing.md). ## Utilisation d'un VPC en mode double pile Lorsque vous utilisez un VPC en mode double pile, vos tâches peuvent communiquer entre elles IPv4 ou IPv6 par les deux. IPv4 et les IPv6 adresses sont indépendantes les unes des autres et vous devez configurer le routage et la sécurité dans votre VPC séparément pour IPv4 et. IPv6 Pour plus d'informations sur la configuration de votre VPC pour le mode double pile, consultez la section [Migration vers le guide de l'utilisateur IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) Amazon *VPC*. Si les conditions suivantes sont remplies, une adresse est attribuée aux tâches Amazon ECS sur Fargate : IPv6 + Le paramètre de votre compte Amazon ECS `dualStackIPv6` est activé (`enabled`) pour que le principal IAM lance vos tâches dans la région dans laquelle vous les lancez. Ce paramètre ne peut être modifié qu'à l'aide de l'API ou AWS CLI. Vous avez la possibilité d’activer ce paramètre pour un principal IAM spécifique sur votre compte ou pour l’ensemble de votre compte en définissant les paramètres par défaut de votre compte. Pour de plus amples informations, veuillez consulter [Accès aux fonctionnalités d’Amazon ECS avec les paramètres du compte](ecs-account-settings.md). + Votre VPC et votre sous-réseau sont activés pour. IPv6 Pour plus d'informations sur la configuration de votre VPC pour le mode double pile, consultez la section [Migration vers le guide de l'utilisateur IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) Amazon *VPC*. + Votre sous-réseau est activé pour l'attribution automatique d'adresses IPv6 . Pour plus d'informations sur la configuration de votre sous-réseau, consultez [Modifier l'attribut d' IPv6 adressage de votre sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/modify-subnets.html) dans le guide de l'utilisateur Amazon *VPC*. + La tâche ou le service utilise la version de plateforme `1.4.0` Fargate ou une version ultérieure pour Linux. Pour les tâches Amazon ECS sur Fargate exécutées dans un VPC en mode double pile, afin de communiquer avec les services de dépendance utilisés dans le processus de lancement de tâches tels que ECR, SSM SecretManager et, la table de routage du sous-réseau public a besoin (0.0.0.0/0) d'une route vers une passerelle Internet et la table de routage du sous-réseau privé IPv4 a besoin (0.0.0.0/0) d'une route vers une passerelle NAT. IPv4 Pour plus d'informations, consultez la section [Passerelles Internet et passerelles](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) [NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) dans le guide de l'utilisateur Amazon *VPC*. Pour des exemples de configuration d'un VPC à double pile, [voir Exemple de configuration de VPC à double pile](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-example.html). ## Utilisation d'un VPC en mode -only IPv6 Dans une configuration IPv6 uniquement, vos tâches Amazon ECS communiquent exclusivement via IPv6. Pour configurer VPCs des sous-réseaux pour une configuration IPv6 uniquement, vous devez ajouter un bloc d'adresse IPv6 CIDR au VPC et créer des sous-réseaux qui incluent uniquement un bloc d'adresse CIDR. IPv6 Pour plus d'informations, consultez [Ajouter un IPv6 support pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-add.html) et [Créer un sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) dans le guide de l'utilisateur Amazon *VPC*. Vous devez également mettre à jour les tables de routage avec IPv6 les cibles et configurer les groupes de sécurité avec des IPv6 règles. Pour plus d’informations, consultez les sections [Configuration des tables de routage](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) et [Configuration des règles des groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) dans le *Guide de l’utilisateur Amazon VPC*. Les considérations suivantes s'appliquent : + Vous pouvez mettre à jour un service Amazon ECS IPv4 uniquement ou à double pile vers IPv6 une configuration uniquement en mettant à jour le service directement pour IPv6 utiliser des sous-réseaux uniquement ou en créant un service parallèle IPv6 uniquement et en utilisant les déploiements bleu-vert d'Amazon ECS pour transférer le trafic vers le nouveau service. Pour plus d’informations sur les déploiements bleu-vert Amazon ECS, consultez la section [blue/green Déploiements Amazon ECS](deployment-type-blue-green.md). + Un service Amazon ECS IPv6 réservé uniquement doit utiliser des équilibreurs de charge à double pile avec des groupes cibles. IPv6 Si vous procédez à la migration d’un service Amazon ECS existant qui repose sur un Application Load Balancer ou un Network Load Balancer, vous pouvez créer un équilibreur de charge à double pile et lui transférer le trafic depuis l’ancien équilibreur de charge, ou mettre à jour le type d’adresse IP de l’équilibreur de charge existant. Pour plus d’informations sur les Network Load Balancer, consultez les sections [Création d’un Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) et [Mise à jour des types d’adresses IP pour votre Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-ip-address-type.html) dans le *Guide de l’utilisateur des Network Load Balancer*. Pour plus d’informations sur les Application Load Balancer, consultez les sections [Création d’un Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) et [Mise à jour des types d’adresses IP pour votre Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-ip-address-type.html) dans le *Guide de l’utilisateur des Application Load Balancer*. + IPv6la configuration -only n'est pas prise en charge surWindows. + Pour les tâches Amazon ECS dans une configuration IPv6 uniquement destinées à communiquer avec des points de IPv4 terminaison uniquement, vous pouvez configurer DNS64 et effectuer la traduction NAT64 d'adresses réseau de vers. IPv6 IPv4 Pour plus d'informations, consultez [DNS64 et](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-nat64-dns64.html) consultez NAT64 le guide de l'*utilisateur Amazon VPC*. + IPv6La configuration -only est prise en charge sur la version de la plateforme Fargate ou ultérieure. `1.4.0` + Les charges de travail Amazon ECS dans une configuration IPv6 réservée doivent utiliser les points de terminaison d'URI d'image à double pile Amazon ECR lors de l'extraction d'images depuis Amazon ECR. Pour plus d'informations, consultez [Getting started with making requests over IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) dans le *guide de l'utilisateur d'Amazon Elastic Container Registry*. **Note** Amazon ECR ne prend pas en charge les points de terminaison VPC à interface double pile que les tâches d'une configuration réservée peuvent utiliser. IPv6 Pour plus d'informations, consultez [Getting started with making requests over IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) dans le *guide de l'utilisateur d'Amazon Elastic Container Registry*. + Amazon ECS Exec n'est pas pris en charge dans une IPv6 configuration uniquement. + Amazon CloudWatch ne prend pas en charge un point de terminaison FIPS à double pile pouvant être utilisé pour surveiller les tâches Amazon ECS dans une configuration IPv6 uniquement conforme à la norme FIPS-140. Pour plus d’informations sur FIPS-140, consultez la section [AWS Fargate Norme fédérale de traitement de l'information (FIPS-140)](ecs-fips-compliance.md). ### Régions AWS qui prennent en charge le mode IPv6 uniquement pour Amazon ECS Vous pouvez exécuter des tâches dans une configuration IPv6 uniquement dans la configuration suivante dans Régions AWS laquelle Amazon ECS est disponible : + USA Est (Ohio) + USA Est (Virginie du Nord) + USA Ouest (Californie du Nord) + USA Ouest (Oregon) + Afrique (Le Cap) + Asie-Pacifique (Hong Kong) + Asie-Pacifique (Hyderabad) + Asie-Pacifique (Jakarta) + Asie-Pacifique (Melbourne) + Asie-Pacifique (Mumbai) + Asie-Pacifique (Osaka) + Asia Pacific (Seoul) + Asie-Pacifique (Singapour) + Asie-Pacifique (Sydney) + Asie-Pacifique (Tokyo) + Canada (Centre) + Canada Ouest (Calgary) + Chine (Pékin) + China (Ningxia) + Europe (Francfort) + Europe (Londres) + Europe (Milan) + Europe (Paris) + Europe (Espagne) + Israël (Tel Aviv) + Middle East (Bahrain) + Moyen-Orient (EAU) + Amérique du Sud (São Paulo) + AWS GovCloud (USA Est) + AWS GovCloud (US-Ouest) # Options de stockage pour les tâches Amazon ECS Amazon ECS vous propose des options de stockage de easy-to-use données flexibles et économiques en fonction de vos besoins. Amazon ECS prend en charge les options de volume de données suivantes pour les conteneurs : | Volume de données | Capacité prise en charge | Systèmes d’exploitation pris en charge | Persistance du stockage | Cas d’utilisation | | --- | --- | --- | --- | --- | | Amazon Elastic Block Store (Amazon EBS) | Fargate, Amazon EC2, instances gérées Amazon ECS | Linux, Windows (sur Amazon EC2 uniquement) | Peut être conservé lorsqu’il est associé à une tâche autonome. Éphémère lorsqu’il est rattaché à une tâche gérée par un service. | Les volumes Amazon EBS offrent un stockage par blocs économique, durable et hautement performant pour les charges de travail conteneurisées gourmandes en données. Les cas d’utilisation courants sont notamment les charges de travail transactionnelles telles que les bases de données, les bureaux virtuels et les volumes racine, ainsi que les charges de travail à débit intensif telles que le traitement des journaux et les charges de travail ETL. Pour de plus amples informations, veuillez consulter [Utilisation des volumes Amazon EBS avec Amazon ECS](ebs-volumes.md). | | Amazon Elastic File System (Amazon EFS) | Fargate, Amazon EC2, instances gérées Amazon ECS | Linux | Persistante | Les volumes Amazon EFS fournissent un stockage de fichiers partagé simple, doté d’une capacité de mise à l’échelle et persistant pour une utilisation avec vos tâches Amazon ECS. Ils croissent et diminuent automatiquement à mesure que vous ajoutez ou supprimez des fichiers. Les volumes Amazon EFS prennent en charge la simultanéité et sont utiles pour les applications conteneurisées qui évoluent horizontalement et nécessitent des fonctionnalités de stockage telles qu'une faible latence, un débit élevé et une cohérence. read-after-write Les cas d’utilisation courants sont notamment les charges de travail telles que l’analytique des données, le traitement multimédia, la gestion de contenu et les services Web. Pour de plus amples informations, veuillez consulter [Utilisation des volumes Amazon EFS avec Amazon ECS](efs-volumes.md). | | Serveur FSx de fichiers Amazon pour Windows | Amazon EC2 | Windows | Persistante | FSx pour Windows File Server, les volumes fournissent des serveurs de fichiers Windows entièrement gérés que vous pouvez utiliser pour configurer vos tâches Windows nécessitant un stockage de fichiers persistant, distribué, partagé et statique. Les cas d’utilisation courants sont notamment les applications .NET qui peuvent nécessiter des dossiers locaux comme stockage persistant pour enregistrer les résultats des applications. Amazon FSx pour Windows File Server propose un dossier local dans le conteneur qui permet à plusieurs conteneurs de lire et écrire sur le même système de fichiers soutenu par un partage SMB. Pour de plus amples informations, veuillez consulter [Utilisation FSx pour les volumes de serveurs de fichiers Windows avec Amazon ECS](wfsx-volumes.md). | | Amazon FSx pour NetApp ONTAP | Amazon EC2 | Linux | Persistante | Les volumes Amazon FSx for NetApp ONTAP fournissent des systèmes de fichiers NetApp ONTAP entièrement gérés que vous pouvez utiliser pour configurer vos tâches Linux nécessitant un stockage de fichiers partagé persistant, performant et riche en fonctionnalités. Amazon FSx for NetApp ONTAP prend en charge les protocoles NFS et SMB et fournit des fonctionnalités professionnelles telles que les instantanés, le clonage et la déduplication des données. Les cas d’utilisation courants sont notamment les charges de travail de calcul hautes performances, les référentiels de contenu et les applications nécessitant un stockage partagé compatible POSIX. Pour plus d'informations, consultez la section [Montage d'Amazon FSx pour les systèmes de fichiers NetApp ONTAP à partir de conteneurs Amazon ECS](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/mount-ontap-ecs-containers.html). | | Volumes Docker | Amazon EC2 | Windows, Linux | Persistante | Les volumes Docker sont une fonctionnalité de l’environnement d’exécution des conteneurs Docker qui permet aux conteneurs de conserver des données en montant un répertoire à partir du système de fichiers de l’hôte. Les pilotes de volume Docker (également appelés plug-ins) sont utilisés pour intégrer les volumes de conteneurs à des systèmes de stockage externes. Les volumes Docker peuvent être gérés par des pilotes tiers ou par le pilote local intégré. Les cas d’utilisation courants des volumes Docker sont notamment la mise à disposition de volumes de données persistants ou le partage de volumes à différents emplacements sur différents conteneurs d’une même instance de conteneur. Pour de plus amples informations, veuillez consulter [Utilisation de volumes Docker avec Amazon ECS](docker-volumes.md). | | Montages liés | Fargate, Amazon EC2, instances gérées Amazon ECS | Windows, Linux | Éphémère | Les montages par liaison consistent en un fichier ou un répertoire sur l'hôte, tel qu'une instance Amazon EC2 AWS Fargate ou un répertoire monté sur un conteneur. Les cas d’utilisation courants des montages liés sont notamment le partage d’un volume d’un conteneur source avec d’autres conteneurs de la même tâche, ou le montage d’un volume hôte ou d’un volume vide dans un ou plusieurs conteneurs. Pour de plus amples informations, veuillez consulter [Utilisation de montages liés avec Amazon ECS](bind-mounts.md). | # Utilisation des volumes Amazon EBS avec Amazon ECS Les volumes Amazon Elastic Block Store (Amazon EBS) offrent un stockage par blocs hautement disponible, économique, durable et performant pour les charges de travail gourmandes en données. Les volumes Amazon EBS peuvent être utilisés avec les tâches Amazon ECS pour les applications à haut débit et gourmandes en transactions. Pour plus d’informations sur les volumes Amazon EBS, consultez la section [Volumes Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) dans le *Guide de l’utilisateur Amazon EBS*. Les volumes Amazon EBS attachés aux tâches Amazon ECS sont gérés par Amazon ECS en votre nom. Lors du lancement d’une tâche autonome, vous pouvez fournir la configuration qui sera utilisée pour associer un volume EBS à la tâche. Lors de la création ou de la mise à jour du service, vous pouvez fournir la configuration qui sera utilisée pour associer un volume EBS par tâche à chaque tâche gérée par le service Amazon ECS. Vous pouvez soit configurer de nouveaux volumes vides pour les attachements, soit utiliser des instantanés pour charger des données à partir de volumes existants. **Note** Lorsque vous utilisez des instantanés pour configurer des volumes, vous pouvez spécifier un `volumeInitializationRate`, en Mio/s, auquel les données sont extraites de l’instantané afin de créer des volumes entièrement initialisés dans un délai prévisible. Pour plus d’informations sur l’initialisation des volumes, consultez la section [Initialisation des volumes Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/initalize-volume.html) dans le *Guide de l’utilisateur Amazon EBS*. Pour plus d’informations sur la configuration des volumes Amazon EBS, consultez les sections [Report de la configuration du volume au moment du lancement dans une définition de tâche Amazon ECS](specify-ebs-config.md) et [Spécification de la configuration du volume Amazon EBS lors du déploiement Amazon ECS](configure-ebs-volume.md). La configuration du volume est reportée à l’heure de lancement à l’aide du paramètre `configuredAtLaunch` figurant dans la définition de tâche. En fournissant la configuration des volumes au moment du lancement plutôt que dans la définition de tâche, vous pouvez créer des définitions de tâche qui ne sont pas limitées à un type de volume de données ou à des paramètres de volume EBS spécifiques. Vous pouvez ensuite réutiliser vos définitions de tâches dans différents environnements d’exécution. Par exemple, vous pouvez fournir un débit supérieur lors du déploiement de vos charges de travail de production par rapport à vos environnements de préproduction. Les volumes Amazon EBS associés à des tâches peuvent être chiffrés avec des clés AWS Key Management Service (AWS KMS) pour protéger vos données. Pour plus d'informations, voir,[Chiffrement des données stockées dans les volumes Amazon EBS associés aux tâches Amazon ECS](ebs-kms-encryption.md). Pour surveiller les performances de votre volume, vous pouvez également utiliser CloudWatch les métriques Amazon. Pour plus d’informations sur les métriques Amazon ECS pour les volumes Amazon EBS, consultez les sections [CloudWatch Métriques Amazon ECS](available-metrics.md) et [Métriques Amazon ECS Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html). L’association d’un volume Amazon EBS à une tâche est prise en charge dans toutes les [Régions AWS](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html?icmpid=docs_homepage_addtlrcs#region) commerciales et chinoises qui prennent en charge Amazon ECS. ## Systèmes d’exploitation et capacité pris en charge Le tableau suivant indique les systèmes d’exploitation et les configurations de capacité pris en charge. | Capacity | Linux | Windows | | --- | --- | --- | | Fargate | Les volumes Amazon EBS sont pris en charge sur la version de plateforme 1.4.0 ou ultérieure (Linux). Pour de plus amples informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md). | Non pris en charge | | EC2 | Les volumes Amazon EBS sont pris en charge pour les tâches hébergées sur des instances Nitro basées sur Amazon Machine Images AMIs () optimisées pour Amazon ECS. Pour plus d’informations sur les types d’instances, consultez la section [Types d’instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) dans le Guide de l’utilisateur Amazon EC2. Les volumes Amazon EBS sont pris en charge sur l’AMI optimisée pour ECS `20231219` ou une version ultérieure. Pour plus d'informations, consultez [Extraction des métadonnées d'AMI optimisée pour Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_AMI.html). | Tâches hébergées sur des instances Nitro basées sur Amazon Machine Images () AMIs optimisées pour Amazon ECS. Pour plus d’informations sur les types d’instances, consultez la section [Types d’instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) dans le Guide de l’utilisateur Amazon EC2. Les volumes Amazon EBS sont pris en charge sur l’AMI optimisée pour ECS `20241017` ou une version ultérieure. Pour plus d’informations, consultez la section [Extraction des métadonnées d’AMI optimisée pour Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_windows_AMI.html). | | Instances gérées Amazon ECS | Les volumes Amazon EBS sont pris en charge pour les tâches hébergées sur des instances gérées Amazon ECS sous Linux. | Non pris en charge | ## Considérations Tenez compte des éléments suivants lorsque vous utilisez des volumes Amazon EBS : + Vous ne pouvez pas configurer de volumes Amazon EBS à rattacher à des tâches Fargate Amazon ECS dans la zone de disponibilité `use1-az3`. + Le type de volume Amazon EBS magnétique (`standard`) n’est pas pris en charge pour les tâches hébergées sur Fargate. Pour plus d’informations sur les types de volumes Amazon EBS, consultez la section [Volumes Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) dans le *Guide de l’utilisateur Amazon EC2*. + Un rôle IAM d’infrastructure Amazon ECS est requis lors de la création d’un service ou d’une tâche autonome qui configure un volume lors du déploiement. Vous pouvez associer la politique IAM `AmazonECSInfrastructureRolePolicyForVolumes` gérée par AWS au rôle, ou vous pouvez utiliser la politique gérée comme guide pour créer et associer votre propre politique avec des autorisations qui répondent à vos besoins spécifiques. Pour de plus amples informations, veuillez consulter [Rôle IAM d’infrastructure Amazon ECS](infrastructure_IAM_role.md). + Vous pouvez associer au maximum un volume Amazon EBS à chaque tâche Amazon ECS, et il doit s’agir d’un nouveau volume. Vous ne pouvez pas associer un volume Amazon EBS existant à une tâche. Toutefois, vous pouvez configurer un nouveau volume Amazon EBS à l’aide de l’instantané d’un volume existant lors du déploiement. + Pour utiliser les volumes Amazon EBS avec les services Amazon ECS, le contrôleur de déploiement doit être `ECS`. Les stratégies de déploiement et blue/green de déploiement sont prises en charge lors de l'utilisation de ce contrôleur de déploiement. + Pour qu'un conteneur de votre tâche puisse écrire sur le volume Amazon EBS monté, il doit disposer des autorisations de système de fichiers appropriées. Lorsque vous spécifiez un utilisateur non root dans votre définition de conteneur, Amazon ECS configure automatiquement le volume avec des autorisations basées sur le groupe qui permettent à l'utilisateur spécifié de lire et d'écrire sur le volume. Si aucun utilisateur n'est spécifié, le conteneur s'exécute en tant que root et dispose d'un accès complet au volume. + Amazon ECS ajoute automatiquement les balises réservées `AmazonECSCreated` et `AmazonECSManaged` au volume attaché. Si vous supprimez ces balises du volume, Amazon ECS ne sera pas en mesure de gérer le volume en votre nom. Pour plus d’informations sur la création d’es volumes Amazon EBS, consultez la section [Étiquetage d’un volume Amazon EBS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specify-ebs-config.html#ebs-volume-tagging). Pour plus d’informations sur l’étiquetage de vos ressources Amazon ECS, consultez [Étiquetage de vos ressources Amazon EC2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html). + L’allocation de volumes à partir d’un instantané d’un volume Amazon EBS contenant des partitions n’est pas prise en charge. + Les volumes attachés à des tâches gérées par un service ne sont pas conservés et sont toujours supprimés à la fin de la tâche. + Vous ne pouvez pas configurer de volumes Amazon EBS à rattacher à des tâches Amazon ECS en cours d’exécution sur AWS Outposts. # Comportement des utilisateurs non root Lorsque vous spécifiez un utilisateur non root dans votre définition de conteneur, Amazon ECS configure automatiquement le volume Amazon EBS avec des autorisations basées sur le groupe qui permettent à l'utilisateur spécifié de lire et d'écrire sur le volume. Le volume est monté avec les caractéristiques suivantes : + Le volume appartient à l'utilisateur root et au groupe root. + Les autorisations de groupe sont définies pour autoriser l'accès en lecture et en écriture. + L'utilisateur non root est ajouté au groupe approprié pour accéder au volume. Suivez ces bonnes pratiques lorsque vous utilisez des volumes Amazon EBS avec des conteneurs autres que root : + Utilisez des utilisateurs IDs (UIDs) et des groupes IDs (GIDs) cohérents dans toutes vos images de conteneur pour garantir des autorisations cohérentes. + Créez au préalable des répertoires de points de montage dans votre image de conteneur et définissez les droits de propriété et les autorisations appropriés. + Testez vos conteneurs avec des volumes Amazon EBS dans un environnement de développement pour vérifier que les autorisations du système de fichiers fonctionnent comme prévu. + Si plusieurs conteneurs partagent un même volume dans le cadre d'une même tâche, assurez-vous qu'ils utilisent un volume compatible UIDs/GIDs ou qu'ils le montent avec des attentes d'accès cohérentes. # Report de la configuration du volume au moment du lancement dans une définition de tâche Amazon ECS Pour configurer un volume Amazon EBS à rattacher à votre tâche, vous devez spécifier la configuration du point de montage dans la définition de tâche et nommer le volume. Vous devez également définir `configuredAtLaunch` sur `true`, car les volumes Amazon EBS ne peuvent pas être configurés pour être attaché dans la définition de tâche. Au lieu de cela, les volumes Amazon EBS sont configurés pour être attachés lors du déploiement. Pour enregistrer la définition de tâche à l'aide de AWS Command Line Interface (AWS CLI), enregistrez le modèle sous forme de fichier JSON, puis transmettez-le comme entrée pour la `[register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html)` commande. Pour créer et enregistrer une définition de tâche à l'aide du AWS Management Console, voir[Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md). La définition de tâche suivante montre la syntaxe des objets `mountPoints` et `volumes` dans la définition de tâche. Pour plus d’informations sur les paramètres de définition des tâches, consultez la section [Paramètres de définition de tâche Amazon ECS pour Fargate](task_definition_parameters.md). Pour utiliser cet exemple, remplacez les `user input placeholders` par vos propres informations. ## 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` Type : tableau d'objets Obligatoire : non Les points de montage pour les volumes de données dans votre conteneur. Ce paramètre correspond à `Volumes` dans l’API Docker create-container et à l’option `--volume` de docker run. Les conteneurs Windows peuvent monter des répertoires entiers sur le même lecteur que `$env:ProgramData`. Les conteneurs Windows ne peuvent pas monter de répertoires sur un autre lecteur, et les points de montage ne peuvent pas être utilisés sur plusieurs lecteurs. Vous devez spécifier des points de montage pour associer un volume Amazon EBS directement à une tâche Amazon ECS. `sourceVolume` Type : Chaîne Obligatoire : oui, lorsque des objets `mountPoints` sont utilisés Nom du volume à monter. `containerPath` Type : Chaîne Obligatoire : oui, lorsque des objets `mountPoints` sont utilisés Le chemin dans le conteneur où le volume sera monté. `readOnly` Type : booléen Obligatoire : non Si cette valeur est `true`, le conteneur ne peut accéder au volume qu'en lecture. Si cette valeur est `false`, le conteneur peut écrire sur le volume. La valeur par défaut est `false`. Pour les tâches exécutées sur des instances EC2 exécutant le système d’exploitation Windows, laissez la valeur `false` par défaut. `name` Type : chaîne Obligatoire : non Nom du volume. Jusqu’à 255 lettres (majuscules et minuscules), chiffres, traits d’union (`-`) et traits de soulignement (`_`) sont autorisés. Ce nom est référencé dans le paramètre `sourceVolume` de l’objet `mountPoints` de définition du conteneur. `configuredAtLaunch` Type : Boolean Obligatoire : oui, lorsque vous souhaitez attacher un volume EBS directement à une tâche. Spécifie si un volume est configurable au lancement. Lorsque ce paramètre est défini sur `true`, vous pouvez configurer le volume lorsque vous exécutez une tâche autonome, ou lorsque vous créez ou mettez à jour un service. Lorsque cette option est définie sur `false`, vous ne pourrez pas fournir d’autre configuration de volume dans la définition de tâche. Ce paramètre doit être fourni et défini sur `true` pour configurer un volume Amazon EBS à rattacher à une tâche. # Chiffrement des données stockées dans les volumes Amazon EBS associés aux tâches Amazon ECS Vous pouvez utiliser AWS Key Management Service (AWS KMS) pour créer et gérer des clés cryptographiques qui protègent vos données. Les volumes Amazon EBS sont chiffrés au repos à l'aide AWS KMS keys de. Les types de données suivants font l’objet d’un chiffrement : + Données stockées au repos sur le volume + E/S du disque + Instantanés créés à partir du volume + Nouveaux volumes créés à partir d’instantanés chiffrés Les volumes Amazon EBS attachés à des tâches peuvent être chiffrés en utilisant soit une Clé gérée par AWS par défaut avec l’alias `alias/aws/ebs`, soit une clé symétrique gérée par le client spécifiée dans la configuration du volume. Clés gérées par AWS Les valeurs par défaut sont uniques à chaque Compte AWS Région AWS utilisateur et sont créées automatiquement. Pour créer une clé symétrique gérée par le client, suivez les étapes décrites dans la section [Création de clés KMS de chiffrement symétrique](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) dans le *Guide du développeur AWS KMS *. Vous pouvez configurer le chiffrement Amazon EBS par défaut afin que tous les nouveaux volumes créés et attachés à une tâche spécifique Région AWS soient chiffrés à l'aide de la clé KMS que vous spécifiez pour votre compte. Pour plus d’informations sur le chiffrement Amazon EBS et le chiffrement par défaut, consultez la section [Chiffrement Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) dans le *Guide de l’utilisateur Amazon EBS*. ## Comportement des instances gérées Amazon ECS Vous chiffrez les volumes Amazon EBS en activant le chiffrement, soit en utilisant le chiffrement par défaut, soit en activant le chiffrement lorsque vous créez un volume que vous souhaitez chiffrer. Pour plus d’informations sur la manière d’activer le chiffrement par défaut (au niveau du compte), consultez la section [Chiffrement par défaut](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html) dans le *Guide de l’utilisateur Amazon EBS*. Vous pouvez configurer n’importe quelle combinaison de ces clés. L’ordre de priorité des clés KMS est le suivant : 1. La clé KMS spécifiée dans la configuration du volume. Lorsque vous spécifiez une clé KMS dans la configuration du volume, elle remplace la clé par défaut d’Amazon EBS et toute clé KMS spécifiée au niveau du compte. 1. La clé KMS spécifiée au niveau du compte. Lorsque vous spécifiez une clé KMS pour le chiffrement au niveau du cluster du stockage géré Amazon ECS, celle-ci remplace le chiffrement par défaut Amazon EBS, mais ne remplace aucune clé KMS spécifiée dans la configuration du volume. 1. Chiffrement par défaut Amazon EBS. Le chiffrement par défaut s’applique lorsque vous ne spécifiez ni clé KMS au niveau du compte ni aucune clé dans la configuration du volume. Si vous activez le chiffrement Amazon EBS par défaut, il s’agit de la clé KMS que vous spécifiez pour le chiffrement par défaut. Dans le cas contraire, la valeur par défaut est Clé gérée par AWS avec l’alias `alias/aws/ebs`. **Note** Si vous définissez `encrypted` sur `false` dans la configuration de votre volume, que vous ne spécifiez aucune clé KMS au niveau du compte et que vous activez le chiffrement Amazon EBS par défaut, le volume sera toujours chiffré avec la clé spécifiée pour le chiffrement Amazon EBS par défaut. ## Comportement des instances gérées hors Amazon ECS Vous pouvez également configurer le chiffrement au niveau du cluster Amazon ECS pour le stockage géré par Amazon ECS lorsque vous créez ou mettez à jour un cluster. Le chiffrement au niveau du cluster prend effet au niveau de la tâche et peut être utilisé pour chiffrer les volumes Amazon EBS attachés à chaque tâche exécutée dans un cluster spécifique à l’aide de la clé KMS spécifiée. Pour plus d'informations sur la configuration du chiffrement au niveau du cluster pour chaque tâche, consultez [ManagedStorageConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedStorageConfiguration.html)la *référence de l'API Amazon ECS*. Vous pouvez configurer n’importe quelle combinaison de ces clés. L’ordre de priorité des clés KMS est le suivant : 1. La clé KMS spécifiée dans la configuration du volume. Lorsque vous spécifiez une clé KMS dans la configuration du volume, elle remplace la clé par défaut d’Amazon EBS et toute clé KMS spécifiée au niveau du cluster. 1. La clé KMS spécifiée au niveau du cluster. Lorsque vous spécifiez une clé KMS pour le chiffrement au niveau du cluster du stockage géré Amazon ECS, celle-ci remplace le chiffrement par défaut Amazon EBS, mais ne remplace aucune clé KMS spécifiée dans la configuration du volume. 1. Chiffrement par défaut Amazon EBS. Le chiffrement par défaut s’applique lorsque vous ne spécifiez ni clé KMS au niveau du cluster, ni clé dans la configuration du volume. Si vous activez le chiffrement Amazon EBS par défaut, il s’agit de la clé KMS que vous spécifiez pour le chiffrement par défaut. Dans le cas contraire, la valeur par défaut est le Clé gérée par AWS avec l'alias`alias/aws/ebs`. **Note** Si vous définissez `encrypted` sur `false` dans la configuration de votre volume, que vous ne spécifiez aucune clé KMS au niveau du cluster et que vous activez le chiffrement Amazon EBS par défaut, le volume sera toujours chiffré avec la clé spécifiée pour le chiffrement Amazon EBS par défaut. ## Stratégie de clé KMS gérée par le client Pour chiffrer un volume EBS attaché à votre tâche à l’aide d’une clé gérée par le client, vous devez configurer votre stratégie de clé KMS afin de vous assurer que le rôle IAM que vous utilisez pour la configuration du volume dispose des autorisations nécessaires pour utiliser la clé. La stratégie de clés KMS doit inclure à la fois les autorisations `kms:CreateGrant` et `kms:GenerateDataKey*`. Les autorisations `kms:ReEncryptTo` et `kms:ReEncryptFrom` sont nécessaires pour chiffrer les volumes créés à l’aide d’instantanés. Si vous souhaitez configurer et chiffrer uniquement les nouveaux volumes vides à attacher, vous pouvez exclure les autorisations `kms:ReEncryptTo` et `kms:ReEncryptFrom`. L’extrait JSON suivant présente les instructions de stratégie de clé que vous pouvez attacher à votre stratégie de clé KMS. L’utilisation de ces instructions permettra à Amazon ECS d’utiliser la clé pour chiffrer le volume EBS. Pour utiliser les exemples d’instructions de politique, remplacez les `user input placeholders` informations par les vôtres. Comme toujours, ne configurez que les autorisations dont vous avez besoin. ``` { "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 } } } ``` Pour plus d’informations sur les politiques et autorisations clés, consultez les sections [Stratégies de clés AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) et [Autorisations AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html) dans le *Guide du développeur AWS KMS *. Pour résoudre les problèmes de connexion aux volumes EBS liés aux autorisations clés, consultez la section [Résolution des problèmes liés à l’attachement de volumes Amazon EBS aux tâches Amazon ECS](troubleshoot-ebs-volumes.md). # Spécification de la configuration du volume Amazon EBS lors du déploiement Amazon ECS Après avoir enregistré une définition de tâche dont le paramètre `configuredAtLaunch` est défini sur `true`, vous pouvez configurer un volume Amazon EBS lors du déploiement, lorsque vous exécutez une tâche autonome, ou lorsque vous créez ou mettez à jour un service. Pour plus d’informations sur le report de la configuration du volume au moment du lancement à l’aide du paramètre `configuredAtLaunch`, consultez la section [Report de la configuration du volume au moment du lancement dans une définition de tâche Amazon ECS](specify-ebs-config.md). Pour configurer un volume, vous pouvez utiliser Amazon ECS APIs ou transmettre un fichier JSON en entrée pour les AWS CLI commandes suivantes : + `[run-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html)` pour exécuter une tâche ECS autonome. + `[start-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/start-task.html)` pour exécuter une tâche ECS autonome dans une instance de conteneur spécifique. Cette commande ne s’applique pas aux tâches Fargate. + `[create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)` pour créer un service ECS. + `[update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html)` pour mettre à jour un service existant. **Note** Pour qu'un conteneur de votre tâche puisse écrire sur le volume Amazon EBS monté, il doit disposer des autorisations de système de fichiers appropriées. Lorsque vous spécifiez un utilisateur non root dans votre définition de conteneur, Amazon ECS configure automatiquement le volume avec des autorisations basées sur le groupe qui permettent à l'utilisateur spécifié de lire et d'écrire sur le volume. Si aucun utilisateur n'est spécifié, le conteneur s'exécute en tant que root et dispose d'un accès complet au volume. Vous pouvez également configurer un volume Amazon EBS à l’aide de l’ AWS Management Console. Pour plus d’informations, consultez [Exécution d’une application en tant que tâche Amazon ECS](standalone-task-create.md), [Création d’un déploiement de mise à jour propagée Amazon ECS](create-service-console-v2.md) et [Mettre à jour un service Amazon ECS](update-service-console-v2.md). L’extrait de code JSON suivant présente tous les paramètres d’un volume Amazon EBS pouvant être configurés lors du déploiement. Pour utiliser ces paramètres pour configurer des volumes, remplacez `user input placeholders` par vos propres informations. Pour plus d’informations sur ces paramètres, consultez la section [Configurations de volume](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" } } ] ``` **Important** Assurez-vous que le `volumeName` que vous spécifiez dans la configuration est identique au `volumeName` que vous spécifiez dans votre définition de tâche. Pour plus d’informations sur la vérification de l’état de connexion du volume, consultez la section [Résolution des problèmes liés à l’attachement de volumes Amazon EBS aux tâches Amazon ECS](troubleshoot-ebs-volumes.md). Pour plus d'informations sur le rôle d'infrastructure Amazon ECS Gestion des identités et des accès AWS (IAM) nécessaire à l'attachement d'un volume EBS, consultez. [Rôle IAM d’infrastructure Amazon ECS](infrastructure_IAM_role.md) Voici des exemples d’extraits de code JSON illustrant la configuration des volumes Amazon EBS. Ces exemples peuvent être utilisés en enregistrant les extraits dans des fichiers JSON et en transmettant les fichiers en tant que paramètres (en utilisant le `--cli-input-json file://filename` paramètre) pour AWS CLI les commandes. Remplacez les `user input placeholders` par vos propres informations. ## Configuration d’un volume pour une tâche autonome L’extrait de code suivant présente la syntaxe permettant de configurer des volumes Amazon EBS à rattacher à une tâche autonome. L’extrait de code JSON suivant présente la syntaxe de configuration des paramètres `volumeType`, `sizeInGiB`, `encrypted` et `kmsKeyId`. La configuration spécifiée dans le fichier JSON est utilisée pour créer et associer un volume EBS à la tâche autonome. ``` { "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" } } ] } ``` ## Configuration d’un volume lors de la création du service L’extrait de code suivant présente la syntaxe permettant de configurer des volumes Amazon EBS à rattacher à des tâches gérées par un service. Les volumes sont extraits de l’instantané spécifié à l’aide du paramètre `snapshotId` à un débit de 200 Mio/s. La configuration spécifiée dans le fichier JSON est utilisée pour créer et attacher un volume EBS à chaque tâche gérée par le service. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "serviceName": "mysvc", "desiredCount": 2, "volumeConfigurations": [ { "name": "myEbsVolume", "managedEBSVolume": { "roleArn":"arn:aws:iam::1111222333:role/ecsInfrastructureRole", "snapshotId": "snap-12345", "volumeInitializationRate": 200 } } ] } ``` ## Configuration d’un volume lors de la mise à jour d’un service L’extrait de code JSON suivant présente la syntaxe permettant de mettre à jour un service qui ne disposait pas auparavant de volumes Amazon EBS configurés pour être rattachés à des tâches. Vous devez fournir l’ARN d’une révision de définition de tâche pour laquelle `configuredAtLaunch` est défini sur `true`. L’extrait de code JSON suivant présente la syntaxe de configuration des paramètres `volumeType`, `sizeInGiB`, `throughput`, `iops` et `filesystemType`. Cette configuration est utilisée pour créer et rattacher un volume EBS à chaque tâche gérée par le service. ``` { "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" } } ] } ``` ### Configuration d’un service pour qu’il n’utilise plus les volumes Amazon EBS L’extrait de code JSON suivant présente la syntaxe permettant de mettre à jour un service afin qu’il n’utilise plus les volumes Amazon EBS. Vous devez fournir l’ARN d’une définition de tâche pour laquelle `configuredAtLaunch` est défini sur `false` ou d’une définition de tâche qui ne comporte pas le paramètre `configuredAtLaunch`. Vous devez également fournir un objet `volumeConfigurations` vide. ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "service": "mysvc", "desiredCount": 2, "volumeConfigurations": [] } ``` ## Stratégie de résiliation pour les volumes Amazon EBS Lorsqu’une tâche Amazon ECS est résiliée, Amazon ECS utilise la valeur `deleteOnTermination` pour déterminer si le volume Amazon EBS associé à la tâche résiliée doit être supprimé. Par défaut, les volumes EBS rattachés à des tâches sont supprimés lorsque la tâche est résiliée. Pour les tâches autonomes, vous pouvez modifier ce paramètre afin de préserver le volume à la fin de la tâche. **Note** Les volumes rattachés à des tâches gérées par un service ne sont pas conservés et sont toujours supprimés lorsque la tâche est résiliée. ## Étiquetage des volumes Amazon EBS Vous pouvez étiqueter les volumes Amazon EBS à l’aide de l’objet `tagSpecifications`. À l’aide de cet objet, vous pouvez fournir vos propres balises et définir la propagation des balises à partir de la définition de tâche ou de service, selon que le volume est associé à une tâche autonome ou à une tâche dans un service. Le nombre maximal de balises pouvant être attachées à un volume est 50. **Important** Amazon ECS attache automatiquement les balises réservées `AmazonECSCreated` et `AmazonECSManaged` à un volume Amazon EBS. Cela signifie que vous pouvez contrôler l’attachement d’un maximum de 48 balises supplémentaires à un volume. Ces balises supplémentaires peuvent être définies par l’utilisateur, gérées par ECS ou propagées. Si vous souhaitez ajouter des balises gérées par Amazon ECS à votre volume, vous devez définir `enableECSManagedTags` sur `true` dans vos appels à `UpdateService`, `CreateService`, `RunTask` ou `StartTask`. Si vous activez les balises gérées par Amazon ECS, celui-ci balisera automatiquement le volume avec les informations relatives au cluster et au service (`aws:ecs:clusterName` et `aws:ecs:serviceName`). Pour plus d’informations sur l’étiquetage de vos ressources Amazon ECS, consultez [Étiquetage de vos ressources Amazon EC2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html). L’extrait de code JSON suivant montre la syntaxe permettant d’étiqueter chaque volume Amazon EBS associé à chaque tâche d’un service avec une balise définie par l’utilisateur. Pour utiliser cet exemple pour créer un service, remplacez chaque `user input placeholders` par vos propres informations. ``` { "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" } } ] } ``` **Important** Vous devez spécifier un type de ressource de `volume` pour étiqueter les volumes Amazon EBS. # Performances des volumes Amazon EBS pour les tâches Fargate à la demande performances de base en termes d’IOPS et de débit des volumes Amazon EBS disponibles pour une tâche Fargate à la demande dépendent du nombre total d’unités d’UC que vous demandez pour la tâche. Si vous demandez 0,25, 0,5 ou 1 unité d’UC virtuelle (vCPU) pour votre tâche Fargate, nous vous recommandons de configurer un volume SSD à usage général (`gp2` ou `gp3`) ou un volume de disque dur (HDD) (`st1` ou `sc1`). Si vous demandez plus d’un vCPU pour votre tâche Fargate, les limites de performances de base suivantes s’appliquent à un volume Amazon EBS rattaché à la tâche. Vous pouvez obtenir des performances EBS temporairement supérieures aux limites suivantes. Cependant, nous vous recommandons de planifier votre charge de travail en fonction de ces limites. | Unités de processeur demandées (en vCPUs) | IOPS Amazon EBS de base (16 Kio en E/S) | Débit de référence d'Amazon EBS (entrée MiBps, 128 Kio d'E/S) | Bande passante de base (en Mbit/s) | | --- | --- | --- | --- | | 2 | 3 000 | 75 | 360 | | 4 | 5 000 | 120 | 1 150 | | 8 | 10 000 | 250 | 2 300 | | 16 | 15 000 | 500 | 4 500 | **Note** Lorsque vous configurez un volume Amazon EBS à rattacher à une tâche Fargate, la limite de performance Amazon EBS pour la tâche Fargate est partagée entre le stockage éphémère de la tâche et le volume attaché. # Performances des volumes Amazon EBS pour les tâches EC2 Amazon EBS fournit les types de volume suivants, qui ont des caractéristiques de performances et des prix différents, ce qui vous permet d’adapter vos performances de stockage et vos coûts en fonction des besoins de vos applications. Pour plus d’informations sur les performances, notamment les IOPS par volume et le débit par volume, consultez la section [Types de volumes Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) dans le *Guide de l’utilisateur d’Amazon Elastic Block Store*. # Performances des volumes Amazon EBS pour les tâches d’instances gérées Amazon ECS Amazon EBS fournit les types de volume suivants, qui ont des caractéristiques de performances et des prix différents, ce qui vous permet d’adapter vos performances de stockage et vos coûts en fonction des besoins de vos applications. Pour plus d’informations sur les performances, notamment les IOPS par volume et le débit par volume, consultez la section [Types de volumes Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) dans le *Guide de l’utilisateur d’Amazon Elastic Block Store*. # Résolution des problèmes liés à l’attachement de volumes Amazon EBS aux tâches Amazon ECS Vous devrez peut-être résoudre des problèmes ou procéder à des vérifications en lien à l’attachement des volumes Amazon EBS aux tâches Amazon ECS. ## Vérification du statut de l’attachement aux volumes Vous pouvez utiliser le AWS Management Console pour consulter l'état de la pièce jointe d'un volume Amazon EBS à une tâche Amazon ECS. Si la tâche démarre et que l’attachement échoue, vous verrez également s’afficher une raison de statut que vous pourrez utiliser pour la résolution des problèmes. Le volume créé sera supprimé et la tâche arrêtée. Pour plus d’informations sur les raisons du statut, consultez la section [Raisons du statut de l’attachement d’un volume Amazon EBS aux tâches Amazon ECS](troubleshoot-ebs-volumes-scenarios.md). **Pour consulter le statut de l’attachement d’un volume et la raison du statut à l’aide de la console** 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Sur la page **Clusters**, choisissez le cluster dans lequel votre tâche est exécutée. La page des détails du cluster s’affiche. 1. Sur la page de détails du cluster, choisissez l’onglet **Tâches**. 1. Choisissez la tâche pour laquelle vous souhaitez afficher le statut de l’attachement au volume. Vous devrez peut-être utiliser **Filtrer le statut souhaité** et choisir **Arrêté** si la tâche que vous souhaitez examiner s’est arrêtée. 1. Sur la page de détails de la tâche, choisissez l’onglet **Volumes**. Vous pourrez voir le statut de l’attachement au volume Amazon EBS sous **Statut de l’attachement**. Si l’attachement du volume à la tâche échoue, vous pouvez sélectionner le statut sous **Statut de l’attachement** pour afficher la cause de l’échec. Vous pouvez également consulter l'état d'attachement au volume d'une tâche et la raison du statut associée à l'aide de l'[DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html)API. ## Échecs de services et de tâches Vous pouvez rencontrer des échecs de service ou de tâche qui ne sont pas spécifiques aux volumes Amazon EBS et qui peuvent affecter l’attachement des volumes. Pour plus d’informations, veuillez consulter la rubrique + [Messages d'événement de service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-event-messages.html) + [Codes d’erreur des tâches arrêtées](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/stopped-task-error-codes.html) + [Raisons de défaillance de l'API](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/api_failures_messages.html) # Le conteneur ne peut pas écrire sur le volume Amazon EBS Utilisateur non root sans autorisations appropriées Lorsque vous spécifiez un utilisateur non root dans votre définition de conteneur, Amazon ECS configure automatiquement le volume avec des autorisations basées sur le groupe pour autoriser l'accès en écriture. Toutefois, si vous rencontrez toujours des problèmes d'autorisation : + Vérifiez que le `user` paramètre est correctement spécifié dans la définition de votre conteneur à l'aide du format `uid:gid` (par exemple,`1001:1001`). + Assurez-vous que l'image de votre conteneur ne remplace pas les autorisations de l'utilisateur une fois le volume monté. + Vérifiez que votre application s'exécute avec l'ID utilisateur attendu en examinant les journaux du conteneur ou en utilisant Amazon ECS Exec pour inspecter le conteneur en cours d'exécution. Utilisateur root ayant des problèmes d'autorisation Si aucun utilisateur n'est spécifié dans votre définition de conteneur, le conteneur s'exécute en tant qu'utilisateur root et doit avoir un accès complet au volume. Si vous rencontrez des problèmes : + Vérifiez que le volume est correctement monté en vérifiant les points de montage à l'intérieur du conteneur. + Assurez-vous que le volume n'est pas configuré en lecture seule dans la configuration de votre point de montage. Tâches multi-conteneurs avec différents utilisateurs Dans les tâches impliquant plusieurs conteneurs exécutés sous le nom d'utilisateurs différents, Amazon ECS gère automatiquement les autorisations de groupe afin de permettre à tous les utilisateurs spécifiés d'écrire sur le volume. Si les conteneurs ne peuvent pas écrire : + Vérifiez que le `user` paramètre est correctement configuré pour tous les conteneurs nécessitant un accès en écriture. + Vérifiez que le volume est installé dans tous les conteneurs qui doivent y accéder. Pour plus d'informations sur la configuration des utilisateurs dans les définitions de conteneurs, consultez les [paramètres de définition des tâches Amazon ECS pour Fargate.](https://docs.aws.amazon.com/./task_definition_parameters.html) # Raisons du statut de l’attachement d’un volume Amazon EBS aux tâches Amazon ECS Utilisez la référence suivante pour résoudre les problèmes que vous pourriez rencontrer sous forme de raisons de statut AWS Management Console lorsque vous configurez des volumes Amazon EBS pour les associer à des tâches Amazon ECS. Pour plus d’informations sur la localisation des raisons de ces statuts dans la console, consultez la section [Vérification du statut de l’attachement aux volumes](troubleshoot-ebs-volumes.md#troubleshoot-ebs-volumes-location). ECS n'a pas pu assumer le rôle d'infrastructure ECS configuré « arn:aws:iam : :role/ ». *111122223333* *ecsInfrastructureRole* Vérifiez que le rôle transmis possède la bonne relation d’approbation avec Amazon ECS Cette raison de statut apparaît dans les scénarios suivants. + Vous fournissez un rôle IAM sans que la stratégie d’approbation requise ne soit attachée. Amazon ECS ne peut pas accéder au rôle IAM d’infrastructure Amazon ECS que vous fournissez si le rôle ne dispose pas de la stratégie d’approbation requise. La tâche peut rester bloquée dans l’état `DEPROVISIONING`. Pour de plus amples informations sur la stratégie d’approbation requise, consultez la section [Rôle IAM d’infrastructure Amazon ECS](infrastructure_IAM_role.md). + Votre utilisateur IAM n’est pas autorisé à transmettre le rôle d’infrastructure Amazon ECS à Amazon ECS. La tâche peut rester bloquée dans l’état `DEPROVISIONING`. Pour éviter ce problème, vous pouvez associer l’autorisation `PassRole` à votre utilisateur. Pour de plus amples informations, veuillez consulter [Rôle IAM d’infrastructure Amazon ECS](infrastructure_IAM_role.md). + Votre rôle IAM ne dispose pas des autorisations requises pour attacher un volume Amazon EBS. La tâche peut rester bloquée dans l’état `DEPROVISIONING`. Pour plus d’informations sur les autorisations spécifiques requises pour attacher des volumes Amazon EBS à des tâches, consultez la section [Rôle IAM d’infrastructure Amazon ECS](infrastructure_IAM_role.md). Ce message d’erreur peut également s’afficher en raison d’un retard dans la propagation des rôles. Si une nouvelle tentative d’utilisation du rôle après quelques minutes d’attente ne résout pas le problème, vous avez peut-être mal configuré la stratégie d’approbation pour le rôle. ECS n’a pas réussi à configurer le volume EBS. IdempotentParameterMismatchTrouvé « ; « Le jeton client que vous avez fourni est associé à une ressource déjà supprimée. Veuillez utiliser un autre jeton client. » Les AWS KMS principaux scénarios suivants peuvent entraîner l'affichage d'un `IdempotentParameterMismatch` message : + Vous spécifiez un ARN, un ID ou un alias de clé KMS non valide. Dans ce scénario, la tâche peut sembler être lancée avec succès, mais elle finit par échouer car elle AWS authentifie la clé KMS de manière asynchrone. Pour plus d’informations, consultez la section [Chiffrement Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) dans le *Guide de l’utilisateur Amazon EC2*. + Vous fournissez une clé gérée par le client qui ne dispose pas des autorisations permettant au rôle IAM d’infrastructure Amazon ECS d’utiliser la clé pour le chiffrement. Pour éviter les problèmes d'autorisation liés aux politiques clés, consultez l'exemple de politique AWS KMS clé dans la section [Chiffrement des données pour les volumes Amazon EBS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html#ebs-kms-encryption). Vous pouvez configurer Amazon EventBridge pour envoyer des événements de volume Amazon EBS et des événements de modification de l'état des tâches Amazon ECS à une cible, telle que CloudWatch des groupes Amazon. Vous pouvez ensuite utiliser ces événements pour identifier le problème spécifique lié aux clés gérées par le client qui a affecté l’attachement du volume. Pour plus d’informations, veuillez consulter la rubrique + [Comment créer un groupe de CloudWatch journaux à utiliser comme cible pour une EventBridge règle ?](https://repost.aws/knowledge-center/cloudwatch-log-group-eventbridge) sur AWS Re:post. + [Événements de modification de l’état de tâche](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html#ecs_task_events) + [ EventBridge Événements Amazon pour Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-cloud-watch-events.html) dans le guide de l'*utilisateur Amazon EBS*. ECS a dépassé le délai imparti lors de la configuration de l’attachement du volume EBS à votre tâche. Les scénarios suivants liés au format du système de fichiers entraînent l’affichage de ce message. + Le format du système de fichiers que vous spécifiez lors de la configuration n’est pas compatible avec le [système d’exploitation de la tâche](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RuntimePlatform.html). + Vous configurez un volume Amazon EBS pour qu’il soit créé à partir d’un instantané, et le format du système de fichiers de l’instantané n’est pas compatible avec le système d’exploitation de la tâche. Pour les volumes créés à partir d’un instantané, vous devez spécifier le même type de système de fichiers que celui utilisé par le volume lors de la création de l’instantané. Vous pouvez utiliser les journaux de l’agent de conteneur Amazon ECS pour résoudre les problèmes liés à ce message pour les tâches EC2. Pour plus d’informations, consultez les sections [Emplacements des fichiers journaux Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/logs.html) et [Collecteur de journaux Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-logs-collector.html). # Utilisation des volumes Amazon EFS avec Amazon ECS Amazon Elastic File System (Amazon EFS) fournit un stockage de fichiers simple et évolutif à utiliser avec vos tâches Amazon ECS. Avec Amazon EFS, la capacité de stockage est élastique. Elle augmente et diminue automatiquement au fil de vos ajouts et suppressions de fichiers. Vos applications peuvent disposer de l'espace de stockage qui leur est nécessaire, au moment où elles en ont besoin. Vous pouvez utiliser le système de fichiers Amazon EFS avec Amazon ECS pour exporter des données du système de fichiers dans l'ensemble de votre flotte d'instances de conteneur. Ainsi, vos tâches ont accès au même stockage permanent, quelle que soit l'instance sur laquelle elles se retrouvent. Vos définitions de tâche doivent faire référence aux montages des volumes de l'instance de conteneur pour utiliser le système de fichiers. Pour obtenir un didacticiel, consultez [Configuration des systèmes de fichiers Amazon EFS pour Amazon ECS à l’aide de la console](tutorial-efs-volumes.md). ## Considérations Tenez compte des éléments suivants lorsque vous utilisez des volumes Amazon EFS : + Pour les tâches qui s’exécutent sur EC2, la prise en charge du système de fichiers Amazon EFS a été ajoutée en tant que version préliminaire publique à l’AMI optimisée pour Amazon ECS version `20191212` et l’agent de conteneur version 1.35.0. Toutefois, elle a été rendue généralement disponible avec l'AMI optimisée pour Amazon ECS version `20200319` et l'agent de conteneur version 1.38.0, qui contenait les fonctions de point d'accès Amazon EFS et d'autorisation IAM. Nous vous recommandons d'utiliser la version `20200319` de l'AMI optimisée pour Amazon ECS ou une version ultérieure pour utiliser ces fonctions. Pour de plus amples informations, veuillez consulter [Linux optimisé pour Amazon ECS AMIs](ecs-optimized_AMI.md). **Note** Si vous créez votre propre AMI, vous devez utiliser l'agent de conteneur version 1.38.0 ou une version ultérieure, `ecs-init` version 1.38.0-1 ou une version ultérieure et exécuter les commandes suivantes sur votre instance Amazon EC2 pour activer le plug-in de volume Amazon ECS. Les commandes varient selon que vous utilisez Amazon Linux 2 ou Amazon Linux comme image de 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 ``` + Pour les tâches hébergées sur Fargate, les systèmes de fichiers Amazon EFS sont pris en charge sur la version 1.4.0 de la plateforme ou une version ultérieure (Linux). Pour de plus amples informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md). + Lorsque vous utilisez des volumes Amazon EFS pour des tâches hébergées sur Fargate, Fargate crée un conteneur de supervision chargé de la gestion du volume Amazon EFS. Le conteneur superviseur utilise une petite partie de la mémoire et de l’UC de la tâche. Le conteneur de supervision est visible lors de l'interrogation du point de terminaison de métadonnées de tâche version 4. En outre, il est visible dans CloudWatch Container Insights en tant que nom du conteneur`aws-fargate-supervisor`. Pour plus d’informations sur l’utilisation d’EC2, consultez la section [Point de terminaison des métadonnées de tâches Amazon ECS version 4](task-metadata-endpoint-v4.md). Pour plus d’informations sur l’utilisation de Fargate, consultez la section [Point de terminaison des métadonnées de tâches Amazon ECS version 4 pour les tâches sur Fargate](task-metadata-endpoint-v4-fargate.md). + L'utilisation de volumes Amazon EFS ou la spécification d'une `EFSVolumeConfiguration` n'est pas prise en charge sur les instances externes. + L’utilisation de volumes Amazon EFS est prise en charge pour les tâches exécutées sur des instances gérées Amazon ECS. + Nous vous recommandons de définir le paramètre `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION` dans le fichier de configuration de l'agent sur une valeur inférieure à la valeur par défaut (environ une heure). Cette modification permet d'éviter l'expiration des informations d'identification de montage EFS et permet le nettoyage des montages qui ne sont pas utilisés. Pour plus d'informations, consultez [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md). ## Utilisation des points d’accès Amazon EFS Les points d'accès Amazon EFS sont des points d'entrée spécifiques à l'application dans un système de fichiers EFS pour gérer l'accès des applications aux jeux de données partagés. Pour de plus amples informations sur les points d'accès Amazon EFS et sur la façon de les contrôler, veuillez consulter [Utilisation des points d'accès Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) dans le *Guide de l'utilisateur Amazon Elastic File System*. Les points d’accès peuvent appliquer de manière forcée une identité d’utilisateur, y compris les groupes POSIX de l’utilisateur, pour toutes les demandes de système de fichiers effectuées via le point d’accès. Les points d'accès peuvent également imposer un répertoire racine différent au système de fichiers. Cela permet aux clients d'accéder uniquement aux données stockées dans le répertoire spécifié ou dans ses sous-répertoires. **Note** Lors de la création d'un point d'accès EFS, spécifiez un chemin d'accès sur le système de fichiers qui servira de répertoire racine. Lorsque vous faites référence au système de fichiers EFS avec un ID de point d'accès dans votre définition de tâche Amazon ECS, le répertoire racine doit être omis ou défini sur `/` ce qui permet d'appliquer le chemin défini sur le point d'accès EFS. Vous pouvez utiliser le rôle IAM d'une tâche Amazon ECS pour imposer l'utilisation d'un point d'accès particulier par des applications spécifiques. En combinant des politiques IAM avec des points d'accès, vous pouvez fournir un accès sécurisé à des ensembles de données spécifiques pour vos applications. Pour plus d'informations sur l'utilisation des rôles IAM de tâche, consultez [rôle IAM de tâche Amazon ECS](task-iam-roles.md). # Pratiques exemplaires en matière d’utilisation des volumes Amazon EFS avec Amazon ECS Tenez compte des recommandations suivantes en matière de pratique exemplaire lorsque vous utilisez Amazon EFS avec Amazon ECS. ## Contrôles de sécurité et d’accès pour les volumes Amazon EFS Amazon EFS propose des fonctionnalités de contrôle d’accès que vous pouvez utiliser pour garantir que les données stockées dans un système de fichiers Amazon EFS sont sécurisées et accessibles uniquement depuis les applications qui en ont besoin. Vous pouvez sécuriser les données en activant le chiffrement au repos et en transit. Pour en savoir plus, consultez [Chiffrement des données dans Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) que vous trouverez dans le *guide de l’utilisateur Amazon Elastic File System*. Outre le chiffrement des données, vous pouvez également utiliser Amazon EFS pour restreindre l’accès à un système de fichiers. Vous pouvez implémenter le contrôle d’accès dans EFS de trois manières. + **Groupes de sécurité** : avec les cibles de montage Amazon EFS, vous pouvez configurer un groupe de sécurité utilisé pour autoriser ou refuser le trafic réseau. Vous pouvez configurer le groupe de sécurité associé à Amazon EFS afin d’autoriser le trafic NFS (port 2049) provenant du groupe de sécurité associé à vos instances Amazon ECS ou, lorsque vous utilisez le mode réseau `awsvpc`, à la tâche Amazon ECS. + **IAM** : vous pouvez restreindre l’accès à un système de fichiers Amazon EFS à l’aide d’IAM. Une fois configurées, les tâches Amazon ECS nécessitent un rôle IAM pour accéder au système de fichiers afin de monter un système de fichiers EFS. Pour plus d’informations, consultez la section [Utilisation d’IAM pour contrôler l’accès aux données du système de fichiers](https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html) dans le *Guide de l’utilisateur Amazon Elastic File System*. Les politiques IAM peuvent également appliquer des conditions prédéfinies, telles que l’obligation pour un client d’utiliser TLS lors de la connexion à un système de fichiers Amazon EFS. Pour plus d’informations, consultez la section [Clés de condition Amazon EFS pour les clients](https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html#efs-condition-keys-for-nfs) dans le *Guide de l’utilisateur Amazon Elastic File System*. + **Points d’accès Amazon EFS** : les points d’accès Amazon EFS sont des points d’entrée spécifiques à l’application dans un système de fichiers Amazon EFS. Vous pouvez utiliser des points d’accès pour imposer une identité utilisateur, y compris les groupes POSIX de l’utilisateur, pour toutes les requêtes du système de fichiers effectuées via le point d’accès. Les points d'accès peuvent également imposer un répertoire racine différent au système de fichiers. Cela permet aux clients d’accéder uniquement aux données stockées dans le répertoire spécifié ou dans ses sous-répertoires. ### politiques IAM Vous pouvez utiliser les politiques IAM pour contrôler l’accès au système de fichiers Amazon EFS. Vous pouvez spécifier les actions suivantes pour les clients sur un système de fichiers à l’aide d’une stratégie de système de fichiers. | Action | Description | | --- | --- | | `elasticfilesystem:ClientMount` | Fournit un accès en lecture seule à un système de fichiers. | | `elasticfilesystem:ClientWrite` | Fournit les droits d’écriture sur un système de fichiers. | | `elasticfilesystem:ClientRootAccess` | Permet d’utiliser l’utilisateur root lors de l’accès à un système de fichiers. | Vous devez spécifier chaque action dans une politique. Les politiques peuvent être définies comme suit : + Basé sur le client : attachez la politique au rôle de tâche Définissez l’option **Autorisation IAM** lorsque vous créez la définition de tâche. + Basé sur les ressources : attachez la politique au système de fichiers Amazon EFS Si la stratégie basée sur les ressources n’existe pas, l’accès est accordé par défaut à tous les principaux (\$1) lors de la création du système de fichiers. Lorsque vous définissez l’option **Autorisation IAM**, nous fusionnons la politique associée au rôle de tâche et la politique basée sur les ressources Amazon EFS. L’option **Autorisation IAM** transmet l’identité de la tâche (le rôle de la tâche) avec la politique à Amazon EFS. Cela permet à la politique basée sur les ressources Amazon EFS d’avoir un contexte pour l’utilisateur ou le rôle IAM spécifié dans la politique. Si vous ne définissez pas cette option, la politique au niveau des ressources Amazon EFS identifie l’utilisateur IAM comme « anonyme ». Envisagez d’implémenter les trois contrôles d’accès sur un système de fichiers Amazon EFS pour une sécurité maximale. Par exemple, vous pouvez configurer le groupe de sécurité attaché à un point de montage Amazon EFS pour n’autoriser que le trafic NFS entrant provenant d’un groupe de sécurité associé à votre instance de conteneur ou à votre tâche Amazon ECS. En outre, vous pouvez configurer Amazon EFS pour exiger un rôle IAM pour accéder au système de fichiers, même si la connexion provient d’un groupe de sécurité autorisé. Enfin, vous pouvez utiliser les points d’accès Amazon EFS pour imposer les autorisations des utilisateurs POSIX et spécifier des répertoires racines pour les applications. L’extrait de définition de tâche suivant illustre comment monter un système de fichiers Amazon EFS à l’aide d’un point d’accès. ``` "volumes": [ { "efsVolumeConfiguration": { "fileSystemId": "fs-1234", "authorizationConfig": { "accessPointId": "fsap-1234", "iam": "ENABLED" }, "transitEncryption": "ENABLED", "rootDirectory": "" }, "name": "my-filesystem" } ] ``` ## Performance des volumes Amazon EFS Amazon EFS propose deux modes de performance : les systèmes de I/O. General Purpose is suitable for latency-sensitive applications such as content management systems and CI/CD tools. In contrast, Max I/O fichiers General Purpose et Max conviennent aux charges de travail telles que l'analyse de données, le traitement multimédia et l'apprentissage automatique. Ces charges de travail doivent effectuer des opérations parallèles à partir de centaines, voire de milliers de conteneurs, et nécessitent un débit global et un nombre d’opérations d’entrée/sortie par seconde (IOPS) aussi élevés que possible. Pour plus d’informations, consultez la section [Modes de performances Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/performance.html#performancemodes) dans le *Guide de l’utilisateur Amazon Elastic File System*. Certaines charges de travail sensibles à la latence nécessitent à la fois les I/O niveaux les plus élevés fournis par le mode de I/O performance Max et les niveaux de latence plus faibles fournis par le mode de performance General Purpose. Pour ce type de charge de travail, nous vous recommandons de créer plusieurs systèmes de fichiers en mode de performance Usage général. De cette manière, vous pouvez répartir la charge de travail de vos applications sur tous ces systèmes de fichiers, à condition que la charge de travail et les applications le permettent. ## Débit des volumes Amazon EFS Tous les systèmes de fichiers Amazon EFS présentent un débit mesuré associé qui est déterminé soit par la quantité de débit alloué pour les systèmes de fichiers utilisant le *débit alloué*, soit par la quantité de données stockées dans la classe de stockage EFS Standard ou One Zone pour les systèmes de fichiers utilisant le *débit de débordement*. Pour plus d’informations, consultez la section [Compréhension du débit mesuré](https://docs.aws.amazon.com/efs/latest/ug/performance.html#read-write-throughput) dans le *Guide de l’utilisateur Amazon Elastic File System*. Le mode de débit par défaut pour les systèmes de fichiers Amazon EFS est le mode de débordement. Avec le mode de débordement, le débit disponible pour un système de fichiers augmente ou diminue au fur et à mesure que le système de fichiers grandit. Étant donné que les charges de travail basées sur des fichiers connaissent généralement des pics, nécessitant des niveaux de débit élevés pendant certaines périodes et des niveaux de débit plus faibles le reste du temps, Amazon EFS est conçu pour déborder afin d’autoriser des niveaux de débit élevés pendant certaines périodes. En outre, étant donné que de nombreuses charges de travail sont gourmandes en lecture, les opérations de lecture sont mesurées selon un ratio de 1:3 par rapport aux autres opérations NFS (comme l’écriture). Tous les systèmes de fichiers Amazon EFS fournissent une performance de référence constante de 50 MB/s  % pour chaque To de stockage Amazon EFS Standard ou Amazon EFS One Zone. Tous les systèmes de fichiers (quelle que soit leur taille) peuvent atteindre 100 MB/s. File systems with more than 1TB of EFS Standard or EFS One Zone storage can burst to 100 MB/s for each TB. Because read operations are metered at a 1:3 ratio, you can drive up to 300 MiBs/s pour chaque TiB de débit de lecture. Lorsque vous ajoutez des données à votre système de fichiers, le débit maximal disponible pour le système de fichiers évolue de manière linéaire et automatique en fonction de votre stockage dans la classe de stockage Amazon EFS Standard. Si vous avez besoin d’un débit supérieur à celui que vous pouvez obtenir avec la quantité de données stockées, vous pouvez configurer le débit alloué en fonction des besoins spécifiques de votre charge de travail. Le débit du système de fichiers est partagé entre toutes les instances Amazon EC2 connectées à un système de fichiers. Par exemple, un système de fichiers de 1 To capable d'atteindre 100 % MB/s de débit peut en piloter 100 à MB/s partir d'une seule instance Amazon EC2 pouvant chacune générer 10 Mo/s. Pour plus d’informations, consultez la section [Performances Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/performance.html) dans le *Guide de l’utilisateur Amazon Elastic File System*. ## Optimisation des coûts pour les volumes Amazon EFS Amazon EFS simplifie la mise à l’échelle du stockage pour vous. Les systèmes de fichiers Amazon EFS augmentent automatiquement au fur et à mesure que vous ajoutez des données. En particulier avec le mode de *débit de débordement* Amazon EFS, le débit sur Amazon EFS est mis à l’échelle à mesure que la taille de votre système de fichiers dans la classe de stockage standard augmente. Pour améliorer le débit sans payer de frais supplémentaires pour le débit alloué sur un système de fichiers EFS, vous pouvez partager un système de fichiers Amazon EFS avec plusieurs applications. À l’aide des points d’accès Amazon EFS, vous pouvez implémenter l’isolation du stockage dans les systèmes de fichiers Amazon EFS partagés. Ainsi, même si les applications partagent toujours le même système de fichiers, elles ne peuvent accéder aux données que si vous les y autorisez. Au fur et à mesure que vos données augmentent, Amazon EFS vous aide à déplacer automatiquement les fichiers rarement consultés vers une classe de stockage inférieure. La classe de stockage Amazon EFS Standard-Infrequent Access (IA) réduit les coûts de stockage pour les fichiers qui ne sont pas consultés quotidiennement. La haute disponibilité, la durabilité, l’élasticité et l’accès au système de fichiers POSIX fournis par Amazon EFS sont conservés. Pour plus d’informations, consultez la section [Classes de stockage EFS](https://docs.aws.amazon.com/efs/latest/ug/features.html) dans le *Guide de l’utilisateur Amazon Elastic File System*. Envisagez d’utiliser les stratégies de cycle de vie Amazon EFS pour réaliser automatiquement des économies en transférant les fichiers rarement consultés vers le stockage Amazon EFS IA. Pour plus d’informations, consultez [Gestion du cycle de vie Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html) dans le *guide de l’utilisateur Amazon Elastic File System*. Lorsque vous créez un système de fichiers Amazon EFS, vous pouvez choisir si Amazon EFS réplique vos données sur plusieurs zones de disponibilité (standard) ou les stocke de manière redondante dans une seule zone de disponibilité. La classe de stockage Amazon EFS One Zone permet de réduire considérablement les coûts de stockage par rapport aux classes de stockage Amazon EFS Standard. Envisagez d’utiliser la classe de stockage Amazon EFS One Zone pour les charges de travail ne nécessitant pas de résilience multi-AZ. Vous pouvez réduire davantage le coût du stockage Amazon EFS One Zone en déplaçant les fichiers rarement consultés vers Amazon EFS One Zone-Infrequent Access. Pour plus d'informations, veuillez consulter [Amazon EFS Infrequent Access](https://aws.amazon.com/efs/features/infrequent-access/). ## Protection des données des volumes Amazon EFS Amazon EFS stocke vos données de manière redondante dans plusieurs zones de disponibilité pour les systèmes de fichiers à l’aide de classes de stockage standard. Si vous sélectionnez les classes de stockage Amazon EFS One Zone, vos données sont stockées de manière redondante dans une seule zone de disponibilité. Amazon EFS est en outre conçu pour fournir 99,99999999999 % (11 9) de durabilité sur une année donnée. Comme dans tout environnement, il est recommandé de disposer d’une sauvegarde et de mettre en place des mesures de protection contre les suppressions accidentelles. Pour les données Amazon EFS, cette bonne pratique inclut une sauvegarde fonctionnelle et régulièrement testée à l'aide de AWS Backup. Les systèmes de fichiers utilisant les classes de stockage Amazon EFS One Zone sont configurés par défaut pour sauvegarder automatiquement les fichiers lors de la création du système de fichiers, sauf si vous choisissez de désactiver cette fonctionnalité. Pour plus d’informations, consultez la section [Sauvegarde des systèmes de fichiers EFS](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html) dans le *Guide de l’utilisateur Amazon Elastic File System*. # Spécification d’un système de fichiers Amazon EFS dans une définition de tâche Amazon ECS Pour utiliser des volumes de système de fichiers Amazon EFS pour vos conteneurs, vous devez spécifier les configurations de volume et de point de montage dans votre définition de tâche. L'extrait de JSON de définition de tâche indiqué ci-dessous illustre la syntaxe des objets `volumes` et `mountPoints` pour un conteneur. ``` { "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` Type : objet Obligatoire : non Ce paramètre est spécifié lorsque vous utilisez des volumes Amazon EFS. `fileSystemId` Type : Chaîne Obligatoire : oui ID du système de fichiers Amazon EFS à utiliser. `rootDirectory` Type : chaîne Obligatoire : non Répertoire du système de fichiers Amazon EFS à monter en tant que répertoire racine à l'intérieur de l'hôte. Si ce paramètre est omis, la racine du volume Amazon EFS est utilisée. La spécification de `/` a le même effet que l'omission de ce paramètre. Si un point d'accès EFS est spécifié dans `authorizationConfig`, le paramètre de répertoire racine doit être omis ou défini sur `/` ce qui permet d'appliquer le chemin défini sur le point d'accès EFS. `transitEncryption` Type : Chaîne Valeurs valides : `ENABLED` \$1 `DISABLED` Obligatoire : non Indique si vous souhaitez activer ou non le chiffrement des données Amazon EFS en transit entre l'hôte Amazon ECS et le serveur Amazon EFS. Si l'autorisation Amazon EFS IAM est utilisée, le chiffrement de transit doit être activé. Si ce paramètre est omis, la valeur par défaut `DISABLED` est utilisée. Pour plus d'informations, consultez [Chiffrement des données en transit](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html) dans le *Guide de l'utilisateur Amazon Elastic File System*. `transitEncryptionPort` Type : Integer Obligatoire : non Port à utiliser lors de l'envoi de données chiffrées entre l'hôte Amazon ECS et le serveur Amazon EFS. Si vous ne spécifiez pas de port de chiffrement en transit, il utilise la stratégie de sélection de port adoptée par l'assistant de montage Amazon EFS. Pour plus d'informations, consultez [Assistant de montage EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html) dans le *Guide de l'utilisateur Amazon Elastic File System User*. `authorizationConfig` Type : objet Obligatoire : non Détails de configuration des autorisations pour le système de fichiers Amazon EFS. `accessPointId` Type : chaîne Obligatoire : non ID du point d'accès à utiliser. Si un point d'accès est spécifié, la valeur du répertoire racine dans `efsVolumeConfiguration` doit être omise ou définie sur `/` qui applique le chemin défini sur le point d'accès EFS. Si un point d'accès est utilisé, le chiffrement de transit doit être activé dans `EFSVolumeConfiguration`. Pour plus d'informations, consultez [Utilisation des points d'accès Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) dans le *Guide de l'utilisateur Amazon Elastic File System*. `iam` Type : Chaîne Valeurs valides : `ENABLED` \$1 `DISABLED` Obligatoire : non Indique s'il faut ou non utiliser le rôle IAM de tâche Amazon ECS spécifié dans une définition de tâche lors du montage du système de fichiers Amazon EFS. Si cette option est activée, le chiffrement en transit doit être activé dans la configuration `EFSVolumeConfiguration`. Si ce paramètre est omis, la valeur par défaut `DISABLED` est utilisée. Pour plus d'informations, consultez [Rôles IAM pour les tâches](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html). # Configuration des systèmes de fichiers Amazon EFS pour Amazon ECS à l’aide de la console Découvrez comment utiliser les systèmes de fichiers Amazon Elastic File System (Amazon EFS) avec Amazon ECS. ## Étape 1 : Créer un cluster Amazon ECS Pour créer un cluster Amazon ECS, effectuez les étapes suivantes. **Pour créer un nouveau cluster (console Amazon ECS)** Avant de commencer, attribuez l'autorisation IAM adéquate. Pour de plus amples informations, veuillez consulter [Exemples de cluster Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies). 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans la barre de navigation, sélectionnez la région à utiliser. 1. Dans le panneau de navigation, choisissez **Clusters**. 1. Sur la page **Clusters**, choisissez **Create Cluster** (Créer un cluster). 1. Sous **Cluster configuration** (Configuration de cluster), dans **Cluster name** (Nom du cluster), saisissez `EFS-tutorial`. 1. (Facultatif) Pour modifier le VPC et les sous-réseaux d'où vos tâches et services se lancent, sous **Networking** (Réseaux), effectuez l'une des opérations suivantes : + Pour supprimer un sous-réseau, sous **Subnets** (Sous-réseaux), choisissez **X** pour chaque sous-réseau que vous souhaitez supprimer. + Pour passer à un VPC autre celui par **défaut**, sous **VPC**, choisissez un **VPC** existant, puis sous **Subnets** (Sous-réseaux), sélectionnez chaque sous-réseau. 1. Pour ajouter des instances Amazon EC2 à votre cluster, développez **Infrastructure**, puis sélectionnez **Instances Amazon EC2**. Ensuite, configurez le groupe Auto Scaling qui agit en tant que fournisseur de capacité : 1. Pour créer un groupe Auto Scaling, depuis **Auto Scaling group (ASG)** (Groupe Auto Scaling [ASG]), sélectionnez **Create new group** (Créer un nouveau groupe), puis fournissez les détails suivants sur le groupe : + Pour **Operating system/Architecture** (Système d'exploitation/Architecture), choisissez Amazon Linux 2. + Dans **EC2 instance type** (Type d'instance EC2), choisissez `t2.micro`. Pour **SSH key pair** (Paire de clés SSH), choisissez la paire qui prouve votre identité lorsque vous connectez à l'instance. + Dans le champ **Capacité**, entrez `1`. 1. Choisissez **Créer**. ## Étape 2 : créer un groupe de sécurité pour des instances Amazon EC2 et le système de fichiers Amazon EFS Lors de cette étape, vous créez un groupe de sécurité pour vos instances Amazon EC2 autorisant le trafic réseau entrant sur le port 80 et pour votre système de fichiers Amazon EFS autorisant l'accès entrant depuis vos instances de conteneur. Créez un groupe de sécurité pour vos instances Amazon EC2 avec les options suivantes : + **Nom du groupe de sécurité** : un nom unique pour votre groupe de sécurité. + **VPC** : le VPC identifié précédemment pour votre cluster. + **Règle entrante** + **Type** : **HTTP**. + **Source** : **0.0.0.0/0**. Créez un groupe de sécurité pour votre système de fichiers Amazon EFS avec les options suivantes : + **Nom du groupe de sécurité** : un nom unique pour votre groupe de sécurité. Par exemple, `EFS-access-for-sg-dc025fa2`. + **VPC** : le VPC identifié précédemment pour votre cluster. + **Règle entrante** + **Type** : **NFS**. + **Source** : **personnalisée** avec l'ID du groupe de sécurité que vous avez créé pour vos instances. Pour plus d’informations sur la création d’un groupe de sécurité, consultez la section [Création d’un groupe de sécurité pour votre instance Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-security-group.html) dans le *Guide de l’utilisateur Amazon EC2*. ## Étape 3 : Créer un système de fichiers Amazon EFS Dans cette étape, vous créez un système de fichiers Amazon EFS. **Pour créer un système de fichiers Amazon EFS pour des tâches Amazon ECS.** 1. Ouvrez la console Amazon Elastic File System à l'adresse [https://console.aws.amazon.com/efs/](https://console.aws.amazon.com/efs/). 1. Choisissez **Create file system** (Créer un système de fichiers). 1. Saisissez un nom pour votre système de fichiers, puis choisissez le VPC dans lequel vos instances de conteneur sont hébergées. Par défaut, chaque sous-réseau du VPC spécifié reçoit une cible de montage qui utilise le groupe de sécurité par défaut de ce VPC. Choisissez ensuite **Personnaliser**. **Note** Ce didacticiel part du principe que votre système de fichiers Amazon EFS, votre cluster Amazon ECS, vos instances de conteneur et vos tâches se trouvent dans le même VPC. Pour plus d’informations sur le montage d’un système de fichiers à partir d’un autre VPC, consultez la section [Procédure pas à pas : montage d’un système de fichiers à partir d’un autre VPC](https://docs.aws.amazon.com/efs/latest/ug/efs-different-vpc.html) dans le *Guide de l’utilisateur Amazon EFS*. 1. Sur la page **Paramètres du système de fichiers**, configurez les paramètres facultatifs, puis sous **Paramètres de performance**, choisissez le mode de débit **Transmission en rafales** pour votre système de fichiers. Après avoir configuré les paramètres, sélectionnez **Suivant**. 1. (Facultatif) Ajoutez des étiquettes pour votre système de fichiers. Par exemple, vous pouvez spécifier un nom unique pour le système de fichiers en entrant ce nom dans la colonne **Valeur** en regard de la clé **Nom**. 1. (Facultatif) Activez la gestion du cycle de vie pour économiser de l'argent sur un stockage rarement utilisé. Pour en savoir plus, consultez la section [Gestion du cycle de vie EFS](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html) du *Amazon Elastic File System User Guide*. 1. (Facultatif) Activez le chiffrement. Cochez la case pour activer le chiffrement de votre système de fichiers Amazon EFS au repos. 1. Sur la page **Accès réseau**, sous **Monter les cibles**, remplacez la configuration de groupe de sécurité existante de chaque zone de disponibilité par le groupe de sécurité que vous avez créé pour le système de fichiers dans [Étape 2 : créer un groupe de sécurité pour des instances Amazon EC2 et le système de fichiers Amazon EFS](#efs-security-group), puis choisissez **Suivant**. 1. Il n'est pas nécessaire de configurer la **Stratégie de système de fichiers** pour ce didacticiel. Vous pouvez donc ignorer la section en choisissant **Suivant**. 1. Vérifiez les options de votre système de fichiers et choisissez **Créer** pour terminer le processus. 1. Sur l'écran **Systèmes de fichiers**, enregistrez l'**ID du système de fichiers**. À l'étape suivante, vous référencerez cette valeur dans votre définition de tâche Amazon ECS. ## Étape 4 : Ajouter du contenu au système de fichiers Amazon EFS Au cours de cette étape, vous monterez le système de fichiers Amazon EFS sur une instance Amazon EC2 et y ajouterez du contenu. Cette opération servira à tester la nature persistante des données dans ce didacticiel. Lorsque vous utilisez cette fonction, vous avez normalement votre application ou une autre méthode d'écriture de données dans votre système de fichiers Amazon EFS. **Pour créer une instance Amazon EC2 et monter le système de fichiers Amazon EFS** 1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Choisissez **Launch Instances** (Lancer les instances). 1. Sous **Images d'applications et de systèmes d'exploitation (Amazon Machine Image)**, sélectionnez l'**AMI Amazon Linux 2 (HVM)**. 1. Sous **Type d'instance**, conservez le type d'instance par défaut `t2.micro`. 1. Sous **Paire de clés (connexion)**, sélectionnez une paire de clés pour l'accès SSH à l'instance. 1. Sous **Paramètres réseau**, sélectionnez le VPC que vous avez spécifié pour votre système de fichiers Amazon EFS et votre cluster Amazon ECS. Sélectionnez un sous-réseau et le groupe de sécurité d'instance créé dans [Étape 2 : créer un groupe de sécurité pour des instances Amazon EC2 et le système de fichiers Amazon EFS](#efs-security-group). Configurez le groupe de sécurité de l'instance. Assurez-vous que **Attribuer automatiquement l'adresse IP publique** est activé. 1. Sous **Configurer le stockage**, cliquez sur le bouton **Modifier** pour les systèmes de fichiers, puis choisissez **EFS**. Sélectionnez le système de fichiers créé dans [Étape 3 : Créer un système de fichiers Amazon EFS](#efs-create-filesystem). Vous pouvez éventuellement modifier le point du montage ou conserver la valeur par défaut. **Important** Vous devez sélectionner un sous-réseau avant de pouvoir ajouter un système de fichiers à l'instance. 1. Désactivez **Créer et associer automatiquement des groupes de sécurité**. Laissez l'autre case cochée. Choisissez **Add shared file system** (Ajouter un système de fichiers partagé). 1. Sous **Advanced Details (Détails avancés)**, assurez-vous que le script de données utilisateur est renseigné automatiquement avec les étapes de montage du système de fichiers Amazon EFS. 1. Sous **Récapitulatif**, assurez-vous que le **Nombre d'instances** est égal à **1**. Choisissez **Launch instance** (Lancer une instance). 1. Sur la page **Lancer une instance**, choisissez **Afficher toutes les instances** pour afficher l'état de vos instances. Initialement, le statut d'**État de l'instance** est `PENDING`. Une fois que l'état est passé à `RUNNING` et que l'instance a réussi toutes les vérifications de statut, celle-ci est prête à être utilisée. Maintenant, connectez-vous à l'instance Amazon EC2 et ajoutez du contenu au système de fichiers Amazon EFS. **Pour vous connecter à l'instance Amazon EC2 et ajouter du contenu au système de fichiers Amazon EFS** 1. Envoyez une requête SSH à l'instance Amazon EC2 que vous avez créée. Pour plus d’informations, consultez la section [Connexion à votre instance Linux à l’aide de SSH](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html) dans le *Guide de l’utilisateur Amazon EC2*. 1. Dans la fenêtre du terminal, exécutez la commande **df -T** pour vérifier que le système de fichiers Amazon EFS est bien monté. Dans la sortie suivante, nous avons mis en évidence le montage du système de fichiers 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. Accédez au répertoire dans lequel le système de fichiers Amazon EFS est monté. Dans l'exemple ci-dessus, il s'agit de `/mnt/efs/fs1`. 1. Créez un fichier nommé `index.html` avec le contenu suivant: ```

It Works!

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

``` ## Étape 5 : Créer une définition de tâche La définition de tâche suivante crée un volume de données nommé `efs-html`. Le conteneur `nginx` monte le volume de données de l'hôte à la racine NGINX, `/usr/share/nginx/html`. **Pour créer une nouvelle définition de tâche à l'aide de la console Amazon ECS** 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans le panneau de navigation, choisissez **Task definitions** (Définition des tâches). 1. Choisissez **Create new task definition** (Créer une nouvelle définition de tâche), puis **Create new task definition with JSON** (Créer une nouvelle définition de tâche avec JSON). 1. Dans la zone de l'éditeur JSON, copiez et collez le texte JSON suivant, en remplaçant `fileSystemId` par l'ID de votre système de fichiers 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" } ``` **Note** Le rôle IAM d’exécution de tâche Amazon ECS ne nécessite aucune autorisation spécifique liée à Amazon EFS pour monter un système de fichiers Amazon EFS. Par défaut, s’il n’existe aucune politique basée sur les ressources Amazon EFS, l’accès est accordé à tous les principaux (\$1) lors de la création du système de fichiers. Le rôle de tâche Amazon ECS n’est requis que si l’option « Autorisation IAM EFS » est activée dans la définition de tâche Amazon ECS. Lorsque cette option est activée, l’identité du rôle de la tâche doit être autorisée à accéder au système de fichiers Amazon EFS conformément à la politique basée sur les ressources Amazon EFS, et l’accès anonyme doit être désactivé. 1. Choisissez **Créer**. ## Étape 6 : Exécuter une tâche et afficher les résultats Maintenant que votre système de fichiers Amazon EFS est créé et qu'il existe du contenu web pour le conteneur NGINX à diffuser, vous pouvez exécuter une tâche à l'aide de la définition de tâche que vous avez créée. Le serveur web NGINX diffuse votre page HTML simple. Si vous mettez à jour le contenu de votre système de fichiers Amazon EFS, ces changements sont propagés vers tous les conteneurs qui ont également monté ce système de fichiers. La tâche s'exécute dans le sous-réseau que vous avez défini pour le cluster. **Pour exécuter une tâche et afficher les résultats à l'aide de la console** 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Sur la page **Clusters**, sélectionnez le cluster dans lequel la tâche autonome doit s'exécuter. Déterminez la ressource à partir de laquelle vous lancez le service. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/tutorial-efs-volumes.html) 1. (Facultatif) Choisissez comment votre tâche planifiée est distribuée dans votre infrastructure de cluster. Développer **Compute configuration** (Configuration de calcul), puis procédez comme suit : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/tutorial-efs-volumes.html) 1. Pour **Application type (Type d'application)**, choisissez **Task (Tâche)**. 1. Pour **Task Definition** (Définition de tâche), choisissez la définition de tâche `efs-tutorial` que vous avez créée précédemment. 1. Pour **Desired tasks** (Tâches souhaitées), saisissez `1`. 1. Choisissez **Créer**. 1. Sur la page **Cluster**, choisissez **Infrastructure**. 1. Sous **Instances de conteneur**, sélectionnez l'instance de conteneur à laquelle vous connecter. 1. Sur la page **Container Instance** (Instance de conteneur), sous **Networking** (Mise en réseau), enregistrez **Public IP** (IP publique) pour votre instance. 1. Ouvrez un navigateur et saisissez l'adresse IP publique. Vous devez voir le message suivant : ``` It works! You are using an Amazon EFS file system for persistent container storage. ``` **Note** Si le message ne s'affiche pas, assurez-vous que le groupe de sécurité de votre instance de conteneur autorise le trafic réseau entrant sur le port 80 et que le groupe de sécurité de votre système de fichiers autorise l'accès entrant depuis l'instance de conteneur. # Utilisation FSx pour les volumes de serveurs de fichiers Windows avec Amazon ECS FSx pour Windows File Server fournit des serveurs de fichiers Windows entièrement gérés, soutenus par un système de fichiers Windows. Lorsque vous utilisez FSx for Windows File Server avec ECS, vous pouvez fournir à vos tâches Windows un stockage de fichiers statique persistant, distribué, partagé et statique. Pour plus d'informations, voir [Qu'est-ce que FSx pour le serveur de fichiers Windows ?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) . **Note** Les instances EC2 qui utilisent l'AMI complète Windows Server 2016 optimisée pour Amazon ECS ne prennent pas en charge FSx les volumes de tâches ECS du serveur de fichiers Windows. Vous ne pouvez pas FSx les utiliser pour les volumes du serveur de fichiers Windows dans une configuration de conteneurs Windows sur Fargate. Au lieu de cela, vous pouvez [modifier les conteneurs pour les monter au démarrage](https://aws.amazon.com/blogs/containers/use-smb-storage-with-windows-containers-on-aws-fargate/). Vous pouvez utiliser Windows File Server FSx pour déployer des charges de travail Windows nécessitant un accès à un espace de stockage externe partagé, à un stockage régional à haute disponibilité ou à un stockage à haut débit. Vous pouvez monter un ou plusieurs volumes de système de fichiers FSx pour Windows File Server sur un conteneur Amazon ECS qui s'exécute sur une instance Windows Amazon ECS. Vous pouvez partager FSx des volumes de système de fichiers pour Windows File Server entre plusieurs conteneurs Amazon ECS dans le cadre d'une seule tâche Amazon ECS. Pour permettre l'utilisation de FSx for Windows File Server avec ECS, incluez l'ID du système de fichiers FSx pour Windows File Server et les informations associées dans une définition de tâche. Il s'agit de l'extrait de code JSON de définition de tâche suivant. Avant de créer et d'exécuter une définition de tâche, vous avez besoin des éléments suivants. + Une instance ECS Windows EC2 jointe à un domaine valide. Elle peut être hébergée par [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html), Active Directory sur site ou Active Directory autohébergé sur Amazon EC2. + Paramètre AWS Secrets Manager secret ou Systems Manager contenant les informations d'identification utilisées pour rejoindre le domaine Active Directory et attacher le FSx système de fichiers Windows File Server. Les valeurs d'informations d'identification sont les informations d'identification de nom et de mot de passe que vous avez entrées lors de la création de l'Active Directory. Pour voir un didacticiel connexe, consultez [Découvrez comment configurer FSx les systèmes de fichiers Windows File Server pour Amazon ECS](tutorial-wfsx-volumes.md). ## Considérations Tenez compte des points suivants lors de l' FSx utilisation de volumes de serveurs de fichiers Windows : + Les volumes FSx for Windows File Server sont pris en charge de manière native avec Amazon ECS sur les instances Amazon EC2 Windows. Amazon ECS gère automatiquement le montage via la configuration de définition des tâches. Sur les instances Amazon EC2 Linux, Amazon ECS ne peut pas monter automatiquement les volumes FSx for Windows File Server via des définitions de tâches. Cependant, vous pouvez monter manuellement un partage de fichiers FSx for Windows File Server sur une instance Linux EC2 au niveau de l'hôte, puis monter ce chemin dans vos conteneurs Amazon ECS. Pour plus d'informations, consultez la section [Montage des partages de FSx fichiers Amazon depuis Linux](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/map-shares-linux.html). **Important** Il s'agit d'une configuration autogérée. Pour obtenir des conseils sur le montage et la maintenance FSx des partages de fichiers Windows File Server sous Linux, reportez-vous à la [FSx documentation relative au serveur de fichiers Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/). **Important** Lors de l'utilisation d'un partage FSx for Windows File Server monté manuellement sur des instances Linux EC2, Amazon ECS FSx et Windows File Server fonctionnent indépendamment. Amazon ECS ne surveille pas le montage FSx Amazon FSx et pour Windows File Server ne suit pas le placement des tâches ou les événements du cycle de vie Amazon ECS. Vous êtes chargé de garantir l'accessibilité du réseau entre vos instances de conteneur Amazon ECS et le système de FSx fichiers Amazon, de mettre en œuvre des contrôles de santé du montage et de gérer la logique de reconnexion afin de tolérer les événements de basculement. + FSx pour Windows File Server avec Amazon ECS n'est pas pris en charge AWS Fargate. + FSx pour Windows File Server avec Amazon ECS n'est pas pris en charge sur les instances gérées Amazon ECS. + FSx pour Windows File Server avec Amazon ECS en mode `awsvpc` réseau, nécessite une version `1.54.0` ou une version ultérieure de l'agent de conteneur. + Le nombre maximal de lettres de lecteur pouvant être utilisées pour une tâche Amazon ECS est de 23. Une lettre de lecteur est attribuée FSx à chaque tâche comportant un volume destiné au serveur de fichiers Windows. + Par défaut, le temps de nettoyage des ressources de tâches est de trois heures après la fin de la tâche. Même si aucune tâche ne l'utilise, un mappage de fichier créé par une tâche persiste pendant trois heures. La durée de nettoyage par défaut peut être configurée à l'aide de la variable d'environnement Amazon ECS `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`. Pour de plus amples informations, veuillez consulter [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md). + Les tâches s'exécutent généralement uniquement dans le même VPC que le système FSx de fichiers Windows File Server. Cependant, il est possible de bénéficier d'un support inter-VPC s'il existe une connectivité réseau établie entre le VPC du cluster Amazon ECS et le système de fichiers FSx pour Windows File Server via le peering VPC. + Vous contrôlez l'accès à un système de fichiers FSx for Windows File Server au niveau du réseau en configurant les groupes de sécurité VPC. Seules les tâches hébergées sur des instances EC2 associées au domaine Active Directory avec des groupes de sécurité Active Directory correctement configurés peuvent accéder au partage de fichiers FSx pour Windows File Server. Si les groupes de sécurité sont mal configurés, Amazon ECS ne parvient pas à lancer la tâche et affiche le message d’erreur suivant : « `unable to mount file system fs-id`. » + FSx pour Windows File Server est intégré à Gestion des identités et des accès AWS (IAM) pour contrôler les actions que vos utilisateurs et groupes IAM peuvent effectuer spécifiquement FSx pour les ressources du serveur de fichiers Windows. Avec l'autorisation du client, les clients peuvent définir des rôles IAM qui autorisent ou refusent l'accès à FSx des systèmes de fichiers spécifiques à Windows File Server, exigent éventuellement un accès en lecture seule et autorisent ou interdisent au client l'accès root au système de fichiers. Pour plus d'informations, consultez [la section Sécurité](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/security.html) dans le guide de l'utilisateur Amazon FSx Windows. # Bonnes pratiques d'utilisation FSx pour Windows File Server avec Amazon ECS Prenez note des recommandations de bonnes pratiques suivantes lorsque vous utilisez FSx un serveur de fichiers Windows avec Amazon ECS. ## Sécurité et contrôles d'accès FSx pour Windows File Server FSx pour Windows File Server propose les fonctionnalités de contrôle d'accès suivantes que vous pouvez utiliser pour garantir que les données stockées dans un système de fichiers FSx pour Windows File Server sont sécurisées et accessibles uniquement depuis les applications qui en ont besoin. ### Chiffrement des données FSx pour les volumes du serveur de fichiers Windows FSx pour Windows File Server prend en charge deux formes de chiffrement pour les systèmes de fichiers. Il s’agit du chiffrement des données en transit et du chiffrement au repos. Le chiffrement des données en transit est pris en charge sur les partages de fichiers mappés sur une instance de conteneur compatible avec le protocole SMB 3.0 ou une version ultérieure. Le chiffrement des données au repos est automatiquement activé lors de la création d'un système de FSx fichiers Amazon. Amazon chiffre FSx automatiquement les données en transit à l'aide du chiffrement SMB lorsque vous accédez à votre système de fichiers sans avoir à modifier vos applications. Pour plus d'informations, consultez la section [Chiffrement des données sur Amazon FSx dans](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/encryption.html) le *guide de l'utilisateur du serveur de fichiers Amazon FSx pour Windows*. ### Utiliser Windows ACLs pour le contrôle d'accès au niveau des dossiers L'instance Windows Amazon EC2 accède aux partages de FSx fichiers Amazon à l'aide des informations d'identification Active Directory. Il utilise des listes de contrôle d'accès Windows standard (ACLs) pour un contrôle d'accès précis au niveau des fichiers et des dossiers. Vous pouvez créer plusieurs informations d’identification, chacune correspondant à un dossier spécifique au sein du partage qui est mappé à une tâche spécifique. Dans l’exemple suivant, la tâche a accès au dossier `App01` à l’aide d’informations d’identification enregistrées dans Secrets Manager. Son Amazon Resource Name (ARN) est `1234`. ``` "rootDirectory": "\\path\\to\\my\\data\App01", "credentialsParameter": "arn-1234", "domain": "corp.fullyqualified.com", ``` Dans un autre exemple, une tâche a accès au dossier `App02` à l’aide d’informations d’identification enregistrées dans Secrets Manager. Son ARN est `6789`. ``` "rootDirectory": "\\path\\to\\my\\data\App02", "credentialsParameter": "arn-6789", "domain": "corp.fullyqualified.com", ``` # Spécifiez un système de fichiers FSx pour Windows File Server dans une définition de tâche Amazon ECS À utiliser FSx pour les volumes du système de fichiers Windows File Server pour vos conteneurs, spécifiez les configurations de volume et de point de montage dans votre définition de tâche. L'extrait de JSON de définition de tâche indiqué ci-dessous illustre la syntaxe des objets `volumes` et `mountPoints` pour un conteneur. ``` { "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` Type : objet Obligatoire : non Ce paramètre est spécifié lorsque vous utilisez FSx le système de [fichiers Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) pour le stockage des tâches. `fileSystemId` Type : Chaîne Obligatoire : oui L' FSx identifiant du système de fichiers Windows File Server à utiliser. `rootDirectory` Type : Chaîne Obligatoire : oui Le répertoire du système FSx de fichiers Windows File Server à monter en tant que répertoire racine sur l'hôte. `authorizationConfig` `credentialsParameter` Type : Chaîne Obligatoire : oui Les options d'informations d'identification d'autorisation : + Amazon Resource Name (ARN) pour un secret [Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html). + Amazon Resource Name (ARN) pour un paramètre [Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html). `domain` Type : Chaîne Obligatoire : oui Un nom de domaine complet hébergé par un répertoire [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) (AWS Managed Microsoft AD) ou un Active Directory EC2 autohébergé. ## Méthodes de stockage des informations d'identification de volume FSx pour le serveur de fichiers Windows Il existe deux méthodes différentes de stockage des informations d'identification à utiliser avec le paramètre d'informations d'identification. + **AWS Secrets Manager secret** Ces informations d'identification peuvent être créées dans la AWS Secrets Manager console à l'aide de la catégorie *Autre type de secret*. Vous ajoutez une ligne pour chaque key/value paire username/admin et un mot de passe/*password*. + **Paramètre Systems Manager** Ces informations d'identification peuvent être créées dans la console de paramètres Systems Manager en saisissant du texte dans le formulaire qui se trouve dans l'exemple d'extrait de code suivant. ``` { "username": "admin", "password": "password" } ``` Le paramètre `credentialsParameter` dans la définition de tâche `FSxWindowsFileServerVolumeConfiguration` contient l'ARN de secret ou l'ARN du paramètre Systems Manager. Pour de plus amples informations, veuillez consulter les rubriques [Présentation d' AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) dans le *Guide de l'utilisateur de Secrets Manager* et [Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) dans le *Guide de l'utilisateur de Systems Manager*. # Découvrez comment configurer FSx les systèmes de fichiers Windows File Server pour Amazon ECS Découvrez comment lancer une instance Windows optimisée pour Amazon ECS qui héberge un système de fichiers FSx pour Windows File Server et des conteneurs pouvant accéder au système de fichiers. Pour ce faire, vous devez d'abord créer un Microsoft Active Directory Directory Service AWS géré. Créez ensuite un système de fichiers FSx for Windows File Server et un cluster avec une instance Amazon EC2 et une définition de tâche. Vous configurez la définition de tâche pour vos conteneurs afin qu'ils utilisent le système de fichiers FSx for Windows File Server. Enfin, vous testez le système de fichiers. Cela prend 20 à 45 minutes chaque fois que vous lancez ou supprimez le système FSx de fichiers Active Directory ou Windows File Server. Préparez-vous à réserver au moins 90 minutes pour terminer le didacticiel ou le compléter en quelques sessions. ## Prérequis pour le didacticiel + Un utilisateur administratif. Consultez [Configurer l'utilisation d'Amazon ECS](get-set-up-for-amazon-ecs.md). + (Facultatif) Une paire de clés `PEM` permettant de vous connecter à votre instance Windows EC2 via un accès RDP. Pour plus d’informations sur la création de paires de clés, consultez les sections [Paires de clés Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) et *Instances Amazon EC2* dans le Guide de l’utilisateur Amazon EC2. + Un VPC avec au moins un sous-réseau public et un sous-réseau privé et un groupe de sécurité. Vous pouvez utiliser votre VPC par défaut. Vous n'avez pas besoin d'une passerelle ou d'un périphérique NAT. Directory Service ne prend pas en charge la traduction d'adresses réseau (NAT) avec Active Directory. Pour que cela fonctionne, le répertoire Active Directory, le système de fichiers FSx for Windows File Server, le cluster ECS et l'instance EC2 doivent se trouver dans votre VPC. Pour plus d'informations concernant VPCs Active Directories, voir [Création d'un VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) et [Conditions préalables à la création d'un AWS Microsoft AD géré](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html#ms_ad_getting_started_prereqs). + Les autorisations IAM ecsInstanceRole et ecsTaskExecution Role sont associées à votre compte. Ces rôles liés à un service permettent aux services d'effectuer des appels d'API et d'accéder aux conteneurs, secrets, répertoires et serveurs de fichiers en votre nom. ## Étape 1 : Créer des rôles IAM d'accès **Créez un cluster avec la AWS Management Console.** 1. Vérifiez si vous en avez un ecsInstanceRole et comment vous pouvez en créer un si vous n'en avez pas. [Rôle IAM d'instance de conteneur Amazon ECS](instance_IAM_role.md) 1. Nous recommandons que les stratégies de rôle soient personnalisées pour les autorisations minimales dans un environnement de production réel. Pour suivre ce didacticiel, vérifiez que la politique AWS gérée suivante est attachée à votreecsInstanceRole. Joignez la stratégie si elle n'est pas déjà attachée. + EC2ContainerServiceforEC2Rôle Amazon + Amazon SSMManaged InstanceCore + Amazon SSMDirectory ServiceAccess Pour associer des politiques AWS gérées. 1. Ouvrez la [console IAM](https://console.aws.amazon.com//iam/). 1. Dans le panneau de navigation, choisissez **Rôles**. 1. Choisissez un **rôle géré par AWS **. 1. Choisissez **Autorisations, Attacher des stratégies**. 1. Pour réduire le nombre de stratégies disponibles à attacher, utilisez **Filter (Filtrer)**. 1. Sélectionnez la stratégie appropriée, puis choisissez **Attach policy (Attacher la stratégie)**. 1. Consultez [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md) pour vérifier si vous avez un ecsTaskExecution rôle et comment vous pouvez en créer un si vous n'en avez pas. Nous recommandons que les stratégies de rôle soient personnalisées pour les autorisations minimales dans un environnement de production réel. Pour suivre ce didacticiel, vérifiez que les politiques AWS gérées suivantes sont associées à votre ecsTaskExecution rôle. Attachez les stratégies si elles ne sont pas déjà attachées. Utilisez la procédure décrite dans la section précédente pour associer les politiques AWS gérées. + SecretsManagerReadWrite + Amazon FSx ReadOnlyAccess + Amazon SSMRead OnlyAccess + Amazon ECSTask ExecutionRolePolicy ## Étape 2 : Créer un Active Directory (AD) Windows 1. Suivez les étapes décrites dans la section [Création de votre Microsoft AD AWS géré](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html#ms_ad_getting_started_create_directory) dans le *Guide d'administration du AWS Directory Service*. Utilisez le VPC que vous avez désigné pour ce didacticiel. À l'étape 3 de la *création de votre Microsoft AD AWS géré*, enregistrez le nom d'utilisateur et le mot de passe administrateur à utiliser lors de l'étape suivante. Notez également le nom DNS complet du répertoire pour les prochaines étapes. Vous pouvez réaliser l’étape suivante pendant la création d’Active Directory. 1. Créez un AWS secret du Gestionnaire de Secrets à utiliser dans les étapes suivantes. Pour plus d'informations, voir [Commencer à utiliser Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html#get-started) dans le *Guide de l'utilisateur de AWS Secrets Manager*. 1. Ouvrez la [console Secrets Manager](https://console.aws.amazon.com//secretsmanager/). 1. Cliquez sur **Store a new secret (Stocker un nouveau secret)**. 1. Sélectionnez **Other type of secrets (Autres types de secrets)**. 1. Pour **Secret key/value (Valeur clé secrète)** dans la première ligne, créez une clé **username** avec la valeur **admin**. Cliquez sur **\$1 Add row (\$1 Ajouter une ligne)**. 1. Dans la nouvelle ligne, créez une clé **password**. Pour obtenir de la valeur, saisissez le mot de passe que vous avez saisi à l'étape 3 de la *section Création de votre annuaire AD AWS géré*. 1. Cliquez sur **Next (Suivant)**. 1. Fournissez un nom et une description de secret. Cliquez sur **Suivant**. 1. Cliquez sur **Suivant**. Cliquez sur **Store (Stocker)**. 1. À partir de la page **Secrets**, cliquez sur le secret que vous venez de créer. 1. Enregistrez l'ARN du nouveau secret pour l'utiliser dans les étapes suivantes. 1. Vous pouvez passer à l'étape suivante pendant la création de votre répertoire Active Directory. ## Étape 3 : Vérifier et mettre à jour votre groupe de sécurité Dans cette étape, vous vérifiez et mettez à jour les règles du groupe de sécurité que vous utilisez. Pour cela, vous pouvez utiliser le groupe de sécurité par défaut qui a été créé pour votre VPC. **Vérifiez et mettez à jour le groupe de sécurité.** Vous devez créer ou modifier votre groupe de sécurité pour envoyer des données depuis et vers les ports, comme indiqué dans la section [Groupes de sécurité Amazon VPC](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/limit-access-security-groups.html#fsx-vpc-security-groups) du guide de l'*utilisateur FSx pour les serveurs de fichiers Windows*. Pour ce faire, créez la règle entrante du groupe de sécurité affichée dans la première ligne du tableau suivant des règles entrantes. Cette règle autorise le trafic entrant à partir d'interfaces réseau (et de leurs instances associées) affectées au groupe de sécurité. Toutes les ressources cloud que vous créez se trouvent au sein du même VPC et sont rattachées au même groupe de sécurité. Par conséquent, cette règle permet d'envoyer du trafic vers et FSx depuis le système de fichiers Windows File Server, Active Directory et l'instance ECS selon les besoins. Les autres règles entrantes autorisent le trafic à servir le site web et l'accès RDP pour la connexion à votre instance ECS. Le tableau suivant indique les règles entrantes de groupe de sécurité requises pour ce didacticiel. | Type | Protocole | Plage de ports | Source | | --- | --- | --- | --- | | Tout le trafic | Tous | Tous | *sg-securitygroup* | | HTTPS | TCP | 443 | 0.0.0.0/0 | | RDP | TCP | 3389 | l'adresse IP de votre ordinateur portable | Le tableau suivant indique les règles sortantes du groupe de sécurité requises pour ce didacticiel. | Type | Protocole | Plage de ports | Destination | | --- | --- | --- | --- | | Tout le trafic | Tous | Tous | 0.0.0.0/0 | 1. Ouvrez la [console EC2](https://console.aws.amazon.com//ec2/) et sélectionnez **Security groups (Groupes de sécurité)** depuis le menu de gauche. 1. Dans la liste des groupes de sécurité qui s'affiche, cochez la case située à gauche du groupe de sécurité que vous utilisez pour ce didacticiel. Les informations de votre groupe de sécurité s'affichent. 1. Modifiez les règles entrantes et sortantes en sélectionnant l'onglet **Inbound rules** (Règles entrantes) ou **Outbound rules** (Règles sortantes) et en cliquant sur **Edit inbound rules** (Modifier les règles entrantes) ou **Edit outbound rules** (Modifier les règles sortantes). Modifiez les règles pour qu'elles correspondent à celles affichées dans les tableaux précédents. Lorsque vous aurez créé votre instance EC2 plus tard dans ce didacticiel, modifiez la règle entrante RDP source avec l’adresse IP publique de votre instance EC2, comme décrit dans la section [Connexion à votre instance Windows à l’aide du protocole RDP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html) du *Guide de l’utilisateur Amazon EC2*. ## Étape 4 : Création d'un système de fichiers FSx pour Windows File Server Une fois que votre groupe de sécurité a été vérifié et mis à jour et que votre Active Directory a été créé et est en état actif, créez le système de fichiers FSx pour Windows File Server dans le même VPC que votre Active Directory. Suivez les étapes ci-dessous pour créer un système de fichiers FSx pour serveur de fichiers Windows pour vos tâches Windows. **Créez votre premier système de fichiers.** 1. Ouvrez la [ FSx console Amazon](https://console.aws.amazon.com//fsx/). 1. Dans Sur le tableau de bord, choisissez **Create file system (Créer un système de fichiers)** pour ouvrir l'assistant de création de système de fichiers. 1. Sur la page **Sélectionner le type de système FSx de fichiers****, choisissez Windows File Server**, puis **Next**. La page **Create file system (Créer un système de fichiers)** s'affiche. 1. Dans la section **File system details (Informations du système de fichiers)**, indiquez un nom pour votre système de fichiers. Donner un nom à vos systèmes de fichiers facilite leur recherche et leur gestion. Vous pouvez utiliser jusqu'à 256 caractères Unicode. Les caractères autorisés sont les lettres, les chiffres, les espaces et les caractères spéciaux suivants : signe plus (\$1), signe moins (-), signe égal (=), point (.), trait de soulignement (\$1), deux points (:) et barre oblique (/). 1. Pour **Deployment type (Type de déploiement)**, choisissez **Single-AZ (Mono-AZ)** afin de déployer un système de fichiers qui est déployé dans une seule zone de disponibilité. *Mono-AZ 2* est la dernière génération de systèmes de fichiers de zone de disponibilité unique et prend en charge le stockage SSD et HDD. 1. Pour **Storage type (Type de stockage)**, choisissez **HDD**. 1. Pour **Storage capacity (Capacité de stockage)**, saisissez la capacité de stockage minimale. 1. Conservez la valeur par défaut de **Throughput capacity (Capacité de débit)**. 1. Dans la section **Réseau et sécurité**, choisissez le même Amazon VPC que celui que vous avez choisi pour votre Directory Service annuaire. 1. Pour **VPC Security Groups (Groupes de sécurité VPC)**, choisissez le groupe de sécurité que vous avez vérifié à l'*Étape 3 : Vérifier et mettre à jour votre groupe de sécurité*. 1. Pour **Windows authentication** (Authentification Windows), choisissez **AWS Managed Microsoft Active Directory** (Annuaire Microsoft Active Directory géré par ), puis choisissez votre répertoire Directory Service dans la liste. 1. Pour **Encryption (Chiffrement)**, conservez la valeur par défaut du paramètre **Encryption key (Clé de chiffrement)**, **aws/fsx (default) (aws/fsx [par défaut])**. 1. Conservez les paramètres par défaut pour **Maintenance preferences (Préférences de maintenance)**. 1. Cliquez sur **Next (Suivant)**. 1. Vérifiez la configuration du système de fichiers qui s'affiche sur la page **Create file system (Créer un système de fichiers)**. Pour référence, notez les paramètres du système de fichiers que vous pouvez modifier une fois le système de fichiers créé. Choisissez **Create file system** (Créer un système de fichiers). 1. Notez l'ID du système de fichiers. Vous en aurez besoin dans une étape ultérieure. Vous pouvez passer aux étapes suivantes pour créer un cluster et une instance EC2 lors de la création du système de fichiers FSx pour Windows File Server. ## Étape 5 : créer un cluster Amazon ECS **Création d'un cluster à l'aide de la console Amazon ECS** 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans la barre de navigation, sélectionnez la région à utiliser. 1. Dans le panneau de navigation, choisissez **Clusters**. 1. Sur la page **Clusters**, choisissez **Create Cluster** (Créer un cluster). 1. Sous **Cluster configuration** (Configuration de cluster), pour **Cluster name** (Nom du cluster), saisissez **windows-fsx-cluster**. 1. Étendez **l'infrastructure**, AWS Fargate effacez (sans serveur), puis sélectionnez les instances **Amazon EC2**. 1. Pour créer un groupe Auto Scaling, depuis **Auto Scaling group (ASG)** (Groupe Auto Scaling [ASG]), sélectionnez **Create new group** (Créer un nouveau groupe), puis fournissez les détails suivants sur le groupe : + Dans **Système d'exploitation/Architecture**, choisissez **Windows Server 2019 Core**. + Pour **Type d'instance EC2**, choisissez t2.medium ou t2.micro. 1. Choisissez **Créer**. ## Étape 6 : créer une instance Amazon EC2 optimisée pour Amazon ECS Créez une instance de conteneur Windows Amazon ECS. **Pour créer une instance Amazon ECS** 1. Utilisez la commande `aws ssm get-parameters` pour récupérer le nom d'AMI de la région qui héberge votre VPC. Pour plus d'informations, consultez [Extraction des métadonnées d'AMI optimisée pour Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_windows_AMI.html). 1. Utilisez la console Amazon EC2 pour lancer l'instance. 1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Dans la barre de navigation, sélectionnez la région à utiliser. 1. Sur le **tableau de bord EC2**, sélectionnez **Launch instance (Lancer une instance)**. 1. Pour **Name (Nom)**, saisissez un nom unique. 1. Pour **Images de l'application et du SE (Amazon Machine Image)**, dans le champ de **recherche**, saisissez le nom de l'AMI que vous avez récupérée. 1. Pour **Type d'instance**, choisissez t2.medium ou t2.micro. 1. Pour **Key pair (login)** (Paire de clés (connexion)), choisissez une paire de clés. Si vous ne spécifiez pas de paire de clés, vous 1. Sous **Paramètres réseau**, pour **VPC** et **Sous-réseau**, choisissez votre VPC et un sous-réseau public. 1. Sous **Network Settings** (Paramètres réseau), pour **Security group** (Groupe de sécurité), choisissez un groupe de sécurité existant ou créez-en un nouveau. Assurez-vous que le groupe de sécurité que vous choisissez possède les règles entrantes et sortantes définies dans [Prérequis pour le didacticiel](#wfsx-prerequisites). 1. Sous **Network settings** (Paramètres réseau), pour **Auto-assign Public IP** (Attribuer automatiquement l'adresse IP publique), sélectionnez **Enable** (Activer). 1. Développez **Détails avancés**, puis pour **Répertoire de jonction de domaines**, sélectionnez l'ID de l'Active Directory que vous avez créé. Cette option de jonction de domaines joint votre répertoire AD lorsque l'instance EC2 est lancée. 1. Sous **Détails avancés**, pour le **profil d'instance IAM**, sélectionnez **ecsInstanceRole**. 1. Configurez votre instance de conteneur Amazon ECS avec les données utilisateur suivantes. Sous **Détails avancés**, collez le script suivant dans le champ **Données utilisateur**, en le *cluster\$1name* remplaçant par le nom de votre cluster. ``` Initialize-ECSAgent -Cluster windows-fsx-cluster -EnableTaskIAMRole ``` 1. Lorsque vous êtes prêt, cochez la case de confirmation, puis sélectionnez **Launch Instances** (Lancer des instances). 1. Une page de confirmation indique que l'instance est en cours de lancement. Sélectionnez **View Instances** (Afficher les instances) pour fermer la page de confirmation et revenir à la console. 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans le volet de navigation, choisissez **Clusters**, puis choisissez **windows-fsx-cluster**. 1. Choisissez l'onglet **Infrastructure** et vérifiez que votre instance a été enregistrée dans le **windows-fsx-cluster**cluster. ## Étape 7 : Enregistrement d'une définition de tâche Windows Avant de pouvoir exécuter des conteneurs Windows dans votre cluster Amazon ECS, vous devez enregistrer une définition de tâche. L'exemple de définition de tâche suivant affiche une page Web simple. La tâche lance deux conteneurs qui ont accès au système de FSx fichiers. Le premier conteneur écrit un fichier HTML dans le système de fichiers. Le deuxième conteneur télécharge le fichier HTML à partir du système de fichiers et sert la page web. 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans le panneau de navigation, choisissez **Task definitions** (Définition des tâches). 1. Choisissez **Create new task definition** (Créer une nouvelle définition de tâche), puis **Create new task definition with JSON** (Créer une nouvelle définition de tâche avec JSON). 1. Dans la zone de l'éditeur JSON, remplacez les valeurs de votre rôle d'exécution des tâches et les informations relatives à votre système de FSx fichiers, puis choisissez **Enregistrer**. ``` { "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" } } ] } ``` ## Étape 8 : Exécuter une tâche et afficher les résultats Avant d'exécuter la tâche, vérifiez que l'état de votre système de fichiers FSx pour Windows File Server est **disponible**. Si c'est le cas, vous pouvez exécuter une tâche à l'aide de la définition de tâche que vous avez créée. La tâche commence par créer des conteneurs qui remanient un fichier HTML sur eux à l'aide du système de fichiers. Après le remaniement, un serveur web sert la page HTML simple. **Note** Il se peut que vous ne parveniez pas à vous connecter au site web depuis un VPN. **Exécutez une tâche et affichez les résultats à l'aide de la console Amazon ECS.** 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans le volet de navigation, choisissez **Clusters**, puis choisissez **windows-fsx-cluster**. 1. Choisissez l'onglet **Tâches**, puis **Exécuter une nouvelle tâche**. 1. Pour **Launch Type** (Type de lancement), choisissez **EC2**. 1. Sous Configuration du déploiement, pour **Définition de tâche**, sélectionnez **fsx-windows**, puis sélectionnez **Créer**. 1. Lorsque le statut de votre tâche est **EN COURS D'EXÉCUTION**, sélectionnez l'ID de la tâche. 1. Sous **Conteneurs**, lorsque le statut container1 est **ARRÊTÉ**, sélectionnez container2 pour afficher les détails du conteneur. 1. Dans **Informations sur le conteneur pour container2**, sélectionnez **Liaisons réseau**, puis cliquez sur l'adresse IP externe associée au conteneur. Votre navigateur s'ouvre et affiche le message suivant. ``` Amazon ECS Sample App It Works! You are using Amazon FSx for Windows File Server file system for persistent container storage. ``` **Note** L'affichage du message peut prendre quelques minutes. Si ce message ne s'affiche pas après plusieurs minutes, vérifiez que vous n'exécutez pas dans un VPN et assurez-vous que le groupe de sécurité de votre instance de conteneur autorise le trafic HTTP réseau entrant sur le port 443. ## Étape 9 : nettoyer **Note** La suppression du système de fichiers Windows File Server ou FSx de l'AD prend 20 à 45 minutes. Vous devez attendre que les opérations FSx de suppression du système de fichiers du serveur de fichiers Windows soient terminées avant de démarrer les opérations de suppression AD. **Supprimer FSx pour le système de fichiers Windows File Server.** 1. Ouvrez la [ FSx console Amazon](https://console.aws.amazon.com//fsx/) 1. Cliquez sur le bouton radio situé à gauche du système FSx de fichiers Windows File Server que vous venez de créer. 1. Choisissez **Actions**. 1. Sélectionnez **Delete file system (Supprimer le système de fichiers)**. **Supprimez le répertoire AD.** 1. Ouvrez la [Directory Service console](https://console.aws.amazon.com//directoryservicev2/). 1. Cliquez sur la case d'option située à gauche du répertoire AD que vous venez de créer. 1. Choisissez **Actions**. 1. Sélectionnez **Delete directory (Supprimer le répertoire)**. **Supprimez le cluster.** 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans le volet de navigation, choisissez **Clusters**, puis choisissez **windows-fsx-cluster**. 1. Choisissez **Supprimer le cluster**. 1. Saisissez l'expression, puis choisissez **Supprimer**. **Résiliez l'instance EC2.** 1. Ouvrez la [console Amazon EC2](https://console.aws.amazon.com//ec2/). 1. Dans le menu de gauche, sélectionnez **Instances**. 1. Cochez la case située à gauche de l'instance EC2 que vous avez créée. 1. Cliquez sur **État de l'instance**, puis sur **Résilier l'instance**. **Supprimez le secret.** 1. Ouvrez la [console Secrets Manager](https://console.aws.amazon.com//secretsmanager/). 1. Sélectionnez le secret que vous avez créé pour cette démonstration. 1. Cliquez sur **Actions**. 1. Sélectionnez **Delete secret (Supprimer le secret)**. # Utilisation de volumes Docker avec Amazon ECS Lorsque vous utilisez des volumes Docker, le pilote `local` intégré ou un pilote de volume tiers peut être utilisé. Les volumes Docker sont gérés par Docker et un répertoire est créé dans `/var/lib/docker/volumes` sur l'instance de conteneur qui contient les données du volume. Pour utiliser des volumes Docker, spécifiez un `dockerVolumeConfiguration` dans votre définition de tâche. Pour plus d’informations, consultez la section [Volumes](https://docs.docker.com/engine/storage/volumes/) dans la documentation Docker. Certains cas d'utilisation courants pour les volumes Docker sont les suivants : + Fournir des volumes de données permanent à utiliser avec des conteneurs + Partager un volume de données défini à différents emplacements sur différents conteneurs situés sur la même instance de conteneur + Définir un volume de données vide, non permanent et le monter dans plusieurs conteneurs au sein d’une même tâche + Fournir un volume de données à votre tâche qui est gérée par un pilote tiers ## Considérations relatives à l’utilisation des volumes Docker Tenez compte des éléments suivants lorsque vous utilisez des volumes Docker : + Les volumes Docker sont pris en charge uniquement en utilisant le type de lancement EC2 ou des instances externes. + Les conteneurs Windows prennent uniquement en charge l'utilisation du pilote `local`. + Si un pilote tiers est utilisé, assurez-vous qu'il est installé et actif sur l'instance de conteneur avant le démarrage de l'agent de conteneur. Si le pilote tiers n'est pas actif avant le démarrage de l'agent, vous pouvez redémarrer l'agent de conteneur à l'aide de l'une des commandes suivantes : + Pour l'AMI Amazon Linux 2 optimisée pour Amazon ECS : ``` sudo systemctl restart ecs ``` + Pour l'AMI Amazon Linux optimisée pour Amazon ECS : ``` sudo stop ecs && sudo start ecs ``` Pour plus d’informations sur la manière de spécifier un volume Docker dans une définition de tâche, consultez la section [Spécification d’un volume Docker dans une définition de tâche Amazon ECS](specify-volume-config.md). # Spécification d’un volume Docker dans une définition de tâche Amazon ECS Avant que vos conteneurs puissent utiliser des volumes de données, vous devez spécifier les configurations du volume et du point de montage dans votre définition de tâche. Cette section décrit la configuration du volume pour un conteneur. Pour les tâches qui utilisent un volume Docker, spécifiez une propriété `dockerVolumeConfiguration`. Pour les tâches qui utilisent un volume hôte de montage lié, spécifiez un `host` et éventuellement un `sourcePath`. La définition de tâche JSON indiquée ci-dessous illustre la syntaxe des objets `volumes` et `mountPoints` pour un conteneur : ``` { "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` Type : chaîne Obligatoire : non Nom du volume. Jusqu’à 255 lettres (majuscules et minuscules), chiffres, traits d’union (`-`) et traits de soulignement (`_`) sont autorisés. Ce nom est référencé dans le paramètre `sourceVolume` de l’objet `mountPoints` de définition du conteneur. `dockerVolumeConfiguration` Type : [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html)Objet Obligatoire : non Ce paramètre est spécifié lorsque vous utilisez des volumes Docker. Les volumes Docker sont pris en charge uniquement lors de l’exécution de tâches sur des instances EC2. Les conteneurs Windows prennent uniquement en charge l’utilisation du pilote `local`. Pour utiliser des montages liés, spécifiez plutôt un paramètre `host`. `scope` Type : Chaîne Valeurs valides : `task` \$1 `shared` Obligatoire : non Portée du volume Docker, qui détermine son cycle de vie. Les volumes Docker destinés à un élément `task` sont automatiquement mis en service lorsque la tâche commence, et détruits lorsque la tâche s'arrête. Les volumes Docker définis comme `shared` ne sont pas supprimés lorsque la tâche s'arrête. `autoprovision` Type : Boolean Valeur par défaut : `false` Obligatoire : non Si cette valeur est `true`, le volume Docker est créé s'il n'existe pas déjà. Ce champ n’est utilisé que si `scope` a la valeur `shared`. Si le champ `scope` a la valeur `task`, ce paramètre doit être omis. `driver` Type : chaîne Obligatoire : non Pilote de volume Docker à utiliser. La valeur du pilote doit correspondre au nom du pilote fourni par Docker, car ce nom est utilisé pour le placement des tâches. Si le pilote a été installé à l’aide de l’interface CLI du plug-in Docker, utilisez `docker plugin ls` pour récupérer le nom du pilote à partir de votre instance de conteneur. Si le pilote a été installé à l’aide d’une autre méthode, utilisez la découverte du plug-in Docker pour récupérer le nom du pilote. `driverOpts` Type : chaîne Obligatoire : non Mappage des options spécifiques au pilote Docker à transmettre. Ce paramètre correspond à `DriverOpts` dans la section « Créer un volume » de Docker. `labels` Type : chaîne Obligatoire : non Métadonnées personnalisées à ajouter à votre volume Docker. `mountPoints` Type : tableau d'objets Obligatoire : non Les points de montage pour les volumes de données dans votre conteneur. Ce paramètre correspond à `Volumes` dans l’API Docker create-container et à l’option `--volume` de docker run. Les conteneurs Windows peuvent monter des répertoires entiers sur le même lecteur que `$env:ProgramData`. Les conteneurs Windows ne peuvent pas monter de répertoires sur un autre lecteur, et les points de montage ne peuvent pas être utilisés sur plusieurs lecteurs. Vous devez spécifier des points de montage pour associer un volume Amazon EBS directement à une tâche Amazon ECS. `sourceVolume` Type : Chaîne Obligatoire : oui, lorsque des objets `mountPoints` sont utilisés Nom du volume à monter. `containerPath` Type : Chaîne Obligatoire : oui, lorsque des objets `mountPoints` sont utilisés Le chemin dans le conteneur où le volume sera monté. `readOnly` Type : booléen Obligatoire : non Si cette valeur est `true`, le conteneur ne peut accéder au volume qu'en lecture. Si cette valeur est `false`, le conteneur peut écrire sur le volume. La valeur par défaut est `false`. Pour les tâches exécutées sur des instances EC2 exécutant le système d’exploitation Windows, laissez la valeur `false` par défaut. # Exemples de volumes Docker pour Amazon ECS Les exemples suivants montrent comment fournir un stockage éphémère pour un conteneur et comment fournir un volume partagé pour plusieurs conteneurs, et comment fournir un stockage persistant NFS pour un conteneur. **Pour fournir un stockage éphémère à un conteneur à l’aide d’un volume Docker** Dans cet exemple, un conteneur utilise un volume de données vide qui est éliminé une fois la tâche terminée. Un exemple d'utilisation est que vous pourriez avoir un conteneur qui doit accéder à un emplacement de stockage de fichiers de travail pendant une tâche. Cette tâche peut être réalisée à l'aide d'un volume Docker. 1. Dans la section `volumes` de la définition de tâche, définissez un volume de données avec les valeurs `name` et `DockerVolumeConfiguration`. Dans cet exemple, nous spécifions la portée sous la forme `task`. Le volume est donc supprimé après l'arrêt de la tâche et il utilise le pilote `local` intégré. ``` "volumes": [ { "name": "scratch", "dockerVolumeConfiguration" : { "scope": "task", "driver": "local", "labels": { "scratch": "space" } } } ] ``` 1. Dans la section `containerDefinitions`, définissez un conteneur avec des valeurs `mountPoints` qui font référence au nom du volume défini et la valeur `containerPath` sur laquelle monter le volume sur le conteneur. ``` "containerDefinitions": [ { "name": "container-1", "mountPoints": [ { "sourceVolume": "scratch", "containerPath": "/var/scratch" } ] } ] ``` **Pour fournir un stockage persistant à plusieurs conteneurs à l’aide d’un volume Docker** Dans cet exemple, vous voulez un volume partagé qui sera utilisé par plusieurs conteneurs et vous souhaitez qu'il persiste après l'arrêt des tâches qui l'utilisent. Le pilote `local` intégré est en cours d'utilisation. Ainsi, le volume est toujours lié au cycle de vie de l'instance de conteneur. 1. Dans la section `volumes` de la définition de tâche, définissez un volume de données avec les valeurs `name` et `DockerVolumeConfiguration`. Dans cet exemple, spécifiez une portée `shared` pour que le volume persiste, définissez autoprovision sur `true`. C'est ainsi que le volume est créé pour être utilisé. Ensuite, utilisez également le pilote `local` intégré. ``` "volumes": [ { "name": "database", "dockerVolumeConfiguration" : { "scope": "shared", "autoprovision": true, "driver": "local", "labels": { "database": "database_name" } } } ] ``` 1. Dans la section `containerDefinitions`, définissez un conteneur avec des valeurs `mountPoints` qui font référence au nom du volume défini et la valeur `containerPath` sur laquelle monter le volume sur le conteneur. ``` "containerDefinitions": [ { "name": "container-1", "mountPoints": [ { "sourceVolume": "database", "containerPath": "/var/database" } ] }, { "name": "container-2", "mountPoints": [ { "sourceVolume": "database", "containerPath": "/var/database" } ] } ] ``` **Pour fournir un stockage permanent NFS pour un conteneur à l'aide d'un volume Docker** Dans cet exemple, un conteneur utilise un volume de données NFS qui est automatiquement monté lorsque la tâche démarre et démonté lorsque la tâche s'arrête. Cela utilise le pilote `local` intégré Docker. Un exemple d'utilisation est que vous pourriez avoir un stockage NFS local et que vous devez y accéder à l'aide d'une tâche ECS Anywhere. Cela peut être réalisé à l'aide d'un volume Docker avec option de pilote NFS. 1. Dans la section `volumes` de la définition de tâche, définissez un volume de données avec les valeurs `name` et `DockerVolumeConfiguration`. Dans cet exemple, spécifiez une portée `task` de telle sorte que le volume soit démonté une fois la tâche terminée. Utilisez le pilote `local` et configurez le `driverOpts` avec le `type`, `device` et les options `o` en conséquence. Remplacez `NFS_SERVER` par le point de terminaison du serveur NFS. ``` "volumes": [ { "name": "NFS", "dockerVolumeConfiguration" : { "scope": "task", "driver": "local", "driverOpts": { "type": "nfs", "device": "$NFS_SERVER:/mnt/nfs", "o": "addr=$NFS_SERVER" } } } ] ``` 1. Dans la section `containerDefinitions`, définissez un conteneur avec des valeurs `mountPoints` qui font référence au nom du volume défini et la valeur `containerPath` sur laquelle monter le volume sur le conteneur. ``` "containerDefinitions": [ { "name": "container-1", "mountPoints": [ { "sourceVolume": "NFS", "containerPath": "/var/nfsmount" } ] } ] ``` # Utilisation de montages liés avec Amazon ECS Avec les montages liés, un fichier ou un répertoire sur un hôte, tel qu’une instance Amazon EC2, est monté dans un conteneur. Les montages liés sont pris en charge lorsque vous exécutez des tâches sur des instances Fargate ou Amazon EC2. Les montages liés sont liés au cycle de vie du conteneur qui les utilise. Une fois que tous les conteneurs qui utilisent un montage lié sont arrêtés, par exemple lorsqu'une tâche est arrêtée, les données sont supprimées. Pour les tâches hébergées sur des instances Amazon EC2, les données peuvent être liées au cycle de vie de l’instance Amazon EC2 hôte en spécifiant un `host` et une valeur `sourcePath` facultative dans votre définition de tâche. Pour de plus amples informations, consultez la section [Montages liés](https://docs.docker.com/engine/storage/bind-mounts/) dans la documentation Docker. Voici quelques cas d'utilisation courants pour les montages liés. + Pour fournir un volume de données vide à monter dans un ou plusieurs conteneurs. + Pour monter un volume de données hôte dans un ou plusieurs conteneurs. + Pour partager un volume de données d'un conteneur source avec d'autres conteneurs dans la même tâche. + Pour exposer un chemin d'accès et son contenu d'un fichier Dockerfile à un ou plusieurs conteneurs. ## Considérations relatives à l'utilisation des montages liés Lorsque vous utilisez des montages liés, tenez compte des éléments suivants. + Par défaut, les tâches hébergées sur AWS Fargate une version de plate-forme `1.4.0` ou ultérieure (Linux) `1.0.0` ou ultérieure (Windows) reçoivent un minimum de 20 GiB de stockage éphémère pour les montages liés. Vous pouvez augmenter la quantité totale de stockage éphémère jusqu’à un maximum de 200 Gio en spécifiant le paramètre `ephemeralStorage` dans votre définition de tâche. + Pour exposer des fichiers d'un fichier Dockerfile à un volume de données lorsqu'une tâche est exécutée, le plan de données Amazon ECS recherche une directive `VOLUME`. Si le chemin absolu spécifié dans la directive `VOLUME` est le même que le `containerPath` spécifié dans la définition de tâche, les données du chemin de directive `VOLUME` sont copiées sur le volume de données. Dans l'exemple Dockerfile suivant, un fichier nommé `examplefile` dans le répertoire `/var/log/exported` est écrit sur l'hôte, puis monté à l'intérieur du conteneur. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN mkdir -p /var/log/exported RUN touch /var/log/exported/examplefile VOLUME ["/var/log/exported"] ``` Par défaut, les autorisations de volume sont définies sur `0755` et le propriétaire en tant que `root`. Vous pouvez personnaliser ces autorisations dans le fichier Dockerfile. L'exemple suivant définit le propriétaire du répertoire en tant que `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"] ``` + Pour les tâches hébergées sur des instances Amazon EC2, lorsque les valeurs `host` et `sourcePath` ne sont pas spécifiées, le démon Docker gère le montage lié à votre place. Lorsqu'aucun conteneur ne fait référence à ce montage lié, le service de nettoyage des tâches de l'agent de conteneur Amazon ECS finit par le supprimer. Par défaut, cela se produit trois heures après la sortie du conteneur. Toutefois, vous pouvez configurer cette durée avec la variable de l'agent `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`. Pour de plus amples informations, veuillez consulter [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md). Si vous avez besoin de conserver ces données au-delà du cycle de vie de conteneur, spécifiez une valeur `sourcePath` pour le montage lié. + Pour les tâches hébergées sur les instances gérées Amazon ECS, certaines parties du système de fichiers racine sont en lecture seule. Read/write les montages par liaison doivent utiliser des répertoires inscriptibles, par exemple `/var` pour les données persistantes ou `/tmp` pour les données temporaires. Toute tentative de création de montages par read/write liaison vers d'autres répertoires entraîne l'échec du lancement de la tâche avec une erreur similaire à la suivante : ``` error creating empty volume: error while creating volume path '/path': mkdir /path: read-only file system ``` Les montages de liaison en lecture seule (configurés `"readOnly": true` dans le `mountPoints` paramètre) peuvent pointer vers n'importe quel répertoire accessible sur l'hôte. Pour consulter la liste complète des chemins accessibles en écriture, vous pouvez exécuter une tâche sur une instance gérée Amazon ECS et l'utiliser pour inspecter la table de montage de l'instance. Créez une définition de tâche avec les paramètres suivants pour accéder au système de fichiers hôte : ``` { "pidMode": "host", "containerDefinitions": [{ "privileged": true, ... }] } ``` Exécutez ensuite les commandes suivantes depuis le conteneur : ``` # 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 ``` **Important** Le `privileged` paramètre accorde au conteneur des fonctionnalités étendues sur l'hôte, équivalentes à un accès root. Dans cet exemple, il est utilisé pour inspecter la table de montage de l'hôte à des fins de diagnostic. Pour de plus amples informations, veuillez consulter [Évitez d'exécuter des conteneurs dotés de privilèges (Amazon EC2)](security-tasks-containers.md#security-tasks-containers-recommendations-avoid-privileged-containers). Pour plus d'informations sur l'exécution interactive de commandes dans des conteneurs, consultez[Surveillance des conteneurs Amazon ECS avec ECS Exec](ecs-exec.md). # Spécification d’un montage lié dans une définition de tâche Amazon ECS Pour les tâches Amazon ECS hébergées sur des instances Fargate ou Amazon EC2, l’extrait JSON de définition de tâche suivant montre la syntaxe des objets `volumes`, `mountPoints` et `ephemeralStorage` pour une définition de tâche. ``` { "family": "", ... "containerDefinitions" : [ { "mountPoints" : [ { "containerPath" : "/path/to/mount_volume", "sourceVolume" : "string" } ], "name" : "string" } ], ... "volumes" : [ { "name" : "string" } ], "ephemeralStorage": { "sizeInGiB": integer } } ``` Pour les tâches Amazon ECS hébergées sur des instances Amazon EC2, vous pouvez utiliser le paramètre `host` facultatif et un `sourcePath` lorsque vous spécifiez les détails du volume de tâches. Lorsqu'il est spécifié, il lie le montage lié au cycle de vie de la tâche plutôt qu'au conteneur. ``` "volumes" : [ { "host" : { "sourcePath" : "string" }, "name" : "string" } ] ``` Voici des descriptions plus détaillées de chaque paramètre de définition de tâche. `name` Type : chaîne Obligatoire : non Nom du volume. Jusqu’à 255 lettres (majuscules et minuscules), chiffres, traits d’union (`-`) et traits de soulignement (`_`) sont autorisés. Ce nom est référencé dans le paramètre `sourceVolume` de l’objet `mountPoints` de définition du conteneur. `host` Obligatoire : non Le paramètre `host` est utilisé pour lier le cycle de vie du montage lié à l'instance Amazon EC2 hôte, plutôt qu'à la tâche et à l'endroit où elle est stockée. Si le paramètre `host` est vide, le démon Docker attribue un chemin hôte au volume de données, mais la persistance des données après l'arrêt des conteneurs qui lui sont associés n'est pas garantie. Les conteneurs Windows peuvent monter des répertoires entiers sur le même lecteur que `$env:ProgramData`. Le `sourcePath` paramètre est pris en charge uniquement lors de l'utilisation de tâches hébergées sur des instances Amazon EC2 ou des instances gérées Amazon ECS. `sourcePath` Type : chaîne Obligatoire : non Lorsque le paramètre `host` est utilisé, spécifiez un paramètre `sourcePath` pour déclarer le chemin d'accès sur l'instance Amazon EC2 hôte qui est présentée au conteneur. Si ce paramètre est vide, le démon Docker attribue un chemin hôte pour vous. Si le paramètre `host` contient un emplacement de fichier `sourcePath`, le volume de données persiste à l'emplacement spécifié sur l'instance Amazon EC2 hôte jusqu'à ce que vous le supprimiez manuellement. Si la valeur `sourcePath` n'existe pas sur l'instance Amazon EC2 hôte, le démon Docker la crée. Si l'emplacement n'existe pas, le contenu du chemin source est exporté. `mountPoints` Type : tableau d'objets Obligatoire : non Les points de montage pour les volumes de données dans votre conteneur. Ce paramètre correspond à `Volumes` dans l’API Docker create-container et à l’option `--volume` de docker run. Les conteneurs Windows peuvent monter des répertoires entiers sur le même lecteur que `$env:ProgramData`. Les conteneurs Windows ne peuvent pas monter de répertoires sur un autre lecteur, et les points de montage ne peuvent pas être utilisés sur plusieurs lecteurs. Vous devez spécifier des points de montage pour associer un volume Amazon EBS directement à une tâche Amazon ECS. `sourceVolume` Type : Chaîne Obligatoire : oui, lorsque des objets `mountPoints` sont utilisés Nom du volume à monter. `containerPath` Type : Chaîne Obligatoire : oui, lorsque des objets `mountPoints` sont utilisés Le chemin dans le conteneur où le volume sera monté. `readOnly` Type : booléen Obligatoire : non Si cette valeur est `true`, le conteneur ne peut accéder au volume qu'en lecture. Si cette valeur est `false`, le conteneur peut écrire sur le volume. La valeur par défaut est `false`. Pour les tâches exécutées sur des instances EC2 exécutant le système d’exploitation Windows, laissez la valeur `false` par défaut. `ephemeralStorage` Type : objet Obligatoire : non Quantité de magasin éphémère à allouer pour la tâche. Ce paramètre est utilisé pour augmenter la quantité totale de stockage éphémère disponible, au-delà de la quantité par défaut, pour les tâches hébergées sur AWS Fargate une version de plate-forme `1.4.0` ou ultérieure (Linux) `1.0.0` ou ultérieure (Windows). Vous pouvez utiliser la CLI Copilot CloudFormation, le AWS SDK ou l'interface de ligne de commande pour spécifier un stockage éphémère pour un montage par liaison. # Exemples de montage lié pour Amazon ECS Les exemples suivants couvrent les cas d’utilisation courants pour l’utilisation d’un montage lié pour vos conteneurs. **Pour allouer une quantité accrue d'espace de stockage éphémère pour une tâche Fargate** Pour les tâches Amazon ECS hébergées sur Fargate à l'aide de la version `1.4.0` de la plateforme ou une version ultérieure (Linux) ou `1.0.0` (Windows), vous pouvez allouer plus que la quantité de magasins éphémères par défaut pour les conteneurs de votre tâche à utiliser. Cet exemple peut être intégré dans les autres exemples afin d'allouer plus de stockage éphémère pour vos tâches Fargate. + Dans la définition de la tâche, définissez un objet `ephemeralStorage`. La valeur `sizeInGiB` doit être un nombre entier compris entre `21` et `200` est exprimée en GiB. ``` "ephemeralStorage": { "sizeInGiB": integer } ``` **Pour fournir un volume de données vide pour un ou plusieurs conteneurs** Dans certains cas, vous voudrez fournir aux conteneurs dans une tâche un peu d'espace vide. Supposons par exemple que deux conteneurs de base de données doivent accéder au même emplacement de stockage temporaire pendant une tâche. Cela peut être réalisé à l'aide d'un montage lié. 1. Dans la section `volumes` de la définition de tâche, définissez un montage lié nommé `database_scratch`. ``` "volumes": [ { "name": "database_scratch" } ] ``` 1. Dans la section `containerDefinitions`, créez les définitions de conteneur de base de données. Cela permet de monter le volume. ``` "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" } ] } ] ``` **Pour exposer un chemin d'accès et son contenu d'un fichier Dockerfile à un ou plusieurs conteneurs.** Dans cet exemple, vous avez un fichier Dockerfile qui écrit les données que vous souhaitez monter à l'intérieur d'un conteneur. Cet exemple fonctionne pour les tâches hébergées sur des instances Fargate ou Amazon EC2. 1. Créez un fichier Dockerfile. L'exemple suivant utilise l'image du conteneur Amazon Linux 2 publique et crée un fichier nommé `examplefile` dans le répertoire `/var/log/exported` que nous voulons monter à l'intérieur du conteneur. Le répertoire `VOLUME` doit spécifier un chemin absolu. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN mkdir -p /var/log/exported RUN touch /var/log/exported/examplefile VOLUME ["/var/log/exported"] ``` Par défaut, les autorisations de volume sont définies sur `0755` et le propriétaire en tant que `root`. Ces autorisations peuvent être modifiées dans le fichier Dockerfile. L'exemple suivant définit le propriétaire du répertoire `/var/log/exported` en tant que `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. Dans la section `volumes` de la définition de tâche, définissez un volume nommé `application_logs`. ``` "volumes": [ { "name": "application_logs" } ] ``` 1. Dans la section `containerDefinitions`, créez les définitions de conteneur d'application. Cela permet de monter le stockage. La valeur `containerPath` doit correspondre au chemin absolu spécifié dans la directive `VOLUME` du 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" } ] } ] ``` **Pour fournir un volume de données vide pour un conteneur lié au cycle de vie de l'instance Amazon EC2 hôte** Pour les tâches hébergées sur des instances Amazon EC2, vous pouvez utiliser des montages liés et lier les données au cycle de vie de l'instance Amazon EC2 hôte. Vous pouvez effectuer cette opération en utilisant le paramètre `host` et en spécifiant une valeur `sourcePath`. Tous les fichiers qui existent sur le `sourcePath` sont présentés dans les conteneurs à la valeur `containerPath`. Tous les fichiers écrits dans la valeur `containerPath` sont écrits dans la valeur `sourcePath` de l'instance Amazon EC2 hôte. **Important** Amazon ECS ne synchronise pas votre stockage entre les instances Amazon EC2. Les tâches qui utilisent un stockage permanent peuvent être placées sur n'importe quelle instance Amazon EC2 disposant de la capacité nécessaire dans votre cluster. Si vos tâches nécessitent un stockage permanent après l'arrêt et le redémarrage, spécifiez toujours la même instance Amazon EC2 au moment du lancement de la tâche à l'aide de AWS CLI [la](https://docs.aws.amazon.com/cli/latest/reference/ecs/start-task.html) commande start-task. Vous pouvez également utiliser des volumes Amazon EFS pour le stockage permanent. Pour de plus amples informations, veuillez consulter [Utilisation des volumes Amazon EFS avec Amazon ECS](efs-volumes.md). 1. Dans la section `volumes` de la définition de tâche, définissez un montage lié avec les valeurs `name` et `sourcePath`. Dans l'exemple suivant, l'instance Amazon EC2 hôte contient des données sous `/ecs/webdata` que vous souhaitez monter à l'intérieur du conteneur. ``` "volumes": [ { "name": "webdata", "host": { "sourcePath": "/ecs/webdata" } } ] ``` 1. Dans la section `containerDefinitions`, définissez un conteneur avec une valeur `mountPoints` qui fait référence au nom du montage lié défini et la valeur `containerPath` sur laquelle monter le montage lié sur le conteneur. ``` "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" } ] } ] ``` **Pour monter un volume défini sur plusieurs conteneurs à différents emplacements** Vous pouvez définir un volume de données dans une définition de tâche et monter ce volume à différents emplacements de différents conteneurs. Par exemple, votre conteneur hôte possède un dossier de données de site web à l'adresse `/data/webroot`. Vous voudrez peut-être monter ce volume de données en lecture seule sur deux serveurs web qui ont des racines de documents différentes. 1. Dans la section `volumes` de la définition de tâche, définissez un volume de données nommé `webroot` et ayant le chemin source `/data/webroot`. ``` "volumes": [ { "name": "webroot", "host": { "sourcePath": "/data/webroot" } } ] ``` 1. Dans la section `containerDefinitions`, définissez un conteneur pour chaque serveur web avec des valeurs `mountPoints` qui associent le volume `webroot` à la valeur `containerPath` pointant vers la racine du document pour ce conteneur. ``` "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 } ] } ] ``` **Pour monter les volumes à partir d'un autre conteneur à l'aide de `volumesFrom`** Pour les tâches hébergées sur des instances Amazon EC2, vous pouvez définir un ou plusieurs volumes sur un conteneur, puis utiliser le paramètre `volumesFrom` dans une définition du conteneur différente, au sein de la même tâche, pour monter tous les volumes du `sourceContainer` à leurs points de montage définis à l'origine. Le paramètre `volumesFrom` s'applique aux volumes définis dans la définition de tâche et à ceux qui sont intégrés à l'image au sein d'un Dockerfile. 1. (Facultatif) Pour partager un volume qui est intégré à une image, suivez les instructions `VOLUME` du fichier Dockerfile. L'exemple de Dockerfile suivant utilise une image `httpd`, puis ajoute un volume et le monte à l'emplacement `dockerfile_volume` dans la racine du document Apache. Il s'agit du dossier utilisé par le serveur web `httpd`. ``` FROM httpd VOLUME ["/usr/local/apache2/htdocs/dockerfile_volume"] ``` Vous pouvez créer une image avec ce Dockerfile, la transférer dans un référentiel (comme Docker Hub), puis l'utiliser dans votre définition de tâche. L’exemple d’image `my-repo/httpd_dockerfile_volume` utilisée dans les étapes suivantes a été créée avec le Dockerfile précédent. 1. Créez une définition de tâche qui définit les autres volumes et points de montage pour les conteneurs. Dans la section `volumes` de cet exemple, vous créez un volume vide appelé `empty` qui est géré par le démon Docker. Il existe également un volume hôte défini qui est appelé `host_etc`. Il exporte le dossier `/etc` dans l'instance de conteneur hôte. ``` { "family": "test-volumes-from", "volumes": [ { "name": "empty", "host": {} }, { "name": "host_etc", "host": { "sourcePath": "/etc" } } ], ``` Dans la section des définitions de conteneur, créez un conteneur qui monte les volumes définis précédemment. Dans cet exemple, le conteneur `web` monte les volumes `empty` et `host_etc`. Il s'agit du conteneur qui utilise l'image créée avec un volume dans le 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 }, ``` Créez un autre conteneur qui utilise `volumesFrom` pour monter tous les volumes qui sont associés au conteneur `web`. Tous les volumes du conteneur `web` sont également montés sur le conteneur `busybox`. Cela inclut le volume spécifié dans le Dockerfile qui a été utilisé pour générer l'image `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 } ] } ``` Lorsque la tâche est exécutée, les deux conteneurs montent les volumes, et la fonction `command` du conteneur `busybox` écrit la date et l'heure dans un fichier. Ce fichier est appelé `date` dans chacun des dossiers de volumes. Les dossiers sont alors visibles sur le site web affiché par le conteneur `web`. **Note** Étant donné que le conteneur `busybox` exécute une commande rapide avant de s'arrêter, il doit être défini en tant que `"essential": false` dans la définition de conteneur. Dans le cas contraire, il arrête l'ensemble de la tâche lorsqu'il s'arrête. # Gestion de l’espace mémoire d’échange de conteneur sur Amazon ECS Avec Amazon ECS, vous pouvez contrôler l'utilisation de l'espace mémoire d'échange sur vos instances Amazon EC2 basées sur Linux au niveau du conteneur. En utilisant une configuration d'échange par conteneur, l'échange peut être activé ou désactivé pour chaque conteneur au sein d'une définition de tâche. Pour ceux qui l'ont activé, la quantité maximale d'espace d'échange utilisée peut être limitée. Par exemple, l'échange peut être désactivé dans les conteneurs sensibles à la latence. En revanche, les conteneurs présentant des demandes de mémoire transitoire élevées peuvent avoir le swap activé afin de réduire les risques d' out-of-memoryerreurs lorsque le conteneur est en charge. La configuration d'échange pour un conteneur est gérée par les paramètres de définition de conteneur suivants : `maxSwap` Quantité totale de mémoire d'échange (en Mio) qu'un conteneur peut utiliser. Ce paramètre est converti en l’option `--memory-swap` de la commande docker run, où la valeur est la somme de la mémoire du conteneur et de la valeur `maxSwap`. Si la valeur `0` est spécifiée pour `maxSwap`, le conteneur n'utilise pas l'échange. Les valeurs acceptées sont `0` ou n'importe quel nombre entier positif. Si le paramètre `maxSwap` n'est pas spécifié, le conteneur utilise la configuration d'échange pour l'instance de conteneur sur laquelle il s'exécute. Une valeur `maxSwap` doit être définie pour que le paramètre `swappiness` soit utilisé. `swappiness` Vous pouvez utiliser ce paramètre pour régler le comportement d'échange de mémoire d'un conteneur. Une valeur `swappiness` de `0` fait que l'échange ne se produit pas, sauf si nécessaire. Avec la valeur `swappiness` pour `100`, l'échange de pages a lieu de manière agressive. Les valeurs acceptées sont les nombres entiers compris entre `0` et `100`. Si le paramètre `swappiness` n'est pas spécifié, la valeur par défaut `60` est utilisée. Si aucune valeur n'est spécifiée pour `maxSwap`, le paramètre est ignoré. Ce paramètre correspond à l’option `--memory-swappiness` de docker run. Dans l'exemple suivant, la syntaxe JSON est fournie. ``` "containerDefinitions": [{ ... "linuxParameters": { "maxSwap": integer, "swappiness": integer }, ... }] ``` ## Considérations Tenez compte des points suivants lorsque vous utilisez une configuration d'échange par conteneur. + L'espace d'échange doit être activé et alloué sur l'instance Amazon EC2 hébergeant vos tâches pour que les conteneurs puissent l'utiliser. Par défaut, le swap n'est AMIs pas activé sur les appareils optimisés pour Amazon ECS. Vous devez activer l'échange sur l'instance pour utiliser cette fonction. Pour plus d’informations, consultez la section [Volumes d’échange pour le stockage d’instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-store-swap-volumes.html) dans le *Guide de l’utilisateur Amazon EC2* ou [Comment allouer de la mémoire en tant qu’espace d’échange dans une instance Amazon EC2 ?](https://repost.aws/knowledge-center/ec2-memory-swap-file). + Les paramètres de définition de conteneur pour l’espace d’échange ne sont pris en charge que pour les définitions de tâche indiquant EC2. Ces paramètres ne sont pas pris en charge pour les définitions de tâches destinées uniquement à l'utilisation d'Amazon ECS sur Fargate. + Cette fonction est uniquement prise en charge pour les conteneurs Linux. Les conteneurs Windows ne sont pas pris en charge actuellement. + Si les paramètres de définition de conteneur `maxSwap` et `swappiness` sont omis d'une définition de tâche, chaque conteneur a une valeur `swappiness` par défaut de `60`. De plus, l’utilisation totale de l’échange est limitée à deux fois la mémoire du conteneur. + Si vous utilisez des tâches sur Amazon Linux 2023, le paramètre `swappiness` n'est pas pris en charge. # Différences entre les définitions de tâches Amazon ECS pour les instances gérées Amazon ECS Pour utiliser les instances gérées Amazon ECS, vous devez configurer votre définition de tâche pour utiliser le type de lancement des instances gérées Amazon ECS. Il existe d’autres considérations à prendre en compte lors de l’utilisation d’instances gérées Amazon ECS. ## Paramètres de définition de tâche Les tâches qui utilisent des instances gérées Amazon ECS prennent en charge la plupart des paramètres de définition de tâche Amazon ECS disponibles. Cependant, certains paramètres présentent des comportements ou des limites spécifiques lorsqu’ils sont utilisés avec des tâches d’instances gérées Amazon ECS. Les paramètres de définition de tâche ne sont pas valides dans les tâches d’instances gérées Amazon ECS : + `disableNetworking` + `dnsSearchDomains` + `dnsServers` + `dockerLabels` + `dockerSecurityOptions` + `dockerVolumeConfiguration` + `ephemeralStorage` + `extraHosts` + `fsxWindowsFileServerVolumeConfiguration` + `hostname` + `inferenceAccelerator` + `ipcMode` + `links` + `maxSwap` + `proxyConfiguration` + `sharedMemorySize` + `sourcepath`Volumes + `swappiness` + `tmpfs` Les paramètres de définition de tâche suivants sont valides dans les tâches d’instances gérées Amazon ECS, mais présentent des limitations à prendre en compte : + `networkConfiguration` : les tâches d’instances gérées Amazon ECS utilisent le mode réseau `awsvpc` ou `host`. + `placementConstraints` : les attributs de contrainte suivants sont pris en charge. + `ecs.subnet-id` + `ecs.availability-zone` + `ecs.instance-type` + `ecs.cpu-architecture` + `requiresCompatibilities` : doit inclure `MANAGED_INSTANCES` pour garantir la compatibilité de la définition de tâche avec les instances gérées Amazon ECS. + `resourceRequirement` : `InferenceAccelerator` n’est pas pris en charge. + `operatingSystemFamily` : les instances gérées Amazon ECS utilisent `LINUX`. + `volumes`- Lorsque vous utilisez des montages par liaison avec un`sourcePath`, le chemin doit pointer vers un répertoire accessible en écriture sur l'hôte. Certaines parties du système de fichiers Amazon ECS Managed Instance sont en lecture seule. Les répertoires inscriptibles incluent `/var` et. `/tmp` Pour de plus amples informations, veuillez consulter [Utilisation de montages liés avec Amazon ECS](bind-mounts.md). Pour vous assurer que votre définition de tâche est valide pour l’utilisation d’instances gérées Amazon ECS, vous pouvez spécifier les éléments suivants 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`MANAGED_INSTANCES`. + Dans le AWS CLI, spécifiez l'`--requires-compatibilities`option. + Dans l'API Amazon ECS, spécifiez l'indicateur `requiresCompatibilities`. # Différences de définition de tâche Amazon ECS pour Fargate Pour utiliser Fargate, vous devez configurer votre définition de tâche pour utiliser le type de lancement Fargate. D’autres considérations à prendre en compte lors de l’utilisation de Fargate. ## Paramètres de définition de tâche Les tâches qui utilisent 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, pour `capabilities`, la seule fonctionnalité que vous pouvez ajouter est `CAP_SYS_PTRACE`. Les paramètres `devices`, `sharedMemorySize` et `tmpfs` ne sont pas pris en charge. Pour de plus amples informations, veuillez consulter [Paramètres Linux](task_definition_parameters.md#container_definition_linuxparameters). + `volumes` : les tâches Fargate prennent en charge uniquement les volumes hôtes de montage lié, le paramètre `dockerVolumeConfiguration` n'est donc pas pris en charge. Pour de plus amples informations, veuillez consulter [Volumes](task_definition_parameters.md#volumes). + `cpu` - Pour les conteneurs Windows sur AWS Fargate, la valeur ne peut pas être inférieure à 1 vCPU. + `networkConfiguration` : les tâches Fargate utilisent toujours le mode réseau `awsvpc`. 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 n’utilisent que 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\$164. Lorsque vous exécutez des conteneurs LinuxAWS Fargate, vous pouvez utiliser l'architecture du processeur X86\$164 ou l' ARM64 architecture de vos applications basées sur ARM. Pour de plus amples informations, veuillez consulter [Définitions de tâche Amazon ECS pour les charges de travail ARM 64 bits](ecs-arm64.md). ## 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. 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 Mio ou en Go. Par exemple, vous pouvez spécifier une valeur de mémoire de `3072` en Mio ou de `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 mode virtuel CPUs (vCPUs). Par exemple, vous pouvez spécifier une valeur de processeur soit `1024` en unités de processeur, soit `1 vCPU` en CPUs v. | 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) Cette option nécessite la plateforme Linux `1.4.0` ou ultérieure | Entre 16 Go et 60 Go par incréments de 4 Go | Linux | | 16384 (16vCPU) Cette option nécessite la plateforme Linux `1.4.0` ou ultérieure | 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' IPv4 adresse 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)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) dans le *Guide de l'utilisateur Amazon Elastic Container Registry*. Voici un exemple de section `networkConfiguration` 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](task_definition_parameters.md#container_definition_limits). ## Logging ### 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 de plus amples informations, veuillez consulter [Automatisez les réponses aux erreurs Amazon ECS à l'aide de EventBridge](cloudwatch_event_stream.md). ### 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 le AWS CLI et. SDKs 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 en matière d’images de conteneurs Amazon ECS](container-considerations.md). ### 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, consultez[Envoyez les journaux Amazon ECS à CloudWatch](using_awslogs.md). 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](using_firelens.md). Pour plus d'informations sur l'utilisation du pilote de journal `splunk` dans une définition de tâche, consultez [Pilote de journalisation `splunk`](example_task_definitions.md#example_task_definition-splunk). ## 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 offrent un stockage par blocs économique, durable et hautement performant pour les charges de travail conteneurisées gourmandes en données. Pour de plus amples informations, veuillez consulter [Utilisation des volumes Amazon EBS avec Amazon ECS](ebs-volumes.md). + Volumes Amazon EFS pour le stockage permanent. Pour de plus amples informations, veuillez consulter [Utilisation des volumes Amazon EFS avec Amazon ECS](efs-volumes.md). + Supports de liaison pour un stockage éphémère. Pour de plus amples informations, veuillez consulter [Utilisation de montages liés avec Amazon ECS](bind-mounts.md). ## 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. 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é](https://aws.amazon.com/about-aws/whats-new/2022/09/introducing-seekable-oci-lazy-loading-container-images/). Les clients souhaitant utiliser SOCI ne pourront utiliser que le manifeste v2 d’index SOCI. Les clients existants qui ont déjà utilisé SOCI sur Fargate peuvent continuer à utiliser le manifeste v1 d’index SOCI mais nous leur conseillons vivement de passer à le manifeste v2 d’index SOCI. Le manifeste v2 d’index SOCI crée une relation explicite entre les images de conteneurs et leurs index SOCI afin de garantir des déploiements cohérents. **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\$164 ou ARM64 sont prises en charge. + 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. + Pour le manifeste v2 d’index SOCI, la génération d’un manifeste d’index SOCI modifie le manifeste de l’image du conteneur lorsque nous ajoutons une annotation pour l’index SOCI. Il en résulte un nouveau condensé d’image du conteneur. Le contenu des couches du système de fichiers des images de conteneur ne change pas. + Pour le manifeste v2 d’index SOCI, lorsque l’image du conteneur a déjà été stockée dans le référentiel d’images du conteneur, une fois qu’un index SOCI a été généré, vous devez republier l’image du conteneur. Le fait de republier une image de conteneur n’augmentera pas les coûts de stockage en dupliquant les couches du système de fichiers, cela ne fera que charger un nouveau fichier manifeste. + 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, l’image de conteneur doit être republiée sans aucun index SOCI joint. **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](https://github.com/awslabs/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](https://awslabs.github.io/cfn-ecr-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). **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 est `overlayfs`, et ce champ est défini sur `soci` si SOCI est utilisé. Pour vérifier que le manifeste v2 d’index SOCI est attaché à une image de conteneur, vous pouvez récupérer l’index d’image auprès d’Amazon ECR à l’aide de l’ 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")' ``` Pour vérifier que le manifeste v1 d’index SOCI est attaché à une image de conteneur, vous pouvez utiliser l’API OCI Referrers. ``` 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 '.' ``` # Différences entre les définitions de tâche Amazon ECS pour les instances EC2 exécutant Windows Les tâches exécutées sur les instances Windows EC2 ne prennent pas en charge tous les paramètres de définition de tâche Amazon ECS disponibles. Certains paramètres ne sont pas pris en charge du tout, tandis que d’autres se comportent différemment. Les paramètres de définition de tâche suivants ne sont pas pris en charge pour les définitions de tâche Amazon EC2 Windows : + `containerDefinitions` + `disableNetworking` + `dnsServers` + `dnsSearchDomains` + `extraHosts` + `links` + `linuxParameters` + `privileged` + `readonlyRootFilesystem` + `user` + `ulimits` + `volumes` + `dockerVolumeConfiguration` + `cpu` Nous vous recommandons de spécifier une UC de niveau conteneur pour les conteneurs Windows. + `memory` Nous vous recommandons de spécifier une mémoire de niveau conteneur pour les conteneurs Windows. + `proxyConfiguration` + `ipcMode` + `pidMode` + `taskRoleArn` Les rôles IAM pour les tâches sur les instances Windows EC2 nécessitent une configuration supplémentaire, mais cette configuration est en grande partie similaire à la configuration des rôles IAM pour les tâches sur les instances de conteneurs Linux. Pour de plus amples informations, veuillez consulter [Configuration supplémentaire d’instance Windows Amazon EC2](task-iam-roles.md#windows_task_IAM_roles). # Création d’une définition de tâche Amazon ECS à l’aide de la console Vous créez une définition de tâche afin de pouvoir définir l’application que vous exécutez en tant que tâche ou service. Lorsque vous créez une définition de tâche pour le type de lancement externe, vous devez créer la définition de tâche à l’aide de l’éditeur JSON et définir le `requireCapabilities` paramètre sur `EXTERNAL`. Vous pouvez créer une définition de tâche en utilisant l’expérience de console ou en spécifiant un fichier JSON. Vous pouvez demander à Amazon Q de fournir des recommandations lorsque vous utilisez l’éditeur JSON. Pour de plus amples informations, consultez [Utilisation d’Amazon Q Developer pour proposer des recommandations de définition de tâche dans la console Amazon ECS](using-amazon-q.md). ## Validation JSON L'éditeur JSON de la console Amazon ECS valide les éléments suivants dans le fichier JSON : + Le fichier est un fichier JSON valide. + Le fichier ne contient aucune clé superflue. + Le fichier contient le paramètre `familyName`. + Il y a au moins une entrée en dessous de`containerDefinitions`. ## CloudFormation piles Le comportement suivant s’applique aux définitions de tâches qui ont été créées dans la nouvelle console avant le 12 janvier 2023. Lorsque vous créez une définition de tâche, la console Amazon ECS crée automatiquement une CloudFormation pile dont le nom commence par`ECS-Console-V2-TaskDefinition-`. Si vous avez utilisé le AWS CLI ou un AWS SDK pour annuler l'enregistrement de la définition de tâche, vous devez supprimer manuellement la pile de définitions de tâches. Pour plus d’informations, consultez la section [Suppression d’une pile](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html) dans le *Guide de l’utilisateur CloudFormation *. Aucune CloudFormation pile n'est créée automatiquement pour les définitions de tâches créées après le 12 janvier 2023. ## Procédure ------ #### [ Amazon ECS console ] 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans le panneau de navigation, choisissez **Task definitions** (Définition des tâches). 1. Dans le menu **Créer une définition de tâche**, choisissez **Créer une définition de tâche**. 1. Pour **Task definition family** (Famille de définition de tâche), spécifiez un nom unique pour la définition de tâche. 1. Pour **Type de lancement**, choisissez l'environnement de l'application. La console par défaut est **AWS Fargate** (qui est sans serveur). Amazon ECS utilise cette valeur pour effectuer une validation afin de s’assurer que les paramètres de définition de tâche sont valides pour le type d’infrastructure. 1. Pour **Operating system/Architecture** (Système d'exploitation/architecture), choisissez le système d'exploitation et l'architecture du processeur pour la tâche. Pour exécuter votre tâche sur une architecture ARM 64 bits, choisissez **Linux/ ARM64**. Pour de plus amples informations, veuillez consulter [Plateforme d'exécution](task_definition_parameters.md#runtime-platform). Pour exécuter vos tâches **AWS Fargate** sur les conteneurs Windows, choisissez un système d'exploitation Windows pris en charge. Pour de plus amples informations, veuillez consulter [Systèmes d’exploitation et architectures](fargate-tasks-services.md#fargate-task-os). 1. Pour **Task size** (Taille de la tâche), choisissez les valeurs du processeur et de la mémoire à réserver pour la tâche. La valeur du processeur est spécifiée comme v CPUs et la mémoire est spécifiée comme Go. Pour les tâches hébergées sur Fargate, le tableau suivant indique les combinaisons de processeur et de mémoire valides. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/create-task-definition.html) Pour les tâches qui utilisent des instances EC2 ou des instances externes, les valeurs de processeur de tâche prises en charge sont comprises entre 128 unités de processeur (0,125 vCPUs) et 196 608 unités de processeur (192 v). CPUs Pour spécifier la valeur de la mémoire en Go, saisissez **Go** après la valeur. Par exemple, pour définir la **valeur de la mémoire** sur 3 Go, saisissez **3 Go**. **Note** Les paramètres d'UC et de mémoire de niveau tâche sont ignorés pour les conteneurs Windows. 1. Pour **Network mode** (Mode réseau), choisissez le mode réseau à utiliser. La valeur par défaut est le mode **awsvpc**. Pour plus d'informations, consultez [Réseaux des tâches Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html). Si vous choisissez **pont**, sous **Mappages de port**, pour **Port hôte**, saisissez le numéro de port sur l’instance de conteneur à réserver pour votre conteneur. 1. (Facultatif) Développez la section **Rôles des tâches** pour configurer les rôles Gestion des identités et des accès AWS (IAM) de la tâche : 1. Pour **Task role** (Rôle de tâche), choisissez le rôle IAM à assigner à la tâche. Un rôle IAM de tâche autorise les conteneurs d'une tâche à appeler des opérations d' AWS API. 1. Pour **Rôle d'exécution de tâche**, choisissez le rôle. Pour savoir quand utiliser un rôle d'exécution de tâche, veuillez consulter [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md). Si vous n’avez pas besoin du rôle, choisissez **Aucun**. 1. (Facultatif) Développez la section **Placement de tâche** pour ajouter des contraintes de placement. Les contraintes de placement de tâche vous permettent de filtrer les instances de conteneur utilisées pour le placement de vos tâches à l’aide d’attributs intégrés ou personnalisés. 1. (Facultatif) Développez la section **Injection de pannes** pour activer l’injection de pannes. L’injection de pannes vous permet de tester la façon dont votre application réagit à certains scénarios de défaillance. 1. Pour chaque conteneur à définir dans votre définition de tâche, effectuez les étapes suivantes. 1. Pour **Name** (Nom), saisissez un nom pour le conteneur. 1. Pour **Image URI** (URI de l'image), saisissez l'image à utiliser pour démarrer un conteneur. Les images de la galerie publique Amazon ECR peuvent être spécifiées uniquement à l’aide du nom de registre Amazon ECR public. Par exemple, si `public.ecr.aws/ecs/amazon-ecs-agent:latest` est spécifié, le conteneur Amazon Linux hébergé dans la galerie publique Amazon ECR est utilisé. Pour tous les autres référentiels, spécifiez le référentiel en utilisant les formats `repository-url/image:tag` ou `repository-url/image@digest`. 1. Si votre image se trouve dans un registre privé en dehors d'Amazon ECR, sous **Registre privé**, activez **Authentification du registre privé**. Ensuite, dans **ARN ou nom Secrets Manager**, saisissez l'Amazon Resource Name (ARN) du secret. 1. Pour **Conteneur essentiel**, si deux conteneurs ou plus sont définis dans votre définition de tâche, vous pouvez spécifier si le conteneur doit être considéré comme essentiel. Si un conteneur est marqué comme **Essentiel** et qu’il s’arrête, la tâche est interrompue. Chaque définition de tâche doit contenir au moins un conteneur essentiel. 1. Un mappage de ports permet aux conteneurs d'accéder aux ports de l'hôte pour envoyer ou recevoir du trafic. Sous **Port mappings** (Mappages de port), effectuez l'une des actions suivantes : + Lorsque vous utilisez le mode réseau **awsvpc**, pour**Container port** (Port du conteneur) et **Protocol** (Protocole), choisissez le mappage de port à utiliser pour le conteneur. + Lorsque vous utilisez le mode réseau **bridge** (pont), pour **Container port** (Port du conteneur) et **Protocol** (Protocole), choisissez le mappage de port à utiliser pour le conteneur. Choisissez **Add more port mappings** (Ajouter d'autres mappages de ports) pour spécifier des mappages de ports de conteneur supplémentaires. 1. Pour donner au conteneur un accès en lecture seule à son système de fichiers racine, pour **Système de fichiers racine en lecture seule**, sélectionnez **Lecture seule**. 1. (Facultatif) Pour définir les limites d’UC, de GPU et de mémoire au niveau du conteneur qui sont différentes des valeurs au niveau des tâches sous **Limites d’allocation de ressources**, procédez comme suit : + Dans **UC**), saisissez le nombre d’UC que l’agent de conteneur Amazon ECS réserve pour le conteneur. + Dans **GPU**, entrez le nombre d'unités GPU pour l'instance de conteneur. Une instance Amazon EC2 prenant en charge les GPU possède une unité GPU pour chaque GPU. Pour de plus amples informations, veuillez consulter [Définitions de tâches Amazon ECS pour les charges de travail GPU](ecs-gpu.md). + Pour **Limite stricte de mémoire**, saisissez la quantité de mémoire, en Go, à attribuer au conteneur. Si le conteneur tente de dépasser la limite stricte, il s'arrête. + Le démon Docker 20.10.0 ou version ultérieure réserve un minimum de 6 Mio de mémoire pour un conteneur. Vous ne devez donc pas spécifier moins de 6 Mio de mémoire pour vos conteneurs. Le démon Docker 19.03.13-ce ou version antérieure réserve un minimum de 4 Mio de mémoire pour un conteneur. Vous ne devez donc pas spécifier moins de 4 Mio de mémoire pour vos conteneurs. + Pour **Limite flexible de mémoire**, saisissez la limite flexible (en Go) de mémoire à réserver pour le conteneur. En cas de contention de la mémoire système, Docker tente de garder la mémoire du conteneur en deçà de cette limite flexible. Si vous ne spécifiez pas de mémoire au niveau de la tâche, vous devez indiquer un nombre entier différent de zéro pour **Limite stricte de mémoire** et/ou **Limite flexible de mémoire**. Si vous spécifiez les deux, **Limite stricte de mémoire** doit être supérieure à **Limite flexible de mémoire**. Cette fonctionnalité n’est pas prise en charge sur les conteneurs Windows. 1. (Facultatif) Développez la section **Variables d'environnement** pour spécifier les variables d'environnement à injecter dans le conteneur. Vous pouvez spécifier des variables d’environnement soit individuellement à l’aide de paires clé-valeur, soit en bloc en spécifiant un fichier de variables d’environnement hébergé dans un compartiment Amazon S3. Pour plus d’informations sur le formatage d’un fichier de variable d’environnement, consultez la section [Transmission d’une variable d’environnement individuelle à un conteneur Amazon ECS](taskdef-envfiles.md). Lorsque vous spécifiez une variable d’environnement pour le stockage des secrets, saisissez le nom du secret dans le champ **Clé**. Ensuite **ValueFrom**, entrez l'ARN complet du secret Parameter Store ou du secret Secrets Manager 1. (Facultatif) Sélectionnez l'option **Use log collection** (Utiliser la collecte de journaux) pour spécifier une configuration de journal. Pour chaque pilote de journal disponible, il existe des options de pilote de journal à spécifier. L'option par défaut envoie les journaux des conteneurs à Amazon CloudWatch Logs. Les autres options du pilote de journal sont configurées à l'aide de AWS FireLens. Pour de plus amples informations, veuillez consulter [Envoyer les journaux Amazon ECS à un AWS service ou AWS Partner](using_firelens.md). Voici une description plus détaillée de chaque destination de journal de conteneur. + **Amazon CloudWatch** — Configurez la tâche pour envoyer les journaux des conteneurs à CloudWatch Logs. Les options du pilote de journal par défaut sont fournies, ce qui permet de créer un groupe de CloudWatch journaux en votre nom. Pour spécifier un autre nom de groupe de journaux, modifiez les valeurs des options de pilote. + **Exporter des journaux vers Splunk** : configurez la tâche pour envoyer les journaux des conteneurs au pilote Splunk qui envoie les journaux à un service distant. Vous devez saisir l’URL de votre service Web Splunk. Le paramètre de jeton Splunk est spécifiée en tant qu’option secrète, car il peut être traité comme des données sensibles. + **Exporter des journaux vers Amazon Data Firehose** : configurez la tâche pour envoyer les journaux de conteneur à Firehose. Les options par défaut du pilote de journalisation sont fournies. Les journaux sont alors envoyés vers un flux de livraison Firehose. Pour spécifier un autre nom de flux de diffusion, modifiez les valeurs des options de pilote. + **Exporter des journaux vers Amazon Kinesis Data Streams** : configurez la tâche pour envoyer les journaux de conteneur à Kinesis Data Streams. Les options par défaut du pilote de journalisation sont fournies. Les journaux sont alors envoyés vers un flux Kinesis Data Streams. Pour spécifier un autre nom de flux, modifiez les valeurs des options de pilote. + **Exporter les journaux vers Amazon OpenSearch Service** : configurez la tâche pour envoyer les journaux des conteneurs vers un domaine OpenSearch de service. Les options de pilote de journal doivent être fournies. + **Exporter des journaux vers Amazon S3** : configurez la tâche pour envoyer les journaux de conteneur à un compartiment Amazon S3. Les options de pilote de journal par défaut sont fournies, mais vous devez spécifier un nom de compartiment Simple Storage Service (Amazon S3) valide. 1. (Facultatif) Configurez des paramètres de conteneur supplémentaires. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/create-task-definition.html) 1. (Facultatif) Choisissez **Add more containers** (Ajouter des conteneurs supplémentaires) pour ajouter des conteneurs supplémentaires à la définition de tâche. 1. (Facultatif) La section **Stockage** permet d’étendre la quantité de magasins éphémères pour les tâches hébergées sur Fargate. Vous pouvez également utiliser cette section pour ajouter une configuration de volume de données à la tâche. 1. Pour étendre le stockage éphémère disponible au-delà de la valeur par défaut de 20 gibibytes (GiB) pour vos tâches Fargate pour **Amount** (Quantité), spécifiez une valeur allant jusqu'à 200 GiB. 1. (Facultatif) Pour ajouter une configuration de volume de données à la définition de tâche, sélectionnez **Ajouter un volume**, puis procédez comme suit. 1. Pour **Volume name** (Nom du volume), saisissez un nom pour le volume de données. Le nom du volume de données est utilisé lors de la création d'un point de montage de conteneur. 1. Pour **Configuration du volume**, indiquez si vous souhaitez configurer votre volume lors de la création de la définition de tâche ou lors du déploiement. **Note** Les volumes qui peuvent être configurés lors de la création d'une définition de tâche incluent Bind mountDocker, Amazon EFS et Amazon FSx pour Windows File Server. Les volumes qui peuvent être configurés lors du déploiement lors de l’exécution d’une tâche, ou lors de la création ou de la mise à jour d’un service incluent Amazon EBS. 1. Pour **Type de volume**, sélectionnez un type de volume compatible avec le type de configuration que vous avez sélectionné, puis configurez le type de volume. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/create-task-definition.html) 1. Pour ajouter un volume depuis un autre conteneur, choisissez **Ajouter un volume à partir de**, puis configurez les éléments suivants : + Pour **Conteneur**, choisissez le conteneur. + Pour **Source**, choisissez le conteneur contenant le volume que vous souhaitez monter. + Pour **Lecture seule**, indiquez si le conteneur dispose d'un accès en lecture seule au volume. 1. (Facultatif) Pour configurer les paramètres de suivi et de collecte de métriques de votre application à l'aide de AWS Distro for OpenTelemetry l'intégration, développez **Monitoring**, puis sélectionnez **Utiliser la collecte de métriques** pour collecter et envoyer des métriques pour vos tâches à Amazon CloudWatch ou à Amazon Managed Service for Prometheus. Lorsque cette option est sélectionnée, Amazon ECS crée un sidecar de AWS Distro for OpenTelemetry conteneur préconfiguré pour envoyer les métriques de l'application. Pour de plus amples informations, veuillez consulter [Corrélation des performances des applications Amazon ECS à l’aide des métriques d’application](metrics-data.md). 1. Lorsque **Amazon CloudWatch** est sélectionné, les métriques personnalisées de votre application sont acheminées vers CloudWatch des métriques personnalisées. Pour de plus amples informations, veuillez consulter [Exporter les métriques des applications vers Amazon CloudWatch](application-metrics-cloudwatch.md). **Important** Lorsque vous exportez des métriques d'application vers Amazon CloudWatch, votre définition de tâche nécessite un rôle IAM de tâche doté des autorisations requises. Pour de plus amples informations, veuillez consulter [Autorisations IAM requises pour AWS Distro pour OpenTelemetry l'intégration à Amazon CloudWatch](application-metrics-cloudwatch.md#application-metrics-cloudwatch-iam). 1. Lorsque vous sélectionnez **Amazon Managed Service for Prometheus (Prometheus libraries instrumentation)** (Amazon Managed Service for Prometheus [instrumentation de bibliothèques Prometheus]), vos métriques de processeur, de la mémoire, du réseau et du stockage au niveau des tâches et vos métriques d'application personnalisées sont acheminées vers Amazon Managed Service for Prometheus. Pour **Point de terminaison de l’écriture à distance de l’espace de travail**, saisissez l’URL du point de terminaison d’écriture à distance pour votre espace de travail Prometheus. Pour **Cible de récupération**, saisissez l’hôte et le port que le collecteur AWS Distro for OpenTelemetry peut utiliser pour récupérer des données de métriques. Pour de plus amples informations, veuillez consulter [Exportation des métriques d'application vers Amazon Managed Service for Prometheus](application-metrics-prometheus.md). **Important** Lorsque vous exportez des métriques d'application vers Amazon Managed Service for Prometheus, votre définition de tâche nécessite un rôle IAM de tâche avec les autorisations nécessaires. Pour de plus amples informations, veuillez consulter [Autorisations IAM requises pour AWS Distro pour OpenTelemetry l'intégration à Amazon Managed Service for Prometheus](application-metrics-prometheus.md#application-metrics-prometheus-iam). 1. Lorsque vous sélectionnez **Amazon Managed Service for Prometheus OpenTelemetry (instrumentation**), vos indicateurs de processeur, de mémoire, de réseau et de stockage au niveau des tâches, ainsi que les indicateurs personnalisés de votre application, sont acheminés vers Amazon Managed Service for Prometheus. Pour **Point de terminaison de l’écriture à distance de l’espace de travail**, saisissez l’URL du point de terminaison d’écriture à distance pour votre espace de travail Prometheus. Pour de plus amples informations, veuillez consulter [Exportation des métriques d'application vers Amazon Managed Service for Prometheus](application-metrics-prometheus.md). **Important** Lorsque vous exportez des métriques d'application vers Amazon Managed Service for Prometheus, votre définition de tâche nécessite un rôle IAM de tâche avec les autorisations nécessaires. Pour de plus amples informations, veuillez consulter [Autorisations IAM requises pour AWS Distro pour OpenTelemetry l'intégration à Amazon Managed Service for Prometheus](application-metrics-prometheus.md#application-metrics-prometheus-iam). 1. (Facultatif) Développez la section **Tags** (Identifications) pour ajouter des identifications, sous forme de paires clé-valeur, à la définition de tâche. + [Ajouter une balise] Choisissez **Add tag** (Ajouter une balise), puis procédez comme suit : + Pour **Clé**, saisissez le nom de la clé. + Pour **Valeur**, saisissez la valeur de clé. + [Supprimer une balise] En regard de la balise, choisissez **Supprimer la balise**. 1. Choisissez **Créer** pour enregistrer la définition de tâche. ------ #### [ Amazon ECS console JSON editor ] 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans le panneau de navigation, choisissez **Task definitions** (Définition des tâches). 1. Choisissez **Créer une définition de tâche**, puis **Créer une définition de tâche avec JSON**. 1. Dans la zone de l'éditeur JSON, modifiez votre fichier JSON, Le JSON doit réussir les contrôles de validation spécifiés dans [Validation JSON](#json-validate-for-create). 1. Choisissez **Créer**. ------ # Utilisation d’Amazon Q Developer pour proposer des recommandations de définition de tâche dans la console Amazon ECS Lorsque vous utilisez l’éditeur JSON de la console Amazon ECS pour créer une définition de tâche, vous pouvez utiliser Amazon Q Developer pour proposer des suggestions de code générées par l’IA pour vos définitions de tâches. Vous pouvez utiliser la fonctionnalité de chat en ligne pour demander à Amazon Q Developer de générer, d’expliquer ou de refactoriser le JSON de définition des tâches à l’aide d’une interface conversationnelle. Vous pouvez injecter les suggestions générées à tout moment dans la définition de la tâche et accepter ou rejeter les modifications proposées. Amazon ECS a également amélioré la fonctionnalité de suggestions en ligne existante afin d’utiliser Amazon Q Developer. Lorsque vous créez une définition de tâche à l’aide de l’éditeur JSON, Amazon Q Developer peut vous fournir des recommandations pour vous aider à créer une définition de tâche plus rapidement. Vous pouvez avoir des suggestions intégrées basées sur les propriétés ou utiliser les suggestions Amazon Q Developer pour compléter automatiquement des blocs entiers d’exemples de code. Vous pouvez utiliser cette fonctionnalité dans les régions où Amazon Q Developer est pris en charge. Pour plus d’informations, consultez la section [Services AWS par région](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/). ## Conditions préalables Les conditions suivantes sont requises : + En plus des autorisations de la console, l’utilisateur qui crée la définition de tâche dans la console doit disposer de l’autorisation `codewhisperer:GenerateRecommendations` pour les recommandations et `q:SendMessage` pour utiliser le chat en ligne. Pour de plus amples informations, veuillez consulter [Autorisations requises pour utiliser Amazon Q Developer afin de fournir des recommandations dans la console](console-permissions.md#amazon-q-permission). ## Procédure 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans le panneau de navigation, choisissez **Task definitions** (Définition des tâches). 1. Choisissez **Créer une définition de tâche**, puis **Créer une définition de tâche avec JSON**. La page **Créer une définition de tâche** s’ouvre. La console fournit le modèle par défaut suivant. ``` { "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. Dans la fenêtre contextuelle des suggestions intégrées d’Amazon Q, sélectionnez **Autoriser**. Si vous fermez la fenêtre contextuelle, vous pouvez activer Amazon Q sous l’icône représentant une roue dentée. 1. Dans la zone de l’éditeur JSON, modifiez le document JSON. Pour qu’Amazon Q crée et renseigne les paramètres, saisissez un commentaire contenant ce que vous souhaitez ajouter. Dans l’exemple ci-dessous, le commentaire amène Amazon Q à générer les lignes en gras. ``` { "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. Pour utiliser la fonctionnalité de chat en ligne, vous pouvez surligner les lignes, puis choisir l’icône en forme d’étoile. La boîte de discussion Amazon Q Developer s’affiche. Saisissez votre requête. Amazon Q Developer génère puis met à jour le JSON. Pour accepter les modifications, choisissez **Accepter tout** 1. Choisissez **Créer**. # Mise à jour d’une définition de tâche Amazon ECS à l’aide de la console Une *Révision de définition de tâche* est une copie de la définition de tâche actuelle avec les nouvelles valeurs de paramètres remplaçant les valeurs existantes. Tous les paramètres que vous ne modifiez pas se trouvent dans la nouvelle révision. Pour mettre à jour une définition de tâche, créez une révision de définition de tâche. Si la définition de tâche est utilisée dans un service, vous devez mettre à jour ce dernier de sorte à utiliser la définition de tâche actualisée. Lorsque vous créez une révision, vous pouvez modifier les propriétés de conteneur et les propriétés d'environnement suivantes. + URI de l'image de conteneur + Mappages de ports + Variables d’environnement + Exigences en matière d'infrastructure + Taille de la tâche + Taille du contenant + Rôle de tâche + Rôle d'exécution de tâche + Volumes et points de montage des conteneurs + Registre privé Vous pouvez demander à Amazon Q de fournir des recommandations lorsque vous utilisez l’éditeur JSON. Pour de plus amples informations, consultez [Utilisation d’Amazon Q Developer pour proposer des recommandations de définition de tâche dans la console Amazon ECS](using-amazon-q.md). ## Validation JSON L'éditeur JSON de la console Amazon ECS valide les éléments suivants dans le fichier JSON : + Le fichier est un fichier JSON valide + Le fichier ne contient aucune clé superflue + Le fichier contient le paramètre `familyName` + Il y a au moins une entrée sous `containerDefinitions` ## Procédure ------ #### [ Amazon ECS console ] 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans la barre de navigation, choisissez la région qui contient votre définition de tâche. 1. Dans le panneau de navigation, choisissez **Task definitions** (Définition des tâches). 1. Choisissez la définition de tâche. 1. Sélectionnez la révision de définition de tâche, puis choisissez **Créer une nouvelle révision**, **Créer une nouvelle révision**. 1. Sur la page **Create new task definition revision** (Créer une nouvelle révision de définition de tâche), effectuez les modifications souhaitées. Par exemple, si vous souhaitez modifier les définitions du conteneur existantes (par exemple, l'image de conteneur, les limites de mémoire ou les mappages de ports), sélectionnez le conteneur et appliquez les modifications. Vous pouvez mettre à jour la compatibilité de la définition de tâche vers **AWS Fargate**, **Instances gérées** ou **Instances Amazon EC2**. 1. Vérifiez les informations, puis choisissez **Mettre à jour**. 1. Si votre définition de tâche est utilisée dans un service, mettez-le à jour avec la définition de tâche mise à jour. Pour de plus amples informations, veuillez consulter [Mettre à jour un service Amazon ECS](update-service-console-v2.md). ------ #### [ Amazon ECS console JSON editor ] 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans le panneau de navigation, choisissez **Task definitions** (Définition des tâches). 1. Choisissez **Create new revision** (Créer une nouvelle révision), puis **Create new revision with JSON** (Créer une nouvelle révision avec JSON). 1. Dans la zone de l'éditeur JSON, modifiez votre fichier JSON, Le JSON doit réussir les contrôles de validation spécifiés dans [Validation JSON](#json-validate-for-update). 1. Choisissez **Créer**. ------ # Annulation de l’enregistrement d’une révision de définition de tâche Amazon ECS à l’aide de la console Vous pouvez annuler l’enregistrement de la révision de la définition de tâche afin qu’elle n’apparaisse plus dans vos appels API `ListTaskDefinition` ou dans la console lorsque vous souhaitez exécuter une tâche ou mettre à jour un service. Lorsque vous annulez l'enregistrement de la révision d'une définition de tâche, celle-ci est immédiatement marquée comme `INACTIVE`. Les tâches et services existants qui font référence à une révision de définition de tâche `INACTIVE` continuent à s'exécuter sans interruption. Les services existants qui font référence à une révision de définition de tâche `INACTIVE` peuvent toujours être mis à l'échelle en augmentant ou réduisant le nombre de services souhaité. Vous ne pouvez pas utiliser une révision de définition de tâche `INACTIVE` pour exécuter de nouvelles tâches ou créer de nouveaux services. Vous ne pouvez pas non plus mettre à jour un service existant pour faire référence à une révision de définition de tâche `INACTIVE` (mais ces restrictions peuvent ne prendre effet que jusqu'à 10 minutes suivant l'annulation de l'enregistrement). **Note** Lorsque vous annulez l'enregistrement de toutes les révisions dans une famille de tâches, la famille de définition de tâche est déplacée vers la liste `INACTIVE`. L'ajout d'une nouvelle révision d'une définition de tâche `INACTIVE` ramène la famille de définition de tâche dans la liste `ACTIVE`. À l'heure actuelle, les révisions de définition de tâche `INACTIVE` restent détectables dans votre compte indéfiniment. Cependant, ce comportement est sujet à changement à l'avenir. Par conséquent, vous ne devriez pas compter sur une conservation de révisions de définition de tâche `INACTIVE` au-delà du cycle de vie des tâches et services associés. ## CloudFormation piles Le comportement suivant s’applique aux définitions de tâches qui ont été créées dans la nouvelle console avant le 12 janvier 2023. Lorsque vous créez une définition de tâche, la console Amazon ECS crée automatiquement une CloudFormation pile dont le nom commence par`ECS-Console-V2-TaskDefinition-`. Si vous avez utilisé le AWS CLI ou un AWS SDK pour annuler l'enregistrement de la définition de tâche, vous devez supprimer manuellement la pile de définitions de tâches. Pour plus d’informations, consultez la section [Suppression d’une pile](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html) dans le *Guide de l’utilisateur CloudFormation *. Aucune CloudFormation pile n'est créée automatiquement pour les définitions de tâches créées après le 12 janvier 2023. ## Procédure **Annuler l'enregistrement d'une nouvelle définition de tâche (console Amazon ECS)** 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans la barre de navigation, choisissez la région qui contient votre définition de tâche. 1. Dans le panneau de navigation, choisissez **Task definitions** (Définition des tâches). 1. Sur la page **Task definitions** (Définitions de tâche), choisissez la famille de la définition de tâche contenant une ou plusieurs révisions dont vous souhaitez annuler l'enregistrement. 1. Sur la page **Nom de la définition de la tâche**, sélectionnez les révisions à supprimer, puis choisissez **Actions**, **Annuler l'enregistrement**. 1. Vérifiez les informations contenues dans la fenêtre **Deregister** (Annuler l'enregistrement), puis choisissez **Deregister** (Annuler l'enregistrement) pour terminer. # Suppression de l’enregistrement d’une révision de définition de tâche Amazon ECS à l’aide de la console Lorsque vous n’avez plus besoin d’une révision de définition de tâche spécifique dans Amazon ECS, vous pouvez supprimer la révision de définition de tâche. Lorsque vous supprimez une révision de définition de tâche, elle passe immédiatement de l'état `INACTIVE` à l'état `DELETE_IN_PROGRESS`. Les tâches et services existants qui font référence à une révision de définition de tâche `DELETE_IN_PROGRESS` continuent à s'exécuter sans interruption. Vous ne pouvez pas utiliser une révision de définition de tâche `DELETE_IN_PROGRESS` pour exécuter de nouvelles tâches ou créer de nouveaux services. Vous ne pouvez pas non plus mettre à jour un service existant pour référencer une révision de définition de tâche `DELETE_IN_PROGRESS`. Lorsque vous supprimez toutes les révisions de définition de tâche `INACTIVE`, le nom de la définition de tâche n'est pas affiché dans la console et n'est pas renvoyé dans l'API. Si une révision de définition de tâche est à l’état `DELETE_IN_PROGRESS`, le nom de la définition de tâche est affiché dans la console et renvoyé dans l’API. Le nom de la définition de tâche est conservé par Amazon ECS et la révision est incrémentée la prochaine fois que vous créerez une définition de tâche portant ce nom. ## Ressources Amazon ECS pouvant bloquer une suppression Aucune requête de suppression de définition de tâche ne sera traitée tant qu’il existe des ressources Amazon ECS qui dépendent de la révision de la définition de tâche. Les ressources suivantes peuvent empêcher la suppression d'une définition de tâche : + Tâches autonomes Amazon ECS : la définition de tâche est nécessaire pour que la tâche reste saine. + Tâches d’un service Amazon ECS : la définition de tâche est nécessaire pour que la tâche reste saine. + Déploiements et jeux de tâches d’un service Amazon ECS : la définition de tâche est nécessaire lorsqu’un événement de mise à l’échelle est lancé pour un déploiement ou un jeu de tâches Amazon ECS. Si votre définition de tâche reste `DELETE_IN_PROGRESS` inchangée, vous pouvez utiliser la console ou le AWS CLI pour identifier, puis arrêter les ressources qui bloquent la suppression de la définition de tâche. ### Suppression de la définition de tâche après la suppression de la ressource bloquée Les règles suivantes s'appliquent une fois que vous avez supprimé les ressources bloquant la suppression de la définition de tâche : + Tâches Amazon ECS : la suppression de la définition de tâche peut prendre jusqu'à une heure après l'arrêt de la tâche. + Déploiements et jeux de tâches d’un service Amazon ECS : la suppression de la définition de tâche peut prendre jusqu’à 24 heures après la suppression du déploiement ou du jeu de tâches. ## Procédure **Pour supprimer les définitions de tâche (console Amazon ECS)** Vous devez annuler l'enregistrement d'une révision de définition de tâche avant de la supprimer. Pour de plus amples informations, veuillez consulter [Annulation de l’enregistrement d’une révision de définition de tâche Amazon ECS à l’aide de la console](deregister-task-definition-v2.md). 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans la barre de navigation, choisissez la région qui contient votre définition de tâche. 1. Dans le panneau de navigation, choisissez **Task definitions** (Définition des tâches). 1. Sur la page **Task definitions** (Définitions de tâche), choisissez la famille de la définition de tâche contenant une ou plusieurs révisions que vous souhaitez supprimer. 1. Sur la page **Nom de la définition de la tâche**, sélectionnez les révisions à supprimer, puis choisissez **Actions**, **Supprimer**. Si **Supprimer** n’est pas disponible, vous devez annuler l’enregistrement de la définition de tâche. 1. Vérifiez les informations contenues dans la fenêtre **Supprimer**, puis choisissez **Supprimer** pour terminer. # Cas d’utilisation de définition de tâche Amazon ECS Découvrez comment rédiger des définitions de tâches pour différents AWS services et fonctionnalités. En fonction de votre charge de travail, certains paramètres de définition des tâches doivent être définis. Pour EC2 également, vous devez choisir des instances spécifiques adaptées à la charge de travail. **Topics** + [ # Définitions de tâches Amazon ECS pour les charges de travail GPU ](ecs-gpu.md) + [ # Définitions de tâche Amazon ECS pour les charges de travail de transcodage vidéo ](ecs-vt1.md) + [ # Définitions de tâches Amazon ECS pour les charges de travail d'apprentissage automatique AWS Neuron ](ecs-inference.md) + [ # Définitions de tâche Amazon ECS pour les instances de deep learning ](ecs-dl1.md) + [ # Définitions de tâche Amazon ECS pour les charges de travail ARM 64 bits ](ecs-arm64.md) + [ # Envoyez les journaux Amazon ECS à CloudWatch ](using_awslogs.md) + [ # Envoyer les journaux Amazon ECS à un AWS service ou AWS Partner ](using_firelens.md) + [ # Utilisation d'images autres que des AWS conteneurs dans Amazon ECS ](private-auth.md) + [ # Redémarrage de conteneurs individuels dans les tâches Amazon ECS à l’aide de politiques de redémarrage de conteneurs ](container-restart-policy.md) + [ # Transmission de données sensibles vers un conteneur Amazon ECS ](specifying-sensitive-data.md) # Définitions de tâches Amazon ECS pour les charges de travail GPU Amazon ECS supporte les charges de travail utilisant des GPU lorsque vous créez des clusters avec des instances de conteneurs prenant en charge les GPU. Les instances de conteneur basées sur le GPU Amazon EC2 qui utilisent les types d'instances p2, p3, p5, g3, g4 et g5 fournissent un accès à NVIDIA. GPUs Pour plus d’informations, consultez la section [Instances de calcul accélérées Linux](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html) du *Guide des types d’instance Amazon EC2*. Amazon ECS fournit une AMI optimisée pour le GPU qui est fournie avec des pilotes de noyau NVIDIA préconfigurés et une exécution du GPU du Docker. Pour de plus amples informations, veuillez consulter [Linux optimisé pour Amazon ECS AMIs](ecs-optimized_AMI.md). Vous pouvez en désigner un certain nombre GPUs dans votre définition de tâche pour prendre en compte le placement des tâches au niveau du conteneur. Amazon ECS planifie les instances de conteneur disponibles qui prennent en charge GPUs et épinglent GPUs les conteneurs physiques aux conteneurs appropriés pour des performances optimales. Les types d'instances GPU Amazon EC2 suivants sont pris en charge. Pour plus d’informations, consultez les sections [Instances Amazon EC2 P2](https://aws.amazon.com/ec2/instance-types/p2/), [Instances Amazon EC2 P3](https://aws.amazon.com/ec2/instance-types/p3/), [Instances Amazon EC2 P4d](https://aws.amazon.com/ec2/instance-types/p4/), [Instances Amazon EC2 P5](https://aws.amazon.com/ec2/instance-types/p5/), [Instances Amazon EC2 G3](https://aws.amazon.com/ec2/instance-types/g3/), [Instances Amazon EC2 G4](https://aws.amazon.com/ec2/instance-types/g4/), [Instances Amazon EC2 G5](https://aws.amazon.com/ec2/instance-types/g5/), [Instances Amazon EC2 G6](https://aws.amazon.com/ec2/instance-types/g6/) et [Instances Amazon EC2 G6e](https://aws.amazon.com/ec2/instance-types/g6e/). | Type d’instance | GPUs | Mémoire GPU (Gio) | v CPUs | Mémoire (Gio) | | --- | --- | --- | --- | --- | | 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 | 1 152 | | 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 | | g6e.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 | Vous pouvez récupérer l'identifiant Amazon Machine Image (AMI) pour Amazon ECS-Optimized AMIs en interrogeant l'API AWS Systems Manager Parameter Store. Avec ce paramètre, vous n'avez pas besoin de rechercher manuellement l'AMI optimisée pour Amazon ECS. IDs Pour plus d'informations sur l'API Systems Manager Parameter Store, consultez [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). L'utilisateur que vous utilisez doit disposer de l'autorisation IAM `ssm:GetParameter` pour récupérer les métadonnées de l'AMI optimisée pour Amazon ECS. ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1 ``` # Utilisation GPUs avec les instances gérées Amazon ECS Les instances gérées Amazon ECS prennent en charge le calcul accéléré par GPU pour les charges de travail telles que le machine learning, le calcul haute performance et le traitement vidéo via les types d’instances Amazon EC2 suivants. Pour plus d’informations sur les types d’instances pris en charge sur les instances gérées Amazon ECS, consultez la section [Types d’instances gérées Amazon ECS](managed-instances-instance-types.md). Voici un sous-ensemble des types d’instances basés sur le GPU pris en charge sur les instances gérées Amazon ECS : + `g4dn` : optimisé par NVIDIA T4 GPUs, adapté à l’inférence de machine learning, à la vision par ordinateur et aux applications gourmandes en graphismes. + `g5` : optimisé par NVIDIA A10G GPUs, offrant des performances supérieures pour les applications à forte intensité graphique et les charges de travail de machine learning. + `p3` : optimisé par NVIDIA V100 GPUs, conçu pour le calcul haute performance et l’entraînement du deep learning. + `p4d` : optimisé par NVIDIA A100 GPUs, offrant les meilleures performances pour l’entraînement du machine learning et le calcul haute performance. Lorsque vous utilisez des types d’instances compatibles GPU avec des instances gérées Amazon ECS, les pilotes NVIDIA et le kit d’outils CUDA sont préinstallés sur l’instance, ce qui facilite l’exécution de charges de travail accélérées par GPU. ## Sélection d’instances compatibles GPU Pour sélectionner des types d’instances compatibles GPU pour les charges de travail de vos instances gérées Amazon ECS, utilisez l’objet `instanceRequirements` dans le modèle de lancement du fournisseur de capacité. L’extrait de code suivant présente les attributs qui peuvent être utilisés pour sélectionner des instances compatibles GPU. ``` { "instanceRequirements": { "acceleratorTypes": "gpu", "acceleratorCount": 1, "acceleratorManufacturers": ["nvidia"] } } ``` L’extrait de code suivant présente les attributs qui peuvent être utilisés pour spécifier les types d’instances compatibles GPU dans le modèle de lancement. ``` { "instanceRequirements": { "allowedInstanceTypes": ["g4dn.xlarge", "p4de.24xlarge"] } } ``` ## Images de conteneurs compatibles GPU Pour les utiliser GPUs dans vos conteneurs, vous devez utiliser des images de conteneur contenant les bibliothèques et outils GPU nécessaires. NVIDIAfournit plusieurs images de conteneur prédéfinies que vous pouvez utiliser comme base pour vos charges de travail GPU, notamment les suivantes : + `nvidia:cuda` : images de base avec le kit d’outils CUDA pour le calcul GPU. + `tensorflow/tensorflow:latest-gpu` : TensorFlow avec support GPU. + `pytorch/pytorch:latest-cuda` : PyTorch avec support GPU. Pour un exemple de définition de tâche pour Amazon ECS sur des instances gérées Amazon ECS impliquant l'utilisation de GPUs, consultez[Spécification GPUs dans une définition de tâche Amazon ECS](ecs-gpu-specifying.md). ## Considérations **Note** La prise en charge du type de famille d'instances g2 est obsolète. Le type de famille d'instances p2 n'est pris en charge que sur les versions antérieures à la version `20230912` des AMI optimisées pour le GPU Amazon ECS. Si vous devez continuer à utiliser des instances p2, veuillez consulter [Que faire si vous avez besoin d'une instance P2](#p2-instance). Les mises à jour sur place des NVIDIA/CUDA pilotes sur ces deux types de familles d'instances peuvent entraîner des défaillances de la charge de travail du GPU. Nous vous recommandons de prendre en compte les points suivants avant de commencer à travailler avec GPUs Amazon ECS. + Vos clusters peuvent contenir une combinaison d'instances de conteneur GPU et non GPU. + Vous pouvez exécuter des charges de travail GPU sur des instances externes. Lorsque vous enregistrez une instance externe auprès de votre cluster, assurez-vous que l'indicateur `--enable-gpu` est inclus dans le script d'installation. Pour de plus amples informations, veuillez consulter [Enregistrement d’une instance externe dans un cluster Amazon ECS](ecs-anywhere-registration.md). + Vous devez définir `ECS_ENABLE_GPU_SUPPORT` sur `true` dans votre fichier de configuration d'agent. Pour de plus amples informations, veuillez consulter [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md). + Lorsque vous exécutez une tâche ou créez un service, vous pouvez utiliser des attributs de type d'instance lors de la configuration des contraintes de placement des tâches afin de déterminer sur quelles instances de conteneur la tâche est lancée. Ainsi, vous pouvez utiliser plus efficacement vos ressources. Pour de plus amples informations, veuillez consulter [Comment Amazon ECS place les tâches sur des instances de conteneur](task-placement.md). L'exemple suivant lance une tâche sur une instance de conteneur `g4dn.xlarge` dans votre cluster par défaut. ``` 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 ``` + Pour chaque conteneur dont les besoins en ressources GPU sont spécifiés dans la définition du conteneur, Amazon ECS définit l'exécution du conteneur comme étant celle du conteneur NVIDIA. + L'exécution du conteneur NVIDIA nécessite que certaines variables d'environnement soient définies dans le conteneur pour fonctionner correctement. Pour obtenir la liste de ces variables d’environnement, consultez la section [Configurations spécialisées avec Docker](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html?highlight=environment%20variable). Amazon ECS définit la valeur de la variable d'`NVIDIA_VISIBLE_DEVICES`environnement comme une liste des périphériques GPU IDs qu'Amazon ECS attribue au conteneur. Pour les autres variables d'environnement requises, Amazon ECS ne les définit pas. Assurez-vous que votre image de conteneur les définit ou qu'elles sont définies dans la définition du conteneur. + La famille de types d'instances p5 est prise en charge sur la version `20230929` et les versions ultérieures des AMI optimisées pour le GPU Amazon ECS. + La famille de types d'instance g4 est prise en charge sur la version `20230913` et les versions ultérieures des AMI optimisées pour le GPU Amazon ECS. Pour de plus amples informations, veuillez consulter [Linux optimisé pour Amazon ECS AMIs](ecs-optimized_AMI.md). Elle n'est pas prise en charge dans le flux de travail Create Cluster (Créer un cluster) dans la console Amazon ECS. Pour utiliser ces types d'instances, vous devez soit utiliser la console Amazon EC2 AWS CLI, soit l'API et enregistrer manuellement les instances dans votre cluster. + Le type d'instance p4d.24xlarge ne fonctionne qu'avec CUDA 11 ou version ultérieure. + L'AMI optimisée pour le GPU Amazon ECS IPv6 est activée, ce qui pose des problèmes lors de son utilisation. `yum` Ce problème peut être résolu en configurant `yum` pour l'utiliser IPv4 avec la commande suivante. ``` echo "ip_resolve=4" >> /etc/yum.conf ``` + Lorsque vous créez une image de conteneur qui n'utilise pas les images de NVIDIA/CUDA base, vous devez définir l'une des valeurs suivantes pour la variable d'exécution du `NVIDIA_DRIVER_CAPABILITIES` conteneur : + `utility,compute` + `all` Pour savoir comment définir la variable, veuillez consulter [Contrôle de l'exécution du conteneur NVIDIA](https://sarus.readthedocs.io/en/stable/user/custom-cuda-images.html#controlling-the-nvidia-container-runtime) sur le site Web de NVIDIA. + GPUs ne sont pas pris en charge sur les conteneurs Windows. # Lancement d’une instance de conteneur GPU pour Amazon ECS Pour utiliser une instance GPU sur Amazon ECS avec Amazon EC2, vous devez créer un modèle de lancement, un fichier de données utilisateur, puis lancer l’instance. Vous pouvez ensuite exécuter une tâche qui utilise une définition de tâche configurée pour le GPU. ## Utiliser un modèle de lancement Vous pouvez créer un modèle de lancement. + Créez un modèle de lancement qui utilise l’ID d’AMI GPU optimisé pour Amazon ECS pour l’AMI. Pour plus d’informations sur la création d’un modèle de lancement, consultez la section [Créer un modèle de lancement à l’aide des paramètres que vous définissez](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#create-launch-template-define-parameters) dans le *Guide de l’utilisateur Amazon EC2*. Utilisez l’ID d’AMI de l’étape précédente pour l’**Amazon Machine image**. Pour plus d’informations sur la façon de spécifier l’ID AMI avec le paramètre Systems Manager, consultez la section [Spécifier un paramètre Systems Manager dans un modèle de lancement](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#use-an-ssm-parameter-instead-of-an-ami-id) dans le *Guide de l’utilisateur Amazon EC2*. Ajoutez ce qui suit à la section **Données utilisateur** du modèle de lancement. Remplacez *cluster-name* par le nom de votre cluster. ``` #!/bin/bash echo ECS_CLUSTER=cluster-name >> /etc/ecs/ecs.config; echo ECS_ENABLE_GPU_SUPPORT=true >> /etc/ecs/ecs.config ``` ## Utilisez le AWS CLI Vous pouvez utiliser le AWS CLI pour lancer l'instance de conteneur. 1. Créez un fichier appelé `userdata.toml`. Ce fichier est utilisé pour les données utilisateur de l'instance. Remplacez *cluster-name* par le nom de votre cluster. ``` #!/bin/bash echo ECS_CLUSTER=cluster-name >> /etc/ecs/ecs.config; echo ECS_ENABLE_GPU_SUPPORT=true >> /etc/ecs/ecs.config ``` 1. Exécutez la commande suivante pour obtenir l’ID d’AMI GPU. Utilisez ceci lors de l'étape suivante. ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1 ``` 1. Exécutez la commande suivante pour lancer l’instance GPU. N'oubliez pas de remplacer les paramètres suivants : + *subnet*Remplacez-le par l'ID du sous-réseau privé ou public dans lequel votre instance sera lancée. + *gpu\$1ami*Remplacez-le par l'ID AMI de l'étape précédente. + *t3.large*Remplacez-le par le type d'instance que vous souhaitez utiliser. + Remplacez *region* par le code de région. ``` 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. Exécutez la commande suivante pour vérifier que l'instance de conteneur est enregistrée auprès du cluster. Lorsque vous exécutez cette commande, n'oubliez pas de remplacer les paramètres suivants : + Remplacez *cluster* par le nom de votre cluster. + *region*Remplacez-le par votre code de région. ``` aws ecs list-container-instances --cluster cluster-name --region region ``` # Spécification GPUs dans une définition de tâche Amazon ECS Pour utiliser l'instance GPUs sur une instance de conteneur et le runtime du GPU Docker, assurez-vous d'indiquer le nombre requis par GPUs votre conteneur dans la définition de la tâche. Au fur et à mesure que les conteneurs compatibles GPUs sont placés, l'agent de conteneur Amazon ECS épingle le nombre de conteneurs physiques GPUs souhaité sur le conteneur approprié. Le nombre de conteneurs GPUs réservés à tous les conteneurs d'une tâche ne peut pas dépasser le nombre de conteneurs disponibles GPUs sur l'instance de conteneur sur laquelle la tâche est lancée. Pour de plus amples informations, veuillez consulter [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md). **Important** Si vos exigences en matière de GPU ne sont pas spécifiées dans la définition de tâche, la tâche utilise l'exécution par défaut du Docker. L'exemple suivant illustre le format JSON pour les exigences de GPU dans une définition de tâche : ``` { "containerDefinitions": [ { ... "resourceRequirements" : [ { "type" : "GPU", "value" : "2" } ], }, ... } ``` L'exemple suivant illustre la syntaxe d'un conteneur Docker qui spécifie une exigence GPU. Ce conteneur en utilise deux GPUs, exécute l'`nvidia-smi`utilitaire, puis se ferme. ``` { "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" } ``` L'exemple de définition de tâche suivant montre un TensorFlow conteneur qui imprime le nombre de tâches disponibles GPUs. La tâche s’exécute sur des instances gérées Amazon ECS, nécessite un GPU et utilise une instance `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", } ``` ## Partagez GPUs Lorsque vous souhaitez partager GPUs, vous devez configurer les éléments suivants. 1. Supprimez les exigences en matière de ressources GPU de vos définitions de tâches afin qu'Amazon ECS ne réserve aucune GPUs ressource devant être partagée. 1. Ajoutez les données utilisateur suivantes à vos instances lorsque vous souhaitez les partager GPUs. NVIDIA deviendra ainsi le moteur d'exécution du conteneur Docker par défaut sur l'instance de conteneur afin que tous les conteneurs Amazon ECS puissent utiliser le GPUs. Pour plus d’informations, consultez la section [Exécution de commandes lors du lancement d’une instance EC2 avec des données utilisateur](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) dans le *Guide de l’utilisateur 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. Définissez la variable d’environnement `NVIDIA_VISIBLE_DEVICES` sur votre conteneur. Pour ce faire, vous pouvez spécifier la variable d’environnement dans votre définition de tâche. Pour plus d’informations sur les valeurs valides, consultez la section[Énumération des GPU](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html#gpu-enumeration) sur le site de documentation de NVIDIA. ## Que faire si vous avez besoin d'une instance P2 Si vous avez besoin d'utiliser une instance P2, vous pouvez utiliser l'une des options suivantes pour continuer à utiliser ces instances. Vous devez modifier les données utilisateur de l'instance pour les deux options. Pour plus d’informations, consultez la section [Exécution de commandes lors du lancement d’une instance EC2 avec des données utilisateur](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) dans le *Guide de l’utilisateur Amazon EC2*. **Utiliser la dernière AMI optimisée pour le GPU prise en charge** Vous pouvez utiliser la version `20230906` de l'AMI optimisée pour le GPU et ajouter les éléments suivants aux données utilisateur de l'instance. Remplacez cluster-name par le nom de votre cluster. ``` #!/bin/bash echo "exclude=*nvidia* *cuda*" >> /etc/yum.conf echo "ECS_CLUSTER=cluster-name" >> /etc/ecs/ecs.config ``` **Utiliser la dernière AMI optimisée pour le GPU et mettre à jour les données utilisateur** Vous pouvez ajouter ce qui suit aux données utilisateur de l'instance. Cela désinstalle les pilotes Nvidia 535/Cuda12.2, puis installe les pilotes Nvidia 470/Cuda11.4 et corrige la version. ``` #!/bin/bash yum remove -y cuda-toolkit* nvidia-driver-latest-dkms* tmpfile=$(mktemp) cat >$tmpfile <> /etc/yum.conf nvidia-smi ``` **Créer votre propre AMI optimisée pour le GPU compatible avec P2** Vous pouvez créer votre propre AMI Amazon ECS personnalisée optimisée pour le GPU et compatible avec les instances P2, puis lancer des instances P2 à l'aide de l'AMI. 1. Exécutez la commande suivante pour cloner le `amazon-ecs-ami repo`. ``` git clone https://github.com/aws/amazon-ecs-ami ``` 1. Définissez l'agent Amazon ECS requis et les versions de l'AMI Amazon Linux source dans `release.auto.pkrvars.hcl` ou `overrides.auto.pkrvars.hcl`. 1. Exécutez la commande suivante pour créer une AMI EC2 privée compatible avec P2. Remplacez la région par la région de l'instance. ``` REGION=region make al2keplergpu ``` 1. Utilisez l'AMI avec les données utilisateur de l'instance suivantes pour vous connecter au cluster Amazon ECS. Remplacez cluster-name par le nom de votre cluster. ``` #!/bin/bash echo "ECS_CLUSTER=cluster-name" >> /etc/ecs/ecs.config ``` # Définitions de tâche Amazon ECS pour les charges de travail de transcodage vidéo Pour utiliser les charges de travail de transcodage vidéo sur Amazon ECS, enregistrez les instances [Amazon VT1 EC2](https://aws.amazon.com/ec2/instance-types/vt1/). Après avoir enregistré ces instances, vous pouvez exécuter des charges de travail de transcodage vidéo en direct et prérendues en tant que tâches sur Amazon ECS. Les VT1 instances Amazon EC2 utilisent les cartes de transcodage multimédia Xilinx U30 pour accélérer les charges de travail de transcodage vidéo en direct et pré-rendu. **Note** Pour obtenir des instructions sur l'exécution de charges de travail de transcodage vidéo dans des conteneurs autres qu'Amazon ECS, consultez la [documentation Xilinx](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#working-with-docker-vt1). ## Considérations Avant de commencer VT1 le déploiement sur Amazon ECS, tenez compte des points suivants : + Vos clusters peuvent contenir à la fois des instances VT1 et des VT1 non-instances. + Vous avez besoin d'une application Linux qui utilise des cartes de transcodage multimédia Xilinx U30 avec des codecs AVC (H.264) et HEVC (H.265) accélérés. **Important** Les applications qui utilisent d'autres codecs peuvent ne pas améliorer les performances des VT1 instances. + Une seule tâche de transcodage peut être exécutée sur une carte U30. Chaque carte est associée à deux appareils. Vous pouvez exécuter autant de tâches de transcodage qu'il y a de cartes pour chacune de vos VT1 instances. + Lorsque vous exécutez une tâche autonome ou créez un service, vous pouvez utiliser des attributs de type d'instance lors de la configuration des contraintes de placement des tâches. Cela garantit que la tâche est lancée sur l'instance de conteneur que vous spécifiez. Cela vous permet de vous assurer que vous utilisez vos ressources de manière efficace et que vos tâches de transcodage vidéo incombent à vos VT1 instances. Pour de plus amples informations, veuillez consulter [Comment Amazon ECS place les tâches sur des instances de conteneur](task-placement.md). Dans l'exemple suivant, une tâche est exécutée sur une instance `vt1.3xlarge` de votre cluster `default`. ``` aws ecs run-task \ --cluster default \ --task-definition vt1-3xlarge-xffmpeg-processor \ --placement-constraints type=memberOf,expression="attribute:ecs.instance-type == vt1.3xlarge" ``` + Vous configurez un conteneur pour utiliser une carte U30 spécifique disponible sur l'instance de conteneur hôte. Vous pouvez effectuer cette opération en utilisant le paramètre `linuxParameters` et en spécifiant les détails de l'appareil. Pour de plus amples informations, veuillez consulter [Exigences relatives à la définition de tâche](#ecs-vt1-requirements). ## Utilisation d'une VT1 AMI Vous avez deux options pour exécuter une AMI sur des instances de conteneur Amazon EC2 pour Amazon ECS. La première option consiste à utiliser l'AMI officielle Xilinx sur AWS Marketplace. La deuxième option consiste à créer votre propre AMI à partir de l'exemple du référentiel. + [Xilinx propose AMIs sur le. AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-phvk6d4mq3hh6) + Amazon ECS fournit un exemple de référentiel que vous pouvez utiliser pour créer une AMI pour les charges de travail de transcodage vidéo. Cette AMI est fournie avec les pilotes Xilinx U30. Vous pouvez trouver le référentiel contenant les scripts Packer sur [GitHub](https://github.com/aws-samples/aws-vt-baseami-pipeline). Pour plus d'informations sur Packer, consultez la [documentation Packer](https://developer.hashicorp.com/packer/docs). ## Exigences relatives à la définition de tâche Pour exécuter des conteneurs de transcodage vidéo sur Amazon ECS, votre définition de tâche doit contenir une application de transcodage vidéo utilisant les codecs H.264/AVC et H.265/HEVC accélérés. Vous pouvez créer une image de conteneur en suivant les étapes indiquées sur le [Xilinx GitHub](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#creating-a-docker-image-for-vt1-usage). La définition de tâche doit être spécifique au type d'instance. Les types d'instance sont 3xlarge, 6xlarge et 24xlarge. Vous devez configurer un conteneur pour utiliser des appareils Xilinx U30 spécifiques disponibles sur l'instance de conteneur hôte. Vous pouvez effectuer cette opération à l'aide du paramètre `linuxParameters`. Le tableau suivant détaille les cartes et SoCs les appareils spécifiques à chaque type d'instance. | Type d'instance | v CPUs | RAM (Gio) | Cartes accélératrices U30 | Appareils XCU30 SoC adressables | Chemins de l'appareil | | --- | --- | --- | --- | --- | --- | | 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 | **Important** Si la définition de tâche répertorie les périphériques dont l'instance EC2 ne dispose pas, la tâche ne s'exécute pas. Lorsque la tâche échoue, le message d'erreur suivant s'affiche dans `stoppedReason` : `CannotStartContainerError: Error response from daemon: error gathering device information while adding custom device "/dev/dri/renderD130": no such file or directory`. # Spécification du transcodage vidéo dans une définition de tâche Amazon ECS Dans l'exemple suivant, la syntaxe utilisée pour définir une tâche d'un conteneur Linux sur Amazon EC2 est fournie. Cette définition de tâche concerne les images de conteneur créées conformément à la procédure fournie dans la [documentation Xilinx](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#creating-a-docker-image-for-vt1-usage). Si vous utilisez cet exemple, remplacez `image` par votre propre image, et copiez vos fichiers vidéo dans l'instance dans le répertoire `/home/ec2-user`. ------ #### [ vt1.3xlarge ] 1. Créez un fichier texte nommé `vt1-3xlarge-ffmpeg-linux.json` avec le contenu suivant. ``` { "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. Enregistrez la définition de tâche. ``` 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. Créez un fichier texte nommé `vt1-6xlarge-ffmpeg-linux.json` avec le contenu suivant. ``` { "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. Enregistrez la définition de tâche. ``` 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. Créez un fichier texte nommé `vt1-24xlarge-ffmpeg-linux.json` avec le contenu suivant. ``` { "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. Enregistrez la définition de tâche. ``` aws ecs register-task-definition --family vt1-24xlarge-xffmpeg-processor --cli-input-json file://vt1-24xlarge-xffmpeg-linux.json --region us-east-1 ``` ------ # Définitions de tâches Amazon ECS pour les charges de travail d'apprentissage automatique AWS Neuron Vous pouvez enregistrer des instances [Amazon EC2 Trn1](https://aws.amazon.com/ec2/instance-types/trn1/), Amazon EC2 [Trn2, Amazon EC2](https://aws.amazon.com/ec2/instance-types/trn2/) [Inf1 et Amazon EC2 Inf2](https://aws.amazon.com/ec2/instance-types/inf1/) [dans vos clusters pour les charges de travail d'apprentissage](https://aws.amazon.com/ec2/instance-types/inf2/) automatique. [Les instances Amazon EC2 Trn1 et Trn2 sont alimentées par des puces Trainium.AWS](https://aws.amazon.com/ai/machine-learning/trainium/) Ces instances fournissent une formation performante et peu coûteuse pour machine learning dans le cloud. Vous pouvez entraîner un modèle d'inférence d'apprentissage automatique à l'aide d'un framework d'apprentissage automatique avec AWS Neuron sur une instance Trn1 ou Trn2. Vous pouvez ensuite exécuter le modèle sur une instance Inf1 ou sur une instance Inf2 pour utiliser l'accélération des puces AWS Inferentia. Les instances Inf1 et Inf2 d'Amazon EC2 sont alimentées par des [puces AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/). Elles fournissent des performances élevées et les inférences de coûts les plus bas dans le cloud. Les modèles de machine learning sont déployés sur des conteneurs à l'aide d'[AWS Neuron](https://aws.amazon.com/ai/machine-learning/neuron/), qui est un kit de développement logiciel (SDK) spécialisé. Le SDK comprend un compilateur, un environnement d'exécution et des outils de profilage qui optimisent les performances d'apprentissage automatique des puces d'apprentissage AWS automatique. AWS Neuron prend en charge les frameworks d'apprentissage automatique populaires tels que TensorFlow, PyTorch, et Apache MXNet. ## Considérations Avant de commencer à déployer Neuron sur Amazon ECS, prenez en compte ce qui suit : + Vos clusters peuvent contenir un mélange de Trn1, Trn2, Inf1, Inf2 et d'autres instances. + Vous avez besoin d'une application Linux dans un conteneur qui utilise un framework d'apprentissage automatique compatible avec AWS Neuron. **Important** Les applications qui utilisent d'autres frameworks peuvent ne pas avoir amélioré les performances sur les instances Trn1, Trn2, Inf1 et Inf2. + Une seule tâche d'inférence ou d'entraînement d'inférence peut être exécutée sur chaque puce [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/) ou [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/). Pour Inf1, chaque puce en possède 4 NeuronCores. Pour Trn1, Trn2 et Inf2, chaque puce en possède 2. NeuronCores Vous pouvez exécuter autant de tâches qu'il y a de puces pour chacune de vos instances Trn1, Trn2, Inf1 et Inf2. + Lorsque vous exécutez une tâche autonome ou créez un service, vous pouvez utiliser des attributs de type d'instance lors de la configuration des contraintes de placement des tâches. Cela garantit que la tâche est lancée sur l'instance de conteneur que vous spécifiez. Cela peut vous aider à optimiser l'utilisation globale des ressources et à garantir que les tâches relatives aux charges de travail d'inférence se trouvent sur vos instances Trn1, Trn2, Inf1 et Inf2. Pour de plus amples informations, veuillez consulter [Comment Amazon ECS place les tâches sur des instances de conteneur](task-placement.md). Dans l'exemple suivant, une tâche est exécutée sur une instance `Inf1.xlarge` de votre cluster `default`. ``` aws ecs run-task \ --cluster default \ --task-definition ecs-inference-task-def \ --placement-constraints type=memberOf,expression="attribute:ecs.instance-type == Inf1.xlarge" ``` + Les besoins en ressources Neuron ne peuvent pas être définis dans une définition de tâche. Vous configurez plutôt un conteneur pour utiliser des puces AWS Trainium ou AWS Inferentia spécifiques disponibles sur l'instance de conteneur hôte. Pour ce faire, utilisez le paramètre `linuxParameters` et en spécifiant les détails du dispositif. Pour de plus amples informations, veuillez consulter [Exigences relatives à la définition de tâche](#ecs-inference-requirements). ## Utilisation de l’AMI Amazon Linux 2023 (Neuron) optimisée pour Amazon ECS Amazon ECS fournit une AMI optimisée pour Amazon ECS basée sur Amazon Linux 2023 pour les charges de travail AWS Trainium et AWS Inferentia. Il est livré avec les pilotes AWS Neuron et le runtime pour Docker. Cette AMI facilite l'exécution de charges de travail d'inférence de machine learning sur Amazon ECS. Nous vous recommandons d’utiliser l’AMI Amazon Linux 2023 (Neuron) optimisée pour Amazon ECS lors du lancement de vos instances Trn1, Inf1 et Inf2 Amazon EC2. Vous pouvez récupérer l'AMI Amazon Linux 2023 (Neuron) actuellement optimisée pour Amazon ECS à l'aide de la commande AWS CLI suivante. ``` aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/recommended ``` ## Exigences relatives à la définition de tâche Pour déployer Neuron sur Amazon ECS, votre définition de tâche doit contenir la définition du conteneur d'un conteneur prédéfini servant le modèle d'inférence pour. TensorFlow Il est fourni par AWS Deep Learning Containers. Ce conteneur contient le runtime AWS Neuron et l'application TensorFlow Serving. Au démarrage, ce conteneur récupère votre modèle depuis Amazon S3, lance Neuron TensorFlow Serving avec le modèle enregistré et attend les demandes de prédiction. Dans l'exemple suivant, l'image du conteneur est TensorFlow 1.15 et Ubuntu 18.04. Une liste complète des Deep Learning Containers prédéfinis optimisés pour Neuron est disponible sur. GitHub Pour plus d'informations, consultez la section [Utilisation de 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 ``` Alternativement, vous pouvez également créer votre propre image de conteneur sidecar Neuron. Pour plus d'informations, consultez [Tutoriel : Neuron TensorFlow Serving](https://github.com/aws-neuron/aws-neuron-sdk/blob/master/frameworks/tensorflow/tensorflow-neuron/tutorials/tutorials-tensorflow-utilizing-neuron-capabilities.rst) dans le *guide du AWS Apprentissage profond (deep learning) AMIs développeur*. La définition de tâche doit être spécifique au type d'instance unique. Vous devez configurer un conteneur pour utiliser des appareils AWS Trainium ou AWS Inferentia spécifiques disponibles sur l'instance de conteneur hôte. Vous pouvez effectuer cette opération à l'aide du paramètre `linuxParameters`. Pour un exemple de définition de tâche, voir[Spécification de l'apprentissage automatique AWS Neuron dans une définition de tâche Amazon ECS](ecs-inference-task-def.md). Le tableau suivant détaille les cartes et les puces qui sont spécifiques à chaque type d'instance. | Type d'instance | v CPUs | RAM (Gio) | AWS puces accélératrices ML | Chemins de l'appareil | | --- | --- | --- | --- | --- | | 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 | # Spécification de l'apprentissage automatique AWS Neuron dans une définition de tâche Amazon ECS Voici un exemple de définition de tâche Linux pour `inf1.xlarge` qui affiche la syntaxe à utiliser. ``` { "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" } ] } ``` # Définitions de tâche Amazon ECS pour les instances de deep learning Pour utiliser les charges de travail d'apprentissage profond sur Amazon ECS, enregistrez les instances [Amazon DL1](https://aws.amazon.com/ec2/instance-types/dl1/) EC2 dans vos clusters. Les DL1 instances Amazon EC2 sont alimentées par les accélérateurs Gaudi de Habana Labs (une société Intel). Utilisez le SDK Habana SynapseAI pour vous connecter aux accélérateurs Habana Gaudi. Le SDK prend en charge les frameworks d'apprentissage automatique populaires, TensorFlow et PyTorch. ## Considérations Avant de commencer DL1 le déploiement sur Amazon ECS, tenez compte des points suivants : + Vos clusters peuvent contenir à la fois des instances DL1 et des DL1 non-instances. + Lorsque vous exécutez une tâche autonome ou créez un service, vous pouvez utiliser des attributs de type d'instance lors de la configuration des contraintes de placement des tâches afin de garantir sur quelles instances de conteneur la tâche, que vous spécifiez, est lancée. Cela garantit que vos ressources sont utilisées efficacement et que les tâches relatives aux charges de travail liées au deep learning se situent sur vos DL1 instances. Pour de plus amples informations, veuillez consulter [Comment Amazon ECS place les tâches sur des instances de conteneur](task-placement.md). L'exemple suivant exécute une tâche sur une instance `dl1.24xlarge` de votre cluster `default`. ``` aws ecs run-task \ --cluster default \ --task-definition ecs-dl1-task-def \ --placement-constraints type=memberOf,expression="attribute:ecs.instance-type == dl1.24xlarge" ``` ## Utilisation d'une DL1 AMI Trois options s'offrent à vous pour exécuter une AMI sur des DL1 instances Amazon EC2 pour Amazon ECS : + AWS Marketplace AMIs qui sont fournis par Habana [ici.](https://aws.amazon.com/marketplace/pp/prodview-h24gzbgqu75zq) + Habana Deep Learning AMIs fourni par Amazon Web Services. Comme il n'est pas inclus, vous devez installer l'agent de conteneur Amazon ECS séparément. + Utilisez Packer pour créer une AMI personnalisée fournie par le [GitHubdépôt](https://github.com/aws-samples/aws-habana-baseami-pipeline). Pour plus d'informations, consultez la section [documentation Packer](https://developer.hashicorp.com/packer/docs). # Spécification du deep learning dans une définition de tâche Amazon ECS Pour exécuter des conteneurs d'apprentissage profond accéléré Habana Gaudi sur Amazon ECS, votre définition de tâche doit contenir la définition de conteneur d'un conteneur prédéfini qui sert le modèle d'apprentissage profond pour TensorFlow ou PyTorch utilisant Habana SynapseAI fourni par Deep Learning Containers. AWS L'image de conteneur suivante contient la TensorFlow version 2.7.0 et Ubuntu 20.04. Une liste complète des Deep Learning Containers prédéfinis et optimisés pour les accélérateurs Habana Gaudi est mise à jour sur. GitHub Pour de plus amples informations, veuillez consulter la section [Conteneurs d'entraînement Habana](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#habana-training-containers). ``` 763104351884.dkr.ecr.us-east-1.amazonaws.com/tensorflow-training-habana:2.7.0-hpu-py38-synapseai1.2.0-ubuntu20.04 ``` Voici un exemple de définition de tâche de conteneurs Linux sur Amazon EC2 qui affiche la syntaxe à utiliser. Cet exemple utilise une image contenant l'outil HL-SMI (HL-SMI) Habana Labs, disponible ici : `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" } ] } ``` # Définitions de tâche Amazon ECS pour les charges de travail ARM 64 bits Amazon ECS prend en charge l'utilisation d'applications ARM 64 bits. Vous pouvez exécuter vos applications sur la plateforme optimisée par les [processeurs AWS  Graviton](https://aws.amazon.com/ec2/graviton/). Cette plateforme est adaptée à une grande variété de charges de travail. Cela inclut les charges de travail telles que les serveurs d'applications, les microservices, le calcul hautes performances, l'inférence de machine learning basée sur le processeur, l'encodage vidéo, l'automatisation de la conception électronique, les jeux vidéos, les bases de données open source et les caches en mémoire. ## Considérations Avant de commencer à déployer des définitions de tâche utilisant l'architecture ARM 64 bits, tenez compte des points suivants : + Les applications peuvent utiliser le Fargate ou. EC2s + Les applications ne peuvent utiliser que le système d'exploitation Linux. + Pour le type Fargate, les applications doivent utiliser la version de plateforme `1.4.0` Fargate ou version ultérieure. + Les applications peuvent être utilisées Fluent Bit ou à CloudWatch des fins de surveillance. + Pour le Fargate, les Régions AWS éléments suivants ne prennent pas en charge les charges de travail ARM 64 bits : + USA Est (Virginie du Nord), la zone de disponibilité `use1-az3` + Pour EC2, consultez les points suivants pour vérifier que votre Région prend en charge le type d’instance que vous souhaitez utiliser : + [Instances M6g Amazon EC2](https://aws.amazon.com/ec2/instance-types/m6) + [Instances T4g Amazon EC2](https://aws.amazon.com/ec2/instance-types/t4/) + [Instances C6g Amazon EC2](https://aws.amazon.com/ec2/instance-types/c6g/) + [Instances R6gd Amazon EC2](https://aws.amazon.com/ec2/instance-types/r6/) + [Instances X2gd Amazon EC2](https://aws.amazon.com/ec2/instance-types/x2/) Vous pouvez également utiliser la commande `describe-instance-type-offerings` Amazon EC2 avec un filtre pour afficher l'offre d'instances pour votre Région. ``` aws ec2 describe-instance-type-offerings --filters Name=instance-type,Values=instance-type --region region ``` L'exemple suivant vérifie la disponibilité du type d'instance M6 dans la Région USA Est (Virginie du Nord) (us-east-1). ``` aws ec2 describe-instance-type-offerings --filters "Name=instance-type,Values=m6*" --region us-east-1 ``` Pour plus d'informations, consultez [describe-instance-type-offerings ](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html)le manuel *Amazon EC2 Command Line* Reference. # Spécification de l’architecture ARM dans votre définition de tâche Amazon ECS Pour utiliser l'architecture ARM, spécifiez `ARM64` pour paramètre de la définition de la tâche `cpuArchitecture`. Dans l'exemple suivant, l'architecture ARM est spécifiée dans une définition de tâche. Elles sont au format JSON. ``` { "runtimePlatform": { "operatingSystemFamily": "LINUX", "cpuArchitecture": "ARM64" }, ... } ``` Dans l'exemple suivant, une définition de tâche pour l'architecture ARM affiche « 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" } ``` # Envoyez les journaux Amazon ECS à CloudWatch Vous pouvez configurer les conteneurs de vos tâches pour envoyer des informations de journal à CloudWatch Logs. Si vous utilisez Fargate pour vos tâches, vous pouvez afficher les journaux de vos conteneurs. Si vous utilisez EC2, vous pouvez afficher différents journaux de vos conteneurs dans un emplacement pratique, et cela empêche vos journaux de conteneur d’occuper de l’espace disque sur vos instances de conteneur. **Note** Le type des informations qui sont consignées par les conteneurs dans votre tâche dépend principalement de leur commande `ENTRYPOINT`. Par défaut, les journaux qui sont capturés affichent la sortie de la commande qui peuvent s'afficher normalement dans un terminal interactif si vous aviez exécuté le conteneur localement, c'est-à-dire les flux d'I/O `STDOUT` et `STDERR`. Le pilote de `awslogs` journal transmet simplement ces journaux de Docker à CloudWatch Logs. Pour plus d'informations sur la façon dont les journaux Docker sont traités, et notamment sur les autres façons de capturer différentes données de fichiers ou différents flux, consultez [View logs for a container or service](https://docs.docker.com/engine/logging/) dans la documentation Docker. Pour envoyer les journaux système de vos instances de conteneur Amazon ECS vers CloudWatch Logs, consultez la section [Surveillance des fichiers journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchLogs.html) et [CloudWatch des quotas de journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html) dans le *guide de l'utilisateur Amazon CloudWatch Logs*. ## Fargate Si vous utilisez Fargate pour vos tâches, vous devez ajouter les paramètres `logConfiguration` requis à votre définition de tâche pour activer le pilote de journalisation `awslogs`. Pour de plus amples informations, veuillez consulter [Exemple de définition de tâche Amazon ECS : acheminer les journaux vers CloudWatch](specify-log-config.md). Pour le conteneur Windows sur Fargate, effectuez l’une des options suivantes lorsque l’un des paramètres de définition de tâche comporte des caractères spéciaux tels que `& \ < > ^ |` : + Ajoutez un caractère d’échappement (`\`) avec des guillemets autour de la chaîne de paramètres entière Exemple ``` "awslogs-multiline-pattern": "\"^[|DEBUG|INFO|WARNING|ERROR\"", ``` + Ajoutez un caractère d’échappement (`^`) autour de chaque caractère spécial Exemple ``` "awslogs-multiline-pattern": "^^[^|DEBUG^|INFO^|WARNING^|ERROR", ``` ## EC2 Si vous utilisez le type de lancement EC2 pour vos tâches et que vous souhaitez activer le pilote de journalisation `awslogs`, vos instances de conteneur Amazon ECS nécessitent au moins la version 1.9.0 de l’agent de conteneur. Pour plus d'informations sur la vérification de la version de votre agent et la mise à jour à la dernière version, consultez [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md). **Note** Vous devez utiliser une AMI optimisée pour Amazon ECS ou une AMI personnalisée avec au moins une version `1.9.0-1` du package `ecs-init`. Lorsque vous utilisez une AMI personnalisée, vous devez spécifier que le pilote de journalisation `awslogs` est disponible sur l’instance Amazon EC2 lorsque vous démarrez l’agent en utilisant la variable d’environnement suivante dans votre instruction **docker run** ou votre fichier de variables d’environnement. ``` ECS_AVAILABLE_LOGGING_DRIVERS=["json-file","awslogs"] ``` Vos instances de conteneur Amazon ECS nécessitent également une autorisation `logs:CreateLogStream` et `logs:PutLogEvents` sur le rôle IAM avec lequel vous pouvez lancer vos instances de conteneur. Si vous avez créé votre rôle d'instance de conteneur Amazon ECS avant l'activation de la prise en charge du pilote du journal `awslogs` dans Amazon ECS, vous devrez sans doute ajouter ces autorisations. `ecsTaskExecutionRole` est utilisé lorsqu'il est affecté à la tâche et contient probablement les autorisations appropriées. Pour plus d’informations sur le rôle d’exécution de tâche, consultez la section [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md). Si vos instances de conteneur utilisent la politique IAM gérée pour les instances de conteneur, vos instances de conteneur disposent probablement des autorisations appropriées. Pour obtenir des informations sur la politique IAM gérée pour les instances de conteneur, consultez la section [Rôle IAM d'instance de conteneur Amazon ECS](instance_IAM_role.md). # Exemple de définition de tâche Amazon ECS : acheminer les journaux vers CloudWatch Avant que vos conteneurs puissent envoyer des journaux CloudWatch, vous devez spécifier le pilote de `awslogs` journal pour les conteneurs dans votre définition de tâche. Pour plus d’informations sur les paramètres de journalisation, consultez la section [Stockage et journalisation](task_definition_parameters.md#container_definition_storage). La définition de tâche JSON qui suit possède un objet `logConfiguration` spécifié pour chaque conteneur. L'un concerne le WordPress conteneur qui envoie les journaux à un groupe de journaux appelé`awslogs-wordpress`. L'autre concerne un conteneur MySQL qui envoie des journaux à un groupe de journaux appelé `awslogs-mysql`. Les deux conteneurs utilisent le préfixe de flux de journal `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" } ``` ## Étapes suivantes + Vous pouvez éventuellement définir une politique de rétention pour le groupe de journaux à l'aide de l'API CloudWatch AWS CLI or. Pour plus d'informations, consultez [put-retention-policy](https://docs.aws.amazon.com/cli/latest/reference/logs/put-retention-policy.html) dans la *référence AWS Command Line Interface *. + Après avoir enregistré une définition de tâche avec le pilote de `awslogs` journal dans une configuration de journal de définition de conteneur, vous pouvez exécuter une tâche ou créer un service avec cette définition de tâche pour commencer à envoyer des CloudWatch journaux à Logs. Pour plus d’informations, consultez [Exécution d’une application en tant que tâche Amazon ECS](standalone-task-create.md) et [Création d’un déploiement de mise à jour propagée Amazon ECS](create-service-console-v2.md). # Envoyer les journaux Amazon ECS à un AWS service ou AWS Partner Vous pouvez utiliser Amazon ECS FireLens pour utiliser les paramètres de définition des tâches pour acheminer les journaux vers un AWS service ou une destination AWS Partner Network (APN) à des fins de stockage et d'analyse des journaux. AWS Partner Network Il s'agit d'une communauté mondiale de partenaires qui tire parti des programmes, de l'expertise et des ressources pour créer, commercialiser et vendre des offres aux clients. Pour plus d'informations, veuillez consulter [AWS Partner](https://aws.amazon.com/partners/work-with-partners/). FireLens fonctionne avec [Fluentd](https://www.fluentd.org/) et [Fluent Bit](https://fluentbit.io/). Nous fournissons l'image AWS pour Fluent Bit ou vous pouvez utiliser votre propre image Fluentd ou Fluent Bit. Par défaut, Amazon ECS configure la dépendance du conteneur pour que le conteneur Firelens démarre avant tout conteneur qui l’utilise. Le conteneur Firelens s’arrête également une fois que tous les conteneurs qui l’utilisent se sont arrêtés. Pour utiliser cette fonctionnalité, vous devez créer un rôle IAM pour vos tâches qui fournit les autorisations nécessaires pour utiliser les AWS services requis par les tâches. Par exemple, si un conteneur achemine des journaux vers Firehose, la tâche nécessite l’autorisation d’appeler l’API `firehose:PutRecordBatch`. Pour plus d'informations, consultez [Ajout et suppression d'autorisations basées sur l'identité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) dans le *Guide de l'utilisateur IAM*. Votre tâche peut également nécessiter le rôle d’exécution de tâche Amazon ECS dans les conditions suivantes. Pour de plus amples informations, veuillez consulter [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md). + Si votre tâche est hébergée sur Fargate et que vous extrayez des images de conteneurs depuis Amazon ECR ou que vous faites référence à des données sensibles AWS Secrets Manager depuis votre configuration de journal, vous devez inclure le rôle IAM d'exécution de la tâche. + Lorsque vous utilisez un fichier de configuration personnalisé hébergé dans Amazon S3, votre rôle IAM d’exécution de tâche doit inclure l’autorisation `s3:GetObject`. Tenez compte des points suivants lors de l'utilisation FireLens pour Amazon ECS : + Nous vous recommandons d’ajouter `my_service_` au nom du conteneur de journaux afin de pouvoir facilement le distinguer dans la console. + Amazon ECS ajoute par défaut une dépendance relative à l’ordre des conteneurs de démarrage entre les conteneurs d’applications et le conteneur FireLens. Lorsque vous spécifiez un ordre de conteneur entre les conteneurs d’applications et le conteneur FireLens, l’ordre de conteneur de départ par défaut est remplacé. + FireLens pour Amazon ECS est pris en charge pour les tâches hébergées à la fois sur AWS Fargate sur Linux et Amazon EC2 sur Linux. Les conteneurs Windows ne prennent pas en charge FireLens. Pour plus d'informations sur la configuration de la journalisation centralisée pour les conteneurs Windows, consultez la section [Journalisation centralisée pour les conteneurs Windows sur Amazon ECS à l'aide de Fluent Bit](https://aws.amazon.com/blogs/containers/centralized-logging-for-windows-containers-on-amazon-ecs-using-fluent-bit/). + Vous pouvez utiliser CloudFormation des modèles FireLens pour configurer Amazon ECS. Pour plus d'informations, voir [AWS::ECS::TaskDefinition FirelensConfiguration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-firelensconfiguration.html)le *guide de AWS CloudFormation l'utilisateur* + FireLensécoute sur le port`24224`. Pour vous assurer que le routeur de FireLens journaux n'est pas accessible en dehors de la tâche, vous ne devez pas autoriser le trafic entrant sur le port `24224` du groupe de sécurité utilisé par votre tâche. Pour les tâches utilisant le mode réseau `awsvpc`, il s'agit du groupe de sécurité associé à la tâche. Pour les tâches utilisant le mode réseau `host`, il s'agit du groupe de sécurité associé à l'instance Amazon EC2 qui héberge la tâche. Pour les tâches utilisant le mode réseau `bridge`, ne créez pas de mappages de ports utilisant le port `24224`. + Pour les tâches qui utilisent le mode `bridge` réseau, le conteneur contenant la FireLens configuration doit démarrer avant que les conteneurs d'applications qui en dépendent ne démarrent. Pour contrôler l'ordre de début de vos conteneurs, utilisez les conditions de dépendance dans la définition de tâche. Pour de plus amples informations, veuillez consulter [Dépendances du conteneur](task_definition_parameters.md#container_definition_dependson). **Note** Si vous utilisez des paramètres de condition de dépendance dans les définitions de conteneur avec une FireLens configuration, assurez-vous que chaque conteneur possède une exigence de `HEALTHY` condition `START` or. + Par défaut, FireLens ajoute le nom du cluster et de la définition de tâche ainsi que le nom de ressource Amazon (ARN) du cluster en tant que clés de métadonnées stdout/stderr dans vos journaux de conteneurs. Voici un exemple du format de métadonnées. ``` "ecs_cluster": "cluster-name", "ecs_task_arn": "arn:aws:ecs:region:111122223333:task/cluster-name/f2ad7dba413f45ddb4EXAMPLE", "ecs_task_definition": "task-def-name:revision", ``` Si vous ne souhaitez pas que les métadonnées figurent dans vos journaux, définissez `enable-ecs-log-metadata` sur `false`dans la section `firelensConfiguration` de la définition de tâche. ``` "firelensConfiguration":{ "type":"fluentbit", "options":{ "enable-ecs-log-metadata":"false", "config-file-type":"file", "config-file-value":"/extra.conf" } ``` Vous pouvez configurer le FireLens conteneur pour qu'il s'exécute en tant qu'utilisateur non root. Éléments à prendre en compte : + Pour configurer le FireLens conteneur afin qu'il s'exécute en tant qu'utilisateur non root, vous devez spécifier l'utilisateur dans l'un des formats suivants : + `uid` + `uid:gid` + `uid:group` Pour plus d'informations sur la spécification d'un utilisateur dans une définition de conteneur, consultez le [ContainerDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html)manuel *Amazon Elastic Container Service API Reference*. Le FireLens conteneur reçoit les journaux des applications via un UNIX socket. L'agent Amazon ECS utilise le `uid` pour attribuer la propriété du répertoire de sockets au FireLens conteneur. + La configuration du FireLens conteneur pour qu'il s'exécute en tant qu'utilisateur non root est prise en charge sur les versions Amazon ECS Agent `1.96.0` et ultérieures, ainsi que sur les versions AMI optimisées pour Amazon ECS et `v20250716` versions ultérieures. + Lorsque vous spécifiez un utilisateur pour le FireLens conteneur, celui-ci `uid` doit être unique et ne pas être utilisé pour d'autres processus appartenant à d'autres conteneurs de la tâche ou de l'instance de conteneur. Pour plus d’informations sur l’utilisation de plusieurs fichiers de configuration avec Amazon ECS, y compris les fichiers que vous hébergez ou les fichiers dans Amazon S3, consultez la section [Processus d’initialisation pour Fluent Bit sur ECS, support multiconfigurations](https://github.com/aws/aws-for-fluent-bit/tree/mainline/use_cases/init-process-for-fluent-bit). Pour plus d'informations sur les exemples de configurations, consultez[Exemple de définition de tâche Amazon ECS : acheminement des journaux vers FireLens](firelens-taskdef.md). Pour plus d'informations sur la configuration des journaux pour un débit élevé, consultez[Configuration des journaux Amazon ECS pour un débit élevé](firelens-docker-buffer-limit.md). # Configuration des journaux Amazon ECS pour un débit élevé Pour les scénarios à haut débit de log, nous recommandons d'utiliser le pilote de `awsfirelens` log avec FireLens etFluent Bit. Fluent Bitest un processeur de journaux léger qui utilise efficacement les ressources et peut gérer des millions d'enregistrements de journaux. Cependant, pour obtenir des performances optimales à grande échelle, il faut ajuster sa configuration. Cette section décrit les techniques Fluent Bit d'optimisation avancées permettant de gérer un débit de log élevé tout en préservant la stabilité du système et en évitant toute perte de données. Pour plus d'informations sur l'utilisation de fichiers de configuration personnalisés avec FireLens, consultez[Utilisation d’un fichier de configuration](firelens-taskdef.md#firelens-taskdef-customconfig). Pour des exemples supplémentaires, consultez les [ FireLens exemples d'Amazon ECS](https://github.com/aws-samples/amazon-ecs-firelens-examples) sur GitHub. **Note** Certaines options de configuration de cette section, telles que `workers` et`threaded`, nécessitent AWS la Fluent Bit version 3 ou ultérieure. Pour plus d'informations sur les versions disponibles, voir [AWS les versions de Fluent Bit](https://github.com/aws/aws-for-fluent-bit/releases). ## Comprendre les morceaux Fluent Bittraite les données en unités appelées *fragments.* Lorsqu'un plugin INPUT reçoit des données, le moteur crée un fragment qui est stocké en mémoire ou sur le système de fichiers avant d'être envoyé aux destinations OUTPUT. Le comportement de mise en mémoire tampon dépend du `storage.type` paramètre défini dans vos sections INPUT. Par défaut, Fluent Bit utilise la mise en mémoire tampon. Pour les scénarios à haut débit ou de production, la mise en mémoire tampon du système de fichiers offre une meilleure résilience. Pour plus d'informations, consultez les sections [Chunks](https://docs.fluentbit.io/manual/administration/buffering-and-storage#chunks) dans la Fluent Bit documentation et [Qu'est-ce qu'un chunk ?](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#what-is-a-chunk) dans le référentiel AWS for Fluent Bit examples. ## Mise en mémoire tampon (par défaut) Par défaut, Fluent Bit utilise la mise en mémoire tampon (`storage.type memory`). Vous pouvez limiter l'utilisation de la mémoire par plug-in INPUT à l'aide du `Mem_Buf_Limit` paramètre. L'exemple suivant montre une configuration d'entrée mise en mémoire tampon : ``` [INPUT] Name tcp Tag ApplicationLogs Port 5170 storage.type memory Mem_Buf_Limit 5MB ``` **Important** Lorsqu'il `Mem_Buf_Limit` est dépassé pour un plugin, la Fluent Bit saisie est interrompue et les nouveaux enregistrements sont perdus. Cela peut provoquer une contre-pression et ralentir votre application. L'avertissement suivant apparaît dans les Fluent Bit journaux : ``` [input] tcp.1 paused (mem buf overlimit) ``` La mise en mémoire tampon convient aux cas d'utilisation simples avec un débit de log faible à modéré. Pour les scénarios à haut débit ou de production où la perte de données est un problème, utilisez plutôt la mise en mémoire tampon du système de fichiers. Pour plus d'informations, consultez [Buffering and Memory](https://docs.fluentbit.io/manual/administration/buffering-and-storage#buffering-and-memory) dans la Fluent Bit documentation et [Memory Buffering Only](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-1-memory-buffering-only-default-or-storagetype-memory) dans le référentiel AWS for Fluent Bit examples. ## Mise en mémoire tampon du système de fichiers Pour les scénarios à haut débit, nous recommandons d'utiliser la mise en mémoire tampon du système de fichiers. Pour plus d'informations sur la Fluent Bit gestion de la mise en mémoire tampon et du stockage, consultez la section Mise en [mémoire tampon et stockage](https://docs.fluentbit.io/manual/administration/buffering-and-storage) dans la Fluent Bit documentation. La mise en mémoire tampon du système de fichiers présente les avantages suivants : + **Capacité de mémoire tampon plus importante** : l'espace disque est généralement plus abondant que la mémoire. + **Persistance** : les données mises en mémoire tampon survivent Fluent Bit aux redémarrages. + **Dégradation progressive** : lors de défaillances de sortie, les données s'accumulent sur le disque au lieu d'épuiser la mémoire. Pour activer la mise en mémoire tampon du système de fichiers, fournissez un fichier de Fluent Bit configuration personnalisé. L'exemple suivant montre la configuration recommandée : ``` [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 ``` Principaux paramètres de configuration : `storage.path` Le répertoire dans lequel sont Fluent Bit stockés les fragments mis en mémoire tampon sur le disque. `storage.backlog.flush_on_shutdown` Lorsque cette option est activée, Fluent Bit tente de vider tous les fragments du système de fichiers en attente vers leur destination lors de l'arrêt. Cela permet de garantir la livraison des données avant les Fluent Bit arrêts, mais peut augmenter le temps d'arrêt. `storage.max_chunks_up` Le nombre de segments qui restent en mémoire. La valeur par défaut est de 128 blocs, qui peuvent consommer plus de 500 Mo de mémoire, car chaque bloc peut utiliser jusqu'à 4 à 5 Mo. Dans les environnements où la mémoire est limitée, réduisez cette valeur. Par exemple, si vous disposez de 50 Mo pour la mise en mémoire tampon, définissez ce paramètre sur 8 à 10 segments. `storage.type filesystem` Active le stockage du système de fichiers pour le plugin d'entrée. Malgré son nom, il permet Fluent Bit de `mmap` mapper des fragments à la fois à la mémoire et au disque, garantissant ainsi la persistance sans sacrifier les performances. `storage.total_limit_size` Espace disque maximal pour les données mises en mémoire tampon pour un plugin OUTPUT spécifique. Lorsque cette limite est atteinte, les enregistrements les plus anciens de cette sortie sont supprimés. Pour plus d'informations sur le dimensionnement, consultez[Présentation du code `storage.total_limit_size`](#firelens-storage-sizing). `threaded true` Exécute l'entrée dans son propre thread, séparé Fluent Bit de la boucle d'événements principale. Cela empêche les entrées lentes de bloquer l'ensemble du pipeline. Pour plus d'informations, consultez la section Mise en [mémoire tampon du système de fichiers](https://docs.fluentbit.io/manual/administration/buffering-and-storage#filesystem-buffering) dans la Fluent Bit documentation et Mise en [mémoire tampon du système de fichiers et de la mémoire](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-2-filesystem-and-memory-buffering-storagetype-filesystem) dans le AWS référentiel d'exemples. Fluent Bit ## Présentation du code `storage.total_limit_size` Le `storage.total_limit_size` paramètre de chaque plug-in OUTPUT contrôle l'espace disque maximal pour les données mises en mémoire tampon pour cette sortie. Lorsque cette limite est atteinte, les enregistrements les plus anciens de cette sortie sont supprimés pour faire de la place aux nouvelles données. Lorsque l'espace disque est complètement épuisé, les enregistrements Fluent Bit ne sont pas mis en file d'attente et ils sont perdus. Utilisez la formule suivante pour calculer le montant approprié en `storage.total_limit_size` fonction de votre taux de journalisation et de la fenêtre de restauration souhaitée : ``` If log rate is in KB/s, convert to MB/s first: log_rate (MB/s) = log_rate (KB/s) / 1000 storage.total_limit_size (GB) = log_rate (MB/s) × duration (hours) × 3600 (seconds/hour) / 1000 (MB to GB) ``` Le tableau suivant présente des exemples de calculs pour les taux de journalisation et les fenêtres de restauration courants : | Taux de journalisation | 1 heure | 6 heures | 12 heures | 24 heures | | --- | --- | --- | --- | --- | | 0,25 Mo/s | 0,9 GO | 5,4 GO | 10,8 GO | 21,6 GO | | 0,5 Mo/s | 1,8 GO | 10,8 GO | 21,6 GO | 43,2 GO | | 1 Mo/s | 3,6 GO | 21,6 GO | 43,2 GO | 86,4 GO | | 5 Mo/s | 18 GO | 108 GO | 216 GO | 432 GO | | 10 Mo/s | 36 GO | 216 GO | 432 GO | 864 GO | Pour observer le débit maximal et choisir les tailles de tampon appropriées, utilisez l'échantillon de débit de [mesure. FireLens ](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/measure-throughput) Utilisez la formule, des exemples de calculs et des analyses comparatives pour choisir la piste la mieux adaptée `storage.total_limit_size` à une reprise optimale en cas de panne. ## Exigences relatives au stockage des tâches Amazon ECS Additionnez toutes les `storage.total_limit_size` valeurs des sections OUTPUT et ajoutez de la mémoire tampon pour les frais généraux. Ce total détermine l'espace de stockage nécessaire dans votre définition de tâche Amazon ECS. Par exemple, 3 sorties × 10 Go chacune = 30 Go \$1 mémoire tampon (5 à 10 Go) = 35 à 40 Go au total requis. Si le total dépasse le stockage disponible, les enregistrements Fluent Bit risquent de ne pas être mis en file d'attente et ils seront perdus. Les options de stockage suivantes sont disponibles : Supports Bind (stockage éphémère) + Pour AWS Fargate, la valeur par défaut est de 20 Go de stockage éphémère (200 Go maximum). Configurez `ephemeralStorage` en utilisant dans la définition de la tâche. Pour plus d’informations, consultez [EphemeralStorage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-ephemeralstorage.html) dans le *Guide de l’utilisateur AWS CloudFormation *. + Pour EC2, la valeur par défaut est de 30 Go lorsque vous utilisez l'AMI optimisée pour Amazon ECS (partagée entre le système d'exploitation et Docker). Augmentez en modifiant la taille du volume racine. Volumes Amazon EBS + Fournit un stockage par blocs à haute disponibilité, durable et hautes performances. + Nécessite une configuration du volume et `mountPoint` une définition de tâche pointant vers `storage.path` (par défaut :`/var/log/flb-storage/`). + Pour de plus amples informations, veuillez consulter [Report de la configuration du volume au moment du lancement dans une définition de tâche Amazon ECS](specify-ebs-config.md). Volumes Amazon EFS + Permet un stockage de fichiers simple et évolutif. + Nécessite une configuration du volume et `mountPoint` une définition de tâche pointant vers `storage.path` (par défaut :`/var/log/flb-storage/`). + Pour de plus amples informations, veuillez consulter [Spécification d’un système de fichiers Amazon EFS dans une définition de tâche Amazon ECS](specify-efs-config.md). Pour plus d'informations sur les volumes de données, consultez[Options de stockage pour les tâches Amazon ECS](using_data_volumes.md). ## Optimisation de la configuration de sortie Les problèmes de réseau, les interruptions de service et la limitation des destinations peuvent empêcher la livraison des journaux. Une configuration de sortie appropriée garantit la résilience sans perte de données. En cas d'échec d'un vidage de sortie, Fluent Bit vous pouvez réessayer l'opération. Les paramètres suivants contrôlent le comportement des nouvelles tentatives : `retry_limit` Nombre maximal de tentatives après la première tentative avant de supprimer des enregistrements. La valeur par défaut est 1. Par exemple, `retry_limit 3` cela signifie 4 tentatives au total (1 tentative initiale \$1 3 tentatives). Pour les environnements de production, nous recommandons une durée de 15 minutes ou plus, ce qui couvre plusieurs minutes d'interruption avec un ralentissement exponentiel. Défini pour `no_limits` ou `False` pour un nombre infini de tentatives : + Avec la mise en mémoire tampon, des tentatives infinies entraînent une pause du plug-in d'entrée lorsque les limites de mémoire sont atteintes. + Avec la mise en mémoire tampon du système de fichiers, les enregistrements les plus anciens sont supprimés lorsqu'ils `storage.total_limit_size` sont atteints. Après avoir épuisé toutes les tentatives (1 tentative initiale et nouvelles `retry_limit` tentatives), les enregistrements sont supprimés. AWS les plugins avec `auto_retry_requests true` (par défaut) fournissent une couche de nouvelle tentative supplémentaire avant Fluent Bit le mécanisme de nouvelle tentative. Pour plus d'informations, consultez la section [Configurer les nouvelles tentatives](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-retries) dans la Fluent Bit documentation. Par exemple, `retry_limit 3` avec les paramètres par défaut (`scheduler.base 5`,,`net.connect_timeout 10s`)`scheduler.cap 2000`, le temps d'attente du planificateur est d'environ 70 secondes (10 s \$1 20 \$1 40 s), les délais de connexion au réseau de 40 secondes (4 tentatives × 10 s), plus de nouvelles tentatives de AWS plug-in, soit un total d'environ 2 à 10 minutes en fonction des conditions du réseau et des délais TCP du système d'exploitation. `scheduler.base` Les secondes de base entre les tentatives (par défaut : 5). Nous recommandons 10 secondes. `scheduler.cap` Nombre maximal de secondes entre deux tentatives (par défaut : 2000). Nous recommandons 60 secondes. Le temps d'attente entre les nouvelles tentatives utilise un recul exponentiel associé à de l'instabilité : ``` wait_time = random(base, min(base × 2^retry_number, cap)) ``` Par exemple, avec `scheduler.base 10` et `scheduler.cap 60` : + Première tentative : attente aléatoire comprise entre 10 et 20 secondes + Deuxième tentative : attente aléatoire comprise entre 10 et 40 secondes + Troisième tentative et versions ultérieures : attente aléatoire comprise entre 10 et 60 secondes (plafonnée) Pour plus d'informations, consultez [Configurer le temps d'attente pour une nouvelle tentative](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-wait-time-for-retry) et [Mise en réseau](https://docs.fluentbit.io/manual/administration/networking) dans la Fluent Bit documentation. `workers` Nombre de threads pour le traitement en sortie parallèle. Plusieurs opérateurs autorisent des purges simultanées, ce qui améliore le débit lors du traitement de nombreux fragments. `auto_retry_requests` Un paramètre AWS spécifique au plugin qui fournit une couche de nouvelle tentative supplémentaire avant le mécanisme Fluent Bit de nouvelle tentative intégré. La valeur par défaut est `true`. Lorsqu'il est activé, le plugin AWS de sortie réessaie les demandes ayant échoué en interne avant que la demande ne soit considérée comme un échec du rinçage et soumise à la `retry_limit` configuration. Le `Grace` paramètre de la `[SERVICE]` section définit le temps d'Fluent Bitattente pendant l'arrêt pour vider les données mises en mémoire tampon. La `Grace` période doit être coordonnée avec celle du contenant`stopTimeout`. Assurez-vous que ce délai `stopTimeout` dépasse le `Grace` délai imparti pour Fluent Bit permettre le rinçage complet avant de le recevoir. `SIGKILL` Par exemple, si elle `Grace` est de 120 secondes, définie `stopTimeout` sur 150 secondes. L'exemple suivant montre une Fluent Bit configuration complète avec tous les paramètres recommandés pour les scénarios à haut débit : ``` [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 ``` ## Comprendre les scénarios de perte de données Les enregistrements peuvent être perdus lors de pannes prolongées ou de problèmes liés aux destinations de sortie. Les recommandations de configuration contenues dans ce guide constituent des approches optimales pour minimiser les pertes de données, mais ne peuvent garantir aucune perte en cas de panne prolongée. La compréhension de ces scénarios vous aide Fluent Bit à configurer pour optimiser la résilience. Les enregistrements peuvent être perdus de deux manières : les enregistrements les plus anciens sont supprimés lorsque le stockage est plein, ou les enregistrements les plus récents sont rejetés lorsque le système ne peut pas accepter davantage de données. ### Les plus anciens records abandonnés Les enregistrements mis en mémoire tampon les plus anciens sont supprimés lorsque les nouvelles tentatives sont épuisées ou lorsqu'ils sont `storage.total_limit_size` pleins et doivent faire de la place pour de nouvelles données. Limite de tentatives dépassée Se produit après de nouvelles tentatives du AWS plugin (if`auto_retry_requests true`) plus 1 Fluent Bit tentative initiale plus de nouvelles `retry_limit` tentatives. Pour atténuer les effets, définissez `retry_limit no_limits` chaque plugin OUTPUT pour un nombre infini de tentatives : ``` [OUTPUT] Name cloudwatch_logs Match ApplicationLogs retry_limit no_limits auto_retry_requests true ``` Un nombre indéfini de tentatives permet d'éviter de perdre des enregistrements en cas d'épuisement des tentatives, mais cela peut `storage.total_limit_size` entraîner un remplissage. Limite de stockage atteinte (mise en mémoire tampon du système de fichiers) Se produit lorsque la destination de sortie n'est pas disponible plus longtemps que la mémoire tampon que `storage.total_limit_size` vous avez configurée. Par exemple, une mémoire tampon de 10 Go à un débit MB/s journalier fournit environ 2,7 heures de mise en mémoire tampon. Pour atténuer les risques, augmentez `storage.total_limit_size` le nombre de plug-ins OUTPUT et fournissez un stockage de tâches Amazon ECS adéquat : ``` [OUTPUT] Name cloudwatch_logs Match ApplicationLogs storage.total_limit_size 10G ``` ### Nouveaux enregistrements rejetés Les enregistrements les plus récents sont supprimés lorsque l'espace disque est épuisé ou lorsque l'entrée est interrompue en raison de`Mem_Buf_Limit`. Espace disque épuisé (mise en mémoire tampon du système de fichiers) Se produit lorsque l'espace disque est complètement épuisé. Fluent Bitne parvient pas à mettre en file d'attente les nouveaux enregistrements et ils sont perdus. Pour atténuer les risques, additionnez toutes les `storage.total_limit_size` valeurs et fournissez un stockage de tâches Amazon ECS adéquat. Pour de plus amples informations, veuillez consulter [Exigences relatives au stockage des tâches Amazon ECS](#firelens-storage-task-requirements). Limite de mémoire atteinte (mise en mémoire tampon) Se produit lorsque la destination de sortie n'est pas disponible et que la mémoire tampon est pleine. Les plugins d'entrée en pause cessent d'accepter de nouveaux enregistrements. Pour atténuer, utiliser `storage.type filesystem` pour améliorer la résilience ou augmenter`Mem_Buf_Limit`. ### Bonnes pratiques pour minimiser les pertes de données Tenez compte des meilleures pratiques suivantes pour minimiser les pertes de données : + **Utiliser la mise en mémoire tampon du système de fichiers** : configurée `storage.type filesystem` pour une meilleure résilience en cas de panne. + **Dimensionnez le stockage de manière appropriée** : calculez en `storage.total_limit_size` fonction du taux de journalisation et de la fenêtre de restauration souhaitée. + **Provisionner un disque adéquat** : assurez-vous que la tâche Amazon ECS dispose d'un espace de stockage éphémère suffisant, Amazon EBS ou Amazon EFS. + **Configurer le comportement des nouvelles tentatives** : équilibre entre `retry_limit` (supprime les enregistrements après avoir épuisé les tentatives) et `no_limits` (nouvelles tentatives indéfiniment mais risque de remplir l'espace de stockage). ## Utilisez la journalisation à destinations multiples pour plus de fiabilité L'envoi de journaux vers plusieurs destinations élimine les points de défaillance uniques. Par exemple, en cas de panne de CloudWatch Logs, les journaux continuent d'atteindre Amazon S3. La journalisation à destinations multiples offre les avantages suivants. Le plug-in de sortie Amazon S3 prend également en charge les options de compression telles que le format gzip et le format Parquet, qui peuvent réduire les coûts de stockage. Pour plus d'informations, consultez la section [Compression S3](https://docs.fluentbit.io/manual/pipeline/outputs/s3#compression) dans la Fluent Bit documentation. La journalisation à destinations multiples peut offrir les avantages suivants : + **Redondance** : si une destination échoue, les journaux continuent d'atteindre l'autre. + **Rétablissement** — Reconstituer les lacunes d'un système par rapport à l'autre. + **Durabilité** — Archivez les journaux dans Amazon S3 pour les conserver à long terme. + **Optimisation des coûts** : conservez les journaux récents dans un service de requête rapide tel que les CloudWatch journaux à durée de conservation plus courte, tout en archivant tous les journaux dans un espace de stockage Amazon S3 à moindre coût pour une conservation à long terme. La Fluent Bit configuration suivante envoie des journaux à la fois à CloudWatch Logs et à 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 ``` Les deux sorties utilisent le même `Match *` schéma, de sorte que tous les enregistrements sont envoyés aux deux destinations indépendamment. En cas de panne d'une destination, les journaux continuent de circuler vers l'autre tandis que les purges échouées s'accumulent dans la mémoire tampon du système de fichiers pour une nouvelle tentative ultérieure. ## Utiliser la journalisation basée sur des fichiers avec le plugin d'entrée tail Pour les scénarios à haut débit dans lesquels la perte de journaux est un problème critique, vous pouvez utiliser une autre approche : demandez à votre application d'écrire des journaux dans des fichiers sur disque et de les configurer Fluent Bit pour les lire à l'aide du plug-in `tail` d'entrée. Cette approche contourne complètement la couche du pilote de journalisation Docker. La journalisation basée sur des fichiers avec le plugin tail offre les avantages suivants : + **Suivi des décalages** — Le plugin tail peut stocker les décalages de fichiers dans un fichier de base de données (en utilisant l'`DB`option), garantissant ainsi une durabilité lors des Fluent Bit redémarrages. Cela permet d'éviter la perte de journal lors du redémarrage du conteneur. + **Mise en mémoire tampon au niveau** de l'entrée : vous pouvez configurer les limites de mémoire tampon directement sur le plug-in d'entrée`Mem_Buf_Limit`, ce qui permet de contrôler plus précisément l'utilisation de la mémoire. + **Évite la surcharge de Docker** : les journaux passent directement du fichier au fichier Fluent Bit sans passer par les mémoires tampon de Docker. Pour utiliser cette approche, votre application doit écrire des journaux dans des fichiers plutôt que dans`stdout`. Le conteneur d'applications et le Fluent Bit conteneur montent tous deux un volume partagé dans lequel les fichiers journaux sont stockés. L'exemple suivant montre une configuration d'entrée secondaire conforme aux meilleures pratiques : ``` [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 ``` Lorsque vous utilisez le plugin d'entrée tail, tenez compte des points suivants : + Implémentez la rotation des journaux de vos applications afin d'éviter l'épuisement du disque. Surveillez les indicateurs de volume sous-jacents pour évaluer les performances. + Tenez compte de paramètres tels que `Ignore_Older``Read_from_Head`, et des analyseurs multilignes basés sur le format de votre journal. Pour plus d'informations, consultez [Tail](https://docs.fluentbit.io/manual/pipeline/inputs/tail) dans la Fluent Bit documentation. Pour connaître les meilleures pratiques, consultez [la section Configuration de Tail avec les meilleures pratiques](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#tail-config-with-best-practices) dans AWS le guide de Fluent Bit dépannage. ## Connectez-vous directement à FireLens Lorsque le pilote de journal `awsfirelens` est spécifié dans une définition de tâche, l'agent de conteneur Amazon ECS injecte les variables d'environnement suivantes dans le conteneur : `FLUENT_HOST` Adresse IP attribuée au FireLens conteneur. Si vous utilisez EC2 en mode `bridge` réseau, la variable d'`FLUENT_HOST`environnement de votre conteneur d'applications peut devenir inexacte après le redémarrage du conteneur FireLens log router (le conteneur contenant l'`firelensConfiguration`objet dans sa définition de conteneur). Cela est dû au fait que `FLUENT_HOST` est une adresse IP dynamique qui peut changer après un redémarrage. La journalisation directe depuis le conteneur de l’application vers l’adresse IP `FLUENT_HOST` peut commencer à échouer après le changement d’adresse. Pour obtenir plus d’informations sur le redémarrage de conteneurs individuels, consultez la section [Redémarrage de conteneurs individuels dans les tâches Amazon ECS à l’aide de politiques de redémarrage de conteneurs](container-restart-policy.md). `FLUENT_PORT` Port sur lequel le protocole Fluent Forward écoute. Vous pouvez utiliser ces variables d'environnement pour vous connecter directement au routeur de Fluent Bit journaux à partir du code de votre application à l'aide du protocole Fluent Forward, au lieu d'écrire sur`stdout`. Cette approche contourne la couche de pilote de journalisation Docker, ce qui offre les avantages suivants : + **Latence réduite** : les journaux sont directement accessibles Fluent Bit sans passer par l'infrastructure de journalisation de Docker. + **Journalisation structurée** : envoyez des données de journal structurées de manière native sans surcharge de codage JSON. + **Meilleur contrôle** : votre application peut implémenter sa propre logique de mise en mémoire tampon et de gestion des erreurs. Les bibliothèques d'enregistreurs Fluent suivantes prennent en charge le protocole Fluent Forward et peuvent être utilisées pour envoyer des journaux directement à 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) ## Configurer la limite de mémoire tampon Docker Lorsque vous créez une définition de tâche, vous pouvez spécifier le nombre de lignes de journal mises en mémoire tampon en spécifiant la valeur dans`log-driver-buffer-limit`. Cela contrôle la mémoire tampon entre Docker et. Fluent Bit Pour plus d’informations, consultez la section [Pilote de journalisation](https://docs.docker.com/engine/logging/drivers/fluentd/) dans la documentation Docker. Utilisez cette option lorsque le débit est élevé, car Docker risque de manquer de mémoire tampon et de rejeter les messages tampons afin d'en ajouter de nouveaux. Tenez compte des points suivants lorsque vous utilisez cette option : + Cette option est prise en charge sur le type de lancement Amazon EC2 et le type de lancement Fargate avec la version de plateforme `1.4.0` ou une version ultérieure. + L'option n'est valide que lorsque `logDriver` est défini sur `awsfirelens`. + La limite par défaut du tampon est de `1048576` lignes de journal. + La limite de mémoire tampon doit être supérieure ou égale à `0` et inférieure à `536870912` lignes de journal. + La quantité maximale de mémoire utilisée pour cette mémoire tampon est le produit de la taille de chaque ligne de journal par la taille de la mémoire tampon. Par exemple, si les lignes de journal de l'application sont en moyenne en `2` KiB, une limite de mémoire tampon de 4 096 utiliserait au maximum 1 `8` MiB. La quantité totale de mémoire allouée au niveau de la tâche doit être supérieure à la quantité de mémoire allouée à tous les conteneurs, en plus du tampon mémoire du pilote de journalisation. La définition de tâche suivante indique comment configurer `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 pour les référentiels Fluent Bit d'images pour Amazon ECS AWS fournit une Fluent Bit image avec des plugins pour CloudWatch Logs et Firehose. Nous vous recommandons d'utiliser Fluent Bit comme routeur de journal car il a un taux d'utilisation des ressources inférieur à Fluentd. Pour plus d'informations, consultez [CloudWatch Logs for Fluent Bit](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) et [Amazon Kinesis Firehose](https://github.com/aws/amazon-kinesis-firehose-for-fluent-bit) for Fluent Bit. L'image **AWS for Fluent Bit** est disponible sur Amazon ECR à la fois dans la galerie publique Amazon ECR et dans un référentiel Amazon ECR pour une haute disponibilité. ## Galerie publique Amazon ECR L'Fluent Bitimage AWS pour est disponible sur la galerie publique Amazon ECR. Il s'agit de l'emplacement recommandé pour télécharger l'Fluent Bitimage AWS for, car il s'agit d'un dépôt public et peut être utilisé par tous Régions AWS. Pour plus d'informations, consultez [aws-for-fluent-bit](https://gallery.ecr.aws/aws-observability/aws-for-fluent-bit)la galerie publique Amazon ECR. ### Linux L'Fluent Bitimage AWS for de la galerie publique Amazon ECR prend en charge le système d'exploitation Amazon Linux avec l'`x86-64`architecture `ARM64` or. Vous pouvez extraire l'Fluent Bitimage AWS for de la galerie publique Amazon ECR en spécifiant l'URL du référentiel avec la balise d'image souhaitée. Les étiquettes d'image disponibles peuvent être trouvées sur la page **Étiquettes d'image** dans la galerie publique Amazon ECR. L'exemple suivant montre la syntaxe à utiliser pour la CLI Docker. ``` docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag ``` Par exemple, vous pouvez extraire la dernière image de la famille « 3.x » de quatre Fluent Bit versions à l'aide AWS de cette commande Docker CLI. ``` docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3 ``` **Note** Les extractions non authentifiées sont autorisées, mais ont une limite de débit inférieure à celle des extractions authentifiées. Pour vous authentifier à l'aide de votre AWS compte avant de le tirer, utilisez la commande suivante. ``` aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws ``` #### AWS pour Fluent Bit 3.0.0 Outre les Fluent Bit versions existantes`2.x`, AWS AWS for Fluent Bit prend en charge une nouvelle version majeure`3.x`. La nouvelle version majeure inclut la mise à niveau des images d'Amazon Linux 2 vers Amazon Linux 2023 et de Fluent Bit la version `1.9.10` vers`4.1.1`. Pour plus d'informations, consultez le [Fluent Bitréférentiel AWS for](https://github.com/aws/aws-for-fluent-bit/blob/mainline/VERSIONS.md) surGitHub. Les exemples suivants illustrent les balises mises à jour AWS pour les Fluent Bit `3.x` images : Vous pouvez utiliser des balises multi-architectures pour l'Fluent Bitimage AWS for. ``` docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3 ``` ### Windows L'Fluent Bitimage AWS for de la galerie publique Amazon ECR prend en charge l'`AMD64`architecture avec les systèmes d'exploitation suivants : + Windows Server 2022 Full + Windows Server 2022 Core + Windows Server 2019 Full + Windows Server 2019 Core Les conteneurs Windows installés sur AWS Fargate ne sont pas pris en charge. FireLens Vous pouvez extraire l'Fluent Bitimage AWS for de la galerie publique Amazon ECR en spécifiant l'URL du référentiel avec la balise d'image souhaitée. Les étiquettes d'image disponibles peuvent être trouvées sur la page **Étiquettes d'image** dans la galerie publique Amazon ECR. L'exemple suivant montre la syntaxe à utiliser pour la CLI Docker. ``` docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag ``` Par exemple, vous pouvez extraire l'Fluent Bitimage stable la plus récente AWS à l'aide de cette commande Docker CLI. ``` docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:windowsservercore-stable ``` **Note** Les extractions non authentifiées sont autorisées, mais ont une limite de débit inférieure à celle des extractions authentifiées. Pour vous authentifier à l'aide de votre AWS compte avant de le tirer, utilisez la commande suivante. ``` aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws ``` ## Amazon ECR L'image AWS for Fluent Bit est disponible sur Amazon ECR pour une haute disponibilité. Les commandes suivantes peuvent être utilisées pour récupérer une image URIs et établir la disponibilité de l'image dans une image donnée. Région AWS ### Linux La dernière version stable de AWS l'URI d'image Fluent Bit peut être récupérée à l'aide de la commande suivante. ``` aws ssm get-parameters \ --names /aws/service/aws-for-fluent-bit/stable \ --region us-east-1 ``` Toutes les versions de l'image AWS for Fluent Bit peuvent être répertoriées à l'aide de la commande suivante pour interroger le paramètre Systems Manager Parameter Store. ``` aws ssm get-parameters-by-path \ --path /aws/service/aws-for-fluent-bit \ --region us-east-1 ``` L'image stable la plus récente AWS pour Fluent Bit peut être référencée dans un CloudFormation modèle en faisant référence au nom du magasin de paramètres Systems Manager. Voici un exemple : ``` Parameters: FireLensImage: Description: Fluent Bit image for the FireLens Container Type: AWS::SSM::Parameter::Value Default: /aws/service/aws-for-fluent-bit/stable ``` **Note** Si la commande échoue ou s'il n'y a aucune sortie, l'image n'est pas disponible dans le Région AWS fichier dans lequel la commande est appelée. ### Windows La dernière version stable de AWS l'URI d'image Fluent Bit peut être récupérée à l'aide de la commande suivante. ``` aws ssm get-parameters \ --names /aws/service/aws-for-fluent-bit/windowsservercore-stable \ --region us-east-1 ``` Toutes les versions de l'image AWS for Fluent Bit peuvent être répertoriées à l'aide de la commande suivante pour interroger le paramètre Systems Manager Parameter Store. ``` aws ssm get-parameters-by-path \ --path /aws/service/aws-for-fluent-bit/windowsservercore \ --region us-east-1 ``` La dernière image stable AWS pour Fluent Bit peut être référencée dans un CloudFormation modèle en faisant référence au nom du magasin de paramètres Systems Manager. Voici un exemple : ``` Parameters: FireLensImage: Description: Fluent Bit image for the FireLens Container Type: AWS::SSM::Parameter::Value Default: /aws/service/aws-for-fluent-bit/windowsservercore-stable ``` # Exemple de définition de tâche Amazon ECS : acheminement des journaux vers FireLens Pour utiliser le routage des journaux personnalisé avec FireLens, vous devez spécifier les éléments suivants dans votre définition de tâche : + Conteneur de routeur journal contenant une configuration FireLens. Nous recommandons que le conteneur soit marqué comme `essential`. + Un ou plusieurs conteneurs d'application contenant une configuration de journal spécifiant le pilote de journal `awsfirelens`. + Un rôle IAM de tâche Amazon Resource Name (ARN) qui contient les autorisations nécessaires à la tâche pour acheminer les journaux. Lorsque vous créez une nouvelle définition de tâche à l'aide de AWS Management Console, il existe une section FireLens d'intégration qui facilite l'ajout d'un conteneur de routeurs de journaux. Pour de plus amples informations, veuillez consulter [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md). Amazon ECS convertit la configuration du journal et génère la configuration de sortie Fluentd ou Fluent Bit. La configuration de sortie est montée dans le conteneur de routage des journaux à `/fluent-bit/etc/fluent-bit.conf` pour Fluent Bit et `/fluentd/etc/fluent.conf` pour Fluentd. **Important** FireLens écoute sur le port `24224`. Par conséquent, pour garantir que le routeur de FireLens journaux n'est pas accessible en dehors de la tâche, vous ne devez pas autoriser le trafic entrant sur le port `24224` du groupe de sécurité utilisé par votre tâche. Pour les tâches utilisant le mode réseau `awsvpc`, il s'agit du groupe de sécurité associé à la tâche. Pour les tâches utilisant le mode réseau `host`, il s'agit du groupe de sécurité associé à l'instance Amazon EC2 qui héberge la tâche. Pour les tâches utilisant le mode réseau `bridge`, ne créez pas de mappages de ports utilisant le port `24224`. Par défaut, Amazon ECS ajoute des champs supplémentaires dans vos entrées de journal qui aident à identifier la source des journaux. + `ecs_cluster` : nom du cluster dont la tâche fait partie. + `ecs_task_arn` : Amazon Resource Name (ARN) de la tâche dont le conteneur fait partie. + `ecs_task_definition` : nom et révision de la définition de tâche que la tâche utilise. + `ec2_instance_id` : ID de l'instance Amazon EC2 sur laquelle le conteneur est hébergé. Ce champ est uniquement valide pour les tâches qui utilisent le type de lancement EC2. Vous pouvez définir `enable-ecs-log-metadata` sur `false` si vous ne souhaitez pas les métadonnées. L'exemple de définition de tâche suivant définit un conteneur de routeur de journaux qui utilise Fluent Bit pour acheminer ses CloudWatch journaux vers Logs. Il définit également un conteneur d’application qui utilise une configuration de journal pour acheminer les journaux vers Amazon Data Firehose et définit la mémoire utilisée pour mettre en mémoire tampon les événements à 2 Mio. **Note** Pour plus d'exemples de définitions de tâches, consultez [les FireLens exemples d'Amazon ECS](https://github.com/aws-samples/amazon-ecs-firelens-examples) sur 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 } ] } ``` Les paires clés/valeurs spécifiées en tant qu'options dans l'objet `logConfiguration` sont utilisées pour générer la configuration de sortie Fluentd ou Fluent Bit. Voici un exemple de code à partir d'une définition de sortie Fluent Bit. ``` [OUTPUT] Name firehose Match app-firelens* region us-west-2 delivery_stream my-stream ``` **Note** FireLens gère la `match` configuration. Vous ne spécifiez pas la configuration `match` dans votre définition de tâche. ## Utilisation d’un fichier de configuration Vous pouvez spécifier un fichier de configuration personnalisé. Le format du fichier de configuration est le format natif du routeur de journal que vous utilisez. Pour plus d’informations, consultez les sections [Syntaxe du fichier de configuration Fluentd](https://docs.fluentd.org/configuration/config-file) et [Fichier de configuration YAML](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/yaml). Dans votre fichier de configuration personnalisé, pour les tâches utilisant le mode réseau `bridge` ou `awsvpc`, ne définissez pas d'entrée de transfert Fluentd ou Fluent Bit sur TCP, car FireLens l'ajoute à la configuration d'entrée. Votre configuration FireLens doit contenir les options suivantes pour spécifier un fichier de configuration personnalisé : `config-file-type` Emplacement source du fichier de configuration personnalisé. Les options disponibles sont `s3` ou `file`. Les tâches hébergées sur AWS Fargate ne prennent en charge que le type `file` de fichier de configuration. Toutefois, vous pouvez utiliser les fichiers de configuration hébergés dans Amazon S3 sur AWS Fargate en utilisant AWS le Fluent Bit conteneur for init. Pour plus d'informations, voir [Processus d'initialisation pour Fluent Bit sur ECS, support multi-configurations activé](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md). GitHub `config-file-value` Source du fichier de configuration personnalisé. Si le type de fichier de configuration `s3` est utilisé, la valeur du fichier de configuration est l'ARN complet du compartiment Amazon S3 et du fichier. Si le type de fichier de configuration `file` est utilisé, la valeur du fichier de configuration est le chemin d'accès complet du fichier de configuration qui existe soit dans l'image du conteneur, soit sur un volume monté dans le conteneur. Lorsque vous utilisez un fichier de configuration personnalisé, vous devez spécifier un chemin différent de celui utilisé par FireLens. Amazon ECS réserve les chemins de fichier `/fluent-bit/etc/fluent-bit.conf` pour Fluent Bit et `/fluentd/etc/fluent.conf` pour Fluentd. L'exemple suivant montre la syntaxe requise lors de la spécification d'une configuration personnalisée. **Important** Pour spécifier un fichier de configuration personnalisé hébergé dans Amazon S3, vérifiez que vous avez créé un rôle IAM d'exécution de tâche avec les autorisations appropriées. Voici la syntaxe requise lors de la spécification d'une configuration personnalisée. ``` { "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" } } } ] } ``` **Note** Les tâches hébergées sur AWS Fargate ne prennent en charge que le type `file` de fichier de configuration. Toutefois, vous pouvez utiliser les fichiers de configuration hébergés dans Amazon S3 sur AWS Fargate en utilisant AWS le Fluent Bit conteneur for init. Pour plus d'informations, voir [Processus d'initialisation pour Fluent Bit sur ECS, support multi-configurations activé](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md). GitHub # Utilisation d'images autres que des AWS conteneurs dans Amazon ECS Utilisez le registre privé pour stocker vos informations d'identification AWS Secrets Manager, puis référencez-les dans votre définition de tâche. Cela permet de référencer des images de conteneurs qui existent dans des registres privés en dehors de ceux AWS qui nécessitent une authentification dans vos définitions de tâches. Cette fonction est prise en charge par les tâches hébergées sur Fargate, les instances Amazon EC2 et les instances externes utilisant Amazon ECS Anywhere. **Important** Si votre définition de tâche fait référence à une image stockée dans Amazon ECR, cette rubrique ne s'applique pas. Pour plus d'informations, consultez [Utilisation d'images Amazon ECR avec Amazon ECS](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) dans le *Guide de l'utilisateur Amazon Elastic Container Registry*. Pour les tâches hébergées sur des instances Amazon EC2, cette fonction exige nécessite la version `1.19.0` ou ultérieure de l'agent de conteneur. Toutefois, nous vous recommandons d'utiliser la dernière version de l'agent de conteneur. Pour plus d'informations sur la vérification de la version de votre agent et la mise à jour à la dernière version, consultez [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md). Pour les tâches hébergées sur Fargate, cette fonction nécessite une version `1.2.0` de la plateforme ou une version ultérieure. Pour plus d'informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md). Dans votre définition du conteneur, spécifiez l'objet `repositoryCredentials` avec les détails du secret que vous avez créé. Le secret référencé peut provenir d'un compte différent Région AWS ou différent de celui de la tâche qui l'utilise. **Note** Lorsque vous utilisez l'API ou le AWS SDK Amazon ECS, si le secret existe dans la même tâche Région AWS que la tâche que vous lancez, vous pouvez utiliser l'ARN complet ou le nom du secret. AWS CLI Si le secret existe dans un autre compte, l'ARN complet du secret doit être spécifié. Lorsque vous utilisez le AWS Management Console, l'ARN complet du secret doit toujours être spécifié. Voici un extrait de code d'une définition de tâche indiquant les paramètres requis : Remplacez les paramètres suivants : + *private-repo*avec le nom d'hôte du dépôt privé + *private-image*avec le nom de l'image + *arn:aws:secretsmanager:region:aws\$1account\$1id:secret:secret\$1name*avec le nom secret Amazon Resource Name (ARN) ``` "containerDefinitions": [ { "image": "private-repo/private-image", "repositoryCredentials": { "credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name" } } ] ``` **Note** Une autre méthode d'activation de l'authentification de registre privé utilise des variables d'environnement d'agent de conteneur Amazon ECS pour s'authentifier auprès de registres privés. Cette méthode est prise en charge uniquement pour les tâches hébergées sur des instances Amazon EC2. Pour de plus amples informations, veuillez consulter [Configuration des instances de conteneur Amazon ECS pour les images Docker privées](private-auth-container-instances.md). **Pour utiliser un registre privé** 1. La définition de tâche doit comporter un rôle d’exécution de tâche. Cela permet à l'agent de conteneur d'extraire l'image de conteneur. Pour de plus amples informations, veuillez consulter [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md). L'authentification par registre privé permet à vos tâches Amazon ECS d'extraire des images de conteneurs depuis des registres privés extérieurs AWS (tels que Docker Hub, Quay.io ou votre propre registre privé) qui nécessitent des informations d'authentification. Cette fonctionnalité utilise Secrets Manager pour stocker en toute sécurité vos informations d’identification de registre, qui sont ensuite référencées dans votre définition de tâche à l’aide du paramètre `repositoryCredentials`. Pour plus d'informations sur la configuration de l'authentification du registre privé, consultez [Utilisation d'images non AWS conteneurisées dans Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html). Pour donner accès aux secrets contenant vos informations d’identification du registre privé, ajoutez les autorisations suivantes en tant que politique intégrée au rôle d’exécution des tâches. Pour plus d'informations, consultez [Ajout et suppression de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html). + `secretsmanager:GetSecretValue` : nécessaire pour récupérer les informations d’identification du registre privé auprès de Secrets Manager. + `kms:Decrypt`  : obligatoire uniquement si votre secret utilise une clé KMS personnalisée et non la clé par défaut. L'Amazon Resource Name (ARN) de votre clé personnalisée doit être ajouté en tant que ressource. Voici un exemple de stratégie en ligne qui ajoute les autorisations. ------ #### [ 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. AWS Secrets Manager À utiliser pour créer un secret pour vos informations d'identification de registre privées. Pour plus d’informations sur la création d’un secret, consultez la section [Création d’un secret AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) dans le *Guide de l’utilisateur AWS Secrets Manager *. Saisissez vos informations d’identification de registre privé en utilisant le format suivant : ``` { "username" : "privateRegistryUsername", "password" : "privateRegistryPassword" } ``` 1. Enregistrer une définition de tâche. Pour de plus amples informations, veuillez consulter [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md). # Redémarrage de conteneurs individuels dans les tâches Amazon ECS à l’aide de politiques de redémarrage de conteneurs Vous pouvez activer une politique de redémarrage pour chaque conteneur essentiel et non essentiel défini dans votre définition de tâche, afin de surmonter plus rapidement les défaillances transitoires et de maintenir la disponibilité des tâches. Lorsque vous activez une politique de redémarrage pour un conteneur, Amazon ECS peut redémarrer le conteneur s’il existe, sans avoir à remplacer la tâche. Les politiques de redémarrage ne sont pas activées par défaut pour les conteneurs. Lorsque vous activez une politique de redémarrage pour un conteneur, vous pouvez spécifier les codes de sortie pour lesquels le conteneur ne sera pas redémarré. Il peut s’agir de codes de sortie indiquant le succès, tels que des codes de sortie `0`, qui ne nécessitent pas de redémarrage. Vous pouvez également spécifier la durée pendant laquelle un conteneur doit fonctionner correctement avant qu’un redémarrage puisse être tenté. Pour obtenir plus d’informations sur ces paramètres, consultez [Politique de redémarrage](task_definition_parameters.md#container_definition_restart_policy). Pour un exemple de définition de tâche qui spécifie ces valeurs, consultez la section [Spécification d’une politique de redémarrage de conteneur dans une définition de tâche Amazon ECS](container-restart-policy-example.md). Vous pouvez utiliser le point de terminaison des métadonnées des tâches Amazon ECS ou CloudWatch Container Insights pour surveiller le nombre de redémarrages d'un conteneur. Pour plus d’informations sur le point de terminaison des métadonnées de tâche, consultez les sections [Point de terminaison des métadonnées de tâches Amazon ECS version 4](task-metadata-endpoint-v4.md) et [Point de terminaison des métadonnées de tâches Amazon ECS version 4 pour les tâches sur Fargate](task-metadata-endpoint-v4-fargate.md). Pour plus d'informations sur les métriques Container Insights pour Amazon ECS, consultez les [métriques Amazon ECS Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html) dans le *guide de CloudWatch l'utilisateur Amazon*. Les politiques de redémarrage des conteneurs sont prises en charge par les tâches hébergées sur Fargate, les instances Amazon EC2 et les instances externes utilisant Amazon ECS Anywhere. ## Considérations Tenez compte des points suivants avant d’activer une politique de redémarrage pour votre conteneur : + Les politiques de redémarrage ne sont pas prises en charge pour les conteneurs Windows sur Fargate. + Pour les tâches hébergées sur des instances Amazon EC2, cette fonction exige nécessite la version `1.86.0` ou ultérieure de l'agent de conteneur. Toutefois, nous vous recommandons d'utiliser la dernière version de l'agent de conteneur. Pour plus d'informations sur la vérification de la version de votre agent et la mise à jour à la dernière version, consultez [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md). + Si vous utilisez EC2 en mode `bridge` réseau, la variable d'`FLUENT_HOST`environnement de votre conteneur d'applications peut devenir inexacte après le redémarrage du conteneur FireLens log router (le conteneur contenant l'`firelensConfiguration`objet dans sa définition de conteneur). Cela est dû au fait que `FLUENT_HOST` est une adresse IP dynamique qui peut changer après un redémarrage. La journalisation directe depuis le conteneur de l’application vers l’adresse IP `FLUENT_HOST` peut commencer à échouer après le changement d’adresse. Pour plus d’informations sur `FLUENT_HOST`, consultez [Configuration des journaux Amazon ECS pour un débit élevé](firelens-docker-buffer-limit.md). + L’agent Amazon ECS gère les politiques de redémarrage des conteneurs. Si, pour une raison inattendue, l’agent Amazon ECS échoue ou ne fonctionne plus, le conteneur ne sera pas redémarré. + La période de tentative de redémarrage définie dans votre politique détermine la période (en secondes) pendant laquelle le conteneur doit fonctionner avant qu’Amazon ECS ne redémarre un conteneur. # Spécification d’une politique de redémarrage de conteneur dans une définition de tâche Amazon ECS Pour spécifier une politique de redémarrage pour un conteneur dans une définition de tâche, dans la définition du conteneur, spécifiez l’objet `restartPolicy`. Pour plus d’informations sur l’objet `restartPolicy`, consultez la section [Politique de redémarrage](task_definition_parameters.md#container_definition_restart_policy). Ce qui suit est une définition de tâche utilisant les conteneurs Linux sur Fargate qui configure un serveur Web. La définition du conteneur inclut l’objet `restartPolicy`, avec `enabled` défini sur true pour activer une politique de redémarrage pour le conteneur. Le conteneur doit fonctionner pendant 180 secondes avant de pouvoir être redémarré et ne sera pas redémarré s’il se ferme avec le code de sortie `0`, qui indique un succès. ``` { "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"] } ``` Après avoir enregistré une définition de tâche avec l’objet `restartPolicy` dans une définition de conteneur, vous pouvez exécuter une tâche ou créer un service avec cette définition de tâche. Pour plus d’informations, consultez [Exécution d’une application en tant que tâche Amazon ECS](standalone-task-create.md) et [Création d’un déploiement de mise à jour propagée Amazon ECS](create-service-console-v2.md). # Transmission de données sensibles vers un conteneur Amazon ECS Vous pouvez transmettre en toute sécurité des données sensibles, telles que des informations d'identification vers une base de données, dans votre conteneur. Les secrets, tels que les clés d'API et les informations d'identification de base de données, sont fréquemment utilisés par les applications pour accéder à d'autres systèmes. Ils se composent souvent d'un nom d'utilisateur et d'un mot de passe, d'un certificat ou d'une clé d'API. L'accès à ces secrets doit être limité à des principaux IAM spécifiques qui utilisent IAM et injectés dans des conteneurs lors de l'exécution. Les secrets peuvent être injectés facilement dans des conteneurs à partir AWS Secrets Manager d'Amazon EC2 Systems Manager Parameter Store. Ces secrets peuvent être référencés dans votre tâche de l'une des manières suivantes. 1. Ils sont référencés en tant que variables d'environnement qui utilisent le paramètre de définition du conteneur `secrets`. 1. Ils sont référencés comme `secretOptions` si votre plateforme de journalisation nécessite une authentification. Pour plus d'informations, veuillez consulter [Options de configuration de la journalisation](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html#API_LogConfiguration_Contents) (langue française non garantie). 1. Ils sont référencés comme des secrets extraits par des images qui utilisent le paramètre de définition de conteneur `repositoryCredentials` si le registre d'où le conteneur est extrait nécessite une authentification. Utilisez cette méthode lors de l'extraction d'images depuis la Galerie publique Amazon ECR. Pour plus d'informations, veuillez consulter [Authentification de registre privé pour les tâches](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html) (langue française non garantie). Nous vous recommandons d'effectuer les opérations suivantes lorsque vous configurez la gestion des secrets. ## Utiliser AWS Secrets Manager ou AWS Systems Manager Parameter Store pour stocker des documents secrets Vous devez stocker en toute sécurité les clés d’API, les informations d’identification de base de données et les autres éléments secrets dans Secrets Manager ou sous forme de paramètre chiffré dans le magasin de paramètres Systems Manager. Ces services sont similaires car il s'agit tous deux de magasins de valeurs clés gérés utilisés AWS KMS pour chiffrer des données sensibles. Secrets Manager, cependant, inclut également la possibilité de faire pivoter automatiquement les secrets, de générer des secrets aléatoires et de partager des secrets entre les comptes. Pour utiliser ces fonctionnalités, utilisez Secrets Manager. Sinon, utilisez des paramètres chiffrés dans le magasin de paramètres Systems Manager. **Important** Si votre secret change, vous devez forcer un nouveau déploiement ou lancer une nouvelle tâche pour récupérer la dernière valeur secrète. Pour plus d’informations, consultez les rubriques suivantes : Tâches : arrêtez la tâche, puis démarrez-la. Pour plus d’informations, consultez [Arrêt d’une tâche Amazon ECS](standalone-task-stop.md) et [Exécution d’une application en tant que tâche Amazon ECS](standalone-task-create.md). Service : mettez à jour le service et utilisez l’option « Forcer un nouveau déploiement ». Pour de plus amples informations, veuillez consulter [Mettre à jour un service Amazon ECS](update-service-console-v2.md). ## Récupération des données d’un compartiment Amazon S3 chiffré Vous devez stocker les secrets dans un compartiment chiffré Amazon S3 et utiliser des rôles de tâche pour restreindre l’accès à ces secrets. Cela empêche les valeurs des variables d’environnement de s’échapper par inadvertance dans les journaux et d’être révélées lors de l’exécution de `docker inspect`. Dans ce cas, votre application doit être écrite pour lire le secret du compartiment Amazon S3. Pour obtenir des instructions, veuillez consulter [Définition du comportement de chiffrement côté serveur par défaut pour les compartiments Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-encryption.html). ## Montez le secret sur un volume à l'aide d'un conteneur sidecar Comme le risque de fuite de données lié aux variables d'environnement est élevé, vous devez utiliser un conteneur annexe qui lit vos secrets AWS Secrets Manager et les écrit sur un volume partagé. Ce conteneur peut s'exécuter et sortir avant le conteneur d'applications en utilisant le système de [commande de conteneurs Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html). Ainsi, le conteneur de l'application monte ensuite le volume dans lequel le secret a été écrit. À l'instar de la méthode du compartiment Amazon S3, votre application doit être écrite pour lire le secret du volume partagé. Le volume étant limité à la tâche, il est automatiquement supprimé après l'arrêt de la tâche. Pour un exemple, consultez le projet [task-def.json](https://github.com/aws-samples/aws-secret-sidecar-injector/blob/master/ecs-task-def/task-def.json). Sur Amazon EC2, le volume sur lequel le secret est écrit peut être chiffré à l'aide d'une clé AWS KMS gérée par le client. Activé AWS Fargate, le stockage en volume est automatiquement chiffré à l'aide d'une clé gérée par le service. # Transmission d’une variable d’environnement individuelle à un conteneur Amazon ECS **Important** Nous vous recommandons de stocker vos données sensibles dans des AWS Secrets Manager secrets ou dans des paramètres AWS Systems Manager Parameter Store. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur Amazon ECS](specifying-sensitive-data.md). Les variables d'environnement spécifiées dans la définition de tâche sont lisibles par tous les utilisateurs et rôles autorisés à effectuer l'action `DescribeTaskDefinition` pour la définition de tâche. Vous pouvez transmettre des variables d'environnement à vos conteneurs des manières suivantes : + Individuellement à l'aide du paramètre de définition de conteneur `environment`. Cela correspond à l'option `--env` de [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/). + En bloc, en utilisant le paramètre de définition de conteneur `environmentFiles` pour répertorier un ou plusieurs fichiers contenant les variables d'environnement. Le fichier doit être hébergé dans Amazon S3. Cela correspond à l'option `--env-file` de [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/). Voici un extrait d'une définition de tâche montrant comment spécifier des variables d'environnement individuelles. ``` { "family": "", "containerDefinitions": [ { "name": "", "image": "", ... "environment": [ { "name": "variable", "value": "value" } ], ... } ], ... } ``` # Transmission de variables d’environnement à un conteneur Amazon ECS **Important** Nous vous recommandons de stocker vos données sensibles dans des AWS Secrets Manager secrets ou dans des paramètres AWS Systems Manager Parameter Store. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur Amazon ECS](specifying-sensitive-data.md). Les fichiers de variables d'environnement sont des objets dans Simple Storage Service (Amazon S3) et toutes les considérations de sécurité Simple Storage Service (Amazon S3) s'appliquent. Vous ne pouvez pas utiliser le paramètre `environmentFiles` sur les conteneurs Windows et les conteneurs Windows sur Fargate. Vous pouvez créer un fichier de variables d’environnement et le stocker dans Amazon S3 pour transmettre des variables d’environnement à votre conteneur. En spécifiant des variables d'environnement dans un fichier, vous pouvez injecter en bloc des variables d'environnement. Dans votre définition de conteneur, spécifiez l'objet `environmentFiles` avec une liste de compartiments Amazon S3 contenant vos fichiers de variables d'environnement. Amazon ECS n’impose pas de limite de taille pour les variables d’environnement, mais un fichier de variables d’environnement volumineux peut saturer l’espace disque. Chaque tâche qui utilise un fichier de variables d'environnement entraîne le téléchargement d'une copie du fichier sur le disque. Amazon ECS supprime le fichier dans le cadre du nettoyage des tâches. Pour plus d'informations sur les variables d'environnement prises en charge, veuillez consulter [Paramètres de définition de conteneur avancés - Environnement](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_environment). Tenez compte des éléments suivants lors de la spécification d'un fichier de variable d'environnement dans une définition de conteneur. + Pour toute tâche Amazon ECS hébergé sur Amazon EC2, vos instances de conteneur nécessitent une version `1.39.0` ou ultérieure de l'agent de conteneur pour utiliser cette fonction. Pour plus d'informations sur la vérification de la version de votre agent et la mise à jour à la dernière version, consultez [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md). + Pour les tâches Amazon ECS sur AWS Fargate, vos tâches doivent utiliser la version de plate-forme ou une `1.4.0` version ultérieure (Linux) pour utiliser cette fonctionnalité. Pour de plus amples informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md). Vérifiez que la variable est prise en charge par la plateforme du système d'exploitation. Pour plus d’informations, consultez [Définitions de conteneur](task_definition_parameters.md#container_definitions) et [Autres paramètres de définition de tâche](task_definition_parameters.md#other_task_definition_params). + Le fichier doit utiliser l'extension de fichier `.env` et l'encodage UTF-8. + Le rôle d’exécution de tâche est requis pour utiliser cette fonctionnalité avec les autorisations supplémentaires pour Amazon S3. Cela permet à l'agent de conteneur d'extraire le fichier de variable d'environnement à partir d'Amazon S3. Pour de plus amples informations, veuillez consulter [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md). + Il y a une limite de 10 fichiers par définition de tâche. + Chaque ligne d'un fichier d'environnement doit contenir une variable d'environnement au format `VARIABLE=VALUE`. Des espaces ou des guillemets **sont** inclus dans les valeurs pour les fichiers Amazon ECS. Les lignes commençant par `#` sont traitées comme des commentaires et sont ignorées. Pour de plus amples informations sur la syntaxe du fichier de variable d’environnement, consultez la section [Définition des variables d’environnement (-e, --env, --env-file)](https://docs.docker.com/reference/cli/docker/container/run/#env) dans la documentation Docker. Voici la syntaxe appropriée. ``` #This is a comment and will be ignored VARIABLE=VALUE ENVIRONMENT=PRODUCTION ``` + Si des variables d'environnement sont spécifiées à l'aide du paramètre `environment` dans une définition de conteneur, elles ont priorité sur les variables contenues dans un fichier d'environnement. + Si plusieurs fichiers d'environnement contenant la même variable sont spécifiés, ils sont traités par ordre d'entrée. Cela signifie que la première valeur de la variable est utilisée et que les valeurs suivantes des variables dupliquées sont ignorées. Nous vous recommandons d'utiliser des noms de variables uniques. + Si un fichier d'environnement est spécifié en tant que remplacement de conteneur, il est utilisé. De plus, tous les autres fichiers d'environnement spécifiés dans la définition du conteneur sont ignorés. + Les règles suivantes s’appliquent à Fargate : + Le fichier est traité de manière similaire à un fichier env Docker natif. + Les définitions de conteneur qui font référence à des variables d’environnement vides et stockées dans Amazon S3 n’apparaissent pas dans le conteneur. + La gestion de l'échappement dans shell n'est pas prise en charge. + Le point d'entrée du conteneur interprète les valeurs `VARIABLE`. ## Exemple Voici un extrait d'une définition de tâche indiquant comment spécifier un fichier de variable d'environnement. ``` { "family": "", "containerDefinitions": [ { "name": "", "image": "", ... "environmentFiles": [ { "value": "arn:aws:s3:::amzn-s3-demo-bucket/envfile_object_name.env", "type": "s3" } ], ... } ], ... } ``` # Transmission des secrets Secrets Manager par programmation dans Amazon ECS Au lieu de coder en dur les informations sensibles en texte brut dans votre application, vous pouvez utiliser Secrets Manager pour stocker les données sensibles. Nous recommandons cette méthode pour récupérer les données sensibles, car si le secret de Secrets Manager est ultérieurement mis à jour, l'application récupère automatiquement la dernière version de celui-ci. Créez un secret dans Secrets Manager. Après avoir créé un secret dans Secrets Manager, mettez à jour le code de votre application pour récupérer le secret. Prenez en compte les points suivants avant de sécuriser des données sensibles dans Secrets Manager. + Seuls les secrets qui stockent des données texte, qui sont des secrets créés avec le `SecretString` paramètre de l'[CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html)API, sont pris en charge. Les secrets qui stockent des données binaires, qui sont des secrets créés avec le `SecretBinary` paramètre de l'[CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html)API, ne sont pas pris en charge. + Utilisez les points de terminaison VPC de l'interface pour améliorer les contrôles de sécurité. Vous devez créer les points de terminaison d'un VPC pour Secrets Manager. Pour plus d'informations sur le point de terminaison d'un VPC, veuillez consulter [Créer des points de terminaison d'un VPC](https://docs.aws.amazon.com/secretsmanager/latest/userguide/setup-create-vpc.html) dans le *Guide de l'utilisateur AWS Secrets Manager *. + Le VPC que votre tâche utilise doit utiliser la résolution DNS. + Votre définition de tâche doit utiliser un rôle de tâche doté des autorisations supplémentaires pour Secrets Manager. Pour de plus amples informations, veuillez consulter [rôle IAM de tâche Amazon ECS](task-iam-roles.md). ## Créer le secret Secrets Manager Vous pouvez utiliser la console Secrets Manager afin de créer un secret pour vos données sensibles. Pour plus d'informations sur la création de secrets, consultez la rubrique [Création d'un secret AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) dans le *Guide de l'utilisateur AWS Secrets Manager *. ## Mettez à jour votre application pour récupérer le secret Secrets Manager par programme Vous pouvez récupérer des secrets en appelant le Secrets Manager APIs directement depuis votre application. Pour plus d’informations, consultez la section [Récupérer les secrets depuis AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) dans le *Guide de l’utilisateur AWS Secrets Manager *. Pour récupérer les données sensibles stockées dans le AWS Secrets Manager, consultez les [exemples de code à AWS Secrets Manager utiliser AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/secrets-manager_code_examples.html) dans la *bibliothèque de codes d'exemples de code du AWS SDK*. # Transmission des secrets du magasin de paramètres Systems Manager par programmation dans Amazon ECS Systems Manager Parameter Store offre un stockage et une gestion sécurisés des secrets. Vous pouvez stocker des données telles que les mots de passe, les chaînes de base de données, l'instance EC2 IDs et l'AMI IDs, ainsi que les codes de licence sous forme de valeurs de paramètres, au lieu de coder ces informations en dur dans votre application. Vous pouvez stocker ces valeurs sous forme de texte brut ou de données chiffrées. Nous recommandons cette méthode de récupération des données sensibles, car si le magasin de paramètres Systems Manager est mis à jour ultérieurement, l’application récupère automatiquement la dernière version. Prenez en compte les points suivants avant de sécuriser des données sensibles dans Systems Manager Parameter Store. + Seuls les secrets qui stockent des données texte sont pris en charge. Les secrets qui stockent des données binaires ne sont pas pris en charge. + Utilisez les points de terminaison d’un VPC de l'interface pour améliorer les contrôles de sécurité. + Le VPC que votre tâche utilise doit utiliser la résolution DNS. + Pour les tâches qui utilisent EC2, vous devez utiliser la variable de configuration `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true` de l’agent ECS pour utiliser cette fonctionnalité. Vous pouvez l'ajouter au fichier `/etc/ecs/ecs.config` lors de la création de l'instance de conteneur, ou vous pouvez l'ajouter à une instance existante, puis redémarrer l'agent ECS. Pour de plus amples informations, veuillez consulter [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md). + Votre définition de tâche doit utiliser un rôle de tâche doté des autorisations supplémentaires pour le magasin de paramètres Systems Manager. Pour de plus amples informations, veuillez consulter [rôle IAM de tâche Amazon ECS](task-iam-roles.md). ## Créer le paramètre Vous pouvez utiliser la console System Manager pour créer un paramètre Systems Manager Parameter Store pour vos données sensibles. Pour plus d'informations, consultez [Créer un paramètre Systems Manager (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) ou [Créer un paramètre Systems Manager (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html) dans le *Guide de l'utilisateur AWS Systems Manager *. ## Mettez à jour votre application pour récupérer par programme les secrets Systems Manager Parameter Store. Pour récupérer les données sensibles stockées dans le paramètre Systems Manager Parameter Store, consultez les [exemples de code à utiliser par Systems Manager AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/ssm_code_examples.html) dans la *bibliothèque de codes d'exemples de code du AWS SDK*. # Transmission des secrets Secrets Manager via les variables d’environnement Amazon ECS Lorsque vous injectez un secret en tant que variable d’environnement, vous pouvez spécifier le contenu complet d’un secret ou une clé JSON spécifique au sein d’un secret. Cela vous aide à contrôler les données sensibles exposées à votre conteneur. Pour plus d’informations sur la gestion des versions de secrets, consultez la section [Que contient un secret Secrets Manager ?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/whats-in-a-secret.html#term_version) dans le *Guide de l’utilisateur AWS Secrets Manager *. Les informations suivantes doivent être prises en compte lors de l’utilisation d’une variable d’environnement pour injecter un secret Secrets Manager dans un conteneur. + Les données sensibles sont injectées dans votre conteneur lors du démarrage initial du conteneur. Si le secret est ensuite mis à jour ou fait l'objet d'une rotation, le conteneur ne reçoit pas la valeur mise à jour automatiquement. Vous devez lancer une nouvelle tâche ou, si votre tâche fait partie d'un service, vous pouvez mettre à jour le service et utiliser l'option **Force new deployment** (Forcer un nouveau déploiement) pour forcer le service à lancer une nouvelle tâche. + Les applications qui s’exécutent sur le conteneur, les journaux du conteneur et les outils de débogage ont accès aux variables d’environnement. + Pour les tâches Amazon ECS sur AWS Fargate, tenez compte des points suivants : + Pour injecter le contenu complet d'un secret en tant que variable d'environnement ou dans une configuration de journal, vous devez utiliser la version `1.3.0` ou ultérieure de la plateforme. Pour plus d'informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md). + Pour injecter une clé JSON spécifique ou une version d'un secret en tant que variable d'environnement ou dans une configuration de journal, vous devez utiliser la version `1.4.0` de la plateforme ou une version ultérieure (Linux) ou `1.0.0` (Windows). Pour plus d'informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md). + Pour les tâches Amazon ECS sur EC2, les informations suivantes doivent être prises en compte : + Pour injecter un secret à l'aide d'une clé JSON spécifique ou d'une version d'un secret, votre instance de conteneur doit avoir la version `1.37.0` ou ultérieure de l'agent de conteneur. Toutefois, nous vous recommandons d'utiliser la dernière version de l'agent de conteneur. Pour plus d'informations sur la vérification de la version de votre agent et la mise à jour à la dernière version, consultez [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md). Pour injecter le contenu complet d'un secret en tant que variable d'environnement ou pour injecter un secret dans une configuration de journal, votre instance de conteneur doit avoir la version `1.22.0` ou ultérieure de l'agent de conteneur. + Utilisez les points de terminaison de VPC d’interface pour renforcer les contrôles de sécurité et pour vous connecter à Secrets Manager via un sous-réseau privé. Vous devez créer les points de terminaison d'un VPC pour Secrets Manager. Pour plus d'informations sur le point de terminaison d'un VPC, veuillez consulter [Créer des points de terminaison d'un VPC](https://docs.aws.amazon.com/secretsmanager/latest/userguide/setup-create-vpc.html) dans le *Guide de l'utilisateur AWS Secrets Manager *. Pour plus d’informations sur l’utilisation de Secrets Manager et Amazon VPC, consultez la section [Comment se connecter au service Secrets Manager au sein d’un Amazon VPC](https://aws.amazon.com/blogs//security/how-to-connect-to-aws-secrets-manager-service-within-a-virtual-private-cloud/). + Pour les tâches Windows configurées pour utiliser le pilote de journalisation `awslogs`, vous devez également définir la variable d'environnement `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE` sur votre instance de conteneur. Utilisez la syntaxe suivante : ``` [Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine") Initialize-ECSAgent -Cluster -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]' ``` + Votre définition de tâche doit utiliser un rôle d’exécution de tâche doté des autorisations supplémentaires pour Secrets Manager. Pour de plus amples informations, veuillez consulter [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md). ## Créez le AWS Secrets Manager secret Vous pouvez utiliser la console Secrets Manager afin de créer un secret pour vos données sensibles. Pour plus d'informations, voir [Création d'un AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) dans le *guide de AWS Secrets Manager l'utilisateur*. ## Ajoutez la variable d'environnement à la définition du conteneur Dans votre définition de conteneur, vous pouvez spécifier les éléments suivants : + Objet `secrets` contenant le nom de la variable d'environnement à définir dans le conteneur + Amazon Resource Name (ARN) du secret Secrets Manager + Paramètres supplémentaires contenant les données sensibles à présenter au conteneur L'exemple suivant montre la syntaxe complète qui doit être spécifiée pour le secret Secrets Manager. ``` arn:aws:secretsmanager:region:aws_account_id:secret:secret-name:json-key:version-stage:version-id ``` La section suivante décrit les paramètres supplémentaires. Ces paramètres sont facultatifs, mais si vous ne les utilisez pas, vous devez inclure les deux-points `:` pour utiliser les valeurs par défaut. Des exemples sont donnés ci-dessous pour plus de contexte. `json-key` Spécifie le nom de la clé dans une paire clé-valeur avec la valeur que vous souhaitez définir comme valeur de variable d'environnement. Seules les valeurs au format JSON sont prises en charge. Si vous ne spécifiez pas de clé JSON, le contenu complet du secret est utilisé. `version-stage` Spécifie l'étiquette intermédiaire de la version d'un secret que vous souhaitez utiliser. Si une étiquette intermédiaire de version est spécifiée, vous ne pouvez pas spécifier d'ID de version. Si aucune étape de version n'est spécifiée, le comportement par défaut consiste à récupérer le secret avec l'étiquette `AWSCURRENT` intermédiaire. Les étiquettes intermédiaires sont utilisées pour suivre les différentes versions d'un secret lorsqu'elles sont mises à jour ou font l'objet d'une rotation. Chaque version d'un secret a une ou plusieurs étiquettes intermédiaires et un ID. `version-id` Spécifie l'identifiant unique de la version du secret que vous souhaitez utiliser. Si un ID de version est spécifié, vous ne pouvez pas spécifier d'étiquette intermédiaire de version. Si aucun ID de version n'est spécifié, le comportement par défaut consiste à récupérer le secret avec l'étiquette `AWSCURRENT` intermédiaire. IDs Les versions sont utilisées pour suivre les différentes versions d'un secret lors de leur mise à jour ou de leur rotation. Chaque version d'un secret a un ID. Pour plus d'informations, veuillez consulter la rubrique [Concepts et termes clés pour AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/terms-concepts.html#term_secret) dans le *Guide de l'utilisateur AWS Secrets Manager *. ### Exemples de définitions de conteneur Les exemples suivants montrent comment vous pouvez référencer des secrets Secrets Manager dans vos définitions de conteneur. **Example référencement d'un secret complet** Voici un extrait d'une définition de tâche montrant le format lorsque vous référencez le texte complet d'un secret Secrets Manager. ``` { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf" }] }] } ``` Pour accéder à la valeur de ce secret depuis le conteneur, vous devez appeler `$environment_variable_name`. **Example référencement de secrets complets** Voici l’extrait de code d’une définition de tâche présentant le format utilisé pour référencer le texte intégral de plusieurs secrets 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" } ] }] } ``` Pour accéder à la valeur de ce secret à partir du conteneur, vous devez appeler `$environment_variable_name1`, `$environment_variable_name2` et `$environment_variable_name3`. **Example référencement d'une clé spécifique dans un secret** Voici un exemple de sortie d'une [get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html)commande qui affiche le contenu d'un secret ainsi que le libellé de la version intermédiaire et l'ID de version qui lui sont associés. ``` { "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 } ``` Référence d'une clé spécifique de la sortie précédente dans une définition de conteneur en spécifiant le nom de la clé à la fin de l'ARN. ``` { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1::" }] }] } ``` **Example référencement d'une version secrète spécifique** Voici un exemple de sortie d'une commande [describe-secret](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/describe-secret.html) qui affiche le contenu non chiffré d'un secret ainsi que les métadonnées de toutes les versions du secret. ``` { "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" ] } } ``` Référence d'une étiquette intermédiaire de version spécifique à partir de la sortie précédente dans une définition de conteneur en spécifiant le nom de la clé à la fin de l'ARN. ``` { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf::AWSPREVIOUS:" }] }] } ``` Référence un ID de version spécifique de la sortie précédente dans une définition de conteneur en spécifiant le nom de clé à la fin de l'ARN. ``` { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:::9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE" }] }] } ``` **Example référencement d'une clé spécifique et d'une étiquette intermédiaire de version d'un secret** Ce qui suit montre comment référencer à la fois une clé spécifique dans une étiquette secrète et une étiquette de mise en scène de version spécifique. ``` { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1:AWSPREVIOUS:" }] }] } ``` Pour spécifier une clé et un ID de version spécifiques, utilisez la syntaxe suivante. ``` { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1::9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE" }] }] } ``` Pour plus d’informations sur la création d’une définition de tâche avec le secret spécifié dans une variable d’environnement, consultez la section [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md). # Transmission des paramètres System Manager via les variables d’environnement Amazon ECS Amazon ECS vous permet d'injecter des données sensibles dans vos conteneurs en les stockant dans les paramètres du AWS Systems Manager Parameter Store, puis en les référençant dans la définition de votre conteneur. Tenez compte des éléments suivants lorsque vous utilisez une variable d’environnement pour injecter un secret Systems Manager dans un conteneur. + Les données sensibles sont injectées dans votre conteneur lors du démarrage initial du conteneur. Si le secret est ensuite mis à jour ou fait l'objet d'une rotation, le conteneur ne reçoit pas la valeur mise à jour automatiquement. Vous devez lancer une nouvelle tâche ou, si votre tâche fait partie d'un service, vous pouvez mettre à jour le service et utiliser l'option **Force new deployment** (Forcer un nouveau déploiement) pour forcer le service à lancer une nouvelle tâche. + Pour les tâches Amazon ECS sur AWS Fargate, les points suivants doivent être pris en compte : + Pour injecter le contenu complet d'un secret en tant que variable d'environnement ou dans une configuration de journal, vous devez utiliser la version `1.3.0` ou ultérieure de la plateforme. Pour plus d'informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md). + Pour injecter une clé JSON spécifique ou une version d'un secret en tant que variable d'environnement ou dans une configuration de journal, vous devez utiliser la version `1.4.0` de la plateforme ou une version ultérieure (Linux) ou `1.0.0` (Windows). Pour plus d'informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md). + Pour les tâches Amazon ECS sur EC2, les informations suivantes doivent être prises en compte : + Pour injecter un secret à l'aide d'une clé JSON spécifique ou d'une version d'un secret, votre instance de conteneur doit avoir la version `1.37.0` ou ultérieure de l'agent de conteneur. Toutefois, nous vous recommandons d'utiliser la dernière version de l'agent de conteneur. Pour plus d'informations sur la vérification de la version de votre agent et la mise à jour à la dernière version, consultez [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md). Pour injecter le contenu complet d'un secret en tant que variable d'environnement ou pour injecter un secret dans une configuration de journal, votre instance de conteneur doit avoir la version `1.22.0` ou ultérieure de l'agent de conteneur. + Utilisez les points de terminaison VPC de l'interface pour améliorer les contrôles de sécurité. Vous devez créer les points de terminaison de VPC d’interface pour Systems Manager. Pour plus d’informations sur le point de terminaison de VPC, consultez la section [Amélioration de la sécurité des instances EC2 à l’aide des points de terminaison de VPC pour Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html) dans le *Guide de l’utilisateur AWS Systems Manager *. + Votre définition de tâche doit utiliser un rôle d’exécution de tâche doté des autorisations supplémentaires pour le magasin de paramètres Systems Manager. Pour de plus amples informations, veuillez consulter [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md). + Pour les tâches Windows configurées pour utiliser le pilote de journalisation `awslogs`, vous devez également définir la variable d'environnement `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE` sur votre instance de conteneur. Utilisez la syntaxe suivante : ``` [Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine") Initialize-ECSAgent -Cluster -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]' ``` ## Création du paramètre Systems Manager Vous pouvez utiliser la console System Manager pour créer un paramètre Systems Manager Parameter Store pour vos données sensibles. Pour plus d'informations, consultez [Créer un paramètre Systems Manager (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) ou [Créer un paramètre Systems Manager (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html) dans le *Guide de l'utilisateur AWS Systems Manager *. ## Ajoutez la variable d'environnement à la définition du conteneur Dans la définition de votre conteneur dans la définition de tâche, spécifiez `secrets` avec le nom de la variable d’environnement à définir dans le conteneur et l’ARN complet du paramètre du magasin de paramètres Systems Manager contenant les données sensibles à présenter au conteneur. Pour de plus amples informations, veuillez consulter [secrets](task_definition_parameters.md#ContainerDefinition-secrets). Voici un extrait d'une définition de tâche montrant le format à utiliser lorsque vous référencez un paramètre Systems Manager Parameter Store. Si le paramètre Systems Manager Parameter Store existe dans la même région que la tâche que vous lancez, vous pouvez utiliser le nom ou l'ARN complet du paramètre. Si le paramètre existe dans une autre région, l'ARN complet doit être spécifié. ``` { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name" }] }] } ``` Pour plus d’informations sur la création d’une définition de tâche avec le secret spécifié dans une variable d’environnement, consultez la section [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md). ## Mettez à jour votre application pour récupérer par programme les secrets Systems Manager Parameter Store. Pour récupérer les données sensibles stockées dans le paramètre Systems Manager Parameter Store, consultez les [exemples de code à utiliser par Systems Manager AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/ssm_code_examples.html) dans la *bibliothèque de codes d'exemples de code du AWS SDK*. # Transmission des secrets pour la configuration de la journalisation Amazon ECS Vous pouvez utiliser le paramètre `secretOptions` dans `logConfiguration` pour transmettre les données sensibles utilisées pour la journalisation. Vous pouvez stocker le secret dans Secrets Manager ou Systems Manager. ## Utilisation de Secrets Manager Dans votre définition de conteneur, lorsque vous spécifiez une `logConfiguration`, vous pouvez spécifier `secretOptions` avec le nom de l'option du pilote de journal à définir dans le conteneur et l'ARN complet du secret Secrets Manager contenant les données sensibles à présenter au conteneur. Pour plus d’informations sur la création de secrets, consultez la section [Création d’un AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html). Voici un extrait d'une définition de tâche montrant le format lorsque vous référencez un secret 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" }] }] }] } ``` ## Ajoutez la variable d'environnement à la définition du conteneur Dans votre définition de conteneur, spécifiez `secrets` avec le nom de la variable d'environnement à définir dans le conteneur et l'ARN complet du paramètre Systems Manager Parameter Store contenant les données sensibles à présenter au conteneur. Pour de plus amples informations, veuillez consulter [secrets](task_definition_parameters.md#ContainerDefinition-secrets). Voici un extrait d'une définition de tâche montrant le format à utiliser lorsque vous référencez un paramètre Systems Manager Parameter Store. Si le paramètre Systems Manager Parameter Store existe dans la même région que la tâche que vous lancez, vous pouvez utiliser le nom ou l'ARN complet du paramètre. Si le paramètre existe dans une autre région, l'ARN complet doit être spécifié. ``` { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name" }] }] } ``` Pour plus d’informations sur la création d’une définition de tâche avec le secret spécifié dans une variable d’environnement, consultez la section [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md). ## Utiliser Systems Manager Vous pouvez injecter des données sensibles dans une configuration de journal. Dans votre définition de conteneur, lorsque vous spécifiez `logConfiguration`, vous pouvez spécifier `secretOptions` avec le nom de l'option du pilote de journal à définir dans le conteneur et l'ARN complet du paramètre Systems Manager Parameter Store contenant les données sensibles à présenter au conteneur. **Important** Si le paramètre Systems Manager Parameter Store existe dans la même région que la tâche que vous lancez, vous pouvez utiliser le nom ou l'ARN complet du paramètre. Si le paramètre existe dans une autre région, l'ARN complet doit être spécifié. Voici un extrait d'une définition de tâche montrant le format à utiliser lorsque vous référencez un paramètre Systems Manager Parameter Store. ``` { "containerDefinitions": [{ "logConfiguration": [{ "logDriver": "fluentd", "options": { "tag": "fluentd demo" }, "secretOptions": [{ "name": "fluentd-address", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter:/parameter_name" }] }] }] } ``` # Spécification de données sensibles à l’aide de secrets Secrets Manager dans Amazon ECS Amazon ECS vous permet d'injecter des données sensibles dans vos conteneurs en les stockant en AWS Secrets Manager secret, puis en les référençant dans la définition de votre conteneur. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur Amazon ECS](specifying-sensitive-data.md). Découvrez comment créer un secret Secrets Manager, référencer le secret dans une définition de tâche Amazon ECS, puis vérifier que cela a fonctionné en interrogeant la variable d’environnement dans un conteneur montrant le contenu du secret. ## Conditions préalables Le didacticiel suppose de remplir les prérequis suivants : + Vous devez avoir suivi les étapes de [Configurer l'utilisation d'Amazon ECS](get-set-up-for-amazon-ecs.md). + Votre utilisateur dispose des autorisations IAM nécessaires pour créer les ressources Secrets Manager et Amazon ECS. ## Étape 1 : Créer un secret Secrets Manager Vous pouvez utiliser la console Secrets Manager afin de créer un secret pour vos données sensibles. Dans ce didacticiel, nous allons créer un secret de base pour stocker un nom d'utilisateur et un mot de passe à référencer ultérieurement dans un conteneur. Pour plus d'informations, voir [Création d'un AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) dans le *guide de AWS Secrets Manager l'utilisateur*. Les ** key/value paires à stocker dans ce secret** sont la valeur de la variable d'environnement dans votre conteneur à la fin du didacticiel. Enregistrez l'**ARN secret** pour le référencer dans votre politique IAM d'exécution de tâche et dans la définition de tâche lors des étapes ultérieures. ## Étape 2 : ajouter des autorisations secrètes au rôle d’exécution de tâche Pour qu’Amazon ECS puisse récupérer les données sensibles à partir de votre secret Secrets Manager, vous devez disposer des autorisations de secrets pour le rôle d’exécution des tâches. Pour de plus amples informations, veuillez consulter [Autorisations Secrets Manager ou Systems Manager](task_execution_IAM_role.md#task-execution-secrets). ## Étape 3 : Créer une définition de tâche Vous pouvez utiliser la console Amazon ECS pour créer une définition de tâche qui fait référence à un secret Secrets Manager. **Pour créer une définition de tâche qui spécifie un secret** Utilisez la console IAM pour mettre à jour votre rôle d'exécution de tâche avec les autorisations requises. 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans le panneau de navigation, choisissez **Task definitions** (Définition des tâches). 1. Choisissez **Create new task definition** (Créer une nouvelle définition de tâche), puis **Create new task definition with JSON** (Créer une nouvelle définition de tâche avec JSON). 1. Dans la zone de l’éditeur JSON, saisissez le texte JSON de définition de tâche suivant, en veillant à spécifier l’ARN complet du secret Secrets Manager que vous avez créée à l’étape 1 et le rôle d’exécution de tâche que vous avez mis à jour à l’étape 2. Choisissez **Enregistrer**. 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. Choisissez **Créer**. ## Étape 4 : créer un cluster Vous pouvez utiliser la console Amazon ECS pour créer un cluster contenant une instance de conteneur pour exécuter la tâche. Si vous avez un cluster existant avec au moins une instance de conteneur enregistrée avec les ressources disponibles pour exécuter une instance de la définition de tâche créée pour ce didacticiel, vous pouvez passer à l'étape suivante. Pour ce didacticiel, nous allons créer un cluster avec une instance de conteneur `t2.micro` à l'aide de l'AMI Amazon Linux 2 optimisée pour Amazon ECS. Pour plus d’informations sur la création d’un cluster pour EC2, consultez la section [Création d’un cluster Amazon ECS pour les charges de travail Amazon EC2](create-ec2-cluster-console-v2.md). ## Étape 5 : exécuter une tâche Vous pouvez utiliser la console Amazon ECS pour exécuter une tâche avec la définition de tâche que vous avez créée. Dans le cadre de ce didacticiel, nous allons exécuter une tâche utilisant EC2, à l’aide du cluster que nous avons créé lors de l’étape précédente. Pour plus d'informations sur l'exécution d’une tâche, consultez [Exécution d’une application en tant que tâche Amazon ECS](standalone-task-create.md). ## Étape 6 : Vérification Vous pouvez vérifier que toutes les étapes ont été effectuées avec succès et que la variable d'environnement a été créée correctement dans votre conteneur en suivant les étapes ci-dessous. **Vérifier que la variable d'environnement a été créée** 1. Trouvez l'adresse IP publique ou DNS pour votre instance de conteneur. 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans le volet de navigation, choisissez **Clusters**, puis choisissez le cluster que vous avez créé. 1. Choisissez **Infrastructure**, puis choisissez l'instance de conteneur. 1. Enregistrez l'adresse **Public IP** (IP publique) ou **Public DNS** (DNS public) de votre instance. 1. Si vous utilisez un ordinateur MacOS ou Linux, connectez-vous à votre instance avec la commande suivante, en indiquant le chemin d'accès de votre clé privée et l'adresse publique de votre instance : ``` $ ssh -i /path/to/my-key-pair.pem ec2-user@ec2-198-51-100-1.compute-1.amazonaws.com ``` Pour plus d’informations sur l’utilisation d’un ordinateur Windows, consultez la section [Se connecter à votre instance Linux à l’aide de PuTTY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-from-windows.html) dans le *Guide de l’utilisateur Amazon EC2*. **Important** Pour plus d’informations sur les problèmes que vous pouvez rencontrer lors de la connexion à votre instance, consultez la section [Résolution des problèmes de connexion à votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html) dans le *Guide de l’utilisateur Amazon EC2*. 1. Répertoriez les conteneurs en cours d'exécution sur l'instance. Notez l'ID de conteneur pour le conteneur `ecs-secrets-tutorial`. ``` docker ps ``` 1. Connectez-vous au conteneur `ecs-secrets-tutorial` à l'aide de l'ID conteneur à partir du résultat de l'étape précédente. ``` docker exec -it container_ID /bin/bash ``` 1. Utilisez la commande `echo` pour imprimer la valeur de la variable d'environnement. ``` echo $username_value ``` Si le didacticiel s'est correctement déroulé, vous devriez voir le résultat suivant : ``` password_value ``` **Note** Sinon, vous pouvez répertorier toutes les variables d'environnement dans votre conteneur à l'aide de la commande `env` (ou `printenv`). ## Étape 7 : nettoyer Une fois que vous avez terminé ce didacticiel, vous devez nettoyer les ressources qui lui sont associées afin d'éviter la facturation de frais pour des ressources inutilisées. **Nettoyer les ressources.** 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans le panneau de navigation, choisissez **Clusters**. 1. Sur la page **Clusters**, choisissez le cluster. 1. Choisissez **Delete Cluster** (Supprimer le cluster). 1. Dans la zone de confirmation, saisissez **Supprimer *cluster name***, puis choisissez **Supprimer**. 1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Dans le panneau de navigation, choisissez **Rôles**. 1. Recherchez `ecsTaskExecutionRole` dans la liste des rôles et sélectionnez-le. 1. Choisissez **Autorisations**, puis le **X** à côté de **ECSSecretsTutoriel**. Cliquez sur **Supprimer**. 1. Ouvrez la console Secrets Manager à l'adresse [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/). 1. Sélectionnez le secret **username\$1value** que vous avez créé, puis choisissez **Actions**, **Delete secret** (Supprimer le secret). # Paramètres de définition de tâche Amazon ECS pour les instances gérées Amazon ECS Les définitions de tâches sont divisées en plusieurs parties : la famille de tâches, le rôle de tâche Gestion des identités et des accès AWS (IAM), le mode réseau, les définitions des conteneurs, les volumes et la capacité. Les définitions de famille et de conteneur sont requises dans une définition de tâche. En revanche, le rôle de tâche, le mode réseau, les volumes et la capacité sont facultatifs. Vous pouvez utiliser ces paramètres dans un fichier JSON pour configurer votre définition de tâche. Vous trouverez ci-dessous une description plus détaillée de chaque paramètre de définition de tâche pour les instances gérées Amazon ECS. ## Family `family` Type : Chaîne Obligatoire : oui Lorsque vous enregistrez une définition de tâche, vous lui attribuez une famille. Cela équivaut, pour plusieurs versions de définition de tâche, à lui attribuer un nom spécifié avec un numéro de révision. La première définition de tâche enregistrée dans une famille donnée reçoit le numéro de révision 1. Toute définition de tâche enregistrée après celle-ci reçoit un numéro de révision ultérieur dans l'ordre séquentiel. ## Capacity Lorsque vous enregistrez une définition de tâche, vous pouvez spécifier la capacité par rapport à laquelle Amazon ECS doit valider la définition de tâche. Une exception client est renvoyée si la définition de tâche n'est pas conforme aux compatibilités spécifiées. Pour plus d’informations, consultez la section [Types de lancement Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/launch_types.html). Le paramètre suivant est autorisé dans une définition de tâche. `requiresCompatibilities` Type : tableau de chaînes Obligatoire : non Valeurs valides : `MANAGED_INSTANCES` La capacité par rapport à laquelle valider la définition de tâche. Une vérification est alors lancée afin de s’assurer que tous les paramètres utilisés dans la définition de tâche répondent aux exigences des instances gérées Amazon ECS. ## Rôle de tâche `taskRoleArn` Type : chaîne Obligatoire : non Lorsque vous enregistrez une définition de tâche, vous pouvez attribuer un rôle de tâche à un rôle IAM qui permet aux conteneurs concernés par l'autorisation de tâche d'appeler AWS APIs les conteneurs spécifiés dans les politiques associées en votre nom. Pour de plus amples informations, veuillez consulter [rôle IAM de tâche Amazon ECS](task-iam-roles.md). ## Rôle d'exécution de tâche `executionRoleArn` Type : Chaîne Obligatoire : Conditionnelle Le nom de ressource Amazon (ARN) du rôle d'exécution des tâches qui autorise l'agent de conteneur Amazon ECS à effectuer des appels d' AWS API en votre nom. Pour de plus amples informations, veuillez consulter [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md). Le rôle IAM d'exécution de la tâche est requis en fonction des besoins de votre tâche. Le rôle est requis pour les extractions d'images ECR privées et pour l'utilisation du pilote de `awslogs` journal. ## Mode réseau `networkMode` Type : chaîne Obligatoire : non Valeur par défaut : `awsvpc` Mode réseau à utiliser pour les conteneurs de la tâche. Pour les tâches Amazon ECS hébergées sur des instances gérées Amazon ECS, les valeurs valides sont `awsvpc` et `host`. Si aucun mode réseau n’est spécifié, le mode réseau par défaut est `awsvpc`. Si le mode réseau est activé`host`, la tâche contourne l'isolation du réseau et les conteneurs utilisent directement la pile réseau de l'hôte. Lorsque vous exécutez des tâches en mode réseau `host`, vous n'exécutez pas de conteneurs à l'aide de l'utilisateur root (UID 0) pour une meilleure sécurité. Comme bonne pratique de sécurité, utilisez toujours un utilisateur non root. Si le mode réseau est `awsvpc`, une interface réseau Elastic est attribuée à la tâche, et vous devez spécifier une configuration `NetworkConfiguration` lorsque vous créez un service ou exécutez une tâche avec la définition de tâche. Pour de plus amples informations, veuillez consulter [Mise en réseau des tâches Amazon ECS pour les instances gérées Amazon ECS](managed-instance-networking.md). Les modes réseau `host` et `awsvpc` offrent les meilleures performances de mise en réseau pour les conteneurs, car ils utilisent la pile de réseau Amazon EC2. Avec les modes réseau `host` et `awsvpc`, les ports de conteneur exposés sont mappés directement au port hôte correspondant (pour le mode réseau hôte `host`) ou au port de l'interface réseau Elastic (pour le mode réseau `awsvpc`). Pour cette raison, vous ne pouvez pas utiliser de mappages de ports hôtes dynamiques. ## Plateforme d'exécution `operatingSystemFamily` Type : chaîne Obligatoire : non Par défaut : LINUX Lorsque vous enregistrez une définition de tâche, vous spécifiez la famille du système d'exploitation. La valeur valide pour ce champ est `LINUX`. Toutes les définitions de tâches qui sont utilisées dans un service doivent avoir la même valeur pour ce paramètre. Lorsqu'une définition de tâche fait partie d'un service, cette valeur doit correspondre à la valeur `platformFamily` du service. `cpuArchitecture` Type : Chaîne Obligatoire : Conditionnelle Lorsque vous enregistrez une définition de tâche, vous spécifiez l'architecture du processeur. Les valeurs valides sont `X86_64` et `ARM64`. Si vous ne spécifiez aucune valeur, Amazon ECS tente de placer les tâches sur l'architecture de processeur disponible en fonction de la configuration du fournisseur de capacité. Pour garantir que les tâches sont placées sur une architecture de processeur spécifique, spécifiez une valeur pour `cpuArchitecture` dans la définition des tâches. Toutes les définitions de tâches qui sont utilisées dans un service doivent avoir la même valeur pour ce paramètre. Pour plus d’informations sur `ARM64`, consultez [Définitions de tâche Amazon ECS pour les charges de travail ARM 64 bits](ecs-arm64.md). ## Taille de la tâche Lorsque vous enregistrez une définition de tâche, vous pouvez spécifier la quantité totale d'UC et de mémoire utilisée pour cette tâche. Ces valeurs sont distinctes des valeurs `cpu` et `memory` au niveau de la définition de conteneur. Pour les tâches hébergées sur des instances Amazon EC2, ces champs sont facultatifs. **Note** Les paramètres d'UC et de mémoire de niveau tâche sont ignorés pour les conteneurs Windows. Nous vous recommandons de spécifier des ressources de niveau conteneur pour les conteneurs Windows. `cpu` Type : Chaîne Obligatoire : Conditionnelle Limite stricte du nombre d'unités UC à présenter pour la tâche. Vous pouvez spécifier les valeurs du processeur dans le fichier JSON sous forme de chaîne en unités de processeur ou en mode virtuel CPUs (vCPUs). Par exemple, vous pouvez spécifier une valeur de processeur soit `1024` en unités de processeur, soit `1 vCPU` en CPUs v. Lorsque la définition de tâche est enregistrée, une valeur vCPU est convertie en un entier indiquant les unités du processeur. Ce champ est facultatif. Si votre cluster n'a pas d'instances de conteneur enregistrées avec les unités UC demandées disponibles, la tâche échoue. Les valeurs prises en charge sont comprises entre `0.125` `10` v CPUs et CPUs v. `memory` Type : Chaîne Obligatoire : Conditionnelle Limite stricte de quantité de mémoire à allouer à la tâche. Vous pouvez spécifier les valeurs de mémoire dans la définition de la tâche sous forme de chaîne en mébioctets (Mio) ou en gigaoctets (Go). Par exemple, vous pouvez spécifier une valeur de mémoire de `3072` en Mio ou de `3 GB` en Go. Lorsque la définition de tâche est enregistrée, la valeur en Go est convertie en un nombre entier indiquant la quantité de Mio. Ce champ est facultatif et n'importe quelle valeur peut être utilisée. Si une valeur de mémoire au niveau de la tâche est spécifiée, la valeur de mémoire au niveau du conteneur est facultative. Si votre cluster n'a pas d'instances de conteneur enregistrées avec la mémoire demandée disponible, la tâche échoue. Vous pouvez optimiser l'utilisation de vos ressources en fournissant à vos tâches autant de mémoire que possible pour un type d'instance particulier. Pour de plus amples informations, veuillez consulter [Réservation de mémoire pour une instance de conteneur Amazon ECS Linux](memory-management.md). ## Autres paramètres de définition de tâche Les paramètres de définition de tâche suivants peuvent être utilisés lors de l'enregistrement des définitions de tâches dans la console Amazon ECS à l'aide de l'option **Configure via JSON** (Configurer via JSON). Pour de plus amples informations, veuillez consulter [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md). **Topics** + [ ### Stockage éphémère ](#task_definition_ephemeralStorage-managed-instances) + [ ### Mode IPC ](#task_definition_ipcmode-managed-instances) + [ ### Mode PID ](#task_definition_pidmode-managed-instances) + [ ### Configuration du proxy ](#proxyConfiguration-managed-instances) + [ ### Étiquettes ](#tags-managed-instances) + [ ### Accélérateur Elastic Inference (obsolète) ](#elastic-Inference-accelerator-managed-instances) + [ ### Contraintes de placement ](#constraints-managed-instances) + [ ### Volumes ](#volumes-managed-instances) ### Stockage éphémère `ephemeralStorage` Ce paramètre n’est pas pris en charge pour les tâches exécutées sur les instances gérées Amazon ECS. Type : objet [EphemeralStorage](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EphemeralStorage.html) Obligatoire : non Quantité de stockage éphémère (en Go) à allouer pour la tâche. Ce paramètre est utilisé pour étendre la quantité totale de stockage éphémère disponible, au-delà de la quantité par défaut, pour les tâches hébergées sur AWS Fargate. Pour de plus amples informations, veuillez consulter [Utilisation de montages liés avec Amazon ECS](bind-mounts.md). ### Mode IPC `ipcMode` Ce paramètre n’est pas pris en charge pour les tâches exécutées sur les instances gérées Amazon ECS. Type : chaîne Obligatoire : non Espace de noms de ressource IPC à utiliser pour les conteneurs de la tâche. Les valeurs valides sont `host`, `task` ou `none`. Si `host` est spécifié, tous les conteneurs des tâches ayant spécifié le mode IPC `host` sur la même instance de conteneur partagent les mêmes ressources IPC avec l'instance Amazon EC2 hôte. Si `task` est spécifié, tous les conteneurs de la tâche spécifiée partagent les mêmes ressources IPC. Si `none` est spécifié, les ressources IPC des conteneurs d'une tâche sont privés et ne partagent rien avec les autres conteneurs d'une tâche ou d'une instance de conteneur. Si aucune valeur n'est spécifiée, le partage de l'espace de noms des ressources IPC dépend de la configuration d'exécution du conteneur. ### Mode PID `pidMode` Type : chaîne Obligatoire : non Espace de noms de processus à utiliser pour les conteneurs de la tâche. Les valeurs valides sont `host` ou `task`. Si `host` est spécifié, tous les conteneurs qui se trouvent dans les tâches ayant spécifié le mode PID `host` sur la même instance de conteneur partagent le même espace de noms de processus avec l’instance Amazon EC2 hôte. Si `task` est spécifié, tous les conteneurs qui se trouvent dans la tâche spécifiée partagent le même espace de noms de processus. Si aucune valeur n'est spécifiée, la valeur par défaut est un espace de noms privé. Si le mode PID `host` est utilisé, il existe un risque accru d'exposition à un espace de noms de processus indésirable. ### Configuration du proxy `proxyConfiguration` Ce paramètre n’est pas pris en charge pour les tâches exécutées sur les instances gérées Amazon ECS. Type : objet [ProxyConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ProxyConfiguration.html) Obligatoire : non Détails de configuration pour le proxy App Mesh. ### Étiquettes Métadonnées que vous appliquez à une définition de tâche pour faciliter le classement et l’organisation. Chaque balise est constituée d’une clé et d’une valeur facultative. Vous définissez ces deux éléments. Les restrictions de base suivantes s’appliquent aux balises : + Nombre maximal de balises par ressource - 50 + Pour chaque ressource, chaque clé d'identification doit être unique, et chaque clé d'identification peut avoir une seule valeur. + Longueur de clé maximale - 128 caractères Unicode en UTF-8 + Longueur de valeur maximale - 256 caractères Unicode en UTF-8 + Si votre schéma d'identification est utilisé pour plusieurs services et ressources, n'oubliez pas que d'autres services peuvent avoir des restrictions concernant les caractères autorisés. Les caractères généralement autorisés sont les lettres, les chiffres et les espaces représentables en UTF-8, ainsi que les caractères suivants : \$1 - =. \$1 :/@. + Les clés et valeurs d'étiquette sont sensibles à la casse. + N'utilisez pas `aws:``AWS:`, ni aucune combinaison majuscules ou minuscules, comme un préfixe pour les clés ou les valeurs, car il est réservé à l'usage. AWS Vous ne pouvez pas modifier ni supprimer des clés ou valeurs d'étiquette ayant ce préfixe. Les étiquettes avec ce préfixe ne sont pas comptabilisées comme vos étiquettes pour la limite de ressources. `key` Type : chaîne Obligatoire : non Partie d'une paire clé-valeur qui constitue une étiquette. Une clé est une étiquette générale qui fait office de catégorie pour les valeurs d'étiquette plus spécifiques. `value` Type : chaîne Obligatoire : non Partie facultative d'une paire clé-valeur qui constitue une étiquette. Une valeur agit comme un descripteur au sein d'une catégorie d'étiquette (clé). ### Accélérateur Elastic Inference (obsolète) **Note** Amazon Elastic Inference (EI) n’est plus disponible pour les clients. `inferenceAccelerator` Ce paramètre n’est pas pris en charge pour les tâches exécutées sur les instances gérées Amazon ECS. Type : objet [InferenceAccelerator](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_InferenceAccelerator.html) Obligatoire : non Accélérateurs d'inférence élastique à utiliser pour les conteneurs de la tâche. ### Contraintes de placement `placementConstraints` Type : tableau d’objets [TaskDefinitionPlacementConstraint](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_TaskDefinitionPlacementConstraint.html) Obligatoire : non Un tableau d'objets de contraintes de placement à utiliser pour la tâche. Vous pouvez spécifier 10 contraintes maximum par tâche (cette limite comprend les contraintes de la définition de tâche et celles spécifiées lors de l'exécution). Amazon ECS prend en charge les contraintes de placement `distinctInstace` et `memberOf` pour les tâches exécutées sur les instances gérées Amazon ECS. Les attributs suivants sont pris en charge pour les tâches qui utilisent la contrainte de placement `memberOf` : + `ecs.subnet-id` + `ecs.availability-zone` + `ecs.cpu-architecture` + `ecs.instance-type` Pour plus d’informations sur les contraintes de placement, consultez la section [Définition des instances de conteneur utilisées par Amazon ECS pour les tâches](task-placement-constraints.md). ### Volumes Lorsque vous enregistrez une définition de tâche, vous pouvez éventuellement spécifier une liste de volumes pour vos tâches. Cela vous permet d’utiliser des volumes de données dans vos tâches. Pour de plus amples informations sur les types de volume et d’autres paramètres, consultez la section [Options de stockage pour les tâches Amazon ECS](using_data_volumes.md). `name` Type : Chaîne Obligatoire : oui Le nom du volume. Il peut comporter jusqu'à 255 lettres (majuscules et minuscules), des chiffres et des tirets. Ce nom est référencé dans le `sourceVolume` paramètre de définition de conteneur `mountPoints`. `host` Type : objet [HostVolumeProperties](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_HostVolumeProperties.html) Obligatoire : non Ce paramètre est spécifié lorsque vous utilisez des volumes hôtes de montage lié. Le contenu du paramètre `host` détermine si votre volume hôte de montage lié persiste sur l'instance de conteneur hôte et où il est stocké. Si le `host` paramètre est vide, le système attribue un chemin d'hôte à votre volume de données. Toutefois, il n'est pas garanti que les données perdureront après l'arrêt de l'exécution des conteneurs associés. `sourcePath` Type : chaîne Obligatoire : non Lorsque le `host` paramètre est utilisé, spécifiez a `sourcePath` pour déclarer le chemin sur l'instance hôte présentée au conteneur. Si ce paramètre est vide, le système vous assigne un chemin d'hôte. Si le `host` paramètre contient un emplacement de `sourcePath` fichier, le volume de données reste à l'emplacement spécifié sur l'instance hôte jusqu'à ce que vous le supprimiez manuellement. Si la `sourcePath` valeur n'existe pas sur l'instance hôte, le système la crée. Si l'emplacement n'existe pas, le contenu du chemin source est exporté. Sur les instances gérées Amazon ECS, certaines parties du système de fichiers hôte sont en lecture seule. Le `sourcePath` doit pointer vers un répertoire accessible en écriture tel que `/var` ou`/tmp`. Pour de plus amples informations, veuillez consulter [Utilisation de montages liés avec Amazon ECS](bind-mounts.md). `dockerVolumeConfiguration` Ce paramètre n’est pas pris en charge pour les tâches exécutées sur les instances gérées Amazon ECS. Type : objet [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html) Obligatoire : non Ce paramètre est spécifié lorsque vous utilisez des volumes Docker. `efsVolumeConfiguration` Type : objet [EFSVolumede configuration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSVolumeConfiguration.html) Obligatoire : non Ce paramètre est spécifié lorsque vous utilisez un système de fichiers Amazon EFS pour le stockage des tâches. `fsxWindowsFileServerVolumeConfiguration` Ce paramètre n’est pas pris en charge pour les tâches exécutées sur les instances gérées Amazon ECS. Type : objet [FSxWindowsFileServerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FSxWindowsFileServerVolumeConfiguration.html) Obligatoire : non Ce paramètre est spécifié lorsque vous utilisez le système de fichiers Amazon FSx pour Windows File Server pour le stockage des tâches. `configuredAtLaunch` Type : booléen Obligatoire : non Indique si le volume doit être configuré lors du lancement. Cette méthode est utilisée pour créer des volumes Amazon EBS pour des tâches autonomes ou des tâches créées dans le cadre d’un service. Chaque révision de définition de tâche ne peut comporter qu’un seul volume configuré lors du lancement dans la configuration du volume. ## Définitions de conteneur Lorsque vous enregistrez une définition de tâche, vous devez spécifier une liste de définitions de conteneur qui sont transmises au démon Docker sur une instance de conteneur. Les paramètres suivants sont autorisés dans une définition de conteneur. **Topics** + [ ### Nom ](#container_definition_name-managed-instances) + [ ### Image ](#container_definition_image-managed-instances) + [ ### Mémoire ](#container_definition_memory-managed-instances) + [ ### CPU ](#container_definition_cpu-managed-instances) + [ ### Mappages de ports ](#container_definition_portmappings-managed-instances) + [ ### Informations d'identification du référentiel privé ](#container_definition_repositoryCredentials-managed-instances) + [ ### Essential ](#container_definition_essential-managed-instances) + [ ### Point d'entrée ](#container_definition_entrypoint-managed-instances) + [ ### Commande ](#container_definition_command-managed-instances) + [ ### Répertoire de travail ](#container_definition_workingdirectory-managed-instances) + [ ### Paramètres de définition de conteneur avancés ](#advanced_container_definition_params-managed-instances) + [ ### Paramètres Linux ](#container_definition_linuxparameters-managed-instances) ### Nom `name` Type : Chaîne Obligatoire : oui Le nom d'un conteneur. Jusqu'à 255 lettres (majuscules et minuscules), chiffres, traits d'union et traits de soulignement sont autorisés. Si vous associez plusieurs conteneurs dans une définition de tâche, vous pouvez spécifier l'option `name` d'un conteneur dans l'option `links` d'un autre conteneur. Cela permet de connecter les conteneurs. ### Image `image` Type : Chaîne Obligatoire : oui Image utilisée pour démarrer un conteneur. Cette chaîne est transmise directement au démon Docker. Par défaut, les images dans le registre Docker Hub sont disponibles. Vous pouvez également spécifier d'autres référentiels avec soit `repository-url/image:tag`, soit `repository-url/image@digest`. Il peut comporter jusqu'à 255 lettres (majuscules et minuscules), des chiffres, des tirets, des traits de soulignement, deux points, des points, des barres obliques et des signes dièse. Ce paramètre correspond à `Image` dans la commande docker create-container et au paramètre `IMAGE` de la commande docker run. + Lorsqu'une nouvelle tâche démarre, l'agent de conteneur Amazon ECS extrait la version la plus récente de l'image et de l'étiquette spécifiées afin que le conteneur puisse les utiliser. Notez cependant que les mises à jour ultérieures apportées à une image de référentiel ne sont pas répercutées sur les tâches déjà en cours d'exécution. + Lorsque vous ne spécifiez pas de balise ou de résumé dans le chemin de l'image dans la définition de tâche, l'agent de conteneur Amazon ECS utilise la `latest` balise pour extraire l'image spécifiée. + Les mises à jour ultérieures d'une image de référentiel ne sont pas répercutées sur les tâches déjà en cours d'exécution. + Les images des registres privés sont prises en charge. Pour de plus amples informations, veuillez consulter [Utilisation d'images autres que des AWS conteneurs dans Amazon ECS](private-auth.md). + Les images des référentiels Amazon ECR peuvent être spécifiées en utilisant soit la convention de dénomination complète `registry/repository:tag` ou `registry/repository@digest` (par exemple, `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app:latest` ou `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE`). + Les images dans les référentiels officiels sur Docker Hub utilisent un nom unique (par exemple, `ubuntu` ou `mongo`). + Les images dans les autres référentiels sur Docker Hub sont qualifiées par un nom d'organisation (par exemple, `amazon/amazon-ecs-agent`). + Les images dans les autres référentiels en ligne sont qualifiées par un nom de domaine (par exemple, `quay.io/assemblyline/ubuntu`). `versionConsistency` Type : Chaîne Valeurs valides : `enabled`\$1`disabled` Obligatoire : non Spécifie si Amazon ECS résoudra la balise d’image de conteneur fournie dans la définition du conteneur en un condensé d’image. Par défaut, ce comportement est `enabled`. Si vous définissez la valeur d’un conteneur sur `disabled`, Amazon ECS ne résoudra pas la balise d’image de conteneur en un condensé et utilisera l’URI d’image d’origine spécifiée dans la définition du conteneur pour le déploiement. Pour plus d’informations sur la résolution des images de conteneur, consultez la section [Résolution des images de conteneurs](deployment-type-ecs.md#deployment-container-image-stability). ### Mémoire `memory` Type : Integer Obligatoire : non La quantité de mémoire (en Mio) à présenter au conteneur. Si votre conteneur tente de dépasser la mémoire spécifiée ici, il sera désactivé. La quantité totale de mémoire réservée pour tous les conteneurs au sein d'une tâche doit être inférieure à la valeur `memory` de la tâche, si cette valeur est spécifiée. Ce paramètre correspond à `Memory` dans la commande docker create-container et à l’option `--memory` dans la commande docker run. Le démon Docker 20.10.0 ou ultérieur réserve un minimum de 6 Mio de mémoire pour un conteneur. Par conséquent, ne spécifiez pas moins de 6 Mio de mémoire pour vos conteneurs. Le démon Docker 19.03.13-ce ou antérieur réserve un minimum de 4 Mio de mémoire pour un conteneur. Par conséquent, ne spécifiez pas moins de 4 Mio de mémoire pour vos conteneurs. Si vous essayez d'optimiser l'utilisation de vos ressources en fournissant à vos tâches autant de mémoire que possible pour un type d'instance particulier, consultez [Réservation de mémoire pour une instance de conteneur Amazon ECS Linux](memory-management.md). `memoryReservation` Type : Integer Obligatoire : non La limite flexible (en Mio) de mémoire à réserver pour le conteneur. En cas de contention de la mémoire système, Docker tente de garder la mémoire du conteneur en deçà de cette limite flexible. Toutefois, votre conteneur peut utiliser davantage de mémoire en cas de besoin. Le conteneur peut consommer jusqu'à la limite stricte spécifiée avec le paramètre `memory` (le cas échéant), ou la totalité de la mémoire disponible sur l'instance de conteneur, selon la première valeur atteinte. Ce paramètre correspond à `MemoryReservation` dans la commande docker create-container et à l’option `--memory-reservation` dans la commande docker run. Si aucune valeur de mémoire au niveau de la tâche n'est spécifiée, vous devez indiquer un nombre entier différent de zéro pour `memory` ou `memoryReservation` dans une définition de conteneur. Si vous spécifiez les deux, `memory` doit être supérieur à `memoryReservation`. Si vous spécifiez `memoryReservation`, cette valeur est soustraite des ressources mémoire disponibles pour l'instance de conteneur sur laquelle le conteneur est placé. Sinon, c'est la valeur `memory` qui est utilisée. Par exemple, supposons que votre conteneur utilise normalement 128 Mio de mémoire, mais qu'il lui arrive d'utiliser jusqu'à 256 Mio de mémoire pendant de courtes périodes. Vous pouvez définir une `memoryReservation` de 128 Mio et une limite stricte `memory` de 300 Mio. Cette configuration permet au conteneur de ne réserver que 128 Mio de mémoire à partir des ressources restantes sur l'instance de conteneur. En même temps, cette configuration permet également au conteneur d'utiliser davantage de ressources mémoire lorsque cela est nécessaire. Le démon Docker 20.10.0 ou ultérieur réserve un minimum de 6 Mio de mémoire pour un conteneur. Par conséquent, ne spécifiez pas moins de 6 Mio de mémoire pour vos conteneurs. Le démon Docker 19.03.13-ce ou antérieur réserve un minimum de 4 Mio de mémoire pour un conteneur. Par conséquent, ne spécifiez pas moins de 4 Mio de mémoire pour vos conteneurs. Si vous essayez d'optimiser l'utilisation de vos ressources en fournissant à vos tâches autant de mémoire que possible pour un type d'instance particulier, consultez [Réservation de mémoire pour une instance de conteneur Amazon ECS Linux](memory-management.md). ### CPU `cpu` Type : Integer Obligatoire : non Le nombre d'unités `cpu` réservées pour le conteneur. Ce paramètre correspond à `CpuShares` dans la commande docker create-container et à l’option `--cpu-shares` dans la commande docker run. Ce champ est facultatif pour les tâches utilisant des fournisseurs de capacité EC2. La seule exigence est que la quantité totale d’UC réservée pour tous les conteneurs d’une tâche soit inférieure à la valeur `cpu` au niveau de la tâche. Vous pouvez déterminer le nombre d'unités de processeur disponibles par type d'instance EC2 en multipliant le v CPUs répertorié pour ce type d'instance sur la page détaillée des instances [Amazon EC2](https://aws.amazon.com/ec2/instance-types/) par 1 024. Les conteneurs Linux partagent des unités d'UC non allouées avec les autres conteneurs de l'instance de contenu selon le même ratio que la quantité allouée. Par exemple, si vous exécutez une tâche à un seul conteneur sur un type d’instance à un seul cœur avec 512 unités d’UC spécifiées pour ce conteneur, et que c’est la seule tâche en cours d’exécution sur l’instance de conteneur, ce conteneur pourrait utiliser la totalité de la totalité des 1 024 unités d’UC à tout moment. Toutefois, si vous avez lancé une autre copie de la même tâche sur cette instance de conteneur, chaque tâche se voit garantir un minimum de 512 unités de processeur si nécessaire. De plus, chaque conteneur pourrait bénéficier d'une utilisation plus importante du processeur si l'autre conteneur ne l'utilisait pas. Toutefois, si les deux tâches étaient actives à 100 % en permanence, elles seraient limitées à 512 unités de processeur. Sur les instances de conteneur Linux, le démon Docker de l'instance de conteneur se sert de la valeur d'UC pour calculer les ratios de partage d'UC relatifs pour les conteneurs en cours d'exécution. Pour plus d'informations, consultez la section [CPU share constraint](https://docs.docker.com/engine/reference/run/#cpu-share-constraint) dans la documentation Docker. La valeur de parts d'UC minimale autorisée par le noyau Linux est de 2. Toutefois, le paramètre de processeur n'est pas obligatoire et vous pouvez utiliser des valeurs de processeur inférieures à 2 dans vos définitions de conteneur. Pour les valeurs d'UC inférieures à 2 (y compris null), le comportement varie selon la version de l'agent de conteneur Amazon ECS : + **Versions d'agent inférieures ou égales à 1.1.0 :** Les valeurs d'UC null et égales à zéro sont transmises à Docker en tant que 0, ce que Docker convertit ensuite en 1024 parts d'UC. Les valeurs d'UC de 1 sont transmises à Docker en tant que 1, ce que le noyau Linux convertit en deux parts d'UC. + **Versions d'agent supérieures ou égales à 1.2.0 :** Les valeurs d'UC null, et égales à zéro et à 1 sont transmises à Docker en tant que 2. Sur les instances de conteneur Windows, la limite d'UC est appliquée comme limite absolue ou quota. Les conteneurs Windows n'ont accès qu'à la quantité spécifiée de processeur décrite dans la définition de tâche. Une valeur d'UC null ou nulle est transmise à Docker comme `0`, que Windows interprète comme 1 % d'un processeur. ### Mappages de ports `portMappings` Type : tableau d'objets Obligatoire : non Les mappages de ports exposent les ports réseau de votre conteneur au monde extérieur, ce qui permet aux clients d’accéder à votre application. Ils sont également utilisés pour la communication entre conteneurs au sein d’une même tâche. Pour les définitions de tâche qui utilisent le mode réseau `awsvpc`, spécifiez uniquement `containerPort`. Le `hostPort` est toujours ignoré et le port du conteneur est automatiquement mappé à un port aléatoire portant un numéro élevé sur l’hôte. La plupart des champs de ce paramètre (y compris `containerPort`, `hostPort`, `protocol`) correspondent à `PortBindings` dans la commande docker create-container et à l’option `--publish` de docker run. Si le mode réseau d'une définition de tâche est défini sur `host`, les ports hôtes doivent être indéfinis ou correspondre au port du conteneur dans le mappage de port. Une fois qu'une tâche passe à l'état `RUNNING`, les affectations manuelles et automatiques de ports de conteneur et d'hôte sont visibles aux emplacements suivants : + Console : la section **Network Bindings** (Liaisons réseau) de la description d'un conteneur pour une tâche sélectionnée. + AWS CLI : la section `networkBindings` de la sortie de la commande **describe-tasks**. + API : la réponse `DescribeTasks`. + Métadonnées : point de terminaison des métadonnées de la tâche. `appProtocol` Type : chaîne Obligatoire : non Protocole d'application utilisé pour le mappage de port. Ce paramètre s'applique uniquement à Service Connect. Nous vous conseillons de définir ce paramètre de manière cohérente avec le protocole que votre application utilise. Si vous définissez ce paramètre, Amazon ECS ajoute une gestion de connexion spécifique au protocole au proxy Service Connect. Si vous définissez ce paramètre, Amazon ECS ajoute une télémétrie spécifique au protocole dans la console Amazon ECS et. CloudWatch Si vous ne définissez aucune valeur pour ce paramètre, le protocole TCP est utilisé. Toutefois, Amazon ECS n'ajoute pas de télémétrie spécifique au protocole pour TCP. Pour de plus amples informations, veuillez consulter [Utilisation de Service Connect pour connecter des services Amazon ECS avec des noms abrégés](service-connect.md). Valeurs de protocole valides : `"HTTP" | "HTTP2" | "GRPC" ` `containerPort` Type : Integer Obligatoire : oui, lorsque des objets `portMappings` sont utilisés Le numéro de port sur le conteneur qui est lié au port hôte spécifié par l'utilisateur ou affecté automatiquement. Pour les tâches utilisant le mode réseau `awsvpc`, vous utilisez `containerPort` pour spécifier les ports exposés. `containerPortRange` Type : chaîne Obligatoire : non Plage de numéros de port du conteneur liée à la plage de ports hôtes mappés dynamiquement. Vous ne pouvez définir ce paramètre qu'à l'aide de l'API `register-task-definition`. L'option est disponible dans le paramètre `portMappings`. Pour plus d'informations, consultez [register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html) dans la *référence AWS Command Line Interface *. Les règles suivantes s'appliquent lorsque vous spécifiez une `containerPortRange` : + Vous devez utiliser le mode réseau `awsvpc`. + L'instance de conteneur doit au moins disposer de la version 1.67.0 de l'agent de conteneur et au moins de la version 1.67.0-1 du package `ecs-init`. + Vous pouvez spécifier un maximum de 100 plages de ports pour chaque conteneur. + Vous ne spécifiez pas de `hostPortRange`. La valeur de `hostPortRange` est définie comme suit : + Pour les conteneurs d'une tâche en mode réseau `awsvpc`, le `hostPort` est défini sur la même valeur que le `containerPort`. Il s'agit d'une stratégie de mappage statique. + Les valeurs valides de `containerPortRange` sont comprises entre 1 et 65535. + Un port peut uniquement être inclus dans un mappage de port pour chaque conteneur. + Vous ne pouvez pas spécifier de plages de ports qui se chevauchent. + Le premier port de la plage doit être inférieur au dernier port de la plage. + Docker vous recommande de désactiver le proxy Docker dans le fichier de configuration du démon Docker en présence d'un grand nombre de ports. Pour plus d'informations, consultez le [numéro \$111185](https://github.com/moby/moby/issues/11185) sur GitHub. Pour plus d'informations sur la désactivation du proxy Docker dans le fichier de configuration du démon Docker, veuillez consulter [Démon Docker](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon) dans le *Guide du développeur Amazon ECS* (langue française non garantie). Vous pouvez appeler [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) pour voir la `hostPortRange` correspondant aux ports hôtes liés aux ports de conteneur. Les plages de ports ne sont pas incluses dans les événements de tâches Amazon ECS, qui sont envoyés à EventBridge. Pour de plus amples informations, veuillez consulter [Automatisez les réponses aux erreurs Amazon ECS à l'aide de EventBridge](cloudwatch_event_stream.md). `hostPortRange` Type : chaîne Obligatoire : non Plage de numéros de port sur l'hôte utilisée avec la liaison réseau. Elle est attribuée par Docker et délivrée par l'agent Amazon ECS. `hostPort` Type : Integer Obligatoire : non Le numéro de port sur l'instance de conteneur à réserver pour votre conteneur. Le `hostPort` peut rester vide ou avoir la même valeur que `containerPort`. La plage de ports éphémères par défaut pour Docker 1.6.0 et versions ultérieures est répertoriée dans l'instance sous `/proc/sys/net/ipv4/ip_local_port_range`. Si ce paramètre de noyau n'est pas disponible, la plage de ports éphémères par défaut de `49153–65535` est utilisée. N'essayez pas de spécifier un port d'hôte dans la plage de ports éphémères. Cela est dû au fait qu'ils sont réservés à une affectation automatique. En général, les ports inférieurs à `32768` ne sont pas compris dans la plage de ports éphémères. Les ports réservés par défaut sont le port `22` pour SSH, les ports Docker `2375` et `2376`, et les ports d'agent de conteneur Amazon ECS `51678-51680`. Tout port hôte ayant été spécifié précédemment par l'utilisateur pour une tâche en cours d'exécution est également réservé pendant l'exécution de la tâche. Après l'arrêt d'une tâche, le port hôte est libéré. Les ports réservés actuels s'affichent dans le champ `remainingResources` de la sortie **describe-container-instances**. Une instance de conteneur peut avoir jusqu'à 100 ports réservés à la fois, y compris les ports réservés par défaut. Les ports affectés automatiquement ne sont pas pris en compte dans le quota des 100 ports réservés. `name` Type : Chaîne Obligatoire : Non, requis pour que Service Connect et VPC Lattice soient configurés dans un service Nom utilisé pour le mappage de port. Ce paramètre ne s’applique qu’à Service Connect et VPC Lattice. Ce paramètre correspond au nom que vous utilisez dans la configuration Service Connect et VPC Lattice d’un service. Pour de plus amples informations, veuillez consulter [Utilisation de Service Connect pour connecter des services Amazon ECS avec des noms abrégés](service-connect.md). Dans l’exemple suivant, les deux champs obligatoires pour Service Connect et VPC Lattice sont utilisés. ``` "portMappings": [ { "name": string, "containerPort": integer } ] ``` `protocol` Type : chaîne Obligatoire : non Le protocole utilisé pour le mappage de port. Les valeurs valides sont `tcp` et `udp`. La valeur par défaut est `tcp`. Seul `tcp` est pris en charge pour Service Connect. N'oubliez pas que `tcp` est implicite si ce champ n'est pas défini. Si vous spécifiez un port hôte, utilisez la syntaxe suivante. ``` "portMappings": [ { "containerPort": integer, "hostPort": integer } ... ] ``` Si vous souhaitez utiliser un port hôte affecté automatiquement, utilisez la syntaxe suivante. ``` "portMappings": [ { "containerPort": integer } ... ] ``` ### Informations d'identification du référentiel privé `repositoryCredentials` Type : objet [RepositoryCredentials](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RepositoryCredentials.html) Obligatoire : non Informations d'identification du référentiel pour l'authentification de registre privé. Pour de plus amples informations, veuillez consulter [Utilisation d'images autres que des AWS conteneurs dans Amazon ECS](private-auth.md). `credentialsParameter` Type : Chaîne Obligatoire : oui, lorsque des objets `repositoryCredentials` sont utilisés L'Amazon Resource Name (ARN) du secret contenant les informations d'identification du référentiel privé. Pour de plus amples informations, veuillez consulter [Utilisation d'images autres que des AWS conteneurs dans Amazon ECS](private-auth.md). Lorsque vous utilisez l'API Amazon ECS AWS CLI AWS SDKs, ou si le secret existe dans la même région que la tâche que vous lancez, vous pouvez utiliser l'ARN complet ou le nom du secret. Lorsque vous utilisez le AWS Management Console, vous devez spécifier l'ARN complet du secret. Voici un extrait de code d'une définition de tâche indiquant les paramètres requis : ``` "containerDefinitions": [ { "image": "private-repo/private-image", "repositoryCredentials": { "credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name" } } ] ``` ### Essential `essential` Type : booléen Obligatoire : non Si le paramètre `essential` d'un conteneur a la valeur `true`, et que ce conteneur échoue ou s'arrête pour une raison quelconque, tous les autres conteneurs qui font partie de la tâche sont arrêtés. Si le paramètre `essential` d'un conteneur est marqué comme `false`, son échec n'a pas d'incidence sur le reste des conteneurs dans la tâche. Si ce paramètre n'est pas spécifié, le conteneur est supposé essentiel. Toutes les tâches doivent comporter au moins un conteneur essentiel. Si vous avez une application composée de plusieurs conteneurs, regroupez les conteneurs utilisés dans un même but et séparer les différents composants en plusieurs définitions de tâche. Pour de plus amples informations, veuillez consulter [Architecture de votre application pour Amazon ECS](application_architecture.md). ### Point d'entrée `entryPoint` Type : tableau de chaînes Obligatoire : non Point d'entrée qui est transmis au conteneur. Ce paramètre correspond à `Entrypoint` dans la commande docker create-container et à l’option `--entrypoint` dans la commande docker run. ``` "entryPoint": ["string", ...] ``` ### Commande `command` Type : tableau de chaînes Obligatoire : non La commande transmise au conteneur. Ce paramètre correspond à `Cmd` dans la commande docker create-container et au paramètre `COMMAND` dans docker run. S'il existe plusieurs arguments, chaque argument est une chaîne séparée dans le tableau. ``` "command": ["string", ...] ``` ### Répertoire de travail `workingDirectory` Type : chaîne Obligatoire : non Répertoire de travail dans lequel exécuter les commandes à l'intérieur du conteneur. Ce paramètre correspond à `WorkingDir` dans la commande docker create-container et à l’option `--workdir` dans la commande docker run. ### Paramètres de définition de conteneur avancés Les paramètres de définition de conteneur avancés suivants étendent les capacités de la commande docker run qui est utilisée pour lancer des conteneurs sur vos instances de conteneur Amazon ECS. **Topics** + [ #### Politique de redémarrage ](#container_definition_restart_policy-managed-instances) + [ #### Surveillance de l'état ](#container_definition_healthcheck-managed-instances) + [ #### Environnement ](#container_definition_environment-managed-instances) + [ #### Sécurité ](#container_definition_security-managed-instances) + [ #### Paramètres réseau ](#container_definition_network-managed-instances) + [ #### Stockage et journalisation ](#container_definition_storage-managed-instances) + [ #### Besoins en ressources ](#container_definition_resourcerequirements-managed-instances) + [ #### Temporisations de conteneurs ](#container_definition_timeout-managed-instances) + [ #### Dépendances du conteneur ](#container_definition_dependency-managed-instances) + [ #### Contrôles système ](#container_definition_systemcontrols-managed-instances) + [ #### Interactive ](#container_definition_interactive-managed-instances) + [ #### Pseudo Terminal ](#container_definition_pseudoterminal-managed-instances) #### Politique de redémarrage `restartPolicy` La politique de redémarrage du conteneur et les paramètres de configuration associés. Lorsque vous configurez une politique de redémarrage pour un conteneur, Amazon ECS peut redémarrer le conteneur sans avoir à remplacer la tâche. Pour de plus amples informations, veuillez consulter [Redémarrage de conteneurs individuels dans les tâches Amazon ECS à l’aide de politiques de redémarrage de conteneurs](container-restart-policy.md). `enabled` Type : Boolean Obligatoire : oui Spécifie si une politique de redémarrage est activée pour le conteneur. `ignoredExitCodes` Type : tableau integer Obligatoire : non Liste des codes de sortie qu’Amazon ECS ignorera et pour lesquels il ne tentera pas de redémarrage. Vous pouvez spécifier un maximum de 50 codes de sortie de conteneur. Par défaut, Amazon ECS n’ignore aucun code de sortie. `restartAttemptPeriod` Type : Integer Obligatoire : non Durée (en secondes) pendant laquelle le conteneur doit fonctionner avant de pouvoir tenter un redémarrage. Un conteneur ne peut être redémarré qu’une fois toutes les `restartAttemptPeriod` secondes. Si un conteneur n’est pas en mesure de fonctionner pendant cette période et qu’il se ferme prématurément, il ne sera pas redémarré. Vous pouvez définir une `restartAttemptPeriod` minimale de 60 secondes et une `restartAttemptPeriod` maximale de 1 800 secondes. Par défaut, un conteneur doit fonctionner pendant 300 secondes avant de pouvoir être redémarré. #### Surveillance de l'état `healthCheck` Commande de surveillance de l'état du conteneur et paramètres de configuration associés pour le conteneur. Pour de plus amples informations, veuillez consulter [Détermination de l’état des tâches Amazon ECS à l’aide de la surveillance de l’état des conteneurs](healthcheck.md). `command` Tableau de chaînes représentant la commande que le conteneur exécute pour déterminer si celle-ci est saine. Le tableau de chaînes peut commencer par `CMD` pour exécuter directement les arguments de la commande, ou par `CMD-SHELL` pour exécuter la commande avec le shell par défaut du conteneur. Si vous n'en spécifiez aucun, `CMD` est utilisé. Lorsque vous enregistrez une définition de tâche dans le AWS Management Console, utilisez une liste de commandes séparées par des virgules. Ces commandes sont converties en une chaîne une fois la définition de tâche créée. Un exemple d'entrée pour une surveillance de l'état est le suivant. ``` CMD-SHELL, curl -f http://localhost/ || exit 1 ``` Lorsque vous enregistrez une définition de tâche à l'aide du AWS CLI panneau AWS Management Console JSON APIs, placez la liste des commandes entre crochets. Un exemple d'entrée pour une surveillance de l'état est le suivant. ``` [ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ] ``` Un code de sortie de 0, avec aucune sortie `stderr`, indique la réussite et un code de sortie autre que zéro indique qu'il s'agit d'un échec. `interval` La durée (en secondes) entre chaque surveillance de l'état. Vous pouvez indiquer une durée comprise entre 5 et 300 secondes. La valeur par défaut est de 30 secondes. `timeout` La durée (en secondes) d'attente pour qu'une surveillance de l'état réussisse avant qu'elle ne soit considérée comme un échec. Vous pouvez indiquer une durée comprise entre 2 et 60 secondes. La valeur par défaut est de 5 secondes. `retries` Nombre de nouvelles tentatives d'exécution d'une surveillance de l'état ayant échoué avant que le conteneur soit considéré comme défectueux. Vous pouvez indiquer un nombre de tentatives compris en 1 et 10. La valeur par défaut est de trois tentatives. `startPeriod` La période de grâce facultative pour donner aux conteneurs le temps de démarrer avant l'échec des surveillance de l'état est prise en compte dans le nombre maximal de tentatives. Vous pouvez spécifier une valeur comprise entre 0 et 300. Par défaut, la `startPeriod` est désactivée. Si une vérification de l'état aboutit dans le délai défini par `startPeriod`, le conteneur est considéré comme sain et toutes les défaillances suivantes sont prises en compte dans le nombre maximal de nouvelles tentatives. #### Environnement `cpu` Type : Integer Obligatoire : non Le nombre d'unités `cpu` que l'agent de conteneur Amazon ECS réserve pour le conteneur. Sous Linux, ce paramètre correspond à `CpuShares` dans la section [Créer un conteneur](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate). Ce champ est facultatif pour les tâches exécutées sur les instances gérées Amazon ECS. La quantité totale de processeurs réservée pour tous les conteneurs au sein d'une tâche doit être inférieure à la valeur `cpu` au niveau de la tâche. Les conteneurs Linux partagent des unités de processeur non allouées avec les autres conteneurs de l'instance de conteneur selon le même ratio que la quantité allouée. Par exemple, supposons que vous exécutez une tâche à conteneur unique sur un type d'instance à cœur unique avec 512 unités de processeur spécifiées pour ce conteneur. De plus, cette tâche est la seule tâche en cours d'exécution sur l'instance de conteneur. Dans cet exemple, le conteneur peut utiliser le partage complet de 1 024 unités UC à tout moment. Toutefois, supposons que vous ayez lancé une autre copie de la même tâche sur cette instance de conteneur. Un minimum de 512 unités de processeur est affecté à chaque tâche si nécessaire. De même, si l'autre conteneur n'utilise pas le processeur restant, chaque conteneur peut bénéficier d'une utilisation plus importante du processeur. Toutefois, si les deux tâches sont actives à 100 % en permanence, elles sont limitées à 512 unités d'UC. Sur les instances de conteneur Linux, le démon Docker de l'instance de conteneur se sert de la valeur de processeur pour calculer les ratios de partage de processeur relatifs pour les conteneurs en cours d'exécution. La valeur de parts d’UC minimale autorisée par le noyau Linux est de 2, et la valeur de parts d’UC maximale autorisée par le noyau Linux est de 262 144. Toutefois, le paramètre UC n’est pas obligatoire et vous pouvez utiliser des valeurs d’UC inférieures à 2 ou supérieures à 262 144 dans vos définitions de conteneur. Pour les valeurs d’UC inférieures à 2 (y compris null) ou supérieures à 262 144, le comportement varie selon la version de l’agent de conteneur Amazon ECS : Pour voir d'autres exemples, veuillez consulter le billet de blog [How Amazon ECS manages CPU and memory resources](https://aws.amazon.com/blogs/containers/how-amazon-ecs-manages-cpu-and-memory-resources/). `gpu` Type : objet [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obligatoire : non Le nombre de `GPUs` physiques que l'agent de conteneur Amazon ECS réserve pour le conteneur. Le nombre de conteneurs GPUs réservés à tous les conteneurs d'une tâche ne doit pas dépasser le nombre de conteneurs disponibles GPUs sur l'instance de conteneur sur laquelle la tâche est lancée. Pour de plus amples informations, veuillez consulter [Définitions de tâches Amazon ECS pour les charges de travail GPU](ecs-gpu.md). `Elastic Inference accelerator` Ce paramètre n’est pas pris en charge pour les conteneurs hébergés sur instances gérées Amazon ECS. Type : objet [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obligatoire : non Pour le type `InferenceAccelerator`, `value` correspond à `deviceName` d'un `InferenceAccelerator` spécifié dans une définition de tâche. Pour de plus amples informations, veuillez consulter [Nom de l'accélérateur Elastic Inference (obsolète)](task_definition_parameters.md#elastic-Inference-accelerator). `essential` Type : booléen Obligatoire : non Supposons que le paramètre `essential` d'un conteneur soit marqué comme `true`, et que ce conteneur échoue ou s'arrête pour une raison quelconque. Ensuite, tous les autres conteneurs qui font partie de la tâche sont arrêtés. Si le paramètre `essential` d'un conteneur a la valeur `false`, son échec n'a pas d'incidence sur le reste des conteneurs dans la tâche. Si ce paramètre n'est pas spécifié, le conteneur est supposé essentiel. Toutes les tâches doivent comporter au moins un conteneur essentiel. Supposons que vous disposiez d'une application composée de plusieurs conteneurs. Ensuite, les conteneurs de groupes qui sont utilisés dans un même but pour former des composants, et séparer les différents composants en plusieurs définitions de tâches. Pour de plus amples informations, veuillez consulter [Architecture de votre application pour Amazon ECS](application_architecture.md). ``` "essential": true|false ``` `entryPoint` Les premières versions de l'agent de conteneur Amazon ECS ne traitent pas correctement les paramètres `entryPoint`. Si vous rencontrez des difficultés pour utiliser `entryPoint`, mettez à jour l'agent de conteneur ou saisissez plutôt vos commandes et vos arguments sous forme d'éléments de tableau `command`. Type : tableau de chaînes Obligatoire : non Point d'entrée qui est transmis au conteneur. ``` "entryPoint": ["string", ...] ``` `command` Type : tableau de chaînes Obligatoire : non La commande transmise au conteneur. Ce paramètre correspond à `Cmd` dans la commande create-container et au paramètre `COMMAND` de docker run. S'il existe plusieurs arguments, assurez-vous que chaque argument est une chaîne séparée dans le tableau. ``` "command": ["string", ...] ``` `workingDirectory` Type : chaîne Obligatoire : non Répertoire de travail dans lequel exécuter les commandes à l'intérieur du conteneur. Ce paramètre correspond à `WorkingDir` dans la section [Create a container](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) (Créer un conteneur) de l'[API Docker à distance](https://docs.docker.com/reference/api/engine/version/v1.38/) et l'option `--workdir` correspond à [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/). ``` "workingDirectory": "string" ``` `environmentFiles` Type : tableau d'objets Obligatoire : non Liste des fichiers contenant les variables d'environnement à transmettre à un conteneur. Ce paramètre correspond à l’option `--env-file` de la commande docker run. Vous pouvez spécifier jusqu'à dix fichiers d'environnement. Le fichier doit avoir une extension de fichier `.env`. Chaque ligne d'un fichier d'environnement contient une variable d'environnement au format `VARIABLE=VALUE`. Les lignes commençant par `#` sont traitées comme des commentaires et sont ignorées. Si des variables d'environnement individuelles sont spécifiées dans la définition du conteneur, elles ont priorité sur les variables contenues dans un fichier d'environnement. Si plusieurs fichiers d'environnement contenant la même variable sont spécifiés, ils sont traités de haut en bas. Nous vous recommandons d'utiliser des noms de variables uniques. Pour de plus amples informations, veuillez consulter [Transmission d’une variable d’environnement individuelle à un conteneur Amazon ECS](taskdef-envfiles.md). `value` Type : Chaîne Obligatoire : oui L'Amazon Resource Name (ARN) de l'objet Amazon S3 contenant le fichier de variable d'environnement. `type` Type : Chaîne Obligatoire : oui Type de fichier à utiliser La seule valeur prise en charge est `s3`. `environment` Type : tableau d'objets Obligatoire : non Variables d'environnement à transmettre à un conteneur. Ce paramètre correspond à `Env` dans la commande docker create-container et à l’option `--env` dans la commande docker run. Nous déconseillons l'utilisation des variables d'environnement en texte clair pour les informations sensibles, comme les données d'identification. `name` Type : Chaîne Obligatoire : oui lorsque `environment` est utilisé Nom de la variable d'environnement. `value` Type : Chaîne Obligatoire : oui lorsque `environment` est utilisé Valeur de la variable d'environnement. ``` "environment" : [ { "name" : "string", "value" : "string" }, { "name" : "string", "value" : "string" } ] ``` `secrets` Type : tableau d'objets Obligatoire : non Objet représentant le secret à exposer à votre conteneur. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur Amazon ECS](specifying-sensitive-data.md). `name` Type : Chaîne Obligatoire : oui Valeur à définir comme variable d'environnement sur le conteneur. `valueFrom` Type : Chaîne Obligatoire : oui Secret à exposer au conteneur. Les valeurs prises en charge sont soit le nom Amazon Resource (ARN) complet du AWS Secrets Manager secret, soit l'ARN complet du paramètre dans le AWS Systems Manager Parameter Store. Si le paramètre Systems Manager Parameter Store ou le paramètre Secrets Manager existe au même endroit Région AWS que la tâche que vous lancez, vous pouvez utiliser l'ARN complet ou le nom du secret. Si le paramètre existe dans une autre région, l'ARN complet doit être spécifié. ``` "secrets": [ { "name": "environment_variable_name", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name" } ] ``` #### Sécurité `privileged` Type : booléen Obligatoire : non Lorsque ce paramètre a la valeur `true`, le conteneur dispose de droits élevés sur l’instance de conteneur hôte (similaire à l’utilisateur `root`). Ce paramètre correspond à `Privileged` dans la commande docker create-container et à l’option `--privileged` dans la commande docker run. `user` Type : chaîne Obligatoire : non Utilisateur à utiliser à l'intérieur du conteneur. Ce paramètre correspond à `User` dans la commande docker create-container et à l’option `--user` dans la commande docker run. Lorsque vous exécutez des tâches en mode réseau `host`, vous ne devez pas exécuter de conteneurs à l'aide de l'utilisateur root (UID 0). Pour plus de sécurité, nous recommandons l’utilisation d'un utilisateur non root. Vous pouvez spécifier l'`user` à l'aide des formats suivants. Si vous spécifiez un UID ou GID, vous devez le spécifier en tant que nombre entier positif. + `user` + `user:group` + `uid` + `uid:gid` + `user:gid` + `uid:group` `readonlyRootFilesystem` Type : booléen Obligatoire : non Lorsque ce paramètre a la valeur `true`, le conteneur ne dispose que d’un accès en lecture seule au système de fichiers racine. Ce paramètre correspond à `ReadonlyRootfs` dans la commande docker create-container et à l’option `--read-only` dans la commande docker run. `dockerSecurityOptions` Ce paramètre n’est pas pris en charge pour les tâches exécutées sur les instances gérées Amazon ECS. Type : tableau de chaînes Obligatoire : non Liste de chaînes fournissant des étiquettes personnalisées pour les systèmes SELinux de sécurité à AppArmor plusieurs niveaux. Ce champ n’est pas valide pour les conteneurs dans les tâches qui utilisent Fargate. `ulimits` Type : tableau d’objets [Ulimit](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html) Obligatoire : non Une liste d'`ulimits` à définir dans le conteneur. Si une valeur ulimit est spécifiée dans une définition de tâche, elle remplace les valeurs par défaut définies par Docker. Ce paramètre correspond à `Ulimits` dans la commande docker create-container et à l’option `--ulimit` dans la commande docker run. Les valeurs d'attribution de nom valides sont affichées dans le type de données [Ulimit](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html). 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` qui est remplacé par Fargate. La limite de ressources `nofile` restreint le nombre de fichiers ouverts qu'un conteneur peut utiliser. Par défaut, la limite souple `nofile` a la valeur `1024` et la limite stricte a la valeur `65535`. Ce paramètre nécessite la version 1.18 de l'API Docker Remote ou une version ultérieure sur votre instance de conteneur. Pour vérifier la version de l'API Docker à distance de votre instance de conteneur, connectez-vous à votre instance de conteneur et exécutez la commande suivante : `sudo docker version --format '{{.Server.APIVersion}}'` `dockerLabels` Type : mappage chaîne/chaîne Obligatoire : non Une key/value carte des étiquettes à ajouter au conteneur. Ce paramètre correspond à `Labels` dans la commande docker create-container et à l’option `--label` dans la commande docker run. Ce paramètre nécessite la version 1.18 de l'API Docker Remote ou une version ultérieure sur votre instance de conteneur. ``` "dockerLabels": {"string": "string" ...} ``` #### Paramètres réseau `disableNetworking` Ce paramètre n’est pas pris en charge pour les tâches exécutées sur les instances gérées Amazon ECS. Type : booléen Obligatoire : non Quand ce paramètre a la valeur true, la mise en réseau est désactivée dans le conteneur. La valeur par défaut est `false`. ``` "disableNetworking": true|false ``` `links` Ce paramètre n’est pas pris en charge pour les tâches exécutées sur les instances gérées Amazon ECS. Type : tableau de chaînes Obligatoire : non Le paramètre `link` permet aux conteneurs de communiquer entre eux sans avoir besoin de définir des mappages de ports. Ce paramètre n'est pris en charge que si le mode réseau d'une définition de tâche est défini sur `bridge`. La construction `name:internalName` est analogue à `name:alias` dans les liaisons Docker. Il peut comporter jusqu’à 255 lettres (majuscules et minuscules), des chiffres, des tirets ou des traits de soulignement. Des conteneurs situés sur la même instance de conteneur peuvent communiquer entre eux sans nécessiter de liens ou de mappages de ports hôtes. L'isolation réseau sur une instance de conteneur est contrôlée par les groupes de sécurité et les paramètres de VPC. ``` "links": ["name:internalName", ...] ``` `hostname` Ce paramètre n’est pas pris en charge pour les tâches exécutées sur les instances gérées Amazon ECS. Type : chaîne Obligatoire : non Nom d'hôte à utiliser pour votre conteneur. Ce paramètre correspond à `Hostname` dans docker create-container et à l’option `--hostname` de docker run. ``` "hostname": "string" ``` `dnsServers` Ce paramètre n’est pas pris en charge pour les tâches exécutées sur les instances gérées Amazon ECS. Type : tableau de chaînes Obligatoire : non Liste de serveurs DNS qui sont présentés au conteneur. ``` "dnsServers": ["string", ...] ``` `extraHosts` Ce paramètre n’est pas pris en charge pour les tâches qui utilisent le mode réseau `awsvpc`. Type : tableau d'objets Obligatoire : non Liste de noms d'hôte et de mappages d'adresses IP à ajouter au fichier `/etc/hosts` dans le conteneur. Ce paramètre correspond à `ExtraHosts` dans la commande docker create-container et à l’option `--add-host` dans la commande docker run. ``` "extraHosts": [ { "hostname": "string", "ipAddress": "string" } ... ] ``` `hostname` Type : Chaîne Obligatoire : oui, lorsque des objets `extraHosts` sont utilisés Nom d'hôte à utiliser dans l'entrée `/etc/hosts`. `ipAddress` Type : Chaîne Obligatoire : oui, lorsque des objets `extraHosts` sont utilisés Adresse IP à utiliser dans l'entrée `/etc/hosts`. #### Stockage et journalisation `readonlyRootFilesystem` Type : booléen Obligatoire : non Quand ce paramètre a la valeur true, le conteneur ne dispose que d'un accès en lecture seule au système de fichiers racine. Ce paramètre correspond à `ReadonlyRootfs` dans la commande docker create-container et à l’option `--read-only` dans la commande docker run. La valeur par défaut est `false`. ``` "readonlyRootFilesystem": true|false ``` `mountPoints` Type : tableau d'objets Obligatoire : non Les points de montage pour les volumes de données dans votre conteneur. Ce paramètre correspond à `Volumes` dans l’API Docker create-container et à l’option `--volume` de docker run. Les conteneurs Windows peuvent monter des répertoires entiers sur le même lecteur que `$env:ProgramData`. Les conteneurs Windows ne peuvent pas monter de répertoires sur un autre lecteur, et les points de montage ne peuvent pas être utilisés sur plusieurs lecteurs. Vous devez spécifier des points de montage pour associer un volume Amazon EBS directement à une tâche Amazon ECS. `sourceVolume` Type : Chaîne Obligatoire : oui, lorsque des objets `mountPoints` sont utilisés Nom du volume à monter. `containerPath` Type : Chaîne Obligatoire : oui, lorsque des objets `mountPoints` sont utilisés Le chemin dans le conteneur où le volume sera monté. `readOnly` Type : booléen Obligatoire : non Si cette valeur est `true`, le conteneur ne peut accéder au volume qu'en lecture. Si cette valeur est `false`, le conteneur peut écrire sur le volume. La valeur par défaut est `false`. Pour les tâches exécutées sur des instances EC2 exécutant le système d’exploitation Windows, laissez la valeur `false` par défaut. `volumesFrom` Type : tableau d'objets Obligatoire : non Volumes de données à monter à partir d'un autre conteneur. Ce paramètre correspond à `VolumesFrom` dans la commande docker create-container et à l’option `--volumes-from` dans la commande docker run. `sourceContainer` Type : Chaîne Obligatoire : oui lorsque `volumesFrom` est utilisé Nom du conteneur à partir duquel monter les volumes. `readOnly` Type : booléen Obligatoire : non Si cette valeur est `true`, le conteneur ne peut accéder au volume qu'en lecture. Si cette valeur est `false`, le conteneur peut écrire sur le volume. La valeur par défaut est `false`. ``` "volumesFrom": [ { "sourceContainer": "string", "readOnly": true|false } ] ``` `logConfiguration` Type : [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html)Objet Obligatoire : non Spécification de configuration du journal pour le conteneur. Pour obtenir des exemples de définitions de tâche qui utilisent une configuration de journaux, consultez [Exemple de définitions de tâches Amazon ECS](example_task_definitions.md). Ce paramètre correspond à `LogConfig` dans la commande docker create-container et à l’option `--log-driver` dans la commande docker run. Par défaut, les conteneurs utilisent le même pilote de journalisation que celui utilisé par le démon Docker. Cependant, le conteneur peut utiliser un pilote de journalisation différent que celui du démon Docker en spécifiant un pilote de journal avec ce paramètre dans la définition de conteneur. Pour utiliser un pilote de journalisation différent pour un conteneur, le système de journal doit être configuré correctement sur l'instance de conteneur (ou sur un serveur de journal différent pour les options de journalisation à distance). Tenez compte des éléments suivants lorsque vous spécifiez une configuration de journal pour vos conteneurs : + Amazon ECS prend en charge un sous-ensemble des pilotes de journalisation qui sont disponibles pour le démon Docker. + Ce paramètre nécessite la version 1.18 ou ultérieure de l'API Docker à distance sur votre instance de conteneur. ``` "logConfiguration": { "logDriver": "awslogs",""splunk", "awsfirelens", "options": {"string": "string" ...}, "secretOptions": [{ "name": "string", "valueFrom": "string" }] } ``` `logDriver` Type : Chaîne Valeurs valides : `"awslogs","splunk","awsfirelens"` Obligatoire : oui lorsque `logConfiguration` est utilisé Pilote de journal à utiliser pour le conteneur. Par défaut, les valeurs valides mentionnées ci-dessus sont les pilotes de journal avec lesquels l'agent de conteneur Amazon ECS peut communiquer. Les pilotes de journalisation pris en charge sont `awslogs`, `splunk` et `awsfirelens`. Pour plus d'informations sur l'utilisation du pilote de `awslogs` journal dans les définitions de tâches pour envoyer les journaux de vos conteneurs à CloudWatch Logs, consultez[Envoyez les journaux Amazon ECS à CloudWatch](using_awslogs.md). Pour plus d’informations sur l’utilisation du pilote de journalisation `awsfirelens`, consultez la section [Envoyer les journaux Amazon ECS à un AWS service ou AWS Partner](using_firelens.md). Si vous avez un pilote personnalisé qui n'est pas répertorié, vous pouvez bifurquer le projet d'agent de conteneur Amazon ECS [disponible sur GitHub et le](https://github.com/aws/amazon-ecs-agent) personnaliser pour qu'il fonctionne avec ce pilote. Nous vous conseillons d'envoyer des demandes d'extraction pour les modifications que vous souhaitez inclure. Toutefois, nous ne prenons pas en charge l'exécution de copies modifiées de ce logiciel pour le moment. Ce paramètre nécessite la version 1.18 de l'API Docker Remote ou une version ultérieure sur votre instance de conteneur. `options` Type : mappage chaîne/chaîne Obligatoire : non key/value Carte des options de configuration à envoyer au pilote du journal. Les options que vous pouvez spécifier dépendent du pilote de journalisation. Certaines des options que vous pouvez spécifier lorsque vous utilisez le `awslogs` routeur pour acheminer les journaux vers Amazon CloudWatch sont les suivantes : `awslogs-create-group` Obligatoire : non Spécifiez si vous souhaitez que le groupe de journaux soit créé automatiquement. Si cette option n'est pas spécifiée, l'emplacement par défaut est `false`. Votre politique IAM doit inclure l'autorisation `logs:CreateLogGroup` afin que vous puissiez essayer d'utiliser `awslogs-create-group`. `awslogs-region` Obligatoire : oui Spécifiez Région AWS le pilote de `awslogs` journal auquel envoyer vos journaux Docker. Vous pouvez choisir d'envoyer tous vos journaux provenant de clusters situés dans différentes régions vers une seule région dans CloudWatch Logs. Cela leur permet d'être tous visibles en un seul endroit. Sinon, vous pouvez les séparer par région pour plus de granularité. Assurez-vous que le groupe de journaux spécifié existe dans la région que vous spécifiez avec cette option. `awslogs-group` Obligatoire : oui Assurez-vous de spécifier un groupe de journaux auquel le pilote de journaux `awslogs` envoie ses flux de journaux. `awslogs-stream-prefix` Obligatoire : oui Utilisez l'option `awslogs-stream-prefix` pour associer un flux de journaux au préfixe spécifié, au nom du conteneur et à l'ID de la tâche Amazon ECS à laquelle appartient le conteneur. Si vous spécifiez un préfixe avec cette option, le format du flux de journaux est le suivant. ``` prefix-name/container-name/ecs-task-id ``` Si vous ne spécifiez pas de préfixe avec cette option, le flux de journaux est nommé d'après l'ID de conteneur attribué par le démon Docker sur l'instance de conteneur. Etant donné qu'il est difficile de suivre les journaux jusqu'au conteneur qui les a envoyé en utilisant uniquement l'ID de conteneur Docker (qui est uniquement disponible sur l'instance de conteneur), nous vous recommandons de spécifier un préfixe avec cette option. Pour les services Amazon ECS, vous pouvez utiliser le nom du service comme préfixe. Ce faisant, vous pourrez suivre les flux de journaux et déterminer le service auquel appartient le conteneur, trouver le nom du conteneur qui les a envoyés, ainsi que l'ID de la tâche à laquelle le conteneur appartient. Vous devez spécifier un préfixe de flux pour vos journaux pour qu'ils apparaissent dans le panneau des journaux lors de l'utilisation de la console Amazon ECS. `awslogs-datetime-format` Obligatoire : non Cette option définit un modèle de démarrage à plusieurs lignes au format `strftime` Python. Un message de journal est composé de plusieurs lignes : une ligne correspondant au modèle et les lignes suivantes qui ne correspondent pas au modèle. La ligne mise en correspondance est le délimiteur entre les messages de journalisation. Ce format peut, par exemple, servir à analyser une sortie comme une pile de vidage, laquelle pourrait, dans le cas contraire, être consignée en plusieurs entrées. Le modèle adéquat permet de la capturer dans une seule entrée. Pour de plus amples informations, veuillez consulter [awslogs-datetime-format](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-datetime-format). Vous ne pouvez pas configurer à la fois les options `awslogs-datetime-format` et `awslogs-multiline-pattern`. La journalisation multiligne effectue l'analyse et la mise en correspondance des expressions régulières de tous les messages de journalisation. Cela peut avoir un impact négatif sur les performances de journalisation. `awslogs-multiline-pattern` Obligatoire : non Cette option définit un modèle de démarrage à plusieurs lignes à l'aide d'une expression régulière. Un message de journal est composé de plusieurs lignes : une ligne correspondant au modèle et les lignes suivantes qui ne correspondent pas au modèle. La ligne mise en correspondance est le délimiteur entre les messages de journalisation. Pour de plus amples informations, veuillez consulter [awslogs-multiline-pattern](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-multiline-pattern). Cette option est ignorée si `awslogs-datetime-format` est également configuré. Vous ne pouvez pas configurer à la fois les options `awslogs-datetime-format` et `awslogs-multiline-pattern`. La journalisation multiligne effectue l'analyse et la mise en correspondance des expressions régulières de tous les messages de journalisation. Cela peut avoir un impact négatif sur les performances de journalisation. `mode` Obligatoire : non Valeurs valides : `non-blocking` \$1 `blocking` Cette option définit le mode de transmission des messages de journalisation du conteneur vers le pilote de journalisation `awslogs`. Le mode de livraison que vous choisissez affecte la disponibilité de l’application lorsque le flux des journaux provenant du conteneur est interrompu. Si vous utilisez le `blocking` mode et que le flux de logs CloudWatch est interrompu, les appels provenant du code du conteneur pour écrire dans les `stderr` flux `stdout` et seront bloqués. Le fil de journalisation de l'application se bloquera en conséquence. Cela peut empêcher l'application de répondre et entraîner l'échec de vérification de l'état du conteneur. Si vous utilisez le mode `non-blocking`, les journaux du conteneur sont plutôt stockés dans une mémoire tampon intermédiaire configurée avec l'option `max-buffer-size`. Cela empêche l'application de ne plus répondre lorsque les journaux ne peuvent pas être envoyés à CloudWatch. Nous vous recommandons d'utiliser ce mode si vous souhaitez garantir la disponibilité du service et si vous acceptez une certaine perte de journaux. Pour plus d’informations, consultez la section [Prévention de la perte de journaux grâce au mode non bloquant dans le pilote de journalisation conteneur `awslogs`](https://aws.amazon.com/blogs/containers/preventing-log-loss-with-non-blocking-mode-in-the-awslogs-container-log-driver/). `max-buffer-size` Obligatoire : non Valeur par défaut : `1m` Quand le mode `non-blocking` est utilisé, l'option de journalisation `max-buffer-size` contrôle la taille de la mémoire tampon utilisée pour le stockage des messages intermédiaires. Assurez-vous de spécifier une taille de mémoire tampon adéquate en fonction de votre application. Lorsque la mémoire tampon est pleine, il est impossible de stocker d'autres journaux. Les journaux qui ne peuvent pas être stockés sont perdus. Pour acheminer les journaux à l’aide du routeur de journaux `splunk`, vous devez spécifier un `splunk-token` et une `splunk-url`. Lorsque vous utilisez le routeur de `awsfirelens` journaux pour acheminer les journaux vers une AWS Partner Network destination Service AWS ou à des fins de stockage et d'analyse des journaux, vous pouvez définir l'`log-driver-buffer-limit`option permettant de limiter le nombre d'événements mis en mémoire tampon avant d'être envoyés au conteneur du routeur de journaux. Cela peut aider à résoudre le problème potentiel de perte de journal, car un débit élevé peut entraîner un épuisement de la mémoire pour le tampon à l'intérieur de Docker. Pour de plus amples informations, veuillez consulter [Configuration des journaux Amazon ECS pour un débit élevé](firelens-docker-buffer-limit.md). Les autres options que vous pouvez spécifier lors de l’utilisation d’`awsfirelens` pour acheminer les journaux dépendent de la destination. Lorsque vous exportez des journaux vers Amazon Data Firehose, vous pouvez spécifier le Région AWS format `region` et le nom du flux de journaux. `delivery_stream` Lorsque vous exportez des journaux vers Amazon Kinesis Data Streams, vous pouvez spécifier la Région AWS avec `region` et un nom pour le flux de données avec `stream`. Lorsque vous exportez des journaux vers Amazon OpenSearch Service, vous pouvez spécifier des options telles que `Name` `Host` (point de terminaison de OpenSearch service sans protocole) `Port` `Index``Type`,`Aws_auth`,`Aws_region`,,`Suppress_Type_Name`, et`tls`. Lorsque vous exportez des journaux vers Amazon S3, vous pouvez spécifier le compartiment à l’aide de l’option `bucket`. Vous pouvez également spécifier `region`, `total_file_size`, `upload_timeout` et `use_put_object` en tant qu’options. Ce paramètre nécessite la version 1.19 de l'API Docker à distance ou une version supérieure sur votre instance de conteneur. `secretOptions` Type : tableau d'objets Obligatoire : non Objet qui représente le secret à transmettre à la configuration de journal. Les secrets utilisés dans la configuration du journal peuvent inclure un jeton d'authentification, un certificat ou une clé de chiffrement. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur Amazon ECS](specifying-sensitive-data.md). `name` Type : Chaîne Obligatoire : oui Valeur à définir comme variable d'environnement sur le conteneur. `valueFrom` Type : Chaîne Obligatoire : oui Secret à exposer à la configuration de journal du conteneur. ``` "logConfiguration": { "logDriver": "splunk", "options": { "splunk-url": "https://cloud.splunk.com:8080", "splunk-token": "...", "tag": "...", ... }, "secretOptions": [{ "name": "splunk-token", "valueFrom": "/ecs/logconfig/splunkcred" }] } ``` `firelensConfiguration` Type : [FirelensConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FirelensConfiguration.html)Objet Obligatoire : non FireLens Configuration du conteneur. Cette option est utilisée pour spécifier et configurer un routeur de journal pour les journaux de conteneur. Pour de plus amples informations, veuillez consulter [Envoyer les journaux Amazon ECS à un AWS service ou AWS Partner](using_firelens.md). ``` { "firelensConfiguration": { "type": "fluentd", "options": { "KeyName": "" } } } ``` `options` Type : mappage chaîne/chaîne Obligatoire : non key/value Carte des options à utiliser lors de la configuration du routeur de log. Ce champ est facultatif et peut être utilisé pour spécifier un fichier de configuration personnalisé ou ajouter des métadonnées supplémentaires, telles que les détails de tâche, de définition de tâche, de cluster et d'instance de conteneur à l'événement de journal. Si spécifié, la syntaxe à utiliser est `"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"}`. Pour de plus amples informations, veuillez consulter [Exemple de définition de tâche Amazon ECS : acheminement des journaux vers FireLens](firelens-taskdef.md). `type` Type : Chaîne Obligatoire : oui Routeur de journal à utiliser. Les valeurs valides sont `fluentd` ou `fluentbit`. #### Besoins en ressources `resourceRequirements` Type : tableau d’objets [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obligatoire : non Type et quantité d'une ressource à attribuer à un conteneur. Actuellement, la seule ressource prise en charge est un GPU. `type` Type : Chaîne Obligatoire : oui Type d'une ressource à attribuer à un conteneur. La valeur prise en charge est `GPU`. `value` Type : Chaîne Obligatoire : oui Valeur du type de ressource spécifié. Si le type `GPU` est utilisé, la valeur est le nombre d’éléments `GPUs` physiques que l’agent de conteneur Amazon ECS réserve pour le conteneur. Le nombre de conteneurs réservés à tous les conteneurs d'une tâche ne peut pas dépasser le nombre de conteneurs disponibles GPUs sur l'instance de conteneur sur GPUs laquelle la tâche est lancée. GPUs ne sont pas disponibles pour les tâches exécutées sur Fargate. #### Temporisations de conteneurs `startTimeout` Type : Integer Obligatoire : non Exemples de valeur : `120` Durée d'attente (en secondes) avant l'abandon de la résolution de dépendances pour un conteneur. Par exemple, vous spécifiez deux conteneurs dans une définition de tâche, où le `containerA` dispose d'une dépendance au `containerB` avec un état `COMPLETE`, `SUCCESS` ou `HEALTHY`. Si une valeur `startTimeout` est spécifiée pour `containerB` et qu'il n'a pas atteint l'état souhaité dans ce délai, alors le `containerA` ne démarre pas. Si un conteneur ne respecte pas une contrainte de dépendance ou s'écoule avant de respecter la contrainte, Amazon ECS ne fait pas progresser pas les conteneurs dépendants vers leur état suivant. La valeur maximale est de 600 secondes (10 minutes). `stopTimeout` Type : Integer Obligatoire : non Exemples de valeur : `120` Durée (en secondes) à attendre avant que le conteneur soit expressément tué s'il ne s'achève pas normalement tout seul. Si le paramètre n'est pas spécifié, alors la valeur par défaut de 30 secondes est utilisée. La valeur maximale est de 86 400 secondes (24 heures). #### Dépendances du conteneur `dependsOn` Type : tableau d’objets [ContainerDependency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html) Obligatoire : non Dépendances définies pour le démarrage et l'arrêt de conteneurs. Un conteneur peut contenir plusieurs dépendances. Lorsqu'une dépendance est définie pour le démarrage des conteneurs, elle est inversée pour leur arrêt. Pour obtenir un exemple, consultez [Dépendances du conteneur](example_task_definitions.md#example_task_definition-containerdependency). Si un conteneur ne respecte pas une contrainte de dépendance ou s'écoule avant de respecter la contrainte, Amazon ECS ne fait pas progresser pas les conteneurs dépendants vers leur état suivant. Ce paramètre exige que la tâche ou le service utilise la version de plateforme `1.3.0` ou une version ultérieure (Linux) ou `1.0.0` (Windows). ``` "dependsOn": [ { "containerName": "string", "condition": "string" } ] ``` `containerName` Type : Chaîne Obligatoire : oui Nom de conteneur qui doit répondre à la condition spécifiée. `condition` Type : Chaîne Obligatoire : oui Condition de dépendance du conteneur. Voici les conditions disponibles et leur comportement : + `START` - Cette condition émule le comportement de liens et de volumes aujourd'hui. La condition vérifie qu'un conteneur dépendant est démarré avant d'autoriser d'autres conteneurs à démarrer. + `COMPLETE` - Cette condition vérifie qu'un conteneur dépendant exécute un cycle complet (sorties) avant d'autoriser d'autres conteneurs à démarrer. Cela peut être utile pour les conteneurs non essentiels qui exécutent un script, puis se ferment. Cette condition ne peut pas être définie sur un conteneur essentiel. + `SUCCESS` - Cette condition est identique à `COMPLETE`, mais elle nécessite également que le conteneur se termine par un état `zero`. Cette condition ne peut pas être définie sur un contenant essentiel. + `HEALTHY` - Cette condition vérifie que la surveillance de l'état du conteneur dépendant réussit avant d'autoriser d'autres conteneurs à démarrer. Cela nécessite que le conteneur dépendant dispose de surveillances de l'état configurées dans la définition de la tâche. Cette condition est confirmée uniquement au démarrage de la tâche. #### Contrôles système `systemControls` Type : objet [SystemControl](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_SystemControl.html) Obligatoire : non Liste des paramètres du noyau de l’espace de noms à définir dans le conteneur. Ce paramètre correspond à `Sysctls` dans la commande docker create-container et à l’option `--sysctl` dans la commande docker run. Par exemple, vous pouvez configurer le paramètre `net.ipv4.tcp_keepalive_time` pour maintenir des connexions de plus longue durée. Il n'est pas recommandé de spécifier des paramètres `systemControls` liés au réseau pour plusieurs conteneurs dans une seule tâche qui utilise également le mode réseau `awsvpc` ou `host`. En procédant ainsi, vous vous exposez aux inconvénients suivants : + Si vous définissez `systemControls` pour n’importe quel conteneur, cela s’applique à tous les conteneurs de la tâche. Si vous définissez différents paramètres `systemControls` pour plusieurs conteneurs dans une seule tâche, c'est le conteneur qui est démarré en dernier qui détermine le paramètre `systemControls` qui prend effet. Si vous définissez un espace de noms des ressources IPC à utiliser pour les conteneurs de la tâche, les conditions suivantes s'appliquent aux contrôles de système. Pour de plus amples informations, veuillez consulter [Mode IPC](task_definition_parameters.md#task_definition_ipcmode). + Pour les tâches qui utilisent le mode IPC `host`, les `systemControls` liés à l'espace de noms IPC ne sont pas pris en charge. + Pour les tâches qui utilisent le mode IPC `task`, les valeurs des `systemControls` liés à l'espace de noms IPC s'appliquent à tous les conteneurs au sein d'une tâche. ``` "systemControls": [ { "namespace":"string", "value":"string" } ] ``` `namespace` Type : chaîne Obligatoire : non Paramètre du noyau de l’espace de noms pour lequel définir une `value`. Valeurs d'espace de noms IPC valides : `"kernel.msgmax" | "kernel.msgmnb" | "kernel.msgmni" | "kernel.sem" | "kernel.shmall" | "kernel.shmmax" | "kernel.shmmni" | "kernel.shm_rmid_forced"`, et `Sysctls` qui commencent par `"fs.mqueue.*"` Valeurs d’espace de noms de réseau valides : `Sysctls` qui commencent par `"net.*"` Sur Fargate, seuls les espaces de noms `Sysctls` existant dans le conteneur sont acceptés. Toutes ces valeurs sont prises en charge par Fargate. `value` Type : chaîne Obligatoire : non Valeur du paramètre du noyau de l’espace de noms spécifié dans `namespace`. #### Interactive `interactive` Type : booléen Obligatoire : non Lorsque ce paramètre est `true`, vous pouvez déployer des applications conteneurisées qui nécessitent l'allocation d'une `stdin` ou d'un `tty`. Ce paramètre correspond à `OpenStdin` dans la commande docker create-container et à l’option `--interactive` dans la commande docker run. La valeur par défaut est `false`. #### Pseudo Terminal `pseudoTerminal` Type : booléen Obligatoire : non Lorsque ce paramètre a la valeur `true`, un TTY est alloué. Ce paramètre correspond à `Tty` dans la commande docker create-container et à l’option `--tty` dans la commande docker run. La valeur par défaut est `false`. ### Paramètres Linux `linuxParameters` Type : objet [LinuxParameters](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LinuxParameters.html) Obligatoire : non Modifications spécifiques à Linux appliquées au conteneur, comme les capacités de noyau Linux. `capabilities` Type : objet [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html) Obligatoire : non Caractéristiques Linux du conteneur ajoutées ou supprimées de la configuration par défaut fournie par Docker. `devices` Type : tableau d'objets [Périphérique](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Device.html) Obligatoire : non Tous les périphériques hôtes à exposer au conteneur. Ce paramètre correspond à `Devices` dans la commande docker create-container et à l’option `--device` dans la commande docker run. `initProcessEnabled` Type : booléen Obligatoire : non Exécutez un processus `init` dans le conteneur afin de transmettre des signaux et de récolter les processus. Ce paramètre correspond à l’option `--init` de docker run. `maxSwap` Ce paramètre n’est pas pris en charge pour les tâches exécutées sur les instances gérées Amazon ECS. Type : Integer Obligatoire : non Quantité totale de mémoire d'échange (en Mio) qu'un conteneur peut utiliser. Ce paramètre est converti en l’option `--memory-swap` de la commande docker run, où la valeur est la somme de la mémoire du conteneur et de la valeur `maxSwap`. `swappiness` Ce paramètre n’est pas pris en charge pour les tâches exécutées sur les instances gérées Amazon ECS. Type : Integer Obligatoire : non Ce paramètre vous permet de régler le comportement d'échange de mémoire d'un conteneur. Si la valeur de `swappiness` est `0`, l'échange n'a pas lieu, sauf si cela s'avère absolument nécessaire. Avec la valeur `100` pour `swappiness`, l'échange de pages a lieu de manière très agressive. Les valeurs valides sont les nombres entiers compris entre `0` et `100`. Si le paramètre `swappiness` n'est pas spécifié, la valeur par défaut `60` est utilisée. Si aucune valeur n'est spécifiée pour `maxSwap`, le paramètre est ignoré. Ce paramètre correspond à l’option `--memory-swappiness` de docker run. `sharedMemorySize` Ce paramètre n’est pas pris en charge pour les tâches exécutées sur les instances gérées Amazon ECS. Type : Integer Obligatoire : non Taille (en Mio) du volume `/dev/shm`. Ce paramètre correspond à l’option `--shm-size` de docker run. `tmpfs` Type : tableau d'objets [Tmpfs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Tmpfs.html) Obligatoire : non Chemin du conteneur, options de montage et taille (en Mio) du montage tmpfs. Ce paramètre correspond à l’option `--tmpfs` de docker run. # Paramètres de définition de tâche Amazon ECS pour Fargate Les définitions de tâches sont divisées en plusieurs parties : la famille de tâches, le rôle de tâche Gestion des identités et des accès AWS (IAM), le mode réseau, les définitions de conteneurs, les volumes et les types de lancement. Les définitions de famille et de conteneur sont requises dans une définition de tâche. En revanche, le rôle de tâche, le mode réseau, les volumes et le type de lancement sont facultatifs. Vous pouvez utiliser ces paramètres dans un fichier JSON pour configurer votre définition de tâche. Voici des descriptions plus détaillées de chaque paramètre de définition de tâche pour Fargate. ## Family `family` Type : Chaîne Obligatoire : oui Lorsque vous enregistrez une définition de tâche, vous lui attribuez une famille. Cela équivaut, pour plusieurs versions de définition de tâche, à lui attribuer un nom spécifié avec un numéro de révision. La première définition de tâche enregistrée dans une famille donnée reçoit le numéro de révision 1. Toute définition de tâche enregistrée après celle-ci reçoit un numéro de révision ultérieur dans l'ordre séquentiel. ## Capacity Lorsque vous enregistrez une définition de tâche, vous pouvez spécifier la capacité par rapport à laquelle Amazon ECS doit valider la définition de tâche. Une exception client est renvoyée si la définition de tâche n'est pas conforme aux compatibilités spécifiées. Le paramètre suivant est autorisé dans une définition de tâche. `requiresCompatibilities` Type : tableau de chaînes Obligatoire : non Valeurs valides : `FARGATE` La capacité par rapport à laquelle valider la définition de tâche. Cela permet de lancer une vérification afin de s’assurer que tous les paramètres utilisés dans la définition de la tâche correspondent aux exigences de Fargate. ## Rôle de tâche `taskRoleArn` Type : chaîne Obligatoire : non Lorsque vous enregistrez une définition de tâche, vous pouvez attribuer un rôle de tâche à un rôle IAM qui permet aux conteneurs concernés par l'autorisation de tâche d'appeler AWS APIs les conteneurs spécifiés dans les politiques associées en votre nom. Pour de plus amples informations, veuillez consulter [rôle IAM de tâche Amazon ECS](task-iam-roles.md). ## Rôle d'exécution de tâche `executionRoleArn` Type : Chaîne Obligatoire : Conditionnelle Le nom de ressource Amazon (ARN) du rôle d'exécution des tâches qui autorise l'agent de conteneur Amazon ECS à effectuer des appels d' AWS API en votre nom. Le rôle IAM d'exécution de la tâche est requis en fonction des besoins de votre tâche. Pour de plus amples informations, veuillez consulter [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md). ## Mode réseau `networkMode` Type : Chaîne Obligatoire : oui Mode réseau Docker à utiliser pour les conteneurs de la tâche. Pour les tâches Amazon ECS hébergées sur Fargate, le mode réseau `awsvpc` est requis. ## Plateforme d'exécution `operatingSystemFamily` Type : Chaîne Obligatoire : Conditionnelle Par défaut : LINUX Ce paramètre est requis pour les tâches Amazon ECS hébergées sur Fargate. Lorsque vous enregistrez une définition de tâche, vous spécifiez la famille du système d'exploitation. Les valeurs valides sont `LINUX`, `WINDOWS_SERVER_2025_FULL`, `WINDOWS_SERVER_2025_CORE`, `WINDOWS_SERVER_2022_FULL`, `WINDOWS_SERVER_2022_CORE`, `WINDOWS_SERVER_2019_FULL` et `WINDOWS_SERVER_2019_CORE`. Toutes les définitions de tâches qui sont utilisées dans un service doivent avoir la même valeur pour ce paramètre. Lorsqu'une définition de tâche fait partie d'un service, cette valeur doit correspondre à la valeur `platformFamily` du service. `cpuArchitecture` Type : Chaîne Obligatoire : Conditionnelle Par défaut : X86\$164 Si le paramètre est laissé sur `null`, la valeur par défaut est automatiquement attribuée lors du lancement d'une tâche hébergée sur Fargate. Lorsque vous enregistrez une définition de tâche, vous spécifiez l'architecture du processeur. Les valeurs valides sont `X86_64` et `ARM64`. Toutes les définitions de tâches qui sont utilisées dans un service doivent avoir la même valeur pour ce paramètre. Lorsque vous avez des tâches Linux, vous pouvez définir la valeur sur `ARM64`. Pour de plus amples informations, veuillez consulter [Définitions de tâche Amazon ECS pour les charges de travail ARM 64 bits](ecs-arm64.md). ## Taille de la tâche Lorsque vous enregistrez une définition de tâche, vous pouvez spécifier la quantité totale d'UC et de mémoire utilisée pour cette tâche. Ces valeurs sont distinctes des valeurs `cpu` et `memory` au niveau de la définition de conteneur. Pour les tâches hébergées sur Fargate (Linux et Windows), ces champs sont obligatoires et des valeurs spécifiques sont disponibles selon le `cpu` et la `memory` pris en charge. Le paramètre suivant est autorisé dans une définition de tâche : `cpu` Type : Chaîne Obligatoire : oui Les paramètres d’UC et de mémoire au niveau de la tâche sont requis et utilisés pour déterminer le type et la taille de l’instance sur laquelle les tâches s’exécutent. Pour les tâches Windows, ces valeurs ne sont pas imposées au moment de l’exécution, car Windows ne dispose pas d’un mécanisme natif permettant d’appliquer facilement des limites de ressources collectives à un groupe de conteneurs. Si vous souhaitez imposer des limites de ressources, nous vous recommandons d’utiliser les ressources au niveau du conteneur pour les conteneurs Windows. Limite stricte du nombre d'unités UC à présenter pour la tâche. Vous pouvez spécifier les valeurs du processeur dans le fichier JSON sous forme de chaîne en unités de processeur ou en mode virtuel CPUs (vCPUs). Par exemple, vous pouvez spécifier une valeur de processeur soit `1024` en unités de processeur, soit `1 vCPU` en CPUs v. Lorsque la définition de tâche est enregistrée, une valeur vCPU est convertie en un entier indiquant les unités du processeur. Ce champ est obligatoire et vous devez utiliser l’une des valeurs suivantes, qui détermine la plage de valeurs prises en charge pour le paramètre `memory`. Le tableau suivant indique les combinaisons valides d'UC et de mémoire au niveau de la tâche. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/task_definition_parameters.html) `memory` Type : Chaîne Obligatoire : oui Les paramètres d’UC et de mémoire au niveau de la tâche sont requis et utilisés pour déterminer le type et la taille de l’instance sur laquelle les tâches s’exécutent. Pour les tâches Windows, ces valeurs ne sont pas imposées au moment de l’exécution, car Windows ne dispose pas d’un mécanisme natif permettant d’appliquer facilement des limites de ressources collectives à un groupe de conteneurs. Si vous souhaitez imposer des limites de ressources, nous vous recommandons d’utiliser les ressources au niveau du conteneur pour les conteneurs Windows. Limite stricte de quantité de mémoire à allouer à la tâche. Vous pouvez spécifier les valeurs de mémoire dans la définition de la tâche sous forme de chaîne en mébioctets (Mio) ou en gigaoctets (Go). Par exemple, vous pouvez spécifier une valeur de mémoire de `3072` en Mio ou de `3 GB` en Go. Lorsque la définition de tâche est enregistrée, la valeur en Go est convertie en un nombre entier indiquant la quantité de Mio. Ce champ est obligatoire et vous devez utiliser l’une des valeurs suivantes, qui détermine la plage de valeurs prises en charge pour le paramètre `cpu` : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/task_definition_parameters.html) ## Définitions de conteneur Lorsque vous enregistrez une définition de tâche, vous devez spécifier une liste de définitions de conteneur qui sont transmises au démon Docker sur une instance de conteneur. Les paramètres suivants sont autorisés dans une définition de conteneur. **Topics** + [ ### Paramètres de définition de conteneur standards ](#standard_container_definition_params) + [ ### Paramètres de définition de conteneur avancés ](#advanced_container_definition_params) + [ ### Autres paramètres de définition de conteneur ](#other_container_definition_params) ### Paramètres de définition de conteneur standards Les paramètres de définition de tâche suivants sont obligatoires ou utilisés dans la plupart des définitions de conteneur. **Topics** + [ #### Nom ](#container_definition_name) + [ #### Image ](#container_definition_image) + [ #### Mémoire ](#container_definition_memory) + [ #### Mappages de ports ](#container_definition_portmappings) + [ #### Informations d'identification du référentiel privé ](#container_definition_repositoryCredentials) #### Nom `name` Type : Chaîne Obligatoire : oui Le nom d'un conteneur. Jusqu'à 255 lettres (majuscules et minuscules), chiffres, traits d'union et traits de soulignement sont autorisés. Si vous associez plusieurs conteneurs dans une définition de tâche, vous pouvez spécifier l'option `name` d'un conteneur dans l'option `links` d'un autre conteneur. Cela permet de connecter les conteneurs. #### Image `image` Type : Chaîne Obligatoire : oui Image utilisée pour démarrer un conteneur. Cette chaîne est transmise directement au démon Docker. Par défaut, les images dans le registre Docker Hub sont disponibles. Vous pouvez également spécifier d'autres référentiels avec soit `repository-url/image:tag`, soit `repository-url/image@digest`. Il peut comporter jusqu'à 255 lettres (majuscules et minuscules), des chiffres, des tirets, des traits de soulignement, deux points, des points, des barres obliques et des signes dièse. Ce paramètre correspond à `Image` dans la commande docker create-container et au paramètre `IMAGE` de la commande docker run. + Lorsqu'une nouvelle tâche démarre, l'agent de conteneur Amazon ECS extrait la version la plus récente de l'image et de l'étiquette spécifiées afin que le conteneur puisse les utiliser. Notez cependant que les mises à jour ultérieures apportées à une image de référentiel ne sont pas répercutées sur les tâches déjà en cours d'exécution. + Lorsque vous ne spécifiez pas de balise ou de résumé dans le chemin de l'image dans la définition de tâche, l'agent de conteneur Amazon ECS utilise la `latest` balise pour extraire l'image spécifiée. + Les mises à jour ultérieures d'une image de référentiel ne sont pas répercutées sur les tâches déjà en cours d'exécution. + Les images des registres privés sont prises en charge. Pour de plus amples informations, veuillez consulter [Utilisation d'images autres que des AWS conteneurs dans Amazon ECS](private-auth.md). + Les images des référentiels Amazon ECR peuvent être spécifiées en utilisant soit la convention de dénomination complète `registry/repository:tag` ou `registry/repository@digest` (par exemple, `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app:latest` ou `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE`). + Les images dans les référentiels officiels sur Docker Hub utilisent un nom unique (par exemple, `ubuntu` ou `mongo`). + Les images dans les autres référentiels sur Docker Hub sont qualifiées par un nom d'organisation (par exemple, `amazon/amazon-ecs-agent`). + Les images dans les autres référentiels en ligne sont qualifiées par un nom de domaine (par exemple, `quay.io/assemblyline/ubuntu`). `versionConsistency` Type : Chaîne Valeurs valides : `enabled`\$1`disabled` Obligatoire : non Spécifie si Amazon ECS résoudra la balise d’image de conteneur fournie dans la définition du conteneur en un condensé d’image. Par défaut, ce comportement est `enabled`. Si vous définissez la valeur d’un conteneur sur `disabled`, Amazon ECS ne résoudra pas la balise d’image de conteneur en un condensé et utilisera l’URI d’image d’origine spécifiée dans la définition du conteneur pour le déploiement. Pour plus d’informations sur la résolution des images de conteneur, consultez la section [Résolution des images de conteneurs](deployment-type-ecs.md#deployment-container-image-stability). #### Mémoire `memory` Type : Integer Obligatoire : non La quantité de mémoire (en Mio) à présenter au conteneur. Si votre conteneur tente de dépasser la mémoire spécifiée ici, il sera désactivé. La quantité totale de mémoire réservée pour tous les conteneurs au sein d'une tâche doit être inférieure à la valeur `memory` de la tâche, si cette valeur est spécifiée. Ce paramètre correspond à `Memory` dans la commande docker create-container et à l’option `--memory` dans la commande docker run. Le démon Docker 20.10.0 ou ultérieur réserve un minimum de 6 Mio de mémoire pour un conteneur. Par conséquent, ne spécifiez pas moins de 6 Mio de mémoire pour vos conteneurs. Le démon Docker 19.03.13-ce ou antérieur réserve un minimum de 4 Mio de mémoire pour un conteneur. Par conséquent, ne spécifiez pas moins de 4 Mio de mémoire pour vos conteneurs. Si vous essayez d'optimiser l'utilisation de vos ressources en fournissant à vos tâches autant de mémoire que possible pour un type d'instance particulier, consultez [Réservation de mémoire pour une instance de conteneur Amazon ECS Linux](memory-management.md). `memoryReservation` Type : Integer Obligatoire : non La limite flexible (en Mio) de mémoire à réserver pour le conteneur. En cas de contention de la mémoire système, Docker tente de garder la mémoire du conteneur en deçà de cette limite flexible. Toutefois, votre conteneur peut utiliser davantage de mémoire en cas de besoin. Le conteneur peut consommer jusqu'à la limite stricte spécifiée avec le paramètre `memory` (le cas échéant), ou la totalité de la mémoire disponible sur l'instance de conteneur, selon la première valeur atteinte. Ce paramètre correspond à `MemoryReservation` dans la commande docker create-container et à l’option `--memory-reservation` dans la commande docker run. Si aucune valeur de mémoire au niveau de la tâche n'est spécifiée, vous devez indiquer un nombre entier différent de zéro pour `memory` ou `memoryReservation` dans une définition de conteneur. Si vous spécifiez les deux, `memory` doit être supérieur à `memoryReservation`. Si vous spécifiez `memoryReservation`, cette valeur est soustraite des ressources mémoire disponibles pour l'instance de conteneur sur laquelle le conteneur est placé. Sinon, c'est la valeur `memory` qui est utilisée. Par exemple, supposons que votre conteneur utilise normalement 128 Mio de mémoire, mais qu'il lui arrive d'utiliser jusqu'à 256 Mio de mémoire pendant de courtes périodes. Vous pouvez définir une `memoryReservation` de 128 Mio et une limite stricte `memory` de 300 Mio. Cette configuration permet au conteneur de ne réserver que 128 Mio de mémoire à partir des ressources restantes sur l'instance de conteneur. En même temps, cette configuration permet également au conteneur d'utiliser davantage de ressources mémoire lorsque cela est nécessaire. Ce paramètre n'est pas pris en charge par les conteneurs Windows. Le démon Docker 20.10.0 ou ultérieur réserve un minimum de 6 Mio de mémoire pour un conteneur. Par conséquent, ne spécifiez pas moins de 6 Mio de mémoire pour vos conteneurs. Le démon Docker 19.03.13-ce ou antérieur réserve un minimum de 4 Mio de mémoire pour un conteneur. Par conséquent, ne spécifiez pas moins de 4 Mio de mémoire pour vos conteneurs. Si vous essayez d'optimiser l'utilisation de vos ressources en fournissant à vos tâches autant de mémoire que possible pour un type d'instance particulier, consultez [Réservation de mémoire pour une instance de conteneur Amazon ECS Linux](memory-management.md). #### Mappages de ports `portMappings` Type : tableau d'objets Obligatoire : non Les mappages de ports exposent les ports réseau de votre conteneur au monde extérieur, ce qui permet aux clients d’accéder à votre application. Ils sont également utilisés pour la communication entre conteneurs au sein d’une même tâche. Pour les définitions de tâche qui utilisent le mode réseau `awsvpc`, spécifiez uniquement `containerPort`. Le `hostPort` est toujours ignoré et le port du conteneur est automatiquement mappé à un port aléatoire portant un numéro élevé sur l’hôte. Les mappages de ports sur Windows utilisent l'adresse de passerelle `NetNAT` plutôt que `localhost`. Il n'existe aucune boucle pour les mappages de ports sous Windows, donc vous ne pouvez pas accéder au port mappé d'un conteneur à partir de l'hôte lui-même. La plupart des champs de ce paramètre (y compris `containerPort`, `hostPort`, `protocol`) correspondent à `PortBindings` dans la commande docker create-container et à l’option `--publish` de docker run. Si le mode réseau d'une définition de tâche est défini sur `host`, les ports hôtes doivent être indéfinis ou correspondre au port du conteneur dans le mappage de port. Une fois qu'une tâche passe à l'état `RUNNING`, les affectations manuelles et automatiques de ports de conteneur et d'hôte sont visibles aux emplacements suivants : + Console : la section **Network Bindings** (Liaisons réseau) de la description d'un conteneur pour une tâche sélectionnée. + AWS CLI : la section `networkBindings` de la sortie de la commande **describe-tasks**. + API : la réponse `DescribeTasks`. + Métadonnées : point de terminaison des métadonnées de la tâche. `appProtocol` Type : chaîne Obligatoire : non Protocole d'application utilisé pour le mappage de port. Ce paramètre s'applique uniquement à Service Connect. Nous vous conseillons de définir ce paramètre de manière cohérente avec le protocole que votre application utilise. Si vous définissez ce paramètre, Amazon ECS ajoute une gestion de connexion spécifique au protocole au proxy Service Connect. Si vous définissez ce paramètre, Amazon ECS ajoute une télémétrie spécifique au protocole dans la console Amazon ECS et. CloudWatch Si vous ne définissez aucune valeur pour ce paramètre, le protocole TCP est utilisé. Toutefois, Amazon ECS n'ajoute pas de télémétrie spécifique au protocole pour TCP. Pour de plus amples informations, veuillez consulter [Utilisation de Service Connect pour connecter des services Amazon ECS avec des noms abrégés](service-connect.md). Valeurs de protocole valides : `"http" | "http2" | "grpc" ` `containerPort` Type : Integer Obligatoire : oui, lorsque des objets `portMappings` sont utilisés Le numéro de port sur le conteneur qui est lié au port hôte spécifié par l'utilisateur ou affecté automatiquement. Pour les tâches utilisant le mode réseau `awsvpc`, vous utilisez `containerPort` pour spécifier les ports exposés. Pour les conteneurs Windows sur Fargate, vous ne pouvez pas utiliser le port 3 150 pour `containerPort`. C'est parce qu'il est réservé. `containerPortRange` Type : chaîne Obligatoire : non Plage de numéros de port du conteneur liée à la plage de ports hôtes mappés dynamiquement. Vous ne pouvez définir ce paramètre qu'à l'aide de l'API `register-task-definition`. L'option est disponible dans le paramètre `portMappings`. Pour plus d'informations, consultez [register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html) dans la *référence AWS Command Line Interface *. Les règles suivantes s'appliquent lorsque vous spécifiez une `containerPortRange` : + Vous devez utiliser le mode réseau `awsvpc`. + Ce paramètre est disponible pour les systèmes d'exploitation Windows et Linux. + L'instance de conteneur doit au moins disposer de la version 1.67.0 de l'agent de conteneur et au moins de la version 1.67.0-1 du package `ecs-init`. + Vous pouvez spécifier un maximum de 100 plages de ports pour chaque conteneur. + Vous ne spécifiez pas de `hostPortRange`. La valeur de `hostPortRange` est définie comme suit : + Pour les conteneurs d'une tâche en mode réseau `awsvpc`, le `hostPort` est défini sur la même valeur que le `containerPort`. Il s'agit d'une stratégie de mappage statique. + Les valeurs valides de `containerPortRange` sont comprises entre 1 et 65535. + Un port peut uniquement être inclus dans un mappage de port pour chaque conteneur. + Vous ne pouvez pas spécifier de plages de ports qui se chevauchent. + Le premier port de la plage doit être inférieur au dernier port de la plage. + Docker vous recommande de désactiver le proxy Docker dans le fichier de configuration du démon Docker en présence d'un grand nombre de ports. Pour plus d'informations, consultez le [numéro \$111185](https://github.com/moby/moby/issues/11185) sur GitHub. Pour plus d'informations sur la désactivation du proxy Docker dans le fichier de configuration du démon Docker, veuillez consulter [Démon Docker](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon) dans le *Guide du développeur Amazon ECS* (langue française non garantie). Vous pouvez appeler [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) pour voir la `hostPortRange` correspondant aux ports hôtes liés aux ports de conteneur. Les plages de ports ne sont pas incluses dans les événements de tâches Amazon ECS, qui sont envoyés à EventBridge. Pour de plus amples informations, veuillez consulter [Automatisez les réponses aux erreurs Amazon ECS à l'aide de EventBridge](cloudwatch_event_stream.md). `hostPortRange` Type : chaîne Obligatoire : non Plage de numéros de port sur l'hôte utilisée avec la liaison réseau. Elle est attribuée par Docker et délivrée par l'agent Amazon ECS. `hostPort` Type : Integer Obligatoire : non Le numéro de port sur l'instance de conteneur à réserver pour votre conteneur. Le `hostPort` peut rester vide ou avoir la même valeur que `containerPort`. La plage de ports éphémères par défaut pour Docker 1.6.0 et versions ultérieures est répertoriée dans l'instance sous `/proc/sys/net/ipv4/ip_local_port_range`. Si ce paramètre de noyau n'est pas disponible, la plage de ports éphémères par défaut de `49153–65535` est utilisée. N'essayez pas de spécifier un port d'hôte dans la plage de ports éphémères. Cela est dû au fait qu'ils sont réservés à une affectation automatique. En général, les ports inférieurs à `32768` ne sont pas compris dans la plage de ports éphémères. Les ports réservés par défaut sont le port `22` pour SSH, les ports Docker `2375` et `2376`, et les ports d'agent de conteneur Amazon ECS `51678-51680`. Tout port hôte ayant été spécifié précédemment par l'utilisateur pour une tâche en cours d'exécution est également réservé pendant l'exécution de la tâche. Après l'arrêt d'une tâche, le port hôte est libéré. Les ports réservés actuels s'affichent dans le champ `remainingResources` de la sortie **describe-container-instances**. Une instance de conteneur peut avoir jusqu'à 100 ports réservés à la fois, y compris les ports réservés par défaut. Les ports affectés automatiquement ne sont pas pris en compte dans le quota des 100 ports réservés. `name` Type : Chaîne Obligatoire : Non, requis pour que Service Connect et VPC Lattice soient configurés dans un service Nom utilisé pour le mappage de port. Ce paramètre ne s’applique qu’à Service Connect et VPC Lattice. Ce paramètre correspond au nom que vous utilisez dans la configuration Service Connect et VPC Lattice d’un service. Pour de plus amples informations, veuillez consulter [Utilisation de Service Connect pour connecter des services Amazon ECS avec des noms abrégés](service-connect.md). Dans l’exemple suivant, les deux champs obligatoires pour Service Connect et VPC Lattice sont utilisés. ``` "portMappings": [ { "name": string, "containerPort": integer } ] ``` `protocol` Type : chaîne Obligatoire : non Le protocole utilisé pour le mappage de port. Les valeurs valides sont `tcp` et `udp`. La valeur par défaut est `tcp`. Seul `tcp` est pris en charge pour Service Connect. N'oubliez pas que `tcp` est implicite si ce champ n'est pas défini. Si vous spécifiez un port hôte, utilisez la syntaxe suivante. ``` "portMappings": [ { "containerPort": integer, "hostPort": integer } ... ] ``` Si vous souhaitez utiliser un port hôte affecté automatiquement, utilisez la syntaxe suivante. ``` "portMappings": [ { "containerPort": integer } ... ] ``` #### Informations d'identification du référentiel privé `repositoryCredentials` Type : objet [RepositoryCredentials](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RepositoryCredentials.html) Obligatoire : non Informations d'identification du référentiel pour l'authentification de registre privé. Pour de plus amples informations, veuillez consulter [Utilisation d'images autres que des AWS conteneurs dans Amazon ECS](private-auth.md). `credentialsParameter` Type : Chaîne Obligatoire : oui, lorsque des objets `repositoryCredentials` sont utilisés L'Amazon Resource Name (ARN) du secret contenant les informations d'identification du référentiel privé. Pour de plus amples informations, veuillez consulter [Utilisation d'images autres que des AWS conteneurs dans Amazon ECS](private-auth.md). Lorsque vous utilisez l'API Amazon ECS AWS CLI AWS SDKs, ou si le secret existe dans la même région que la tâche que vous lancez, vous pouvez utiliser l'ARN complet ou le nom du secret. Lorsque vous utilisez le AWS Management Console, vous devez spécifier l'ARN complet du secret. Voici un extrait de code d'une définition de tâche indiquant les paramètres requis : ``` "containerDefinitions": [ { "image": "private-repo/private-image", "repositoryCredentials": { "credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name" } } ] ``` ### Paramètres de définition de conteneur avancés Les paramètres de définition de conteneur avancés suivants étendent les capacités de la commande docker run qui est utilisée pour lancer des conteneurs sur vos instances de conteneur Amazon ECS. **Topics** + [ #### Politique de redémarrage ](#container_definition_restart_policy) + [ #### Surveillance de l'état ](#container_definition_healthcheck) + [ #### Environnement ](#container_definition_environment) + [ #### Paramètres réseau ](#container_definition_network) + [ #### Stockage et journalisation ](#container_definition_storage) + [ #### Sécurité ](#container_definition_security) + [ #### Limites des ressources ](#container_definition_limits) + [ #### Étiquettes Docker ](#container_definition_labels) #### Politique de redémarrage `restartPolicy` La politique de redémarrage du conteneur et les paramètres de configuration associés. Lorsque vous configurez une politique de redémarrage pour un conteneur, Amazon ECS peut redémarrer le conteneur sans avoir à remplacer la tâche. Pour de plus amples informations, veuillez consulter [Redémarrage de conteneurs individuels dans les tâches Amazon ECS à l’aide de politiques de redémarrage de conteneurs](container-restart-policy.md). `enabled` Type : Boolean Obligatoire : oui Spécifie si une politique de redémarrage est activée pour le conteneur. `ignoredExitCodes` Type : tableau integer Obligatoire : non Liste des codes de sortie qu’Amazon ECS ignorera et pour lesquels il ne tentera pas de redémarrage. Vous pouvez spécifier un maximum de 50 codes de sortie de conteneur. Par défaut, Amazon ECS n’ignore aucun code de sortie. `restartAttemptPeriod` Type : Integer Obligatoire : non Durée (en secondes) pendant laquelle le conteneur doit fonctionner avant de pouvoir tenter un redémarrage. Un conteneur ne peut être redémarré qu’une fois toutes les `restartAttemptPeriod` secondes. Si un conteneur n’est pas en mesure de fonctionner pendant cette période et qu’il se ferme prématurément, il ne sera pas redémarré. Vous pouvez définir une `restartAttemptPeriod` minimale de 60 secondes et une `restartAttemptPeriod` maximale de 1 800 secondes. Par défaut, un conteneur doit fonctionner pendant 300 secondes avant de pouvoir être redémarré. #### Surveillance de l'état `healthCheck` Commande de surveillance de l'état du conteneur et paramètres de configuration associés pour le conteneur. Pour de plus amples informations, veuillez consulter [Détermination de l’état des tâches Amazon ECS à l’aide de la surveillance de l’état des conteneurs](healthcheck.md). `command` Tableau de chaînes représentant la commande que le conteneur exécute pour déterminer si celle-ci est saine. Le tableau de chaînes peut commencer par `CMD` pour exécuter directement les arguments de la commande, ou par `CMD-SHELL` pour exécuter la commande avec le shell par défaut du conteneur. Si vous n'en spécifiez aucun, `CMD` est utilisé. Lorsque vous enregistrez une définition de tâche dans le AWS Management Console, utilisez une liste de commandes séparées par des virgules. Ces commandes sont converties en une chaîne une fois la définition de tâche créée. Un exemple d'entrée pour une surveillance de l'état est le suivant. ``` CMD-SHELL, curl -f http://localhost/ || exit 1 ``` Lorsque vous enregistrez une définition de tâche à l'aide du AWS CLI panneau AWS Management Console JSON APIs, placez la liste des commandes entre crochets. Un exemple d'entrée pour une surveillance de l'état est le suivant. ``` [ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ] ``` Un code de sortie de 0, avec aucune sortie `stderr`, indique la réussite et un code de sortie autre que zéro indique qu'il s'agit d'un échec. `interval` La durée (en secondes) entre chaque surveillance de l'état. Vous pouvez indiquer une durée comprise entre 5 et 300 secondes. La valeur par défaut est de 30 secondes. `timeout` La durée (en secondes) d'attente pour qu'une surveillance de l'état réussisse avant qu'elle ne soit considérée comme un échec. Vous pouvez indiquer une durée comprise entre 2 et 60 secondes. La valeur par défaut est de 5 secondes. `retries` Nombre de nouvelles tentatives d'exécution d'une surveillance de l'état ayant échoué avant que le conteneur soit considéré comme défectueux. Vous pouvez indiquer un nombre de tentatives compris en 1 et 10. La valeur par défaut est de trois tentatives. `startPeriod` La période de grâce facultative pour donner aux conteneurs le temps de démarrer avant l'échec des surveillance de l'état est prise en compte dans le nombre maximal de tentatives. Vous pouvez spécifier une valeur comprise entre 0 et 300. Par défaut, la `startPeriod` est désactivée. Si une vérification de l'état aboutit dans le délai défini par `startPeriod`, le conteneur est considéré comme sain et toutes les défaillances suivantes sont prises en compte dans le nombre maximal de nouvelles tentatives. #### Environnement `cpu` Type : Integer Obligatoire : non Le nombre d'unités `cpu` que l'agent de conteneur Amazon ECS réserve pour le conteneur. Sous Linux, ce paramètre correspond à `CpuShares` dans la section [Créer un conteneur](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate). Ce champ est facultatif pour les tâches qui utilisent Fargate. La quantité totale de processeurs réservée pour tous les conteneurs au sein d'une tâche doit être inférieure à la valeur `cpu` au niveau de la tâche. Les conteneurs Linux partagent des unités de processeur non allouées avec les autres conteneurs de l'instance de conteneur selon le même ratio que la quantité allouée. Par exemple, supposons que vous exécutez une tâche à conteneur unique sur un type d'instance à cœur unique avec 512 unités de processeur spécifiées pour ce conteneur. De plus, cette tâche est la seule tâche en cours d'exécution sur l'instance de conteneur. Dans cet exemple, le conteneur peut utiliser le partage complet de 1 024 unités UC à tout moment. Toutefois, supposons que vous ayez lancé une autre copie de la même tâche sur cette instance de conteneur. Un minimum de 512 unités de processeur est affecté à chaque tâche si nécessaire. De même, si l'autre conteneur n'utilise pas le processeur restant, chaque conteneur peut bénéficier d'une utilisation plus importante du processeur. Toutefois, si les deux tâches sont actives à 100 % en permanence, elles sont limitées à 512 unités d'UC. Sur les instances de conteneur Linux, le démon Docker de l'instance de conteneur se sert de la valeur de processeur pour calculer les ratios de partage de processeur relatifs pour les conteneurs en cours d'exécution. La valeur de parts d’UC minimale autorisée par le noyau Linux est de 2, et la valeur de parts d’UC maximale autorisée par le noyau Linux est de 262 144. Toutefois, le paramètre UC n’est pas obligatoire et vous pouvez utiliser des valeurs d’UC inférieures à 2 ou supérieures à 262 144 dans vos définitions de conteneur. Pour les valeurs d’UC inférieures à 2 (y compris null) ou supérieures à 262 144, le comportement varie selon la version de l’agent de conteneur Amazon ECS : Sur les instances de conteneur Windows, le quota de processeur est appliqué comme quota absolu. Les conteneurs Windows n'ont accès qu'à la quantité spécifiée de processeur décrite dans la définition de tâche. Une valeur de processeur nulle ou égale à zéro est transmise à Docker comme étant `0`. Windows interprète ensuite cette valeur comme 1 % d'un processeur. Pour voir d'autres exemples, veuillez consulter le billet de blog [How Amazon ECS manages CPU and memory resources](https://aws.amazon.com/blogs/containers/how-amazon-ecs-manages-cpu-and-memory-resources/). `gpu` Ce paramètre n’est pas pris en charge pour les conteneurs hébergés sur Fargate. Type : objet [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obligatoire : non Le nombre de `GPUs` physiques que l'agent de conteneur Amazon ECS réserve pour le conteneur. Le nombre de conteneurs GPUs réservés à tous les conteneurs d'une tâche ne doit pas dépasser le nombre de conteneurs disponibles GPUs sur l'instance de conteneur sur laquelle la tâche est lancée. Pour de plus amples informations, veuillez consulter [Définitions de tâches Amazon ECS pour les charges de travail GPU](ecs-gpu.md). `Elastic Inference accelerator` Ce paramètre n’est pas pris en charge pour les conteneurs hébergés sur Fargate. Type : objet [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obligatoire : non Pour le type `InferenceAccelerator`, `value` correspond à `deviceName` d'un `InferenceAccelerator` spécifié dans une définition de tâche. Pour de plus amples informations, veuillez consulter [Nom de l'accélérateur Elastic Inference (obsolète)](#elastic-Inference-accelerator). `essential` Type : booléen Obligatoire : non Supposons que le paramètre `essential` d'un conteneur soit marqué comme `true`, et que ce conteneur échoue ou s'arrête pour une raison quelconque. Ensuite, tous les autres conteneurs qui font partie de la tâche sont arrêtés. Si le paramètre `essential` d'un conteneur a la valeur `false`, son échec n'a pas d'incidence sur le reste des conteneurs dans la tâche. Si ce paramètre n'est pas spécifié, le conteneur est supposé essentiel. Toutes les tâches doivent comporter au moins un conteneur essentiel. Supposons que vous disposiez d'une application composée de plusieurs conteneurs. Ensuite, les conteneurs de groupes qui sont utilisés dans un même but pour former des composants, et séparer les différents composants en plusieurs définitions de tâches. Pour de plus amples informations, veuillez consulter [Architecture de votre application pour Amazon ECS](application_architecture.md). ``` "essential": true|false ``` `entryPoint` Les premières versions de l'agent de conteneur Amazon ECS ne traitent pas correctement les paramètres `entryPoint`. Si vous rencontrez des difficultés pour utiliser `entryPoint`, mettez à jour l'agent de conteneur ou saisissez plutôt vos commandes et vos arguments sous forme d'éléments de tableau `command`. Type : tableau de chaînes Obligatoire : non Point d'entrée qui est transmis au conteneur. ``` "entryPoint": ["string", ...] ``` `command` Type : tableau de chaînes Obligatoire : non La commande transmise au conteneur. Ce paramètre correspond à `Cmd` dans la commande create-container et au paramètre `COMMAND` de docker run. S'il existe plusieurs arguments, assurez-vous que chaque argument est une chaîne séparée dans le tableau. ``` "command": ["string", ...] ``` `workingDirectory` Type : chaîne Obligatoire : non Répertoire de travail dans lequel exécuter les commandes à l'intérieur du conteneur. Ce paramètre correspond à `WorkingDir` dans la section [Create a container](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) (Créer un conteneur) de l'[API Docker à distance](https://docs.docker.com/reference/api/engine/version/v1.38/) et l'option `--workdir` correspond à [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/). ``` "workingDirectory": "string" ``` `environmentFiles` Il n’est pas disponible pour les conteneurs Windows sur Fargate. Type : tableau d'objets Obligatoire : non Liste des fichiers contenant les variables d'environnement à transmettre à un conteneur. Ce paramètre correspond à l’option `--env-file` de la commande docker run. Vous pouvez spécifier jusqu'à dix fichiers d'environnement. Le fichier doit avoir une extension de fichier `.env`. Chaque ligne d'un fichier d'environnement contient une variable d'environnement au format `VARIABLE=VALUE`. Les lignes commençant par `#` sont traitées comme des commentaires et sont ignorées. Si des variables d'environnement individuelles sont spécifiées dans la définition du conteneur, elles ont priorité sur les variables contenues dans un fichier d'environnement. Si plusieurs fichiers d'environnement contenant la même variable sont spécifiés, ils sont traités de haut en bas. Nous vous recommandons d'utiliser des noms de variables uniques. Pour de plus amples informations, veuillez consulter [Transmission d’une variable d’environnement individuelle à un conteneur Amazon ECS](taskdef-envfiles.md). `value` Type : Chaîne Obligatoire : oui L'Amazon Resource Name (ARN) de l'objet Amazon S3 contenant le fichier de variable d'environnement. `type` Type : Chaîne Obligatoire : oui Type de fichier à utiliser La seule valeur prise en charge est `s3`. `environment` Type : tableau d'objets Obligatoire : non Variables d'environnement à transmettre à un conteneur. Ce paramètre correspond à `Env` dans la commande docker create-container et à l’option `--env` dans la commande docker run. Nous déconseillons l'utilisation des variables d'environnement en texte clair pour les informations sensibles, comme les données d'identification. `name` Type : Chaîne Obligatoire : oui lorsque `environment` est utilisé Nom de la variable d'environnement. `value` Type : Chaîne Obligatoire : oui lorsque `environment` est utilisé Valeur de la variable d'environnement. ``` "environment" : [ { "name" : "string", "value" : "string" }, { "name" : "string", "value" : "string" } ] ``` `secrets` Type : tableau d'objets Obligatoire : non Objet représentant le secret à exposer à votre conteneur. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur Amazon ECS](specifying-sensitive-data.md). `name` Type : Chaîne Obligatoire : oui Valeur à définir comme variable d'environnement sur le conteneur. `valueFrom` Type : Chaîne Obligatoire : oui Secret à exposer au conteneur. Les valeurs prises en charge sont soit le nom Amazon Resource (ARN) complet du AWS Secrets Manager secret, soit l'ARN complet du paramètre dans le AWS Systems Manager Parameter Store. Si le paramètre Systems Manager Parameter Store ou le paramètre Secrets Manager existe au même endroit Région AWS que la tâche que vous lancez, vous pouvez utiliser l'ARN complet ou le nom du secret. Si le paramètre existe dans une autre région, l'ARN complet doit être spécifié. ``` "secrets": [ { "name": "environment_variable_name", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name" } ] ``` #### Paramètres réseau `disableNetworking` Ce paramètre n’est pas pris en charge pour les tâches exécutées sur Fargate. Type : booléen Obligatoire : non Quand ce paramètre a la valeur true, la mise en réseau est désactivée dans le conteneur. La valeur par défaut est `false`. ``` "disableNetworking": true|false ``` `links` Ce paramètre n’est pas pris en charge pour les tâches qui utilisent le mode réseau `awsvpc`. Type : tableau de chaînes Obligatoire : non Le paramètre `link` permet aux conteneurs de communiquer entre eux sans avoir besoin de définir des mappages de ports. Ce paramètre n'est pris en charge que si le mode réseau d'une définition de tâche est défini sur `bridge`. La construction `name:internalName` est analogue à `name:alias` dans les liaisons Docker. Il peut comporter jusqu’à 255 lettres (majuscules et minuscules), des chiffres, des tirets ou des traits de soulignement. Des conteneurs situés sur la même instance de conteneur peuvent communiquer entre eux sans nécessiter de liens ou de mappages de ports hôtes. L'isolation réseau sur une instance de conteneur est contrôlée par les groupes de sécurité et les paramètres de VPC. ``` "links": ["name:internalName", ...] ``` `hostname` Type : chaîne Obligatoire : non Nom d'hôte à utiliser pour votre conteneur. Ce paramètre correspond à `Hostname` dans docker create-container et à l’option `--hostname` de docker run. Si vous utilisez le mode réseau `awsvpc`, le paramètre `hostname` n'est pas pris en charge. ``` "hostname": "string" ``` `dnsServers` Il n’est pas pris en charge pour les tâches exécutées sur Fargate. Type : tableau de chaînes Obligatoire : non Liste de serveurs DNS qui sont présentés au conteneur. ``` "dnsServers": ["string", ...] ``` `extraHosts` Ce paramètre n’est pas pris en charge pour les tâches qui utilisent le mode réseau `awsvpc`. Type : tableau d'objets Obligatoire : non Liste de noms d'hôte et de mappages d'adresses IP à ajouter au fichier `/etc/hosts` dans le conteneur. Ce paramètre correspond à `ExtraHosts` dans la commande docker create-container et à l’option `--add-host` dans la commande docker run. ``` "extraHosts": [ { "hostname": "string", "ipAddress": "string" } ... ] ``` `hostname` Type : Chaîne Obligatoire : oui, lorsque des objets `extraHosts` sont utilisés Nom d'hôte à utiliser dans l'entrée `/etc/hosts`. `ipAddress` Type : Chaîne Obligatoire : oui, lorsque des objets `extraHosts` sont utilisés Adresse IP à utiliser dans l'entrée `/etc/hosts`. #### Stockage et journalisation `readonlyRootFilesystem` Type : booléen Obligatoire : non Quand ce paramètre a la valeur true, le conteneur ne dispose que d'un accès en lecture seule au système de fichiers racine. Ce paramètre correspond à `ReadonlyRootfs` dans la commande docker create-container et à l’option `--read-only` dans la commande docker run. Ce paramètre n'est pas pris en charge par les conteneurs Windows. La valeur par défaut est `false`. ``` "readonlyRootFilesystem": true|false ``` `mountPoints` Type : tableau d'objets Obligatoire : non Les points de montage pour les volumes de données dans votre conteneur. Ce paramètre correspond à `Volumes` dans l’API Docker create-container et à l’option `--volume` de docker run. Les conteneurs Windows peuvent monter des répertoires entiers sur le même lecteur que `$env:ProgramData`. Les conteneurs Windows ne peuvent pas monter de répertoires sur un autre lecteur, et les points de montage ne peuvent pas être utilisés sur plusieurs lecteurs. Vous devez spécifier des points de montage pour associer un volume Amazon EBS directement à une tâche Amazon ECS. `sourceVolume` Type : Chaîne Obligatoire : oui, lorsque des objets `mountPoints` sont utilisés Nom du volume à monter. `containerPath` Type : Chaîne Obligatoire : oui, lorsque des objets `mountPoints` sont utilisés Le chemin dans le conteneur où le volume sera monté. `readOnly` Type : booléen Obligatoire : non Si cette valeur est `true`, le conteneur ne peut accéder au volume qu'en lecture. Si cette valeur est `false`, le conteneur peut écrire sur le volume. La valeur par défaut est `false`. Pour les tâches exécutées sur des instances EC2 exécutant le système d’exploitation Windows, laissez la valeur `false` par défaut. `volumesFrom` Type : tableau d'objets Obligatoire : non Volumes de données à monter à partir d'un autre conteneur. Ce paramètre correspond à `VolumesFrom` dans la commande docker create-container et à l’option `--volumes-from` dans la commande docker run. `sourceContainer` Type : Chaîne Obligatoire : oui lorsque `volumesFrom` est utilisé Nom du conteneur à partir duquel monter les volumes. `readOnly` Type : booléen Obligatoire : non Si cette valeur est `true`, le conteneur ne peut accéder au volume qu'en lecture. Si cette valeur est `false`, le conteneur peut écrire sur le volume. La valeur par défaut est `false`. ``` "volumesFrom": [ { "sourceContainer": "string", "readOnly": true|false } ] ``` `logConfiguration` Type : [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html)Objet Obligatoire : non Spécification de configuration du journal pour le conteneur. Pour obtenir des exemples de définitions de tâche qui utilisent une configuration de journaux, consultez [Exemple de définitions de tâches Amazon ECS](example_task_definitions.md). Ce paramètre correspond à `LogConfig` dans la commande docker create-container et à l’option `--log-driver` dans la commande docker run. Par défaut, les conteneurs utilisent le même pilote de journalisation que celui utilisé par le démon Docker. Cependant, le conteneur peut utiliser un pilote de journalisation différent que celui du démon Docker en spécifiant un pilote de journal avec ce paramètre dans la définition de conteneur. Pour utiliser un pilote de journalisation différent pour un conteneur, le système de journal doit être configuré correctement sur l'instance de conteneur (ou sur un serveur de journal différent pour les options de journalisation à distance). Tenez compte des éléments suivants lorsque vous spécifiez une configuration de journal pour vos conteneurs : + Amazon ECS prend en charge un sous-ensemble des pilotes de journalisation qui sont disponibles pour le démon Docker. + Ce paramètre nécessite la version 1.18 ou ultérieure de l'API Docker à distance sur votre instance de conteneur. + Vous devez installer tout logiciel supplémentaire en dehors de cette tâche. Par exemple, les agrégateurs de sortie Fluentd ou un hôte distant exécutant Logstash auquel envoyer des journaux Gelf. ``` "logConfiguration": { "logDriver": "awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens", "options": {"string": "string" ...}, "secretOptions": [{ "name": "string", "valueFrom": "string" }] } ``` `logDriver` Type : Chaîne Valeurs valides : `"awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens"` Obligatoire : oui lorsque `logConfiguration` est utilisé Pilote de journal à utiliser pour le conteneur. Par défaut, les valeurs valides mentionnées ci-dessus sont les pilotes de journal avec lesquels l'agent de conteneur Amazon ECS peut communiquer. Les pilotes de journalisation pris en charge sont `awslogs`, `splunk` et `awsfirelens`. Pour plus d'informations sur l'utilisation du pilote de `awslogs` journal dans les définitions de tâches pour envoyer les journaux de vos conteneurs à CloudWatch Logs, consultez[Envoyez les journaux Amazon ECS à CloudWatch](using_awslogs.md). Pour de plus amples informations sur l'utilisation du pilote de journal `awsfirelens`, consultez [Routage personnalisé des journaux](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html). Si vous avez un pilote personnalisé qui n'est pas répertorié, vous pouvez bifurquer le projet d'agent de conteneur Amazon ECS [disponible sur GitHub et le](https://github.com/aws/amazon-ecs-agent) personnaliser pour qu'il fonctionne avec ce pilote. Nous vous conseillons d'envoyer des demandes d'extraction pour les modifications que vous souhaitez inclure. Toutefois, nous ne prenons pas en charge l'exécution de copies modifiées de ce logiciel pour le moment. Ce paramètre nécessite la version 1.18 de l'API Docker Remote ou une version ultérieure sur votre instance de conteneur. `options` Type : mappage chaîne/chaîne Obligatoire : non key/value Carte des options de configuration à envoyer au pilote du journal. Les options que vous pouvez spécifier dépendent du pilote de journalisation. Certaines des options que vous pouvez spécifier lorsque vous utilisez le `awslogs` routeur pour acheminer les journaux vers Amazon CloudWatch sont les suivantes : `awslogs-create-group` Obligatoire : non Spécifiez si vous souhaitez que le groupe de journaux soit créé automatiquement. Si cette option n'est pas spécifiée, l'emplacement par défaut est `false`. Votre politique IAM doit inclure l'autorisation `logs:CreateLogGroup` afin que vous puissiez essayer d'utiliser `awslogs-create-group`. `awslogs-region` Obligatoire : oui Spécifiez Région AWS le pilote de `awslogs` journal auquel envoyer vos journaux Docker. Vous pouvez choisir d'envoyer tous vos journaux provenant de clusters situés dans différentes régions vers une seule région dans CloudWatch Logs. Cela leur permet d'être tous visibles en un seul endroit. Sinon, vous pouvez les séparer par région pour plus de granularité. Assurez-vous que le groupe de journaux spécifié existe dans la région que vous spécifiez avec cette option. `awslogs-group` Obligatoire : oui Assurez-vous de spécifier un groupe de journaux auquel le pilote de journaux `awslogs` envoie ses flux de journaux. `awslogs-stream-prefix` Obligatoire : oui Utilisez l'option `awslogs-stream-prefix` pour associer un flux de journaux au préfixe spécifié, au nom du conteneur et à l'ID de la tâche Amazon ECS à laquelle appartient le conteneur. Si vous spécifiez un préfixe avec cette option, le format du flux de journaux est le suivant. ``` prefix-name/container-name/ecs-task-id ``` Si vous ne spécifiez pas de préfixe avec cette option, le flux de journaux est nommé d'après l'ID de conteneur attribué par le démon Docker sur l'instance de conteneur. Etant donné qu'il est difficile de suivre les journaux jusqu'au conteneur qui les a envoyé en utilisant uniquement l'ID de conteneur Docker (qui est uniquement disponible sur l'instance de conteneur), nous vous recommandons de spécifier un préfixe avec cette option. Pour les services Amazon ECS, vous pouvez utiliser le nom du service comme préfixe. Ce faisant, vous pourrez suivre les flux de journaux et déterminer le service auquel appartient le conteneur, trouver le nom du conteneur qui les a envoyés, ainsi que l'ID de la tâche à laquelle le conteneur appartient. Vous devez spécifier un préfixe de flux pour vos journaux pour qu'ils apparaissent dans le panneau des journaux lors de l'utilisation de la console Amazon ECS. `awslogs-datetime-format` Obligatoire : non Cette option définit un modèle de démarrage à plusieurs lignes au format `strftime` Python. Un message de journal est composé de plusieurs lignes : une ligne correspondant au modèle et les lignes suivantes qui ne correspondent pas au modèle. La ligne mise en correspondance est le délimiteur entre les messages de journalisation. Ce format peut, par exemple, servir à analyser une sortie comme une pile de vidage, laquelle pourrait, dans le cas contraire, être consignée en plusieurs entrées. Le modèle adéquat permet de la capturer dans une seule entrée. Pour de plus amples informations, veuillez consulter [awslogs-datetime-format](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-datetime-format). Vous ne pouvez pas configurer à la fois les options `awslogs-datetime-format` et `awslogs-multiline-pattern`. La journalisation multiligne effectue l'analyse et la mise en correspondance des expressions régulières de tous les messages de journalisation. Cela peut avoir un impact négatif sur les performances de journalisation. `awslogs-multiline-pattern` Obligatoire : non Cette option définit un modèle de démarrage à plusieurs lignes à l'aide d'une expression régulière. Un message de journal est composé de plusieurs lignes : une ligne correspondant au modèle et les lignes suivantes qui ne correspondent pas au modèle. La ligne mise en correspondance est le délimiteur entre les messages de journalisation. Pour de plus amples informations, veuillez consulter [awslogs-multiline-pattern](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-multiline-pattern). Cette option est ignorée si `awslogs-datetime-format` est également configuré. Vous ne pouvez pas configurer à la fois les options `awslogs-datetime-format` et `awslogs-multiline-pattern`. La journalisation multiligne effectue l'analyse et la mise en correspondance des expressions régulières de tous les messages de journalisation. Cela peut avoir un impact négatif sur les performances de journalisation. Les options suivantes s’appliquent à tous les pilotes de journalisation pris en charge. `mode` Obligatoire : non Valeurs valides : `non-blocking` \$1 `blocking` Cette option définit le mode de transmission des messages de journalisation depuis le conteneur vers le pilote de journalisation spécifié à l’aide de `logDriver`. Le mode de livraison que vous choisissez affecte la disponibilité de l’application lorsque le flux des journaux provenant du conteneur est interrompu. Si vous utilisez le mode `blocking` et que le flux de journaux est interrompu, les appels provenant du code du conteneur à écrire dans les flux `stdout` et `stderr` seront bloqués. Le fil de journalisation de l'application se bloquera en conséquence. Cela peut empêcher l'application de répondre et entraîner l'échec de vérification de l'état du conteneur. Si vous utilisez le mode `non-blocking`, les journaux du conteneur sont plutôt stockés dans une mémoire tampon intermédiaire configurée avec l'option `max-buffer-size`. Cela empêche l’application de ne plus répondre lorsque les journaux ne peuvent pas être envoyés. Nous vous recommandons d'utiliser ce mode si vous souhaitez garantir la disponibilité du service et si vous acceptez une certaine perte de journaux. Pour plus d’informations, consultez la section [Prévention de la perte de journaux grâce au mode non bloquant dans le pilote de journalisation conteneur `awslogs`](https://aws.amazon.com/blogs/containers/preventing-log-loss-with-non-blocking-mode-in-the-awslogs-container-log-driver/). Vous pouvez définir une valeur de `mode` par défaut pour tous les conteneurs d’un conteneur dans une Région AWS spécifique en utilisant le paramètre de compte `defaultLogDriverMode`. Si vous ne spécifiez pas l’option `mode` dans `logConfiguration` ou ne configurez pas les paramètres du compte, Amazon ECS utilisera par défaut le mode `non-blocking`. Pour plus d’informations sur ce paramètre de compte, consultez la section le [Mode de pilote du journal par défaut](ecs-account-settings.md#default-log-driver-mode). Quand le mode `non-blocking` est utilisé, l'option de journalisation `max-buffer-size` contrôle la taille de la mémoire tampon utilisée pour le stockage des messages intermédiaires. Assurez-vous de spécifier une taille de mémoire tampon adéquate en fonction de votre application. La quantité totale de mémoire allouée au niveau de la tâche doit être supérieure à la quantité de mémoire allouée à tous les conteneurs, en plus du tampon mémoire du pilote de journalisation. Le 25 juin 2025, Amazon ECS a modifié le mode par défaut du pilote de journalisation, passant de `blocking` à `non-blocking` afin de privilégier la disponibilité des tâches plutôt que la journalisation. Pour continuer à utiliser le mode `blocking` après cette modification, effectuez l’une des opérations suivantes : + Définissez l’option `mode` dans votre définition de conteneur `logConfiguration` sur `blocking`. + Réglez le paramètre du compte `defaultLogDriverMode` sur `blocking`. `max-buffer-size` Obligatoire : non Valeur par défaut : `10m` Quand le mode `non-blocking` est utilisé, l'option de journalisation `max-buffer-size` contrôle la taille de la mémoire tampon utilisée pour le stockage des messages intermédiaires. Assurez-vous de spécifier une taille de mémoire tampon adéquate en fonction de votre application. Lorsque la mémoire tampon est pleine, il est impossible de stocker d'autres journaux. Les journaux qui ne peuvent pas être stockés sont perdus. Pour acheminer les journaux à l’aide du routeur de journaux `splunk`, vous devez spécifier un `splunk-token` et une `splunk-url`. Lorsque vous utilisez le routeur de `awsfirelens` journaux pour acheminer les journaux vers une AWS Partner Network destination Service AWS ou à des fins de stockage et d'analyse des journaux, vous pouvez définir l'`log-driver-buffer-limit`option permettant de limiter le nombre de lignes de journal mises en mémoire tampon avant d'être envoyées au conteneur du routeur de journaux. Cela peut aider à résoudre le problème potentiel de perte de journal, car un débit élevé peut entraîner un épuisement de la mémoire pour le tampon à l'intérieur de Docker. Pour de plus amples informations, veuillez consulter [Configuration des journaux Amazon ECS pour un débit élevé](firelens-docker-buffer-limit.md). Les autres options que vous pouvez spécifier lors de l’utilisation d’`awsfirelens` pour acheminer les journaux dépendent de la destination. Lorsque vous exportez des journaux vers Amazon Data Firehose, vous pouvez spécifier le Région AWS format `region` et le nom du flux de journaux. `delivery_stream` Lorsque vous exportez des journaux vers Amazon Kinesis Data Streams, vous pouvez spécifier la Région AWS avec `region` et un nom pour le flux de données avec `stream`. Lorsque vous exportez des journaux vers Amazon OpenSearch Service, vous pouvez spécifier des options telles que `Name` `Host` (point de terminaison de OpenSearch service sans protocole) `Port` `Index``Type`,`Aws_auth`,`Aws_region`,,`Suppress_Type_Name`, et`tls`. Lorsque vous exportez des journaux vers Amazon S3, vous pouvez spécifier le compartiment à l’aide de l’option `bucket`. Vous pouvez également spécifier `region`, `total_file_size`, `upload_timeout` et `use_put_object` en tant qu’options. Ce paramètre nécessite la version 1.19 de l'API Docker à distance ou une version supérieure sur votre instance de conteneur. `secretOptions` Type : tableau d'objets Obligatoire : non Objet qui représente le secret à transmettre à la configuration de journal. Les secrets utilisés dans la configuration du journal peuvent inclure un jeton d'authentification, un certificat ou une clé de chiffrement. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur Amazon ECS](specifying-sensitive-data.md). `name` Type : Chaîne Obligatoire : oui Valeur à définir comme variable d'environnement sur le conteneur. `valueFrom` Type : Chaîne Obligatoire : oui Secret à exposer à la configuration de journal du conteneur. ``` "logConfiguration": { "logDriver": "splunk", "options": { "splunk-url": "https://cloud.splunk.com:8080", "splunk-token": "...", "tag": "...", ... }, "secretOptions": [{ "name": "splunk-token", "valueFrom": "/ecs/logconfig/splunkcred" }] } ``` `firelensConfiguration` Type : [FirelensConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FirelensConfiguration.html)Objet Obligatoire : non FireLens Configuration du conteneur. Cette option est utilisée pour spécifier et configurer un routeur de journal pour les journaux de conteneur. Pour de plus amples informations, veuillez consulter [Envoyer les journaux Amazon ECS à un AWS service ou AWS Partner](using_firelens.md). ``` { "firelensConfiguration": { "type": "fluentd", "options": { "KeyName": "" } } } ``` `options` Type : mappage chaîne/chaîne Obligatoire : non key/value Carte des options à utiliser lors de la configuration du routeur de log. Ce champ est facultatif et peut être utilisé pour spécifier un fichier de configuration personnalisé ou ajouter des métadonnées supplémentaires, telles que les détails de tâche, de définition de tâche, de cluster et d'instance de conteneur à l'événement de journal. Si spécifié, la syntaxe à utiliser est `"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"}`. Pour de plus amples informations, veuillez consulter [Exemple de définition de tâche Amazon ECS : acheminement des journaux vers FireLens](firelens-taskdef.md). `type` Type : Chaîne Obligatoire : oui Routeur de journal à utiliser. Les valeurs valides sont `fluentd` ou `fluentbit`. #### Sécurité Pour plus d’informations sur la sécurité des conteneurs, consultez la section [Pratiques exemplaires en matière de sécurité des tâches et des conteneurs Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-tasks-containers.html). `credentialSpecs` Type : tableau de chaînes Obligatoire : non Liste des informations contenues ARNs dans SSM ou Amazon S3 dans un fichier de spécifications d'identification (`CredSpec`) qui configure le conteneur pour l'authentification Active Directory. Nous vous recommandons d'utiliser ce paramètre plutôt que les `dockerSecurityOptions`. Le nombre maximum de ARNs est 1. Il existe deux formats pour chaque ARN. credentialspecdomainless:MyARN Vous utilisez `credentialspecdomainless:MyARN` pour fournir un `CredSpec` avec une section supplémentaire pour un secret dans Secrets Manager. Vous fournissez les informations d'identification de connexion au domaine dans le secret. Chaque tâche exécutée sur une instance de conteneur peut rejoindre différents domaines. Vous pouvez utiliser ce format sans associer l'instance de conteneur à un domaine. credentialspec:MyARN Vous utilisez `credentialspec:MyARN` pour fournir un `CredSpec` pour un domaine unique. Vous devez joindre l'instance de conteneur au domaine avant de démarrer toute tâche utilisant cette définition de tâche. Dans les deux formats, remplacez `MyARN` par l'ARN dans SSM ou Amazon S3. Le `credspec` doit fournir un ARN dans Secrets Manager pour un secret contenant le nom d'utilisateur, le mot de passe et le domaine auquel se connecter. Pour une meilleure sécurité, l'instance n'est pas jointe au domaine pour l'authentification sans domaine. Les autres applications de l'instance ne peuvent pas utiliser les informations d'identification sans domaine. Vous pouvez utiliser ce paramètre pour exécuter des tâches sur la même instance, même si les tâches doivent être jointes à différents domaines. Pour plus d'informations, consultez les [sections Utilisation de g MSAs pour les conteneurs Windows](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/windows-gmsa.html) et [Utilisation de g MSAs pour les conteneurs Linux](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/linux-gmsa.html). `user` Type : chaîne Obligatoire : non Utilisateur à utiliser à l'intérieur du conteneur. Ce paramètre correspond à `User` dans la commande docker create-container et à l’option `--user` dans la commande docker run. Lorsque vous exécutez des tâches en mode réseau `host`, n'exécutez pas de conteneurs à l'aide de l'utilisateur root (UID 0). Comme bonne pratique de sécurité, utilisez toujours un utilisateur non root. Vous pouvez spécifier l'`user` à l'aide des formats suivants. Si vous spécifiez un UID ou GID, vous devez le spécifier en tant que nombre entier positif. + `user` + `user:group` + `uid` + `uid:gid` + `user:gid` + `uid:group` Ce paramètre n'est pas pris en charge par les conteneurs Windows. ``` "user": "string" ``` #### Limites des ressources `ulimits` Type : tableau d'objets Obligatoire : non Une liste de valeurs `ulimit` à définir pour un conteneur. Cette valeur remplace le paramètre de quota de ressources par défaut pour le système d'exploitation. Ce paramètre correspond à `Ulimits` dans la commande docker create-container et à l’option `--ulimit` dans la commande docker run. 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`. Pour de plus amples informations, veuillez consulter [Limites des ressources de tâche](fargate-tasks-services.md#fargate-resource-limits). Ce paramètre nécessite la version 1.18 de l'API Docker Remote ou une version ultérieure sur votre instance de conteneur. Ce paramètre n'est pas pris en charge par les conteneurs Windows. ``` "ulimits": [ { "name": "core"|"cpu"|"data"|"fsize"|"locks"|"memlock"|"msgqueue"|"nice"|"nofile"|"nproc"|"rss"|"rtprio"|"rttime"|"sigpending"|"stack", "softLimit": integer, "hardLimit": integer } ... ] ``` `name` Type : Chaîne Valeurs valides : `"core" | "cpu" | "data" | "fsize" | "locks" | "memlock" | "msgqueue" | "nice" | "nofile" | "nproc" | "rss" | "rtprio" | "rttime" | "sigpending" | "stack"` Obligatoire : oui, lorsque des objets `ulimits` sont utilisés Le `type` d'`ulimit`. `hardLimit` Type : Integer Obligatoire : oui, lorsque des objets `ulimits` sont utilisés La limite stricte du type `ulimit`. La valeur peut être spécifiée en octets, en secondes ou en nombre, selon le `type` d’`ulimit`. `softLimit` Type : Integer Obligatoire : oui, lorsque des objets `ulimits` sont utilisés La limite flexible du type `ulimit`. La valeur peut être spécifiée en octets, en secondes ou en nombre, selon le `type` d’`ulimit`. #### Étiquettes Docker `dockerLabels` Type : mappage chaîne/chaîne Obligatoire : non Une key/value carte des étiquettes à ajouter au conteneur. Ce paramètre correspond à `Labels` dans la commande docker create-container et à l’option `--label` dans la commande docker run. Ce paramètre nécessite la version 1.18 de l'API Docker Remote ou une version ultérieure sur votre instance de conteneur. ``` "dockerLabels": {"string": "string" ...} ``` ### Autres paramètres de définition de conteneur Les paramètres de définition de conteneur suivants peuvent être utilisés lors de l'enregistrement des définitions de tâche dans la console Amazon ECS à l'aide de l'option **Configure via JSON** (Configurer via JSON). Pour de plus amples informations, veuillez consulter [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md). **Topics** + [ #### Paramètres Linux ](#container_definition_linuxparameters) + [ #### Dépendances du conteneur ](#container_definition_dependson) + [ #### Temporisations de conteneurs ](#container_definition_timeout) + [ #### Contrôles système ](#container_definition_systemcontrols) + [ #### Interactive ](#container_definition_interactive) + [ #### Pseudo Terminal ](#container_definition_pseudoterminal) #### Paramètres Linux `linuxParameters` Type : objet [LinuxParameters](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LinuxParameters.html) Obligatoire : non Linux-des options spécifiques appliquées au conteneur, telles [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html)que. Ce paramètre n'est pas pris en charge par les conteneurs Windows. ``` "linuxParameters": { "capabilities": { "add": ["string", ...], "drop": ["string", ...] } } ``` `capabilities` Type : objet [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html) Obligatoire : non Les fonctionnalités Linux pour le conteneur qui sont supprimées de la configuration par défaut fournie par Docker. Pour plus d'informations sur ces caractéristiques Linux, veuillez consulter la page consacrée aux [caractéristiques(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html) dans le manuel Linux (langue française non garantie). `add` Type : tableau de chaînes Valeurs valides : `"SYS_PTRACE"` Obligatoire : non Caractéristiques Linux du conteneur à ajouter à la configuration par défaut fournie par Docker. Ce paramètre correspond à `CapAdd` dans la commande docker create-container et à l’option `--cap-add` dans la commande docker run. `drop` Type : tableau de chaînes Valeurs valides : `"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"` Obligatoire : non Caractéristiques Linux du conteneur à supprimer de la configuration par défaut fournie par Docker. Ce paramètre correspond à `CapDrop` dans la commande docker create-container et à l’option `--cap-drop` dans la commande docker run. `devices` Tous les périphériques hôtes à exposer au conteneur. Ce paramètre correspond à `Devices` dans la commande docker create-container et à l’option `--device` dans la commande docker run. Le paramètre `devices` n’est pas pris en charge lorsque vous utilisez le type de lancement Fargate. Type : tableau d'objets [Périphérique](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Device.html) Obligatoire : non `hostPath` Chemin du périphérique dans l'instance de conteneur hôte. Type : Chaîne Obligatoire : oui `containerPath` Chemin auquel exposer l'appareil hôte à l'intérieur du conteneur. Type : chaîne Obligatoire : non `permissions` Autorisations explicites à fournir au conteneur pour le périphérique. Par défaut, le conteneur dispose des autorisations `read`, `write` et `mknod` sur l'appareil. Type : tableau de chaînes Valeurs valides : `read` \$1 `write` \$1 `mknod` `initProcessEnabled` Exécutez un processus `init` dans le conteneur afin de transmettre des signaux et de récolter les processus. Ce paramètre correspond à l’option `--init` de docker run. Ce paramètre nécessite la version 1.25 de l'API Docker à distance ou une version supérieure sur votre instance de conteneur. `maxSwap` Il n’est pas pris en charge pour les tâches exécutées sur Fargate. Quantité totale de mémoire d'échange (en Mio) qu'un conteneur peut utiliser. Ce paramètre est converti en l’option `--memory-swap` de la commande docker run, où la valeur est la somme de la mémoire du conteneur et de la valeur `maxSwap`. Si la valeur `0` est spécifiée pour `maxSwap`, le conteneur n'utilise pas l'échange. Les valeurs acceptées sont `0` ou n'importe quel nombre entier positif. Si le paramètre `maxSwap` n'est pas spécifié, le conteneur utilise la configuration d'échange pour l'instance de conteneur sur laquelle il s'exécute. Une valeur `maxSwap` doit être définie pour que le paramètre `swappiness` soit utilisé. `sharedMemorySize` Valeur correspondant à la taille (en Mio) du volume `/dev/shm`. Ce paramètre correspond à l’option `--shm-size` de docker run. Si vous utilisez des tâches qui utilisent Fargate, le paramètre `sharedMemorySize` n’est pas pris en charge. Type : Integer `tmpfs` Chemin du conteneur, options de montage et taille maximale (en Mio) du montage tmpfs. Ce paramètre correspond à l’option `--tmpfs` de docker run. Type : tableau d'objets [Tmpfs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Tmpfs.html) Obligatoire : non `containerPath` Chemin de fichier absolu où sera monté le volume tmpfs. Type : Chaîne Obligatoire : oui `mountOptions` Liste des options de montage du volume tmpfs. Type : tableau de chaînes Obligatoire : non Valeurs valides : `"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` Taille maximale (en Mio) du volume tmpfs. Type : Integer Obligatoire : oui #### Dépendances du conteneur `dependsOn` Type : tableau d’objets [ContainerDependency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html) Obligatoire : non Dépendances définies pour le démarrage et l'arrêt de conteneurs. Un conteneur peut contenir plusieurs dépendances. Lorsqu'une dépendance est définie pour le démarrage des conteneurs, elle est inversée pour leur arrêt. Pour obtenir un exemple, consultez [Dépendances du conteneur](example_task_definitions.md#example_task_definition-containerdependency). Si un conteneur ne respecte pas une contrainte de dépendance ou s'écoule avant de respecter la contrainte, Amazon ECS ne fait pas progresser pas les conteneurs dépendants vers leur état suivant. Ce paramètre exige que la tâche ou le service utilise la version de plateforme `1.3.0` ou une version ultérieure (Linux) ou `1.0.0` (Windows). ``` "dependsOn": [ { "containerName": "string", "condition": "string" } ] ``` `containerName` Type : Chaîne Obligatoire : oui Nom de conteneur qui doit répondre à la condition spécifiée. `condition` Type : Chaîne Obligatoire : oui Condition de dépendance du conteneur. Voici les conditions disponibles et leur comportement : + `START` - Cette condition émule le comportement de liens et de volumes aujourd'hui. La condition vérifie qu'un conteneur dépendant est démarré avant d'autoriser d'autres conteneurs à démarrer. + `COMPLETE` - Cette condition vérifie qu'un conteneur dépendant exécute un cycle complet (sorties) avant d'autoriser d'autres conteneurs à démarrer. Cela peut être utile pour les conteneurs non essentiels qui exécutent un script, puis se ferment. Cette condition ne peut pas être définie sur un conteneur essentiel. + `SUCCESS` - Cette condition est identique à `COMPLETE`, mais elle nécessite également que le conteneur se termine par un état `zero`. Cette condition ne peut pas être définie sur un contenant essentiel. + `HEALTHY` - Cette condition vérifie que la surveillance de l'état du conteneur dépendant réussit avant d'autoriser d'autres conteneurs à démarrer. Cela nécessite que le conteneur dépendant dispose de surveillances de l'état configurées dans la définition de la tâche. Cette condition est confirmée uniquement au démarrage de la tâche. #### Temporisations de conteneurs `startTimeout` Type : Integer Obligatoire : non Exemples de valeur : `120` Durée d'attente (en secondes) avant l'abandon de la résolution de dépendances pour un conteneur. Par exemple, vous spécifiez deux conteneurs dans une définition de tâche, où le `containerA` dispose d'une dépendance au `containerB` avec un état `COMPLETE`, `SUCCESS` ou `HEALTHY`. Si une valeur `startTimeout` est spécifiée pour `containerB` et qu'il n'a pas atteint l'état souhaité dans ce délai, alors le `containerA` ne démarre pas. Si un conteneur ne respecte pas une contrainte de dépendance ou s'écoule avant de respecter la contrainte, Amazon ECS ne fait pas progresser pas les conteneurs dépendants vers leur état suivant. Ce paramètre exige que la tâche ou le service utilise la version de plateforme `1.3.0` ou une version ultérieure (Linux). La valeur maximale est de 120 secondes. `stopTimeout` Type : Integer Obligatoire : non Exemples de valeur : `120` Durée (en secondes) à attendre avant que le conteneur soit expressément tué s'il ne s'achève pas normalement tout seul. Ce paramètre exige que la tâche ou le service utilise la version de plateforme `1.3.0` ou une version ultérieure (Linux). Si le paramètre n'est pas spécifié, alors la valeur par défaut de 30 secondes est utilisée. La valeur maximale est de 120 secondes. #### Contrôles système `systemControls` Type : objet [SystemControl](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_SystemControl.html) Obligatoire : non Liste des paramètres du noyau de l’espace de noms à définir dans le conteneur. Ce paramètre correspond à `Sysctls` dans la commande docker create-container et à l’option `--sysctl` dans la commande docker run. Par exemple, vous pouvez configurer le paramètre `net.ipv4.tcp_keepalive_time` pour maintenir des connexions de plus longue durée. Il n'est pas recommandé de spécifier des paramètres `systemControls` liés au réseau pour plusieurs conteneurs dans une seule tâche qui utilise également le mode réseau `awsvpc` ou `host`. En procédant ainsi, vous vous exposez aux inconvénients suivants : + Si vous définissez `systemControls` pour n’importe quel conteneur, cela s’applique à tous les conteneurs de la tâche. Si vous définissez différents paramètres `systemControls` pour plusieurs conteneurs dans une seule tâche, c'est le conteneur qui est démarré en dernier qui détermine le paramètre `systemControls` qui prend effet. Si vous définissez un espace de noms des ressources IPC à utiliser pour les conteneurs de la tâche, les conditions suivantes s'appliquent aux contrôles de système. Pour de plus amples informations, veuillez consulter [Mode IPC](#task_definition_ipcmode). + Pour les tâches qui utilisent le mode IPC `host`, les `systemControls` liés à l'espace de noms IPC ne sont pas pris en charge. + Pour les tâches qui utilisent le mode IPC `task`, les valeurs des `systemControls` liés à l'espace de noms IPC s'appliquent à tous les conteneurs au sein d'une tâche. Ce paramètre n'est pas pris en charge par les conteneurs Windows. Ce paramètre est uniquement pris en charge pour les tâches hébergées sur AWS Fargate , si elles utilisent la version de plateforme `1.4.0` ou ultérieure (Linux). Cela n'est pas pris en charge par les conteneurs Windows sur Fargate. ``` "systemControls": [ { "namespace":"string", "value":"string" } ] ``` `namespace` Type : chaîne Obligatoire : non Paramètre du noyau de l’espace de noms pour lequel définir une `value`. Valeurs d'espace de noms IPC valides : `"kernel.msgmax" | "kernel.msgmnb" | "kernel.msgmni" | "kernel.sem" | "kernel.shmall" | "kernel.shmmax" | "kernel.shmmni" | "kernel.shm_rmid_forced"`, et `Sysctls` qui commencent par `"fs.mqueue.*"` Valeurs d’espace de noms de réseau valides : `Sysctls` qui commencent par `"net.*"` Sur Fargate, seuls les espaces de noms `Sysctls` existant dans le conteneur sont acceptés. Toutes ces valeurs sont prises en charge par Fargate. `value` Type : chaîne Obligatoire : non Valeur du paramètre du noyau de l’espace de noms spécifié dans `namespace`. #### Interactive `interactive` Type : booléen Obligatoire : non Lorsque ce paramètre est `true`, vous pouvez déployer des applications conteneurisées qui nécessitent l'allocation d'une `stdin` ou d'un `tty`. Ce paramètre correspond à `OpenStdin` dans la commande docker create-container et à l’option `--interactive` dans la commande docker run. La valeur par défaut est `false`. #### Pseudo Terminal `pseudoTerminal` Type : booléen Obligatoire : non Lorsque ce paramètre a la valeur `true`, un TTY est alloué. Ce paramètre correspond à `Tty` dans la commande docker create-container et à l’option `--tty` dans la commande docker run. La valeur par défaut est `false`. ## Nom de l'accélérateur Elastic Inference (obsolète) L'exigence de la ressource d'accélérateur Elastic Inference pour votre définition de tâche. **Note** Amazon Elastic Inference (EI) n’est plus disponible pour les clients. Les paramètres suivants sont autorisés dans une définition de tâche : `deviceName` Type : Chaîne Obligatoire : oui Nom de l'appareil accélérateur d'inférence élastique pour l'instance. `deviceName` doit également être référencé dans une définition du conteneur. Consultez [Elastic Inference accelerator](#ContainerDefinition-elastic-inference). `deviceType` Type : Chaîne Obligatoire : oui L'accélérateur Elastic Inference à utiliser. ## Configuration du proxy `proxyConfiguration` Type : objet [ProxyConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ProxyConfiguration.html) Obligatoire : non Détails de configuration pour le proxy App Mesh. Ce paramètre n'est pas pris en charge par les conteneurs Windows. ``` "proxyConfiguration": { "type": "APPMESH", "containerName": "string", "properties": [ { "name": "string", "value": "string" } ] } ``` `type` Type : Chaîne Valeur valeurs : `APPMESH` Obligatoire : non Type de proxy. La seule valeur prise en charge est `APPMESH`. `containerName` Type : Chaîne Obligatoire : oui Nom du conteneur qui fait office de proxy App Mesh. `properties` Type : tableau d’objets [KeyValuePair](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KeyValuePair.html) Obligatoire : non L'ensemble de paramètres de configuration réseau pour fournir le plug-in Container Network Interface (CNI), spécifié sous la forme de paires clé-valeur. + `IgnoredUID` – (Obligatoire) ID d'utilisateur (UID) du conteneur de proxy, tel que défini par le paramètre `user` dans une définition de conteneur. Ce port est utilisé pour garantir que le proxy ignore son propre trafic. Si vous avez spécifié `IgnoredGID`, ce champ doit être vide. + `IgnoredGID` – (Obligatoire) ID de groupe (GID) du conteneur de proxy, tel que défini par le paramètre `user` dans une définition de conteneur. Ce port est utilisé pour garantir que le proxy ignore son propre trafic. Si vous avez spécifié `IgnoredUID`, ce champ doit être vide. + `AppPorts` - (Obligatoire) Liste des ports utilisés par l'application. Le trafic réseau vers ces ports est transmis à `ProxyIngressPort` et `ProxyEgressPort`. + `ProxyIngressPort` – (Obligatoire) Spécifie le port auquel le trafic entrant vers `AppPorts` est dirigé. + `ProxyEgressPort` – (Obligatoire) Spécifie le port auquel le trafic sortant de `AppPorts` est dirigé. + `EgressIgnoredPorts` – (Obligatoire) Le trafic sortant accédant à ces ports spécifiés est ignoré et n'est pas redirigé vers le `ProxyEgressPort`. Cela peut être une liste vide. + `EgressIgnoredIPs` – (Obligatoire) Le trafic sortant accédant à ces adresses IP spécifiées est ignoré et n'est pas redirigé vers le `ProxyEgressPort`. Cela peut être une liste vide. `name` Type : chaîne Obligatoire : non Nom de la paire clé-valeur. `value` Type : chaîne Obligatoire : non Valeur de la paire clé-valeur. ## Volumes Lorsque vous enregistrez une définition de tâche, vous pouvez spécifier une liste de volumes à transmettre au démon Docker sur une instance de conteneur, à laquelle d’autres conteneurs de la même instance de conteneur pourront accéder. Les types de volumes de données qui peuvent être utilisés sont les suivants : + Volumes Amazon EBS : fournit un stockage par blocs rentable, durable et performant pour les charges de travail conteneurisées gourmandes en données. Vous pouvez attacher un volume Amazon EBS par tâche Amazon ECS lorsque vous exécutez une tâche autonome ou lorsque vous créez ou mettez à jour un service. Les volumes Amazon EBS sont pris en charge pour les tâches Linux hébergées sur Fargate. Pour de plus amples informations, veuillez consulter [Utilisation des volumes Amazon EBS avec Amazon ECS](ebs-volumes.md). + Volumes Amazon EFS : fournit un stockage de fichiers simple, évolutif et permanent à utiliser avec vos tâches Amazon ECS. Avec Amazon EFS, la capacité de stockage est élastique. Elle augmente et diminue automatiquement au fil de vos ajouts et suppressions de fichiers. Vos applications peuvent disposer de l'espace de stockage dont elles ont besoin, au moment où elles en ont besoin. Les volumes Amazon EFS sont pris en charge pour les tâches hébergées sur Fargate. Pour de plus amples informations, veuillez consulter [Utilisation des volumes Amazon EFS avec Amazon ECS](efs-volumes.md). + FSx pour les volumes de serveurs de fichiers Windows : fournit des serveurs de fichiers Microsoft Windows entièrement gérés. Ces serveurs de fichiers sont basés sur un système de fichiers Windows. Lorsque vous utilisez FSx un serveur de fichiers Windows avec Amazon ECS, vous pouvez fournir à vos tâches Windows un stockage de fichiers persistant, distribué, partagé et statique. Pour de plus amples informations, veuillez consulter [Utilisation FSx pour les volumes de serveurs de fichiers Windows avec Amazon ECS](wfsx-volumes.md). Les conteneurs Windows sur Fargate ne prennent pas en charge cette option. + Montages liés : un fichier ou un dossier sur la machine hôte est monté dans un conteneur. Les volumes hôtes de montage lié sont pris en charge lorsque vous exécutez des tâches. Pour utiliser des volumes hôte de montage lié, spécifiez un `host` et éventuellement une valeur `sourcePath` dans votre définition de tâche. Pour de plus amples informations, veuillez consulter [Options de stockage pour les tâches Amazon ECS](using_data_volumes.md). Les paramètres suivants sont autorisés dans une définition de conteneur. `name` Type : chaîne Obligatoire : non Nom du volume. Jusqu’à 255 lettres (majuscules et minuscules), chiffres, traits d’union (`-`) et traits de soulignement (`_`) sont autorisés. Ce nom est référencé dans le paramètre `sourceVolume` de l’objet `mountPoints` de définition du conteneur. `host` Obligatoire : non Le paramètre `host` est utilisé pour lier le cycle de vie du montage lié à l'instance Amazon EC2 hôte, plutôt qu'à la tâche et à l'endroit où elle est stockée. Si le paramètre `host` est vide, le démon Docker attribue un chemin hôte au volume de données, mais la persistance des données après l'arrêt des conteneurs qui lui sont associés n'est pas garantie. Les conteneurs Windows peuvent monter des répertoires entiers sur le même lecteur que `$env:ProgramData`. Le `sourcePath` paramètre est pris en charge uniquement lors de l'utilisation de tâches hébergées sur des instances Amazon EC2 ou des instances gérées Amazon ECS. `sourcePath` Type : chaîne Obligatoire : non Lorsque le paramètre `host` est utilisé, spécifiez un paramètre `sourcePath` pour déclarer le chemin d'accès sur l'instance Amazon EC2 hôte qui est présentée au conteneur. Si ce paramètre est vide, le démon Docker attribue un chemin hôte pour vous. Si le paramètre `host` contient un emplacement de fichier `sourcePath`, le volume de données persiste à l'emplacement spécifié sur l'instance Amazon EC2 hôte jusqu'à ce que vous le supprimiez manuellement. Si la valeur `sourcePath` n'existe pas sur l'instance Amazon EC2 hôte, le démon Docker la crée. Si l'emplacement n'existe pas, le contenu du chemin source est exporté. `configuredAtLaunch` Type : booléen Obligatoire : non Spécifie si un volume est configurable au lancement. Lorsqu’il est défini sur `true`, vous pouvez configurer le volume lors de l’exécution d’une tâche autonome ou lors de la création ou de la mise à jour d’un service. Lorsque cette option est définie sur `true`, vous ne pourrez pas fournir d’autre configuration de volume dans la définition de tâche. Ce paramètre doit être défini sur `true` pour configurer un volume Amazon EBS à rattacher à une tâche. En définissant `configuredAtLaunch` sur `true` et en reportant la configuration du volume à la phase de lancement, vous pouvez créer des définitions de tâches qui ne sont pas limitées à un type de volume ou à des paramètres de volume spécifiques. Cela rend votre définition de tâche réutilisable dans différents environnements d’exécution. Pour plus d'informations, consultez [Volumes Amazon EBS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html). `dockerVolumeConfiguration` Type : [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html)Objet Obligatoire : non Ce paramètre est spécifié lorsque vous utilisez des volumes Docker. Les volumes Docker sont pris en charge uniquement lors de l’exécution de tâches sur des instances EC2. Les conteneurs Windows prennent uniquement en charge l’utilisation du pilote `local`. Pour utiliser des montages liés, spécifiez plutôt un paramètre `host`. `scope` Type : Chaîne Valeurs valides : `task` \$1 `shared` Obligatoire : non Portée du volume Docker, qui détermine son cycle de vie. Les volumes Docker destinés à un élément `task` sont automatiquement mis en service lorsque la tâche commence, et détruits lorsque la tâche s'arrête. Les volumes Docker définis comme `shared` ne sont pas supprimés lorsque la tâche s'arrête. `autoprovision` Type : Boolean Valeur par défaut : `false` Obligatoire : non Si cette valeur est `true`, le volume Docker est créé s'il n'existe pas déjà. Ce champ n’est utilisé que si `scope` a la valeur `shared`. Si le champ `scope` a la valeur `task`, ce paramètre doit être omis. `driver` Type : chaîne Obligatoire : non Pilote de volume Docker à utiliser. La valeur du pilote doit correspondre au nom du pilote fourni par Docker, car ce nom est utilisé pour le placement des tâches. Si le pilote a été installé à l’aide de l’interface CLI du plug-in Docker, utilisez `docker plugin ls` pour récupérer le nom du pilote à partir de votre instance de conteneur. Si le pilote a été installé à l’aide d’une autre méthode, utilisez la découverte du plug-in Docker pour récupérer le nom du pilote. `driverOpts` Type : chaîne Obligatoire : non Mappage des options spécifiques au pilote Docker à transmettre. Ce paramètre correspond à `DriverOpts` dans la section « Créer un volume » de Docker. `labels` Type : chaîne Obligatoire : non Métadonnées personnalisées à ajouter à votre volume Docker. `efsVolumeConfiguration` Type : objet [EFSVolumede configuration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSVolumeConfiguration.html) Obligatoire : non Ce paramètre est spécifié lorsque vous utilisez des volumes Amazon EFS. `fileSystemId` Type : Chaîne Obligatoire : oui ID du système de fichiers Amazon EFS à utiliser. `rootDirectory` Type : chaîne Obligatoire : non Répertoire du système de fichiers Amazon EFS à monter en tant que répertoire racine à l'intérieur de l'hôte. Si ce paramètre est omis, la racine du volume Amazon EFS est utilisée. La spécification de `/` a le même effet que l'omission de ce paramètre. Si un point d’accès EFS est spécifié dans `authorizationConfig`, le paramètre de répertoire racine doit être omis ou défini sur `/`, ce qui imposera le chemin défini sur le point d’accès EFS. `transitEncryption` Type : Chaîne Valeurs valides : `ENABLED` \$1 `DISABLED` Obligatoire : non Indique si vous souhaitez activer ou non le chiffrement des données Amazon EFS en transit entre l'hôte Amazon ECS et le serveur Amazon EFS. Si l'autorisation Amazon EFS IAM est utilisée, le chiffrement de transit doit être activé. Si ce paramètre est omis, la valeur par défaut `DISABLED` est utilisée. Pour plus d'informations, consultez [Chiffrement des données en transit](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html) dans le *Guide de l'utilisateur Amazon Elastic File System*. `transitEncryptionPort` Type : Integer Obligatoire : non Port à utiliser lors de l'envoi de données chiffrées entre l'hôte Amazon ECS et le serveur Amazon EFS. Si vous ne spécifiez pas de port de chiffrement en transit, la tâche utilisera la stratégie de sélection de port adoptée par l’assistant de montage Amazon EFS. Pour plus d'informations, consultez [Assistant de montage EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html) dans le *Guide de l'utilisateur Amazon Elastic File System User*. `authorizationConfig` Type : objet [EFSAuthorizationConfig](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSAuthorizationConfig.html) Obligatoire : non Détails de configuration des autorisations pour le système de fichiers Amazon EFS. `accessPointId` Type : chaîne Obligatoire : non ID du point d'accès à utiliser. Si un point d’accès est spécifié, la valeur du répertoire racine dans `efsVolumeConfiguration` doit être omise ou définie sur `/`, ce qui imposera le chemin défini sur le point d’accès EFS. Si un point d'accès est utilisé, le chiffrement de transit doit être activé dans `EFSVolumeConfiguration`. Pour plus d'informations, consultez [Utilisation des points d'accès Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) dans le *Guide de l'utilisateur Amazon Elastic File System*. `iam` Type : Chaîne Valeurs valides : `ENABLED` \$1 `DISABLED` Obligatoire : non Indique s’il faut ou non utiliser le rôle IAM de tâche Amazon ECS spécifié dans une définition de tâche lors du montage du système de fichiers Amazon EFS. Si cette option est activée, le chiffrement en transit doit être activé dans la configuration `EFSVolumeConfiguration`. Si ce paramètre est omis, la valeur par défaut `DISABLED` est utilisée. Pour plus d'informations, consultez [Rôles IAM pour les tâches](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html). `FSxWindowsFileServerVolumeConfiguration` Type : [FSxWindowsFileServerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FSxWindowsFileServerVolumeConfiguration.html)Objet Obligatoire : oui Ce paramètre est spécifié lorsque vous utilisez un système de fichiers [Amazon FSx pour Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) pour le stockage des tâches. `fileSystemId` Type : Chaîne Obligatoire : oui L' FSx identifiant du système de fichiers Windows File Server à utiliser. `rootDirectory` Type : Chaîne Obligatoire : oui Le répertoire du système FSx de fichiers Windows File Server à monter en tant que répertoire racine sur l'hôte. `authorizationConfig` `credentialsParameter` Type : Chaîne Obligatoire : oui Options d'informations d'identification d'autorisation. **Options :** + Amazon Resource Name (ARN) d’un secret [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html). + ARN d’un paramètre [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html). `domain` Type : Chaîne Obligatoire : oui Nom de domaine complet hébergé par un répertoire [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) (AWS Managed Microsoft AD) ou un Active Directory EC2 autohébergé. ## Étiquettes Lorsque vous enregistrez une définition de tâche, vous pouvez éventuellement spécifier des étiquettes de métadonnées qui sont appliquées à la définition de tâche. Les balises vous aident à classer et à organiser votre définition de tâche. Chaque balise est constituée d’une clé et d’une valeur facultative. Vous définissez ces deux éléments. Pour de plus amples informations, veuillez consulter [Balisage des ressources Amazon ECS](ecs-using-tags.md). **Important** N'ajoutez pas de données d'identification personnelle ou d'autres informations confidentielles ou sensibles dans les étiquettes. Les tags sont accessibles à de nombreux AWS services, y compris la facturation. Les étiquettes ne sont pas destinées à être utilisées pour des données privées ou sensibles. Les paramètres suivants sont autorisés dans un objet balise. `key` Type : chaîne Obligatoire : non Partie d'une paire clé-valeur qui constitue une étiquette. Une clé est une étiquette générale qui fait office de catégorie pour les valeurs d'étiquette plus spécifiques. `value` Type : chaîne Obligatoire : non Partie facultative d'une paire clé-valeur qui constitue une étiquette. Une valeur agit comme un descripteur au sein d'une catégorie d'étiquette (clé). ## Autres paramètres de définition de tâche Les paramètres de définition de tâche suivants peuvent être utilisés lors de l'enregistrement des définitions de tâches dans la console Amazon ECS à l'aide de l'option **Configure via JSON** (Configurer via JSON). Pour de plus amples informations, veuillez consulter [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md). **Topics** + [ ### Stockage éphémère ](#task_definition_ephemeralStorage) + [ ### Mode IPC ](#task_definition_ipcmode) + [ ### Mode PID ](#task_definition_pidmode) + [ ### Injection de pannes ](#task_definition_faultInjection) ### Stockage éphémère `ephemeralStorage` Type : objet [EphemeralStorage](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EphemeralStorage.html) Obligatoire : non Quantité de stockage éphémère (en Go) à allouer pour la tâche. Ce paramètre est utilisé pour étendre la quantité totale de stockage éphémère disponible, au-delà de la quantité par défaut, pour les tâches hébergées sur AWS Fargate. Pour de plus amples informations, veuillez consulter [Utilisation de montages liés avec Amazon ECS](bind-mounts.md). Ce paramètre n’est pris en charge que sur la version de plateforme `1.4.0` ou ultérieure (Linux), ou `1.0.0` ou ultérieure (Windows). ### Mode IPC `ipcMode` Il n’est pas pris en charge pour les tâches exécutées sur Fargate. Type : chaîne Obligatoire : non Espace de noms de ressource IPC à utiliser pour les conteneurs de la tâche. Les valeurs valides sont `host`, `task` ou `none`. Si `host` est spécifié, tous les conteneurs des tâches ayant spécifié le mode IPC `host` sur la même instance de conteneur partagent les mêmes ressources IPC avec l'instance Amazon EC2 hôte. Si `task` est spécifié, tous les conteneurs de la tâche spécifiée partagent les mêmes ressources IPC. Si `none` est spécifié, les ressources IPC des conteneurs d'une tâche sont privés et ne partagent rien avec les autres conteneurs d'une tâche ou d'une instance de conteneur. Si aucune valeur n'est spécifiée, le partage de l'espace de noms de ressource IPC dépend du paramètre du démon Docker sur l'instance de conteneur. Si le mode IPC `host` est utilisé, il existe un risque accru d'exposition à un espace de noms IPC indésirable. Si vous définissez les paramètres du noyau placés dans un espace de noms à l'aide de `systemControls` pour les conteneurs de la tâche, les éléments suivants s'appliquent à votre espace de noms de ressource IPC. + Pour les tâches qui utilisent le mode IPC `host`, les `systemControls` liés à l'espace de noms IPC ne sont pas pris en charge. + Pour les tâches qui utilisent le mode IPC `task`, les `systemControls` liés à l'espace de noms IPC s'appliquent à tous les conteneurs au sein d'une tâche. **Note** Ce paramètre n'est pas pris en charge pour les conteneurs ou tâches Windows qui utilisent le type de lancement Fargate. ### Mode PID `pidMode` Type : Chaîne Valeurs valides : `host` \$1 `task` Obligatoire : non Espace de noms de processus à utiliser pour les conteneurs de la tâche. Les valeurs valides sont `host` ou `task`. Sur les conteneurs Linux, la seule valeur valide est `task`. Par exemple, la surveillance des sidecars peut avoir besoin de `pidMode` pour accéder à des informations sur d'autres conteneurs exécutés dans le cadre de la même tâche. Si `task` est spécifié, tous les conteneurs de la tâche spécifiée partagent le même espace de noms de processus. Si aucune valeur n'est spécifiée, la valeur par défaut est un espace de noms privé pour chaque conteneur. **Note** Ce paramètre est uniquement pris en charge pour les tâches hébergées sur AWS Fargate , si elles utilisent la version de plateforme `1.4.0` ou ultérieure (Linux). Cela n'est pas pris en charge par les conteneurs Windows sur Fargate. ### Injection de pannes `enableFaultInjection` Type : Boolean Valeurs valides : `true` \$1 `false` Obligatoire : non Si ce paramètre est défini sur `true`, dans les données utiles d’une tâche, Amazon ECS et Fargate acceptent les requêtes d’injection de pannes provenant des conteneurs de la tâche. Par défaut, ce paramètre est défini sur `false`. # Paramètres de définition de tâche Amazon ECS pour Amazon EC2 Les définitions de tâches sont divisées en plusieurs parties : la famille de tâches, le rôle de tâche Gestion des identités et des accès AWS (IAM), le mode réseau, les définitions des conteneurs, les volumes, les contraintes de placement des tâches et la capacité. Les définitions de famille et de conteneur sont requises dans une définition de tâche. En revanche, le rôle de tâche, le mode réseau, les volumes, les contraintes de placement des tâches et le type de lancement sont facultatifs. Vous pouvez utiliser ces paramètres dans un fichier JSON pour configurer votre définition de tâche. Voici des descriptions plus détaillées de chaque paramètre de définition de tâche pour Amazon EC2. ## Family `family` Type : Chaîne Obligatoire : oui Lorsque vous enregistrez une définition de tâche, vous lui attribuez une famille. Cela équivaut, pour plusieurs versions de définition de tâche, à lui attribuer un nom spécifié avec un numéro de révision. La première définition de tâche enregistrée dans une famille donnée reçoit le numéro de révision 1. Toute définition de tâche enregistrée après celle-ci reçoit un numéro de révision ultérieur dans l'ordre séquentiel. ## Capacity Lorsque vous enregistrez une définition de tâche, vous pouvez spécifier la capacité par rapport à laquelle Amazon ECS doit valider la définition de tâche. Une exception client est renvoyée si la définition de tâche n'est pas conforme aux compatibilités spécifiées. Le paramètre suivant est autorisé dans une définition de tâche. `requiresCompatibilities` Type : tableau de chaînes Obligatoire : non Valeurs valides : `EC2` La capacité par rapport à laquelle valider la définition de tâche. Une vérification est alors lancée afin de s’assurer que tous les paramètres utilisés dans la définition de tâche répondent aux exigences d’Amazon EC2. ## Rôle de tâche `taskRoleArn` Type : chaîne Obligatoire : non Lorsque vous enregistrez une définition de tâche, vous pouvez attribuer un rôle de tâche à un rôle IAM qui permet aux conteneurs concernés par l'autorisation de tâche d'appeler AWS APIs les conteneurs spécifiés dans les politiques associées en votre nom. Pour de plus amples informations, veuillez consulter [rôle IAM de tâche Amazon ECS](task-iam-roles.md). Lorsque vous lancez l'AMI Windows Server optimisée pour Amazon ECS, les rôles IAM pour les tâches sous Windows nécessitent que l'option `-EnableTaskIAMRole` soit définie. Vos conteneurs doivent également exécuter certains codes de configuration afin d'utiliser la fonctionnalité. Pour de plus amples informations, veuillez consulter [Configuration supplémentaire d’instance Windows Amazon EC2](task-iam-roles.md#windows_task_IAM_roles). ## Rôle d'exécution de tâche `executionRoleArn` Type : Chaîne Obligatoire : Conditionnelle Le nom de ressource Amazon (ARN) du rôle d'exécution des tâches qui autorise l'agent de conteneur Amazon ECS à effectuer des appels d' AWS API en votre nom. Le rôle IAM d'exécution de la tâche est requis en fonction des besoins de votre tâche. Pour de plus amples informations, veuillez consulter [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md). ## Mode réseau `networkMode` Type : chaîne Obligatoire : non Mode réseau Docker à utiliser pour les conteneurs de la tâche. Pour les tâches Amazon ECS hébergées sur des instances Linux Amazon EC2, les valeurs valides sont `none`, `bridge`, `awsvpc` et `host`. Si aucun mode réseau n’est spécifié, le mode réseau par défaut est `bridge`. Pour les tâches Amazon ECS hébergées sur des instances Windows Amazon EC2, les valeurs valides sont `default` et `awsvpc`. Si aucun mode réseau n’est spécifié, le mode réseau `default` est utilisé. Si le mode réseau est défini sur `none`, les conteneurs de la tâche ne disposent d'aucune connectivité externe et les mappages de ports ne peuvent pas être spécifiés dans la définition du conteneur. Si le mode réseau est `bridge`, la tâche utilise le réseau virtuel intégré de Docker sous Linux, qui s'exécute à l'intérieur de chaque instance Amazon EC2 hébergeant la tâche. Le réseau virtuel intégré sous Linux utilise le pilote réseau Docker `bridge`. Si le mode réseau est `host`, la tâche utilise le réseau de l'hôte qui contourne le réseau virtuel intégré de Docker en mappant les ports de conteneur directement à l'ENI de l'instance Amazon EC2 qui héberge la tâche. Les mappages de ports dynamiques ne peuvent pas être utilisés dans ce mode réseau. Dans une définition de tâche qui utilise ce mode, un conteneur doit spécifier un numéro `hostPort` spécifique. Un numéro de port sur un hôte ne peut pas être utilisé par plusieurs tâches. Dans ce mode, vous ne pouvez pas exécuter plusieurs tâches de la même définition de tâche sur une instance Amazon EC2 unique. Lorsque vous exécutez des tâches en mode réseau `host`, vous n'exécutez pas de conteneurs à l'aide de l'utilisateur root (UID 0) pour une meilleure sécurité. Comme bonne pratique de sécurité, utilisez toujours un utilisateur non root. Si le mode réseau est `awsvpc`, une interface réseau Elastic est attribuée à la tâche, et vous devez spécifier une configuration `NetworkConfiguration` lorsque vous créez un service ou exécutez une tâche avec la définition de tâche. Pour de plus amples informations, veuillez consulter [Options de mise en réseau des tâches Amazon ECS pour EC2](task-networking.md). Si le mode réseau est `default`, la tâche utilise le réseau virtuel intégré de Docker sous Windows, qui s'exécute à l'intérieur de chaque instance Amazon EC2 hébergeant la tâche. Le réseau virtuel intégré sous Windows utilise le pilote réseau Docker `nat`. Les modes réseau `host` et `awsvpc` offrent les meilleures performances de mise en réseau pour les conteneurs, car ils utilisent la pile de réseau Amazon EC2. Avec les modes réseau `host` et `awsvpc`, les ports de conteneur exposés sont mappés directement au port hôte correspondant (pour le mode réseau hôte `host`) ou au port de l'interface réseau Elastic (pour le mode réseau `awsvpc`). Pour cette raison, vous ne pouvez pas utiliser de mappages de ports hôtes dynamiques. Le mode réseau autorisé dépend du système d’exploitation de l’instance EC2 sous-jacente. Sous Linux, n'importe quel mode réseau peut être utilisé. S'il s'agit de Windows, les modes `default` et `awsvpc` peuvent être utilisés. ## Plateforme d'exécution `operatingSystemFamily` Type : Chaîne Obligatoire : Conditionnelle Par défaut : LINUX Lorsque vous enregistrez une définition de tâche, vous spécifiez la famille du système d'exploitation. Les valeurs valides sont `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` et `WINDOWS_SERVER_20H2_CORE`. Toutes les définitions de tâches qui sont utilisées dans un service doivent avoir la même valeur pour ce paramètre. Lorsqu'une définition de tâche fait partie d'un service, cette valeur doit correspondre à la valeur `platformFamily` du service. `cpuArchitecture` Type : Chaîne Obligatoire : Conditionnelle Lorsque vous enregistrez une définition de tâche, vous pouvez spécifier l'architecture du processeur. Les valeurs valides sont `X86_64` et `ARM64`. Si vous ne spécifiez aucune valeur, Amazon ECS tente de placer les tâches sur l'architecture de processeur disponible en fonction de la configuration du fournisseur de capacité. Pour garantir que les tâches sont placées sur une architecture de processeur spécifique, spécifiez une valeur pour `cpuArchitecture` dans la définition des tâches. Toutes les définitions de tâches qui sont utilisées dans un service doivent avoir la même valeur pour ce paramètre. Lorsque vous avez des tâches Linux, vous pouvez définir la valeur sur `ARM64`. Pour de plus amples informations, veuillez consulter [Définitions de tâche Amazon ECS pour les charges de travail ARM 64 bits](ecs-arm64.md). ## Taille de la tâche Lorsque vous enregistrez une définition de tâche, vous pouvez spécifier la quantité totale d'UC et de mémoire utilisée pour cette tâche. Ces valeurs sont distinctes des valeurs `cpu` et `memory` au niveau de la définition de conteneur. Pour les tâches hébergées sur des instances Amazon EC2, ces champs sont facultatifs. **Note** Les paramètres d'UC et de mémoire de niveau tâche sont ignorés pour les conteneurs Windows. Nous vous recommandons de spécifier des ressources de niveau conteneur pour les conteneurs Windows. `cpu` Type : Chaîne Obligatoire : Conditionnelle Ce paramètre n'est pas pris en charge par les conteneurs Windows. Limite stricte du nombre d'unités UC à présenter pour la tâche. Vous pouvez spécifier les valeurs du processeur dans le fichier JSON sous forme de chaîne en unités de processeur ou en mode virtuel CPUs (vCPUs). Par exemple, vous pouvez spécifier une valeur de processeur soit `1024` en unités de processeur, soit `1 vCPU` en CPUs v. Lorsque la définition de tâche est enregistrée, une valeur vCPU est convertie en un entier indiquant les unités du processeur. Ce champ est facultatif. Si votre cluster n'a pas d'instances de conteneur enregistrées avec les unités UC demandées disponibles, la tâche échoue. Les valeurs prises en charge sont comprises entre `0.125` `192` v CPUs et CPUs v. `memory` Type : Chaîne Obligatoire : Conditionnelle Ce paramètre n'est pas pris en charge par les conteneurs Windows. Limite stricte de quantité de mémoire à allouer à la tâche. Vous pouvez spécifier les valeurs de mémoire dans la définition de la tâche sous forme de chaîne en mébioctets (Mio) ou en gigaoctets (Go). Par exemple, vous pouvez spécifier une valeur de mémoire de `3072` en Mio ou de `3 GB` en Go. Lorsque la définition de tâche est enregistrée, la valeur en Go est convertie en un nombre entier indiquant la quantité de Mio. Ce champ est facultatif et n'importe quelle valeur peut être utilisée. Si une valeur de mémoire au niveau de la tâche est spécifiée, la valeur de mémoire au niveau du conteneur est facultative. Si votre cluster n'a pas d'instances de conteneur enregistrées avec la mémoire demandée disponible, la tâche échoue. Vous pouvez optimiser l'utilisation de vos ressources en fournissant à vos tâches autant de mémoire que possible pour un type d'instance particulier. Pour de plus amples informations, veuillez consulter [Réservation de mémoire pour une instance de conteneur Amazon ECS Linux](memory-management.md). ## Définitions de conteneur Lorsque vous enregistrez une définition de tâche, vous devez spécifier une liste de définitions de conteneur qui sont transmises au démon Docker sur une instance de conteneur. Les paramètres suivants sont autorisés dans une définition de conteneur. **Topics** + [ ### Paramètres de définition de conteneur standards ](#standard_container_definition_params_ec2) + [ ### Paramètres de définition de conteneur avancés ](#advanced_container_definition_params_ec2) + [ ### Autres paramètres de définition de conteneur ](#other_container_definition_params_ec2) ### Paramètres de définition de conteneur standards Les paramètres de définition de tâche suivants sont obligatoires ou utilisés dans la plupart des définitions de conteneur. **Topics** + [ #### Nom ](#container_definition_name_ec2) + [ #### Image ](#container_definition_image_ec2) + [ #### Mémoire ](#container_definition_memory_ec2) + [ #### Mappages de ports ](#container_definition_portmappings_ec2) + [ #### Informations d'identification du référentiel privé ](#container_definition_repositoryCredentials_ec2) #### Nom `name` Type : Chaîne Obligatoire : oui Le nom d'un conteneur. Jusqu'à 255 lettres (majuscules et minuscules), chiffres, traits d'union et traits de soulignement sont autorisés. Si vous associez plusieurs conteneurs dans une définition de tâche, vous pouvez spécifier l'option `name` d'un conteneur dans l'option `links` d'un autre conteneur. Cela permet de connecter les conteneurs. #### Image `image` Type : Chaîne Obligatoire : oui Image utilisée pour démarrer un conteneur. Cette chaîne est transmise directement au démon Docker. Par défaut, les images dans le registre Docker Hub sont disponibles. Vous pouvez également spécifier d'autres référentiels avec soit `repository-url/image:tag`, soit `repository-url/image@digest`. Il peut comporter jusqu'à 255 lettres (majuscules et minuscules), des chiffres, des tirets, des traits de soulignement, deux points, des points, des barres obliques et des signes dièse. Ce paramètre correspond à `Image` dans la commande docker create-container et au paramètre `IMAGE` de la commande docker run. + Lorsqu'une nouvelle tâche démarre, l'agent de conteneur Amazon ECS extrait la version la plus récente de l'image et de l'étiquette spécifiées afin que le conteneur puisse les utiliser. Notez cependant que les mises à jour ultérieures apportées à une image de référentiel ne sont pas répercutées sur les tâches déjà en cours d'exécution. + Lorsque vous ne spécifiez pas de balise ou de résumé dans le chemin de l'image dans la définition de tâche, l'agent de conteneur Amazon ECS utilise la `latest` balise pour extraire l'image spécifiée. + Les mises à jour ultérieures d'une image de référentiel ne sont pas répercutées sur les tâches déjà en cours d'exécution. + Les images des registres privés sont prises en charge. Pour de plus amples informations, veuillez consulter [Utilisation d'images autres que des AWS conteneurs dans Amazon ECS](private-auth.md). + Les images des référentiels Amazon ECR peuvent être spécifiées en utilisant soit la convention de dénomination complète `registry/repository:tag` ou `registry/repository@digest` (par exemple, `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app:latest` ou `aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE`). + Les images dans les référentiels officiels sur Docker Hub utilisent un nom unique (par exemple, `ubuntu` ou `mongo`). + Les images dans les autres référentiels sur Docker Hub sont qualifiées par un nom d'organisation (par exemple, `amazon/amazon-ecs-agent`). + Les images dans les autres référentiels en ligne sont qualifiées par un nom de domaine (par exemple, `quay.io/assemblyline/ubuntu`). `versionConsistency` Type : Chaîne Valeurs valides : `enabled`\$1`disabled` Obligatoire : non Spécifie si Amazon ECS résoudra la balise d’image de conteneur fournie dans la définition du conteneur en un condensé d’image. Par défaut, ce comportement est `enabled`. Si vous définissez la valeur d’un conteneur sur `disabled`, Amazon ECS ne résoudra pas la balise d’image de conteneur en un condensé et utilisera l’URI d’image d’origine spécifiée dans la définition du conteneur pour le déploiement. Pour plus d’informations sur la résolution des images de conteneur, consultez la section [Résolution des images de conteneurs](deployment-type-ecs.md#deployment-container-image-stability). #### Mémoire `memory` Type : Integer Obligatoire : non La quantité de mémoire (en Mio) à présenter au conteneur. Si votre conteneur tente de dépasser la mémoire spécifiée ici, il sera désactivé. La quantité totale de mémoire réservée pour tous les conteneurs au sein d'une tâche doit être inférieure à la valeur `memory` de la tâche, si cette valeur est spécifiée. Ce paramètre correspond à `Memory` dans la commande docker create-container et à l’option `--memory` dans la commande docker run. Vous devez spécifier une valeur de mémoire soit au niveau de la tâche, soit au niveau du conteneur. Si vous spécifiez à la fois une valeur de `memory` au niveau du conteneur et une valeur `memoryReservation`, la valeur de `memory` doit être supérieure à celle de `memoryReservation`. Si vous spécifiez `memoryReservation`, cette valeur est soustraite des ressources mémoire disponibles pour l'instance de conteneur sur laquelle le conteneur est placé. Sinon, c'est la valeur `memory` qui est utilisée. Le démon Docker 20.10.0 ou ultérieur réserve un minimum de 6 Mio de mémoire pour un conteneur. Par conséquent, ne spécifiez pas moins de 6 Mio de mémoire pour vos conteneurs. Le démon Docker 19.03.13-ce ou antérieur réserve un minimum de 4 Mio de mémoire pour un conteneur. Par conséquent, ne spécifiez pas moins de 4 Mio de mémoire pour vos conteneurs. Si vous essayez d'optimiser l'utilisation de vos ressources en fournissant à vos tâches autant de mémoire que possible pour un type d'instance particulier, consultez [Réservation de mémoire pour une instance de conteneur Amazon ECS Linux](memory-management.md). `memoryReservation` Type : Integer Obligatoire : non La limite flexible (en Mio) de mémoire à réserver pour le conteneur. En cas de contention de la mémoire système, Docker tente de garder la mémoire du conteneur en deçà de cette limite flexible. Toutefois, votre conteneur peut utiliser davantage de mémoire en cas de besoin. Le conteneur peut consommer jusqu'à la limite stricte spécifiée avec le paramètre `memory` (le cas échéant), ou la totalité de la mémoire disponible sur l'instance de conteneur, selon la première valeur atteinte. Ce paramètre correspond à `MemoryReservation` dans la commande docker create-container et à l’option `--memory-reservation` dans la commande docker run. Si aucune valeur de mémoire au niveau de la tâche n'est spécifiée, vous devez indiquer un nombre entier différent de zéro pour `memory` ou `memoryReservation` dans une définition de conteneur. Si vous spécifiez les deux, `memory` doit être supérieur à `memoryReservation`. Si vous spécifiez `memoryReservation`, cette valeur est soustraite des ressources mémoire disponibles pour l'instance de conteneur sur laquelle le conteneur est placé. Sinon, c'est la valeur `memory` qui est utilisée. Par exemple, supposons que votre conteneur utilise normalement 128 Mio de mémoire, mais qu'il lui arrive d'utiliser jusqu'à 256 Mio de mémoire pendant de courtes périodes. Vous pouvez définir une `memoryReservation` de 128 Mio et une limite stricte `memory` de 300 Mio. Cette configuration permet au conteneur de ne réserver que 128 Mio de mémoire à partir des ressources restantes sur l'instance de conteneur. En même temps, cette configuration permet également au conteneur d'utiliser davantage de ressources mémoire lorsque cela est nécessaire. Ce paramètre n'est pas pris en charge par les conteneurs Windows. Le démon Docker 20.10.0 ou ultérieur réserve un minimum de 6 Mio de mémoire pour un conteneur. Par conséquent, ne spécifiez pas moins de 6 Mio de mémoire pour vos conteneurs. Le démon Docker 19.03.13-ce ou antérieur réserve un minimum de 4 Mio de mémoire pour un conteneur. Par conséquent, ne spécifiez pas moins de 4 Mio de mémoire pour vos conteneurs. Si vous essayez d'optimiser l'utilisation de vos ressources en fournissant à vos tâches autant de mémoire que possible pour un type d'instance particulier, consultez [Réservation de mémoire pour une instance de conteneur Amazon ECS Linux](memory-management.md). #### Mappages de ports `portMappings` Type : tableau d'objets Obligatoire : non Les mappages de ports exposent les ports réseau de votre conteneur au monde extérieur, ce qui permet aux clients d’accéder à votre application. Ils sont également utilisés pour la communication entre conteneurs au sein d’une même tâche. Pour les définitions de tâche qui utilisent le mode réseau `awsvpc`, spécifiez uniquement `containerPort`. Le `hostPort` est toujours ignoré et le port du conteneur est automatiquement mappé à un port aléatoire portant un numéro élevé sur l’hôte. Les mappages de ports sur Windows utilisent l'adresse de passerelle `NetNAT` plutôt que `localhost`. Il n'existe aucune boucle pour les mappages de ports sous Windows, donc vous ne pouvez pas accéder au port mappé d'un conteneur à partir de l'hôte lui-même. La plupart des champs de ce paramètre (y compris `containerPort`, `hostPort`, `protocol`) correspondent à `PortBindings` dans la commande docker create-container et à l’option `--publish` de docker run. Si le mode réseau d'une définition de tâche est défini sur `host`, les ports hôtes doivent être indéfinis ou correspondre au port du conteneur dans le mappage de port. Une fois qu'une tâche passe à l'état `RUNNING`, les affectations manuelles et automatiques de ports de conteneur et d'hôte sont visibles aux emplacements suivants : + Console : la section **Network Bindings** (Liaisons réseau) de la description d'un conteneur pour une tâche sélectionnée. + AWS CLI : la section `networkBindings` de la sortie de la commande **describe-tasks**. + API : la réponse `DescribeTasks`. + Métadonnées : point de terminaison des métadonnées de la tâche. `appProtocol` Type : chaîne Obligatoire : non Protocole d'application utilisé pour le mappage de port. Ce paramètre s'applique uniquement à Service Connect. Nous vous conseillons de définir ce paramètre de manière cohérente avec le protocole que votre application utilise. Si vous définissez ce paramètre, Amazon ECS ajoute une gestion de connexion spécifique au protocole au proxy Service Connect. Si vous définissez ce paramètre, Amazon ECS ajoute une télémétrie spécifique au protocole dans la console Amazon ECS et. CloudWatch Si vous ne définissez aucune valeur pour ce paramètre, le protocole TCP est utilisé. Toutefois, Amazon ECS n'ajoute pas de télémétrie spécifique au protocole pour TCP. Pour de plus amples informations, veuillez consulter [Utilisation de Service Connect pour connecter des services Amazon ECS avec des noms abrégés](service-connect.md). Valeurs de protocole valides : `"http" | "http2" | "grpc" ` `containerPort` Type : Integer Obligatoire : oui, lorsque des objets `portMappings` sont utilisés Le numéro de port sur le conteneur qui est lié au port hôte spécifié par l'utilisateur ou affecté automatiquement. Pour les tâches utilisant le mode réseau `awsvpc`, vous utilisez `containerPort` pour spécifier les ports exposés. Supposons que vous utilisiez des conteneurs dans une tâche avec les fournisseurs de capacité EC2 et que vous spécifiez un port de conteneur et non un port hôte. Ensuite, votre conteneur reçoit automatiquement un port hôte dans la plage de ports éphémères. Pour de plus amples informations, veuillez consulter `hostPort`. Les mappages de ports qui sont automatiquement affectés de cette façon ne sont pas comptabilisés dans le quota des 100 ports réservés d'une instance de conteneur. `containerPortRange` Type : chaîne Obligatoire : non Plage de numéros de port du conteneur liée à la plage de ports hôtes mappés dynamiquement. Vous ne pouvez définir ce paramètre qu'à l'aide de l'API `register-task-definition`. L'option est disponible dans le paramètre `portMappings`. Pour plus d'informations, consultez [register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html) dans la *référence AWS Command Line Interface *. Les règles suivantes s'appliquent lorsque vous spécifiez une `containerPortRange` : + Vous devez utiliser le mode réseau `bridge` ou le mode réseau `awsvpc`. + Ce paramètre est disponible pour les systèmes d'exploitation Windows et Linux. + L'instance de conteneur doit au moins disposer de la version 1.67.0 de l'agent de conteneur et au moins de la version 1.67.0-1 du package `ecs-init`. + Vous pouvez spécifier un maximum de 100 plages de ports pour chaque conteneur. + Vous ne spécifiez pas de `hostPortRange`. La valeur de `hostPortRange` est définie comme suit : + Pour les conteneurs d'une tâche en mode réseau `awsvpc`, le `hostPort` est défini sur la même valeur que le `containerPort`. Il s'agit d'une stratégie de mappage statique. + Pour les conteneurs d'une tâche en mode réseau `bridge`, l'agent Amazon ECS trouve les ports hôtes ouverts dans la plage éphémère par défaut et les transmet à Docker pour les lier aux ports du conteneur. + Les valeurs valides de `containerPortRange` sont comprises entre 1 et 65535. + Un port peut uniquement être inclus dans un mappage de port pour chaque conteneur. + Vous ne pouvez pas spécifier de plages de ports qui se chevauchent. + Le premier port de la plage doit être inférieur au dernier port de la plage. + Docker vous recommande de désactiver le proxy Docker dans le fichier de configuration du démon Docker en présence d'un grand nombre de ports. Pour plus d'informations, consultez le [numéro \$111185](https://github.com/moby/moby/issues/11185) sur GitHub. Pour plus d'informations sur la désactivation du proxy Docker dans le fichier de configuration du démon Docker, veuillez consulter [Démon Docker](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon) dans le *Guide du développeur Amazon ECS* (langue française non garantie). Vous pouvez appeler [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) pour voir la `hostPortRange` correspondant aux ports hôtes liés aux ports de conteneur. Les plages de ports ne sont pas incluses dans les événements de tâches Amazon ECS, qui sont envoyés à EventBridge. Pour de plus amples informations, veuillez consulter [Automatisez les réponses aux erreurs Amazon ECS à l'aide de EventBridge](cloudwatch_event_stream.md). `hostPortRange` Type : chaîne Obligatoire : non Plage de numéros de port sur l'hôte utilisée avec la liaison réseau. Elle est attribuée par Docker et délivrée par l'agent Amazon ECS. `hostPort` Type : Integer Obligatoire : non Le numéro de port sur l'instance de conteneur à réserver pour votre conteneur. Vous pouvez spécifier un port hôte non réservé pour le mappage de ports de votre conteneur. C'est ce que l'on appelle le mappage *statique* des ports hôtes. Vous pouvez également omettre le `hostPort` (ou le définir sur `0`) lorsque vous spécifiez un `containerPort`. Votre conteneur reçoit automatiquement un port dans la plage de ports éphémères pour le système d'exploitation et la version Docker de votre instance de conteneur. C'est ce que l'on appelle le mappage *dynamique* des ports hôtes. La plage de ports éphémères par défaut pour Docker 1.6.0 et versions ultérieures est répertoriée dans l'instance sous `/proc/sys/net/ipv4/ip_local_port_range`. Si ce paramètre de noyau n'est pas disponible, la plage de ports éphémères par défaut de `49153–65535` est utilisée. N'essayez pas de spécifier un port d'hôte dans la plage de ports éphémères. Cela est dû au fait qu'ils sont réservés à une affectation automatique. En général, les ports inférieurs à `32768` ne sont pas compris dans la plage de ports éphémères. Vous pouvez utiliser les `ECS_DYNAMIC_HOST_PORT_RANGE` paramètres de configuration de l'agent de conteneur ECS pour spécifier une plage personnalisée pour les ports hôtes attribués dynamiquement. Cela peut être utile si vos tâches ne démarrent pas en raison de conflits de ports avec d'autres processus de l'instance de conteneur, tels que les connexions sortantes qui utilisent également des ports de la plage de ports éphémères. Pour de plus amples informations, veuillez consulter [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md). Les ports réservés par défaut sont le port `22` pour SSH, les ports Docker `2375` et `2376`, et les ports d'agent de conteneur Amazon ECS `51678-51680`. Tout port hôte ayant été spécifié précédemment par l'utilisateur pour une tâche en cours d'exécution est également réservé pendant l'exécution de la tâche. Après l'arrêt d'une tâche, le port hôte est libéré. Les ports réservés actuels s’affichent dans les `remainingResources` de la sortie de **describe-container-instances**. Une instance de conteneur peut avoir jusqu'à 100 ports réservés à la fois, y compris les ports réservés par défaut. Les ports affectés automatiquement ne sont pas pris en compte dans le quota des 100 ports réservés. `name` Type : Chaîne Obligatoire : Non, requis pour que Service Connect et VPC Lattice soient configurés dans un service Nom utilisé pour le mappage de port. Ce paramètre ne s’applique qu’à Service Connect et VPC Lattice. Ce paramètre correspond au nom que vous utilisez dans la configuration Service Connect et VPC Lattice d’un service. Pour de plus amples informations, veuillez consulter [Utilisation de Service Connect pour connecter des services Amazon ECS avec des noms abrégés](service-connect.md). Dans l’exemple suivant, les deux champs obligatoires pour Service Connect et VPC Lattice sont utilisés. ``` "portMappings": [ { "name": string, "containerPort": integer } ] ``` `protocol` Type : chaîne Obligatoire : non Le protocole utilisé pour le mappage de port. Les valeurs valides sont `tcp` et `udp`. La valeur par défaut est `tcp`. Seul `tcp` est pris en charge pour Service Connect. N'oubliez pas que `tcp` est implicite si ce champ n'est pas défini. La prise en charge du protocole UDP n'est disponible que sur les instances de conteneur qui ont été lancées avec la version 1.2.0 ou ultérieure de l'agent de conteneur Amazon ECS (comme l'AMI `amzn-ami-2015.03.c-amazon-ecs-optimized`), ou avec des agents de conteneur qui ont été mis à jour vers la version 1.3.0 ou ultérieure. Pour mettre à jour votre agent de conteneur avec la dernière version, consultez [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md). Si vous spécifiez un port hôte, utilisez la syntaxe suivante. ``` "portMappings": [ { "containerPort": integer, "hostPort": integer } ... ] ``` Si vous souhaitez utiliser un port hôte affecté automatiquement, utilisez la syntaxe suivante. ``` "portMappings": [ { "containerPort": integer } ... ] ``` #### Informations d'identification du référentiel privé `repositoryCredentials` Type : objet [RepositoryCredentials](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RepositoryCredentials.html) Obligatoire : non Informations d'identification du référentiel pour l'authentification de registre privé. Pour de plus amples informations, veuillez consulter [Utilisation d'images autres que des AWS conteneurs dans Amazon ECS](private-auth.md). `credentialsParameter` Type : Chaîne Obligatoire : oui, lorsque des objets `repositoryCredentials` sont utilisés L'Amazon Resource Name (ARN) du secret contenant les informations d'identification du référentiel privé. Pour de plus amples informations, veuillez consulter [Utilisation d'images autres que des AWS conteneurs dans Amazon ECS](private-auth.md). Lorsque vous utilisez l'API Amazon ECS AWS CLI AWS SDKs, ou si le secret existe dans la même région que la tâche que vous lancez, vous pouvez utiliser l'ARN complet ou le nom du secret. Lorsque vous utilisez le AWS Management Console, vous devez spécifier l'ARN complet du secret. Voici un extrait de code d'une définition de tâche indiquant les paramètres requis : ``` "containerDefinitions": [ { "image": "private-repo/private-image", "repositoryCredentials": { "credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name" } } ] ``` ### Paramètres de définition de conteneur avancés Les paramètres de définition de conteneur avancés suivants étendent les capacités de la commande docker run qui est utilisée pour lancer des conteneurs sur vos instances de conteneur Amazon ECS. **Topics** + [ #### Politique de redémarrage ](#container_definition_restart_policy_ec2) + [ #### Surveillance de l'état ](#container_definition_healthcheck_ec2) + [ #### Environnement ](#container_definition_environment_ec2) + [ #### Paramètres réseau ](#container_definition_network_ec2) + [ #### Stockage et journalisation ](#container_definition_storage_ec2) + [ #### Sécurité ](#container_definition_security_ec2) + [ #### Limites des ressources ](#container_definition_limits_ec2) + [ #### Étiquettes Docker ](#container_definition_labels_ec2) #### Politique de redémarrage `restartPolicy` La politique de redémarrage du conteneur et les paramètres de configuration associés. Lorsque vous configurez une politique de redémarrage pour un conteneur, Amazon ECS peut redémarrer le conteneur sans avoir à remplacer la tâche. Pour de plus amples informations, veuillez consulter [Redémarrage de conteneurs individuels dans les tâches Amazon ECS à l’aide de politiques de redémarrage de conteneurs](container-restart-policy.md). `enabled` Type : Boolean Obligatoire : oui Spécifie si une politique de redémarrage est activée pour le conteneur. `ignoredExitCodes` Type : tableau integer Obligatoire : non Liste des codes de sortie qu’Amazon ECS ignorera et pour lesquels il ne tentera pas de redémarrage. Vous pouvez spécifier un maximum de 50 codes de sortie de conteneur. Par défaut, Amazon ECS n’ignore aucun code de sortie. `restartAttemptPeriod` Type : Integer Obligatoire : non Durée (en secondes) pendant laquelle le conteneur doit fonctionner avant de pouvoir tenter un redémarrage. Un conteneur ne peut être redémarré qu’une fois toutes les `restartAttemptPeriod` secondes. Si un conteneur n’est pas en mesure de fonctionner pendant cette période et qu’il se ferme prématurément, il ne sera pas redémarré. Vous pouvez définir une `restartAttemptPeriod` minimale de 60 secondes et une `restartAttemptPeriod` maximale de 1 800 secondes. Par défaut, un conteneur doit fonctionner pendant 300 secondes avant de pouvoir être redémarré. #### Surveillance de l'état `healthCheck` Commande de surveillance de l'état du conteneur et paramètres de configuration associés pour le conteneur. Pour de plus amples informations, veuillez consulter [Détermination de l’état des tâches Amazon ECS à l’aide de la surveillance de l’état des conteneurs](healthcheck.md). `command` Tableau de chaînes représentant la commande que le conteneur exécute pour déterminer si celle-ci est saine. Le tableau de chaînes peut commencer par `CMD` pour exécuter directement les arguments de la commande, ou par `CMD-SHELL` pour exécuter la commande avec le shell par défaut du conteneur. Si vous n'en spécifiez aucun, `CMD` est utilisé. Lorsque vous enregistrez une définition de tâche dans le AWS Management Console, utilisez une liste de commandes séparées par des virgules. Ces commandes sont converties en une chaîne une fois la définition de tâche créée. Un exemple d'entrée pour une surveillance de l'état est le suivant. ``` CMD-SHELL, curl -f http://localhost/ || exit 1 ``` Lorsque vous enregistrez une définition de tâche à l'aide du AWS CLI panneau AWS Management Console JSON APIs, placez la liste des commandes entre crochets. Un exemple d'entrée pour une surveillance de l'état est le suivant. ``` [ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ] ``` Un code de sortie de 0, avec aucune sortie `stderr`, indique la réussite et un code de sortie autre que zéro indique qu'il s'agit d'un échec. `interval` La durée (en secondes) entre chaque surveillance de l'état. Vous pouvez indiquer une durée comprise entre 5 et 300 secondes. La valeur par défaut est de 30 secondes. `timeout` La durée (en secondes) d'attente pour qu'une surveillance de l'état réussisse avant qu'elle ne soit considérée comme un échec. Vous pouvez indiquer une durée comprise entre 2 et 60 secondes. La valeur par défaut est de 5 secondes. `retries` Nombre de nouvelles tentatives d'exécution d'une surveillance de l'état ayant échoué avant que le conteneur soit considéré comme défectueux. Vous pouvez indiquer un nombre de tentatives compris en 1 et 10. La valeur par défaut est de trois tentatives. `startPeriod` La période de grâce facultative pour donner aux conteneurs le temps de démarrer avant l'échec des surveillance de l'état est prise en compte dans le nombre maximal de tentatives. Vous pouvez indiquer une durée comprise entre 0 et 300 secondes. Par défaut, la `startPeriod` est désactivée. Si une vérification de l'état aboutit dans le délai défini par `startPeriod`, le conteneur est considéré comme sain et toutes les défaillances suivantes sont prises en compte dans le nombre maximal de nouvelles tentatives. #### Environnement `cpu` Type : Integer Obligatoire : non Le nombre d'unités `cpu` que l'agent de conteneur Amazon ECS réserve pour le conteneur. Sous Linux, ce paramètre correspond à `CpuShares` dans la section [Créer un conteneur](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate). Vous pouvez déterminer le nombre d'unités de processeur qui sont disponibles pour chaque type d'instance Amazon EC2. Pour ce faire, multipliez le nombre de v CPUs répertorié pour ce type d'instance sur la page détaillée des [instances Amazon EC2](https://aws.amazon.com/ec2/instance-types/) par 1 024. Les conteneurs Linux partagent des unités de processeur non allouées avec les autres conteneurs de l'instance de conteneur selon le même ratio que la quantité allouée. Par exemple, supposons que vous exécutez une tâche à conteneur unique sur un type d'instance à cœur unique avec 512 unités de processeur spécifiées pour ce conteneur. De plus, cette tâche est la seule tâche en cours d'exécution sur l'instance de conteneur. Dans cet exemple, le conteneur peut utiliser le partage complet de 1 024 unités UC à tout moment. Toutefois, supposons que vous ayez lancé une autre copie de la même tâche sur cette instance de conteneur. Un minimum de 512 unités de processeur est affecté à chaque tâche si nécessaire. De même, si l'autre conteneur n'utilise pas le processeur restant, chaque conteneur peut bénéficier d'une utilisation plus importante du processeur. Toutefois, si les deux tâches sont actives à 100 % en permanence, elles sont limitées à 512 unités d'UC. Sur les instances de conteneur Linux, le démon Docker de l'instance de conteneur se sert de la valeur de processeur pour calculer les ratios de partage de processeur relatifs pour les conteneurs en cours d'exécution. La valeur de parts d’UC minimale autorisée par le noyau Linux est de 2, et la valeur de parts d’UC maximale autorisée par le noyau Linux est de 262 144. Toutefois, le paramètre UC n’est pas obligatoire et vous pouvez utiliser des valeurs d’UC inférieures à 2 ou supérieures à 262 144 dans vos définitions de conteneur. Pour les valeurs d’UC inférieures à 2 (y compris null) ou supérieures à 262 144, le comportement varie selon la version de l’agent de conteneur Amazon ECS : + **Versions de l'agent <= 1.1.0 :** les valeurs de processeur nulles et égales à zéro sont transmises à Docker en tant que 0, ce que Docker convertit ensuite en 1 024 parts de processeur. Les valeurs de processeur de 1 sont transmises à Docker en tant que 1, ce que le noyau Linux convertit en deux parts de processeur. + **Versions de l'agent > = 1.2.0 :** les valeurs de processeur nulles, 0 et 1 sont transmises à Docker en tant que deux partages de processeur.. + **Versions d’agent >= 1.84.0 :** les valeurs d’UC supérieures à 256 vCPU sont transmises à Docker avec la valeur de 256, ce qui équivaut à 262 144 partages d’UC. Sur les instances de conteneur Windows, le quota de processeur est appliqué comme quota absolu. Les conteneurs Windows n'ont accès qu'à la quantité spécifiée de processeur décrite dans la définition de tâche. Une valeur de processeur nulle ou égale à zéro est transmise à Docker comme étant `0`. Windows interprète ensuite cette valeur comme 1 % d'un processeur. Pour voir d'autres exemples, veuillez consulter le billet de blog [How Amazon ECS manages CPU and memory resources](https://aws.amazon.com/blogs/containers/how-amazon-ecs-manages-cpu-and-memory-resources/). `gpu` Type : objet [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obligatoire : non Le nombre de `GPUs` physiques que l'agent de conteneur Amazon ECS réserve pour le conteneur. Le nombre de conteneurs GPUs réservés à tous les conteneurs d'une tâche ne doit pas dépasser le nombre de conteneurs disponibles GPUs sur l'instance de conteneur sur laquelle la tâche est lancée. Pour de plus amples informations, veuillez consulter [Définitions de tâches Amazon ECS pour les charges de travail GPU](ecs-gpu.md). Ce paramètre n'est pas pris en charge par les conteneurs Windows. `Elastic Inference accelerator` Type : objet [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) Obligatoire : non Pour le type `InferenceAccelerator`, `value` correspond à `deviceName` d'un `InferenceAccelerator` spécifié dans une définition de tâche. Pour de plus amples informations, veuillez consulter [Nom de l'accélérateur Elastic Inference (obsolète)](task_definition_parameters.md#elastic-Inference-accelerator). Ce paramètre n'est pas pris en charge par les conteneurs Windows. `essential` Type : booléen Obligatoire : non Supposons que le paramètre `essential` d'un conteneur soit marqué comme `true`, et que ce conteneur échoue ou s'arrête pour une raison quelconque. Ensuite, tous les autres conteneurs qui font partie de la tâche sont arrêtés. Si le paramètre `essential` d'un conteneur a la valeur `false`, son échec n'a pas d'incidence sur le reste des conteneurs dans la tâche. Si ce paramètre n'est pas spécifié, le conteneur est supposé essentiel. Toutes les tâches doivent comporter au moins un conteneur essentiel. Supposons que vous disposiez d'une application composée de plusieurs conteneurs. Ensuite, les conteneurs de groupes qui sont utilisés dans un même but pour former des composants, et séparer les différents composants en plusieurs définitions de tâches. Pour de plus amples informations, veuillez consulter [Architecture de votre application pour Amazon ECS](application_architecture.md). ``` "essential": true|false ``` `entryPoint` Les premières versions de l'agent de conteneur Amazon ECS ne traitent pas correctement les paramètres `entryPoint`. Si vous rencontrez des difficultés pour utiliser `entryPoint`, mettez à jour l'agent de conteneur ou saisissez plutôt vos commandes et vos arguments sous forme d'éléments de tableau `command`. Type : tableau de chaînes Obligatoire : non Point d'entrée qui est transmis au conteneur. ``` "entryPoint": ["string", ...] ``` `command` Type : tableau de chaînes Obligatoire : non La commande transmise au conteneur. Ce paramètre correspond à `Cmd` dans la commande create-container et au paramètre `COMMAND` de docker run. S'il existe plusieurs arguments, assurez-vous que chaque argument est une chaîne séparée dans le tableau. ``` "command": ["string", ...] ``` `workingDirectory` Type : chaîne Obligatoire : non Répertoire de travail dans lequel exécuter les commandes à l'intérieur du conteneur. Ce paramètre correspond à `WorkingDir` dans la section [Create a container](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) (Créer un conteneur) de l'[API Docker à distance](https://docs.docker.com/reference/api/engine/version/v1.38/) et l'option `--workdir` correspond à [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/). ``` "workingDirectory": "string" ``` `environmentFiles` Type : tableau d'objets Obligatoire : non Liste des fichiers contenant les variables d'environnement à transmettre à un conteneur. Ce paramètre correspond à l’option `--env-file` de la commande docker run. Lorsque le protocole FIPS est activé, les noms de compartiments comportant des points (.) (par exemple, amzn-s3-demo-bucket1.name.example) ne sont pas pris en charge. La présence de points (.) dans le nom du compartiment empêche le démarrage de la tâche, car l’agent ne peut pas extraire le fichier de variables d’environnement depuis Amazon S3. Ceci n'est pas disponible pour les conteneurs Windows. Vous pouvez spécifier jusqu'à dix fichiers d'environnement. Le fichier doit avoir une extension de fichier `.env`. Chaque ligne d'un fichier d'environnement contient une variable d'environnement au format `VARIABLE=VALUE`. Les lignes commençant par `#` sont traitées comme des commentaires et sont ignorées. Si des variables d'environnement individuelles sont spécifiées dans la définition du conteneur, elles ont priorité sur les variables contenues dans un fichier d'environnement. Si plusieurs fichiers d'environnement contenant la même variable sont spécifiés, ils sont traités de haut en bas. Nous vous recommandons d'utiliser des noms de variables uniques. Pour de plus amples informations, veuillez consulter [Transmission d’une variable d’environnement individuelle à un conteneur Amazon ECS](taskdef-envfiles.md). `value` Type : Chaîne Obligatoire : oui L'Amazon Resource Name (ARN) de l'objet Amazon S3 contenant le fichier de variable d'environnement. `type` Type : Chaîne Obligatoire : oui Type de fichier à utiliser La seule valeur prise en charge est `s3`. `environment` Type : tableau d'objets Obligatoire : non Variables d'environnement à transmettre à un conteneur. Ce paramètre correspond à `Env` dans la commande docker create-container et à l’option `--env` dans la commande docker run. Nous déconseillons l'utilisation des variables d'environnement en texte clair pour les informations sensibles, comme les données d'identification. `name` Type : Chaîne Obligatoire : oui lorsque `environment` est utilisé Nom de la variable d'environnement. `value` Type : Chaîne Obligatoire : oui lorsque `environment` est utilisé Valeur de la variable d'environnement. ``` "environment" : [ { "name" : "string", "value" : "string" }, { "name" : "string", "value" : "string" } ] ``` `secrets` Type : tableau d'objets Obligatoire : non Objet représentant le secret à exposer à votre conteneur. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur Amazon ECS](specifying-sensitive-data.md). `name` Type : Chaîne Obligatoire : oui Valeur à définir comme variable d'environnement sur le conteneur. `valueFrom` Type : Chaîne Obligatoire : oui Secret à exposer au conteneur. Les valeurs prises en charge sont soit le nom Amazon Resource (ARN) complet du AWS Secrets Manager secret, soit l'ARN complet du paramètre dans le AWS Systems Manager Parameter Store. Si le paramètre Systems Manager Parameter Store ou le paramètre Secrets Manager existe au même endroit Région AWS que la tâche que vous lancez, vous pouvez utiliser l'ARN complet ou le nom du secret. Si le paramètre existe dans une autre région, l'ARN complet doit être spécifié. ``` "secrets": [ { "name": "environment_variable_name", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name" } ] ``` #### Paramètres réseau `disableNetworking` Type : booléen Obligatoire : non Quand ce paramètre a la valeur true, la mise en réseau est désactivée dans le conteneur. Ce paramètre n'est pas pris en charge pour les conteneurs ou tâches Windows qui utilisent le mode réseau `awsvpc`. La valeur par défaut est `false`. ``` "disableNetworking": true|false ``` `links` Type : tableau de chaînes Obligatoire : non Le paramètre `link` permet aux conteneurs de communiquer entre eux sans avoir besoin de définir des mappages de ports. Ce paramètre n'est pris en charge que si le mode réseau d'une définition de tâche est défini sur `bridge`. La construction `name:internalName` est analogue à `name:alias` dans les liaisons Docker. Il peut comporter jusqu’à 255 lettres (majuscules et minuscules), des chiffres, des tirets ou des traits de soulignement. Ce paramètre n'est pas pris en charge pour les conteneurs ou tâches Windows qui utilisent le mode réseau `awsvpc`. Des conteneurs situés sur la même instance de conteneur peuvent communiquer entre eux sans nécessiter de liens ou de mappages de ports hôtes. L'isolation réseau sur une instance de conteneur est contrôlée par les groupes de sécurité et les paramètres de VPC. ``` "links": ["name:internalName", ...] ``` `hostname` Type : chaîne Obligatoire : non Nom d'hôte à utiliser pour votre conteneur. Ce paramètre correspond à `Hostname` dans docker create-container et à l’option `--hostname` de docker run. Si vous utilisez le mode réseau `awsvpc`, le paramètre `hostname` n'est pas pris en charge. ``` "hostname": "string" ``` `dnsServers` Type : tableau de chaînes Obligatoire : non Liste de serveurs DNS qui sont présentés au conteneur. Ce paramètre n'est pas pris en charge pour les conteneurs ou tâches Windows qui utilisent le mode réseau `awsvpc`. ``` "dnsServers": ["string", ...] ``` `dnsSearchDomains` Type : tableau de chaînes Obligatoire : non Modèle : ^[a-zA-Z0-9-.]\$10,253\$1[a-zA-Z0-9]\$1 Liste des domaines de recherche DNS qui sont présentés au conteneur. Ce paramètre correspond à `DnsSearch` dans la commande docker create-container et à l’option `--dns-search` dans la commande docker run. Ce paramètre n'est pas pris en charge pour les conteneurs ou tâches Windows qui utilisent le mode réseau `awsvpc`. ``` "dnsSearchDomains": ["string", ...] ``` `extraHosts` Type : tableau d'objets Obligatoire : non Liste de noms d'hôte et de mappages d'adresses IP à ajouter au fichier `/etc/hosts` dans le conteneur. Ce paramètre correspond à `ExtraHosts` dans la commande docker create-container et à l’option `--add-host` dans la commande docker run. Ce paramètre n'est pas pris en charge pour les conteneurs ou tâches Windows qui utilisent le mode réseau `awsvpc`. ``` "extraHosts": [ { "hostname": "string", "ipAddress": "string" } ... ] ``` `hostname` Type : Chaîne Obligatoire : oui, lorsque des objets `extraHosts` sont utilisés Nom d'hôte à utiliser dans l'entrée `/etc/hosts`. `ipAddress` Type : Chaîne Obligatoire : oui, lorsque des objets `extraHosts` sont utilisés Adresse IP à utiliser dans l'entrée `/etc/hosts`. #### Stockage et journalisation `readonlyRootFilesystem` Type : booléen Obligatoire : non Quand ce paramètre a la valeur true, le conteneur ne dispose que d'un accès en lecture seule au système de fichiers racine. Ce paramètre correspond à `ReadonlyRootfs` dans la commande docker create-container et à l’option `--read-only` dans la commande docker run. Ce paramètre n'est pas pris en charge par les conteneurs Windows. La valeur par défaut est `false`. ``` "readonlyRootFilesystem": true|false ``` `mountPoints` Type : tableau d'objets Obligatoire : non Les points de montage pour les volumes de données dans votre conteneur. Ce paramètre correspond à `Volumes` dans l’API Docker create-container et à l’option `--volume` de docker run. Les conteneurs Windows peuvent monter des répertoires entiers sur le même lecteur que `$env:ProgramData`. Les conteneurs Windows ne peuvent pas monter de répertoires sur un autre lecteur, et les points de montage ne peuvent pas être utilisés sur plusieurs lecteurs. Vous devez spécifier des points de montage pour associer un volume Amazon EBS directement à une tâche Amazon ECS. `sourceVolume` Type : Chaîne Obligatoire : oui, lorsque des objets `mountPoints` sont utilisés Nom du volume à monter. `containerPath` Type : Chaîne Obligatoire : oui, lorsque des objets `mountPoints` sont utilisés Le chemin dans le conteneur où le volume sera monté. `readOnly` Type : booléen Obligatoire : non Si cette valeur est `true`, le conteneur ne peut accéder au volume qu'en lecture. Si cette valeur est `false`, le conteneur peut écrire sur le volume. La valeur par défaut est `false`. Pour les tâches qui exécutent le système d’exploitation Windows, laissez la valeur par défaut de `false`. `volumesFrom` Type : tableau d'objets Obligatoire : non Volumes de données à monter à partir d'un autre conteneur. Ce paramètre correspond à `VolumesFrom` dans la commande docker create-container et à l’option `--volumes-from` dans la commande docker run. `sourceContainer` Type : Chaîne Obligatoire : oui lorsque `volumesFrom` est utilisé Nom du conteneur à partir duquel monter les volumes. `readOnly` Type : booléen Obligatoire : non Si cette valeur est `true`, le conteneur ne peut accéder au volume qu'en lecture. Si cette valeur est `false`, le conteneur peut écrire sur le volume. La valeur par défaut est `false`. ``` "volumesFrom": [ { "sourceContainer": "string", "readOnly": true|false } ] ``` `logConfiguration` Type : [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html)Objet Obligatoire : non Spécification de configuration du journal pour le conteneur. Pour obtenir des exemples de définitions de tâche qui utilisent une configuration de journaux, consultez [Exemple de définitions de tâches Amazon ECS](example_task_definitions.md). Ce paramètre correspond à `LogConfig` dans la commande docker create-container et à l’option `--log-driver` dans la commande docker run. Par défaut, les conteneurs utilisent le même pilote de journalisation que celui utilisé par le démon Docker. Cependant, le conteneur peut utiliser un pilote de journalisation différent que celui du démon Docker en spécifiant un pilote de journal avec ce paramètre dans la définition de conteneur. Pour utiliser un pilote de journalisation différent pour un conteneur, le système de journal doit être configuré correctement sur l'instance de conteneur (ou sur un serveur de journal différent pour les options de journalisation à distance). Tenez compte des éléments suivants lorsque vous spécifiez une configuration de journal pour vos conteneurs : + Amazon ECS prend en charge un sous-ensemble des pilotes de journalisation qui sont disponibles pour le démon Docker. + Ce paramètre nécessite la version 1.18 ou ultérieure de l'API Docker à distance sur votre instance de conteneur. + L’agent de conteneur Amazon ECS qui s’exécute sur une instance de conteneur doit enregistrer les pilotes de journalisation disponibles sur cette instance avec la variable d’environnement `ECS_AVAILABLE_LOGGING_DRIVERS` avant que les conteneurs placés sur cette instance puissent utiliser ces options de configuration de journalisation. Pour de plus amples informations, veuillez consulter [Configuration de l'agent de conteneur 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` Type : Chaîne Valeurs valides : `"awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens"` Obligatoire : oui lorsque `logConfiguration` est utilisé Pilote de journal à utiliser pour le conteneur. Par défaut, les valeurs valides mentionnées ci-dessus sont les pilotes de journal avec lesquels l'agent de conteneur Amazon ECS peut communiquer. Les pilotes de journal pris en charge sont `awslogs`, `fluentd`, `gelf`, `json-file`, `journald`, `syslog`, `splunk` et `awsfirelens`. Pour plus d'informations sur l'utilisation du pilote de `awslogs` journal dans les définitions de tâches pour envoyer les journaux de vos conteneurs à CloudWatch Logs, consultez[Envoyez les journaux Amazon ECS à CloudWatch](using_awslogs.md). Pour de plus amples informations sur l'utilisation du pilote de journal `awsfirelens`, consultez [Routage personnalisé des journaux](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html). Si vous avez un pilote personnalisé qui n'est pas répertorié, vous pouvez bifurquer le projet d'agent de conteneur Amazon ECS [disponible sur GitHub et le](https://github.com/aws/amazon-ecs-agent) personnaliser pour qu'il fonctionne avec ce pilote. Nous vous conseillons d'envoyer des demandes d'extraction pour les modifications que vous souhaitez inclure. Toutefois, nous ne prenons pas en charge l'exécution de copies modifiées de ce logiciel pour le moment. Ce paramètre nécessite la version 1.18 de l'API Docker Remote ou une version ultérieure sur votre instance de conteneur. `options` Type : mappage chaîne/chaîne Obligatoire : non key/value Carte des options de configuration à envoyer au pilote du journal. Les options que vous pouvez spécifier dépendent du pilote de journalisation. Certaines des options que vous pouvez spécifier lorsque vous utilisez le `awslogs` routeur pour acheminer les journaux vers Amazon CloudWatch sont les suivantes : `awslogs-create-group` Obligatoire : non Spécifiez si vous souhaitez que le groupe de journaux soit créé automatiquement. Si cette option n'est pas spécifiée, l'emplacement par défaut est `false`. Votre politique IAM doit inclure l'autorisation `logs:CreateLogGroup` afin que vous puissiez essayer d'utiliser `awslogs-create-group`. `awslogs-region` Obligatoire : oui Spécifiez Région AWS le pilote de `awslogs` journal auquel envoyer vos journaux Docker. Vous pouvez choisir d'envoyer tous vos journaux provenant de clusters situés dans différentes régions vers une seule région dans CloudWatch Logs. Cela leur permet d'être tous visibles en un seul endroit. Sinon, vous pouvez les séparer par région pour plus de granularité. Assurez-vous que le groupe de journaux spécifié existe dans la région que vous spécifiez avec cette option. `awslogs-group` Obligatoire : oui Assurez-vous de spécifier un groupe de journaux auquel le pilote de journaux `awslogs` envoie ses flux de journaux. `awslogs-stream-prefix` Obligatoire : Facultatif Utilisez l'option `awslogs-stream-prefix` pour associer un flux de journaux au préfixe spécifié, au nom du conteneur et à l'ID de la tâche Amazon ECS à laquelle appartient le conteneur. Si vous spécifiez un préfixe avec cette option, le format du flux de journaux est le suivant. ``` prefix-name/container-name/ecs-task-id ``` Si vous ne spécifiez pas de préfixe avec cette option, le flux de journaux est nommé d'après l'ID de conteneur attribué par le démon Docker sur l'instance de conteneur. Etant donné qu'il est difficile de suivre les journaux jusqu'au conteneur qui les a envoyé en utilisant uniquement l'ID de conteneur Docker (qui est uniquement disponible sur l'instance de conteneur), nous vous recommandons de spécifier un préfixe avec cette option. Pour les services Amazon ECS, vous pouvez utiliser le nom du service comme préfixe. Ce faisant, vous pourrez suivre les flux de journaux et déterminer le service auquel appartient le conteneur, trouver le nom du conteneur qui les a envoyés, ainsi que l'ID de la tâche à laquelle le conteneur appartient. Vous devez spécifier un préfixe de flux pour vos journaux pour qu'ils apparaissent dans le panneau des journaux lors de l'utilisation de la console Amazon ECS. `awslogs-datetime-format` Obligatoire : non Cette option définit un modèle de démarrage à plusieurs lignes au format `strftime` Python. Un message de journal est composé de plusieurs lignes : une ligne correspondant au modèle et les lignes suivantes qui ne correspondent pas au modèle. La ligne mise en correspondance est le délimiteur entre les messages de journalisation. Ce format peut, par exemple, servir à analyser une sortie comme une pile de vidage, laquelle pourrait, dans le cas contraire, être consignée en plusieurs entrées. Le modèle adéquat permet de la capturer dans une seule entrée. Pour de plus amples informations, veuillez consulter [awslogs-datetime-format](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-datetime-format). Vous ne pouvez pas configurer à la fois les options `awslogs-datetime-format` et `awslogs-multiline-pattern`. La journalisation multiligne effectue l'analyse et la mise en correspondance des expressions régulières de tous les messages de journalisation. Cela peut avoir un impact négatif sur les performances de journalisation. `awslogs-multiline-pattern` Obligatoire : non Cette option définit un modèle de démarrage à plusieurs lignes à l'aide d'une expression régulière. Un message de journal est composé de plusieurs lignes : une ligne correspondant au modèle et les lignes suivantes qui ne correspondent pas au modèle. La ligne mise en correspondance est le délimiteur entre les messages de journalisation. Pour de plus amples informations, veuillez consulter [awslogs-multiline-pattern](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-multiline-pattern). Cette option est ignorée si `awslogs-datetime-format` est également configuré. Vous ne pouvez pas configurer à la fois les options `awslogs-datetime-format` et `awslogs-multiline-pattern`. La journalisation multiligne effectue l'analyse et la mise en correspondance des expressions régulières de tous les messages de journalisation. Cela peut avoir un impact négatif sur les performances de journalisation. Les options suivantes s’appliquent à tous les pilotes de journalisation pris en charge. `mode` Obligatoire : non Valeurs valides : `non-blocking` \$1 `blocking` Cette option définit le mode de transmission des messages de journalisation depuis le conteneur vers le pilote de journalisation spécifié à l’aide de `logDriver`. Le mode de livraison que vous choisissez affecte la disponibilité de l’application lorsque le flux des journaux provenant du conteneur est interrompu. Si vous utilisez le mode `blocking` et que le flux de journaux est interrompu, les appels provenant du code du conteneur à écrire dans les flux `stdout` et `stderr` seront bloqués. Le fil de journalisation de l'application se bloquera en conséquence. Cela peut empêcher l'application de répondre et entraîner l'échec de vérification de l'état du conteneur. Si vous utilisez le mode `non-blocking`, les journaux du conteneur sont plutôt stockés dans une mémoire tampon intermédiaire configurée avec l'option `max-buffer-size`. Cela empêche l’application de ne plus répondre lorsque les journaux ne peuvent pas être envoyés. Nous vous recommandons d'utiliser ce mode si vous souhaitez garantir la disponibilité du service et si vous acceptez une certaine perte de journaux. Pour plus d’informations, consultez la section [Prévention de la perte de journaux grâce au mode non bloquant dans le pilote de journalisation conteneur `awslogs`](https://aws.amazon.com/blogs/containers/preventing-log-loss-with-non-blocking-mode-in-the-awslogs-container-log-driver/). Vous pouvez définir une valeur de `mode` par défaut pour tous les conteneurs d’un conteneur dans une Région AWS spécifique en utilisant le paramètre de compte `defaultLogDriverMode`. Si vous ne spécifiez pas l’option `mode` dans `logConfiguration` ou ne configurez pas les paramètres du compte, Amazon ECS utilisera par défaut le mode `non-blocking`. Pour plus d’informations sur ce paramètre de compte, consultez la section le [Mode de pilote du journal par défaut](ecs-account-settings.md#default-log-driver-mode). Quand le mode `non-blocking` est utilisé, l'option de journalisation `max-buffer-size` contrôle la taille de la mémoire tampon utilisée pour le stockage des messages intermédiaires. Assurez-vous de spécifier une taille de mémoire tampon adéquate en fonction de votre application. La quantité totale de mémoire allouée au niveau de la tâche doit être supérieure à la quantité de mémoire allouée à tous les conteneurs, en plus du tampon mémoire du pilote de journalisation. Le 25 juin 2025, Amazon ECS a modifié le mode par défaut du pilote de journalisation, passant de `blocking` à `non-blocking` afin de privilégier la disponibilité des tâches plutôt que la journalisation. Pour continuer à utiliser le mode `blocking` après cette modification, effectuez l’une des opérations suivantes : + Définissez l’option `mode` dans votre définition de conteneur `logConfiguration` sur `blocking`. + Réglez le paramètre du compte `defaultLogDriverMode` sur `blocking`. `max-buffer-size` Obligatoire : non Valeur par défaut : `10 m` Quand le mode `non-blocking` est utilisé, l'option de journalisation `max-buffer-size` contrôle la taille de la mémoire tampon utilisée pour le stockage des messages intermédiaires. Assurez-vous de spécifier une taille de mémoire tampon adéquate en fonction de votre application. Lorsque la mémoire tampon est pleine, il est impossible de stocker d'autres journaux. Les journaux qui ne peuvent pas être stockés sont perdus. Pour acheminer les journaux à l’aide du routeur de journaux `splunk`, vous devez spécifier un `splunk-token` et une `splunk-url`. Lorsque vous utilisez le routeur de `awsfirelens` journaux pour acheminer les journaux vers une AWS Partner Network destination Service AWS ou à des fins de stockage et d'analyse des journaux, vous pouvez définir l'`log-driver-buffer-limit`option permettant de limiter le nombre de lignes de journal mises en mémoire tampon avant d'être envoyées au conteneur du routeur de journaux. Cela peut aider à résoudre le problème potentiel de perte de journal, car un débit élevé peut entraîner un épuisement de la mémoire pour le tampon à l'intérieur de Docker. Pour de plus amples informations, veuillez consulter [Configuration des journaux Amazon ECS pour un débit élevé](firelens-docker-buffer-limit.md). Les autres options que vous pouvez spécifier lors de l’utilisation d’`awsfirelens` pour acheminer les journaux dépendent de la destination. Lorsque vous exportez des journaux vers Amazon Data Firehose, vous pouvez spécifier le Région AWS format `region` et le nom du flux de journaux. `delivery_stream` Lorsque vous exportez des journaux vers Amazon Kinesis Data Streams, vous pouvez spécifier la Région AWS avec `region` et un nom pour le flux de données avec `stream`. Lorsque vous exportez des journaux vers Amazon OpenSearch Service, vous pouvez spécifier des options telles que `Name` `Host` (point de terminaison de OpenSearch service sans protocole) `Port` `Index``Type`,`Aws_auth`,`Aws_region`,,`Suppress_Type_Name`, et`tls`. Lorsque vous exportez des journaux vers Amazon S3, vous pouvez spécifier le compartiment à l’aide de l’option `bucket`. Vous pouvez également spécifier `region`, `total_file_size`, `upload_timeout` et `use_put_object` en tant qu’options. Ce paramètre nécessite la version 1.19 de l'API Docker à distance ou une version supérieure sur votre instance de conteneur. `secretOptions` Type : tableau d'objets Obligatoire : non Objet qui représente le secret à transmettre à la configuration de journal. Les secrets utilisés dans la configuration du journal peuvent inclure un jeton d'authentification, un certificat ou une clé de chiffrement. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur Amazon ECS](specifying-sensitive-data.md). `name` Type : Chaîne Obligatoire : oui Valeur à définir comme variable d'environnement sur le conteneur. `valueFrom` Type : Chaîne Obligatoire : oui Secret à exposer à la configuration de journal du conteneur. ``` "logConfiguration": { "logDriver": "splunk", "options": { "splunk-url": "https://cloud.splunk.com:8080", "splunk-token": "...", "tag": "...", ... }, "secretOptions": [{ "name": "splunk-token", "valueFrom": "/ecs/logconfig/splunkcred" }] } ``` `firelensConfiguration` Type : [FirelensConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FirelensConfiguration.html)Objet Obligatoire : non FireLens Configuration du conteneur. Cette option est utilisée pour spécifier et configurer un routeur de journal pour les journaux de conteneur. Pour de plus amples informations, veuillez consulter [Envoyer les journaux Amazon ECS à un AWS service ou AWS Partner](using_firelens.md). ``` { "firelensConfiguration": { "type": "fluentd", "options": { "KeyName": "" } } } ``` `options` Type : mappage chaîne/chaîne Obligatoire : non key/value Carte des options à utiliser lors de la configuration du routeur de log. Ce champ est facultatif et peut être utilisé pour spécifier un fichier de configuration personnalisé ou ajouter des métadonnées supplémentaires, telles que les détails de tâche, de définition de tâche, de cluster et d'instance de conteneur à l'événement de journal. Si spécifié, la syntaxe à utiliser est `"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"}`. Pour de plus amples informations, veuillez consulter [Exemple de définition de tâche Amazon ECS : acheminement des journaux vers FireLens](firelens-taskdef.md). `type` Type : Chaîne Obligatoire : oui Routeur de journal à utiliser. Les valeurs valides sont `fluentd` ou `fluentbit`. #### Sécurité Pour plus d’informations sur la sécurité des conteneurs, consultez la section [Pratiques exemplaires en matière de sécurité des tâches et des conteneurs Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-tasks-containers.html). `credentialSpecs` Type : tableau de chaînes Obligatoire : non Liste des informations contenues ARNs dans SSM ou Amazon S3 dans un fichier de spécifications d'identification (`CredSpec`) qui configure le conteneur pour l'authentification Active Directory. Nous vous recommandons d'utiliser ce paramètre plutôt que les `dockerSecurityOptions`. Le nombre maximum de ARNs est 1. Il existe deux formats pour chaque ARN. credentialspecdomainless:MyARN Vous utilisez `credentialspecdomainless:MyARN` pour fournir un `CredSpec` avec une section supplémentaire pour un secret dans Secrets Manager. Vous fournissez les informations d'identification de connexion au domaine dans le secret. Chaque tâche exécutée sur une instance de conteneur peut rejoindre différents domaines. Vous pouvez utiliser ce format sans associer l'instance de conteneur à un domaine. credentialspec:MyARN Vous utilisez `credentialspec:MyARN` pour fournir un `CredSpec` pour un domaine unique. Vous devez joindre l'instance de conteneur au domaine avant de démarrer toute tâche utilisant cette définition de tâche. Dans les deux formats, remplacez `MyARN` par l'ARN dans SSM ou Amazon S3. Le `credspec` doit fournir un ARN dans Secrets Manager pour un secret contenant le nom d'utilisateur, le mot de passe et le domaine auquel se connecter. Pour une meilleure sécurité, l'instance n'est pas jointe au domaine pour l'authentification sans domaine. Les autres applications de l'instance ne peuvent pas utiliser les informations d'identification sans domaine. Vous pouvez utiliser ce paramètre pour exécuter des tâches sur la même instance, même si les tâches doivent être jointes à différents domaines. Pour plus d'informations, consultez les [sections Utilisation de g MSAs pour les conteneurs Windows](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/windows-gmsa.html) et [Utilisation de g MSAs pour les conteneurs Linux](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/linux-gmsa.html). `privileged` Type : booléen Obligatoire : non Quand ce paramètre a la valeur true, le conteneur dispose de droits élevés sur l'instance de conteneur hôte (similaire à l'utilisateur `root`). Nous vous déconseillons d'exécuter des conteneurs avec `privileged`. Dans la plupart des cas, vous pouvez spécifier les privilèges exacts dont vous avez besoin en utilisant les paramètres spécifiques au lieu d'utiliser `privileged`. Ce paramètre correspond à `Privileged` dans la commande docker create-container et à l’option `--privileged` dans la commande docker run. Ce paramètre n'est pas pris en charge pour les conteneurs ou tâches Windows qui utilisent le type de lancement Fargate. La valeur par défaut est `false`. ``` "privileged": true|false ``` `user` Type : chaîne Obligatoire : non Utilisateur à utiliser à l'intérieur du conteneur. Ce paramètre correspond à `User` dans la commande docker create-container et à l’option `--user` dans la commande docker run. Lorsque vous exécutez des tâches en mode réseau `host`, n'exécutez pas de conteneurs à l'aide de l'utilisateur root (UID 0). Comme bonne pratique de sécurité, utilisez toujours un utilisateur non root. Vous pouvez spécifier l'`user` à l'aide des formats suivants. Si vous spécifiez un UID ou GID, vous devez le spécifier en tant que nombre entier positif. + `user` + `user:group` + `uid` + `uid:gid` + `user:gid` + `uid:group` Ce paramètre n'est pas pris en charge par les conteneurs Windows. ``` "user": "string" ``` `dockerSecurityOptions` Type : tableau de chaînes Valeurs valides : « » \$1 no-new-privileges « apparmor:profile » \$1 « label : » \$1 « *value* credentialspec : » *CredentialSpecFilePath* Obligatoire : non Liste de chaînes pour fournir une configuration personnalisée pour plusieurs systèmes de sécurité. Pour les tâches Linux, ce paramètre peut être utilisé pour référencer des étiquettes personnalisées pour SELinux et des systèmes de sécurité à plusieurs niveaux AppArmor . Ce paramètre peut être utilisé pour référencer un fichier de spécification d’informations d’identification qui configure un conteneur pour l’authentification Active Directory. Pour plus d’informations, consultez [Utilisation des gMSA pour les conteneurs Windows EC2 pour Amazon ECS](windows-gmsa.md) et [Utilisation de gMSA pour les conteneurs Linux EC2 sur Amazon ECS](linux-gmsa.md). Ce paramètre correspond à `SecurityOpt` dans la commande docker create-container et à l’option `--security-opt` dans la commande docker run. ``` "dockerSecurityOptions": ["string", ...] ``` L'agent de conteneur Amazon ECS en cours d'exécution sur une instance de conteneur doit s'enregistrer avec les variables d'environnement `ECS_SELINUX_CAPABLE=true` ou `ECS_APPARMOR_CAPABLE=true` pour que les conteneurs placés sur cette instance puissent utiliser ces options de sécurité. Pour de plus amples informations, veuillez consulter [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md). #### Limites des ressources `ulimits` Type : tableau d'objets Obligatoire : non Une liste de valeurs `ulimit` à définir pour un conteneur. Cette valeur remplace le paramètre de quota de ressources par défaut pour le système d'exploitation. Ce paramètre correspond à `Ulimits` dans la commande docker create-container et à l’option `--ulimit` dans la commande docker run. Ce paramètre nécessite la version 1.18 de l'API Docker Remote ou une version ultérieure sur votre instance de conteneur. Ce paramètre n'est pas pris en charge par les conteneurs Windows. ``` "ulimits": [ { "name": "core"|"cpu"|"data"|"fsize"|"locks"|"memlock"|"msgqueue"|"nice"|"nofile"|"nproc"|"rss"|"rtprio"|"rttime"|"sigpending"|"stack", "softLimit": integer, "hardLimit": integer } ... ] ``` `name` Type : Chaîne Valeurs valides : `"core" | "cpu" | "data" | "fsize" | "locks" | "memlock" | "msgqueue" | "nice" | "nofile" | "nproc" | "rss" | "rtprio" | "rttime" | "sigpending" | "stack"` Obligatoire : oui, lorsque des objets `ulimits` sont utilisés Le `type` d'`ulimit`. `hardLimit` Type : Integer Obligatoire : oui, lorsque des objets `ulimits` sont utilisés La limite stricte du type `ulimit`. La valeur peut être spécifiée en octets, en secondes ou en nombre, selon le `type` d’`ulimit`. `softLimit` Type : Integer Obligatoire : oui, lorsque des objets `ulimits` sont utilisés La limite flexible du type `ulimit`. La valeur peut être spécifiée en octets, en secondes ou en nombre, selon le `type` d’`ulimit`. #### Étiquettes Docker `dockerLabels` Type : mappage chaîne/chaîne Obligatoire : non Une key/value carte des étiquettes à ajouter au conteneur. Ce paramètre correspond à `Labels` dans la commande docker create-container et à l’option `--label` dans la commande docker run. Ce paramètre nécessite la version 1.18 de l'API Docker Remote ou une version ultérieure sur votre instance de conteneur. ``` "dockerLabels": {"string": "string" ...} ``` ### Autres paramètres de définition de conteneur Les paramètres de définition de conteneur suivants peuvent être utilisés lors de l'enregistrement des définitions de tâche dans la console Amazon ECS à l'aide de l'option **Configure via JSON** (Configurer via JSON). Pour de plus amples informations, veuillez consulter [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md). **Topics** + [ #### Paramètres Linux ](#container_definition_linuxparameters_ec2) + [ #### Dépendances du conteneur ](#container_definition_dependson_ec2) + [ #### Temporisations de conteneurs ](#container_definition_timeout_ec2) + [ #### Contrôles système ](#container_definition_systemcontrols_ec2) + [ #### Interactive ](#container_definition_interactive_ec2) + [ #### Pseudo Terminal ](#container_definition_pseudoterminal_ec2) #### Paramètres Linux `linuxParameters` Type : objet [LinuxParameters](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LinuxParameters.html) Obligatoire : non Linux-des options spécifiques appliquées au conteneur, telles [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html)que. Ce paramètre n'est pas pris en charge par les conteneurs Windows. ``` "linuxParameters": { "capabilities": { "add": ["string", ...], "drop": ["string", ...] } } ``` `capabilities` Type : objet [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities_ec2.html) Obligatoire : non Caractéristiques Linux du conteneur ajoutées ou supprimées de la configuration par défaut fournie par Docker. Pour plus d'informations sur ces caractéristiques Linux, veuillez consulter la page consacrée aux [caractéristiques(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html) dans le manuel Linux (langue française non garantie). `add` Type : tableau de chaînes Valeurs valides : `"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"` Obligatoire : non Caractéristiques Linux du conteneur à ajouter à la configuration par défaut fournie par Docker. Ce paramètre correspond à `CapAdd` dans la commande docker create-container et à l’option `--cap-add` dans la commande docker run. `add` Type : tableau de chaînes Valeurs valides : `"SYS_PTRACE"` Obligatoire : non Caractéristiques Linux du conteneur à ajouter à la configuration par défaut fournie par Docker. Ce paramètre correspond à `CapAdd` dans la commande docker create-container et à l’option `--cap-add` dans la commande docker run. `drop` Type : tableau de chaînes Valeurs valides : `"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"` Obligatoire : non Caractéristiques Linux du conteneur à supprimer de la configuration par défaut fournie par Docker. Ce paramètre correspond à `CapDrop` dans la commande docker create-container et à l’option `--cap-drop` dans la commande docker run. `devices` Tous les périphériques hôtes à exposer au conteneur. Ce paramètre correspond à `Devices` dans la commande docker create-container et à l’option `--device` dans la commande docker run. Type : tableau d'objets [Périphérique](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Device.html) Obligatoire : non `hostPath` Chemin du périphérique dans l'instance de conteneur hôte. Type : Chaîne Obligatoire : oui `containerPath` Chemin auquel exposer l'appareil hôte à l'intérieur du conteneur. Type : chaîne Obligatoire : non `permissions` Autorisations explicites à fournir au conteneur pour le périphérique. Par défaut, le conteneur dispose des autorisations `read`, `write` et `mknod` sur l'appareil. Type : tableau de chaînes Valeurs valides : `read` \$1 `write` \$1 `mknod` `initProcessEnabled` Exécutez un processus `init` dans le conteneur afin de transmettre des signaux et de récolter les processus. Ce paramètre correspond à l’option `--init` de docker run. Ce paramètre nécessite la version 1.25 de l'API Docker à distance ou une version supérieure sur votre instance de conteneur. `maxSwap` Quantité totale de mémoire d'échange (en Mio) qu'un conteneur peut utiliser. Ce paramètre est converti en l’option `--memory-swap` de la commande docker run, où la valeur est la somme de la mémoire du conteneur et de la valeur `maxSwap`. Si la valeur `0` est spécifiée pour `maxSwap`, le conteneur n'utilise pas l'échange. Les valeurs acceptées sont `0` ou n'importe quel nombre entier positif. Si le paramètre `maxSwap` n'est pas spécifié, le conteneur utilise la configuration d'échange pour l'instance de conteneur sur laquelle il s'exécute. Une valeur `maxSwap` doit être définie pour que le paramètre `swappiness` soit utilisé. `sharedMemorySize` Valeur correspondant à la taille (en Mio) du volume `/dev/shm`. Ce paramètre correspond à l’option `--shm-size` de docker run. Type : Integer `swappiness` Vous pouvez utiliser ce paramètre pour régler le comportement d'échange de mémoire d'un conteneur. Une valeur `swappiness` de `0` empêche l'échange de se produire à moins que cela ne soit nécessaire. Une valeur `swappiness` de `100` entraîne fréquemment l'échange de pages. Les valeurs acceptées sont les nombres entiers compris entre `0` et `100`. Si vous ne spécifiez aucune valeur, la valeur par défaut `60` est utilisée. De plus, si vous ne spécifiez pas de valeur pour `maxSwap`, ce paramètre est ignoré. Ce paramètre correspond à l’option `--memory-swappiness` de docker run. Si vous utilisez des tâches sur Amazon Linux 2023, le paramètre `swappiness` n'est pas pris en charge. `tmpfs` Chemin du conteneur, options de montage et taille maximale (en Mio) du montage tmpfs. Ce paramètre correspond à l’option `--tmpfs` de docker run. Type : tableau d'objets [Tmpfs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Tmpfs.html) Obligatoire : non `containerPath` Chemin de fichier absolu où sera monté le volume tmpfs. Type : Chaîne Obligatoire : oui `mountOptions` Liste des options de montage du volume tmpfs. Type : tableau de chaînes Obligatoire : non Valeurs valides : `"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` Taille maximale (en Mio) du volume tmpfs. Type : Integer Obligatoire : oui #### Dépendances du conteneur `dependsOn` Type : tableau d’objets [ContainerDependency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html) Obligatoire : non Dépendances définies pour le démarrage et l'arrêt de conteneurs. Un conteneur peut contenir plusieurs dépendances. Lorsqu'une dépendance est définie pour le démarrage des conteneurs, elle est inversée pour leur arrêt. Pour obtenir un exemple, consultez [Dépendances du conteneur](example_task_definitions.md#example_task_definition-containerdependency). Si un conteneur ne respecte pas une contrainte de dépendance ou s'écoule avant de respecter la contrainte, Amazon ECS ne fait pas progresser pas les conteneurs dépendants vers leur état suivant. Les instances nécessitent au moins la version `1.26.0` de l’agent de conteneur pour activer les dépendances de conteneur. Toutefois, nous vous recommandons d'utiliser la dernière version de l'agent de conteneur. Pour plus d'informations sur la vérification de la version de votre agent et la mise à jour à la dernière version, consultez [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md). Si vous utilisez l'AMI Linux Amazon optimisée pour Amazon ECS, votre instance doit au moins disposer de la version `1.26.0-1` du package `ecs-init`. Si vos instances de conteneur sont lancées à partir de la version `20190301` ou ultérieure, elles contiennent les versions requises de l'agent de conteneur et `ecs-init`. Pour de plus amples informations, veuillez consulter [Linux optimisé pour Amazon ECS AMIs](ecs-optimized_AMI.md). ``` "dependsOn": [ { "containerName": "string", "condition": "string" } ] ``` `containerName` Type : Chaîne Obligatoire : oui Nom de conteneur qui doit répondre à la condition spécifiée. `condition` Type : Chaîne Obligatoire : oui Condition de dépendance du conteneur. Voici les conditions disponibles et leur comportement : + `START` - Cette condition émule le comportement de liens et de volumes aujourd'hui. La condition vérifie qu'un conteneur dépendant est démarré avant d'autoriser d'autres conteneurs à démarrer. + `COMPLETE` - Cette condition vérifie qu'un conteneur dépendant exécute un cycle complet (sorties) avant d'autoriser d'autres conteneurs à démarrer. Cela peut être utile pour les conteneurs non essentiels qui exécutent un script, puis se ferment. Cette condition ne peut pas être définie sur un conteneur essentiel. + `SUCCESS` - Cette condition est identique à `COMPLETE`, mais elle nécessite également que le conteneur se termine par un état `zero`. Cette condition ne peut pas être définie sur un contenant essentiel. + `HEALTHY` - Cette condition vérifie que la surveillance de l'état du conteneur dépendant réussit avant d'autoriser d'autres conteneurs à démarrer. Cela nécessite que le conteneur dépendant dispose de surveillances de l'état configurées dans la définition de la tâche. Cette condition est confirmée uniquement au démarrage de la tâche. #### Temporisations de conteneurs `startTimeout` Type : Integer Obligatoire : non Exemples de valeur : `120` Durée d'attente (en secondes) avant l'abandon de la résolution de dépendances pour un conteneur. Par exemple, vous spécifiez deux conteneurs dans une définition de tâche, où le `containerA` dispose d'une dépendance au `containerB` avec un état `COMPLETE`, `SUCCESS` ou `HEALTHY`. Si une valeur `startTimeout` est spécifiée pour `containerB` et qu'il n'a pas atteint l'état souhaité dans ce délai, alors le `containerA` ne démarre pas. Si un conteneur ne respecte pas une contrainte de dépendance ou s'écoule avant de respecter la contrainte, Amazon ECS ne fait pas progresser pas les conteneurs dépendants vers leur état suivant. La valeur maximale est de 120 secondes. `stopTimeout` Type : Integer Obligatoire : non Exemples de valeur : `120` Durée (en secondes) à attendre avant que le conteneur soit expressément tué s'il ne s'achève pas normalement tout seul. Si le paramètre `stopTimeout` n’est pas spécifié, la valeur définie pour la variable de configuration `ECS_CONTAINER_STOP_TIMEOUT` de l’agent de conteneur Amazon ECS est utilisée. Si ni le paramètre `stopTimeout` ni la variable de configuration de l'agent `ECS_CONTAINER_STOP_TIMEOUT` ne sont définis, les valeurs par défaut de 30 secondes pour les conteneurs Linux et de 30 secondes pour les conteneurs Windows sont utilisées. Les instances de conteneur doivent au moins disposer de la version 1.26.0 de l'agent de conteneur pour permettre une valeur de temporisation d'arrêt d'un conteneur. Toutefois, nous vous recommandons d'utiliser la dernière version de l'agent de conteneur. Pour plus d'informations sur la vérification de la version de votre agent et la mise à jour à la dernière version, consultez [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md). Si vous utilisez l'AMI Amazon Linux optimisée pour Amazon ECS, votre instance doit au moins disposer de la version 1.26.0-1 du package `ecs-init`. Si vos instances de conteneur sont lancées à partir de la version `20190301` ou ultérieure, elles contiennent les versions requises de l'agent de conteneur et `ecs-init`. Pour de plus amples informations, veuillez consulter [Linux optimisé pour Amazon ECS AMIs](ecs-optimized_AMI.md). #### Contrôles système `systemControls` Type : objet [SystemControl](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_SystemControl.html) Obligatoire : non Liste des paramètres du noyau de l’espace de noms à définir dans le conteneur. Ce paramètre correspond à `Sysctls` dans la commande docker create-container et à l’option `--sysctl` dans la commande docker run. Par exemple, vous pouvez configurer le paramètre `net.ipv4.tcp_keepalive_time` pour maintenir des connexions de plus longue durée. Il n'est pas recommandé de spécifier des paramètres `systemControls` liés au réseau pour plusieurs conteneurs dans une seule tâche qui utilise également le mode réseau `awsvpc` ou `host`. En procédant ainsi, vous vous exposez aux inconvénients suivants : + Pour les tâches qui utilisent le mode réseau `awsvpc`, si vous définissez le paramètre `systemControls` pour un conteneur, il s'applique à tous les conteneurs de la tâche. Si vous définissez différents paramètres `systemControls` pour plusieurs conteneurs dans une seule tâche, c'est le conteneur qui est démarré en dernier qui détermine le paramètre `systemControls` qui prend effet. + Les définitions de tâche qui utilisent le mode réseau `host`, l'espace de noms `systemControls` ne sont pas prises en charge. Si vous définissez un espace de noms des ressources IPC à utiliser pour les conteneurs de la tâche, les conditions suivantes s'appliquent aux contrôles de système. Pour de plus amples informations, veuillez consulter [Mode IPC](task_definition_parameters.md#task_definition_ipcmode). + Pour les tâches qui utilisent le mode IPC `host`, les `systemControls` liés à l'espace de noms IPC ne sont pas pris en charge. + Pour les tâches qui utilisent le mode IPC `task`, les valeurs des `systemControls` liés à l'espace de noms IPC s'appliquent à tous les conteneurs au sein d'une tâche. Ce paramètre n'est pas pris en charge par les conteneurs Windows. ``` "systemControls": [ { "namespace":"string", "value":"string" } ] ``` `namespace` Type : chaîne Obligatoire : non Paramètre du noyau de l’espace de noms pour lequel définir une `value`. Valeurs d'espace de noms IPC valides : `"kernel.msgmax" | "kernel.msgmnb" | "kernel.msgmni" | "kernel.sem" | "kernel.shmall" | "kernel.shmmax" | "kernel.shmmni" | "kernel.shm_rmid_forced"`, et `Sysctls` qui commencent par `"fs.mqueue.*"` Valeurs d'espace de noms de réseau valides : `Sysctls` qui commencent par `"net.*"` `value` Type : chaîne Obligatoire : non Valeur du paramètre du noyau de l’espace de noms spécifié dans `namespace`. #### Interactive `interactive` Type : booléen Obligatoire : non Lorsque ce paramètre est `true`, vous pouvez déployer des applications conteneurisées qui nécessitent l'allocation d'une `stdin` ou d'un `tty`. Ce paramètre correspond à `OpenStdin` dans la commande docker create-container et à l’option `--interactive` dans la commande docker run. La valeur par défaut est `false`. #### Pseudo Terminal `pseudoTerminal` Type : booléen Obligatoire : non Lorsque ce paramètre a la valeur `true`, un TTY est alloué. Ce paramètre correspond à `Tty` dans la commande docker create-container et à l’option `--tty` dans la commande docker run. La valeur par défaut est `false`. ## Nom de l'accélérateur Elastic Inference (obsolète) L'exigence de la ressource d'accélérateur Elastic Inference pour votre définition de tâche. **Note** Amazon Elastic Inference (EI) n’est plus disponible pour les clients. Les paramètres suivants sont autorisés dans une définition de tâche : `deviceName` Type : Chaîne Obligatoire : oui Nom de l'appareil accélérateur d'inférence élastique pour l'instance. `deviceName` doit également être référencé dans une définition du conteneur. Consultez [Elastic Inference accelerator](task_definition_parameters.md#ContainerDefinition-elastic-inference). `deviceType` Type : Chaîne Obligatoire : oui L'accélérateur Elastic Inference à utiliser. ## Contraintes de placement des tâches Lorsque vous enregistrez une définition de tâche, vous pouvez fournir des contraintes de placement des tâches qui personnalisent la façon dont Amazon ECS place les tâches. Vous pouvez utiliser des contraintes pour placer des tâches en fonction de la zone de disponibilité, du type d’instance ou d’attributs personnalisés. Pour de plus amples informations, veuillez consulter [Définition des instances de conteneur utilisées par Amazon ECS pour les tâches](task-placement-constraints.md). Les paramètres suivants sont autorisés dans une définition de conteneur: `expression` Type : chaîne Obligatoire : non Expression de langage de requête de cluster à appliquer à la contrainte. Pour de plus amples informations, veuillez consulter [Création d’expressions pour définir des instances de conteneur pour les tâches Amazon ECS](cluster-query-language.md). `type` Type : Chaîne Obligatoire : oui Type de contrainte. Utilisez `memberOf` pour limiter la sélection à un groupe de candidats valides. ## Configuration du proxy `proxyConfiguration` Type : objet [ProxyConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ProxyConfiguration.html) Obligatoire : non Détails de configuration pour le proxy App Mesh. Pour les tâches qui utilisent EC2, les instances de conteneur nécessitent au moins la version 1.26.0 de l’agent de conteneur et au moins la version 1.26.0-1 du package `ecs-init` pour activer une configuration proxy. Si vos instances de conteneur sont lancées à partir de la version d'AMI `20190301` ou ultérieure optimisée pour Amazon ECS, elles contiennent les versions requises de l'agent de conteneur et `ecs-init`. Pour de plus amples informations, veuillez consulter [Linux optimisé pour Amazon ECS AMIs](ecs-optimized_AMI.md). Ce paramètre n'est pas pris en charge par les conteneurs Windows. ``` "proxyConfiguration": { "type": "APPMESH", "containerName": "string", "properties": [ { "name": "string", "value": "string" } ] } ``` `type` Type : Chaîne Valeur valeurs : `APPMESH` Obligatoire : non Type de proxy. La seule valeur prise en charge est `APPMESH`. `containerName` Type : Chaîne Obligatoire : oui Nom du conteneur qui fait office de proxy App Mesh. `properties` Type : tableau d’objets [KeyValuePair](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KeyValuePair.html) Obligatoire : non L'ensemble de paramètres de configuration réseau pour fournir le plug-in Container Network Interface (CNI), spécifié sous la forme de paires clé-valeur. + `IgnoredUID` – (Obligatoire) ID d'utilisateur (UID) du conteneur de proxy, tel que défini par le paramètre `user` dans une définition de conteneur. Ce port est utilisé pour garantir que le proxy ignore son propre trafic. Si vous avez spécifié `IgnoredGID`, ce champ doit être vide. + `IgnoredGID` – (Obligatoire) ID de groupe (GID) du conteneur de proxy, tel que défini par le paramètre `user` dans une définition de conteneur. Ce port est utilisé pour garantir que le proxy ignore son propre trafic. Si vous avez spécifié `IgnoredUID`, ce champ doit être vide. + `AppPorts` - (Obligatoire) Liste des ports utilisés par l'application. Le trafic réseau vers ces ports est transmis à `ProxyIngressPort` et `ProxyEgressPort`. + `ProxyIngressPort` – (Obligatoire) Spécifie le port auquel le trafic entrant vers `AppPorts` est dirigé. + `ProxyEgressPort` – (Obligatoire) Spécifie le port auquel le trafic sortant de `AppPorts` est dirigé. + `EgressIgnoredPorts` – (Obligatoire) Le trafic sortant accédant à ces ports spécifiés est ignoré et n'est pas redirigé vers le `ProxyEgressPort`. Cela peut être une liste vide. + `EgressIgnoredIPs` – (Obligatoire) Le trafic sortant accédant à ces adresses IP spécifiées est ignoré et n'est pas redirigé vers le `ProxyEgressPort`. Cela peut être une liste vide. `name` Type : chaîne Obligatoire : non Nom de la paire clé-valeur. `value` Type : chaîne Obligatoire : non Valeur de la paire clé-valeur. ## Volumes Lorsque vous enregistrez une définition de tâche, vous pouvez spécifier une liste de volumes à transmettre au démon Docker sur une instance de conteneur, à laquelle d’autres conteneurs de la même instance de conteneur pourront accéder. Les types de volumes de données qui peuvent être utilisés sont les suivants : + Volumes Amazon EBS : fournit un stockage par blocs rentable, durable et performant pour les charges de travail conteneurisées gourmandes en données. Vous pouvez attacher un volume Amazon EBS par tâche Amazon ECS lorsque vous exécutez une tâche autonome ou lorsque vous créez ou mettez à jour un service. Les volumes Amazon EBS sont pris en charge pour les tâches Linux. Pour de plus amples informations, veuillez consulter [Utilisation des volumes Amazon EBS avec Amazon ECS](ebs-volumes.md). + Volumes Amazon EFS : fournit un stockage de fichiers simple, évolutif et permanent à utiliser avec vos tâches Amazon ECS. Avec Amazon EFS, la capacité de stockage est élastique. Elle augmente et diminue automatiquement au fil de vos ajouts et suppressions de fichiers. Vos applications peuvent disposer de l'espace de stockage dont elles ont besoin, au moment où elles en ont besoin. Les volumes Amazon EFS sont pris en charge. Pour de plus amples informations, veuillez consulter [Utilisation des volumes Amazon EFS avec Amazon ECS](efs-volumes.md). + FSx pour les volumes de serveurs de fichiers Windows : fournit des serveurs de fichiers Microsoft Windows entièrement gérés. Ces serveurs de fichiers sont basés sur un système de fichiers Windows. Lorsque vous utilisez FSx un serveur de fichiers Windows avec Amazon ECS, vous pouvez fournir à vos tâches Windows un stockage de fichiers persistant, distribué, partagé et statique. Pour de plus amples informations, veuillez consulter [Utilisation FSx pour les volumes de serveurs de fichiers Windows avec Amazon ECS](wfsx-volumes.md). Les conteneurs Windows sur Fargate ne prennent pas en charge cette option. + Volumes Docker : volume géré par Docker qui est créé sous `/var/lib/docker/volumes` sur l’instance Amazon EC2 hôte. Les pilotes de volume Docker (également appelés plugins) sont utilisés pour intégrer les volumes à des systèmes de stockage externes, tels qu'Amazon EBS. Le pilote de volume `local` intégré ou un pilote de volume tiers peut être utilisé. Les volumes Docker sont pris en charge uniquement lors de l’exécution de tâches sur des instances Amazon EC2. Les conteneurs Windows prennent uniquement en charge l’utilisation du pilote `local`. Pour utiliser des volumes Docker, spécifiez un `dockerVolumeConfiguration` dans votre définition de tâche. + Montages liés : un fichier ou un dossier sur la machine hôte est monté dans un conteneur. Les volumes hôtes à montage lié sont pris en charge. Pour utiliser des volumes hôte de montage lié, spécifiez un `host` et éventuellement une valeur `sourcePath` dans votre définition de tâche. Pour de plus amples informations, veuillez consulter [Options de stockage pour les tâches Amazon ECS](using_data_volumes.md). Les paramètres suivants sont autorisés dans une définition de conteneur. `name` Type : chaîne Obligatoire : non Nom du volume. Jusqu’à 255 lettres (majuscules et minuscules), chiffres, traits d’union (`-`) et traits de soulignement (`_`) sont autorisés. Ce nom est référencé dans le paramètre `sourceVolume` de l’objet `mountPoints` de définition du conteneur. `host` Obligatoire : non Le paramètre `host` est utilisé pour lier le cycle de vie du montage lié à l'instance Amazon EC2 hôte, plutôt qu'à la tâche et à l'endroit où elle est stockée. Si le paramètre `host` est vide, le démon Docker attribue un chemin hôte au volume de données, mais la persistance des données après l'arrêt des conteneurs qui lui sont associés n'est pas garantie. Les conteneurs Windows peuvent monter des répertoires entiers sur le même lecteur que `$env:ProgramData`. Le `sourcePath` paramètre est pris en charge uniquement lors de l'utilisation de tâches hébergées sur des instances Amazon EC2 ou des instances gérées Amazon ECS. `sourcePath` Type : chaîne Obligatoire : non Lorsque le paramètre `host` est utilisé, spécifiez un paramètre `sourcePath` pour déclarer le chemin d'accès sur l'instance Amazon EC2 hôte qui est présentée au conteneur. Si ce paramètre est vide, le démon Docker attribue un chemin hôte pour vous. Si le paramètre `host` contient un emplacement de fichier `sourcePath`, le volume de données persiste à l'emplacement spécifié sur l'instance Amazon EC2 hôte jusqu'à ce que vous le supprimiez manuellement. Si la valeur `sourcePath` n'existe pas sur l'instance Amazon EC2 hôte, le démon Docker la crée. Si l'emplacement n'existe pas, le contenu du chemin source est exporté. `configuredAtLaunch` Type : booléen Obligatoire : non Spécifie si un volume est configurable au lancement. Lorsqu’il est défini sur `true`, vous pouvez configurer le volume lors de l’exécution d’une tâche autonome ou lors de la création ou de la mise à jour d’un service. Lorsque cette option est définie sur `true`, vous ne pourrez pas fournir d’autre configuration de volume dans la définition de tâche. Ce paramètre doit être défini sur `true` pour configurer un volume Amazon EBS à rattacher à une tâche. En définissant `configuredAtLaunch` sur `true` et en reportant la configuration du volume à la phase de lancement, vous pouvez créer des définitions de tâches qui ne sont pas limitées à un type de volume ou à des paramètres de volume spécifiques. Cela rend votre définition de tâche réutilisable dans différents environnements d’exécution. Pour plus d'informations, consultez [Volumes Amazon EBS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html). `dockerVolumeConfiguration` Type : [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html)Objet Obligatoire : non Ce paramètre est spécifié lorsque vous utilisez des volumes Docker. Les volumes Docker sont pris en charge uniquement lors de l’exécution de tâches sur des instances EC2. Les conteneurs Windows prennent uniquement en charge l’utilisation du pilote `local`. Pour utiliser des montages liés, spécifiez plutôt un paramètre `host`. `scope` Type : Chaîne Valeurs valides : `task` \$1 `shared` Obligatoire : non Portée du volume Docker, qui détermine son cycle de vie. Les volumes Docker destinés à un élément `task` sont automatiquement mis en service lorsque la tâche commence, et détruits lorsque la tâche s'arrête. Les volumes Docker définis comme `shared` ne sont pas supprimés lorsque la tâche s'arrête. `autoprovision` Type : Boolean Valeur par défaut : `false` Obligatoire : non Si cette valeur est `true`, le volume Docker est créé s'il n'existe pas déjà. Ce champ n’est utilisé que si `scope` a la valeur `shared`. Si le champ `scope` a la valeur `task`, ce paramètre doit être omis. `driver` Type : chaîne Obligatoire : non Pilote de volume Docker à utiliser. La valeur du pilote doit correspondre au nom du pilote fourni par Docker, car ce nom est utilisé pour le placement des tâches. Si le pilote a été installé à l’aide de l’interface CLI du plug-in Docker, utilisez `docker plugin ls` pour récupérer le nom du pilote à partir de votre instance de conteneur. Si le pilote a été installé à l’aide d’une autre méthode, utilisez la découverte du plug-in Docker pour récupérer le nom du pilote. `driverOpts` Type : chaîne Obligatoire : non Mappage des options spécifiques au pilote Docker à transmettre. Ce paramètre correspond à `DriverOpts` dans la section « Créer un volume » de Docker. `labels` Type : chaîne Obligatoire : non Métadonnées personnalisées à ajouter à votre volume Docker. `efsVolumeConfiguration` Type : objet [EFSVolumede configuration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSVolumeConfiguration.html) Obligatoire : non Ce paramètre est spécifié lorsque vous utilisez des volumes Amazon EFS. `fileSystemId` Type : Chaîne Obligatoire : oui ID du système de fichiers Amazon EFS à utiliser. `rootDirectory` Type : chaîne Obligatoire : non Répertoire du système de fichiers Amazon EFS à monter en tant que répertoire racine à l'intérieur de l'hôte. Si ce paramètre est omis, la racine du volume Amazon EFS est utilisée. La spécification de `/` a le même effet que l'omission de ce paramètre. Si un point d’accès EFS est spécifié dans `authorizationConfig`, le paramètre de répertoire racine doit être omis ou défini sur `/`, ce qui imposera le chemin défini sur le point d’accès EFS. `transitEncryption` Type : Chaîne Valeurs valides : `ENABLED` \$1 `DISABLED` Obligatoire : non Indique si vous souhaitez activer ou non le chiffrement des données Amazon EFS en transit entre l'hôte Amazon ECS et le serveur Amazon EFS. Si l'autorisation Amazon EFS IAM est utilisée, le chiffrement de transit doit être activé. Si ce paramètre est omis, la valeur par défaut `DISABLED` est utilisée. Pour plus d'informations, consultez [Chiffrement des données en transit](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html) dans le *Guide de l'utilisateur Amazon Elastic File System*. `transitEncryptionPort` Type : Integer Obligatoire : non Port à utiliser lors de l'envoi de données chiffrées entre l'hôte Amazon ECS et le serveur Amazon EFS. Si vous ne spécifiez pas de port de chiffrement en transit, la tâche utilisera la stratégie de sélection de port adoptée par l’assistant de montage Amazon EFS. Pour plus d'informations, consultez [Assistant de montage EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html) dans le *Guide de l'utilisateur Amazon Elastic File System User*. `authorizationConfig` Type : objet [EFSAuthorizationConfig](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSAuthorizationConfig.html) Obligatoire : non Détails de configuration des autorisations pour le système de fichiers Amazon EFS. `accessPointId` Type : chaîne Obligatoire : non ID du point d'accès à utiliser. Si un point d’accès est spécifié, la valeur du répertoire racine dans `efsVolumeConfiguration` doit être omise ou définie sur `/`, ce qui imposera le chemin défini sur le point d’accès EFS. Si un point d'accès est utilisé, le chiffrement de transit doit être activé dans `EFSVolumeConfiguration`. Pour plus d'informations, consultez [Utilisation des points d'accès Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) dans le *Guide de l'utilisateur Amazon Elastic File System*. `iam` Type : Chaîne Valeurs valides : `ENABLED` \$1 `DISABLED` Obligatoire : non Indique s’il faut ou non utiliser le rôle IAM de tâche Amazon ECS spécifié dans une définition de tâche lors du montage du système de fichiers Amazon EFS. Si cette option est activée, le chiffrement en transit doit être activé dans la configuration `EFSVolumeConfiguration`. Si ce paramètre est omis, la valeur par défaut `DISABLED` est utilisée. Pour plus d'informations, consultez [Rôles IAM pour les tâches](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html). `FSxWindowsFileServerVolumeConfiguration` Type : [FSxWindowsFileServerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FSxWindowsFileServerVolumeConfiguration.html)Objet Obligatoire : oui Ce paramètre est spécifié lorsque vous utilisez un système de fichiers [Amazon FSx pour Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) pour le stockage des tâches. `fileSystemId` Type : Chaîne Obligatoire : oui L' FSx identifiant du système de fichiers Windows File Server à utiliser. `rootDirectory` Type : Chaîne Obligatoire : oui Le répertoire du système FSx de fichiers Windows File Server à monter en tant que répertoire racine sur l'hôte. `authorizationConfig` `credentialsParameter` Type : Chaîne Obligatoire : oui Options d'informations d'identification d'autorisation. **Options :** + Amazon Resource Name (ARN) d’un secret [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html). + ARN d’un paramètre [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html). `domain` Type : Chaîne Obligatoire : oui Nom de domaine complet hébergé par un répertoire [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) (AWS Managed Microsoft AD) ou un Active Directory EC2 autohébergé. ## Étiquettes Lorsque vous enregistrez une définition de tâche, vous pouvez éventuellement spécifier des étiquettes de métadonnées qui sont appliquées à la définition de tâche. Les balises vous aident à classer et à organiser votre définition de tâche. Chaque balise est constituée d’une clé et d’une valeur facultative. Vous définissez ces deux éléments. Pour de plus amples informations, veuillez consulter [Balisage des ressources Amazon ECS](ecs-using-tags.md). **Important** N'ajoutez pas de données d'identification personnelle ou d'autres informations confidentielles ou sensibles dans les étiquettes. Les tags sont accessibles à de nombreux AWS services, y compris la facturation. Les étiquettes ne sont pas destinées à être utilisées pour des données privées ou sensibles. Les paramètres suivants sont autorisés dans un objet balise. `key` Type : chaîne Obligatoire : non Partie d'une paire clé-valeur qui constitue une étiquette. Une clé est une étiquette générale qui fait office de catégorie pour les valeurs d'étiquette plus spécifiques. `value` Type : chaîne Obligatoire : non Partie facultative d'une paire clé-valeur qui constitue une étiquette. Une valeur agit comme un descripteur au sein d'une catégorie d'étiquette (clé). ## Autres paramètres de définition de tâche Les paramètres de définition de tâche suivants peuvent être utilisés lors de l'enregistrement des définitions de tâches dans la console Amazon ECS à l'aide de l'option **Configure via JSON** (Configurer via JSON). Pour de plus amples informations, veuillez consulter [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md). **Topics** + [ ### Mode IPC ](#task_definition_ipcmode_ec2) + [ ### Mode PID ](#task_definition_pidmode_ec2) + [ ### Injection de pannes ](#task_definition_faultInjection_ec2) ### Mode IPC `ipcMode` Type : chaîne Obligatoire : non Espace de noms de ressource IPC à utiliser pour les conteneurs de la tâche. Les valeurs valides sont `host`, `task` ou `none`. Si `host` est spécifié, tous les conteneurs des tâches ayant spécifié le mode IPC `host` sur la même instance de conteneur partagent les mêmes ressources IPC avec l'instance Amazon EC2 hôte. Si `task` est spécifié, tous les conteneurs de la tâche spécifiée partagent les mêmes ressources IPC. Si `none` est spécifié, les ressources IPC des conteneurs d'une tâche sont privés et ne partagent rien avec les autres conteneurs d'une tâche ou d'une instance de conteneur. Si aucune valeur n'est spécifiée, le partage de l'espace de noms de ressource IPC dépend du paramètre du démon Docker sur l'instance de conteneur. Si le mode IPC `host` est utilisé, il existe un risque accru d'exposition à un espace de noms IPC indésirable. Si vous définissez les paramètres du noyau placés dans un espace de noms à l'aide de `systemControls` pour les conteneurs de la tâche, les éléments suivants s'appliquent à votre espace de noms de ressource IPC. + Pour les tâches qui utilisent le mode IPC `host`, les `systemControls` liés à l'espace de noms IPC ne sont pas pris en charge. + Pour les tâches qui utilisent le mode IPC `task`, les `systemControls` liés à l'espace de noms IPC s'appliquent à tous les conteneurs au sein d'une tâche. ### Mode PID `pidMode` Type : Chaîne Valeurs valides : `host` \$1 `task` Obligatoire : non Espace de noms de processus à utiliser pour les conteneurs de la tâche. Les valeurs valides sont `host` ou `task`. Par exemple, la surveillance des sidecars peut avoir besoin de `pidMode` pour accéder à des informations sur d'autres conteneurs exécutés dans le cadre de la même tâche. Si `host` est spécifié, tous les conteneurs des tâches ayant spécifié le mode PID `host` sur la même instance de conteneur partagent le même espace de noms de processus avec l'instance Amazon EC2 hôte. Si `task` est spécifié, tous les conteneurs de la tâche spécifiée partagent le même espace de noms de processus. Si aucune valeur n'est spécifiée, la valeur par défaut est un espace de noms privé pour chaque conteneur. Si le mode PID `host` est utilisé, il existe un risque accru d'exposition à un espace de noms de processus indésirable. **Note** Ce paramètre n'est pas pris en charge par les conteneurs Windows. ### Injection de pannes `enableFaultInjection` Type : Boolean Valeurs valides : `true` \$1 `false` Obligatoire : non Si ce paramètre est défini sur `true`, dans les données utiles d’une tâche, Amazon ECS accepte les requêtes d’injection de pannes provenant des conteneurs de la tâche. Par défaut, ce paramètre est défini sur `false`. # Modèle de définition de tâche Amazon ECS Un modèle de définition de tâche vide est présenté ci-dessous. Vous pouvez utiliser ce modèle pour créer votre définition de tâche, qui peut ensuite être collée dans la zone de saisie JSON de la console ou enregistrée dans un fichier et utilisée avec l' AWS CLI `--cli-input-json`option. Pour de plus amples informations, veuillez consulter [Paramètres de définition de tâche Amazon ECS pour Fargate](task_definition_parameters.md). **Modèle 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" } } ``` **Modèle Fargate** **Important** Pour Fargate, vous devez inclure le paramètre `operatingSystemFamily` avec l’une des valeurs suivantes : `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": "" } ] } ``` Vous pouvez générer ce modèle de définition de tâche à l'aide de la commande AWS CLI suivante. ``` aws ecs register-task-definition --generate-cli-skeleton ``` # Exemple de définitions de tâches Amazon ECS Vous pouvez copier les exemples et extraits de code pour commencer à créer vos propres définitions de tâches. Vous pouvez copier les exemples, puis les coller lorsque vous utilisez l'option **Configurer via JSON** dans la console classique. Assurez-vous de personnaliser les exemples, en utilisant par exemple votre ID de compte. Vous pouvez inclure les extraits dans le JSON de définition de tâche. Pour plus d’informations, consultez [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md) et [Paramètres de définition de tâche Amazon ECS pour Fargate](task_definition_parameters.md). Pour d'autres exemples de définition de tâches, voir [AWS Exemples de définitions de tâches](https://github.com/aws-samples/aws-containers-task-definitions) sur GitHub. **Topics** + [ ## Serveur Web ](#example_task_definition-webserver) + [ ## Pilote de journalisation `splunk` ](#example_task_definition-splunk) + [ ## Pilote de journalisation `fluentd` ](#example_task_definition-fluentd) + [ ## Pilote de journalisation `gelf` ](#example_task_definition-gelf) + [ ## Charges de travail sur les instances externes ](#ecs-anywhere-runtask) + [ ## Image Amazon ECR et rôle IAM de définition de tâche ](#example_task_definition-iam) + [ ## Point d’entrée avec commande ](#example_task_definition-ping) + [ ## Dépendances du conteneur ](#example_task_definition-containerdependency) + [ ## Volumes dans les définitions de tâches ](#volume_sample_task_defs) + [ ## Exemples de définitions de tâche Windows ](#windows_sample_task_defs) ## Serveur Web Voici un exemple de définition de tâche utilisant des conteneurs Linux sur Fargate qui configure un serveur 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" ] } ``` Voici un exemple de définition de tâche à l’aide des conteneurs Windows sur Fargate qui configure un serveur 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"] } ``` ## Pilote de journalisation `splunk` L'extrait suivant montre comment utiliser le pilote de journal `splunk` dans une définition de tâche qui envoie les journaux à un service distant. Le paramètre de jeton Splunk est spécifiée en tant qu'option secrète, car il peut être traité comme des données sensibles. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur 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" }], ``` ## Pilote de journalisation `fluentd` L'extrait suivant montre comment utiliser le pilote de journal `fluentd` dans une définition de tâche qui envoie les journaux à un service distant. La valeur `fluentd-address` est spécifiée en tant qu'option secrète, car elle peut être traitée comme des données sensibles. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur 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 }] }], ``` ## Pilote de journalisation `gelf` L'extrait suivant montre comment utiliser le pilote de journal `gelf` dans une définition de tâche qui envoie les journaux à un hôte distant exécutant Logstash qui accepte les journaux Gelf sous forme d'entrée. Pour de plus amples informations, veuillez consulter [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 } ] }], ``` ## Charges de travail sur les instances externes Lors de l'enregistrement d'une définition de tâche Amazon ECS, utilisez le paramètre `requiresCompatibilities` et spécifiez `EXTERNAL`, qui valide la compatibilité de la définition de tâche lors de l'exécution d'applications Amazon ECS sur vos instances externes. Si vous utilisez la console pour enregistrer une définition de tâche, vous devez utiliser l'éditeur JSON. Pour de plus amples informations, veuillez consulter [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md). **Important** Si vos tâches nécessitent un rôle IAM d'exécution de tâche, assurez-vous qu'il est spécifié dans la définition de tâche. Lorsque vous déployez votre application, utilisez le type de lancement `EXTERNAL` lors de la création de votre service ou de l'exécution de votre tâche autonome. Voici un exemple de définition de tâche. ------ #### [ 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" } ``` ------ ## Image Amazon ECR et rôle IAM de définition de tâche L'extrait suivant utilise une image Amazon ECR appelée `aws-nodejs-sample` avec la balise `v1` à partir du registre `123456789012.dkr.ecr.us-west-2.amazonaws.com`. Le conteneur de cette tâche hérite des autorisations IAM du rôle `arn:aws:iam::123456789012:role/AmazonECSTaskS3BucketRole`. Pour de plus amples informations, veuillez consulter [rôle IAM de tâche 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" } ``` ## Point d’entrée avec commande L'extrait suivant illustre la syntaxe d'un conteneur Docker qui utilise un point d'entrée et un argument de commande. Ce conteneur enverra un ping à `example.com` quatre fois, puis il s'arrêtera. ``` { "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" } ``` ## Dépendances du conteneur Cet extrait illustre la syntaxe d'une définition de tâche avec plusieurs conteneurs où la dépendance de conteneur est spécifiée. Dans la définition de tâche suivante, le conteneur `envoy` doit atteindre un état sain, déterminé par les paramètres de surveillance de l'état du conteneur requis avant que le conteneur `app` démarre. Pour de plus amples informations, veuillez consulter [Dépendances du conteneur](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" } ``` ## Volumes dans les définitions de tâches Utilisez ce qui suit pour comprendre comment spécifier des volumes dans les tâches. + Pour plus d’informations sur la configuration d’un volume Amazon EBS, consultez la section [Spécification de la configuration du volume Amazon EBS lors du déploiement Amazon ECS](configure-ebs-volume.md). + Pour plus d’informations sur la configuration d’un volume Amazon EFS, consultez la section [Configuration des systèmes de fichiers Amazon EFS pour Amazon ECS à l’aide de la console](tutorial-efs-volumes.md). + Pour plus d'informations sur la configuration d'un volume FSx pour un serveur de fichiers Windows, consultez[Découvrez comment configurer FSx les systèmes de fichiers Windows File Server pour Amazon ECS](tutorial-wfsx-volumes.md). + Pour plus d’informations sur la configuration d’un volume Docker, consultez la section [Exemples de volumes Docker pour Amazon ECS](docker-volume-examples.md). + Pour plus d’informations sur la configuration d’un montage lié, consultez la section [Exemples de montage lié pour Amazon ECS](bind-mount-examples.md). ## Exemples de définitions de tâche Windows Voici un exemple de définition de tâche qui peut vous aider à commencer à utiliser les conteneurs Windows sur Amazon ECS. **Example Exemple d'application de console Amazon ECS pour Windows** La définition de tâche suivante est l'exemple d'application de console Amazon ECS produit dans l'assistant de première exécution pour Amazon ECS ; il a été transféré pour utiliser l'image de conteneur `microsoft/iis` Windows. ``` { "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" } ```