Vous avez un problème avec le format de fichier.

Dans votre .dockerignore changez subdir/ en subdir .

Pourquoi le .dockerignore fonctionne-t-il pour docker build -t subdir ../ mais pas docker-compose build ?

J'ai le même problème avec docker-compose 1.2.0.
L'exécution de vanilla docker build extrait le fichier ignorer et construit l'image, np là-bas.
Cependant, docker-compose n'utilise pas le fichier ignorer, avec ou sans la barre oblique finale.

Ressemble à un problème de docker-py; un correctif est en cours d'élaboration dans https://github.com/docker/docker-py/pull/604. Marquer cela comme un bogue pour nous rappeler de mettre à jour notre version de docker-py une fois que le correctif est sorti.

@aanand ressemble à https://github.com/docker/docker-py/pull/604 bloqué et a été retiré du jalon là-bas?

@thaJeztah J'ai créé https://github.com/docker/docker-py/pull/721 pour continuer le travail.

Salut,

Je suis confronté à un problème étrange avec .dockerignore:

*.sh

!awesome/script.sh

avec docker build tout va bien, mais docker-compose n'a pas vu "awesome / script.sh"

Suis-je dans le même problème?

@twillouer c'est un bug connu, corrigé par https://github.com/docker/docker-py/pull/721 - il sera corrigé côté Compose dans la version 1.5.0.

Merci !

Cela semble toujours être cassé même sur le dernier maître git sur certaines machines. Cela ne fonctionne pas pour moi sur une machine étant donné cette configuration:

Debian 8.2 avec noyau 3.16.0 avec lxc-docker version 1.7.1, build 786b29d
docker-compose est git master, HEAD est à dabf1e8657674014a5bc89f99edbf2fe0629bb71

Le .dockerignore fonctionne bien pour la construction de docker (qui s'exécute instantanément), mais pas pour docker-compose (qui télécharge des éléments qu'il ne devrait pas télécharger pendant plusieurs minutes).

Voir aussi # 2100

J'ai le même problème. docker-compose ignore ".dockerignore". "docker build" fonctionne très bien.
Système: windows 10

Je rencontre le même problème en utilisant la boîte à outils Docker qui a été publiée hier:

• Windows 7 x64
• Docker version 1.9.0, build 76d6bc9
• Docker-Compose 1.5.0

Il semble que nous ayons toujours des problèmes avec .dockerignore . Si vous rencontrez ces problèmes avec compose 1.5.0, veuillez inclure un exemple de .dockerignore et une structure de répertoire afin que nous puissions reproduire l'erreur.

Désolé de ne pas avoir fourni de cas d'utilisation plus petit, mais c'est ainsi que j'ai remarqué le problème:

J'ai ce package.json pour mon projet:

{
  "dependencies": {
    "grunt-contrib-uglify": "^0.9.2"
  }
}

De plus, j'ai ce docker-compose.yml :

web:
  build: .

Le Dockerfile ressemble à ceci:

FROM node:0.12

Mon .dockerignore contient une ligne (j'ai essayé d'ajouter une barre oblique à la fin, mais le problème a persisté):

node_modules

Maintenant je peux faire

> npm install
  (...snip...)
> docker build .
Sending build context to Docker daemon  5.12 kB

Génial, ça marche, seulement 5 Kio sont envoyés ( node_modules équivaut à environ 10 Mo au total). Avec docker-compose en Q:\sites\test :

> npm install
  (...snip...)
> docker-compose up
Building web
Traceback (most recent call last):
  File "D:\opt\python\Scripts\docker-compose-script.py", line 9, in <module>
    load_entry_point('docker-compose==1.5.0dev', 'console_scripts', 'docker-compose')()
  File "D:\opt\python\lib\site-packages\compose\cli\main.py", line 54, in main
    command.sys_dispatch()
  File "D:\opt\python\lib\site-packages\compose\cli\docopt_command.py", line 23, in sys_dispatch
    self.dispatch(sys.argv[1:], None)
  File "D:\opt\python\lib\site-packages\compose\cli\docopt_command.py", line 26, in dispatch
    self.perform_command(*self.parse(argv, global_options))
  File "D:\opt\python\lib\site-packages\compose\cli\main.py", line 170, in perform_command
    handler(project, command_options)
  File "D:\opt\python\lib\site-packages\compose\cli\main.py", line 583, in up
    detached=detached
  File "D:\opt\python\lib\site-packages\compose\project.py", line 313, in up
    detached=detached
  File "D:\opt\python\lib\site-packages\compose\service.py", line 404, in execute_convergence_plan
    container = self.create_container(do_build=do_build)
  File "D:\opt\python\lib\site-packages\compose\service.py", line 303, in create_container
    self.ensure_image_exists(do_build=do_build)
  File "D:\opt\python\lib\site-packages\compose\service.py", line 326, in ensure_image_exists
    self.build()
  File "D:\opt\python\lib\site-packages\compose\service.py", line 718, in build
    dockerfile=self.options.get('dockerfile', None),
  File "D:\opt\python\lib\site-packages\docker\api\build.py", line 48, in build
    context = utils.tar(path, exclude=exclude, dockerfile=dockerfile)
  File "D:\opt\python\lib\site-packages\docker\utils\utils.py", line 85, in tar
    t.add(os.path.join(root, path), arcname=path, recursive=False)
  File "D:\opt\python\lib\tarfile.py", line 1998, in add
    tarinfo = self.gettarinfo(name, arcname)
  File "D:\opt\python\lib\tarfile.py", line 1870, in gettarinfo
    statres = os.lstat(name)
WindowsError: [Error 3] Das System kann den angegebenen Pfad nicht finden: 'Q:\\sites\\test\\node_modules\\grunt-contrib-uglify\\node_modules\\maxmin\\node_modules\\pretty-bytes\\node_modules\\meow\\node_modules\\normalize-package-data\\node_modules\\validate-npm-package-license\\node_modules\\spdx-correct\\node_modules\\spdx-license-ids\\spdx-license-ids.json'

