Principes de base de Docker - Utilisez des montages de liaison pour gérer les données d'application

Les montures de liaison sont apparues dans les premiers jours de Docker. Comparé aux volumes, le montage en liaison a des capacités limitées. Lorsque vous utilisez le montage de liaison, les fichiers ou répertoires sur l'hôte seront montés dans le conteneur. Le fichier ou le répertoire est référencé par son chemin d'accès complet ou relatif sur l'hôte. À l'inverse, lorsque vous utilisez un volume, créez un nouveau répertoire dans le répertoire de stockage de Docker sur l'hôte, et Docker gère le contenu du répertoire.

Le fichier ou le répertoire n'a pas besoin d'exister déjà sur l'hôte Docker. S'il n'existe pas encore, créez-le à la demande. Les performances des montages de liaison sont très bonnes, mais elles dépendent du système de fichiers de l'hôte, qui a une structure de répertoires utilisable spécifique. Si vous développez une nouvelle application Docker, envisagez plutôt d'utiliser des volumes nommés . Vous ne pouvez pas utiliser les commandes CLI Docker pour gérer directement les montages de liaison.

docker-types-of-mounts-bind

Sélectionnez -vou --mountmarquez

Initialement, -vou --volumemarqué pour des conteneurs séparés, --mountétiqueté pour les services de cluster. Cependant, à partir de Docker 17.06, vous pouvez également --mountêtre utilisé indépendamment du conteneur. En général, l' --mountexpression de la marque est plus claire et plus détaillée. La plus grande différence est la -vsyntaxe de toutes les combinaisons d'options dans un champ et les --mountoptions de syntaxe séparées. Voici une comparaison de syntaxe de chaque balise.

Astuce: les nouveaux utilisateurs recommandent l'utilisation de la --mountgrammaire, les utilisateurs expérimentés peuvent être plus familiers -vou --volumegrammaticaux, mais encouragent également l'utilisation de la --mountgrammaire, car des études ont montré qu'elle est plus facile à utiliser.

  • -vOu --volume: Il se compose de trois champs, séparés par des deux-points (:). Les champs doivent être disposés dans le bon ordre et la signification de chaque champ n'est pas assez intuitive.
    • Pour les montages de liaison, le premier champ est le chemin du fichier ou du répertoire sur l'hôte.
    • Le deuxième champ est le chemin où le fichier ou le répertoire dans le conteneur est monté.
    • Le troisième champ est facultatif, est une liste séparée par des virgules d'options, telles que ro, consistent, delegated, cached, zet Z. Ces options seront discutées ci-dessous dans cet article.
  • --mount: Une pluralité de clés - paires de valeurs, séparées par des virgules, chaque clé - la valeur de l'un des <key>=<value>tuples. --mountSyntaxe plus -vou --volumeplus verbeuse, mais l'ordre des clés n'est pas important, la valeur de la balise est également plus facile à comprendre.
    • Le type de montage ( type), qui peut être soit bind, volumesoit tmpfs. Cette rubrique traite des montages de liaison, de sorte que le type ( type) est toujours bind mount ( bind).
    • La source de mount ( source). Pour les montages de liaison, il s'agit du chemin du fichier ou du répertoire sur l'hôte du démon Docker. Vous pouvez être utilisé sourceou srcspécifié.
    • Target ( destination), le chemin où le fichier ou le répertoire dans le conteneur est monté en tant que valeur. Il peut être utilisé destination, dstou targetspécifier.
    • readonlyOption (si présente), le montage de liaison sera monté sur le conteneur en lecture seule .
    • bind-propagationOption (si présente), modifiez la propagation de la liaison . Les valeurs possibles sont rprivate, private, rshared, shared, rslaveou slaveun.
    • consistencyOptions ( le cas échéant), les valeurs possibles consistent, delegatedou cachedun. Ce paramètre s'applique uniquement à Docker Desktop pour Mac et est ignoré sur les autres plates-formes.
    • --mountLa balise ne prend pas en charge les étiquettes selinux utilisées pour modifier zou Zoptions.

L'exemple suivant montre aussi simultanément que possible --mountet les -vdeux syntaxes, et le premier show --mount.

-vEt --mountla différence entre le comportement

Étant donné -vque le -volumemarquage de Docker fait depuis longtemps partie de, leur comportement ne peut pas être modifié. Cela signifie -vet -mountentre il y a un comportement différent.

Si vous utilisez -vou -volumepour lier des montages sur le fichier hôte ou le répertoire Docker n'existe pas, il -vle créera. Il est toujours créé sous forme de répertoire.

Si vous utilisez des --mountmontages de liaison sur le fichier hôte ou le répertoire Docker n'existe pas, Docker ne le crée pas automatiquement pour vous, mais génère une erreur.

Démarrez le conteneur avec le montage de liaison

Prenons une situation: vous avez un répertoire source, lorsque vous créez la source, la pièce est enregistrée dans un autre répertoire source/target/dans. Vous souhaitez travailler dans le /app/répertoire du conteneur est disponible, et chaque fois que vous souhaitez créer le code source sur l'hôte de développement, le conteneur peut accéder au nouveau bâtiment. Utilisez la commande suivante pour target/cataloguer monté en liaison sur le conteneur /app/. Dans le sourcerépertoire de commande d'exécution. Sur les hôtes Linux ou macOS, la $(pwd)sous - commande s'étend au répertoire de travail actuel.

