.dockerignore workflow unclear

994 Views Asked by At

I have a question about the .dockerignore workflow which I wasn't really able to understand while browsing through the documentation and different internet topics.

Have the following folder structure:

home
   |
   |- folder_1
   |- folder_2

Inside my dockerfile I want to copy the contents of home directory, so I use

COPY ./ /home

Inside .dockerignore I have:

*
!folder_1
!folder_3

I am referring to a non-existent folder - folder_3, which is supposed to be copied, right? I ran it and it looks like there's no problem with that, thus .dockerignore somehow manages this situation.

If I tried to do the same thing without using .dockerignore, targeting a non-existent directory I would get an error.

If anybody can please clear this workflow, or if a duplicate, please attach some information so I can educate myself.

Thanks in advance!

2

There are 2 best solutions below

1
On BEST ANSWER

First of all, .dockerignore works like .gitignore. Inside these files you set the rules on the basis of which files should be added, and which should not.

In your scenario you COPY the whole home directory which consists of folder_1 and folder_2. Your .dockerignore file sets the following rules:

*           # ignore all files/directories
!folder_1   # do not ignore folder_1
!folder_3   # do not ignore folder_3

Regardless of whether there is a folder_1 or folder_3 in your local home directory or not, it won't show you any errors, because it just tries to find particular files/directories that are inside .dockerignore. If it finds this file/directory, it applies the rules. If it doesn't find this file/directory, it doesn't do anything with it.

Hope that's a little bit more clear now.

0
On

You'll occasionally see reference to a Docker build context. The build has two steps:

  1. The docker build client application creates a tar file of its directory parameter, and sends it in an HTTP request to the Docker daemon.
  2. The Docker daemon unpacks the tar file, finds the Dockerfile in it, and runs it using the file content it was given.

.dockerignore only affects the first step: it keeps docker build from sending the Docker daemon particular files. The .dockerignore file doesn't require there to be a folder_3 directory, it just says that if there is one it shouldn't be excluded. The second step on the Docker daemon side doesn't use .dockerignore at all, and when you COPY . /somewhere it copies the entire build context; that is, whatever was sent in the API request.

There are a couple of practical consequences of this workflow. If you have a very large local directory it can take time to send it to the Docker daemon, and the Docker daemon keeps a duplicate copy of it during the build, so it's often worthwhile to .dockerignore your .git directory and a build tree. This setup is also how docker build works with a Docker daemon on a different system or in a VM, and it's why if you try to COPY a file by name that doesn't exist (COPY folder_3 somewhere) you get an error message referencing a Docker-internal path.