Volume de fichier unique monté en tant que répertoire dans Docker
documentation Docker indique qu'il est possible de monter un seul fichier dans un conteneur Docker:
L'indicateur -v peut également être utilisé pour monter un seul fichier - au lieu de répertoires - à partir de la machine hôte.
$ docker run --rm -it -v ~/.bash_history:/.bash_history ubuntu /bin/bashCela vous déposera dans un nouveau conteneur dans un shell bash, vous aurez l'historique de bash de l'hôte et, lorsque vous quitterez le conteneur, l'historique des commandes saisies se trouvera dans le conteneur.
Quand j'essaye cela cependant le fichier monte comme un répertoire:
tom@u ~/project $ docker run --rm -it -v file.json:/file.json test
total 80K
drwxr-xr-x 9 root root 4.0K Dec 7 12:58 .
drwxr-xr-x 63 root root 4.0K Dec 7 12:58 ..
drwxr-xr-x 2 root root 4.0K Dec 4 16:10 file.json
Mon Dockerfile ressemble à ceci:
FROM ubuntu:14.04
MAINTAINER Tom
CMD ["ls", "-lah", "/test"]
La version de Docker est 1.9.1, construisez a34a1d5.
Est-ce un problème de documentation, un malentendu de ma part, ou y a-t-il autre chose qui se passe?
test est le nom de votre image que vous avez construite avec le dossier 'docker build -t test', pas un dossier /test.
Essayez un Dockerfile avec:
CMD ["ls", "-lah", "/"]
or
CMD ["cat", "/file.json"]
Et:
docker run --rm -it -v $(pwd)/file.json:/file.json test
Notez l'utilisation de $(pwd) pour monter un fichier avec son chemin absolu complet (les chemins relatifs ne sont pas supportés)
C'est peut-être clair dans les réponses ci-dessus ... mais il m'a fallu du temps pour le comprendre dans mon cas.
La raison sous-jacente faisant en sorte que le fichier partagé avec -v apparaisse sous la forme d'un répertoire plutôt que d'un fichier est que Docker n'a pas pu trouver le fichier sur l'hôte. Donc, Docker crée un nouveau répertoire dans le conteneur avec le nom correspondant au fichier non existant sur l'hôte, car docker pense que l'utilisateur souhaite simplement partager un volume/répertoire qui sera créé ultérieurement.
Ainsi, dans le problème signalé ci-dessus, si vous avez utilisé un répertoire relatif dans la commande -v et que le menu fixe ne comprend pas les répertoires relatifs, cela signifie que le fichier n'a pas été trouvé sur l'hôte et que docker a créé un répertoire. Et la réponse ci-dessus qui suggère d'utiliser $ (pwd) sera la solution correcte lorsque le problème est dû à un répertoire relatif.
Mais pour ceux qui lisent cette page qui n'utilisent pas de répertoire relatif et qui ont le même problème ... essayez de comprendre pourquoi le fichier manque sur l'hôte.
Ce pourrait être juste une faute de frappe stupide ...
Il se peut que vous exécutiez la commande "docker run" à partir d'un client qui génère le conteneur docker sur un hôte différent et que le fichier partagé n'existe pas sur cet hôte différent. Le fichier partagé avec -v doit exister sur l'hôte sur lequel l'agent de menu fixe génèrera le conteneur ... pas nécessairement sur le client sur lequel la commande "docker run -v ..." est exécutée (bien qu'ils soient identiques). nombreux cas).
Il existe d'autres explications possibles ci-dessus pour Mac et Windows ... qui pourraient l'être aussi.
Le problème est donc le fichier manquant de l'hôte ... résoudre le problème dans votre configuration ... utiliser $ (pwd) pourrait être la solution, mais pas toujours.
J'ai passé un peu de temps à me battre et à diagnostiquer ce problème avec docker sous Windows. Cela pourrait également affecter les utilisateurs de Mac OSX. J'ajoute ici une réponse aux personnes susceptibles de rencontrer un problème dans ces environnements, car ma recherche m'a amené ici et une explication de ce qui semble se produire dans docker.
Sous Windows ou Mac OSX, votre menu fixe s’exécute dans un boot2docker VM et seul le répertoire des utilisateurs est réellement partagé par défaut. Sous Windows, ce répertoire est partagé sous le nom/c/Utilisateurs /, cependant. Dans le shell MinGW fourni avec Docker Machine, le lecteur peut être accédé en tant que/C ou/c, de sorte que cela peut vous rendre fou si vous oubliez que les commandes de Docker sont en cours d’exécution sur le boot2docker VM et vos chemins de fichiers doivent exister sur le boot2docker VM et être spécifiés de la manière qui existe ici car ce qui semble se produire dans docker est que, au lieu de donner un avertissement ou une erreur, le répertoire/fichier n'existe pas, docker crée en mode silencieux la source spécifiée en tant que répertoire dans le répertoire boot2docker VM), de sorte qu'il n'y a pas de sortie prête pour indiquer que vous faites quoi que ce soit de manière incorrecte.
Ainsi, comme dans la réponse ci-dessus, si votre fichier est monté en tant que répertoire, vérifiez que vous fournissez un chemin absolu. Pour Windows et Mac OSX, vérifiez que le chemin absolu que vous montez existe dans votre machine virtuelle boot2docker.
Lorsque vous exécutez docker dans docker (en montant /var/run/docker.sock Par exemple), vous devez savoir que si vous montez dans docker, les chemins de fichiers utilisés sont toujours ceux de votre hôte.
Donc si sur votre hôte vous faites le montage suivant:
-v /tmp/foobar.txt:/my/path/foobar.txt
vous devriez pas faire le montage suivant à l'intérieur du menu fixe:
-v /my/path/foobar.txt:/my/other/path.txt
mais utilisez plutôt le chemin de fichier de l'hôte, par exemple:
-v /tmp/foobar:txt:/my/other/path.txt
Il existe une solution simple pour ceux qui utilisent la machine VirtualBox. Par défaut, le dossier C:/User est ajouté. Si votre projet est dans C:/projets, ajoutez ce dossier pour le rendre disponible dans VB (avec automount).