Sie haben ein Problem mit dem Dateiformat.

Ändern Sie in Ihrem .dockerignore subdir/ in subdir .

Warum funktioniert der .dockerignore für docker build -t subdir ../ aber nicht für docker-compose build ?

Ich habe das gleiche Problem mit Docker-Compose 1.2.0.
Wenn Sie Vanilla Docker Build ausführen, wird die Ignorierdatei abgerufen und das Image erstellt.
Docker-compose verwendet jedoch nicht die Ignorierdatei mit oder ohne den abschließenden Schrägstrich.

Sieht aus wie ein Docker-Py-Problem; In https://github.com/docker/docker-py/pull/604 wird an einem Fix gearbeitet

@aanand sieht aus wie https://github.com/docker/docker-py/pull/604 ins Stocken geraten und wurde dort vom Meilenstein entfernt?

@thaJeztah Ich habe https://github.com/docker/docker-py/pull/721 erstellt, um die Arbeit fortzusetzen.

Hallo,

Ich habe ein seltsames Problem mit .dockerignore:

*.sh

!awesome/script.sh

Mit Docker Build ist alles in Ordnung, aber Docker-Compose hat "awesome / script.sh" nicht gesehen.

Bin ich in der gleichen Ausgabe?

@twillouer das ist ein bekannter Fehler, der von https://github.com/docker/docker-py/pull/721 behoben wurde - er wird in 1.5.0 auf der Compose-Seite behoben.

Vielen Dank !

Dies scheint sogar auf dem neuesten Git-Master auf einigen Maschinen immer noch kaputt zu sein. Auf einem Computer funktioniert dies bei dieser Konfiguration nicht:

Debian 8.2 mit Kernel 3.16.0 mit lxc-docker Version 1.7.1, Build 786b29d
Docker-Compose ist Git Master, HEAD ist bei dabf1e8657674014a5bc89f99edbf2fe0629bb71

Der .dockerignore funktioniert gut für Docker-Builds (der sofort ausgeführt wird), aber nicht für Docker-Compose (der Dinge hochlädt, die nicht für verschiedene Minuten hochgeladen werden sollten).

Siehe auch # 2100

Ich habe das gleiche Problem. Docker-Compose ignoriert ".dockerignore". "Docker Build" funktioniert gut.
System: Windows 10

Ich habe das gleiche Problem mit der Docker Toolbox, die gestern veröffentlicht wurde:

• Windows 7 x64
• Docker Version 1.9.0, Build 76d6bc9
• Docker-Compose 1.5.0

Es hört sich so an, als hätten wir immer noch Probleme mit .dockerignore . Wenn Sie diese Probleme mit compose 1.5.0 haben, fügen Sie bitte ein Beispiel .dockerignore und eine Verzeichnisstruktur bei, damit wir den Fehler reproduzieren können.

Es tut mir leid, dass ich keinen kleineren Anwendungsfall angegeben habe, aber so ist mir das Problem aufgefallen:

Ich habe diese package.json für mein Projekt:

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

Außerdem habe ich diese docker-compose.yml :

web:
  build: .

Das Dockerfile sieht folgendermaßen aus:

FROM node:0.12

Mein .dockerignore enthält eine Zeile (ich habe versucht, einen abschließenden Schrägstrich hinzuzufügen, aber das Problem blieb bestehen):

node_modules

Jetzt kann ich tun

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

Genial, es funktioniert, es werden nur 5 KiB gesendet ( node_modules sind insgesamt ungefähr 10 MiB). Mit docker-compose in 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'

(Ich verwende 1.5.0dev auf diesem Computer, aber ich habe genau das gleiche Problem auf meinem anderen Computer mit 1.5.0 final).

Bei Node treten unter Windows häufig Probleme mit zu langen Pfaden und Dingen auf, aber die Tatsache, dass Docker-Compose versucht, die node_modules zu tarieren, ist der Indikator dafür, dass .dockerignore ignoriert wird.

FWIW, ich habe immer noch Probleme damit unter Linux (Ubuntu) mit Docker-Compose 1.5.0dev, daher ist es wahrscheinlich nicht auf Windows isoliert. Es befindet sich jedoch auf einer Produktionsmaschine, sodass ich nicht einfach einen minimalen Testfall zusammenstellen kann (es funktioniert gut auf meiner Testmaschine).

Ich habe auch dieses Problem.

Verzeichnisaufbau:

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

