Você tem problemas com o formato do arquivo.

No seu .dockerignore mude subdir/ para subdir .

Por que o .dockerignore funciona para docker build -t subdir ../ mas não para docker-compose build ?

Estou tendo o mesmo problema ao executar docker-compose 1.2.0.
A execução do vanilla docker build puxa o arquivo ignore e constrói a imagem, np lá.
No entanto, docker-compose não usa o arquivo ignorar, com ou sem a barra final.

Parece um problema docker-py; uma correção está sendo trabalhada em https://github.com/docker/docker-py/pull/604. Marcando isso como um bug para nos lembrar de atualizar nossa versão docker-py assim que a correção for lançada.

@aanand parece que https://github.com/docker/docker-py/pull/604 estagnou e foi removido do marco lá?

@thaJeztah Eu criei https://github.com/docker/docker-py/pull/721 para continuar o trabalho.

Oi,

Estou enfrentando um problema estranho com .dockerignore:

*.sh

!awesome/script.sh

com docker build está tudo bem, mas docker-compose não viu "awesome / script.sh"

Estou no mesmo problema?

@twillouer é um bug conhecido, corrigido por https://github.com/docker/docker-py/pull/721 - será corrigido no lado do Compose no 1.5.0.

obrigado !

Isso ainda parece estar quebrado, mesmo no último git master em algumas máquinas. Não funciona para mim em uma máquina com esta configuração:

Debian 8.2 com kernel 3.16.0 com lxc-docker versão 1.7.1, compilação 786b29d
docker-compose é git master, HEAD está em dabf1e8657674014a5bc89f99edbf2fe0629bb71

O .dockerignore funciona bem para docker build (que é executado instantaneamente), mas não para docker-compose (que carrega coisas que não deveriam carregar por vários minutos).

Veja também # 2100

Eu tenho o mesmo problema. docker-compose ignora ".dockerignore". "docker build" funciona bem.
Sistema: windows 10

Estou tendo o mesmo problema ao usar o Docker Toolbox lançado ontem:

• Windows 7 x64
• Docker versão 1.9.0, compilação 76d6bc9
• Docker-Compose 1.5.0

Parece que ainda estamos tendo problemas com .dockerignore . Se você estiver tendo esses problemas com o Compose 1.5.0, inclua uma amostra .dockerignore e estrutura de diretório para que possamos reproduzir o erro.

Desculpe por não fornecer um caso de uso menor, mas foi assim que percebi o problema:

Tenho este package.json para o meu projeto:

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

Além disso, tenho este docker-compose.yml :

web:
  build: .

O Dockerfile tem esta aparência:

FROM node:0.12

Meu .dockerignore contém uma linha (tentei adicionar uma barra final, mas o problema persistiu):

node_modules

Agora eu posso fazer

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

Incrível, funciona, apenas 5 KiB são enviados ( node_modules são aproximadamente 10 MiB no total). Com docker-compose em 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'

(Estou usando 1.5.0dev nesta máquina, mas tenho exatamente o mesmo problema na minha outra máquina com 1.5.0 final).

Com o node, geralmente encontro problemas com caminhos muito longos e outras coisas no Windows, mas o fato de que o Docker-Compose está tentando tar os node_modules é o indicador de que .dockerignore é ignorado.

FWIW, ainda estou tendo problemas com isso no Linux (Ubuntu) com docker-compose 1.5.0dev, então provavelmente não é isolado para Windows. No entanto, ele está em uma máquina de produção, então não posso montar facilmente um caso de teste mínimo (funciona bem na minha máquina de teste).

Eu também estou tendo esse problema.

Estrutura do diretório:

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

Alguém encontrou uma solução alternativa? Estou tentando fazer tudo apenas no Dockerfile, mas ainda não tive sorte.

Também estou tendo esse problema. Ele pode estar relacionado à versão do nó que todos estão executando? Por meio deste problema: https://github.com/npm/npm/issues/3697 .. Imagino que atualizar o nó (mais especificamente para npm 3+) resolveria isso, mas é mais uma opção nuclear e .dockerignore ainda deve trabalhos.

Mais uma vez, apesar de aparentemente ter sido ignorado, estou vendo isso também em uma máquina Linux.