(J'utilise 1.5.0dev sur cette machine, mais j'ai exactement le même problème sur mon autre machine avec 1.5.0 final).

Avec node, je rencontre souvent des problèmes avec des chemins et des trucs trop longs sous Windows, mais le fait que Docker-Compose tente de tarer les node_modules est l'indicateur que le .dockerignore est ignoré.

FWIW, j'ai toujours des problèmes avec cela sous Linux (Ubuntu) avec docker-compose 1.5.0dev, donc il n'est probablement pas isolé de Windows. Cependant, c'est sur une machine de production, donc je ne peux pas facilement assembler un cas de test minimal (cela fonctionne bien sur ma machine de test).

J'ai aussi ce problème.

Structure du répertoire:

docker-compose.yml
web
  + .dockerignore
  + Dockerfile
  + node_modules
    + ...

docker-compose.yaml

web:
  build: web
  tty: true
  ports:
    - 8081:5000

Dockerfile

FROM microsoft/aspnet

# Curl, node, npm, bower, grunt
RUN apt-get update && apt-get install -y curl
RUN curl -sL https://deb.nodesource.com/setup | bash -
RUN apt-get install -y nodejs
RUN npm install -g bower
RUN npm install -g grunt-bower-cli
RUN npm install -g grunt
RUN npm install -g grunt-cli
RUN npm install -g grunt-bower-task

# Copy the project.json file first, then do a restore.
# This ensures that as long as project.json doesn't change, it will avoid
# doing a package restore
COPY project.json /app/
COPY bower.json /app/
COPY gruntfile.js /app/
COPY package.json /app/
WORKDIR /app

RUN ["dnu", "restore"]

# Then copy the rest of the files
COPY . /app

# Expose the port that the website listens on
EXPOSE 5000
# And start the website
ENTRYPOINT ["dnx", "-p", "project.json", "web"]

.dockerignore

node_modules

Résultat:

Pi<strong i="19">@Ricci</strong> MINGW64 /d/proj/Repro
$ docker-compose build
Building web
Traceback (most recent call last):
  File "<string>", line 3, in <module>
  File "C:\projects\compose\compose\cli\main.py", line 54, in main
  File "C:\projects\compose\compose\cli\docopt_command.py", line 23, in sys_dispatch
  File "C:\projects\compose\compose\cli\docopt_command.py", line 26, in dispatch
  File "C:\projects\compose\compose\cli\main.py", line 171, in perform_command
  File "C:\projects\compose\compose\cli\main.py", line 192, in build
  File "C:\projects\compose\compose\project.py", line 235, in build
  File "C:\projects\compose\compose\service.py", line 683, in build
  File "c:\projects\compose\venv\lib\site-packages\docker\api\build.py", line 48, in build
  File "c:\projects\compose\venv\lib\site-packages\docker\utils\utils.py", line 85, in tar
  File "c:\python27-x64\Lib\tarfile.py", line 2000, in add
  File "c:\python27-x64\Lib\tarfile.py", line 1872, in gettarinfo
WindowsError: [Error 3] The system cannot find the path specified: 'D:\\proj\\Repro\\web\\node_modules\\babel-preset-react\\node_modules\\babel-plugin-transform-react-jsx\\node_modules\\babel-helper-builder-react-jsx\\node_modules\\babel-types\\node_modules\\babel-traverse\\node_modules\\babel-code-frame\\node_modules\\js-tokens\\changelog.md'
docker-compose returned -1

+1

Quelqu'un a-t-il trouvé une solution de contournement? J'essaie de tout faire uniquement dans le Dockerfile, mais je n'ai pas encore eu de chance.

Je reçois également ce problème, pourrait-il être lié à la version du nœud que tout le monde utilise? Via ce problème: https://github.com/npm/npm/issues/3697 .. J'imagine que la mise à niveau du nœud (plus spécifiquement vers npm 3+) le corrigerait, mais c'est plus une option nucléaire, et .dockerignore devrait toujours travail.

Encore une fois, bien que cela soit apparemment ignoré, je le vois également sur une machine Linux.

J'ai résolu ce problème en supprimant une référence de volume inutile dans mon fichier docker-compose. Compose ignore .gitignore pour les volumes.

J'ai également dû mettre à niveau mon application pour utiliser npm 3+ .. mais cela ne peut s'appliquer qu'aux utilisateurs de Windows.

