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. # Utilisation de montages liés avec Amazon ECS Avec les montages liés, un fichier ou un répertoire sur un hôte, tel qu’une instance Amazon EC2, est monté dans un conteneur. Les montages liés sont pris en charge lorsque vous exécutez des tâches sur des instances Fargate ou Amazon EC2. Les montages liés sont liés au cycle de vie du conteneur qui les utilise. Une fois que tous les conteneurs qui utilisent un montage lié sont arrêtés, par exemple lorsqu'une tâche est arrêtée, les données sont supprimées. Pour les tâches hébergées sur des instances Amazon EC2, les données peuvent être liées au cycle de vie de l’instance Amazon EC2 hôte en spécifiant un `host` et une valeur `sourcePath` facultative dans votre définition de tâche. Pour de plus amples informations, consultez la section [Montages liés](https://docs.docker.com/engine/storage/bind-mounts/) dans la documentation Docker. Voici quelques cas d'utilisation courants pour les montages liés. + Pour fournir un volume de données vide à monter dans un ou plusieurs conteneurs. + Pour monter un volume de données hôte dans un ou plusieurs conteneurs. + Pour partager un volume de données d'un conteneur source avec d'autres conteneurs dans la même tâche. + Pour exposer un chemin d'accès et son contenu d'un fichier Dockerfile à un ou plusieurs conteneurs. ## Considérations relatives à l'utilisation des montages liés Lorsque vous utilisez des montages liés, tenez compte des éléments suivants. + Par défaut, les tâches hébergées sur AWS Fargate une version de plate-forme `1.4.0` ou ultérieure (Linux) `1.0.0` ou ultérieure (Windows) reçoivent un minimum de 20 GiB de stockage éphémère pour les montages liés. Vous pouvez augmenter la quantité totale de stockage éphémère jusqu’à un maximum de 200 Gio en spécifiant le paramètre `ephemeralStorage` dans votre définition de tâche. + Pour exposer des fichiers d'un fichier Dockerfile à un volume de données lorsqu'une tâche est exécutée, le plan de données Amazon ECS recherche une directive `VOLUME`. Si le chemin absolu spécifié dans la directive `VOLUME` est le même que le `containerPath` spécifié dans la définition de tâche, les données du chemin de directive `VOLUME` sont copiées sur le volume de données. Dans l'exemple Dockerfile suivant, un fichier nommé `examplefile` dans le répertoire `/var/log/exported` est écrit sur l'hôte, puis monté à l'intérieur du conteneur. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN mkdir -p /var/log/exported RUN touch /var/log/exported/examplefile VOLUME ["/var/log/exported"] ``` Par défaut, les autorisations de volume sont définies sur `0755` et le propriétaire en tant que `root`. Vous pouvez personnaliser ces autorisations dans le fichier Dockerfile. L'exemple suivant définit le propriétaire du répertoire en tant que `node`. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN yum install -y shadow-utils && yum clean all RUN useradd node RUN mkdir -p /var/log/exported && chown node:node /var/log/exported RUN touch /var/log/exported/examplefile USER node VOLUME ["/var/log/exported"] ``` + Pour les tâches hébergées sur des instances Amazon EC2, lorsque les valeurs `host` et `sourcePath` ne sont pas spécifiées, le démon Docker gère le montage lié à votre place. Lorsqu'aucun conteneur ne fait référence à ce montage lié, le service de nettoyage des tâches de l'agent de conteneur Amazon ECS finit par le supprimer. Par défaut, cela se produit trois heures après la sortie du conteneur. Toutefois, vous pouvez configurer cette durée avec la variable de l'agent `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`. Pour de plus amples informations, veuillez consulter [Configuration de l'agent de conteneur Amazon ECS](ecs-agent-config.md). Si vous avez besoin de conserver ces données au-delà du cycle de vie de conteneur, spécifiez une valeur `sourcePath` pour le montage lié. + Pour les tâches hébergées sur les instances gérées Amazon ECS, certaines parties du système de fichiers racine sont en lecture seule. Read/write les montages par liaison doivent utiliser des répertoires inscriptibles, par exemple `/var` pour les données persistantes ou `/tmp` pour les données temporaires. Toute tentative de création de montages par read/write liaison vers d'autres répertoires entraîne l'échec du lancement de la tâche avec une erreur similaire à la suivante : ``` error creating empty volume: error while creating volume path '/path': mkdir /path: read-only file system ``` Les montages de liaison en lecture seule (configurés `"readOnly": true` dans le `mountPoints` paramètre) peuvent pointer vers n'importe quel répertoire accessible sur l'hôte. Pour consulter la liste complète des chemins accessibles en écriture, vous pouvez exécuter une tâche sur une instance gérée Amazon ECS et l'utiliser pour inspecter la table de montage de l'instance. Créez une définition de tâche avec les paramètres suivants pour accéder au système de fichiers hôte : ``` { "pidMode": "host", "containerDefinitions": [{ "privileged": true, ... }] } ``` Exécutez ensuite les commandes suivantes depuis le conteneur : ``` # List writable mounts cat /proc/1/root/proc/1/mounts | awk '$4 ~ /^rw,/ || $4 == "rw" {print $2}' | sort # List read-only mounts cat /proc/1/root/proc/1/mounts | awk '$4 ~ /^ro,/ || $4 == "ro" {print $2}' | sort ``` **Important** Le `privileged` paramètre accorde au conteneur des fonctionnalités étendues sur l'hôte, équivalentes à un accès root. Dans cet exemple, il est utilisé pour inspecter la table de montage de l'hôte à des fins de diagnostic. Pour de plus amples informations, veuillez consulter [Évitez d'exécuter des conteneurs dotés de privilèges (Amazon EC2)](security-tasks-containers.md#security-tasks-containers-recommendations-avoid-privileged-containers). Pour plus d'informations sur l'exécution interactive de commandes dans des conteneurs, consultez[Surveillance des conteneurs Amazon ECS avec ECS Exec](ecs-exec.md). # Spécification d’un montage lié dans une définition de tâche Amazon ECS Pour les tâches Amazon ECS hébergées sur des instances Fargate ou Amazon EC2, l’extrait JSON de définition de tâche suivant montre la syntaxe des objets `volumes`, `mountPoints` et `ephemeralStorage` pour une définition de tâche. ``` { "family": "", ... "containerDefinitions" : [ { "mountPoints" : [ { "containerPath" : "/path/to/mount_volume", "sourceVolume" : "string" } ], "name" : "string" } ], ... "volumes" : [ { "name" : "string" } ], "ephemeralStorage": { "sizeInGiB": integer } } ``` Pour les tâches Amazon ECS hébergées sur des instances Amazon EC2, vous pouvez utiliser le paramètre `host` facultatif et un `sourcePath` lorsque vous spécifiez les détails du volume de tâches. Lorsqu'il est spécifié, il lie le montage lié au cycle de vie de la tâche plutôt qu'au conteneur. ``` "volumes" : [ { "host" : { "sourcePath" : "string" }, "name" : "string" } ] ``` Voici des descriptions plus détaillées de chaque paramètre de définition de tâche. `name` Type : chaîne Obligatoire : non Nom du volume. Jusqu’à 255 lettres (majuscules et minuscules), chiffres, traits d’union (`-`) et traits de soulignement (`_`) sont autorisés. Ce nom est référencé dans le paramètre `sourceVolume` de l’objet `mountPoints` de définition du conteneur. `host` Obligatoire : non Le paramètre `host` est utilisé pour lier le cycle de vie du montage lié à l'instance Amazon EC2 hôte, plutôt qu'à la tâche et à l'endroit où elle est stockée. Si le paramètre `host` est vide, le démon Docker attribue un chemin hôte au volume de données, mais la persistance des données après l'arrêt des conteneurs qui lui sont associés n'est pas garantie. Les conteneurs Windows peuvent monter des répertoires entiers sur le même lecteur que `$env:ProgramData`. Le `sourcePath` paramètre est pris en charge uniquement lors de l'utilisation de tâches hébergées sur des instances Amazon EC2 ou des instances gérées Amazon ECS. `sourcePath` Type : chaîne Obligatoire : non Lorsque le paramètre `host` est utilisé, spécifiez un paramètre `sourcePath` pour déclarer le chemin d'accès sur l'instance Amazon EC2 hôte qui est présentée au conteneur. Si ce paramètre est vide, le démon Docker attribue un chemin hôte pour vous. Si le paramètre `host` contient un emplacement de fichier `sourcePath`, le volume de données persiste à l'emplacement spécifié sur l'instance Amazon EC2 hôte jusqu'à ce que vous le supprimiez manuellement. Si la valeur `sourcePath` n'existe pas sur l'instance Amazon EC2 hôte, le démon Docker la crée. Si l'emplacement n'existe pas, le contenu du chemin source est exporté. `mountPoints` Type : tableau d'objets Obligatoire : non Les points de montage pour les volumes de données dans votre conteneur. Ce paramètre correspond à `Volumes` dans l’API Docker create-container et à l’option `--volume` de docker run. Les conteneurs Windows peuvent monter des répertoires entiers sur le même lecteur que `$env:ProgramData`. Les conteneurs Windows ne peuvent pas monter de répertoires sur un autre lecteur, et les points de montage ne peuvent pas être utilisés sur plusieurs lecteurs. Vous devez spécifier des points de montage pour associer un volume Amazon EBS directement à une tâche Amazon ECS. `sourceVolume` Type : Chaîne Obligatoire : oui, lorsque des objets `mountPoints` sont utilisés Nom du volume à monter. `containerPath` Type : Chaîne Obligatoire : oui, lorsque des objets `mountPoints` sont utilisés Le chemin dans le conteneur où le volume sera monté. `readOnly` Type : booléen Obligatoire : non Si cette valeur est `true`, le conteneur ne peut accéder au volume qu'en lecture. Si cette valeur est `false`, le conteneur peut écrire sur le volume. La valeur par défaut est `false`. Pour les tâches exécutées sur des instances EC2 exécutant le système d’exploitation Windows, laissez la valeur `false` par défaut. `ephemeralStorage` Type : objet Obligatoire : non Quantité de magasin éphémère à allouer pour la tâche. Ce paramètre est utilisé pour augmenter la quantité totale de stockage éphémère disponible, au-delà de la quantité par défaut, pour les tâches hébergées sur AWS Fargate une version de plate-forme `1.4.0` ou ultérieure (Linux) `1.0.0` ou ultérieure (Windows). Vous pouvez utiliser la CLI Copilot CloudFormation, le AWS SDK ou l'interface de ligne de commande pour spécifier un stockage éphémère pour un montage par liaison. # Exemples de montage lié pour Amazon ECS Les exemples suivants couvrent les cas d’utilisation courants pour l’utilisation d’un montage lié pour vos conteneurs. **Pour allouer une quantité accrue d'espace de stockage éphémère pour une tâche Fargate** Pour les tâches Amazon ECS hébergées sur Fargate à l'aide de la version `1.4.0` de la plateforme ou une version ultérieure (Linux) ou `1.0.0` (Windows), vous pouvez allouer plus que la quantité de magasins éphémères par défaut pour les conteneurs de votre tâche à utiliser. Cet exemple peut être intégré dans les autres exemples afin d'allouer plus de stockage éphémère pour vos tâches Fargate. + Dans la définition de la tâche, définissez un objet `ephemeralStorage`. La valeur `sizeInGiB` doit être un nombre entier compris entre `21` et `200` est exprimée en GiB. ``` "ephemeralStorage": { "sizeInGiB": integer } ``` **Pour fournir un volume de données vide pour un ou plusieurs conteneurs** Dans certains cas, vous voudrez fournir aux conteneurs dans une tâche un peu d'espace vide. Supposons par exemple que deux conteneurs de base de données doivent accéder au même emplacement de stockage temporaire pendant une tâche. Cela peut être réalisé à l'aide d'un montage lié. 1. Dans la section `volumes` de la définition de tâche, définissez un montage lié nommé `database_scratch`. ``` "volumes": [ { "name": "database_scratch" } ] ``` 1. Dans la section `containerDefinitions`, créez les définitions de conteneur de base de données. Cela permet de monter le volume. ``` "containerDefinitions": [ { "name": "database1", "image": "my-repo/database", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "database_scratch", "containerPath": "/var/scratch" } ] }, { "name": "database2", "image": "my-repo/database", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "database_scratch", "containerPath": "/var/scratch" } ] } ] ``` **Pour exposer un chemin d'accès et son contenu d'un fichier Dockerfile à un ou plusieurs conteneurs.** Dans cet exemple, vous avez un fichier Dockerfile qui écrit les données que vous souhaitez monter à l'intérieur d'un conteneur. Cet exemple fonctionne pour les tâches hébergées sur des instances Fargate ou Amazon EC2. 1. Créez un fichier Dockerfile. L'exemple suivant utilise l'image du conteneur Amazon Linux 2 publique et crée un fichier nommé `examplefile` dans le répertoire `/var/log/exported` que nous voulons monter à l'intérieur du conteneur. Le répertoire `VOLUME` doit spécifier un chemin absolu. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN mkdir -p /var/log/exported RUN touch /var/log/exported/examplefile VOLUME ["/var/log/exported"] ``` Par défaut, les autorisations de volume sont définies sur `0755` et le propriétaire en tant que `root`. Ces autorisations peuvent être modifiées dans le fichier Dockerfile. L'exemple suivant définit le propriétaire du répertoire `/var/log/exported` en tant que `node`. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN yum install -y shadow-utils && yum clean all RUN useradd node RUN mkdir -p /var/log/exported && chown node:node /var/log/exported USER node RUN touch /var/log/exported/examplefile VOLUME ["/var/log/exported"] ``` 1. Dans la section `volumes` de la définition de tâche, définissez un volume nommé `application_logs`. ``` "volumes": [ { "name": "application_logs" } ] ``` 1. Dans la section `containerDefinitions`, créez les définitions de conteneur d'application. Cela permet de monter le stockage. La valeur `containerPath` doit correspondre au chemin absolu spécifié dans la directive `VOLUME` du Dockerfile. ``` "containerDefinitions": [ { "name": "application1", "image": "my-repo/application", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "application_logs", "containerPath": "/var/log/exported" } ] }, { "name": "application2", "image": "my-repo/application", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "application_logs", "containerPath": "/var/log/exported" } ] } ] ``` **Pour fournir un volume de données vide pour un conteneur lié au cycle de vie de l'instance Amazon EC2 hôte** Pour les tâches hébergées sur des instances Amazon EC2, vous pouvez utiliser des montages liés et lier les données au cycle de vie de l'instance Amazon EC2 hôte. Vous pouvez effectuer cette opération en utilisant le paramètre `host` et en spécifiant une valeur `sourcePath`. Tous les fichiers qui existent sur le `sourcePath` sont présentés dans les conteneurs à la valeur `containerPath`. Tous les fichiers écrits dans la valeur `containerPath` sont écrits dans la valeur `sourcePath` de l'instance Amazon EC2 hôte. **Important** Amazon ECS ne synchronise pas votre stockage entre les instances Amazon EC2. Les tâches qui utilisent un stockage permanent peuvent être placées sur n'importe quelle instance Amazon EC2 disposant de la capacité nécessaire dans votre cluster. Si vos tâches nécessitent un stockage permanent après l'arrêt et le redémarrage, spécifiez toujours la même instance Amazon EC2 au moment du lancement de la tâche à l'aide de AWS CLI [la](https://docs.aws.amazon.com/cli/latest/reference/ecs/start-task.html) commande start-task. Vous pouvez également utiliser des volumes Amazon EFS pour le stockage permanent. Pour de plus amples informations, veuillez consulter [Utilisation des volumes Amazon EFS avec Amazon ECS](efs-volumes.md). 1. Dans la section `volumes` de la définition de tâche, définissez un montage lié avec les valeurs `name` et `sourcePath`. Dans l'exemple suivant, l'instance Amazon EC2 hôte contient des données sous `/ecs/webdata` que vous souhaitez monter à l'intérieur du conteneur. ``` "volumes": [ { "name": "webdata", "host": { "sourcePath": "/ecs/webdata" } } ] ``` 1. Dans la section `containerDefinitions`, définissez un conteneur avec une valeur `mountPoints` qui fait référence au nom du montage lié défini et la valeur `containerPath` sur laquelle monter le montage lié sur le conteneur. ``` "containerDefinitions": [ { "name": "web", "image": "public.ecr.aws/docker/library/nginx:latest", "cpu": 99, "memory": 100, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "essential": true, "mountPoints": [ { "sourceVolume": "webdata", "containerPath": "/usr/share/nginx/html" } ] } ] ``` **Pour monter un volume défini sur plusieurs conteneurs à différents emplacements** Vous pouvez définir un volume de données dans une définition de tâche et monter ce volume à différents emplacements de différents conteneurs. Par exemple, votre conteneur hôte possède un dossier de données de site web à l'adresse `/data/webroot`. Vous voudrez peut-être monter ce volume de données en lecture seule sur deux serveurs web qui ont des racines de documents différentes. 1. Dans la section `volumes` de la définition de tâche, définissez un volume de données nommé `webroot` et ayant le chemin source `/data/webroot`. ``` "volumes": [ { "name": "webroot", "host": { "sourcePath": "/data/webroot" } } ] ``` 1. Dans la section `containerDefinitions`, définissez un conteneur pour chaque serveur web avec des valeurs `mountPoints` qui associent le volume `webroot` à la valeur `containerPath` pointant vers la racine du document pour ce conteneur. ``` "containerDefinitions": [ { "name": "web-server-1", "image": "my-repo/ubuntu-apache", "cpu": 100, "memory": 100, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "essential": true, "mountPoints": [ { "sourceVolume": "webroot", "containerPath": "/var/www/html", "readOnly": true } ] }, { "name": "web-server-2", "image": "my-repo/sles11-apache", "cpu": 100, "memory": 100, "portMappings": [ { "containerPort": 8080, "hostPort": 8080 } ], "essential": true, "mountPoints": [ { "sourceVolume": "webroot", "containerPath": "/srv/www/htdocs", "readOnly": true } ] } ] ``` **Pour monter les volumes à partir d'un autre conteneur à l'aide de `volumesFrom`** Pour les tâches hébergées sur des instances Amazon EC2, vous pouvez définir un ou plusieurs volumes sur un conteneur, puis utiliser le paramètre `volumesFrom` dans une définition du conteneur différente, au sein de la même tâche, pour monter tous les volumes du `sourceContainer` à leurs points de montage définis à l'origine. Le paramètre `volumesFrom` s'applique aux volumes définis dans la définition de tâche et à ceux qui sont intégrés à l'image au sein d'un Dockerfile. 1. (Facultatif) Pour partager un volume qui est intégré à une image, suivez les instructions `VOLUME` du fichier Dockerfile. L'exemple de Dockerfile suivant utilise une image `httpd`, puis ajoute un volume et le monte à l'emplacement `dockerfile_volume` dans la racine du document Apache. Il s'agit du dossier utilisé par le serveur web `httpd`. ``` FROM httpd VOLUME ["/usr/local/apache2/htdocs/dockerfile_volume"] ``` Vous pouvez créer une image avec ce Dockerfile, la transférer dans un référentiel (comme Docker Hub), puis l'utiliser dans votre définition de tâche. L’exemple d’image `my-repo/httpd_dockerfile_volume` utilisée dans les étapes suivantes a été créée avec le Dockerfile précédent. 1. Créez une définition de tâche qui définit les autres volumes et points de montage pour les conteneurs. Dans la section `volumes` de cet exemple, vous créez un volume vide appelé `empty` qui est géré par le démon Docker. Il existe également un volume hôte défini qui est appelé `host_etc`. Il exporte le dossier `/etc` dans l'instance de conteneur hôte. ``` { "family": "test-volumes-from", "volumes": [ { "name": "empty", "host": {} }, { "name": "host_etc", "host": { "sourcePath": "/etc" } } ], ``` Dans la section des définitions de conteneur, créez un conteneur qui monte les volumes définis précédemment. Dans cet exemple, le conteneur `web` monte les volumes `empty` et `host_etc`. Il s'agit du conteneur qui utilise l'image créée avec un volume dans le Dockerfile. ``` "containerDefinitions": [ { "name": "web", "image": "my-repo/httpd_dockerfile_volume", "cpu": 100, "memory": 500, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "mountPoints": [ { "sourceVolume": "empty", "containerPath": "/usr/local/apache2/htdocs/empty_volume" }, { "sourceVolume": "host_etc", "containerPath": "/usr/local/apache2/htdocs/host_etc" } ], "essential": true }, ``` Créez un autre conteneur qui utilise `volumesFrom` pour monter tous les volumes qui sont associés au conteneur `web`. Tous les volumes du conteneur `web` sont également montés sur le conteneur `busybox`. Cela inclut le volume spécifié dans le Dockerfile qui a été utilisé pour générer l'image `my-repo/httpd_dockerfile_volume`. ``` { "name": "busybox", "image": "busybox", "volumesFrom": [ { "sourceContainer": "web" } ], "cpu": 100, "memory": 500, "entryPoint": [ "sh", "-c" ], "command": [ "echo $(date) > /usr/local/apache2/htdocs/empty_volume/date && echo $(date) > /usr/local/apache2/htdocs/host_etc/date && echo $(date) > /usr/local/apache2/htdocs/dockerfile_volume/date" ], "essential": false } ] } ``` Lorsque la tâche est exécutée, les deux conteneurs montent les volumes, et la fonction `command` du conteneur `busybox` écrit la date et l'heure dans un fichier. Ce fichier est appelé `date` dans chacun des dossiers de volumes. Les dossiers sont alors visibles sur le site web affiché par le conteneur `web`. **Note** Étant donné que le conteneur `busybox` exécute une commande rapide avant de s'arrêter, il doit être défini en tant que `"essential": false` dans la définition de conteneur. Dans le cas contraire, il arrête l'ensemble de la tâche lorsqu'il s'arrête.