Ergebnis:

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

Hat jemand eine Problemumgehung gefunden? Ich versuche alles nur in der Docker-Datei zu machen, hatte aber noch kein Glück.

Ich bekomme auch dieses Problem. Könnte es mit der Knotenversion zusammenhängen, die von allen ausgeführt wird? Über dieses Problem: https://github.com/npm/npm/issues/3697 .. Ich kann mir vorstellen, dass ein Upgrade des Knotens (genauer auf npm 3+) das Problem beheben würde, aber das ist eher eine nukleare Option, und .dockerignore sollte es immer noch sein Arbeit.

Obwohl dies anscheinend ignoriert wird, sehe ich dies auch auf einem Linux-Computer.

Ich habe dieses Problem behoben, indem ich eine unnötige Volume-Referenz in meiner Docker-Compose-Datei entfernt habe. Compose ignoriert .gitignore für Volumes.

Ich musste auch meine App aktualisieren, um npm 3+ zu verwenden. Dies gilt jedoch möglicherweise nur für Windows-Benutzer.

@ esc-rtn Die Datei .dockerignore gibt nur an, welche Dateien während _build_ nicht an den Daemon gesendet werden sollen. Wenn Sie während des "Ausführens" ein durch Binden bereitgestelltes Volume verwenden, werden einfach alle Dateien an diesem Speicherort als Volume bereitgestellt (alle Dateien, die auf dem Host vorhanden sind).

Ich sehe auch unter Windows Ähnliches: docker build funktioniert wie erwartet, docker-compose nicht.

Ich habe ein kleines Beispiel auf GitHub mit Notizen in der README.md veröffentlicht: https://github.com/stekershaw/docker-compose-ignore

Eine weitere Runde von Korrekturen für .dockerignore ging nach der Veröffentlichung von Compsoe 1.5.2 in Docker-Py. Könnten Sie die Version Compose 1.6.0 RC2 ausprobieren, um festzustellen, ob sie jetzt behoben ist?

Gerade mit Docker-Compose Version 1.6.0rc2 versucht, Build a7636be.

Ich habe drei Testfälle in meinem Repo und mit 1.5.2 sind zwei davon fehlgeschlagen. Jetzt mit 1.6.0rc2 schlägt nur einer fehl, wenn ich ein Verzeichnis und eine Datei im Verzeichnis ausgeschlossen habe, wie folgt:

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

Ich bekomme in diesem Fall ein identisches Verhalten zwischen docker build und 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

Hallo @aanand , danke für deine Antwort, ich erhalte das gleiche Ergebnis wie du, wenn du deinen Schritten

Bei dem zuvor ausgeführten Test war jedoch auch eine andere Datei in files / test_dir vorhanden. Wenn ich eine weitere Datei zu files / test_dir hinzufüge, sehe ich, dass sie nicht (wie erwartet) mit docker build vorhanden ist, aber mit 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

Dies ist Windows (mit Git Bash als Shell), überprüft mit Docker Compose 1.5.2 und 1.6.0rc2, Docker 1.9.1.

Dasselbe unter Ubuntu 14.04 mit Docker-Compose 1.5.2 und Docker 1.9.1 auszuführen, ist in Ordnung:

# 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

Ich beschäftige mich den größten Teil des Nachmittags immer noch damit.

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

Die Ausgabe erfolgt wie erwartet mit docker build .

docker-compose build --no-cache test über alles kopiert

2992 enthält einige weitere .dockerignore Korrekturen, die in 1.6.1 enthalten sein sollten

Danke @ shin-, leider sehe ich immer noch ein anderes Verhalten mit Docker-Compose 1.6.2 aus Docker Toolbox für 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

Das ist sehr seltsam. Es funktioniert definitiv für mich.

$ 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

Was ist die Ausgabe von pip show docker-py in Ihrer Umgebung?

Ich glaube, ich habe auch das gleiche Problem.

 Docker build .

funktioniert bei mir. Das Einschließen desselben Builds in eine docker-compose.yml-Datei bricht jedoch meinen Build. In meiner .dockerignore-Datei schließe ich das Verzeichnis node_modules für meinen Knotenaufbau aus. Dies ist der relevante Abschnitt aus meiner docker-compose.yml:

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

Ich glaube, ich verwende die neueste Version von 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

Ich verwende Windows 10, x64.

Windows-spezifisches Problem, möglicherweise mit Pfadtrennzeichen?

