Compose: Ignores .dockerignore file

[lukaso]

Here is a simple test case to illustrate the problem. This was verified to work correctly in docker in this issue: https://github.com/docker/docker/issues/14308.

~/projects/docker_tests $ docker-compose --version
docker-compose version: 1.4.0
~/projects/docker_tests $ cat test.sh
#!/bin/bash

rm -rf foo
mkdir -p foo/a/b/c
mkdir -p foo/b/c/d/e

cat >foo/Dockerfile <<EOF
FROM ubuntu
ADD . /foo
WORKDIR foo
EOF

cat >foo/.dockerignore <<EOF
a
b/c
EOF

cat >foo/docker-compose.yml <<EOF
test:
  build: .
  dockerfile: Dockerfile
  volumes:
    - .:/foo
EOF

docker-compose -f foo/docker-compose.yml build
docker-compose -f foo/docker-compose.yml run test find .
~/projects/docker_tests $ ./test.sh
Building test...
Step 0 : FROM ubuntu
 ---> 91e54dfb1179
Step 1 : ADD . /foo
 ---> Using cache
 ---> 02ebfcbd8bc2
Step 2 : WORKDIR foo
 ---> Using cache
 ---> 981d6d1d5fd3
Successfully built 981d6d1d5fd3
.
./.dockerignore
./a
./a/b
./a/b/c
./b
./b/c
./b/c/d
./b/c/d/e
./docker-compose.yml
./Dockerfile

Expected output for the find command is:

.
./.dockerignore
./b
./Dockerfile

[greaber]

I think the issue is that you are doing a volume mount that overlays the stuff added from context. If you take out that "volume" line, it should do what you want.

[lukaso]

You are totally right.

I guess what that means is that the "volume" command ignores the .dockerignore file. Does that mean the .dockerignore file is only intended to be used during docker build commands? I have to say that is not what I would have expected.

[greaber]

I think if you start thinking about all the different contexts in which a docker image could be used (on a different machine, for example -- think of stock images like "ubuntu"), and all the different possibilities for volume mounts, it wouldn't really make much sense for .dockerignore to somehow be consulted for volume mounts.

[lukaso]

OK, that makes sense. The whole reason I need it is because of the much discussed issues with ssh-forward, and the less discussed issues with caching a build (for example during bundle install) between builds that make vanilla docker builds very hard to use in a development environment.

[lukaso]

I thought about this a bit more. I don't think the issue with stock images is a real one, in the sense that you would never have the "ubuntu" Dockerfile or .dockerignore file present from that image when you were using it in a separate context.

Whenever you are mounting a volume, if at that moment you would also like to have a .dockerignore file present, that makes total sense. If you don't want one, don't have one. Otherwise you can find yourself coming up with quite exotic volume commands and some cases cannot be handled at all (i.e. a file based exclusion) where .dockerignore would have been really useful.

Hope this makes sense.

I should probably reopen this as a feature request.

[greaber]

I may not fully understand everything you are saying, but container building and container running are two really separate things, so if your issue is that you want more flexibility around what parts of a directory tree get mounted in a container with volume mounts, it is likely to be confusing to talk about that in terms of .dockerignore. Also, the use case for this is presumably not the ssh-forwarding and build caching you mentioned, because those are build-stage issues, right? Two possible issues with the feature request would be what the use case is and how it could even be implemented given that volume mounts are just an interface to underlying bind mount functionality.

[lukaso]

A few thoughts (trying to get clear in my mind, and thanks for taking the time to talk all this through!):

1) The build stage caching issue bleeds through to the run stage, because that's the only way to get reasonable performance during development (vs. deployment). So yes, if the build stage issues were sorted, this would be less of an issue, though I'd still want to run my container with the local filesystem mounted, and might still want to exclude things.
2) I see how the docker interface keeps build and run very separate, but that's an artificial distinction I suspect. (This is conceptual since I don't know for sure, haven't dug deep enough) But, doesn't docker build execute a docker run , then for each line in the Dockerfile, execute the line, followed by a docker commit? Or am I missing something here?

But you are absolutely right, the ssh-forwarding and caching are the major issues here.

[greaber]

1. I'm actually not totally clear on the build stage caching issue you are referencing. I guess it is common that you might want to have one container that builds stuff and then for your production container you would have a separate Dockerfile that just copies in the built artifacts. Is this related to the issue you are referencing?
2. I think the builder does roughly what you say, but a central difference is the difference between copying files into a container and mounting a volume, which establishes a communication path across the container boundary.

We should probably close this issue.

[shin-]

Note that support for .dockerignore outside of the context of a build would most likely not be a compose feature, but a docker feature. As such it might be more appropriate to discuss it on the mailing list

[dnephin]

Agree, a .volumeignore would have to be supported by docker first, so going to close this issue.

[madhums]

@dnephin Are there any plans for adding .volumeignore ?

[justechn]

+1 for .volumeignore

[askoretskiy]

Hopefully docker would implement this feature so docker-compose could have it in compose file ))