Ci --mount- dessous et des -vexemples produiront les mêmes résultats. Sauf si enlevé après avoir exécuté le premier devtestconteneur d' échantillons , ou ne peut pas les exécuter en même temps.

--mount

$ docker run -d \
  -it \
  --name devtest \
  --mount type=bind,source="$(pwd)"/target,target=/app \
  nginx:latest

-v

$ docker run -d \
  -it \
  --name devtest \
  -v "$(pwd)"/target:/app \
  nginx:latest

Utilisez pour docker inspect devtestvérifier si les montages de liaison sont créés correctement. Voir la Mountspartie:

"Mounts": [
    {
    
    
        "Type": "bind",
        "Source": "/tmp/source/target",
        "Destination": "/app",
        "Mode": "",
        "RW": true,
        "Propagation": "rprivate"
    }
],

Cela indique que le montage est un bindmontage, qui montre la source et la destination correctes, est également montré monté lisible et inscriptible, et est configuré pour se propager rprivate.

Arrêtez le conteneur:

$ docker container stop devtest

$ docker container rm devtest

Répertoire non vide monté sur le conteneur

Si vous le montez en liaison dans un répertoire non vide du conteneur, le contenu existant du répertoire sera écrasé par le montage en liaison. Cela peut être utile, par exemple lorsque vous souhaitez tester une nouvelle version de l'application sans créer une nouvelle image. Cependant, il peut également être surprenant que ce comportement soit différent des volumes de docker .

Cet exemple est conçu pour être extrême, l'hôte utilisant uniquement le /tmp/répertoire de /usr/contenu du répertoire du conteneur de remplissage . Dans la plupart des cas, cela entraînera un dysfonctionnement du conteneur.

--mountEt des -vexemples des mêmes résultats.

--mount

$ docker run -d \
  -it \
  --name broken-container \
  --mount type=bind,source=/tmp,target=/usr \
  nginx:latest

docker: Error response from daemon: oci runtime error: container_linux.go:262:
starting container process caused "exec: \"nginx\": executable file not found in $PATH".

-v

$ docker run -d \
  -it \
  --name broken-container \
  -v /tmp:/usr \
  nginx:latest

docker: Error response from daemon: oci runtime error: container_linux.go:262:
starting container process caused "exec: \"nginx\": executable file not found in $PATH".

Le conteneur a été créé mais pas démarré. Supprime-le:

$ docker container rm broken-container

Utiliser le montage de liaison en lecture seule

Pour certaines applications de développement, le conteneur doit écrire pour lier les montages, de sorte que les modifications seront propagées à l'hôte Docker. À d'autres moments, le conteneur n'a besoin que d'un accès en lecture.

Cet exemple modifie l'exemple ci-dessus, mais monte role répertoire en tant que montage de liaison en lecture seule en l'ajoutant à la liste d'options (vide par défaut) après le point de montage dans le conteneur . Lorsqu'il existe plusieurs options, séparez-les par des virgules.

--mountEt des -vexemples des mêmes résultats.

--mount

$ docker run -d \
  -it \
  --name devtest \
  --mount type=bind,source="$(pwd)"/target,target=/app,readonly \
  nginx:latest

-v

$ docker run -d \
  -it \
  --name devtest \
  -v "$(pwd)"/target:/app:ro \
  nginx:latest

Utilisez pour docker inspect devtestvérifier si les montages de liaison sont créés correctement. Voir la Mountspartie:

"Mounts": [
    {
    
    
        "Type": "bind",
        "Source": "/tmp/source/target",
        "Destination": "/app",
        "Mode": "ro",
        "RW": false,
        "Propagation": "rprivate"
    }
],

Arrêtez le conteneur:

$ docker container stop devtest

$ docker container rm devtest

Configurer la propagation de la liaison

Pour les montages et les volumes de liaison, les valeurs de propagation par défaut des deux sont liées rprivate. Il ne peut être configuré que pour le montage en liaison, et il ne peut être configuré que sur un hôte Linux. La propagation des liaisons est un sujet avancé et de nombreux utilisateurs n'ont jamais besoin de la configurer.

La propagation de liaison indique si un montage créé dans un montage de liaison donné ou un volume nommé peut être propagé vers une copie du montage. Considérez un point de montage /mnt, montez- /tmple. Le contrôle de propagation est fourni /tmp/amonté sur l'autorisation ou non de l' /mnt/autilisation. Chaque paramètre de propagation a une contrepartie récursive. Dans le cas de la récursivité, considérez /tmp/aégalement être monté comme /foo. Réglage du contrôle de propagation /mnt/aet / ou /tmp/aprésence ou absence.

