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.

# Comment Amazon ECS place les tâches sur des instances de conteneur
<a name="task-placement"></a>

Vous pouvez utiliser le placement des tâches pour configurer Amazon ECS afin de placer vos tâches sur des instances de conteneur répondant à certains critères, par exemple une zone de disponibilité ou un type d’instance.

Les composants de placement des tâches sont les suivants :
+ Stratégie de placement des tâches : l’algorithme permettant de sélectionner les instances de conteneur pour le placement des tâches ou les tâches à terminer. Par exemple, Amazon ECS peut sélectionner des instances de conteneur au hasard, ou il peut sélectionner des instances de conteneur de manière à ce que les tâches soient réparties uniformément entre un groupe d’instances.
+ Groupe de tâches : un groupe de tâches connexes, par exemple des tâches de base de données.
+ Contrainte de placement des tâches : il s’agit de règles qui doivent être respectées pour placer une tâche sur une instance de conteneur. Si la contrainte n’est pas respectée, la tâche n’est pas placée et reste dans l’état `PENDING`. Par exemple, vous pouvez utiliser une contrainte pour ne placer des tâches que sur un type d’instance spécifique. 

Amazon ECS utilise différents algorithmes pour les différentes options de capacité. 

## Instances gérées Amazon ECS
<a name="managed-instances-launch-type"></a>

Pour les tâches exécutées sur des instances gérées Amazon ECS, Amazon ECS doit déterminer où placer la tâche et, lors de la réduction du nombre de tâches, quelles tâches résilier. Amazon ECS prend cette décision en fonction des exigences d’instance spécifiées dans le modèle de lancement du fournisseur de capacité, des exigences spécifiées dans la définition de la tâche, telles que l’UC et la mémoire, et des contraintes de placement des tâches.

**Note**  
Les instances gérées Amazon ECS ne prennent pas en charge les stratégies de placement de tâches. Amazon ECS fera tout son possible pour répartir les tâches entre les zones de disponibilité accessibles.

Lorsqu'Amazon ECS place des tâches, il a recours au processus suivant afin de sélectionner les instances de conteneur :

1. Identification des instances qui répondent aux exigences en termes d’UC, de GPU, de mémoire et de port dans la définition de tâche.

1. Identification des instances de conteneur qui satisfont aux contraintes de placement des tâches.

1. Identification des instances de conteneur qui satisfont aux exigences spécifiées dans le modèle de lancement du fournisseur de capacité.

1. Sélection des instances de conteneur pour le placement des tâches.

## EC2
<a name="ec2-launch-type"></a>

Pour les tâches qui utilisent le type de lancement EC2, Amazon ECS doit déterminer où placer la tâche en fonction des exigences spécifiées dans la définition de la tâche, telles que l’UC et la mémoire. De la même manière, lorsque vous réduisez le nombre de tâches, Amazon ECS doit déterminer quelles tâches doivent être résiliées. Vous pouvez appliquer des stratégies et des contraintes de placement des tâches afin de personnaliser la façon dont Amazon ECS place et résilie les tâches. 

Les stratégies de placement des tâches par défaut dépendent du fait que vous exécutiez les tâches manuellement (tâches autonomes) ou dans le cadre d’un service. Pour les tâches exécutées dans le cadre d'un service Amazon ECS, la stratégie de placement des tâches est `spread`, en utilisant `attribute:ecs.availability-zone`. Il n’y a pas de contrainte de placement par défaut pour les tâches qui ne font pas partie des services. Pour de plus amples informations, veuillez consulter [Planification de vos conteneurs sur Amazon ECS](scheduling_tasks.md).

**Note**  
Les stratégies de placement des tâches ont une obligation de moyens, mais pas de résultat. Amazon ECS tente toujours de placer les tâches, même lorsque l'option de placement optimale n'est pas disponible. Néanmoins, les contraintes de placement des tâches constituent une obligation et peuvent empêcher le placement des tâches. 

Vous pouvez utiliser simultanément des stratégies et des contraintes de placement des tâches. Par exemple, vous pouvez utiliser une stratégie et une contrainte de placement des tâches de façon à répartir les tâches entre différentes zones de disponibilité et les regrouper par bin packing en fonction de la mémoire dans chaque zone de disponibilité, mais uniquement pour les instances G2.

Lorsqu'Amazon ECS place des tâches, il a recours au processus suivant afin de sélectionner les instances de conteneur :

1. Identification des instances qui répondent aux exigences en termes d’UC, de GPU, de mémoire et de port dans la définition de tâche.

1. Identification des instances de conteneur qui satisfont aux contraintes de placement des tâches.

1. Identification des instances de conteneur qui satisfont aux stratégies de placement des tâches.

1. Sélection des instances de conteneur pour le placement des tâches.

## Fargate
<a name="fargate-launch-type"></a>

