Ouais, ça me remet!

Cela fonctionne-t-il après que vous ayez fig kill et fig rm ? Je soupçonne que c'est un bogue Docker avec VolumesFrom : https://github.com/docker/fig/issues/328#issuecomment -50926263

Cela fonctionne-t-il après que vous ayez fig kill et fig rm ? Je soupçonne que c'est un bogue Docker avec VolumesFrom : https://github.com/docker/fig/issues/328#issuecomment -50926263

non, pas vraiment,

Même erreur ici en essayant d'utiliser des volumes avec un fichier ...

Ne fonctionne pas sur un VFS ici:

Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
Execution Driver: native-0.2
Kernel Version: 3.10.42-xenU-12-e888729-x86_64
Operating System: Ubuntu 14.04 LTS

Mais ça marche, ça marche bien sur mon ordinateur personnel:

$ docker info
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
Execution Driver: native-0.2
Kernel Version: 3.13.0-35-generic
Operating System: Ubuntu 14.04.1 LTS

Pour les enregistrements, la sortie de la version docker est la même, mais je suis à peu près sûr que ce n'est pas si important que je me souvienne, cela fonctionnait parfaitement aussi en 1.2 ...

Client version: 1.3.0
Client API version: 1.15
Go version (client): go1.3.3
Git commit (client): c78088f
OS/Arch (client): linux/amd64
Server version: 1.3.0
Server API version: 1.15
Go version (server): go1.3.3
Git commit (server): c78088f

Donc, la seule différence que je peux repérer est la version du noyau. Le premier (qui ne fonctionne pas) est un VFS, le second est mon ordinateur. Cela aide-t-il à comprendre ce qui se passe?

Humm, désolé pour la pollution. Typo simple. Il ne semble pas que je sois le premier attrapé par ça.