Ich weiß nicht, wie ich feststellen soll, ob dies mit Pfadtrennzeichen zusammenhängt.

Lassen Sie mich wissen, ob ich beim Testen oder auf andere Weise helfen kann. Im Moment habe ich eine Batch-Datei, die die "ignorierten" Ordner vor dem Build aus dem Projektverzeichnis verschiebt, offensichtlich hässlich.

Danke für Ihre Hilfe.

Der Vollständigkeit halber ist dies meine .dockerignore-Datei:

**/node_modules

Aha! Es ist das Glob-Muster, das das Problem verursacht. Durch Entfernen des "** /" wurde das Problem für mich behoben.

Ich habe zwar eine Problemumgehung für mein spezifisches Problem, aber es bleibt die Tatsache, dass es einen Fehler gibt. Zumindest wird das Glob-Muster ** / mit Docker-Compose nicht richtig analysiert, funktioniert aber gut mit dem regulären Docker-Build-Befehl. Andere Glob-Muster können funktionieren oder nicht.

@bfirsh und alle anderen, die sich interessieren könnten:

Ich habe einen absolut einfachen .dockerignore, der so aussieht:

livedata
readonly-data

Der .dockerignore funktioniert auch nicht (diese beiden Ordner im Build-Kontextordner werden auf den Daemon hochgeladen und es dauert _forever_) und ich bin unter Linux . Ich habe nur auf den aktuellen 1.6.2 aktualisiert, keine Änderung. Wenn ich kein anderes Problem mit demselben Symptom sehe, möchte ich noch einmal wiederholen, dass dies kein Windows-spezifisches Problem zu sein scheint.

+1, auch für mich unter Linux kaputt - glaube nicht, dass es ein Windows-spezifisches Problem ist.

@JonasT @nicbarker Wie bestätigen Sie, dass die in .dockerignore genannten Ordner hochgeladen werden, abgesehen davon , dass es lange dauert? Wenn Sie eine Möglichkeit haben, den Tarball zu überprüfen, möchte ich versuchen, das Problem lokal zu reproduzieren. So wie es ist, habe ich Docker-py ein Debug hinzugefügt und kann es immer noch nicht reproduzieren:

$ 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 es dauert

Das bestätigt das Problem nicht wirklich. Wenn es ein weiteres großes Verzeichnis im Projektstamm gäbe, würde das Verschieben des Builds auf ./context ihn schneller machen.

@dnephin Es gibt dort keine anderen Ordner außer "Kontext" selbst, den ich als Problemumgehung hinzugefügt habe, und drei winzige Textdateien.

@ JonasT Ist es möglich, dass Sie ein großes Verzeichnis .git , das aufgenommen wird?

Edit: NVM, es scheint, ich war wirklich dumm genug, ein Verzeichnis zu verpassen, weil ich die falsche rsync'ed copy> überprüft habe.> Sorry Leute ..

Ich hatte vor einiger Zeit tatsächlich ein Problem damit bei einer älteren Docker-Compose-Version, bei der ich es eingehender untersucht habe, aber vielleicht wurde diese spezielle Instanz, die ich hatte, tatsächlich mit einigen der jüngsten Dockerpy-Updates behoben.

Zurück zu diesem Windows-Problem? :) :)

Hallo,
Ich habe Linux, komponiere 1.6.2, Docker 1.10.3 ... genau das gleiche Problem. Docker verwendet .dockerignore , Compose ignoriert es.

@ulrichSchreiner Können Sie Schritte zur Reproduktion

Hallo,