Paramètres de diffusion la description
partagé Les sous-montages de la monture d'origine sont exposés à la monture de réplique, et les sous-montages de la monture de réplique sont également propagés à la monture d'origine.
trimer Similaire au montage partagé, mais dans un seul sens. Si le montage d'origine expose le sous-montage, le montage de réplique peut le voir. Cependant, si la copie monte un sous-montant public, le montage d'origine ne peut pas le voir.
privé La monture est privée. Les sous-montages de la monture d'origine ne sont pas exposés à la monture de réplique et les sous-montages de la monture de réplique ne sont pas exposés à la monture d'origine.
rshared Identique à partagé, mais la propagation s'étend également aux points de montage imbriqués dans des points de montage d'origine ou en double.
rslave Identique à l'esclave, mais la propagation s'étend également aux points de montage imbriqués dans les points de montage d'origine ou de réplique.
rprivate Valeurs par défaut. Identique à private, cela signifie que les points de montage n'importe où dans les points de montage d'origine ou en double ne se propageront dans aucune direction.

Avant de configurer la propagation de liaison sur le point de montage, le système de fichiers hôte doit prendre en charge la propagation de liaison.

Pour plus d'informations sur la propagation des liaisons, consultez la documentation sur la sous-arborescence partagée du noyau Linux .

L'exemple suivant double le target/répertoire est monté sur le navire, le second définit les rooptions de chargement et rslavela propagation des options de liaison.

--mountEt des -vexemples des mêmes résultats.

--mount

$ docker run -d \
  -it \
  --name devtest \
  --mount type=bind,source="$(pwd)"/target,target=/app \
  --mount type=bind,source="$(pwd)"/target,target=/app2,readonly,bind-propagation=rslave \
  nginx:latest

-v

$ docker run -d \
  -it \
  --name devtest \
  -v "$(pwd)"/target:/app \
  -v "$(pwd)"/target:/app2:ro,rslave \
  nginx:latest

Maintenant, si vous le créez /app/foo/, /app2/foo/il existe également.

Configurer les balises selinux

Si vous utilisez selinux, vous pouvez ajouter des options zou Zpour modifier le montage selinux pour étiqueter les conteneurs du fichier hôte ou du répertoire. Cela affectera les fichiers ou répertoires sur l'hôte et aura des conséquences au-delà de la portée de Docker.

  • z L'option indique que le contenu du montage de la liaison est partagé entre plusieurs conteneurs.
  • Z L'option indique que le contenu du montage de la liaison est privé et non partagé.

Soyez supplémentaire prudent lorsque vous utilisez ces options . Utiliser le Zrépertoire système monté en liaison avec Options (tel que /homeou /usr) fait que votre hôte ne fonctionne pas, vous devrez peut-être re-marquer manuellement le fichier d'hôtes.

IMPORTANT: lorsque vous utilisez des montages de liaison pour le service, les étiquettes selinux ( :Zet :Z) et :roseront ignorées. Voir moby / moby # 32579 pour plus de détails .

Cet exemple définit l' zoption permettant de spécifier que plusieurs conteneurs peuvent partager des liaisons de contenu montées:

Vous ne pouvez pas utiliser la --mountbalise pour modifier l'étiquette selinux.

$ docker run -d \
  -it \
  --name devtest \
  -v "$(pwd)"/target:/app:z \
  nginx:latest

Configurer la cohérence de montage pour macOS

Docker Desktop pour Mac utilise osxfsdes répertoires partagés macOS et des fichiers répartis sur la machine virtuelle Linux. Cette répartition rend ces répertoires et fichiers disponibles pour les conteneurs Docker exécutés sur Docker Desktop pour Mac.

Par défaut, ces partages sont complètement cohérents, ce qui signifie que chaque fois qu'une opération d'écriture se produit sur l'hôte macOS ou via un montage dans le conteneur, les modifications sont vidées sur le disque afin que tous les participants au partage aient une vue de cohérence complète. Dans certains cas, une cohérence complète peut gravement affecter les performances. Docker 17.05 et les versions supérieures introduisent certaines options pour ajuster les paramètres de cohérence par montage et par conteneur. Les options suivantes sont disponibles:

  • consistentOu default: Le paramètre par défaut pour une cohérence totale, comme décrit ci-dessus.
  • delegated: La vue de montage du runtime du conteneur fait autorité. Les mises à jour effectuées dans le conteneur peuvent être retardées avant d'être visibles sur l'hôte.
  • cached: La vue de montage de l'hôte macOS fait autorité. Les mises à jour effectuées sur l'hôte peuvent être retardées avant d'être visibles dans le conteneur.

Ces options sont complètement ignorées sur tous les systèmes d'exploitation hôtes, à l'exception de macOS.

--mountEt des -vexemples des mêmes résultats.

--mount

$ docker run -d \
  -it \
  --name devtest \
  --mount type=bind,source="$(pwd)"/target,destination=/app,consistency=cached \
  nginx:latest

-v

$ docker run -d \
  -it \
  --name devtest \
  -v "$(pwd)"/target:/app:cached \
  nginx:latest

Auteur:
Traducteur du site officiel de Docker : Technical Zemin
Editeur: Technical Verses
links: English text

Je suppose que tu aimes

Origine blog.csdn.net/weixin_47498376/article/details/107603369
conseillé
Classement