Corrigi esse problema removendo uma referência de volume desnecessária em meu arquivo docker-compose. Compose ignora .gitignore para volumes.

Eu também tive que atualizar meu aplicativo para usar o npm 3+ .. mas isso pode se aplicar apenas a usuários do Windows.

@ esc-rtn o arquivo .dockerignore especifica apenas quais arquivos não devem ser enviados para o daemon durante _build_. Se você estiver usando um volume montado por vinculação durante a "execução", ele simplesmente montará todos os arquivos naquele local como um volume (todos os arquivos que estão presentes no host).

Também estou vendo algo parecido no Windows: docker build funciona como esperado, docker-compose não.

Coloquei um pequeno exemplo no GitHub, com notas no README.md: https://github.com/stekershaw/docker-compose-ignore

Outra rodada de correções para .dockerignore entrou em docker-py depois que o Compsoe 1.5.2 foi lançado. Você poderia experimentar a versão Compose 1.6.0 RC2 para ver se ela foi corrigida agora?

Tentei com docker-compose versão 1.6.0rc2, build a7636be.

Eu tenho três casos de teste em meu repo e com 1.5.2 dois deles falharam. Agora com 1.6.0rc2 apenas um falha, quando eu tenho um diretório e um arquivo no diretório excluídos, assim:

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

Eu obtenho um comportamento idêntico nesse caso entre docker build e 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

Olá @aanand , obrigado pela sua resposta, obtenho o mesmo resultado ao seguir os seus passos.

No entanto, o teste que executei anteriormente também tinha outro arquivo presente em files / test_dir. Se eu adicionar outro arquivo a files / test_dir, vejo que ele não está presente (como seria de esperar) com docker build mas está presente com 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

Este é o Windows (usando git bash como meu shell), verificado com Docker compose 1.5.2 e 1.6.0rc2, docker 1.9.1.

Executar o mesmo no Ubuntu 14.04 com docker-compose 1.5.2 e docker 1.9.1 é bom:

# 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

Ainda lidando com isso a maior parte da tarde.

Docker versão 1.10.1, compilação 9e83765
docker-compose versão 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

A saída é a esperada com docker build .

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

2992 tem mais algumas .dockerignore correções que devem ser incluídas em 1.6.1

Obrigado @ shin-, infelizmente ainda vejo um comportamento diferente com docker-compose 1.6.2 do 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

Isso é muito estranho. Definitivamente funciona para mim.

$ 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

Qual é a saída de pip show docker-py em seu ambiente?

Eu acredito que também tenho o mesmo problema.

 Docker build .

funciona para mim. No entanto, incluir a mesma compilação em um arquivo docker-compose.yml interrompe minha compilação. Em meu arquivo .dockerignore, estou excluindo o diretório node_modules para minha construção de nó. Esta é a seção relevante de meu docker-compose.yml:

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

Acho que estou executando a versão mais recente do 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

Estou executando o Windows 10, x64.

Problema específico do Windows, talvez com separadores de caminho?

Não sei como saber se isso está relacionado a separadores de caminho.

Deixe-me saber se posso ajudar com o teste ou de outra forma. No momento, tenho um arquivo em lote que move as pastas "ignoradas" para fora do diretório do projeto antes da construção, obviamente feio.

Obrigado pela ajuda.

Para fins de integridade, este é meu arquivo .dockerignore:

**/node_modules

Aha! É o padrão glob que está causando o problema. remover o "** /" corrigiu o problema para mim.

Embora eu tenha uma solução alternativa para meu problema específico, o fato é que há um bug. No mínimo, o padrão glob ** / não é analisado corretamente com docker-compose, mas funciona bem com o comando docker build regular. Outros padrões de glob podem ou não funcionar.

@bfirsh e todos os outros que possam se importar:

Eu tenho um .dockerignore absolutamente simples que se parece com isto:

livedata
readonly-data

O .dockerignore também não funciona (essas duas pastas na pasta de contexto de construção são carregadas para o daemon e leva _para sempre_) e estou no Linux . Eu atualizei apenas para 1.6.2 atual, sem alteração. A menos que eu esteja vendo um problema diferente com o mesmo sintoma, deixe-me reiterar _novamente_ que esse não parece ser um problema específico do Windows.

