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.

# Cas d’utilisation de définition de tâche Amazon ECS
<a name="use-cases"></a>

Découvrez comment rédiger des définitions de tâches pour différents AWS services et fonctionnalités.

En fonction de votre charge de travail, certains paramètres de définition des tâches doivent être définis. Pour EC2 également, vous devez choisir des instances spécifiques adaptées à la charge de travail.

**Topics**
+ [

# Définitions de tâches Amazon ECS pour les charges de travail GPU
](ecs-gpu.md)
+ [

# Définitions de tâche Amazon ECS pour les charges de travail de transcodage vidéo
](ecs-vt1.md)
+ [

# Définitions de tâches Amazon ECS pour les charges de travail d'apprentissage automatique AWS Neuron
](ecs-inference.md)
+ [

# Définitions de tâche Amazon ECS pour les instances de deep learning
](ecs-dl1.md)
+ [

# Définitions de tâche Amazon ECS pour les charges de travail ARM 64 bits
](ecs-arm64.md)
+ [

# Envoyez les journaux Amazon ECS à CloudWatch
](using_awslogs.md)
+ [

# Envoyer les journaux Amazon ECS à un AWS service ou AWS Partner
](using_firelens.md)
+ [

# Utilisation d'images autres que des AWS conteneurs dans Amazon ECS
](private-auth.md)
+ [

# Redémarrage de conteneurs individuels dans les tâches Amazon ECS à l’aide de politiques de redémarrage de conteneurs
](container-restart-policy.md)
+ [

# Transmission de données sensibles vers un conteneur Amazon ECS
](specifying-sensitive-data.md)

# Définitions de tâches Amazon ECS pour les charges de travail GPU
<a name="ecs-gpu"></a>

Amazon ECS supporte les charges de travail utilisant des GPU lorsque vous créez des clusters avec des instances de conteneurs prenant en charge les GPU. Les instances de conteneur basées sur le GPU Amazon EC2 qui utilisent les types d'instances p2, p3, p5, g3, g4 et g5 fournissent un accès à NVIDIA. GPUs Pour plus d’informations, consultez la section [Instances de calcul accélérées Linux](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html) du *Guide des types d’instance Amazon EC2*.

Amazon ECS fournit une AMI optimisée pour le GPU qui est fournie avec des pilotes de noyau NVIDIA préconfigurés et une exécution du GPU du Docker. Pour de plus amples informations, veuillez consulter [Linux optimisé pour Amazon ECS AMIs](ecs-optimized_AMI.md).

Vous pouvez en désigner un certain nombre GPUs dans votre définition de tâche pour prendre en compte le placement des tâches au niveau du conteneur. Amazon ECS planifie les instances de conteneur disponibles qui prennent en charge GPUs et épinglent GPUs les conteneurs physiques aux conteneurs appropriés pour des performances optimales. 

Les types d'instances GPU Amazon EC2 suivants sont pris en charge. Pour plus d’informations, consultez les sections [Instances Amazon EC2 P2](https://aws.amazon.com/ec2/instance-types/p2/), [Instances Amazon EC2 P3](https://aws.amazon.com/ec2/instance-types/p3/), [Instances Amazon EC2 P4d](https://aws.amazon.com/ec2/instance-types/p4/), [Instances Amazon EC2 P5](https://aws.amazon.com/ec2/instance-types/p5/), [Instances Amazon EC2 G3](https://aws.amazon.com/ec2/instance-types/g3/), [Instances Amazon EC2 G4](https://aws.amazon.com/ec2/instance-types/g4/), [Instances Amazon EC2 G5](https://aws.amazon.com/ec2/instance-types/g5/), [Instances Amazon EC2 G6](https://aws.amazon.com/ec2/instance-types/g6/) et [Instances Amazon EC2 G6e](https://aws.amazon.com/ec2/instance-types/g6e/).


|  Type d’instance  |  GPUs  |  Mémoire GPU (Gio)  |  v CPUs  |  Mémoire (Gio)  | 
| --- | --- | --- | --- | --- | 
|  p3.2xlarge  |  1  |  16  |  8  |  61  | 
|  p3.8xlarge  |  4  |  64  |  32  |  244  | 
|  p3.16xlarge  |  8  |  128  |  64  |  488  | 
|  p3dn.24xlarge  |  8  |  256  |  96  |  768  | 
|  p4d.24xlarge  | 8 | 320 | 96 | 1 152 | 
| p5.48xlarge | 8 | 640 | 192 | 2048 | 
|  g3s.xlarge  |  1  |  8  |  4  |  30,5  | 
|  g3.4xlarge  |  1  |  8  |  16  |  122  | 
|  g3.8xlarge  |  2  |  16  |  32  |  244  | 
|  g3.16xlarge  |  4  |  32  |  64  |  488  | 
|  g4dn.xlarge  |  1  |  16  |  4  |  16  | 
|  g4dn.2xlarge  |  1  |  16  |  8  |  32  | 
|  g4dn.4xlarge  |  1  |  16  |  16  |  64  | 
|  g4dn.8xlarge  |  1  |  16  |  32  |  128  | 
|  g4dn.12xlarge  |  4  |  64  |  48  |  192  | 
|  g4dn.16xlarge  |  1  |  16  |  64  |  256  | 
|  g5.xlarge  |  1  |  24  |  4  |  16  | 
|  g5.2xlarge  |  1  |  24  |  8  |  32  | 
|  g5.4xlarge  |  1  |  24  |  16  |  64  | 
|  g5.8xlarge  |  1  |  24  |  32  |  128  | 
|  g5.16xlarge  |  1  |  24  |  64  |  256  | 
|  g5.12xlarge  |  4  |  96  |  48  |  192  | 
|  g5.24xlarge  |  4  |  96  |  96  |  384  | 
|  g5.48xlarge  |  8  |  192  |  192  |  768  | 
| g6.xlarge | 1 | 24 | 4 | 16 | 
| g6.2xlarge | 1 | 24 | 8 | 32 | 
| g6.4xlarge | 1 | 24 | 16 | 64 | 
| g6.8xlarge | 1 | 24 | 32 | 128 | 
| g6.16.xlarge | 1 | 24 | 64 | 256 | 
| g6.12xlarge | 4 | 96 | 48 | 192 | 
| g6.24xlarge | 4 | 96 | 96 | 384 | 
| g6.48xlarge | 8 | 192 | 192 | 768 | 
| g6.metal | 8 | 192 | 192 | 768 | 
| gr6.4xlarge | 1 | 24 | 16 | 128 | 
| g6e.xlarge | 1 | 48 | 4 | 32 | 
| g6e.2xlarge | 1 | 48 | 8 | 64 | 
| g6e.4xlarge | 1 | 48 | 16 | 128 | 
| g6e.8xlarge | 1 | 48 | 32 | 256 | 
| g6e16.xlarge | 1 | 48 | 64 | 512 | 
| g6e12.xlarge | 4 | 192 | 48 | 384 | 
| g6e24.xlarge | 4 | 192 | 96 | 768 | 
| g6e48.xlarge | 8 | 384 | 192 | 1536 | 
| gr6.8xlarge | 1 | 24 | 32 | 256 | 