Les stratégies et contraintes de placement des tâches ne sont pas prises en charge pour les tâches utilisant Fargate. Fargate fera de son mieux pour répartir les tâches entre les zones de disponibilité accessibles. Si le fournisseur de capacité inclut à la fois Fargate et Fargate Spot, le comportement de répartition est indépendant pour chaque fournisseur de capacité. 

# Autoscaling des instances gérées Amazon ECS et placement des tâches
<a name="managed-instance-auto-scaling"></a>

Les instances gérées Amazon ECS utilisent des algorithmes intelligents pour automatiquement mettre à l’échelle la capacité de votre cluster et répartir les tâches de manière efficace sur l’ensemble de votre infrastructure. Comprendre le fonctionnement de ces algorithmes vous permet d’optimiser les configurations de vos services et de résoudre les problèmes liés aux comportements de placement.

## Algorithme de placement des tâches
<a name="managed-instance-task-placement-algorithm"></a>

Les instances gérées Amazon ECS utilisent un algorithme de placement sophistiqué qui équilibre la disponibilité, l’utilisation des ressources et les exigences du réseau lors de la planification des tâches.

### Répartition des zones de disponibilité
<a name="managed-instance-az-spread-behavior"></a>

Par défaut, les instances gérées Amazon ECS donnent la priorité à la disponibilité en répartissant les tâches entre plusieurs zones de disponibilité :
+ Pour les services comportant plusieurs tâches, les instances gérées Amazon ECS garantissent une distribution sur au moins trois instances dans différentes zones de disponibilité lorsque cela est possible
+ Ce comportement permet une tolérance aux pannes, mais peut entraîner une baisse de l’utilisation des ressources par instance
+ La répartition des zones de disponibilité prime sur l’optimisation du bin packing

### Comportement de bin packing
<a name="managed-instance-bin-packing"></a>

Bien que les instances gérées Amazon ECS puissent effectuer du bin packing pour optimiser l’utilisation des ressources, ce comportement est influencé par la configuration de votre réseau :
+ Pour réaliser le bin packing, configurez votre service de manière à utiliser un seul sous-réseau
+ Les configurations à sous-réseaux multiples donnent la priorité à la distribution des zones de disponibilité plutôt qu’à la densité des ressources
+ Le bin packing est plus probable lors du lancement initial du service que lors des événements de mise à l’échelle

### Considérations relatives à la densité de l’ENI
<a name="managed-instance-eni-density"></a>

Pour les services utilisant le mode réseau `awsvpc`, les instances gérées Amazon ECS tiennent compte de la densité de l’interface réseau Elastic (ENI) lorsqu’elles prennent des décisions de placement :
+ Chaque tâche en mode `awsvpc` nécessite une ENI dédiée
+ Les types d’instances ont des limites ENI différentes qui affectent la densité des tâches
+ Les instances gérées Amazon ECS tiennent compte de la disponibilité de l’ENI lors de la sélection des instances cibles

**Note**  
Les calculs de densité d’ENI sont continuellement améliorés afin d’optimiser les décisions de placement.

## Logique de décision du fournisseur de capacité
<a name="managed-instance-capacity-provider-decisions"></a>

Les fournisseurs de capacité d’instances gérées Amazon ECS prennent des décisions de mise à l’échelle et de placement en fonction de plusieurs facteurs :

Besoins en ressources  
Exigences relatives à l’UC, à la mémoire et au réseau pour les tâches en attente

Disponibilité de l’instance  
Capacité et utilisation actuelles sur les instances existantes

Contraintes de réseau  
Configuration du sous-réseau et disponibilité de l’ENI

Distribution par zone de disponibilité  
Maintien de la tolérance aux pannes dans plusieurs zones de disponibilité

## Options de configuration
<a name="managed-instance-configuration-options"></a>

### Stratégie de sélection de sous-réseaux
<a name="managed-instance-subnet-strategy"></a>

La configuration de votre sous-réseau a un impact significatif sur le comportement de placement des tâches :

Sous-réseaux multiples (par défaut)  
Priorise la répartition entre les zones de disponibilité pour une haute disponibilité  
Peut entraîner une baisse de l’utilisation des ressources par instance  
Recommandé pour les charges de production nécessitant une tolérance aux pannes

Sous-réseau unique  
Permet le bin packing pour une meilleure utilisation des ressources  
Réduit la tolérance aux pannes en concentrant les tâches dans une seule zone de disponibilité  
Adapté au développement ou aux charges de travail optimisées en termes de coûts

### Considérations relatives au mode réseau
<a name="managed-instance-network-mode-considerations"></a>

Le mode réseau que vous choisissez influe sur les décisions de placement :
+ Mode `awsvpc` : chaque tâche nécessite une ENI dédiée, ce qui limite la densité des tâches par instance
+ Mode `host` : les tâches utilisent directement le réseau de l’hôte, le placement étant principalement déterminé par la disponibilité des ressources

### Considérations concernant l'architecture du processeur
<a name="managed-instance-cpu-architecture-considerations"></a>

