What is the purpose of the Docker build context?

Question

What is the purpose of the Docker build context? I understand, from the documentation, that it's the "entry" point from which the entire contents will be sent to the docker daemon. But what's the point of sending the entire contents of the current directory, assuming the default use case provided in examples, when we must also explicitly include a COPY or ADD directive in the Dockerfile to ACTUALLY include the contents of the current directory in the generated image? If the context is sent to the daemon to be included in the image, then why are we required to make this extra step. Why doesn't the compressed upload/send/copy task include the contents of the specified directory by default?

e.g. Given this directory structure

-rw-r--r--  1 me me    7 Jun  8 18:52 .dockerignore -rw-r--r--  1 me me 1.1K Jun  9 12:42 Dockerfile drwxr-xr-x 13 me me 4.0K Jun  8 19:43 myproject 

When I run this command docker build -t user/myproject:2.3 .

Then I would expect to see an myproject directory somewhere in the generated image. But, I MUST include

 ADD myproject / 

for that to be the case.

If the build process compresses the current directory contents and sends it to the daemon, where does it go? Why doesn't it make that content available for use in the image?

Answer 1

TL;DR: "because the client and daemon may not even run on the same machine"

The docker command is the docker client of the dockerd that is the service that can run directly in your PC (linux) or under a Linux VM under OSX or Windows.

Q: What is the purpose of the Docker build context?

From here:

Would probably be good to also mention that this has to happen this way because the client and daemon may not even run on the same machine, so without this "context" the daemon machine wouldn't have any other way to get files for ADD or otherwise

---

Q: If the build process compresses the current directory contents and sends it to the daemon, where does it go?

The docker daemon receives the compressed directory and process it on the fly; does not matter where it is stored in that moment.

Q: Why doesn't it make that content available for use in the image?

Think this: How can docker know where do you want to put each file/directory in the target image? With COPY/ADD directives you can control where put each one. The case that you've mentioned is only a trivial example where you have a single directory and a single target.