Tiene un problema con el formato de archivo.

En su .dockerignore cambie subdir/ a subdir .

¿Por qué .dockerignore funciona para docker build -t subdir ../ pero no para docker-compose build ?

Tengo el mismo problema al ejecutar docker-compose 1.2.0.
Al ejecutar vanilla docker build, se extrae el archivo ignorado y se genera la imagen, np allí.
Sin embargo, docker-compose no usa el archivo ignorar, con o sin la barra diagonal.

Parece un problema de Docker-Py; se está trabajando en una solución en https://github.com/docker/docker-py/pull/604. Marcar esto como un error para recordarnos que actualicemos nuestra versión de docker-py una vez que se haya solucionado.

@aanand parece que https://github.com/docker/docker-py/pull/604 se detuvo y se eliminó del hito allí.

@thaJeztah He creado https://github.com/docker/docker-py/pull/721 para continuar el trabajo.

Hola,

Me enfrento a un extraño problema con .dockerignore:

*.sh

!awesome/script.sh

con docker build todo está bien, pero docker-compose no vio "awesome / script.sh"

¿Estoy en el mismo problema?

@twillouer es un error conocido, corregido por https://github.com/docker/docker-py/pull/721 ; se solucionará en el lado de Redactar en 1.5.0.

Gracias !

Esto todavía parece estar roto incluso en el último git master en algunas máquinas. No me funciona en una máquina dada esta configuración:

Debian 8.2 con kernel 3.16.0 con lxc-docker versión 1.7.1, compilación 786b29d
docker-compose es git master, HEAD está en dabf1e8657674014a5bc89f99edbf2fe0629bb71

El .dockerignore funciona bien para la compilación de docker (que se ejecuta instantáneamente), pero no para la compilación de docker (que carga cosas que no debería cargar durante varios minutos).

Vea también el n. ° 2100

Yo tengo el mismo problema. docker-compose ignora ".dockerignore". "Docker build" funciona bien.
Sistema: Windows 10

Estoy experimentando el mismo problema al usar Docker Toolbox que se lanzó ayer:

• Windows 7 x64
• Docker versión 1.9.0, compilación 76d6bc9
• Docker-Compose 1.5.0

Parece que todavía tenemos problemas con .dockerignore . Si tiene estos problemas con compose 1.5.0, incluya una muestra .dockerignore y una estructura de directorio para que podamos reproducir el error.

Lo siento por no proporcionar un caso de uso más pequeño, pero así es como noté el problema:

Tengo este package.json para mi proyecto:

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

Además tengo esto docker-compose.yml :

web:
  build: .

El Dockerfile ve así:

FROM node:0.12

Mi .dockerignore contiene una línea (intenté agregar una barra al final, pero el problema persistió):

node_modules

Ahora puedo hacer

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

Impresionante, funciona, solo se envían 5 KiB ( node_modules son aproximadamente 10 MiB en total). Con 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'

(Estoy usando 1.5.0dev en esta máquina, pero tengo exactamente el mismo problema en mi otra máquina con 1.5.0 final).

Con el nodo, a menudo encuentro problemas con rutas demasiado largas y otras cosas en Windows, pero el hecho de que Docker-Compose esté intentando cargar los módulos de nodo es un indicador de que se ignora el .dockerignore .

FWIW, todavía tengo problemas con esto en Linux (Ubuntu) con docker-compose 1.5.0dev, por lo que probablemente no esté aislado en Windows. Sin embargo, está en una máquina de producción, por lo que no puedo armar fácilmente un caso de prueba mínimo (funciona bien en mi máquina de prueba).

Yo tambien estoy teniendo este problema.

Estructura de directorios:

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

Resultado:

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

¿Alguien encontró una solución? Estoy tratando de hacer todo solo en el Dockerfile, pero aún no he tenido suerte.

También tengo este problema, ¿podría estar relacionado con la versión de nodo que todos están ejecutando? A través de este problema: https://github.com/npm/npm/issues/3697 .. Me imagino que actualizar el nodo (más específicamente a npm 3+) lo solucionaría, pero esa es más una opción nuclear, y .dockerignore aún debería trabajo.

Una vez más, a pesar de que aparentemente esto se ha ignorado, también lo veo en una máquina Linux.