`cpuArchitecture`Ce que vous spécifiez dans votre définition de tâche est utilisé pour placer des tâches sur une architecture spécifique. Si vous ne spécifiez pas de`cpuArchitecture`, Amazon ECS essaiera de placer les tâches sur n'importe quelle architecture de processeur disponible en fonction de la configuration du fournisseur de capacité. Vous pouvez spécifier `X86_64` ou `ARM64`.

## Résolution des problèmes de placement des tâches
<a name="managed-instance-troubleshooting-placement"></a>

### Modèles de placement courants
<a name="managed-instance-common-placement-patterns"></a>

La compréhension des modèles de placement attendus permet de distinguer le comportement normal des problèmes potentiels :

Distribution répartie  
Tâches réparties sur plusieurs instances avec une utilisation partielle  
Comportement normal lors de l’utilisation de plusieurs sous-réseaux  
Indique que la disponibilité prime sur l’efficacité des ressources

Placement concentré  
Tâches multiples placées sur un nombre réduit d’instances avec un taux d’utilisation plus élevé  
Prévu lors de l’utilisation d’une configuration de sous-réseau unique  
Peut se produire lors du lancement initial du service

Distribution inégale  
Certaines instances sont très utilisées tandis que d’autres restent sous-utilisées  
Peut indiquer les limites de l’ENI ou les contraintes de ressources  
Envisagez de revoir les types d’instances et la configuration réseau

### Optimisation du comportement de placement
<a name="managed-instance-placement-optimization"></a>

Pour optimiser le placement des tâches en fonction de vos besoins spécifiques :

1. Évaluez vos exigences de disponibilité par rapport à vos besoins d’optimisation des coûts

1. Choisissez la configuration de sous-réseau appropriée en fonction de vos priorités

1. Sélectionnez les types d’instances dotés d’une capacité ENI adaptée à votre mode réseau

1. Surveillez les modèles de placement et ajustez la configuration selon les besoins

## Bonnes pratiques
<a name="managed-instance-best-practices"></a>
+ **Pour les charges de travail de production** : utilisez plusieurs sous-réseaux répartis dans différentes zones de disponibilité pour garantir une haute disponibilité, en acceptant le compromis en termes d’utilisation des ressources
+ **Pour le développement ou les tests** : envisagez une configuration de sous-réseau unique pour optimiser l’utilisation des ressources et réduire les coûts
+ **Pour le mode `awsvpc`** : choisissez des types d’instances dotés d’une capacité d’ENI suffisante pour éviter les contraintes de placement
+ **Pour optimiser les coûts** : surveillez les modèles d’utilisation et ajustez la configuration des services pour équilibrer disponibilité et efficacité
+ **Pour résoudre les problèmes** : passez en revue la configuration du sous-réseau et le mode réseau lorsque vous étudiez des modèles de placement inattendus

# Utilisation des stratégies pour définir le placement des tâches Amazon ECS
<a name="task-placement-strategies"></a>

Pour les tâches qui utilisent le type de lancement EC2, Amazon ECS doit déterminer où placer la tâche en fonction des exigences spécifiées dans la définition de la tâche, telles que l’UC et la mémoire. De la même manière, lorsque vous réduisez le nombre de tâches, Amazon ECS doit déterminer quelles tâches doivent être résiliées. Vous pouvez appliquer des stratégies et des contraintes de placement des tâches afin de personnaliser la façon dont Amazon ECS place et résilie les tâches. 

Les stratégies de placement des tâches par défaut dépendent du fait que vous exécutiez les tâches manuellement (tâches autonomes) ou dans le cadre d’un service. Pour les tâches exécutées dans le cadre d'un service Amazon ECS, la stratégie de placement des tâches est `spread`, en utilisant `attribute:ecs.availability-zone`. Il n’y a pas de contrainte de placement par défaut pour les tâches qui ne font pas partie des services. Pour de plus amples informations, veuillez consulter [Planification de vos conteneurs sur Amazon ECS](scheduling_tasks.md).

**Note**  
Les stratégies de placement des tâches ont une obligation de moyens, mais pas de résultat. Amazon ECS tente toujours de placer les tâches, même lorsque l'option de placement optimale n'est pas disponible. Néanmoins, les contraintes de placement des tâches constituent une obligation et peuvent empêcher le placement des tâches. 

Vous pouvez utiliser simultanément des stratégies et des contraintes de placement des tâches. Par exemple, vous pouvez utiliser une stratégie et une contrainte de placement des tâches de façon à répartir les tâches entre différentes zones de disponibilité et les regrouper par bin packing en fonction de la mémoire dans chaque zone de disponibilité, mais uniquement pour les instances G2.

Lorsqu'Amazon ECS place des tâches, il a recours au processus suivant afin de sélectionner les instances de conteneur :

1. Identification des instances qui répondent aux exigences en termes d’UC, de GPU, de mémoire et de port dans la définition de tâche.

1. Identification des instances de conteneur qui satisfont aux contraintes de placement des tâches.

1. Identification des instances de conteneur qui satisfont aux stratégies de placement des tâches.