@ esc-rtn le fichier .dockerignore spécifie uniquement quels fichiers ne doivent pas être envoyés au démon pendant _build_. Si vous utilisez un volume monté en liaison pendant "l'exécution", il montera simplement tous les fichiers à cet emplacement en tant que volume (tous les fichiers présents sur l'hôte).

Je vois aussi la même chose, sous Windows: docker build fonctionne comme prévu, docker-compose pas.

J'ai mis un petit exemple sur GitHub, avec des notes dans le README.md: https://github.com/stekershaw/docker-compose-ignore

Une autre série de correctifs pour .dockerignore est entrée dans docker-py après la sortie de Compsoe 1.5.2. Pourriez-vous essayer la version Compose 1.6.0 RC2 pour voir si elle est corrigée maintenant?

Juste essayé avec la version 1.6.0rc2 de docker-compose, compilez a7636be.

J'ai trois cas de test dans mon repo et avec 1.5.2, deux d'entre eux ont échoué. Maintenant, avec 1.6.0rc2, un seul échoue, quand j'ai un répertoire et un fichier dans le répertoire exclus, comme ceci:

$ cat .dockerignore
files/test_dir
!files/test_dir/should_be_here_maybe

J'obtiens un comportement identique dans ce cas entre docker build et docker-compose build .

.dockerignore :

files/test_dir
!files/test_dir/should_be_here_maybe

docker-compose.yml :

test:
  build: .

Dockerfile :

FROM busybox
COPY . /context
CMD ["find", "/context"]

$ docker version
Client:
 Version:      1.10.0-rc1
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   677c593
 Built:        Fri Jan 15 18:17:17 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.10.0-rc1
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   677c593
 Built:        Fri Jan 15 18:17:17 2016
 OS/Arch:      linux/amd64

$ docker-compose version
docker-compose version 1.6.0rc2, build 695c692
docker-py version: 1.7.0-rc3
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1j 15 Oct 2014

$ mkdir -p files/test_dir
$ touch files/test_dir/should_be_here_maybe

$ find .
.
./.dockerignore
./docker-compose.yml
./Dockerfile
./files
./files/test_dir
./files/test_dir/should_be_here_maybe

$ docker build --no-cache -t 1607-docker-build .
Sending build context to Docker daemon  5.12 kB
Step 1 : FROM busybox
 ---> 0cb40641836c
Step 2 : COPY . /context
 ---> 859e12600100
Removing intermediate container 9067b263098b
Step 3 : CMD find /context
 ---> Running in 1ddc0a573492
 ---> b1b3beacf5f2
Removing intermediate container 1ddc0a573492
Successfully built b1b3beacf5f2

$ docker run 1607-docker-build
/context
/context/docker-compose.yml
/context/Dockerfile
/context/files
/context/files/test_dir
/context/files/test_dir/should_be_here_maybe
/context/.dockerignore

$ docker-compose build --no-cache
Building test
Step 1 : FROM busybox
 ---> 0cb40641836c
Step 2 : COPY . /context
 ---> d86507051d6d
Removing intermediate container 0af2cbf69b17
Step 3 : CMD find /context
 ---> Running in 8533dae3af74
 ---> 1f736ecb2b38
Removing intermediate container 8533dae3af74
Successfully built 1f736ecb2b38

$ docker-compose run test
/context
/context/docker-compose.yml
/context/Dockerfile
/context/files
/context/files/test_dir
/context/files/test_dir/should_be_here_maybe
/context/.dockerignore

Salut @aanand , merci pour votre réponse, j'obtiens le même résultat que vous en suivant vos pas.

Cependant, le test que j'ai effectué précédemment avait également un autre fichier présent dans files / test_dir. Si j'ajoute un autre fichier à files / test_dir alors je vois qu'il n'est pas présent (comme je m'y attendais) avec docker build mais il est présent avec docker-compose :

$ touch files/test_dir/should_not_be_here

$ docker build --no-cache -t 1607-docker-build .
Sending build context to Docker daemon  5.12 kB
Step 1 : FROM busybox
 ---> b175bcb79023
Step 2 : COPY . /context
 ---> a23d9645c21c
Removing intermediate container 8eb2bb23c4db
Step 3 : CMD find /context
 ---> Running in d9fef847acd8
 ---> e52ae84b1250
Removing intermediate container d9fef847acd8
Successfully built e52ae84b1250
SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories.

$ docker run --rm 1607-docker-build
/context
/context/Dockerfile
/context/files
/context/files/test_dir
/context/files/test_dir/should_be_here_maybe
/context/docker-compose.yml
/context/.dockerignore

$ docker-compose build --no-cache
Building test
Step 1 : FROM busybox
 ---> b175bcb79023
Step 2 : COPY . /context
 ---> 9df0cf4bfb69
Removing intermediate container 7820f982d59e
Step 3 : CMD find /context
 ---> Running in 06e1a0b89a45
 ---> 2c922dbc66d9
Removing intermediate container 06e1a0b89a45
Successfully built 2c922dbc66d9

$ docker-compose run test
ERROR: Interactive mode is not yet supported on Windows.
Please pass the -d flag when using `docker-compose run`.

$ docker-compose run -d test
dcitest_test_run_2

$ docker logs dcitest_test_run_2
/context
/context/Dockerfile
/context/files
/context/files/test_dir
/context/files/test_dir/should_not_be_here
/context/files/test_dir/should_be_here_maybe
/context/docker-compose.yml
/context/.dockerignore

Ceci est Windows (en utilisant git bash comme shell), vérifié avec les deux avec Docker compose 1.5.2 et 1.6.0rc2, docker 1.9.1.

Exécuter la même chose sur Ubuntu 14.04 avec docker-compose 1.5.2 et docker 1.9.1 est bien:

# cat .dockerignore
files/test_dir
!files/test_dir/should_be_here_maybe

# find .
.
./.dockerignore
./docker-compose.yml
./files
./files/test_dir
./files/test_dir/should_not_be_here
./files/test_dir/should_be_here_maybe
./Dockerfile

# docker-compose build --no-cache
Building test
Step 1 : FROM busybox
 ---> b175bcb79023
Step 2 : COPY . /context
 ---> c533a0768d5e
Removing intermediate container 0c057fe8eb82
Step 3 : CMD find /context
 ---> Running in e8a0cf1f58d8
 ---> 175777486a25
Removing intermediate container e8a0cf1f58d8
Successfully built 175777486a25

# docker-compose run test
/context
/context/docker-compose.yml
/context/.dockerignore
/context/files
/context/files/test_dir
/context/files/test_dir/should_be_here_maybe
/context/Dockerfile

Je m'occupe toujours de cela la plupart de l'après-midi.

Docker version 1.10.1, build 9e83765
docker-compose version 1.6.0, build d99cad6

#docker-compose.yml
test:
  build: ./cdn

#Dockerfile
FROM busybox
COPY ["content/","/test/"]
RUN find /test/ -maxdepth 1

#.dockerignore
**/.DS_Store
**/.git
**/.bowerrc
**/bower_components
**/node_modules
**/npm-debug.log

La sortie est comme prévu avec docker build .

docker-compose build --no-cache test copié sur tout

2992 a d'autres correctifs .dockerignore qui devraient être inclus dans 1.6.1

Merci @ shin-, malheureusement, je vois toujours un comportement différent avec docker-compose 1.6.2 de Docker Toolbox pour Windows:

$ docker-compose --version
docker-compose version 1.6.2, build e80fc83

$ find .
.
./.dockerignore
./docker-compose.yml
./Dockerfile
./files
./files/test_dir
./files/test_dir/should_be_here_maybe
./files/test_dir/should_not_be_here

$ cat .dockerignore
files/test_dir
!files/test_dir/should_be_here_maybe

$ docker-compose build --no-cache
Building test
Step 1 : FROM busybox
latest: Pulling from library/busybox
f810322bba2c: Pull complete
a3ed95caeb02: Pull complete
Digest: sha256:97473e34e311e6c1b3f61f2a721d038d1e5eef17d98d1353a513007cf46ca6bd
Status: Downloaded newer image for busybox:latest
 ---> 3240943c9ea3
Step 2 : COPY . /context
 ---> 85a65d7f861c
Removing intermediate container 386d3103d8ab
Step 3 : CMD find /context
 ---> Running in e5e29b5746c4
 ---> 2c2d57a899ea
Removing intermediate container e5e29b5746c4
Successfully built 2c2d57a899ea

$ docker-compose run -d test
dcitest_test_run_1

$ docker logs dcitest_test_run_1
/context
/context/Dockerfile
/context/files
/context/files/test_dir
/context/files/test_dir/should_be_here_maybe
/context/files/test_dir/should_not_be_here
/context/.dockerignore
/context/docker-compose.yml

C'est très étrange. Cela fonctionne vraiment pour moi.

$ docker-compose build --no-cache
Building web
Step 1 : FROM busybox
 ---> 3240943c9ea3
Step 2 : COPY . /context
 ---> 3619871879ad
Removing intermediate container 08432f688579
Step 3 : CMD find /context
 ---> Running in 5bbcf987c9e7
 ---> cf2bff2c1416
Removing intermediate container 5bbcf987c9e7
Successfully built cf2bff2c1416

$ docker-compose run -d web
Creating network "testdockerignore_default" with the default driver
testdockerignore_web_run_1

$ docker logs testdockerignore_web_run_1 
/context
/context/Dockerfile
/context/files
/context/files/test_dir
/context/files/test_dir/should_be_here
/context/docker-compose.yml
/context/.dockerignore

$ find .
.
./Dockerfile
./files
./files/test_dir
./files/test_dir/should_not_be_here
./files/test_dir/should_be_here
./docker-compose.yml
./.dockerignore

$ cat .dockerignore files/test_dir
!files/test_dir/should_be_here

Quelle est la sortie de pip show docker-py dans votre environnement?

Je crois que j'ai aussi le même problème.

 Docker build .

travaille pour moi. Cependant, inclure la même compilation dans un fichier docker-compose.yml rompt ma construction. Dans mon fichier .dockerignore, j'exclus le répertoire node_modules pour ma construction de nœud. Voici la section pertinente de mon docker-compose.yml:

web:
  build: ./app
  ports:
    - "8080:8080"
  links:
    - mongodb

Je crois que j'utilise la version la plus récente de docker-compose:

>docker-compose version
docker-compose version 1.6.2, build e80fc83
docker-py version: 1.7.2
CPython version: 2.7.11
OpenSSL version: OpenSSL 1.0.2d 9 Jul 2015

J'utilise Windows 10, x64.

Problème spécifique à Windows, peut-être avec les séparateurs de chemin?

Je ne sais pas comment dire si cela est lié aux séparateurs de chemin.

Faites-moi savoir si je peux vous aider avec les tests ou autrement. En ce moment, j'ai un fichier batch qui déplace les dossiers "ignorés" hors du répertoire du projet avant la construction, évidemment moche.

Merci de votre aide.

Par souci d'exhaustivité, voici mon fichier .dockerignore:

**/node_modules

Ah! C'est le modèle global qui pose le problème. la suppression du "** /" a résolu le problème pour moi.

Bien que j'aie une solution de contournement pour mon problème spécifique, le fait demeure qu'il y a un bogue. À tout le moins, le modèle glob ** / n'est pas correctement analysé avec docker-compose, mais fonctionne bien avec la commande de construction docker standard. D'autres modèles globaux peuvent ou non fonctionner.

@bfirsh et tous les autres qui pourraient s'en soucier:

J'ai un .dockerignore absolument simple qui ressemble à ceci:

livedata
readonly-data

Le .dockerignore ne fonctionne pas non plus (ces deux dossiers dans le dossier de contexte de construction sont téléchargés vers le démon et cela prend _forever_) et je suis sous Linux . J'ai mis à jour juste à la version 1.6.2 actuelle, aucun changement. Sauf si je vois un problème différent avec le même symptôme, permettez-moi de répéter _à nouveau_ que cela ne semble pas être un problème spécifique à Windows.

+1, également cassé pour moi sous Linux - ne pense pas que ce soit un problème spécifique à Windows.

@JonasT @nicbarker Comment confirmez-vous que les dossiers nommés dans .dockerignore sont en cours de téléchargement, mis à part le fait que cela prend beaucoup de temps? Si vous avez un moyen de vérifier l'archive tar, j'aimerais essayer de l'utiliser pour reproduire le problème localement. Dans l'état actuel des choses, j'ai ajouté un débogage à docker-py et je suis toujours incapable de reproduire:

$ pip list | grep docker
docker-compose (1.7.0.dev0, /Users/aanand/work/docker/compose)
docker-py (1.8.0rc2, /Users/aanand/work/docker/docker-py)

$ find .
.
./.dockerignore
./docker-compose.yml
./Dockerfile
./include.txt
./livedata
./livedata/exclude.txt
./readonly-data
./readonly-data/exclude.txt

$ cat .dockerignore
livedata
readonly-data

$ cat Dockerfile
FROM busybox
COPY . /data

$ docker-compose --verbose build --no-cache
<unrelated output>
docker.utils.utils.tar: Writing tar file to <open file '<fdopen>', mode 'w+b' at 0x1090f26f0>
docker.utils.utils.tar:   Adding .dockerignore
docker.utils.utils.tar:   Adding Dockerfile
docker.utils.utils.tar:   Adding docker-compose.yml
docker.utils.utils.tar:   Adding include.txt
docker.utils.utils.tar: Done
<unrelated output>

@aanand cela prend VRAIMENT longtemps avant de démarrer, et lorsque je déplace le Dockerfile vers ./context et que j'utilise "build: ./context/" sans autre changement, il est instantanément extrêmement rapide. Aussi à l'époque, lorsque ce problème est apparu pour la première fois, j'ai essayé de construire manuellement le docker avec "docker build" et c'était également instantané.

Cela ne confirme pas vraiment le problème. S'il y avait un autre grand répertoire dans la racine du projet, déplacer la compilation vers ./context le rendrait plus rapide.

@dnephin, il n'y a pas d'autres dossiers à l'exception du "contexte" lui-même que j'ai ajouté comme solution de contournement, et trois petits fichiers texte.

@JonasT Est-il possible que vous ayez un grand répertoire .git qui sera inclus?

Edit: NVM, il semble que j'étais en fait assez stupide pour manquer un répertoire parce que j'ai vérifié le mauvais rsync'ed copy>.> Désolé les gars ..

J'ai en fait eu un problème avec cela il y a quelque temps sur une ancienne version de docker-compose où je l'ai étudié plus en profondeur, mais peut-être que l'instance spécifique que j'avais a été en fait corrigée avec certaines des dernières mises à jour de dockerpy.

Revenir à ceci étant un problème Windows? :)

salut,
J'ai Linux, compose 1.6.2, docker 1.10.3 ... exactement le même problème. docker utilise .dockerignore , compose l'ignore.

@ulrichSchreiner Pouvez-vous fournir des étapes pour reproduire?

salut,

voici l'essentiel (https://gist.github.com/ulrichSchreiner/566815cea26ce55b95207e7795cf6962). le .dockerignore contient **/node_modules le Dockerfile ajoute un fichier dans un sous-dossier t1/a/b/c/node_modules .

si vous construisez ceci avec "docker build ..." vous obtenez une erreur car il n'y a aucun fichier à ajouter (il est correctement ignoré à cause du modèle dans .dockerignore ). vous pouvez voir la sortie dans le dernier fichier de l'essentiel.

mais si vous le construisez avec le "docker-compose.yml" donné, il est construit avec succès -> docker-compose ignore le fichier .dockerignore .

et c'est vraiment pénible quand votre répertoire node_modules fait des centaines de Mo ...

j'utilise

docker-compose version 1.6.2, build 4d72027

OK, je peux reproduire cela. On dirait que docker-py a probablement un bogue avec les règles **/ .

IIRC, le manque de support pour la syntaxe ** est une limitation connue de notre implémentation .dockerignore . Voir https://github.com/docker/docker-py/pull/721#issuecomment -135065043

Même problème ici. .dockerignore est ignoré lorsqu'il est utilisé avec docker-compose
docker-compose version 1.6.2, build 4d72027 OSX

./.dockerignore
./Dockerfile (symlink to ./server/docker/cms/Dockerfile)
./server/docker/docker-compose.yml

Contenu de .dockerignore

./.git
./.vagrant

.vagrant fait 16 Go, c'est donc un "Big Deal (tm)" pour nous.

Désolé,

docker-machine version 0.7.0, build a650a40

docker-compose version 1.7.0, build 0d7bf73
docker-py version: 1.8.0
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1j 15 Oct 2014

Client:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Tue Apr 26 23:44:17 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Wed Apr 27 00:34:20 2016
 OS/Arch:      linux/amd64

@lattwood On dirait un bogue - je l'ai corrigé dans https://github.com/docker/docker-py/pull/1065. Pour l'instant, vous pouvez supprimer le premier ./ de vos modèles et cela devrait fonctionner.

Merci!

Fonctionnant sous Ubuntu 14.04, mon dockerignore est simplement **/always_restart.txt . Sur un docker build (v1.11.2) normal, je ne vois pas le fichier dans le conteneur, mais avec Compose (v1.7.1), je le fais.

Edit1: On dirait que docker-py ne teste pas la notation double astérisque et je suppose qu'il ne le gère probablement pas non plus: https://github.com/docker/docker-py/blob/1.9. 0-release / tests / unit / utils_test.py # L721

Edit2: l'utilisation du modèle */tmp/always_restart.txt fonctionne avec Compose, donc le modèle ** est spécifiquement ignoré

@ agilgur5 Correct, il s'agit d'un problème connu avec docker-py. J'ai créé https://github.com/docker/docker-py/issues/1117 pour le suivre.

Notre vilaine solution de contournement dans le DOCKERFILE:
En utilisant git-check-ignore pour l'analyse (nécessitant donc git init ), nous supprimons simplement tout ce qui devrait être ignoré après la copie.
Notez que dans notre cas, cela devait être après tout COPY s (ou ADD s), sinon nous avons à nouveau des fichiers indésirables.

RUN mkdir /app/
WORKDIR   /app/
# ...
# all the COPYs
# ...
RUN git init
COPY ./.dockerignore /app/
RUN mv .dockerignore .gitignore
RUN DEL_ME=$(find . -print0 | xargs -0) && echo Forcing deletion of .dockerignore files && git check-ignore --no-index $DEL_ME > tmp.txt
RUN DEL_ME=$(cat tmp.txt | xargs) && echo DELETING: $DEL_ME tmp.txt && rm -f -d -r $DEL_ME tmp.txt

Pour supprimer également des fichiers du .gitignore (car pourquoi pas)

COPY ./.gitignore      /app/
COPY ./.dockerignore   /app/
RUN DEL_ME=$(find . -print0 | xargs -0) && echo gitignore && git check-ignore --no-index $DEL_ME > tmp.txt
RUN rm .gitignore && mv .dockerignore .gitignore
RUN DEL_ME=$(find . -print0 | xargs -0) && echo dockerignore && git check-ignore --no-index $DEL_ME >> tmp.txt
RUN DEL_ME=$(cat tmp.txt | xargs) && echo DELETING: DEL_ME tmp.txt && rm -f -d -r $DEL_ME tmp.txt

Je pense avoir trouvé une solution de contournement pour cela en utilisant des volumes de données dans docker-compose.yml , en énumérant essentiellement les répertoires de conteneurs que vous ne voulez pas écraser. Dans notre cas, nous voulions conserver le répertoire node_modules dans le conteneur.

Donc, notre docker-compose.yml ressemble à ceci:

  my_app:
    build: ./my_app
    volumes:
      - ./my_app:/app
      # prevent the mounting above from overwriting the following
      - /app/node_modules

La volumes duplique ce qui est dans .dockerignore mais cela nous permet de continuer pour le moment ...

J'ai une suggestion de haut niveau pour ce problème:

Je recommanderais de renommer ce problème en quelque chose comme, "[meta issue]: mauvaise gestion des règles .dockerignore" (ou "[tracking issue]: incorrect handling ..."), ou bien simplement fermer ce problème en faveur d'une collection des problèmes plus petits et plus exploitables. C'est parce que (1) ce n'est pas que Docker compose "ignore" le fichier .dockerignore (ce que dit actuellement le titre du numéro). Il n'a tout simplement pas mis en œuvre les règles correctement. Et (2), il y a un certain nombre de parties à ce problème. Ce n'est pas seulement un problème. Par exemple, il y a celui-ci (traitement ** ) et ce nouveau que je viens de déposer (priorité de dernière ligne). Et il y en a peut-être plus.

Étant donné que ce thread de problème est si long (car il couvre une vaste zone de problème), les problèmes individuels qui doivent être résolus sont difficiles à localiser dans le thread. Par opposition à un problème général ".dockerignore ne semble pas fonctionner", je suggère de déposer des problèmes bien définis qui peuvent être résolus isolément. Tel qu'il est actuellement formulé, ce problème peut ne jamais être résolu car l'implémentation Python pourrait ne jamais être paritaire avec l'implémentation de référence.

J'ai utilisé **/**/node_modules mais j'ai découvert que celui-ci ne fonctionnait pas. J'ai donc défini chaque répertoire node_modules dans mes sous-projets pour corriger ce bogue.

Avant ce correctif, j'avais une "erreur de droit d'accès" lors de l'installation des dépendances npm car elles étaient déjà là (causées par la copie avec un fichier dockerignore ne fonctionnant pas).

Même problème.

macOS Sierra 10.12.2
Docker version 1.12.5, build 7392c3b
docker-compose version 1.9.0, build 2585387

Le problème de modèle ** devrait être corrigé dans 1.11.2
Il y a des problèmes en suspens possibles comme celui avec la priorité de dernière ligne, qui sont suivis séparément dans # 3931 et # 3886. Veuillez vous référer à ceux-ci pour d'autres mises à jour.

Je ne sais pas si docker-compose ignore mon .dockerignore ou s'il ne l'interprète pas correctement (contrairement à docker qui fonctionne très bien). voici comment j'ai atterri ici: http://stackoverflow.com/questions/42883596/equivalent-builds-dont-behave-the-same

et voici mon fichier .dockerignore (au cas où vous pourriez repérer le problème):

$ cat .dockerignore 
*
!www
!app
!inc
*/node_modules
*/bower_components
**/*.log
**/Dockerfile
**/.gitignore

Il semble que mon docker-compose build ignore complètement le fichier .dockerignore .
docker build fonctionne comme prévu.

$ docker-compose version                                                                                                                       
docker-compose version 1.14.0, build c7bdf9e
docker-py version: 2.3.0
CPython version: 2.7.13
OpenSSL version: OpenSSL 1.0.1t  3 May 2016

Mon .dockerignore ressemble à ceci

.bundle
.git
.gitignore
test
tmp
log

donc rien de spécial ici.
J'utilise Ubuntu 16.04 mais je ne sais pas si cela compte.

BTW: Quelqu'un peut-il expliquer pourquoi docker-compose build n'utilise pas le même code que docker build pour créer une image en utilisant Dockerfile et tout ça? Pourquoi y a-t-il une duplication de code évidente (qui ne fonctionne pas vraiment bien comme le montre ce problème)?

pourquoi ce numéro a-t-il été fermé et comment le rouvrir? le logiciel est clairement cassé et doit être corrigé

https://github.com/docker/compose/issues/1607#issuecomment -287177186

ah. merci shin. heureux qu'il soit traité

J'ai lu les numéros # 3931 et # 3886 comme suggéré, mais mon .dockerignore n'est pas spécial, donc je n'ai pas pu cartographier exactement mon problème.
Je ne travaille pas du tout pour moi et ce n'est pas grave, ce qui est dans mon .dockerignore.

Tellement stupide, c'était mon erreur.: Dizzy_face:
J'ai monté mon code sous forme de volume donc il est clair qu'il n'y a rien d'ignoré. Désolé.

app:
  build: .
  container_name: my_app
  volumes:
    - .:/my_app

cela ne semble pas résolu?

version: '3.4'
services:
  ui:
    build:
      context: ./source/ui
      dockerfile: Dockerfile
      target: development
    command: bash -c "yarn dev"
    ports:
      - '9091:9091'
      - '9092:9092'
    expose:
      - '9091'
      - '9092'
    volumes:
      - ./source/ui:/app
      - node-modules:/app/node_modules

    environment:
      - PORT=9091
      - HMR_PORT=9092
      - NODE_ENV=development
      - API_HOST=api.docker:7001

volumes:
  node-modules:

in source/ui/.dockerignore:

node_modules
dist
''

mais les deux dossiers finissent par être créés de toute façon ...

J'ai eu le même problème. juste au moment où j'ai remarqué que j'étais sur une ancienne version de composition. Mis à jour à docker-compose version 1.22.0-rc1, build e7de1bc3 .

Le problème est que la version de composition livrée avec debian / ubuntu est trop ancienne.

Maintenant, cela fonctionne mieux, mais toujours pas la même chose que docker build

Ceci n'est toujours pas résolu. Exécution de Docker pour Mac, dernière version (Docker 18.03.1-ce-mac65).

Mon .dockerignore:

**/package-lock.json
**/node_modules

mais les deux sont passés dans le conteneur lors de l'utilisation de docker-compose.

https://github.com/docker/docker-py/pull/2065 est dans 1.22.0 RC2 et devrait résoudre ce problème.

J'utilise Docker pour Mac Version 18.06.1-ce-mac73 (26764) et le bogue est toujours là.

J'utilise:

docker-compose version 1.22.0, build f46880f
Docker version 18.06.1-ce, build e68fc7a

s'exécutant sur Ubuntu 16.04 Xenial et docker-compose build ignore le .dockerignore suivant:

**/*.jpg **/*.png **/*.pyc **/*.solverstate **/*.caffemodel **/*.tgz **/.pytest_cache **/*__pycache__* **/.git **/node_modules *.egg-info .eggs *Dockerfile* build dist
Comme il est censé maintenant interpréter les doubles astérisques, je ne sais pas quelle peut en être la cause. Quelqu'un avec le même problème?

Comme il est censé maintenant interpréter les doubles astérisques, je ne sais pas quelle peut en être la cause. Quelqu'un avec le même problème?

J'ai le même problème (avec **/.tox ).

J'ai eu le même problème. J'utilise différents contextes.
docker-compose.yml est placé sur le chemin racine de l'application et ressemble à

services:
  api:
    build:
      context: ./docker/api

Mon arborescence de fichiers:

- app/
-- docker/
--- api/
---- .dockerignore <- it works!
-- docker-compose.yml
-- .dockerignore <- it does not work for contexts

Bonne journée!

@ zymtx5g79k Cela ne fonctionne pas pour moi.

Structure du répertoire:

- .dockerignore
- docker/
-- development/
--- docker-compose.yml  

docker-compose.yml

version: '3'
services:
  web:
    build:
      context: ../../.

@rodrigobdz , vérifiez s'il vous plaît:
docker-compose.yml :

services:
  api:
    build:
      context: ./../../
version: '3'

.dockerignore :

/docker

Structure des fichiers :

- docker/
-- api/
--- docker-compose.yml
- .dockerignore

Toujours le même résultat, le répertoire .git est dans le conteneur par exemple. Je posterai ici mon .dockerignore. Il y a peut-être un problème en soi.

# Custom
docker-compose.yml
docs/
livereload.js*
yarn-error.log
v8-compile-cache-0
# vim
*.swp

.git
.gitignore
README.md

@rodrigobdz Je ne parviens pas à reproduire le problème (exécutant docker compose la version 1.22.0);

Préparez le test;

mkdir repro-1607 && cd repro-1607
mkdir -p docker/development/
mkdir -p ./.git/this-is-a-git-repo
echo "this is README.md" > README.md

cat > docker/development/docker-compose.yml -<<EOF
version: '3'
services:
  web:
    build:
      context: ../../.
EOF

cat > ./.dockerignore -<<EOF
# Custom
docker-compose.yml
docs/
livereload.js*
yarn-error.log
v8-compile-cache-0
# vim
*.swp

.git
.gitignore
README.md
EOF

cat > Dockerfile -<<EOF
FROM alpine
RUN apk add --no-cache tree
COPY . /foobar/
CMD tree -a /foobar/
EOF

Construire en utilisant docker-compose;

cd docker/development/
docker-compose build --no-cache

Building web
Step 1/4 : FROM alpine
 ---> 11cd0b38bc3c
Step 2/4 : RUN apk add --no-cache tree
 ---> Running in 8767bc07dad9
fetch http://dl-cdn.alpinelinux.org/alpine/v3.8/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.8/community/x86_64/APKINDEX.tar.gz
(1/1) Installing tree (1.7.0-r1)
Executing busybox-1.28.4-r0.trigger
OK: 5 MiB in 14 packages
Removing intermediate container 8767bc07dad9
 ---> 3916d3b689bb
Step 3/4 : COPY . /foobar/
 ---> 76ab68d75f88
Step 4/4 : CMD tree -a /foobar/
 ---> Running in 9891624b3cab
Removing intermediate container 9891624b3cab
 ---> d22b81d149f2
Successfully built d22b81d149f2
Successfully tagged development_web:latest

Et vérifiez que le contenu n'est pas ajouté;

docker run --rm development_web:latest
/foobar/
├── .dockerignore
├── Dockerfile
└── docker
    └── development
        └── docker-compose.yml

2 directories, 3 files

Maintenant, renommez le .dockerignore et recommencez la construction;

mv ../../.dockerignore ../../.dockerignore.disabled
docker-compose build --no-cache

Building web
Step 1/4 : FROM alpine
....

Vérifiez que le contenu n'est plus ignoré et ajouté à l'image:

docker run --rm development_web:latest
/foobar/
├── .dockerignore.disabled
├── .git
│   └── this-is-a-git-repo
├── Dockerfile
├── README.md
└── docker
    └── development
        └── docker-compose.yml

4 directories, 4 files

(modifier: sortie mise à jour de la première exécution, car j'ai oublié d'exécuter tree avec -a la première fois)

@thaJeztah Merci d'avoir pris le temps de l'examiner. J'ai trouvé le problème.

Mon cas d'utilisation est similaire à celui décrit dans https://github.com/docker/compose/issues/2098#issue -108463351. J'utilise une commande COPY dans mon Dockerfile et en plus, je monte le même répertoire en tant que volume .

Je m'attendais à ce que les exclusions de .dockerignore soient appliquées au volume, comme décrit dans https://github.com/docker/compose/issues/2098#issuecomment -143505943.

Je m'attendais à ce que les exclusions de .dockerignore soient appliquées au volume, comme décrit dans # 2098 (commentaire).

Non, lors du montage en liaison d'un chemin à partir de l'hôte, le docker ne sera pas "au milieu" de cela; sous Linux, il monte littéralement ce répertoire à partir de l'hôte à l'intérieur du conteneur. Sur Docker Desktop (Docker pour Mac / Windows), il y a une "magie" supplémentaire impliquée pour rendre ces fichiers disponibles à l'intérieur de la VM où le démon (et le conteneur) s'exécute, mais essentiellement il fait la même chose que sur Linux après cela.

.dockerignore n'est utilisé que pendant la construction, et était destiné à accélérer les versions; pour éviter d'avoir à envoyer des fichiers au démon qui ne sont pas utilisés / souhaités dans l'image.

Merci pour la clarification! Je considère que cette explication devrait être dans la documentation pour éviter de nouveaux malentendus dans la communauté. Actuellement, la documentation se concentre davantage sur la façon d'ignorer les fichiers que sur la portée de .dockerignore elle-même.

Cette page de la documentation décrit le Dockerfile et docker build ; de ce point de vue; se demandant s'il serait logique de décrire que cela ne fonctionne pas pour d'autres commandes / utilisations.

Eh bien, si c'est une source courante de malentendu, et c'est évidemment le cas, il serait certainement logique de la mentionner ici.

Une seule phrase dans la documentation nous aurait fait gagner beaucoup de temps à @thaJeztah , et à tous les utilisateurs ci-dessous.

Édition 1607

Édition 2098

Je voulais juste attribuer +1 à ce problème.

J'utilise docker-copose: 1.23.2 (le plus récent que j'ai pu trouver entre Homebrew et PIP)
Système d'exploitation: Mac OS 10.14.2