Solucioné este problema eliminando una referencia de volumen innecesaria en mi archivo docker-compose. Compose ignora .gitignore para los volúmenes.

También tuve que actualizar mi aplicación para usar npm 3+ ... pero eso solo puede aplicarse a usuarios de Windows.

@ esc-rtn el archivo .dockerignore solo especifica qué archivos no deben enviarse al demonio durante _build_. Si está utilizando un volumen montado en enlace durante la "ejecución", simplemente montará todos los archivos en esa ubicación como un volumen (todos los archivos que están presentes en el host).

También veo algo similar en Windows: docker build funciona como se esperaba, docker-compose no.

He puesto un pequeño ejemplo en GitHub, con notas en README.md: https://github.com/stekershaw/docker-compose-ignore

Otra ronda de correcciones para .dockerignore entró en docker-py después de que se lanzó Compsoe 1.5.2. ¿Podrías probar la versión Compose 1.6.0 RC2 para ver si está arreglada ahora?

Intenté con la versión 1.6.0rc2 de docker-compose, compilación a7636be.

Tengo tres casos de prueba en mi repositorio y con 1.5.2 dos de ellos fallaron. Ahora con 1.6.0rc2 solo uno falla, cuando tengo un directorio y un archivo en el directorio excluido, así:

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

En ese caso, obtengo un comportamiento idéntico entre docker build y 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

Hola @aanand , gracias por tu respuesta, obtengo el mismo resultado si sigues tus pasos.

Sin embargo, la prueba que ejecuté anteriormente también tenía otro archivo presente en files / test_dir. Si agrego otro archivo a files / test_dir, veo que no está presente (como sería de esperar) con docker build pero sí con 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

Esto es Windows (usando git bash como mi shell), verificado con Docker compose 1.5.2 y 1.6.0rc2, docker 1.9.1.

Ejecutar lo mismo en Ubuntu 14.04 con docker-compose 1.5.2 y 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

Sigo lidiando con esto la mayor parte de la tarde.

Docker versión 1.10.1, compilación 9e83765
docker-compose versión 1.6.0, compilación 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 salida es la esperada con docker build .

docker-compose build --no-cache test copiado sobre todo

2992 tiene algunas correcciones más .dockerignore que deberían incluirse en 1.6.1

Gracias @ shin-, desafortunadamente todavía veo un comportamiento diferente con docker-compose 1.6.2 de Docker Toolbox para 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

Eso es muy extraño. Definitivamente funciona para mí.

$ 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

¿Cuál es la salida de pip show docker-py en su entorno?

Creo que también tengo el mismo problema.

 Docker build .

funciona para mi. Sin embargo, incluir la misma compilación en un archivo docker-compose.yml rompe mi compilación. En mi archivo .dockerignore, estoy excluyendo el directorio node_modules para la compilación de mi nodo. Esta es la sección relevante de mi docker-compose.yml:

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

Creo que estoy ejecutando la versión más reciente 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

Estoy usando Windows 10, x64.

Problema específico de Windows, ¿tal vez con los separadores de ruta?

No sé cómo saber si esto está relacionado con los separadores de ruta.

Hágame saber si puedo ayudar con la prueba o de otra manera. En este momento, tengo un archivo por lotes que mueve las carpetas "ignoradas" fuera del directorio del proyecto antes de la compilación, obviamente feo.

Gracias por tu ayuda.

En aras de la integridad, este es mi archivo .dockerignore:

**/node_modules

¡Ajá! Es el patrón global el que está causando el problema. quitar el "** /" solucionó el problema para mí.

Si bien tengo una solución para mi problema específico, el hecho es que hay un error. Como mínimo, el patrón glob ** / no se analiza correctamente con docker-compose, pero funciona bien con el comando de compilación de docker normal. Otros patrones glob pueden funcionar o no.

@bfirsh y todos los demás a quienes les pueda importar:

Tengo un .dockerignore absolutamente simple que se ve así:

livedata
readonly-data

El .dockerignore tampoco funciona (esas dos carpetas en la carpeta de contexto de compilación se cargan en el demonio y toma _forever_) y estoy en Linux . Actualicé solo a la 1.6.2 actual, sin cambios. A menos que vea un problema diferente con el mismo síntoma, permítanme reiterar _ una vez más_ que esto no parece ser un problema específico de Windows.

+1, también roto para mí en Linux, no creo que sea un problema específico de Windows.

