The .dockerignore is used to control what files are included in the build context. This impacts the COPY and ADD commands in the Dockerfile, and ultimately the resulting image. When you run that image with a volume mount, e.g.:

        {
            "Type": "bind",
            "Source": "/home/adam/Desktop/Dev/ec2-data-analysis/grimlock",
            "Destination": "/opt/project",
            "Mode": "rw",
            "RW": true,
            "Propagation": "rprivate"
        },

That volume mount overrides the contents of the image for that container. All access to the path will go to your desktop directory rather than the image contents, and Linux bind mounts do not have a concept of the .dockerignore file.

When you run this image without the volume mount, you should see different behavior.

For anyone coming across this question in the future, the .dockerignore needs to be in the root of your build context. The build context is the directory you pass at the end of the build command, often a . or the current directory. If you enable BuildKit, it will first check for a Dockerfile.dockerignore where your Dockerfile path/name could be changed. And to test your .dockerignore, see this answer.

Before explaining the use of the .dockerignore file we must spend a little time understanding what docker build does.

Docker build. What does happen when I build an image ?

When you build an image from a Dockerfile using the docker build command the daemon will create a context. That context contains everything in the directory you executed the command in.

What does .dockerignore do and why use it?

The .dockerignore file allows you to exclude files from the context like a .gitignore file allow you to exclude files from your git repository.

It helps to make build faster and lighter by excluding from the context big files or repository that are not used in the build.

From your docs link:

Before the docker CLI sends the context to the docker daemon, it looks for a file named .dockerignore in the root directory of the context.

From build context:

The build context is the argument that you pass to the build command. When your build context is a local directory, a remote Git repository, or a tar file, then that becomes the set of files that the builder can access during the build.

From docker build:

By default the docker build command will look for a Dockerfile at the root of the build context. The -f, --file, option lets you specify the path to an alternative file to use instead.

So you should be able to do:

docker build -f client <path_to_project>

Something to keep in mind using this approach: If you have only one .dockerignore file you wont be able to exclude the source code for the other builds. As a result the source code for all builds will be sent to the docker daemon in each individual build. So be careful that you are not sending large amounts of data.

The .dockerignore file is similar to the .gitignore syntax. Here are some example rules:

# Ignore a file or directory in the context root named "modules"
modules

# Ignore any files or directories within the subdirectory named "modules" 
# in the context root
modules/*

# Ignore any files or directories in the context root beginning with "modules"
modules*

# Ignore any files or directories one level down from the context root named
# "modules"
*/modules

# Ignore any files or directories at any level, including the context root, 
# named modules
**/modules

# Ignore every file in the entire build context (see next rule for how this 
# could be used)
*

# Re-include the file or directory named "src" that may have been previously
# excluded. Note that you cannot re-include files in subdirectories that have 
# been previously excluded at a higher level
!src

Note that "build context" is the directory you pass at the end of your build command, typically a . to indicate the current directory. This directory is packaged from the docker client, excluding any files you have ignored with .dockerignore, and sent to the docker daemon to perform the build. Even when the daemon is on the same host as your client, the build only works from this context and not directly from the folders.

There is only a single .dockerignore for a build, and it must be in the root of the build context. It will not work if it is in your home directory (assuming you build from a subdirectory), and it will not work from a subdirectory of your build context.

To test what is in your current build context and verify your .dockerignore file is behaving correctly, you can copy/paste the following (this assumes you do not have an image named test-context, it will be overwritten and then deleted if you do):

# create an image that includes the entire build context
docker build -t test-context -f - . <<EOF
FROM busybox
COPY . /context
WORKDIR /context
CMD find .
EOF

# run the image which executes the find command
docker container run --rm test-context

# cleanup the built image
docker image rm test-context

The root directory of the context means the root of where you are building from, typically the directory you are running the docker command. It is the usually the last argument to docker commands. So say you are in /X/, when you end a command like docker build -f path/to/docker/Dockerfile ., the last . is the context (current directory), and your docker file should be in /X/.dockerignore. Instead let's say you ran like docker build -f path/to/docker/Dockerfile path/to/docker/Dockerfile, it would be in /X/path/to/docker/.dockerignore.

Another alternative, I believe, is if you add a file /X/path/to/docker/Dockerfile.dockerignore, it will be honored no matter what your build context is.