Il ignore toujours mon .dockerfile lors de la construction. Je vais devoir copier les choses explicitement dans l'intervalle.

J'ai résolu ce problème en supprimant une référence de volume inutile dans mon fichier docker-compose. Compose ignore .gitignore pour les volumes.

Cela a résolu le problème pour moi - docker-compose ignorera un fichier .dockerignore dans un volume monté.

@xvrqt J'ai probablement perdu des heures la semaine dernière à avoir des erreurs aléatoires avec mon fichier de configuration mal copié (mon processus de construction est censé le copier mais il était bloqué par le fichier .dockerignore non utilisé). C'est assez incroyable.

Merci d'avoir souligné cela.

Salut! Quel est le statut de cela? J'ai préparé des scénarios docker-compose.yml très simples qui n'impliquent pas de volumes et pourtant, il ne parvient pas à récupérer .dockerignore lors de la construction à partir du dépôt git distant.

https://github.com/LocoDelAssembly/docker-compose-dockerignore

L'erreur que j'ai dans la branche principale est-elle attendue? Y a-t-il des solutions autres que la construction et le balisage de l'image avec docker vanilla, puis son utilisation dans docker-compose.yml?

Merci

Y a-t-il des solutions autres que la construction et le balisage de l'image avec docker vanilla, puis son utilisation dans docker-compose.yml?