@JonasT @nicbarker ¿Cómo confirma que las carpetas nombradas en .dockerignore se están cargando, aparte del hecho de que está tardando mucho tiempo? Si tiene una forma de comprobar el tarball, me gustaría intentar utilizarlo para reproducir el problema localmente. Tal como están las cosas, agregué algo de depuración a docker-py y todavía no puedo reproducir:

$ 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 toma REALMENTE mucho tiempo antes de que comience, y cuando muevo el Dockerfile a ./context y uso "build: ./context/" sin ningún otro cambio, es instantáneamente increíblemente rápido. También en ese entonces, cuando apareció este problema por primera vez, probé la compilación de la ventana acoplable manualmente con "compilación de la ventana acoplable" y también fue instantáneo.

Eso realmente no confirma el problema. Si hubiera otro directorio grande en la raíz del proyecto, mover la compilación a ./context lo haría más rápido.

@dnephin no hay otras carpetas allí, excepto el "contexto" en sí, que agregué como solución alternativa, y tres pequeños archivos de texto.

@JonasT ¿Es posible que tenga un directorio .git grande que se va a incluir?

Editar: NVM, parece que fui lo suficientemente estúpido como para perderme un directorio porque verifiqué el rsync'ed copy>.> Lo siento chicos ...

De hecho, tuve un problema con esto hace un tiempo en una versión anterior de docker-compose donde lo investigué más a fondo, pero tal vez esa instancia específica que tuve se solucionó con algunas de las actualizaciones recientes de Dockerpy.

¿Volver a que esto sea un problema de Windows? :)

Hola,
tengo linux, compongo 1.6.2, acoplador 1.10.3 ... exactamente el mismo problema. docker usa .dockerignore , compose lo ignora.

@ulrichSchreiner ¿Puede proporcionar los pasos para reproducir?

Hola,