1, também quebrado para mim no Linux - não pense que é um problema específico do Windows.

@JonasT @nicbarker Como você está confirmando que as pastas nomeadas em .dockerignore estão sendo carregadas, além do fato de estar demorando muito? Se você tiver uma maneira de verificar o tarball, gostaria de tentar usá-lo para reproduzir o problema localmente. Da forma como está, adicionei um pouco de depuração ao docker-py e ainda não consigo reproduzir:

$ 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 leva MUITO muito tempo antes de começar, e quando eu movo o Dockerfile para ./context e uso "build: ./context/" sem nenhuma outra alteração, é instantaneamente incrivelmente rápido. Também naquela época, quando esse problema apareceu pela primeira vez, tentei o docker build manualmente com o "docker build" e também foi instantâneo.

Isso realmente não confirma o problema. Se houvesse outro diretório grande na raiz do projeto, mover a compilação para ./context o tornaria mais rápido.

@dnephin, não há outras pastas lá, exceto para o próprio "contexto", que eu adicionei como uma solução alternativa, e três pequenos arquivos de texto.

@JonasT É possível que você tenha um grande diretório .git que está sendo incluído?

Edit: NVM, parece que fui realmente estúpido o suficiente para perder um diretório porque verifiquei a cópia errada de rsync'ed >.> Desculpe pessoal ..

Na verdade, tive um problema com isso um tempo atrás em uma versão mais antiga do docker-compose onde investiguei mais profundamente, mas talvez aquela instância específica que eu tinha foi corrigida com algumas das atualizações recentes do dockerpy.

Voltar a ser um problema do Windows? :)

Oi,
eu tenho linux, compor 1.6.2, docker 1.10.3 ... exatamente o mesmo problema. docker usa .dockerignore , compose o ignora.

@ulrichSchreiner Você pode fornecer etapas para reproduzir?

Oi,

