web-dev-qa-db-fra.com

Docker-compose le volume monté nommé

Afin de garder une trace des volumes utilisés par docker-compos, j'aime utiliser des volumes nommés. Cela fonctionne très bien pour des volumes "normaux" comme

version: 2
services: 
  example-app:
    volume:
      -named_vol:/dir/in/container/volume
volumes:
  named_vol:

Mais je ne peux pas comprendre comment le faire fonctionner lors du montage de l'hôte local. Je cherche quelque chose comme:

version: 2
services: 
  example-app:
    volume:
      -named_homedir:/dir/in/container/volume
volumes:
  named_homedir: /c/Users/

ou

version: 2
services: 
  example-app:
    volume:
      -/c/Users/:/home/dir/in/container/ --name named_homedir

est-ce possible ou suis-je coincé avec des volumes anonymes pour ceux montés?

docker-composedocker-volume
45
pvgoddijn

Comme vous pouvez le lire dans ce numéro de GitHub, le montage de volumes nommés c'est maintenant une chose … depuis 1.11 ou 1.12.). Les options spécifiques au pilote sont documentées. Quelques notes du fil de discussion GitHub:

docker volume create --opt type=none --opt device=<Host path> --opt o=bind

Si le chemin de l'hôte n'existe pas, il ne sera pas créé.

Les options sont transmises littéralement à l'appel système de montage. Nous pouvons ajouter des cas spéciaux pour certains "types" car ils sont difficiles à utiliser ... comme dans l'exemple nfs [référencé ci-dessus].

- @ cpuguy83

Pour répondre à votre question spécifique sur l'utilisation de cela dans Compose, vous écrivez dans votre section volumes:

my-named-volume:
     driver_opts:
           type: none
           device: /home/full/path #NOTE needs full path (~ doesn't work)
           o: bind

En effet, comme cpuguy83 l’a écrit dans le thread lié github, les options sont (sous le capot) directement transmises à la commande mount.

EDIT: Commenté par…

  • … @ Visslav, vous pouvez utiliser ${PWD} pour les chemins relatifs.

  • … @ Mikeyjk, vous devrez peut-être supprimer des volumes préexistants:

    docker volume rm $(docker volume ls)
27
kaiser

Les volumes hôtes sont différents des volumes nommés ou des volumes anonymes. Leur "nom" est le chemin sur l'hôte.

Il n’ya aucun moyen d’utiliser la section volumes pour les volumes d’hôte.

7
dnephin

Je cherchais une réponse à la même question récemment et suis tombé sur ce plugin: https://github.com/CWSpear/local-persist On dirait que cela permet de savoir exactement ce que le sujet démarré veut faire.

Je n'ai pas encore essayé moi-même, mais j'ai pensé que cela pourrait être utile à quelqu'un.

7
Stas Makarov

J'ai essayé la (presque) même chose et cela semble fonctionner avec quelque chose comme:

version: '2'
services: 
  example-app:
    volume:
      -named_vol:/dir/in/container/volume
      -/c/Users/:/dir/in/container/volume
volumes:
  named_vol:

Cela semble fonctionner pour moi (je ne l'ai pas creusé, je l'ai juste testé).

5
rmNyro

OP semble utiliser déjà des chemins d'accès complets, mais si, comme la plupart des gens, vous souhaitez monter un dossier de projet dans le conteneur, cela pourrait aider.

Voici comment le faire avec driver_opts _ comme @kaiser a dit et @linuxbandit est exemplifié. Mais vous pouvez essayer d'utiliser la variable d'environnement disponible généralement $ PWD pour éviter de spécifier des chemins complets pour les répertoires dans le contexte docker-compose:

logs-directory:
  driver_opts:
    type: none
    device: ${PWD}/logs
    o: bind
4
villasv