aquí hay una esencia (https://gist.github.com/ulrichSchreiner/566815cea26ce55b95207e7795cf6962). el .dockerignore contiene **/node_modules el Dockerfile agrega un archivo en una subcarpeta t1/a/b/c/node_modules .

si construye esto con "docker build ..." obtendrá un error porque no hay archivo para agregar (se ignora correctamente debido al patrón en .dockerignore ). puede ver la salida en el último archivo de la esencia.

pero si lo compila con el "docker-compose.yml" dado, se compila con éxito -> docker-compose ignora el archivo .dockerignore .

y esto es realmente una molestia cuando su directorio node_modules tiene cientos de megas ...

yo suelo

docker-compose version 1.6.2, build 4d72027

Bien, puedo reproducir esto. Parece que docker-py probablemente tiene un error con las reglas **/ .

IIRC, la falta de soporte para la sintaxis ** es una limitación conocida de nuestra implementación .dockerignore . Ver https://github.com/docker/docker-py/pull/721#issuecomment -135065043

El mismo problema aquí. .dockerignore se ignora cuando se usa con docker-compose
docker-compose version 1.6.2, build 4d72027 OSX

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

Contenido de .dockerignore

./.git
./.vagrant

.vagrant es de 16 GB, por lo que este es un "gran negocio (tm)" para nosotros.

Lo siento,

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 Parece un error; lo he solucionado en https://github.com/docker/docker-py/pull/1065. Por ahora, puede eliminar el ./ de sus patrones y debería funcionar.

¡Gracias!

Ejecutando en Ubuntu 14.04, mi dockerignore es simplemente **/always_restart.txt . En un docker build (v1.11.2) normal, no veo el archivo en el contenedor, pero con Compose (v1.7.1), sí.

Edit1: Parece que docker-py no prueba la notación de doble asterisco y supongo que probablemente tampoco lo maneja: https://github.com/docker/docker-py/blob/1.9. 0-release / tests / unit / utils_test.py # L721

Edit2: usar el patrón */tmp/always_restart.txt funciona con Compose, por lo que el patrón ** específicamente se ignora

@ agilgur5 Correcto, este es un problema conocido con docker-py. Creé https://github.com/docker/docker-py/issues/1117 para rastrearlo.

Nuestra fea solución en el DOCKERFILE:
Al usar git-check-ignore para analizar (por lo tanto, necesitamos git init ), simplemente eliminamos todo lo que debe ignorarse después de copiar.
Tenga en cuenta que en nuestro caso, después de todo, tenía que ser COPY s (o ADD s), de lo contrario, volvemos a tener archivos no deseados.

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

Para eliminar también archivos del .gitignore (porque por qué no)

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

Creo que encontré una solución para esto usando volúmenes de datos en docker-compose.yml , básicamente enumerando los directorios de contenedores que no desea que se sobrescriban. En nuestro caso, queríamos conservar el directorio node_modules en el contenedor.

Entonces, nuestro docker-compose.yml ve así:

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

El volumes duplica lo que hay en .dockerignore pero nos pone en marcha por ahora ...

Tengo una sugerencia de alto nivel para este problema:

Recomendaría cambiar el título de este problema a algo como "[meta problema]: manejo incorrecto de las reglas .dockerignore" (o "[problema de seguimiento]: manejo incorrecto ..."), o simplemente cerrar este problema a favor de una colección de problemas más pequeños y procesables. Esto se debe a que (1) no es que Docker compose esté "ignorando" el archivo .dockerignore (que es lo que dice actualmente el título del problema). Simplemente no ha implementado las reglas correctamente. Y (2), hay varias partes en este problema. Este no es solo un problema. Por ejemplo, existe este ( ** procesamiento) y este nuevo que acabo de presentar (precedencia de última línea). Y muy bien puede haber más.

Debido a que este hilo de problemas es tan largo (porque cubre un área de problemas amplia), los problemas individuales que deben resolverse son difíciles de localizar dentro del hilo. A diferencia de un problema general de ".dockerignore no parece funcionar", sugiero presentar problemas bien definidos que se pueden resolver de forma aislada. Como está redactado actualmente, es posible que este problema nunca se resuelva porque la implementación de Python podría nunca tener paridad con la implementación de referencia.

He usado **/**/node_modules pero descubrí que este no estaba funcionando. Así que definí cada directorio node_modules en mis subproyectos para corregir este error.

Antes de esta revisión, tenía un "Error de derecho de acceso" al instalar las dependencias npm porque ya estaban allí (causado por copiar con un archivo dockerignore que no funcionaba).

El mismo problema.

macOS Sierra 10.12.2
Docker versión 1.12.5, compilación 7392c3b
docker-compose versión 1.9.0, compilación 2585387

El problema del patrón ** debería solucionarse en 1.11.2
Hay posibles problemas pendientes como el que tiene precedencia de última línea, que se rastrean por separado en # 3931 y # 3886. Consulte esos para obtener más actualizaciones.

No estoy seguro de si docker-compose ignora mi .dockerignore o no lo interpreta correctamente (a diferencia de la ventana acoplable que funciona bien). así es como llegué aquí: http://stackoverflow.com/questions/42883596/equivalent-builds-dont-behave-the-same

y aquí está mi archivo .dockerignore (en caso de que pueda detectar cuál puede ser el problema):

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

Parece que mi docker-compose build ignora completamente el archivo .dockerignore .
docker build funciona como se esperaba.

$ 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

Mi .dockerignore ve así

.bundle
.git
.gitignore
test
tmp
log

así que no hay nada especial aquí.
Estoy usando Ubuntu 16.04 pero no sé si eso importa.

Por cierto: ¿Alguien puede explicar por qué docker-compose build no usa el mismo código que docker build para construir una imagen usando Dockerfile y todo eso? ¿Por qué hay una duplicación de código obvia (que no funciona realmente bien como muestra este problema)?

¿Por qué se cerró este problema y cómo lo reabrimos? el software está claramente roto y necesita ser reparado

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

ah. gracias shin. me alegro de que se aborde

He leído los problemas # 3931 y # 3886 como se sugirió, pero mi .dockerignore no es especial, por lo que no pude mapear exactamente mi problema.
No trabajo en absoluto para mí y no importa, qué hay en mi .dockerignore.

Tan estúpido, fue mi error .:dizzy_face:
Monté mi código como un volumen para que quede claro, que no se ignora nada. Lo siento por eso.

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

esto parece irresuelto?

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
''

pero ambas carpetas terminan siendo creadas de todos modos ...

Yo tuve el mismo problema. justo cuando me di cuenta de que estoy en una versión de redacción antigua. Actualizado a docker-compose version 1.22.0-rc1, build e7de1bc3 .

El problema es que la versión de redacción enviada con debian / ubuntu es demasiado antigua.

Ahora funciona mejor, pero aún no es lo mismo que docker build

Esto aún no se ha resuelto. Ejecutando Docker para Mac, última versión (Docker 18.03.1-ce-mac65).

Mi .dockerignore:

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

pero ambos se pasan al contenedor cuando se usa docker-compose.

https://github.com/docker/docker-py/pull/2065 está en 1.22.0 RC2 y debería abordar eso.

Estoy usando Docker para Mac Versión 18.06.1-ce-mac73 (26764) y el error sigue ahí.

Estoy usando:

docker-compose versión 1.22.0, compilación f46880f
Docker versión 18.06.1-ce, compilación e68fc7a

que se ejecuta en Ubuntu 16.04 Xenial y docker-compose build ignora el siguiente .dockerignore:

**/*.jpg **/*.png **/*.pyc **/*.solverstate **/*.caffemodel **/*.tgz **/.pytest_cache **/*__pycache__* **/.git **/node_modules *.egg-info .eggs *Dockerfile* build dist
Como ahora se supone que debe interpretar los asteriscos dobles, no sé cuál puede ser la causa. ¿Alguien con el mismo problema?

Como ahora se supone que debe interpretar los asteriscos dobles, no sé cuál puede ser la causa. ¿Alguien con el mismo problema?

Tengo el mismo problema (con **/.tox ).

Tuve el mismo problema. Utilizo diferentes contextos.
docker-compose.yml se coloca en la ruta raíz de la aplicación y parece

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

Mi árbol de archivos:

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

¡Que tengas un buen día!

@ zymtx5g79k Eso no me funciona.

Estructura de directorios:

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

docker-compose.yml

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

@rodrigobdz , verifique por favor:
docker-compose.yml :

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

.dockerignore :

/docker

Estructura de archivos :

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

Aún con el mismo resultado, el directorio .git está en el contenedor, por ejemplo. Publicaré aquí mi .dockerignore. Tal vez tenga algún problema en sí mismo.

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

.git
.gitignore
README.md

@rodrigobdz No puedo reproducir el problema (ejecutando docker compose versión 1.22.0);

Prepare la prueba;

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

Construya usando 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

Y verifique que no se agregue el contenido;

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

2 directories, 3 files

Ahora, cambie el nombre de .dockerignore y realice la compilación nuevamente;

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

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

Verifique que el contenido ya no se ignore y se agregue a la imagen:

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

(editar: salida actualizada de la primera ejecución, ya que olvidé ejecutar tree con -a la primera vez)

@thaJeztah Gracias por tomarse el tiempo para investigarlo. Encontré el problema.

Mi caso de uso es similar al descrito en https://github.com/docker/compose/issues/2098#issue -108463351. Utilizo un comando COPY en mi Dockerfile y, además, monte el mismo directorio como volumen .

Esperaba que las exclusiones en .dockerignore se aplicaran al volumen, como se describe en https://github.com/docker/compose/issues/2098#issuecomment -143505943.

Esperaba que las exclusiones en .dockerignore se aplicaran al volumen, como se describe en # 2098 (comentario).

No, cuando se vincula una ruta desde el host, la ventana acoplable no estará "en el medio" de eso; en Linux, literalmente está montando ese directorio desde el host dentro del contenedor. En Docker Desktop (Docker para Mac / Windows), hay algo de "magia" adicional involucrada para hacer que esos archivos estén disponibles dentro de la VM donde se ejecuta el demonio (y el contenedor), pero esencialmente hace lo mismo que en Linux después de eso.

.dockerignore solo se usa durante la compilación y fue diseñado para acelerar las compilaciones; para evitar tener que enviar archivos al demonio que no se utilizan o no se desean en la imagen.

¡Gracias por la aclaración! Considero que esta explicación debería estar en los documentos para evitar más malentendidos en la comunidad. Actualmente, la documentación se centra más en cómo ignorar archivos que en el alcance de .dockerignore sí.

Esa página de la documentación describe el Dockerfile y docker build ; desde esa perspectiva; preguntándome si tendría sentido describir que no funciona para otros comandos / usos.

Bueno, si es una fuente común de malentendidos, y evidentemente lo es, ciertamente tendría sentido que se mencionara allí.

Una sola oración en la documentación nos habría ahorrado a @thaJeztah , y a todos los usuarios a continuación, mucho tiempo .

Número 1607

Edición 2098

Solo quería hacer +1 en este problema.

Estoy ejecutando docker-copose: 1.23.2 (lo más nuevo que pude encontrar entre Homebrew y PIP)
Sistema operativo: Mac OS 10.14.2

Todavía está ignorando mi .dockerfile durante la construcción. Tendré que copiar cosas explícitamente mientras tanto.

Solucioné este problema eliminando una referencia de volumen innecesaria en mi archivo docker-compose. Compose ignora .gitignore para los volúmenes.

Esto lo solucionó para mí: docker-compose ignorará un archivo .dockerignore en un volumen montado.

@xvrqt Probablemente he perdido horas durante la última semana teniendo errores aleatorios con mi archivo de configuración que no se ha copiado correctamente (se supone que mi proceso de compilación debe copiarlo, pero el archivo .dockerignore lo estaba bloqueando). Esto es algo increíble.

Gracias por resaltar eso.

¡Hola! ¿Cuál es el estado de esto? He preparado escenarios de docker-compose.yml muy simples que no involucran volúmenes y, sin embargo, no logra recoger .dockerignore cuando se construye desde un repositorio de git remoto.

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

¿Se espera el error que tengo en la rama maestra? ¿Alguna solución además de crear y etiquetar la imagen con la ventana acoplable vanilla y luego usarla en docker-compose.yml?

Gracias

¿Alguna solución además de crear y etiquetar la imagen con la ventana acoplable vanilla y luego usarla en docker-compose.yml?

Si está ejecutando la versión actual de compose, puede usar las opciones COMPOSE_DOCKER_CLI_BUILD=1 (y DOCKER_BUILDKIT=1 ) para hacer que docker compose use el docker build nativo.

Su ejemplo parece ser diferente al que se está discutiendo aquí, por lo que podría ser bueno abrir un nuevo ticket (si todavía no hay ninguno para eso)

¡Gracias @thaJeztah! Funciona con COMPOSE_DOCKER_CLI_BUILD=1 , pero si también agrego DOCKER_BUILDKIT=1 , falla (por una razón no relacionada).

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

Hm, sospecho que es un error en la versión de Docker que se está ejecutando allí; Docker 18.06 es bastante antiguo (y EOL); esa versión de Docker tiene una versión bastante temprana de BuildKit, que aún no era estable.

''
=> ERROR [interno] cargar metadatos para docker.io/library/alpine:3.9.5 0.1s
218 => ERROR [1/5] FROM docker.io/library/alpine:3.9.5 0.0s
219 => => resolver docker.io/library/alpine:3.9.5 0.0s
220 ------
221> [interno] cargar metadatos para docker.io/library/alpine:3.9.5:
222 ------
223 ------
224> [1/5] DE docker.io/library/ alpine: 3.9.5 :
225 ------
226 no se pudo resolver con la interfaz dockerfile.v0: no se pudo compilar LLB: no se pudo cargar la clave de caché: docker.io/library/ alpine: 3.9.5 no encontrado

Oh, hm, veo que tu Travis también está instalando Docker (leyendo desde mi teléfono); ¿Eso reemplaza la versión preinstalada? Si agrega un paso docker info y docker version después de la instalación, ¿muestra la versión correcta (19.03.x) de la ventana acoplable que se instalará?

Aquí está https://travis-ci.org/LocoDelAssembly/docker-compose-dockerignore/builds/658435194

Resumen

Versión de Docker para ambas compilaciones fallidas

$ 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 salida de Server Version: 19.03.7

versiones 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 versión informada es incorrecta, es rc2, el hash de compilación coincide con 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

El problema aún existe en 19.03.8.

El problema aún existe en 19.03.8.

Correcto. También actualicé mi repositorio de prueba con las versiones más recientes de 1.25 y 1.26 docker-compose, pero todo sigue siendo como se describe en https://github.com/LocoDelAssembly/docker-compose-dockerignore

Construya donde se puede encontrar el mismo tipo de información que pegué anteriormente: https://travis-ci.org/github/LocoDelAssembly/docker-compose-dockerignore/builds/673393656

Tiene el mismo problema aquí, .dockerignore no funciona de manera confiable con docker-compose