1. Sélection des instances de conteneur pour le placement des tâches.

Vous spécifiez les stratégies de placement des tâches dans la définition du service ou dans la définition des tâches à l’aide du paramètre `placementStrategy`.

```
"placementStrategy": [
    {
        "field": "The field to apply the placement strategy against",
        "type": "The placement strategy to use"
    }
]
```

Vous pouvez définir les stratégies lorsque vous exécutez une tâche ([RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)), créez un nouveau service ([CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)) ou mettez à jour un service existant ([UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)).

Le tableau suivant décrit les types et champs disponibles.


| type | Valeurs de champ valides | 
| --- | --- | 
| binpack Les tâches sont placées sur les instances de conteneur afin de laisser le moins de CPU ou de mémoire inutilisées. Cette stratégie minimise le nombre d'instances de conteneur utilisées. Lorsque cette stratégie est utilisée et qu'une action de mise à l'échelle horizontale est entreprise, Amazon ECS résilie les tâches. Elle effectue cette opération en fonction de la quantité de ressources laissée sur l'instance de conteneur après la résiliation de la tâche. L'instance de conteneur qui a le plus de ressources disponibles après la résiliation de la tâche voit cette tâche résiliée. |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/task-placement-strategies.html)  | 
| random Les tâches sont placées au hasard. | Non utilisé | 
| spreadLes tâches sont placées uniformément en fonction de la valeur spécifiée. Les tâches de service sont réparties en fonction des tâches du service concerné. Les tâches autonomes sont réparties en fonction des tâches du même groupe de tâches. Pour de plus amples informations sur les groupes de tâches, consultez [Tâches Amazon ECS liées au groupe](task-groups.md). Lorsque la stratégie `spread` est utilisée et qu'une action de mise à l'échelle horizontale est entreprise, Amazon ECS sélectionne les tâches à résilier qui maintiennent un équilibre entre les zones de disponibilité. Au sein d'une zone de disponibilité, les tâches sont sélectionnées au hasard. |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/task-placement-strategies.html)  | 

Les stratégies de placement des tâches peuvent également être mises à jour pour les services existants. Pour de plus amples informations, veuillez consulter [Comment Amazon ECS place les tâches sur des instances de conteneur](task-placement.md).

Vous pouvez créer une stratégie de placement des tâches qui utilise plusieurs stratégies en créant des tableaux de stratégies dans l'ordre d'exécution souhaité. Par exemple, si vous souhaitez répartir les tâches entre les zones de disponibilité, puis les regrouper en fonction de la mémoire au sein de chaque zone de disponibilité, spécifiez la stratégie de zone de disponibilité suivie de la stratégie de mémoire. Pour consulter des exemples de stratégies, voir [Exemples de stratégies de placement des tâches Amazon ECS](strategy-examples.md).

# Exemples de stratégies de placement des tâches Amazon ECS
<a name="strategy-examples"></a>

Vous pouvez définir des stratégies de placement des tâches à l'aide des actions suivantes : [CreateService[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), et [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html).