Vous pouvez récupérer l'identifiant Amazon Machine Image (AMI) pour Amazon ECS-Optimized AMIs en interrogeant l'API AWS Systems Manager Parameter Store. Avec ce paramètre, vous n'avez pas besoin de rechercher manuellement l'AMI optimisée pour Amazon ECS. IDs Pour plus d'informations sur l'API Systems Manager Parameter Store, consultez [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). L'utilisateur que vous utilisez doit disposer de l'autorisation IAM `ssm:GetParameter` pour récupérer les métadonnées de l'AMI optimisée pour Amazon ECS.

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1
```

# Utilisation GPUs avec les instances gérées Amazon ECS
<a name="managed-instances-gpu"></a>

Les instances gérées Amazon ECS prennent en charge le calcul accéléré par GPU pour les charges de travail telles que le machine learning, le calcul haute performance et le traitement vidéo via les types d’instances Amazon EC2 suivants. Pour plus d’informations sur les types d’instances pris en charge sur les instances gérées Amazon ECS, consultez la section [Types d’instances gérées Amazon ECS](managed-instances-instance-types.md).

Voici un sous-ensemble des types d’instances basés sur le GPU pris en charge sur les instances gérées Amazon ECS :
+ `g4dn` : optimisé par NVIDIA T4 GPUs, adapté à l’inférence de machine learning, à la vision par ordinateur et aux applications gourmandes en graphismes.
+ `g5` : optimisé par NVIDIA A10G GPUs, offrant des performances supérieures pour les applications à forte intensité graphique et les charges de travail de machine learning.
+ `p3` : optimisé par NVIDIA V100 GPUs, conçu pour le calcul haute performance et l’entraînement du deep learning.
+ `p4d` : optimisé par NVIDIA A100 GPUs, offrant les meilleures performances pour l’entraînement du machine learning et le calcul haute performance.

Lorsque vous utilisez des types d’instances compatibles GPU avec des instances gérées Amazon ECS, les pilotes NVIDIA et le kit d’outils CUDA sont préinstallés sur l’instance, ce qui facilite l’exécution de charges de travail accélérées par GPU.

## Sélection d’instances compatibles GPU
<a name="managed-instances-gpu-instance-selection"></a>

Pour sélectionner des types d’instances compatibles GPU pour les charges de travail de vos instances gérées Amazon ECS, utilisez l’objet `instanceRequirements` dans le modèle de lancement du fournisseur de capacité. L’extrait de code suivant présente les attributs qui peuvent être utilisés pour sélectionner des instances compatibles GPU.

```
{
  "instanceRequirements": {
    "acceleratorTypes": "gpu",
    "acceleratorCount": 1,
    "acceleratorManufacturers": ["nvidia"]
  }
}
```

L’extrait de code suivant présente les attributs qui peuvent être utilisés pour spécifier les types d’instances compatibles GPU dans le modèle de lancement.

```
{
  "instanceRequirements": {
    "allowedInstanceTypes": ["g4dn.xlarge", "p4de.24xlarge"]
  }
}
```

## Images de conteneurs compatibles GPU
<a name="managed-instances-gpu-container-images"></a>

Pour les utiliser GPUs dans vos conteneurs, vous devez utiliser des images de conteneur contenant les bibliothèques et outils GPU nécessaires. NVIDIAfournit plusieurs images de conteneur prédéfinies que vous pouvez utiliser comme base pour vos charges de travail GPU, notamment les suivantes :
+ `nvidia:cuda` : images de base avec le kit d’outils CUDA pour le calcul GPU.
+ `tensorflow/tensorflow:latest-gpu` : TensorFlow avec support GPU.
+ `pytorch/pytorch:latest-cuda` : PyTorch avec support GPU.

Pour un exemple de définition de tâche pour Amazon ECS sur des instances gérées Amazon ECS impliquant l'utilisation de GPUs, consultez[Spécification GPUs dans une définition de tâche Amazon ECS](ecs-gpu-specifying.md).

## Considérations
<a name="gpu-considerations"></a>

**Note**  
La prise en charge du type de famille d'instances g2 est obsolète.  
Le type de famille d'instances p2 n'est pris en charge que sur les versions antérieures à la version `20230912` des AMI optimisées pour le GPU Amazon ECS. Si vous devez continuer à utiliser des instances p2, veuillez consulter [Que faire si vous avez besoin d'une instance P2](#p2-instance).  
Les mises à jour sur place des NVIDIA/CUDA pilotes sur ces deux types de familles d'instances peuvent entraîner des défaillances de la charge de travail du GPU.

Nous vous recommandons de prendre en compte les points suivants avant de commencer à travailler avec GPUs Amazon ECS.
+ Vos clusters peuvent contenir une combinaison d'instances de conteneur GPU et non GPU.
+ Vous pouvez exécuter des charges de travail GPU sur des instances externes. Lorsque vous enregistrez une instance externe auprès de votre cluster, assurez-vous que l'indicateur `--enable-gpu` est inclus dans le script d'installation. Pour de plus amples informations, veuillez consulter [Enregistrement d’une instance externe dans un cluster Amazon ECS](ecs-anywhere-registration.md).
+ Vous devez définir `ECS_ENABLE_GPU_SUPPORT` sur `true` dans votre fichier de configuration d'agent. Pour de plus amples informations, veuillez consulter [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md).
+ Lorsque vous exécutez une tâche ou créez un service, vous pouvez utiliser des attributs de type d'instance lors de la configuration des contraintes de placement des tâches afin de déterminer sur quelles instances de conteneur la tâche est lancée. Ainsi, vous pouvez utiliser plus efficacement vos ressources. Pour de plus amples informations, veuillez consulter [Comment Amazon ECS place les tâches sur des instances de conteneur](task-placement.md).

  L'exemple suivant lance une tâche sur une instance de conteneur `g4dn.xlarge` dans votre cluster par défaut.

  ```
  aws ecs run-task --cluster default --task-definition ecs-gpu-task-def \
       --placement-constraints type=memberOf,expression="attribute:ecs.instance-type ==  g4dn.xlarge" --region us-east-2
  ```
+ Pour chaque conteneur dont les besoins en ressources GPU sont spécifiés dans la définition du conteneur, Amazon ECS définit l'exécution du conteneur comme étant celle du conteneur NVIDIA.
+ L'exécution du conteneur NVIDIA nécessite que certaines variables d'environnement soient définies dans le conteneur pour fonctionner correctement. Pour obtenir la liste de ces variables d’environnement, consultez la section [Configurations spécialisées avec Docker](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html?highlight=environment%20variable). Amazon ECS définit la valeur de la variable d'`NVIDIA_VISIBLE_DEVICES`environnement comme une liste des périphériques GPU IDs qu'Amazon ECS attribue au conteneur. Pour les autres variables d'environnement requises, Amazon ECS ne les définit pas. Assurez-vous que votre image de conteneur les définit ou qu'elles sont définies dans la définition du conteneur.
+ La famille de types d'instances p5 est prise en charge sur la version `20230929` et les versions ultérieures des AMI optimisées pour le GPU Amazon ECS. 
+ La famille de types d'instance g4 est prise en charge sur la version `20230913` et les versions ultérieures des AMI optimisées pour le GPU Amazon ECS. Pour de plus amples informations, veuillez consulter [Linux optimisé pour Amazon ECS AMIs](ecs-optimized_AMI.md). Elle n'est pas prise en charge dans le flux de travail Create Cluster (Créer un cluster) dans la console Amazon ECS. Pour utiliser ces types d'instances, vous devez soit utiliser la console Amazon EC2 AWS CLI, soit l'API et enregistrer manuellement les instances dans votre cluster.
+ Le type d'instance p4d.24xlarge ne fonctionne qu'avec CUDA 11 ou version ultérieure.
+ L'AMI optimisée pour le GPU Amazon ECS IPv6 est activée, ce qui pose des problèmes lors de son utilisation. `yum` Ce problème peut être résolu en configurant `yum` pour l'utiliser IPv4 avec la commande suivante.

  ```
  echo "ip_resolve=4" >> /etc/yum.conf
  ```
+  Lorsque vous créez une image de conteneur qui n'utilise pas les images de NVIDIA/CUDA base, vous devez définir l'une des valeurs suivantes pour la variable d'exécution du `NVIDIA_DRIVER_CAPABILITIES` conteneur :
  + `utility,compute`
  + `all`

  Pour savoir comment définir la variable, veuillez consulter [Contrôle de l'exécution du conteneur NVIDIA](https://sarus.readthedocs.io/en/stable/user/custom-cuda-images.html#controlling-the-nvidia-container-runtime) sur le site Web de NVIDIA.
+ GPUs ne sont pas pris en charge sur les conteneurs Windows.

# Lancement d’une instance de conteneur GPU pour Amazon ECS
<a name="gpu-launch"></a>

Pour utiliser une instance GPU sur Amazon ECS avec Amazon EC2, vous devez créer un modèle de lancement, un fichier de données utilisateur, puis lancer l’instance.

Vous pouvez ensuite exécuter une tâche qui utilise une définition de tâche configurée pour le GPU.

## Utiliser un modèle de lancement
<a name="gpu-launch-template"></a>

Vous pouvez créer un modèle de lancement.
+ Créez un modèle de lancement qui utilise l’ID d’AMI GPU optimisé pour Amazon ECS pour l’AMI. Pour plus d’informations sur la création d’un modèle de lancement, consultez la section [Créer un modèle de lancement à l’aide des paramètres que vous définissez](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#create-launch-template-define-parameters) dans le *Guide de l’utilisateur Amazon EC2*.

  Utilisez l’ID d’AMI de l’étape précédente pour l’**Amazon Machine image**. Pour plus d’informations sur la façon de spécifier l’ID AMI avec le paramètre Systems Manager, consultez la section [Spécifier un paramètre Systems Manager dans un modèle de lancement](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#use-an-ssm-parameter-instead-of-an-ami-id) dans le *Guide de l’utilisateur Amazon EC2*.

  Ajoutez ce qui suit à la section **Données utilisateur** du modèle de lancement. Remplacez *cluster-name* par le nom de votre cluster.

  ```
  #!/bin/bash
  echo ECS_CLUSTER=cluster-name >> /etc/ecs/ecs.config;
  echo ECS_ENABLE_GPU_SUPPORT=true >> /etc/ecs/ecs.config
  ```

## Utilisez le AWS CLI
<a name="gpu-launch-cli"></a>

Vous pouvez utiliser le AWS CLI pour lancer l'instance de conteneur.

1. Créez un fichier appelé `userdata.toml`. Ce fichier est utilisé pour les données utilisateur de l'instance. Remplacez *cluster-name* par le nom de votre cluster.

   ```
   #!/bin/bash
   echo ECS_CLUSTER=cluster-name >> /etc/ecs/ecs.config;
   echo ECS_ENABLE_GPU_SUPPORT=true >> /etc/ecs/ecs.config
   ```

1. Exécutez la commande suivante pour obtenir l’ID d’AMI GPU. Utilisez ceci lors de l'étape suivante.

   ```
   aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1
   ```

1. Exécutez la commande suivante pour lancer l’instance GPU. N'oubliez pas de remplacer les paramètres suivants :
   + *subnet*Remplacez-le par l'ID du sous-réseau privé ou public dans lequel votre instance sera lancée.
   + *gpu\$1ami*Remplacez-le par l'ID AMI de l'étape précédente.
   + *t3.large*Remplacez-le par le type d'instance que vous souhaitez utiliser.
   + Remplacez *region* par le code de région.

   ```
   aws ec2 run-instances --key-name ecs-gpu-example \
      --subnet-id subnet \
      --image-id gpu_ami \
      --instance-type t3.large \
      --region region \
      --tag-specifications 'ResourceType=instance,Tags=[{Key=GPU,Value=example}]' \
      --user-data file://userdata.toml \
      --iam-instance-profile Name=ecsInstanceRole
   ```

1. Exécutez la commande suivante pour vérifier que l'instance de conteneur est enregistrée auprès du cluster. Lorsque vous exécutez cette commande, n'oubliez pas de remplacer les paramètres suivants :
   + Remplacez *cluster* par le nom de votre cluster.
   + *region*Remplacez-le par votre code de région.

   ```
   aws ecs list-container-instances --cluster cluster-name --region region
   ```

# Spécification GPUs dans une définition de tâche Amazon ECS
<a name="ecs-gpu-specifying"></a>

Pour utiliser l'instance GPUs sur une instance de conteneur et le runtime du GPU Docker, assurez-vous d'indiquer le nombre requis par GPUs votre conteneur dans la définition de la tâche. Au fur et à mesure que les conteneurs compatibles GPUs sont placés, l'agent de conteneur Amazon ECS épingle le nombre de conteneurs physiques GPUs souhaité sur le conteneur approprié. Le nombre de conteneurs GPUs réservés à tous les conteneurs d'une tâche ne peut pas dépasser le nombre de conteneurs disponibles GPUs sur l'instance de conteneur sur laquelle la tâche est lancée. Pour de plus amples informations, veuillez consulter [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md).

**Important**  
Si vos exigences en matière de GPU ne sont pas spécifiées dans la définition de tâche, la tâche utilise l'exécution par défaut du Docker.

L'exemple suivant illustre le format JSON pour les exigences de GPU dans une définition de tâche :

```
{
  "containerDefinitions": [
     {
        ...
        "resourceRequirements" : [
            {
               "type" : "GPU", 
               "value" : "2"
            }
        ],
     },
...
}
```

L'exemple suivant illustre la syntaxe d'un conteneur Docker qui spécifie une exigence GPU. Ce conteneur en utilise deux GPUs, exécute l'`nvidia-smi`utilitaire, puis se ferme.

```
{
  "containerDefinitions": [
    {
      "memory": 80,
      "essential": true,
      "name": "gpu",
      "image": "nvidia/cuda:11.0.3-base",
      "resourceRequirements": [
         {
           "type":"GPU",
           "value": "2"
         }
      ],
      "command": [
        "sh",
        "-c",
        "nvidia-smi"
      ],
      "cpu": 100
    }
  ],
  "family": "example-ecs-gpu"
}
```

L'exemple de définition de tâche suivant montre un TensorFlow conteneur qui imprime le nombre de tâches disponibles GPUs. La tâche s’exécute sur des instances gérées Amazon ECS, nécessite un GPU et utilise une instance `g4dn.xlarge`.

```
{
  "family": "tensorflow-gpu",
  "networkMode": "awsvpc",
  "executionRoleArn": "arn:aws:iam::account-id:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "tensorflow",
      "image": "tensorflow/tensorflow:latest-gpu",
      "essential": true,
      "command": [
        "python",
        "-c",
        "import tensorflow as tf; print('Num GPUs Available: ', len(tf.config.list_physical_devices('GPU')))"
      ],
      "resourceRequirements": [
        {
          "type": "GPU",
          "value": "1"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/tensorflow-gpu",
          "awslogs-region": "region",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ],
  "requiresCompatibilities": [
    "MANAGED_INSTANCES"
  ],
  "cpu": "4096",
  "memory": "8192",
}
```

## Partagez GPUs
<a name="share-gpu"></a>

Lorsque vous souhaitez partager GPUs, vous devez configurer les éléments suivants.

1. Supprimez les exigences en matière de ressources GPU de vos définitions de tâches afin qu'Amazon ECS ne réserve aucune GPUs ressource devant être partagée.

1. Ajoutez les données utilisateur suivantes à vos instances lorsque vous souhaitez les partager GPUs. NVIDIA deviendra ainsi le moteur d'exécution du conteneur Docker par défaut sur l'instance de conteneur afin que tous les conteneurs Amazon ECS puissent utiliser le GPUs. Pour plus d’informations, consultez la section [Exécution de commandes lors du lancement d’une instance EC2 avec des données utilisateur](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) dans le *Guide de l’utilisateur Amazon EC2*.

   ```
   const userData = ec2.UserData.forLinux();
    userData.addCommands(
    'sudo rm /etc/sysconfig/docker',
    'echo DAEMON_MAXFILES=1048576 | sudo tee -a /etc/sysconfig/docker',
    'echo OPTIONS="--default-ulimit nofile=32768:65536 --default-runtime nvidia" | sudo tee -a /etc/sysconfig/docker',
    'echo DAEMON_PIDFILE_TIMEOUT=10 | sudo tee -a /etc/sysconfig/docker',
    'sudo systemctl restart docker',
   );
   ```

1. Définissez la variable d’environnement `NVIDIA_VISIBLE_DEVICES` sur votre conteneur. Pour ce faire, vous pouvez spécifier la variable d’environnement dans votre définition de tâche. Pour plus d’informations sur les valeurs valides, consultez la section[Énumération des GPU](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html#gpu-enumeration) sur le site de documentation de NVIDIA.

## Que faire si vous avez besoin d'une instance P2
<a name="p2-instance"></a>

Si vous avez besoin d'utiliser une instance P2, vous pouvez utiliser l'une des options suivantes pour continuer à utiliser ces instances.

Vous devez modifier les données utilisateur de l'instance pour les deux options. Pour plus d’informations, consultez la section [Exécution de commandes lors du lancement d’une instance EC2 avec des données utilisateur](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) dans le *Guide de l’utilisateur Amazon EC2*.

**Utiliser la dernière AMI optimisée pour le GPU prise en charge**

Vous pouvez utiliser la version `20230906` de l'AMI optimisée pour le GPU et ajouter les éléments suivants aux données utilisateur de l'instance.

Remplacez cluster-name par le nom de votre cluster.

```
#!/bin/bash
echo "exclude=*nvidia* *cuda*" >> /etc/yum.conf
echo "ECS_CLUSTER=cluster-name" >> /etc/ecs/ecs.config
```

**Utiliser la dernière AMI optimisée pour le GPU et mettre à jour les données utilisateur**

Vous pouvez ajouter ce qui suit aux données utilisateur de l'instance. Cela désinstalle les pilotes Nvidia 535/Cuda12.2, puis installe les pilotes Nvidia 470/Cuda11.4 et corrige la version.

```
#!/bin/bash
yum remove -y cuda-toolkit* nvidia-driver-latest-dkms*
tmpfile=$(mktemp)
cat >$tmpfile <<EOF
[amzn2-nvidia]
name=Amazon Linux 2 Nvidia repository
mirrorlist=\$awsproto://\$amazonlinux.\$awsregion.\$awsdomain/\$releasever/amzn2-nvidia/latest/\$basearch/mirror.list
priority=20
gpgcheck=1
gpgkey=https://developer.download.nvidia.com/compute/cuda/repos/rhel7/x86_64/7fa2af80.pub
enabled=1
exclude=libglvnd-*
EOF

mv $tmpfile /etc/yum.repos.d/amzn2-nvidia-tmp.repo
yum install -y system-release-nvidia cuda-toolkit-11-4 nvidia-driver-latest-dkms-470.182.03
yum install -y libnvidia-container-1.4.0 libnvidia-container-tools-1.4.0 nvidia-container-runtime-hook-1.4.0 docker-runtime-nvidia-1

echo "exclude=*nvidia* *cuda*" >> /etc/yum.conf
nvidia-smi
```

**Créer votre propre AMI optimisée pour le GPU compatible avec P2**

Vous pouvez créer votre propre AMI Amazon ECS personnalisée optimisée pour le GPU et compatible avec les instances P2, puis lancer des instances P2 à l'aide de l'AMI.

1. Exécutez la commande suivante pour cloner le `amazon-ecs-ami repo`.

   ```
   git clone https://github.com/aws/amazon-ecs-ami
   ```

1. Définissez l'agent Amazon ECS requis et les versions de l'AMI Amazon Linux source dans `release.auto.pkrvars.hcl` ou `overrides.auto.pkrvars.hcl`.

1. Exécutez la commande suivante pour créer une AMI EC2 privée compatible avec P2.

   Remplacez la région par la région de l'instance.

   ```
   REGION=region make al2keplergpu
   ```

1. Utilisez l'AMI avec les données utilisateur de l'instance suivantes pour vous connecter au cluster Amazon ECS.

   Remplacez cluster-name par le nom de votre cluster.

   ```
   #!/bin/bash
   echo "ECS_CLUSTER=cluster-name" >> /etc/ecs/ecs.config
   ```

# Définitions de tâche Amazon ECS pour les charges de travail de transcodage vidéo
<a name="ecs-vt1"></a>

Pour utiliser les charges de travail de transcodage vidéo sur Amazon ECS, enregistrez les instances [Amazon VT1 EC2](https://aws.amazon.com/ec2/instance-types/vt1/). Après avoir enregistré ces instances, vous pouvez exécuter des charges de travail de transcodage vidéo en direct et prérendues en tant que tâches sur Amazon ECS. Les VT1 instances Amazon EC2 utilisent les cartes de transcodage multimédia Xilinx U30 pour accélérer les charges de travail de transcodage vidéo en direct et pré-rendu.

**Note**  
Pour obtenir des instructions sur l'exécution de charges de travail de transcodage vidéo dans des conteneurs autres qu'Amazon ECS, consultez la [documentation Xilinx](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#working-with-docker-vt1).

## Considérations
<a name="ecs-vt1-considerations"></a>

Avant de commencer VT1 le déploiement sur Amazon ECS, tenez compte des points suivants :
+ Vos clusters peuvent contenir à la fois des instances VT1 et des VT1 non-instances.
+ Vous avez besoin d'une application Linux qui utilise des cartes de transcodage multimédia Xilinx U30 avec des codecs AVC (H.264) et HEVC (H.265) accélérés.
**Important**  
Les applications qui utilisent d'autres codecs peuvent ne pas améliorer les performances des VT1 instances.
+ Une seule tâche de transcodage peut être exécutée sur une carte U30. Chaque carte est associée à deux appareils. Vous pouvez exécuter autant de tâches de transcodage qu'il y a de cartes pour chacune de vos VT1 instances.
+ Lorsque vous exécutez une tâche autonome ou créez un service, vous pouvez utiliser des attributs de type d'instance lors de la configuration des contraintes de placement des tâches. Cela garantit que la tâche est lancée sur l'instance de conteneur que vous spécifiez. Cela vous permet de vous assurer que vous utilisez vos ressources de manière efficace et que vos tâches de transcodage vidéo incombent à vos VT1 instances. Pour de plus amples informations, veuillez consulter [Comment Amazon ECS place les tâches sur des instances de conteneur](task-placement.md).

  Dans l'exemple suivant, une tâche est exécutée sur une instance `vt1.3xlarge` de votre cluster `default`.

  ```
  aws ecs run-task \
       --cluster default \
       --task-definition vt1-3xlarge-xffmpeg-processor \
       --placement-constraints type=memberOf,expression="attribute:ecs.instance-type == vt1.3xlarge"
  ```
+ Vous configurez un conteneur pour utiliser une carte U30 spécifique disponible sur l'instance de conteneur hôte. Vous pouvez effectuer cette opération en utilisant le paramètre `linuxParameters` et en spécifiant les détails de l'appareil. Pour de plus amples informations, veuillez consulter [Exigences relatives à la définition de tâche](#ecs-vt1-requirements).

## Utilisation d'une VT1 AMI
<a name="ecs-vt1-ami"></a>

Vous avez deux options pour exécuter une AMI sur des instances de conteneur Amazon EC2 pour Amazon ECS. La première option consiste à utiliser l'AMI officielle Xilinx sur AWS Marketplace. La deuxième option consiste à créer votre propre AMI à partir de l'exemple du référentiel.
+ [Xilinx propose AMIs sur le. AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-phvk6d4mq3hh6)
+ Amazon ECS fournit un exemple de référentiel que vous pouvez utiliser pour créer une AMI pour les charges de travail de transcodage vidéo. Cette AMI est fournie avec les pilotes Xilinx U30. Vous pouvez trouver le référentiel contenant les scripts Packer sur [GitHub](https://github.com/aws-samples/aws-vt-baseami-pipeline). Pour plus d'informations sur Packer, consultez la [documentation Packer](https://developer.hashicorp.com/packer/docs).

## Exigences relatives à la définition de tâche
<a name="ecs-vt1-requirements"></a>

Pour exécuter des conteneurs de transcodage vidéo sur Amazon ECS, votre définition de tâche doit contenir une application de transcodage vidéo utilisant les codecs H.264/AVC et H.265/HEVC accélérés. Vous pouvez créer une image de conteneur en suivant les étapes indiquées sur le [Xilinx GitHub](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#creating-a-docker-image-for-vt1-usage).

La définition de tâche doit être spécifique au type d'instance. Les types d'instance sont 3xlarge, 6xlarge et 24xlarge. Vous devez configurer un conteneur pour utiliser des appareils Xilinx U30 spécifiques disponibles sur l'instance de conteneur hôte. Vous pouvez effectuer cette opération à l'aide du paramètre `linuxParameters`. Le tableau suivant détaille les cartes et SoCs les appareils spécifiques à chaque type d'instance.


| Type d'instance | v CPUs | RAM (Gio) | Cartes accélératrices U30 | Appareils XCU30 SoC adressables | Chemins de l'appareil | 
| --- | --- | --- | --- | --- | --- | 
| vt1.3xlarge | 12 | 24 | 1 | 2 | /dev/dri/renderD128,/dev/dri/renderD129 | 
| vt1.6xlarge | 24 | 48 | 2 | 4 | /dev/dri/renderD128,/dev/dri/renderD129,/dev/dri/renderD130,/dev/dri/renderD131 | 
| vt1.24xlarge | 96 | 182 | 8 | 16 | /dev/dri/renderD128,/dev/dri/renderD129,/dev/dri/renderD130,/dev/dri/renderD131,/dev/dri/renderD132,/dev/dri/renderD133,/dev/dri/renderD134,/dev/dri/renderD135,/dev/dri/renderD136,/dev/dri/renderD137,/dev/dri/renderD138,/dev/dri/renderD139,/dev/dri/renderD140,/dev/dri/renderD141,/dev/dri/renderD142,/dev/dri/renderD143 | 

**Important**  
Si la définition de tâche répertorie les périphériques dont l'instance EC2 ne dispose pas, la tâche ne s'exécute pas. Lorsque la tâche échoue, le message d'erreur suivant s'affiche dans `stoppedReason` : `CannotStartContainerError: Error response from daemon: error gathering device information while adding custom device "/dev/dri/renderD130": no such file or directory`.

# Spécification du transcodage vidéo dans une définition de tâche Amazon ECS
<a name="task-def-video-transcode"></a>

Dans l'exemple suivant, la syntaxe utilisée pour définir une tâche d'un conteneur Linux sur Amazon EC2 est fournie. Cette définition de tâche concerne les images de conteneur créées conformément à la procédure fournie dans la [documentation Xilinx](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#creating-a-docker-image-for-vt1-usage). Si vous utilisez cet exemple, remplacez `image` par votre propre image, et copiez vos fichiers vidéo dans l'instance dans le répertoire `/home/ec2-user`.

------
#### [ vt1.3xlarge ]

1. Créez un fichier texte nommé `vt1-3xlarge-ffmpeg-linux.json` avec le contenu suivant.

   ```
   {
       "family": "vt1-3xlarge-xffmpeg-processor",
       "requiresCompatibilities": ["EC2"],
       "placementConstraints": [
           {
               "type": "memberOf",
               "expression": "attribute:ecs.os-type == linux"
           },
           {
               "type": "memberOf",
               "expression": "attribute:ecs.instance-type == vt1.3xlarge"
           }
       ],
       "containerDefinitions": [
           {
               "entryPoint": [
                   "/bin/bash",
                   "-c"
               ],
               "command": ["/video/ecs_ffmpeg_wrapper.sh"],
               "linuxParameters": {
                   "devices": [
                       {
                           "containerPath": "/dev/dri/renderD128",
                           "hostPath": "/dev/dri/renderD128",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD129",
                           "hostPath": "/dev/dri/renderD129",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       }
                   ]
               },
               "mountPoints": [
                   {
                       "containerPath": "/video",
                       "sourceVolume": "video_file"
                   }
               ],
               "cpu": 0,
               "memory": 12000,
               "image": "0123456789012.dkr.ecr.us-west-2.amazonaws.com/aws/xilinx-xffmpeg",
               "essential": true,
               "name": "xilinix-xffmpeg"
           }
       ],
       "volumes": [
           {
               "name": "video_file",
               "host": {"sourcePath": "/home/ec2-user"}
           }
       ]
   }
   ```

1. Enregistrez la définition de tâche.

   ```
   aws ecs register-task-definition --family vt1-3xlarge-xffmpeg-processor --cli-input-json file://vt1-3xlarge-xffmpeg-linux.json --region us-east-1
   ```

------
#### [ vt1.6xlarge ]

1. Créez un fichier texte nommé `vt1-6xlarge-ffmpeg-linux.json` avec le contenu suivant.

   ```
   {
       "family": "vt1-6xlarge-xffmpeg-processor",
       "requiresCompatibilities": ["EC2"],
       "placementConstraints": [
           {
               "type": "memberOf",
               "expression": "attribute:ecs.os-type == linux"
           },
           {
               "type": "memberOf",
               "expression": "attribute:ecs.instance-type == vt1.6xlarge"
           }
       ],
       "containerDefinitions": [
           {
               "entryPoint": [
                   "/bin/bash",
                   "-c"
               ],
               "command": ["/video/ecs_ffmpeg_wrapper.sh"],
               "linuxParameters": {
                   "devices": [
                       {
                           "containerPath": "/dev/dri/renderD128",
                           "hostPath": "/dev/dri/renderD128",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD129",
                           "hostPath": "/dev/dri/renderD129",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD130",
                           "hostPath": "/dev/dri/renderD130",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD131",
                           "hostPath": "/dev/dri/renderD131",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       }
                   ]
               },
               "mountPoints": [
                   {
                       "containerPath": "/video",
                       "sourceVolume": "video_file"
                   }
               ],
               "cpu": 0,
               "memory": 12000,
               "image": "0123456789012.dkr.ecr.us-west-2.amazonaws.com/aws/xilinx-xffmpeg",
               "essential": true,
               "name": "xilinix-xffmpeg"
           }
       ],
       "volumes": [
           {
               "name": "video_file",
               "host": {"sourcePath": "/home/ec2-user"}
           }
       ]
   }
   ```

1. Enregistrez la définition de tâche.

   ```
   aws ecs register-task-definition --family vt1-6xlarge-xffmpeg-processor --cli-input-json file://vt1-6xlarge-xffmpeg-linux.json --region us-east-1
   ```

------
#### [ vt1.24xlarge ]

1. Créez un fichier texte nommé `vt1-24xlarge-ffmpeg-linux.json` avec le contenu suivant.

   ```
   {
       "family": "vt1-24xlarge-xffmpeg-processor",
       "requiresCompatibilities": ["EC2"],
       "placementConstraints": [
           {
               "type": "memberOf",
               "expression": "attribute:ecs.os-type == linux"
           },
           {
               "type": "memberOf",
               "expression": "attribute:ecs.instance-type == vt1.24xlarge"
           }
       ],
       "containerDefinitions": [
           {
               "entryPoint": [
                   "/bin/bash",
                   "-c"
               ],
               "command": ["/video/ecs_ffmpeg_wrapper.sh"],
               "linuxParameters": {
                   "devices": [
                       {
                           "containerPath": "/dev/dri/renderD128",
                           "hostPath": "/dev/dri/renderD128",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD129",
                           "hostPath": "/dev/dri/renderD129",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD130",
                           "hostPath": "/dev/dri/renderD130",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD131",
                           "hostPath": "/dev/dri/renderD131",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD132",
                           "hostPath": "/dev/dri/renderD132",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD133",
                           "hostPath": "/dev/dri/renderD133",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD134",
                           "hostPath": "/dev/dri/renderD134",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD135",
                           "hostPath": "/dev/dri/renderD135",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD136",
                           "hostPath": "/dev/dri/renderD136",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD137",
                           "hostPath": "/dev/dri/renderD137",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD138",
                           "hostPath": "/dev/dri/renderD138",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD139",
                           "hostPath": "/dev/dri/renderD139",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD140",
                           "hostPath": "/dev/dri/renderD140",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD141",
                           "hostPath": "/dev/dri/renderD141",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD142",
                           "hostPath": "/dev/dri/renderD142",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       },
                       {
                           "containerPath": "/dev/dri/renderD143",
                           "hostPath": "/dev/dri/renderD143",
                           "permissions": [
                               "read",
                               "write"
                           ]
                       }
                   ]
               },
               "mountPoints": [
                   {
                       "containerPath": "/video",
                       "sourceVolume": "video_file"
                   }
               ],
               "cpu": 0,
               "memory": 12000,
               "image": "0123456789012.dkr.ecr.us-west-2.amazonaws.com/aws/xilinx-xffmpeg",
               "essential": true,
               "name": "xilinix-xffmpeg"
           }
       ],
       "volumes": [
           {
               "name": "video_file",
               "host": {"sourcePath": "/home/ec2-user"}
           }
       ]
   }
   ```

1. Enregistrez la définition de tâche.

   ```
   aws ecs register-task-definition --family vt1-24xlarge-xffmpeg-processor --cli-input-json file://vt1-24xlarge-xffmpeg-linux.json --region us-east-1
   ```

------

# Définitions de tâches Amazon ECS pour les charges de travail d'apprentissage automatique AWS Neuron
<a name="ecs-inference"></a>

Vous pouvez enregistrer des instances [Amazon EC2 Trn1](https://aws.amazon.com/ec2/instance-types/trn1/), Amazon EC2 [Trn2, Amazon EC2](https://aws.amazon.com/ec2/instance-types/trn2/) [Inf1 et Amazon EC2 Inf2](https://aws.amazon.com/ec2/instance-types/inf1/) [dans vos clusters pour les charges de travail d'apprentissage](https://aws.amazon.com/ec2/instance-types/inf2/) automatique.

[Les instances Amazon EC2 Trn1 et Trn2 sont alimentées par des puces Trainium.AWS](https://aws.amazon.com/ai/machine-learning/trainium/) Ces instances fournissent une formation performante et peu coûteuse pour machine learning dans le cloud. Vous pouvez entraîner un modèle d'inférence d'apprentissage automatique à l'aide d'un framework d'apprentissage automatique avec AWS Neuron sur une instance Trn1 ou Trn2. Vous pouvez ensuite exécuter le modèle sur une instance Inf1 ou sur une instance Inf2 pour utiliser l'accélération des puces AWS Inferentia.

Les instances Inf1 et Inf2 d'Amazon EC2 sont alimentées par des [puces AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/). Elles fournissent des performances élevées et les inférences de coûts les plus bas dans le cloud.

Les modèles de machine learning sont déployés sur des conteneurs à l'aide d'[AWS Neuron](https://aws.amazon.com/ai/machine-learning/neuron/), qui est un kit de développement logiciel (SDK) spécialisé. Le SDK comprend un compilateur, un environnement d'exécution et des outils de profilage qui optimisent les performances d'apprentissage automatique des puces d'apprentissage AWS automatique. AWS Neuron prend en charge les frameworks d'apprentissage automatique populaires tels que TensorFlow, PyTorch, et Apache MXNet.

## Considérations
<a name="ecs-inference-considerations"></a>

Avant de commencer à déployer Neuron sur Amazon ECS, prenez en compte ce qui suit :
+ Vos clusters peuvent contenir un mélange de Trn1, Trn2, Inf1, Inf2 et d'autres instances.
+ Vous avez besoin d'une application Linux dans un conteneur qui utilise un framework d'apprentissage automatique compatible avec AWS Neuron.
**Important**  
Les applications qui utilisent d'autres frameworks peuvent ne pas avoir amélioré les performances sur les instances Trn1, Trn2, Inf1 et Inf2.
+ Une seule tâche d'inférence ou d'entraînement d'inférence peut être exécutée sur chaque puce [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/) ou [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/). Pour Inf1, chaque puce en possède 4 NeuronCores. Pour Trn1, Trn2 et Inf2, chaque puce en possède 2. NeuronCores Vous pouvez exécuter autant de tâches qu'il y a de puces pour chacune de vos instances Trn1, Trn2, Inf1 et Inf2.
+ Lorsque vous exécutez une tâche autonome ou créez un service, vous pouvez utiliser des attributs de type d'instance lors de la configuration des contraintes de placement des tâches. Cela garantit que la tâche est lancée sur l'instance de conteneur que vous spécifiez. Cela peut vous aider à optimiser l'utilisation globale des ressources et à garantir que les tâches relatives aux charges de travail d'inférence se trouvent sur vos instances Trn1, Trn2, Inf1 et Inf2. Pour de plus amples informations, veuillez consulter [Comment Amazon ECS place les tâches sur des instances de conteneur](task-placement.md).

  Dans l'exemple suivant, une tâche est exécutée sur une instance `Inf1.xlarge` de votre cluster `default`.

  ```
  aws ecs run-task \
       --cluster default \
       --task-definition ecs-inference-task-def \
       --placement-constraints type=memberOf,expression="attribute:ecs.instance-type == Inf1.xlarge"
  ```
+ Les besoins en ressources Neuron ne peuvent pas être définis dans une définition de tâche. Vous configurez plutôt un conteneur pour utiliser des puces AWS Trainium ou AWS Inferentia spécifiques disponibles sur l'instance de conteneur hôte. Pour ce faire, utilisez le paramètre `linuxParameters` et en spécifiant les détails du dispositif. Pour de plus amples informations, veuillez consulter [Exigences relatives à la définition de tâche](#ecs-inference-requirements).

## Utilisation de l’AMI Amazon Linux 2023 (Neuron) optimisée pour Amazon ECS
<a name="ecs-inference-ami2023"></a>

Amazon ECS fournit une AMI optimisée pour Amazon ECS basée sur Amazon Linux 2023 pour les charges de travail AWS Trainium et AWS Inferentia. Il est livré avec les pilotes AWS Neuron et le runtime pour Docker. Cette AMI facilite l'exécution de charges de travail d'inférence de machine learning sur Amazon ECS.

Nous vous recommandons d’utiliser l’AMI Amazon Linux 2023 (Neuron) optimisée pour Amazon ECS lors du lancement de vos instances Trn1, Inf1 et Inf2 Amazon EC2. 

Vous pouvez récupérer l'AMI Amazon Linux 2023 (Neuron) actuellement optimisée pour Amazon ECS à l'aide de la commande AWS CLI suivante.

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/recommended
```

## Exigences relatives à la définition de tâche
<a name="ecs-inference-requirements"></a>

Pour déployer Neuron sur Amazon ECS, votre définition de tâche doit contenir la définition du conteneur d'un conteneur prédéfini servant le modèle d'inférence pour. TensorFlow Il est fourni par AWS Deep Learning Containers. Ce conteneur contient le runtime AWS Neuron et l'application TensorFlow Serving. Au démarrage, ce conteneur récupère votre modèle depuis Amazon S3, lance Neuron TensorFlow Serving avec le modèle enregistré et attend les demandes de prédiction. Dans l'exemple suivant, l'image du conteneur est TensorFlow 1.15 et Ubuntu 18.04. Une liste complète des Deep Learning Containers prédéfinis optimisés pour Neuron est disponible sur. GitHub Pour plus d'informations, consultez la section [Utilisation de AWS Neuron TensorFlow Serving](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-inferentia-tf-neuron-serving.html).

```
763104351884.dkr.ecr.us-east-1.amazonaws.com/tensorflow-inference-neuron:1.15.4-neuron-py37-ubuntu18.04
```

Alternativement, vous pouvez également créer votre propre image de conteneur sidecar Neuron. Pour plus d'informations, consultez [Tutoriel : Neuron TensorFlow Serving](https://github.com/aws-neuron/aws-neuron-sdk/blob/master/frameworks/tensorflow/tensorflow-neuron/tutorials/tutorials-tensorflow-utilizing-neuron-capabilities.rst) dans le *guide du AWS Apprentissage profond (deep learning) AMIs développeur*.

La définition de tâche doit être spécifique au type d'instance unique. Vous devez configurer un conteneur pour utiliser des appareils AWS Trainium ou AWS Inferentia spécifiques disponibles sur l'instance de conteneur hôte. Vous pouvez effectuer cette opération à l'aide du paramètre `linuxParameters`. Pour un exemple de définition de tâche, voir[Spécification de l'apprentissage automatique AWS Neuron dans une définition de tâche Amazon ECS](ecs-inference-task-def.md). Le tableau suivant détaille les cartes et les puces qui sont spécifiques à chaque type d'instance.


| Type d'instance | v CPUs | RAM (Gio) | AWS puces accélératrices ML | Chemins de l'appareil | 
| --- | --- | --- | --- | --- | 
| trn1.2xlarge | 8 | 32 | 1 | /dev/neuron0 | 
| trn1.32xlarge | 128 | 512 | 16 |  /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11, /dev/neuron12, /dev/neuron13, /dev/neuron14, /dev/neuron15  | 
| trn2.48xlarge | 192 | 1536 | 16 |  /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11, /dev/neuron12, /dev/neuron13, /dev/neuron14, /dev/neuron15  | 
| inf1.xlarge | 4 | 8 | 1 | /dev/neuron0 | 
| inf1.2xlarge | 8 | 16 | 1 | /dev/neuron0 | 
| inf1.6xlarge | 24 | 48 | 4 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3 | 
| inf1.24xlarge | 96 | 192 | 16 |  /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11, /dev/neuron12, /dev/neuron13, /dev/neuron14, /dev/neuron15  | 
| inf2.xlarge | 8 | 16 | 1 | /dev/neuron0 | 
| inf2.8xlarge | 32 | 64 | 1 | /dev/neuron0 | 
| inf2.24xlarge | 96 | 384 | 6 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5,  | 
| inf2.48xlarge | 192 | 768 | 12 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11 | 

# Spécification de l'apprentissage automatique AWS Neuron dans une définition de tâche Amazon ECS
<a name="ecs-inference-task-def"></a>

Voici un exemple de définition de tâche Linux pour `inf1.xlarge` qui affiche la syntaxe à utiliser.

```
{
    "family": "ecs-neuron",
    "requiresCompatibilities": ["EC2"],
    "placementConstraints": [
        {
            "type": "memberOf",
            "expression": "attribute:ecs.os-type == linux"
        },
        {
            "type": "memberOf",
            "expression": "attribute:ecs.instance-type == inf1.xlarge"
        }
    ],
    "executionRoleArn": "${YOUR_EXECUTION_ROLE}",
    "containerDefinitions": [
        {
            "entryPoint": [
                "/usr/local/bin/entrypoint.sh",
                "--port=8500",
                "--rest_api_port=9000",
                "--model_name=resnet50_neuron",
                "--model_base_path=s3://amzn-s3-demo-bucket/resnet50_neuron/"
            ],
            "portMappings": [
                {
                    "hostPort": 8500,
                    "protocol": "tcp",
                    "containerPort": 8500
                },
                {
                    "hostPort": 8501,
                    "protocol": "tcp",
                    "containerPort": 8501
                },
                {
                    "hostPort": 0,
                    "protocol": "tcp",
                    "containerPort": 80
                }
            ],
            "linuxParameters": {
                "devices": [
                    {
                        "containerPath": "/dev/neuron0",
                        "hostPath": "/dev/neuron0",
                        "permissions": [
                            "read",
                            "write"
                        ]
                    }
                ],
                "capabilities": {
                    "add": [
                        "IPC_LOCK"
                    ]
                }
            },
            "cpu": 0,
            "memoryReservation": 1000,
            "image": "763104351884.dkr.ecr.us-east-1.amazonaws.com/tensorflow-inference-neuron:1.15.4-neuron-py37-ubuntu18.04",
            "essential": true,
            "name": "resnet50"
        }
    ]
}
```

# Définitions de tâche Amazon ECS pour les instances de deep learning
<a name="ecs-dl1"></a>

Pour utiliser les charges de travail d'apprentissage profond sur Amazon ECS, enregistrez les instances [Amazon DL1](https://aws.amazon.com/ec2/instance-types/dl1/) EC2 dans vos clusters. Les DL1 instances Amazon EC2 sont alimentées par les accélérateurs Gaudi de Habana Labs (une société Intel). Utilisez le SDK Habana SynapseAI pour vous connecter aux accélérateurs Habana Gaudi. Le SDK prend en charge les frameworks d'apprentissage automatique populaires, TensorFlow et PyTorch.

## Considérations
<a name="ecs-dl1-considerations"></a>

Avant de commencer DL1 le déploiement sur Amazon ECS, tenez compte des points suivants :
+ Vos clusters peuvent contenir à la fois des instances DL1 et des DL1 non-instances.
+ Lorsque vous exécutez une tâche autonome ou créez un service, vous pouvez utiliser des attributs de type d'instance lors de la configuration des contraintes de placement des tâches afin de garantir sur quelles instances de conteneur la tâche, que vous spécifiez, est lancée. Cela garantit que vos ressources sont utilisées efficacement et que les tâches relatives aux charges de travail liées au deep learning se situent sur vos DL1 instances. Pour de plus amples informations, veuillez consulter [Comment Amazon ECS place les tâches sur des instances de conteneur](task-placement.md).

  L'exemple suivant exécute une tâche sur une instance `dl1.24xlarge` de votre cluster `default`.

  ```
  aws ecs run-task \
       --cluster default \
       --task-definition ecs-dl1-task-def \
       --placement-constraints type=memberOf,expression="attribute:ecs.instance-type == dl1.24xlarge"
  ```

## Utilisation d'une DL1 AMI
<a name="ecs-dl1-ami"></a>

Trois options s'offrent à vous pour exécuter une AMI sur des DL1 instances Amazon EC2 pour Amazon ECS :
+ AWS Marketplace AMIs qui sont fournis par Habana [ici.](https://aws.amazon.com/marketplace/pp/prodview-h24gzbgqu75zq)
+ Habana Deep Learning AMIs fourni par Amazon Web Services. Comme il n'est pas inclus, vous devez installer l'agent de conteneur Amazon ECS séparément.
+ Utilisez Packer pour créer une AMI personnalisée fournie par le [GitHubdépôt](https://github.com/aws-samples/aws-habana-baseami-pipeline). Pour plus d'informations, consultez la section [documentation Packer](https://developer.hashicorp.com/packer/docs).

# Spécification du deep learning dans une définition de tâche Amazon ECS
<a name="ecs-dl1-requirements"></a>

Pour exécuter des conteneurs d'apprentissage profond accéléré Habana Gaudi sur Amazon ECS, votre définition de tâche doit contenir la définition de conteneur d'un conteneur prédéfini qui sert le modèle d'apprentissage profond pour TensorFlow ou PyTorch utilisant Habana SynapseAI fourni par Deep Learning Containers. AWS 

L'image de conteneur suivante contient la TensorFlow version 2.7.0 et Ubuntu 20.04. Une liste complète des Deep Learning Containers prédéfinis et optimisés pour les accélérateurs Habana Gaudi est mise à jour sur. GitHub Pour de plus amples informations, veuillez consulter la section [Conteneurs d'entraînement Habana](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#habana-training-containers).

```
763104351884.dkr.ecr.us-east-1.amazonaws.com/tensorflow-training-habana:2.7.0-hpu-py38-synapseai1.2.0-ubuntu20.04
```

Voici un exemple de définition de tâche de conteneurs Linux sur Amazon EC2 qui affiche la syntaxe à utiliser. Cet exemple utilise une image contenant l'outil HL-SMI (HL-SMI) Habana Labs, disponible ici : `vault.habana.ai/gaudi-docker/1.1.0/ubuntu20.04/habanalabs/tensorflow-installer-tf-cpu-2.6.0:1.1.0-614`

```
{
    "family": "dl-test",
    "requiresCompatibilities": ["EC2"],
    "placementConstraints": [
        {
            "type": "memberOf",
            "expression": "attribute:ecs.os-type == linux"
        },
        {
            "type": "memberOf",
            "expression": "attribute:ecs.instance-type == dl1.24xlarge"
        }
    ],
    "networkMode": "host",
    "cpu": "10240",
    "memory": "1024",
    "containerDefinitions": [
        {
            "entryPoint": [
                "sh",
                "-c"
            ],
            "command": ["hl-smi"],
            "cpu": 8192,
            "environment": [
                {
                    "name": "HABANA_VISIBLE_DEVICES",
                    "value": "all"
                }
            ],
            "image": "vault.habana.ai/gaudi-docker/1.1.0/ubuntu20.04/habanalabs/tensorflow-installer-tf-cpu-2.6.0:1.1.0-614",
            "essential": true,
            "name": "tensorflow-installer-tf-hpu"
        }
    ]
}
```

# Définitions de tâche Amazon ECS pour les charges de travail ARM 64 bits
<a name="ecs-arm64"></a>

Amazon ECS prend en charge l'utilisation d'applications ARM 64 bits. Vous pouvez exécuter vos applications sur la plateforme optimisée par les [processeurs AWS  Graviton](https://aws.amazon.com/ec2/graviton/). Cette plateforme est adaptée à une grande variété de charges de travail. Cela inclut les charges de travail telles que les serveurs d'applications, les microservices, le calcul hautes performances, l'inférence de machine learning basée sur le processeur, l'encodage vidéo, l'automatisation de la conception électronique, les jeux vidéos, les bases de données open source et les caches en mémoire.

## Considérations
<a name="ecs-arm64-considerations"></a>

Avant de commencer à déployer des définitions de tâche utilisant l'architecture ARM 64 bits, tenez compte des points suivants :
+ Les applications peuvent utiliser le Fargate ou. EC2s
+ Les applications ne peuvent utiliser que le système d'exploitation Linux.
+ Pour le type Fargate, les applications doivent utiliser la version de plateforme `1.4.0` Fargate ou version ultérieure.
+ Les applications peuvent être utilisées Fluent Bit ou à CloudWatch des fins de surveillance.
+ Pour le Fargate, les Régions AWS éléments suivants ne prennent pas en charge les charges de travail ARM 64 bits :
  + USA Est (Virginie du Nord), la zone de disponibilité `use1-az3`
+  Pour EC2, consultez les points suivants pour vérifier que votre Région prend en charge le type d’instance que vous souhaitez utiliser :
  + [Instances M6g Amazon EC2](https://aws.amazon.com/ec2/instance-types/m6)
  +  [Instances T4g Amazon EC2](https://aws.amazon.com/ec2/instance-types/t4/)
  +  [Instances C6g Amazon EC2](https://aws.amazon.com/ec2/instance-types/c6g/)
  +  [Instances R6gd Amazon EC2](https://aws.amazon.com/ec2/instance-types/r6/)
  +  [Instances X2gd Amazon EC2](https://aws.amazon.com/ec2/instance-types/x2/)

  Vous pouvez également utiliser la commande `describe-instance-type-offerings` Amazon EC2 avec un filtre pour afficher l'offre d'instances pour votre Région. 

  ```
  aws ec2 describe-instance-type-offerings --filters Name=instance-type,Values=instance-type --region region
  ```

  L'exemple suivant vérifie la disponibilité du type d'instance M6 dans la Région USA Est (Virginie du Nord) (us-east-1).

  ```
  aws ec2 describe-instance-type-offerings --filters "Name=instance-type,Values=m6*" --region us-east-1
  ```

  Pour plus d'informations, consultez [describe-instance-type-offerings ](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html)le manuel *Amazon EC2 Command Line* Reference.

# Spécification de l’architecture ARM dans votre définition de tâche Amazon ECS
<a name="ecs-arm-specifying"></a>

Pour utiliser l'architecture ARM, spécifiez `ARM64` pour paramètre de la définition de la tâche `cpuArchitecture`. 

Dans l'exemple suivant, l'architecture ARM est spécifiée dans une définition de tâche. Elles sont au format JSON.

```
{
    "runtimePlatform": {
        "operatingSystemFamily": "LINUX",
        "cpuArchitecture": "ARM64"
    },
...
}
```

Dans l'exemple suivant, une définition de tâche pour l'architecture ARM affiche « hello world ».

```
{
 "family": "arm64-testapp",
 "networkMode": "awsvpc",
 "containerDefinitions": [
    {
        "name": "arm-container",
        "image": "public.ecr.aws/docker/library/busybox:latest",
        "cpu": 100,
        "memory": 100,
        "essential": true,
        "command": [ "echo hello world" ],
        "entryPoint": [ "sh", "-c" ]
    }
 ],
 "requiresCompatibilities": [ "EC2" ],
 "cpu": "256",
 "memory": "512",
 "runtimePlatform": {
        "operatingSystemFamily": "LINUX",
        "cpuArchitecture": "ARM64"
  },
 "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
}
```

# Envoyez les journaux Amazon ECS à CloudWatch
<a name="using_awslogs"></a>

Vous pouvez configurer les conteneurs de vos tâches pour envoyer des informations de journal à CloudWatch Logs. Si vous utilisez Fargate pour vos tâches, vous pouvez afficher les journaux de vos conteneurs. Si vous utilisez EC2, vous pouvez afficher différents journaux de vos conteneurs dans un emplacement pratique, et cela empêche vos journaux de conteneur d’occuper de l’espace disque sur vos instances de conteneur.

**Note**  
Le type des informations qui sont consignées par les conteneurs dans votre tâche dépend principalement de leur commande `ENTRYPOINT`. Par défaut, les journaux qui sont capturés affichent la sortie de la commande qui peuvent s'afficher normalement dans un terminal interactif si vous aviez exécuté le conteneur localement, c'est-à-dire les flux d'I/O `STDOUT` et `STDERR`. Le pilote de `awslogs` journal transmet simplement ces journaux de Docker à CloudWatch Logs. Pour plus d'informations sur la façon dont les journaux Docker sont traités, et notamment sur les autres façons de capturer différentes données de fichiers ou différents flux, consultez [View logs for a container or service](https://docs.docker.com/engine/logging/) dans la documentation Docker.

Pour envoyer les journaux système de vos instances de conteneur Amazon ECS vers CloudWatch Logs, consultez la section [Surveillance des fichiers journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchLogs.html) et [CloudWatch des quotas de journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html) dans le *guide de l'utilisateur Amazon CloudWatch Logs*.

## Fargate
<a name="enable_awslogs"></a>

Si vous utilisez Fargate pour vos tâches, vous devez ajouter les paramètres `logConfiguration` requis à votre définition de tâche pour activer le pilote de journalisation `awslogs`. Pour de plus amples informations, veuillez consulter [Exemple de définition de tâche Amazon ECS : acheminer les journaux vers CloudWatch](specify-log-config.md).

Pour le conteneur Windows sur Fargate, effectuez l’une des options suivantes lorsque l’un des paramètres de définition de tâche comporte des caractères spéciaux tels que `& \ < > ^ |` :
+ Ajoutez un caractère d’échappement (`\`) avec des guillemets autour de la chaîne de paramètres entière

  Exemple

  ```
  "awslogs-multiline-pattern": "\"^[|DEBUG|INFO|WARNING|ERROR\"",
  ```
+ Ajoutez un caractère d’échappement (`^`) autour de chaque caractère spécial

  Exemple

  ```
  "awslogs-multiline-pattern": "^^[^|DEBUG^|INFO^|WARNING^|ERROR",
  ```

## EC2
<a name="ec2-considerations"></a>

Si vous utilisez le type de lancement EC2 pour vos tâches et que vous souhaitez activer le pilote de journalisation `awslogs`, vos instances de conteneur Amazon ECS nécessitent au moins la version 1.9.0 de l’agent de conteneur. Pour plus d'informations sur la vérification de la version de votre agent et la mise à jour à la dernière version, consultez [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md).

**Note**  
Vous devez utiliser une AMI optimisée pour Amazon ECS ou une AMI personnalisée avec au moins une version `1.9.0-1` du package `ecs-init`. Lorsque vous utilisez une AMI personnalisée, vous devez spécifier que le pilote de journalisation `awslogs` est disponible sur l’instance Amazon EC2 lorsque vous démarrez l’agent en utilisant la variable d’environnement suivante dans votre instruction **docker run** ou votre fichier de variables d’environnement.  

```
ECS_AVAILABLE_LOGGING_DRIVERS=["json-file","awslogs"]
```

Vos instances de conteneur Amazon ECS nécessitent également une autorisation `logs:CreateLogStream` et `logs:PutLogEvents` sur le rôle IAM avec lequel vous pouvez lancer vos instances de conteneur. Si vous avez créé votre rôle d'instance de conteneur Amazon ECS avant l'activation de la prise en charge du pilote du journal `awslogs` dans Amazon ECS, vous devrez sans doute ajouter ces autorisations. `ecsTaskExecutionRole` est utilisé lorsqu'il est affecté à la tâche et contient probablement les autorisations appropriées. Pour plus d’informations sur le rôle d’exécution de tâche, consultez la section [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md). Si vos instances de conteneur utilisent la politique IAM gérée pour les instances de conteneur, vos instances de conteneur disposent probablement des autorisations appropriées. Pour obtenir des informations sur la politique IAM gérée pour les instances de conteneur, consultez la section [Rôle IAM d'instance de conteneur Amazon ECS](instance_IAM_role.md).

# Exemple de définition de tâche Amazon ECS : acheminer les journaux vers CloudWatch
<a name="specify-log-config"></a>

Avant que vos conteneurs puissent envoyer des journaux CloudWatch, vous devez spécifier le pilote de `awslogs` journal pour les conteneurs dans votre définition de tâche. Pour plus d’informations sur les paramètres de journalisation, consultez la section [Stockage et journalisation](task_definition_parameters.md#container_definition_storage).

La définition de tâche JSON qui suit possède un objet `logConfiguration` spécifié pour chaque conteneur. L'un concerne le WordPress conteneur qui envoie les journaux à un groupe de journaux appelé`awslogs-wordpress`. L'autre concerne un conteneur MySQL qui envoie des journaux à un groupe de journaux appelé `awslogs-mysql`. Les deux conteneurs utilisent le préfixe de flux de journal `awslogs-example`.

```
{
    "containerDefinitions": [
        {
            "name": "wordpress",
            "links": [
                "mysql"
            ],
            "image": "public.ecr.aws/docker/library/wordpress:latest",
            "essential": true,
            "portMappings": [
                {
                    "containerPort": 80,
                    "hostPort": 80
                }
            ],
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-create-group": "true",
                    "awslogs-group": "awslogs-wordpress",
                    "awslogs-region": "us-west-2",
                    "awslogs-stream-prefix": "awslogs-example"
                }
            },
            "memory": 500,
            "cpu": 10
        },
        {
            "environment": [
                {
                    "name": "MYSQL_ROOT_PASSWORD",
                    "value": "password"
                }
            ],
            "name": "mysql",
            "image": "public.ecr.aws/docker/library/mysql:latest",
            "cpu": 10,
            "memory": 500,
            "essential": true,
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-create-group": "true",
                    "awslogs-group": "awslogs-mysql",
                    "awslogs-region": "us-west-2",
                    "awslogs-stream-prefix": "awslogs-example",
                    "mode": "non-blocking", 
                    "max-buffer-size": "25m" 
                }
            }
        }
    ],
    "family": "awslogs-example"
}
```

## Étapes suivantes
<a name="specify-log-config-next-steps"></a>
+ Vous pouvez éventuellement définir une politique de rétention pour le groupe de journaux à l'aide de l'API CloudWatch AWS CLI or. Pour plus d'informations, consultez [put-retention-policy](https://docs.aws.amazon.com/cli/latest/reference/logs/put-retention-policy.html) dans la *référence AWS Command Line Interface *.
+ Après avoir enregistré une définition de tâche avec le pilote de `awslogs` journal dans une configuration de journal de définition de conteneur, vous pouvez exécuter une tâche ou créer un service avec cette définition de tâche pour commencer à envoyer des CloudWatch journaux à Logs. Pour plus d’informations, consultez [Exécution d’une application en tant que tâche Amazon ECS](standalone-task-create.md) et [Création d’un déploiement de mise à jour propagée Amazon ECS](create-service-console-v2.md).

# Envoyer les journaux Amazon ECS à un AWS service ou AWS Partner
<a name="using_firelens"></a>

Vous pouvez utiliser Amazon ECS FireLens pour utiliser les paramètres de définition des tâches pour acheminer les journaux vers un AWS service ou une destination AWS Partner Network (APN) à des fins de stockage et d'analyse des journaux. AWS Partner Network Il s'agit d'une communauté mondiale de partenaires qui tire parti des programmes, de l'expertise et des ressources pour créer, commercialiser et vendre des offres aux clients. Pour plus d'informations, veuillez consulter [AWS Partner](https://aws.amazon.com/partners/work-with-partners/). FireLens fonctionne avec [Fluentd](https://www.fluentd.org/) et [Fluent Bit](https://fluentbit.io/). Nous fournissons l'image AWS pour Fluent Bit ou vous pouvez utiliser votre propre image Fluentd ou Fluent Bit.

Par défaut, Amazon ECS configure la dépendance du conteneur pour que le conteneur Firelens démarre avant tout conteneur qui l’utilise. Le conteneur Firelens s’arrête également une fois que tous les conteneurs qui l’utilisent se sont arrêtés.

Pour utiliser cette fonctionnalité, vous devez créer un rôle IAM pour vos tâches qui fournit les autorisations nécessaires pour utiliser les AWS services requis par les tâches. Par exemple, si un conteneur achemine des journaux vers Firehose, la tâche nécessite l’autorisation d’appeler l’API `firehose:PutRecordBatch`. Pour plus d'informations, consultez [Ajout et suppression d'autorisations basées sur l'identité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) dans le *Guide de l'utilisateur IAM*.

Votre tâche peut également nécessiter le rôle d’exécution de tâche Amazon ECS dans les conditions suivantes. Pour de plus amples informations, veuillez consulter [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md).
+ Si votre tâche est hébergée sur Fargate et que vous extrayez des images de conteneurs depuis Amazon ECR ou que vous faites référence à des données sensibles AWS Secrets Manager depuis votre configuration de journal, vous devez inclure le rôle IAM d'exécution de la tâche.
+ Lorsque vous utilisez un fichier de configuration personnalisé hébergé dans Amazon S3, votre rôle IAM d’exécution de tâche doit inclure l’autorisation `s3:GetObject`.

Tenez compte des points suivants lors de l'utilisation FireLens pour Amazon ECS :
+ Nous vous recommandons d’ajouter `my_service_` au nom du conteneur de journaux afin de pouvoir facilement le distinguer dans la console.
+ Amazon ECS ajoute par défaut une dépendance relative à l’ordre des conteneurs de démarrage entre les conteneurs d’applications et le conteneur FireLens. Lorsque vous spécifiez un ordre de conteneur entre les conteneurs d’applications et le conteneur FireLens, l’ordre de conteneur de départ par défaut est remplacé.
+ FireLens pour Amazon ECS est pris en charge pour les tâches hébergées à la fois sur AWS Fargate sur Linux et Amazon EC2 sur Linux. Les conteneurs Windows ne prennent pas en charge FireLens.

  Pour plus d'informations sur la configuration de la journalisation centralisée pour les conteneurs Windows, consultez la section [Journalisation centralisée pour les conteneurs Windows sur Amazon ECS à l'aide de Fluent Bit](https://aws.amazon.com/blogs/containers/centralized-logging-for-windows-containers-on-amazon-ecs-using-fluent-bit/).
+ Vous pouvez utiliser CloudFormation des modèles FireLens pour configurer Amazon ECS. Pour plus d'informations, voir [AWS::ECS::TaskDefinition FirelensConfiguration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-firelensconfiguration.html)le *guide de AWS CloudFormation l'utilisateur*
+ FireLensécoute sur le port`24224`. Pour vous assurer que le routeur de FireLens journaux n'est pas accessible en dehors de la tâche, vous ne devez pas autoriser le trafic entrant sur le port `24224` du groupe de sécurité utilisé par votre tâche. Pour les tâches utilisant le mode réseau `awsvpc`, il s'agit du groupe de sécurité associé à la tâche. Pour les tâches utilisant le mode réseau `host`, il s'agit du groupe de sécurité associé à l'instance Amazon EC2 qui héberge la tâche. Pour les tâches utilisant le mode réseau `bridge`, ne créez pas de mappages de ports utilisant le port `24224`.
+ Pour les tâches qui utilisent le mode `bridge` réseau, le conteneur contenant la FireLens configuration doit démarrer avant que les conteneurs d'applications qui en dépendent ne démarrent. Pour contrôler l'ordre de début de vos conteneurs, utilisez les conditions de dépendance dans la définition de tâche. Pour de plus amples informations, veuillez consulter [Dépendances du conteneur](task_definition_parameters.md#container_definition_dependson).
**Note**  
Si vous utilisez des paramètres de condition de dépendance dans les définitions de conteneur avec une FireLens configuration, assurez-vous que chaque conteneur possède une exigence de `HEALTHY` condition `START` or.
+ Par défaut, FireLens ajoute le nom du cluster et de la définition de tâche ainsi que le nom de ressource Amazon (ARN) du cluster en tant que clés de métadonnées stdout/stderr dans vos journaux de conteneurs. Voici un exemple du format de métadonnées.

  ```
  "ecs_cluster": "cluster-name",
  "ecs_task_arn": "arn:aws:ecs:region:111122223333:task/cluster-name/f2ad7dba413f45ddb4EXAMPLE",
  "ecs_task_definition": "task-def-name:revision",
  ```

  Si vous ne souhaitez pas que les métadonnées figurent dans vos journaux, définissez `enable-ecs-log-metadata` sur `false`dans la section `firelensConfiguration` de la définition de tâche.

  ```
  "firelensConfiguration":{
     "type":"fluentbit",
     "options":{
        "enable-ecs-log-metadata":"false",
        "config-file-type":"file",
        "config-file-value":"/extra.conf"
  }
  ```

Vous pouvez configurer le FireLens conteneur pour qu'il s'exécute en tant qu'utilisateur non root. Éléments à prendre en compte :
+  Pour configurer le FireLens conteneur afin qu'il s'exécute en tant qu'utilisateur non root, vous devez spécifier l'utilisateur dans l'un des formats suivants :
  + `uid`
  + `uid:gid`
  + `uid:group`

  Pour plus d'informations sur la spécification d'un utilisateur dans une définition de conteneur, consultez le [ContainerDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html)manuel *Amazon Elastic Container Service API Reference*.

  Le FireLens conteneur reçoit les journaux des applications via un UNIX socket. L'agent Amazon ECS utilise le `uid` pour attribuer la propriété du répertoire de sockets au FireLens conteneur.
+ La configuration du FireLens conteneur pour qu'il s'exécute en tant qu'utilisateur non root est prise en charge sur les versions Amazon ECS Agent `1.96.0` et ultérieures, ainsi que sur les versions AMI optimisées pour Amazon ECS et `v20250716` versions ultérieures.
+ Lorsque vous spécifiez un utilisateur pour le FireLens conteneur, celui-ci `uid` doit être unique et ne pas être utilisé pour d'autres processus appartenant à d'autres conteneurs de la tâche ou de l'instance de conteneur.

Pour plus d’informations sur l’utilisation de plusieurs fichiers de configuration avec Amazon ECS, y compris les fichiers que vous hébergez ou les fichiers dans Amazon S3, consultez la section [Processus d’initialisation pour Fluent Bit sur ECS, support multiconfigurations](https://github.com/aws/aws-for-fluent-bit/tree/mainline/use_cases/init-process-for-fluent-bit).

Pour plus d'informations sur les exemples de configurations, consultez[Exemple de définition de tâche Amazon ECS : acheminement des journaux vers FireLens](firelens-taskdef.md).

Pour plus d'informations sur la configuration des journaux pour un débit élevé, consultez[Configuration des journaux Amazon ECS pour un débit élevé](firelens-docker-buffer-limit.md).

# Configuration des journaux Amazon ECS pour un débit élevé
<a name="firelens-docker-buffer-limit"></a>

Pour les scénarios à haut débit de log, nous recommandons d'utiliser le pilote de `awsfirelens` log avec FireLens etFluent Bit. Fluent Bitest un processeur de journaux léger qui utilise efficacement les ressources et peut gérer des millions d'enregistrements de journaux. Cependant, pour obtenir des performances optimales à grande échelle, il faut ajuster sa configuration.

Cette section décrit les techniques Fluent Bit d'optimisation avancées permettant de gérer un débit de log élevé tout en préservant la stabilité du système et en évitant toute perte de données.

Pour plus d'informations sur l'utilisation de fichiers de configuration personnalisés avec FireLens, consultez[Utilisation d’un fichier de configuration](firelens-taskdef.md#firelens-taskdef-customconfig). Pour des exemples supplémentaires, consultez les [ FireLens exemples d'Amazon ECS](https://github.com/aws-samples/amazon-ecs-firelens-examples) sur GitHub.

**Note**  
Certaines options de configuration de cette section, telles que `workers` et`threaded`, nécessitent AWS la Fluent Bit version 3 ou ultérieure. Pour plus d'informations sur les versions disponibles, voir [AWS les versions de Fluent Bit](https://github.com/aws/aws-for-fluent-bit/releases).

## Comprendre les morceaux
<a name="firelens-understanding-chunks"></a>

Fluent Bittraite les données en unités appelées *fragments.* Lorsqu'un plugin INPUT reçoit des données, le moteur crée un fragment qui est stocké en mémoire ou sur le système de fichiers avant d'être envoyé aux destinations OUTPUT.

Le comportement de mise en mémoire tampon dépend du `storage.type` paramètre défini dans vos sections INPUT. Par défaut, Fluent Bit utilise la mise en mémoire tampon. Pour les scénarios à haut débit ou de production, la mise en mémoire tampon du système de fichiers offre une meilleure résilience.

Pour plus d'informations, consultez les sections [Chunks](https://docs.fluentbit.io/manual/administration/buffering-and-storage#chunks) dans la Fluent Bit documentation et [Qu'est-ce qu'un chunk ?](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#what-is-a-chunk) dans le référentiel AWS for Fluent Bit examples.

## Mise en mémoire tampon (par défaut)
<a name="firelens-memory-buffering"></a>

Par défaut, Fluent Bit utilise la mise en mémoire tampon (`storage.type memory`). Vous pouvez limiter l'utilisation de la mémoire par plug-in INPUT à l'aide du `Mem_Buf_Limit` paramètre.

L'exemple suivant montre une configuration d'entrée mise en mémoire tampon :

```
[INPUT]
    Name          tcp
    Tag           ApplicationLogs
    Port          5170
    storage.type  memory
    Mem_Buf_Limit 5MB
```

**Important**  
Lorsqu'il `Mem_Buf_Limit` est dépassé pour un plugin, la Fluent Bit saisie est interrompue et les nouveaux enregistrements sont perdus. Cela peut provoquer une contre-pression et ralentir votre application. L'avertissement suivant apparaît dans les Fluent Bit journaux :  

```
[input] tcp.1 paused (mem buf overlimit)
```

La mise en mémoire tampon convient aux cas d'utilisation simples avec un débit de log faible à modéré. Pour les scénarios à haut débit ou de production où la perte de données est un problème, utilisez plutôt la mise en mémoire tampon du système de fichiers.

Pour plus d'informations, consultez [Buffering and Memory](https://docs.fluentbit.io/manual/administration/buffering-and-storage#buffering-and-memory) dans la Fluent Bit documentation et [Memory Buffering Only](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-1-memory-buffering-only-default-or-storagetype-memory) dans le référentiel AWS for Fluent Bit examples.

## Mise en mémoire tampon du système de fichiers
<a name="firelens-filesystem-buffering"></a>

Pour les scénarios à haut débit, nous recommandons d'utiliser la mise en mémoire tampon du système de fichiers. Pour plus d'informations sur la Fluent Bit gestion de la mise en mémoire tampon et du stockage, consultez la section Mise en [mémoire tampon et stockage](https://docs.fluentbit.io/manual/administration/buffering-and-storage) dans la Fluent Bit documentation.

La mise en mémoire tampon du système de fichiers présente les avantages suivants :
+ **Capacité de mémoire tampon plus importante** : l'espace disque est généralement plus abondant que la mémoire.
+ **Persistance** : les données mises en mémoire tampon survivent Fluent Bit aux redémarrages.
+ **Dégradation progressive** : lors de défaillances de sortie, les données s'accumulent sur le disque au lieu d'épuiser la mémoire.

Pour activer la mise en mémoire tampon du système de fichiers, fournissez un fichier de Fluent Bit configuration personnalisé. L'exemple suivant montre la configuration recommandée :

```
[SERVICE]
    # Flush logs every 1 second
    Flush 1
    # Wait 120 seconds during shutdown to flush remaining logs
    Grace 120
    # Directory for filesystem buffering
    storage.path             /var/log/flb-storage/
    # Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
    storage.max_chunks_up    32
    # Flush backlog chunks to destinations during shutdown (prevents log loss)
    storage.backlog.flush_on_shutdown On

[INPUT]
    Name forward
    unix_path /var/run/fluent.sock
    # Run input in separate thread to prevent blocking
    threaded true
    # Enable filesystem buffering for persistence
    storage.type filesystem

[OUTPUT]
    Name cloudwatch_logs
    Match *
    region us-west-2
    log_group_name /aws/ecs/my-app
    log_stream_name $(ecs_task_id)
    # Use multiple workers for parallel processing
    workers 2
    # Retry failed flushes up to 15 times
    retry_limit 15
    # Maximum disk space for buffered data for this output
    storage.total_limit_size 10G
```

Principaux paramètres de configuration :

`storage.path`  
Le répertoire dans lequel sont Fluent Bit stockés les fragments mis en mémoire tampon sur le disque.

`storage.backlog.flush_on_shutdown`  
Lorsque cette option est activée, Fluent Bit tente de vider tous les fragments du système de fichiers en attente vers leur destination lors de l'arrêt. Cela permet de garantir la livraison des données avant les Fluent Bit arrêts, mais peut augmenter le temps d'arrêt.

`storage.max_chunks_up`  
Le nombre de segments qui restent en mémoire. La valeur par défaut est de 128 blocs, qui peuvent consommer plus de 500 Mo de mémoire, car chaque bloc peut utiliser jusqu'à 4 à 5 Mo. Dans les environnements où la mémoire est limitée, réduisez cette valeur. Par exemple, si vous disposez de 50 Mo pour la mise en mémoire tampon, définissez ce paramètre sur 8 à 10 segments.

`storage.type filesystem`  
Active le stockage du système de fichiers pour le plugin d'entrée. Malgré son nom, il permet Fluent Bit de `mmap` mapper des fragments à la fois à la mémoire et au disque, garantissant ainsi la persistance sans sacrifier les performances.

`storage.total_limit_size`  
Espace disque maximal pour les données mises en mémoire tampon pour un plugin OUTPUT spécifique. Lorsque cette limite est atteinte, les enregistrements les plus anciens de cette sortie sont supprimés. Pour plus d'informations sur le dimensionnement, consultez[Présentation du code `storage.total_limit_size`](#firelens-storage-sizing).

`threaded true`  
Exécute l'entrée dans son propre thread, séparé Fluent Bit de la boucle d'événements principale. Cela empêche les entrées lentes de bloquer l'ensemble du pipeline.

Pour plus d'informations, consultez la section Mise en [mémoire tampon du système de fichiers](https://docs.fluentbit.io/manual/administration/buffering-and-storage#filesystem-buffering) dans la Fluent Bit documentation et Mise en [mémoire tampon du système de fichiers et de la mémoire](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-2-filesystem-and-memory-buffering-storagetype-filesystem) dans le AWS référentiel d'exemples. Fluent Bit

## Présentation du code `storage.total_limit_size`
<a name="firelens-storage-sizing"></a>

Le `storage.total_limit_size` paramètre de chaque plug-in OUTPUT contrôle l'espace disque maximal pour les données mises en mémoire tampon pour cette sortie. Lorsque cette limite est atteinte, les enregistrements les plus anciens de cette sortie sont supprimés pour faire de la place aux nouvelles données. Lorsque l'espace disque est complètement épuisé, les enregistrements Fluent Bit ne sont pas mis en file d'attente et ils sont perdus.

Utilisez la formule suivante pour calculer le montant approprié en `storage.total_limit_size` fonction de votre taux de journalisation et de la fenêtre de restauration souhaitée :

```
If log rate is in KB/s, convert to MB/s first:
log_rate (MB/s) = log_rate (KB/s) / 1000

storage.total_limit_size (GB) = log_rate (MB/s) × duration (hours) × 3600 (seconds/hour) / 1000 (MB to GB)
```

Le tableau suivant présente des exemples de calculs pour les taux de journalisation et les fenêtres de restauration courants :


| Taux de journalisation | 1 heure | 6 heures | 12 heures | 24 heures | 
| --- | --- | --- | --- | --- | 
| 0,25 Mo/s | 0,9 GO | 5,4 GO | 10,8 GO | 21,6 GO | 
| 0,5 Mo/s | 1,8 GO | 10,8 GO | 21,6 GO | 43,2 GO | 
| 1 Mo/s | 3,6 GO | 21,6 GO | 43,2 GO | 86,4 GO | 
| 5 Mo/s | 18 GO | 108 GO | 216 GO | 432 GO | 
| 10 Mo/s | 36 GO | 216 GO | 432 GO | 864 GO | 

Pour observer le débit maximal et choisir les tailles de tampon appropriées, utilisez l'échantillon de débit de [mesure. FireLens ](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/measure-throughput)

Utilisez la formule, des exemples de calculs et des analyses comparatives pour choisir la piste la mieux adaptée `storage.total_limit_size` à une reprise optimale en cas de panne.

## Exigences relatives au stockage des tâches Amazon ECS
<a name="firelens-storage-task-requirements"></a>

Additionnez toutes les `storage.total_limit_size` valeurs des sections OUTPUT et ajoutez de la mémoire tampon pour les frais généraux. Ce total détermine l'espace de stockage nécessaire dans votre définition de tâche Amazon ECS. Par exemple, 3 sorties × 10 Go chacune = 30 Go \$1 mémoire tampon (5 à 10 Go) = 35 à 40 Go au total requis. Si le total dépasse le stockage disponible, les enregistrements Fluent Bit risquent de ne pas être mis en file d'attente et ils seront perdus.

Les options de stockage suivantes sont disponibles :

Supports Bind (stockage éphémère)  
+ Pour AWS Fargate, la valeur par défaut est de 20 Go de stockage éphémère (200 Go maximum). Configurez `ephemeralStorage` en utilisant dans la définition de la tâche. Pour plus d’informations, consultez [EphemeralStorage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-ephemeralstorage.html) dans le *Guide de l’utilisateur AWS CloudFormation *.
+ Pour EC2, la valeur par défaut est de 30 Go lorsque vous utilisez l'AMI optimisée pour Amazon ECS (partagée entre le système d'exploitation et Docker). Augmentez en modifiant la taille du volume racine.

Volumes Amazon EBS  
+ Fournit un stockage par blocs à haute disponibilité, durable et hautes performances.
+ Nécessite une configuration du volume et `mountPoint` une définition de tâche pointant vers `storage.path` (par défaut :`/var/log/flb-storage/`).
+ Pour de plus amples informations, veuillez consulter [Report de la configuration du volume au moment du lancement dans une définition de tâche Amazon ECS](specify-ebs-config.md).

Volumes Amazon EFS  
+ Permet un stockage de fichiers simple et évolutif.
+ Nécessite une configuration du volume et `mountPoint` une définition de tâche pointant vers `storage.path` (par défaut :`/var/log/flb-storage/`).
+ Pour de plus amples informations, veuillez consulter [Spécification d’un système de fichiers Amazon EFS dans une définition de tâche Amazon ECS](specify-efs-config.md).

Pour plus d'informations sur les volumes de données, consultez[Options de stockage pour les tâches Amazon ECS](using_data_volumes.md).

## Optimisation de la configuration de sortie
<a name="firelens-output-optimization"></a>

Les problèmes de réseau, les interruptions de service et la limitation des destinations peuvent empêcher la livraison des journaux. Une configuration de sortie appropriée garantit la résilience sans perte de données.

En cas d'échec d'un vidage de sortie, Fluent Bit vous pouvez réessayer l'opération. Les paramètres suivants contrôlent le comportement des nouvelles tentatives :

`retry_limit`  
Nombre maximal de tentatives après la première tentative avant de supprimer des enregistrements. La valeur par défaut est 1. Par exemple, `retry_limit 3` cela signifie 4 tentatives au total (1 tentative initiale \$1 3 tentatives). Pour les environnements de production, nous recommandons une durée de 15 minutes ou plus, ce qui couvre plusieurs minutes d'interruption avec un ralentissement exponentiel.  
Défini pour `no_limits` ou `False` pour un nombre infini de tentatives :  
+ Avec la mise en mémoire tampon, des tentatives infinies entraînent une pause du plug-in d'entrée lorsque les limites de mémoire sont atteintes.
+ Avec la mise en mémoire tampon du système de fichiers, les enregistrements les plus anciens sont supprimés lorsqu'ils `storage.total_limit_size` sont atteints.
Après avoir épuisé toutes les tentatives (1 tentative initiale et nouvelles `retry_limit` tentatives), les enregistrements sont supprimés. AWS les plugins avec `auto_retry_requests true` (par défaut) fournissent une couche de nouvelle tentative supplémentaire avant Fluent Bit le mécanisme de nouvelle tentative. Pour plus d'informations, consultez la section [Configurer les nouvelles tentatives](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-retries) dans la Fluent Bit documentation.  
Par exemple, `retry_limit 3` avec les paramètres par défaut (`scheduler.base 5`,,`net.connect_timeout 10s`)`scheduler.cap 2000`, le temps d'attente du planificateur est d'environ 70 secondes (10 s \$1 20 \$1 40 s), les délais de connexion au réseau de 40 secondes (4 tentatives × 10 s), plus de nouvelles tentatives de AWS plug-in, soit un total d'environ 2 à 10 minutes en fonction des conditions du réseau et des délais TCP du système d'exploitation.

`scheduler.base`  
Les secondes de base entre les tentatives (par défaut : 5). Nous recommandons 10 secondes.

`scheduler.cap`  
Nombre maximal de secondes entre deux tentatives (par défaut : 2000). Nous recommandons 60 secondes.

Le temps d'attente entre les nouvelles tentatives utilise un recul exponentiel associé à de l'instabilité :

```
wait_time = random(base, min(base × 2^retry_number, cap))
```

Par exemple, avec `scheduler.base 10` et `scheduler.cap 60` :
+ Première tentative : attente aléatoire comprise entre 10 et 20 secondes
+ Deuxième tentative : attente aléatoire comprise entre 10 et 40 secondes
+ Troisième tentative et versions ultérieures : attente aléatoire comprise entre 10 et 60 secondes (plafonnée)

Pour plus d'informations, consultez [Configurer le temps d'attente pour une nouvelle tentative](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-wait-time-for-retry) et [Mise en réseau](https://docs.fluentbit.io/manual/administration/networking) dans la Fluent Bit documentation.

`workers`  
Nombre de threads pour le traitement en sortie parallèle. Plusieurs opérateurs autorisent des purges simultanées, ce qui améliore le débit lors du traitement de nombreux fragments.

`auto_retry_requests`  
Un paramètre AWS spécifique au plugin qui fournit une couche de nouvelle tentative supplémentaire avant le mécanisme Fluent Bit de nouvelle tentative intégré. La valeur par défaut est `true`. Lorsqu'il est activé, le plugin AWS de sortie réessaie les demandes ayant échoué en interne avant que la demande ne soit considérée comme un échec du rinçage et soumise à la `retry_limit` configuration.

Le `Grace` paramètre de la `[SERVICE]` section définit le temps d'Fluent Bitattente pendant l'arrêt pour vider les données mises en mémoire tampon. La `Grace` période doit être coordonnée avec celle du contenant`stopTimeout`. Assurez-vous que ce délai `stopTimeout` dépasse le `Grace` délai imparti pour Fluent Bit permettre le rinçage complet avant de le recevoir. `SIGKILL` Par exemple, si elle `Grace` est de 120 secondes, définie `stopTimeout` sur 150 secondes.

L'exemple suivant montre une Fluent Bit configuration complète avec tous les paramètres recommandés pour les scénarios à haut débit :

```
[SERVICE]
    # Flush logs every 1 second
    Flush 1
    # Wait 120 seconds during shutdown to flush remaining logs
    Grace 120
    # Directory for filesystem buffering
    storage.path             /var/log/flb-storage/
    # Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
    storage.max_chunks_up    32
    # Flush backlog chunks to destinations during shutdown (prevents log loss)
    storage.backlog.flush_on_shutdown On
    # Minimum seconds between retries
    scheduler.base           10
    # Maximum seconds between retries (exponential backoff cap)
    scheduler.cap            60

[INPUT]
    Name forward
    unix_path /var/run/fluent.sock
    # Run input in separate thread to prevent blocking
    threaded true
    # Enable filesystem buffering for persistence
    storage.type filesystem

[OUTPUT]
    Name cloudwatch_logs
    Match *
    region us-west-2
    log_group_name /aws/ecs/my-app
    log_stream_name $(ecs_task_id)
    # Use multiple workers for parallel processing
    workers 2
    # Retry failed flushes up to 15 times
    retry_limit 15
    # Maximum disk space for buffered data for this output
    storage.total_limit_size 10G
```

## Comprendre les scénarios de perte de données
<a name="firelens-record-loss-scenarios"></a>

Les enregistrements peuvent être perdus lors de pannes prolongées ou de problèmes liés aux destinations de sortie. Les recommandations de configuration contenues dans ce guide constituent des approches optimales pour minimiser les pertes de données, mais ne peuvent garantir aucune perte en cas de panne prolongée. La compréhension de ces scénarios vous aide Fluent Bit à configurer pour optimiser la résilience.

Les enregistrements peuvent être perdus de deux manières : les enregistrements les plus anciens sont supprimés lorsque le stockage est plein, ou les enregistrements les plus récents sont rejetés lorsque le système ne peut pas accepter davantage de données.

### Les plus anciens records abandonnés
<a name="firelens-record-loss-oldest-dropped"></a>

Les enregistrements mis en mémoire tampon les plus anciens sont supprimés lorsque les nouvelles tentatives sont épuisées ou lorsqu'ils sont `storage.total_limit_size` pleins et doivent faire de la place pour de nouvelles données.

Limite de tentatives dépassée  
Se produit après de nouvelles tentatives du AWS plugin (if`auto_retry_requests true`) plus 1 Fluent Bit tentative initiale plus de nouvelles `retry_limit` tentatives. Pour atténuer les effets, définissez `retry_limit no_limits` chaque plugin OUTPUT pour un nombre infini de tentatives :  

```
[OUTPUT]
    Name                        cloudwatch_logs
    Match                       ApplicationLogs
    retry_limit                 no_limits
    auto_retry_requests         true
```
Un nombre indéfini de tentatives permet d'éviter de perdre des enregistrements en cas d'épuisement des tentatives, mais cela peut `storage.total_limit_size` entraîner un remplissage.

Limite de stockage atteinte (mise en mémoire tampon du système de fichiers)  
Se produit lorsque la destination de sortie n'est pas disponible plus longtemps que la mémoire tampon que `storage.total_limit_size` vous avez configurée. Par exemple, une mémoire tampon de 10 Go à un débit MB/s journalier fournit environ 2,7 heures de mise en mémoire tampon. Pour atténuer les risques, augmentez `storage.total_limit_size` le nombre de plug-ins OUTPUT et fournissez un stockage de tâches Amazon ECS adéquat :  

```
[OUTPUT]
    Name                        cloudwatch_logs
    Match                       ApplicationLogs
    storage.total_limit_size    10G
```

### Nouveaux enregistrements rejetés
<a name="firelens-record-loss-newest-rejected"></a>

Les enregistrements les plus récents sont supprimés lorsque l'espace disque est épuisé ou lorsque l'entrée est interrompue en raison de`Mem_Buf_Limit`.

Espace disque épuisé (mise en mémoire tampon du système de fichiers)  
Se produit lorsque l'espace disque est complètement épuisé. Fluent Bitne parvient pas à mettre en file d'attente les nouveaux enregistrements et ils sont perdus. Pour atténuer les risques, additionnez toutes les `storage.total_limit_size` valeurs et fournissez un stockage de tâches Amazon ECS adéquat. Pour de plus amples informations, veuillez consulter [Exigences relatives au stockage des tâches Amazon ECS](#firelens-storage-task-requirements).

Limite de mémoire atteinte (mise en mémoire tampon)  
Se produit lorsque la destination de sortie n'est pas disponible et que la mémoire tampon est pleine. Les plugins d'entrée en pause cessent d'accepter de nouveaux enregistrements. Pour atténuer, utiliser `storage.type filesystem` pour améliorer la résilience ou augmenter`Mem_Buf_Limit`.

### Bonnes pratiques pour minimiser les pertes de données
<a name="firelens-record-loss-best-practices"></a>

Tenez compte des meilleures pratiques suivantes pour minimiser les pertes de données :
+ **Utiliser la mise en mémoire tampon du système de fichiers** : configurée `storage.type filesystem` pour une meilleure résilience en cas de panne.
+ **Dimensionnez le stockage de manière appropriée** : calculez en `storage.total_limit_size` fonction du taux de journalisation et de la fenêtre de restauration souhaitée.
+ **Provisionner un disque adéquat** : assurez-vous que la tâche Amazon ECS dispose d'un espace de stockage éphémère suffisant, Amazon EBS ou Amazon EFS.
+ **Configurer le comportement des nouvelles tentatives** : équilibre entre `retry_limit` (supprime les enregistrements après avoir épuisé les tentatives) et `no_limits` (nouvelles tentatives indéfiniment mais risque de remplir l'espace de stockage).

## Utilisez la journalisation à destinations multiples pour plus de fiabilité
<a name="firelens-multi-destination"></a>

L'envoi de journaux vers plusieurs destinations élimine les points de défaillance uniques. Par exemple, en cas de panne de CloudWatch Logs, les journaux continuent d'atteindre Amazon S3.

La journalisation à destinations multiples offre les avantages suivants. Le plug-in de sortie Amazon S3 prend également en charge les options de compression telles que le format gzip et le format Parquet, qui peuvent réduire les coûts de stockage. Pour plus d'informations, consultez la section [Compression S3](https://docs.fluentbit.io/manual/pipeline/outputs/s3#compression) dans la Fluent Bit documentation.

La journalisation à destinations multiples peut offrir les avantages suivants :
+ **Redondance** : si une destination échoue, les journaux continuent d'atteindre l'autre.
+ **Rétablissement** — Reconstituer les lacunes d'un système par rapport à l'autre.
+ **Durabilité** — Archivez les journaux dans Amazon S3 pour les conserver à long terme.
+ **Optimisation des coûts** : conservez les journaux récents dans un service de requête rapide tel que les CloudWatch journaux à durée de conservation plus courte, tout en archivant tous les journaux dans un espace de stockage Amazon S3 à moindre coût pour une conservation à long terme.

La Fluent Bit configuration suivante envoie des journaux à la fois à CloudWatch Logs et à Amazon S3 :

```
[OUTPUT]
    Name cloudwatch_logs
    Match *
    region us-west-2
    log_group_name /aws/ecs/my-app
    log_stream_name $(ecs_task_id)
    workers 2
    retry_limit 15

[OUTPUT]
    Name s3
    Match *
    bucket my-logs-bucket
    region us-west-2
    total_file_size 100M
    s3_key_format /fluent-bit-logs/$(ecs_task_id)/%Y%m%d/%H/%M/$UUID
    upload_timeout 10m
    # Maximum disk space for buffered data for this output
    storage.total_limit_size 5G
```

Les deux sorties utilisent le même `Match *` schéma, de sorte que tous les enregistrements sont envoyés aux deux destinations indépendamment. En cas de panne d'une destination, les journaux continuent de circuler vers l'autre tandis que les purges échouées s'accumulent dans la mémoire tampon du système de fichiers pour une nouvelle tentative ultérieure.

## Utiliser la journalisation basée sur des fichiers avec le plugin d'entrée tail
<a name="firelens-tail-input"></a>

Pour les scénarios à haut débit dans lesquels la perte de journaux est un problème critique, vous pouvez utiliser une autre approche : demandez à votre application d'écrire des journaux dans des fichiers sur disque et de les configurer Fluent Bit pour les lire à l'aide du plug-in `tail` d'entrée. Cette approche contourne complètement la couche du pilote de journalisation Docker.

La journalisation basée sur des fichiers avec le plugin tail offre les avantages suivants :
+ **Suivi des décalages** — Le plugin tail peut stocker les décalages de fichiers dans un fichier de base de données (en utilisant l'`DB`option), garantissant ainsi une durabilité lors des Fluent Bit redémarrages. Cela permet d'éviter la perte de journal lors du redémarrage du conteneur.
+ **Mise en mémoire tampon au niveau** de l'entrée : vous pouvez configurer les limites de mémoire tampon directement sur le plug-in d'entrée`Mem_Buf_Limit`, ce qui permet de contrôler plus précisément l'utilisation de la mémoire.
+ **Évite la surcharge de Docker** : les journaux passent directement du fichier au fichier Fluent Bit sans passer par les mémoires tampon de Docker.

Pour utiliser cette approche, votre application doit écrire des journaux dans des fichiers plutôt que dans`stdout`. Le conteneur d'applications et le Fluent Bit conteneur montent tous deux un volume partagé dans lequel les fichiers journaux sont stockés.

L'exemple suivant montre une configuration d'entrée secondaire conforme aux meilleures pratiques :

```
[INPUT]
    Name tail
    # File path or glob pattern to tail
    Path /var/log/app.log
    # Database file for storing file offsets (enables resuming after restart)
    DB /var/log/flb_tail.db
    # when true, controls that only fluent-bit will access the database (improves performance)
    DB.locking true
    # Skip long lines instead of skipping the entire file
    Skip_Long_Lines On
    # How often (in seconds) to check for new files matching the glob pattern
    Refresh_Interval 10
    # Extra seconds to monitor a file after rotation to account for pending flush
    Rotate_Wait 30
    # Maximum size of the buffer for a single line
    Buffer_Max_Size 10MB
    # Initial allocation size for reading file data
    Buffer_Chunk_Size 1MB
    # Maximum memory buffer size (tail pauses when full)
    Mem_Buf_Limit 75MB
```

Lorsque vous utilisez le plugin d'entrée tail, tenez compte des points suivants :
+ Implémentez la rotation des journaux de vos applications afin d'éviter l'épuisement du disque. Surveillez les indicateurs de volume sous-jacents pour évaluer les performances.
+ Tenez compte de paramètres tels que `Ignore_Older``Read_from_Head`, et des analyseurs multilignes basés sur le format de votre journal.

Pour plus d'informations, consultez [Tail](https://docs.fluentbit.io/manual/pipeline/inputs/tail) dans la Fluent Bit documentation. Pour connaître les meilleures pratiques, consultez [la section Configuration de Tail avec les meilleures pratiques](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#tail-config-with-best-practices) dans AWS le guide de Fluent Bit dépannage.

## Connectez-vous directement à FireLens
<a name="firelens-environment-variables"></a>

Lorsque le pilote de journal `awsfirelens` est spécifié dans une définition de tâche, l'agent de conteneur Amazon ECS injecte les variables d'environnement suivantes dans le conteneur :

`FLUENT_HOST`  
Adresse IP attribuée au FireLens conteneur.  
Si vous utilisez EC2 en mode `bridge` réseau, la variable d'`FLUENT_HOST`environnement de votre conteneur d'applications peut devenir inexacte après le redémarrage du conteneur FireLens log router (le conteneur contenant l'`firelensConfiguration`objet dans sa définition de conteneur). Cela est dû au fait que `FLUENT_HOST` est une adresse IP dynamique qui peut changer après un redémarrage. La journalisation directe depuis le conteneur de l’application vers l’adresse IP `FLUENT_HOST` peut commencer à échouer après le changement d’adresse. Pour obtenir plus d’informations sur le redémarrage de conteneurs individuels, consultez la section [Redémarrage de conteneurs individuels dans les tâches Amazon ECS à l’aide de politiques de redémarrage de conteneurs](container-restart-policy.md).

`FLUENT_PORT`  
Port sur lequel le protocole Fluent Forward écoute.

Vous pouvez utiliser ces variables d'environnement pour vous connecter directement au routeur de Fluent Bit journaux à partir du code de votre application à l'aide du protocole Fluent Forward, au lieu d'écrire sur`stdout`. Cette approche contourne la couche de pilote de journalisation Docker, ce qui offre les avantages suivants :
+ **Latence réduite** : les journaux sont directement accessibles Fluent Bit sans passer par l'infrastructure de journalisation de Docker.
+ **Journalisation structurée** : envoyez des données de journal structurées de manière native sans surcharge de codage JSON.
+ **Meilleur contrôle** : votre application peut implémenter sa propre logique de mise en mémoire tampon et de gestion des erreurs.

Les bibliothèques d'enregistreurs Fluent suivantes prennent en charge le protocole Fluent Forward et peuvent être utilisées pour envoyer des journaux directement à Fluent Bit :
+ **Go** – [fluent-logger-golang](https://github.com/fluent/fluent-logger-golang)
+ **Python** : [fluent-logger-python](https://github.com/fluent/fluent-logger-python)
+ **Java** : [fluent-logger-java](https://github.com/fluent/fluent-logger-java)
+ **Node.js** : [fluent-logger-node](https://github.com/fluent/fluent-logger-node)
+ **Ruby** – [fluent-logger-ruby](https://github.com/fluent/fluent-logger-ruby)

## Configurer la limite de mémoire tampon Docker
<a name="firelens-buffer-limit"></a>

Lorsque vous créez une définition de tâche, vous pouvez spécifier le nombre de lignes de journal mises en mémoire tampon en spécifiant la valeur dans`log-driver-buffer-limit`. Cela contrôle la mémoire tampon entre Docker et. Fluent Bit Pour plus d’informations, consultez la section [Pilote de journalisation](https://docs.docker.com/engine/logging/drivers/fluentd/) dans la documentation Docker.

Utilisez cette option lorsque le débit est élevé, car Docker risque de manquer de mémoire tampon et de rejeter les messages tampons afin d'en ajouter de nouveaux.

Tenez compte des points suivants lorsque vous utilisez cette option :
+ Cette option est prise en charge sur le type de lancement Amazon EC2 et le type de lancement Fargate avec la version de plateforme `1.4.0` ou une version ultérieure.
+ L'option n'est valide que lorsque `logDriver` est défini sur `awsfirelens`.
+ La limite par défaut du tampon est de `1048576` lignes de journal.
+ La limite de mémoire tampon doit être supérieure ou égale à `0` et inférieure à `536870912` lignes de journal.
+ La quantité maximale de mémoire utilisée pour cette mémoire tampon est le produit de la taille de chaque ligne de journal par la taille de la mémoire tampon. Par exemple, si les lignes de journal de l'application sont en moyenne en `2` KiB, une limite de mémoire tampon de 4 096 utiliserait au maximum 1 `8` MiB. La quantité totale de mémoire allouée au niveau de la tâche doit être supérieure à la quantité de mémoire allouée à tous les conteneurs, en plus du tampon mémoire du pilote de journalisation.

La définition de tâche suivante indique comment configurer `log-driver-buffer-limit` :

```
{
    "containerDefinitions": [
        {
            "name": "my_service_log_router",
            "image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3",
            "cpu": 0,
            "memoryReservation": 51,
            "essential": true,
            "firelensConfiguration": {
                "type": "fluentbit"
            }
        },
        {
            "essential": true,
            "image": "public.ecr.aws/docker/library/httpd:latest",
            "name": "app",
            "logConfiguration": {
                "logDriver": "awsfirelens",
                "options": {
                    "Name": "firehose",
                    "region": "us-west-2",
                    "delivery_stream": "my-stream",
                    "log-driver-buffer-limit": "52428800"
                }
            },
            "dependsOn": [
                {
                    "containerName": "my_service_log_router",
                    "condition": "START"
                }
            ],
            "memoryReservation": 100
        }
    ]
}
```

# AWS pour les référentiels Fluent Bit d'images pour Amazon ECS
<a name="firelens-using-fluentbit"></a>

AWS fournit une Fluent Bit image avec des plugins pour CloudWatch Logs et Firehose. Nous vous recommandons d'utiliser Fluent Bit comme routeur de journal car il a un taux d'utilisation des ressources inférieur à Fluentd. Pour plus d'informations, consultez [CloudWatch Logs for Fluent Bit](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) et [Amazon Kinesis Firehose](https://github.com/aws/amazon-kinesis-firehose-for-fluent-bit) for Fluent Bit.

L'image **AWS for Fluent Bit** est disponible sur Amazon ECR à la fois dans la galerie publique Amazon ECR et dans un référentiel Amazon ECR pour une haute disponibilité.

## Galerie publique Amazon ECR
<a name="firelens-image-ecrpublic"></a>

L'Fluent Bitimage AWS pour est disponible sur la galerie publique Amazon ECR. Il s'agit de l'emplacement recommandé pour télécharger l'Fluent Bitimage AWS for, car il s'agit d'un dépôt public et peut être utilisé par tous Régions AWS. Pour plus d'informations, consultez [aws-for-fluent-bit](https://gallery.ecr.aws/aws-observability/aws-for-fluent-bit)la galerie publique Amazon ECR.

### Linux
<a name="firelens-image-ecrpublic-linux"></a>

L'Fluent Bitimage AWS for de la galerie publique Amazon ECR prend en charge le système d'exploitation Amazon Linux avec l'`x86-64`architecture `ARM64` or.

Vous pouvez extraire l'Fluent Bitimage AWS for de la galerie publique Amazon ECR en spécifiant l'URL du référentiel avec la balise d'image souhaitée. Les étiquettes d'image disponibles peuvent être trouvées sur la page **Étiquettes d'image** dans la galerie publique Amazon ECR.

L'exemple suivant montre la syntaxe à utiliser pour la CLI Docker.

```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag
```

Par exemple, vous pouvez extraire la dernière image de la famille « 3.x » de quatre Fluent Bit versions à l'aide AWS de cette commande Docker CLI.

```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3
```

**Note**  
Les extractions non authentifiées sont autorisées, mais ont une limite de débit inférieure à celle des extractions authentifiées. Pour vous authentifier à l'aide de votre AWS compte avant de le tirer, utilisez la commande suivante.  

```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```

#### AWS pour Fluent Bit 3.0.0
<a name="firelens-image-ecrpublic-linux-3.0.0"></a>

Outre les Fluent Bit versions existantes`2.x`, AWS AWS for Fluent Bit prend en charge une nouvelle version majeure`3.x`. La nouvelle version majeure inclut la mise à niveau des images d'Amazon Linux 2 vers Amazon Linux 2023 et de Fluent Bit la version `1.9.10` vers`4.1.1`. Pour plus d'informations, consultez le [Fluent Bitréférentiel AWS for](https://github.com/aws/aws-for-fluent-bit/blob/mainline/VERSIONS.md) surGitHub.

Les exemples suivants illustrent les balises mises à jour AWS pour les Fluent Bit `3.x` images :

Vous pouvez utiliser des balises multi-architectures pour l'Fluent Bitimage AWS for.

```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3
```

### Windows
<a name="firelens-image-ecrpublic-windows"></a>

L'Fluent Bitimage AWS for de la galerie publique Amazon ECR prend en charge l'`AMD64`architecture avec les systèmes d'exploitation suivants :
+ Windows Server 2022 Full
+ Windows Server 2022 Core
+ Windows Server 2019 Full
+ Windows Server 2019 Core

Les conteneurs Windows installés sur AWS Fargate ne sont pas pris en charge. FireLens

Vous pouvez extraire l'Fluent Bitimage AWS for de la galerie publique Amazon ECR en spécifiant l'URL du référentiel avec la balise d'image souhaitée. Les étiquettes d'image disponibles peuvent être trouvées sur la page **Étiquettes d'image** dans la galerie publique Amazon ECR.

L'exemple suivant montre la syntaxe à utiliser pour la CLI Docker.

```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag
```

Par exemple, vous pouvez extraire l'Fluent Bitimage stable la plus récente AWS à l'aide de cette commande Docker CLI.

```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:windowsservercore-stable
```

**Note**  
Les extractions non authentifiées sont autorisées, mais ont une limite de débit inférieure à celle des extractions authentifiées. Pour vous authentifier à l'aide de votre AWS compte avant de le tirer, utilisez la commande suivante.  

```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```

## Amazon ECR
<a name="firelens-image-ecr"></a>

L'image AWS for Fluent Bit est disponible sur Amazon ECR pour une haute disponibilité. Les commandes suivantes peuvent être utilisées pour récupérer une image URIs et établir la disponibilité de l'image dans une image donnée. Région AWS

### Linux
<a name="firelens-image-ecr-linux"></a>

La dernière version stable de AWS l'URI d'image Fluent Bit peut être récupérée à l'aide de la commande suivante.

```
aws ssm get-parameters \
      --names /aws/service/aws-for-fluent-bit/stable \
      --region us-east-1
```

Toutes les versions de l'image AWS for Fluent Bit peuvent être répertoriées à l'aide de la commande suivante pour interroger le paramètre Systems Manager Parameter Store.

```
aws ssm get-parameters-by-path \
      --path /aws/service/aws-for-fluent-bit \
      --region us-east-1
```

L'image stable la plus récente AWS pour Fluent Bit peut être référencée dans un CloudFormation modèle en faisant référence au nom du magasin de paramètres Systems Manager. Voici un exemple :

```
Parameters:
  FireLensImage:
    Description: Fluent Bit image for the FireLens Container
    Type: AWS::SSM::Parameter::Value<String>
    Default: /aws/service/aws-for-fluent-bit/stable
```

**Note**  
Si la commande échoue ou s'il n'y a aucune sortie, l'image n'est pas disponible dans le Région AWS fichier dans lequel la commande est appelée.

### Windows
<a name="firelens-image-ecr-windows"></a>

La dernière version stable de AWS l'URI d'image Fluent Bit peut être récupérée à l'aide de la commande suivante.

```
aws ssm get-parameters \
      --names /aws/service/aws-for-fluent-bit/windowsservercore-stable \
      --region us-east-1
```

Toutes les versions de l'image AWS for Fluent Bit peuvent être répertoriées à l'aide de la commande suivante pour interroger le paramètre Systems Manager Parameter Store.

```
aws ssm get-parameters-by-path \
      --path /aws/service/aws-for-fluent-bit/windowsservercore \
      --region us-east-1
```

La dernière image stable AWS pour Fluent Bit peut être référencée dans un CloudFormation modèle en faisant référence au nom du magasin de paramètres Systems Manager. Voici un exemple :

```
Parameters:
  FireLensImage:
    Description: Fluent Bit image for the FireLens Container
    Type: AWS::SSM::Parameter::Value<String>
    Default: /aws/service/aws-for-fluent-bit/windowsservercore-stable
```

# Exemple de définition de tâche Amazon ECS : acheminement des journaux vers FireLens
<a name="firelens-taskdef"></a>

Pour utiliser le routage des journaux personnalisé avec FireLens, vous devez spécifier les éléments suivants dans votre définition de tâche :
+ Conteneur de routeur journal contenant une configuration FireLens. Nous recommandons que le conteneur soit marqué comme `essential`.
+ Un ou plusieurs conteneurs d'application contenant une configuration de journal spécifiant le pilote de journal `awsfirelens`.
+ Un rôle IAM de tâche Amazon Resource Name (ARN) qui contient les autorisations nécessaires à la tâche pour acheminer les journaux.

Lorsque vous créez une nouvelle définition de tâche à l'aide de AWS Management Console, il existe une section FireLens d'intégration qui facilite l'ajout d'un conteneur de routeurs de journaux. Pour de plus amples informations, veuillez consulter [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md).

Amazon ECS convertit la configuration du journal et génère la configuration de sortie Fluentd ou Fluent Bit. La configuration de sortie est montée dans le conteneur de routage des journaux à `/fluent-bit/etc/fluent-bit.conf` pour Fluent Bit et `/fluentd/etc/fluent.conf` pour Fluentd.

**Important**  
FireLens écoute sur le port `24224`. Par conséquent, pour garantir que le routeur de FireLens journaux n'est pas accessible en dehors de la tâche, vous ne devez pas autoriser le trafic entrant sur le port `24224` du groupe de sécurité utilisé par votre tâche. Pour les tâches utilisant le mode réseau `awsvpc`, il s'agit du groupe de sécurité associé à la tâche. Pour les tâches utilisant le mode réseau `host`, il s'agit du groupe de sécurité associé à l'instance Amazon EC2 qui héberge la tâche. Pour les tâches utilisant le mode réseau `bridge`, ne créez pas de mappages de ports utilisant le port `24224`.

Par défaut, Amazon ECS ajoute des champs supplémentaires dans vos entrées de journal qui aident à identifier la source des journaux. 
+ `ecs_cluster` : nom du cluster dont la tâche fait partie.
+ `ecs_task_arn` : Amazon Resource Name (ARN) de la tâche dont le conteneur fait partie.
+ `ecs_task_definition` : nom et révision de la définition de tâche que la tâche utilise.
+ `ec2_instance_id` : ID de l'instance Amazon EC2 sur laquelle le conteneur est hébergé. Ce champ est uniquement valide pour les tâches qui utilisent le type de lancement EC2.

Vous pouvez définir `enable-ecs-log-metadata` sur `false` si vous ne souhaitez pas les métadonnées.

L'exemple de définition de tâche suivant définit un conteneur de routeur de journaux qui utilise Fluent Bit pour acheminer ses CloudWatch journaux vers Logs. Il définit également un conteneur d’application qui utilise une configuration de journal pour acheminer les journaux vers Amazon Data Firehose et définit la mémoire utilisée pour mettre en mémoire tampon les événements à 2 Mio.

**Note**  
Pour plus d'exemples de définitions de tâches, consultez [les FireLens exemples d'Amazon ECS](https://github.com/aws-samples/amazon-ecs-firelens-examples) sur GitHub.

```
{
  "family": "firelens-example-firehose",
  "taskRoleArn": "arn:aws:iam::123456789012:role/ecs_task_iam_role",
  "containerDefinitions": [
    {
            "name": "log_router",
            "image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3",
            "cpu": 0,
            "memoryReservation": 51,
            "portMappings": [],
            "essential": true,
            "environment": [],
            "mountPoints": [],
            "volumesFrom": [],
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-group": "/ecs/ecs-aws-firelens-sidecar-container",
                    "mode": "non-blocking",
                    "awslogs-create-group": "true",
                    "max-buffer-size": "25m",
                    "awslogs-region": "us-east-1",
                    "awslogs-stream-prefix": "firelens"
                },
                "secretOptions": []
            },
            "systemControls": [],
            "firelensConfiguration": {
                "type": "fluentbit"
            }
        },
    {
      "essential": true,
      "image": "public.ecr.aws/docker/library/httpd:latest",
      "name": "app",
      "logConfiguration": {
        "logDriver": "awsfirelens",
        "options": {
          "Name": "firehose",
          "region": "us-west-2",
          "delivery_stream": "my-stream",
          "log-driver-buffer-limit": "1048576"
        }
      },
      "memoryReservation": 100
    }
  ]
}
```

Les paires clés/valeurs spécifiées en tant qu'options dans l'objet `logConfiguration` sont utilisées pour générer la configuration de sortie Fluentd ou Fluent Bit. Voici un exemple de code à partir d'une définition de sortie Fluent Bit.

```
[OUTPUT]
    Name   firehose
    Match  app-firelens*
    region us-west-2
    delivery_stream my-stream
```

**Note**  
FireLens gère la `match` configuration. Vous ne spécifiez pas la configuration `match` dans votre définition de tâche. 

## Utilisation d’un fichier de configuration
<a name="firelens-taskdef-customconfig"></a>

Vous pouvez spécifier un fichier de configuration personnalisé. Le format du fichier de configuration est le format natif du routeur de journal que vous utilisez. Pour plus d’informations, consultez les sections [Syntaxe du fichier de configuration Fluentd](https://docs.fluentd.org/configuration/config-file) et [Fichier de configuration YAML](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/yaml).

Dans votre fichier de configuration personnalisé, pour les tâches utilisant le mode réseau `bridge` ou `awsvpc`, ne définissez pas d'entrée de transfert Fluentd ou Fluent Bit sur TCP, car FireLens l'ajoute à la configuration d'entrée.

Votre configuration FireLens doit contenir les options suivantes pour spécifier un fichier de configuration personnalisé :

`config-file-type`  
Emplacement source du fichier de configuration personnalisé. Les options disponibles sont `s3` ou `file`.  
Les tâches hébergées sur AWS Fargate ne prennent en charge que le type `file` de fichier de configuration. Toutefois, vous pouvez utiliser les fichiers de configuration hébergés dans Amazon S3 sur AWS Fargate en utilisant AWS le Fluent Bit conteneur for init. Pour plus d'informations, voir [Processus d'initialisation pour Fluent Bit sur ECS, support multi-configurations activé](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md). GitHub

`config-file-value`  
Source du fichier de configuration personnalisé. Si le type de fichier de configuration `s3` est utilisé, la valeur du fichier de configuration est l'ARN complet du compartiment Amazon S3 et du fichier. Si le type de fichier de configuration `file` est utilisé, la valeur du fichier de configuration est le chemin d'accès complet du fichier de configuration qui existe soit dans l'image du conteneur, soit sur un volume monté dans le conteneur.  
Lorsque vous utilisez un fichier de configuration personnalisé, vous devez spécifier un chemin différent de celui utilisé par FireLens. Amazon ECS réserve les chemins de fichier `/fluent-bit/etc/fluent-bit.conf` pour Fluent Bit et `/fluentd/etc/fluent.conf` pour Fluentd.

L'exemple suivant montre la syntaxe requise lors de la spécification d'une configuration personnalisée.

**Important**  
Pour spécifier un fichier de configuration personnalisé hébergé dans Amazon S3, vérifiez que vous avez créé un rôle IAM d'exécution de tâche avec les autorisations appropriées. 

Voici la syntaxe requise lors de la spécification d'une configuration personnalisée.

```
{
  "containerDefinitions": [
    {
      "essential": true,
      "image": "906394416424.dkr.ecr.us-west-2.amazonaws.com/aws-for-fluent-bit:3",
      "name": "log_router",
      "firelensConfiguration": {
        "type": "fluentbit",
        "options": {
          "config-file-type": "s3 | file",
          "config-file-value": "arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf | filepath"
        }
      }
    }
  ]
}
```

**Note**  
Les tâches hébergées sur AWS Fargate ne prennent en charge que le type `file` de fichier de configuration. Toutefois, vous pouvez utiliser les fichiers de configuration hébergés dans Amazon S3 sur AWS Fargate en utilisant AWS le Fluent Bit conteneur for init. Pour plus d'informations, voir [Processus d'initialisation pour Fluent Bit sur ECS, support multi-configurations activé](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md). GitHub

# Utilisation d'images autres que des AWS conteneurs dans Amazon ECS
<a name="private-auth"></a>

Utilisez le registre privé pour stocker vos informations d'identification AWS Secrets Manager, puis référencez-les dans votre définition de tâche. Cela permet de référencer des images de conteneurs qui existent dans des registres privés en dehors de ceux AWS qui nécessitent une authentification dans vos définitions de tâches. Cette fonction est prise en charge par les tâches hébergées sur Fargate, les instances Amazon EC2 et les instances externes utilisant Amazon ECS Anywhere.

**Important**  
Si votre définition de tâche fait référence à une image stockée dans Amazon ECR, cette rubrique ne s'applique pas. Pour plus d'informations, consultez [Utilisation d'images Amazon ECR avec Amazon ECS](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) dans le *Guide de l'utilisateur Amazon Elastic Container Registry*.

Pour les tâches hébergées sur des instances Amazon EC2, cette fonction exige nécessite la version `1.19.0` ou ultérieure de l'agent de conteneur. Toutefois, nous vous recommandons d'utiliser la dernière version de l'agent de conteneur. Pour plus d'informations sur la vérification de la version de votre agent et la mise à jour à la dernière version, consultez [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md).

Pour les tâches hébergées sur Fargate, cette fonction nécessite une version `1.2.0` de la plateforme ou une version ultérieure. Pour plus d'informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md).

Dans votre définition du conteneur, spécifiez l'objet `repositoryCredentials` avec les détails du secret que vous avez créé. Le secret référencé peut provenir d'un compte différent Région AWS ou différent de celui de la tâche qui l'utilise.

**Note**  
Lorsque vous utilisez l'API ou le AWS SDK Amazon ECS, si le secret existe dans la même tâche Région AWS que la tâche que vous lancez, vous pouvez utiliser l'ARN complet ou le nom du secret. AWS CLI Si le secret existe dans un autre compte, l'ARN complet du secret doit être spécifié. Lorsque vous utilisez le AWS Management Console, l'ARN complet du secret doit toujours être spécifié.

Voici un extrait de code d'une définition de tâche indiquant les paramètres requis :

Remplacez les paramètres suivants :
+ *private-repo*avec le nom d'hôte du dépôt privé 
+ *private-image*avec le nom de l'image
+ *arn:aws:secretsmanager:region:aws\$1account\$1id:secret:secret\$1name*avec le nom secret Amazon Resource Name (ARN)

```
"containerDefinitions": [
    {
        "image": "private-repo/private-image",
        "repositoryCredentials": {
            "credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name"
        }
    }
]
```

**Note**  
Une autre méthode d'activation de l'authentification de registre privé utilise des variables d'environnement d'agent de conteneur Amazon ECS pour s'authentifier auprès de registres privés. Cette méthode est prise en charge uniquement pour les tâches hébergées sur des instances Amazon EC2. Pour de plus amples informations, veuillez consulter [Configuration des instances de conteneur Amazon ECS pour les images Docker privées](private-auth-container-instances.md).

**Pour utiliser un registre privé**

1. La définition de tâche doit comporter un rôle d’exécution de tâche. Cela permet à l'agent de conteneur d'extraire l'image de conteneur. Pour de plus amples informations, veuillez consulter [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md).

   L'authentification par registre privé permet à vos tâches Amazon ECS d'extraire des images de conteneurs depuis des registres privés extérieurs AWS (tels que Docker Hub, Quay.io ou votre propre registre privé) qui nécessitent des informations d'authentification. Cette fonctionnalité utilise Secrets Manager pour stocker en toute sécurité vos informations d’identification de registre, qui sont ensuite référencées dans votre définition de tâche à l’aide du paramètre `repositoryCredentials`.

   Pour plus d'informations sur la configuration de l'authentification du registre privé, consultez [Utilisation d'images non AWS conteneurisées dans Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html).

   Pour donner accès aux secrets contenant vos informations d’identification du registre privé, ajoutez les autorisations suivantes en tant que politique intégrée au rôle d’exécution des tâches. Pour plus d'informations, consultez [Ajout et suppression de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
   + `secretsmanager:GetSecretValue` : nécessaire pour récupérer les informations d’identification du registre privé auprès de Secrets Manager.
   + `kms:Decrypt`  : obligatoire uniquement si votre secret utilise une clé KMS personnalisée et non la clé par défaut. L'Amazon Resource Name (ARN) de votre clé personnalisée doit être ajouté en tant que ressource.

   Voici un exemple de stratégie en ligne qui ajoute les autorisations.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "kms:Decrypt",
                   "secretsmanager:GetSecretValue"
               ],
               "Resource": [
                   "arn:aws:secretsmanager:us-east-1:111122223333:secret:secret_name",
                   "arn:aws:kms:us-east-1:111122223333:key/key_id"
               ]
           }
       ]
   }
   ```

------

1.  AWS Secrets Manager À utiliser pour créer un secret pour vos informations d'identification de registre privées. Pour plus d’informations sur la création d’un secret, consultez la section [Création d’un secret AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) dans le *Guide de l’utilisateur AWS Secrets Manager *.

   Saisissez vos informations d’identification de registre privé en utilisant le format suivant :

   ```
   {
     "username" : "privateRegistryUsername",
     "password" : "privateRegistryPassword"
   }
   ```

1. Enregistrer une définition de tâche. Pour de plus amples informations, veuillez consulter [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md).

# Redémarrage de conteneurs individuels dans les tâches Amazon ECS à l’aide de politiques de redémarrage de conteneurs
<a name="container-restart-policy"></a>

Vous pouvez activer une politique de redémarrage pour chaque conteneur essentiel et non essentiel défini dans votre définition de tâche, afin de surmonter plus rapidement les défaillances transitoires et de maintenir la disponibilité des tâches. Lorsque vous activez une politique de redémarrage pour un conteneur, Amazon ECS peut redémarrer le conteneur s’il existe, sans avoir à remplacer la tâche.

Les politiques de redémarrage ne sont pas activées par défaut pour les conteneurs. Lorsque vous activez une politique de redémarrage pour un conteneur, vous pouvez spécifier les codes de sortie pour lesquels le conteneur ne sera pas redémarré. Il peut s’agir de codes de sortie indiquant le succès, tels que des codes de sortie `0`, qui ne nécessitent pas de redémarrage. Vous pouvez également spécifier la durée pendant laquelle un conteneur doit fonctionner correctement avant qu’un redémarrage puisse être tenté. Pour obtenir plus d’informations sur ces paramètres, consultez [Politique de redémarrage](task_definition_parameters.md#container_definition_restart_policy). Pour un exemple de définition de tâche qui spécifie ces valeurs, consultez la section [Spécification d’une politique de redémarrage de conteneur dans une définition de tâche Amazon ECS](container-restart-policy-example.md).

Vous pouvez utiliser le point de terminaison des métadonnées des tâches Amazon ECS ou CloudWatch Container Insights pour surveiller le nombre de redémarrages d'un conteneur. Pour plus d’informations sur le point de terminaison des métadonnées de tâche, consultez les sections [Point de terminaison des métadonnées de tâches Amazon ECS version 4](task-metadata-endpoint-v4.md) et [Point de terminaison des métadonnées de tâches Amazon ECS version 4 pour les tâches sur Fargate](task-metadata-endpoint-v4-fargate.md). Pour plus d'informations sur les métriques Container Insights pour Amazon ECS, consultez les [métriques Amazon ECS Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html) dans le *guide de CloudWatch l'utilisateur Amazon*.

Les politiques de redémarrage des conteneurs sont prises en charge par les tâches hébergées sur Fargate, les instances Amazon EC2 et les instances externes utilisant Amazon ECS Anywhere.

## Considérations
<a name="container-restart-policy-considerations"></a>

Tenez compte des points suivants avant d’activer une politique de redémarrage pour votre conteneur :
+ Les politiques de redémarrage ne sont pas prises en charge pour les conteneurs Windows sur Fargate.
+ Pour les tâches hébergées sur des instances Amazon EC2, cette fonction exige nécessite la version `1.86.0` ou ultérieure de l'agent de conteneur. Toutefois, nous vous recommandons d'utiliser la dernière version de l'agent de conteneur. Pour plus d'informations sur la vérification de la version de votre agent et la mise à jour à la dernière version, consultez [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md).
+ Si vous utilisez EC2 en mode `bridge` réseau, la variable d'`FLUENT_HOST`environnement de votre conteneur d'applications peut devenir inexacte après le redémarrage du conteneur FireLens log router (le conteneur contenant l'`firelensConfiguration`objet dans sa définition de conteneur). Cela est dû au fait que `FLUENT_HOST` est une adresse IP dynamique qui peut changer après un redémarrage. La journalisation directe depuis le conteneur de l’application vers l’adresse IP `FLUENT_HOST` peut commencer à échouer après le changement d’adresse. Pour plus d’informations sur `FLUENT_HOST`, consultez [Configuration des journaux Amazon ECS pour un débit élevé](firelens-docker-buffer-limit.md).
+ L’agent Amazon ECS gère les politiques de redémarrage des conteneurs. Si, pour une raison inattendue, l’agent Amazon ECS échoue ou ne fonctionne plus, le conteneur ne sera pas redémarré.
+  La période de tentative de redémarrage définie dans votre politique détermine la période (en secondes) pendant laquelle le conteneur doit fonctionner avant qu’Amazon ECS ne redémarre un conteneur.

# Spécification d’une politique de redémarrage de conteneur dans une définition de tâche Amazon ECS
<a name="container-restart-policy-example"></a>

Pour spécifier une politique de redémarrage pour un conteneur dans une définition de tâche, dans la définition du conteneur, spécifiez l’objet `restartPolicy`. Pour plus d’informations sur l’objet `restartPolicy`, consultez la section [Politique de redémarrage](task_definition_parameters.md#container_definition_restart_policy).

Ce qui suit est une définition de tâche utilisant les conteneurs Linux sur Fargate qui configure un serveur Web. La définition du conteneur inclut l’objet `restartPolicy`, avec `enabled` défini sur true pour activer une politique de redémarrage pour le conteneur. Le conteneur doit fonctionner pendant 180 secondes avant de pouvoir être redémarré et ne sera pas redémarré s’il se ferme avec le code de sortie `0`, qui indique un succès.

```
{
  "containerDefinitions": [
    {
      "command": [
        "/bin/sh -c \"echo '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>' >  /usr/local/apache2/htdocs/index.html && httpd-foreground\""
      ],
      "entryPoint": ["sh", "-c"],
      "essential": true,
      "image": "public.ecr.aws/docker/library/httpd:2.4",
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/fargate-task-definition",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      },
      "name": "sample-fargate-app",
      "portMappings": [
        {
          "containerPort": 80,
          "hostPort": 80,
          "protocol": "tcp"
        }
      ],
      "restartPolicy": {
        "enabled": true,
        "ignoredExitCodes": [0],
        "restartAttemptPeriod": 180
      }
    }
  ],
  "cpu": "256",
  "executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole",
  "family": "fargate-task-definition",
  "memory": "512",
  "networkMode": "awsvpc",
  "runtimePlatform": {
    "operatingSystemFamily": "LINUX"
  },
  "requiresCompatibilities": ["FARGATE"]
}
```

Après avoir enregistré une définition de tâche avec l’objet `restartPolicy` dans une définition de conteneur, vous pouvez exécuter une tâche ou créer un service avec cette définition de tâche. Pour plus d’informations, consultez [Exécution d’une application en tant que tâche Amazon ECS](standalone-task-create.md) et [Création d’un déploiement de mise à jour propagée Amazon ECS](create-service-console-v2.md).

# Transmission de données sensibles vers un conteneur Amazon ECS
<a name="specifying-sensitive-data"></a>

Vous pouvez transmettre en toute sécurité des données sensibles, telles que des informations d'identification vers une base de données, dans votre conteneur. 

Les secrets, tels que les clés d'API et les informations d'identification de base de données, sont fréquemment utilisés par les applications pour accéder à d'autres systèmes. Ils se composent souvent d'un nom d'utilisateur et d'un mot de passe, d'un certificat ou d'une clé d'API. L'accès à ces secrets doit être limité à des principaux IAM spécifiques qui utilisent IAM et injectés dans des conteneurs lors de l'exécution.

Les secrets peuvent être injectés facilement dans des conteneurs à partir AWS Secrets Manager d'Amazon EC2 Systems Manager Parameter Store. Ces secrets peuvent être référencés dans votre tâche de l'une des manières suivantes.

1. Ils sont référencés en tant que variables d'environnement qui utilisent le paramètre de définition du conteneur `secrets`.

1. Ils sont référencés comme `secretOptions` si votre plateforme de journalisation nécessite une authentification. Pour plus d'informations, veuillez consulter [Options de configuration de la journalisation](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html#API_LogConfiguration_Contents) (langue française non garantie).

1. Ils sont référencés comme des secrets extraits par des images qui utilisent le paramètre de définition de conteneur `repositoryCredentials` si le registre d'où le conteneur est extrait nécessite une authentification. Utilisez cette méthode lors de l'extraction d'images depuis la Galerie publique Amazon ECR. Pour plus d'informations, veuillez consulter [Authentification de registre privé pour les tâches](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html) (langue française non garantie).

Nous vous recommandons d'effectuer les opérations suivantes lorsque vous configurez la gestion des secrets.

## Utiliser AWS Secrets Manager ou AWS Systems Manager Parameter Store pour stocker des documents secrets
<a name="security-secrets-management-recommendations-storing-secret-materials"></a>

Vous devez stocker en toute sécurité les clés d’API, les informations d’identification de base de données et les autres éléments secrets dans Secrets Manager ou sous forme de paramètre chiffré dans le magasin de paramètres Systems Manager. Ces services sont similaires car il s'agit tous deux de magasins de valeurs clés gérés utilisés AWS KMS pour chiffrer des données sensibles. Secrets Manager, cependant, inclut également la possibilité de faire pivoter automatiquement les secrets, de générer des secrets aléatoires et de partager des secrets entre les comptes. Pour utiliser ces fonctionnalités, utilisez Secrets Manager. Sinon, utilisez des paramètres chiffrés dans le magasin de paramètres Systems Manager.

**Important**  
Si votre secret change, vous devez forcer un nouveau déploiement ou lancer une nouvelle tâche pour récupérer la dernière valeur secrète. Pour plus d’informations, consultez les rubriques suivantes :  
Tâches : arrêtez la tâche, puis démarrez-la. Pour plus d’informations, consultez [Arrêt d’une tâche Amazon ECS](standalone-task-stop.md) et [Exécution d’une application en tant que tâche Amazon ECS](standalone-task-create.md).
Service : mettez à jour le service et utilisez l’option « Forcer un nouveau déploiement ». Pour de plus amples informations, veuillez consulter [Mettre à jour un service Amazon ECS](update-service-console-v2.md).

## Récupération des données d’un compartiment Amazon S3 chiffré
<a name="security-secrets-management-recommendations-encrypted-s3-buckets"></a>

Vous devez stocker les secrets dans un compartiment chiffré Amazon S3 et utiliser des rôles de tâche pour restreindre l’accès à ces secrets. Cela empêche les valeurs des variables d’environnement de s’échapper par inadvertance dans les journaux et d’être révélées lors de l’exécution de `docker inspect`. Dans ce cas, votre application doit être écrite pour lire le secret du compartiment Amazon S3. Pour obtenir des instructions, veuillez consulter [Définition du comportement de chiffrement côté serveur par défaut pour les compartiments Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-encryption.html).

## Montez le secret sur un volume à l'aide d'un conteneur sidecar
<a name="security-secrets-management-recommendations-mount-secret-volumes"></a>

Comme le risque de fuite de données lié aux variables d'environnement est élevé, vous devez utiliser un conteneur annexe qui lit vos secrets AWS Secrets Manager et les écrit sur un volume partagé. Ce conteneur peut s'exécuter et sortir avant le conteneur d'applications en utilisant le système de [commande de conteneurs Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html). Ainsi, le conteneur de l'application monte ensuite le volume dans lequel le secret a été écrit. À l'instar de la méthode du compartiment Amazon S3, votre application doit être écrite pour lire le secret du volume partagé. Le volume étant limité à la tâche, il est automatiquement supprimé après l'arrêt de la tâche. Pour un exemple, consultez le projet [task-def.json](https://github.com/aws-samples/aws-secret-sidecar-injector/blob/master/ecs-task-def/task-def.json).

Sur Amazon EC2, le volume sur lequel le secret est écrit peut être chiffré à l'aide d'une clé AWS KMS gérée par le client. Activé AWS Fargate, le stockage en volume est automatiquement chiffré à l'aide d'une clé gérée par le service. 

# Transmission d’une variable d’environnement individuelle à un conteneur Amazon ECS
<a name="taskdef-envfiles"></a>

**Important**  
Nous vous recommandons de stocker vos données sensibles dans des AWS Secrets Manager secrets ou dans des paramètres AWS Systems Manager Parameter Store. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur Amazon ECS](specifying-sensitive-data.md).  
Les variables d'environnement spécifiées dans la définition de tâche sont lisibles par tous les utilisateurs et rôles autorisés à effectuer l'action `DescribeTaskDefinition` pour la définition de tâche.

Vous pouvez transmettre des variables d'environnement à vos conteneurs des manières suivantes :
+ Individuellement à l'aide du paramètre de définition de conteneur `environment`. Cela correspond à l'option `--env` de [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/).
+ En bloc, en utilisant le paramètre de définition de conteneur `environmentFiles` pour répertorier un ou plusieurs fichiers contenant les variables d'environnement. Le fichier doit être hébergé dans Amazon S3. Cela correspond à l'option `--env-file` de [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/).

Voici un extrait d'une définition de tâche montrant comment spécifier des variables d'environnement individuelles.

```
{
    "family": "",
    "containerDefinitions": [
        {
            "name": "",
            "image": "",
            ...
            "environment": [
                {
                    "name": "variable",
                    "value": "value"
                }
            ],
            ...
        }
    ],
    ...
}
```

# Transmission de variables d’environnement à un conteneur Amazon ECS
<a name="use-environment-file"></a>

**Important**  
Nous vous recommandons de stocker vos données sensibles dans des AWS Secrets Manager secrets ou dans des paramètres AWS Systems Manager Parameter Store. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur Amazon ECS](specifying-sensitive-data.md).  
Les fichiers de variables d'environnement sont des objets dans Simple Storage Service (Amazon S3) et toutes les considérations de sécurité Simple Storage Service (Amazon S3) s'appliquent.   
Vous ne pouvez pas utiliser le paramètre `environmentFiles` sur les conteneurs Windows et les conteneurs Windows sur Fargate.

Vous pouvez créer un fichier de variables d’environnement et le stocker dans Amazon S3 pour transmettre des variables d’environnement à votre conteneur.

En spécifiant des variables d'environnement dans un fichier, vous pouvez injecter en bloc des variables d'environnement. Dans votre définition de conteneur, spécifiez l'objet `environmentFiles` avec une liste de compartiments Amazon S3 contenant vos fichiers de variables d'environnement.

Amazon ECS n’impose pas de limite de taille pour les variables d’environnement, mais un fichier de variables d’environnement volumineux peut saturer l’espace disque. Chaque tâche qui utilise un fichier de variables d'environnement entraîne le téléchargement d'une copie du fichier sur le disque. Amazon ECS supprime le fichier dans le cadre du nettoyage des tâches.

Pour plus d'informations sur les variables d'environnement prises en charge, veuillez consulter [Paramètres de définition de conteneur avancés - Environnement](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_environment).

Tenez compte des éléments suivants lors de la spécification d'un fichier de variable d'environnement dans une définition de conteneur.
+ Pour toute tâche Amazon ECS hébergé sur Amazon EC2, vos instances de conteneur nécessitent une version `1.39.0` ou ultérieure de l'agent de conteneur pour utiliser cette fonction. Pour plus d'informations sur la vérification de la version de votre agent et la mise à jour à la dernière version, consultez [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md).
+ Pour les tâches Amazon ECS sur AWS Fargate, vos tâches doivent utiliser la version de plate-forme ou une `1.4.0` version ultérieure (Linux) pour utiliser cette fonctionnalité. Pour de plus amples informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md).

  Vérifiez que la variable est prise en charge par la plateforme du système d'exploitation. Pour plus d’informations, consultez [Définitions de conteneur](task_definition_parameters.md#container_definitions) et [Autres paramètres de définition de tâche](task_definition_parameters.md#other_task_definition_params).
+ Le fichier doit utiliser l'extension de fichier `.env` et l'encodage UTF-8.
+ Le rôle d’exécution de tâche est requis pour utiliser cette fonctionnalité avec les autorisations supplémentaires pour Amazon S3. Cela permet à l'agent de conteneur d'extraire le fichier de variable d'environnement à partir d'Amazon S3. Pour de plus amples informations, veuillez consulter [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md).
+ Il y a une limite de 10 fichiers par définition de tâche.
+ Chaque ligne d'un fichier d'environnement doit contenir une variable d'environnement au format `VARIABLE=VALUE`. Des espaces ou des guillemets **sont** inclus dans les valeurs pour les fichiers Amazon ECS. Les lignes commençant par `#` sont traitées comme des commentaires et sont ignorées. Pour de plus amples informations sur la syntaxe du fichier de variable d’environnement, consultez la section [Définition des variables d’environnement (-e, --env, --env-file)](https://docs.docker.com/reference/cli/docker/container/run/#env) dans la documentation Docker.

  Voici la syntaxe appropriée.

  ```
  #This is a comment and will be ignored
  VARIABLE=VALUE
  ENVIRONMENT=PRODUCTION
  ```
+ Si des variables d'environnement sont spécifiées à l'aide du paramètre `environment` dans une définition de conteneur, elles ont priorité sur les variables contenues dans un fichier d'environnement.
+ Si plusieurs fichiers d'environnement contenant la même variable sont spécifiés, ils sont traités par ordre d'entrée. Cela signifie que la première valeur de la variable est utilisée et que les valeurs suivantes des variables dupliquées sont ignorées. Nous vous recommandons d'utiliser des noms de variables uniques.
+ Si un fichier d'environnement est spécifié en tant que remplacement de conteneur, il est utilisé. De plus, tous les autres fichiers d'environnement spécifiés dans la définition du conteneur sont ignorés.
+ Les règles suivantes s’appliquent à Fargate :
  + Le fichier est traité de manière similaire à un fichier env Docker natif.
  + Les définitions de conteneur qui font référence à des variables d’environnement vides et stockées dans Amazon S3 n’apparaissent pas dans le conteneur.
  + La gestion de l'échappement dans shell n'est pas prise en charge.
  + Le point d'entrée du conteneur interprète les valeurs `VARIABLE`.

## Exemple
<a name="environment-file-example"></a>

Voici un extrait d'une définition de tâche indiquant comment spécifier un fichier de variable d'environnement.

```
{
    "family": "",
    "containerDefinitions": [
        {
            "name": "",
            "image": "",
            ...
            "environmentFiles": [
                {
                    "value": "arn:aws:s3:::amzn-s3-demo-bucket/envfile_object_name.env",
                    "type": "s3"
                }
            ],
            ...
        }
    ],
    ...
}
```

# Transmission des secrets Secrets Manager par programmation dans Amazon ECS
<a name="secrets-app-secrets-manager"></a>

Au lieu de coder en dur les informations sensibles en texte brut dans votre application, vous pouvez utiliser Secrets Manager pour stocker les données sensibles.

Nous recommandons cette méthode pour récupérer les données sensibles, car si le secret de Secrets Manager est ultérieurement mis à jour, l'application récupère automatiquement la dernière version de celui-ci.

Créez un secret dans Secrets Manager. Après avoir créé un secret dans Secrets Manager, mettez à jour le code de votre application pour récupérer le secret.

Prenez en compte les points suivants avant de sécuriser des données sensibles dans Secrets Manager.
+ Seuls les secrets qui stockent des données texte, qui sont des secrets créés avec le `SecretString` paramètre de l'[CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html)API, sont pris en charge. Les secrets qui stockent des données binaires, qui sont des secrets créés avec le `SecretBinary` paramètre de l'[CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html)API, ne sont pas pris en charge.
+ Utilisez les points de terminaison VPC de l'interface pour améliorer les contrôles de sécurité. Vous devez créer les points de terminaison d'un VPC pour Secrets Manager. Pour plus d'informations sur le point de terminaison d'un VPC, veuillez consulter [Créer des points de terminaison d'un VPC](https://docs.aws.amazon.com/secretsmanager/latest/userguide/setup-create-vpc.html) dans le *Guide de l'utilisateur AWS Secrets Manager *.
+ Le VPC que votre tâche utilise doit utiliser la résolution DNS.
+ Votre définition de tâche doit utiliser un rôle de tâche doté des autorisations supplémentaires pour Secrets Manager. Pour de plus amples informations, veuillez consulter [rôle IAM de tâche Amazon ECS](task-iam-roles.md).

## Créer le secret Secrets Manager
<a name="secrets-app-secrets-manager-create-secret"></a>

Vous pouvez utiliser la console Secrets Manager afin de créer un secret pour vos données sensibles. Pour plus d'informations sur la création de secrets, consultez la rubrique [Création d'un secret AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) dans le *Guide de l'utilisateur AWS Secrets Manager *.

## Mettez à jour votre application pour récupérer le secret Secrets Manager par programme
<a name="secrets-app-secrets-manager-update-app"></a>

Vous pouvez récupérer des secrets en appelant le Secrets Manager APIs directement depuis votre application. Pour plus d’informations, consultez la section [Récupérer les secrets depuis AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) dans le *Guide de l’utilisateur AWS Secrets Manager *.

Pour récupérer les données sensibles stockées dans le AWS Secrets Manager, consultez les [exemples de code à AWS Secrets Manager utiliser AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/secrets-manager_code_examples.html) dans la *bibliothèque de codes d'exemples de code du AWS SDK*.

# Transmission des secrets du magasin de paramètres Systems Manager par programmation dans Amazon ECS
<a name="secrets-app-ssm-paramstore"></a>

Systems Manager Parameter Store offre un stockage et une gestion sécurisés des secrets. Vous pouvez stocker des données telles que les mots de passe, les chaînes de base de données, l'instance EC2 IDs et l'AMI IDs, ainsi que les codes de licence sous forme de valeurs de paramètres, au lieu de coder ces informations en dur dans votre application. Vous pouvez stocker ces valeurs sous forme de texte brut ou de données chiffrées.

Nous recommandons cette méthode de récupération des données sensibles, car si le magasin de paramètres Systems Manager est mis à jour ultérieurement, l’application récupère automatiquement la dernière version.

Prenez en compte les points suivants avant de sécuriser des données sensibles dans Systems Manager Parameter Store.
+ Seuls les secrets qui stockent des données texte sont pris en charge. Les secrets qui stockent des données binaires ne sont pas pris en charge.
+ Utilisez les points de terminaison d’un VPC de l'interface pour améliorer les contrôles de sécurité.
+ Le VPC que votre tâche utilise doit utiliser la résolution DNS.
+ Pour les tâches qui utilisent EC2, vous devez utiliser la variable de configuration `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true` de l’agent ECS pour utiliser cette fonctionnalité. Vous pouvez l'ajouter au fichier `/etc/ecs/ecs.config` lors de la création de l'instance de conteneur, ou vous pouvez l'ajouter à une instance existante, puis redémarrer l'agent ECS. Pour de plus amples informations, veuillez consulter [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md).
+ Votre définition de tâche doit utiliser un rôle de tâche doté des autorisations supplémentaires pour le magasin de paramètres Systems Manager. Pour de plus amples informations, veuillez consulter [rôle IAM de tâche Amazon ECS](task-iam-roles.md).

## Créer le paramètre
<a name="secrets-app-ssm-paramstore-create-secret"></a>

Vous pouvez utiliser la console System Manager pour créer un paramètre Systems Manager Parameter Store pour vos données sensibles. Pour plus d'informations, consultez [Créer un paramètre Systems Manager (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) ou [Créer un paramètre Systems Manager (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html) dans le *Guide de l'utilisateur AWS Systems Manager *.

## Mettez à jour votre application pour récupérer par programme les secrets Systems Manager Parameter Store.
<a name="secrets-app-ssm-paramstore-update-app"></a>

Pour récupérer les données sensibles stockées dans le paramètre Systems Manager Parameter Store, consultez les [exemples de code à utiliser par Systems Manager AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/ssm_code_examples.html) dans la *bibliothèque de codes d'exemples de code du AWS SDK*.

# Transmission des secrets Secrets Manager via les variables d’environnement Amazon ECS
<a name="secrets-envvar-secrets-manager"></a>

Lorsque vous injectez un secret en tant que variable d’environnement, vous pouvez spécifier le contenu complet d’un secret ou une clé JSON spécifique au sein d’un secret. Cela vous aide à contrôler les données sensibles exposées à votre conteneur. Pour plus d’informations sur la gestion des versions de secrets, consultez la section [Que contient un secret Secrets Manager ?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/whats-in-a-secret.html#term_version) dans le *Guide de l’utilisateur AWS Secrets Manager *.

Les informations suivantes doivent être prises en compte lors de l’utilisation d’une variable d’environnement pour injecter un secret Secrets Manager dans un conteneur.
+ Les données sensibles sont injectées dans votre conteneur lors du démarrage initial du conteneur. Si le secret est ensuite mis à jour ou fait l'objet d'une rotation, le conteneur ne reçoit pas la valeur mise à jour automatiquement. Vous devez lancer une nouvelle tâche ou, si votre tâche fait partie d'un service, vous pouvez mettre à jour le service et utiliser l'option **Force new deployment** (Forcer un nouveau déploiement) pour forcer le service à lancer une nouvelle tâche.
+ Les applications qui s’exécutent sur le conteneur, les journaux du conteneur et les outils de débogage ont accès aux variables d’environnement.
+ Pour les tâches Amazon ECS sur AWS Fargate, tenez compte des points suivants :
  + Pour injecter le contenu complet d'un secret en tant que variable d'environnement ou dans une configuration de journal, vous devez utiliser la version `1.3.0` ou ultérieure de la plateforme. Pour plus d'informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md).
  + Pour injecter une clé JSON spécifique ou une version d'un secret en tant que variable d'environnement ou dans une configuration de journal, vous devez utiliser la version `1.4.0` de la plateforme ou une version ultérieure (Linux) ou `1.0.0` (Windows). Pour plus d'informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md).
+ Pour les tâches Amazon ECS sur EC2, les informations suivantes doivent être prises en compte :
  + Pour injecter un secret à l'aide d'une clé JSON spécifique ou d'une version d'un secret, votre instance de conteneur doit avoir la version `1.37.0` ou ultérieure de l'agent de conteneur. Toutefois, nous vous recommandons d'utiliser la dernière version de l'agent de conteneur. Pour plus d'informations sur la vérification de la version de votre agent et la mise à jour à la dernière version, consultez [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md).

    Pour injecter le contenu complet d'un secret en tant que variable d'environnement ou pour injecter un secret dans une configuration de journal, votre instance de conteneur doit avoir la version `1.22.0` ou ultérieure de l'agent de conteneur.
+ Utilisez les points de terminaison de VPC d’interface pour renforcer les contrôles de sécurité et pour vous connecter à Secrets Manager via un sous-réseau privé. Vous devez créer les points de terminaison d'un VPC pour Secrets Manager. Pour plus d'informations sur le point de terminaison d'un VPC, veuillez consulter [Créer des points de terminaison d'un VPC](https://docs.aws.amazon.com/secretsmanager/latest/userguide/setup-create-vpc.html) dans le *Guide de l'utilisateur AWS Secrets Manager *. Pour plus d’informations sur l’utilisation de Secrets Manager et Amazon VPC, consultez la section [Comment se connecter au service Secrets Manager au sein d’un Amazon VPC](https://aws.amazon.com/blogs//security/how-to-connect-to-aws-secrets-manager-service-within-a-virtual-private-cloud/).
+ Pour les tâches Windows configurées pour utiliser le pilote de journalisation `awslogs`, vous devez également définir la variable d'environnement `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE` sur votre instance de conteneur. Utilisez la syntaxe suivante :

  ```
  <powershell>
  [Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine")
  Initialize-ECSAgent -Cluster <cluster name> -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]'
  </powershell>
  ```
+ Votre définition de tâche doit utiliser un rôle d’exécution de tâche doté des autorisations supplémentaires pour Secrets Manager. Pour de plus amples informations, veuillez consulter [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md).

## Créez le AWS Secrets Manager secret
<a name="secrets-envvar-secrets-manager-create-secret"></a>

Vous pouvez utiliser la console Secrets Manager afin de créer un secret pour vos données sensibles. Pour plus d'informations, voir [Création d'un AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) dans le *guide de AWS Secrets Manager l'utilisateur*.

## Ajoutez la variable d'environnement à la définition du conteneur
<a name="secrets-envvar-secrets-manager-update-container-definition"></a>

Dans votre définition de conteneur, vous pouvez spécifier les éléments suivants :
+ Objet `secrets` contenant le nom de la variable d'environnement à définir dans le conteneur
+ Amazon Resource Name (ARN) du secret Secrets Manager
+ Paramètres supplémentaires contenant les données sensibles à présenter au conteneur

L'exemple suivant montre la syntaxe complète qui doit être spécifiée pour le secret Secrets Manager.

```
arn:aws:secretsmanager:region:aws_account_id:secret:secret-name:json-key:version-stage:version-id
```

La section suivante décrit les paramètres supplémentaires. Ces paramètres sont facultatifs, mais si vous ne les utilisez pas, vous devez inclure les deux-points `:` pour utiliser les valeurs par défaut. Des exemples sont donnés ci-dessous pour plus de contexte.

`json-key`  
Spécifie le nom de la clé dans une paire clé-valeur avec la valeur que vous souhaitez définir comme valeur de variable d'environnement. Seules les valeurs au format JSON sont prises en charge. Si vous ne spécifiez pas de clé JSON, le contenu complet du secret est utilisé.

`version-stage`  
Spécifie l'étiquette intermédiaire de la version d'un secret que vous souhaitez utiliser. Si une étiquette intermédiaire de version est spécifiée, vous ne pouvez pas spécifier d'ID de version. Si aucune étape de version n'est spécifiée, le comportement par défaut consiste à récupérer le secret avec l'étiquette `AWSCURRENT` intermédiaire.  
Les étiquettes intermédiaires sont utilisées pour suivre les différentes versions d'un secret lorsqu'elles sont mises à jour ou font l'objet d'une rotation. Chaque version d'un secret a une ou plusieurs étiquettes intermédiaires et un ID.

`version-id`  
Spécifie l'identifiant unique de la version du secret que vous souhaitez utiliser. Si un ID de version est spécifié, vous ne pouvez pas spécifier d'étiquette intermédiaire de version. Si aucun ID de version n'est spécifié, le comportement par défaut consiste à récupérer le secret avec l'étiquette `AWSCURRENT` intermédiaire.  
 IDs Les versions sont utilisées pour suivre les différentes versions d'un secret lors de leur mise à jour ou de leur rotation. Chaque version d'un secret a un ID. Pour plus d'informations, veuillez consulter la rubrique [Concepts et termes clés pour AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/terms-concepts.html#term_secret) dans le *Guide de l'utilisateur AWS Secrets Manager *.

### Exemples de définitions de conteneur
<a name="secrets-examples"></a>

Les exemples suivants montrent comment vous pouvez référencer des secrets Secrets Manager dans vos définitions de conteneur.

**Example référencement d'un secret complet**  
Voici un extrait d'une définition de tâche montrant le format lorsque vous référencez le texte complet d'un secret Secrets Manager.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf"
    }]
  }]
}
```
Pour accéder à la valeur de ce secret depuis le conteneur, vous devez appeler `$environment_variable_name`.

**Example référencement de secrets complets**  
Voici l’extrait de code d’une définition de tâche présentant le format utilisé pour référencer le texte intégral de plusieurs secrets Secrets Manager.  

```
{
  "containerDefinitions": [{
     "secrets": [
      {
        "name": "environment_variable_name1",
         "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf"
      },
      {
        "name": "environment_variable_name2",
         "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-abcdef"
      },
      {
        "name": "environment_variable_name3",
        "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-ABCDEF"
      }
    ]
  }]
}
```
Pour accéder à la valeur de ce secret à partir du conteneur, vous devez appeler `$environment_variable_name1`, `$environment_variable_name2` et `$environment_variable_name3`.

**Example référencement d'une clé spécifique dans un secret**  
Voici un exemple de sortie d'une [get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html)commande qui affiche le contenu d'un secret ainsi que le libellé de la version intermédiaire et l'ID de version qui lui sont associés.  

```
{
    "ARN": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf",
    "Name": "appauthexample",
    "VersionId": "871d9eca-18aa-46a9-8785-981ddEXAMPLE",
    "SecretString": "{\"username1\":\"password1\",\"username2\":\"password2\",\"username3\":\"password3\"}",
    "VersionStages": [
        "AWSCURRENT"
    ],
    "CreatedDate": 1581968848.921
}
```
Référence d'une clé spécifique de la sortie précédente dans une définition de conteneur en spécifiant le nom de la clé à la fin de l'ARN.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1::"
    }]
  }]
}
```

**Example référencement d'une version secrète spécifique**  
Voici un exemple de sortie d'une commande [describe-secret](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/describe-secret.html) qui affiche le contenu non chiffré d'un secret ainsi que les métadonnées de toutes les versions du secret.  

```
{
    "ARN": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf",
    "Name": "appauthexample",
    "Description": "Example of a secret containing application authorization data.",
    "RotationEnabled": false,
    "LastChangedDate": 1581968848.926,
    "LastAccessedDate": 1581897600.0,
    "Tags": [],
    "VersionIdsToStages": {
        "871d9eca-18aa-46a9-8785-981ddEXAMPLE": [
            "AWSCURRENT"
        ],
        "9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE": [
            "AWSPREVIOUS"
        ]
    }
}
```
Référence d'une étiquette intermédiaire de version spécifique à partir de la sortie précédente dans une définition de conteneur en spécifiant le nom de la clé à la fin de l'ARN.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf::AWSPREVIOUS:"
    }]
  }]
}
```
Référence un ID de version spécifique de la sortie précédente dans une définition de conteneur en spécifiant le nom de clé à la fin de l'ARN.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:::9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE"
    }]
  }]
}
```