Hier ist eine Zusammenfassung (https://gist.github.com/ulrichSchreiner/566815cea26ce55b95207e7795cf6962). Das .dockerignore enthält **/node_modules Das Dockerfile fügt eine Datei in einen t1/a/b/c/node_modules Unterordner ein.

Wenn Sie dies mit "Docker Build ..." erstellen, wird eine Fehlermeldung angezeigt, da keine Datei hinzugefügt werden muss (diese wird aufgrund des Musters in .dockerignore korrekt ignoriert). Sie können die Ausgabe in der letzten Datei des Kerns sehen.

Wenn Sie es jedoch mit der angegebenen "docker-compose.yml" erstellen, wird es erfolgreich erstellt -> docker-compose ignoriert die Datei .dockerignore .

und das ist wirklich ein Schmerz, wenn Ihr node_modules -Verzeichnis Hunderte von Megas enthält ....

ich benutze

docker-compose version 1.6.2, build 4d72027

OK, ich kann das reproduzieren. Sieht so aus, als hätte Docker-Py wahrscheinlich einen Fehler mit **/ Regeln.

IIRC, mangelnde Unterstützung für die Syntax ** ist eine bekannte Einschränkung unserer Implementierung von .dockerignore . Siehe https://github.com/docker/docker-py/pull/721#issuecomment -135065043

Gleiches Problem hier. .dockerignore wird bei Verwendung mit Docker-Compose ignoriert
docker-compose version 1.6.2, build 4d72027 OSX

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

Inhalt von .dockerignore

./.git
./.vagrant

.vagrant ist 16 GB groß, daher ist dies eine "große Sache (tm)" für uns.

Es tut uns leid,

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 Sieht aus wie ein Fehler - ich habe ihn unter https://github.com/docker/docker-py/pull/1065 behoben ./ aus Ihren Mustern entfernen und es sollte funktionieren.

Vielen Dank!

Unter Dockuntu 14.04 ist mein Dockerignore einfach **/always_restart.txt . Bei einem regulären docker build (v1.11.2) wird die Datei nicht im Container angezeigt, bei Compose (v1.7.1) jedoch.

Edit1: Scheint, als würde docker-py nicht auf die doppelte Sternchen-Notation testen, und ich vermute, dass dies wahrscheinlich auch nicht funktioniert: https://github.com/docker/docker-py/blob/1.9. 0-release / tests / unit / utils_test.py # L721

Edit2: Die Verwendung des Musters */tmp/always_restart.txt funktioniert mit Compose, daher wird das Muster ** speziell ignoriert

@ agilgur5 Richtig, dies ist ein bekanntes Problem mit Docker-Py. Ich habe https://github.com/docker/docker-py/issues/1117 erstellt, um es zu verfolgen.

Unsere hässliche Problemumgehung in der DOCKERFILE:
Mit git-check-ignore zum Parsen (daher wird git init ) löschen wir einfach alles, was nach dem Kopieren ignoriert werden sollte.
Beachten Sie, dass dies in unserem Fall immerhin COPY s (oder ADD s) sein musste, sonst haben wir wieder unerwünschte Dateien.

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

So entfernen Sie auch Dateien aus dem .gitignore (weil warum nicht)

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

Ich denke, wir haben eine Problemumgehung dafür gefunden, indem wir Datenmengen in docker-compose.yml , indem wir im Grunde die Containerverzeichnisse aufgelistet haben, die nicht überschrieben werden sollen. In unserem Fall wollten wir das Verzeichnis node_modules im Container beibehalten.

Unser docker-compose.yml sieht also so aus:

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

Der volumes dupliziert zwar, was in .dockerignore , bringt uns aber erst einmal in Schwung ...

Ich habe einen allgemeinen Vorschlag für dieses Problem:

Ich würde empfehlen, dieses Problem in "[Meta-Problem]: falsche Behandlung von .dockerignore-Regeln" (oder "[Tracking-Problem]: falsche Behandlung ...") umzubenennen oder dieses Problem einfach zugunsten einer Sammlung zu schließen von kleineren, umsetzbareren Themen. Dies liegt daran, dass (1) Docker Compose die Datei .dockerignore nicht "ignoriert" (wie der Titel des Problems derzeit sagt). Es hat die Regeln einfach nicht richtig implementiert. Und (2) es gibt eine Reihe von Teilen zu diesem Thema. Dies ist nicht nur ein Problem. Zum Beispiel gibt es diese ( ** Verarbeitung) und diese neue, die ich gerade eingereicht habe (Vorrang in der letzten Zeile). Und es kann sehr gut mehr geben.

Da dieser Problem-Thread so lang ist (weil er einen breiten Problembereich abdeckt), sind die einzelnen Probleme, die gelöst werden müssen, im Thread schwer zu finden. Im Gegensatz zu einem allgemeinen Problem ".dockerignore scheint nicht zu funktionieren" schlage ich vor, genau definierte Probleme einzureichen, die isoliert gelöst werden können. Wie derzeit formuliert, wird dieses Problem möglicherweise nie geschlossen, da die Python-Implementierung möglicherweise niemals Parität mit der Referenzimplementierung aufweist.

Ich habe **/**/node_modules aber herausgefunden, dass dieses nicht funktioniert. Also habe ich jedes node_modules-Verzeichnis in meinen Teilprojekten definiert, um diesen Fehler zu beheben.

Vor diesem Hotfix hatte ich beim Installieren von npm-Abhängigkeiten einen "Zugriffsrechtsfehler", da diese bereits vorhanden waren (verursacht durch das Kopieren mit einer nicht funktionierenden Dockerignore-Datei).

Gleiches Problem.

macOS Sierra 10.12.2
Docker Version 1.12.5, Build 7392c3b
Docker-Compose Version 1.9.0, Build 2585387

Das ** -Musterproblem sollte in 1.11.2 behoben werden
Es gibt möglicherweise offene Probleme wie das Problem mit dem Vorrang der letzten Zeile, die in # 3931 und # 3886 separat verfolgt werden. Weitere Updates finden Sie in diesen.

Ich bin mir nicht sicher, ob Docker-Compose mein .dockerignore ignoriert oder es nicht richtig interpretiert (im Gegensatz zu Docker, das gut funktioniert). So bin ich hier gelandet: http://stackoverflow.com/questions/42883596/equivalent-builds-dont-behave-the-same

und hier ist meine .dockerignore -Datei (falls Sie das Problem erkennen können):

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

Es scheint, dass mein docker-compose build die .dockerignore Datei vollständig ignoriert.
docker build funktioniert wie erwartet.

$ 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

Mein .dockerignore sieht so aus

.bundle
.git
.gitignore
test
tmp
log

also hier nichts besonderes.
Ich benutze Ubuntu 16.04, aber ich weiß nicht, ob das wichtig ist.

Übrigens: Kann jemand erklären, warum docker-compose build nicht den gleichen Code wie docker build , um ein Bild mit Dockerfile und all dem Zeug zu erstellen? Warum gibt es eine offensichtliche Codeduplizierung (die nicht wirklich gut funktioniert, wie dieses Problem zeigt)?

Warum wurde diese Ausgabe geschlossen und wie öffnen wir sie erneut? Die Software ist eindeutig defekt und muss repariert werden

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

Ah. danke shin. froh, dass es angesprochen wird

Ich habe die Probleme Nr. 3931 und Nr. 3886 wie vorgeschlagen gelesen, aber mein .dockerignore ist nichts Besonderes, sodass ich mein Problem nicht genau zuordnen konnte.
Ich arbeite überhaupt nicht für mich und es spielt keine Rolle, was in meinem .dockerignore ist.

So dumm, es war mein Fehler.:dizzy_face:
Ich habe meinen Code als Volume gemountet, damit klar ist, dass nichts ignoriert wird. Das tut mir leid.

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

das scheint ungelöst?

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:

Knotenmodule
dist
`` `

aber beide Ordner werden trotzdem erstellt ...

Ich hatte das gleiche Problem. gerade als ich bemerkte, dass ich auf einer alten Compose-Version bin. Auf docker-compose version 1.22.0-rc1, build e7de1bc3 aktualisiert.

Das Problem ist, dass die mit debian / ubuntu gelieferte Compose-Version zu alt ist.

Jetzt funktioniert es besser, aber immer noch nicht dasselbe wie docker build

Dies ist noch ungelöst. Ausführen von Docker für Mac, neueste Version (Docker 18.03.1-ce-mac65).

Mein .dockerignore:

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

aber beide werden bei Verwendung von Docker-Compose in den Container übergeben.

https://github.com/docker/docker-py/pull/2065 ist in 1.22.0 RC2 enthalten und sollte dies beheben.

Ich verwende Docker für Mac Version 18.06.1-ce-mac73 (26764) und der Fehler ist immer noch da.

Ich benutze:

Docker-Compose Version 1.22.0, Build f46880f
Docker Version 18.06.1-ce, Build e68fc7a

Unter Ubuntu 16.04 Xenial und Docker-Compose-Build wird der folgende .dockerignore ignoriert:

**/*.jpg **/*.png **/*.pyc **/*.solverstate **/*.caffemodel **/*.tgz **/.pytest_cache **/*__pycache__* **/.git **/node_modules *.egg-info .eggs *Dockerfile* build dist
Da es jetzt doppelte Sternchen interpretieren soll, weiß ich nicht, was die Ursache sein kann. Jemand mit dem gleichen Problem?

Da es jetzt doppelte Sternchen interpretieren soll, weiß ich nicht, was die Ursache sein kann. Jemand mit dem gleichen Problem?

Ich habe das gleiche Problem (mit **/.tox ).

Ich hatte das gleiche Problem. Ich benutze verschiedene Kontexte.
docker-compose.yml befindet sich im App

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

Mein Dateibaum:

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

Einen schönen Tag noch!

@ zymtx5g79k Das funktioniert bei mir nicht.

Verzeichnisaufbau:

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

docker-compose.yml

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

@rodrigobdz , bitte überprüfen:
docker-compose.yml :

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

.dockerignore :

/docker

Dateistruktur :

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

Immer noch das gleiche Ergebnis: Das Verzeichnis .git befindet sich beispielsweise im Container. Ich werde hier meinen .dockerignore posten. Vielleicht hat es selbst ein Problem.

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

.git
.gitignore
README.md

@rodrigobdz Ich kann das Problem nicht reproduzieren (Docker Compose Version 1.22.0 wird ausgeführt).

Bereiten Sie den Test vor;

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

Erstellen Sie mit 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

Stellen Sie sicher, dass der Inhalt nicht hinzugefügt wurde.

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

2 directories, 3 files

Benennen Sie nun .dockerignore und führen Sie den Build erneut aus.

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

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

Stellen Sie sicher, dass der Inhalt nicht mehr ignoriert und dem Bild hinzugefügt wird:

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

(Bearbeiten: Aktualisierte Ausgabe des ersten Laufs, da ich vergessen habe, tree beim ersten Mal mit -a auszuführen)

@thaJeztah Danke, dass hast , es dir anzusehen. Ich habe das Problem gefunden.

Mein Anwendungsfall ähnelt dem unter https://github.com/docker/compose/issues/2098#issue -108463351 beschriebenen. Ich verwende einen COPY -Befehl in meiner Docker-Datei und mounte zusätzlich dasselbe Verzeichnis wie ein Volume .

Ich hatte erwartet, dass die Ausschlüsse in .dockerignore auf das Volume angewendet werden, wie unter https://github.com/docker/compose/issues/2098#issuecomment -143505943 beschrieben.

Ich hatte erwartet, dass die Ausschlüsse in .dockerignore auf das Volume angewendet werden, wie in # 2098 (Kommentar) beschrieben.

Nein, wenn Sie einen Pfad vom Host aus binden, befindet sich Docker nicht "in der Mitte". Unter Linux wird dieses Verzeichnis buchstäblich vom Host im Container bereitgestellt. Auf Docker Desktop (Docker für Mac / Windows) ist eine zusätzliche "Magie" erforderlich, um die Dateien in der VM verfügbar zu machen, auf der der Dämon (und der Container) ausgeführt werden. Im Wesentlichen funktioniert dies jedoch genauso wie unter Linux.

.dockerignore wird nur während des Builds verwendet und war dazu gedacht, Builds zu beschleunigen. um zu verhindern, dass Dateien an den Daemon gesendet werden müssen, die im Image nicht verwendet / gewünscht werden.

Danke für die Klarstellung! Ich bin der Meinung, dass diese Erklärung in den Dokumenten enthalten sein sollte, um weitere Missverständnisse in der Community zu vermeiden. Derzeit konzentriert sich die Dokumentation mehr auf das Ignorieren von Dateien als auf den Umfang von .dockerignore selbst.

Diese Seite der Dokumentation beschreibt die Docker-Datei und docker build ; aus dieser Perspektive; Ich frage mich, ob es sinnvoll wäre zu beschreiben, dass es für andere Befehle / Verwendungen nicht funktioniert.

Nun, wenn es eine häufige Ursache für Missverständnisse ist und es offensichtlich ist, wäre es sicherlich sinnvoll, es dort erwähnen zu lassen.

Ein einziger Satz in der Dokumentation hätte uns @thaJeztah und allen Benutzern unten viel Zeit gespart.

Ausgabe 1607

Ausgabe 2098

Ich wollte nur dieses Problem +1.

Ich verwende Docker-Copose: 1.23.2 (das neueste, das ich zwischen Homebrew und PIP finden konnte)
Betriebssystem: Mac OS 10.14.2

Es ignoriert immer noch meine .docker-Datei beim Erstellen. Ich werde die Dinge in der Zwischenzeit explizit kopieren müssen.

Ich habe dieses Problem behoben, indem ich eine unnötige Volume-Referenz in meiner Docker-Compose-Datei entfernt habe. Compose ignoriert .gitignore für Volumes.

Dies hat es für mich behoben - Docker-Compose ignoriert eine .dockerignore-Datei in einem gemounteten Volume.

@xvrqt Ich habe in der letzten Woche wahrscheinlich Stunden mit zufälligen Fehlern verschwendet, da meine Konfigurationsdatei nicht ordnungsgemäß kopiert wurde (mein Erstellungsprozess sollte sie kopieren, wurde jedoch durch die nicht verwendete .dockerignore-Datei blockiert). Das ist irgendwie unglaublich.

Vielen Dank, dass Sie das hervorgehoben haben.

Hallo! Wie ist der Status davon? Ich habe sehr einfache Docker-Compose.yml-Szenarien vorbereitet, die keine Volumes beinhalten, und dennoch beim Erstellen von Remote-Git-Repo .dockerignore erfasst.

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

Wird der Fehler erwartet, den ich in der Hauptniederlassung habe? Gibt es andere Lösungen als das Erstellen und Markieren des Bildes mit Vanilla Docker und die anschließende Verwendung in docker-compose.yml?

Vielen Dank

Gibt es andere Lösungen als das Erstellen und Markieren des Bildes mit Vanilla Docker und die anschließende Verwendung in docker-compose.yml?

Wenn Sie die aktuelle Version von compose ausführen, können Sie die Optionen COMPOSE_DOCKER_CLI_BUILD=1 (und DOCKER_BUILDKIT=1 ) verwenden, damit Docker Compose die nativen docker build .

Ihr Beispiel sieht anders aus als das hier diskutierte. Es kann also sinnvoll sein, ein neues Ticket zu eröffnen (falls es noch keines gibt).

Danke @thaJeztah! Funktioniert mit COMPOSE_DOCKER_CLI_BUILD=1 , aber wenn ich auch DOCKER_BUILDKIT=1 hinzufüge, schlägt dies fehl (aus einem nicht verwandten Grund).

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

Hm, ich vermute, das ist ein Fehler in der Version von Docker, die dort läuft. Docker 18.06 ist ziemlich alt (und EOL); Diese Version von Docker hat eine ziemlich frühe Version von BuildKit, die noch nicht stabil war.

`` `
=> FEHLER [intern] Metadaten für docker.io/library/alpine:3.9.5 0.1s laden
218 => ERROR [1/5] FROM docker.io/library/alpine:3.9.5 0.0s
219 => => docker.io/library/alpine:3.9.5 0.0s auflösen
220 ------ ------
221> [intern] Metadaten für docker.io/library/alpine:3.9.5 laden:
222 ------
223 ------
224> [1/5] FROM docker.io/library/ alpine: 3.9.5 :
225 ------ ------
226 Fehler beim Lösen mit Frontend dockerfile.v0: LLB konnte nicht erstellt werden: Cache-Schlüssel konnte nicht alpine: 3.9.5 nicht gefunden

Oh, hm, ich sehe, dass Ihr Travis auch Docker installiert (von meinem Telefon aus lesen); ersetzt das die vorinstallierte Version? Wenn Sie nach der Installation einen Schritt docker info und docker version hinzufügen, wird die richtige (19.03.x) Version des zu installierenden Dockers angezeigt?

Hier ist es https://travis-ci.org/LocoDelAssembly/docker-compose-dockerignore/builds/658435194

Zusammenfassung

Docker-Version für beide fehlgeschlagenen Builds

$ 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 Ausgabe ist ein bisschen groß, also nicht eingeschlossen, aber Server Version: 19.03.7 .

Docker-Compose-Versionen

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

(Die gemeldete Version ist falsch, es ist rc2, der Build-Hash stimmt mit rc2 überein.)

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

Das Problem ist am 19.03.8 noch vorhanden.

Das Problem ist am 19.03.8 noch vorhanden.

Richtig. Außerdem wurde mein Test-Repo mit den neuesten Docker-Compose-Versionen 1.25 und 1.26 aktualisiert, aber alle sind weiterhin wie unter https://github.com/LocoDelAssembly/docker-compose-dockerignore beschrieben

Erstellen Sie dort, wo sich die oben eingefügten Informationen befinden: https://travis-ci.org/github/LocoDelAssembly/docker-compose-dockerignore/builds/673393656

Haben Sie das gleiche Problem hier, .dockerignore funktioniert nicht zuverlässig mit docker-compose