Si vous exécutez la version actuelle de compose, vous pouvez utiliser les options COMPOSE_DOCKER_CLI_BUILD=1 (et DOCKER_BUILDKIT=1 ) pour que docker compose utilise le natif docker build .

Votre exemple semble différent de celui dont il est question ici, il serait donc bon d'ouvrir un nouveau ticket (s'il n'y en a pas encore pour cela)

Merci @thaJeztah! Fonctionne avec COMPOSE_DOCKER_CLI_BUILD=1 , mais si j'ajoute également DOCKER_BUILDKIT=1 cela échoue (pour une raison indépendante).

https://travis-ci.org/LocoDelAssembly/docker-compose-dockerignore/builds/658351109

Hm, je soupçonne que c'est un bogue dans la version de docker qui fonctionne là-bas; docker 18.06 est assez vieux (et EOL); cette version de docker a une version assez ancienne de BuildKit, qui n'était pas encore stable.

''
=> ERREUR [interne] charger les métadonnées pour docker.io/library/alpine:3.9.5 0.1s
218 => ERREUR [1/5] FROM docker.io/library/alpine:3.9.5 0.0s
219 => => résoudre docker.io/library/alpine:3.9.5 0.0s
220 ------
221> [interne] charger les métadonnées pour docker.io/library/alpine:3.9.5:
222 ------
223 ------
224> [1/5] DE docker.io/library/ alpin: 3.9.5 :
225 ------
226 échec de résolution avec le frontend dockerfile.v0: échec de la construction de LLB: échec du chargement de la clé de cache: docker.io/library/ alpine: 3.9.5 introuvable