**Example référencement d'une clé spécifique et d'une étiquette intermédiaire de version d'un secret**  
Ce qui suit montre comment référencer à la fois une clé spécifique dans une étiquette secrète et une étiquette de mise en scène de version spécifique.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1:AWSPREVIOUS:"
    }]
  }]
}
```
Pour spécifier une clé et un ID de version spécifiques, utilisez la syntaxe suivante.  

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1::9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE"
    }]
  }]
}
```

Pour plus d’informations sur la création d’une définition de tâche avec le secret spécifié dans une variable d’environnement, consultez la section [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md). 

# Transmission des paramètres System Manager via les variables d’environnement Amazon ECS
<a name="secrets-envvar-ssm-paramstore"></a>

Amazon ECS vous permet d'injecter des données sensibles dans vos conteneurs en les stockant dans les paramètres du AWS Systems Manager Parameter Store, puis en les référençant dans la définition de votre conteneur.

Tenez compte des éléments suivants lorsque vous utilisez une variable d’environnement pour injecter un secret Systems Manager dans un conteneur.
+ Les données sensibles sont injectées dans votre conteneur lors du démarrage initial du conteneur. Si le secret est ensuite mis à jour ou fait l'objet d'une rotation, le conteneur ne reçoit pas la valeur mise à jour automatiquement. Vous devez lancer une nouvelle tâche ou, si votre tâche fait partie d'un service, vous pouvez mettre à jour le service et utiliser l'option **Force new deployment** (Forcer un nouveau déploiement) pour forcer le service à lancer une nouvelle tâche.
+ Pour les tâches Amazon ECS sur AWS Fargate, les points suivants doivent être pris en compte :
  + Pour injecter le contenu complet d'un secret en tant que variable d'environnement ou dans une configuration de journal, vous devez utiliser la version `1.3.0` ou ultérieure de la plateforme. Pour plus d'informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md).
  + Pour injecter une clé JSON spécifique ou une version d'un secret en tant que variable d'environnement ou dans une configuration de journal, vous devez utiliser la version `1.4.0` de la plateforme ou une version ultérieure (Linux) ou `1.0.0` (Windows). Pour plus d'informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md).
