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.
# Clusters Amazon ECS
Un cluster Amazon ECS est un regroupement logique de tâches ou de services qui fournit la capacité d’infrastructure pour vos applications conteneurisées. Lorsque vous créez un cluster, vous avez le choix entre les trois principaux types d’infrastructure, optimisés pour différents cas d’utilisation et exigences opérationnelles.
## Sélection du type de cluster approprié
Amazon ECS propose trois types d’infrastructure pour vos clusters. Choisissez le type qui correspond le mieux à vos exigences en matière de charge de travail, à vos préférences opérationnelles et à vos objectifs d’optimisation des coûts :
Instances gérées Amazon ECS (recommandées)
**Idéal pour la plupart des charges de travail** : gère AWS entièrement les instances Amazon EC2 sous-jacentes, y compris le provisionnement, l'application de correctifs et le dimensionnement. Cette option offre un équilibre optimal entre performances, rentabilité et simplicité opérationnelle.
**À utiliser lorsque :**
+ Vous AWS souhaitez gérer l'infrastructure
+ vous avez besoin d’une puissance de calcul rentable avec optimisation automatique ;
+ vous souhaitez vous concentrer sur vos applications plutôt que sur l’infrastructure ;
+ vous avez besoin de performances prévisibles avec une mise à l’échelle flexible.
Fargate
**Calcul sans serveur** : ne payez que pour les ressources utilisées par vos tâches, sans avoir à gérer aucune infrastructure. Idéal pour les charges de travail variables et pour démarrer rapidement.
**À utiliser lorsque :**
+ vous voulez des opérations totalement sans serveur ;
+ vous avez des charges de travail imprévisibles ou variables ;
+ vous souhaitez minimiser les frais d’exploitation ;
+ vous avez besoin d’un déploiement et d’une capacité de mise à l’échelle rapides.
Instances Amazon EC2
**Contrôle total** : vous gérez directement les instances Amazon EC2 sous-jacentes, y compris la sélection, la configuration et la maintenance des instances.
**À utiliser lorsque :**
+ vous avez besoin de types d’instances ou de configurations spécifiques ;
+ vous disposez d’une infrastructure Amazon EC2 existante à exploiter ;
+ Vous avez besoin d'un logiciel personnalisé AMIs ou spécialisé
+ vous avez besoin d’un contrôle maximal sur l’infrastructure sous-jacente.
**Note**
Les instances gérées Amazon ECS constituent le choix recommandé pour la plupart des nouvelles charges de travail, car elles offrent la meilleure combinaison de performances, d'optimisation des coûts et de simplicité opérationnelle tout en permettant de AWS gérer les tâches de gestion de l'infrastructure.
## Composants d’un cluster
Outre la capacité de l’infrastructure, un cluster est constitué des ressources suivantes :
+ Réseau (VPC et sous-réseau) sur lequel s'exécutent vos tâches et services
Lorsque vous utilisez des instances gérées Amazon ECS ou des instances Amazon EC2 pour la capacité, le sous-réseau peut se trouver dans des zones de disponibilité, des zones locales, des zones Wavelength ou AWS Outposts.
+ Un espace de noms facultatif
Un espace de noms est utilisé pour service-to-service communiquer avec Service Connect.
+ Option de surveillance
CloudWatch Container Insights est un service entièrement géré, moyennant un coût supplémentaire. Il collecte, agrège et résume automatiquement les métriques et les journaux Amazon ECS.
## Concepts de cluster
Vous trouverez ci-après des concepts généraux sur les clusters Amazon ECS.
+ Vous créez des clusters pour séparer vos ressources.
+ Les clusters sont Région AWS spécifiques.
+ Les clusters peuvent avoir l’un des états suivants.
ACTIF
Le cluster est prêt à accepter des tâches et, le cas échéant, vous pouvez enregistrer des instances de conteneur auprès du cluster.
PROVISIONING
Le cluster est associé à des fournisseurs de capacité et les ressources nécessaires au fournisseur de capacité sont en cours de création.
DEPROVISIONING
Le cluster est associé à des fournisseurs de capacité et les ressources nécessaires au fournisseur de capacité sont en cours de suppression.
ÉCHEC
Le cluster est associé à des fournisseurs de capacité et la création des ressources nécessaires au fournisseur de capacité a échoué.
INACTIVE
Le cluster a été supprimé. Les clusters ayant un état `INACTIVE` peuvent rester détectables dans votre compte pendant un certain temps. Ce comportement est susceptible de changer à terme. Il est donc important de ne pas compter sur la persistance des clusters `INACTIVE`.
+ Un cluster peut contenir une combinaison de tâches qui sont hébergées sur des instances gérées Amazon ECS, AWS Fargate, des instances Amazon EC2 ou des instances externes. Les tâches peuvent être exécutées sur une infrastructure d’instances gérées Amazon ECS, Fargate ou EC2 en tant que type de lancement ou stratégie de fournisseur de capacité. Si vous utilisez des fournisseurs de capacité EC2, Amazon ECS ne surveille ni ne met à l’échelle la capacité des groupes Amazon EC2 Auto Scaling.
+ Un cluster peut contenir un mélange de fournisseurs de capacité d’instances gérées Amazon ECS, de fournisseurs de capacité de groupe Auto Scaling et de fournisseurs de capacité Fargate. Une stratégie de fournisseur de capacité ne peut contenir que des fournisseurs de capacité d’instances gérées Amazon ECS, des fournisseurs de capacité du groupe Auto Scaling ou des fournisseurs de capacité Fargate.
+ Vous pouvez utiliser différents types d’instances pour les instances gérées Amazon ECS et EC2, ou pour les fournisseurs de capacité du groupe Auto Scaling. Une instance ne peut être enregistrée que dans un seul cluster à la fois.
+ Vous pouvez restreindre l’accès aux clusters en créant des politiques IAM personnalisées. Pour plus d’informations, consultez la section [Exemples de cluster Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies) dans [Exemples de politiques basées sur l'identité pour Amazon Elastic Container Service](security_iam_id-based-policy-examples.md).
+ Vous pouvez utiliser Service Auto Scaling pour mettre à l’échelle les tâches Fargate. Pour de plus amples informations, veuillez consulter [Mise à l’échelle automatique de votre service Amazon ECS](service-auto-scaling.md).
+ Vous pouvez configurer un espace de noms Service Connect par défaut pour un cluster. Une fois que vous avez défini un espace de noms Service Connect par défaut, tous les nouveaux services créés dans le cluster peuvent être ajoutés en tant que services clients dans l'espace de noms en activant Service Connect. Aucune configuration supplémentaire n’est requise. 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).
## Fournisseurs de capacité
Les fournisseurs de capacité Amazon ECS gèrent la mise à l'échelle de l'infrastructure pour les tâches de vos clusters. Chaque cluster dispose d'un ou plusieurs fournisseurs de capacité et éventuellement d'une stratégie de fournisseur de capacité facultative. Vous pouvez attribuer une stratégie de fournisseur de capacité par défaut au cluster. La stratégie de fournisseur de capacité détermine la façon dont les tâches sont réparties entre les fournisseurs de capacité du cluster. Lorsque vous exécutez une tâche autonome ou que vous créez un service, vous pouvez utiliser soit la stratégie de fournisseur de capacité par défaut du cluster, soit une stratégie de fournisseur de capacité qui remplace celle par défaut. La stratégie de fournisseur de capacité par défaut du cluster ne s’applique que lorsque vous ne spécifiez pas de type de lancement ou de stratégie de fournisseur de capacité pour votre tâche ou votre service. Si vous fournissez l’un de ces paramètres, la stratégie par défaut n’est pas utilisée.
Amazon ECS propose trois types de fournisseurs de capacité pour vos clusters :
Fournisseurs de capacité Amazon ECS Managed Instances
AWS gère entièrement les instances Amazon EC2 sous-jacentes, y compris le provisionnement, l'application de correctifs, le dimensionnement et la gestion du cycle de vie. Ce choix offre un équilibre optimal entre performances, rentabilité et simplicité opérationnelle. Les fournisseurs de capacité d’instances gérées Amazon ECS optimisent automatiquement la sélection et la mise à l’échelle des instances en fonction de vos exigences en matière de charge de travail.
Avec les instances gérées Amazon ECS, vous bénéficiez des avantages suivants :
+ Allocation et mise à l’échelle automatiques des instances
+ Correctifs et mises à jour de sécurité gérés
+ Optimisation des coûts grâce à la sélection intelligente des instances
+ Frais d’exploitation réduits
Fournisseurs de capacité Fargate
Calcul sans serveur où vous ne payez que pour les ressources utilisées par vos tâches, sans aucune infrastructure à gérer. Il vous suffit d’associer les fournisseurs de capacité prédéfinis (Fargate et Fargate Spot) au cluster.
Fournisseurs de capacité de groupe Auto Scaling
Lorsque vous utilisez des instances Amazon EC2 pour votre capacité, vous utilisez un groupe Auto Scaling pour gérer les instances Amazon EC2. L’autoscaling permet de vous assurer que vous disposez du bon nombre d’instances Amazon EC2 disponibles pour gérer la charge de l’application. Vous avez un contrôle total sur l’infrastructure sous-jacente.
Un cluster peut contenir une combinaison de tâches qui sont hébergées sur des instances gérées Amazon ECS, AWS Fargate, des instances Amazon EC2 ou des instances externes. Les tâches peuvent être exécutées sur une infrastructure d’instances gérées Amazon ECS, Fargate ou EC2 en tant que type de lancement ou stratégie de fournisseur de capacité. Si vous utilisez EC2 comme type de lancement, Amazon ECS ne surveille ni ne met à l’échelle la capacité des groupes Amazon EC2 Auto Scaling.
Un cluster peut contenir un mélange de fournisseurs de capacité d’instances gérées Amazon ECS, de fournisseurs de capacité de groupe Auto Scaling et de fournisseurs de capacité Fargate. Une stratégie de fournisseur de capacité ne peut contenir que des fournisseurs de capacité d’instances gérées Amazon ECS, des fournisseurs de capacité du groupe Auto Scaling ou des fournisseurs de capacité Fargate.
# Clusters pour les instances gérées Amazon ECS
Les fournisseurs de capacité Amazon ECS gèrent la mise à l'échelle de l'infrastructure pour les tâches de vos clusters. Après avoir créé le cluster, vous créez un ou plusieurs fournisseurs de capacité et éventuellement une stratégie de fournisseur de capacité facultative pour le cluster. La stratégie de fournisseur de capacité détermine la façon dont les tâches sont réparties entre les fournisseurs de capacité du cluster. Lorsque vous exécutez une tâche autonome ou que vous créez un service, vous pouvez utiliser soit la stratégie de fournisseur de capacité par défaut du cluster, soit une stratégie de fournisseur de capacité qui remplace celle par défaut.
Les instances gérées Amazon ECS dispose des fournisseurs de capacité suivants.
| Type | Critères utilisés pour choisir les instances |
| --- | --- |
| Par défaut | Les instances les plus économiques qui répondent aux exigences suivantes en matière de définition des tâches et de paramètres de service : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/managed-instance-clusters.html) |
| Personnalisé | Les instances qui répondent aux exigences d’attribut et de type que vous spécifiez lors de la création du cluster. Pour plus d’informations sur les attributs, consultez la section [Attributs d’instance de conteneur Amazon ECS](task-placement-constraints.md#attributes). Pour plus d’informations sur les types d’instance, consultez la section [Spécifications des types d’instance Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-instance-type-specifications.html) dans Types d’instance Amazon EC2. |
Amazon ECS lance les instances et les associe au fournisseurs de capacité d’instances gérées Amazon ECS. Pour le fournisseur de capacité personnalisé, Amazon ECS crée également le fournisseur de capacité.
# Création d’un cluster pour les instances gérées Amazon ECS
Vous créez un cluster pour définir l’infrastructure sur laquelle vos tâches et vos services s’exécutent.
Lorsque vous créez un cluster pour les instances gérées Amazon ECS, Amazon ECS crée automatiquement un fournisseur de capacité pour les instances gérées avec des configurations par défaut. Ce fournisseur de capacité sélectionne les types d'instances les plus rentables pour vos charges de travail. Vous pouvez également créer des fournisseurs de capacité personnalisés si vous avez besoin d’attributs ou de types d’instance spécifiques.
Pour simplifier au maximum le processus de création de clusters, la console propose des sélections par défaut pour de nombreux choix.
+ Crée un espace de noms par défaut portant le même nom que le cluster. AWS Cloud Map Un espace de noms permet aux services que vous créez dans le cluster de se connecter aux autres services de l'espace de noms sans configuration supplémentaire.
Pour de plus amples informations, veuillez consulter [Interconnexion des services Amazon ECS](interconnecting-services.md).
Vous pouvez modifier les options suivantes :
+ Modifiez l'espace de noms par défaut associé au cluster.
Un espace de noms permet aux services que vous créez dans le cluster de se connecter aux autres services de l'espace de noms sans configuration supplémentaire. L'espace de noms par défaut porte le même nom que le cluster. Pour de plus amples informations, veuillez consulter [Interconnexion des services Amazon ECS](interconnecting-services.md).
+ Attribuez une AWS KMS clé à votre espace de stockage géré. Pour plus d’informations sur la création d’une clé, consultez la section [Création d’une clé KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le *Guide de l’utilisateur AWS Key Management Service *.
+ Ajoutez des balises pour vous aider à identifier vos clusters.
## Conditions préalables
Avant de commencer, veillez achever les étapes de [Configurer l'utilisation d'Amazon ECS](get-set-up-for-amazon-ecs.md) et affectez l’autorisation IAM appropriée. Pour de plus amples informations, veuillez consulter [Exemples de cluster Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies).
L’utilisateur qui crée le cluster doit disposer d’une autorisation supplémentaire : `iam:CreateServiceLinkedRole`.
Lorsque vous ne le spécifiez pas`instanceRequirements`, Amazon ECS sélectionne automatiquement les types d'instances les plus optimisés en termes de coûts en fonction de vos exigences en matière de définition des tâches. Pour utiliser des attributs ou des types d'instance spécifiques, créez un fournisseur de capacité avec`instanceRequirements`.
Découvrez comment choisir vos instances. Pour de plus amples informations, veuillez consulter [Pratiques exemplaires en matière de sélection d’instances pour les instances gérées Amazon ECS](managed-instances-instance-selection-best-practices.md).
Vous disposez des rôles IAM requis pour les instances gérées Amazon ECS. Cela inclut notamment les éléments suivants :
+ **Rôle dans l'infrastructure** : permet à Amazon ECS de passer des appels aux AWS services en votre nom afin de gérer l'infrastructure des instances gérées Amazon ECS.
Pour de plus amples informations, veuillez consulter [Rôle IAM d’infrastructure Amazon ECS](infrastructure_IAM_role.md).
+ **Profil d’instance** : fournit des autorisations pour l’agent de conteneur Amazon ECS et le démon Docker exécutés sur des instances gérées.
Pour de plus amples informations, veuillez consulter [Profil d’instance des instances gérées Amazon ECS](managed-instances-instance-profile.md).
## Procédure pour la console
**Pour créer un nouveau cluster (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 **Configuration de cluster**, configurez les éléments suivants :
+ Pour **Nom du cluster**, saisissez un nom unique.
Le nom peut contenir jusqu'à 255 lettres (minuscules et majuscules), des chiffres et des traits d'union.
+ (Facultatif) Pour que l'espace de noms utilisé pour Service Connect soit différent du nom du cluster, saisissez un nom unique dans **Espace de nom**.
1. Pour **Fournisseur de capacité personnalisé**, procédez comme suit :
+ Pour **Sélectionner une méthode d’obtention de capacité EC2**, choisissez **Instances gérées Amazon ECS**.
+ Pour Profil d’instance, choisissez le rôle du profil d’instance.
+ Pour Rôle d’infrastructure, choisissez le rôle d’infrastructure.
+ Pour utiliser un fournisseur de capacité personnalisé, pour **Sélection de l’instance**, sélectionnez **Utiliser une instance personnalisée**. Ensuite, pour chaque attribut, saisissez la **valeur de l’attribut**.
1. (Facultatif) Utilisez Container Insights, développez **Surveillance**, puis sélectionnez une des options suivantes :
+ Pour utiliser Container Insights avec observabilité améliorée comme recommandé, sélectionnez **Container Insights avec observabilité améliorée**.
+ Pour utiliser Container Insights, choisissez **Container Insights**.
1. (Facultatif) Chiffrez les données sur le stockage géré. Sous **Chiffrement**, pour **Stockage géré**, entrez l'ARN de la AWS KMS clé que vous souhaitez utiliser pour chiffrer les données du stockage géré.
1. (Facultatif) Pour vous aider à identifier votre cluster, développez **Tags** (balises), puis configurez vos balises.
[Add a tag] Choisissez **Add tag** (Ajouter une balise) et procédez comme suit :
+ Pour **Key** (Clé), saisissez le nom de la clé.
+ Pour **Valeur**, saisissez la valeur de clé.
1. Choisissez **Créer**.
## AWS CLI procédure
Vous pouvez créer un cluster pour les instances gérées Amazon ECS à l’aide de l’ AWS CLI. Utilisez la version la plus récente de l’ AWS CLI. Pour savoir comment opérer une mise à niveau vers la dernière version, consultez la section [Installation ou mise à jour vers la dernière version de l’ AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Note**
Vous pouvez utiliser des points de terminaison de service à double pile pour interagir avec Amazon ECS à partir de AWS AWS CLI SDKs, et de l'API Amazon ECS via les deux IPv4 et. IPv6 Pour de plus amples informations, veuillez consulter [Utilisation des points de terminaison à double pile Amazon ECS](dual-stack-endpoint.md).
**Pour créer un cluster (AWS CLI)**
1. Créez votre propre cluster avec un nom unique à l’aide de la commande suivante :
```
aws ecs create-cluster --cluster-name managed-instances-cluster
```
Sortie :
```
{
"cluster": {
"status": "ACTIVE",
"defaultCapacityProviderStrategy": [],
"statistics": [],
"capacityProviders": [],
"tags": [],
"clusterName": "managed-instances-cluster",
"settings": [
{
"name": "containerInsights",
"value": "disabled"
}
],
"registeredContainerInstancesCount": 0,
"pendingTasksCount": 0,
"runningTasksCount": 0,
"activeServicesCount": 0,
"clusterArn": "arn:aws:ecs:region:aws_account_id:cluster/managed-instances-cluster"
}
}
```
1. (Facultatif) Pour activer Container Insights avec observabilité améliorée pour votre cluster, utilisez la commande suivante :
```
aws ecs put-account-setting --name containerInsights --value enhanced
```
1. (Facultatif) Pour ajouter des balises à votre cluster, utilisez la commande suivante :
```
aws ecs tag-resource --resource-arn arn:aws:ecs:region:aws_account_id:cluster/managed-instances-cluster --tags key=Environment,value=Production
```
## Étapes suivantes
Créez une définition de tâche pour les instances gérées Amazon ECS. 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).
Exécutez vos applications en tant que tâches autonomes ou dans le cadre d’un service. Pour plus d’informations, consultez les ressources suivantes :
+ [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)
# Mise à jour d’un cluster pour l’utilisation des instances gérées Amazon ECS
Vous pouvez mettre à jour un cluster existant pour utiliser les instances gérées Amazon ECS.
Lorsque vous ajoutez des instances gérées Amazon ECS à votre cluster, Amazon ECS crée automatiquement un fournisseur de capacité d'instances gérées avec des configurations par défaut. Ce fournisseur de capacité sélectionne les types d'instances à usage général les plus optimisés en termes de coûts pour vos charges de travail. Vous pouvez également créer des fournisseurs de capacité personnalisés si vous avez besoin d’attributs ou de types d’instance spécifiques.
## Conditions préalables
Lorsque vous ne le spécifiez pas`instanceRequirements`, Amazon ECS sélectionne automatiquement les types d'instances les plus optimisés en termes de coûts en fonction de vos exigences en matière de définition des tâches. Pour utiliser des attributs ou des types d'instance spécifiques, créez un fournisseur de capacité avec`instanceRequirements`.
Vous disposez des rôles IAM requis pour les instances gérées Amazon ECS. Cela inclut notamment les éléments suivants :
+ **Rôle dans l'infrastructure** : permet à Amazon ECS de passer des appels aux AWS services en votre nom afin de gérer l'infrastructure des instances gérées Amazon ECS.
Pour de plus amples informations, veuillez consulter [Rôle IAM d’infrastructure Amazon ECS](infrastructure_IAM_role.md).
+ **Profil d’instance** : fournit des autorisations pour l’agent de conteneur Amazon ECS et le démon Docker exécutés sur des instances gérées.
Pour de plus amples informations, veuillez consulter [Profil d’instance des instances gérées Amazon ECS](managed-instances-instance-profile.md).
## Considérations relatives à la mise à jour
Tenez compte des éléments suivants lorsque vous mettez à jour un cluster pour instances gérées Amazon ECS :
+ Tâches en cours : la mise à jour des paramètres du cluster n’affecte pas les tâches en cours d’exécution. Les modifications s’appliqueront aux nouvelles tâches lancées après la mise à jour.
+ Changements de fournisseur de capacité : si vous modifiez les paramètres du fournisseur de capacité, les instances gérées existantes continueront de fonctionner, mais les nouvelles instances utiliseront la configuration mise à jour.
+ Surveillance des modifications : l’activation ou la désactivation de Container Insights affectera la collecte de métriques pour l’ensemble du cluster.
## Procédure pour la console
**Pour mettre à jour un cluster (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. Sélectionnez **Clusters** et choisissez le cluster que vous souhaitez mettre à jour.
1. Choisissez **Mettre à jour le cluster**.
1. (Facultatif) Pour modifier les paramètres du fournisseur de capacité, sous **Fournisseur de capacité personnalisé**, mettez à jour les éléments suivants selon les besoins :
+ Pour **Profil d’instance**, choisissez un rôle de profil d’instance différent si nécessaire.
+ Pour **Rôle d’infrastructure**, choisissez un rôle d’infrastructure différent si nécessaire.
+ Pour utiliser un fournisseur de capacité personnalisé, pour **Sélection de l’instance**, mettez à jour les paramètres de **Valeur d’attribut**.
1. Choisissez **Mettre à jour**.
## AWS CLI procédure
Vous pouvez mettre à jour un cluster pour les instances gérées Amazon ECS à l’aide de l’ AWS CLI. Utilisez la version la plus récente de l’ AWS CLI. Pour savoir comment opérer une mise à niveau vers la dernière version, consultez la section [Installation ou mise à jour vers la dernière version de l’ AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Note**
Vous pouvez utiliser des points de terminaison de service à double pile pour interagir avec Amazon ECS à partir de AWS AWS CLI SDKs, et de l'API Amazon ECS via les deux IPv4 et. IPv6 Pour de plus amples informations, veuillez consulter [Utilisation des points de terminaison à double pile Amazon ECS](dual-stack-endpoint.md).
**Pour mettre à jour un cluster (AWS CLI)**
1. Créer un fournisseur de capacité pour . Exécutez la commande suivante :
Remplacez le *user-input* par vos valeurs.
```
aws ecs create-capacity-provider \
--name my-managed-instances-provider \
--managed-instances-provider \
--instance-profile arn:aws:iam::123456789012:instance-profile/ecsInstanceProfile \
--infrastructure-role-arn arn:aws:iam::123456789012:role/ecsInfrastructureRole \
--instance-requirements '{
"vCpuCount": {"min": 2, "max": 8},
"memoryMiB": {"min": 4096, "max": 16384}
}
```
1. Ajoutez le fournisseur de capacité au cluster à l’aide de la commande suivante :
Remplacez le *user-input* par vos valeurs.
```
aws ecs put-cluster-capacity-providers --cluster managed-instances-cluster --capacity-providers my-managed-instances-provider --default-capacity-provider-strategy capacityProvider=my-managed-instances-provider,weight=1
```
# Fournisseurs de capacité d’instances gérées Amazon ECS
Les fournisseurs de capacité des instances gérées Amazon ECS fournissent un modèle de calcul par conteneur qui vous donne accès à la gamme complète des AWS fonctionnalités et aux offres Amazon EC2 tout en AWS gérant les responsabilités opérationnelles et de sécurité. AWS gère l'application de correctifs aux logiciels et aux systèmes d'exploitation, le dimensionnement et la maintenance des instances, vous offrant ainsi les avantages opérationnels de Fargate tout en conservant l'accès à AWS toutes les fonctionnalités et intégrations.
Amazon ECS crée des modèles de lancement pour vos instances gérées Amazon ECS. Cela définit la manière dont Amazon ECS lance les instances gérées Amazon ECS, y compris le profil d’instance pour vos tâches, la configuration du réseau et du stockage, les options de capacité et les exigences d’instance pour une sélection flexible du type d’instance.
## Quand utiliser des fournisseurs de capacité personnalisés
Envisagez l’utilisation de fournisseurs de capacité personnalisés lorsque vos charges de travail nécessitent :
+ Exigences informatiques spécifiques : applications nécessitant un calcul accéléré, des jeux d'instructions spécifiques au processeur, des performances réseau élevées ou des configurations de mémoire volumineuses qui ne sont pas disponibles avec les options Fargate standard.
+ Charges de travail du processeur graphique : inférence par apprentissage automatique, rendu d'image en temps réel, encodage vidéo ou autres applications accélérées par GPU nécessitant un accès à NVIDIA ou AMD. GPUs
+ Réservations de capacité : charges de travail critiques qui nécessitent une disponibilité prévisible des capacités.
+ Observabilité avancée : outils de sécurité et de surveillance qui nécessitent un accès privilégié au système d'exploitation sous-jacent, tels que les solutions de surveillance basées sur le protocole EBPF ou les outils d'analyse du réseau.
+ Optimisation des coûts : charges de travail qui peuvent bénéficier d'un placement multitâche, de composants d'infrastructure partagés ou qui doivent optimiser l'utilisation de types d'instances plus importants.
## Options de surveillance
Les instances gérées Amazon ECS fournissent des fonctionnalités de surveillance complètes pour vous aider à suivre les performances, l’état et l’utilisation des ressources de vos charges de travail conteneurisées. Vous pouvez choisir parmi différents niveaux de surveillance en fonction de vos exigences opérationnelles.
+ **Surveillance de base** : fournit des métriques essentielles à intervalles de cinq minutes pour la plupart des métriques et à intervalles d’une minute pour les vérifications de statut. Cette fonctionnalité est activée par défaut et n’entraîne aucuns frais supplémentaires.
+ **Surveillance détaillée** : offre une visibilité améliorée avec toutes les métriques disponibles à intervalles d’une minute, permettant une détection et une réponse plus rapides aux problèmes opérationnels. Pour de plus amples informations, veuillez consulter [Surveillance détaillée des instances gérées Amazon ECS](monitoring-managed-instances.md#detailed-monitoring-managed-instances).
Les deux options de surveillance s'intègrent parfaitement CloudWatch pour fournir des tableaux de bord, des alarmes et des réponses automatisées afin de maintenir des performances et une disponibilité optimales des applications.
## Considérations relatives aux fournisseurs de capacité
Un cluster peut contenir un mélange de fournisseurs de capacité d’instances gérées Amazon ECS, de fournisseurs de capacité de groupe Auto Scaling et de fournisseurs de capacité Fargate. Une stratégie de fournisseur de capacité ne peut contenir que des fournisseurs de capacité d’instances gérées Amazon ECS, des fournisseurs de capacité du groupe Auto Scaling ou des fournisseurs de capacité Fargate.
## Propagation de balises
Les fournisseurs de capacité pour les instances gérées Amazon ECS prennent en charge la propagation des balises. Avec la propagation des balises, toutes les ressources gérées par le fournisseur de capacité (l’instance gérée, l’instance de conteneur Amazon ECS, le modèle de lancement, les volumes, les interfaces réseau Elastic) sont étiquetées avec les mêmes balises spécifiées au niveau du fournisseur de capacité. Vous pouvez spécifier des balises lors de la création du fournisseur de capacité et activer la propagation des balises en spécifiant le paramètre `propagateTags` en tant que `CAPACITY_PROVIDER`.
Pour plus d’informations sur le balisage des instances gérées Amazon ECS, consultez la section [Balises pour les instances gérées Amazon ECS](instance-details-tags-managed-instances.md).
# Pratiques exemplaires pour la mise à jour des fournisseurs de capacité pour les instances gérées Amazon ECS
Pour bénéficier du plus haut niveau de sécurité et d’assistance en cas de restauration, nous recommandons de traiter les fournisseurs de capacités comme des ressources immuables. Lorsque vous devez mettre à jour la configuration d’un fournisseur de capacité, suivez ce flux de travail recommandé :
1. **Créez un fournisseur de capacité** avec votre configuration mise à jour au lieu de modifier le fournisseur existant.
1. **Mettez à jour chaque service** pour utiliser le nouveau fournisseur de capacité et permettre aux déploiements de se terminer.
1. **Supprimez l’ancien fournisseur de capacité** après avoir confirmé que la nouvelle configuration fonctionne comme prévu.
Cette approche offre plusieurs avantages :
+ **Déploiement contrôlé** : vous pouvez mettre à jour les services un par un et en surveiller l’impact.
+ **Restauration facile** : en cas de problème, vous pouvez rapidement rétablir les services pour utiliser le fournisseur de capacité précédent.
+ **Rayon d’action réduit** : les problèmes liés à la nouvelle configuration n’affectent pas immédiatement toutes les charges de travail.
**Note**
Si vous en utilisez CloudFormation, pensez à conserver l'ancien fournisseur de capacité jusqu'à un déploiement ultérieur afin de conserver la possibilité d'annuler les modifications apportées à votre stack.
Bien que vous puissiez mettre à jour les fournisseurs de capacité en place, cette approche crée un rayon d’action incontrôlé plus important. Les mises à jour en place appliquent de nouveaux paramètres à toutes les nouvelles capacités fournies à l’avenir, mais ne déclenchent pas de déploiements de service. Cela signifie que vous ne découvrirez peut-être les problèmes de configuration que bien plus tard, lorsque vos services devront être mis à l’échelle.
# Création d’un fournisseur de capacité pour les instances gérées Amazon ECS
Les instances gérées Amazon ECS font appel à des fournisseurs de capacité pour gérer la capacité de calcul de vos charges de travail. Lorsque vous créez un fournisseur de capacité sans le spécifier`instanceRequirements`, Amazon ECS sélectionne automatiquement les types d'instances à usage général les plus optimisés en termes de coûts. Vous pouvez créer des fournisseurs de capacité `instanceRequirements` pour spécifier des attributs d'instance tels que les types d'instance, les fabricants de processeurs, les types d'accélérateurs et d'autres exigences.
Les fournisseurs de capacité personnalisés utilisent la sélection du type d’instance basée sur des attributs, qui vous permet d’exprimer les exigences d’instance sous la forme d’un ensemble d’attributs. Ces exigences sont automatiquement transposées à tous les types d’instances Amazon EC2 correspondants, ce qui simplifie la création et la maintenance des configurations de types d’instances. Pour en savoir plus sur les exigences relatives aux instances et la sélection basée sur les attributs, consultez la documentation relative à la [sélection du type d’instance basée sur les attributs de flotte d’Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) dans le *Guide de l’utilisateur Amazon EC2*.
## Conditions préalables
Avant de commencer, assurez-vous d’avoir effectué les opérations suivantes :
+ Déterminer le type de surveillance à utiliser. Pour de plus amples informations, veuillez consulter [Surveillance détaillée des instances gérées Amazon ECS](monitoring-managed-instances.md#detailed-monitoring-managed-instances).
+ Avoir un cluster existant ou prévoir d’en créer un. Pour de plus amples informations, veuillez consulter [Création d’un cluster pour les instances gérées Amazon ECS](create-cluster-managed-instances.md).
+ Vous disposez des rôles IAM requis pour les instances gérées Amazon ECS. Cela inclut notamment les éléments suivants :
+ **Rôle dans l'infrastructure** : permet à Amazon ECS de passer des appels aux AWS services en votre nom afin de gérer l'infrastructure des instances gérées Amazon ECS.
Pour de plus amples informations, veuillez consulter [Rôle IAM d’infrastructure Amazon ECS](infrastructure_IAM_role.md).
+ **Profil d’instance** : fournit des autorisations pour l’agent de conteneur Amazon ECS et le démon Docker exécutés sur des instances gérées.
Pour de plus amples informations, veuillez consulter [Profil d’instance des instances gérées Amazon ECS](managed-instances-instance-profile.md).
Découvrez comment choisir vos instances. Pour de plus amples informations, veuillez consulter [Pratiques exemplaires en matière de sélection d’instances pour les instances gérées Amazon ECS](managed-instances-instance-selection-best-practices.md).
## Procédure pour la console
**Pour créer un fournisseur de capacité pour instances gérées Amazon ECS (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 le nom de votre cluster.
1. Sur la page Clusters, choisissez l’onglet **Infrastructure**.
1. Dans la section **Fournisseur de capacité**, choisissez **Créer un fournisseur de capacité**.
1. Sous **Configuration du fournisseur de capacité**, configurez les éléments suivants :
+ Pour **Nom du fournisseur de capacité**, saisissez un nom unique pour votre fournisseur de capacité.
+ Pour **Type de fournisseur de capacité**, choisissez **Instances gérées Amazon ECS**.
1. Sous **Configuration de l’instance**, configurez les éléments suivants :
+ Pour **Profil d’instance**, choisissez le rôle de profil d’instance créé pour les instances gérées Amazon ECS.
+ Pour **Rôle d’infrastructure**, choisissez le rôle d’infrastructure créé pour les instances gérées Amazon ECS.
1. Sous **Exigences de l’instance**, spécifiez les attributs de vos instances. Vous pouvez configurer n’importe quelle combinaison de ce qui suit :
+ **Nombre de vCPU** - Spécifiez le nombre de vCPU CPUs (par exemple, `4` ou `8-16` pour une plage).
+ **Mémoire (Mio)** : spécifiez la quantité de mémoire en Mio (par exemple, `8192` ou `16384-32768` pour une plage).
+ **Types d’instances** : spécifiez des types d’instances spécifiques (par exemple, `m5.large,m5.xlarge,c5.large`).
+ **Fabricants d’UC** : choisissez parmi `intel`, `amd`, ou `amazon-web-services`.
+ **Types d’accélérateurs** : spécifiez les types d’accélérateurs tels que `gpu`, `fpga`, ou `inference`.
+ **Nombre d’accélérateurs** : spécifiez le nombre d’accélérateurs (par exemple, `1` ou `2-4` pour une plage).
1. Sous **Configuration avancée**, choisissez l’une des options de surveillance suivantes :
+ **Pour que les métriques de vérification du statut des CloudWatch envois soient envoyées, choisissez Basic.**
+ Pour avoir CloudWatch envoyé toutes les métriques, choisissez **Detaillé**.
1. (Facultatif) Pour vous aider à identifier votre cluster, développez **Balises**, puis configurez vos balises.
Pour activer la propagation des balises du fournisseur de capacité vers les ressources gérées, telles que les instances lancées depuis le fournisseur de capacité, pour **Propager les balises depuis**, choisissez **Fournisseur de capacité**.
[Add a tag] Choisissez **Add tag** (Ajouter une balise) et procédez comme suit :
+ Pour **Key** (Clé), saisissez le nom de la clé.
+ Pour **Valeur**, saisissez la valeur de clé.
1. Choisissez **Créer**.
## AWS CLI procédure
Vous pouvez créer un fournisseur de capacité pour les instances gérées Amazon ECS à l’aide de l’ AWS CLI. Utilisez la version la plus récente de l’ AWS CLI. Pour savoir comment opérer une mise à niveau vers la dernière version, consultez la section [Installation ou mise à jour vers la dernière version de l’ AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Pour créer un fournisseur de capacité pour les instances gérées Amazon ECS (AWS CLI)**
1. Exécutez la commande suivante :
```
aws ecs create-capacity-provider --cli-input-json file://capacity-provider-definition.json
```
Le fichier `capacity-provider-definition.json` suivant peut être utilisé pour spécifier les exigences de base de l’instance, la taille de stockage de l’instance et activer la propagation des balises :
```
{
"name": "my-managed-instances-provider",
"cluster": "my-cluster",
"tags": [
{
"key": "version",
"value": "test"
}
],
"managedInstancesProvider": {
"infrastructureRoleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRole",
"instanceLaunchTemplate": {
"ec2InstanceProfileArn": "arn:aws:iam::123456789012:instance-profile/ecsInstanceRole",
"instanceRequirements": {
"vCpuCount": {
"min": 4,
"max": 8
},
"memoryMiB": {
"min": 8192,
"max": 16384
}
},
"networkConfiguration": {
"subnets": [
"subnet-abcdef01234567",
"subnet-bcdefa98765432"
],
"securityGroups": [
"sg-0123456789abcdef"
]
},
"storageConfiguration": {
"storageSizeGiB": 100
},
"monitoring": "basic"
},
"propagateTags": "CAPACITY_PROVIDER"
}
}
```
1. Vérifiez que votre fournisseur de capacité a été créé avec succès :
```
aws ecs describe-capacity-providers \
--capacity-providers my-managed-instances-provider
```
## Étapes suivantes
Après avoir créé votre fournisseur de capacité, vous pouvez l’utiliser pour créer des services ou exécuter des tâches :
+ Pour utiliser le fournisseur de capacité avec un service, consultez la section [Création d’un déploiement de mise à jour propagée Amazon ECS](create-service-console-v2.md).
+ Pour utiliser le fournisseur de capacité avec des tâches autonomes, consultez la section [Exécution d’une application en tant que tâche Amazon ECS](standalone-task-create.md).
# Mise à jour de la surveillance des instances gérées Amazon ECS
Vous pouvez modifier l’option de surveillance pour votre fournisseur de capacité d’instances gérées Amazon ECS afin de passer d’une surveillance de base à une surveillance détaillée. Cela vous permet d’ajuster le niveau des données de surveillance collectées sans avoir à recréer le fournisseur de capacité.
Pour plus d'informations sur les options de surveillance, consultez la section [Surveillance des instances gérées Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/monitoring-managed-instances.html).
## Procédure pour la console
**Pour mettre à jour la surveillance des instances gérées Amazon ECS (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 le nom de votre cluster.
1. Sur la page Clusters, choisissez l’onglet **Infrastructure**.
1. Sous **Configuration avancée**, choisissez l’une des options de surveillance suivantes :
+ **Pour que les métriques de vérification du statut des CloudWatch envois soient envoyées, choisissez Basic.**
+ Pour avoir CloudWatch envoyé toutes les métriques, choisissez **Detaillé**.
1. Choisissez **Mettre à jour**.
Pour mettre à jour les balises associées à un fournisseur de capacité d’instances gérées Amazon ECS existant, procédez comme suit :
1. Dans le panneau de navigation, choisissez **Clusters**.
1. Sur la page Clusters, choisissez **Infrastructure**.
1. Sur la page Infrastructure, choisissez le fournisseur de capacité que vous avez créé.
1. Sur la page Fournisseur de capacité, choisissez **Balises**.
1. Sous **Balises**, choisissez **Gérer les balises**.
1. Pour ajouter une balise, saisissez la clé et la valeur de la balise que vous voulez ajouter, puis choisissez **Enregistrer**. Pour ajouter plusieurs balises à la fois, choisissez **Ajouter une balise** pour chaque balise que vous voulez ajouter. Vous pouvez ajouter un maximum de 50 balises.
Pour supprimer une identification, choisissez **Supprimer**.
**Note**
Si la propagation des balises est activée, les balises ajoutées ou supprimées après la création du fournisseur de capacité ne s’appliquent pas aux ressources créées précédemment par le fournisseur de capacité.
## AWS CLI procédure
Vous pouvez mettre à jour un fournisseur de capacité pour les instances gérées Amazon ECS à l’aide de l’ AWS CLI. Utilisez la version la plus récente de l’ AWS CLI. Pour savoir comment opérer une mise à niveau vers la dernière version, consultez la section [Installation ou mise à jour vers la dernière version de l’ AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Pour mettre à jour la surveillance des instances gérées Amazon ECS (AWS CLI)**
1. Pour activer la surveillance détaillée, utilisez la commande suivante :
```
aws ecs update-capacity-provider \
--name my-managed-instances-provider \
--managed-instances-provider '{
"instanceLaunchTemplateUpdate": {
"monitoring": "DETAILED"
}
}'
```
1. Pour activer la surveillance de base, utilisez la commande suivante :
```
aws ecs update-capacity-provider \
--name my-managed-instances-provider \
--managed-instances-provider '{
"instanceLaunchTemplateUpdate": {
"monitoring": "BASIC"
}
}'
```
# Suppression d’un fournisseur de capacité d’instances gérées Amazon ECS
Si vous n’utilisez plus un fournisseur de capacité d’instances gérées Amazon ECS, vous pouvez le supprimer. Une fois le groupe supprimé, le fournisseur de capacité d’instances gérées Amazon ECS passe à l’état `INACTIVE`. Les fournisseurs de capacité ayant un état `INACTIVE` peuvent rester détectables dans votre compte pendant un certain temps. Cependant, cela est susceptible de changer à terme. Il est donc important de ne pas compter sur la persistance des fournisseurs de capacité dont l'état est `INACTIVE`. Avant de supprimer le fournisseur de capacité d’instance gérée Amazon ECS, vous devez le supprimer de la stratégie de fournisseur de capacité de tous les services. Vous pouvez utiliser l'API `UpdateService` ou le flux de service de mise à jour dans la console Amazon ECS pour supprimer un fournisseur de capacité de la stratégie de fournisseur de capacité d'un service. Utilisez l’option **Forcer le nouveau déploiement** pour vous assurer que toutes les tâches utilisant la capacité fournie par le fournisseur de capacité d’instances gérées Amazon ECS sont transférées vers les autres fournisseurs de capacité afin d’utiliser leur capacité.
**Pour supprimer un fournisseur de capacité pour le cluster (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 **Clusters**.
1. Sur la page **Clusters**, choisissez le cluster.
1. Sur la *name* page **Cluster :**, choisissez **Infrastructure**, le fournisseur de capacité des instances gérées Amazon ECS, puis choisissez **Supprimer**.
1. Dans le champ de confirmation, saisissez **Supprimer *Amazon ECS Managed Instances capacity provider name***
1. Sélectionnez **Delete (Supprimer)**.
# Arrêt sécurisé des charges de travail Amazon ECS exécutées sur des instances gérées Amazon ECS
Vous pouvez utiliser la protection évolutive des tâches Amazon ECS pour empêcher que vos tâches ne soient interrompues par des événements de réduction horizontale liés à la réduction horizontale des services ou aux déploiements.
Certaines applications nécessitent un mécanisme permettant de protéger les tâches critiques contre toute interruption due à des événements de mise à l'échelle horizontale en période de faible utilisation ou lors de déploiements de services. Par exemple :
+ Vous disposez d'une application asynchrone de traitement des files d'attente, telle qu'une tâche de transcodage vidéo, dans laquelle certaines tâches doivent s'exécuter pendant des heures, même lorsque l'utilisation cumulée des services est faible.
+ Vous disposez d’une application de jeu exécutant des serveurs de jeu en tant que tâches, lesquels doivent continuer à fonctionner même si tous les utilisateurs se sont déconnectés afin de réduire la latence de démarrage lors d’un redémarrage du serveur.
+ Lorsque vous déployez une nouvelle version de code, vous avez besoin que des tâches continuent à s'exécuter, car leur retraitement serait coûteux.
Pour empêcher les tâches appartenant à votre service de se terminer lors d'un événement de mise à l'échelle horizontale, définissez l'attribut `ProtectionEnabled` sur `true`. Lorsque vous définissez `ProtectionEnabled` sur true, les tâches sont protégées pendant deux heures par défaut. Vous pouvez ensuite personnaliser la période de protection à l’aide de l’attribut `ExpiresInMinutes`. Vous pouvez protéger vos tâches pendant au moins une minute et jusqu'à un maximum de 2 880 minutes (48 heures). Si vous utilisez le AWS CLI, vous pouvez spécifier l'`--protection-enabled`option.
Une fois qu'une tâche a terminé son travail requis, vous pouvez définir l'attribut `ProtectionEnabled` sur `false`, ce qui permet à la tâche d'être interrompue par des événements ultérieurs de mise à l'échelle horizontale. Si vous utilisez le AWS CLI, vous pouvez spécifier l'`--no-protection-enabled`option.
## Mécanismes de protection évolutive des tâches
Vous pouvez définir et obtenir une protection évolutive des tâches à l'aide du point de terminaison de l'agent de conteneur Amazon ECS ou de l'API Amazon ECS.
+ **Point de terminaison de l'agent de conteneur Amazon ECS**
Nous vous recommandons d'utiliser le point de terminaison de l'agent de conteneur Amazon ECS pour les tâches qui peuvent déterminer automatiquement le besoin de protection. Utilisez cette approche pour les charges de travail basées sur les files d'attente ou le traitement des tâches.
Lorsqu'un conteneur commence à traiter un travail, par exemple en consommant un message SQS, vous pouvez définir l'attribut `ProtectionEnabled` via le chemin `$ECS_AGENT_URI/task-protection/v1/state` du point de terminaison de protection évolutive des tâches depuis le conteneur. Amazon ECS n'interrompra pas cette tâche lors d'événements de mise à l'échelle horizontale. Une fois que votre tâche a terminé son travail, vous pouvez effacer l’attribut `ProtectionEnabled` en utilisant le même point de terminaison, ce qui rend la tâche susceptible d’être interrompue lors d’événements ultérieurs de mise à l’échelle horizontale.
Pour de plus amples informations sur l’utilisation de point de terminaison de l’agent de conteneur Amazon ECS, consultez la section [Point de terminaison de protection évolutive des tâches Amazon ECS](managed-instance-task-scale-in-protection-endpoint.md).
+ **API Amazon ECS**
Vous pouvez utiliser l’API Amazon ECS pour définir et récupérer la protection évolutive des tâches si votre application dispose d’un composant qui suit l’état des tâches actives. Utilisez `UpdateTaskProtection` pour marquer une ou plusieurs tâches comme protégées. Utilisez `GetTaskProtection` pour récupérer l’état de protection.
Un exemple de cette approche serait si votre application héberge des sessions de serveur de jeu comme tâches Amazon ECS. Lorsqu'un utilisateur se connecte à une session sur le serveur (tâche), vous pouvez marquer la tâche comme protégée. Une fois que l'utilisateur se déconnecte, vous pouvez soit retirer la protection spécifique à cette tâche, soit retirer périodiquement la protection pour des tâches similaires qui ne comportent plus de sessions actives, en fonction de vos besoins en termes de serveurs inactifs.
Pour plus d'informations, consultez [UpdateTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateTaskProtection.html)et consultez le [GetTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_GetTaskProtection.html)manuel *Amazon Elastic Container Service API Reference*.
Vous pouvez combiner les deux approches. Par exemple, utilisez le point de terminaison de l'agent Amazon ECS pour définir la protection des tâches depuis un conteneur et utilisez l'API Amazon ECS pour retirer la protection des tâches depuis votre service de contrôleur externe.
## Considérations
Prenez en compte les points suivants avant d'utiliser la protection évolutive des tâches :
+ La protection évolutive des tâches n’est prise en charge que pour les tâches déployées à partir d’un service.
+ La protection évolutive des tâches est prise en charge par les tâches déployées à partir d’un service exécuté sur les instances gérées Amazon ECS.
+ Nous vous recommandons d'utiliser le point de terminaison de l'agent de conteneur Amazon ECS, car l'agent Amazon ECS possède des mécanismes de nouvelle tentative intégrés et une interface plus simple.
+ Vous pouvez réinitialiser la période d'expiration de la protection contre la mise à l'échelle horizontale des tâches en appelant `UpdateTaskProtection` pour une tâche pour laquelle la protection est déjà activée.
+ Déterminez le temps nécessaire à une tâche pour effectuer le travail requis et définissez la propriété `expiresInMinutes` en conséquence. Si vous fixez une période d'expiration de la protection plus longue que nécessaire, vous devrez supporter des coûts et serez confronté à des retards dans le déploiement de nouvelles tâches.
+ Considérations relatives au déploiement :
+ Si le service utilise une mise à jour propagée, de nouvelles tâches seront créées, mais les tâches exécutant une ancienne version ne seront pas terminées avant la désactivation ou l'expiration de `protectionEnabled`. Vous pouvez ajuster le paramètre `maximumPercentage` dans la configuration du déploiement sur une valeur qui permet de créer de nouvelles tâches lorsque les anciennes tâches sont protégées.
+ Si vous l'utilisez CloudFormation, le délai d'expiration de la pile de mises à jour est de 3 heures. Par conséquent, si vous définissez la protection des tâches pour une durée supérieure à 3 heures, votre CloudFormation déploiement peut entraîner un échec et une annulation.
Pendant le temps que vos anciennes tâches sont protégées, la CloudFormation pile apparaît`UPDATE_IN_PROGRESS`. Si la protection contre la mise à l'échelle horizontale des tâches est supprimée ou expire dans un délai de trois heures, votre déploiement réussira et passera au statut `UPDATE_COMPLETE`. Si le déploiement est bloqué dans l'état `UPDATE_IN_PROGRESS` pendant plus de 3 heures, il échouera et affichera un état `UPDATE_FAILED`, puis reviendra au dernier ensemble de tâches.
+ Amazon ECS envoie des événements de service lorsque des tâches protégées empêchent un déploiement (propagé ou bleu/vert) d'atteindre l'état stable, afin que vous puissiez prendre des mesures correctives. Lorsque vous essayez de mettre à jour l'état de protection d'une tâche et que vous recevez un message d'erreur `DEPLOYMENT_BLOCKED`, cela signifie que le service possède un nombre de tâches protégées supérieur au nombre de tâches souhaité pour le service. Pour résoudre cette erreur, effectuez l'une des opérations suivantes :
+ Attendez que la protection des tâches en cours expire. Définissez ensuite la protection des tâches.
+ Déterminez quelles tâches peuvent être interrompues. Utilisez ensuite `UpdateTaskProtection` avec l'option `protectionEnabled` définie sur `false` pour ces tâches.
+ Augmentez le nombre de tâches souhaité pour le service à un nombre supérieur au nombre de tâches protégées.
## Autorisations IAM requises pour la protection évolutive des tâches
La tâche doit avoir le rôle de tâche Amazon ECS avec les autorisations suivantes :
+ `ecs:GetTaskProtection` : permet à l'agent de conteneur Amazon ECS d'appeler `GetTaskProtection`.
+ `ecs:UpdateTaskProtection` : permet à l'agent de conteneur Amazon ECS d'appeler `UpdateTaskProtection`.
# Point de terminaison de protection évolutive des tâches Amazon ECS
L'agent de conteneur Amazon ECS injecte automatiquement la variable d'environnement `ECS_AGENT_URI` dans les conteneurs des tâches Amazon ECS afin de fournir une méthode permettant d'interagir avec le point de terminaison de l'API de l'agent de conteneur.
Nous vous recommandons d'utiliser le point de terminaison de l'agent de conteneur Amazon ECS pour les tâches qui peuvent déterminer automatiquement le besoin de protection.
Lorsqu’un conteneur commence à traiter une tâche, vous pouvez définir l’attribut `protectionEnabled` à l’aide du chemin d’accès `$ECS_AGENT_URI/task-protection/v1/state` du point de terminaison de protection évolutive des tâches à partir du conteneur.
Utilisez une requête PUT vers cette URI à partir d’un conteneur pour définir la protection évolutive des tâches. Une requête GET vers cette URI renvoie le statut de protection actuel d’une tâche.
## Paramètres de requête de protection évolutive des tâches
Vous pouvez définir la protection évolutive des tâches à l'aide du point de terminaison `${ECS_AGENT_URI}/task-protection/v1/state` avec les paramètres de demande suivants.
`ProtectionEnabled`
Spécifiez `true` pour marquer une tâche à protéger. Spécifiez `false` si vous souhaitez supprimer la protection et rendre la tâche éligible à l’arrêt.
Type : Boolean
Obligatoire : oui
`ExpiresInMinutes`
Le nombre de minutes pendant lesquelles la tâche est protégée. Vous pouvez spécifier un minimum de 1 minute et aller jusqu'à 2 880 minutes (48 heures). Pendant cette période, votre tâche ne sera pas interrompue par des événements de mise à l'échelle horizontale provenant de l'autoscaling du service ou de déploiements. Une fois cette période écoulée, le paramètre `protectionEnabled` est défini sur `false`.
Si vous ne spécifiez pas de durée, la tâche est automatiquement protégée pendant 120 minutes (2 heures).
Type : Integer
Obligatoire : non
Les exemples suivants montrent comment définir la protection des tâches avec des durées différentes.
**Exemple de protection d’une tâche avec la durée par défaut**
Cet exemple montre comment protéger une tâche dont la durée par défaut est de 2 heures.
```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true}'
```
**Exemple de protection d’une tâche pendant 60 minutes**
Cet exemple montre comment protéger une tâche pendant 60 minutes à l'aide du paramètre `expiresInMinutes`.
```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":60}'
```
**Exemple de protection d’une tâche pendant 24 heures**
Cet exemple montre comment protéger une tâche pendant 24 heures à l'aide du paramètre `expiresInMinutes`.
```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":1440}'
```
La requête PUT renvoie la réponse suivante.
```
{
"protection": {
"ExpirationDate": "2023-12-20T21:57:44.837Z",
"ProtectionEnabled": true,
"TaskArn": "arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
}
}
```
## Paramètres de réponse de protection évolutive des tâches
Les informations suivantes sont renvoyées à partir de la réponse JSON du point de terminaison de protection contre la mise à l'échelle horizontale des tâches `${ECS_AGENT_URI}/task-protection/v1/state`.
`ExpirationDate`
Période pendant laquelle la protection de la tâche expirera. Si la tâche n’est pas protégée, cette valeur est nulle.
`ProtectionEnabled`
État de protection de la tâche. Si la protection évolutive est activée pour une tâche, la valeur est `true`. Sinon, la valeur est `false`.
`TaskArn`
Amazon Resource Name (ARN) de la tâche à laquelle le conteneur appartient.
L'exemple suivant affiche les détails renvoyés pour une tâche protégée.
```
curl --request GET ${ECS_AGENT_URI}/task-protection/v1/state
```
```
{
"protection":{
"ExpirationDate":"2023-12-20T21:57:44Z",
"ProtectionEnabled":true,
"TaskArn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
}
}
```
Les informations suivantes sont renvoyées en cas d'échec.
`Arn`
Amazon Resource Name (ARN) complet de la tâche.
`Detail`
Détails relatifs à l'échec.
`Reason`
Raison de l'échec.
L'exemple suivant affiche les détails renvoyés pour une tâche qui n'est pas protégée.
```
{
"failure":{
"Arn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0",
"Detail":null,
"Reason":"TASK_NOT_VALID"
}
}
```
Les informations suivantes sont renvoyées en cas d'exception.
`requestID`
L'ID de AWS demande pour l'appel d'API Amazon ECS qui entraîne une exception.
`Arn`
Amazon Resource Name (ARN) complet de la tâche ou du service.
`Code`
Code de l’erreur.
`Message`
Message d’erreur.
Si une erreur `RequestError` ou `RequestTimeout` apparaît, il s'agit probablement d'un problème de mise en réseau. Essayez d'utiliser les points de terminaison d'un VPC pour Amazon ECS.
L'exemple suivant affiche les détails renvoyés en cas d'erreur.
```
{
"requestID":"12345-abc-6789-0123-abc",
"error":{
"Arn":"arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
"Code":"AccessDeniedException",
"Message":"User: arn:aws:sts::444455556666:assumed-role/my-ecs-task-role/1234567890abcdef0 is not authorized to perform: ecs:GetTaskProtection on resource: arn:aws:ecs:us-west-2:555555555555:task/test/1234567890abcdef0 because no identity-based policy allows the ecs:GetTaskProtection action"
}
}
```
L'erreur suivante s'affiche si l'agent Amazon ECS ne parvient pas à obtenir de réponse du point de terminaison Amazon ECS pour des raisons telles que des problèmes de réseau ou si le plan de contrôle Amazon ECS est en panne.
```
{
"error": {
"Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
"Code": "RequestCanceled",
"Message": "Timed out calling Amazon ECS Task Protection API"
}
}
```
L'erreur suivante apparaît lorsque l'agent Amazon ECS reçoit une exception de limitation de la part d'Amazon ECS.
```
{
"requestID": "12345-abc-6789-0123-abc",
"error": {
"Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
"Code": "ThrottlingException",
"Message": "Rate exceeded"
}
}
```
# Clusters Amazon ECS pour Fargate
Avec Amazon ECS sur les fournisseurs AWS Fargate de capacité, vous pouvez utiliser à la fois les capacités Fargate et Fargate Spot pour vos tâches Amazon ECS.
Avec Fargate Spot, vous pouvez exécuter des tâches Amazon ECS tolérantes aux interruptions à un tarif réduit par rapport au prix de Fargate. Fargate Spot exécute les tâches sur la capacité de calcul de réserve. Lorsque la AWS capacité est rétablie, vos tâches sont interrompues par un avertissement de deux minutes.
Lorsque les tâches qui utilisent les fournisseurs de capacité Fargate et Fargate Spot sont arrêtées, l'événement de changement d'état de la tâche est envoyé à Amazon. EventBridge Le motif de l'arrêt en décrit la cause. Pour de plus amples informations, veuillez consulter [Événements de changement d’état d’une tâche Amazon ECS](ecs_task_events.md).
Un cluster peut contenir une combinaison à la fois de fournisseurs de capacité Fargate et de groupe Auto Scaling. Toutefois, une stratégie de fournisseur de capacité ne peut contenir que des fournisseurs de capacité Fargate ou de groupe Auto Scaling, mais pas les deux. Pour plus d’informations, consultez la section [Fournisseurs de capacité pour les groupes Auto Scaling](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html#asg-capacity-providers).
Prenez les points suivants en compte lors de l'utilisation de fournisseurs de capacité :
+ Vous devez associer un fournisseur de capacité à un cluster avant de l’associer à la stratégie du fournisseur de capacité.
+ Vous pouvez spécifier un maximum de 20 fournisseurs de capacité pour une stratégie de fournisseur de capacité.
+ Vous ne pouvez pas mettre à jour un service utilisant un fournisseur de capacité de groupe Auto Scaling pour utiliser un fournisseur de capacité Fargate. L'inverse est également vrai.
+ Dans une stratégie de fournisseur de capacité, si aucune valeur `weight` n'est spécifiée pour un fournisseur de capacité dans la console, alors la valeur par défaut `1` est utilisée. Si vous utilisez l'API ou AWS CLI, la valeur par défaut de `0` est utilisée.
+ Lorsque plusieurs fournisseurs de capacité sont spécifiés dans le cadre d'une stratégie de fournisseur de capacité, au moins l'un des fournisseurs de capacité doit disposer d'une valeur de poids supérieure à zéro. Les fournisseurs de capacité dont le poids est nul ne sont pas utilisés pour attribuer des tâches. Si vous spécifiez, dans une stratégie, plusieurs fournisseurs de capacité qui possèdent tous un poids nul, toutes les actions `RunTask` ou `CreateService` utilisant la stratégie de fournisseur de capacité échoueront.
+ Une valeur de *base* ne peut être définie que pour un seul fournisseur de capacité dans une stratégie de fournisseur de capacité. Si aucune valeur de base n'est spécifiée, la valeur par défaut de zéro est utilisée.
+ Un cluster peut contenir une combinaison à la fois de fournisseurs de capacité de groupe Auto Scaling et de fournisseurs de capacité Fargate. Cependant, une stratégie de fournisseur de capacité ne peut contenir que des groupes Auto Scaling ou des fournisseurs de capacité Fargate, mais pas les deux.
+ Un cluster peut contenir un mélange de services et de tâches autonomes qui utilisent les deux fournisseurs de capacité. Un service peut être mis à jour pour utiliser une stratégie de fournisseur de capacité plutôt qu'un type de lancement. Vous devez toutefois forcer un nouveau déploiement pour ce faire.
## Avis de résiliation Spot Fargate
Pendant les périodes de forte demande, la capacité Spot de Fargate peut être indisponible. Cela peut retarder les tâches Spot de Fargate. Lorsque cela se produit, les services Amazon ECS essaient de relancer les tâches jusqu’à ce que la capacité requise soit disponible. Fargate ne remplace pas la capacité Spot par une capacité à la demande.
Lorsque des tâches utilisant la capacité Fargate Spot sont arrêtées en raison d'une interruption Spot, un avertissement d'interruption sous deux minutes est envoyé avant cet arrêt. L'avertissement est envoyé en tant qu'événement de changement d'état de tâche à Amazon EventBridge et en tant que signal SIGTERM à la tâche en cours d'exécution. Si vous utilisez Fargate Spot au titre d'un service, le planificateur de service reçoit dans ce scénario le signal d'interruption et tente de lancer des tâches supplémentaires sur Fargate Spot si la capacité est disponible. Un service avec une seule tâche est interrompu jusqu'à ce que la capacité soit disponible. Pour plus d'informations sur un arrêt progressif, veuillez consulter le billet de blog [Graceful shutdowns with ECS](https://aws.amazon.com/blogs/containers/graceful-shutdowns-with-ecs/).
Pour faire en sorte que vos conteneurs se ferment correctement avant l'arrêt de la tâche, vous pouvez configurer les éléments suivants :
+ Il est possible de spécifier une valeur de temporisation d'arrêt (`stopTimeout`) de `120` secondes ou moins dans la définition de conteneur utilisée par la tâche. La valeur `stopTimeout` par défaut est de 30 secondes. Vous pouvez spécifier une valeur `stopTimeout` plus longue pour disposer de plus de temps entre le moment où l'événement de changement d'état de tâche est reçu et l'instant où le conteneur est arrêté de force. Pour de plus amples informations, veuillez consulter [Temporisations de conteneurs](task_definition_parameters.md#container_definition_timeout).
+ Le signal SIGTERM doit être reçu à l'intérieur du conteneur pour effectuer des actions de nettoyage. Si vous ne parvenez pas à traiter ce signal, la tâche reçoit un signal SIGKILL après le `stopTimeout` configuré et peut entraîner une perte ou une corruption de données.
Voici un extrait d'événement de changement d'état de tâche. Cet extrait indique le motif et le code d'arrêt d'une interruption Fargate Spot.
```
{
"version": "0",
"id": "9bcdac79-b31f-4d3d-9410-fbd727c29fab",
"detail-type": "ECS Task State Change",
"source": "aws.ecs",
"account": "111122223333",
"resources": [
"arn:aws:ecs:us-east-1:111122223333:task/b99d40b3-5176-4f71-9a52-9dbd6f1cebef"
],
"detail": {
"clusterArn": "arn:aws:ecs:us-east-1:111122223333:cluster/default",
"createdAt": "2016-12-06T16:41:05.702Z",
"desiredStatus": "STOPPED",
"lastStatus": "RUNNING",
"stoppedReason": "Your Spot Task was interrupted.",
"stopCode": "SpotInterruption",
"taskArn": "arn:aws:ecs:us-east-1:111122223333:task/b99d40b3-5176-4f71-9a52-9dbd6fEXAMPLE",
...
}
}
```
Voici un modèle d'événement utilisé pour créer une EventBridge règle pour les événements de changement d'état des tâches Amazon ECS. Vous pouvez éventuellement spécifier un cluster dans le champ `detail`. Cela signifie que vous recevrez des événements de changement d'état de tâche pour ce cluster. Pour plus d'informations sur la création d'une EventBridge règle, consultez [Getting started with Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) dans le *guide de EventBridge l'utilisateur Amazon*.
```
{
"source": [
"aws.ecs"
],
"detail-type": [
"ECS Task State Change"
],
"detail": {
"clusterArn": [
"arn:aws:ecs:us-west-2:111122223333:cluster/default"
]
}
}
```
# Création d’un cluster Amazon ECS pour les charges de travail Fargate
Vous créez un cluster pour définir l’infrastructure sur laquelle vos tâches et vos services s’exécutent.
Avant de commencer, veillez achever les étapes de [Configurer l'utilisation d'Amazon ECS](get-set-up-for-amazon-ecs.md) et affectez l’autorisation IAM appropriée. Pour de plus amples informations, veuillez consulter [Exemples de cluster Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies). La console Amazon ECS crée les ressources nécessaires à un cluster Amazon ECS en créant une CloudFormation pile.
La console associe automatiquement les fournisseurs de capacité Fargate et Fargate Spot au cluster.
Vous pouvez modifier les options suivantes :
+ Ajoutez un espace de noms au cluster.
Un espace de noms permet aux services que vous créez dans le cluster de se connecter aux autres services de l'espace de noms sans configuration supplémentaire. Pour de plus amples informations, veuillez consulter [Interconnexion des services Amazon ECS](interconnecting-services.md).
+ Activez les événements de tâche pour recevoir des EventBridge notifications en cas de modification de l'état des tâches.
+ Ajoutez des balises pour vous aider à identifier vos clusters.
+ Attribuez une AWS KMS clé à votre espace de stockage géré. Pour plus d’informations sur la création d’une clé, consultez la section [Création d’une clé KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le *Guide de l’utilisateur AWS Key Management Service *.
+ Attribuez une AWS KMS clé à votre espace de stockage éphémère Fargate. Pour plus d’informations sur la création d’une clé, consultez la section [Création d’une clé KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le *Guide de l’utilisateur AWS Key Management Service *.
+ Configurez la AWS KMS clé et la journalisation pour ECS Exec.
## Procédure
**Pour créer un nouveau cluster (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 **Configuration de cluster**, configurez les éléments suivants :
+ Pour **Nom du cluster**, saisissez un nom unique.
Le nom peut contenir jusqu'à 255 lettres (minuscules et majuscules), des chiffres et des traits d'union.
+ (Facultatif) Pour que l’espace de noms utilisé pour Service Connect soit différent du nom du cluster, sous **Paramètres par défaut de Service Connect**, pour **Espace de noms par défaut**, sélectionnez ou saisissez un nom d’espace de noms. Pour utiliser un espace de noms partagé, choisissez ou saisissez un ARN d’espace de noms. Pour plus d’informations sur l’utilisation d’espaces de nom partagés, consultez la section [Amazon ECS Service Connect avec espaces de AWS Cloud Map noms partagés](service-connect-shared-namespaces.md).
1. (Facultatif) Utilisez Container Insights, développez **Surveillance**, puis sélectionnez une des options suivantes :
+ Pour utiliser Container Insights avec observabilité améliorée comme recommandé, sélectionnez **Container Insights avec observabilité améliorée**.
+ Pour utiliser Container Insights, choisissez **Container Insights**.
1. (Facultatif) Pour activer les événements de tâches, développez les **événements de tâches**, puis activez l'**option Activer les événements de tâches**.
Lorsque vous activez les événements de tâches, Amazon ECS envoie les événements de modification de l'état des tâches à EventBridge. Cela vous permet de surveiller les modifications du cycle de vie des tâches et d'y répondre automatiquement.
1. (Facultatif) Pour utiliser ECS Exec afin de déboguer les tâches dans le cluster, développez **Configuration de la résolution des problèmes**, puis configurez les éléments suivants :
+ (Facultatif) Pour la **AWS KMS clé pour ECS Exec**, entrez l'ARN de la AWS KMS clé que vous souhaitez utiliser pour chiffrer les données de session ECS Exec.
+ (Facultatif) Pour **Journalisation ECS Exec**, choisissez la destination du journal :
+ Pour envoyer des journaux à CloudWatch Logs, choisissez **Amazon CloudWatch**.
+ Pour envoyer les journaux à Amazon S3, choisissez **Amazon S3**.
+ Pour désactiver la journalisation, choisissez **Aucune**.
1. (Facultatif). Sous **Chiffrement**, vous pouvez configurer les éléments suivants :
+ Chiffrer vos données sur le stockage éphémère Fargate. Sous **Chiffrement**, pour le **stockage éphémère Fargate**, entrez l'ARN de la clé que vous souhaitez utiliser pour chiffrer AWS KMS les données de stockage éphémère Fargate.
+ Chiffrer les données sur le stockage géré. Sous **Chiffrement**, pour **Stockage géré**, entrez l'ARN de la AWS KMS clé que vous souhaitez utiliser pour chiffrer les données du stockage géré.
1. (Facultatif) Pour vous aider à identifier votre cluster, développez **Tags** (balises), puis configurez vos balises.
[Add a tag] Choisissez **Add tag** (Ajouter une balise) et procédez comme suit :
+ Pour **Key** (Clé), saisissez le nom de la clé.
+ Pour **Value** (Valeur), saisissez la valeur de clé.
[Remove a tag] Choisissez **Remove** (Supprimer) à la droite de la clé et de la valeur de l'étiquette.
1. Choisissez **Créer**.
## Étapes suivantes
Après avoir créé le cluster, vous pouvez créer des définitions de tâches pour vos applications, puis les exécuter en tant que tâches autonomes ou dans le cadre d'un service. Pour plus d’informations, consultez les ressources suivantes :
+ [Définitions de tâche Amazon ECS](task_definitions.md)
+ [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)
# Fournisseurs de capacité Amazon ECS pour les charges de travail EC2
Lorsque vous utilisez les instances Amazon EC2 pour votre capacité, vous utilisez les groupes Auto Scaling pour gérer les instances Amazon EC2 enregistrées sur leurs clusters. L’autoscaling permet de vous assurer que vous disposez du bon nombre d’instances Amazon EC2 disponibles pour gérer la charge de l’application.
Vous pouvez utiliser la fonctionnalité de mise à l’échelle gérée pour qu’Amazon ECS gère l’augmentation et la réduction horizontale du groupe Auto Scaling, ou vous pouvez gérer les actions de mise à l’échelle vous-même. Pour de plus amples informations, veuillez consulter [Gestion automatique de la capacité Amazon ECS grâce à l’autoscaling de cluster](cluster-auto-scaling.md).
Nous vous recommandons de créer un groupe Auto Scaling vide. Si vous utilisez un groupe Auto Scaling existant, il se peut que les instances Amazon EC2 associées au groupe qui étaient déjà en cours d'exécution et enregistrées sur un cluster Amazon ECS avant le groupe Auto Scaling utilisé pour créer un fournisseur de capacité ne soient pas bien enregistrées auprès du fournisseur de capacité. Cela peut occasionner des problèmes lorsque le fournisseur de capacité est utilisé dans une stratégie de fournisseur de capacité. Utilisez `DescribeContainerInstances` pour vérifier qu'une instance de conteneur est bien associée à un fournisseur de capacité.
**Note**
Pour créer un groupe Auto Scaling vide, définissez le nombre souhaité sur zéro. Après avoir créé le fournisseur de capacité et l'avoir associé à un cluster, vous pouvez le mettre à l'échelle.
Lorsque vous utilisez la console Amazon ECS, Amazon ECS crée un modèle de lancement Amazon EC2 et un groupe Auto Scaling en votre nom dans le cadre de la CloudFormation pile. Ils sont préfixés par `EC2ContainerService-`. Vous pouvez utiliser le groupe Auto Scaling comme fournisseur de capacité pour ce cluster.
Nous vous recommandons d’utiliser le drainage d’instance gérée pour permettre la résiliation progressive des instances Amazon EC2 sans perturber vos charges de travail. Cette fonctionnalité est activée par défaut. Pour de plus amples informations, consultez [Arrêt en toute sécurité des charges de travail Amazon ECS exécutées sur les instances EC2](managed-instance-draining.md).
Les points suivants doivent être pris en compte lors de l'utilisation de fournisseurs de capacité de groupe Auto Scaling dans la console :
+ La valeur du paramètre `MaxSize` d'un groupe Auto Scaling doit être supérieure à zéro pour une montée en puissance.
+ Le groupe Auto Scaling ne peut pas avoir de paramètres de pondération d'instance.
+ Si le groupe Auto Scaling ne peut pas monter en puissance pour s'adapter au nombre de tâches exécutées, les tâches ne parviennent pas à passer outre l'état `PROVISIONING`.
+ Ne modifiez pas la ressource de politique de mise à l'échelle associée à vos groupes Auto Scaling gérés par des fournisseurs de capacité.
+ Si la mise à l'échelle gérée est activée au moment où vous créez un fournisseur de capacité, le nombre souhaité de groupes Auto Scaling peut être défini sur `0`. Lorsque la mise à l'échelle gérée est activée, Amazon ECS gère les actions de mise à l'échelle horizontale et de montée en puissance du groupe Auto Scaling.
+ Vous devez associer un fournisseur de capacité à un cluster avant de l’associer à la stratégie du fournisseur de capacité.
+ Vous pouvez spécifier un maximum de 20 fournisseurs de capacité pour une stratégie de fournisseur de capacité.
+ Vous ne pouvez pas mettre à jour un service utilisant un fournisseur de capacité de groupe Auto Scaling pour utiliser un fournisseur de capacité Fargate. L'inverse est également vrai.
+ Dans une stratégie de fournisseur de capacité, si aucune valeur `weight` n'est spécifiée pour un fournisseur de capacité dans la console, alors la valeur par défaut `1` est utilisée. Si vous utilisez l'API ou AWS CLI, la valeur par défaut de `0` est utilisée.
+ Lorsque plusieurs fournisseurs de capacité sont spécifiés dans le cadre d'une stratégie de fournisseur de capacité, au moins l'un des fournisseurs de capacité doit disposer d'une valeur de poids supérieure à zéro. Les fournisseurs de capacité dont le poids est nul ne sont pas utilisés pour attribuer des tâches. Si vous spécifiez, dans une stratégie, plusieurs fournisseurs de capacité qui possèdent tous un poids nul, toutes les actions `RunTask` ou `CreateService` utilisant la stratégie de fournisseur de capacité échoueront.
+ Une valeur de *base* ne peut être définie que pour un seul fournisseur de capacité dans une stratégie de fournisseur de capacité. Si aucune valeur de base n'est spécifiée, la valeur par défaut de zéro est utilisée.
+ Un cluster peut contenir une combinaison à la fois de fournisseurs de capacité de groupe Auto Scaling et de fournisseurs de capacité Fargate. Toutefois, une stratégie de fournisseur de capacité ne peut contenir que des fournisseurs de capacité du groupe Auto Scaling ou Fargate, mais pas les deux.
+ Un cluster peut contenir une combinaison de services et de tâches autonomes utilisant à la fois des fournisseurs de capacité et des types de lancement. Un service peut être mis à jour pour utiliser une stratégie de fournisseur de capacité plutôt qu'un type de lancement. Vous devez toutefois forcer un nouveau déploiement pour ce faire.
+ Amazon ECS prend en charge les groupes d'instances pré-initialisées Amazon EC2 Auto Scaling. Un groupe d'instances pré-initialisées est un groupe d'instances Amazon EC2 pré-initialisées prêtes à être mises en service. Chaque fois que votre application doit être mise à l’échelle, Amazon EC2 Auto Scaling utilise les instances préinitialisées du groupe d’instances préinitialisées plutôt que de lancer des instances non initialisées. Cela permet à tout processus d’initialisation final de s’exécuter avant que l’instance ne soit mise en service. Pour de plus amples informations, veuillez consulter [Configuration d’instances préinitialisées pour votre groupe Auto Scaling Amazon ECS](using-warm-pool.md).
Pour plus d’informations sur la création de modèles de lancement pour Amazon EC2 Auto Scaling, consultez la section [Modèles de lancement](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html) dans le *Guide de l’utilisateur Amazon EC2 Auto Scaling*. Pour plus d'informations sur la création de groupe Amazon EC2 Auto Scaling, consultez la section [Création de groupes Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) dans le *Guide de l'utilisateur Amazon EC2 Auto Scaling*.
# Considérations relatives à la sécurité des instances de conteneur Amazon EC2 pour Amazon ECS
Vous devez envisager une instance de conteneur unique et son accès dans le cadre de votre modèle de menace. Par exemple, une seule tâche affectée peut être en mesure de tirer parti des autorisations IAM d'une tâche non infectée sur la même instance.
Nous vous recommandons d'utiliser la procédure suivante pour empêcher cela :
+ N'utilisez pas les privilèges d'administrateur lors de l'exécution de vos tâches.
+ Attribuez un rôle de tâche avec un accès de moindre privilège à vos tâches.
L'agent de conteneur crée automatiquement un jeton avec un ID d'informations d'identification unique qui est utilisé pour accéder aux ressources Amazon ECS.
+ Pour empêcher les conteneurs exécutés par des tâches utilisant le mode réseau `awsvpc` d'accéder aux informations d'identification fournies par le profil d'instance Amazon EC2, tout en accordant les autorisations fournies par le rôle de la tâche, définissez la variable de configuration d'agent `ECS_AWSVPC_BLOCK_IMDS` sur true dans le fichier de configuration de l'agent et redémarrez l'agent.
+ Utilisez Amazon GuardDuty Runtime Monitoring pour détecter les menaces visant les clusters et les conteneurs au sein de votre AWS environnement. La surveillance du temps d'exécution utilise un agent de GuardDuty sécurité qui augmente la visibilité de l'exécution sur les charges de travail Amazon ECS individuelles, par exemple l'accès aux fichiers, l'exécution des processus et les connexions réseau. Pour plus d'informations, consultez la section [Surveillance du temps GuardDuty d'exécution](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html) dans le *guide de GuardDuty l'utilisateur*.
# Création d’un cluster Amazon ECS pour les charges de travail Amazon EC2
Vous créez un cluster pour définir l’infrastructure sur laquelle vos tâches et vos services s’exécutent.
Avant de commencer, veillez achever les étapes de [Configurer l'utilisation d'Amazon ECS](get-set-up-for-amazon-ecs.md) et affectez l’autorisation IAM appropriée. Pour de plus amples informations, veuillez consulter [Exemples de cluster Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies). La console Amazon ECS fournit un moyen simple de créer les ressources nécessaires à un cluster Amazon ECS en créant une CloudFormation pile.
Pour que le processus de création de cluster soit aussi simple que possible, la console dispose de sélections par défaut pour de nombreux choix que nous décrivons ci-dessous. La plupart des sections de la console comportent des volets d'aide qui fournissent un contexte supplémentaire.
Vous pouvez enregistrer des instances Amazon EC2 lors de la création du cluster ou enregistrer des instances supplémentaires avec le cluster après sa création.
Vous pouvez modifier les options par défaut suivantes :
+ Modifier les sous-réseaux sur lesquels vos instances sont lancées.
+ Modifier les groupes de sécurité utilisés pour contrôler le trafic vers les instances de conteneur.
+ Ajoutez un espace de noms au cluster.
Un espace de noms permet aux services que vous créez dans le cluster de se connecter aux autres services de l'espace de noms sans configuration supplémentaire. Pour de plus amples informations, veuillez consulter [Interconnexion des services Amazon ECS](interconnecting-services.md).
+ Activez les événements de tâche pour recevoir des EventBridge notifications en cas de modification de l'état des tâches.
+ Attribuez une AWS KMS clé à votre espace de stockage géré. Pour plus d’informations sur la création d’une clé, consultez la section [Création d’une clé KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le *Guide de l’utilisateur AWS Key Management Service *.
+ Attribuez une AWS KMS clé à votre espace de stockage éphémère Fargate. Pour plus d’informations sur la création d’une clé, consultez la section [Création d’une clé KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le *Guide de l’utilisateur AWS Key Management Service *.
+ Configurez la AWS KMS clé et la journalisation pour ECS Exec.
+ Ajoutez des balises pour vous aider à identifier vos clusters.
## Options de groupe Auto Scaling
Lorsque vous utilisez des instances Amazon EC2, vous devez spécifier un groupe Auto Scaling pour gérer l'infrastructure sur laquelle vos tâches et services s'exécutent.
Lorsque vous choisissez de créer un groupe Auto Scaling, il est automatiquement configuré pour le comportement suivant :
+ Amazon ECS gère les actions de mise à l'échelle horizontale et de montée en puissance du groupe Auto Scaling.
+ Amazon ECS empêche la résiliation des instances Amazon EC2 d'un groupe Auto Scaling contenant des tâches lors d'une action de mise à l'échelle horizontale. Pour plus d'informations, consultez [Protection des instances](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html#instance-protection) dans le *Guide de l'utilisateur AWS Auto Scaling *.
Vous configurez les propriétés de groupe Auto Scaling suivantes qui déterminent le type et le nombre d'instances à lancer pour le groupe :
+ L'AMI optimisée pour Amazon ECS.
+ Type d'instance.
+ La paire de clés SSH qui prouve votre identité lorsque vous connectez à l'instance. Pour de plus amples informations sur comment créer des clés SSH, consultez la section [Paires de clés Amazon EC2 et instances Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le *Guide de l’utilisateur Amazon EC2*.
+ Nombre minimum d'instances à lancer pour le groupe Auto Scaling.
+ Nombre maximal d'instances démarrées pour le groupe Auto Scaling.
Pour que le groupe puisse monter en puissance, le maximum doit être supérieur à 0.
Amazon ECS crée un modèle de lancement Amazon EC2 Auto Scaling et un groupe Auto Scaling en votre nom dans le cadre de la pile CloudFormation . Les valeurs que vous avez spécifiées pour l'AMI, les types d'instances et la paire de clés SSH se trouvent dans le modèle de lancement. Les modèles sont précédés du préfixe `EC2ContainerService-`, ce qui facilite leur identification. Les groupes Auto Scaling sont précédés du préfixe `-ECS-Infra-ECSAutoScalingGroup`.
Les instances lancées pour le groupe Auto Scaling utilisent le modèle de lancement.
## Options de mise en réseau
Par défaut, les instances sont lancées dans les sous-réseaux par défaut de la région. Les groupes de sécurité qui contrôlent le trafic vers vos instances de conteneur, actuellement associés aux sous-réseaux, sont utilisés. Vous pouvez modifier les sous-réseaux et les groupes de sécurité des instances.
Vous pouvez choisir un sous-réseau existant. Vous pouvez soit utiliser un groupe de sécurité existant, soit en créer un. Pour créer des tâches dans une configuration IPv6 réservée, utilisez des sous-réseaux qui incluent uniquement un bloc IPv6 CIDR.
Lorsque vous créez un groupe de sécurité, vous devez spécifier au moins une règle entrante.
Les règles entrantes déterminent le trafic qui peut atteindre vos instances de conteneur et incluent les propriétés suivantes :
+ Le protocole à autoriser
+ La gamme de ports à autoriser
+ Le trafic entrant (source)
Pour autoriser le trafic entrant provenant d'une adresse ou d'un bloc d'adresses CIDR spécifique, utilisez **Personnalisée** pour **Source** avec le CIDR autorisé.
Pour autoriser le trafic entrant en provenance de toutes les destinations, utilisez **Partout** pour **Source**. Cela ajoute automatiquement le bloc d'adresse CIDR 0.0.0.0/0 et le bloc d' IPv4 adresse CIDR : :/0. IPv6
Pour autoriser le trafic entrant depuis votre ordinateur local, utilisez **Groupe source** pour **Source**. Cette action ajoute automatiquement l'adresse IP actuelle de votre ordinateur local comme source autorisée.
**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 **Configuration de cluster**, configurez les éléments suivants :
+ Pour **Nom du cluster**, saisissez un nom unique.
Le nom peut contenir jusqu'à 255 lettres (minuscules et majuscules), des chiffres et des traits d'union.
+ (Facultatif) Pour que l’espace de noms utilisé pour Service Connect soit différent du nom du cluster, sous **Paramètres par défaut de Service Connect**, pour **Espace de noms par défaut**, sélectionnez ou saisissez un nom d’espace de noms. Pour utiliser un espace de noms partagé, choisissez ou saisissez un ARN d’espace de noms. Pour plus d’informations sur l’utilisation d’espaces de nom partagés, consultez la section [Amazon ECS Service Connect avec espaces de AWS Cloud Map noms partagés](service-connect-shared-namespaces.md).
1. Ajoutez des instances Amazon EC2 à votre cluster, développez **Infrastructure**, puis sélectionnez **Fargate et Instances autogérées**.
Ensuite, configurez le groupe Auto Scaling qui agit en tant que fournisseur de capacité :
1. Pour utiliser un groupe Auto Scaling existant, depuis **Auto Scaling group (ASG)** (Groupe Auto Scaling [ASG]), sélectionnez le groupe.
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 **Modèle d’allocation**, choisissez d’utiliser des instances **à la demande** ou des instances **Spot**.
+ Si vous choisissez d’utiliser des instances Spot, pour **Stratégie d’allocation**, sélectionnez les groupes de capacité Spot (types d’instances et zones de disponibilité) à utiliser pour les instances.
Pour la plupart des charges de travail, vous pouvez choisir **Capacité et prix optimisés**.
Pour plus d'informations, voir [Stratégies d'allocation pour les instances Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-allocation-strategy.html) dans le *Guide de l'utilisateur Amazon EC2*.
+ Pour **Instance de conteneur Amazon Machine Image (AMI)**, choisissez l’AMI optimisée pour Amazon ECS pour les instances de groupe Auto Scaling.
+ Pour **EC2 instance type** (Type d'instance EC2), choisissez le type d'instance pour vos charges de travail.
La mise à l'échelle gérée fonctionne mieux si votre groupe Auto Scaling utilise les mêmes types d'instance ou des types d'instance similaires.
+ Pour **Rôle d’instance EC2**, choisissez un rôle d’instance de conteneur existant ou créez-en un autre.
Pour de plus amples informations, veuillez consulter [Rôle IAM d'instance de conteneur Amazon ECS](instance_IAM_role.md).
+ Pour **Capacity** (Capacité), saisissez le nombre minimum et le nombre maximum d'instances à lancer dans le groupe Auto Scaling.
+ Pour **SSH key pair** (Paire de clés SSH), choisissez la paire qui prouve votre identité lorsque vous connectez à l'instance.
+ Pour permettre une image et un stockage plus grands, pour **Taille du volume EBS racine**, saisissez la valeur en Gio.
1. (Facultatif) Pour modifier le VPC et les sous-réseaux, sous **Mise en réseau pour les instances Amazon EC2**, 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 que celui par **défaut**, sous **VPC**, choisissez un **VPC** existant, puis sous **Sous-réseaux**, sélectionnez les sous-réseaux. Pour une configuration IPv6 uniquement, choisissez un VPC doté d'un bloc d'adresse CIDR et de sous-réseaux dotés uniquement IPv6 d'un bloc d'adresse CIDR. IPv6
+ Choisissez les groupes de sécurité. Sous **Groupe de sécurité**, choisissez l'une des options suivantes :
+ Pour utiliser un groupe de sécurité existant, choisissez **Utiliser un groupe de sécurité existant**, puis sélectionnez le groupe de sécurité.
+ Pour créer un groupe de sécurité, sélectionnez **Créer un nouveau groupe de sécurité**. Ensuite, choisissez **Ajouter une règle** pour chaque règle entrante.
Pour plus d'informations sur les règles entrantes, veuillez consulter [Options de mise en réseau](#networking-options).
+ Pour attribuer automatiquement des adresses IP publiques à vos instances de conteneur Amazon EC2, dans **Attribuer automatiquement l'adresse IP publique**, choisissez l'une des options suivantes :
+ **Utiliser le paramètre de sous-réseau** : attribuez une adresse IP publique aux instances lorsque le sous-réseau dans lequel les instances sont lancées est un sous-réseau public.
+ **Activer** : attribuez une adresse IP publique aux instances.
1. (Facultatif) Utilisez Container Insights, développez **Surveillance**, puis sélectionnez une des options suivantes :
+ Pour utiliser Container Insights avec observabilité améliorée comme recommandé, sélectionnez **Container Insights avec observabilité améliorée**.
+ Pour utiliser Container Insights, choisissez **Container Insights**.
1. (Facultatif) Pour activer les événements de tâches, développez les **événements de tâches**, puis activez l'**option Activer les événements de tâches**.
Lorsque vous activez les événements de tâches, Amazon ECS envoie les événements de modification de l'état des tâches à EventBridge. Cela vous permet de surveiller les modifications du cycle de vie des tâches et d'y répondre automatiquement.
1. (Facultatif) Pour utiliser ECS Exec afin de déboguer les tâches dans le cluster, développez **Configuration de la résolution des problèmes**, puis configurez les éléments suivants :
+ (Facultatif) Pour la **AWS KMS clé pour ECS Exec**, entrez l'ARN de la AWS KMS clé que vous souhaitez utiliser pour chiffrer les données de session ECS Exec.
+ (Facultatif) Pour **Journalisation ECS Exec**, choisissez la destination du journal :
+ Pour envoyer des journaux à CloudWatch Logs, choisissez **Amazon CloudWatch**.
+ Pour envoyer les journaux à Amazon S3, choisissez **Amazon S3**.
+ Pour désactiver la journalisation, choisissez **Aucune**.
1. (Facultatif)
Si vous utilisez la surveillance du temps d'exécution avec l'option manuelle et que vous souhaitez que ce cluster soit surveillé GuardDuty, choisissez **Ajouter une balise** et procédez comme suit :
+ Pour **Clé**, saisissez **guardDutyRuntimeMonitoringManaged**.
+ Pour le champ **Valeur**, saisissez **true**.
1. (Facultatif) Chiffrez les données sur le stockage géré. Sous **Chiffrement**, pour **Stockage géré**, entrez l'ARN de la AWS KMS clé que vous souhaitez utiliser pour chiffrer les données du stockage géré.
1. (Facultatif) Pour gérer les identifications de cluster, développez **Tags** (Identifications), puis effectuez l'une des opérations suivantes :
[Add a tag] Choisissez **Add tag** (Ajouter une étiquette) et procédez comme suit :
+ Pour **Key** (Clé), saisissez le nom de la clé.
+ Pour **Value** (Valeur), saisissez la valeur de clé.
[Remove a tag] Choisissez **Remove** (Supprimer) à la droite de la clé et de la valeur de l'étiquette.
1. Choisissez **Créer**.
## Étapes suivantes
Après avoir créé le cluster, vous pouvez créer des définitions de tâches pour vos applications, puis les exécuter en tant que tâches autonomes ou dans le cadre d'un service. Pour plus d’informations, consultez les ressources suivantes :
+ [Définitions de tâche Amazon ECS](task_definitions.md)
+ [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)
# Gestion automatique de la capacité Amazon ECS grâce à l’autoscaling de cluster
Amazon ECS peut gérer la mise à l'échelle des instances Amazon EC2 enregistrées sur votre cluster. C'est ce qu'on appelle l'*autoscaling du cluster* Amazon ECS. Vous activez la mise à l’échelle gérée lors de la création du fournisseur de capacité de groupe Auto Scaling Amazon ECS. Vous définissez ensuite un pourcentage cible (la `targetCapacity`) pour l’utilisation de l’instance dans ce groupe Auto Scaling. Amazon ECS crée deux CloudWatch métriques personnalisées et une politique de dimensionnement du suivi des cibles pour votre groupe Auto Scaling. Amazon ECS gère ensuite l’évolutivité horizontale en fonction des ressources que vos tâches utilisent.
Pour chaque fournisseur de capacité de groupe Auto Scaling associé à un cluster, Amazon ECS crée et gère les ressources suivantes :
+ Une CloudWatch alarme de faible valeur métrique
+ Une CloudWatch alarme à valeur métrique élevée
+ Stratégie de mise à l'échelle de suivi cible
**Note**
Amazon ECS crée la politique de mise à l'échelle de suivi cible et la joint au groupe Auto Scaling. Pour mettre à jour la stratégie de dimensionnement de suivi cible, mettez à jour les paramètres de dimensionnement géré du fournisseur de capacité au lieu de mettre à jour directement la politique de dimensionnement.
Lorsque vous désactivez le dimensionnement géré ou que vous dissociez le fournisseur de capacité d'un cluster, Amazon ECS supprime à la fois les CloudWatch métriques et les ressources de politique de dimensionnement de suivi des cibles.
Amazon ECS utilise les métriques suivantes pour déterminer les mesures à prendre :
`CapacityProviderReservation`
Le pourcentage d’instances de conteneur utilisées pour un fournisseur de capacité spécifique. Amazon ECS génère cette métrique.
Amazon ECS définit la valeur `CapacityProviderReservation` sur un nombre compris entre 0 et 100. Amazon ECS utilise la formule suivante pour représenter le ratio de capacité restant dans le groupe Auto Scaling. Amazon ECS publie ensuite la métrique sur CloudWatch. Pour plus d’informations sur le calcul de la métrique, consultez la section le billet de blog [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/).
```
CapacityProviderReservation = (number of instances needed) / (number of running instances) x 100
```
`DesiredCapacity`
Quantité de capacité pour le groupe Auto Scaling. Cette métrique n'est pas publiée sur CloudWatch.
Amazon ECS publie la `CapacityProviderReservation` métrique CloudWatch dans l'espace de `AWS/ECS/ManagedScaling` noms. La métrique `CapacityProviderReservation` entraîne l'une des actions suivantes :
**La valeur `CapacityProviderReservation` est égale à `targetCapacity`.**
Le groupe Auto Scaling n'a pas besoin d'une mise à l'échelle horizontale ou d'une montée en puissance. Le pourcentage d'utilisation cible a été atteint.
**La valeur `CapacityProviderReservation` est supérieure à `targetCapacity`.**
Un plus grand nombre de tâches utilisent un pourcentage de capacité supérieur à votre pourcentage `targetCapacity`. L'augmentation de la valeur de la `CapacityProviderReservation` métrique entraîne l'action de l' CloudWatch alarme associée. Cette alarme met à jour la valeur `DesiredCapacity` pour le groupe Auto Scaling. Le groupe Auto Scaling utilise cette valeur pour lancer des instances EC2, puis les enregistrer auprès du cluster.
Lorsque la valeur par défaut de `targetCapacity` est de 100 %, les nouvelles tâches sont à l'état `PENDING` pendant la montée en puissance, car les instances ne disposent pas de la capacité nécessaire pour exécuter les tâches. Une fois les nouvelles instances enregistrées auprès d'ECS, ces tâches commenceront sur les nouvelles instances.
**La valeur `CapacityProviderReservation` est inférieure à `targetCapacity`.**
Un plus petit nombre de tâches utilisent un pourcentage de capacité inférieur à votre pourcentage `targetCapacity`, et au moins une instance peut être résiliée. La diminution de la valeur de la `CapacityProviderReservation` métrique entraîne l'action de l' CloudWatch alarme associée. Cette alarme met à jour la valeur `DesiredCapacity` pour le groupe Auto Scaling. Le groupe Auto Scaling utilise cette valeur pour résilier des instances de conteneur EC2, puis annuler leur enregistrement dans le cluster.
Le groupe Auto Scaling suit les stratégies de résiliation du groupe pour déterminer quelles instances seront résiliées en premier lors d'événements de mise à l'échelle horizontale. De plus, cela évite les instances ayant un paramètre de protection contre la mise à l'échelle horizontale d'instance activé. L'autoscaling de cluster permet de gérer les instances dotées du paramètre de protection contre la mise à l'échelle horizontale des instances si vous activez la protection contre la résiliation gérée. Pour plus d'informations sur la protection contre la résiliation gérée, veuillez consulter [Contrôle des instances résiliées par Amazon ECS](managed-termination-protection.md). Pour plus d'informations sur la résiliation des instances par les groupes Auto Scaling, veuillez consulter [Contrôle des instances Auto Scaling à résilier lors d'une mise à l'échelle horizontale](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) dans le *Guide de l'utilisateur Amazon EC2 Auto Scaling*.
Les points suivants doivent être pris en compte lors de l'utilisation de l'autoscaling de cluster :
+ Ne modifiez pas ou ne gérez pas la capacité souhaitée pour le groupe Auto Scaling associé à un fournisseur de capacité avec d'autres stratégies de mise à l'échelle que celle gérée par Amazon ECS.
+ Lorsqu’Amazon ECS passe à zéro instance, il lance automatiquement deux instances.
+ Amazon ECS utilise le rôle IAM `AWSServiceRoleForECS` lié à un service pour obtenir les autorisations dont il a besoin pour appeler en votre AWS Auto Scaling nom. Pour de plus amples informations, veuillez consulter [Utilisation des rôles liés à un service pour Amazon ECS](using-service-linked-roles.md).
+ Lorsque vous utilisez des fournisseurs de capacité avec des groupes Auto Scaling, l'utilisateur, le groupe ou le rôle qui crée les fournisseurs de capacité a besoin de l'autorisation `autoscaling:CreateOrUpdateTags`. En effet, Amazon ECS ajoute une balise au groupe Auto Scaling lorsqu'il l'associe au fournisseur de capacité.
**Important**
Assurez-vous que les outils que vous utilisez ne suppriment pas la balise `AmazonECSManaged` du groupe Auto Scaling. Si cette balise est supprimée, Amazon ECS ne peut pas gérer la mise à l’échelle.
+ Le dimensionnement automatique du cluster ne modifie pas le **MinimumCapacity**ou **MaximumCapacity**pour le groupe. Pour que le groupe puisse être redimensionné, la valeur de **MaximumCapacity**doit être supérieure à zéro.
+ Lorsque la fonction Auto Scaling (mise à l'échelle gérée) est activée, un fournisseur de capacité ne peut être connecté qu'à un seul cluster à la fois. Si votre fournisseur de capacité a désactivé la mise à l'échelle gérée, vous pouvez l'associer à plusieurs clusters.
+ Lorsque la mise à l'échelle gérée est désactivée, le fournisseur de capacité ne bénéficie pas d'une mise à l'échelle horizontale ou d'une montée en puissance. Vous pouvez utiliser une stratégie de fournisseur de capacité pour équilibrer vos tâches entre les fournisseurs de capacité.
+ La stratégie `binpack` est la plus efficace en termes de capacité.
+ Lorsque la capacité cible est inférieure à 100 %, dans le cadre de la stratégie de placement, la stratégie `binpack` doit avoir un ordre supérieur à la stratégie `spread`. Cela empêche l’augmentation horizontale du fournisseur de capacité jusqu’à ce que chaque tâche dispose d’une instance dédiée ou que la limite soit atteinte.
## Activation de l'autoscaling de cluster
Vous pouvez activer l’autoscaling de cluster à l’aide de la console ou de l’ AWS CLI.
Lorsque vous créez un cluster qui utilise des fournisseurs de capacité EC2 à l’aide de la console, Amazon ECS crée un groupe Auto Scaling en votre nom et définit la capacité cible. Pour de plus amples informations, veuillez consulter [Création d’un cluster Amazon ECS pour les charges de travail Amazon EC2](create-ec2-cluster-console-v2.md).
Vous pouvez également créer un groupe Auto Scaling, puis l’attribuer à un cluster. Pour de plus amples informations, veuillez consulter [Mise à jour d’un fournisseur de capacité Amazon ECS](update-capacity-provider-console-v2.md).
Lorsque vous utilisez le AWS CLI, après avoir créé le cluster
1. Avant de créer le fournisseur de capacité, vous devez créer un groupe Auto Scaling. Pour plus d'informations, voir [Groupes Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) dans le *Guide de l'utilisateur Amazon EC2 Auto Scaling*.
1. Utilisez `put-cluster-capacity-providers` pour modifier le fournisseur de capacité du cluster. Pour de plus amples informations, veuillez consulter [Activation de l’autoscaling de cluster Amazon ECS](turn-on-cluster-auto-scaling.md).
# Optimisation de l’autoscaling de cluster Amazon ECS
Les clients qui exécutent Amazon ECS sur Amazon EC2 peuvent tirer parti de l’autoscaling de cluster pour gérer la mise à l’échelle des groupes Amazon EC2 Auto Scaling. Grâce à l’autoscaling de cluster, vous pouvez configurer Amazon ECS pour qu’il mette automatiquement à l’échelle votre groupe Auto Scaling, et vous concentrer uniquement sur l’exécution de vos tâches. Amazon ECS veille à ce que le groupe Auto Scaling évolue horizontalement en fonction des besoins, sans qu’aucune autre intervention ne soit requise. Les fournisseurs de capacité Amazon ECS vous permettent de gérer l’infrastructure de votre cluster en s’assurant qu’il y a suffisamment d’instances de conteneur pour répondre aux demandes de votre application. Pour savoir comment fonctionne l’autoscaling de cluster, consultez le billet de blog [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/).
La mise à l'échelle automatique du cluster repose sur une intégration CloudWatch basée sur le groupe Auto Scaling pour ajuster la capacité du cluster. Par conséquent, il a une latence inhérente associée :
+ Publier les CloudWatch statistiques,
+ Le temps nécessaire à la métrique `CapacityProviderReservation` pour violer les CloudWatch alarmes (haute et faible)
+ au temps nécessaire à la préinitialisation d’une instance Amazon EC2 récemment lancée. Vous pouvez prendre les mesures suivantes pour améliorer la réactivité de l’autoscaling de cluster et accélérer les déploiements :
## Mise à l’échelle par étapes du fournisseur de capacités
Les fournisseurs de capacité Amazon ECS grow/shrink fourniront les instances de conteneur répondant aux exigences de votre application. Le nombre minimum d’instances qu’Amazon ECS lancera est fixé à une par défaut. Cela peut allonger la durée de vos déploiements si plusieurs instances sont nécessaires pour placer vos tâches en attente. Vous pouvez augmenter la [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) via l’API Amazon ECS afin d’accroître le nombre minimum d’instances qu’Amazon ECS peut faire évoluer horizontalement à la fois. Une [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) trop faible peut limiter le nombre d’instances de conteneur pouvant être mises à l’échelle horizontale, ce qui peut ralentir vos déploiements.
**Note**
Cette configuration n'est actuellement disponible que via le [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html)ou [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) APIs.
## Durée de préinitialisation de l’instance
La période de préchauffage de l'instance est la période au bout de laquelle une instance Amazon EC2 récemment lancée peut contribuer CloudWatch aux métriques du groupe Auto Scaling. Une fois la période de préinitialisation spécifiée expirée, l’instance est prise en compte dans les mesures agrégées du groupe Auto Scaling, et l’autoscaling de cluster poursuit sa prochaine itération de calculs pour estimer le nombre d’instances requises.
La valeur par défaut [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod)est de 300 secondes, que vous pouvez configurer à une valeur inférieure via [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html)ou [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) APIs pour une mise à l'échelle plus réactive. Nous vous recommandons de définir la valeur sur une valeur supérieure à 60 secondes afin d’éviter la surallocation.
## Capacité de réserve
Si votre fournisseur de capacité ne dispose d’aucune instance de conteneur pour placer des tâches, il doit accroître (augmenter horizontalement) la capacité du cluster en lançant des instances Amazon EC2 à la volée, puis attendre leur démarrage avant de pouvoir y lancer des conteneurs. Cela peut réduire considérablement la vitesse de lancement des tâches. Vous avez deux options.
Dans ce cas, le fait de disposer d’une capacité Amazon EC2 disponible déjà lancée et prête à exécuter des tâches augmentera la vitesse de lancement effective des tâches. Vous pouvez utiliser la configuration de `Target Capacity` pour indiquer que vous souhaitez conserver de la capacité de réserve dans vos clusters. Par exemple, en définissant `Target Capacity` sur 80 %, vous indiquez que votre cluster a besoin de 20 % de capacité de réserve à tout moment. Cette capacité de réserve peut permettre le lancement immédiat de toutes les tâches autonomes, garantissant ainsi que les lancements de tâches ne sont pas ralentis. L’inconvénient de cette approche est l’augmentation potentielle des coûts liés au maintien de la capacité de réserve des clusters.
Une autre approche que vous pouvez envisager consiste à augmenter la marge de manœuvre de votre service, et non celle du fournisseur de capacité. Cela signifie qu’au lieu de réduire la configuration de `Target Capacity` pour lancer de la capacité de réserve, vous pouvez augmenter le nombre de réplicas dans votre service en modifiant la métrique de mise à l’échelle du suivi de cible ou les seuils de mise à l’échelle par étapes de l’autoscaling du service. Notez que cette approche ne sera utile que pour les charges de travail complexes, mais n’aura aucun effet lorsque vous déployez de nouveaux services et que vous passez de 0 à N tâches pour la première fois. Pour plus d’informations sur les politiques de mise à l’échelle associées, consultez les sections [Politiques de mise à l’échelle du suivi de cible](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html) ou [Politiques de mise à l’échelle par étapes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-stepscaling.html) dans le *Guide du développeur Amazon Elastic Container Service*.
# Comportement de mise à l’échelle gérée par Amazon ECS
Lorsque vous disposez de fournisseurs de capacité de groupe Auto Scaling qui utilisent la mise à l’échelle gérée, Amazon ECS estime le nombre optimal d’instances à ajouter à votre cluster et utilise cette valeur pour déterminer le nombre d’instances à demander ou à libérer.
## Comportement de montée en puissance gérée
Amazon ECS sélectionne un fournisseur de capacité pour chaque tâche en appliquant la stratégie du fournisseur de capacité définie par le service, la tâche autonome ou le cluster par défaut. Amazon ECS suit le reste de ces étapes pour un seul fournisseur de capacité.
Les tâches dépourvues de stratégie de fournisseur de capacité sont ignorées par les fournisseurs de capacité. Une tâche en attente qui n'est pas associée à une stratégie de fournisseur de capacité n'entraînera pas la montée en puissance d'un fournisseur de capacité. Les tâches ou les services ne peuvent pas définir de stratégie de fournisseur de capacité si elles définissent un type de lancement.
Le comportement de montée en puissance est décrit plus en détail ci-dessous.
+ Regroupez toutes les tâches de provisionnement pour ce fournisseur de capacité de façon à ce chaque groupe ait exactement les mêmes besoins en ressources.
+ Lorsque vous utilisez plusieurs types d'instances dans un groupe Auto Scaling, les types d'instances du groupe Auto Scaling sont triés par leurs paramètres. Ces paramètres incluent le vCPU, la mémoire, les interfaces réseau élastiques (ENIs), les ports et. GPUs Les types d'instance les plus petits et les plus grands pour chaque paramètre sont sélectionnés. Pour plus d’informations sur la façon de choisir le type d’instances, consultez la section [Instances de conteneur Amazon EC2 pour Amazon ECS](create-capacity.md).
**Important**
Si les besoins en ressources d'un groupe de tâches sont supérieurs à ceux du plus petit type d'instance du groupe Auto Scaling, ce groupe de tâches ne peut pas être exécuté avec ce fournisseur de capacité. Le fournisseur de capacité ne met pas le groupe Auto Scaling à l'échelle. Les tâches restent à l'état `PROVISIONING`.
Pour éviter que les tâches ne restent à l'état `PROVISIONING`, nous vous recommandons de créer des groupes Auto Scaling et des fournisseurs de capacité distincts pour des besoins en ressources minimales différents. Lorsque vous exécutez des tâches ou créez des services, ajoutez uniquement des fournisseurs de capacité à la stratégie de fournisseur de capacité capables d'exécuter la tâche sur le plus petit type d'instance du groupe Auto Scaling. Pour les autres paramètres, vous pouvez utiliser des contraintes de placement.
+ Pour chaque groupe de tâches, Amazon ECS calcule le nombre d'instances requises pour exécuter les tâches non placées. Ce calcul utilise une stratégie `binpack`. Cette stratégie tient compte des besoins en vCPU, mémoire, interfaces réseau Elastic (ENI), ports et GPU des tâches. Elle prend également en compte la disponibilité des ressources des instances Amazon EC2. Les valeurs des types d'instance les plus grands sont traitées comme le nombre maximal d'instances calculé. Les valeurs du plus petit type d'instance sont utilisées comme protection. Si le type d'instance le plus petit ne peut pas exécuter au moins une instance de la tâche, le calcul considère la tâche comme non compatible. Par conséquent, la tâche est exclue du calcul de montée en puissance. Lorsque toutes les tâches ne sont pas compatibles avec le plus petit type d'instance, l'autoscaling du cluster s'arrête et la valeur `CapacityProviderReservation` reste à `targetCapacity`.
+ Amazon ECS publie la `CapacityProviderReservation` métrique CloudWatch par rapport à `minimumScalingStepSize` si l'une des conditions suivantes est le cas.
+ Le nombre maximal d’instances calculé est inférieur à la taille minimale de l’étape de mise à l’échelle.
+ La plus faible des valeurs entre la `maximumScalingStepSize` et le nombre maximal d’instances calculé.
+ CloudWatch les alarmes utilisent la `CapacityProviderReservation` métrique pour les fournisseurs de capacité. Lorsque la métrique `CapacityProviderReservation` est supérieure à la valeur `targetCapacity`, les alarmes augmentent également la `DesiredCapacity` du groupe Auto Scaling. La `targetCapacity` valeur est un paramètre du fournisseur de capacité envoyé à l' CloudWatch alarme pendant la phase d'activation du dimensionnement automatique du cluster.
La `targetCapacity` par défaut est de 100 %.
+ Le groupe Auto Scaling lance des instances EC2 supplémentaires. Pour éviter la surallocation, l’autoscaling veille à ce que la capacité de l’instance EC2 récemment lancée soit stabilisée avant de lancer de nouvelles instances. La scalabilité automatique vérifie si toutes les instances existantes ont passé la `instanceWarmupPeriod` (maintenant moins l'heure de lancement de l'instance). L’augmentation horizontale est bloquée pour les instances en cours de `instanceWarmupPeriod`.
Le nombre de secondes par défaut pour qu'une instance nouvellement lancée se prépare est de 300.
Pour plus d'informations, consultez [Exploration approfondie de la mise à l'échelle automatique du cluster Amazon ECS](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/).
### Considérations relatives aux montées en puissance
Tenez compte des points suivants pour le processus de montée en puissance :
+ Bien qu'il existe plusieurs contraintes de placement, nous vous recommandons d'utiliser uniquement la contrainte de placement des tâches `distinctInstance`. Celle-ci empêche l'arrêt du processus de montée en puissance, car vous utilisez une contrainte de placement qui n'est pas compatible avec les instances échantillonnées.
+ La mise à l'échelle gérée fonctionne mieux si votre groupe Auto Scaling utilise les mêmes types d'instance ou des types d'instance similaires.
+ Lorsqu'un processus de mise à l'échelle horizontale est requis et qu'aucune instance de conteneur n'est en cours d'exécution, Amazon ECS monte toujours en puissance à deux instances dans un premier temps, puis exécute des processus de mise à l'échelle horizontale ou de montée en puissance supplémentaires. Toute montée en puissance attend la période de préparation de l'instance. Pour la mise à l'échelle horizontale, Amazon ECS attend 15 minutes après une montée en puissance avant de lancer des processus de mise à l'échelle horizontale à tout moment.
+ La deuxième étape de montée en puissance doit attendre l'expiration du délai de la `instanceWarmupPeriod`, ce qui peut affecter la limite d'échelle globale. Si vous devez réduire ce délai, assurez-vous que la `instanceWarmupPeriod` est suffisamment importante pour que l’instance EC2 ait le temps de démarrer et lancer l’agent Amazon ECS (ce qui évite d’allouer trop de ressources).
+ L'autoscaling de cluster prend en charge la configuration du lancement, les modèles de lancement et plusieurs types d'instances dans le groupe Auto Scaling du fournisseur de capacité. Vous pouvez également utiliser la sélection de type d'instance basée sur des attributs sans plusieurs types d'instances.
+ Lorsque vous utilisez un groupe Auto Scaling avec des instances à la demande et plusieurs types d'instance ou instances Spot, placez les types d'instances plus importants plus haut dans la liste des priorités et ne spécifiez pas de pondération. La spécification d'une pondération n'est pas prise en charge pour le moment. Pour plus d'informations, consultez [Groupes Auto Scaling avec types d'instance multiples](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html) dans le *Guide de l'utilisateur AWS Auto Scaling *.
+ Amazon ECS lance ensuite la `minimumScalingStepSize`, si le nombre maximal d'instances calculé est inférieur à la taille minimale de l'étape de mise à l'échelle, ou la plus faible des valeurs entre `maximumScalingStepSize` et la valeur maximale calculée du nombre d'instances.
+ Si un service Amazon ECS ou `run-task` lance une tâche et que les instances de conteneur du fournisseur de capacité ne disposent pas de ressources suffisantes pour démarrer la tâche, Amazon ECS limite le nombre de tâches ayant ce statut pour chaque cluster et empêche toute tâche de dépasser cette limite. Pour de plus amples informations, veuillez consulter [Quotas de service Amazon ECS service](service-quotas.md).
## Comportement de mise à l'échelle horizontale gérée
Amazon ECS surveille les instances de conteneur pour chaque fournisseur de capacité au sein du cluster. Lorsqu'une instance de conteneur n'exécute aucune tâche, elle est considérée comme vide et Amazon ECS démarre le processus de mise à l'échelle horizontale.
CloudWatch les alarmes scale-in nécessitent 15 points de données (15 minutes) avant que le processus de scale-in ne démarre pour le groupe Auto Scaling. Une fois que le processus de mise à l'échelle horizontale démarre jusqu'à ce qu'Amazon ECS ait besoin de réduire le nombre d'instances de conteneur enregistrées, le groupe Auto Scaling définit la `DesireCapacity` pour qu'elle soit supérieure à une instance et inférieure à 50 % par minute.
Lorsqu'Amazon ECS demande une montée en puissance (lorsque la `CapacityProviderReservation` est supérieure à 100) alors qu'un processus de mise à l'échelle horizontale est en cours, le processus de mise à l'échelle horizontale est arrêté et démarre dès le début si nécessaire.
Le comportement de mise à l'échelle horizontale est décrit plus en détail ci-dessous :
1. Amazon ECS calcule le nombre d'instances de conteneur vides. Une instance de conteneur est considérée comme vide même lorsque les tâches de démon sont exécutées.
1. Amazon ECS définit la valeur `CapacityProviderReservation` sur un nombre compris entre 0 et 100 qui utilise la formule suivante pour représenter le ratio entre la taille que doit avoir le groupe Auto Scaling par rapport à sa taille réelle, exprimé en pourcentage. Amazon ECS publie ensuite la métrique sur CloudWatch. Pour plus d'informations sur le calcul de la métrique, veuillez consulter le billet de blog [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/).
```
CapacityProviderReservation = (number of instances needed) / (number of running instances) x 100
```
1. La `CapacityProviderReservation` métrique génère une CloudWatch alarme. Cette alarme met à jour la valeur `DesiredCapacity` pour le groupe Auto Scaling. Ensuite, l'une des actions suivantes se produit :
+ Si vous n'utilisez pas la résiliation gérée par le fournisseur de capacité, le groupe Auto Scaling sélectionne les instances EC2 à l'aide de la politique de résiliation de groupe Auto Scaling et résilie les instances jusqu'à ce que le nombre d'instances EC2 atteigne la `DesiredCapacity`. L'enregistrement des instances de conteneur est ensuite annulé du cluster.
+ Si toutes les instances de conteneur utilisent la protection contre la résiliation gérée, Amazon ECS supprime la protection contre la mise à l'échelle horizontale sur les instances de conteneur qui sont vides. Le groupe Auto Scaling sera alors en mesure de résilier les instances EC2. L'enregistrement des instances de conteneur est ensuite annulé du cluster.
# Contrôle des instances résiliées par Amazon ECS
**Important**
Vous devez activer la *protection contre la mise à l'échelle horizontale d'instance* Auto Scaling sur le groupe Auto Scaling pour utiliser la fonctionnalité de protection contre la résiliation gérée de l'autoscaling de cluster.
La protection contre la résiliation gérée permet à l’autoscaling de cluster de contrôler quelles instances sont résiliées. Lorsque vous utilisez la protection contre la résiliation gérée, Amazon ECS ne résilie que les instances EC2 qui n’ont pas de tâches Amazon ECS en cours d’exécution. Les tâches exécutées par un service utilisant la stratégie de planification `DAEMON` sont ignorées et une instance peut être résiliée par le biais de l'autoscaling de cluster, même lorsque l'instance exécute ces tâches. Cela est dû au fait que toutes les instances du cluster exécutent ces tâches.
Amazon ECS active d’abord l’option de *protection d’instance contre la mise à l’échelle horizontale* pour les instances EC2 du groupe Auto Scaling. Amazon ECS place ensuite les tâches sur les instances. Lorsque toutes les tâches autres que le démon sont arrêtées sur une instance, Amazon ECS lance le processus de mise à l'échelle horizontale et désactive la protection de la mise à l'échelle horizontale pour l'instance EC2. Le groupe Auto Scaling peut ensuite résilier l'instance.
La *protection contre la mise à l'échelle horizontale d'instance* Auto Scaling contrôle quelles instances EC2 peuvent être résiliées par Auto Scaling. Les instances dont la fonction de mise à l'échelle horizontale est activée ne peuvent pas être résiliées pendant le processus de mise à l'échelle horizontale. Pour plus d'informations sur la protection contre la mise à l'échelle horizontale d'instance Auto Scaling, veuillez consulter [Utilisation de la protection contre la mise à l'échelle horizontale d'instance](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) dans le *Guide de l'utilisateur Amazon EC2 Auto Scaling*.
Vous pouvez définir le pourcentage de `targetCapacity` de manière à disposer d’une capacité de réserve. Cela permet de lancer plus rapidement les tâches futures, car le groupe Auto Scaling n’a pas besoin de lancer davantage d’instances. Amazon ECS utilise la valeur de capacité cible pour gérer la CloudWatch métrique créée par le service. Amazon ECS gère la CloudWatch métrique. Le groupe Auto Scaling est traité comme un état stable de sorte qu’aucune action de mise à l’échelle ne soit requise. Les valeurs peuvent être comprises entre 0 et 100 %. Par exemple, pour configurer Amazon ECS de manière à conserver 10 % de capacité gratuite en plus de celle utilisée par les tâches Amazon ECS, définissez la valeur de capacité cible à 90 %. Tenez compte des points suivants lors de la définition de la valeur `targetCapacity` sur un fournisseur de capacité.
+ Une valeur de `targetCapacity` inférieure à 100 % représente la quantité de capacité libre (instances Amazon EC2) devant être présente dans le cluster. La capacité libre signifie qu'il n'y a aucune tâche en cours d'exécution.
+ Les contraintes de placement telles que les zones de disponibilité, sans `binpack` supplémentaire, forcent Amazon ECS à exécuter une tâche pour chaque instance, ce qui peut ne pas être le comportement souhaité.
Vous devez activer la protection contre la mise à l'échelle horizontale d'instance Auto Scaling sur le groupe Auto Scaling pour utiliser la protection contre la résiliation gérée. Si vous n'activez pas la protection contre la mise à l'échelle horizontale, l'activation de la protection contre la résiliation gérée peut entraîner un comportement indésirable. Par exemple, certaines instances peuvent être bloquées à l'état de drainage. Pour plus d’informations, consultez [Protection contre la mise à l’échelle horizontale d’instance](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) dans le *Guide de l’utilisateur Amazon EC2 Auto Scaling*.
Lorsque vous utilisez la protection contre la résiliation auprès d'un fournisseur de capacité, n'effectuez aucune action manuelle, telle que le détachement de l'instance, sur le groupe Auto Scaling associé au fournisseur de capacité. Les actions manuelles peuvent interrompre la mise à l'échelle horizontale du fournisseur de capacité. Si vous détachez une instance du groupe Auto Scaling, vous devez également [annuler l'enregistrement de l'instance détachée](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deregister_container_instance.html) du cluster Amazon ECS.
# Mise à jour de la protection contre la résiliation gérée pour les fournisseurs de capacité Amazon ECS
Lorsque vous utilisez la protection contre la résiliation gérée, vous devez mettre à jour les paramètres des fournisseurs de capacité existants.
## 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.
1. Sur la page Cluster, choisissez l’onglet **Infrastructure**.
1. Choisissez le fournisseur de capacité.
1. Choisissez **Mettre à jour** pour modifier les paramètres du fournisseur de capacité.
1. Sous **Paramètres du groupe Auto Scaling**, activez ou désactivez la fonctionnalité **Protection contre la résiliation gérée** pour activer ou désactiver la fonctionnalité.
1. Choisissez **Mettre à jour**.
## AWS CLI
Vous pouvez mettre à jour le paramètre de protection contre la résiliation gérée d’un fournisseur de capacité à l’aide de la commande `update-capacity-provider` suivante :
Pour activer la protection contre la résiliation gérée :
```
aws ecs update-capacity-provider \
--name CapacityProviderName \
--auto-scaling-group-provider "managedScaling={status=ENABLED,targetCapacity=70,minimumScalingStepSize=1,maximumScalingStepSize=10},managedTerminationProtection=ENABLED"
```
Pour désactiver la protection contre la résiliation gérée :
```
aws ecs update-capacity-provider \
--name CapacityProviderName \
--auto-scaling-group-provider "managedScaling={status=ENABLED,targetCapacity=70,minimumScalingStepSize=1,maximumScalingStepSize=10},managedTerminationProtection=DISABLED"
```
**Note**
Les modifications peuvent prendre quelques minutes avant d’être effectives sur l’ensemble de votre cluster. Lorsque vous activez la protection contre la résiliation gérée, les instances qui exécutent déjà des tâches seront protégées contre les événements de réduction horizontale. Lorsque vous désactivez la protection contre la résiliation gérée, l’indicateur de protection sera supprimé des instances lors du prochain cycle de gestion du fournisseur de capacité ECS.
## Console pour l’exécution de tâches
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.
1. Sur la page Cluster, choisissez l’onglet **Tâches**.
1. Choisissez la tâche.
1. Sous **Configuration**, basculez la **Protection contre la résiliation gérée** pour activer ou désactiver la fonctionnalité.
1. Choisissez **Configurer la protection évolutive des tâches**.
La boîte de dialogue **Configurer la protection intégrée des tâches** s’affiche
1. Sous **Protection évolutive des tâches**, basculer sur **Activer**.
1. Pour **Expire en minutes**, saisissez le nombre de minutes avant la fin de la protection évolutive des tâches.
1. Choisissez **Update (Mettre à jour)**
# Activation de l’autoscaling de cluster Amazon ECS
Vous activez l’autoscaling de cluster de manière à ce qu’Amazon ECS gère la mise à l’échelle des instances Amazon EC2 enregistrées dans votre cluster.
Si vous souhaitez utiliser la console pour activer l’autoscaling de cluster, consultez la section [Création d’un fournisseur de capacité pour Amazon ECS](create-capacity-provider-console-v2.md).
Avant de commencer, créez un groupe Auto Scaling et un fournisseur de capacité. Pour de plus amples informations, veuillez consulter [Fournisseurs de capacité Amazon ECS pour les charges de travail EC2](asg-capacity-providers.md).
Pour activer l’autoscaling de cluster, vous associez le fournisseur de capacité au cluster, puis vous activez l’autoscaling de cluster.
1. Utilisez la commande `put-cluster-capacity-providers` pour associer un ou plusieurs fournisseurs de capacité au cluster.
Pour ajouter les fournisseurs de AWS Fargate capacité, incluez les fournisseurs de `FARGATE_SPOT` capacité `FARGATE` et les fournisseurs de capacité dans la demande. Pour plus d’informations, consultez `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` dans la *Référence des commandes de l’AWS CLI *.
```
aws ecs put-cluster-capacity-providers \
--cluster ClusterName \
--capacity-providers CapacityProviderName FARGATE FARGATE_SPOT \
--default-capacity-provider-strategy capacityProvider=CapacityProvider,weight=1
```
Pour ajouter un groupe Auto Scaling pour EC2, incluez le nom du groupe Auto Scaling dans la requête. Pour plus d’informations, consultez `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` dans la *Référence des commandes de l’AWS CLI *.
```
aws ecs put-cluster-capacity-providers \
--cluster ClusterName \
--capacity-providers CapacityProviderName \
--default-capacity-provider-strategy capacityProvider=CapacityProvider,weight=1
```
1. Utilisez la commande `describe-clusters` pour vérifier que l'association a réussi. Pour plus d’informations, consultez `[describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-clusters.html)` dans la *Référence des commandes de l’AWS CLI *.
```
aws ecs describe-clusters \
--cluster ClusterName \
--include ATTACHMENTS
```
1. Utilisez la commande `update-capacity-provider` pour activer la mise à l'échelle automatique gérée pour le fournisseur de capacité. Pour plus d’informations, consultez `[update-capacity-provider](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-capacity-provider.html)` dans la *Référence des commandes de l’AWS CLI *.
```
aws ecs update-capacity-provider \
--name CapacityProviderName \
--auto-scaling-group-provider "managedScaling={status=ENABLED}"
```
# Désactivation de l’autoscaling de cluster Amazon ECS
Vous désactivez l’autoscaling de cluster lorsque vous avez besoin d’un contrôle plus précis des instances EC2 enregistrées sur votre cluster,
Pour désactiver l’autoscaling de cluster, vous pouvez soit dissocier le fournisseur de capacité pour lequel la mise à l’échelle gérée du cluster est activée, soit mettre à jour le fournisseur de capacité afin de désactiver la mise à l’échelle gérée.
## Dissociation du fournisseur de capacité
Effectuez les étapes suivantes pour dissocier le fournisseur de capacité d'un cluster.
1. Utilisez la commande `put-cluster-capacity-providers` pour dissocier le fournisseur de capacité de groupe Auto Scaling du cluster. Le cluster peut conserver l'association avec les fournisseurs AWS Fargate de capacité. Pour plus d’informations, consultez `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` dans la *Référence des commandes de l’AWS CLI *.
```
aws ecs put-cluster-capacity-providers \
--cluster ClusterName \
--capacity-providers FARGATE FARGATE_SPOT \
--default-capacity-provider-strategy '[]'
```
Utilisez la commande `put-cluster-capacity-providers` pour dissocier le fournisseur de capacité de groupe Auto Scaling du cluster. Pour plus d’informations, consultez `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` dans la *Référence des commandes de l’AWS CLI *.
```
aws ecs put-cluster-capacity-providers \
--cluster ClusterName \
--capacity-providers [] \
--default-capacity-provider-strategy '[]'
```
1. Utilisez la commande `describe-clusters` pour vérifier que la dissociation a réussi. Pour plus d'informations, consultez la section `[describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-clusters.html)` dans la *référence des commandes AWS CLI *.
```
aws ecs describe-clusters \
--cluster ClusterName \
--include ATTACHMENTS
```
## Désactivez la mise à l'échelle gérée pour le fournisseur de capacité
Effectuez les étapes suivantes pour désactiver la mise à l'échelle gérée pour le fournisseur de capacité.
+ Utilisez la commande `update-capacity-provider` pour désactiver la mise à l'échelle automatique gérée pour le fournisseur de capacité. Pour plus d’informations, consultez `[update-capacity-provider](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-capacity-provider.html)` dans la *Référence des commandes de l’AWS CLI *.
```
aws ecs update-capacity-provider \
--name CapacityProviderName \
--auto-scaling-group-provider "managedScaling={status=DISABLED}"
```
# Création d’un fournisseur de capacité pour Amazon ECS
Une fois la création du cluster terminée, vous pouvez créer un fournisseur de capacité (groupe Auto Scaling) pour EC2. Les fournisseurs de capacité vous aident à gérer et à mettre à l’échelle votre infrastructure pour vos applications.
Avant de créer le fournisseur de capacité, vous devez créer un groupe Auto Scaling. Pour plus d'informations, voir [Groupes Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) dans le *Guide de l'utilisateur Amazon EC2 Auto Scaling*.
**Pour créer un fournisseur de capacité pour le cluster (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 **Clusters**.
1. Sur la page **Clusters**, choisissez le cluster.
1. Sur la *name* page **Cluster :**, choisissez **Infrastructure**, puis **Create**.
1. Sur la page **Create capacity provider** (Créer des fournisseurs de capacité), configurez les options suivantes.
1. Sous **Basic details** (Détails de base), pour le **Capacity provider name** (Nom du fournisseur de capacité), entrez un nom de fournisseur de capacité.
1. Sous **Auto Scaling group** (Groupe Auto Scaling), pour **Use an existing Auto Scaling group** (Utiliser un groupe Auto Scaling existant), choisissez le groupe Auto Scaling.
1. (Facultatif) Pour configurer une stratégie de dimensionnement, sous **Stratégies de dimensionnement**, configurez les options suivantes.
+ Pour qu'Amazon ECS gère les actions de mise à l'échelle horizontale et de montée en puissance, sélectionnez **Turn on managed scaling** (Activer la mise à l'échelle gérée).
+ Pour empêcher la résiliation de l'instance EC2 exécutant des tâches Amazon ECS, sélectionnez **Turn on scaling protection** (Activer la protection du dimensionnement).
+ Pour **Définir la capacité cible**, entrez la valeur cible pour la CloudWatch métrique utilisée dans la politique de dimensionnement du suivi des cibles gérée par Amazon ECS.
1. Choisissez **Créer**.
# Mise à jour d’un fournisseur de capacité Amazon ECS
Lorsque vous utilisez un groupe Auto Scaling comme fournisseur de capacité, vous pouvez modifier la stratégie de dimensionnement du groupe.
**Pour mettre à jour un fournisseur de capacité pour le cluster (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 **Clusters**.
1. Sur la page **Clusters**, choisissez le cluster.
1. Sur la *name* page **Cluster :**, choisissez **Infrastructure**, puis **Update**.
1. Sur la page **Create capacity provider** (Créer des fournisseurs de capacité), configurez les options suivantes.
1. Sous **Groupe Auto Scaling** de **Scaling policies** (Stratégies de dimensionnement), configurez les options suivantes.
+ Pour qu'Amazon ECS gère les actions de mise à l'échelle horizontale et de montée en puissance, sélectionnez **Turn on managed scaling** (Activer la mise à l'échelle gérée).
+ Pour empêcher la résiliation des instances EC2 exécutant des tâches Amazon ECS, sélectionnez **Activer la protection du dimensionnement**.
+ Pour **Définir la capacité cible**, entrez la valeur cible pour la CloudWatch métrique utilisée dans la politique de dimensionnement du suivi des cibles gérée par Amazon ECS.
1. Choisissez **Mettre à jour**.
# Suppression d’un fournisseur de capacité Amazon ECS
Si vous avez fini d'utiliser un fournisseur de capacité de groupe Auto Scaling, vous pouvez le supprimer. Une fois le groupe supprimé, le fournisseur de capacité de groupe Auto Scaling passe à l’état `INACTIVE`. Les fournisseurs de capacité ayant un état `INACTIVE` peuvent rester détectables dans votre compte pendant un certain temps. Cependant, cela est susceptible de changer à terme. Il est donc important de ne pas compter sur la persistance des fournisseurs de capacité dont l'état est `INACTIVE`. Avant que le fournisseur de capacité de groupe Auto Scaling ne soit supprimé, il doit être retiré de la stratégie de fournisseur de capacité de tous les services. Vous pouvez utiliser l'API `UpdateService` ou le flux de service de mise à jour dans la console Amazon ECS pour supprimer un fournisseur de capacité de la stratégie de fournisseur de capacité d'un service. Utilisez l’option **Forcer le nouveau déploiement** pour vous assurer que toutes les tâches utilisant la capacité d’instance Amazon EC2 fournie par le fournisseur de capacité sont basculées vers l’utilisation de la capacité des autres fournisseurs de capacité.
**Pour supprimer un fournisseur de capacité pour le cluster (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 **Clusters**.
1. Sur la page **Clusters**, choisissez le cluster.
1. Sur la *name* page **Cluster :**, choisissez **Infrastructure**, le groupe Auto Scaling, puis choisissez **Delete**.
1. Dans le champ de confirmation, saisissez **Supprimer *Auto Scaling group name***
1. Sélectionnez **Delete (Supprimer)**.
# Arrêt en toute sécurité des charges de travail Amazon ECS exécutées sur les instances EC2
Le drainage d’instance gérée facilite la résiliation progressive des instances Amazon EC2. Cela permet à vos charges de travail de s’arrêter en toute sécurité et d’être reprogrammées vers des instances qui ne sont pas en cours de résiliation. La maintenance et les mises à jour de l’infrastructure sont effectuées sans perturber les charges de travail. En utilisant le drainage d’instance gérée, vous simplifiez les flux de travail de gestion de votre infrastructure qui nécessitent le remplacement des instances Amazon EC2, tout en garantissant la résilience et la disponibilité de vos applications.
Le drainage d’instance gérée Amazon ECS fonctionne avec les remplacements d’instances de groupe Auto Scaling. Sur la base de l’actualisation des instances et de leur durée de vie maximale, les clients peuvent s’assurer qu’ils restent conformes aux dernières réglementations en matière de système d’exploitation et de sécurité en matière de capacité.
Le drainage d’instance gérée ne peut être utilisé qu’avec les fournisseurs de capacité Amazon ECS. Vous pouvez activer le drainage géré des instances lorsque vous créez ou mettez à jour les fournisseurs de capacité de votre groupe Auto Scaling à l'aide de la console Amazon ECS ou du SDK. AWS CLI
Les événements suivants sont couverts par le drainage d’instance gérée Amazon ECS.
+ [Actualisation de l’instance du groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-instance-refresh.html) : utilisez l’actualisation des instances pour effectuer le remplacement progressif de vos instances Amazon EC2 dans votre groupe Auto Scaling au lieu de le faire manuellement par lots. Cette méthode est très utile lorsque vous devez remplacer un grand nombre d’instances. Une actualisation d’instance est lancée via la console Amazon EC2 ou l’API `StartInstanceRefresh`. Assurez-vous de sélectionner `Replace` pour la protection contre la réduction horizontale lorsque vous appelez `StartInstanceRefresh` si vous utilisez une protection contre la résiliation gérée.
+ [Durée de vie maximale des instances](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-max-instance-lifetime.html) : vous pouvez définir une durée de vie maximale lorsqu’il s’agit de remplacer les instances du groupe Auto Scaling. Cette méthode est utile pour planifier le remplacement des instances en fonction des politiques de sécurité internes ou de la conformité.
+ Mise à l’échelle du groupe Auto Scaling : sur la base des politiques de mise à l’échelle et des actions de mise à l’échelle planifiées, le groupe Auto Scaling prend en charge la mise à l’échelle automatique des instances. En utilisant un groupe Auto Scaling comme fournisseur de capacité Amazon ECS, vous pouvez intégrer des instances de groupe Auto Scaling lorsqu’aucune tâche n’y est exécutée.
+ [Surveillances de l’état du groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-health-checks.html) : le groupe Auto Scaling prend en charge de nombreuses surveillances de l’état pour gérer la résiliation d’instances défectueuses.
+ [CloudFormation mises à jour de la pile](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-direct.html) ‐ Vous pouvez ajouter un `UpdatePolicy` attribut à votre CloudFormation pile pour effectuer des mises à jour continues lorsque le groupe change.
+ [Rééquilibrage de la capacité Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html) : le groupe Auto Scaling essaie de remplacer de manière proactive les instances Spot présentant un risque d’interruption plus élevé sur la base de l’évaluation du rééquilibrage de capacité Amazon EC2. Le groupe Auto Scaling résilie l’ancienne instance lorsque la solution de remplacement est lancée et saine. Le drainage d’instance gérée Amazon ECS draine l’instance Spot de la même manière qu’une instance non Spot.
+ [Interruption Spot](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-capacity-rebalancing.html) : les instances Spot sont résiliées avec un préavis de deux minutes. Le drainage d’instance gérée Amazon ECS place l’instance en état de drainage en réponse.
**Hooks de cycle de vie Amazon EC2 Auto Scaling avec drainage d’instance gérée**
Les hooks du cycle de vie du groupe Auto Scaling permettent au client de créer des solutions déclenchées par certains événements du cycle de vie de l’instance et d’effectuer une action personnalisée lorsque cet événement se produit. Un groupe Auto Scaling autorise jusqu’à 50 hooks. Plusieurs hooks de résiliation peuvent exister et être exécutés en parallèle. Le groupe Auto Scaling attend que tous les hooks soient terminés avant de résilier une instance.
En plus de la résiliation de hook gérée par Amazon ECS, vous pouvez également configurer vos propres hooks de résiliation de cycle de vie. Les hooks du cycle de vie ont une `default action`, et nous vous recommandons de le définir sur `continue` par défaut pour garantir que les autres hooks, tels que le hook géré par Amazon ECS, ne soient pas affectés par les erreurs provenant des hooks personnalisés.
Si vous avez déjà configuré un hook de fin de cycle de vie de groupe Auto Scaling et que vous avez également activé le drainage d’instance gérée Amazon ECS, les deux hooks de cycle de vie sont exécutés. Les horaires relatifs ne sont toutefois pas garantis. Les hooks du cycle de vie disposent d’un paramètre `default action` permettant de spécifier l’action à entreprendre lorsque le délai expire. En cas d’échec, nous vous recommandons d’utiliser `continue` comme résultat par défaut votre hook personnalisé. Cela garantit que les autres hooks, en particulier les hooks gérés par Amazon ECS, ne sont pas affectés par des erreurs dans votre hook de cycle de vie personnalisé. Le résultat alternatif `abandon` provoque l’ignorance de tous les autres hooks et doit être évité. Pour plus d’informations sur les hooks du cycle de vie des groupes Auto Scaling, consultez la section [Hooks du cycle de vie Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) dans le *Guide de l’utilisateur Amazon EC2 Auto Scaling*.
**Tâches et drainage d’instance gérée**
Le drainage d’instance gérée Amazon ECS utilise la fonctionnalité de drainage existante présente dans les instances de conteneur. La fonctionnalité de [drainage des instances de conteneur](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-draining.html) remplace et arrête les tâches de réplica appartenant à un service Amazon ECS. Une tâche autonome, telle qu’une tâche invoquée par `RunTask`, qui est à l’état `PENDING` ou `RUNNING` reste inchangée. Vous devez attendre qu’elles soient terminées ou qu’elles soient arrêtées manuellement. L’instance de conteneur reste dans l’état `DRAINING` jusqu’à ce que toutes les tâches soient arrêtées ou jusqu’à ce que 48 heures se soient écoulées. Les tâches du démon sont les dernières à s’arrêter après l’arrêt de toutes les tâches de réplica.
**Drainage d’instance gérée et protection contre la résiliation gérée**
Le drainage d’instance gérée fonctionne même si la résiliation gérée est désactivée. Pour plus d’informations sur la protection contre la résiliation gérée, consultez la section [Contrôle des instances résiliées par Amazon ECS](managed-termination-protection.md).
Le tableau suivant récapitule le comportement des différentes combinaisons de résiliation gérée et de drainage géré.
| Résiliation gérée | Drainage géré | Outcome |
| --- | --- | --- |
| Activé | Activé | Amazon ECS empêche les instances Amazon EC2 qui exécutent des tâches d’être résiliées par des événements de réduction horizontale. Toutes instances en cours de résiliation, telles que celles pour lesquelles la protection contre la résiliation n’est pas définie, celles qui font l’objet d’une interruption Spot ou qui sont forcées par une actualisation de l’instance, sont drainées progressivement. |
| Désactivé | Activé | Amazon ECS ne protège pas les instances Amazon EC2 exécutant des tâches contre la réduction horizontale. Cependant, toutes les instances résiliées sont drainées progressivement. |
| Activé | Désactivé | Amazon ECS empêche les instances Amazon EC2 qui exécutent des tâches d’être résiliées par des événements de réduction horizontale. Cependant, les instances peuvent toujours être résiliées en cas d’interruption Spot ou d’actualisation forcée de l’instance, ou si elles n’exécutent aucune tâche. Amazon ECS n’effectue pas de drainage progressif pour ces instances et lance des tâches de service de remplacement après leur arrêt. |
| Désactivé | Désactivé | Les instances Amazon EC2 peuvent faire l’objet d’une réduction horizontale ou être résiliées à tout moment, même si elles exécutent des tâches Amazon ECS. Amazon ECS lancera les tâches de service de remplacement après leur arrêt. |
**Drainage d’instance gérée et drainage d’instance Spot**
Avec le drainage d’instance Spot, vous pouvez définir une variable d’environnement `ECS_ENABLE_SPOT_INSTANCE_DRAINING` sur l’agent Amazon ECS permettant à Amazon ECS de placer une instance en état de drainage en réponse à une interruption Spot de deux minutes. Le drainage d’instance gérée Amazon ECS facilite l’arrêt progressif des instances Amazon EC2 en cours de résiliation pour de nombreuses raisons, et pas uniquement pour une interruption Spot. Par exemple, vous pouvez utiliser le rééquilibrage de capacité d’Amazon EC2 Auto Scaling pour remplacer de manière proactive une instance Spot en cas de risque élevé d’interruption, et le drainage d’instance gérée permet d’arrêter progressivement l’instance Spot remplacée. Lorsque vous utilisez le drainage d’instance gérée, il n’est pas nécessaire d’activer le drainage d’instance Spot séparément. Par conséquent, la spécification de `ECS_ENABLE_SPOT_INSTANCE_DRAINING` dans les données utilisateur du groupe Auto Scaling est redondant. Pour plus d’informations sur les instances Spot, consultez la section [Instances Spot](create-capacity.md#container-instance-spot).
## Comment fonctionne le drainage géré des instances avec EventBridge
Les événements de vidange des instances gérées par Amazon ECS sont publiés sur Amazon EventBridge, et Amazon ECS crée une règle EventBridge gérée dans le bus par défaut de votre compte pour prendre en charge le drainage des instances gérées. Vous pouvez filtrer ces événements vers d'autres AWS services tels que Lambda, Amazon SNS et Amazon SQS à des fins de surveillance et de résolution des problèmes.
+ Amazon EC2 Auto Scaling envoie un événement EventBridge lorsqu'un hook du cycle de vie est invoqué.
+ Les avis d'interruption ponctuelle sont publiés à EventBridge.
+ Amazon ECS génère des messages d'erreur que vous pouvez récupérer via la console Amazon ECS et APIs.
+ EventBridge comporte des mécanismes de réessai intégrés pour atténuer les défaillances temporaires.
# Configuration des fournisseurs de capacité Amazon ECS pour l’arrêt des instances en toute sécurité
Vous pouvez activer le drainage d’instance gérée lorsque vous créez ou mettez à jour les fournisseurs de capacité de votre groupe Auto Scaling à l’aide de la console et AWS CLI Amazon ECS.
**Note**
Le drainage d’instance gérée est activé par défaut lorsque vous créez un fournisseur de capacité.
Voici des exemples d'utilisation du AWS CLI pour créer un fournisseur de capacité avec le drainage d'instance géré activé et pour activer le drainage d'instance géré pour le fournisseur de capacité existant d'un cluster.
**Création d’un fournisseur de capacité avec le drainage d’instance gérée**
Pour créer un fournisseur de capacité avec le drainage d’instance gérée activé, utilisez la commande `create-capacity-provider`. Définissez le paramètre `managedDraining` sur `ENABLED`.
```
aws ecs create-capacity-provider \
--name capacity-provider \
--auto-scaling-group-provider '{
"autoScalingGroupArn": "asg-arn",
"managedScaling": {
"status": "ENABLED",
"targetCapacity": 100,
"minimumScalingStepSize": 1,
"maximumScalingStepSize": 1
},
"managedDraining": "ENABLED",
"managedTerminationProtection": "ENABLED",
}'
```
Réponse :
```
{
"capacityProvider": {
"capacityProviderArn": "capacity-provider-arn",
"name": "capacity-provider",
"status": "ACTIVE",
"autoScalingGroupProvider": {
"autoScalingGroupArn": "asg-arn",
"managedScaling": {
"status": "ENABLED",
"targetCapacity": 100,
"minimumScalingStepSize": 1,
"maximumScalingStepSize": 1
},
"managedTerminationProtection": "ENABLED"
"managedDraining": "ENABLED"
}
}
}
```
**Activation du drainage d’instance gérée pour le fournisseur de capacité existant d’un cluster**
Activez le drainage d’instance gérée pour le fournisseur de capacité existant d’un cluster à l’aide de la commande `update-capacity-provider`. Vous voyez que `managedDraining` a pour valeur actuelle `DISABLED` et que `updateStatus` a pour valeur actuelle `UPDATE_IN_PROGRESS`.
```
aws ecs update-capacity-provider \
--name cp-draining \
--auto-scaling-group-provider '{
"managedDraining": "ENABLED"
}
```
Réponse :
```
{
"capacityProvider": {
"capacityProviderArn": "cp-draining-arn",
"name": "cp-draining",
"status": "ACTIVE",
"autoScalingGroupProvider": {
"autoScalingGroupArn": "asg-draining-arn",
"managedScaling": {
"status": "ENABLED",
"targetCapacity": 100,
"minimumScalingStepSize": 1,
"maximumScalingStepSize": 1,
"instanceWarmupPeriod": 300
},
"managedTerminationProtection": "DISABLED",
"managedDraining": "DISABLED" // before update
},
"updateStatus": "UPDATE_IN_PROGRESS", // in progress and need describe again to find out the result
"tags": [
]
}
}
```
Utilisez la commande `describe-clusters` et incluez l’option `ATTACHMENTS`. Le `status` de l’attachement du drainage d’instance gérée est `PRECREATED`, et le `attachmentsStatus` global est `UPDATING`.
```
aws ecs describe-clusters --clusters cluster-name --include ATTACHMENTS
```
Réponse :
```
{
"clusters": [
{
...
"capacityProviders": [
"cp-draining"
],
"defaultCapacityProviderStrategy": [],
"attachments": [
# new precreated managed draining attachment
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"type": "managed_draining",
"status": "PRECREATED",
"details": [
{
"name": "capacityProviderName",
"value": "cp-draining"
},
{
"name": "autoScalingLifecycleHookName",
"value": "ecs-managed-draining-termination-hook"
}
]
},
...
],
"attachmentsStatus": "UPDATING"
}
],
"failures": []
}
```
Lorsque la mise à jour est terminée, utilisez `describe-capacity-providers`, et vous verrez que `managedDraining` a maintenant pour valeur `ENABLED`.
```
aws ecs describe-capacity-providers --capacity-providers cp-draining
```
Réponse :
```
{
"capacityProviders": [
{
"capacityProviderArn": "cp-draining-arn",
"name": "cp-draining",
"status": "ACTIVE",
"autoScalingGroupProvider": {
"autoScalingGroupArn": "asg-draning-arn",
"managedScaling": {
"status": "ENABLED",
"targetCapacity": 100,
"minimumScalingStepSize": 1,
"maximumScalingStepSize": 1,
"instanceWarmupPeriod": 300
},
"managedTerminationProtection": "DISABLED",
"managedDraining": "ENABLED" // successfully update
},
"updateStatus": "UPDATE_COMPLETE",
"tags": []
}
]
}
```
## Résolution des problèmes liés au drainage d’instance gérée Amazon ECS
Il se peut que vous deviez résoudre les problèmes liés au drainage d’instance gérée. Vous trouverez ci-dessous un exemple de problème et de résolution que vous pourriez rencontrer lors de son utilisation.
**Les instances ne s’arrêtent pas après avoir dépassé leur durée de vie maximale lors de l’utilisation de l’autoscaling.**
Si vos instances ne s’arrêtent pas même après avoir atteint ou dépassé la durée de vie maximale lors de l’utilisation d’un groupe Auto Scaling, c’est peut-être parce qu’elles sont protégées contre la réduction horizontale. Vous pouvez désactiver la gestion de la résiliation et autoriser le drainage géré pour gérer le recyclage des instances.
## Comportement du drainage pour les instances gérées Amazon ECS
La résiliation des instances gérées Amazon ECS garantit des transitions de charge de travail harmonieuses tout en optimisant les coûts et en préservant l'intégrité du système. Le système de résiliation offre trois voies décisionnelles distinctes pour la résiliation d’instance, chacune présentant des caractéristiques différentes en termes de délais et d’impact sur le client.
### Voies de décision en matière de résiliation
Résiliation initiée par le client
Permet de contrôler directement la suppression des instances lorsque vous devez immédiatement retirer des instances de conteneur du service. Vous appelez l' DeregisterContainerInstance API avec l'indicateur de force défini sur true, ce qui indique qu'une résiliation immédiate est requise malgré les charges de travail en cours.
Résiliation initiée par le système en cas d’inactivité
Amazon ECS Managed Instances surveille en permanence et optimise les coûts de manière proactive en mettant fin aux instances de conteneur Amazon ECS inactives qui n'exécutent aucune tâche. ECS utilise un délai heuristique pour donner aux instances de conteneur la possibilité d'acquérir des tâches nouvellement lancées avant d'être interrompues. Cela peut être personnalisé à l'aide du paramètre de configuration du fournisseur de capacité `scaleInAfter` Amazon ECS Managed Instances.
Résiliation provoquée par l’actualisation de l’infrastructure
Amazon ECS Managed Instances gère et met à jour automatiquement le logiciel sur les instances de conteneur gérées afin de garantir la sécurité et la conformité tout en préservant la disponibilité de la charge de travail. Pour plus d'informations, consultez la section relative aux [correctifs dans les instances gérées Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-instances-patching.html).
### Drainage progressif et migration de la charge de travail
Le système de drainage progressif met en œuvre une coordination sophistiquée avec la gestion des services Amazon ECS afin de garantir que les tâches gérées par les services sont correctement migrées hors des instances dont l’arrêt est prévu.
**Coordination du drainage des tâches de service**
Lorsqu’une instance passe à l’état DRAINAGE, le planificateur Amazon ECS arrête automatiquement de placer de nouvelles tâches sur l’instance tout en mettant en œuvre des procédures d’arrêt progressif pour les tâches de service existantes. Le drainage des tâches de service inclut la coordination avec les stratégies de déploiement de service, les exigences en matière de surveillance de l’état et vos préférences en matière de drainage, afin de garantir un calendrier de migration et des taux de réussite optimaux.
**Gestion autonome des tâches**
Les tâches autonomes nécessitent un traitement différent, car elles ne bénéficient pas de la gestion automatique des services. Le système évalue les caractéristiques des tâches autonomes, notamment les estimations de durée des tâches, l’analyse des probabilités d’achèvement et l’évaluation de l’impact sur le client. La stratégie d’exécution progressive permet aux tâches autonomes de s’exécuter naturellement pendant une période de grâce prolongée, tandis que la résiliation forcée garantit que l’actualisation de l’infrastructure se produit dans des délais acceptables lorsque les tâches ne se sont pas résiliées naturellement.
### Stratégie de réalisation en deux phases
Le système de résiliation met en œuvre une approche en deux phases qui équilibre la continuité de la charge de travail avec les exigences de gestion de l’infrastructure.
**Phase 1 : période d’achèvement progressif**
Au cours de cette phase, le système met en œuvre des stratégies de drainage progressif qui privilégient la continuité de la charge de travail. Les tâches de service sont progressivement drainées par le biais des processus de planification habituels d’Amazon ECS, les tâches autonomes continuent de s’exécuter et peuvent se terminer naturellement, et le système surveille que toutes les tâches atteignent l’état d’arrêt grâce à des processus d’achèvement naturels.
**Phase 2 : application stricte des délais**
Lorsque l’achèvement progressif ne permet pas d’atteindre les objectifs de résiliation dans des délais acceptables, le système met en œuvre une application stricte des délais. Le délai strict est généralement fixé à la date de début du drainage plus sept jours, ce qui laisse suffisamment de temps pour mener à bien l’opération tout en respectant les exigences opérationnelles. L’application de ce délai comprend l’invocation automatique des procédures de désinscription forcée et l’arrêt immédiat de toutes les tâches restantes, quel que soit le statut d’achèvement.
# Création de ressources pour le dimensionnement automatique du cluster Amazon ECS à l'aide du AWS Management Console
Découvrez comment créer les ressources pour l’autoscaling de cluster à l’aide de l’ AWS Management Console. Lorsque les ressources nécessitent un nom, nous utilisons le préfixe `ConsoleTutorial` afin de garantir qu’elles ont toutes un nom unique et de faciliter leur localisation.
**Topics**
+ [
## Conditions préalables
](#console-tutorial-prereqs)
+ [
## Étape 1 : Créer un cluster Amazon ECS
](#console-tutorial-cluster)
+ [
## Étape 2 : Enregistrer une définition de tâche
](#console-tutorial-register-task-definition)
+ [
## Étape 3 : Exécuter une tâche
](#console-tutorial-run-task)
+ [
## Étape 4 : Vérifier
](#console-tutorial-verify)
+ [
## Étape 5 : nettoyer
](#console-tutorial-cleanup)
## 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 IAM dispose des autorisations requises spécifiées dans l’exemple de politique IAM [Amazon ECS\$1 FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess).
+ Le rôle IAM d'instance de conteneur Amazon ECS est créé. Pour de plus amples informations, veuillez consulter [Rôle IAM d'instance de conteneur Amazon ECS](instance_IAM_role.md).
+ Le rôle IAM lié à un service Amazon ECS service est créé. Pour de plus amples informations, veuillez consulter [Utilisation des rôles liés à un service pour Amazon ECS](using-service-linked-roles.md).
+ Le rôle IAM lié à un service Auto Scaling est créé. Pour plus d'informations, consultez [Rôles liés à un service pour Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-service-linked-role.html) dans le *guide de l'utilisateur Amazon EC2 Auto Scaling*.
+ Vous avez un créé un VPC et un groupe de sécurité prêts à être utilisés. Pour de plus amples informations, veuillez consulter [Créer un Virtual Private Cloud](get-set-up-for-amazon-ecs.md#create-a-vpc).
## Étape 1 : Créer un cluster Amazon ECS
Pour créer un cluster Amazon ECS, effectuez les étapes suivantes.
Amazon ECS crée un modèle de lancement Amazon EC2 Auto Scaling et un groupe Auto Scaling en votre nom dans le cadre de CloudFormation la pile.
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, sélectionnez **Clusters**, puis **Créer un cluster**.
1. Sous **Cluster configuration** (Configuration de cluster), pour **Cluster name** (Nom du cluster), saisissez `ConsoleTutorial-cluster`.
1. **Sous **Infrastructure**, désactivez AWS Fargate (sans serveur), puis sélectionnez les instances Amazon EC2.** Ensuite, configurez le groupe Auto Scaling qui agit en tant que fournisseur de capacité.
1. Dans **Groupe Auto Scaling (ASG)**. Sélectionnez **Créer un ASG**, puis fournissez les informations suivantes sur le groupe :
+ Pour **Operating system/Architecture (Système d'exploitation/Architecture)**, choisissez **Amazon Linux 2**.
+ Pour **EC2 instance type** (Type d'instance EC2), choisissez **t3.nano**.
+ Pour **Capacity** (Capacité), saisissez le nombre minimum et le nombre maximum d'instances à lancer dans le groupe Auto Scaling.
1. (Facultatif) Pour gérer les identifications de cluster, développez **Tags** (Identifications), puis effectuez l'une des opérations suivantes :
[Add a tag] Choisissez **Add tag** (Ajouter une étiquette) et procédez comme suit :
+ Pour **Key** (Clé), saisissez le nom de la clé.
+ Pour **Value** (Valeur), saisissez la valeur de clé.
[Remove a tag] Choisissez **Remove** (Supprimer) à la droite de la clé et de la valeur de l'étiquette.
1. Choisissez **Créer**.
## Étape 2 : Enregistrer une définition de tâche
Avant de pouvoir exécuter une tâche sur votre cluster, vous devez enregistrer une définition de tâche. Les définitions de tâches sont des listes de conteneurs regroupés ensemble. L'exemple suivant est une définition de tâche simple qui utilise une image `amazonlinux` de Docker Hub et qui est simplement en veille. Pour plus d'informations sur les paramètres de définition des tâches disponibles, consultez [Définitions de tâche Amazon ECS](task_definitions.md).
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**, collez le contenu suivant.
```
{
"family": "ConsoleTutorial-taskdef",
"containerDefinitions": [
{
"name": "sleep",
"image": "public.ecr.aws/amazonlinux/amazonlinux:latest",
"memory": 20,
"essential": true,
"command": [
"sh",
"-c",
"sleep infinity"
]
}
],
"requiresCompatibilities": [
"EC2"
]
}
```
1. Choisissez **Créer**.
## Étape 3 : Exécuter une tâche
Après avoir enregistré une définition de tâche pour votre compte, vous pouvez exécuter une tâche dans le cluster. Pour ce didacticiel, vous exécutez cinq instances de la définition de tâche `ConsoleTutorial-taskdef` de votre cluster `ConsoleTutorial-cluster`.
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 **ConsoleTutorial-cluster**.
1. Dans **Tâches**, choisissez **Exécuter une nouvelle tâche**.
1. Dans la section **Environnement**, sous **Options de calcul**, choisissez **Stratégie de fournisseur de capacité**.
1. Sous **Configuration de déploiement**, pour **Type d'application**, sélectionnez **Tâche**.
1. Choisissez **ConsoleTutorial-taskdef** dans la liste déroulante **Famille**.
1. Sous **Tâches souhaitées**, saisissez 5.
1. Choisissez **Créer**.
## Étape 4 : Vérifier
À ce stade du didacticiel, vous devez avoir un cluster avec cinq tâches en cours d'exécution et un groupe Auto Scaling avec un fournisseur de capacité. La mise à l'échelle gérée Amazon ECS est activée pour le fournisseur de capacité.
Nous pouvons vérifier que tout fonctionne correctement en consultant les CloudWatch métriques, les paramètres du groupe Auto Scaling et enfin le nombre de tâches du cluster Amazon ECS.
**Pour consulter les CloudWatch statistiques de votre cluster**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans la barre de navigation, en haut de l'écran, sélectionnez la région .
1. Dans le panneau de navigation, sous **Métriques**, sélectionnez **Toutes les métriques**.
1. Sur la page **Toutes les métriques**, sous l'onglet **Parcourir**, sélectionnez `AWS/ECS/ManagedScaling`.
1. Choisissez **CapacityProviderName, ClusterName**.
1. Cochez la case correspondant au `ConsoleTutorial-cluster` ** ClusterName**.
1. Dans l'onglet **Graphique des métriques**, faites passer la valeur de **Période** à **30 secondes** et celle de **Statistique** à **Maximum**.
La valeur affichée dans le graphique indique la valeur de capacité cible pour le fournisseur de capacité. Elle doit commencer à `100`, ce qui correspond au pourcentage de capacité cible que nous avons défini. Elle doit ensuite monter à `200`, ce qui déclenche une alarme en vertu de la politique de suivi des objectifs et d'échelonnement. L'alarme déclenche alors la montée en puissance du groupe Auto Scaling.
Effectuez les étapes suivantes pour afficher les détails de votre groupe Auto Scaling et vérifier que la montée en puissance a bien eu lieu.
**Pour vérifier que le groupe Auto Scaling est monté en puissance**
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, en haut de l'écran, sélectionnez la région .
1. Dans le volet de navigation, sous **Auto Scaling**, choisissez **Auto Scaling Groups** (Groupes Auto Scaling).
1. Choisissez le groupe Auto Scaling `ConsoleTutorial-cluster` créé dans ce didacticiel. Consultez la valeur sous **Capacité souhaitée** et consultez les instances sous l'onglet **Gestion des instances** pour confirmer que votre groupe est monté en puissance de deux instances.
Effectuez les étapes suivantes pour examiner votre cluster Amazon ECS et vérifier que les instances Amazon EC2 ont bien été enregistrées auprès du cluster et que vos tâches sont passées à l'état `RUNNING`.
**Vérifier les instances dans le groupe Auto Scaling**
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 `ConsoleTutorial-cluster`.
1. Dans l'onglet **Tâches**, vérifiez qu'il y a bien cinq tâches à l'état `RUNNING`.
## Étape 5 : nettoyer
Lorsque vous avez terminé ce didacticiel, nettoyez les ressources qui lui sont associées afin d'éviter la facturation de frais pour des ressources que vous n'utilisez pas. La suppression des fournisseurs de capacité et des définitions de tâches n'est pas prise en charge, mais ces ressources n'entraînent aucun coût.
**Pour nettoyer les ressources du didacticiel**
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 **ConsoleTutorial-cluster**.
1. Sur la page **ConsoleTutorial-cluster**, choisissez l'onglet **Tâches**, puis sélectionnez **Arrêter**, **Tout arrêter**.
1. Dans le panneau de navigation, choisissez **Clusters**.
1. Sur la page **Clusters**, choisissez **ConsoleTutorial-cluster**.
1. Dans le coin supérieur droit de la page, choisissez **Supprimer le cluster**
1. Dans le champ de confirmation, entrez **delete **ConsoleTutorial-cluster**** et choisissez **Supprimer**.
1. Supprimez les groupes Auto Scaling en effectuant les étapes suivantes.
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, en haut de l'écran, sélectionnez la région .
1. Dans le volet de navigation, sous **Auto Scaling**, choisissez **Auto Scaling Groups** (Groupes Auto Scaling).
1. Sélectionnez le groupe Auto Scaling `ConsoleTutorial-cluster`, puis sélectionnez **Actions**.
1. Dans le menu **Actions**, choisissez **Delete (Supprimer)**. Saisissez **delete** dans la zone de confirmation, puis choisissez **Supprimer**.
# Instances de conteneur Amazon EC2 pour Amazon ECS
Une instance de conteneur Amazon ECS est une instance Amazon EC2 qui exécute l’agent de conteneur Amazon ECS et qui est enregistrée dans un cluster. Lorsque vous exécutez des tâches avec Amazon ECS à l’aide du fournisseur de capacité, du fournisseur de capacité externe ou d’un fournisseur de capacité de groupe Auto Scaling, vos tâches sont placées sur vos instances de conteneur actives. Vous êtes responsable de la gestion et de la maintenance des instances de conteneur.
Bien que vous puissiez créer votre propre AMI d'instance Amazon EC2 qui répond aux spécifications de base nécessaires pour exécuter vos charges de travail conteneurisées sur Amazon ECS, les AMI optimisées pour Amazon EC2 sont AMIs préconfigurées et testées sur Amazon ECS par des ingénieurs. AWS C'est la façon la plus simple de démarrer et d'exécuter rapidement vos conteneurs sur AWS .
Lorsque vous créez un cluster à l’aide de la console, Amazon ECS crée un modèle de lancement pour vos instances avec la dernière AMI associée au système d’exploitation sélectionné.
Lorsque vous créez CloudFormation un cluster, le paramètre SSM fait partie du modèle de lancement Amazon EC2 pour les instances du groupe Auto Scaling. Vous pouvez configurer le modèle pour utiliser un paramètre dynamique de Systems Manager afin de déterminer l’AMI optimisée pour Amazon ECS à déployer. Ce paramètre garantit que chaque fois que vous déployez la pile, une vérification est effectuée pour voir s’il existe une mise à jour disponible qui doit être appliquée aux instances EC2. Pour un exemple d’utilisation du paramètre Systems Manager, consultez la section [Créer un cluster Amazon ECS avec l’AMI Amazon Linux 2023 optimisée pour Amazon ECS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI) dans le *Guide de l’utilisateur AWS CloudFormation *.
+ [Extraction des métadonnées d’AMI Linux optimisée pour Amazon ECS](retrieve-ecs-optimized_AMI.md)
+ [Extraction des métadonnées de l’AMI Bottlerocket optimisée pour Amazon ECS](ecs-bottlerocket-retrieve-ami.md)
+ [Extraction des métadonnées d’AMI Windows optimisée pour Amazon ECS](retrieve-ecs-optimized_windows_AMI.md)
Vous pouvez choisir parmi les types d'instances compatibles avec votre application. Avec des instances plus grandes, vous pouvez lancer plus de tâches en même temps. Avec des instances plus petites, l’augmentation horizontale est plus fine, ce qui permet de réduire les coûts. Il n'est pas nécessaire de choisir un seul type d'instance Amazon EC2 adapté à toutes les applications de votre cluster. Au lieu de cela, vous pouvez créer plusieurs groupes Auto Scaling dans lesquels chaque groupe comporte un type d’instance différent. Vous pouvez ensuite créer un fournisseur de capacité Amazon EC2 pour chacun de ces groupes.
Utilisez les instructions suivantes pour déterminer les types de familles d’instances et le type d’instance à utiliser :
+ Éliminez les types d’instances ou les familles d’instances qui ne répondent pas aux exigences spécifiques de votre application. Par exemple, si votre application nécessite un GPU, vous pouvez exclure tous les types d'instances qui n'en ont pas.
+ Tenez compte des exigences, notamment en termes de débit réseau et de stockage.
+ Tenez compte de l’UC et de la mémoire. En règle générale, le processeur et la mémoire doivent être suffisamment volumineux pour contenir au moins une réplique de la tâche que vous souhaitez exécuter.
## Instances Spot
La capacité Spot peut permettre de réaliser d'importantes économies par rapport aux instances à la demande. La capacité Spot est une capacité excédentaire dont le prix est nettement inférieur à celui de la capacité réservée ou à la demande. Elle convient aux charges de travail de traitement par lots et de machine learning, ainsi qu'aux environnements de développement et intermédiaire. Plus généralement, elle convient à toutes les charges de travail qui tolèrent des temps d'arrêt temporaires.
Ayez conscience des conséquences suivantes, car la capacité Spot peut ne pas être disponible en permanence.
+ Pendant les périodes de très forte demande, la capacité Spot peut être indisponible. Cela peut retarder le lancement des instances Spot d'Amazon EC2. Dans ce cas, les services Amazon ECS réessayent de lancer des tâches, et les groupes Amazon EC2 Auto Scaling réessayent également de lancer des instances, jusqu'à ce que la capacité requise soit disponible. Amazon EC2 ne remplace pas la capacité Spot par une capacité à la demande.
+ Lorsque la demande globale de capacité augmente, les instances Spot et les tâches peuvent être résiliées avec un avertissement de deux minutes seulement. Une fois l'avertissement envoyé, les tâches doivent commencer à s'arrêter de manière ordonnée si nécessaire avant que l'instance ne soit complètement résiliée. Cela permet de réduire les risques d'erreurs. Pour plus d'informations sur un arrêt progressif, veuillez consulter le billet de blog [Graceful shutdowns with ECS](https://aws.amazon.com/blogs/containers/graceful-shutdowns-with-ecs/).
Pour réduire les pénuries de capacité Spot, tenez compte des recommandations suivantes :
+ Utilisez plusieurs régions et zones de disponibilité : la capacité Spot varie en fonction de la région et de la zone de disponibilité. Vous pouvez améliorer la disponibilité Spot en exécutant vos charges de travail dans plusieurs régions et zones de disponibilité. Si possible, spécifiez des sous-réseaux dans toutes les zones de disponibilité des régions dans lesquelles vous exécutez vos tâches et instances.
+ Utiliser plusieurs types d'instances Amazon EC2 : lorsque vous utilisez des stratégies d'instance mixtes avec Amazon EC2 Auto Scaling, plusieurs types d'instances sont lancés dans votre groupe Auto Scaling. Cela garantit qu'une demande de capacité Spot peut être satisfaite en cas de besoin. Pour optimiser la fiabilité et réduire la complexité, utilisez des types d'instances dotés à peu près de la même quantité de processeur et de mémoire dans votre stratégie d'instances mixtes. Ces instances peuvent provenir d'une génération différente ou de variantes du même type d'instance de base. Veuillez noter qu'elles peuvent être dotées de fonctionnalités supplémentaires dont vous n'aurez peut-être pas besoin. Une telle liste pourrait inclure, par exemple m4.large, m5.large, m5a.large, m5d.large, m5n.large, m5dn.large et m5ad.large. Pour plus d’informations, consultez [Groupes Auto Scaling avec types d’instance et options d’achat multiples](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html) dans le *Guide de l’utilisateur Amazon EC2 Auto Scaling*.
+ Utilisez la stratégie d'allocation Spot optimisée en termes de capacité : avec Amazon EC2 Spot, vous pouvez choisir entre des stratégies d'allocation optimisées en termes de capacité et de coûts. Si vous optez pour la stratégie optimisée en termes de capacités lors du lancement d'une nouvelle instance, Amazon EC2 Spot sélectionne le type d'instance le plus disponible dans la zone de disponibilité sélectionnée. Cela permet de réduire le risque que l'instance soit résiliée peu après son lancement.
Pour en savoir plus sur la configuration des avis de résiliation Spot sur vos instances de conteneur, consultez :
+ [Configuration des instances de conteneur Amazon ECS Linux pour recevoir des notifications relatives aux instances Spot](spot-instance-draining-linux-container.md)
+ [Configuration des instances de conteneur Windows Amazon ECS pour recevoir des notifications relatives aux instances Spot](windows-spot-instance-draining-container.md)
# Linux optimisé pour Amazon ECS AMIs
**Important**
[L'AMI Amazon Linux 2 optimisée pour Amazon ECS arrive end-of-life le 30 juin 2026, reflétant la même date de fin de vie que le système d'exploitation Amazon Linux 2 en amont (pour plus d'informations, consultez Amazon Linux 2). FAQs](https://aws.amazon.com/amazon-linux-2/faqs/) Nous encourageons les clients à mettre à niveau leurs applications pour utiliser Amazon Linux 2023, qui inclut un support à long terme jusqu’en 2028. Pour plus d’informations sur la migration d’Amazon Linux 2 vers Amazon Linux 2023, consultez la section [Migration de l’AMI optimisée pour Amazon Linux 2 vers l’AMI optimisée pour Amazon Linux 2023 pour Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html).
Par défaut, la date d'obsolescence de toutes les AMI optimisées pour Amazon ECS est fixée à deux ans après la date de création de l'AMI. Vous pouvez utiliser l'`DescribeImages`API Amazon EC2 pour vérifier le statut et la date de dépréciation d'une AMI. Pour plus d'informations, consultez [DescribeImages](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeImages.html)le manuel *Amazon Elastic Compute Cloud API Reference*.
Amazon ECS fournit les AMI optimisées pour Amazon ECS préconfigurées avec les exigences et les recommandations permettant d’exécuter vos charges de travail de conteneur. Nous vous recommandons d’utiliser l’AMI Amazon Linux 2023 optimisée pour Amazon ECS pour vos instances Amazon EC2. Le lancement de vos instances de conteneur à partir de l'AMI optimisée pour Amazon ECS la plus récente garantit que vous recevez la version actuelle de l'agent de conteneur ainsi que ses mises à jour de sécurité. Pour plus d'informations sur le lancement d'une instance, veuillez consulter [Lancement d'une instance de conteneur Amazon ECS Linux](launch_container_instance.md).
Lorsque vous créez un cluster à l’aide de la console, Amazon ECS crée un modèle de lancement pour vos instances avec la dernière AMI associée au système d’exploitation sélectionné.
Lorsque vous créez CloudFormation un cluster, le paramètre SSM fait partie du modèle de lancement Amazon EC2 pour les instances du groupe Auto Scaling. Vous pouvez configurer le modèle pour utiliser un paramètre dynamique de Systems Manager afin de déterminer l’AMI optimisée pour Amazon ECS à déployer. Ce paramètre garantit que chaque fois que vous déployez la pile, une vérification est effectuée pour voir s’il existe une mise à jour disponible qui doit être appliquée aux instances EC2. Pour un exemple d’utilisation du paramètre Systems Manager, consultez la section [Créer un cluster Amazon ECS avec l’AMI Amazon Linux 2023 optimisée pour Amazon ECS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI) dans le *Guide de l’utilisateur AWS CloudFormation *.
Si vous devez personnaliser l'AMI optimisée pour Amazon ECS, consultez [Amazon ECS Optimized AMI Build Recipes](https://github.com/aws/amazon-ecs-ami) sur. GitHub
Les variantes suivantes de l’AMI optimisée pour Amazon ECS sont disponibles pour vos instances Amazon EC2 équipées du système d’exploitation Amazon Linux 2023.
| Système d’exploitation | AMI | Description | Configuration du stockage |
| --- | --- | --- | --- |
| Amazon Linux 2023 | AMI Amazon Linux 2023 optimisée pour Amazon ECS | Amazon Linux 2023 est la nouvelle génération d'Amazon Linux de AWS. Recommandée dans la plupart des cas pour le lancement de vos instances Amazon EC2 pour vos charges de travail Amazon ECS. Pour plus d'informations, veuillez consulter [Qu'est-ce qu'Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/what-is-amazon-linux.html) dans le *Guide de l'utilisateur Amazon Linux 2023* (langue française non garantie). | Par défaut, l'AMI Amazon Linux 2023 optimisée pour Amazon ECS est fournie avec un volume racine unique de 30 Gio. Vous pouvez modifier la taille du volume racine de 30 Gio lors du lancement pour augmenter le stockage disponible sur votre instance de conteneur. Ce stockage est utilisé pour le système d’exploitation, ainsi que pour les métadonnées et images Docker. Le système de fichiers par défaut pour l'AMI Amazon Linux 2023 optimisée pour Amazon ECS est `xfs`, tandis que Docker utilise le pilote de stockage `overlay2`. Pour plus d'informations, consultez [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) dans la documentation Docker. |
| Amazon Linux 2023 (arm64) | AMI Amazon Linux 2023 (arm64) optimisée pour Amazon ECS | Basée sur Amazon Linux 2023, il est recommandé d'utiliser cette AMI lors du lancement de vos instances Amazon EC2, qui sont alimentées par des processeurs AWS Graviton/Graviton 2/Graviton 3/Graviton 4 basés sur ARM, pour vos charges de travail Amazon ECS. Pour plus d’informations, consultez la section [Spécifications relatives aux instances à usage général Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html) dans le *Guide des types d’instances Amazon EC2*. | Par défaut, l'AMI Amazon Linux 2023 optimisée pour Amazon ECS est fournie avec un volume racine unique de 30 Gio. Vous pouvez modifier la taille du volume racine de 30 Gio lors du lancement pour augmenter le stockage disponible sur votre instance de conteneur. Ce stockage est utilisé pour le système d’exploitation, ainsi que pour les métadonnées et images Docker. Le système de fichiers par défaut pour l'AMI Amazon Linux 2023 optimisée pour Amazon ECS est `xfs`, tandis que Docker utilise le pilote de stockage `overlay2`. Pour plus d'informations, consultez [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) dans la documentation Docker. |
| Amazon Linux 2023 (Neuron) | AMI Amazon Linux 2023 optimisée pour Amazon ECS | Basée sur Amazon Linux 2023, cette AMI est destinée aux instances Amazon EC2 Inf1, Trn1 ou Inf2. Il est préconfiguré avec les pilotes AWS Inferentia et AWS Trainium ainsi que le moteur d'exécution AWS Neuron pour Docker, qui facilite l'exécution des charges de travail d'inférence liées au machine learning sur Amazon ECS. Pour de plus amples informations, veuillez consulter [Définitions de tâches Amazon ECS pour les charges de travail d'apprentissage automatique AWS Neuron](ecs-inference.md). L’AMI Amazon Linux 2023 (Neuron) optimisée pour Amazon ECS n’est pas fournie avec une préinstallation de la AWS CLI . | Par défaut, l'AMI Amazon Linux 2023 optimisée pour Amazon ECS est fournie avec un volume racine unique de 30 Gio. Vous pouvez modifier la taille du volume racine de 30 Gio lors du lancement pour augmenter le stockage disponible sur votre instance de conteneur. Ce stockage est utilisé pour le système d’exploitation, ainsi que pour les métadonnées et images Docker. Le système de fichiers par défaut pour l'AMI Amazon Linux 2023 optimisée pour Amazon ECS est `xfs`, tandis que Docker utilise le pilote de stockage `overlay2`. Pour plus d'informations, consultez [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) dans la documentation Docker. |
| GPU Amazon Linux 2023 | AMI GPU Amazon Linux 2023 optimisée pour Amazon ECS | Basée sur Amazon Linux 2023, cette AMI est recommandée lors du lancement de vos instances basées sur GPU Amazon EC2 pour vos charges de travail Amazon ECS. Il est préconfiguré avec des pilotes de noyau NVIDIA et un environnement d'exécution GPU Docker, ce qui permet d'exécuter des charges de travail exploitables sur GPUs Amazon ECS. Pour de plus amples informations, veuillez consulter [Définitions de tâches Amazon ECS pour les charges de travail GPU](ecs-gpu.md). | Par défaut, l'AMI Amazon Linux 2023 optimisée pour Amazon ECS est fournie avec un volume racine unique de 30 Gio. Vous pouvez modifier la taille du volume racine de 30 Gio lors du lancement pour augmenter le stockage disponible sur votre instance de conteneur. Ce stockage est utilisé pour le système d’exploitation, ainsi que pour les métadonnées et images Docker. Le système de fichiers par défaut pour l'AMI Amazon Linux 2023 optimisée pour Amazon ECS est `xfs`, tandis que Docker utilise le pilote de stockage `overlay2`. Pour plus d'informations, consultez [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) dans la documentation Docker. |
Les variantes suivantes de l’AMI optimisée pour Amazon ECS sont disponibles pour vos instances Amazon EC2 équipées du système d’exploitation Amazon Linux 2.
| Système d’exploitation | AMI | Description | Configuration du stockage |
| --- | --- | --- | --- |
| **Amazon Linux 2** | AMI Amazon Linux 2 noyau 5.10 optimisée pour Amazon ECS | Basée sur Amazon Linux 2, cette AMI est à utiliser lorsque vous lancez vos instances Amazon EC2 et que vous souhaitez utiliser le noyau Linux 5.10 au lieu du noyau 4.14 pour vos charges de travail Amazon ECS. L'AMI Amazon Linux 2 noyau 5.10 optimisée pour Amazon ECS n'est pas fournie avec AWS CLI préinstallé. | Par défaut, les AMI Amazon ECS optimisées pour Amazon Linux 2 (AMI AMIs Amazon Linux 2 optimisée pour Amazon ECS, AMI Amazon Linux 2 (arm64) optimisée pour Amazon ECS et AMI optimisée pour le GPU Amazon ECS) sont livrées avec un seul volume racine de 30 Go. Vous pouvez modifier la taille du volume racine de 30 Gio lors du lancement pour augmenter le stockage disponible sur votre instance de conteneur. Ce stockage est utilisé pour le système d’exploitation, ainsi que pour les métadonnées et images Docker. Le système de fichiers par défaut pour l'AMI Amazon Linux 2 optimisée pour Amazon ECS est `xfs`, tandis que Docker utilise le pilote de stockage `overlay2`. Pour plus d'informations, consultez [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) dans la documentation Docker. |
| **Amazon Linux 2** | AMI Amazon Linux 2 optimisée pour Amazon ECS | Destinée à vos charges de travail Amazon ECS. L'AMI Amazon Linux 2 optimisée pour Amazon ECS n'est pas fournie avec la AWS CLI préinstallée. | Par défaut, les AMI Amazon ECS optimisées pour Amazon Linux 2 (AMI AMIs Amazon Linux 2 optimisée pour Amazon ECS, AMI Amazon Linux 2 (arm64) optimisée pour Amazon ECS et AMI optimisée pour le GPU Amazon ECS) sont livrées avec un seul volume racine de 30 Go. Vous pouvez modifier la taille du volume racine de 30 Gio lors du lancement pour augmenter le stockage disponible sur votre instance de conteneur. Ce stockage est utilisé pour le système d’exploitation, ainsi que pour les métadonnées et images Docker. Le système de fichiers par défaut pour l'AMI Amazon Linux 2 optimisée pour Amazon ECS est `xfs`, tandis que Docker utilise le pilote de stockage `overlay2`. Pour plus d'informations, consultez [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) dans la documentation Docker. |
| **Amazon Linux 2 (arm64)** | AMI Amazon Linux 2 noyau 5.10 (arm64) optimisée pour Amazon ECS | Basée sur Amazon Linux 2, cette AMI est destinée à vos instances Amazon EC2, qui sont alimentées par AWS Graviton/Graviton 2/Graviton 3/Graviton 4 processeurs ARM, et vous souhaitez utiliser le noyau Linux 5.10 au lieu du noyau Linux 4.14 pour vos charges de travail Amazon ECS. Pour plus d’informations, consultez la section [Spécifications relatives aux instances à usage général Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html) dans le *Guide des types d’instances Amazon EC2*. L'AMI Amazon Linux 2 (arm64) optimisée pour Amazon ECS n'est pas fournie avec le préinstallé. AWS CLI | Par défaut, les AMI Amazon ECS optimisées pour Amazon Linux 2 (AMI AMIs Amazon Linux 2 optimisée pour Amazon ECS, AMI Amazon Linux 2 (arm64) optimisée pour Amazon ECS et AMI optimisée pour le GPU Amazon ECS) sont livrées avec un seul volume racine de 30 Go. Vous pouvez modifier la taille du volume racine de 30 Gio lors du lancement pour augmenter le stockage disponible sur votre instance de conteneur. Ce stockage est utilisé pour le système d’exploitation, ainsi que pour les métadonnées et images Docker. Le système de fichiers par défaut pour l'AMI Amazon Linux 2 optimisée pour Amazon ECS est `xfs`, tandis que Docker utilise le pilote de stockage `overlay2`. Pour plus d'informations, consultez [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) dans la documentation Docker. |
| Amazon Linux 2 (arm64) | AMI Amazon Linux 2 (arm64) optimisée pour Amazon ECS | Basée sur Amazon Linux 2, cette AMI est destinée à être utilisée lors du lancement de vos instances Amazon EC2, qui sont alimentées par AWS Graviton/Graviton 2/Graviton 3/Graviton 4 processeurs ARM, pour vos charges de travail Amazon ECS. L'AMI Amazon Linux 2 (arm64) optimisée pour Amazon ECS n'est pas fournie avec le préinstallé. AWS CLI | Par défaut, les AMI Amazon ECS optimisées pour Amazon Linux 2 (AMI AMIs Amazon Linux 2 optimisée pour Amazon ECS, AMI Amazon Linux 2 (arm64) optimisée pour Amazon ECS et AMI optimisée pour le GPU Amazon ECS) sont livrées avec un seul volume racine de 30 Go. Vous pouvez modifier la taille du volume racine de 30 Gio lors du lancement pour augmenter le stockage disponible sur votre instance de conteneur. Ce stockage est utilisé pour le système d’exploitation, ainsi que pour les métadonnées et images Docker. Le système de fichiers par défaut pour l'AMI Amazon Linux 2 optimisée pour Amazon ECS est `xfs`, tandis que Docker utilise le pilote de stockage `overlay2`. Pour plus d'informations, consultez [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) dans la documentation Docker. |
| **Amazon Linux 2 (GPU)** | AMI Amazon ECS optimisée pour GPU avec noyau 5.10 | Basée sur Amazon Linux 2, cette AMI est recommandée lors du lancement de vos instances Amazon EC2 basées sur GPU avec le noyau Linux 5.10 pour vos charges de travail Amazon ECS. Il est préconfiguré avec des pilotes de noyau NVIDIA et un environnement d'exécution GPU Docker, ce qui permet d'exécuter des charges de travail exploitables sur GPUs Amazon ECS. Pour de plus amples informations, veuillez consulter [Définitions de tâches Amazon ECS pour les charges de travail GPU](ecs-gpu.md). | Par défaut, les AMI Amazon ECS optimisées pour Amazon Linux 2 (AMI AMIs Amazon Linux 2 optimisée pour Amazon ECS, AMI Amazon Linux 2 (arm64) optimisée pour Amazon ECS et AMI optimisée pour le GPU Amazon ECS) sont livrées avec un seul volume racine de 30 Go. Vous pouvez modifier la taille du volume racine de 30 Gio lors du lancement pour augmenter le stockage disponible sur votre instance de conteneur. Ce stockage est utilisé pour le système d’exploitation, ainsi que pour les métadonnées et images Docker. Le système de fichiers par défaut pour l'AMI Amazon Linux 2 optimisée pour Amazon ECS est `xfs`, tandis que Docker utilise le pilote de stockage `overlay2`. Pour plus d'informations, consultez [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) dans la documentation Docker. |
| Amazon Linux 2 (GPU) | AMI optimisée pour GPU Amazon ECS | Basée sur Amazon Linux 2, cette AMI est recommandée lors du lancement de vos instances Amazon EC2 basées sur GPU avec le noyau Linux 4.14 pour vos charges de travail Amazon ECS. Il est préconfiguré avec des pilotes de noyau NVIDIA et un environnement d'exécution GPU Docker, ce qui permet d'exécuter des charges de travail exploitables sur GPUs Amazon ECS. Pour de plus amples informations, veuillez consulter [Définitions de tâches Amazon ECS pour les charges de travail GPU](ecs-gpu.md). | Par défaut, les AMI Amazon ECS optimisées pour Amazon Linux 2 (AMI AMIs Amazon Linux 2 optimisée pour Amazon ECS, AMI Amazon Linux 2 (arm64) optimisée pour Amazon ECS et AMI optimisée pour le GPU Amazon ECS) sont livrées avec un seul volume racine de 30 Go. Vous pouvez modifier la taille du volume racine de 30 Gio lors du lancement pour augmenter le stockage disponible sur votre instance de conteneur. Ce stockage est utilisé pour le système d’exploitation, ainsi que pour les métadonnées et images Docker. Le système de fichiers par défaut pour l'AMI Amazon Linux 2 optimisée pour Amazon ECS est `xfs`, tandis que Docker utilise le pilote de stockage `overlay2`. Pour plus d'informations, consultez [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) dans la documentation Docker. |
| Amazon Linux 2 (Neuron) | AMI Amazon Linux 2 (Neuron) avec noyau 5.10 optimisée pour Amazon ECS | Basée sur Amazon Linux 2, cette AMI est destinée aux instances Inf1, Trn1 ou Inf2 d'Amazon EC2. Il est préconfiguré avec AWS Inferentia avec le noyau Linux 5.10 et les pilotes AWS Trainium, ainsi que le moteur d'exécution AWS Neuron pour Docker, qui facilite l'exécution des charges de travail d'inférence par apprentissage automatique sur Amazon ECS. Pour de plus amples informations, veuillez consulter [Définitions de tâches Amazon ECS pour les charges de travail d'apprentissage automatique AWS Neuron](ecs-inference.md). L'AMI Amazon Linux 2 (Neuron) optimisée pour Amazon ECS n'est pas fournie avec le AWS CLI préinstallé. | Par défaut, les AMI Amazon ECS optimisées pour Amazon Linux 2 (AMI AMIs Amazon Linux 2 optimisée pour Amazon ECS, AMI Amazon Linux 2 (arm64) optimisée pour Amazon ECS et AMI optimisée pour le GPU Amazon ECS) sont livrées avec un seul volume racine de 30 Go. Vous pouvez modifier la taille du volume racine de 30 Gio lors du lancement pour augmenter le stockage disponible sur votre instance de conteneur. Ce stockage est utilisé pour le système d’exploitation, ainsi que pour les métadonnées et images Docker. Le système de fichiers par défaut pour l'AMI Amazon Linux 2 optimisée pour Amazon ECS est `xfs`, tandis que Docker utilise le pilote de stockage `overlay2`. Pour plus d'informations, consultez [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) dans la documentation Docker. |
| Amazon Linux 2 (Neuron) | AMI Amazon Linux 2 (Neuron) optimisée pour Amazon ECS | Basée sur Amazon Linux 2, cette AMI est destinée aux instances Inf1, Trn1 ou Inf2 d'Amazon EC2. Il est préconfiguré avec les pilotes AWS Inferentia et AWS Trainium ainsi que le moteur d'exécution AWS Neuron pour Docker, qui facilite l'exécution des charges de travail d'inférence liées au machine learning sur Amazon ECS. Pour de plus amples informations, veuillez consulter [Définitions de tâches Amazon ECS pour les charges de travail d'apprentissage automatique AWS Neuron](ecs-inference.md). L'AMI Amazon Linux 2 (Neuron) optimisée pour Amazon ECS n'est pas fournie avec le AWS CLI préinstallé. | Par défaut, les AMI Amazon ECS optimisées pour Amazon Linux 2 (AMI AMIs Amazon Linux 2 optimisée pour Amazon ECS, AMI Amazon Linux 2 (arm64) optimisée pour Amazon ECS et AMI optimisée pour le GPU Amazon ECS) sont livrées avec un seul volume racine de 30 Go. Vous pouvez modifier la taille du volume racine de 30 Gio lors du lancement pour augmenter le stockage disponible sur votre instance de conteneur. Ce stockage est utilisé pour le système d’exploitation, ainsi que pour les métadonnées et images Docker. Le système de fichiers par défaut pour l'AMI Amazon Linux 2 optimisée pour Amazon ECS est `xfs`, tandis que Docker utilise le pilote de stockage `overlay2`. Pour plus d'informations, consultez [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) dans la documentation Docker. |
Amazon ECS fournit un journal des modifications pour la variante Linux de l'AMI optimisée pour Amazon ECS sur. GitHub Pour plus d'informations, consultez [Journal des modifications](https://github.com/aws/amazon-ecs-ami/blob/main/CHANGELOG.md).
Les variantes Linux de l'AMI optimisée pour Amazon ECS utilisent l'AMI Amazon Linux 2 ou Amazon Linux 2023 comme base. Vous pouvez récupérer le nom de l’AMI pour chaque variante en interrogeant l’API Systems Manager Parameter Store. Pour de plus amples informations, veuillez consulter [Extraction des métadonnées d’AMI Linux optimisée pour Amazon ECS](retrieve-ecs-optimized_AMI.md). Les notes de mise à jour de l'AMI Amazon Linux 2 sont également disponibles. Pour plus d'informations, consultez [Notes de mise à jour Amazon Linux 2](https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html). Les notes de mise à jour d'Amazon Linux 2023 sont également disponibles. Pour plus d'informations, veuillez consulter [Notes de mise à jour Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes.html) (langue française non garantie).
Les pages suivantes fournissent des informations supplémentaires sur les modifications :
+ Notes de [mise à jour de l'AMI source](https://github.com/aws/amazon-ecs-ami/releases) sur GitHub
+ [Notes de mise à jour Docker Engine](https://docs.docker.com/engine/release-notes/) dans la documentation Docker
+ [Documentation du pilote NVIDIA](https://docs.nvidia.com/datacenter/tesla/index.html) dans la documentation NVIDIA
+ Connectez-vous à la liste des [modifications apportées à l'agent Amazon ECS](https://github.com/aws/amazon-ecs-agent/blob/master/CHANGELOG.md) GitHub
Le code source de l'application `ecs-init`, ainsi que les scripts et la configuration nécessaires à l'empaquetage de l'agent, font désormais partie du référentiel de l'agent. Pour les anciennes versions `ecs-init` et emballages, consultez le journal des modifications [Amazon ecs-init](https://github.com/aws/amazon-ecs-init/blob/master/CHANGELOG.md) sur GitHub
## Application des mises à jour de sécurité à l’AMI optimisée pour Amazon ECS
Les versions optimisées pour Amazon ECS AMIs basées sur Amazon Linux contiennent une version personnalisée de. cloud-init Cloud-initest un package utilisé pour démarrer des images Linux dans un environnement de cloud computing et effectuer les actions souhaitées lors du lancement d'une instance. Par défaut, toutes les mises à jour de sécurité « critiques » et « importantes » sont appliquées dès le lancement de l'instance à toutes les mises à jour de sécurité optimisées pour Amazon ECS AMIs basées sur Amazon Linux publiées avant le 12 juin 2024.
À compter des versions du 12 juin 2024 de l'outil optimisé pour Amazon ECS AMIs basé sur Amazon Linux 2, le comportement par défaut n'inclura plus la mise à jour des packages au lancement. Nous vous recommandons plutôt de passer à une nouvelle AMI optimisée pour Amazon ECS au fur et à mesure que les versions seront disponibles. Les versions optimisées pour Amazon ECS AMIs sont publiées lorsque des mises à jour de sécurité ou des modifications de l'AMI de base sont disponibles. Cela garantira que vous recevez les dernières versions des packages et mises à jour de sécurité, et que les versions des packages sont immuables lors des lancements d’instances. Pour plus d’informations sur la récupération de la dernière AMI optimisée pour Amazon ECS, consultez la section [Extraction des métadonnées d’AMI Linux optimisée pour Amazon ECS](retrieve-ecs-optimized_AMI.md).
Nous vous recommandons d’automatiser votre environnement pour qu’il soit mis à jour vers une nouvelle AMI dès qu’elle sera disponible. Pour plus d’informations sur les options disponibles, consultez le billet de blog [Amazon ECS enables easier EC2 capacity management, with managed instance draining](https://aws.amazon.com/blogs/containers/amazon-ecs-enables-easier-ec2-capacity-management-with-managed-instance-draining/).
Pour continuer à appliquer manuellement les mises à jour de sécurité « critiques » et « importantes » sur une version d’AMI, vous pouvez exécuter la commande suivante sur votre instance Amazon EC2.
```
yum update --security
```
**Avertissement**
La mise à jour des packages docker ou containerd arrêtera tous les conteneurs en cours d'exécution sur l'hôte, ce qui signifie que toutes les tâches Amazon ECS en cours d'exécution seront arrêtées. Planifiez en conséquence afin de minimiser les interruptions de service.
Si vous souhaitez réactiver les mises à jour de sécurité au lancement, vous pouvez ajouter la ligne suivante à la section `#cloud-config` des données utilisateur de cloud-init lors du lancement de votre instance Amazon EC2. Pour plus d’informations, consultez la section [Utilisation de cloud-init sur Amazon Linux 2](https://docs.aws.amazon.com/linux/al2/ug/amazon-linux-cloud-init.html) dans le *Guide de l’utilisateur Amazon Linux*.
```
#cloud-config
repo_upgrade: security
```
## Packages verrouillés par version dans un GPU optimisé pour Amazon ECS AL2023 AMIs
Certains packages sont essentiels pour un comportement correct et performant des fonctionnalités du GPU dans le GPU optimisé pour Amazon ECS AL2023 . AMIs Il s’agit des licences suivantes :
+ Pilotes NVIDIA (`nvidia*`)
+ Modules du noyau (`kmod*`)
+ Bibliothèques NVIDIA (`libnvidia*`)
+ Packages de noyau (`kernel*`)
**Note**
Cette liste n'est pas exhaustive. La liste complète des packages verrouillés est disponible avec `dnf versionlock list`
La version de ces packages est verrouillée pour garantir la stabilité et empêcher les modifications involontaires susceptibles de perturber les charges de travail du GPU. Par conséquent, ces packages doivent généralement être modifiés dans les limites d'un processus géré qui gère correctement les problèmes potentiels et préserve les fonctionnalités du GPU.
Pour éviter les modifications involontaires, le `dnf versionlock` plugin est utilisé sur ces packages.
Si vous souhaitez modifier un package verrouillé, vous pouvez :
```
# unlock a single package
sudo dnf versionlock delete $PACKAGE_NAME
# unlock all packages
sudo dnf versionlock clear
```
**Important**
Lorsque des mises à jour de ces packages sont nécessaires, les clients doivent envisager d'utiliser la dernière version de l'AMI qui inclut les mises à jour requises. Si la mise à jour d'instances existantes est requise, une approche prudente impliquant le déverrouillage, la mise à jour et le reverrouillage des packages doit être utilisée, en veillant toujours à ce que les fonctionnalités du GPU soient maintenues tout au long du processus.
# Extraction des métadonnées d’AMI Linux optimisée pour Amazon ECS
Vous pouvez extraire les métadonnées d’AMI optimisée pour Amazon ECS par programmation. Les métadonnées incluent le nom de l’AMI, la version de l’agent de conteneur Amazon ECS et la version de l’exécution Amazon ECS qui inclut la version Docker.
Lorsque vous créez un cluster à l’aide de la console, Amazon ECS crée un modèle de lancement pour vos instances avec la dernière AMI associée au système d’exploitation sélectionné.
Lorsque vous créez CloudFormation un cluster, le paramètre SSM fait partie du modèle de lancement Amazon EC2 pour les instances du groupe Auto Scaling. Vous pouvez configurer le modèle pour utiliser un paramètre dynamique de Systems Manager afin de déterminer l’AMI optimisée pour Amazon ECS à déployer. Ce paramètre garantit que chaque fois que vous déployez la pile, une vérification est effectuée pour voir s’il existe une mise à jour disponible qui doit être appliquée aux instances EC2. Pour un exemple d’utilisation du paramètre Systems Manager, consultez la section [Créer un cluster Amazon ECS avec l’AMI Amazon Linux 2023 optimisée pour Amazon ECS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI) dans le *Guide de l’utilisateur AWS CloudFormation *.
L'ID de l'AMI, le nom de l'image, le système d'exploitation, la version de l'agent de conteneur, le nom de l'image source et la version d'exécution de chaque variante d'Amazon ECS-Optimized AMIs peuvent être récupérés par programmation en interrogeant l'API Systems Manager Parameter Store. Pour plus d'informations sur l'API Systems Manager Parameter Store, reportez-vous aux sections [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html)et [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html).
**Note**
Votre compte administratif doit avoir les autorisations IAM suivantes pour extraire les métadonnées d'AMI optimisée pour Amazon ECS. Ces autorisations ont été ajoutées à la politique IAM `AmazonECS_FullAccess`.
SMS : GetParameters
SMS : GetParameter
SMS : GetParametersByPath
## Format de paramètre Systems Manager Parameter Store
Les informations ci-dessous présentent le format de nom de paramètre pour chaque variante d'AMI optimisée pour Amazon ECS.
**Optimisé pour Linux Amazon ECS AMIs**
+ Métadonnées d'AMI Amazon Linux 2023 :
```
/aws/service/ecs/optimized-ami/amazon-linux-2023/
```
+ Métadonnées d'AMI Amazon Linux 2023 (arm64) :
```
/aws/service/ecs/optimized-ami/amazon-linux-2023/arm64/
```
+ Métadonnées d'AMI Amazon Linux 2023 (Neuron) :
```
/aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/
```
+ Métadonnées de l’AMI Amazon Linux 2023 (GPU) :
```
/aws/service/ecs/optimized-ami/amazon-linux-2023/gpu/
```
Métadonnées d'AMI Amazon Linux 2 :
```
/aws/service/ecs/optimized-ami/amazon-linux-2/
```
+ Métadonnées d'AMI Amazon Linux 2 noyau 5.10 :
```
/aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/
```
+ Métadonnées d'AMI Amazon Linux 2 (arm64) :
```
/aws/service/ecs/optimized-ami/amazon-linux-2/arm64/
```
+ Métadonnées d'AMI Amazon Linux 2 noyau 5.10 (arm64) :
```
/aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/arm64/
```
+ Métadonnées de l’AMI avec noyau 5.10 optimisée pour GPU Amazon ECS :
```
/aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/gpu/
```
+ Métadonnées d'AMI Amazon Linux 2 (GPU) :
```
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/
```
+ Métadonnées de l’AMI Amazon Linux 2 (Neuron) avec noyau 5.10 optimisée pour Amazon ECS :
```
/aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/inf/
```
+ Métadonnées d'AMI Amazon Linux 2 (Neuron) :
```
/aws/service/ecs/optimized-ami/amazon-linux-2/inf/
```
Le format de nom de paramètre suivant récupère l’ID d’image de la dernière AMI Amazon Linux 2 optimisée pour Amazon ECS recommandée à l’aide du sous-paramètre `image_id`.
```
/aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id
```
Le format de nom de paramètre suivant extrait les métadonnées d'une version spécifique d'AMI optimisée pour Amazon ECS en spécifiant le nom d'AMI.
+ Métadonnées d'AMI Amazon Linux 2 optimisée pour Amazon ECS :
```
/aws/service/ecs/optimized-ami/amazon-linux-2/amzn2-ami-ecs-hvm-2.0.20181112-x86_64-ebs
```
**Note**
Toutes les versions de l'AMI Amazon Linux 2 optimisée pour Amazon ECS sont disponibles pour l'extraction. Seule l'AMI optimisée pour Amazon ECS versions `amzn-ami-2017.09.l-amazon-ecs-optimized` (Linux) et versions ultérieures peuvent être extraites.
## Exemples
Les exemples suivants montrent comment vous pouvez récupérer les métadonnées de chaque variante d'AMI optimisée pour Amazon ECS.
### Extraction des métadonnées de la dernière AMI optimisée pour Amazon ECS recommandée
Vous pouvez récupérer la dernière AMI optimisée pour Amazon ECS recommandée à l' AWS CLI aide des commandes suivantes AWS CLI .
**Optimisé pour Linux Amazon ECS AMIs**
+ **Pour Amazon Linux 2023 optimisé pour Amazon ECS : AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended --region us-east-1
```
+ **Pour Amazon Linux 2023 (arm64) optimisé pour Amazon ECS : AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/arm64/recommended --region us-east-1
```
+ **Pour Amazon Linux 2023 (Neuron) optimisé pour Amazon ECS : AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/recommended --region us-east-1
```
+ **Pour le GPU Amazon Linux 2023 optimisé pour Amazon ECS : AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/gpu/recommended --region us-east-1
```
+ **Pour le noyau Amazon Linux 2 5.10 optimisé pour Amazon ECS : AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended --region us-east-1
```
+ **Pour Amazon Linux 2 optimisé pour Amazon ECS : AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended --region us-east-1
```
+ **Pour le noyau Amazon Linux 2 5.10 (arm64) optimisé pour Amazon ECS : AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/arm64/recommended --region us-east-1
```
+ **Pour Amazon Linux 2 (arm64) optimisé pour Amazon ECS : AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/arm64/recommended --region us-east-1
```
+ **Pour le noyau 5.10 optimisé pour le GPU Amazon ECS : AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/gpu/recommended --region us-east-1
```
+ **Pour l'Amazon ECS optimisé pour le GPU AMIs :**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1
```
+ **Pour le noyau Amazon Linux 2 (Neuron) AMIs 5.10 optimisé pour Amazon ECS :**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/inf/recommended --region us-east-1
```
+ **Pour Amazon Linux 2 (Neuron) AMIs optimisé pour Amazon ECS :**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/inf/recommended --region us-east-1
```
### Extraction de l'ID d'image de la dernière AMI Amazon Linux 2023 optimisée pour Amazon ECS recommandée
Vous pouvez extraire l'ID d'image de l'ID de la dernière AMI Amazon Linux 2023 optimisée pour Amazon ECS recommandée en utilisant le sous-paramètre `image_id`.
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended/image_id --region us-east-1
```
Pour extraire uniquement la valeur `image_id`, vous pouvez interroger la valeur de paramètre spécifique ; par exemple :
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended/image_id --region us-east-1 --query "Parameters[0].Value"
```
### Extraction des métadonnées d'une version spécifique d'AMI Amazon Linux 2 optimisée pour Amazon ECS
Récupérez les métadonnées d'une version spécifique de l'AMI Amazon Linux optimisée pour Amazon ECS à l' AWS CLI aide de la commande suivante AWS CLI . Remplacez le nom d'AMI par le nom d'AMI Amazon Linux optimisée pour Amazon ECS pour procéder à l'extraction.
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/amzn2-ami-ecs-hvm-2.0.20200928-x86_64-ebs --region us-east-1
```
### Récupération des métadonnées AMI du noyau Amazon Linux 2 5.10 optimisées pour Amazon ECS à l'aide de l'API Systems Manager GetParametersByPath
Récupérez les métadonnées de l'AMI Amazon Linux 2 optimisées pour Amazon ECS avec l' GetParametersByPath API Systems Manager à l'aide de la AWS CLI commande suivante.
```
aws ssm get-parameters-by-path --path /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/ --region us-east-1
```
### Extraction de l’ID d’image de la dernière AMI Amazon Linux 2 avec noyau 5.10 optimisée pour Amazon ECS recommandée
Vous pouvez extraire l’ID d’image de l’ID de la dernière AMI Amazon Linux 2 avec noyau 5.10 optimisée pour Amazon ECS recommandée en utilisant le sous-paramètre `image_id`.
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended/image_id --region us-east-1
```
Pour extraire uniquement la valeur `image_id`, vous pouvez interroger la valeur de paramètre spécifique ; par exemple :
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id --region us-east-1 --query "Parameters[0].Value"
```
### Utilisation de l'AMI optimisée pour Amazon ECS la plus récente recommandée dans un modèle CloudFormation
Vous pouvez référencer la dernière AMI optimisée pour Amazon ECS recommandée dans un modèle CloudFormation en référençant le nom du magasin de paramètres Systems Manager.
**Exemple Linux**
```
Parameters:kernel-5.10
LatestECSOptimizedAMI:
Description: AMI ID
Type: AWS::SSM::Parameter::Value
Default: /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended/image_id
```
# Migration d’Amazon Linux 2 vers une AMI optimisée pour Amazon Linux 2023 optimisée pour Amazon ECS
À la suite d'[Amazon Linux](https://aws.amazon.com/amazon-linux-2/faqs), Amazon ECS met fin au support standard pour Amazon Linux 2 optimisé pour Amazon ECS à AMIs compter du 30 juin 2026. Après cette date, la version de l'agent Amazon ECS est épinglée et les nouveaux Amazon Linux 2 optimisés pour Amazon ECS ne AMIs sont publiés que lorsque l'AMI Amazon Linux 2 source est mise à jour. La fin de vie complète (EOL) a lieu le 30 juin 2026, après quoi aucun autre Amazon Linux AMIs 2 optimisé pour Amazon ECS n'est publié, même si l'AMI source est mise à jour.
Amazon Linux 2023 propose une secure-by-default approche avec des politiques de sécurité préconfigurées, SELinux en mode permissif, le mode IMDSv2 uniquement activé par défaut, des temps de démarrage optimisés et une gestion des packages améliorée pour une sécurité et des performances accrues.
Il existe un haut degré de compatibilité entre Amazon Linux 2 et Amazon Linux 2023 optimisé pour Amazon ECS AMIs, et la plupart des clients constateront des minimal-to-zero modifications de leur charge de travail entre les deux systèmes d'exploitation.
Pour plus d'informations, consultez la section [Comparaison entre Amazon Linux 2 et *Amazon Linux 2023*](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) dans le *guide de l'utilisateur Amazon Linux 2023* et le [AL2023 FAQs](https://aws.amazon.com/linux/amazon-linux-2023/faqs).
## Considérations de compatibilité
### Gestion des packages et mises à jour du système d’exploitation
Contrairement aux versions précédentes d'Amazon Linux, Amazon Linux 2023 AMIs optimisé pour Amazon ECS est verrouillé sur une version spécifique du référentiel Amazon Linux. Cela permet aux utilisateurs de ne pas mettre à jour par inadvertance des packages susceptibles d’apporter des modifications indésirables ou irréversibles. Pour plus d’informations, consultez la section [Gestion des référentiels et des mises à jour du système d’exploitation dans Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html) du *Guide de l’utilisateur Amazon Linux 2023*.
### Versions du noyau Linux
Amazon Linux 2 est basé sur AMIs les noyaux Linux 4.14 et 5.10, tandis qu'Amazon Linux 2023 utilise les noyaux Linux 6.1 et 6.12. Pour plus d’informations, consultez la section [Comparaison des noyaux Amazon Linux 2 et Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2-kernel.html) dans le *Guide de l’utilisateur Amazon Linux 2023*.
### Modifications relatives à la disponibilité des packages
Ci-dessous figurent les modifications notables apportées aux paquets dans Amazon Linux 2023 :
+ Certains paquets binaires source d’Amazon Linux 2 ne sont plus disponibles dans Amazon Linux 2023. Pour plus d’informations, consultez la section [Packages supprimés d’Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/removed.html) dans les *Notes de mise à jour d’Amazon Linux 2023*.
+ Modifications apportées à la manière dont Amazon Linux prend en charge les différentes versions des packages. Le système `amazon-linux-extras` utilisé dans Amazon Linux 2 n’existe pas dans Amazon Linux 2023. Tous les packages sont simplement disponibles dans le référentiel « core ».
+ Les packages supplémentaires pour Enterprise Linux (EPEL) ne sont pas pris en charge dans Amazon Linux 2023. Pour plus d’informations, consultez la section [Compatibilité EPEL dans Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/epel.html) du *Guide de l’utilisateur Amazon Linux 2023*.
+ Les applications 32 bits ne sont pas prises en charge dans Amazon Linux 2023. Pour plus d’informations, consultez la section [Fonctionnalités obsolètes d’Amazon Linux 2](https://docs.aws.amazon.com/linux/al2023/ug/deprecated-al2.html#deprecated-32bit-rpms) dans le *Guide de l’utilisateur Amazon Linux 2023*.
### Modifications relatives aux groupes de contrôle (cgroups)
Un groupe de contrôle (cgroup) est une fonctionnalité du noyau Linux permettant d’organiser hiérarchiquement les processus et de répartir les ressources système entre eux. Les groupes de contrôle sont très fréquemment utilisés pour implémenter un environnement d'exécution de conteneur, et par `systemd`.
L’agent Amazon ECS, Docker et containerd prennent tous en charge à la fois cgroupv1 et cgroupv2. L’agent Amazon ECS et le moteur d’exécution du conteneur gèrent les cgroups pour vous, de sorte que les clients Amazon ECS n’ont pas besoin d’apporter de modifications pour cette mise à niveau de cgroup sous-jacente.
Pour plus de détails sur cgroupv2, consultez la section [Groupes de contrôle v2 dans Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/cgroupv2.html) dans le *Guide de l’utilisateur Amazon Linux 2023*.
### Modifications relatives au service de métadonnées d’instance (IMDS)
Amazon Linux 2023 nécessite la version 2 (IMDSv2) du service de métadonnées d'instance par défaut. IMDSv2 présente plusieurs avantages qui contribuent à améliorer la posture de sécurité. Il utilise une méthode d’authentification orientée session qui nécessite la création d’un jeton secret dans une simple requête HTTP PUT pour démarrer la session. La durée de validité du jeton de session peut avoir une valeur quelconque entre 1 seconde et 6 heures.
Pour plus d'informations sur la manière de passer de IMDSv1 à IMDSv2, consultez la section [Transition vers l'utilisation du service de métadonnées d'instance version 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) dans le guide de l'*utilisateur Amazon EC2*.
Si vous souhaitez l'utiliser IMDSv1, vous pouvez toujours le faire en remplaçant manuellement les paramètres à l'aide des propriétés de lancement de l'option de métadonnées de l'instance.
### Modifications relatives à la permutation de mémoire
La permutation de mémoire par conteneur n’est pas pris en charge sur Amazon Linux 2023 et cgroups v2. Pour de plus amples informations, veuillez consulter [Gestion de l’espace mémoire d’échange de conteneur sur Amazon ECS](container-swap.md).
### Modifications relatives à la validation FIPS
Amazon Linux 2 est certifié selon la norme FIPS 140-2 et Amazon Linux 2023 selon la norme FIPS 140-3.
Pour activer le mode FIPS sur Amazon Linux 2023, installez les packages nécessaires sur votre instance Amazon EC2 et suivez les étapes de configuration en suivant les instructions de la section [Activer le mode FIPS sur Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/fips-mode.html) dans le *Guide de l’utilisateur Amazon Linux 2023*.
### Prise en charge des instances accélérées
Amazon Linux 2023 optimisé pour Amazon ECS AMIs prend en charge les types d'instances accélérées Neuron et GPU. Pour de plus amples informations, veuillez consulter [Linux optimisé pour Amazon ECS AMIs](ecs-optimized_AMI.md).
## Construire sur mesure AMIs
Bien que nous vous recommandions de passer à la version officiellement prise en charge et publiée par AMIs Amazon ECS optimisée pour Amazon Linux 2023, vous pouvez continuer à créer des versions personnalisées d'Amazon Linux 2 optimisées pour Amazon ECS à AMIs l'aide des scripts de génération open source utilisés pour créer les variantes Linux de l'AMI optimisée pour Amazon ECS. Pour de plus amples informations, veuillez consulter [Script de création d'AMI Linux optimisées pour Amazon ECS](ecs-ami-build-scripts.md).
## Stratégies de migration
Nous vous recommandons de créer et de mettre en œuvre un plan de migration incluant des tests approfondis des applications. Les sections suivantes décrivent les différentes stratégies de migration en fonction de la façon dont vous gérez votre infrastructure Amazon ECS.
### Migration avec des fournisseurs de capacité Amazon ECS
1. Créez un fournisseur de capacité à l’aide d’un modèle de lancement. Celui-ci doit faire référence à un groupe Auto Scaling avec un modèle de lancement similaire à votre modèle existant, mais au lieu de l’AMI Amazon Linux 2 optimisée pour Amazon ECS, il doit spécifier l’une des variantes d’Amazon Linux 2023. Ajoutez ce nouveau fournisseur de capacité à votre cluster Amazon ECS existant.
1. Mettez à jour la stratégie de fournisseur de capacité par défaut de votre cluster pour inclure à la fois le fournisseur de capacité Amazon Linux 2 existant et le nouveau fournisseur de capacité Amazon Linux 2023. Commencez par un poids plus élevé chez le fournisseur Amazon Linux 2 et un poids inférieur chez le fournisseur Amazon Linux 2023 (par exemple, Amazon Linux 2 : poids de 80, Amazon Linux 2023 : poids de 20). Amazon ECS commence alors à allouer les instances Amazon Linux 2023 au fur et à mesure que de nouvelles tâches sont planifiées. Vérifiez que les instances s’enregistrent correctement et que les tâches peuvent s’exécuter correctement sur les nouvelles instances.
1. Ajustez progressivement le poids du fournisseur de capacité dans la stratégie par défaut de votre cluster, en augmentant le poids du fournisseur Amazon Linux 2023 tout en diminuant le poids du fournisseur Amazon Linux 2 au fil du temps (par exemple, 60/40, puis 40/60, puis 20/80). Vous pouvez également mettre à jour les stratégies de chaque fournisseur de capacité de service afin de prioriser les instances Amazon Linux 2023. Surveillez le placement des tâches pour vous assurer qu’elles s’exécutent correctement sur les instances Amazon Linux 2023.
1. Drainez éventuellement les instances de conteneur Amazon Linux 2 pour accélérer la migration des tâches. Si vous disposez d'une capacité de remplacement suffisante pour Amazon Linux 2023, vous pouvez vider manuellement vos instances de conteneur Amazon Linux 2 via la console Amazon ECS ou AWS CLI pour accélérer la transition de vos tâches d'Amazon Linux 2 vers Amazon Linux 2023. Une fois la migration terminée, supprimez le fournisseur de capacité Amazon Linux 2 de votre cluster et supprimez le groupe Auto Scaling associé.
### Migration à l’aide d’un groupe Amazon EC2 Auto Scaling
1. Créez un nouveau groupe Amazon EC2 Auto Scaling avec un nouveau modèle de lancement. Celui-ci doit être similaire à votre modèle de lancement existant, mais au lieu de l’AMI Amazon Linux 2 optimisée pour Amazon ECS, il doit spécifier l’une des variantes d’Amazon Linux 2023. Ce nouveau groupe Auto Scaling peut lancer des instances sur votre cluster existant.
1. Augmentez verticalement le groupe Auto Scaling afin que les instances Amazon Linux 2023 commencent à s’enregistrer dans votre cluster. Vérifiez que les instances s’enregistrent correctement et que les tâches peuvent s’exécuter correctement sur les nouvelles instances.
1. Une fois que vos tâches ont été vérifiées pour fonctionner sur Amazon Linux 2023, augmentez verticalement le groupe Auto Scaling Amazon Linux 2023 tout en réduisant verticalement de manière progressive le groupe Auto Scaling Amazon Linux 2, jusqu’à ce que vous ayez complètement remplacé toutes les instances Amazon Linux 2.
1. Si vous disposez d’une capacité de remplacement suffisante pour Amazon Linux 2023, vous souhaiterez peut-être drainer explicitement les instances de conteneur afin d’accélérer la transition de vos tâches d’Amazon Linux 2 vers Amazon Linux 2023. Pour de plus amples informations, veuillez consulter [Drainage des instances de conteneur Amazon ECS](container-instance-draining.md).
### Migration à l’aide d’instances gérées manuellement
1. Lancez manuellement (ou ajustez les scripts qui lancent) de nouvelles instances Amazon EC2 à l’aide de l’AMI Amazon Linux 2023 optimisée pour Amazon ECS au lieu d’Amazon Linux 2. Assurez-vous que ces instances utilisent les mêmes groupes de sécurité, sous-réseaux, rôles IAM et configuration de cluster que vos instances Amazon Linux 2 existantes. Les instances devraient s’enregistrer automatiquement dans votre cluster Amazon ECS existant lors du lancement.
1. Vérifiez que les nouvelles instances Amazon Linux 2023 sont correctement enregistrées dans votre cluster Amazon ECS et qu’elles sont dans l’état `ACTIVE`. Vérifiez que les tâches peuvent être planifiées et exécutées correctement sur ces nouvelles instances en attendant le placement naturel des tâches ou en déclenchant manuellement la replanification de stopping/starting certaines tâches.
1. Remplacez progressivement vos instances Amazon Linux 2 en lançant des instances Amazon Linux 2023 supplémentaires selon les besoins, puis en drainant et en arrêtant manuellement les instances Amazon Linux 2 une par une. Vous pouvez drainer les instances via la console Amazon ECS en définissant le statut de l’instance sur `DRAINING`, ce qui empêchera d’y placer de nouvelles tâches et permettra aux tâches existantes de se terminer ou d’être reprogrammées ailleurs.
# Script de création d'AMI Linux optimisées pour Amazon ECS
Amazon ECS comporte des scripts de génération open source qui sont utilisés pour créer les variantes Linux de l'AMI optimisée pour Amazon ECS. Ces scripts de compilation sont désormais disponibles sur GitHub. Pour plus d'informations, voir [amazon-ecs-ami](https://github.com/aws/amazon-ecs-ami)ci-dessous GitHub.
Si vous devez personnaliser l'AMI optimisée pour Amazon ECS, consultez [Amazon ECS Optimized AMI Build Recipies](https://github.com/aws/amazon-ecs-ami) on. GitHub
Le référentiel de scripts de génération inclut un modèle de [HashiCorppacker](https://developer.hashicorp.com/packer/docs) et des scripts de génération pour générer chacune des variantes Linux de l'AMI optimisée pour Amazon ECS. Ces scripts sont la source de vérité pour les versions d'AMI optimisées pour Amazon ECS. Vous pouvez donc suivre le GitHub référentiel pour suivre les modifications apportées à notre. AMIs Par exemple, vous pouvez souhaiter que votre propre AMI utilise la même version de Docker que celle utilisée par l'équipe Amazon ECS pour l'AMI officielle.
Pour plus d'informations, consultez le référentiel d'AMI Amazon ECS à l'adresse [aws/ amazon-ecs-ami](https://github.com/aws/amazon-ecs-ami) on GitHub.
**Créer un AMI Linux optimisée pour Amazon ECS**
1. Clonez le `aws/amazon-ecs-ami` GitHub dépôt.
```
git clone https://github.com/aws/amazon-ecs-ami.git
```
1. Ajoutez une variable d'environnement à utiliser par la AWS région lors de la création de l'AMI. Remplacez la valeur `us-west-2` avec la Région à utiliser.
```
export REGION=us-west-2
```
1. Un Makefile est fourni pour créer l'AMI. À partir du répertoire racine du référentiel cloné, utilisez l'une des commandes suivantes, correspondant à la variante Linux de l'AMI optimisée pour Amazon ECS que vous souhaitez créer.
+ AMI Amazon Linux 2 optimisée pour Amazon ECS
```
make al2
```
+ AMI Amazon Linux 2 (arm64) optimisée pour Amazon ECS
```
make al2arm
```
+ AMI optimisée pour GPU Amazon ECS
```
make al2gpu
```
+ AMI Amazon Linux 2 (Neuron) optimisée pour Amazon ECS
```
make al2inf
```
+ AMI Amazon Linux 2023 optimisée pour Amazon ECS
```
make al2023
```
+ AMI Amazon Linux 2023 (arm64) optimisée pour Amazon ECS
```
make al2023arm
```
+ AMI GPU Amazon Linux 2023 optimisée pour Amazon ECS
```
make al2023gpu
```
+ AMI Amazon Linux 2023 (Neuron) optimisée pour Amazon ECS
```
make al2023neu
```
# Optimisé pour Amazon ECS Bottlerocket AMIs
Bottlerocketest un Linux système d'exploitation open source spécialement conçu AWS pour exécuter des conteneurs sur des machines virtuelles ou des hôtes bare metal. L'AMI Bottlerocket optimisée pour Amazon ECS est sécurisée et ne comprend que le nombre minimum de packages nécessaires à l'exécution des conteneurs. Cela améliore l'utilisation des ressources, réduit la surface d'attaque de sécurité et contribue à réduire les frais de gestion. L'AMI Bottlerocket est également intégrée à Amazon ECS afin de réduire la charge opérationnelle liée à la mise à jour des instances de conteneur dans un cluster.
Bottlerocket diffère d'Amazon Linux par les aspects suivants :
+ Bottlerocket n'inclut pas de gestionnaire de packages et son logiciel ne peut être exécuté que sous forme de conteneurs. Les mises à jour de Bottlerocket sont appliquées et peuvent être annulées en une seule étape, ce qui réduit le risque d'erreurs de mise à jour.
+ Le principal mécanisme de gestion des hôtes Bottlerocket est un planificateur de conteneurs. Contrairement à Amazon Linux, la connexion à des instances Bottlerocket individuelles est censée être une opération peu fréquente uniquement à des fins avancées de débogage et de dépannage.
Pour plus d'informations sur Bottlerocket, consultez la [documentation](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md) et les [versions](https://github.com/bottlerocket-os/bottlerocket/releases) sur GitHub.
Il existe des variantes de l’AMI Bottlerocket optimisée pour Amazon ECS pour le noyau 6.1 et le noyau 5.10.
Les variantes suivantes utilisent le noyau 6.1 :
+ `aws-ecs-2`
+ `aws-ecs-2-nvidia`
Les variantes suivantes utilisent le noyau 5.10 :
+ `aws-ecs-1`
+ `aws-ecs-1-nvidia`
Pour plus d'informations sur la variante `aws-ecs-1-nvidia`, veuillez consulter le billet de blog [Announcing NVIDIA GPU support for Bottlerocket on Amazon ECS](https://aws.amazon.com/blogs/containers/announcing-nvidia-gpu-support-for-bottlerocket-on-amazon-ecs/).
## Considérations
Tenez compte des informations suivantes lors de l'utilisation d'une AMI Bottlerocket avec Amazon ECS.
+ Bottlerocket prend en charge les instances Amazon EC2 avec processeurs `x86_64` et `arm64`. Il n'est pas recommandé d'utiliser une AMI Bottlerocket avec les instances Amazon EC2 dotées d'une puce Inferentia.
+ Les images Bottlerocket n'incluent pas un serveur SSH ou un shell. Cependant, vous pouvez utiliser out-of-band des outils de gestion pour obtenir un accès administrateur SSH et effectuer un amorçage.
Pour plus d'informations, consultez ces sections dans le [README.md de bottlerocket](https://github.com/bottlerocket-os/bottlerocket) sur GitHub :
+ [Exploration](https://github.com/bottlerocket-os/bottlerocket#exploration)
+ [Conteneur d'administration](https://github.com/bottlerocket-os/bottlerocket#admin-container)
+ Par défaut, Bottlerocket possède un [conteneur de contrôle](https://github.com/bottlerocket-os/bottlerocket-control-container) qui est activé. Ce conteneur exécute l'[agent AWS Systems Manager](https://github.com/aws/amazon-ssm-agent) que vous pouvez utiliser pour exécuter des commandes ou démarrer des sessions shell sur les instances Bottlerocket d'Amazon EC2. Pour plus d'informations, consultez [Configuration du gestionnaire de session](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html) dans le *Guide de l'utilisateur AWS Systems Manager *.
+ Bottlerocket est optimisé pour les applications de conteneurs et met l'accent sur la sécurité. Bottlerocket n'inclut pas de gestionnaire de package et est inaltérable.
Pour plus d'informations sur les fonctionnalités de sécurité et les conseils de [sécurité, voir Fonctionnalités de](https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_FEATURES.md) [sécurité et conseils de sécurité](https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_GUIDANCE.md) sur GitHub.
+ Le mode réseau `awsvpc` est pris en charge pour la version d'AMI Bottlerocket `1.1.0` ou version ultérieure.
+ App Mesh dans une définition de tâche est pris en charge pour la version d'AMI Bottlerocket `1.15.0` ou ultérieure.
+ Le paramètre de définition de tâche `initProcessEnabled` est pris en charge pour la version `1.19.0` ou ultérieure de l’AMI Bottlerocket.
+ Ils ne prennent pas Bottlerocket AMIs non plus en charge les services et fonctionnalités suivants :
+ ECS Anywhere
+ Service Connect
+ Amazon EFS en mode chiffré
+ Amazon EFS en mode réseau `awsvpc`
+ Les volumes Amazon EBS ne peuvent pas être montés
+ Accélérateur Elastic Inference
# Extraction des métadonnées de l’AMI Bottlerocket optimisée pour Amazon ECS
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.
## Variante de l’AMI Bottlerocket `aws-ecs-2`
Vous pouvez récupérer la dernière variante stable de l'AMI `aws-ecs-2` Bottlerocket Région AWS par architecture avec AWS CLI le ou le. AWS Management Console
+ **AWS CLI**— Vous pouvez récupérer l'ID d'image de la dernière Bottlerocket AMI optimisée pour Amazon ECS recommandée à l'aide de la AWS CLI commande suivante en utilisant le sous-paramètre. `image_id` Remplacez la `region` par le code de région pour lequel vous souhaitez obtenir l'ID AMI.
Pour plus d'informations sur les options prises en charge Régions AWS, consultez [la section Trouver une AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) sur GitHub. Pour récupérer une autre version que la dernière, remplacez `latest` par le numéro de version.
+ Pour l'architecture 64 bits (`x86_64`) :
```
aws ssm get-parameter --region us-east-2 --name "/aws/service/bottlerocket/aws-ecs-2/x86_64/latest/image_id" --query Parameter.Value --output text
```
+ Pour l'architecture Arm 64 bits (`arm64`) :
```
aws ssm get-parameter --region us-east-2 --name "/aws/service/bottlerocket/aws-ecs-2/arm64/latest/image_id" --query Parameter.Value --output text
```
+ **AWS Management Console** : vous pouvez interroger l'ID d'AMI optimisée pour Amazon ECS recommandée à l'aide d'une URL dans l' AWS Management Console. L'URL ouvre la console Amazon EC2 Systems Manager avec la valeur de l'ID du paramètre. Dans l'URL suivante, remplacez `region` par le code de région pour lequel vous souhaitez obtenir l'ID AMI.
Pour plus d'informations sur les options prises en charge Régions AWS, consultez [la section Trouver une AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) sur GitHub.
+ Pour l'architecture 64 bits (`x86_64`) :
```
https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2/x86_64/latest/image_id/description?region=region#
```
+ Pour l'architecture Arm 64 bits (`arm64`) :
```
https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2/arm64/latest/image_id/description?region=region#
```
## Variante de l’AMI Bottlerocket `aws-ecs-2-nvidia`
Vous pouvez récupérer la dernière variante stable de l'AMI `aws-ecs-2-nvdia` Bottlerocket par région et architecture avec AWS CLI le ou le. AWS Management Console
+ **AWS CLI**— Vous pouvez récupérer l'ID d'image de la dernière Bottlerocket AMI optimisée pour Amazon ECS recommandée à l'aide de la AWS CLI commande suivante en utilisant le sous-paramètre. `image_id` Remplacez la `region` par le code de région pour lequel vous souhaitez obtenir l'ID AMI.
Pour plus d'informations sur les options prises en charge Régions AWS, consultez [la section Trouver une AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) sur GitHub. Pour récupérer une autre version que la dernière, remplacez `latest` par le numéro de version.
+ Pour l'architecture 64 bits (`x86_64`) :
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-2-nvidia/x86_64/latest/image_id" --query Parameter.Value --output text
```
+ Pour l'architecture Arm 64 bits (`arm64`) :
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-2-nvidia/arm64/latest/image_id" --query Parameter.Value --output text
```
+ **AWS Management Console** : vous pouvez interroger l'ID d'AMI optimisée pour Amazon ECS recommandée à l'aide d'une URL dans l' AWS Management Console. L'URL ouvre la console Amazon EC2 Systems Manager avec la valeur de l'ID du paramètre. Dans l'URL suivante, remplacez `region` par le code de région pour lequel vous souhaitez obtenir l'ID AMI.
Pour plus d'informations sur les options prises en charge Régions AWS, consultez [la section Trouver une AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) sur GitHub.
+ Pour l'architecture 64 bits (`x86_64`) :
```
https://regionconsole.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2-nvidia/x86_64/latest/image_id/description?region=region#
```
+ Pour l'architecture Arm 64 bits (`arm64`) :
```
https://regionconsole.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2-nvidia/arm64/latest/image_id/description?region=region#
```
## Variante de l’AMI Bottlerocket `aws-ecs-1`
Vous pouvez récupérer la dernière variante stable de l'AMI `aws-ecs-1` Bottlerocket Région AWS par architecture avec AWS CLI le ou le. AWS Management Console
+ **AWS CLI**— Vous pouvez récupérer l'ID d'image de la dernière Bottlerocket AMI optimisée pour Amazon ECS recommandée à l'aide de la AWS CLI commande suivante en utilisant le sous-paramètre. `image_id` Remplacez la `region` par le code de région pour lequel vous souhaitez obtenir l'ID AMI.
Pour plus d'informations sur les options prises en charge Régions AWS, consultez [la section Trouver une AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) sur GitHub. Pour récupérer une autre version que la dernière, remplacez `latest` par le numéro de version.
+ Pour l'architecture 64 bits (`x86_64`) :
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_id" --query Parameter.Value --output text
```
+ Pour l'architecture Arm 64 bits (`arm64`) :
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1/arm64/latest/image_id" --query Parameter.Value --output text
```
+ **AWS Management Console** : vous pouvez interroger l'ID d'AMI optimisée pour Amazon ECS recommandée à l'aide d'une URL dans l' AWS Management Console. L'URL ouvre la console Amazon EC2 Systems Manager avec la valeur de l'ID du paramètre. Dans l'URL suivante, remplacez `region` par le code de région pour lequel vous souhaitez obtenir l'ID AMI.
Pour plus d'informations sur les options prises en charge Régions AWS, consultez [la section Trouver une AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) sur GitHub.
+ Pour l'architecture 64 bits (`x86_64`) :
```
https://region.console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_id/description
```
+ Pour l'architecture Arm 64 bits (`arm64`) :
```
https://region.console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1/arm64/latest/image_id/description
```
## Variante de l’AMI Bottlerocket `aws-ecs-1-nvidia`
Vous pouvez récupérer la dernière variante stable de l'AMI `aws-ecs-1-nvdia` Bottlerocket par région et architecture avec AWS CLI le ou le. AWS Management Console
+ **AWS CLI**— Vous pouvez récupérer l'ID d'image de la dernière Bottlerocket AMI optimisée pour Amazon ECS recommandée à l'aide de la AWS CLI commande suivante en utilisant le sous-paramètre. `image_id` Remplacez la `region` par le code de région pour lequel vous souhaitez obtenir l'ID AMI.
Pour plus d'informations sur les options prises en charge Régions AWS, consultez [la section Trouver une AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) sur GitHub.
+ Pour l'architecture 64 bits (`x86_64`) :
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1-nvidia/x86_64/latest/image_id" --query Parameter.Value --output text
```
+ Pour l'architecture Arm 64 bits (`arm64`) :
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1-nvidia/arm64/latest/image_id" --query Parameter.Value --output text
```
+ **AWS Management Console** : vous pouvez interroger l'ID d'AMI optimisée pour Amazon ECS recommandée à l'aide d'une URL dans l' AWS Management Console. L'URL ouvre la console Amazon EC2 Systems Manager avec la valeur de l'ID du paramètre. Dans l'URL suivante, remplacez `region` par le code de région pour lequel vous souhaitez obtenir l'ID AMI.
Pour plus d'informations sur les options prises en charge Régions AWS, consultez [la section Trouver une AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) sur GitHub.
+ Pour l'architecture 64 bits (`x86_64`) :
```
https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1-nvidia/x86_64/latest/image_id/description?region=region#
```
+ Pour l'architecture Arm 64 bits (`arm64`) :
```
https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1-nvidia/arm64/latest/image_id/description?region=region#
```
## Étapes suivantes
Pour un didacticiel détaillé sur la prise en main du système Bottlerocket d'exploitation sur Amazon ECS, consultez les sections [Utilisation d'une AMI Bottlerocket avec Amazon ECS GitHub activé](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md) [et Getting started with Bottlerocket et Amazon](https://aws.amazon.com/blogs/containers/getting-started-with-bottlerocket-and-amazon-ecs/) ECS sur AWS le site du blog.
Pour plus d’informations sur le lancement d’une instance Bottlerocket, consultez la section [Lancement d’une instance Bottlerocket pour Amazon ECS](bottlerocket-launch.md).
# Lancement d’une instance Bottlerocket pour Amazon ECS
Vous pouvez lancer une instance Bottlerocket de manière à pouvoir exécuter vos charges de travail de conteneur.
Vous pouvez utiliser le AWS CLI pour lancer l'Bottlerocketinstance.
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.
```
[settings.ecs]
cluster = "cluster-name"
```
1. Utilisez l'une des commandes incluses dans [Extraction des métadonnées de l’AMI Bottlerocket optimisée pour Amazon ECS](ecs-bottlerocket-retrieve-ami.md) pour obtenir l'ID d'AMI Bottlerocket. Utilisez ceci lors de l'étape suivante.
1. Exécutez la commande suivante pour lancer l'instance Bottlerocket. 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.
+ *bottlerocket\$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-bottlerocket-example \
--subnet-id subnet \
--image-id bottlerocket_ami \
--instance-type t3.large \
--region region \
--tag-specifications 'ResourceType=instance,Tags=[{Key=bottlerocket,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
```
Pour une présentation détaillée de la prise en main du système Bottlerocket d'exploitation sur Amazon ECS, consultez les sections [Utilisation d'une AMI Bottlerocket avec Amazon](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md) ECS activé et Getting started with [Bottlerocketet Amazon](https://aws.amazon.com/blogs/containers/getting-started-with-bottlerocket-and-amazon-ecs/) ECS GitHub sur le AWS site du blog.
# Gestion des instances de conteneur Amazon ECS Linux
Lorsque vous utilisez des instances EC2 pour vos charges de travail Amazon ECS, vous êtes responsable de la maintenance des instances
**Topics**
+ [Lancement d'une instance de conteneur](launch_container_instance.md)
+ [Démarrage d’instances de conteneur Linux](bootstrap_container_instance.md)
+ [Configuration des instances de conteneur pour recevoir des notifications relatives aux instances Spot](spot-instance-draining-linux-container.md)
+ [Exécution d’un script lorsque vous lancez une instance de conteneur](start_task_at_launch.md)
+ [
# Augmentation des interfaces réseau d’une instance de conteneur Amazon ECS Linux
](container-instance-eni.md)
+ [Réservation de mémoire pour une instance de conteneur](memory-management.md)
+ [Gestion à distance des instances de conteneur](ec2-run-command.md)
+ [Utilisation d’un proxy HTTP pour les instances de conteneur Linux](http_proxy_config.md)
+ [Configuration d’instances préinitialisées pour votre groupe Auto Scaling](using-warm-pool.md)
+ [
# Mise à jour de l'agent de conteneur Amazon ECS
](ecs-agent-update.md)
Chaque version d'agent de conteneur Amazon ECS prend en charge un ensemble de différentes fonctions et fournit des correctifs des versions précédentes. Dans la mesure du possible, nous recommandons toujours d'utiliser la dernière version de l'agent de conteneur Amazon ECS. 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).
Pour voir quelles fonctionnalités et améliorations sont incluses dans chaque version de l'agent, consultez [https://github.com/aws/amazon-ecs-agent/releases](https://github.com/aws/amazon-ecs-agent/releases).
**Important**
La version minimale de Docker pour des métriques fiables est la version `v20.10.13` et les versions ultérieures, qui sont incluses dans l'AMI `20220607` optimisée pour Amazon ECS et les versions plus récentes.
La version de l'agent Amazon ECS `1.20.0` et les versions plus récentes ne prennent plus en charge les versions de Docker antérieures à `18.01.0`.
# Lancement d'une instance de conteneur Amazon ECS Linux
Vos instances de conteneur Amazon ECS sont créées à l’aide de la console Amazon EC2.
Vous pouvez lancer une instance par différentes méthodes, notamment la console Amazon EC2 et AWS CLI le SDK. Pour plus d’informations sur les autres méthodes de lancement d’instance, consultez la section [Lancer votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html) dans le *Guide de l’utilisateur Amazon EC2*.
Pour plus d’informations sur l’assistant de lancement, consultez la section [Lancement d’une instance à l’aide du nouvel assistant de lancement d’instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) dans le *Guide de l’utilisateur Amazon EC2*.
Avant de commencer, complétez les étapes détaillées dans [Configurer l'utilisation d'Amazon ECS](get-set-up-for-amazon-ecs.md).
Vous pouvez utiliser le nouvel assistant Amazon EC2 pour lancer une instance. L’assistant de lancement d’instance spécifie les paramètres de lancement qui sont requis pour lancer une instance.
**Topics**
+ [
## Procédure
](#linux-liw-initiate-instance-launch)
+ [
## Noms et identifications
](#linux-liw-name-and-tags)
+ [
## Images d’applications et de systèmes d’exploitation (Amazon Machine Image)
](#linux-liw-ami)
+ [
## Type d’instance
](#linux-liw-instance-type)
+ [
## Paire de clés (connexion)
](#linux-liw-key-pair)
+ [
## Paramètres réseau
](#linux-liw-network-settings)
+ [
## Configurer le stockage
](#linux-liw-storage)
+ [
## Détails avancés
](#linux-liw-advanced-details)
## Procédure
Avant de commencer, complétez les étapes détaillées dans [Configurer l'utilisation d'Amazon ECS](get-set-up-for-amazon-ecs.md).
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 en haut de l'écran, la AWS région actuelle est affichée (par exemple, USA East (Ohio)). Sélectionnez une région dans laquelle lancer l’instance.
1. Sur le tableau de bord de la console Amazon EC2, sélectionnez **Launch instance (Lancer une instance)**.
## Noms et identifications
Le nom de l'instance est une identification, où la clé est **Name** (Nom), et la valeur est le nom que vous spécifiez. Vous pouvez étiqueter l'instance, les volumes et les Elastic Graphics. Pour les instances Spot, vous pouvez baliser uniquement la demande d’instance Spot.
La spécification d’un nom d’instance et d’identifications supplémentaires est facultative.
+ Pour **Name** (Nom), saisissez un nom descriptif pour l’instance. Si vous ne spécifiez pas de nom, l’instance peut être identifiée par son ID, qui est automatiquement généré lorsque vous lancez l’instance.
+ Pour ajouter des identifications supplémentaires, sélectionnez **Add additional tags** (Ajouter des identifications supplémentaires). Choisissez **Add tag** (Ajouter une identification), saisissez une clé et une valeur, puis sélectionnez le type de ressource à étiqueter. Choisissez **Add tag** (Ajouter une identification) pour chaque étiquette supplémentaire.
## Images d’applications et de systèmes d’exploitation (Amazon Machine Image)
Une Amazon Machine Image (AMI) contient les informations requises pour créer une instance. Par exemple, une AMI peut contenir le logiciel nécessaire pour fonctionner en tant que serveur web, comme Apache et votre site web.
Utilisez la barre **de recherche** pour trouver une AMI optimisée pour Amazon ECS adaptée publiée par. AWS
1. Entrez l'un des termes suivants dans la barre de **recherche**.
+ **ami-ecs**
+ La **valeur** d'une AMI optimisée pour Amazon ECS.
Pour connaître les dernières versions optimisées pour Amazon ECS AMIs et leurs valeurs, consultez l'AMI optimisée pour [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux) pour Linux.
1. Appuyez sur **Entrée**.
1. Sur la page **Choose an Amazon Machine Image (AMI)**, sélectionnez l' AMIsonglet **AWS Marketplace**.
1. À partir du volet de gauche **Refine results (Affiner les résultats)**, sélectionnez **Amazon Web Services** en tant qu'**éditeur**.
1. Choisissez **Sélectionner** sur la ligne de l'AMI que vous souhaitez utiliser.
Vous pouvez également choisir **Cancel (Annuler)** (en haut à droite) pour revenir à l'assistant de lancement d'instance sans choisir une AMI. Une AMI par défaut sera sélectionnée. Assurez-vous que l'AMI répond aux exigences décrites dans le système Linux [optimisé pour Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html). AMIs
## Type d’instance
Le type d’instance définit la configuration matérielle et la taille de l’instance. Les types d’instance plus importants disposent de plus d’UC et de mémoire. Pour plus d’informations, consultez [Types d’instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) dans le *Guide de l’utilisateur Amazon EC2*. Si vous souhaitez exécuter une charge de travail IPv6 uniquement, certains types d'instances ne prennent pas en charge IPv6 les adresses. Pour plus d'informations, consultez les [IPv6adresses](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#ipv6-addressing) dans le guide de l'*utilisateur Amazon EC2*.
+ Pour **Instance type** (Type d’instance), sélectionnez le type de l’instance.
Le type d'instance que vous sélectionnez détermine les ressources disponibles pour les tâches à exécuter.
## Paire de clés (connexion)
Pour **Key pair name** (Nom de la paire de clés), choisissez une paire de clés existante ou choisissez **Create new key pair** (Créer une nouvelle paire de clés) pour en créer une nouvelle.
**Important**
Si vous sélectionnez l’option **Proceed without key pair (Not recommended)** ((Continuer sans paire de clé) (Non recommandé)), vous ne pourrez pas vous connecter à l’instance à moins de choisir une AMI configurée de façon à autoriser les utilisateurs à se connecter d’une autre façon.
## Paramètres réseau
Configurez les paramètres réseau selon vos besoins après avoir cliqué sur le bouton **Modifier** dans la section **Paramètres réseau** du formulaire.
+ Pour **VPC**, choisissez le VPC dans lequel vous souhaitez lancer l’instance. Pour exécuter une charge de travail IPv6 uniquement, choisissez un VPC à double pile qui inclut à la fois IPv4 un bloc CIDR et IPv6 un bloc CIDR.
+ Pour **Sous-réseau**, choisissez le sous-réseau dans lequel lancer l’instance. Vous pouvez lancer une instance dans un sous-réseau associé à une zone de disponibilité, une zone locale, une zone Wavelength ou un Outpost.
Pour lancer l’instance dans une zone de disponibilité, sélectionnez le sous-réseau dans lequel lancer votre instance. Pour créer un sous-réseau, choisissez **Créer un nouveau sous-réseau** afin d’accéder à la console Amazon VPC. Une fois que vous avez terminé, revenez dans l’assistant de lancement d’instance et choisissez l’icône Refresh (Actualiser) afin de charger votre sous-réseau dans la liste.
Pour lancer l’instance dans une zone locale, sélectionnez un sous-réseau que vous avez créé dans la zone locale.
Pour lancer une instance dans un Outpost, sélectionnez un sous-réseau dans un VPC que vous avez associé à l’Outpost.
Pour exécuter une charge de travail IPv6 uniquement, choisissez un sous-réseau qui inclut uniquement un bloc IPv6 CIDR.
+ **Auto-assign Public IP** (Attribuer automatiquement l'adresse IP publique) : si votre instance doit être accessible à partir d'Internet, vérifiez que le champ **Auto-assign Public IP** (Attribuer automatiquement l'adresse IP publique) est défini sur **Enable** (Activer). Si ce n'est pas le cas, définissez ce champ sur **Disable** (Désactiver).
**Note**
Les instances de conteneur ont besoin de communiquer avec le point de terminaison de service Amazon ECS. Cela peut être via un point de terminaison d'un VPC d'interface ou via vos instances de conteneur ayant des adresses IP publiques.
Pour plus d'informations sur les points de terminaison d'un VPC d'interface, consultez [Points de terminaison d'un VPC d'interface Amazon ECS (AWS PrivateLink)](vpc-endpoints.md).
Si vous n'avez pas de point de terminaison d'un VPC d'interface configuré et que vos instances de conteneur n'ont pas d'adresses IP publiques, elles doivent utiliser la traduction d'adresse réseau (NAT) pour fournir cet accès. Pour de plus amples informations, veuillez consulter [Passerelles NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) dans le *Guide de l'utilisateur Amazon VPC* et [Utilisation d’un proxy HTTP pour les instances de conteneur Amazon ECS Linux](http_proxy_config.md) dans ce guide.
+ **Si vous choisissez un VPC à double pile et un sous-réseau IPv6 uniquement, pour **Attribuer automatiquement IPv6 ** une adresse IP, choisissez Enable.**
+ **Firewall (security groups)** (Pare-feu (groupes de sécurité)) : utilisez un groupe de sécurité afin de définir les règles de pare-feu de votre instance de conteneur. Ces règles déterminent le trafic réseau entrant acheminé vers votre instance de conteneur. Le reste du trafic est ignoré.
+ Pour sélectionner un groupe de sécurité existant, choisissez **Select existing security group** (Sélectionner un groupe de sécurité existant), puis sélectionnez le groupe de sécurité que vous avez créé dans [Configurer l'utilisation d'Amazon ECS](get-set-up-for-amazon-ecs.md).
+ Si vous lancez l'instance pour une charge de travail IPv6 uniquement, choisissez **Configuration réseau avancée**, puis pour **Attribuer une IPv6 adresse IP principale**, choisissez **Oui**.
**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.
## Configurer le stockage
L’AMI sélectionnée inclut un ou plusieurs volumes de stockage, notamment le volume racine. Vous pouvez spécifier d’autres volumes à attacher à l’instance.
Vous pouvez utiliser la vue **Simple**.
+ **Storage type** (Type de stockage) : configurez le stockage pour votre instance de conteneur.
Si vous utilisez l'AMI Amazon Linux 2 optimisée pour Amazon ECS, votre instance contient un seul volume configuré de 30 Gio, partagé entre le système d'exploitation et Docker.
Si vous utilisez l'AMI optimisée pour Amazon ECS, votre instance contient deux volumes configurés. Le volume **Racine** est réservé au système d'exploitation et le second volume Amazon EBS (attaché à `/dev/xvdcz`) est réservé à Docker.
Vous pouvez augmenter ou diminuer la taille des volumes pour votre instance afin de répondre aux besoins de votre application.
## Détails avancés
Développez la section **Détails avancés** pour afficher les champs et spécifier des paramètres supplémentaires pour l’instance.
+ **Purchasing option** (Option d'achat) : sélectionnez **Request Spot Instances** (Demander des instances Spot) pour demander une instance Spot. Vous devez également définir les autres champs associés aux instances Spot. Pour plus d'informations, consultez [Demandes d'instances Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html).
**Note**
Si vous utilisez les instances Spot et qu'un message `Not available` s'affiche, vous devrez peut-être choisir un autre type d'instance.
+ **IAM instance profile** (Profil d'instance IAM) : sélectionnez votre rôle IAM d'instance de conteneur. Celui-ci est généralement nommé `ecsInstanceRole`.
**Important**
Si vous ne pas lancez votre instance de conteneur avec les autorisations IAM appropriées, votre agent Amazon ECS ne peut pas se connecter à votre cluster. Pour de plus amples informations, veuillez consulter [Rôle IAM d'instance de conteneur Amazon ECS](instance_IAM_role.md).
+ **Données utilisateur** : configurez votre instance de conteneur Amazon ECS avec les données utilisateur, telles que les variables d’environnement d’agent depuis [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md). Les scripts de données utilisateur Amazon EC2 sont exécutés une seule fois, au premier lancement de l'instance. Les exemples suivants présentent des utilisations courantes des données utilisateur :
+ Par défaut, votre instance de conteneur est lancée dans votre cluster par défaut. Pour un lancement dans un cluster autre que celui défini par défaut, choisissez la liste **Détails avancés**. Collez ensuite le script suivant dans le champ **Données utilisateur**, en le *your\$1cluster\$1name* remplaçant par le nom de votre cluster.
```
#!/bin/bash
echo ECS_CLUSTER=your_cluster_name >> /etc/ecs/ecs.config
```
+ Si vous avez un fichier `ecs.config` dans Amazon S3 et que l'accès en lecture seule d'Amazon S3 à votre rôle d'instance de conteneur est activé, choisissez la liste **Advanced Details (Détails avancés)**. Collez ensuite le script suivant dans le champ **Données utilisateur**, en le *your\$1bucket\$1name* remplaçant par le nom de votre bucket pour installer le AWS CLI et écrivez votre fichier de configuration au moment du lancement.
**Note**
Pour en savoir plus sur cette configuration, consultez [Stockage de la configuration d’instance de conteneur Amazon ECS dans Amazon S3](ecs-config-s3.md).
```
#!/bin/bash
yum install -y aws-cli
aws s3 cp s3://your_bucket_name/ecs.config /etc/ecs/ecs.config
```
+ Spécifiez des balises pour votre instance de conteneur à l'aide du paramètre de configuration `ECS_CONTAINER_INSTANCE_TAGS`. Cela permet de créer des balises associées uniquement à Amazon ECS, qui ne peuvent pas être répertoriées à l'aide de l'API Amazon EC2.
**Important**
Si vous lancez vos instances de conteneur à l'aide d'un groupe Amazon EC2 Auto Scaling, vous devez utiliser le paramètre de configuration de l'agent ECS\$1CONTENER\$1INSTANCE\$1TAGS pour ajouter des balises. Cela est dû à la manière dont les balises sont ajoutées aux instances Amazon EC2 lancées à l'aide de groupes Auto Scaling.
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=your_cluster_name
ECS_CONTAINER_INSTANCE_TAGS={"tag_key": "tag_value"}
EOF
```
+ Spécifiez les balises pour votre instance de conteneur, puis utilisez le paramètre de configuration `ECS_CONTAINER_INSTANCE_PROPAGATE_TAGS_FROM` pour les propager depuis Amazon EC2 vers Amazon ECS.
L'exemple suivant présente un script de données utilisateur qui propage les balises associées à une instance de conteneur, et enregistre l'instance de conteneur avec un cluster nommé `your_cluster_name` :
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=your_cluster_name
ECS_CONTAINER_INSTANCE_PROPAGATE_TAGS_FROM=ec2_instance
EOF
```
+ 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.
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=your_cluster_name
ECS_INSTANCE_IP_COMPATIBILITY=ipv6
EOF
```
Pour de plus amples informations, veuillez consulter [Démarrage des instances de conteneurs Amazon ECS Linux pour transmettre des données](bootstrap_container_instance.md).
# Démarrage des instances de conteneurs Amazon ECS Linux pour transmettre des données
Lorsque vous lancez une instance Amazon EC2, vous pouvez transmettre les données utilisateur à cette instance. Ces données peuvent être utilisées afin d'effectuer des tâches de configuration automatisées courantes, voire d'exécuter des scripts lors du démarrage de l'instance. Pour Amazon ECS, les données utilisateur sont le plus souvent utilisées pour transmettre les informations de configuration au démon Docker et à l'agent de conteneur Amazon ECS.
Vous pouvez transmettre plusieurs types de données utilisateur à Amazon EC2, notamment des boothooks de cloud, des scripts shell et des directives `cloud-init`. Pour plus d'informations sur ce point et sur d'autres types de format, consultez la [documentation sur Cloud-Init](https://cloudinit.readthedocs.io/en/latest/explanation/format.html).
Pour transmettre les données utilisateur lors de l’utilisation de l’assistant de lancement Amazon EC2, consultez la section [Lancement d'une instance de conteneur Amazon ECS Linux](launch_container_instance.md).
Vous pouvez configurer l’instance de conteneur pour transmettre des données dans la configuration de l’agent de conteneur ou dans la configuration du démon Docker.
## Agent de conteneur Amazon ECS
Les variantes Linux de l'AMI optimisée pour Amazon ECS recherchent les données de configuration de l'agent dans le fichier `/etc/ecs/ecs.config` au démarrage de l'agent de conteneur. Vous pouvez spécifier ces données de configuration lors du lancement avec les données utilisateur Amazon EC2. Pour plus d'informations sur les variables de configuration d'agent de conteneur Amazon ECS disponibles, veuillez consulter [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md).
Pour définir une seule variable de configuration d'agent, par exemple le nom du cluster, utilisez **echo** afin de copier la variable dans le fichier de configuration :
```
#!/bin/bash
echo "ECS_CLUSTER=MyCluster" >> /etc/ecs/ecs.config
```
Si vous devez écrire plusieurs variables dans `/etc/ecs/ecs.config`, utilisez le format `heredoc` suivant. Ce format écrit tout entre les lignes commençant par **cat** et `EOF` dans le fichier de configuration.
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
ECS_LOGLEVEL=debug
ECS_WARM_POOLS_CHECK=true
EOF
```
Pour définir des attributs d'instance personnalisés, définissez la variable d'environnement `ECS_INSTANCE_ATTRIBUTES`.
```
#!/bin/bash
cat <<'EOF' >> ecs.config
ECS_INSTANCE_ATTRIBUTES={"envtype":"prod"}
EOF
```
## Démon Docker
Vous pouvez spécifier des informations de configuration du démon Docker avec les données utilisateur Amazon EC2. Pour plus d'informations sur les options de configuration , consultez [la documentation sur le démon Docker](https://docs.docker.com/reference/cli/dockerd/).
**Note**
AWS ne prend pas en charge les configurations Docker personnalisées, car elles peuvent parfois entrer en conflit avec les futures modifications ou fonctionnalités d'Amazon ECS sans avertissement.
Dans l'exemple ci-dessous, les options personnalisées sont ajoutées au fichier de configuration du démon Docker, `/etc/docker/daemon.json`, qui est ensuite spécifié dans les données utilisateur lors du lancement de l'instance.
```
#!/bin/bash
cat </etc/docker/daemon.json
{"debug": true}
EOF
systemctl restart docker --no-block
```
Dans l'exemple ci-dessous, les options personnalisées sont ajoutées au fichier de configuration du démon Docker, `/etc/docker/daemon.json`, qui est ensuite spécifié dans les données utilisateur lors du lancement de l'instance. Cet exemple montre comment désactiver le proxy Docker dans le fichier de configuration du démon Docker.
```
#!/bin/bash
cat </etc/docker/daemon.json
{"userland-proxy": false}
EOF
systemctl restart docker --no-block
```
# Configuration des instances de conteneur Amazon ECS Linux pour recevoir des notifications relatives aux instances Spot
Amazon EC2 résilie, arrête ou met en veille prolongée votre instance Spot lorsque le prix Spot dépasse le prix maximum de votre demande ou lorsque la capacité n'est plus disponible. Amazon EC2 fournit un avis d'interruption de deux minutes pour les actions de résiliation et d'arrêt des instances Spot. Il ne fournit pas l'avis de deux minutes pour l'action de mise en veille prolongée. Si le drainage des instances Spot Amazon ECS est activé sur l’instance, Amazon ECS reçoit l’avis d’interruption d’instance Spot et bascule l’instance à l’état `DRAINING`.
**Important**
Amazon ECS ne reçoit pas d'avis de la part d'Amazon EC2 lorsque les instances sont supprimées par le rééquilibrage de la capacité Auto Scaling. Pour plus d'informations, consultez [Rééquilibrage de la capacité Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-capacity-rebalancing.html).
Lorsqu'une instance de conteneur est définie sur `DRAINING`, Amazon ECS bloque la planification du placement des nouvelles tâches sur l'instance de conteneur. Les tâches de service ayant l'état `PENDING` sur l'instance de conteneur faisant l'objet du drainage sont arrêtées immédiatement. S'il y a des instances de conteneur disponibles dans le cluster, des tâches de service de remplacement sont lancées dessus.
Le drainage des instances Spot est désactivé par défaut.
Vous pouvez activer le drainage d’instance Spot lorsque vous lancez une instance. Ajoutez le script suivant dans le champ **Données utilisateur**. Remplacez *MyCluster* par le nom du cluster dans lequel enregistrer l'instance de conteneur.
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true
EOF
```
Pour de plus amples informations, veuillez consulter [Lancement d'une instance de conteneur Amazon ECS Linux](launch_container_instance.md).
**Pour activer le drainage des instances Spot pour une instance de conteneur existante**
1. Connectez-vous à l'instance Spot via SSH.
1. Modifiez le fichier `/etc/ecs/ecs.config` et ajoutez le code suivant :
```
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true
```
1. Redémarrez le service `ecs`.
+ Pour l'AMI Amazon Linux 2 optimisée pour Amazon ECS :
```
sudo systemctl restart ecs
```
1. (Facultatif) Vous pouvez vérifier que l'agent est en cours d'exécution et consulter des informations sur votre nouvelle instance de conteneur en interrogeant l'opération API d'introspection d'agent. Pour de plus amples informations, veuillez consulter [Introspection de conteneur Amazon ECS](ecs-agent-introspection.md).
```
curl http://localhost:51678/v1/metadata
```
# Exécution d’un script lorsque vous lancez une instance de conteneur Amazon ECS Linux
Vous devrez peut-être exécuter un conteneur spécifique sur chaque instance de conteneur pour traiter les problèmes de sécurité et de fonctionnement, telles que la surveillance, la sécurité, les métriques, la découverte de service ou la journalisation.
Pour ce faire, vous pouvez configurer vos instances de conteneur de façon à ce qu'elles appellent la commande **docker run** avec le script de données utilisateur au moment du lancement ou dans un système d'initialisation comme Upstart ou **systemd**. Bien que cette méthode soit efficace, elle présente quelques inconvénients, étant donné qu'Amazon ECS n'a pas connaissance du conteneur et qu'il ne peut pas surveiller l'UC, la mémoire, les ports ni aucune autre ressource utilisée. Afin de veiller à ce qu'Amazon ECS prenne en compte correctement toutes les ressources de la tâche, vous devez créer une définition de tâche pour le conteneur que vous voulez exécuter sur vos instances de conteneur. Ensuite, utilisez Amazon ECS pour placer la tâche au moment du lancement avec les données utilisateur Amazon EC2.
Le script de données utilisateur Amazon EC2 de la procédure suivante utilise l'API d'introspection Amazon ECS pour identifier l'instance de conteneur. Ensuite, il utilise la **start-task** commande AWS CLI et pour exécuter une tâche spécifiée sur lui-même au démarrage.
**Pour démarrer une tâche au moment du lancement d'une instance de conteneur**
1. Modifiez votre rôle IAM `ecsInstanceRole` pour ajouter des autorisations pour l'opération d'API `StartTask`. Pour plus d’informations, consultez la section [Mettre à jour les autorisations pour un rôle](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_update-role-permissions.html) dans le *Guide de l’utilisateur Gestion des identités et des accès AWS *.
1. Lancez une ou plusieurs instances de conteneur à l’aide de l’AMI Amazon Linux 2 optimisée pour Amazon ECS. Lancez de nouvelles instances de conteneur et utilisez l’exemple de script suivant dans les données utilisateur EC2. *your\$1cluster\$1name*Remplacez-le par le cluster dans lequel l'instance de conteneur doit être enregistrée et *my\$1task\$1def* par la définition de tâche à exécuter sur l'instance au lancement.
Pour de plus amples informations, veuillez consulter [Lancement d'une instance de conteneur Amazon ECS Linux](launch_container_instance.md).
**Note**
Le contenu du fichier MIME en plusieurs parties ci-dessous utilise un script shell pour définir les valeurs de configuration et installer les packages. Il utilise également une tâche systemd pour démarrer la tâche après le lancement du service **ecs** et une fois que l'API d'introspection est disponible.
```
Content-Type: multipart/mixed; boundary="==BOUNDARY=="
MIME-Version: 1.0
--==BOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
# Specify the cluster that the container instance should register into
cluster=your_cluster_name
# Write the cluster configuration variable to the ecs.config file
# (add any other configuration variables here also)
echo ECS_CLUSTER=$cluster >> /etc/ecs/ecs.config
START_TASK_SCRIPT_FILE="/etc/ecs/ecs-start-task.sh"
cat <<- 'EOF' > ${START_TASK_SCRIPT_FILE}
exec 2>>/var/log/ecs/ecs-start-task.log
set -x
# Install prerequisite tools
yum install -y jq aws-cli
# Wait for the ECS service to be responsive
until curl -s http://localhost:51678/v1/metadata
do
sleep 1
done
# Grab the container instance ARN and AWS Region from instance metadata
instance_arn=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .ContainerInstanceArn' | awk -F/ '{print $NF}' )
cluster=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .Cluster' | awk -F/ '{print $NF}' )
region=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .ContainerInstanceArn' | awk -F: '{print $4}')
# Specify the task definition to run at launch
task_definition=my_task_def
# Run the AWS CLI start-task command to start your task on this container instance
aws ecs start-task --cluster $cluster --task-definition $task_definition --container-instances $instance_arn --started-by $instance_arn --region $region
EOF
# Write systemd unit file
UNIT="ecs-start-task.service"
cat <<- EOF > /etc/systemd/system/${UNIT}
[Unit]
Description=ECS Start Task
Requires=ecs.service
After=ecs.service
[Service]
Restart=on-failure
RestartSec=30
ExecStart=/usr/bin/bash ${START_TASK_SCRIPT_FILE}
[Install]
WantedBy=default.target
EOF
# Enable our ecs.service dependent service with `--no-block` to prevent systemd deadlock
# See https://github.com/aws/amazon-ecs-agent/issues/1707
systemctl enable --now --no-block "${UNIT}"
--==BOUNDARY==--
```
1. Vérifiez que vos instances de conteneur sont lancées dans le cluster approprié et que vos tâches ont démarré.
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 dans laquelle se trouve votre cluster.
1. Dans le panneau de navigation, choisissez **Clusters**, puis sélectionnez le cluster qui héberge vos instances de conteneur.
1. Sur la page **Cluster**, choisissez **Tâches**, puis choisissez vos tâches.
Chaque instance de conteneur que vous avez lancée doit comporter votre tâche en cours d'exécution.
Si vous ne voyez pas vos tâches, vous pouvez vous connecter à vos instances de conteneur avec le protocole SSH et vérifier le fichier `/var/log/ecs/ecs-start-task.log` pour consulter les informations de débogage.
# Augmentation des interfaces réseau d’une instance de conteneur Amazon ECS Linux
**Note**
Cette fonction n'est pas disponible sur Fargate.
Les tâches qui utilisent le mode réseau `awsvpc` reçoivent chacune leur propre interface réseau Elastic (ENI), qui est attachée à l’instance de conteneur qui l’héberge. Le nombre d'interfaces réseau qui peuvent être attachées à des instances Amazon EC2 est limité par défaut et l'interface réseau principale est considérée comme l'une d'elles. Par exemple, par défaut, jusqu'à trois `c5.large` instances peuvent être ENIs associées. L'interface réseau principale de l'instance compte pour une seule, vous pouvez donc 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.
Amazon ECS prend en charge le lancement d’instances de conteneur avec une augmentation de la densité ENI et utilisant des types d’instances Amazon EC2 pris en charge. Lorsque vous utilisez ces types d'instances et que vous activez le paramètre du `awsvpcTrunking` compte, d'autres ENIs sont disponibles sur les instances de conteneur récemment lancées. Cette configuration vous permet de placer plus de tâches sur chaque instance de conteneur. Pour utiliser la console afin d’activer la fonctionnalité, consultez la section [Modification des paramètres de compte Amazon ECS](ecs-modifying-longer-id-settings.md). Pour utiliser le AWS CLI pour activer la fonctionnalité, voir[Gestion des paramètres du compte Amazon ECS à l'aide du AWS CLI](account-setting-management-cli.md).
Par exemple, une instance `c5.large` dotée du paramètre `awsvpcTrunking` dispose d’une limite ENI augmentée à douze. L'instance de conteneur a alors une interface réseau principale. Amazon ECS crée et attache une interface réseau « tronc » à l'instance de conteneur. Par conséquent, cette configuration vous permet de lancer dix tâches sur l'instance de conteneur au lieu des deux tâches actuellement possibles.
L'interface réseau « tronc » est entièrement gérée par Amazon ECS et est supprimée lorsque vous résiliez votre instance de conteneur ou lorsque vous annulez son enregistrement dans le cluster. Pour de plus amples informations, veuillez consulter [Options de mise en réseau des tâches Amazon ECS pour EC2](task-networking.md).
## Considérations
Tenez compte des éléments suivants lorsque vous utilisez la fonctionnalité de jonction ENI.
+ Seules les versions Linux des AMI optimisées pour Amazon ECS ou les autres variantes Amazon Linux avec la version `1.28.1` ou ultérieure de l’agent de conteneur et la version `1.28.1-2` ou ultérieure du package ecs-init, prennent en charge l’augmentation de la limite ENI. Si vous utilisez la dernière variante Linux des AMI optimisées pour Amazon ECS, ces exigences seront respectées. Les conteneurs Windows ne sont pas pris en charge à l'heure actuelle.
+ Seules les nouvelles instances Amazon EC2 lancées après l’activation du paramètre `awsvpcTrunking` reçoivent l’augmentation des limites ENI et l’interface réseau « de jonction ». Les instances lancées avant cette adoption ne reçoivent pas ces fonctionnalités, quelles que soient les actions réalisées.
+ Les requêtes IPv4 DNS basées sur les ressources doivent être désactivées sur les instances Amazon EC2. Pour désactiver cette option, désactivez l'option **Activer les requêtes DNS basées sur les ressources IPV4 (enregistrement A)** lorsque vous créez une nouvelle instance dans la console Amazon EC2. Pour désactiver cette option à l'aide de AWS CLI, utilisez la commande suivante.
```
aws ec2 modify-private-dns-name-options --instance-id i-xxxxxxx --no-enable-resource-name-dns-a-record --no-dry-run
```
+ Les instances Amazon EC2 dans les sous-réseaux partagés ne sont pas prises en charge. Elles ne pourront pas s'enregistrer dans un cluster si elles sont utilisées.
+ Vos tâches doivent utiliser le mode réseau `awsvpc` et l’EC2. Les tâches utilisant Fargate ont toujours reçu une ENI dédiée, quel que soit leur nombre. Cette fonctionnalité n’est donc pas nécessaire.
+ Vos tâches doivent être lancées dans le même Amazon VPC que votre instance de conteneur. Vos tâches ne parviendront pas à démarrer avec une erreur d'attribut si elles ne sont pas dans le même VPC.
+ Lors du lancement d'une nouvelle instance de conteneur, celle-ci passe à l'état `REGISTERING` tandis que l'Elastic Network Interface (ENI) « tronc » est mise en service pour l'instance. Si l'enregistrement échoue, l'instance passe à l'état `REGISTRATION_FAILED`. Vous pouvez dépanner un échec d'enregistrement en décrivant l'instance de conteneur pour afficher le champ `statusReason` qui décrit la raison de l'échec. L'instance de conteneur peut alors être désenregistrée ou résiliée manuellement. Une fois que l’instance de conteneur est correctement désenregistrée ou résiliée, Amazon ECS supprime l’ENI « tronc ».
**Note**
Amazon ECS émet des événements de changement d'état d'instance de conteneur que vous pouvez contrôler pour les instances qui passent à un état `REGISTRATION_FAILED`. Pour de plus amples informations, veuillez consulter [Événements de changement d’état d’une instance de conteneur Amazon ECS](ecs_container_instance_events.md).
+ Une fois que l'instance de conteneur est résiliée, elle passe à l'état `DEREGISTERING` tandis que la mise en service de l'ENI « tronc » est annulée. L'instance passe alors à l'état `INACTIVE`.
+ Si une instance de conteneur d’un sous-réseau public bénéficiant de l’augmentation des limites ENI est arrêtée puis redémarrée, elle perd son adresse IP publique et l’agent de conteneur perd sa connexion.
+ Lorsque vous activez `awsvpcTrunking`, les instances de conteneur reçoivent une ENI supplémentaire qui utilise le groupe de sécurité par défaut du VPC et qui est gérée par Amazon ECS.
Un VPC par défaut est fourni avec un sous-réseau public dans chaque zone de disponibilité, une passerelle Internet et des paramètres permettant la résolution DNS. Le sous-réseau par défaut est public, car la table de routage principale envoie le trafic du sous-réseau destiné à Internet vers la passerelle Internet. Pour transformer un sous-réseau par défaut en sous-réseau privé, vous devez supprimer la route 0.0.0.0/0 pointant vers la passerelle Internet. Toutefois, si vous procédez ainsi, aucune instance de conteneur exécutée dans ce sous-réseau ne pourra accéder à Internet. Vous pouvez ajouter ou supprimer des règles de groupe de sécurité pour contrôler le trafic entrant et sortant de vos sous-réseaux. Pour plus d’informations, consultez la section [Règles des groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.
## Conditions préalables
Avant de lancer une instance de conteneur bénéficiant d’une augmentation des limites ENI, vous devez veiller à ce que les conditions préalables suivantes soient réunies.
+ Le rôle lié à un service pour Amazon ECS doit être créé. Le rôle lié à un service Amazon ECS fournit à 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 compte ou rôle IAM d'instance de conteneur doit activer le paramètre de compte `awsvpcTrunking`. Nous vous recommandons de créer deux rôles d’instance de conteneur (`ecsInstanceRole`). Vous pouvez ensuite activer le paramètre du compte `awsvpcTrunking` pour un rôle et utiliser ce rôle pour les tâches nécessitant une jonction ENI. Pour plus d’informations sur le rôle d’instance de conteneur, consultez la section [Rôle IAM d'instance de conteneur Amazon ECS](instance_IAM_role.md).
Une fois les conditions remplies, vous pouvez lancer une nouvelle instance de conteneur en utilisant l’un des types d’instances Amazon EC2 pris en charge. Cette instance bénéficiera de l’augmentation des limites ENI. Pour obtenir la liste des types d’instances, consultez [Instances prises en charge pour augmenter le nombre d’interfaces réseau de conteneurs Amazon ECS](eni-trunking-supported-instance-types.md). L'instance de conteneur doit disposer de la version `1.28.1` ou ultérieure de l'agent de conteneur et de la version `1.28.1-2` ou ultérieure du package ecs-init. Si vous utilisez la dernière variante Linux des AMI optimisées pour Amazon ECS, ces exigences seront respectées. Pour de plus amples informations, veuillez consulter [Lancement d'une instance de conteneur Amazon ECS Linux](launch_container_instance.md).
**Important**
Les requêtes IPv4 DNS basées sur les ressources doivent être désactivées sur les instances Amazon EC2. Pour désactiver cette option, assurez-vous que l'option **Activer les requêtes DNS basées sur les ressources IPV4 (enregistrement A)** est désélectionnée lors de la création d'une nouvelle instance à l'aide de la console Amazon EC2. Pour désactiver cette option à l'aide de AWS CLI, utilisez la commande suivante.
```
aws ec2 modify-private-dns-name-options --instance-id i-xxxxxxx --no-enable-resource-name-dns-a-record --no-dry-run
```
**Pour afficher vos instances de conteneur avec des ENI limites accrues à l'aide du AWS CLI**
Chaque instance de conteneur possède une interface réseau par défaut, appelée interface réseau « tronc ». Utilisez la commande suivante pour répertorier vos instances de conteneur bénéficiant de l’augmentation des limites ENI en interrogeant l’attribut `ecs.awsvpc-trunk-id`, qui indique qu’elle dispose d’une interface réseau « de jonction ».
+ [list-attributes](https://docs.aws.amazon.com/cli/latest/reference/ecs/list-attributes.html) (AWS CLI)
```
aws ecs list-attributes \
--target-type container-instance \
--attribute-name ecs.awsvpc-trunk-id \
--cluster cluster_name \
--region us-east-1
```
+ [Obtenir la ECSAttribute liste](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-ECSAttributeList.html) (AWS Tools for Windows PowerShell)
```
Get-ECSAttributeList -TargetType container-instance -AttributeName ecs.awsvpc-trunk-id -Region us-east-1
```
# Instances prises en charge pour augmenter le nombre d’interfaces réseau de conteneurs Amazon ECS
L'exemple suivant montre les types d'instances Amazon EC2 pris en charge et le nombre de tâches qui utilisent le mode réseau `awsvpc` pouvant être lancées sur chaque type d'instance avant et après l'activation du paramètre de compte `awsvpcTrunking`.
**Important**
Bien que d'autres types d'instance soient pris en charge dans la même famille d'instances, les types d'instance `a1.metal`, `c5.metal`, `c5a.8xlarge`, `c5ad.8xlarge`, `c5d.metal`, `m5.metal`, `p3dn.24xlarge`, `r5.metal`, `r5.8xlarge` et `r5d.metal` ne sont pas pris en charge.
Les familles d'instances `c5n`, `d3`, `d3en`, `g3`, `g3s` ,`g4dn`, `i3`, `i3en`, `inf1`, `m5dn`, `m5n`, `m5zn`, `mac1`, `r5b`, `r5n`, `r5dn`, `u-12tb1`, `u-6tb1`, `u-9tb1` et `z1d` ne sont pas prises en charge.
**Topics**
+ [
## Usage général
](#eni-branch-gp)
+ [
## Calcul optimisé
](#eni-branch-co)
+ [
## Mémoire optimisée
](#eni-branch-mo)
+ [
## Stockage optimisé
](#eni-branch-so)
+ [
## Calcul accéléré
](#eni-branch-ac)
+ [
## Calcul haute performance
](#eni-branch-hpc)
## Usage général
| Type d’instance | Limite de tâche sans jonction ENI | Limite de tâche avec jonction ENI |
| --- | --- | --- |
| a1.medium | 1 | 10 |
| a1.large | 2 | 10 |
| a1.xlarge | 3 | 20 |
| a1.2xlarge | 3 | 40 |
| a1.4xlarge | 7 | 60 |
| m5.large | 2 | 10 |
| m5.xlarge | 3 | 20 |
| m5.2xlarge | 3 | 40 |
| m5.4xlarge | 7 | 60 |
| m5.8xlarge | 7 | 60 |
| m5.12xlarge | 7 | 60 |
| m5.16xlarge | 14 | 120 |
| m5.24xlarge | 14 | 120 |
| m5a.large | 2 | 10 |
| m5a.xlarge | 3 | 20 |
| m5a.2xlarge | 3 | 40 |
| m5a.4xlarge | 7 | 60 |
| m5a.8xlarge | 7 | 60 |
| m5a.12xlarge | 7 | 60 |
| m5a.16xlarge | 14 | 120 |
| m5a.24xlarge | 14 | 120 |
| m5ad.large | 2 | 10 |
| m5ad.xlarge | 3 | 20 |
| m5ad.2xlarge | 3 | 40 |
| m5ad.4xlarge | 7 | 60 |
| m5ad.8xlarge | 7 | 60 |
| m5ad.12xlarge | 7 | 60 |
| m5ad.16xlarge | 14 | 120 |
| m5ad.24xlarge | 14 | 120 |
| m5d.large | 2 | 10 |
| m5d.xlarge | 3 | 20 |
| m5d.2xlarge | 3 | 40 |
| m5d.4xlarge | 7 | 60 |
| m5d.8xlarge | 7 | 60 |
| m5d.12xlarge | 7 | 60 |
| m5d.16xlarge | 14 | 120 |
| m5d.24xlarge | 14 | 120 |
| m5d.metal | 14 | 120 |
| m6a.large | 2 | 10 |
| m6a.xlarge | 3 | 20 |
| m6a.2xlarge | 3 | 40 |
| m6a.4xlarge | 7 | 60 |
| m6a.8xlarge | 7 | 90 |
| m6a.12xlarge | 7 | 120 |
| m6a.16xlarge | 14 | 120 |
| m6a.24xlarge | 14 | 120 |
| m6a.32xlarge | 14 | 120 |
| m6a.48xlarge | 14 | 120 |
| m6a.metal | 14 | 120 |
| m6g.medium | 1 | 4 |
| m6g.large | 2 | 10 |
| m6g.xlarge | 3 | 20 |
| m6g.2xlarge | 3 | 40 |
| m6g.4xlarge | 7 | 60 |
| m6g.8xlarge | 7 | 60 |
| m6g.12xlarge | 7 | 60 |
| m6g.16xlarge | 14 | 120 |
| m6g.metal | 14 | 120 |
| m6gd.medium | 1 | 4 |
| m6gd.large | 2 | 10 |
| m6gd.xlarge | 3 | 20 |
| m6gd.2xlarge | 3 | 40 |
| m6gd.4xlarge | 7 | 60 |
| m6gd.8xlarge | 7 | 60 |
| m6gd.12xlarge | 7 | 60 |
| m6gd.16xlarge | 14 | 120 |
| m6gd.metal | 14 | 120 |
| m6i.large | 2 | 10 |
| m6i.xlarge | 3 | 20 |
| m6i.2xlarge | 3 | 40 |
| m6i.4xlarge | 7 | 60 |
| m6i.8xlarge | 7 | 90 |
| m6i.12xlarge | 7 | 120 |
| m6i.16xlarge | 14 | 120 |
| m6i.24xlarge | 14 | 120 |
| m6i.32xlarge | 14 | 120 |
| m6i.metal | 14 | 120 |
| m6id.large | 2 | 10 |
| m6id.xlarge | 3 | 20 |
| m6id.2xlarge | 3 | 40 |
| m6id.4xlarge | 7 | 60 |
| m6id.8xlarge | 7 | 90 |
| m6id.12xlarge | 7 | 120 |
| m6id.16xlarge | 14 | 120 |
| m6id.24xlarge | 14 | 120 |
| m6id.32xlarge | 14 | 120 |
| m6id.metal | 14 | 120 |
| m6idn.large | 2 | 10 |
| m6idn.xlarge | 3 | 20 |
| m6idn.2xlarge | 3 | 40 |
| m6idn.4xlarge | 7 | 60 |
| m6idn.8xlarge | 7 | 90 |
| m6idn.12xlarge | 7 | 120 |
| m6idn.16xlarge | 14 | 120 |
| m6idn.24xlarge | 14 | 120 |
| m6idn.32xlarge | 15 | 120 |
| m6idn.metal | 15 | 120 |
| m6in.large | 2 | 10 |
| m6in.xlarge | 3 | 20 |
| m6in.2xlarge | 3 | 40 |
| m6in.4xlarge | 7 | 60 |
| m6in.8xlarge | 7 | 90 |
| m6in.12xlarge | 7 | 120 |
| m6in.16xlarge | 14 | 120 |
| m6in.24xlarge | 14 | 120 |
| m6in.32xlarge | 15 | 120 |
| m6in.metal | 15 | 120 |
| m7a.medium | 1 | 4 |
| m7a.large | 2 | 10 |
| m7a.xlarge | 3 | 20 |
| m7a.2xlarge | 3 | 40 |
| m7a.4xlarge | 7 | 60 |
| m7a.8xlarge | 7 | 90 |
| m7a.12xlarge | 7 | 120 |
| m7a.16xlarge | 14 | 120 |
| m7a.24xlarge | 14 | 120 |
| m7a.32xlarge | 14 | 120 |
| m7a.48xlarge | 14 | 120 |
| m7a.metal-48xl | 14 | 120 |
| m7g.medium | 1 | 4 |
| m7g.large | 2 | 10 |
| m7g.xlarge | 3 | 20 |
| m7g.2xlarge | 3 | 40 |
| m7g.4xlarge | 7 | 60 |
| m7g.8xlarge | 7 | 60 |
| m7g.12xlarge | 7 | 60 |
| m7g.16xlarge | 14 | 120 |
| m7g.metal | 14 | 120 |
| m7gd.medium | 1 | 4 |
| m7gd.large | 2 | 10 |
| m7gd.xlarge | 3 | 20 |
| m7gd.2xlarge | 3 | 40 |
| m7gd.4xlarge | 7 | 60 |
| m7gd.8xlarge | 7 | 60 |
| m7gd.12xlarge | 7 | 60 |
| m7gd.16xlarge | 14 | 120 |
| m7gd.metal | 14 | 120 |
| m7i.large | 2 | 10 |
| m7i.xlarge | 3 | 20 |
| m7i.2xlarge | 3 | 40 |
| m7i.4xlarge | 7 | 60 |
| m7i.8xlarge | 7 | 90 |
| m7i.12xlarge | 7 | 120 |
| m7i.16xlarge | 14 | 120 |
| m7i.24xlarge | 14 | 120 |
| m7i.48xlarge | 14 | 120 |
| m7i.metal-24xl | 14 | 120 |
| m7i.metal-48xl | 14 | 120 |
| m7i-flex.large | 2 | 4 |
| m7i-flex.xlarge | 3 | 10 |
| m7i-flex.2xlarge | 3 | 20 |
| m7i-flex.4xlarge | 7 | 40 |
| m7i-flex.8xlarge | 7 | 60 |
| m7i-flex.12xlarge | 7 | 120 |
| m7i-flex.16xlarge | 14 | 120 |
| m8a.medium | 1 | 4 |
| m8a.large | 2 | 10 |
| m8a.xlarge | 3 | 20 |
| 8 m x 2 x large | 3 | 40 |
| 8 x 4 x large | 7 | 60 |
| 8 x 8 x large | 9 | 90 |
| 8 m x 12 x large | 11 | 120 |
| 8 m x 16 x large | 15 | 120 |
| 8 m x 24 x large | 15 | 120 |
| 8 m x 48 x large | 23 | 120 |
| m8a.metal-24xl | 15 | 120 |
| m8a.metal-48xl | 23 | 120 |
| m8azn.medium | 2 | 4 |
| m8azn.large | 3 | 10 |
| m8azn.xlarge | 3 | 20 |
| m8azn.3 x large | 7 | 40 |
| m8azn. 6 x large | 7 | 60 |
| m8azn. 12 x large | 15 | 120 |
| m8azn. 24 x large | 15 | 120 |
| m8azn.metal-12xl | 15 | 120 |
| m8azn.metal-24xl | 15 | 120 |
| m8g.medium | 1 | 4 |
| m8g.large | 2 | 10 |
| m8g.xlarge | 3 | 20 |
| m8g.2xlarge | 3 | 40 |
| m8g.4xlarge | 7 | 60 |
| m8g.8xlarge | 7 | 60 |
| m8g.12xlarge | 7 | 60 |
| m8g.16xlarge | 14 | 120 |
| m8g.24xlarge | 14 | 120 |
| m8g.48xlarge | 14 | 120 |
| m8g.metal-24xl | 14 | 120 |
| m8g.metal-48xl | 14 | 120 |
| 8 Go, taille moyenne | 1 | 4 |
| 8 Go de large | 2 | 10 |
| m8gb.xlarge | 3 | 20 |
| 8 Go, 2 x large | 3 | 40 |
| 8 Go, 4 x large | 7 | 60 |
| 8 Go, 8 x large | 9 | 60 |
| 8 Go, 12 x large | 11 | 60 |
| 8 Go, 16 x large | 15 | 120 |
| 8 Go, 24 x large | 23 | 120 |
| 8 Go, 48 x large | 23 | 120 |
| m8gb.metal-24xl | 23 | 120 |
| m8gb.metal-48xl | 23 | 120 |
| m8gd.medium | 1 | 4 |
| m8gd.large | 2 | 10 |
| m8gd.xlarge | 3 | 20 |
| m8gd.2xlarge | 3 | 40 |
| m8gd.4xlarge | 7 | 60 |
| m8gd.8xlarge | 7 | 60 |
| m8gd.12xlarge | 7 | 60 |
| m8gd.16xlarge | 14 | 120 |
| m8gd.24xlarge | 14 | 120 |
| m8gd.48xlarge | 14 | 120 |
| m8gd.metal-24xl | 14 | 120 |
| m8gd.metal-48xl | 14 | 120 |
| m8gn.medium | 1 | 4 |
| 8 mm de large | 2 | 10 |
| m8gn.xlarge | 3 | 20 |
| 8 mm, 2 x large | 3 | 40 |
| 8 mm x 4 x large | 7 | 60 |
| 8 mm x 8 x large | 9 | 60 |
| 8 mm x 12 x large | 11 | 60 |
| 8 mm x 16 x large | 15 | 120 |
| 8 mm, 24 x large | 23 | 120 |
| 8 mm x 48 x large | 23 | 120 |
| m8gn.metal-24xl | 23 | 120 |
| m8gn.metal-48xl | 23 | 120 |
| m8i.large | 2 | 10 |
| m8i.xlarge | 3 | 20 |
| m8i.2xlarge | 3 | 40 |
| m8i.4xlarge | 7 | 60 |
| m8i.8xlarge | 9 | 90 |
| m8i.12xlarge | 11 | 120 |
| m8i.16xlarge | 15 | 120 |
| m8i.24xlarge | 15 | 120 |
| m8i.32xlarge | 23 | 120 |
| m8i.48xlarge | 23 | 120 |
| m8i.96xlarge | 23 | 120 |
| m8i.metal-48xl | 23 | 120 |
| m8i.metal-96xl | 23 | 120 |
| m8id.large | 2 | 10 |
| m8id.xlarge | 3 | 20 |
| 8 m de diamètre x 2 x large | 3 | 40 |
| 8 m x 4 x large | 7 | 60 |
| 8 m de diamètre x 8 x large | 9 | 90 |
| m 8 id. 12 x large | 11 | 120 |
| m 8 x 16 x large | 15 | 120 |
| m 8 id. 24 x large | 15 | 120 |
| m 8 id.32 x large | 23 | 120 |
| m 8 id.48 x large | 23 | 120 |
| M8 id.96 x large | 23 | 120 |
| m8id.metal-48xl | 23 | 120 |
| m8id.metal-96xl | 23 | 120 |
| m8i-flex.large | 2 | 4 |
| m8i-flex.xlarge | 3 | 10 |
| m8i-flex.2xlarge | 3 | 20 |
| m8i-flex.4xlarge | 7 | 40 |
| m8i-flex.8xlarge | 9 | 60 |
| m8i-flex.12xlarge | 11 | 120 |
| m8i-flex.16xlarge | 15 | 120 |
| mac2.metal | 7 | 12 |
| mac2-m1ultra.metal | 7 | 12 |
| mac2-m2.metal | 7 | 12 |
| mac2-m2pro.metal | 7 | 12 |
| mac-m4.metal | 7 | 12 |
| mac-m4pro.metal | 7 | 12 |
| mac-m4max. metal | 7 | 12 |
## Calcul optimisé
| Type d’instance | Limite de tâche sans jonction ENI | Limite de tâche avec jonction ENI |
| --- | --- | --- |
| c5.large | 2 | 10 |
| c5.xlarge | 3 | 20 |
| c5.2xlarge | 3 | 40 |
| c5.4xlarge | 7 | 60 |
| c5.9xlarge | 7 | 60 |
| c5.12xlarge | 7 | 60 |
| c5.18xlarge | 14 | 120 |
| c5.24xlarge | 14 | 120 |
| c5a.large | 2 | 10 |
| c5a.xlarge | 3 | 20 |
| c5a.2xlarge | 3 | 40 |
| c5a.4xlarge | 7 | 60 |
| c5a.12xlarge | 7 | 60 |
| c5a.16xlarge | 14 | 120 |
| c5a.24xlarge | 14 | 120 |
| c5ad.large | 2 | 10 |
| c5ad.xlarge | 3 | 20 |
| c5ad.2xlarge | 3 | 40 |
| c5ad.4xlarge | 7 | 60 |
| c5ad.12xlarge | 7 | 60 |
| c5ad.16xlarge | 14 | 120 |
| c5ad.24xlarge | 14 | 120 |
| c5d.large | 2 | 10 |
| c5d.xlarge | 3 | 20 |
| c5d.2xlarge | 3 | 40 |
| c5d.4xlarge | 7 | 60 |
| c5d.9xlarge | 7 | 60 |
| c5d.12xlarge | 7 | 60 |
| c5d.18xlarge | 14 | 120 |
| c5d.24xlarge | 14 | 120 |
| c6a.large | 2 | 10 |
| c6a.xlarge | 3 | 20 |
| c6a.2xlarge | 3 | 40 |
| c6a.4xlarge | 7 | 60 |
| c6a.8xlarge | 7 | 90 |
| c6a.12xlarge | 7 | 120 |
| c6a.16xlarge | 14 | 120 |
| c6a.24xlarge | 14 | 120 |
| c6a.32xlarge | 14 | 120 |
| c6a.48xlarge | 14 | 120 |
| c6a.metal | 14 | 120 |
| c6g.medium | 1 | 4 |
| c6g.large | 2 | 10 |
| c6g.xlarge | 3 | 20 |
| c6g.2xlarge | 3 | 40 |
| c6g.4xlarge | 7 | 60 |
| c6g.8xlarge | 7 | 60 |
| c6g.12xlarge | 7 | 60 |
| c6g.16xlarge | 14 | 120 |
| c6g.metal | 14 | 120 |
| c6gd.medium | 1 | 4 |
| c6gd.large | 2 | 10 |
| c6gd.xlarge | 3 | 20 |
| c6gd.2xlarge | 3 | 40 |
| c6gd.4xlarge | 7 | 60 |
| c6gd.8xlarge | 7 | 60 |
| c6gd.12xlarge | 7 | 60 |
| c6gd.16xlarge | 14 | 120 |
| c6gd.metal | 14 | 120 |
| c6gn.medium | 1 | 4 |
| c6gn.large | 2 | 10 |
| c6gn.xlarge | 3 | 20 |
| c6gn.2xlarge | 3 | 40 |
| c6gn.4xlarge | 7 | 60 |
| c6gn.8xlarge | 7 | 60 |
| c6gn.12xlarge | 7 | 60 |
| c6gn.16xlarge | 14 | 120 |
| c6i.large | 2 | 10 |
| c6i.xlarge | 3 | 20 |
| c6i.2xlarge | 3 | 40 |
| c6i.4xlarge | 7 | 60 |
| c6i.8xlarge | 7 | 90 |
| c6i.12xlarge | 7 | 120 |
| c6i.16xlarge | 14 | 120 |
| c6i.24xlarge | 14 | 120 |
| c6i.32xlarge | 14 | 120 |
| c6i.metal | 14 | 120 |
| c6id.large | 2 | 10 |
| c6id.xlarge | 3 | 20 |
| c6id.2xlarge | 3 | 40 |
| c6id.4xlarge | 7 | 60 |
| c6id.8xlarge | 7 | 90 |
| c6id.12xlarge | 7 | 120 |
| c6id.16xlarge | 14 | 120 |
| c6id.24xlarge | 14 | 120 |
| c6id.32xlarge | 14 | 120 |
| c6id.metal | 14 | 120 |
| c6in.large | 2 | 10 |
| c6in.xlarge | 3 | 20 |
| c6in.2xlarge | 3 | 40 |
| c6in.4xlarge | 7 | 60 |
| c6in.8xlarge | 7 | 90 |
| c6in.12xlarge | 7 | 120 |
| c6in.16xlarge | 14 | 120 |
| c6in.24xlarge | 14 | 120 |
| c6in.32xlarge | 15 | 120 |
| c6in.metal | 15 | 120 |
| c7a.medium | 1 | 4 |
| c7a.large | 2 | 10 |
| c7a.xlarge | 3 | 20 |
| c7a.2xlarge | 3 | 40 |
| c7a.4xlarge | 7 | 60 |
| c7a.8xlarge | 7 | 90 |
| c7a.12xlarge | 7 | 120 |
| c7a.16xlarge | 14 | 120 |
| c7a.24xlarge | 14 | 120 |
| c7a.32xlarge | 14 | 120 |
| c7a.48xlarge | 14 | 120 |
| c7a.metal-48xl | 14 | 120 |
| c7g.medium | 1 | 4 |
| c7g.large | 2 | 10 |
| c7g.xlarge | 3 | 20 |
| c7g.2xlarge | 3 | 40 |
| c7g.4xlarge | 7 | 60 |
| c7g.8xlarge | 7 | 60 |
| c7g.12xlarge | 7 | 60 |
| c7g.16xlarge | 14 | 120 |
| c7g.metal | 14 | 120 |
| c7gd.medium | 1 | 4 |
| c7gd.large | 2 | 10 |
| c7gd.xlarge | 3 | 20 |
| c7gd.2xlarge | 3 | 40 |
| c7gd.4xlarge | 7 | 60 |
| c7gd.8xlarge | 7 | 60 |
| c7gd.12xlarge | 7 | 60 |
| c7gd.16xlarge | 14 | 120 |
| c7gd.metal | 14 | 120 |
| c7gn.medium | 1 | 4 |
| c7gn.large | 2 | 10 |
| c7gn.xlarge | 3 | 20 |
| c7gn.2xlarge | 3 | 40 |
| c7gn.4xlarge | 7 | 60 |
| c7gn.8xlarge | 7 | 60 |
| c7gn.12xlarge | 7 | 60 |
| c7gn.16xlarge | 14 | 120 |
| c7gn.metal | 14 | 120 |
| c7i.large | 2 | 10 |
| c7i.xlarge | 3 | 20 |
| c7i.2xlarge | 3 | 40 |
| c7i.4xlarge | 7 | 60 |
| c7i.8xlarge | 7 | 90 |
| c7i.12xlarge | 7 | 120 |
| c7i.16xlarge | 14 | 120 |
| c7i.24xlarge | 14 | 120 |
| c7i.48xlarge | 14 | 120 |
| c7i.metal-24xl | 14 | 120 |
| c7i.metal-48xl | 14 | 120 |
| c7i-flex.large | 2 | 4 |
| c7i-flex.xlarge | 3 | 10 |
| c7i-flex.2xlarge | 3 | 20 |
| c7i-flex.4xlarge | 7 | 40 |
| c7i-flex.8xlarge | 7 | 60 |
| c7i-flex.12xlarge | 7 | 120 |
| c7i-flex.16xlarge | 14 | 120 |
| c8a.medium | 1 | 4 |
| c8a.large | 2 | 10 |
| c8a.xlarge | 3 | 20 |
| c8a.2xlarge | 3 | 40 |
| c8a.4xlarge | 7 | 60 |
| 8 x 8 x large | 9 | 90 |
| environ 8 x 12 x large | 11 | 120 |
| environ 8 x 16 x large | 15 | 120 |
| environ 8 x 24 x large | 15 | 120 |
| environ 8 x 48 x large | 23 | 120 |
| c8a.metal-24xl | 15 | 120 |
| c8a.metal-48xl | 23 | 120 |
| c8g.medium | 1 | 4 |
| c8g.large | 2 | 10 |
| c8g.xlarge | 3 | 20 |
| c8g.2xlarge | 3 | 40 |
| c8g.4xlarge | 7 | 60 |
| c8g.8xlarge | 7 | 60 |
| c8g.12xlarge | 7 | 60 |
| c8g.16xlarge | 14 | 120 |
| c8g.24xlarge | 14 | 120 |
| c8g.48xlarge | 14 | 120 |
| c8g.metal-24xl | 14 | 120 |
| c8g.metal-48xl | 14 | 120 |
| c8gb.medium | 1 | 4 |
| 8 Go de large | 2 | 10 |
| c8gb.xlarge | 3 | 20 |
| 8 Go, 2 x large | 3 | 40 |
| 8 Go, 4 x large | 7 | 60 |
| 8 Go, 8 x large | 9 | 60 |
| 8 Go, 12 x large | 11 | 60 |
| 8 Go, 16 x large | 15 | 120 |
| 8 Go, 24 x large | 23 | 120 |
| 8 Go, 48 x large | 23 | 120 |
| c8gb.metal-24xl | 23 | 120 |
| c8gb.metal-48xl | 23 | 120 |
| c8gd.medium | 1 | 4 |
| c8gd.large | 2 | 10 |
| c8gd.xlarge | 3 | 20 |
| c8gd.2xlarge | 3 | 40 |
| c8gd.4xlarge | 7 | 60 |
| c8gd.8xlarge | 7 | 60 |
| c8gd.12xlarge | 7 | 60 |
| c8gd.16xlarge | 14 | 120 |
| c8gd.24xlarge | 14 | 120 |
| c8gd.48xlarge | 14 | 120 |
| c8gd.metal-24xl | 14 | 120 |
| c8gd.metal-48xl | 14 | 120 |
| c8gn.medium | 1 | 4 |
| c8gn.large | 2 | 10 |
| c8gn.xlarge | 3 | 20 |
| c8gn.2xlarge | 3 | 40 |
| c8gn.4xlarge | 7 | 60 |
| c8gn.8xlarge | 9 | 60 |
| c8gn.12xlarge | 11 | 60 |
| c8gn.16xlarge | 15 | 120 |
| c8gn.24xlarge | 23 | 120 |
| c8gn.48xlarge | 23 | 120 |
| c8gn.metal-24xl | 23 | 120 |
| c8gn.metal-48xl | 23 | 120 |
| c8i.large | 2 | 10 |
| c8i.xlarge | 3 | 20 |
| c8i, 2 x large | 3 | 40 |
| c8i.4xlarge | 7 | 60 |
| 8 x 8 x large | 9 | 90 |
| 8 x 12 x large | 11 | 120 |
| 8 x 16 x large | 15 | 120 |
| c8i 24xlarge | 15 | 120 |
| c8i 32xlarge | 23 | 120 |
| 8 x 48 x large | 23 | 120 |
| c8i.96xlarge | 23 | 120 |
| c8i.metal-48xl | 23 | 120 |
| c8i.metal-96xl | 23 | 120 |
| c8id.large | 2 | 10 |
| c8id.xlarge | 3 | 20 |
| c8id.2xlarge | 3 | 40 |
| c8id.4xlarge | 7 | 60 |
| 8 cm de diamètre x 8 x large | 9 | 90 |
| C8 id.12 x large | 11 | 120 |
| C8 id.16 x large | 15 | 120 |
| C8 id.24 x large | 15 | 120 |
| C8 id.32 x large | 23 | 120 |
| C8 id.48 x large | 23 | 120 |
| C8 id.96 x large | 23 | 120 |
| c8id.metal-48xl | 23 | 120 |
| c8id.metal-96xl | 23 | 120 |
| c8i-flex.large | 2 | 4 |
| c8i-flex.xlarge | 3 | 10 |
| c8i-flex.2xlarge | 3 | 20 |
| c8i-flex.4xlarge | 7 | 40 |
| c8i-flex.8xlarge | 9 | 60 |
| c8i-flex.12xlarge | 11 | 120 |
| c8i-flex.16xlarge | 15 | 120 |
## Mémoire optimisée
| Type d’instance | Limite de tâche sans jonction ENI | Limite de tâche avec jonction ENI |
| --- | --- | --- |
| r5.large | 2 | 10 |
| r5.xlarge | 3 | 20 |
| r5.2xlarge | 3 | 40 |
| r5.4xlarge | 7 | 60 |
| r5.12xlarge | 7 | 60 |
| r5.16xlarge | 14 | 120 |
| r5.24xlarge | 14 | 120 |
| r5a.large | 2 | 10 |
| r5a.xlarge | 3 | 20 |
| r5a.2xlarge | 3 | 40 |
| r5a.4xlarge | 7 | 60 |
| r5a.8xlarge | 7 | 60 |
| r5a.12xlarge | 7 | 60 |
| r5a.16xlarge | 14 | 120 |
| r5a.24xlarge | 14 | 120 |
| r5ad.large | 2 | 10 |
| r5ad.xlarge | 3 | 20 |
| r5ad.2xlarge | 3 | 40 |
| r5ad.4xlarge | 7 | 60 |
| r5ad.8xlarge | 7 | 60 |
| r5ad.12xlarge | 7 | 60 |
| r5ad.16xlarge | 14 | 120 |
| r5ad.24xlarge | 14 | 120 |
| r5b.16xlarge | 14 | 120 |
| r5d.large | 2 | 10 |
| r5d.xlarge | 3 | 20 |
| r5d.2xlarge | 3 | 40 |
| r5d.4xlarge | 7 | 60 |
| r5d.8xlarge | 7 | 60 |
| r5d.12xlarge | 7 | 60 |
| r5d.16xlarge | 14 | 120 |
| r5d.24xlarge | 14 | 120 |
| r5dn.16xlarge | 14 | 120 |
| r6a.large | 2 | 10 |
| r6a.xlarge | 3 | 20 |
| r6a.2xlarge | 3 | 40 |
| r6a.4xlarge | 7 | 60 |
| r6a.8xlarge | 7 | 90 |
| r6a.12xlarge | 7 | 120 |
| r6a.16xlarge | 14 | 120 |
| r6a.24xlarge | 14 | 120 |
| r6a.32xlarge | 14 | 120 |
| r6a.48xlarge | 14 | 120 |
| r6a.metal | 14 | 120 |
| r6g.medium | 1 | 4 |
| r6g.large | 2 | 10 |
| r6g.xlarge | 3 | 20 |
| r6g.2xlarge | 3 | 40 |
| r6g.4xlarge | 7 | 60 |
| r6g.8xlarge | 7 | 60 |
| r6g.12xlarge | 7 | 60 |
| r6g.16xlarge | 14 | 120 |
| r6g.metal | 14 | 120 |
| r6gd.medium | 1 | 4 |
| r6gd.large | 2 | 10 |
| r6gd.xlarge | 3 | 20 |
| r6gd.2xlarge | 3 | 40 |
| r6gd.4xlarge | 7 | 60 |
| r6gd.8xlarge | 7 | 60 |
| r6gd.12xlarge | 7 | 60 |
| r6gd.16xlarge | 14 | 120 |
| r6gd.metal | 14 | 120 |
| r6i.large | 2 | 10 |
| r6i.xlarge | 3 | 20 |
| r6i.2xlarge | 3 | 40 |
| r6i.4xlarge | 7 | 60 |
| r6i.8xlarge | 7 | 90 |
| r6i.12xlarge | 7 | 120 |
| r6i.16xlarge | 14 | 120 |
| r6i.24xlarge | 14 | 120 |
| r6i.32xlarge | 14 | 120 |
| r6i.metal | 14 | 120 |
| r6id.large | 2 | 10 |
| r6id.xlarge | 3 | 20 |
| r6id.2xlarge | 3 | 40 |
| r6id.4xlarge | 7 | 60 |
| r6id.8xlarge | 7 | 90 |
| r6id.12xlarge | 7 | 120 |
| r6id.16xlarge | 14 | 120 |
| r6id.24xlarge | 14 | 120 |
| r6id.32xlarge | 14 | 120 |
| r6id.metal | 14 | 120 |
| r6idn.large | 2 | 10 |
| r6idn.xlarge | 3 | 20 |
| r6idn.2xlarge | 3 | 40 |
| r6idn.4xlarge | 7 | 60 |
| r6idn.8xlarge | 7 | 90 |
| r6idn.12xlarge | 7 | 120 |
| r6idn.16xlarge | 14 | 120 |
| r6idn.24xlarge | 14 | 120 |
| r6idn.32xlarge | 15 | 120 |
| r6idn.metal | 15 | 120 |
| r6in.large | 2 | 10 |
| r6in.xlarge | 3 | 20 |
| r6in.2xlarge | 3 | 40 |
| r6in.4xlarge | 7 | 60 |
| r6in.8xlarge | 7 | 90 |
| r6in.12xlarge | 7 | 120 |
| r6in.16xlarge | 14 | 120 |
| r6in.24xlarge | 14 | 120 |
| r6in.32xlarge | 15 | 120 |
| r6in.metal | 15 | 120 |
| r7a.medium | 1 | 4 |
| r7a.large | 2 | 10 |
| r7a.xlarge | 3 | 20 |
| r7a.2xlarge | 3 | 40 |
| r7a.4xlarge | 7 | 60 |
| r7a.8xlarge | 7 | 90 |
| r7a.12xlarge | 7 | 120 |
| r7a.16xlarge | 14 | 120 |
| r7a.24xlarge | 14 | 120 |
| r7a.32xlarge | 14 | 120 |
| r7a.48xlarge | 14 | 120 |
| r7a.metal-48xl | 14 | 120 |
| r7g.medium | 1 | 4 |
| r7g.large | 2 | 10 |
| r7g.xlarge | 3 | 20 |
| r7g.2xlarge | 3 | 40 |
| r7g.4xlarge | 7 | 60 |
| r7g.8xlarge | 7 | 60 |
| r7g.12xlarge | 7 | 60 |
| r7g.16xlarge | 14 | 120 |
| r7g.metal | 14 | 120 |
| r7gd.medium | 1 | 4 |
| r7gd.large | 2 | 10 |
| r7gd.xlarge | 3 | 20 |
| r7gd.2xlarge | 3 | 40 |
| r7gd.4xlarge | 7 | 60 |
| r7gd.8xlarge | 7 | 60 |
| r7gd.12xlarge | 7 | 60 |
| r7gd.16xlarge | 14 | 120 |
| r7gd.metal | 14 | 120 |
| r7i.large | 2 | 10 |
| r7i.xlarge | 3 | 20 |
| r7i.2xlarge | 3 | 40 |
| r7i.4xlarge | 7 | 60 |
| r7i.8xlarge | 7 | 90 |
| r7i.12xlarge | 7 | 120 |
| r7i.16xlarge | 14 | 120 |
| r7i.24xlarge | 14 | 120 |
| r7i.48xlarge | 14 | 120 |
| r7i.metal-24xl | 14 | 120 |
| r7i.metal-48xl | 14 | 120 |
| r7iz.large | 2 | 10 |
| r7iz.xlarge | 3 | 20 |
| r7iz.2xlarge | 3 | 40 |
| r7iz.4xlarge | 7 | 60 |
| r7iz.8xlarge | 7 | 90 |
| r7iz.12xlarge | 7 | 120 |
| r7iz.16xlarge | 14 | 120 |
| r7iz.32xlarge | 14 | 120 |
| r7iz.metal-16xl | 14 | 120 |
| r7iz.metal-32xl | 14 | 120 |
| r8a.medium | 1 | 4 |
| r8a.large | 2 | 10 |
| r8a.xlarge | 3 | 20 |
| r8a.2xlarge | 3 | 40 |
| r8a.4xlarge | 7 | 60 |
| 8 x 8 x large | 9 | 90 |
| r8a. 12 x large | 11 | 120 |
| r8a.16xlarge | 15 | 120 |
| r8a.24xlarge | 15 | 120 |
| r8a. 48 x large | 23 | 120 |
| r8a.metal-24xl | 15 | 120 |
| r8a.metal-48xl | 23 | 120 |
| r8g.medium | 1 | 4 |
| r8g.large | 2 | 10 |
| r8g.xlarge | 3 | 20 |
| r8g.2xlarge | 3 | 40 |
| r8g.4xlarge | 7 | 60 |
| r8g.8xlarge | 7 | 60 |
| r8g.12xlarge | 7 | 60 |
| r8g.16xlarge | 14 | 120 |
| r8g.24xlarge | 14 | 120 |
| r8g.48xlarge | 14 | 120 |
| r8g.metal-24xl | 14 | 120 |
| r8g.metal-48xl | 14 | 120 |
| r8gb.medium | 1 | 4 |
| r8gb.large | 2 | 10 |
| r8gb.xlarge | 3 | 20 |
| r8gb.2xlarge | 3 | 40 |
| r8gb.4xlarge | 7 | 60 |
| r8gb.8xlarge | 9 | 60 |
| r8gb.12xlarge | 11 | 60 |
| r8gb.16xlarge | 15 | 120 |
| r8gb.24xlarge | 23 | 120 |
| 8 Go, 48 x large | 23 | 120 |
| r8gb.metal-24xl | 23 | 120 |
| r8gb.metal-48xl | 23 | 120 |
| r8gd.medium | 1 | 4 |
| r8gd.large | 2 | 10 |
| r8gd.xlarge | 3 | 20 |
| r8gd.2xlarge | 3 | 40 |
| r8gd.4xlarge | 7 | 60 |
| r8gd.8xlarge | 7 | 60 |
| r8gd.12xlarge | 7 | 60 |
| r8gd.16xlarge | 14 | 120 |
| r8gd.24xlarge | 14 | 120 |
| r8gd.48xlarge | 14 | 120 |
| r8gd.metal-24xl | 14 | 120 |
| r8gd.metal-48xl | 14 | 120 |
| r8gn.medium | 1 | 4 |
| r8gn.large | 2 | 10 |
| r8gn.xlarge | 3 | 20 |
| r8gn.2xlarge | 3 | 40 |
| r8gn.4xlarge | 7 | 60 |
| r8gn.8xlarge | 9 | 60 |
| r8gn.12xlarge | 11 | 60 |
| r8gn.16xlarge | 15 | 120 |
| r8gn.24xlarge | 23 | 120 |
| r8gn.48xlarge | 23 | 120 |
| r8gn.metal-24xl | 23 | 120 |
| r8gn.metal-48xl | 23 | 120 |
| r8i.large | 2 | 10 |
| r8i.xlarge | 3 | 20 |
| r8i.2xlarge | 3 | 40 |
| r8i.4xlarge | 7 | 60 |
| r8i.8xlarge | 9 | 90 |
| r8i.12xlarge | 11 | 120 |
| r8i.16xlarge | 15 | 120 |
| r8i.24xlarge | 15 | 120 |
| r8i.32xlarge | 23 | 120 |
| r8i.48xlarge | 23 | 120 |
| r8i.96xlarge | 23 | 120 |
| r8i.metal-48xl | 23 | 120 |
| r8i.metal-96xl | 23 | 120 |
| r8id.large | 2 | 10 |
| r8id.xlarge | 3 | 20 |
| r8id.2xlarge | 3 | 40 |
| r8id.4xlarge | 7 | 60 |
| 8 x id.8 x large | 9 | 90 |
| R8id.12xlarge | 11 | 120 |
| R8 id.16 x large | 15 | 120 |
| R8id.24xlarge | 15 | 120 |
| R8id.32xlarge | 23 | 120 |
| R8id.48xlarge | 23 | 120 |
| 8 id.96 x large | 23 | 120 |
| r8id.metal-48xl | 23 | 120 |
| r8id.metal-96xl | 23 | 120 |
| r8i-flex.large | 2 | 4 |
| r8i-flex.xlarge | 3 | 10 |
| r8i-flex.2xlarge | 3 | 20 |
| r8i-flex.4xlarge | 7 | 40 |
| r8i-flex.8xlarge | 9 | 60 |
| r8i-flex.12xlarge | 11 | 120 |
| r8i-flex.16xlarge | 15 | 120 |
| u-3tb1.56xlarge | 7 | 12 |
| u-6tb1.56xlarge | 14 | 12 |
| u-18tb1.112xlarge | 14 | 12 |
| u-18tb1.metal | 14 | 12 |
| u-24tb1.112xlarge | 14 | 12 |
| u-24tb1.metal | 14 | 12 |
| u7i-6tb.112xlarge | 14 | 120 |
| u7i-8tb.112xlarge | 14 | 120 |
| u7i-12tb.224xlarge | 14 | 120 |
| u7in-16tb.224xlarge | 15 | 120 |
| u7in-24tb.224xlarge | 15 | 120 |
| u7in-32tb.224xlarge | 15 | 120 |
| u7inh-32tb.480xlarge | 15 | 120 |
| x2gd.medium | 1 | 10 |
| x2gd.large | 2 | 10 |
| x2gd.xlarge | 3 | 20 |
| x2gd.2xlarge | 3 | 40 |
| x2gd.4xlarge | 7 | 60 |
| x2gd.8xlarge | 7 | 60 |
| x2gd.12xlarge | 7 | 60 |
| x2gd.16xlarge | 14 | 120 |
| x2gd.metal | 14 | 120 |
| x2idn.16xlarge | 14 | 120 |
| x2idn.24xlarge | 14 | 120 |
| x2idn.32xlarge | 14 | 120 |
| x2idn.metal | 14 | 120 |
| x2iedn.xlarge | 3 | 13 |
| x2iedn.2xlarge | 3 | 29 |
| x2iedn.4xlarge | 7 | 60 |
| x2iedn.8xlarge | 7 | 120 |
| x2iedn.16xlarge | 14 | 120 |
| x2iedn.24xlarge | 14 | 120 |
| x2iedn.32xlarge | 14 | 120 |
| x2iedn.metal | 14 | 120 |
| x2iezn.2xlarge | 3 | 64 |
| x2iezn.4xlarge | 7 | 120 |
| x2iezn.6xlarge | 7 | 120 |
| x2iezn.8xlarge | 7 | 120 |
| x2iezn.12xlarge | 14 | 120 |
| x2iezn.metal | 14 | 120 |
| x8g.medium | 1 | 4 |
| x8g.large | 2 | 10 |
| x8g.xlarge | 3 | 20 |
| x8g.2xlarge | 3 | 40 |
| x8g.4xlarge | 7 | 60 |
| x8g.8xlarge | 7 | 60 |
| x8g.12xlarge | 7 | 60 |
| x8g.16xlarge | 14 | 120 |
| x8g.24xlarge | 14 | 120 |
| x8g.48xlarge | 14 | 120 |
| x8g.metal-24xl | 14 | 120 |
| x8g.metal-48xl | 14 | 120 |
| x8aedz.large | 3 | 10 |
| x8aedz.xlarge | 3 | 20 |
| x 8 aedz. 3 x large | 7 | 40 |
| x 8 aedz. 6 x large | 7 | 60 |
| x 8 aedz. 12 x large | 15 | 120 |
| x 8 aedz. 24 x large | 15 | 120 |
| x8aedz.metal-12xl | 15 | 120 |
| x8aedz.metal-24xl | 15 | 120 |
| x8 i. large | 2 | 10 |
| x8i.xlarge | 3 | 20 |
| x 8 x 2 x large | 3 | 40 |
| x 8 x 4 x large | 7 | 60 |
| 8 x 1 x 8 x large | 9 | 90 |
| 8 x 1 x 12 x large | 11 | 120 |
| 8 x 1 x 16 x large | 15 | 120 |
| 8 x 1 x 24 x large | 15 | 120 |
| x 8 x 32 x large | 23 | 120 |
| 8 x 48 x large | 23 | 120 |
| x 8 x 64 x large | 23 | 120 |
| x 8 x 96 x large | 23 | 120 |
| x8i.metal-48xl | 23 | 120 |
| x8i.metal-96xl | 23 | 120 |
## Stockage optimisé
| Type d’instance | Limite de tâche sans jonction ENI | Limite de tâche avec jonction ENI |
| --- | --- | --- |
| i4g.large | 2 | 10 |
| i4g.xlarge | 3 | 20 |
| i4g.2xlarge | 3 | 40 |
| i4g.4xlarge | 7 | 60 |
| i4g.8xlarge | 7 | 60 |
| i4g.16xlarge | 14 | 120 |
| i4i.xlarge | 3 | 8 |
| i4i.2xlarge | 3 | 28 |
| i4i.4xlarge | 7 | 58 |
| i4i.8xlarge | 7 | 118 |
| i4i.12xlarge | 7 | 118 |
| i4i.16xlarge | 14 | 248 |
| i4i.24xlarge | 14 | 118 |
| i4i.32xlarge | 14 | 498 |
| i4i.metal | 14 | 498 |
| i7i.large | 2 | 10 |
| i7i.xlarge | 3 | 20 |
| i7i.2xlarge | 3 | 40 |
| i7i.4xlarge | 7 | 60 |
| i7i.8xlarge | 7 | 90 |
| i7i.12xlarge | 7 | 90 |
| i7i.16xlarge | 14 | 120 |
| i7i.24xlarge | 14 | 120 |
| i7i.48xlarge | 14 | 120 |
| i7i.metal-24xl | 14 | 120 |
| i7i.metal-48xl | 14 | 120 |
| i7ie.large | 2 | 20 |
| i7ie.xlarge | 3 | 29 |
| i7ie.2xlarge | 3 | 29 |
| i7ie.3xlarge | 3 | 29 |
| i7ie.6xlarge | 7 | 60 |
| i7ie.12xlarge | 7 | 60 |
| i7ie.18xlarge | 14 | 120 |
| i7ie.24xlarge | 14 | 120 |
| i7ie.48xlarge | 14 | 120 |
| i7ie.metal-24xl | 14 | 120 |
| i7ie.metal-48xl | 14 | 120 |
| i8g.large | 2 | 10 |
| i8g.xlarge | 3 | 20 |
| i8g.2xlarge | 3 | 40 |
| i8g.4xlarge | 7 | 60 |
| i8g.8xlarge | 7 | 60 |
| i8g.12xlarge | 7 | 60 |
| i8g.16xlarge | 14 | 120 |
| i8g.24xlarge | 14 | 120 |
| i8g.48xlarge | 14 | 120 |
| i8g.metal-24xl | 14 | 120 |
| i8g.metal-48xl | 14 | 120 |
| i8ge.large | 2 | 20 |
| i8ge.xlarge | 3 | 29 |
| i8ge.2xlarge | 3 | 29 |
| i8ge.3xlarge | 5 | 29 |
| i8ge.6xlarge | 9 | 60 |
| i8ge.12xlarge | 11 | 60 |
| i8ge.18xlarge | 15 | 120 |
| i8ge.24xlarge | 15 | 120 |
| i8ge.48xlarge | 23 | 120 |
| i8ge.metal-24xl | 15 | 120 |
| i8ge.metal-48xl | 23 | 120 |
| im4gn.large | 2 | 10 |
| im4gn.xlarge | 3 | 20 |
| im4gn.2xlarge | 3 | 40 |
| im4gn.4xlarge | 7 | 60 |
| im4gn.8xlarge | 7 | 60 |
| im4gn.16xlarge | 14 | 120 |
| is4gen.medium | 1 | 4 |
| is4gen.large | 2 | 10 |
| is4gen.xlarge | 3 | 20 |
| is4gen.2xlarge | 3 | 40 |
| is4gen.4xlarge | 7 | 60 |
| is4gen.8xlarge | 7 | 60 |
## Calcul accéléré
| Type d’instance | Limite de tâche sans jonction ENI | Limite de tâche avec jonction ENI |
| --- | --- | --- |
| dl1.24xlarge | 59 | 120 |
| dl2q.24xlarge | 14 | 120 |
| f2.6xlarge | 7 | 90 |
| f2.12xlarge | 7 | 120 |
| f2.48xlarge | 14 | 120 |
| g4ad.xlarge | 1 | 12 |
| g4ad.2xlarge | 1 | 12 |
| g4ad.4xlarge | 2 | 12 |
| g4ad.8xlarge | 3 | 12 |
| g4ad.16xlarge | 7 | 12 |
| g5.xlarge | 3 | 6 |
| g5.2xlarge | 3 | 19 |
| g5.4xlarge | 7 | 40 |
| g5.8xlarge | 7 | 90 |
| g5.12xlarge | 14 | 120 |
| g5.16xlarge | 7 | 120 |
| g5.24xlarge | 14 | 120 |
| g5.48xlarge | 6 | 120 |
| g5g.xlarge | 3 | 20 |
| g5g.2xlarge | 3 | 40 |
| g5g.4xlarge | 7 | 60 |
| g5g.8xlarge | 7 | 60 |
| g5g.16xlarge | 14 | 120 |
| g5g.metal | 14 | 120 |
| g6.xlarge | 3 | 20 |
| g6.2xlarge | 3 | 40 |
| g6.4xlarge | 7 | 60 |
| g6.8xlarge | 7 | 90 |
| g6.12xlarge | 7 | 120 |
| g6.16xlarge | 14 | 120 |
| g6.24xlarge | 14 | 120 |
| g6.48xlarge | 14 | 120 |
| g6e.xlarge | 3 | 20 |
| g6e.2xlarge | 3 | 40 |
| g6e.4xlarge | 7 | 60 |
| g6e.8xlarge | 7 | 90 |
| g6e.12xlarge | 9 | 120 |
| g6e.16xlarge | 14 | 120 |
| g6e.24xlarge | 19 | 120 |
| g6e.48xlarge | 39 | 120 |
| g6f.large | 1 | 10 |
| g6f.xlarge | 3 | 20 |
| g6f.2xlarge | 3 | 40 |
| g6f.4xlarge | 7 | 60 |
| gr6.4xlarge | 7 | 60 |
| gr6.8xlarge | 7 | 90 |
| gr6f.4xlarge | 7 | 60 |
| g7e.2xlarge | 3 | 242 |
| g7e.4xlarge | 7 | 242 |
| 7e x 8 x large | 7 | 242 |
| G7E, 12 x large | 9 | 242 |
| g7e x 24 x large | 19 | 242 |
| g7e 48 x large | 39 | 242 |
| inf2.xlarge | 3 | 20 |
| inf2.8xlarge | 7 | 90 |
| inf2.24xlarge | 14 | 120 |
| inf2.48xlarge | 14 | 120 |
| p4d.24xlarge | 59 | 120 |
| p4de.24xlarge | 59 | 120 |
| p5.4xlarge | 3 | 60 |
| p5.48xlarge | 63 | 242 |
| p5e.48xlarge | 63 | 242 |
| p5en.48xlarge | 63 | 242 |
| p6-b200.48xlarge | 31 | 242 |
| p6-b 300,48 x large | 67 | 242 |
| p6e-gb200.36xlarge | 38 | 120 |
| trn1.2xlarge | 3 | 19 |
| trn1.32xlarge | 39 | 120 |
| trn1n.32xlarge | 79 | 242 |
| trn 2,3 x large | 1 | 14 |
| trn2.48xlarge | 31 | 242 |
| trn2u.48xlarge | 31 | 242 |
| vt1.3xlarge | 3 | 40 |
| vt1.6xlarge | 7 | 60 |
| vt1.24xlarge | 14 | 120 |
## Calcul haute performance
| Type d’instance | Limite de tâche sans jonction ENI | Limite de tâche avec jonction ENI |
| --- | --- | --- |
| hpc6a.48xlarge | 1 | 120 |
| hpc6id.32xlarge | 1 | 120 |
| hpc7g.4xlarge | 3 | 120 |
| hpc7g.8xlarge | 3 | 120 |
| hpc7g.16xlarge | 3 | 120 |
| HP C8A. 96 x large | 3 | -2 |
# Réservation de mémoire pour une instance de conteneur Amazon ECS Linux
Lorsque l’agent de conteneur Amazon ECS enregistre une instance de conteneur dans un cluster, il doit déterminer la quantité de mémoire disponible que l’instance de conteneur peut réserver pour vos tâches. En raison de la surcharge de mémoire de la plateforme et de la mémoire utilisée par le noyau du système, ce nombre est différent de la quantité de mémoire installée qui est annoncée pour les instances Amazon EC2. Par exemple, une instance `m4.large` a 8 Gio de mémoire installée. Toutefois, cela n’équivaut pas toujours exactement à 8 192 Mio de mémoire disponible pour les tâches lorsque l’instance de conteneur s’enregistre.
## Détermination des ressources de mémoire des instances gérées ECS
Les instances gérées Amazon ECS utilisent une approche hiérarchique pour déterminer les besoins en ressources de mémoire pour les tâches. Contrairement à ECS sur EC2 qui repose sur l'introspection de la mémoire de Docker, ECS Managed Instances calcule les besoins en mémoire directement à partir de la charge utile des tâches lors des décisions de planification.
Lorsque l'agent ECS Managed Instances reçoit une tâche, il calcule la mémoire requise en utilisant l'ordre de priorité suivant :
1. **Mémoire au niveau des tâches (priorité la plus élevée)** : si la mémoire au niveau des tâches est spécifiée dans la définition des tâches, l'agent utilise directement cette valeur. Cela a priorité sur tous les paramètres de mémoire au niveau du conteneur.
1. **Somme de mémoire au niveau du conteneur (solution de secours)** : si la mémoire au niveau de la tâche n'est pas spécifiée (ou vaut 0), l'agent fait la somme des besoins en mémoire de tous les conteneurs de la tâche. Pour chaque contenant, il utilise :
1. *Réservation de mémoire (limite souple)* : si un conteneur le spécifie `memoryReservation` dans sa configuration, l'agent utilise cette valeur.
1. *Mémoire du conteneur (limite stricte)* - Si `memoryReservation` ce n'est pas spécifié, l'agent utilise le `memory` champ du conteneur.
**Example Mémoire au niveau des tâches spécifiée**
Lorsque la mémoire au niveau des tâches est spécifiée, elle a priorité sur les paramètres au niveau du conteneur :
```
{
"family": "my-task",
"memory": "2048",
"containerDefinitions": [
{
"name": "container1",
"memory": 1024,
"memoryReservation": 512
}
]
}
```
L'agent réserve 2048 MiB (la mémoire au niveau des tâches est prioritaire).
**Example Mémoire au niveau du conteneur avec réservations**
Lorsque la mémoire au niveau des tâches n'est pas spécifiée, l'agent additionne les besoins en mémoire du conteneur :
```
{
"family": "my-task",
"containerDefinitions": [
{
"name": "container1",
"memory": 1024,
"memoryReservation": 512
},
{
"name": "container2",
"memory": 512
}
]
}
```
L'agent réserve 512 Mo (réservation conteneur1) \$1 512 Mo (conteneur2 mémoire) = 1024 Mo au total.
L'agent ECS Managed Instances effectue le calcul de la mémoire en trois phases :
1. **Réception de tâches** - Lorsqu'une charge utile de tâche arrive depuis le plan de contrôle ECS, l'agent calcule immédiatement la mémoire requise.
1. **Stockage des ressources** - La mémoire requise calculée est stockée dans le modèle de tâche pour être utilisée ultérieurement dans les opérations de comptabilité des ressources.
1. **Décision de planification** - Avant d'accepter une tâche, l'agent vérifie si suffisamment de mémoire est disponible. Si la mémoire disponible est insuffisante, la tâche est rejetée et reste dans la file d'attente du service ECS jusqu'à ce que les ressources soient disponibles.
**Note**
Contrairement à ECS sur EC2, ECS Managed Instances n'utilise pas la variable `ECS_RESERVED_MEMORY` de configuration. La réservation de mémoire pour les processus du système est gérée par le biais de la gestion des ressources de la plate-forme sous-jacente, et l'agent effectue une comptabilité précise des ressources en fonction des définitions de tâches.
Pour ECS sur EC2, l'agent de conteneur Amazon ECS fournit une variable de configuration appelée`ECS_RESERVED_MEMORY`, que vous pouvez utiliser pour supprimer un nombre spécifié de MiB de mémoire du pool alloué à vos tâches. Cela réserve de manière effective cette quantité de mémoire pour les processus système critiques.
Si vous occupez la totalité de la mémoire sur une instance de conteneur avec vos tâches, il est alors possible que vos tâches se disputent la mémoire avec les processus système critiques, ce qui peut provoquer une défaillance du système.
Par exemple, si vous spécifiez `ECS_RESERVED_MEMORY=256` dans votre fichier de configuration de l'agent de conteneur, l'agent enregistre la mémoire totale, moins 256 Mio pour cette instance. 256 Mio de mémoire ne sont donc pas allouées par des tâches ECS. Pour plus d'informations sur les variables de configuration de l'agent et la façon de les définir, consultez [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md) et [Démarrage des instances de conteneurs Amazon ECS Linux pour transmettre des données](bootstrap_container_instance.md).
Si vous spécifiez 8 192 Mio pour la tâche et qu’aucune de vos instances de conteneur ne dispose d’au moins 8 192 Mio de mémoire disponible pour répondre à cette exigence, la tâche ne peut pas être placée dans votre cluster. Si vous utilisez un environnement informatique géré, vous AWS Batch devez lancer un type d'instance plus important pour répondre à la demande.
L'agent de conteneur Amazon ECS utilise la fonction `ReadMemInfo()` Docker pour connaître la mémoire totale disponible pour le système d'exploitation. Linux et Windows fournissent tous deux des utilitaires de ligne de commande pour déterminer la mémoire totale.
**Example - Déterminer la mémoire totale Linux**
La commande **free** renvoie la mémoire totale reconnue par le système d'exploitation.
```
$ free -b
```
Exemple de sortie d'une instance `m4.large` exécutant l'AMI Amazon Linux optimisée pour Amazon ECS.
```
total used free shared buffers cached
Mem: 8373026816 348180480 8024846336 90112 25534464 205418496
-/+ buffers/cache: 117227520 8255799296
```
Cette instance comporte 8373026816 octets de mémoire totale, soit 7 985 Mio disponible pour les tâches.
**Example - Déterminer la mémoire totale Windows**
La commande **wmic** renvoie la mémoire totale reconnue par le système d'exploitation.
```
C:\> wmic ComputerSystem get TotalPhysicalMemory
```
Exemple de sortie d’une instance `m4.large` exécutant l’AMI Windows Server optimisée pour Amazon ECS.
```
TotalPhysicalMemory
8589524992
```
Cette instance comporte 8589524992 octets de mémoire totale, soit 8 191 Mio disponible pour les tâches.
## Affichage de la mémoire d’une instance de conteneur
Vous pouvez voir la quantité de mémoire utilisée par une instance de conteneur dans la console Amazon ECS (ou dans le cadre de l'opération [DescribeContainerInstances](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeContainerInstances.html)API). 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, vous pouvez observer la mémoire disponible pour cette instance de conteneur, puis attribuer autant de mémoire à vos tâches.
**Pour afficher la mémoire d’une 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 panneau de navigation, choisissez **Clusters**, puis sélectionnez le cluster qui héberge votre instance de conteneur.
1. Choisissez **Infrastructure**, puis sous les instances de conteneur, choisissez une instance de conteneur.
1. La section **Ressources** indique la mémoire enregistrée et la mémoire disponible pour l’instance de conteneur.
La valeur de mémoire **Enregistrée** correspond à l’instance de conteneur enregistrée auprès d’Amazon ECS lors de son premier lancement, tandis que la valeur de mémoire **Disponible** correspond à la mémoire qui n’a pas encore été allouée à des tâches.
# Gestion à distance des instances de conteneur Amazon ECS à l'aide de AWS Systems Manager
Vous pouvez utiliser la fonctionnalité Run Command dans AWS Systems Manager (Systems Manager) pour gérer de manière sécurisée et à distance la configuration de vos instances de conteneur Amazon ECS. Exécutez la commande vous fournit des outils simples afin d'effectuer des tâches administratives courantes sans qu'il soit nécessaire de se connecter localement à l'instance. Vous pouvez gérer les changements de configuration sur vos clusters en exécutant des commandes simultanément sur plusieurs instances de conteneur. La fonctionnalité Exécuter la commande affiche le statut et les résultats de chaque commande.
Voici quelques exemples des types de tâches susceptibles d'être effectués avec la fonctionnalité Exécuter la commande :
+ Installer ou désinstaller des packages
+ Effectuer des mises à jour de sécurité
+ Nettoyer les images Docker
+ Arrêter ou démarrer des services
+ Afficher les ressources système
+ Afficher les fichiers journaux
+ Effectuer des opérations sur les fichiers
Pour plus d'informations sur Run Command, veuillez consulter [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) dans le *Guide de l'utilisateur AWS Systems Manager *.
Les conditions suivantes sont requises pour utiliser Systems Manager avec Amazon ECS.
1. Vous devez accorder à l'instance de conteneur role (**ecsInstanceRole**) les autorisations d'accès au Systems Manager APIs. Vous pouvez le faire en affectant l'**Amazon SSMManaged InstanceCore** au `ecsInstanceRole` rôle. Pour plus d’informations sur la manière d’associer une politique à un rôle, consultez la section [Modification des autorisations pour un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) dans le *Guide de l’utilisateur Gestion des identités et des accès AWS *.
1. Vérifier que SSM Agent est installé sur vos instances de conteneur. Pour plus d’informations, consultez la section [Installation et désinstallation manuelle de l’agent SSM sur les instances EC2 pour Linux](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html).
Après avoir attaché les politiques gérées par Systems Manager à vos instances de conteneur `ecsInstanceRole` et vérifié que AWS Systems Manager l'agent (agent SSM) est installé sur vos instances de conteneur, vous pouvez commencer à utiliser Run Command pour envoyer des commandes à vos instances de conteneur. Pour de plus amples informations sur l'exécution des commandes et des scripts shell sur vos instances et pour afficher la sortie obtenue, veuillez consulter [Exécution de commandes avec Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) et [Procédures Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command-walkthroughs.html) dans le *Guide de l'utilisateur AWS Systems Manager *.
Un cas d’utilisation courant consiste à mettre à jour le logiciel d’instance de conteneur avec Exécuter une commande. Vous pouvez suivre les procédures décrites dans le guide de l' AWS Systems Manager utilisateur avec les paramètres suivants.
| Paramètre | Value |
| --- | --- |
| **Document de commande** | AWS-RunShellScript |
| Commande | $ yum update -y
|
| Instances cibles | Vos instances de conteneur |
# Utilisation d’un proxy HTTP pour les instances de conteneur Amazon ECS Linux
Vous pouvez configurer vos instances de conteneur Amazon ECS pour qu'elles utilisent un proxy HTTP pour l'agent de conteneur Amazon ECS et le démon Docker. C'est utile si vos instances de conteneur n'ont pas accès au réseau externe via une passerelle Internet Amazon VPC, une instance ou une passerelle NAT.
Pour configurer votre instance de conteneur Linux Amazon ECS afin qu'elle utilise un proxy HTTP, définissez les variables suivantes dans les fichiers appropriés lors du lancement (avec les données utilisateur Amazon EC2). Vous pouvez également modifier manuellement le fichier de configuration, puis redémarrer l’agent.
`/etc/ecs/ecs.config`(Amazon Linux 2et AmazonLinux AMI)
`HTTP_PROXY=10.0.0.131:3128`
Pour cette valeur, employez le nom d'hôte (ou l'adresse IP) et le numéro de port d'un proxy HTTP à utiliser pour que l'agent Amazon ECS puisse se connecter à Internet. Par exemple, vos instances de conteneur n'ont peut-être pas accès au réseau externe via une passerelle Internet Amazon VPC, une instance ou une passerelle NAT.
`NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock`
Utilisez la valeur `169.254.169.254,169.254.170.2,/var/run/docker.sock` pour filtrer des métadonnées d'instance EC2, les rôles IAM et le trafic du démon Docker en provenance du proxy.
`/etc/systemd/system/ecs.service.d/http-proxy.conf` (Amazon Linux 2 uniquement)
`Environment="HTTP_PROXY=10.0.0.131:3128/"`
Pour cette valeur, employez le nom d'hôte (ou l'adresse IP) et le numéro de port d'un proxy HTTP à utiliser pour que `ecs-init` puisse se connecter à Internet. Par exemple, vos instances de conteneur n'ont peut-être pas accès au réseau externe via une passerelle Internet Amazon VPC, une instance ou une passerelle NAT.
`Environment="NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock"`
Utilisez la valeur `169.254.169.254,169.254.170.2,/var/run/docker.sock` pour filtrer des métadonnées d'instance EC2, les rôles IAM et le trafic du démon Docker en provenance du proxy.
`/etc/init/ecs.override` (Amazon Linux AMI uniquement)
`env HTTP_PROXY=10.0.0.131:3128`
Pour cette valeur, employez le nom d'hôte (ou l'adresse IP) et le numéro de port d'un proxy HTTP à utiliser pour que `ecs-init` puisse se connecter à Internet. Par exemple, vos instances de conteneur n'ont peut-être pas accès au réseau externe via une passerelle Internet Amazon VPC, une instance ou une passerelle NAT.
`env NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock`
Utilisez la valeur `169.254.169.254,169.254.170.2,/var/run/docker.sock` pour filtrer des métadonnées d'instance EC2, les rôles IAM et le trafic du démon Docker en provenance du proxy.
`/etc/systemd/system/docker.service.d/http-proxy.conf` (Amazon Linux 2 uniquement)
`Environment="HTTP_PROXY=http://10.0.0.131:3128"`
Pour cette valeur, employez le nom d'hôte (ou l'adresse IP) et le numéro de port d'un proxy HTTP à utiliser pour que le démon Docker puisse se connecter à Internet. Par exemple, vos instances de conteneur n'ont peut-être pas accès au réseau externe via une passerelle Internet Amazon VPC, une instance ou une passerelle NAT.
`Environment="NO_PROXY=169.254.169.254,169.254.170.2"`
Utilisez la valeur `169.254.169.254,169.254.170.2` pour filtrer les métadonnées d'instance EC2 issues du proxy.
`/etc/sysconfig/docker` (Amazon Linux AMI et Amazon Linux 2 uniquement)
`export HTTP_PROXY=http://10.0.0.131:3128`
Pour cette valeur, employez le nom d'hôte (ou l'adresse IP) et le numéro de port d'un proxy HTTP à utiliser pour que le démon Docker puisse se connecter à Internet. Par exemple, vos instances de conteneur n'ont peut-être pas accès au réseau externe via une passerelle Internet Amazon VPC, une instance ou une passerelle NAT.
`export NO_PROXY=169.254.169.254,169.254.170.2`
Utilisez la valeur `169.254.169.254,169.254.170.2` pour filtrer les métadonnées d'instance EC2 issues du proxy.
La définition de ces variables d'environnement dans les fichiers ci-dessus affecte uniquement l'agent de conteneur Amazon ECS, `ecs-init`, et le démon Docker. Elles ne configurent aucun autre service (comme **yum**) pour utiliser le proxy.
Pour plus d'informations sur la configuration du proxy, consultez [Comment configurer un proxy HTTP pour Docker et l'agent de conteneur Amazon ECS dans Amazon Linux 2](https://repost.aws/knowledge-center/ecs-http-proxy-docker-linux2) ou. AL2023
# Configuration d’instances préinitialisées pour votre groupe Auto Scaling Amazon ECS
Amazon ECS prend en charge les groupes d'instances pré-initialisées Amazon EC2 Auto Scaling. Un groupe d'instances pré-initialisées est un groupe d'instances Amazon EC2 pré-initialisées prêtes à être mises en service. Chaque fois que votre application doit monter en puissance, Amazon EC2 Auto Scaling utilise les instances pré-initialisées du groupe d'instances pré-initialisées plutôt que de lancer des instances froides, permet l'exécution de tout processus d'initialisation final, puis met l'instance en service.
Pour en savoir plus sur les groupes instances pré-initialisées et comment les ajouter à votre groupe Auto Scaling, consultez la section [Groupes d'instances pré-initialisées pour Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html) *dans le Guide de l'utilisateur Amazon EC2 Auto Scaling*.
Lorsque vous créez ou mettez à jour un groupe instances pré-initialisées pour un groupe Auto Scaling pour Amazon ECS, vous ne pouvez pas définir l'option qui renvoie les instances vers le groupe instances pré-initialisées à mise à l'échelle horizontale (`ReuseOnScaleIn`). Pour plus d'informations, consultez [put-warm-pool](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-warm-pool.html) dans la *référence AWS Command Line Interface *.
Pour utiliser des groupes d'instances pré-initialisées avec votre cluster Amazon ECS, définissez la variable de configuration de l'agent `ECS_WARM_POOLS_CHECK` sur `true` dans le champ **User data** (Données utilisateur) du modèle de lancement de votre groupe Amazon EC2 Auto Scaling.
Voici un exemple de la façon dont la variable de configuration de l'agent peut être spécifiée dans le champ **User data** (Données utilisateur) d'un modèle de lancement Amazon EC2. Remplacez *MyCluster* par le nom de votre cluster.
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_WARM_POOLS_CHECK=true
EOF
```
La variable `ECS_WARM_POOLS_CHECK` est uniquement prise en charge sur les versions d'agent `1.59.0` et ultérieures. Pour plus d'informations sur la variable, veuillez consulter [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md).
# Mise à jour de l'agent de conteneur Amazon ECS
L’agent de conteneur Amazon ECS doit parfois être mis à jour afin d’obtenir les correctifs de bogues et les nouvelles fonctions. La mise à jour de l'agent de conteneur Amazon ECS n'interrompt pas les tâches ou les services en cours d'exécution sur l'instance de conteneur. Le processus de mise à jour de l'agent varie selon si votre instance de conteneur a été lancée avec l'AMI optimisée pour Amazon ECS ou un autre système d'exploitation.
**Note**
Les mises à jour de l'agent ne s'appliquent pas aux instances de conteneur Windows. Nous vous recommandons de lancer de nouvelles instances de conteneur pour mettre à jour le version de l'agent dans vos clusters Windows.
## Vérification de la version d'agent de conteneur Amazon ECS
Vous pouvez vérifier la version de l'agent de conteneur qui est en cours d'exécution sur vos instances de conteneur afin de savoir s'il doit être mis à jour. L'affichage d'une instance de conteneur dans la console Amazon ECS fournit la version de l'agent. Procédez comme indiqué ci-dessous pour vérifier la version de votre agent.
------
#### [ 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 dans laquelle votre instance externe est inscrite.
1. Dans le panneau de navigation, choisissez **Clusters**, puis sélectionnez le cluster qui héberge l'instance externe.
1. Sur la *name* page **Cluster :**, choisissez l'onglet **Infrastructure**.
1. Sous **Container instances** (Instances de conteneur), notez la colonne **Agent version** (Version d'agent) pour vos instances de conteneur. Si l'instance de conteneur ne contient pas la dernière version de l'agent de conteneur, la console vous prévient à l'aide d'un message et signale la version d'agent obsolète.
Si votre version d'agent est obsolète, vous pouvez la mettre à jour en suivant les instructions ci-dessous :
+ Si votre instance de conteneur exécute l'AMI optimisée pour Amazon ECS, veuillez consulter [Mise à jour de l'agent de conteneur Amazon ECS sur une AMI optimisée pour Amazon ECS](agent-update-ecs-ami.md).
+ Si votre instance de conteneur n'exécute pas une AMI optimisée pour Amazon ECS, veuillez consulter [Mise à jour manuelle de l'agent de conteneur Amazon ECS (pour les applications non optimisées pour Amazon ECS AMIs)](manually_update_agent.md).
**Important**
Pour mettre à jour la version de l'agent Amazon ECS à partir des versions antérieures à v1.0.0 sur votre AMI optimisée pour Amazon ECS, nous vous recommandons de résilier votre instance de conteneur actuelle et de lancer une nouvelle instance avec la version d'AMI la plus récente. Toutes les instances de conteneur qui utilisent une version précédente doivent être retirées et remplacées par l'AMI la plus récente. Pour de plus amples informations, veuillez consulter [Lancement d'une instance de conteneur Amazon ECS Linux](launch_container_instance.md).
------
#### [ Amazon ECS container agent introspection API ]
Vous pouvez également utiliser l'API d'introspection d'agent de conteneur Amazon ECS pour vérifier la version de l'agent à partir de l'instance de conteneur elle-même. Pour de plus amples informations, veuillez consulter [Introspection de conteneur Amazon ECS](ecs-agent-introspection.md).
**Pour vérifier si votre agent de conteneur Amazon ECS exécute la dernière version avec l'API d'introspection**
1. Connectez-vous à votre instance de conteneur via SSH.
1. Interrogez l'API d'introspection.
```
[ec2-user ~]$ curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
```
**Note**
L'API d'introspection a ajouté les informations `Version` dans la version v1.0.0 de l'agent de conteneur Amazon ECS. Si `Version` n'apparaît pas lors de l'interrogation de l'API d'introspection ou que l'API d'introspection n'apparaît pas du tout dans votre agent, la version que vous exécutez est v0.0.3 ou une version antérieure. Vous devez mettre à jour votre version.
------
# Mise à jour de l'agent de conteneur Amazon ECS sur une AMI optimisée pour Amazon ECS
Si vous utilisez l'AMI optimisée pour Amazon ECS, vous disposez de plusieurs options pour obtenir la dernière version de l'agent de conteneur Amazon ECS (présentées dans l'ordre de recommandation) :
+ Résiliez l'instance de conteneur et lancez la dernière version de l'AMI Amazon Linux 2 optimisée pour Amazon ECS (manuellement ou en mettant à jour votre configuration du lancement Auto Scaling avec la dernière AMI). Cette opération fournit une instance de conteneur propre avec les versions les plus récemment testées et validées d'Amazon Linux, de Docker, d'`ecs-init` et de l'agent de conteneur Amazon ECS. Pour de plus amples informations, veuillez consulter [Linux optimisé pour Amazon ECS AMIs](ecs-optimized_AMI.md).
+ Connectez-vous à l'instance avec SSH et mettez à jour le package `ecs-init` (et ses dépendances) vers la dernière version. Cette opération fournit les versions les plus récemment testées et validées de Docker et d'`ecs-init` disponibles dans les référentiels Amazon Linux et la dernière version de l'agent de conteneur Amazon ECS. Pour de plus amples informations, veuillez consulter [Pour mettre à jour le package `ecs-init` sur une AMI optimisée pour Amazon ECS](#procedure_update_ecs-init).
+ Mettez à jour l'agent de conteneur avec l'opération d'`UpdateContainerAgent`API, soit via la console, soit avec le AWS CLI ou AWS SDKs. Pour de plus amples informations, veuillez consulter [Mise à jour de l'agent de conteneur Amazon ECS avec l'opération d'API `UpdateContainerAgent`](#agent-update-api).
**Note**
Les mises à jour de l'agent ne s'appliquent pas aux instances de conteneur Windows. Nous vous recommandons de lancer de nouvelles instances de conteneur pour mettre à jour le version de l'agent dans vos clusters Windows.
**Pour mettre à jour le package `ecs-init` sur une AMI optimisée pour Amazon ECS**
1. Connectez-vous à votre instance de conteneur via SSH.
1. Mettez à jour le package `ecs-init` avec la commande suivante.
```
sudo yum update -y ecs-init
```
**Note**
Le package `ecs-init` et l'agent de conteneur Amazon ECS sont mis à jour immédiatement. Cependant, les versions les plus récentes de Docker ne sont pas chargées tant que le démon Docker n'est pas redémarré. Redémarrez en relançant l'instance ou en exécutant les commandes suivantes sur votre instance :
AMI Amazon Linux 2 optimisée pour Amazon ECS :
```
sudo systemctl restart docker
```
AMI Amazon Linux optimisée pour Amazon ECS :
```
sudo service docker restart && sudo start ecs
```
## Mise à jour de l'agent de conteneur Amazon ECS avec l'opération d'API `UpdateContainerAgent`
**Important**
L'API `UpdateContainerAgent` n'est prise en charge que sur les variantes Linux de l'AMI optimisée pour Amazon ECS, à l'exception de l'AMI Amazon Linux 2 (arm64) optimisée pour Amazon ECS. Pour les instances de conteneur utilisant l'AMI Amazon Linux 2 (arm64) optimisée pour Amazon ECS, mettez à jour le package `ecs-init` pour mettre à jour l'agent. Pour les instances de conteneur qui exécutent d'autres systèmes d'exploitation, consultez la page [Mise à jour manuelle de l'agent de conteneur Amazon ECS (pour les applications non optimisées pour Amazon ECS AMIs)](manually_update_agent.md). Si vous utilisez des instances de conteneur Windows, nous vous recommandons de lancer de nouvelles instances de conteneur pour mettre à jour le version de l'agent dans vos clusters Windows.
Le processus `UpdateContainerAgent` d'API commence lorsque vous demandez une mise à jour de l'agent, soit via la console, soit avec le AWS CLI ou AWS SDKs. Amazon ECS vérifie la version actuelle de votre agent par rapport à la dernière version disponible, et détermine si une mise à jour est possible. Si aucune mise à jour n'est disponible, si l'agent exécute déjà par exemple la version la plus récente, le message `NoUpdateAvailableException` est renvoyé.
Les étapes du processus de mise à jour ci-dessus sont les suivantes :
`PENDING`
Une mise à jour de l'agent est disponible, et le processus de mise à jour a commencé.
`STAGING`
L'agent a commencé le téléchargement de la mise à jour. Si l'agent ne peut pas télécharger la mise à jour, ou si le contenu de la mise à jour est incorrect ou endommagé, l'agent envoie une notification de l'échec et la mise à jour passe en état `FAILED`.
`STAGED`
Le téléchargement est terminé et le contenu de l'agent a été vérifié.
`UPDATING`
Le service `ecs-init` est redémarré et il récupère la nouvelle version de l'agent. Si, pour une raison quelconque, l'agent est incapable de redémarrer, la mise à jour passe à l'état `FAILED`. Dans le cas contraire, l'agent indique à Amazon ECS que la mise à jour est terminée.
**Note**
Les mises à jour de l'agent ne s'appliquent pas aux instances de conteneur Windows. Nous vous recommandons de lancer de nouvelles instances de conteneur pour mettre à jour le version de l'agent dans vos clusters Windows.
**Pour mettre à jour l'agent de conteneur Amazon ECS sur une AMI optimisée pour Amazon ECS dans la 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 dans laquelle votre instance externe est inscrite.
1. Dans le panneau de navigation, choisissez **Clusters** et sélectionnez le cluster.
1. Sur la *name* page **Cluster :**, choisissez l'onglet **Infrastructure**.
1. Sous **Instances de conteneur**, sélectionnez les instances à mettre à jour, puis choisissez **Actions** et **Mettre à jour l'agent**.
# Mise à jour manuelle de l'agent de conteneur Amazon ECS (pour les applications non optimisées pour Amazon ECS AMIs)
L’agent de conteneur Amazon ECS doit parfois être mis à jour afin d’obtenir les correctifs de bogues et les nouvelles fonctions. La mise à jour de l'agent de conteneur Amazon ECS n'interrompt pas les tâches ou les services en cours d'exécution sur l'instance de conteneur.
**Note**
Les mises à jour de l'agent ne s'appliquent pas aux instances de conteneur Windows. Nous vous recommandons de lancer de nouvelles instances de conteneur pour mettre à jour le version de l'agent dans vos clusters Windows.
1. Connectez-vous à votre instance de conteneur via SSH.
1. Vérifiez si votre agent utilise la variable d'environnement `ECS_DATADIR` pour enregistrer son état.
```
ubuntu:~$ docker inspect ecs-agent | grep ECS_DATADIR
```
Sortie :
```
"ECS_DATADIR=/data",
```
**Important**
Si la commande précédente ne renvoie pas la variable d'environnement `ECS_DATADIR`, vous devez arrêter toutes les tâches en cours d'exécution sur cette instance de conteneur avant de mettre à jour votre agent. Les agents récents avec la variable d'environnement `ECS_DATADIR` enregistrent leur état et sont possibles à mettre à jour sans problèmes tandis que les tâches sont en cours d'exécution.
1. Arrêtez l'agent de conteneur Amazon ECS.
```
ubuntu:~$ docker stop ecs-agent
```
1. Supprimez le conteneur de l'agent.
```
ubuntu:~$ docker rm ecs-agent
```
1. Vérifiez que le répertoire `/etc/ecs` et le fichier de configuration de l'agent de conteneur Amazon ECS existent à l'emplacement `/etc/ecs/ecs.config`.
```
ubuntu:~$ sudo mkdir -p /etc/ecs && sudo touch /etc/ecs/ecs.config
```
1. Modifiez le fichier `/etc/ecs/ecs.config` et vérifiez qu'il contient au moins les déclarations de variable suivantes. Pour que votre instance de conteneur ne s'inscrive pas auprès du cluster par défaut, spécifiez le nom de votre cluster comme valeur pour `ECS_CLUSTER`.
```
ECS_DATADIR=/data
ECS_ENABLE_TASK_IAM_ROLE=true
ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=true
ECS_LOGFILE=/log/ecs-agent.log
ECS_AVAILABLE_LOGGING_DRIVERS=["json-file","awslogs"]
ECS_LOGLEVEL=info
ECS_CLUSTER=default
```
Pour plus d'informations sur ces options ainsi que d'autres options d'exécution d'agents, consultez la page [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md).
**Note**
Vous pouvez éventuellement stocker vos variables d'environnement d'agent dans Amazon S3. Elles pourront être téléchargées dans vos instances de conteneur lors du lancement à l'aide des données utilisateur Amazon EC2. Ceci est particulièrement conseillé pour les informations sensibles, telles que les informations d'authentification pour les référentiels privés. Pour plus d’informations, consultez [Stockage de la configuration d’instance de conteneur Amazon ECS dans Amazon S3](ecs-config-s3.md) et [Utilisation d'images autres que des AWS conteneurs dans Amazon ECS](private-auth.md).
1. Extrayez la dernière image de l'agent de conteneur Amazon ECS depuis Amazon Elastic Container Registry Public.
```
ubuntu:~$ docker pull public.ecr.aws/ecs/amazon-ecs-agent:latest
```
Sortie :
```
Pulling repository amazon/amazon-ecs-agent
a5a56a5e13dc: Download complete
511136ea3c5a: Download complete
9950b5d678a1: Download complete
c48ddcf21b63: Download complete
Status: Image is up to date for amazon/amazon-ecs-agent:latest
```
1. Exécutez l'agent de conteneur Amazon ECS le plus récent sur votre instance de conteneur.
**Note**
Utilisez les stratégies de redémarrage de Docker ou un gestionnaire de processus (tel que **upstart** ou **systemd**) pour traiter l'agent de conteneur comme un service ou un démon, et vous assurer qu'il est redémarré après avoir été arrêté. L'AMI optimisée pour Amazon ECS utilise le `ecs-init` RPM à cette fin, et vous pouvez consulter le [code source de ce RPM](https://github.com/aws/amazon-ecs-init) sur. GitHub
L'exemple suivant de commande d'exécution d'agent est divisé en lignes distinctes pour montrer chaque option. Pour plus d'informations sur ces options ainsi que d'autres options d'exécution d'agents, consultez la page [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md).
**Important**
Les systèmes d'exploitation sur lesquels cette `--privileged` option est SELinux activée doivent figurer dans votre **docker run** commande. En outre, pour les instances de conteneur SELinux activées, nous vous recommandons d'ajouter l'`:Z`option aux montages de `/data` volume `/log` et. Cependant, les montages hôtes de ces volumes doivent exister avant d'exécuter la commande. Dans le cas contraire, vous recevrez une erreur `no such file or directory`. Procédez comme suit si vous rencontrez des difficultés pour exécuter l'agent Amazon ECS sur une instance de conteneur SELinux activée :
Créez les points de montage des volumes hôtes sur votre instance de conteneur.
```
ubuntu:~$ sudo mkdir -p /var/log/ecs /var/lib/ecs/data
```
Ajoutez l'option `--privileged` à la commande **docker run** ci-dessous.
Ajoutez l'option `:Z` aux montages de volume de conteneur `/log` et `/data` (par exemple, `--volume=/var/log/ecs/:/log:Z`) dans la commande **docker run** ci-dessous.
```
ubuntu:~$ sudo docker run --name ecs-agent \
--detach=true \
--restart=on-failure:10 \
--volume=/var/run:/var/run \
--volume=/var/log/ecs/:/log \
--volume=/var/lib/ecs/data:/data \
--volume=/etc/ecs:/etc/ecs \
--volume=/etc/ecs:/etc/ecs/pki \
--net=host \
--env-file=/etc/ecs/ecs.config \
amazon/amazon-ecs-agent:latest
```
**Note**
Si vous recevez un message `Error response from daemon: Cannot start container`, vous pouvez supprimer le conteneur ayant échoué à l'aide de la commande **sudo docker rm ecs-agent**, puis réessayer d'exécuter l'agent.
# Windows optimisé pour Amazon ECS AMIs
Les modèles optimisés pour Amazon ECS AMIs sont préconfigurés avec les composants nécessaires dont vous avez besoin pour exécuter les charges de travail Amazon ECS. Bien que vous puissiez créer votre propre AMI d'instance de conteneur qui répond aux spécifications de base nécessaires pour exécuter vos charges de travail conteneurisées sur Amazon ECS, les applications optimisées pour Amazon ECS AMIs sont préconfigurées et testées sur Amazon ECS par des ingénieurs. AWS C'est la façon la plus simple de démarrer et d'exécuter rapidement vos conteneurs sur AWS .
Pour chaque variante, les métadonnées d'AMI optimisées pour Amazon ECS peuvent être récupérées par programmation. Ces métadonnées incluent le nom de l'AMI, la version de l'agent de conteneur Amazon ECS et la version d'exécution Amazon ECS qui inclut la version Docker. Pour de plus amples informations, veuillez consulter [Extraction des métadonnées d’AMI Windows optimisée pour Amazon ECS](retrieve-ecs-optimized_windows_AMI.md).
**Important**
Toutes les variantes AMI optimisées pour ECS produites après le mois d’août 2022 feront l’objet d’une migration de Docker EE (Mirantis) vers Docker CE (projet Moby).
Pour garantir que les clients disposent des dernières mises à jour de sécurité par défaut, Amazon ECS gère au moins les trois dernières versions optimisées pour Windows Amazon ECS AMIs. Après avoir publié les nouvelles versions optimisées pour Windows Amazon ECS, AMIs Amazon ECS rend privées les versions optimisées pour Windows Amazon ECS AMIs qui sont plus anciennes. S'il existe une AMI privée à laquelle vous devez accéder, soumettez un ticket auprès du support Cloud.
## Variantes d'AMI optimisées pour Amazon ECS
Les variantes Windows Server suivantes de l'AMI optimisée pour Amazon ECS sont disponibles pour vos instances Amazon EC2.
**Important**
Toutes les variantes AMI optimisées pour ECS produites après le mois d'août migreront de Docker EE (Mirantis) vers Docker CE (projet Moby).
+ **AMI complète pour Windows Server 2025 optimisée pour Amazon ECS**
+ **AMI principale pour Windows Server 2025 optimisée pour Amazon ECS**
+ **AMI Windows Server 2022 Full optimisée pour Amazon ECS**
+ **AMI de Windows Server 2022 Core optimisée pour Amazon ECS**
+ **AMI Windows Server 2019 Full optimisée pour Amazon ECS**
+ **AMI de Windows Server 2019 Core optimisée pour Amazon ECS**
+ **AMI complète de Windows Server 2016 optimisée pour Amazon ECS**
**Important**
Windows Server 2016 ne prend pas en charge la dernière version de Docker, par exemple 25.x.x. Par conséquent, Windows Server 2016 Full ne AMIs recevra pas de correctifs de sécurité ou de bogues pour le moteur d'exécution Docker. Nous vous recommandons de passer à l’une des plateformes Windows suivantes :
Windows Server 2022 Full
Windows Server 2022 Core
Windows Server 2019 Full
Windows Server 2019 Core
Le 9 août 2022, la date de fin de prise en charge de l'AMI Windows Server 20H2 Core optimisée pour Amazon ECS a été atteinte. Aucune nouvelle version de cette AMI ne sera publiée. Pour plus d'informations, consultez les [informations sur la version de Windows Server](https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info).
Windows Server 2025, Windows Server 2022, Windows Server 2019 et Windows Server 2016 sont des versions du canal de maintenance à long terme (LTSC). Windows Server 20H2 est une version Canal semi-annuelle. Pour plus d'informations, consultez les [informations sur la version de Windows Server](https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info).
### Considérations
Voici quelques éléments que vous devez savoir sur les conteneurs Windows Amazon EC2 et Amazon ECS.
+ Les conteneurs Windows ne peuvent pas s'exécuter sur des instances de conteneur Linux, et inversement. Afin de garantir un meilleur placement de la tâche pour les tâches Windows et Linux, gardez les instances de conteneur Windows et Linux dans des clusters distincts et placez uniquement les tâches Windows sur des clusters Windows. Pour vous assurer que les définitions de tâche Windows sont uniquement placées sur des instances Windows, vous pouvez définir la contrainte de placement suivante : `memberOf(ecs.os-type=='windows')`.
+ Les conteneurs Windows sont pris en charge pour les tâches qui utilisent EC2 et Fargate.
+ Les conteneurs Windows et les instances de conteneur ne peuvent pas prendre en charge tous les paramètres de définition de tâche disponibles pour les conteneurs Linux et les instances de conteneur. Certains paramètres ne sont pas du tout pris en charge, tandis que d'autres se comportent différemment sous Windows et Linux. Pour de plus amples informations, veuillez consulter [Différences entre les définitions de tâche Amazon ECS pour les instances EC2 exécutant Windows](windows_task_definitions.md).
+ Pour les rôles IAM pour la fonction des tâches, vous devez configurer vos instances de conteneur Windows pour autoriser la fonction lors du lancement. Vos conteneurs doivent exécuter le PowerShell code fourni lorsqu'ils utilisent cette fonctionnalité. Pour de plus amples informations, veuillez consulter [Configuration supplémentaire d’instance Windows Amazon EC2](task-iam-roles.md#windows_task_IAM_roles).
+ Les rôles IAM pour la fonction des tâches utilisent un proxy d'informations d'identification pour fournir des informations d'identification aux conteneurs. Ce proxy d'informations d'identification occupe le port 80 sur l'instance de conteneur, donc si vous utilisez des rôles IAM pour les tâches, le port 80 n'est pas disponible pour les tâches. Pour les conteneurs de service web, vous pouvez utiliser un Application Load Balancer et un mappage de port dynamique pour fournir des connexions port 80 HTTP standard à vos conteneurs. 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).
+ Les images Docker de Windows Server sont volumineuses (9 Gio). Ainsi, vos instances de conteneur Windows nécessitent plus d'espace de stockage que les instances de conteneur Linux.
+ Pour exécuter un conteneur Windows sur un Windows Server, la version du système d'exploitation de l'image de base du conteneur doit correspondre à celle de l'hôte. Pour plus d'informations, consultez [Compatibilité avec la version du conteneur Windows](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility?tabs=windows-server-2022%2Cwindows-11) sur le site web de documentation Microsoft. Si votre cluster exécute plusieurs versions de Windows, vous pouvez vous assurer qu'une tâche est placée sur une instance EC2 exécutée sur la même version en utilisant la contrainte de placement : `memberOf(attribute:ecs.os-family == WINDOWS_SERVER__)`. Pour de plus amples informations, veuillez consulter [Extraction des métadonnées d’AMI Windows optimisée pour Amazon ECS](retrieve-ecs-optimized_windows_AMI.md).
# Extraction des métadonnées d’AMI Windows optimisée pour Amazon ECS
L'ID de l'AMI, le nom de l'image, le système d'exploitation, la version de l'agent de conteneur et la version d'exécution de chaque variante d'Amazon ECS-Optimized AMIs peuvent être récupérés par programmation en interrogeant l'API du magasin de paramètres de Systems Manager. Pour plus d'informations sur l'API Systems Manager Parameter Store, reportez-vous aux sections [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html)et [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html).
**Note**
Votre compte administratif doit avoir les autorisations IAM suivantes pour extraire les métadonnées d'AMI optimisée pour Amazon ECS. Ces autorisations ont été ajoutées à la politique IAM `AmazonECS_FullAccess`.
SMS : GetParameters
SMS : GetParameter
SMS : GetParametersByPath
## Format de paramètre Systems Manager Parameter Store
**Note**
Les paramètres de l'API Systems Manager Parameter Store suivants sont obsolètes et ne doivent pas être utilisés pour récupérer la dernière version de Windows : AMIs
`/aws/service/ecs/optimized-ami/windows_server/2016/english/full/recommended/image_id `
`/aws/service/ecs/optimized-ami/windows_server/2019/english/full/recommended/image_id`
Les informations ci-dessous présentent le format de nom de paramètre pour chaque variante d'AMI optimisée pour Amazon ECS.
+ Métadonnées de l’AMI Windows Server 2025 Full :
```
/aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized
```
+ Métadonnées de l’AMI Windows Server 2025 Core :
```
/aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized
```
+ Métadonnées de l'AMI Windows Server 2022 Full :
```
/aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized
```
+ Métadonnées de l'AMI Windows Server 2022 Core :
```
/aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized
```
+ Métadonnées de l'AMI Windows Server 2019 Full :
```
/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
```
+ Métadonnées de l'AMI principale de Windows Server 2019 :
```
/aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized
```
+ Métadonnées de l'AMI complète de Windows Server 2016 :
```
/aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized
```
Le format de nom de paramètre suivant extrait les métadonnées de la dernière AMI de base complète Windows Server 2019.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
```
Les informations suivantes présentent un exemple de l'objet JSON renvoyé pour la valeur du paramètre.
```
{
"Parameters": [
{
"Name": "/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized",
"Type": "String",
"Value": "{\"image_name\":\"Windows_Server-2019-English-Full-ECS_Optimized-2023.06.13\",\"image_id\":\"ami-0debc1fb48e4aee16\",\"ecs_runtime_version\":\"Docker (CE) version 20.10.21\",\"ecs_agent_version\":\"1.72.0\"}",
"Version": 58,
"LastModifiedDate": "2023-06-22T19:37:37.841000-04:00",
"ARN": "arn:aws:ssm:us-east-1::parameter/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized",
"DataType": "text"
}
],
"InvalidParameters": []
}
```
Chacun des champs dans la sortie obtenue ci-dessus est disponible pour être interrogé comme sous-paramètres. Construisez le chemin d'accès d'un sous-paramètre en ajoutant le nom du sous-paramètre au chemin d'accès de l'AMI sélectionnée. Les sous-paramètres suivants sont disponibles :
+ `schema_version`
+ `image_id`
+ `image_name`
+ `os`
+ `ecs_agent_version`
+ `ecs_runtime_version`
## Exemples
Les exemples suivants montrent comment vous pouvez récupérer les métadonnées de chaque variante d'AMI optimisée pour Amazon ECS.
### Extraction des métadonnées de la dernière AMI optimisée pour Amazon ECS stable
Vous pouvez récupérer la dernière AMI stable optimisée pour Amazon ECS à l' AWS CLI aide des commandes suivantes AWS CLI .
+ **Pour l’AMI Windows Server 2025 Full optimisée pour Amazon ECS :**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized --region us-east-1
```
+ **Pour l’AMI Windows Server 2025 Core optimisée pour Amazon ECS:**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized --region us-east-1
```
+ **Pour l'AMI Windows Server 2022 Full optimisée pour Amazon ECS :**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized --region us-east-1
```
+ **Pour l'AMI Windows Server 2022 optimisée pour Amazon ECS :**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized --region us-east-1
```
+ **Pour l'AMI Windows Server 2019 Full optimisée pour Amazon ECS :**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized --region us-east-1
```
+ **Pour l'AMI Windows Server 2019 Core optimisée pour Amazon ECS :**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized --region us-east-1
```
+ **Pour l'AMI Windows Server 2016 Full optimisée pour Amazon ECS :**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized --region us-east-1
```
### Utilisation de l'AMI optimisée pour Amazon ECS la plus récente recommandée dans un modèle CloudFormation
Vous pouvez référencer la dernière AMI optimisée pour Amazon ECS recommandée dans un modèle CloudFormation en référençant le nom du magasin de paramètres Systems Manager.
```
Parameters:
LatestECSOptimizedAMI:
Description: AMI ID
Type: AWS::SSM::Parameter::Value
Default: /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized/image_id
```
# Versions d’AMI Windows optimisées pour Amazon ECS Windows
Consultez les versions actuelles et précédentes de l'outil optimisé pour Amazon ECS AMIs et les versions correspondantes de l'agent de conteneur Amazon ECS, de Docker et du package. `ecs-init`
Les métadonnées d'AMI optimisée pour Amazon ECS, notamment l'ID d'AMI, peuvent être extraites par programmation pour chaque variante. Pour de plus amples informations, veuillez consulter [Extraction des métadonnées d’AMI Windows optimisée pour Amazon ECS](retrieve-ecs-optimized_windows_AMI.md).
Les onglets suivants affichent la liste des versions optimisées pour Windows Amazon ECS AMIs . Pour plus de détails sur le référencement du paramètre Systems Manager Parameter Store dans un CloudFormation modèle, consultez[Utilisation de l'AMI optimisée pour Amazon ECS la plus récente recommandée dans un modèle CloudFormation](retrieve-ecs-optimized_AMI.md#ecs-optimized-ami-parameter-examples-5).
**Important**
Pour garantir que les clients disposent des dernières mises à jour de sécurité par défaut, Amazon ECS gère au moins les trois dernières versions optimisées pour Windows Amazon ECS AMIs. Après avoir publié les nouvelles versions optimisées pour Windows Amazon ECS, AMIs Amazon ECS rend privées les versions optimisées pour Windows Amazon ECS AMIs qui sont plus anciennes. S'il existe une AMI privée à laquelle vous devez accéder, soumettez un ticket auprès du support Cloud.
Windows Server 2016 ne prend pas en charge la dernière version de Docker, par exemple 25.x.x. Par conséquent, Windows Server 2016 Full ne AMIs recevra pas de correctifs de sécurité ou de bogues pour le moteur d'exécution Docker. Nous vous recommandons de passer à l’une des plateformes Windows suivantes :
Windows Server 2022 Full
Windows Server 2022 Core
Windows Server 2019 Full
Windows Server 2019 Core
**Note**
La journalisation du plug-in gMSA est passée d’une journalisation basée sur des fichiers `(C:\ProgramData\Amazon\gmsa)` vers Windows Event logging lors de la version d’août 2025 de l’AMI. Le script public log collector collectera tous les logs gMSA. Pour de plus amples informations, veuillez consulter [Collecte des journaux de conteneur avec collecteur de journaux Amazon ECS](ecs-logs-collector.md).
------
#### [ Windows Server 2025 Full AMI versions ]
Le tableau ci-dessous répertorie les versions actuelles et antérieures de l’AMI Windows Server 2025 Full optimisée pour Amazon ECS, ainsi que les versions correspondantes de l’agent de conteneur Amazon ECS et de Docker.
| AMI de Windows Server 2025 Full optimisée pour Amazon ECS | Version d'agent de conteneur Amazon ECS | Version de Docker | Visibilité |
| --- | --- | --- | --- |
| **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2026.03.13** | `1.102.0` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2026.02.13** | `1.101.3` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2026.01.16** | `1.101.2` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.12.13** | `1.101.0` | `25.0.6 (Docker CE)` | Public |
Utilisez la AWS CLI commande suivante pour récupérer l'AMI complète Windows Server 2025 actuellement optimisée pour Amazon ECS.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized
```
------
#### [ Windows Server 2025 Core AMI versions ]
Le tableau ci-dessous répertorie les versions actuelles et précédentes de l'AMI Windows Server 2025 Core optimisée pour Amazon ECS, ainsi que les versions correspondantes de l'agent de conteneur Amazon ECS et de Docker.
| AMI Windows Server 2025 Core optimisée pour Amazon ECS | Version d'agent de conteneur Amazon ECS | Version de Docker | Visibilité |
| --- | --- | --- | --- |
| **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2026.03.13** | `1.102.0` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2026.02.13** | `1.101.3` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2026.01.16** | `1.101.2` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.12.13** | `1.101.0` | `25.0.6 (Docker CE)` | Public |
Utilisez la AWS CLI commande suivante pour récupérer l'AMI principale Windows Server 2025 actuellement optimisée pour Amazon ECS.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized
```
------
#### [ Windows Server 2022 Full AMI versions ]
Le tableau ci-dessous répertorie les versions actuelles et antérieures de l'AMI Windows Server 2022 Full optimisée pour Amazon ECS, ainsi que les versions correspondantes de l'agent de conteneur Amazon ECS et de Docker.
| AMI Windows Server 2022 Full optimisée pour Amazon ECS | Version d'agent de conteneur Amazon ECS | Version de Docker | Visibilité |
| --- | --- | --- | --- |
| **Windows\$1Server-2\$1English-Full-ECS\$1Optimized-2026.03.13** | `1.102.0` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2\$1English-Full-ECS\$1Optimized-2026.02.13** | `1.101.3` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2\$1English-Full-ECS\$1Optimized-2026.01.16** | `1.101.2` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2\$1English-Full-ECS\$1Optimized-2025.12.13** | `1.101.0` | `25.0.6 (Docker CE)` | Public |
Utilisez la AWS CLI commande suivante pour récupérer l'AMI complète Windows Server 2022 actuellement optimisée pour Amazon ECS.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized
```
------
#### [ Windows Server 2022 Core AMI versions ]
Le tableau ci-dessous répertorie les versions actuelles et antérieures de l'AMI Windows Server 2022 Core optimisée pour Amazon ECS, ainsi que les versions correspondantes de l'agent de conteneur Amazon ECS et de Docker.
| AMI de Windows Server 2022 Core optimisée pour Amazon ECS | Version d'agent de conteneur Amazon ECS | Version de Docker | Visibilité |
| --- | --- | --- | --- |
| **Windows\$1Server-2\$1English-Core-ECS\$1Optimized-2026.03.13** | `1.102.0` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2\$1English-Core-ECS\$1Optimized-2026.02.13** | `1.101.3` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2\$1English-Core-ECS\$1Optimized-2026.01.16** | `1.101.2` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2\$1English-Core-ECS\$1Optimized-2025.12.13** | `1.101.0` | `25.0.6 (Docker CE)` | Public |
Utilisez la AWS CLI commande suivante pour récupérer l'AMI complète Windows Server 2022 actuellement optimisée pour Amazon ECS.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized
```
------
#### [ Windows Server 2019 Full AMI versions ]
Le tableau ci-dessous répertorie les versions actuelles et antérieures de l'AMI Windows Server 2019 Full optimisée pour Amazon ECS, ainsi que les versions correspondantes de l'agent de conteneur Amazon ECS et de Docker.
| AMI Windows Server 2019 Full optimisée pour Amazon ECS | Version d'agent de conteneur Amazon ECS | Version de Docker | Visibilité |
| --- | --- | --- | --- |
| **Windows\$1Server-2019-Englis-Full-ECS\$1Optimized-2026.03.13** | `1.102.0` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2019-Englis-Full-ECS\$1Optimized-2026.02.13** | `1.101.3` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2019-Englis-Full-ECS\$1Optimized-2026.01.16** | `1.101.2` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2019-Englis-Full-ECS\$1Optimized-2025.12.13** | `1.101.0` | `25.0.6 (Docker CE)` | Public |
Utilisez la AWS CLI commande suivante pour récupérer l'AMI complète Windows Server 2019 actuellement optimisée pour Amazon ECS.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
```
------
#### [ Windows Server 2019 Core AMI versions ]
Le tableau ci-dessous répertorie les versions actuelles et antérieures de l'AMI Windows Server 2019 Core optimisée pour Amazon ECS, ainsi que les versions correspondantes de l'agent de conteneur Amazon ECS et de Docker.
| AMI de Windows Server 2019 Core optimisée pour Amazon ECS | Version d'agent de conteneur Amazon ECS | Version de Docker | Visibilité |
| --- | --- | --- | --- |
| **Windows\$1Server-2019-Englis-Core-ECS\$1Optimized-2026.03.13** | `1.102.0` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2019-Englis-Core-ECS\$1Optimized-2026.02.13** | `1.101.3` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2019-Englis-Core-ECS\$1Optimized-2026.01.16** | `1.101.2` | `25.0.6 (Docker CE)` | Public |
| **Windows\$1Server-2019-Englis-Core-ECS\$1Optimized-2025.12.13** | `1.101.0` | `25.0.6 (Docker CE)` | Public |
Utilisez la AWS CLI commande suivante pour récupérer l'AMI complète Windows Server 2019 actuellement optimisée pour Amazon ECS.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized
```
------
#### [ Windows Server 2016 Full AMI versions ]
**Important**
Windows Server 2016 ne prend pas en charge la dernière version de Docker, par exemple 25.x.x. Par conséquent, Windows Server 2016 Full ne AMIs recevra pas de correctifs de sécurité ou de bogues pour le moteur d'exécution Docker. Nous vous recommandons de passer à l’une des plateformes Windows suivantes :
Windows Server 2022 Full
Windows Server 2022 Core
Windows Server 2019 Full
Windows Server 2019 Core
Le tableau ci-dessous répertorie les versions actuelles et antérieures de l'AMI Windows Server 2016 Full optimisée pour Amazon ECS, ainsi que les versions correspondantes de l'agent de conteneur Amazon ECS et de Docker.
| AMI complète de Windows Server 2016 optimisée pour Amazon ECS | Version d'agent de conteneur Amazon ECS | Version de Docker | Visibilité |
| --- | --- | --- | --- |
| **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2026.03.13** | `1.102.0` | `20.10.23 (Docker CE)` | Public |
| **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2026.02.13** | `1.101.3` | `20.10.23 (Docker CE)` | Public |
| **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2026.01.16** | `1.101.2` | `20.10.23 (Docker CE)` | Public |
| **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.12.13** | `1.101.0` | `20.10.23 (Docker CE)` | Public |
Utilisez l'AMI complète Windows Server 2016 optimisée pour AWS CLI Amazon ECS suivante.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized
```
------
# Création de votre propre AMI Windows optimisée pour Amazon ECS
Utilisez EC2 Image Builder pour créer votre propre AMI Windows personnalisée optimisée pour Amazon ECS. Cela facilite l'utilisation d'une AMI Windows avec votre propre licence sur Amazon ECS. Amazon ECS propose un composant Image Builder géré qui fournit la configuration système nécessaire pour exécuter des instances Windows afin d'héberger vos conteneurs. Chaque composant géré par Amazon ECS comprend un agent de conteneur spécifique et une version Docker. Vous pouvez personnaliser votre image pour utiliser le dernier composant géré Amazon ECS, ou si un agent de conteneur plus ancien ou une version Docker plus ancienne est nécessaire, vous pouvez spécifier un autre composant.
Pour une démonstration complète de l'utilisation d'EC2 Image Builder, veuillez consulter [Getting started with EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/set-up-ib-env.html#image-builder-accessing-prereq) dans le *Guide de l'utilisateur EC2 Image Builder*.
Lorsque vous créez votre propre AMI Windows optimisée pour Amazon ECS à l'aide d'EC2 Image Builder, vous créez une recette d'image. Votre recette d'image doit répondre aux critères suivants :
+ L’**image source** doit être basée sur Windows Server 2019 Core, Windows Server 2019 Full, Windows Server 2022 Core ou Windows Server 2022 Full. Tout autre système d'exploitation Windows n'est pas pris en charge et peut ne pas être compatible avec le composant.
+ Lorsque vous spécifiez les **composants de création**, le composant `ecs-optimized-ami-windows` est requis. Le composant `update-windows` est recommandé, ce qui garantit que l'image contient les dernières mises à jour de sécurité.
Pour spécifier une version de composant différente, développez le menu **Versioning options** (Options de gestion des versions) et spécifiez la version du composant à utiliser. Pour de plus amples informations, veuillez consulter [Établissement de la liste des versions de composants `ecs-optimized-ami-windows`](#windows-component-list).
## Établissement de la liste des versions de composants `ecs-optimized-ami-windows`
Lors de la création d'une recette EC2 Image Builder et de la spécification du composant `ecs-optimized-ami-windows`, vous pouvez utiliser l'option par défaut ou spécifier une version de composant spécifique. Pour déterminer les versions de composants disponibles, ainsi que l'agent de conteneur Amazon ECS et les versions Docker contenues dans le composant, vous pouvez utiliser la AWS Management Console.
**Pour répertorier les versions de composants `ecs-optimized-ami-windows` disponibles**
1. Ouvrez la console [https://console.aws.amazon.com/imagebuilder/](https://console.aws.amazon.com/imagebuilder/)EC2 Image Builder à l'adresse.
1. Dans la barre de navigation, sélectionnez la région dans laquelle votre image est créée.
1. Dans le panneau de navigation, sous le menu **Saved configurations (Configurations enregistrées)**, choisissez **Components (Composants)**.
1. Sur la page **Components (Composants)**, dans la barre de recherche, saisissez `ecs-optimized-ami-windows` et faites défiler le menu de qualification et sélectionnez **Quick start (Amazon-managed) [Quick Start (géré par Amazon)]**.
1. Utilisation de la colonne **Description** pour déterminer la version du composant avec l'agent de conteneur Amazon ECS et la version Docker qu'exige votre image.
# Gestion des instances de conteneurs Windows Amazon ECS
Lorsque vous utilisez des instances EC2 pour vos charges de travail Amazon ECS, vous êtes responsable de la maintenance des instances.
Les mises à jour de l'agent ne s'appliquent pas aux instances de conteneur Windows. Nous vous recommandons de lancer de nouvelles instances de conteneur pour mettre à jour le version de l'agent dans vos clusters Windows.
**Topics**
+ [Lancement d'une instance de conteneur](launch_window-container_instance.md)
+ [Amorçage des instances de conteneur](bootstrap_windows_container_instance.md)
+ [Utilisation d’un proxy HTTP pour les instances de conteneur Windows](http_proxy_config-windows.md)
+ [Configuration des instances de conteneur pour recevoir des notifications relatives aux instances Spot](windows-spot-instance-draining-container.md)
# Lancement d'une instance de conteneur Amazon ECS Windows
Vos instances de conteneur Amazon ECS sont créées à l'aide de la console Amazon EC2. Avant de commencer, assurez-vous d’avoir terminé les étapes de [Configurer l'utilisation d'Amazon ECS](get-set-up-for-amazon-ecs.md).
Pour plus d’informations sur l’assistant de lancement, consultez la section [Lancement d’une instance à l’aide du nouvel assistant de lancement d’instance](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-launch-instance-wizard.html) dans le *Guide de l’utilisateur Amazon EC2*.
Vous pouvez utiliser le nouvel assistant Amazon EC2 pour lancer une instance. Vous pouvez utiliser la liste suivante pour les paramètres et laisser les paramètres non répertoriés comme paramètres par défaut. Les instructions suivantes vous guident dans chaque groupe de paramètres.
## Procédure
Avant de commencer, complétez les étapes détaillées dans [Configurer l'utilisation d'Amazon ECS](get-set-up-for-amazon-ecs.md).
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 en haut de l'écran, la AWS région actuelle est affichée (par exemple, USA East (Ohio)). Sélectionnez une région dans laquelle lancer l’instance. Ce choix est important car certaines ressources Amazon EC2 peuvent être partagées entre des régions, contrairement à d’autres ressources.
1. Sur le tableau de bord de la console Amazon EC2, sélectionnez **Launch instance (Lancer une instance)**.
## Noms et identifications
Le nom de l'instance est une identification, où la clé est **Name** (Nom), et la valeur est le nom que vous spécifiez. Vous pouvez étiqueter l'instance, les volumes et les Elastic Graphics. Pour les instances Spot, vous pouvez baliser uniquement la demande d’instance Spot.
La spécification d’un nom d’instance et d’identifications supplémentaires est facultative.
+ Pour **Name** (Nom), saisissez un nom descriptif pour l’instance. Si vous ne spécifiez pas de nom, l’instance peut être identifiée par son ID, qui est automatiquement généré lorsque vous lancez l’instance.
+ Pour ajouter des identifications supplémentaires, sélectionnez **Add additional tags** (Ajouter des identifications supplémentaires). Choisissez **Add tag** (Ajouter une identification), saisissez une clé et une valeur, puis sélectionnez le type de ressource à étiqueter. Choisissez **Add tag** (Ajouter une identification) pour chaque étiquette supplémentaire.
## Images d’applications et de systèmes d’exploitation (Amazon Machine Image)
Une Amazon Machine Image (AMI) contient les informations requises pour créer une instance. Par exemple, une AMI peut contenir le logiciel nécessaire pour fonctionner en tant que serveur web, comme Apache et votre site web.
Pour connaître les dernières versions optimisées pour Amazon ECS AMIs et leurs valeurs, consultez l'AMI optimisée pour [Windows Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_windows_AMI.html).
Utilisez la barre **de recherche** pour trouver une AMI optimisée pour Amazon ECS adaptée publiée par. AWS
1. En fonction de vos besoins, saisissez l'une des options suivantes AMIs dans la barre **de recherche** et appuyez sur **Entrée**.
+ Windows\$1Server-2022-English-Full-ECS\$1Optimized
+ Windows\$1Server-2022-English-Core-ECS\$1Optimized
+ Windows\$1Server-2019-English-Full-ECS\$1Optimized
+ Windows\$1Server-2019-English-Core-ECS\$1Optimized
+ Windows\$1Server-2016-English-Full-ECS\$1Optimized
1. Sur la page **Choose an Amazon Machine Image (AMI)**, sélectionnez l' AMIsonglet **Communauté**.
1. Dans la liste qui apparaît, choisissez une AMI vérifiée par Microsoft avec la date de publication la plus récente et cliquez sur **Sélectionner**.
## Type d’instance
Le type d’instance définit la configuration matérielle et la taille de l’instance. Les types d’instance plus importants disposent de plus d’UC et de mémoire. Pour plus d’informations, consultez [Types d’instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html).
+ Pour **Instance type** (Type d’instance), sélectionnez le type de l’instance.
Le type d'instance que vous sélectionnez détermine les ressources disponibles pour les tâches à exécuter.
## Paire de clés (connexion)
Pour **Key pair name** (Nom de la paire de clés), choisissez une paire de clés existante ou choisissez **Create new key pair** (Créer une nouvelle paire de clés) pour en créer une nouvelle.
**Important**
Si vous sélectionnez l’option **Proceed without key pair (Not recommended)** ((Continuer sans paire de clé) (Non recommandé)), vous ne pourrez pas vous connecter à l’instance à moins de choisir une AMI configurée de façon à autoriser les utilisateurs à se connecter d’une autre façon.
## Paramètres réseau
Configurez les paramètres réseau, le cas échéant.
+ **Networking platform** (Plateforme de mise en réseau) : choisissez **Virtual Private Cloud (VPC)** (Cloud privé virtuel [VPC]), puis spécifiez le sous-réseau dans la section **Network interfaces** (Interfaces réseau).
+ **VPC** : sélectionnez un VPC existant dans lequel créer le groupe de sécurité.
+ **Sous-réseau** : vous pouvez lancer une instance dans un sous-réseau associé à une zone de disponibilité, une zone locale, une zone Wavelength ou un Outpost.
Pour lancer l’instance dans une zone de disponibilité, sélectionnez le sous-réseau dans lequel lancer votre instance. Pour créer un sous-réseau, choisissez **Créer un nouveau sous-réseau** afin d’accéder à la console Amazon VPC. Une fois que vous avez terminé, revenez dans l’assistant de lancement d’instance et choisissez l’icône Refresh (Actualiser) afin de charger votre sous-réseau dans la liste.
Pour lancer l’instance dans une zone locale, sélectionnez un sous-réseau que vous avez créé dans la zone locale.
Pour lancer une instance dans un Outpost, sélectionnez un sous-réseau dans un VPC que vous avez associé à l’Outpost.
+ **Auto-assign Public IP** (Attribuer automatiquement l'adresse IP publique) : si votre instance doit être accessible à partir d'Internet, vérifiez que le champ **Auto-assign Public IP** (Attribuer automatiquement l'adresse IP publique) est défini sur **Enable** (Activer). Si ce n'est pas le cas, définissez ce champ sur **Disable** (Désactiver).
**Note**
Les instances de conteneur ont besoin de communiquer avec le point de terminaison de service Amazon ECS. Cela peut être via un point de terminaison d'un VPC d'interface ou via vos instances de conteneur ayant des adresses IP publiques.
Pour plus d'informations sur les points de terminaison d'un VPC d'interface, consultez [Points de terminaison d'un VPC d'interface Amazon ECS (AWS PrivateLink)](vpc-endpoints.md).
Si vous n'avez pas de point de terminaison d'un VPC d'interface configuré et que vos instances de conteneur n'ont pas d'adresses IP publiques, elles doivent utiliser la traduction d'adresses réseau (NAT) pour fournir cet accès. Pour de plus amples informations, veuillez consulter [Passerelles NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) dans le *Guide de l'utilisateur Amazon VPC* et [Utilisation d’un proxy HTTP pour les instances de conteneur Amazon ECS Linux](http_proxy_config.md) dans ce guide.
+ **Firewall (security groups)** (Pare-feu (groupes de sécurité)) : utilisez un groupe de sécurité afin de définir les règles de pare-feu de votre instance de conteneur. Ces règles déterminent le trafic réseau entrant acheminé vers votre instance de conteneur. Le reste du trafic est ignoré.
+ Pour sélectionner un groupe de sécurité existant, choisissez **Select existing security group** (Sélectionner un groupe de sécurité existant), puis sélectionnez le groupe de sécurité que vous avez créé dans [Configurer l'utilisation d'Amazon ECS](get-set-up-for-amazon-ecs.md).
## Configurer le stockage
L’AMI sélectionnée inclut un ou plusieurs volumes de stockage, notamment le volume racine. Vous pouvez spécifier d’autres volumes à attacher à l’instance.
Vous pouvez utiliser la vue **Simple**.
+ **Storage type** (Type de stockage) : configurez le stockage pour votre instance de conteneur.
Si vous utilisez l’AMI Linux optimisée pour Amazon ECS, votre instance contient deux volumes configurés. Le volume **Racine** est réservé au système d'exploitation et le second volume Amazon EBS (attaché à `/dev/xvdcz`) est réservé à Docker.
Vous pouvez augmenter ou diminuer la taille des volumes pour votre instance afin de répondre aux besoins de votre application.
## Détails avancés
Développez la section **Détails avancés** pour afficher les champs et spécifier des paramètres supplémentaires pour l’instance.
+ **Purchasing option** (Option d'achat) : sélectionnez **Request Spot Instances** (Demander des instances Spot) pour demander une instance Spot. Vous devez également définir les autres champs associés aux instances Spot. Pour plus d'informations, consultez [Demandes d'instances Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html).
**Note**
Si vous utilisez les instances Spot et qu'un message `Not available` s'affiche, vous devrez peut-être choisir un autre type d'instance.
.
+ **IAM instance profile** (Profil d'instance IAM) : sélectionnez votre rôle IAM d'instance de conteneur. Celui-ci est généralement nommé `ecsInstanceRole`.
**Important**
Si vous ne pas lancez votre instance de conteneur avec les autorisations IAM appropriées, votre agent Amazon ECS ne peut pas se connecter à votre cluster. Pour de plus amples informations, veuillez consulter [Rôle IAM d'instance de conteneur Amazon ECS](instance_IAM_role.md).
+ (Facultatif) **User data** (Données utilisateur) : configurez votre instance de conteneur Amazon ECS avec les données utilisateur, telles que les variables d'environnement d'agent depuis [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md). Les scripts de données utilisateur Amazon EC2 sont exécutés une seule fois, au premier lancement de l'instance. Les exemples suivants présentent des utilisations courantes des données utilisateur :
+ Par défaut, votre instance de conteneur est lancée dans votre cluster par défaut. Pour un lancement dans un cluster autre que celui défini par défaut, choisissez la liste **Détails avancés**. Collez ensuite le script suivant dans le champ **Données utilisateur**, en le *your\$1cluster\$1name* remplaçant par le nom de votre cluster.
`EnableTaskIAMRole` active la fonction Rôles IAM pour les tâches.
En outre, les options suivantes sont disponibles lorsque vous utilisez le mode réseau `awsvpc`.
+ `EnableTaskENI` : cet indicateur active les réseaux des tâches et est requis lorsque vous utilisez le mode réseau `awsvpc`.
+ `AwsvpcBlockIMDS` : cet indicateur facultatif bloque l'accès IMDS pour les conteneurs de tâches qui s'exécutent dans en mode réseau `awsvpc`.
+ `AwsvpcAdditionalLocalRoutes` : cet indicateur facultatif vous permet d'avoir des acheminements supplémentaires dans l'espace de noms de tâche.
Remplacez `ip-address` par l'adresse IP pour les acheminements supplémentaires, par exemple 172.31.42.23/32.
```
Import-Module ECSTools
Initialize-ECSAgent -Cluster your_cluster_name -EnableTaskIAMRole -EnableTaskENI -AwsvpcBlockIMDS -AwsvpcAdditionalLocalRoutes
'["ip-address"]'
```
# Amorçage des instances de conteneurs Windows Amazon ECS pour transmettre des données
Lorsque vous lancez une instance Amazon EC2, vous pouvez transmettre les données utilisateur à cette instance. Ces données peuvent être utilisées afin d'effectuer des tâches de configuration automatisées courantes, voire d'exécuter des scripts lors du démarrage de l'instance. Pour Amazon ECS, les données utilisateur sont le plus souvent utilisées pour transmettre les informations de configuration au démon Docker et à l'agent de conteneur Amazon ECS.
Vous pouvez transmettre plusieurs types de données utilisateur à Amazon EC2, notamment des boothooks de cloud, des scripts shell et des directives `cloud-init`. Pour plus d'informations sur ce point et sur d'autres types de format, consultez la [documentation sur Cloud-Init](https://cloudinit.readthedocs.io/en/latest/explanation/format.html).
Vous pouvez transmettre ces données utilisateur lors de l'utilisation de l'Amazon EC2 Launch Wizard. Pour de plus amples informations, veuillez consulter [Lancement d'une instance de conteneur Amazon ECS Linux](launch_container_instance.md).
## Données utilisateur Windows par défaut
Cet exemple de script de données utilisateur montre les données utilisateur par défaut que vos instances de conteneur Windows reçoivent si vous utilisez la console. Le script ci-dessous :
+ Définit le nom du cluster selon le nom que vous avez saisi.
+ Définit les rôles IAM pour les tâches.
+ Définit `json-file` et `awslogs` comme pilotes de journalisation disponibles.
En outre, les options suivantes sont disponibles lorsque vous utilisez le mode réseau `awsvpc`.
+ `EnableTaskENI` : cet indicateur active les réseaux des tâches et est requis lorsque vous utilisez le mode réseau `awsvpc`.
+ `AwsvpcBlockIMDS` : cet indicateur facultatif bloque l'accès IMDS pour les conteneurs de tâches qui s'exécutent dans en mode réseau `awsvpc`.
+ `AwsvpcAdditionalLocalRoutes` : cet indicateur facultatif vous permet d'avoir des acheminements supplémentaires.
Remplacez `ip-address` par l'adresse IP pour les acheminements supplémentaires, par exemple 172.31.42.23/32.
Vous pouvez utiliser ce script pour vos propres instances de conteneur (sous réserve qu'elles soient lancées à partir d'une AMI Windows Server optimisée pour Amazon ECS).
Remplacez la ligne `-Cluster cluster-name` pour spécifier votre propre nom de cluster.
```
Initialize-ECSAgent -Cluster cluster-name -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]' -EnableTaskENI -AwsvpcBlockIMDS -AwsvpcAdditionalLocalRoutes
'["ip-address"]'
```
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.
Remplacez la ligne `-Cluster cluster-name` pour spécifier votre propre nom de cluster.
```
[Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine")
Initialize-ECSAgent -Cluster cluster-name -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]'
```
## Données utilisateur d'installation d'un agent Windows
Cet exemple de script de données utilisateur installe l'agent de conteneur Amazon ECS sur une instance lancée avec une AMI **Windows\$1Server-2016-English-Full-Containers**. Il a été adapté à partir des instructions d'installation de l'agent figurant sur la page README du [ GitHubréférentiel Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent).
**Note**
Ce script est partagé à titre d'exemple. Il est beaucoup plus facile de commencer avec les conteneurs Windows en utilisant l'AMI Windows Server optimisée pour Amazon ECS. Pour de plus amples informations, veuillez consulter [Création d’un cluster Amazon ECS pour les charges de travail Fargate](create-cluster-console-v2.md).
Pour plus d'informations sur l'installation de l'agent Amazon ECS sur Windows Server 2022 Full, consultez le [numéro 3753](https://github.com/aws/amazon-ecs-agent/issues/3753) sur GitHub.
Vous pouvez utiliser ce script pour vos propres instances de conteneur (à condition qu'elles soient lancées avec une version de l'**AMI Windows\$1Server-2016-English-Full-Containers**). Veillez à modifier la ligne `windows` dans le fichier de configuration en spécifiant votre propre nom de cluster (si vous n'utilisez pas un cluster nommé `windows`).
```
# Set up directories the agent uses
New-Item -Type directory -Path ${env:ProgramFiles}\Amazon\ECS -Force
New-Item -Type directory -Path ${env:ProgramData}\Amazon\ECS -Force
New-Item -Type directory -Path ${env:ProgramData}\Amazon\ECS\data -Force
# Set up configuration
$ecsExeDir = "${env:ProgramFiles}\Amazon\ECS"
[Environment]::SetEnvironmentVariable("ECS_CLUSTER", "windows", "Machine")
[Environment]::SetEnvironmentVariable("ECS_LOGFILE", "${env:ProgramData}\Amazon\ECS\log\ecs-agent.log", "Machine")
[Environment]::SetEnvironmentVariable("ECS_DATADIR", "${env:ProgramData}\Amazon\ECS\data", "Machine")
# Download the agent
$agentVersion = "latest"
$agentZipUri = "https://s3.amazonaws.com/amazon-ecs-agent/ecs-agent-windows-$agentVersion.zip"
$zipFile = "${env:TEMP}\ecs-agent.zip"
Invoke-RestMethod -OutFile $zipFile -Uri $agentZipUri
# Put the executables in the executable directory.
Expand-Archive -Path $zipFile -DestinationPath $ecsExeDir -Force
Set-Location ${ecsExeDir}
# Set $EnableTaskIAMRoles to $true to enable task IAM roles
# Note that enabling IAM roles will make port 80 unavailable for tasks.
[bool]$EnableTaskIAMRoles = $false
if (${EnableTaskIAMRoles}) {
$HostSetupScript = Invoke-WebRequest https://raw.githubusercontent.com/aws/amazon-ecs-agent/master/misc/windows-deploy/hostsetup.ps1
Invoke-Expression $($HostSetupScript.Content)
}
# Install the agent service
New-Service -Name "AmazonECS" `
-BinaryPathName "$ecsExeDir\amazon-ecs-agent.exe -windows-service" `
-DisplayName "Amazon ECS" `
-Description "Amazon ECS service runs the Amazon ECS agent" `
-DependsOn Docker `
-StartupType Manual
sc.exe failure AmazonECS reset=300 actions=restart/5000/restart/30000/restart/60000
sc.exe failureflag AmazonECS 1
Start-Service AmazonECS
```
# Utilisation d’un proxy HTTP pour les instances de conteneur Windows Amazon ECS
Vous pouvez configurer vos instances de conteneur Amazon ECS pour qu'elles utilisent un proxy HTTP pour l'agent de conteneur Amazon ECS et le démon Docker. C'est utile si vos instances de conteneur n'ont pas accès au réseau externe via une passerelle Internet Amazon VPC, une instance ou une passerelle NAT.
Pour configurer votre instance de conteneur Amazon ECS Windows afin qu'elle utilise un proxy HTTP, définissez les variables suivantes lors du lancement (avec les données utilisateur Amazon EC2).
`[Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.mydomain:port", "Machine")`
Définissez `HTTP_PROXY` sur le nom d'hôte (ou l'adresse IP) et le numéro de port d'un proxy HTTP à utiliser pour que l'agent Amazon ECS puisse se connecter à Internet. Par exemple, vos instances de conteneur n'ont peut-être pas accès au réseau externe via une passerelle Internet Amazon VPC, une instance ou une passerelle NAT.
`[Environment]::SetEnvironmentVariable("NO_PROXY", "169.254.169.254,169.254.170.2,\\.\pipe\docker_engine", "Machine")`
Définissez `NO_PROXY` sur `169.254.169.254,169.254.170.2,\\.\pipe\docker_engine` pour filtrer les métadonnées d'instance EC2, les rôles IAM pour les tâches et le trafic du démon Docker en provenance du proxy.
**Example Script de données utilisateur proxy HTTP pour Windows**
L'exemple de PowerShell script de données utilisateur ci-dessous configure l'agent de conteneur Amazon ECS et le daemon Docker pour utiliser un proxy HTTP que vous spécifiez. Vous pouvez également spécifier un cluster auprès duquel l'instance de conteneur s'enregistrera.
Pour utiliser ce script lors du lancement d'une instance de conteneur, suivez les étapes indiquées dans [Lancement d'une instance de conteneur Amazon ECS Windows](launch_window-container_instance.md). Copiez et collez simplement le PowerShell script ci-dessous dans le champ **Données utilisateur** (veillez à remplacer les exemples de valeurs en rouge par vos propres informations de proxy et de cluster).
L'option `-EnableTaskIAMRole` est nécessaire pour activer les rôles IAM pour les tâches. Pour de plus amples informations, veuillez consulter [Configuration supplémentaire d’instance Windows Amazon EC2](task-iam-roles.md#windows_task_IAM_roles).
```
Import-Module ECSTools
$proxy = "http://proxy.mydomain:port"
[Environment]::SetEnvironmentVariable("HTTP_PROXY", $proxy, "Machine")
[Environment]::SetEnvironmentVariable("NO_PROXY", "169.254.169.254,169.254.170.2,\\.\pipe\docker_engine", "Machine")
Restart-Service Docker
Initialize-ECSAgent -Cluster MyCluster -EnableTaskIAMRole
```
# Configuration des instances de conteneur Windows Amazon ECS pour recevoir des notifications relatives aux instances Spot
Amazon EC2 résilie, arrête ou met en veille prolongée votre instance Spot lorsque le prix Spot dépasse le prix maximum de votre demande ou lorsque la capacité n'est plus disponible. Amazon EC2 communique un avis d'interruption d'instance Spot, qui donne à l'instance un avertissement deux minutes avant qu'elle soit interrompue. Si le drainage des instances Spot Amazon ECS est activé sur l'instance, ECS reçoit l'avis d'interruption d'instance Spot et bascule l'instance à l'état `DRAINING`.
**Important**
Amazon ECS surveille les avis d'interruption d'instance Spot qui comportent les actions d'instance `terminate` et `stop`. Si vous avez spécifié le comportement d'interruption d'instance `hibernate` lors de la demande de vos instances Spot ou de votre parc d'instances Spot, le drainage des instances Spot Amazon ECS n'est pas pris en charge pour ces instances.
Lorsqu'une instance de conteneur est définie sur `DRAINING`, Amazon ECS bloque la planification du placement des nouvelles tâches sur l'instance de conteneur. Les tâches de service ayant l'état `PENDING` sur l'instance de conteneur faisant l'objet du drainage sont arrêtées immédiatement. S'il y a des instances de conteneur disponibles dans le cluster, des tâches de service de remplacement sont lancées dessus.
Vous pouvez activer le drainage d’instance Spot lorsque vous lancez une instance. Vous devez définir le paramètre `ECS_ENABLE_SPOT_INSTANCE_DRAINING` avant de démarrer l'agent de conteneur. Remplacez *my-cluster* par le nom de votre cluster.
```
[Environment]::SetEnvironmentVariable("ECS_ENABLE_SPOT_INSTANCE_DRAINING", "true", "Machine")
# Initialize the agent
Initialize-ECSAgent -Cluster my-cluster
```
Pour de plus amples informations, veuillez consulter [Lancement d'une instance de conteneur Amazon ECS Windows](launch_window-container_instance.md).
# Clusters Amazon ECS pour instances externes
Amazon ECS Anywhere fournit un support pour l'enregistrement d'une *Instance externe*, telle qu'un serveur sur site ou une machine virtuelle (VM), sur votre cluster Amazon ECS. Les instances externes sont optimisées pour exécuter des applications qui génèrent du trafic sortant ou des données de processus. Si votre application nécessite du trafic entrant, l'absence de prise en charge d'Elastic Load Balancing rend l'exécution de ces applications moins efficace. Amazon ECS a ajouté un nouveau type de lancement `EXTERNAL` que vous pouvez utiliser pour créer des services ou exécuter des tâches sur vos instances externes.
## Systèmes d'exploitation et architectures système pris en charge
Voici la liste des systèmes d'exploitation pris en charge. Les architectures d'UC `x86_64` et `ARM64` sont prises en charge.
+ Amazon Linux 2023
+ Ubuntu 20, Ubuntu 22, Ubuntu 24
+ RHEL 9 — Vous devez vous assurer que Docker est installé avant d'exécuter le script d'[installation d'ECS Anywhere](https://github.com/aws/amazon-ecs-agent/blob/master/scripts/ecs-anywhere-install.sh). Pour plus d'informations, consultez [Installer le moteur Docker sur RHEL](https://docs.docker.com/engine/install/rhel/) dans la documentation Docker.
À compter du 7 août 2026, les systèmes d'exploitation suivants ne sont plus pris en charge par Amazon ECS Anywhere :
+ Amazon Linux 2
+ CentOS Stream 9
+ RHEL 7, RHEL 8
+ Fedora 32, Fedora 33, Fedora 40
+ openSUSE Tumbleweed
+ Ubuntu 18
+ Debian 9, Debian 10, Debian 11, Debian 12
+ SUSE Enterprise Server 15
+ Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 20H2
## Considérations
Avant de démarrer l'utilisation des instances externes, tenez compte des considérations suivantes.
+ Vous pouvez enregistrer une instance externe dans un cluster à la fois. Pour plus d'informations sur l'enregistrement d'une instance externe auprès d'un autre cluster, veuillez consulter [Annulation de l’enregistrement d’une instance externe Amazon ECS](ecs-anywhere-deregistration.md).
+ Vos instances externes ont besoin d'un rôle IAM qui leur permet de communiquer avec AWS APIs. Pour de plus amples informations, veuillez consulter [Rôle IAM Amazon ECS Anywhere](iam-role-ecsanywhere.md).
+ Vos instances externes ne doivent pas avoir de chaîne d'informations d'identification d'instance préconfigurée définie localement, car cela interférera avec le script d'enregistrement.
+ Pour envoyer des journaux de conteneur à CloudWatch Logs, assurez-vous de créer et de spécifier un rôle IAM d'exécution de tâche dans la définition de votre tâche.
+ Lorsqu'une instance externe est enregistrée dans un cluster, la valeur `ecs.capability.external` est associée à l'instance. Cet attribut identifie l'instance en tant qu'instance externe. Vous pouvez ajouter des attributs personnalisés à vos instances externes pour les utiliser comme contrainte de placement de tâches. Pour de plus amples informations, veuillez consulter [Attributs personnalisés](task-placement-constraints.md#ecs-custom-attributes).
+ Vous pouvez ajouter des balises de ressources à votre instance externe. Pour de plus amples informations, veuillez consulter [Ajout de balises à une instance de conteneur externe pour Amazon ECS](instance-details-tags-external.md).
+ ECS Exec est pris en charge sur les instances externes. Pour de plus amples informations, veuillez consulter [Surveillance des conteneurs Amazon ECS avec ECS Exec](ecs-exec.md).
+ Vous trouverez ci-dessous des considérations supplémentaires spécifiques aux réseaux avec vos instances externes. Pour de plus amples informations, veuillez consulter [Réseaux](#ecs-anywhere-networking).
+ La répartition de charge de service n'est pas prise en charge.
+ La découverte de service n'est pas prise en charge.
+ Les tâches qui s'exécutent sur des instances externes doivent utiliser les modes réseau `bridge`, `host` ou `none`. Le mode réseau `awsvpc` n'est pas pris en charge.
+ Il existe des domaines de service Amazon ECS dans chaque AWS région. Ces domaines de service doivent être autorisés à envoyer du trafic vers vos instances externes.
+ Le SSM Agent installé sur votre instance externe gère les informations d'identification IAM qui effectuent une rotation toutes les 30 minutes à l'aide d'une empreinte matérielle. Si votre instance externe perd la connexion à AWS, l'agent SSM actualise automatiquement les informations d'identification une fois la connexion rétablie. Pour plus d'informations, consultez [Validation de serveurs et de machines virtuelles sur site à l'aide d'une empreinte matérielle](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html#fingerprint-validation) dans le *Guide de l'utilisateur AWS Systems Manager *.
+ Vous pouvez exécuter des tâches Linux sur des instances externes dans une configuration IPv6 uniquement tant que les instances se trouvent dans des sous-réseaux IPv6 uniquement. Pour de plus amples informations, veuillez consulter [Utilisation d'un VPC en mode -only IPv6](task-networking.md#networking-ipv6-only).
+ L'API `UpdateContainerAgent` n'est pas prise en charge. Pour obtenir des instructions sur la mise à jour du SSM Agent ou de l'agent Amazon ECS sur vos instances externes, veuillez consulter [Mise à jour de l' AWS Systems Manager agent et de l'agent de conteneur Amazon ECS sur une instance externe](ecs-anywhere-updates.md).
+ Les fournisseurs de capacité Amazon ECS ne sont pas pris en charge. Pour créer un service ou exécuter une tâche autonome sur vos instances externes, utilisez le type de lancement `EXTERNAL`.
+ SELinux n'est pas pris en charge.
+ L'utilisation de volumes Amazon EFS ou la spécification d'une `EFSVolumeConfiguration` n'est pas prise en charge.
+ L'intégration à App Mesh n'est pas prise en charge.
+ Si vous utilisez la console pour créer une définition de tâche d'instance externe, vous devez créer la définition de tâche avec l'éditeur JSON de la console.
+ Lorsque vous utilisez une AMI non optimisée pour Amazon ECS, exécutez les commandes suivantes sur l'instance de conteneur externe pour configurer les règles d'utilisation des rôles IAM pour les tâches. Pour de plus amples informations, veuillez consulter [Configuration supplémentaire d’instance externe](task-iam-roles.md#enable_task_iam_roles).
```
$ sysctl -w net.ipv4.conf.all.route_localnet=1
$ iptables -t nat -A PREROUTING -p tcp -d 169.254.170.2 --dport 80 -j DNAT --to-destination 127.0.0.1:51679
$ iptables -t nat -A OUTPUT -d 169.254.170.2 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 51679
```
### Réseaux
Les instances externes Amazon ECS sont optimisées pour exécuter des applications qui génèrent du trafic sortant ou des données de traitement. Si votre application nécessite un trafic entrant, tel qu'un service web, l'absence de prise en charge d'Elastic Load Balancing rend l'exécution de ces applications moins efficace, car il n'existe pas de prise en charge pour placer ces charges de travail derrière un équilibreur de charge.
Vous trouverez ci-dessous des considérations supplémentaires spécifiques aux réseaux avec vos instances externes.
+ La répartition de charge de service n'est pas prise en charge.
+ La découverte de service n'est pas prise en charge.
+ Les tâches Linux qui s'exécutent sur des instances externes doivent utiliser les modes réseau `bridge`, `host` ou `none`. Le mode réseau `awsvpc` n'est pas pris en charge.
Pour savoir comment opérer un réseau, consultez la section [Options de mise en réseau des tâches Amazon ECS pour les instances EC2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html).
+ Vous pouvez exécuter des tâches Linux sur des instances externes dans une configuration IPv6 uniquement tant que les instances se trouvent dans des sous-réseaux IPv6 uniquement. Pour de plus amples informations, veuillez consulter [Utilisation d'un VPC en mode -only IPv6](task-networking.md#networking-ipv6-only).
+ Il existe des domaines de service Amazon ECS dans chaque région et vous devez être autorisé à envoyer du trafic vers vos instances externes.
+ Le SSM Agent installé sur votre instance externe gère les informations d'identification IAM qui effectuent une rotation toutes les 30 minutes à l'aide d'une empreinte matérielle. Si votre instance externe perd la connexion à AWS, l'agent SSM actualise automatiquement les informations d'identification une fois la connexion rétablie. Pour plus d'informations, consultez [Validation de serveurs et de machines virtuelles sur site à l'aide d'une empreinte matérielle](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html#fingerprint-validation) dans le *Guide de l'utilisateur AWS Systems Manager *.
Les domaines suivants sont utilisés pour la communication entre le service Amazon ECS service et l'agent Amazon ECS installé sur votre instance externe. Assurez-vous que le trafic est autorisé et que la résolution DNS fonctionne. Pour chaque point de terminaison, *region* représente l'identifiant de AWS région d'une région prise en charge par Amazon ECS, par exemple `us-east-2` pour la région USA Est (Ohio). Les points de terminaison de toutes les régions que vous utilisez doivent être autorisés. Pour les points de terminaison `ecs-a` et `ecs-t`, vous devez inclure un astérisque (par exemple, `ecs-a-*`).
+ `ecs-a-*.region.amazonaws.com` — Ce point de terminaison est utilisé lors de la gestion des tâches.
+ `ecs-t-*.region.amazonaws.com` — Ce point de terminaison est utilisé pour gérer les métriques de tâche et de conteneur.
+ `ecs.region.amazonaws.com` — Il s'agit du point de terminaison de service pour Amazon ECS.
+ `ssm.region.amazonaws.com `— Il s'agit du point de terminaison du service pour AWS Systems Manager.
+ `ec2messages.region.amazonaws.com`— Il s'agit du point de terminaison du service AWS Systems Manager utilisé pour communiquer entre l'agent Systems Manager et le service Systems Manager dans le cloud.
+ `ssmmessages.region.amazonaws.com` — Il s'agit du point de terminaison requis pour créer et supprimer des canaux de session avec le service Session Manager dans le cloud.
+ Si vos tâches nécessitent une communication avec d'autres AWS services, assurez-vous que ces points de terminaison de service sont autorisés. Parmi les applications, citons l'utilisation d'Amazon ECR pour extraire des images de conteneurs ou l'utilisation de CloudWatch for CloudWatch Logs. Pour plus d'informations, consultez [Points de terminaison de service](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) dans la *Référence générale AWS *.
### Amazon FSx for Windows File Server avec ECS Anywhere
**Important**
Le support Windows pour Amazon ECS Anywhere est obsolète. Cette section n'est plus applicable.
Pour utiliser les instances externes Amazon FSx for Windows File Server d'Amazon ECS, vous devez établir une connexion entre votre centre de données sur site et le AWS Cloud. Pour plus d'informations sur la connexion de votre réseau à votre VPC, consultez [Options de connectivité du cloud privé virtuel Amazon](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html).
### gMSA avec ECS Anywhere
**Important**
Le support Windows pour Amazon ECS Anywhere est obsolète. Cette section n'est plus applicable.
Les cas d'utilisation suivants ont été pris en charge pour ECS Anywhere lorsque Windows était un système d'exploitation compatible.
+ L'Active Directory se trouve dans le AWS Cloud - Pour cette configuration, vous créez une connexion entre votre réseau local et l' AWS Cloud utilisation d'une AWS Direct Connect connexion. Pour en savoir plus comment créer une connexion, consultez [Options de connectivité du cloud privé virtuel Amazon](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html). Vous pouvez créer un Active Directory dans AWS Cloud. Pour plus d'informations sur la façon de démarrer AWS Directory Service, consultez la section [Configuration AWS Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/setting_up.html) dans le *Guide d'AWS Directory Service administration*. Vous pouvez ensuite joindre vos instances externes au domaine à l'aide de la AWS Direct Connect connexion. Pour en savoir plus sur l'utilisation de gMSA avec Amazon ECS, consultez [Utilisation des gMSA pour les conteneurs Windows EC2 pour Amazon ECS](windows-gmsa.md).
+ Active Directory se trouve dans le centre de données sur site. - Pour cette configuration, vous joignez vos instances externes à Active Directory sur site. Vous utilisez ensuite les informations d'identification disponibles localement lorsque vous exécutez les tâches Amazon ECS.
# Création d’un cluster Amazon ECS pour les charges de travail d’instance externe
Vous créez un cluster pour définir l’infrastructure sur laquelle vos tâches et vos services s’exécutent.
Avant de commencer, veillez achever les étapes de [Configurer l'utilisation d'Amazon ECS](get-set-up-for-amazon-ecs.md) et affectez l’autorisation IAM appropriée. Pour de plus amples informations, veuillez consulter [Exemples de cluster Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies). La console Amazon ECS fournit un moyen simple de créer les ressources nécessaires à un cluster Amazon ECS en créant une CloudFormation pile.
Pour que le processus de création de cluster soit aussi simple que possible, la console dispose de sélections par défaut pour de nombreux choix que nous décrivons ci-dessous. La plupart des sections de la console comportent des volets d'aide qui fournissent un contexte supplémentaire.
Vous pouvez modifier les options suivantes :
+ Ajoutez un espace de noms au cluster.
Un espace de noms permet aux services que vous créez dans le cluster de se connecter aux autres services de l'espace de noms sans configuration supplémentaire. Pour de plus amples informations, veuillez consulter [Interconnexion des services Amazon ECS](interconnecting-services.md).
+ Configuration du cluster pour les instances externes
+ Attribuez une AWS KMS clé à votre espace de stockage géré. Pour plus d’informations sur la création d’une clé, consultez la section [Création d’une clé KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le *Guide de l’utilisateur AWS Key Management Service *.
+ Ajoutez des balises pour vous aider à identifier vos clusters.
**Pour créer un nouveau cluster (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 **Configuration de cluster**, configurez les éléments suivants :
+ Pour **Nom du cluster**, saisissez un nom unique.
Le nom peut contenir jusqu'à 255 lettres (minuscules et majuscules), des chiffres et des traits d'union.
+ (Facultatif) Pour que l'espace de noms utilisé pour Service Connect soit différent du nom du cluster, saisissez un nom unique dans **Espace de nom**.
1. (Facultatif) Utilisez Container Insights, développez **Surveillance**, puis sélectionnez une des options suivantes :
+ Pour utiliser Container Insights avec observabilité améliorée comme recommandé, sélectionnez **Container Insights avec observabilité améliorée**.
+ Pour utiliser Container Insights, choisissez **Container Insights**.
1. (Facultatif) Pour utiliser ECS Exec afin de déboguer les tâches dans le cluster, développez **Configuration de la résolution des problèmes**, puis configurez les éléments suivants :
+ Sélectionnez **Activer sur ECS Exec**.
+ (Facultatif) Pour la **AWS KMS clé pour ECS Exec**, entrez l'ARN de la AWS KMS clé que vous souhaitez utiliser pour chiffrer les données de session ECS Exec.
+ (Facultatif) Pour **Journalisation ECS Exec**, choisissez la destination du journal :
+ Pour envoyer des journaux à CloudWatch Logs, choisissez **Amazon CloudWatch**.
+ Pour envoyer les journaux à Amazon S3, choisissez **Amazon S3**.
+ Pour désactiver la journalisation, choisissez **Aucune**.
1. (Facultatif) Chiffrez les données sur le stockage géré. Sous **Chiffrement**, pour **Stockage géré**, entrez l'ARN de la AWS KMS clé que vous souhaitez utiliser pour chiffrer les données du stockage géré.
1. (Facultatif) Pour vous aider à identifier votre cluster, développez **Tags** (balises), puis configurez vos balises.
[Add a tag] Choisissez **Add tag** (Ajouter une balise) et procédez comme suit :
+ Pour **Key** (Clé), saisissez le nom de la clé.
+ Pour **Valeur**, saisissez la valeur de clé.
1. Choisissez **Créer**.
## Étapes suivantes
Vous devez enregistrer les instances auprès du cluster. Pour de plus amples informations, veuillez consulter [Enregistrement d’une instance externe dans un cluster Amazon ECS](ecs-anywhere-registration.md).
Créez une définition de tâche pour le type de lancement externe. Pour de plus amples informations, consultez [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md).
Exécutez vos applications en tant que tâches autonomes ou dans le cadre d’un service. Pour plus d’informations, consultez les ressources suivantes :
+ [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)
# Enregistrement d’une instance externe dans un cluster Amazon ECS
Pour chaque instance externe que vous enregistrez auprès d'un cluster Amazon ECS, le SSM Agent, l'agent de conteneur Amazon ECS et Docker doivent être installés. Pour enregistrer l'instance externe dans un cluster Amazon ECS, elle doit d'abord être enregistrée en tant qu'instance AWS Systems Manager gérée. Vous pouvez créer le script d'installation en quelques clics sur la console Amazon ECS. Le script d'installation inclut une clé d'activation Systems Manager et des commandes pour installer chacun des agents requis et Docker. Le script d'installation doit être exécuté sur votre serveur local ou votre machine virtuelle pour terminer la procédure d'installation et d'enregistrement.
**Note**
Avant d'enregistrer votre instance externe Linux auprès du cluster, créez le fichier `/etc/ecs/ecs.config` sur votre instance externe et ajoutez les paramètres de configuration de l'agent de conteneur souhaités. Vous ne pouvez pas le faire après l'enregistrement de l'instance externe dans un cluster. Pour de plus amples informations, veuillez consulter [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md).
------
#### [ AWS Management 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, sélectionnez la région à utiliser.
1. Dans le panneau de navigation, choisissez **Clusters**.
1. Dans la page **Clusters**, sélectionnez un cluster dans lequel enregistrer votre instance externe.
1. Sur la *name* page **Cluster :**, choisissez l'onglet **Infrastructure**.
1. Sur la page **Register external instances** (Enregistrer des instances externes), effectuez les étapes suivantes.
1. Pour **Activation key duration (in days)** [Durée de la clé d'activation (en jours)], saisissez le nombre de jours pendant lesquels la clé d'activation reste active. Une fois que le nombre de jours que vous avez saisis est écoulé, la clé ne fonctionne plus lors de l'enregistrement d'une instance externe.
1. Pour **Number of instances (Nombre d'instances)**, saisissez le nombre d'instances externes que vous souhaitez enregistrer dans votre cluster avec la clé d'activation.
1. Pour **Instance role (Rôle d'instance)**, choisissez le rôle IAM à associer à vos instances externes. Si aucun rôle n'a déjà été créé, choisissez **Create new role (Créer un rôle)** Pour qu'Amazon ECS crée un rôle en votre nom. Pour plus d'informations sur les autorisations IAM requises pour vos instances externes, consultez [Rôle IAM Amazon ECS Anywhere](iam-role-ecsanywhere.md).
1. Copiez la commande d'inscription. Cette commande doit être exécutée sur chaque instance externe que vous souhaitez enregistrer dans le cluster.
**Important**
La partie bash du script doit être exécutée en tant que root. Si la commande n'est pas exécutée en tant que racine, une erreur est renvoyée.
1. Choisissez **Close** (Fermer).
------
#### [ AWS CLI for Linux operating systems ]
1. Créez une paire d'activations de Systems Manager. Elle est utilisée pour l'activation de l'instance gérée par Systems Manager. La sortie inclut un `ActivationId` et un `ActivationCode`. Vous les utiliserez dans une étape ultérieure. Veillez à spécifier le rôle IAM ECS Anywhere que vous avez créé. Pour de plus amples informations, veuillez consulter [Rôle IAM Amazon ECS Anywhere](iam-role-ecsanywhere.md).
```
aws ssm create-activation --iam-role ecsAnywhereRole | tee ssm-activation.json
```
1. Sur votre serveur local ou votre machine virtuelle (VM), téléchargez le script d'installation.
```
curl --proto "https" -o "/tmp/ecs-anywhere-install.sh" "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh"
```
1. (Facultatif) Sur votre serveur sur site ou votre machine virtuelle (VM), procédez comme suit pour vérifier le script d'installation à l'aide du fichier de signature du script.
1. Téléchargez et installez GnuPG. Pour plus d'informations GNUpg, consultez le site Web de [GnuPG](https://www.gnupg.org). Pour les systèmes Linux, installez `gpg` à l'aide du gestionnaire de package de votre version de Linux.
1. Extrayez la clé publique PGP Amazon ECS.
```
gpg --keyserver hkp://keys.gnupg.net:80 --recv BCE9D9A42D51784F
```
1. Téléchargez la signature du script d'installation. La signature est une signature PGP détachées ASCII, stockée dans un fichier portant l'extension `.asc`.
```
curl --proto "https" -o "/tmp/ecs-anywhere-install.sh.asc" "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh.asc"
```
1. Vérifiez le fichier de script d'installation à l'aide de la clé.
```
gpg --verify /tmp/ecs-anywhere-install.sh.asc /tmp/ecs-anywhere-install.sh
```
La sortie attendue est la suivante :
```
gpg: Signature made Tue 25 May 2021 07:16:29 PM UTC
gpg: using RSA key 50DECCC4710E61AF
gpg: Good signature from "Amazon ECS " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: F34C 3DDA E729 26B0 79BE AEC6 BCE9 D9A4 2D51 784F
Subkey fingerprint: D64B B6F9 0CF3 77E9 B5FB 346F 50DE CCC4 710E 61AF
```
1. Sur votre serveur sur site ou votre machine virtuelle (VM), exécutez le script d'installation. Spécifiez le nom du cluster, la région, l'ID d'activation de Systems Manager et le code d'activation à partir de la première étape.
```
sudo bash /tmp/ecs-anywhere-install.sh \
--region $REGION \
--cluster $CLUSTER_NAME \
--activation-id $ACTIVATION_ID \
--activation-code $ACTIVATION_CODE
```
Pour un serveur local ou une machine virtuelle (VM) sur lequel le pilote NVIDIA est installé pour les charges de travail GPU, vous devez ajouter l'indicateur `--enable-gpu` du script d'installation. Lorsque cet indicateur est spécifié, le script d'installation vérifie que le pilote NVIDIA est en cours d'exécution, puis ajoute les variables de configuration requises pour exécuter vos tâches Amazon ECS. Pour plus d'informations sur l'exécution de charges de travail GPU et la spécification des exigences GPU dans une définition de tâche, consultez [Spécification GPUs dans une définition de tâche Amazon ECS](ecs-gpu-specifying.md).
```
sudo bash /tmp/ecs-anywhere-install.sh \
--region $REGION \
--cluster $CLUSTER_NAME \
--activation-id $ACTIVATION_ID \
--activation-code $ACTIVATION_CODE \
--enable-gpu
```
Pour enregistrer une instance externe existante auprès d'un cluster différent, procédez comme suit.
**Pour enregistrer une instance externe existante auprès d'un cluster différent**
1. Arrêtez l'agent de conteneur Amazon ECS.
```
sudo systemctl stop ecs.service
```
1. Modifiez le fichier `/etc/ecs/ecs.config` et sur la ligne `ECS_CLUSTER`, assurez-vous que le nom du cluster correspond au nom du cluster auprès duquel vous souhaitez enregistrer l'instance externe.
1. Supprimez les données existantes de l'agent Amazon ECS.
```
sudo rm /var/lib/ecs/data/agent.db
```
1. Démarrez l'agent de conteneur Amazon ECS.
```
sudo systemctl start ecs.service
```
------
#### [ AWS CLI for Windows operating systems ]
1. Créez une paire d'activations de Systems Manager. Elle est utilisée pour l'activation de l'instance gérée par Systems Manager. La sortie inclut un `ActivationId` et un `ActivationCode`. Vous les utiliserez dans une étape ultérieure. Veillez à spécifier le rôle IAM ECS Anywhere que vous avez créé. Pour de plus amples informations, veuillez consulter [Rôle IAM Amazon ECS Anywhere](iam-role-ecsanywhere.md).
```
aws ssm create-activation --iam-role ecsAnywhereRole | tee ssm-activation.json
```
1. Sur votre serveur local ou votre machine virtuelle (VM), téléchargez le script d'installation.
```
Invoke-RestMethod -URI "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install.ps1" -OutFile “ecs-anywhere-install.ps1”
```
1. (Facultatif) Le script PowerShell est signé par Amazon et, par conséquent, Windows effectue automatiquement la validation du certificat sur ce dernier. Aucune validation manuelle n'est requise.
Pour vérifier manuellement le certificat, effectuez un clic droit sur le fichier, accédez aux propriétés et utilisez l'onglet Signatures numériques pour obtenir plus de détails.
Cette option n'est disponible que lorsque l'hôte possède le certificat dans le magasin de certificats.
La vérification doit renvoyer des informations semblables à ce qui suit :
```
# Verification (PowerShell)
Get-AuthenticodeSignature -FilePath .\ecs-anywhere-install.ps1
SignerCertificate Status Path
----------------- ------ ----
EXAMPLECERTIFICATE Valid ecs-anywhere-install.ps1
...
Subject : CN="Amazon Web Services, Inc.",...
----
```
1. Sur votre serveur sur site ou votre machine virtuelle (VM), exécutez le script d'installation. Spécifiez le nom du cluster, la région, l'ID d'activation de Systems Manager et le code d'activation à partir de la première étape.
```
.\ecs-anywhere-install.ps1 -Region $Region -Cluster $Cluster -ActivationID $ActivationID -ActivationCode $ActivationCode
```
1. Vérifiez que l'agent de conteneur Amazon ECS est en cours d'exécution.
```
Get-Service AmazonECS
Status Name DisplayName
------ ---- -----------
Running AmazonECS Amazon ECS
```
Pour enregistrer une instance externe existante auprès d'un cluster différent, procédez comme suit.
**Pour enregistrer une instance externe existante auprès d'un cluster différent**
1. Arrêtez l'agent de conteneur Amazon ECS.
```
Stop-Service AmazonECS
```
1. Modifier le paramètre `ECS_CLUSTER` afin que le nom du cluster corresponde au nom du cluster auprès duquel vous souhaitez enregistrer l'instance externe.
```
[Environment]::SetEnvironmentVariable("ECS_CLUSTER", $ECSCluster, [System.EnvironmentVariableTarget]::Machine)
```
1. Supprimez les données existantes de l'agent Amazon ECS.
```
Remove-Item -Recurse -Force $env:ProgramData\Amazon\ECS\data\*
```
1. Démarrez l'agent de conteneur Amazon ECS.
```
Start-Service AmazonECS
```
------
Il AWS CLI peut être utilisé pour créer une activation de Systems Manager avant d'exécuter le script d'installation afin de terminer le processus d'enregistrement de l'instance externe.
# Annulation de l’enregistrement d’une instance externe Amazon ECS
Nous vous recommandons de désenregistrer l'instance à la fois auprès d'Amazon ECS et une AWS Systems Manager fois que vous en aurez terminé avec l'instance. Après l'annulation de l'enregistrement, l'instance externe n'est plus en mesure d'accepter de nouvelles tâches.
Si des tâches sont en cours d'exécution sur l'instance de conteneur lorsque vous annulez l'enregistrement, ces tâches restent en cours d'exécution jusqu'à ce que vous les arrêtiez d'une autre manière. Toutefois, ces tâches ne sont plus surveillées ou prise en compte par Amazon ECS. Si ces tâches sur votre instance externe font partie d'un Amazon ECS service, le planificateur de service commence une autre copie de cette tâche sur une autre instance de conteneur, si possible.
Après avoir désenregistré l'instance, nettoyez les AWS ressources restantes sur l'instance. Vous pouvez ensuite l’enregistrer dans un nouveau cluster.
## Procédure
------
#### [ AWS Management 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 dans laquelle votre instance externe est inscrite.
1. Dans le panneau de navigation, choisissez **Clusters**, puis sélectionnez le cluster qui héberge l'instance externe.
1. Sur la *name* page **Cluster :**, choisissez l'onglet **Infrastructure**.
1. Sous **Constainer instances** (Instances de conteneur), sélectionnez l'ID de l'instance externe pour annuler l'enregistrement. Vous êtes redirigé vers la page de détails de l'instance de conteneur.
1. Sur la *id* page **Instance de conteneur :**, choisissez **Désenregistrer**.
1. Passez en revue le message d'annulation d'enregistrement. Sélectionnez **Deregister from AWS Systems Manager(Annuler l'enregistrement AWS Systems Manager)** pour également annuler l'enregistrement de l'instance externe en tant qu'instance gérée par Systems Manager. Choisissez **Deregister** (Annuler l'enregistrement).
**Note**
Vous pouvez annuler l'enregistrement de l'instance externe en tant qu'instance gérée par Systems Manager dans la console Systems Manager. Pour plus d’informations, consultez la section [Annuler l’enregistrement des nœuds gérés dans un environnement hybride et multicloud](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet-manager-deregister-hybrid-nodes.html) dans le *Guide de l’utilisateur AWS Systems Manager *.
1. Après avoir désenregistré l'instance, nettoyez les AWS ressources sur votre serveur local ou sur votre machine virtuelle.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/ecs-anywhere-deregistration.html)
------
#### [ AWS CLI ]
1. Vous avez besoin de l'ID d'instance et de l'ARN de l'instance de conteneur pour annuler l'enregistrement de l'instance de conteneur. Si vous n'avez pas ces valeurs, exécutez les commandes suivantes.
Exécutez la commande suivante pour obtenir l'ID d'instance.
Vous utilisez l'ID d'instance (`instanceID`) pour obtenir l'ARN de l'instance de conteneur (`containerInstanceARN`).
```
instanceId=$(aws ssm describe-instance-information --region "{{ region }}" | jq ".InstanceInformationList[] |select(.IPAddress==\"{{ IPv4 Address }}\") | .InstanceId" | tr -d'"'
```
Exécutez les commandes suivantes.
Vous utilisez l'`containerInstanceArn` comme paramètre dans la commande pour annuler l'enregistrement de l'instance (`deregister-container-instance`).
```
instances=$(aws ecs list-container-instances --cluster "{{ cluster }}" --region "{{ region }}" | jq -c '.containerInstanceArns')
containerInstanceArn=$(aws ecs describe-container-instances --cluster "{{ cluster }}" --region "{{ region }}" --container-instances $instances | jq ".containerInstances[] | select(.ec2InstanceId==\"{{ instanceId }}\") | .containerInstanceArn" | tr -d '"')
```
1. Exécutez la commande suivante pour purger l'instance.
```
aws ecs update-container-instances-state --cluster "{{ cluster }}" --region "{{ region }}" --container-instances "{{ containerInstanceArn }}" --status DRAINING
```
1. Une fois le drainage de l'instance de conteneur terminé, exécutez la commande suivante pour annuler son enregistrement.
```
aws ecs deregister-container-instance --cluster "{{ cluster }}" --region "{{ region }}" --container-instance "{{ containerInstanceArn }}"
```
1. Exécutez la commande suivante pour supprimer l'instance de conteneur de SSM.
```
aws ssm deregister-managed-instance --region "{{ region }}" --instance-id "{{ instanceId }}"
```
1. Après avoir désenregistré l'instance, nettoyez les AWS ressources sur votre serveur local ou sur votre machine virtuelle.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/ecs-anywhere-deregistration.html)
------
# Mise à jour de l' AWS Systems Manager agent et de l'agent de conteneur Amazon ECS sur une instance externe
Votre serveur ou machine virtuelle sur site doit exécuter à la fois l' AWS Systems Manager agent (agent SSM) et l'agent de conteneur Amazon ECS lors de l'exécution de charges de travail Amazon ECS. AWS publie de nouvelles versions de ces agents lorsque des fonctionnalités sont ajoutées ou mises à jour. Si vos instances externes utilisent une version antérieure de l'un ou l'autre des agents, vous pouvez les mettre à jour à l'aide des procédures suivantes.
## Mise à jour de SSM Agent sur une instance externe
AWS Systems Manager vous recommande d'automatiser le processus de mise à jour de l'agent SSM sur vos instances. Ils fournissent plusieurs méthodes pour automatiser les mises à jour. Pour de plus amples informations, veuillez consulter [Automatisation des mises à jour sur SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-automatic-updates.html) dans le *Guide de l'utilisateur AWS Systems Manager *.
## Mise à jour de l'agent Amazon ECS sur une instance externe
Sur vos instances externes, l'agent de conteneur Amazon ECS est mis à jour en mettant à niveau le package `ecs-init`. La mise à jour de l'agent Amazon ECS n'interrompt pas les tâches ou les services en cours d'exécution. Amazon ECS fournit le package `ecs-init` et le fichier SIGNATURE dans un compartiment Amazon S3 dans chaque région. En commençant par `ecs-init` version `1.52.1-1`, Amazon ECS fournit des packages `ecs-init` distincts à utiliser en fonction du système d'exploitation et de l'architecture système que votre instance externe utilise.
Utilisez le tableau suivant pour déterminer le package `ecs-init` que vous devez télécharger en fonction du système d'exploitation et de l'architecture système que votre instance externe utilise.
**Note**
Vous pouvez déterminer le système d'exploitation et l'architecture système que votre instance externe utilise à l'aide des commandes suivantes.
```
cat /etc/os-release
uname -m
```
| Systèmes d'exploitation (architecture) | package ecs-init |
| --- | --- |
| CentOS 7 (x86\$164) CentOS 8 (x86\$164) CentOS Stream 9 (x86\$164) SUSE Enterprise Server 15 (x86\$164) RHEL 7 (x86\$164) RHEL 8 (x86\$164) | `amazon-ecs-init-latest.x86_64.rpm` |
| CentOS 7 (aarch64) CentOS 8 (aarch64) CentOS Stream 9 (aarch64) RHEL 7 (aarch64) | `amazon-ecs-init-latest.aarch64.rpm` |
| Debian 9 (x86\$164) Debian 10 (x86\$164) Debian 11 (x86\$164) Debian 12 (x86\$164) Ubuntu 18 (x86\$164) Ubuntu 20 (x86\$164) Ubuntu 22 (x86\$164) Ubuntu 24 (x86\$164) | `amazon-ecs-init-latest.amd64.deb` |
| Debian 9 (aarch64) Debian 10 (aarch64) Debian 11 (aarch64) Debian 12 (aarch64) Ubuntu 18 (aarch64) Ubuntu 20 (aarch64) Ubuntu 22 (aarch64) Ubuntu 24 (aarch64) | `amazon-ecs-init-latest.arm64.deb` |
Procédez comme suit pour mettre à jour l'agent Amazon ECS.
**Pour mettre à jour l'agent Amazon ECS**
1. Confirmez la version de l'agent Amazon ECS que vous exécutez.
```
curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
```
1. Télécharger le package `ecs-init` pour votre système d'exploitation et votre architecture système. Amazon ECS fournit le fichier de package `ecs-init` dans un compartiment Amazon S3 dans chaque région. Assurez-vous de remplacer l'**identifiant dans la commande par le nom de la région (par exemple`us-west-2`) dont vous êtes le plus proche géographiquement.
**amazon-ecs-init-latest.x86\$164 .rpm**
```
curl -o amazon-ecs-init.rpm https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.x86_64.rpm
```
**amazon-ecs-init-latest.aarch64 tr/min**
```
curl -o amazon-ecs-init.rpm https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.aarch64.rpm
```
**amazon-ecs-init-latest.amd64.deb**
```
curl -o amazon-ecs-init.deb https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.amd64.deb
```
**amazon-ecs-init-latest.arm64.deb**
```
curl -o amazon-ecs-init.deb https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.arm64.deb
```
1. (Facultatif) Vérification de la validité du fichier de package `ecs-init` à l'aide de la signature PGP.
1. Téléchargez et installez GnuPG. Pour plus d'informations GNUpg, consultez le site Web de [GnuPG](https://www.gnupg.org). Pour les systèmes Linux, installez `gpg` à l'aide du gestionnaire de package de votre version de Linux.
1. Extrayez la clé publique PGP Amazon ECS.
```
gpg --keyserver hkp://keys.gnupg.net:80 --recv BCE9D9A42D51784F
```
1. Téléchargez la signature de package `ecs-init`. La signature est une signature PGP détachées ASCII, stockée dans un fichier portant l'extension `.asc`. Amazon ECS fournit le fichier SIGNATURE dans un compartiment Amazon S3 dans chaque région. Assurez-vous de remplacer l'**identifiant dans la commande par le nom de la région (par exemple`us-west-2`) dont vous êtes le plus proche géographiquement.
**amazon-ecs-init-latest.x86\$164 .rpm**
```
curl -o amazon-ecs-init.rpm.asc https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.x86_64.rpm.asc
```
**amazon-ecs-init-latest.aarch64 tr/min**
```
curl -o amazon-ecs-init.rpm.asc https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.aarch64.rpm.asc
```
**amazon-ecs-init-latest.amd64.deb**
```
curl -o amazon-ecs-init.deb.asc https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.amd64.deb.asc
```
**amazon-ecs-init-latest.arm64.deb**
```
curl -o amazon-ecs-init.deb.asc https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.arm64.deb.asc
```
1. Vérifiez le fichier de package `ecs-init` à l'aide de la clé.
**Pour les packages `rpm`**
```
gpg --verify amazon-ecs-init.rpm.asc ./amazon-ecs-init.rpm
```
**Pour les packages `deb`**
```
gpg --verify amazon-ecs-init.deb.asc ./amazon-ecs-init.deb
```
La sortie attendue est la suivante :
```
gpg: Signature made Fri 14 May 2021 09:31:36 PM UTC
gpg: using RSA key 50DECCC4710E61AF
gpg: Good signature from "Amazon ECS " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: F34C 3DDA E729 26B0 79BE AEC6 BCE9 D9A4 2D51 784F
Subkey fingerprint: D64B B6F9 0CF3 77E9 B5FB 346F 50DE CCC4 710E 61AF
```
1. Installez le package `ecs-init`.
**Pour le package `rpm` sur CentOS 7, CentOS 8 et RHEL 7**
```
sudo yum install -y ./amazon-ecs-init.rpm
```
**Pour le package `rpm` sur SUSE Enterprise Server 15**
```
sudo zypper install -y --allow-unsigned-rpm ./amazon-ecs-init.rpm
```
**Pour le package `deb`**
```
sudo dpkg -i ./amazon-ecs-init.deb
```
1. Redémarrez le service `ecs`.
```
sudo systemctl restart ecs
```
1. Vérifiez que la version d'agent Amazon ECS a été mise à jour.
```
curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
```
# Mise à jour d’un cluster Amazon ECS.
Vous pouvez modifier les propriétés de cluster suivantes :
+ Définissez un fournisseur de capacité par défaut.
Chaque cluster dispose d'un ou plusieurs fournisseurs de capacité et éventuellement d'une stratégie de fournisseur de capacité facultative. La stratégie de fournisseur de capacité détermine la façon dont les tâches sont réparties entre les fournisseurs de capacité du cluster. Lorsque vous exécutez une tâche autonome ou que vous créez un service, vous pouvez utiliser soit la stratégie de fournisseur de capacité par défaut du cluster, soit une stratégie de fournisseur de capacité qui remplace celle par défaut.
+ Activez Container Insights.
CloudWatch Container Insights collecte, agrège et résume les métriques et les journaux de vos applications conteneurisées et de vos microservices. Conteneur Insights fournit également des informations de diagnostic (par exemple sur les échecs de redémarrage des conteneurs) que vous pouvez utiliser pour isoler les problèmes et les résoudre rapidement. Pour de plus amples informations, veuillez consulter [Surveillance des conteneurs Amazon ECS au moyen de Container Insights avec observabilité améliorée](cloudwatch-container-insights.md).
+ Ajoutez des étiquettes pour vous aider à identifier vos clusters.
**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 **Clusters**.
1. Sur la page **Clusters**, choisissez le cluster.
1. Sur la *name* page **Cluster :**, choisissez **Mettre à jour le cluster**.
1. Pour définir le fournisseur de capacité par défaut, sous **Stratégie de fournisseur de capacité par défaut**, sélectionnez **Ajouter plus**.
1. Pour **Fournisseur de capacité**, choisissez le fournisseur de capacité.
1. (Facultatif) Pour **Base**, saisissez le nombre minimal de tâches exécutées sur le fournisseur de capacité.
Vous ne pouvez définir une valeur de **Base** que pour un seul fournisseur de capacité.
1. (Facultatif) Pour **Poids**, saisissez le pourcentage relatif du nombre total de tâches lancées qui utilisent le fournisseur de capacité spécifié.
1. (Facultatif) Répétez les étapes pour tous les fournisseurs de capacité supplémentaires.
1. Pour activer ou désactiver Container Insights, développez **Surveillance**, puis activez **Utiliser Container Insights**.
1. Pour vous aider à identifier votre cluster, développez **Balises**, puis configurez vos balises.
[Add a tag] Choisissez **Add tag** (Ajouter une balise) et procédez comme suit :
+ Pour **Key** (Clé), saisissez le nom de la clé.
+ Pour **Value** (Valeur), saisissez la valeur de clé.
[Remove a tag] Choisissez **Remove** (Supprimer) à la droite de la clé et de la valeur de la balise.
1. Choisissez **Mettre à jour**.
# Suppression d’un cluster Amazon ECS.
Si vous avez terminé d'utiliser un cluster, vous pouvez le supprimer. Une fois que vous avez supprimé le cluster, il passe à l'état `INACTIVE`. Les clusters ayant un état `INACTIVE` peuvent rester détectables dans votre compte pendant un certain temps. Cependant, cela est susceptible de changer à terme. Il est donc important de ne pas compter sur la persistance des clusters `INACTIVE`.
Avant de supprimer un cluster, vous devez effectuer les opérations suivantes :
+ Supprimez tous les services du cluster. Pour de plus amples informations, veuillez consulter [Suppression d’un service Amazon ECS à l’aide de la console](delete-service-v2.md).
+ Arrêtez toutes les tâches en cours d'exécution. Pour de plus amples informations, veuillez consulter [Arrêt d’une tâche Amazon ECS](standalone-task-stop.md).
+ Annulez l'enregistrement de toutes les instances de conteneur enregistrées dans le cluster. Pour de plus amples informations, veuillez consulter [Annulation de l’enregistrement d’instance de conteneur Amazon ECS](deregister_container_instance.md).
+ Supprimez l'espace de noms. Pour plus d'informations, consultez [Suppression des espaces de noms](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) dans le *Guide du développeur AWS Cloud Map *.
**Procédure**
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** sélectionnez le cluster à supprimer.
1. Dans le coin supérieur droit de la page, choisissez **Delete Cluster** (Supprimer le cluster).
Un message s'affiche lorsque vous n'avez pas supprimé toutes les ressources associées au cluster.
1. Dans le champ de confirmation, saisissez **Supprimer *cluster name***.
# Annulation de l’enregistrement d’instance de conteneur Amazon ECS
**Important**
Cette rubrique concerne uniquement les instances de conteneur créées dans Amazon EC2. Pour plus d'informations sur l'annulation de l'enregistrement des instances externes, veuillez consulter[Annulation de l’enregistrement d’une instance externe Amazon ECS](ecs-anywhere-deregistration.md).
Lorsque vous avez terminé avec une instance de conteneur sauvegardée par Amazon EC2, vous pouvez en annuler l'enregistrement dans votre cluster. Après l'annulation de l'enregistrement, l'instance de conteneur n'est plus en mesure d'accepter de nouvelles tâches.
Si des tâches sont en cours d'exécution sur l'instance du conteneur lorsque vous annulez l'enregistrement, ces tâches restent en cours d'exécution jusqu'à ce que vous résiliez l'instance ou les tâches d'une autre manière. Toutefois, ces tâches sont orphelines, ce qui signifie qu'elles ne sont plus surveillées ou prise en compte par Amazon ECS. Si une tâche orpheline sur votre instance de conteneur fait partie d'un service Amazon ECS service, le planificateur de service commence une autre copie de cette tâche sur une autre instance de conteneur, si possible. L'enregistrement de tout conteneur des tâches de service orphelines enregistré avec un groupe cible Application Load Balancer est annulé. Le drainage de la connexion commence en fonction des paramètres de l'équilibreur de charge ou du groupe cible. Si une tâche orpheline utilise le mode réseau `awsvpc`, leurs interfaces réseau Elastic sont supprimées.
Si vous prévoyez d'utiliser l'instance de conteneur à d'autres fins après l'annulation de l'enregistrement, vous devez arrêter toutes les tâches en cours d'exécution sur l'instance de conteneur avant l'annulation de l'enregistrement. Vous éviterez ainsi que les tâches orphelines consomment des ressources.
Lors de la désinscription d'une instance de conteneur, tenez compte des considérations suivantes.
+ Étant donné que chaque instance de conteneur possède des informations d'état uniques, elles ne peuvent pas faire l'objet d'une annulation d'enregistrement dans un cluster et d'un réenregistrement dans un autre. Pour déplacer des ressources d'instance de conteneur, nous vous recommandons de résilier les instances de conteneur d'un cluster et d'en lancer de nouvelles dans le nouveau cluster. Pour de plus amples informations, consultez la section [Résilier votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) dans le *Guide de l’utilisateur Amazon EC2* et [Lancement d'une instance de conteneur Amazon ECS Linux](launch_container_instance.md).
+ Si l'instance de conteneur est gérée par un groupe ou une CloudFormation pile Auto Scaling, mettez fin à l'instance en mettant à jour le groupe ou la CloudFormation pile Auto Scaling. Sinon, le groupe Auto Scaling ou CloudFormation créera une instance après sa résiliation.
+ Si vous résiliez une instance de conteneur en cours d'exécution avec un agent de conteneur Amazon ECS connecté, l'agent annule automatiquement l'enregistrement de l'instance dans votre cluster. L'annulation de l'enregistrement des instances de conteneur arrêtées ou des instances ayant des agents déconnectés n'est pas automatique lorsque ces instances sont résiliées.
+ L'annulation de l'enregistrement d'une instance de conteneur supprime l'instance d'un cluster, mais ne résilie pas l'instance Amazon EC2. Si vous avez fini d'utiliser l'instance, veillez à la résilier pour arrêter la facturation. Pour de plus amples informations, veuillez consulter [Résilier une instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) dans le *Guide de l'utilisateur Amazon EC2*.
## Procédure
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 dans laquelle votre instance externe est inscrite.
1. Dans le panneau de navigation, choisissez **Clusters**, puis sélectionnez le cluster qui héberge l'instance.
1. Sur la *name* page **Cluster :**, choisissez l'onglet **Infrastructure**.
1. Sous **Constainer instances** (Instances de conteneur), sélectionnez l'ID d'instance pour annuler l'enregistrement. Vous êtes redirigé vers la page de détails de l'instance de conteneur.
1. Sur la *id* page **Instance de conteneur :**, choisissez **Désenregistrer**.
1. Dans le message de confirmation, **Annuler l’inscription**.
1. Si vous n'avez plus besoin de l'instance de conteneur, résiliez l'instance Amazon EC2 sous-jacente. Pour plus d’informations, consultez [Résilier une instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) dans le *Guide de l’utilisateur Amazon EC2*.
# Drainage des instances de conteneur Amazon ECS
Il peut arriver que vous deviez supprimer une instance de conteneur de votre cluster, par exemple pour effectuer des mises à jour du système ou réduire verticalement la capacité du cluster. Amazon ECS offre la possibilité de transférer une instance de conteneur vers un état `DRAINING`. C'est ce que l'on appelle le *drainage des instances de conteneur*. Lorsqu'une instance de conteneur est définie sur `DRAINING`, Amazon ECS bloque la planification du placement des nouvelles tâches sur l'instance de conteneur.
## Comportement de drainage pour les services
Toutes les tâches faisant partie d'un service dans un état `PENDING` sont arrêtées immédiatement. S'il existe une capacité d'instance de conteneur disponible dans le cluster, le planificateur de service va démarrer les tâches de remplacement. S'il n'y a pas assez de capacité d'instance de conteneur, un message d'événement de service sera envoyé pour indiquer le problème.
Les tâches faisant partie d'un service sur l'instance de conteneur qui se trouvent à l'état `RUNNING` passent à l'état `STOPPED`. Le planificateur de service tente de remplacer les tâches en fonction du type de déploiement du service et des paramètres de configuration du déploiement, `minimumHealthyPercent` et `maximumPercent`. Pour plus d’informations, consultez [Services Amazon ECS](ecs_services.md) et [Paramètres de définition d’un service Amazon ECS](service_definition_parameters.md).
+ Si `minimumHealthyPercent` est inférieur à 100 %, le planificateur peut ignorer `desiredCount` temporairement pendant le remplacement de tâche. Par exemple, si le `desiredCount` est de quatre tâches, un minimum de 50 % permet au planificateur d'arrêter deux tâches existantes avant de commencer deux nouvelles tâches. Si le minimum est de 100 %, le planificateur de service ne peut pas supprimer les tâches existantes tant que les tâches de remplacement sont considérées comme saines. Si les tâches des services qui n'utilisent pas d'équilibreur de charge ont l'état `RUNNING`, elles sont considérées comme saines. Les tâches des services qui utilisent un équilibreur de charge sont considérées comme saines si elles se trouvent à l'état `RUNNING` et si l'instance de conteneur sur laquelle elles sont hébergées est signalée comme saine par l'équilibreur de charge.
**Important**
Si vous utilisez des instances Spot et que la valeur `minimumHealthyPercent` est supérieure ou égale à 100 %, le service ne disposera pas de suffisamment de temps pour remplacer la tâche avant la fin de l'instance Spot.
+ Le paramètre `maximumPercent` représente une limite supérieure du nombre de tâches en cours d'exécution lors du remplacement des tâches, ce qui vous permet de définir la taille du lot de remplacement. Par exemple, si le `desiredCount` est de quatre tâches, un maximum de 200 % lance quatre nouvelles tâches avant d'arrêter les quatre tâches à drainer (à condition de disposer des ressources de cluster nécessaires). Si le maximum est de 100 %, les tâches de remplacement ne peuvent pas commencer tant que les tâches de drainage sont arrêtées.
**Important**
Si `minimumHealthyPercent` et `maximumPercent` sont à 100 %, alors le service ne peut pas supprimer les tâches existantes et ne peut pas non plus démarrer les tâches de remplacement. Cela empêche le drainage des instances de conteneur ainsi que d'effectuer de nouveaux déploiements.
## Comportement de drainage pour les tâches autonomes
Toutes les tâches autonomes à l'état `PENDING` ou `RUNNING` ne sont pas affectées. Vous devez attendre qu'elles s'arrêtent d'elles-mêmes ou les arrêter manuellement. L'instance de conteneur restera dans l'état `DRAINING`.
## Comportement du drainage pour les instances gérées Amazon ECS
La résiliation des instances gérées Amazon ECS garantit des transitions de charge de travail harmonieuses tout en optimisant les coûts et en préservant l'intégrité du système. Le système de résiliation offre trois voies décisionnelles distinctes pour la résiliation d’instance, chacune présentant des caractéristiques différentes en termes de délais et d’impact sur le client.
Résiliation initiée par le client
Permet de contrôler directement la suppression des instances lorsque vous devez immédiatement retirer des instances de conteneur du service. Vous exécutez `deregister-container-instance` avec le paramètre de `force` requête défini sur true. Cela signifie qu'une résiliation immédiate est requise malgré les charges de travail en cours.
Résiliation initiée par le système en cas d’inactivité
Amazon ECS Managed Instances surveille en permanence et optimise les coûts de manière proactive en mettant fin aux instances de conteneur Amazon ECS inactives qui n'exécutent aucune tâche. ECS utilise un délai heuristique pour donner aux instances de conteneur la possibilité d'acquérir des tâches nouvellement lancées avant d'être interrompues. Cela peut être personnalisé à l'aide du paramètre de configuration du fournisseur de capacité `scaleInAfter` Amazon ECS Managed Instances.
Résiliation provoquée par l’actualisation de l’infrastructure
Amazon ECS Managed Instances gère et met à jour automatiquement le logiciel sur les instances de conteneur gérées afin de garantir la sécurité et la conformité tout en préservant la disponibilité de la charge de travail. Pour plus d'informations, consultez la section relative aux [correctifs dans les instances gérées Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-instances-patching.html).
Le système de résiliation met en œuvre une approche en deux phases qui équilibre la continuité de la charge de travail avec les exigences de gestion de l’infrastructure.
**Phase 1 : période d’achèvement progressif**
Au cours de cette phase, le système met en œuvre des stratégies de drainage progressif qui privilégient la continuité de la charge de travail. Les tâches de service sont traitées de manière progressive par le biais des processus de planification habituels d’Amazon ECS. Les tâches autonomes continuent de s’exécuter, car elles peuvent se terminer naturellement. Le système veille à ce que toutes les tâches atteignent l’état d’arrêt grâce à des processus d’achèvement naturels.
**Phase 2 : application stricte des délais**
Lorsque l’achèvement progressif ne permet pas d’atteindre les objectifs de résiliation dans des délais acceptables, le système met en œuvre une application stricte des délais. Le délai strict est généralement fixé à la date de début du drainage plus sept jours, ce qui laisse suffisamment de temps pour mener à bien l’opération tout en respectant les exigences opérationnelles. L’application comprend des procédures automatiques d’annulation de l’enregistrement forcée et l’arrêt immédiat de toutes les tâches restantes, quel que soit le statut d’achèvement.
Une instance de conteneur a terminé le drainage lorsque toutes les tâches qui s'exécutent sur l'instance passent à l'état `STOPPED`. L'instance de conteneur reste à l'état `DRAINING` jusqu'à ce qu'elle soit réactivée ou supprimée. Vous pouvez vérifier l'état des tâches sur l'instance de conteneur en utilisant l'[ListTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ListTasks.html)opération avec le `containerInstance` paramètre pour obtenir une liste des tâches de l'instance, suivie d'une [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html)opération avec le nom de ressource Amazon (ARN) ou l'ID de chaque tâche pour vérifier l'état de la tâche.
Lorsque vous êtes prêt pour que l'instance de conteneur recommence à héberger des tâches, vous modifiez l'état de l'instance de conteneur de `DRAINING` en `ACTIVE`. Le planificateur de service Amazon ECS prend alors à nouveau en compte l’instance de conteneur pour le placement des tâches.
## Procédure
Les étapes suivantes peuvent être utilisées pour définir une instance de conteneur à drainer à l'aide de la nouvelle AWS Management Console.
Vous pouvez également utiliser l'action ou la [update-container-instances-state](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-container-instances-state.html)commande de l'[UpdateContainerInstancesState](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateContainerInstancesState.html)API pour modifier le statut d'une instance de conteneur en`DRAINING`.
**AWS Management 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 **Clusters**.
1. Sur la page **Clusters**, choisissez un cluster qui héberge vos instances.
1. Sur la *name* page **Cluster :**, choisissez l'onglet **Infrastructure**. Puis, sous **Container instances** (Instances de conteneur), cochez la case correspondant à chaque instance de conteneur que vous souhaitez drainer.
1. Choisissez **Actions**, **Drain** (Drainer).
# Modification du type ou de la taille de l'instance en dehors du groupe Auto Scaling
AWS vous recommande de garder votre infrastructure immuable. Si vous devez modifier la taille des instances, vous pouvez soit :
+ Effectuez une mise à l'échelle horizontale et ajoutez des instances supplémentaires. Ensuite, placez des tâches supplémentaires sur ces instances, ou vous
+ Effectuez une mise à l'échelle verticale en lançant une nouvelle larger/smaller instance, puis en vidant l'ancienne instance.
Ces deux approches permettront de minimiser l'impact sur la disponibilité des applications.
Si vous avez utilisé une autre méthode pour modifier l'instance, le message d'erreur suivant peut s'afficher :
```
Container instance type changes are not supported.
```
Lorsque cette erreur s'affiche, effectuez les opérations suivantes :
1. Lancez de nouvelles instances avec le type d'instance souhaité.
1. Videz vos anciens types d'instances. Pour de plus amples informations, veuillez consulter [Drainage des instances de conteneur Amazon ECS](container-instance-draining.md).
# Instances de conteneur EC2 Amazon ECS
L’agent Amazon ECS est un processus qui s’exécute sur chaque instance de conteneur enregistrée auprès de votre cluster. Il facilite la communication entre vos instances de conteneur et Amazon ECS.
**Note**
Sur les instances de conteneur Linux, le conteneur d’agents monte des répertoires de premier niveau tels que `/lib`, `/lib64` et `/proc`. Ceci est nécessaire pour les fonctionnalités d’ECS telles que les volumes Amazon EBS, le mode réseau `awsvpc`, Amazon ECS Service Connect et FireLens pour Amazon ECS.
Chaque version d'agent de conteneur Amazon ECS prend en charge un ensemble de différentes fonctions et fournit des correctifs des versions précédentes. Dans la mesure du possible, nous recommandons toujours d'utiliser la dernière version de l'agent de conteneur Amazon ECS. 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).
L’agent de conteneur Amazon ECS contient l’image `amazon-ecs-pause`. Amazon ECS utilise cette image pour les tâches qui utilisent le mode réseau `awsvpc`.
Pour voir quelles fonctionnalités et améliorations sont incluses dans chaque version de l'agent, consultez [https://github.com/aws/amazon-ecs-agent/releases](https://github.com/aws/amazon-ecs-agent/releases).
**Important**
La version minimale de Docker pour des métriques fiables est la version `v20.10.13` et les versions ultérieures, qui sont incluses dans l'AMI `20220607` optimisée pour Amazon ECS et les versions plus récentes.
La version de l'agent Amazon ECS `1.20.0` et les versions plus récentes ne prennent plus en charge les versions de Docker antérieures à `18.01.0`.
## Cycle de vie
Lorsque l'agent de conteneur Amazon ECS enregistre une instance Amazon EC2 dans votre cluster, le statut de l'instance Amazon EC2 est `ACTIVE` et le statut de connexion de l'agent est `TRUE`. Cette instance de conteneur peut exécuter des demandes de tâches.
Si vous arrêtez (sans la résilier) une instance de conteneur, son statut reste `ACTIVE`, mais le statut de connexion de l'agent devient `FALSE` en quelques minutes. Toutes les tâches qui étaient en cours d'exécution sur l'instance de conteneur s'arrêtent. Si vous redémarrez l'instance de conteneur, l'agent de conteneur se connecte à nouveau avec le service Amazon ECS service et vous êtes à nouveau en mesure d'exécuter des tâches sur l'instance.
Si vous remplacez le statut d'une instance de conteneur par `DRAINING`, les nouvelles tâches ne sont pas placées sur l'instance de conteneur. Toutes les tâches de service en cours d'exécution sur l'instance de conteneur sont supprimées, si possible, afin que vous puissiez effectuer les mises à jour du système. Pour de plus amples informations, veuillez consulter [Drainage des instances de conteneur Amazon ECS](container-instance-draining.md).
Si vous annulez l'enregistrement d'une instance de conteneur ou la résiliez, le statut de l'instance de conteneur passe immédiatement à `INACTIVE` et l'instance de conteneur ne figure plus dans la liste des instances de conteneur. Cependant, vous pouvez toujours décrire l'instance de conteneur pendant une heure après la résiliation. Après un délai d'une heure, la description de l'instance n'est plus disponible.
Vous pouvez drainer les instances manuellement ou créer un hook de cycle de vie du groupe Auto Scaling pour définir l'état de l'instance sur `DRAINING`. Pour plus d'informations sur les hooks de cycle de vie Auto Scaling, consultez [Hooks de cycle de vie Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html).
## Prise en charge de Docker
Amazon ECS prend en charge les deux dernières versions majeures de Docker publiées sur Amazon Linux. Actuellement, cela inclut Docker 20.10.x et Docker 25.x.
La version minimale requise de Docker pour Amazon ECS se trouve dans le [fichier de spécification de l'agent Amazon ECS](https://github.com/aws/amazon-ecs-agent/blob/dev/packaging/amazon-linux-ami-integrated/ecs-agent.spec#L53) sur GitHub.
Lorsque vous utilisez l’AMI optimisée pour Amazon ECS, Docker est préinstallé et configuré pour fonctionner avec l’agent de conteneur Amazon ECS. L’AMI inclut une version de Docker testée et prise en charge par Amazon ECS.
**Note**
Amazon ECS prend en charge plusieurs versions de Docker, mais nous vous recommandons d’utiliser la version Docker fournie avec l’AMI optimisée pour Amazon ECS pour une compatibilité et un support optimaux.
## AMI optimisée pour Amazon ECS
Pour plus d'informations sur l'AMI optimisée pour Amazon ECS, consultez [Amazon ECS-optimized](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html) Linux. AMIs
## Informations supplémentaires
Les pages suivantes fournissent des informations supplémentaires sur les modifications :
+ Connectez-vous à la liste des [modifications apportées à l'agent Amazon ECS](https://github.com/aws/amazon-ecs-agent/blob/master/CHANGELOG.md) GitHub
+ [Notes de mise à jour pour Amazon Linux 2](https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html).
+ [Notes de mise à jour Docker Engine](https://docs.docker.com/engine/release-notes/27/) dans la documentation Docker
+ [Documentation du pilote NVIDIA](https://docs.nvidia.com/datacenter/tesla/index.html) dans la documentation NVIDIA
# Configuration de l'agent de conteneur Amazon ECS
**S’applique à** : instances EC2
L’agent de conteneur Amazon ECS prend en charge un certain nombre d’options de configuration, dont la plupart sont définies via des variables d’environnement.
Si votre instance de conteneur a été lancée avec une variante Linux de l'AMI optimisée pour Amazon ECS, vous pouvez définir ces variables d'environnement dans le fichier `/etc/ecs/ecs.config`, puis redémarrer l'agent. Vous pouvez également écrire ces variables de configuration dans vos instances de conteneur avec les données utilisateur Amazon EC2 lors du lancement. Pour de plus amples informations, veuillez consulter [Démarrage des instances de conteneurs Amazon ECS Linux pour transmettre des données](bootstrap_container_instance.md).
Si votre instance de conteneur a été lancée avec une variante Windows de l'AMI optimisée pour Amazon ECS, vous pouvez définir ces variables d'environnement à l'aide de la PowerShell SetEnvironmentVariable commande, puis redémarrer l'agent. Pour plus d’informations, consultez la section [Exécuter des commandes lorsque vous lancez une instance EC2 avec des données utilisateur fournies](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) dans le *Guide de l’utilisateur Amazon EC2* et [Amorçage des instances de conteneurs Windows Amazon ECS pour transmettre des données](bootstrap_windows_container_instance.md).
Si vous démarrez manuellement l'agent de conteneur Amazon ECS (pour les applications non optimisées pour Amazon ECS AMIs), vous pouvez utiliser ces variables d'environnement dans la **docker run** commande que vous utilisez pour démarrer l'agent. Utilisez ces variables avec la syntaxe `--env=VARIABLE_NAME=VARIABLE_VALUE`. Pour les informations sensibles, telles que les informations d'authentification des référentiels privés, vous devez stocker vos variables d'environnement d'agent dans un fichier et les transmettre toutes à la fois avec l'option `--env-file path_to_env_file`. Vous pouvez utiliser les commandes suivantes pour ajouter les variables.
```
sudo systemctl stop ecs
sudo vi /etc/ecs/ecs.config
# And add the environment variables with VARIABLE_NAME=VARIABLE_VALUE format.
sudo systemctl start ecs
```
## Exécution de l’agent Amazon ECS avec l’espace de noms PID de l’hôte
Par défaut, l’agent Amazon ECS s’exécute avec son propre espace de noms PID. Dans les configurations suivantes, vous pouvez configurer l’agent Amazon ECS pour qu’il s’exécute avec l’espace de noms PID de l’hôte :
+ SELinux le mode d'application est activé.
+ La politique de SELinux sécurité de Docker est définie sur true.
Vous pouvez configurer ce comportement en définissant la variable d’environnement `ECS_AGENT_PID_NAMESPACE_HOST` sur `true` dans votre fichier `/etc/ecs/ecs.config`. Lorsque cette variable est activée, le conteneur de l'agent Amazon ECS `ecs-init` démarre avec l'espace de noms PID de l'hôte (`--pid=host`), ce qui permet à l'agent de s'amorcer correctement dans SELinux les environnements d'application. Ces fonctionnalités sont disponibles dans les versions `1.94.0` et ultérieures de l’agent Amazon ECS.
Pour activer cette fonctionnalité, ajoutez la ligne suivante à votre fichier `/etc/ecs/ecs.config` :
```
ECS_AGENT_PID_NAMESPACE_HOST=true
```
Après avoir effectué cette modification, redémarrez l’agent Amazon ECS pour que la modification soit prise en compte :
```
sudo systemctl restart ecs
```
Les fonctionnalités suivantes ne fonctionneront pas : le mode d' SELinux exécution est activé et la politique de sécurité Docker est définie sur true, même lorsqu'elle `ECS_AGENT_PID_NAMESPACE_HOST=true` est définie.
+ Amazon ECS Exec
+ Attacher une tâche Amazon EBS
+ Service Connect
+ FireLens pour Amazon ECS
## Paramètres disponibles
Pour plus d'informations sur les paramètres de configuration de l'agent de conteneur Amazon ECS disponibles, consultez [Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) on GitHub.
# Stockage de la configuration d’instance de conteneur Amazon ECS dans Amazon S3
La configuration de l’agent de conteneur Amazon ECS est contrôlée avec les variables d’environnement. Les variantes Linux de l'AMI optimisée pour Amazon ECS vérifient la présence de ces variables dans `/etc/ecs/ecs.config` lorsque l'agent de conteneur démarre et configurent l'agent en conséquence. Les variables d’environnement non sensibles, telles que `ECS_CLUSTER`, peuvent être transmises à l’instance de conteneur au moment du lancement via les données utilisateur Amazon EC2 et enregistrées dans ce fichier sans conséquence. Cependant, d'autres informations sensibles, telles que vos AWS informations d'identification ou la `ECS_ENGINE_AUTH_DATA` variable, ne doivent jamais être transmises à une instance `/etc/ecs/ecs.config` dans les données utilisateur ou écrites de manière à ce qu'elles apparaissent dans un `.bash_history` fichier.
Stocker les informations de configuration dans un compartiment privé d'Amazon S3 et accorder un accès en lecture seule au rôle IAM de votre instance de conteneur est un moyen pratique et sécurisé d'autoriser la configuration d'une instance de conteneur au moment du lancement. Vous pouvez stocker une copie de votre fichier `ecs.config` dans un compartiment privé. Vous pouvez ensuite utiliser les données utilisateur Amazon EC2 pour installer AWS CLI et copier vos informations de configuration au `/etc/ecs/ecs.config` moment du lancement de l'instance.
**Pour stocker un fichier `ecs.config` dans Amazon S3**
1. Vous devez accorder au rôle d'instance de conteneur (**ecsInstanceRole**) des autorisations pour avoir un accès en lecture seule à Amazon S3. Vous pouvez le faire en assignant l'**AmazonS3 ReadOnlyAccess au rôle**. `ecsInstanceRole` Pour plus d’informations sur la manière d’associer une politique à un rôle, consultez la section [Modification des autorisations pour un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) dans le *Guide de l’utilisateur Gestion des identités et des accès AWS *.
1. Créez un fichier `ecs.config` contenant des variables de configuration d'agent Amazon ECS valides en utilisant le format suivant. Cet exemple configure 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).
```
ECS_ENGINE_AUTH_TYPE=dockercfg
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example.com"}}
```
**Note**
Pour obtenir la liste complète des variables de configuration des agents Amazon ECS disponibles, consultez [Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) on GitHub.
1. Pour stocker votre fichier de configuration, créez un compartiment privé dans Amazon S3. Pour de plus amples informations, consultez la section [Création d’un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) dans le *Guide de l’utilisateur d’Amazon Simple Storage Service*.
1. Chargez le fichier `ecs.config` dans votre compartiment S3. Pour plus d'informations, consultez [Chargement d'objets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.
**Pour charger un fichier `ecs.config` à partir d'Amazon S3 lors du lancement**
1. Exécutez les précédentes procédures de la présente section pour autoriser l'accès en lecture seule d'Amazon S3 à vos instances de conteneur et stocker un fichier `ecs.config` dans un compartiment S3 privé.
1. Lancez de nouvelles instances de conteneur et utilisez l’exemple de script suivant dans les données utilisateur EC2. Le script installe AWS CLI et copie votre fichier de configuration dans. `/etc/ecs/ecs.config` Pour de plus amples informations, veuillez consulter [Lancement d'une instance de conteneur Amazon ECS Linux](launch_container_instance.md).
```
#!/bin/bash
yum install -y aws-cli
aws s3 cp s3://your_bucket_name/ecs.config /etc/ecs/ecs.config
```
# Installation de l'agent de conteneur Amazon ECS
Si vous souhaitez enregistrer une instance Amazon EC2 auprès de votre cluster Amazon ECS et que cette instance n’utilise pas d’AMI basée sur l’AMI optimisée pour Amazon ECS, vous pouvez installer l’agent de conteneur Amazon ECS manuellement à l’aide de la procédure suivante. Pour ce faire, vous pouvez télécharger l’agent à partir d’un des compartiments S3 régionaux ou à partir d’Amazon Elastic Container Registry Public. Si vous téléchargez à partir d’un des compartiments S3 régionaux, vous pouvez éventuellement vérifier la validité du fichier d’agent de conteneur à l’aide de la signature PGP.
**Note**
Les unités `systemd` pour les services Amazon ECS et Docker sont soumises à une directive qui demande d'attendre que `cloud-init` ait terminé avant de démarrer les deux services. Le processus `cloud-init` n'est pas considéré comme terminé tant que les données utilisateur Amazon EC2 n'ont pas été complètement exécutées. Par conséquent, le démarrage d'Amazon ECS ou de Docker via les données utilisateur Amazon EC2 peut provoquer un blocage. Pour démarrer l'agent de conteneur à l'aide des données utilisateur Amazon EC2, vous pouvez utiliser `systemctl enable --now --no-block ecs.service`.
## Installation de l'agent du conteneur Amazon ECS sur une instance EC2 autre que Amazon Linux
Pour installer l’agent de conteneur Amazon ECS sur une instance Amazon EC2, vous pouvez télécharger l’agent à partir d’un des compartiments Amazon S3 régionaux et l’installer.
**Note**
Lorsque vous utilisez une AMI Linux autre qu'Amazon, votre instance Amazon EC2 nécessite une prise en charge de `cgroupfs` pour le pilote `cgroup` pour que l'agent Amazon ECS prenne en charge les limites de ressources au niveau des tâches. Pour plus d'informations, consultez la section [Agent Amazon ECS sur GitHub](https://github.com/aws/amazon-ecs-agent).
Les fichiers de l'agent de conteneur Amazon ECS le plus récent sont répertoriés par région ci-dessous à des fins de référence pour chaque architecture système.
| Région | Nom de la région | Fichiers deb init Amazon ECS | Fichiers rpm init Amazon ECS |
| --- | --- | --- | --- |
| us-east-2 | USA Est (Ohio) | [Amazon ECS init amd64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| us-east-1 | USA Est (Virginie du Nord) | [Amazon ECS init amd64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| us-west-1 | USA Ouest (Californie du Nord) | [Amazon ECS init amd64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| us-west-2 | USA Ouest (Oregon) | [Amazon ECS init amd64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| ap-east-1 | Asie-Pacifique (Hong Kong) | [Amazon ECS init amd64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| ap-northeast-1 | Asie-Pacifique (Tokyo) | [Amazon ECS init amd64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| ap-northeast-2 | Asie-Pacifique (Séoul) | [Amazon ECS init amd64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| ap-south-1 | Asie-Pacifique (Mumbai) | [Amazon ECS init amd64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| ap-southeast-1 | Asie-Pacifique (Singapour) | [Amazon ECS init amd64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| ap-southeast-2 | Asie-Pacifique (Sydney) | [Amazon ECS init amd64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| ca-central-1 | Canada (Centre) | [Amazon ECS init amd64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| eu-central-1 | Europe (Francfort) | [Amazon ECS init amd64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| eu-west-1 | Europe (Irlande) | [Amazon ECS init amd64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| eu-west-2 | Europe (Londres) | [Amazon ECS init amd64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| eu-west-3 | Europe (Paris) | [Amazon ECS init amd64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| sa-east-1 | Amérique du Sud (São Paulo) | [Amazon ECS init amd64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.x86_64.rpm) [Amazon ECS init aarch64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| us-gov-east-1 | AWS GovCloud (USA Est) | [Amazon ECS init amd64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| us-gov-west-1 | AWS GovCloud (US-Ouest) | [Amazon ECS init amd64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
**Pour installer l'agent de conteneur Amazon ECS sur une instance Amazon EC2 autre qu'Amazon Linux AMI**
1. Lancez une instance Amazon EC2 avec un rôle IAM qui autorise l'accès à Amazon ECS. Pour de plus amples informations, veuillez consulter [Rôle IAM d'instance de conteneur Amazon ECS](instance_IAM_role.md).
1. Connectez-vous à votre instance.
1. Installez la dernière version de Docker sur votre instance.
1. Vérifiez votre version de Docker pour vous assurer que votre système répond à l'exigence de version minimale. Pour plus d’informations sur la prise en charge de Docker, consultez la section [Instances de conteneur EC2 Amazon ECS](ecs-agent-versions.md).
```
docker --version
```
1. Téléchargez le fichier d'agent Amazon ECS approprié pour votre système d'exploitation et votre architecture système, puis installez-le.
Pour les architectures `deb` :
```
ubuntu:~$ curl -O https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.amd64.deb
ubuntu:~$ sudo dpkg -i amazon-ecs-init-latest.amd64.deb
```
Pour les architectures `rpm` :
```
fedora:~$ curl -O https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.x86_64.rpm
fedora:~$ sudo yum localinstall -y amazon-ecs-init-latest.x86_64.rpm
```
1. Modifiez le fichier `/lib/systemd/system/ecs.service` et ajoutez la ligne suivante à la fin de la section `[Unit]`.
```
After=cloud-final.service
```
1. (Facultatif) Pour enregistrer l'instance auprès d'un cluster autre que le cluster `default`, modifiez le fichier `/etc/ecs/ecs.config` et ajoutez le contenu suivant. L'exemple suivant spécifie le cluster `MyCluster` :
```
ECS_CLUSTER=MyCluster
```
Pour plus d'informations sur ces options ainsi que d'autres options d'exécution d'agents, consultez la page [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md).
**Note**
Vous pouvez éventuellement stocker vos variables d'environnement d'agent dans Amazon S3. Elles pourront être téléchargées dans vos instances de conteneur lors du lancement à l'aide des données utilisateur Amazon EC2. Ceci est particulièrement conseillé pour les informations sensibles, telles que les informations d'authentification pour les référentiels privés. Pour plus d’informations, consultez [Stockage de la configuration d’instance de conteneur Amazon ECS dans Amazon S3](ecs-config-s3.md) et [Utilisation d'images autres que des AWS conteneurs dans Amazon ECS](private-auth.md).
1. Lancez le service `ecs`.
```
ubuntu:~$ sudo systemctl start ecs
```
## Exécution de l'agent Amazon ECS avec le mode réseau hôte
Lorsque vous exécutez l'agent de conteneur Amazon ECS, `ecs-init` créera le conteneur d'agent de conteneur avec le mode de réseau `host`. C'est le seul mode de réseau pris en charge pour le conteneur d'agent de conteneur.
Cela vous permet de bloquer l'accès au [point de terminaison de service de métadonnées de l'instance Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) (`http://169.254.169.254`) pour les conteneurs lancés par l'agent de conteneur. Cela permet d'assurer que les conteneurs ne sont pas en mesure d'accéder aux informations d'identification du rôle IAM à partir du profil d'instance de conteneur et impose que les tâches utilisent uniquement les informations d'identification de rôle de tâche IAM. Pour de plus amples informations, veuillez consulter [rôle IAM de tâche Amazon ECS](task-iam-roles.md).
Cela permet également à l'agent de conteneur de ne pas devoir disputer les connexions et le trafic réseau sur la passerelle `docker0`.
## Paramètres de configuration du journal de l’agent de conteneur Amazon ECS
L'agent de conteneur Amazon ECS stocke les journaux sur vos instances de conteneur.
Pour l'agent de conteneur version 1.36.0 et ultérieure, les journaux sont par défaut situés sur `/var/log/ecs/ecs-agent.log` sur les instances Linux et `C:\ProgramData\Amazon\ECS\log\ecs-agent.log` sur les instances Windows.
Pour l'agent de conteneur version 1.35.0 et antérieure, les journaux sont par défaut situés sur `/var/log/ecs/ecs-agent.log.timestamp` sur les instances Linux et `C:\ProgramData\Amazon\ECS\log\ecs-agent.log.timestamp` sur les instances Windows.
Par défaut, les journaux de l'agent font l'objet d'une rotation toutes les heures et un maximum de 24 journaux sont stockés.
Voici les variables de configuration de l'agent de conteneur qui peuvent être utilisées pour modifier le comportement de journalisation de l'agent par défaut. Pour obtenir des informations détaillées sur tous les paramètres de configuration disponibles, consultez [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md) le [fichier README de l'agent Amazon ECS](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) sur GitHub.
Pour l'agent de conteneur version 1.36.0 et ultérieure, voici un exemple de fichier journal lorsque le format `logfmt` est utilisé.
```
level=info time=2019-12-12T23:43:29Z msg="Loading configuration" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Image excluded from cleanup: amazon/amazon-ecs-agent:latest" module=parse.go
level=info time=2019-12-12T23:43:29Z msg="Image excluded from cleanup: amazon/amazon-ecs-pause:0.1.0" module=parse.go
level=info time=2019-12-12T23:43:29Z msg="Amazon ECS agent Version: 1.36.0, Commit: ca640387" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Creating root ecs cgroup: /ecs" module=init_linux.go
level=info time=2019-12-12T23:43:29Z msg="Creating cgroup /ecs" module=cgroup_controller_linux.go
level=info time=2019-12-12T23:43:29Z msg="Loading state!" module=statemanager.go
level=info time=2019-12-12T23:43:29Z msg="Event stream ContainerChange start listening..." module=eventstream.go
level=info time=2019-12-12T23:43:29Z msg="Restored cluster 'auto-robc'" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Restored from checkpoint file. I am running as 'arn:aws:ecs:us-west-2:0123456789:container-instance/auto-robc/3330a8a91d15464ea30662d5840164cd' in cluster 'auto-robc'" module=agent.go
```
Voici un exemple de fichier journal lorsque le format JSON est utilisé.
```
{"time": "2019-11-07T22:52:02Z", "level": "info", "msg": "Starting Amazon Elastic Container Service Agent", "module": "engine.go"}
```
# Configuration des instances de conteneur Amazon ECS pour les images Docker privées
L'agent de conteneur Amazon ECS peut authentifier au moyen de registres privés, à l'aide de l'authentification de base. Lorsque vous activez l'authentification de registres privés, vous pouvez utiliser des images Docker privées dans vos définitions de tâche. Cette fonctionnalité n’est prise en charge que pour les tâches utilisant EC2.
Une autre méthode d'activation de l'authentification du registre privé consiste AWS Secrets Manager à stocker vos informations d'identification de registre privé en toute sécurité, puis à les référencer dans la définition de votre conteneur. Cela permet à vos tâches d'utiliser des images de référentiels privés. Cette méthode prend en charge les tâches utilisant EC2 ou Fargate. Pour de plus amples informations, veuillez consulter [Utilisation d'images autres que des AWS conteneurs dans Amazon ECS](private-auth.md).
Au lancement, l'agent de conteneur Amazon ECS recherche deux variables d'environnement :
+ `ECS_ENGINE_AUTH_TYPE`, qui spécifie le type des données d'authentification envoyées.
+ `ECS_ENGINE_AUTH_DATA`, qui contient les informations d'authentification réelles.
Les variantes Linux de l'AMI optimisée pour Amazon ECS analysent le `/etc/ecs/ecs.config` fichier à la recherche de ces variables au lancement de l'instance de conteneur et à chaque démarrage du service (avec la **sudo start ecs** commande). AMIs qui ne sont pas optimisés pour Amazon ECS doivent stocker ces variables d'environnement dans un fichier et les transmettre avec l'`--env-file path_to_env_file`option à la **docker run** commande qui démarre l'agent de conteneur.
**Important**
Nous déconseillons d'injecter ces variables d'environnement d'authentification au moment du lancement de l'instance avec les données utilisateur Amazon EC2 ou de les transmettre avec l'option `--env` à la commande **docker run**. Ces méthodes ne sont pas appropriées pour les données sensibles, par exemple les informations d'authentification. Pour plus d'informations sur l'ajout en toute sécurité d'informations d'authentification à vos instances de conteneur, consultez [Stockage de la configuration d’instance de conteneur Amazon ECS dans Amazon S3](ecs-config-s3.md).
## Formats d'authentification
Il existe deux formats disponibles pour une authentification de registre privé, `dockercfg` et `docker`.
**Format d'authentification dockercfg**
Le format `dockercfg` utilise les informations d'authentification stockées dans le fichier de configuration qui est créé lorsque vous exécutez la commande **docker login**. Pour créer ce fichier, exécutez **docker login** sur votre système local et saisissez votre nom d'utilisateur de registre, votre mot de passe et une adresse e-mail. Vous pouvez également vous connecter à une instance de conteneur et y exécuter la commande. Selon votre version de Docker, ce fichier est enregistré sous la forme `~/.dockercfg` ou `~/.docker/config.json`.
```
cat ~/.docker/config.json
```
Sortie :
```
{
"auths": {
"https://index.docker.io/v1/": {
"auth": "zq212MzEXAMPLE7o6T25Dk0i"
}
}
}
```
**Important**
Les versions les plus récentes de Docker créent un fichier de configuration comme illustré ci-après avec un objet `auths` externe. L'agent Amazon ECS prend en charge les données d'authentification `dockercfg` au format ci-dessous uniquement, sans l'objet `auths`. Si l'utilitaire **jq** est installé, vous pouvez extraire ces données à l'aide de la commande suivante : **cat \$1/.docker/config.json \$1 jq .auths**
```
cat ~/.docker/config.json | jq .auths
```
Sortie :
```
{
"https://index.docker.io/v1/": {
"auth": "zq212MzEXAMPLE7o6T25Dk0i",
"email": "email@example.com"
}
}
```
Dans l'exemple ci-dessus, les variables d'environnement suivantes doivent être ajoutées au fichier de variables d'environnement (`/etc/ecs/ecs.config` pour l'AMI optimisée pour Amazon ECS) que l'agent de conteneur Amazon ECS charge au moment de l'exécution. Si vous n'utilisez pas l'AMI optimisée pour Amazon ECS et que vous démarrez l'agent manuellement avec **docker run**, spécifiez le fichier de variables d'environnement avec l'option `--env-file path_to_env_file` lorsque vous démarrez l'agent.
```
ECS_ENGINE_AUTH_TYPE=dockercfg
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example.com"}}
```
Vous pouvez configurer plusieurs registres privés avec la syntaxe suivante :
```
ECS_ENGINE_AUTH_TYPE=dockercfg
ECS_ENGINE_AUTH_DATA={"repo.example-01.com":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example-01.com"},"repo.example-02.com":{"auth":"fQ172MzEXAMPLEoF7225DU0j","email":"email@example-02.com"}}
```
**Format d'authentification docker**
Le format `docker` utilise une représentation JSON du serveur de registre que l'agent doit utiliser pour l'authentification. Il inclut également les paramètres d'authentification requis par ce registre (par exemple, nom d'utilisateur, mot de passe et adresse e-mail pour ce compte). Pour un compte Docker Hub, la représentation JSON se présente comme suit :
```
{
"https://index.docker.io/v1/": {
"username": "my_name",
"password": "my_password",
"email": "email@example.com"
}
}
```
Dans cet exemple, les variables d'environnement suivantes doivent être ajoutées au fichier de variables d'environnement (`/etc/ecs/ecs.config` pour l'AMI optimisée pour Amazon ECS) que l'agent de conteneur Amazon ECS charge au moment de l'exécution. Si vous n'utilisez pas l'AMI optimisée pour Amazon ECS et que vous démarrez l'agent manuellement avec **docker run**, spécifiez le fichier de variables d'environnement avec l'option `--env-file path_to_env_file` lorsque vous démarrez l'agent.
```
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
```
Vous pouvez configurer plusieurs registres privés avec la syntaxe suivante :
```
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"repo.example-01.com":{"username":"my_name","password":"my_password","email":"email@example-01.com"},"repo.example-02.com":{"username":"another_name","password":"another_password","email":"email@example-02.com"}}
```
## Procédure
Utilisez la procédure suivante pour activer les registres privés pour vos instances de conteneur.
**Pour activer les registres privés dans l'AMI optimisée pour Amazon ECS**
1. Connectez-vous à votre instance de conteneur à l'aide de SSH.
1. Ouvrez le fichier `/etc/ecs/ecs.config` et ajoutez les valeurs `ECS_ENGINE_AUTH_TYPE` et `ECS_ENGINE_AUTH_DATA` pour votre registre et votre compte :
```
sudo vi /etc/ecs/ecs.config
```
Cet exemple authentifie un compte d'utilisateur Docker Hub :
```
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
```
1. Vérifiez si votre agent utilise la variable d'environnement `ECS_DATADIR` pour enregistrer son état :
```
docker inspect ecs-agent | grep ECS_DATADIR
```
Sortie :
```
"ECS_DATADIR=/data",
```
**Important**
Si la commande précédente ne renvoie pas la variable d'environnement `ECS_DATADIR`, vous devez arrêter toutes les tâches en cours d'exécution sur cette instance de conteneur avant d'arrêter l'agent. Les agents les plus récents avec la variable d'environnement `ECS_DATADIR` enregistrent leur état et peuvent être arrêtés et démarrés sans problèmes tandis que des tâches sont en cours d'exécution. Pour de plus amples informations, veuillez consulter [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md).
1. Arrêtez le service `ecs` :
```
sudo stop ecs
```
Sortie :
```
ecs stop/waiting
```
1. Redémarrez le service `ecs`.
+ 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
```
1. (Facultatif) Vous pouvez vérifier que l'agent est en cours d'exécution et consulter des informations sur votre nouvelle instance de conteneur en interrogeant l'opération API d'introspection d'agent. Pour de plus amples informations, veuillez consulter [Introspection de conteneur Amazon ECS](ecs-agent-introspection.md).
```
curl http://localhost:51678/v1/metadata
```
# Nettoyage automatique des tâches et des images Amazon ECS
Chaque fois qu'une tâche est placée sur une instance de conteneur, l'agent de conteneur Amazon ECS vérifie si les images référencées dans la tâche sont les images les plus récentes de la balise spécifiée dans le référentiel. Si ce n'est pas le cas, le comportement par défaut permet à l'agent d'extraire les images de leurs référentiels respectifs. Si vous modifiez fréquemment les images dans vos tâches et services, votre stockage d'instance de conteneur peut se remplir rapidement avec des images Docker que vous n'utilisez plus et que vous n'utiliserez probablement jamais plus. Par exemple, vous utilisez peut-être un pipeline pour l'intégration et le déploiement continus (CI/CD).
**Note**
Il est possible de personnaliser le comportement d'extraction d'image de l'agent Amazon ECS à l'aide du paramètre `ECS_IMAGE_PULL_BEHAVIOR`. Pour de plus amples informations, veuillez consulter [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md).
De même, les conteneurs appartenant à des tâches arrêtées peuvent également consommer du stockage d'instance de conteneur avec des informations de journal, des volumes de données et d'autres artefacts. Ces artefacts sont utiles pour le débogage des conteneurs qui se sont arrêtés de manière inattendue, mais la plupart de ce stockage peut être libéré en toute sécurité après une période donnée.
Par défaut, l'agent de conteneur Amazon ECS élimine automatiquement les tâches arrêtées et les images Docker qui ne sont pas utilisées par des tâches de vos instances de conteneur.
**Note**
La fonction de nettoyage automatique d'image nécessite au moins la version 1.13.0 de l'agent de conteneur Amazon ECS. Pour mettre à jour votre agent avec la dernière version, consultez [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md).
Les variables de configuration d'agent suivantes sont disponibles pour ajuster votre expérience de tâches automatisées et de nettoyage d'image. Pour plus d'informations sur la façon de définir ces variables sur vos instances de conteneur, consultez [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md).
`ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`
Délai d’attente par défaut avant la suppression des conteneurs pour une tâche arrêtée. Si la valeur définie est inférieure à 1 seconde, elle est ignorée. Par défaut, ce paramètre est défini sur trois heures, mais vous pouvez réduire cette période à une seconde, si votre application le nécessite.
Le processus de nettoyage d'image ne peut pas supprimer une image tant qu'un conteneur y fait référence. Une fois les conteneurs supprimés, toutes les images non référencées peuvent être nettoyées en fonction des paramètres de configuration du nettoyage d’image.
`ECS_DISABLE_IMAGE_CLEANUP`
Si vous définissez cette variable sur `true`, le nettoyage automatique d'image est désactivé sur votre instance de conteneur et aucune image n'est supprimée automatiquement.
`ECS_IMAGE_CLEANUP_INTERVAL`
Cette variable spécifie à quelle fréquence le processus de nettoyage d'image automatique recherche des images à supprimer. La valeur par défaut est toutes les 30 minutes, mais vous pouvez réduire ce délai à 10 minutes pour supprimer les images plus fréquemment.
`ECS_IMAGE_MINIMUM_CLEANUP_AGE`
Cette variable spécifie le délai minimal entre le moment où une image a été extraite et celui où elle peut être supprimée. Cela permet d'empêcher le nettoyage d'images tout juste extraites. La valeur par défaut est 1 heure.
`ECS_NUM_IMAGES_DELETE_PER_CYCLE`
Cette variable spécifie le nombre d'images pouvant être supprimées en un seul cycle de nettoyage. La valeur par défaut est de 5 et la valeur minimale est de 1.
Lorsque l'agent de conteneur Amazon ECS est en cours d'exécution et que le nettoyage automatique d'image n'est pas désactivé, l'agent recherche des images Docker qui ne sont pas référencées par des conteneurs en cours d'exécution ou arrêtés à une fréquence déterminée par la variable `ECS_IMAGE_CLEANUP_INTERVAL`. Si des images inutilisées sont trouvées et qu'elles sont antérieures au délai de nettoyage minimal spécifié par la variable `ECS_IMAGE_MINIMUM_CLEANUP_AGE`, l'agent supprime le nombre maximal d'images spécifiées avec la variable `ECS_NUM_IMAGES_DELETE_PER_CYCLE`. Les images référencées le moins récemment sont supprimées en premier. Une fois les images supprimées, l'agent attend jusqu'au prochain intervalle et répète le processus.