**Topics**
+ [Répartition des tâches de manière uniforme sur plusieurs zones de disponibilité](#even-az)
+ [Répartition des tâches de manière uniforme sur toutes les instances](#even-instance)
+ [Regroupement des tâches en fonction de la mémoire](#binpack)
+ [Placement des tâches de façon aléatoire](#random)
+ [Répartition des tâches de manière uniforme entre les zones de disponibilité, puis répartition de manière uniforme entre les instances de chaque zone de disponibilité](#az-instance)
+ [Répartition des tâches de manière uniforme entre les zones de disponibilité, puis regroupement des tâches en fonction de la mémoire de chaque zone de disponibilité](#az-memory)
+ [Répartition des tâches de manière uniforme entre les instances, puis regroupement des tâches en fonction de la mémoire](#instance-memory)

## Répartition des tâches de manière uniforme sur plusieurs zones de disponibilité
<a name="even-az"></a>

La stratégie suivante répartit les tâches de façon uniforme dans les zones de disponibilité.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    }
]
```

## Répartition des tâches de manière uniforme sur toutes les instances
<a name="even-instance"></a>

La stratégie suivante répartit les tâches de façon uniforme entre toutes les instances.

```
"placementStrategy": [
    {
        "field": "instanceId",
        "type": "spread"
    }
]
```

## Regroupement des tâches en fonction de la mémoire
<a name="binpack"></a>

La stratégie suivante regroupe les tâches par bin packing en fonction de la mémoire.

```
"placementStrategy": [
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## Placement des tâches de façon aléatoire
<a name="random"></a>

La stratégie suivante place les tâches de façon aléatoire.

```
"placementStrategy": [
    {
        "type": "random"
    }
]
```

## Répartition des tâches de manière uniforme entre les zones de disponibilité, puis répartition de manière uniforme entre les instances de chaque zone de disponibilité
<a name="az-instance"></a>

La stratégie suivante permet de répartir les tâches de façon égale entre les zones de disponibilité, puis de les répartir de façon égale entre les instances de chaque zone de disponibilité.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "instanceId",
        "type": "spread"
    }
]
```

## Répartition des tâches de manière uniforme entre les zones de disponibilité, puis regroupement des tâches en fonction de la mémoire de chaque zone de disponibilité
<a name="az-memory"></a>

La stratégie suivante permet de répartir les tâches de façon égale entre les zones de disponibilité, puis de répartir les tâches par bin packing en fonction de la mémoire de chaque zone de disponibilité.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## Répartition des tâches de manière uniforme entre les instances, puis regroupement des tâches en fonction de la mémoire
<a name="instance-memory"></a>

La stratégie suivante répartit les tâches de manière uniforme entre toutes les instances, puis regroupe les tâches en fonction de la mémoire au sein de chaque instance. 

```
"placementStrategy": [
    {
        "field": "instanceId",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

# Tâches Amazon ECS liées au groupe
<a name="task-groups"></a>

Vous pouvez identifier un ensemble de tâches connexes et les placer dans un groupe de tâches. Toutes les tâches ayant le même nom de groupe de tâches sont considérées comme un ensemble lorsque la stratégie de placement des tâches `spread` est utilisée. Par exemple, supposons que vous exécutiez différentes applications dans un cluster, par exemple des bases de données et des serveurs web. Afin de veiller à ce que les bases de données soient réparties de façon équilibrée dans les zones de disponibilité, ajoutez-les à un groupe de tâches nommé `databases`, puis utilisez la stratégie de placement des tâches `spread`. Pour de plus amples informations, veuillez consulter [Utilisation des stratégies pour définir le placement des tâches Amazon ECS](task-placement-strategies.md).

Les groupes de tâches peuvent également être utilisés comme contrainte de placement des tâches. Lorsque vous spécifiez un groupe de tâches dans la contrainte `memberOf`, les tâches sont uniquement envoyées aux instances de conteneur qui se trouvent dans le groupe de tâches spécifié. Pour obtenir un exemple, consultez [Exemple de contraintes de placement de tâche Amazon ECS](constraint-examples.md).

Par défaut, les tâches autonomes utilisent le nom de famille de définition de tâche (par exemple, `family:my-task-definition`) comme nom de groupe de tâches si aucun nom de groupe de tâches personnalisé n'est spécifié. Les tâches lancées dans le cadre d'un service utilisent le nom du service comme nom de groupe de tâches et ne peuvent pas être modifiées.

Les exigences suivantes s’appliquent au groupe de tâches.
+ Un nom de groupe de tâches doit être composé de 255 caractères maximum.
+ Chaque tâche peut faire partie d'un seul groupe.
+ Après avoir lancé une tâche, vous ne pouvez pas modifier le groupe de tâches auquel elle appartient.

# Définition des instances de conteneur utilisées par Amazon ECS pour les tâches
<a name="task-placement-constraints"></a>

Une contrainte de placement de tâche est une règle concernant une instance de conteneur qu’Amazon ECS utilise pour déterminer si la tâche est autorisée à s’exécuter sur l’instance. Au moins une instance de conteneur doit correspondre à la contrainte. Si aucune instance ne correspond à la contrainte, la tâche reste à l'état `PENDING`. Lorsque vous créez un nouveau service ou que vous mettez à jour un service existant, vous pouvez définir des contraintes de placement des tâches pour les tâches du service. 

Vous pouvez spécifier des contraintes de placement des tâches dans la définition du service, dans la définition de la tâche ou dans la tâche à l’aide du paramètre `placementConstraint`.

```
"placementConstraints": [
    {
        "expression": "The expression that defines the task placement constraints",
        "type": "The placement constraint type to use"
    }
]
```

Le tableau suivant décrit comment utiliser les paramètres.


| Constraint type (Type de contrainte) | Peut être spécifié quand | 
| --- | --- | 
| distinctInstancePlace chaque tâche sur une instance de conteneur différente.Amazon ECS examine le statut souhaité des tâches pour le placement des tâches. Par exemple, si le statut souhaité de la tâche existante est `STOPPED` (mais que le dernier statut ne l’est pas), une nouvelle tâche entrante peut être placée sur la même instance malgré la contrainte de placement `distinctInstance`. En conséquence, vous pouvez voir deux tâches dont le dernier statut est `RUNNING` sur la même instance. Nous recommandons aux clients qui recherchent une isolation forte pour leurs tâches d’utiliser Fargate. Fargate exécute chaque tâche dans un environnement de virtualisation matérielle. Cela garantit que ces charges de travail conteneurisées ne partagent pas les interfaces réseau, le stockage éphémère Fargate, l’UC ou la mémoire avec d’autres tâches. Pour plus d'informations, consultez [la section Présentation de la sécurité de AWS Fargate](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf). |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/task-placement-constraints.html)  | 
| memberOfPlace les tâches sur des instances de conteneur qui correspondent à une expression.  | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/task-placement-constraints.html) | 

Lorsque vous utilisez le type de contrainte `memberOf`, vous pouvez créer une expression à l’aide du langage de requête de cluster qui définit les instances de conteneur dans lesquelles Amazon ECS peut placer des tâches. L’expression vous permet de regrouper vos instances de conteneur par attributs. L’expression va dans le paramètre `expression ` de `placementConstraint`.

## Attributs d’instance de conteneur Amazon ECS
<a name="attributes"></a>

Vous pouvez ajouter à vos instances de conteneur des métadonnées personnalisées connues sous le nom d'*attributs*. Chaque attribut a un nom et une valeur de chaîne facultative. Vous pouvez utiliser les attributs intégrés fournis par Amazon ECS ou définir des attributs personnalisés.

Les sections suivantes contiennent des exemples d'attributs intégrés, facultatifs et personnalisés.

### Attributs intégrés
<a name="ecs-automatic-attributes"></a>

Amazon ECS applique automatiquement les attributs suivants à vos instances de conteneur.

`ecs.ami-id`  
ID de l’AMI utilisée pour lancer l’instance. Cet attribut peut par exemple avoir la valeur `ami-1234abcd`.

`ecs.availability-zone`  
Zone de disponibilité de l'instance. Cet attribut peut par exemple avoir la valeur `us-east-1a`.

`ecs.instance-type`  
Type de l'instance. Cet attribut peut par exemple avoir la valeur `g2.2xlarge`.

`ecs.os-type`  
Système d'exploitation de l'instance. Les valeurs possibles pour cet attribut sont `linux` et `windows`.

`ecs.os-family`  
Version du système d'exploitation de l'instance.  
Pour les instances Linux, la valeur valide est `LINUX`. Pour les instances Windows, ECS définit la valeur au format `WINDOWS_SERVER_<OS_Release>_<FULL or CORE>`. Les valeurs valides sont `WINDOWS_SERVER_2022_FULL`, `WINDOWS_SERVER_2022_CORE`, `WINDOWS_SERVER_20H2_CORE`, `WINDOWS_SERVER_2019_FULL`, `WINDOWS_SERVER_2019_CORE` et `WINDOWS_SERVER_2016_FULL`.  
Cela est important pour les conteneurs Windows et Windows containers on AWS Fargate parce que la version du système d'exploitation de chaque conteneur Windows doit correspondre à celle de l'hôte. Si la version Windows de l'image du conteneur est différente de celle de l'hôte, le conteneur ne démarre pas. 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_<OS_Release>_<FULL or CORE>)`. 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).

`ecs.cpu-architecture`  
Architecture du processeur de l'instance. Cet attribut peut par exemple avoir la valeur `x86_64` ou `arm64`.

`ecs.vpc-id`  
VPC dans lequel l'instance a été lancée. Cet attribut peut par exemple avoir la valeur `vpc-1234abcd`.

`ecs.subnet-id`  
Sous-réseau utilisé par l'instance. Cet attribut peut par exemple avoir la valeur `subnet-1234abcd`.

**Note**  
Les instances gérées Amazon ECS prennent en charge le sous-ensemble d’attributs suivant :  
`ecs.subnet-id`
`ecs.availability-zone`
`ecs.instance-type`
`ecs.cpu-architecture`

### Attributs facultatifs
<a name="ecs-optional-attributes"></a>

Amazon ECS peut ajouter les attributs suivants à vos instances de conteneur.

`ecs.awsvpc-trunk-id`  
Si cet attribut existe, l'instance dispose d'une interface réseau de jonction. Pour de plus amples informations, veuillez consulter [Augmentation des interfaces réseau d’une instance de conteneur Amazon ECS Linux](container-instance-eni.md).

`ecs.outpost-arn`  
Si cet attribut existe, il contient l'Amazon Resource Name (ARN) de l'Outpost. Pour de plus amples informations, veuillez consulter [Amazon Elastic Container Service sur AWS Outposts](using-outposts.md).

`ecs.capability.external`  
Si cet attribut existe, l'instance est identifiée en tant qu'instance externe. Pour de plus amples informations, veuillez consulter [Clusters Amazon ECS pour instances externes](ecs-anywhere.md).

### Attributs personnalisés
<a name="ecs-custom-attributes"></a>

Vous pouvez appliquer des attributs personnalisés à vos instances de conteneur. Par exemple, vous pouvez définir un attribut avec le nom « stack » et la valeur « prod ».

Lorsque vous spécifiez des attributs personnalisés, vous devez prendre en compte les éléments suivants.
+ Le `name` doit comprendre entre 1 et 128 caractères et peut contenir des lettres (majuscules et minuscules), des chiffres, des tirets, des traits de soulignement, des barres obliques et des points.
+ Le `value` doit comprendre entre 1 et 128 caractères et peut contenir des lettres (majuscules et minuscules), des chiffres, des tirets, des traits de soulignement, des points, des arrobases, des barres obliques, des deux-points et des espaces. La valeur ne peut pas contenir d'espaces de début ou de fin.

# Création d’expressions pour définir des instances de conteneur pour les tâches Amazon ECS
<a name="cluster-query-language"></a>

Les requêtes de cluster sont des expressions qui vous permettent de regrouper des objets. Par exemple, vous pouvez regrouper des instances de conteneur par attributs, notamment par zone de disponibilité, type d'instance ou métadonnées personnalisées. Pour de plus amples informations, veuillez consulter [Attributs d’instance de conteneur Amazon ECS](task-placement-constraints.md#attributes).

Une fois que vous avez défini un groupe d'instances de conteneur, vous pouvez personnaliser Amazon ECS de façon à placer les instances de conteneur en fonction du groupe. Pour plus d'informations, consultez [Exécution d’une application en tant que tâche Amazon ECS](standalone-task-create.md) et [Création d’un déploiement de mise à jour propagée Amazon ECS](create-service-console-v2.md). Vous pouvez également appliquer un filtre de groupe lorsque vous répertoriez les instances de conteneur.

## Syntaxe des expressions
<a name="expression-syntax"></a>

Les expressions ont la syntaxe suivante :

```
subject operator [argument]
```

**Sujet**  
Attribut ou champ à évaluer.

`agentConnected`  
Sélectionnez les instances de conteneur par leur état de connexion de l'agent de conteneur Amazon ECS. Vous pouvez utiliser ce filtre pour rechercher des instances avec des agents de conteneur déconnectés.  
Opérateurs valides : equals (==), not\$1equals (\$1=), in, not\$1in (\$1in), matches (=\$1), not\$1matches (\$1\$1)

`agentVersion`  
Sélectionnez les instances de conteneur par la version de l'agent de conteneur Amazon ECS. Vous pouvez utiliser ce filtre pour trouver des instances qui exécutent des versions obsolètes de l'agent de conteneur Amazon ECS.  
Opérateurs valides : equals (==), not\$1equals (\$1=), greater\$1than (>), greater\$1than\$1equal (>=), less\$1than (<), less\$1than\$1equal (<=)

`attribute:attribute-name`  
Sélectionnez les instances de conteneur par attribut. Pour de plus amples informations, veuillez consulter [Attributs d’instance de conteneur Amazon ECS](task-placement-constraints.md#attributes).

`ec2InstanceId`  
Sélectionnez les instances de conteneur par leur ID d'instance Amazon EC2.  
Opérateurs valides : equals (==), not\$1equals (\$1=), in, not\$1in (\$1in), matches (=\$1), not\$1matches (\$1\$1)

`registeredAt`  
Sélectionnez les instances de conteneur par leur date d'enregistrement d'instance de conteneur. Vous pouvez utiliser ce filtre pour trouver de nouvelles instances enregistrées ou des instances très anciennes.  
Opérateurs valides : equals (==), not\$1equals (\$1=), greater\$1than (>), greater\$1than\$1equal (>=), less\$1than (<), less\$1than\$1equal (<=)  
Formats de date valides : 2018-06-18T22:28:28\$100:00, 2018-06-18T22:28:28Z, 2018-06-18T22:28:28, 2018-06-18

`runningTasksCount`  
Sélectionnez les instances de conteneur par nombre de tâches en cours d'exécution. Vous pouvez utiliser ce filtre pour trouver des instances vides ou presque vides (peu de tâches exécutées sur elles).  
Opérateurs valides : equals (==), not\$1equals (\$1=), greater\$1than (>), greater\$1than\$1equal (>=), less\$1than (<), less\$1than\$1equal (<=)

`task:group`  
Sélectionnez les instances de conteneur par groupe de tâches. Pour de plus amples informations, veuillez consulter [Tâches Amazon ECS liées au groupe](task-groups.md).

**Opérateur**  
Opérateur de comparaison. Les opérateurs suivants sont pris en charge.


|  Opérateur  |  Description  | 
| --- | --- | 
|  ==, equals  |  Égalité de chaînes  | 
|  \$1=, not\$1equals  |  Inégalité de chaînes  | 
|  >, greater\$1than  |  Supérieur à  | 
|  >=, greater\$1than\$1equal  |  Supérieur ou égal à  | 
|  <, less\$1than  |  Inférieur à  | 
|  <=, less\$1than\$1equal  |  Inférieur ou égal à  | 
|  exists  |  Le sujet existe  | 
|  \$1exists, not\$1exists  |  Le sujet n'existe pas  | 
|  in  |  Valeur présente dans la liste d'arguments  | 
|  \$1in, not\$1in  |  Valeur ne se trouvant pas dans la liste d'arguments  | 
|  =\$1, matches  |  Correspondance de modèle  | 
|  \$1\$1, not\$1matches  |  Non-correspondance de modèle  | 

**Note**  
Une expression ne peut pas contenir de parenthèses. En revanche, vous pouvez utiliser des parenthèses pour spécifier la priorité dans des expressions composées.

**Argument**  
Pour de nombreux opérateurs, l'argument est une valeur littérale.

Les opérateurs `in` et `not_in` attendent une liste d'arguments comme argument. Vous spécifiez une liste d'arguments comme suit :

```
[argument1, argument2, ..., argumentN]
```

Les opérateurs matches et not\$1matches attendent un argument respectant la syntaxe de l'expression régulière Java. Pour en savoir plus, consultez [java.util.regex.Pattern](http://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html).

**Expressions composées**

Vous pouvez combiner des expressions à l'aide des opérateurs booléens suivants :
+ &&, and
+ \$1\$1, or
+ \$1, not

Vous pouvez spécifier la priorité à l'aide de parenthèses :

```
(expression1 or expression2) and expression3
```

## Exemples d'expressions
<a name="expression-examples"></a>

Des exemples d'expressions sont présentés ci-après.

**Exemple : égalité des chaînes**  
L'expression suivante sélectionne des instances avec le type d'instance spécifié.

```
attribute:ecs.instance-type == t2.small
```

**Exemple : liste d'arguments**  
L'expression suivante sélectionne des instances dans la zone de disponibilité us-east-1a ou us-east-1b.

```
attribute:ecs.availability-zone in [us-east-1a, us-east-1b]
```

**Exemple : expression composée**  
L'expression suivante sélectionne des instances G2 qui ne se trouvent pas dans la zone de disponibilité us-east-1d.

```
attribute:ecs.instance-type =~ g2.* and attribute:ecs.availability-zone != us-east-1d
```

**Exemple : affinité des tâches**  
L'expression suivante sélectionne des instances qui hébergent des tâches dans le groupe `service:production`.

```
task:group == service:production
```

**Exemple : anti-affinité des tâches**  
L'expression suivante sélectionne des instances qui n'hébergent pas de tâches dans le groupe de base de données.

```
not(task:group == database)
```

**Exemple : nombre de tâches en cours d'exécution**  
L'expression suivante sélectionne des instances qui n'exécutent qu'une seule tâche.

```
runningTasksCount == 1
```

**Exemple : version de l'agent de conteneur Amazon ECS**  
L'expression suivante sélectionne des instances qui exécutent une version de l'agent de conteneur antérieure à 1.14.5.

```
agentVersion < 1.14.5
```

**Exemple : Date d'enregistrement d'instance**  
L'expression suivante sélectionne des instances qui ont été enregistrées avant le 13 février 2018.

```
registeredAt < 2018-02-13
```

**Exemple : ID d'instance Amazon EC2**  
L'expression suivante sélectionne des instances avec l'instance Amazon EC2 suivante. IDs

```
ec2InstanceId in ['i-abcd1234', 'i-wxyx7890']
```

# Exemple de contraintes de placement de tâche Amazon ECS
<a name="constraint-examples"></a>

Voici des exemples de contraintes de placement des tâches.

Cet exemple utilise la contrainte `memberOf` pour placer des tâches sur des instances t2. Il peut être spécifié à l'aide des actions suivantes : [CreateService[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html), et [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html).

```
"placementConstraints": [
    {
        "expression": "attribute:ecs.instance-type =~ t2.*",
        "type": "memberOf"
    }
]
```

L'exemple utilise la contrainte `memberOf` pour placer des tâches de réplica sur des instances avec des tâches dans le groupe de tâches `daemon-service` du service démon, en respectant les stratégies de placement des tâches qui sont également spécifiées. Cette contrainte garantit que les tâches de service démon sont placées sur l'instance EC2 avant les tâches de service de réplica.

Remplacez `daemon-service` par le nom du service démon.

```
"placementConstraints": [
    {
        "expression": "task:group == service:daemon-service",
        "type": "memberOf"
    }
]
```

L'exemple utilise la contrainte `memberOf` pour placer des tâches sur des instances avec d'autres tâches dans le groupe de tâches `databases`, en respectant les stratégies de placement des tâches qui sont également spécifiées. Pour de plus amples informations sur les groupes de tâches, veuillez consulter [Tâches Amazon ECS liées au groupe](task-groups.md). Il peut être spécifié à l'aide des actions suivantes : [CreateService[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html), et [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html).

```
"placementConstraints": [
    {
        "expression": "task:group == databases",
        "type": "memberOf"
    }
]
```

La contrainte `distinctInstance` place chaque tâche du groupe sur une instance différente. Il peut être spécifié à l'aide des actions suivantes : [CreateService[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), et [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)

Amazon ECS examine le statut souhaité des tâches pour le placement des tâches. Par exemple, si le statut souhaité de la tâche existante est `STOPPED` (mais que le dernier statut ne l’est pas), une nouvelle tâche entrante peut être placée sur la même instance malgré la contrainte de placement `distinctInstance`. En conséquence, vous pouvez voir deux tâches dont le dernier statut est `RUNNING` sur la même instance.

```
"placementConstraints": [
    {
        "type": "distinctInstance"
    }
]
```