+ Pour les tâches Amazon ECS sur EC2, les informations suivantes doivent être prises en compte :
  + Pour injecter un secret à l'aide d'une clé JSON spécifique ou d'une version d'un secret, votre instance de conteneur doit avoir la version `1.37.0` ou ultérieure de l'agent de conteneur. Toutefois, nous vous recommandons d'utiliser la dernière version de l'agent de conteneur. Pour plus d'informations sur la vérification de la version de votre agent et la mise à jour à la dernière version, consultez [Mise à jour de l'agent de conteneur Amazon ECS](ecs-agent-update.md).

    Pour injecter le contenu complet d'un secret en tant que variable d'environnement ou pour injecter un secret dans une configuration de journal, votre instance de conteneur doit avoir la version `1.22.0` ou ultérieure de l'agent de conteneur.
+ Utilisez les points de terminaison VPC de l'interface pour améliorer les contrôles de sécurité. Vous devez créer les points de terminaison de VPC d’interface pour Systems Manager. Pour plus d’informations sur le point de terminaison de VPC, consultez la section [Amélioration de la sécurité des instances EC2 à l’aide des points de terminaison de VPC pour Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html) dans le *Guide de l’utilisateur AWS Systems Manager *.
+ Votre définition de tâche doit utiliser un rôle d’exécution de tâche doté des autorisations supplémentaires pour le magasin de paramètres Systems Manager. Pour de plus amples informations, veuillez consulter [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md).
+ Pour les tâches Windows configurées pour utiliser le pilote de journalisation `awslogs`, vous devez également définir la variable d'environnement `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE` sur votre instance de conteneur. Utilisez la syntaxe suivante :

  ```
  <powershell>
  [Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine")
  Initialize-ECSAgent -Cluster <cluster name> -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]'
  </powershell>
  ```

## Création du paramètre Systems Manager
<a name="secrets-envvar-ssm-paramstore-create-parameter"></a>

Vous pouvez utiliser la console System Manager pour créer un paramètre Systems Manager Parameter Store pour vos données sensibles. Pour plus d'informations, consultez [Créer un paramètre Systems Manager (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) ou [Créer un paramètre Systems Manager (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html) dans le *Guide de l'utilisateur AWS Systems Manager *.

## Ajoutez la variable d'environnement à la définition du conteneur
<a name="secrets-ssm-paramstore-update-container-definition"></a>

Dans la définition de votre conteneur dans la définition de tâche, spécifiez `secrets` avec le nom de la variable d’environnement à définir dans le conteneur et l’ARN complet du paramètre du magasin de paramètres Systems Manager contenant les données sensibles à présenter au conteneur. Pour de plus amples informations, veuillez consulter [secrets](task_definition_parameters.md#ContainerDefinition-secrets).

Voici un extrait d'une définition de tâche montrant le format à utiliser lorsque vous référencez un paramètre Systems Manager Parameter Store. Si le paramètre Systems Manager Parameter Store existe dans la même région que la tâche que vous lancez, vous pouvez utiliser le nom ou l'ARN complet du paramètre. Si le paramètre existe dans une autre région, l'ARN complet doit être spécifié.

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name"
    }]
  }]
}
```

Pour plus d’informations sur la création d’une définition de tâche avec le secret spécifié dans une variable d’environnement, consultez la section [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md).

## Mettez à jour votre application pour récupérer par programme les secrets Systems Manager Parameter Store.
<a name="secrets-ssm-paramstore-update-app"></a>

Pour récupérer les données sensibles stockées dans le paramètre Systems Manager Parameter Store, consultez les [exemples de code à utiliser par Systems Manager AWS SDKs](https://docs.aws.amazon.com/code-library/latest/ug/ssm_code_examples.html) dans la *bibliothèque de codes d'exemples de code du AWS SDK*.

# Transmission des secrets pour la configuration de la journalisation Amazon ECS
<a name="secrets-logconfig"></a>

Vous pouvez utiliser le paramètre `secretOptions` dans `logConfiguration` pour transmettre les données sensibles utilisées pour la journalisation.

Vous pouvez stocker le secret dans Secrets Manager ou Systems Manager.

## Utilisation de Secrets Manager
<a name="secrets-logconfig-secrets-manager"></a>

Dans votre définition de conteneur, lorsque vous spécifiez une `logConfiguration`, vous pouvez spécifier `secretOptions` avec le nom de l'option du pilote de journal à définir dans le conteneur et l'ARN complet du secret Secrets Manager contenant les données sensibles à présenter au conteneur. Pour plus d’informations sur la création de secrets, consultez la section [Création d’un AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html).

Voici un extrait d'une définition de tâche montrant le format lorsque vous référencez un secret Secrets Manager.

```
{
  "containerDefinitions": [{
    "logConfiguration": [{
      "logDriver": "splunk",
      "options": {
        "splunk-url": "https://your_splunk_instance:8088"
      },
      "secretOptions": [{
        "name": "splunk-token",
        "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf"
      }]
    }]
  }]
}
```

## Ajoutez la variable d'environnement à la définition du conteneur
<a name="secrets-envvar-ssm-paramstore-update-container-definition"></a>

Dans votre définition de conteneur, spécifiez `secrets` avec le nom de la variable d'environnement à définir dans le conteneur et l'ARN complet du paramètre Systems Manager Parameter Store contenant les données sensibles à présenter au conteneur. Pour de plus amples informations, veuillez consulter [secrets](task_definition_parameters.md#ContainerDefinition-secrets).

Voici un extrait d'une définition de tâche montrant le format à utiliser lorsque vous référencez un paramètre Systems Manager Parameter Store. Si le paramètre Systems Manager Parameter Store existe dans la même région que la tâche que vous lancez, vous pouvez utiliser le nom ou l'ARN complet du paramètre. Si le paramètre existe dans une autre région, l'ARN complet doit être spécifié.

```
{
  "containerDefinitions": [{
    "secrets": [{
      "name": "environment_variable_name",
      "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name"
    }]
  }]
}
```

Pour plus d’informations sur la création d’une définition de tâche avec le secret spécifié dans une variable d’environnement, consultez la section [Création d’une définition de tâche Amazon ECS à l’aide de la console](create-task-definition.md).

## Utiliser Systems Manager
<a name="secrets-logconfig-ssm-paramstore"></a>

Vous pouvez injecter des données sensibles dans une configuration de journal. Dans votre définition de conteneur, lorsque vous spécifiez `logConfiguration`, vous pouvez spécifier `secretOptions` avec le nom de l'option du pilote de journal à définir dans le conteneur et l'ARN complet du paramètre Systems Manager Parameter Store contenant les données sensibles à présenter au conteneur.

**Important**  
Si le paramètre Systems Manager Parameter Store existe dans la même région que la tâche que vous lancez, vous pouvez utiliser le nom ou l'ARN complet du paramètre. Si le paramètre existe dans une autre région, l'ARN complet doit être spécifié.

Voici un extrait d'une définition de tâche montrant le format à utiliser lorsque vous référencez un paramètre Systems Manager Parameter Store.

```
{
  "containerDefinitions": [{
    "logConfiguration": [{
      "logDriver": "fluentd",
      "options": {
        "tag": "fluentd demo"
      },
      "secretOptions": [{
        "name": "fluentd-address",
        "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter:/parameter_name"
      }]
    }]
  }]
}
```

# Spécification de données sensibles à l’aide de secrets Secrets Manager dans Amazon ECS
<a name="specifying-sensitive-data-tutorial"></a>

Amazon ECS vous permet d'injecter des données sensibles dans vos conteneurs en les stockant en AWS Secrets Manager secret, puis en les référençant dans la définition de votre conteneur. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur Amazon ECS](specifying-sensitive-data.md).

Découvrez comment créer un secret Secrets Manager, référencer le secret dans une définition de tâche Amazon ECS, puis vérifier que cela a fonctionné en interrogeant la variable d’environnement dans un conteneur montrant le contenu du secret.

## Conditions préalables
<a name="specifying-sensitive-data-tutorial-prereqs"></a>

Le didacticiel suppose de remplir les prérequis suivants :
+ Vous devez avoir suivi les étapes de [Configurer l'utilisation d'Amazon ECS](get-set-up-for-amazon-ecs.md).
+ Votre utilisateur dispose des autorisations IAM nécessaires pour créer les ressources Secrets Manager et Amazon ECS.

## Étape 1 : Créer un secret Secrets Manager
<a name="specifying-sensitive-data-tutorial-create-secret"></a>

Vous pouvez utiliser la console Secrets Manager afin de créer un secret pour vos données sensibles. Dans ce didacticiel, nous allons créer un secret de base pour stocker un nom d'utilisateur et un mot de passe à référencer ultérieurement dans un conteneur. Pour plus d'informations, voir [Création d'un AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) dans le *guide de AWS Secrets Manager l'utilisateur*.

Les ** key/value paires à stocker dans ce secret** sont la valeur de la variable d'environnement dans votre conteneur à la fin du didacticiel.

Enregistrez l'**ARN secret** pour le référencer dans votre politique IAM d'exécution de tâche et dans la définition de tâche lors des étapes ultérieures.

## Étape 2 : ajouter des autorisations secrètes au rôle d’exécution de tâche
<a name="specifying-sensitive-data-tutorial-update-iam"></a>

Pour qu’Amazon ECS puisse récupérer les données sensibles à partir de votre secret Secrets Manager, vous devez disposer des autorisations de secrets pour le rôle d’exécution des tâches. Pour de plus amples informations, veuillez consulter [Autorisations Secrets Manager ou Systems Manager](task_execution_IAM_role.md#task-execution-secrets).

## Étape 3 : Créer une définition de tâche
<a name="specifying-sensitive-data-tutorial-create-taskdef"></a>

Vous pouvez utiliser la console Amazon ECS pour créer une définition de tâche qui fait référence à un secret Secrets Manager.

**Pour créer une définition de tâche qui spécifie un secret**

Utilisez la console IAM pour mettre à jour votre rôle d'exécution de tâche avec les autorisations requises.

1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2).

1. Dans le panneau de navigation, choisissez **Task definitions** (Définition des tâches).

1. Choisissez **Create new task definition** (Créer une nouvelle définition de tâche), puis **Create new task definition with JSON** (Créer une nouvelle définition de tâche avec JSON).

1. Dans la zone de l’éditeur JSON, saisissez le texte JSON de définition de tâche suivant, en veillant à spécifier l’ARN complet du secret Secrets Manager que vous avez créée à l’étape 1 et le rôle d’exécution de tâche que vous avez mis à jour à l’étape 2. Choisissez **Enregistrer**.

1. 

   ```
   {
       "executionRoleArn": "arn:aws:iam::aws_account_id:role/ecsTaskExecutionRole",
       "containerDefinitions": [
           {
               "entryPoint": [
                   "sh",
                   "-c"
               ],
               "portMappings": [
                   {
                       "hostPort": 80,
                       "protocol": "tcp",
                       "containerPort": 80
                   }
               ],
               "command": [
                   "/bin/sh -c \"echo '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>' >  /usr/local/apache2/htdocs/index.html && httpd-foreground\""
               ],
               "cpu": 10,
               "secrets": [
                   {
                       "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:username_value",
                       "name": "username_value"
                   }
               ],
               "memory": 300,
               "image": "public.ecr.aws/docker/library/httpd:2.4",
               "essential": true,
               "name": "ecs-secrets-container"
           }
       ],
       "family": "ecs-secrets-tutorial"
   }
   ```

1. Choisissez **Créer**.

## Étape 4 : créer un cluster
<a name="specifying-sensitive-data-tutorial-create-cluster"></a>

Vous pouvez utiliser la console Amazon ECS pour créer un cluster contenant une instance de conteneur pour exécuter la tâche. Si vous avez un cluster existant avec au moins une instance de conteneur enregistrée avec les ressources disponibles pour exécuter une instance de la définition de tâche créée pour ce didacticiel, vous pouvez passer à l'étape suivante.

Pour ce didacticiel, nous allons créer un cluster avec une instance de conteneur `t2.micro` à l'aide de l'AMI Amazon Linux 2 optimisée pour Amazon ECS.

Pour plus d’informations sur la création d’un cluster pour EC2, consultez la section [Création d’un cluster Amazon ECS pour les charges de travail Amazon EC2](create-ec2-cluster-console-v2.md).

## Étape 5 : exécuter une tâche
<a name="specifying-sensitive-data-tutorial-run-task"></a>

Vous pouvez utiliser la console Amazon ECS pour exécuter une tâche avec la définition de tâche que vous avez créée. Dans le cadre de ce didacticiel, nous allons exécuter une tâche utilisant EC2, à l’aide du cluster que nous avons créé lors de l’étape précédente. 

Pour plus d'informations sur l'exécution d’une tâche, consultez [Exécution d’une application en tant que tâche Amazon ECS](standalone-task-create.md).

## Étape 6 : Vérification
<a name="specifying-sensitive-data-tutorial-verify"></a>

Vous pouvez vérifier que toutes les étapes ont été effectuées avec succès et que la variable d'environnement a été créée correctement dans votre conteneur en suivant les étapes ci-dessous.

**Vérifier que la variable d'environnement a été créée**

1. Trouvez l'adresse IP publique ou DNS pour votre instance de conteneur.

   1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2).

   1. Dans le volet de navigation, choisissez **Clusters**, puis choisissez le cluster que vous avez créé.

   1. Choisissez **Infrastructure**, puis choisissez l'instance de conteneur.

   1. Enregistrez l'adresse **Public IP** (IP publique) ou **Public DNS** (DNS public) de votre instance.

1. Si vous utilisez un ordinateur MacOS ou Linux, connectez-vous à votre instance avec la commande suivante, en indiquant le chemin d'accès de votre clé privée et l'adresse publique de votre instance :

   ```
   $ ssh -i /path/to/my-key-pair.pem ec2-user@ec2-198-51-100-1.compute-1.amazonaws.com
   ```

   Pour plus d’informations sur l’utilisation d’un ordinateur Windows, consultez la section [Se connecter à votre instance Linux à l’aide de PuTTY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-from-windows.html) dans le *Guide de l’utilisateur Amazon EC2*.
**Important**  
Pour plus d’informations sur les problèmes que vous pouvez rencontrer lors de la connexion à votre instance, consultez la section [Résolution des problèmes de connexion à votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html) dans le *Guide de l’utilisateur Amazon EC2*.

1. Répertoriez les conteneurs en cours d'exécution sur l'instance. Notez l'ID de conteneur pour le conteneur `ecs-secrets-tutorial`.

   ```
   docker ps
   ```

1. Connectez-vous au conteneur `ecs-secrets-tutorial` à l'aide de l'ID conteneur à partir du résultat de l'étape précédente.

   ```
   docker exec -it container_ID /bin/bash
   ```

1. Utilisez la commande `echo` pour imprimer la valeur de la variable d'environnement.

   ```
   echo $username_value
   ```

   Si le didacticiel s'est correctement déroulé, vous devriez voir le résultat suivant :

   ```
   password_value
   ```
**Note**  
Sinon, vous pouvez répertorier toutes les variables d'environnement dans votre conteneur à l'aide de la commande `env` (ou `printenv`).

## Étape 7 : nettoyer
<a name="specifying-sensitive-data-tutorial-cleanup"></a>

Une fois que vous avez terminé ce didacticiel, vous devez nettoyer les ressources qui lui sont associées afin d'éviter la facturation de frais pour des ressources inutilisées.

**Nettoyer les ressources.**

1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2).

1. Dans le panneau de navigation, choisissez **Clusters**.

1. Sur la page **Clusters**, choisissez le cluster.

1. Choisissez **Delete Cluster** (Supprimer le cluster). 

1. Dans la zone de confirmation, saisissez **Supprimer *cluster name***, puis choisissez **Supprimer**.

1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. Dans le panneau de navigation, choisissez **Rôles**. 

1. Recherchez `ecsTaskExecutionRole` dans la liste des rôles et sélectionnez-le.

1. Choisissez **Autorisations**, puis le **X** à côté de **ECSSecretsTutoriel**. Cliquez sur **Supprimer**.

1. Ouvrez la console Secrets Manager à l'adresse [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/).

1. Sélectionnez le secret **username\$1value** que vous avez créé, puis choisissez **Actions**, **Delete secret** (Supprimer le secret).