Oh, hm, je vois que votre travis installe également le docker (en lisant sur mon téléphone); est-ce que cela remplace la version préinstallée? Si vous ajoutez une étape docker info et docker version après l'installation, la version correcte (19.03.x) du docker à installer est-elle affichée?

Le voici https://travis-ci.org/LocoDelAssembly/docker-compose-dockerignore/builds/658435194

Sommaire

Version Docker pour les deux versions ayant échoué

$ docker version
Client: Docker Engine - Community
 Version:           19.03.7
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        7141c199a2
 Built:             Wed Mar  4 01:22:36 2020
 OS/Arch:           linux/amd64
 Experimental:      false
Server: Docker Engine - Community
 Engine:
  Version:          19.03.7
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       7141c199a2
  Built:            Wed Mar  4 01:21:08 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

docker info sortie de Server Version: 19.03.7 .

versions de docker-compose

DOCKER_COMPOSE_VERSION = 1.26.0-rc2

$ docker-compose version
docker-compose version 1.26.0-rc1, build 07cab513
docker-py version: 4.2.0
CPython version: 3.7.6
OpenSSL version: OpenSSL 1.1.0l  10 Sep 2019

(La version signalée est incorrecte, c'est rc2, le hachage de construction correspond à rc2)

DOCKER_COMPOSE_VERSION = 1,25,4

$ docker-compose version
docker-compose version 1.25.4, build 8d51620a
docker-py version: 4.1.0
CPython version: 3.7.5
OpenSSL version: OpenSSL 1.1.0l  10 Sep 2019

Problème toujours existant en 19.03.8.

Problème toujours existant en 19.03.8.

Correct. J'ai également mis à jour mon dépôt de test avec les dernières versions de docker-compose 1.25 et 1.26, mais tout continue d'être comme décrit dans https://github.com/LocoDelAssembly/docker-compose-dockerignore

Build où le même type d'informations que j'ai collé ci-dessus peut être trouvé: https://travis-ci.org/github/LocoDelAssembly/docker-compose-dockerignore/builds/673393656

J'ai le même problème ici, .dockerignore ne fonctionne pas de manière fiable avec docker-compose