aqui está uma essência (https://gist.github.com/ulrichSchreiner/566815cea26ce55b95207e7795cf6962). o .dockerignore contém **/node_modules o Dockerfile adiciona um arquivo em uma subpasta t1/a/b/c/node_modules .

se você construir isso com "docker build ...", obterá um erro porque não há nenhum arquivo a ser adicionado (ele é ignorado corretamente por causa do padrão em .dockerignore ). você pode ver a saída no último arquivo da essência.

mas se você construí-lo com o "docker-compose.yml" fornecido, ele foi construído com sucesso -> docker-compose ignora o arquivo .dockerignore .

e isso é realmente uma dor quando seu diretório node_modules tem centenas de megas ....

eu uso

docker-compose version 1.6.2, build 4d72027

OK, posso reproduzir isso. Parece que o docker-py provavelmente tem um bug com as regras **/ .

IIRC, a falta de suporte para a sintaxe ** é uma limitação conhecida de nossa implementação de .dockerignore . Consulte https://github.com/docker/docker-py/pull/721#issuecomment -135065043

Mesmo problema aqui. .dockerignore é ignorado quando usado com docker-compose
docker-compose version 1.6.2, build 4d72027 OSX

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

Conteúdo de .dockerignore

./.git
./.vagrant

.vagrant tem 16 GB, então este é um "Big Deal (tm)" para nós.

Desculpa,

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 um bug - eu https://github.com/docker/docker-py/pull/1065. Por enquanto, você pode remover o ./ de seus padrões e deve funcionar.

Obrigado!

Rodando no Ubuntu 14.04, meu dockerignore é simplesmente **/always_restart.txt . Em um docker build normal (v1.11.2), não vejo o arquivo no contêiner, mas com Compose (v1.7.1), sim.

Edit1: Parece que docker-py não testa a notação de asterisco duplo e estou supondo que provavelmente também não lida com isso: https://github.com/docker/docker-py/blob/1.9. 0-release / tests / unit / utils_test.py # L721

Edit2: usar o padrão */tmp/always_restart.txt funciona com Compose, então o padrão ** especificamente é ignorado

@ agilgur5 Correto, este é um problema conhecido com docker-py. Criei https://github.com/docker/docker-py/issues/1117 para rastreá-lo.

Nossa solução alternativa feia no DOCKERFILE:
Usando git-check-ignore para análise (portanto, precisando de git init ), nós apenas deletamos tudo que deveria ser ignorado após a cópia.
Note, em nosso caso que afinal tinha que ser COPY s (ou ADD s), caso contrário, teríamos arquivos indesejados novamente.

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 remover também arquivos do .gitignore (porque não)

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

Acho que encontrei uma solução alternativa para isso usando volumes de dados em docker-compose.yml , basicamente listando os diretórios de contêineres que você não deseja substituir. Em nosso caso, queríamos preservar o diretório node_modules no contêiner.

Então, nosso docker-compose.yml parece com isto:

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

O volumes duplica o que está em .dockerignore mas nos faz continuar por enquanto ...

Tenho uma sugestão de alto nível para este problema:

Eu recomendaria mudar o título desse problema para algo como "[meta problema]: manuseio incorreto de regras .dockerignore" (ou "[problema de rastreamento]: manuseio incorreto ...") ou simplesmente encerrar esse problema em favor de uma coleção de problemas menores e mais acionáveis. Isso ocorre porque (1) não é que a composição do Docker esteja "ignorando" o arquivo .dockerignore (que é o que o título do problema diz atualmente). Ele simplesmente não implementou as regras corretamente. E (2), há várias partes para esse problema. Este não é apenas um problema. Por exemplo, existe este (processamento de ** ) e este novo que acabei de apresentar (precedência de última linha). E pode muito bem haver mais.

Como esse encadeamento de problemas é muito longo (porque cobre uma ampla área de problemas), os problemas individuais que precisam ser resolvidos são difíceis de localizar dentro do encadeamento. Ao contrário de um problema geral ".dockerignore não parece funcionar", estou sugerindo o arquivamento de questões bem definidas que podem ser resolvidas isoladamente. Conforme expresso atualmente, esse problema pode nunca ser resolvido porque a implementação Python pode nunca ter paridade com a implementação de referência.

Usei **/**/node_modules mas descobri que este não estava funcionando. Portanto, defini cada diretório node_modules em meus subprojetos para corrigir esse bug.

Antes desse hotfix, eu tinha um "Erro de direito de acesso" ao instalar dependências npm porque elas já existiam (causado pela cópia de um arquivo dockerignore que não estava funcionando).

Mesmo problema.

macOS Sierra 10.12.2
Docker versão 1.12.5, compilação 7392c3b
docker-compose versão 1.9.0, build 2585387

O problema do padrão ** deve ser corrigido em 1.11.2
Existem possíveis problemas pendentes, como aquele com precedência de última linha, que são rastreados separadamente em # 3931 e # 3886. Consulte-os para obter mais atualizações.

Não tenho certeza se docker-compose está ignorando meu .dockerignore ou não está interpretando-o corretamente (ao contrário do docker, que funciona perfeitamente). foi assim que cheguei aqui: http://stackoverflow.com/questions/42883596/equivalent-builds-dont-behave-the-same

e aqui está meu arquivo .dockerignore (caso você consiga identificar qual é o problema):

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

Parece que meu docker-compose build ignora o arquivo .dockerignore completamente.
docker build funciona como esperado.

$ 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

Meu .dockerignore tem esta aparência

.bundle
.git
.gitignore
test
tmp
log

então nada de especial aqui.
Estou usando o Ubuntu 16.04, mas não sei se isso importa.

BTW: Alguém pode explicar por que docker-compose build não usa o mesmo código de docker build para construir uma imagem usando Dockerfile e todas essas coisas? Por que há uma duplicação de código óbvia (que não funciona muito bem, como mostra este problema)?

por que este problema foi encerrado e como o reabrimos? o software está claramente quebrado e precisa ser consertado

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

ah. obrigado shin. feliz que será abordado

Eu li os problemas # 3931 e # 3886 conforme sugerido, mas meu .dockerignore não é especial, então não pude mapear exatamente o meu problema.
Eu não trabalho para mim e não importa, o que está no meu .dockerignore.

Tão estúpido, foi meu erro.:dizzy_face:
Montei meu código como um volume para que fique claro que não há nada ignorado. Desculpe por isso.

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

isso parece não resolvido?

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

mas ambas as pastas acabam sendo criadas de qualquer maneira ...

Eu tive o mesmo problema. apenas quando percebi que estou em uma versão escrita antiga. Atualizado para docker-compose version 1.22.0-rc1, build e7de1bc3 .

O problema é que a versão composta fornecida com o debian / ubuntu é muito antiga.

Agora funciona melhor, mas ainda não é o mesmo que docker build

Isso ainda não foi resolvido. Executando Docker para Mac, versão mais recente (Docker 18.03.1-ce-mac65).

Meu .dockerignore:

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

mas ambos são passados ​​para o contêiner ao usar docker-compose.

https://github.com/docker/docker-py/pull/2065 está em 1.22.0 RC2 e deve resolver isso.

Estou usando o Docker para Mac versão 18.06.1-ce-mac73 (26764) e o bug ainda está lá.

Estou a usar:

docker-compose versão 1.22.0, compilação f46880f
Docker versão 18.06.1-ce, compilação e68fc7a

em execução no Ubuntu 16.04 Xenial e docker-compose build ignora o seguinte .dockerignore:

**/*.jpg **/*.png **/*.pyc **/*.solverstate **/*.caffemodel **/*.tgz **/.pytest_cache **/*__pycache__* **/.git **/node_modules *.egg-info .eggs *Dockerfile* build dist
Como agora deve interpretar asteriscos duplos, não sei qual pode ser a causa. Alguém com o mesmo problema?

Como agora deve interpretar asteriscos duplos, não sei qual pode ser a causa. Alguém com o mesmo problema?

Estou tendo o mesmo problema (com **/.tox ).

Eu tive o mesmo problema. Eu uso contextos diferentes.
docker-compose.yml é colocado no caminho raiz do aplicativo e parece

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

Minha árvore de arquivos:

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

Tenha um bom dia!

@ zymtx5g79k Isso não está funcionando para mim.

Estrutura do diretório:

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

Estrutura de arquivos :

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

Ainda com o mesmo resultado, o diretório .git está no contêiner, por exemplo. Vou postar aqui meu .dockerignore. Talvez tenha algum problema em si.

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

.git
.gitignore
README.md

@rodrigobdz Não consigo reproduzir o problema (executando docker compose versão 1.22.0);

Prepare o teste;

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

Construir 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

E verifique se o conteúdo não foi adicionado;

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

2 directories, 3 files

Agora, renomeie .dockerignore e execute a construção novamente;

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

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

Verifique se o conteúdo não é mais ignorado e adicionado à imagem:

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: saída atualizada da primeira execução, pois esqueci de executar tree com -a pela primeira vez)