Si "-v" est appelé sur un emplacement inexistant du côté hôte (à cause d'une faute de frappe), il créera un répertoire vide et tout le répertoire parents si nécessaire. Ensuite, lorsqu'il tente de monter ce répertoire vide sur le conteneur et qu'un fichier est déjà à l'emplacement cible, il lance ce message.

Je ne pense pas que docker devrait être autorisé à créer des répertoires du côté hôte. Dois-je supprimer mon commentaire précédent (et celui-ci?) Pour éviter de polluer ce fil?

Je vais ajouter mes deux cents / bosse ce fil. Ce serait super utile de pouvoir ajouter des fichiers uniques dans docker-compose . À l'heure actuelle, je dois avoir un répertoire séparé pour chacun de mes conteneurs, mais la plupart d'entre eux ne contiennent qu'un ou deux fichiers. Ce serait génial de les mettre tous dans le même dossier et de les référencer individuellement.

Je pense qu'il y a eu un bogue à un moment donné lors de la création de volumes, à partir desquels des fichiers montés en liaison étaient inclus.
Je ne pense pas que ce soit un problème aujourd'hui.

Cela semble être un problème récurrent.

Conformément à la référence de @ md5 et aux autres commentaires, je peux reproduire fidèlement ce comportement dans les conditions suivantes:

• CentOS 7
• Docker 1.5.0 (paquet yum docker-1.5.0-28.el7.centos)
• docker-compose 1.1.0

Ce comportement ne se présentait pas dans le package yum docker-1.5.0-1.el7 .

Exemple:

À l'aide d'une simple déclaration de service:

test:
  image: nginx
  ports:
    - "80:80"
  volumes:
    - sites/test.conf:/etc/nginx/conf.d/default.conf

En essayant de monter un fichier plutôt qu'un répertoire, docker-compose produit ce qui suit:

docker create_container <- (name=u'webcluster_test_1', image=u'nginx:latest', environment={}, volumes={u'/etc/nginx/conf.d/default.conf': {}}, detach=True, ports=[u'80'])
file exists at %!s(MISSING), can't create volume there

Pourtant, la commande équivalente docker run réussira:

docker run --name test -d -p "80:80" \
  -v ${PWD}/sites/test.conf:/etc/nginx/conf.d/default.conf \
  nginx

@dayglojesus Vous semblez utiliser une version de développement de Docker.
Pouvez-vous fournir la sortie de docker version ?
Le message d'erreur que vous avez ici provient de ce commit: https://github.com/docker/docker/commit/b0ed2da4418d62d2d7b940b49e0e89bdcd264569

Ce commit n'est pas dans une version publiée de Docker et a un correctif dans master, et fait partie de la série 1.6 RC.

@ cpuguy83 Il signale qu'il s'agit de la version 1.5.0, et non de 1.6 RC:

Docker version 1.5.0-dev, build fc0329b/1.5.0

Il s'agit de la version "officielle" mise à disposition dans les dépôts yum CentOS 7, pas de modifications pour les dépôts de développement.

Pourquoi est-ce que docker-compose présente ce comportement et docker run non? Est-ce un bug dans Docker ou docker-compose ?

Tenez-moi au courant si vous avez besoin de plus d'informations.

@dayglojesus Oui, ce n'est pas une version publiée de docker 1.5.0-dev été construit quelque temps après la suppression de docker 1.5.0.
Le bogue n'existe pas dans une version publiée de docker.

@ cpuguy83 Je vois. Bizarre, je me demande comment ce package est entré dans le repo? Savez-vous quel package yum correspond à la version actuelle de Docker 1.5.0 pour CentOS 7?

Je ne suis pas sûr ... ping @ lsm5

@dayglojesus donc celui que vous avez installé est le docker recompilé par RHEL qui a quelques correctifs redhat au-dessus du docker en amont. Si vous ne vous souciez pas de cela et que vous ne voulez qu'un rpm avec docker en amont, veuillez consulter: http://wiki.centos.org/Cloud/Docker . Cela mentionne un dépôt supplémentaire qui contient un rpm que je construis séparément dans le cadre du CentOS virt SIG.

Si vous vous souciez des choses rhel là-dedans, veuillez signaler un bogue sur https://bugzilla.redhat.com . HTH

A déposé un ticket RHEL pour ce problème. https://bugzilla.redhat.com/show_bug.cgi?id=1209625
Merci, @ lsm5.

Mmm, j'ai eu la même chose sur ubuntu 14.04lts avec docker 1.5

m'arrive sous linux mint / ubuntu, les fichiers ne sont pas du tout montés (ils sont censés écraser le conteneur mais ils ne le font pas)

J'ai le même problème avec etc-localtime sur

• Linux guest.vm 3.13.0-49-generic # 81-Ubuntu
• x86_64 x86_64 x86_64 GNU / Linux
• Description: Ubuntu 14.04.2 LTS
• Sortie: 14.04
• Nom de code: fidèle
• docker version 1.5

Si vous rencontrez un problème, les +1 ne vous aideront pas, d'autant plus qu'ils ne sont probablement pas du tout liés au problème du PO.

Veuillez inclure la commande docker que vous exécutez, ce que vous vous attendez à voir et ce que vous voyez réellement.
Inclut également la sortie de docker info et docker version .
Merci.

@ cpuguy83 ok, voici mon cas:

commander:

docker run -d --name webserver -p 80:80 -v ~/www/:/home/site/www/ -v ~/docker/share/apache_logs/:/home/site/logs -v ~/.gitconfig:/home/site/.gitconfig ...

situation: ~ / .gitconfig non présent sur l'hôte avant d'exécuter cette commande

ce qui se passe: ~ / .gitconfig est créé en tant que répertoire, appartenant à root (au lieu de l'utilisateur actuel), et le conteneur ne s'exécute pas, s'arrêtant avec un message indiquant qu'il n'est pas possible de monter ~ / .gitconfig (en utilisant le chemin complet dans son texte, pas le raccourci tilde)

ce que j'attends de voir: soit le docker devrait créer ~ / .gitconfig comme un fichier vide, appartenant à l'utilisateur actuel, et démarrer le conteneur avec succès, soit refuser de démarrer avec un meilleur message d'erreur et sans avoir créé du tout ~ / .gitconfig

infos docker:

user<strong i="14">@ubuntu14server</strong>:~$ docker info
Containers: 5
Images: 153
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 163
Execution Driver: native-0.2
Kernel Version: 3.16.0-30-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 1
Total Memory: 3.847 GiB
Name: ubuntu14server
ID: D52N:QLNG:UE33:N7F3:LZJP:NCF4:6OUS:COOJ:ISL3:2CRK:ZX3U:L3DW
WARNING: No swap limit support
user<strong i="15">@ubuntu14server</strong>:~$ docker version
Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.4.1
Git commit (client): a8a31ef
OS/Arch (client): linux/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.4.1
Git commit (server): a8a31ef

@gggeek Le problème ici est qu'il n'y a aucun moyen pour nous de détecter que vous voulez un fichier (cela a déjà été discuté).
Dans votre script de démarrage, je recommanderais d'ajouter une commande touch ~/.gitconfig avant votre commande docker run .

:-D c'est ce que j'ai fini par faire.
Qu'en est-il alors de prendre la route 2 et de ne pas créer le dossier?

@gggeek Ce navire a navigué et serait un changement majeur, malheureusement.

;-( tant pis

J'ai ce bug avec Docker version 1.6.0, build 4749651

Problème lié: https://github.com/docker/docker-py/issues/546

Je pense avoir trouvé une chose liée pour résoudre ce problème. J'utilise le dernier docker-compose (1.20) / docker (1.6.0) sur AWS. Et obtenait cette erreur chaque fois que j'essayais de démarrer nginx:

Cannot start container e9586e9e936c9b3991283c676bd071abb92a7b6b3bc0b667cf77a68fa4cc9222: [8] System error: mounting into / is prohibited

Par désespoir, j'ai regardé dans nginx Dockerfile et j'ai vu qu'il exposait un volume. J'ai donc ajouté ce volume à la liste que j'ai montée et du coup tout a fonctionné!

Donc, la différence entre les coutures docker-compose et docker est la valeur par défaut des volumes.

Le problème est clos mais quelle est la solution?
Nous avons le même problème que nous ne pouvons pas monter de fichiers dans un conteneur Docker.
Dernière version de Docker Toolbox (docker 1.9) sur Windows
Le démarrage du conteneur se termine par

Cannot start container XXX: [8] System error: not a directory

Identique à Sascha-Egeria, une solution?

Le problème que vous signalez n'est pas le même que ce problème. Ce problème était un bogue dans la version précédente de Docker, qui a été corrigé il y a longtemps.

Votre problème semble lié à # 2268 peut-être? Si vous pouviez publier dans ce numéro avec la sortie complète de docker-compose version , docker info , le contenu de votre docker-compose.yml et les commandes que vous avez exécutées, nous pourrions être en mesure de déboguer davantage le problème.

J'ai finalement résolu mon problème en utilisant Git Bash et la commande "docker-machine ssh [MACHINE]" pour travailler avec Docker.
Le nouveau shell de Docker Quickstart Terminal (1.9d) sur Windows fonctionne vraiment mal.

J'ai le même problème.
Docker-compose: 1.5.1
Docker: 1.9.1

nginx:
  image: nginx
  links:
   - web
  volumes:
   - .:/code
   - ./docker/nginx.conf:/etc/nginx/conf.d/default.conf <------
  ports:
   - "80:80"

@ jordi12100 Si vous obtenez un répertoire, cela

Reproduit dans le docker 1.9.1 en essayant de monter avec server.conf:/etc/server.conf où le fichier /etc/server.conf existe dans une image.

L'utilisation d'un chemin relatif semble faire que docker considère le fichier hôte comme le nom d'un dossier. Comme il s'agit d'un fichier dans un conteneur et que nous ne pouvons pas monter un dossier sur un fichier existant /etc/server.conf , cela échoue.

L'utilisation d'un chemin absolu vers server.conf résout le problème pour moi docker run -v /absolute/path/to/server.conf:/etc/server.conf ... et docker traite server.conf comme un fichier habituel.

Les chemins relatifs doivent commencer par . , alors essayez ./server.config .

Sans cela, il est considéré comme un volume nommé.

J'ai le même problème et je ne peux pas monter le fichier même avec un . . Docker (ou docker-compose?) Considère le fichier comme un dossier à moins que je ne fournisse un chemin de fichier absolu.

Docker: 1.9.1
Docker-compose: 1.5.2

Utilisez ./server.conf:/etc/server.conf avec les travaux de docker-compose. Mais l'option -v docker CLI se plaint d'un chemin illégal, n'accepte que le chemin absolu vers le fichier à monter.

@kirisetsz correct; docker-compose accepte les chemins relatifs (qui sont relatifs au fichier docker-compose.yml ); Compose se chargera de la conversion d'un chemin relatif en chemin absolu. Lors de l'utilisation de docker (pas de composition), vous devez spécifier un chemin absolu. Vous pouvez utiliser -v $(pwd)/server.conf:/etc/server.conf si vous ne voulez pas taper le chemin complet

Je confirme, j'ai le même problème avec:
Mac OS X.10.11.3
Docker version 1.9.1, build a34a1d5
docker-compose version 1.5.2, build 7240ff3
Même si je spécifie un chemin d'hôte absolu ou relatif, j'ai la même réponse:
ERROR: Cannot start container a9ed08a3ee639f61ff2720745011c940a5fff5b9b98bda6a45156a80381c5328: [8] System error: not a directory
FYI:

nginx:
  image: nginx
  ports:
    - 8080:80
    - 8443:443
  volumes_from:
    - application
  volumes:
    - ./SCM/Data/Etc/Configuration/nginx.conf:/etc/nginx/conf.d/default.conf:ro
    - ./LOGS/nginx:/var/log/nginx:rw
  links:
    - fpm

J'ai aussi ce problème

composer:
    image: php7-composer:latest
    working_dir: /data/application
    volumes:
      - ./.composer/cache:/var/composer/cache:rw
      - ./.composer/auth.json:/var/composer/auth.json:rw

Dans cet exemple, auth.json est créé en tant que répertoire sur la machine hôte et doit être un fichier. Si je mets d'abord auth.json sur la machine hôte, il se plaint que ce n'est pas un répertoire.

Pour moi aussi quand j'essaye:

volumes:
- ./docker/default.conf:/etc/nginx/conf.d/default.conf

J'obtiens l'erreur: ERREUR: Impossible de démarrer le conteneur 9f ...... f1e: [9] Erreur système: pas un répertoire

Si je change conf.d en autre chose, cela fonctionne mais il monte default.conf comme répertoire au lieu de fichier

Windows 10
Version de docker: 1.10.1
docker-compose version 1.6.0, build cdb920a

Ce bogue peut-il être rouvert, s'il vous plaît, puisqu'il a été fermé sans résolution? Cela se passe toujours. Mon cas est le même que beaucoup d'autres, en essayant de monter un fichier nginx.conf dans l'image nginx sous /etc/nginx/nginx.conf.

Dans docker-compose.yml:

nginx:
  image: "nginx:1.9.7"
  ports:
    - "80:80"
    - "443:443"
  volumes:
    - "./config/nginx.conf:/etc/nginx/nginx.conf:ro"
    - "./config/development-cert.pem:/etc/nginx/cert.pem:ro"
    - "./config/development-key.pem:/etc/nginx/key.pem:ro"

Production:

$ docker-compose up -d nginx
Starting example_nginx_1
ERROR: Cannot start container 81f4237f3f0e962d8861ca30744bfd78c3b61b4ea5891a19c712c682ecc5142c: [9] System error: not a directory

J'exécute Docker sur OS X (10.11.3) en utilisant une VM Vagrant avec le plugin VMware Fusion (VMware Fusion 8.1.0) et un hôte CoreOS. Informations de version pertinentes:

$ vagrant -v
Vagrant 1.8.1

$ vagrant plugin list
vagrant-vmware-fusion (4.0.8)

$ docker-compose -v
docker-compose version 1.6.0, build unknown

$ docker info
Containers: 6
 Running: 5
 Paused: 0
 Stopped: 1
Images: 6
Server Version: 1.10.1
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: host bridge null
Kernel Version: 4.4.1-coreos
Operating System: CoreOS 970.1.0 (Coeur Rouge)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 2.391 GiB
Name: localhost
ID: 73NW:JIK2:PTGX:3JVG:JZM4:NON4:DXOD:NAUU:UN7Q:T3F5:ZMZG:UWGR
Username: redacted
Registry: https://index.docker.io/v1/

$ docker version
Client:
 Version:      1.10.1
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   9e83765
 Built:        Fri Feb 12 22:11:40 UTC 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.10.1
 API version:  1.22
 Go version:   go1.4.3
 Git commit:   88b8b3a
 Built:
 OS/Arch:      linux/amd64

S'il vous plaît voir mon commentaire ici: https://github.com/docker/compose/issues/424#issuecomment -157751229

L'erreur peut apparaître la même, mais elle est probablement due à un problème différent.

Voir également https://github.com/docker/docker/issues/13670 et https://github.com/docker/docker/issues/19304.

J'ai également entendu des rapports selon lesquels vous pouvez obtenir cela si le répertoire de travail que vous avez défini n'existe pas en tant que répertoire. Je pense que vous vous heurtez à l'un de ces problèmes.

Essayez d'utiliser https://github.com/brikis98/docker-osx-dev

J'ai rencontré ce problème et après avoir tiré tous mes cheveux, j'ai découvert que le dossier était un lien symbolique vers un dossier appartenant à la racine.

Déplacement de tout le contenu dans (mon) dossier appartenant à l'utilisateur et fonctionne correctement.

Docker-1.12.0-rc2
Machine Docker 0.8.0-rc1
Docker-compose 1.8.0-rc1

J'ai trouvé ce fil via Google. J'ai aussi ce problème. Je ne peux pas me lier à des fichiers uniques, OSX.

Docker version 1.12.0-rc4, build e4a0dbc, experimental
docker-compose version 1.8.0-rc2, build c72c966

Docker vient d'être mis à jour aujourd'hui.

Mise à jour: Capture d'écran montrant qu'il tente de monter en tant que répertoire, pas fichier.

J'ai le même problème :-( impossible de monter un seul fichier

Client:
 Version:      1.12.0-rc4
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   e4a0dbc
 Built:        Wed Jul 13 03:28:51 2016
 OS/Arch:      darwin/amd64
 Experimental: true

Server:
 Version:      1.12.0-rc4
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   e4a0dbc
 Built:        Wed Jul 13 03:28:51 2016
 OS/Arch:      linux/amd64
 Experimental: true

confirmant également le problème

La mise à jour d'aujourd'hui sur OSX l'a corrigé. J'ai pu monter avec succès un seul fichier à l'aide de docker-compose.

Docker version 1.12.0, build 8eab29e, experimental
docker-compose version 1.8.0, build f3628c7

J'ai essayé de monter un fichier avec docker-compose

// docker-compose.yml
version: '2'
services:
  web:
    build: .
    privileged: true
    volumes:
      - "/usr/src/app/app.conf:/etc/app.conf"
    entrypoint: /run.sh

Sur la machine hôte

ls /usr/src/app/ -la
total 12
drwxr-xr-x   3 root root 4096 Aug  9 11:08 .
drwxr-xr-x 101 root root 4096 Aug  8 14:16 ..
drwxr-xr-x   2 root root 4096 Aug  9 11:08 app.conf

Docker-compose a créé un répertoire: drwxr-xr-x app.conf
au lieu d'un fichier.

Est-ce un comportement normal? J'ai supposé que le fichier était créé et monté.

Je serai très reconnaissant si quelqu'un me donne une clarification.

# lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial

Docker version 1.12.0, build 8eab29e
docker-compose version 1.8.0, build f3628c7

@bogulean si le fichier ou le répertoire que vous essayez de monter en liaison n'existe pas, docker n'a aucun moyen de déterminer si vous attendez un _file_ ou un _directory_, dans ce cas (si /usr/src/app/app.conf n'existe pas exist), le démon docker crée un répertoire à cet emplacement et le lie-monte dans le conteneur.

Notez que nous avons essayé de déprécier / supprimer la création automatique du chemin (et de produire une erreur à la place), mais c'était trop un changement incompatible en arrière (certaines personnes s'appuient sur ce comportement), nous avons donc dû conserver ce comportement.

@thaJeztah Merci pour une réponse rapide!
J'ai essayé de créer manuellement un fichier "/usr/src/app/app.conf" avant de démarrer docker-compose et le résultat est ci-dessous:

ERROR: for web  Cannot start service web: oci runtime error: rootfs_linux.go:53: mounting "/var/lib/docker/aufs/mnt/dc65b60b56bae344412f8c23a35f6a19d897b0cad0673bcb9316267ed02a44fe/etc/app.conf" to rootfs "/var/lib/docker/aufs/mnt/dc65b60b56bae344412f8c23a35f6a19d897b0cad0673bcb9316267ed02a44fe" caused "not a directory"
ERROR: Encountered errors while bringing up the project.

@bogulean quelle est votre configuration? Le démon et le client fonctionnent-ils sur le même ordinateur, ou travaillez-vous avec un démon distant (ou un démon s'exécutant sur une machine virtuelle?)

@thaJeztah J'utilise l'hôte DO, Ubuntu 16.04 LTS,
docker-compose et docker installés dessus, veuillez trouver les versions ci-dessous:

# lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial

Docker version 1.12.0, build 8eab29e
docker-compose version 1.8.0, build f3628c7

tout fonctionne sur cette machine jusqu'à là je suis connecté en utilisant ssh

En essayant de retirer docker compose de l'équation, pouvez-vous essayer de reproduire avec;

docker run --rm -v /usr/src/app/app.conf:/test/app.conf alpine cat /test/app.conf

qui doit monter en liaison le fichier de configuration et imprimer son contenu

docker run -it --rm -v /usr/src/app/app.conf:/test/app.conf alpine sh -c 'cat /test/app.conf'
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
e110a4a17941: Pull complete
Digest: sha256:3dcdb92d7432d56604d4545cbd324b14e647b313626d99b889d0626de158f73a
Status: Downloaded newer image for alpine:latest
Hello from /usr/src/app/app.conf

@thaJeztah Je pourrais également exécuter un fichier docker-compose.yml si vous me le donnez à des fins de test

@bogulean right, semble donc être un problème avec docker-compose, ou avec l'image que vous créez / exécutez. Ce serait l'équivalent du test précédent, mais ensuite via docker-compose;

version: '2'
services:
  web:
    image: "alpine:latest"
    volumes:
      - "/usr/src/app/app.conf:/test/app.conf"
    command: "cat /test/app.conf"

Et pour essayer si ça marche;

docker-compose run web

(qui devrait également afficher Hello from /usr/src/app/app.conf )

@thaJeztah , merci beaucoup! Votre docker-compose.yml a renvoyé Hello from /usr/src/app/app.conf
Cela m'a donc fait réaliser que je faisais quelque chose de mal ailleurs et j'ai trouvé qu'il y avait une ligne dans mon Dockerfile:
VOLUME ["/usr/src/app.conf"]
l'a supprimé et le fichier a commencé à se lier comme prévu.

Merci pour votre temps.

C'est bon à entendre et heureux de vous aider!

Le problème dans votre cas, c'est que VOLUME attend également un répertoire, donc créé un volume et essayé de le monter à /usr/src/app.conf . La meilleure façon de travailler avec des fichiers uniques de l'hôte est généralement de prendre en compte cette situation, par exemple, en ayant un répertoire /usr/src/config/ ; vous lieriez alors (ou utiliseriez un volume) pour ce répertoire, au lieu du fichier. Evidemment, pas toujours possible

@thaJeztah , j'ai le même problème lors de l'exécution de ceci:

docker run -v $(pwd)/filebeat.yml:/filebeat.yml prima/filebeat:1.2 cat filebeat.yml
cat: filebeat.yml: Is a directory

/ existe définitivement dans l'image / le conteneur:

docker run -v $(pwd)/filebeat.yml:/filebeat.yml prima/filebeat:1.2 ls -al
drwxr-xr-x   2 root root   40 Aug  9 20:46 filebeat.yml

Semble être un bogue Docker en général, non lié à Docker Compose.
Je ne sais pas pourquoi Docker créerait un répertoire dans ce cas.

Des idées? Merci beaucoup!

J'ai également essayé votre exemple avec l'image alpine. Même. cat: read error: Is a directory

@thasmo Vous obtenez cette erreur car filebeat.yml est un répertoire, pas un fichier.
Vous devez vous assurer que le fichier existe sur l'hôte avant d'essayer de le monter dans le conteneur, sinon docker créera un répertoire pour vous.

@ cpuguy83 , je pense que je viens de trouver le problème. J'utilise Docker sur Windows via Docker Machine et VirtualBox et il ne peut probablement pas monter le fichier local via VirtualBox dans le conteneur.
https://docs.docker.com/docker-for-windows/troubleshoot/#/host -filesystem-sharing

J'ai trouvé ce problème sur le docker d'installation propre sur la mise à jour anniversaire de Windows 10.
En fait, ce problème est une solution très simple

Besoin de partager des lecteurs dans les options de docker http://www.awesomescreenshot.com/image/1510321/0f1a81d7a8883df5a61bcdf04b3994cf
Regarde trouver et résout le problème.

J'ai toujours le problème sur ubuntu 16.10

➜  gi_proxy git:(master) ✗ docker -v
Docker version 1.12.3, build 6b644ec

docker run --name hap ... -v /home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.conf:/etc/resolv.conf

docker: Error response from daemon: invalid header field value "oci runtime error: container_linux.go:247: starting container process caused \"process_linux.go:359: container init caused \\\"rootfs_linux.go:53: mounting \\\\\\\"/home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.conf\\\\\\\" to rootfs \\\\\\\"/mnt/sda1/var/lib/docker/aufs/mnt/34ee49dcff906310df08b5a0bdf02ebafd302c1c7bf8b81ecd2778757fdb5713\\\\\\\" at \\\\\\\"/mnt/sda1/var/lib/docker/aufs/mnt/34ee49dcff906310df08b5a0bdf02ebafd302c1c7bf8b81ecd2778757fdb5713/etc/resolv.conf\\\\\\\" caused \\\\\\\"not a directory\\\\\\\"\\\"\"\n".

Si j'ai changé la course du docker pour monter dans un fichier qui n'existe pas comme / tmp / foo, cela fonctionne mais monte un répertoire.

@djpate est votre démon docker s'exécutant sur le même hôte (et pas dans une machine virtuelle?). Si /home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.conf n'existe pas sur la machine sur laquelle le démon docker est en cours d'exécution, alors le démon créera un _directory_ avec ce nom, et essaiera de le monter en liaison à /etc/resolv.conf à l'intérieur du conteneur. Puisque /etc/resolv.conf est un _file_, le montage en liaison d'un répertoire au-dessus d'un fichier échouera.

Cela dit, je déconseille fortement de remplacer /etc/resolv.conf par un fichier local; /etc/resolv.conf est géré par docker pour définir le serveur DNS correct à utiliser. Docker dispose d'un serveur DNS intégré pour la découverte de services, donc le remplacement de ce fichier entraînera le dysfonctionnement de la découverte de services.

Si vous souhaitez définir les options DNS, utilisez les options --dns , --dns-opt et --dns-search sur docker run ;

--dns value                   Set custom DNS servers (default [])
--dns-opt value               Set DNS options (default [])
--dns-search value            Set custom DNS search domains (default [])

Cela définira ces options sans provoquer de résultats inattendus. Notez que le DNS à l'intérieur du conteneur sera toujours 127.0.0.11 (le serveur DNS intégré), mais ce serveur transfère automatiquement les requêtes au serveur DNS que vous avez spécifié avec --dns

@thaJeztah Je suis nouveau dans docker mais je penserais qu'il tourne sur ma machine. J'ai essentiellement installé docker-engine et docker-machine sur une machine locale ubuntu ordinaire. Ceci est l'environnement de développement de mon entreprise et semble fonctionner pour tout le monde sur un docker mac.

Je vais le changer pour l'option DNS comme vous l'avez mentionné, je n'étais pas au courant de cela. Je vous remercie! Mais le bug est toujours là je pense.

Cela ne fonctionne pas non plus pour moi sur docker-compose v1.6.2 et docker v1.10.2 :(

Utiliser des chemins absolus fonctionne, mais malheureusement pour mon cas d'utilisation, les chemins absolus ne fonctionneront absolument pas: (. J'ai essayé toutes les combinaisons de ./ et ../ auxquelles je peux penser.

EDIT: De plus, je fonctionne sous Linux sans VM, donc la solution @thaJeztah ne fonctionne pas pour moi

Le système d'exploitation est Ubuntu 14.04

Docker est maintenant à 1.13.1. Veuillez mettre à jour votre Docker. Cela fonctionne depuis la 1.12.x.

Ah merci. Mettra à niveau le docker et mettra à jour si / lorsqu'il est corrigé :)

EDIT: A travaillé! Merci @guice

@thaJeztah

Si le fichier ou le répertoire que vous essayez de monter en liaison n'existe pas, docker n'a aucun moyen de déterminer si vous attendez un fichier ou un répertoire, dans ce cas (si /usr/src/app/app.conf n'existe pas), le démon docker crée un répertoire à cet emplacement et le lie-monte dans le conteneur.
Notez que nous avons essayé de déprécier / supprimer la création automatique du chemin (et de produire une erreur à la place), mais c'était trop un changement incompatible en arrière (certaines personnes s'appuient sur ce comportement), nous avons donc dû conserver ce comportement.

Je suis assez frustré après six heures d'essayer exactement ce cas d'utilisation et de découvrir maintenant que c'est impossible.
Pourquoi ne pas ajouter quelque chose comme "file flag" à la déclaration de volume, étant donné que nous pouvons spécifier des options de montage supplémentaires comme :ro et :rw ?

volumes:
  - "./config.json:/app/config.json:rwf"

Lorsque je mappe un fichier conteneur vers un fichier hôte, je m'attends à ce que ce fichier hôte soit créé (copié à partir du conteneur) lors de l'initialisation du conteneur.
Malheureusement, il est assez courant de trouver des conteneurs ayant des fichiers de configuration placés directement dans le répertoire racine de l'application, et évidemment vous ne voulez pas "volumiser" toute la racine. Dans ce cas, il serait particulièrement utile que cela fonctionne.

@malyzeli, vous voudrez peut-être examiner les secrets comme un moyen d'injecter une configuration comme celle-ci, ou de créer des modèles au démarrage.
Les volumes sont vraiment conçus pour la persistance, pas la configuration.
En réalité, docker ne devrait pas du tout créer automatiquement des chemins d'hôte, et ce comportement a été supprimé sur les API plus récentes.

@ cpuguy83

Je ne comprends pas votre point, alors veuillez expliquer ou corriger mes hypothèses, car je suis assez nouveau dans l'écosystème Docker.

Vous voudrez peut-être examiner les secrets comme moyen d'injecter une configuration comme celle-ci, ou de créer des modèles au démarrage.

Que faire si je ne sais pas à quoi ressemblera le fichier de configuration, car il est créé par un assistant d'installation directement à partir de l'application (et qui finit par changer de version en version)?
De nombreuses applications ont ce type de configuration initiale, par exemple Limesurvey et NodeBB.

Les volumes sont vraiment conçus pour la persistance, pas la configuration.

Voulez-vous dire que la configuration du conteneur existant ne doit pas être persistante?
Et si je souhaite sauvegarder une partie de mon infrastructure multi-conteneurs?
Je veux avoir à la fois les données et la configuration en volumes afin de pouvoir les restaurer rapidement en cas de problème.

En réalité, docker ne devrait pas du tout créer automatiquement des chemins d'hôte, et ce comportement a été supprimé sur les API plus récentes.

En fait, je n'en ai pas besoin pour créer des chemins d'hôte, mais pour initialiser un volume donné avec des données d'image existantes (par exemple, "externaliser" certains modèles html, que je souhaite modifier à partir du système hôte et / ou d'un autre conteneur) fonctionne exactement comme indiqué dans la référence Dockerfile :

La commande docker run initialise le volume nouvellement créé avec toutes les données qui existent à l'emplacement spécifié dans l'image de base.

Que faire si je ne sais pas à quoi ressemblera le fichier de configuration, car il est créé par un assistant d'installation directement à partir de l'application (et qui finit par changer de version en version)?

Laissez-le se créer, extrayez-le de l'image / du conteneur, faites-en un secret

Je veux avoir à la fois les données et la configuration en volumes afin de pouvoir les restaurer rapidement en cas de problème.

Utilisez des secrets. Nous examinons également un objet config dédié qui est similaire aux secrets, mais pas si restreint ... mais aujourd'hui, les secrets sont ce qui est disponible.

En fait, je n'en ai pas besoin pour créer des chemins d'hôte, mais pour initialiser un volume donné avec des données d'image existantes (par exemple, "externaliser" certains modèles html, que je souhaite modifier à partir du système hôte et / ou d'un autre conteneur), et cela reste fonctionne exactement comme indiqué dans la référence Dockerfile:

Les montages de liaison ne sont pas des volumes. La référence Dockerfile parle de volumes. Il est malheureux que docker run -v soit utilisé pour les deux.

Je ne dis certainement pas de ne pas utiliser de volumes pour stocker la configuration, je dis que vous devriez évaluer s'il existe une meilleure solution (et les secrets IMO sont bien meilleurs pour cela).

Les liaisons d'hôte sont une mauvaise solution pour autre chose que de prendre quelque chose qui existe déjà sur l'hôte et de l'introduire dans le conteneur ... et même dans ce cas, ce n'est généralement pas réalisable lorsque vous parlez d'environnements en cluster.

@ cpuguy83

Laissez-le se créer, extrayez-le de l'image / du conteneur, faites-en un secret

Ouais, c'est ce que je fais, mais ça me semble quand même ennuyeusement compliqué .. :-)

Utilisez des secrets. Nous examinons également un objet config dédié qui est similaire aux secrets, mais pas si restreint ... mais aujourd'hui, les secrets sont ce qui est disponible.

Je vais l'examiner, je ne connaissais pas les secrets, merci!

Les montages de liaison ne sont pas des volumes. La référence Dockerfile parle de volumes. Il est malheureux que docker run -v soit utilisé pour les deux.

D'accord, cela semble être une explication de la raison pour laquelle cela n'a pas fonctionné comme prévu. Je pensais que les liaisons et les volumes sont simplement des noms différents pour la même chose, étant donné que cela est fait par le même -v .

Pour ceux qui voient ce bogue dans Windows ... même si vous avez des disques partagés ...

Il y a un problème où si vous utilisez Docker Windows (avec docker-compose) et utilisez certaines informations d'identification pour "Partager le lecteur" telles que C: \ ou D: \ etc., vous devrez peut-être annuler le partage, partager à nouveau le lecteur, ressaisir informations d'identification, sinon cela vous donne une erreur liée comme:

"ERREUR: for ... Impossible de démarrer le service yourservice: erreur d'exécution oci: container_linux.go: 262: démarrage du processus du conteneur causé" process_linux.go: 339: conteneur "causé \" rootfs_linux.go: 57: montage \

"\\" a causé \\ "pas un répertoire \\" ""
: Essayez-vous de monter un répertoire sur un fichier (ou vice-versa)? Vérifiez si le chemin d’hôte spécifié existe et est du type attendu "

BaranOrnarli comment être celui qui a DockerToolbox?

Même problème ici que la plupart des gens ici. Mais je l'ai fait fonctionner à nouveau simplement en redémarrant la VM.

Éducation Windows 10
Boîte à outils Docker, 17.10.0-ce
VirtualBox 5.2.2

L'exécution de ceci via docker CLI fonctionne:
docker run -d -p 8080:80 -v $(pwd)/src/vhost.conf:/etc/nginx/sites-enabled/vhost.conf tutoriel / nginx

Exécuter la même chose via docker-compose, n'a pas:
couper
volumes: - ./src/vhost.conf:/etc/nginx/sites-enabled/vhost.conf
Autrement dit, jusqu'à ce que j'arrête la machine virtuelle via l'interface graphique de VirtualBox et que je redémarre le terminal de démarrage rapide Docker.

Depuis lors, la destruction répétée des conteneurs et la composition de docker n'ont pas fait revenir l'erreur.

J'espère que cela aide quelqu'un.

J'ai le même problème. En attendant, j'utilise le dossier docker de vrais volumes dans docker-compose.yml. Il s'agit de /var/lib/docker/volumes..../file.ext comme solution de contournement temporelle
(Docker version 17.12.0-ce, build c97c6d6)

Si vous rencontrez un tel problème, vérifiez également si vous avez partagé votre répertoire sous Windows.

Im sur Ubuntu 14.04. Lorsque j'exécute la commande docker-compose up -d , j'ai l'erreur suivante:

ERROR: for frontend Cannot start service frontend: OCI runtime create failed: container_linux.go:296: starting container process caused "process_linux.go:398: container init caused \"rootfs_linux.go:58: mounting \\\"/home/curso-docker/email-worker-compose/nginx/default.conf\\\" to rootfs \\\"/var/lib/docker/aufs/mnt/ffc214cd493c376554125473ba95e8cd918cd3ad73b6aa8292f51ce84beca8a6\\\" at \\\"/var/lib/docker/aufs/mnt/ffc214cd493c376554125473ba95e8cd918cd3ad73b6aa8292f51ce84beca8a6/etc/nginx/conf.d/default.conf\\\" caused \\\"not a directory\\\"\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

J'utilise le chemin absolu pour mapper le volume /home/curso-docker/email-worker-compose/nginx/default.conf de mon hôte.

Quelqu'un a une idée de ce problème?

@AzeredoGabriel pour moi, faire ce que @BaranOrnarli a mentionné plus tôt a fonctionné comme un charme. Réinitialisez les informations d'identification de votre Drive partagé, partagez-le à nouveau et cela devrait fonctionner. Je ne sais pas pourquoi il a soudainement cessé de fonctionner en premier lieu, mais maintenant c'est à nouveau.

des nouvelles à ce sujet? Il semble toujours impossible de monter un seul fichier

@Karlheinzniebuhr Cela n'a jamais été un problème. Docker permet de monter des fichiers dans un conteneur, mais vous ne pouvez pas monter un fichier dans un répertoire ou vice-versa.

des nouvelles à ce sujet? Il semble toujours impossible de monter un seul fichier

essayez de mapper le fichier avec le répertoire existant. Docker essaie de créer un répertoire toujours s'il n'existe pas.

@ cpuguy83 Bien sûr, c'est un problème. Nous n'essayons pas de monter des fichiers dans un répertoire. Nous essayons de monter un seul fichier créé par le conteneur sur l'hôte en tant que fichier.

Pouvons-nous rouvrir ce numéro? Ne fonctionne toujours pas en 2019. Sur le dernier Docker et le dernier docker-compose fonctionnant sur le dernier Debian.

Vous ne pouvez pas monter du conteneur vers l'hôte, mais dans l'autre sens.
C'est le même comportement pour les répertoires et les fichiers.

Même problème, en utilisant docker 19.03.1 et docker-compose 1.24.1, tout en essayant de remplacer un fichier de configuration dans store/elastic/filebeat:7.3.0 image avec une liaison de volume dans docker-compose.yml:

    volumes:
      - ${PWD}/filebeat.yml:/usr/share/filebeat/filebeat.yml:ro

ERROR: for docker_filebeat_1 Cannot start service filebeat: OCI runtime create failed: container_linux.go:345: starting container process caused "process_linux.go:430: container init caused \"rootfs_linux.go:58: mounting \\\"/filebeat.yml\\\" to rootfs \\\"/var/lib/docker/overlay2/f49a0ae0ec6646c818dcf05dbcbbdd79fc7c42561f3684fbb1fc5d2b9d3ad192/merged\\\" at \\\"/var/lib/docker/overlay2/f49a0ae0ec6646c818dcf05dbcbbdd79fc7c42561f3684fbb1fc5d2b9d3ad192/merged/usr/share/filebeat/filebeat.yml\\\" caused \\\"not a directory\\\"\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

Au départ, j'ai essayé d'utiliser des "configs", mais j'ai découvert que cette fonctionnalité est réservée à l'essaim.
J'essaie de trouver un moyen de fournir un fichier de configuration à l'image par défaut sans en créer un personnalisé avec les fichiers de configuration COPY.

Même problème

$ ls -l logstash.conf
-rw-r--r--  1 lubumbax  staff  164 Apr 30 18:01 logstash.conf
$ pwd
/Users/lubumbax/Src/Java/elk

$ docker run -it --name logstash -p 5000:5000 \
             -v "$(pwd)/logstash.conf:/usr/share/logstash/pipeline/logstash.conf" \
             docker.elastic.co/logstash/logstash:7.6.2

Résultat:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"/Users/lubumbax/Src/Java/elk/logstash.conf\\\" to rootfs \\\"/var/lib/docker/overlay2/bad85f1a2984bed23619fdf401cc9655573bb1799a8b681d371f5964201b9a82/merged\\\" at \\\"/var/lib/docker/overlay2/bad85f1a2984bed23619fdf401cc9655573bb1799a8b681d371f5964201b9a82/merged/usr/share/logstash/pipeline/logstash.conf\\\" caused \\\"not a directory\\\"\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type.

$ docker version
Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.14
 Git commit:        afacb8b
 Built:             Thu Mar 12 02:45:41 2020
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       afacb8b7f0
  Built:            Wed Mar 11 01:30:32 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Une chance de résoudre ce problème?

Problème ennuyeux.

Chers collègues, vérifiez la direction de montage dans docker-compose.
J'ai eu les mêmes problèmes jusqu'à ce que je réalise que j'avais tort, devrait être comme ça:

...
    volumes:
      - /host/file:/docker/file:ro
...