@thaJeztah Obrigado por analisá -lo. Eu encontrei o problema.

Meu caso de uso é semelhante ao descrito em https://github.com/docker/compose/issues/2098#issue -108463351. Eu uso um comando COPY em meu Dockerfile e, adicionalmente, monto o mesmo diretório como um volume .

Eu esperava que as exclusões em .dockerignore fossem aplicadas ao volume, conforme descrito em https://github.com/docker/compose/issues/2098#issuecomment -143505943.

Eu esperava que as exclusões em .dockerignore fossem aplicadas ao volume, conforme descrito em # 2098 (comentário).

Não, ao montar um caminho a partir do host, o docker não estará "no meio" disso; no Linux, ele está literalmente montando esse diretório do host dentro do contêiner. No Docker Desktop (Docker para Mac / Windows), há alguma "mágica" adicional envolvida para disponibilizar esses arquivos dentro da VM onde o daemon (e contêiner) é executado, mas essencialmente está fazendo o mesmo que no Linux depois disso.

.dockerignore é usado apenas durante a compilação e foi planejado para acelerar as compilações; para evitar ter que enviar arquivos para o daemon que não são usados ​​/ desejados na imagem.

Obrigado pelo esclarecimento! Considero que esta explicação deve estar nos documentos para evitar mais mal-entendidos na comunidade. Atualmente, a documentação está mais focada em como ignorar arquivos do que no escopo de .dockerignore si.

Essa página da documentação descreve o Dockerfile e docker build ; dessa perspectiva; perguntando-se se faria sentido descrever que não funciona para outros comandos / usos.

Bem, se é uma fonte comum de mal-entendidos, e evidentemente é, certamente faria sentido mencioná-lo aqui.

Uma única frase na documentação teria nos salvado @thaJeztah , e a todos os usuários abaixo, muito tempo .

Edição 1607

Edição 2098

Só queria marcar este problema com +1.

Estou executando o docker-copose: 1.23.2 (o mais recente que consegui encontrar entre o Homebrew e o PIP)
SO: Mac OS 10.14.2

Ainda está ignorando meu arquivo .docker durante a construção. Vai ter que copiar as coisas explicitamente nesse meio tempo.

Corrigi esse problema removendo uma referência de volume desnecessária em meu arquivo docker-compose. Compose ignora .gitignore para volumes.

Isso corrigiu para mim - docker-compose irá ignorar um arquivo .dockerignore em um volume montado.

@xvrqt Provavelmente perdi horas na última semana tendo erros aleatórios com meu arquivo de configuração não sendo copiado corretamente (meu processo de construção deveria copiá-lo, mas estava sendo bloqueado pelo arquivo .dockerignore não sendo usado). Isso é inacreditável.

Obrigado por destacar isso.

Oi! Qual é o status disso? Preparei cenários docker-compose.yml muito simples que não envolvem volumes e, ainda assim, não consegue pegar .dockerignore ao compilar a partir do repositório git remoto.

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

O erro que estou tendo no branch master é esperado? Alguma solução além de construir e marcar a imagem com o vanilla docker e, em seguida, usá-lo em docker-compose.yml?

obrigado

Alguma solução além de construir e marcar a imagem com o vanilla docker e, em seguida, usá-lo em docker-compose.yml?

Se você estiver executando a versão atual do compose, poderá usar as opções COMPOSE_DOCKER_CLI_BUILD=1 (e DOCKER_BUILDKIT=1 ) para fazer o docker compose usar o docker build nativo.

Seu exemplo parece ser diferente do que está sendo discutido aqui, então pode ser bom abrir um novo tíquete (se não houver nenhum para isso ainda)

Obrigado @thaJeztah! Funciona com COMPOSE_DOCKER_CLI_BUILD=1 , mas se eu também adicionar DOCKER_BUILDKIT=1 ele falha (por um motivo não relacionado).

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

Hm, suspeito que seja um bug na versão do docker que está rodando lá; docker 18.06 é muito antigo (e EOL); essa versão do docker tem uma versão bastante inicial do BuildKit, que ainda não era estável.

`` `
=> ERROR [interno] carregar metadados para docker.io/library/alpine:3.9.5 0.1s
218 => ERRO [1/5] DE docker.io/library/alpine:3.9.5 0.0s
219 => => resolver docker.io/library/alpine:3.9.5 0.0s
220 ------
221> [interno] carregar metadados para docker.io/library/alpine:3.9.5:
222 ------
223 ------
224> [1/5] DE docker.io/library/ alpine: 3.9.5 :
225 ------
226 falhou ao resolver com frontend dockerfile.v0: falhou ao construir LLB: falhou ao carregar a chave do cache: docker.io/library/ alpine: 3.9.5 não encontrado

Oh, hm, vejo que seu travis está instalando o docker também (lendo no meu telefone); isso substitui a versão pré-instalada? Se você adicionar uma etapa docker info e docker version após a instalação, ela mostra a versão correta (19.03.x) do docker a ser instalada?

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

Resumo

Versão do Docker para ambas as compilações com falha

$ 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 saída de Server Version: 19.03.7 .

versões 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

(A versão relatada está errada, é rc2, o hash de construção corresponde a 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

Problema ainda existente em 19.03.8.

Problema ainda existente em 19.03.8.

Corrigir. Também atualizei meu repositório de teste com as versões 1.25 e 1.26 docker-compose mais recentes, mas todas continuam conforme descrito em https://github.com/LocoDelAssembly/docker-compose-dockerignore

Construa onde o mesmo tipo de informação que colei acima pode ser encontrado: https://travis-ci.org/github/LocoDelAssembly/docker-compose-dockerignore/builds/673393656

Tenho o mesmo problema aqui, .dockerignore não funciona de maneira confiável com docker-compose