Hi there
when I use dockerfile to compile a docker image, the log outputs ‘Sending build context to Docker daemon 899.5 MB’,
I want to know where the files in the current directory are sent to?
Can anyone help me, thanks a lot
Is anyone there please help me?
I use docker since 2014 and never cared about where the physical files of the build context are stored.
Why do you feel the need to know where the physical files are stored? What are you planing to do with this information?
@meyay My view is that it is indeed useful to know what happens with the Docker context so you can make sure nothing wil be sent to a place where you don’t want it to see and forget about that if it stays there. Fortunately it won’t, but I can understand the question. Of course I always like to find out how certain components of Docker work behind the scenes 
@arshwgi If your Docker client and the Docker daemon is on the same machine, it will be just sent to /<docker_data_root>/tmp/ which is usually /var/lib/docker/tmp/.
If your client is on a different machine and it communicates with a remote Docker daemon, it will be sent to the same folder on that machine, not on client side.
It only happens when you are not using buildkit. So if you do this:
DOCKER_BUILDKIT=1 docker build . -t localhost/test
the context will not be sent anywhere, only the files that you actually refer to in the Dockerfile and those files will be saved immediately on the filesystem layer of the docker image somewhere in <docker_data_root>/overlay2/.
Even if you don’t use buildkit and Docker sends the context to the daemon, Docker will remove it after the build. If you want to make sure that Docker will not send any sensitive data to a remote machine which you don’t need in your image, create a .dockerignore file like .gitignore and define what you want to send and what you don’t.
@rimelek Yes, there is something sensitive in context when building a docker image, that’s why I want to know where to send these files
Your answer is very professional, it just solved my question, thank you very much,Thanks♪(･ω･)ﾉ
@meyay thank you
I am still curious as of why it matters to know where the files are stored, as it is obvious they are stored on the local file system.
The more significant problem is that files/ENV variables can unintentionally end up in the image cache or in the final image.
There are plenty of ways to leak unwanted information into the final image, and there are ways to build images that they may not even require sensitive information during the build at all.
Depending on your environmental/tooling constraints, this can be easy to ommit or become quite challenging. For instance, if you need auth credential to fetch artifacts from an artifact store, it might be better to do so outside the image build and use the COPY instruction to just copy the artifacts into the image, instead of requiring the tool and its auth information in the image. If auth credentials are required to install os packages from a repo that requires auth information, then the details should be passed in as --build-arg and used as ARG inside the Dockerfile. The same is true if a proxy is required.
To not accidentally leak information into image layers, it is important to understand that file changes in an image layer can not be undone in a following image layer. Lets say you create a file with credentials in one RUN instruction and remove it in a later RUN instruction, this file will still exist in the image layer where the file was created, and can potentially extracted by anyone who is able to pull the final image.
But docker is not the only tool to build images. Actually, most companies use tools like kaniko or buildah to build their Container Images, because they run in userspace and do not require access to the docker engine or privileged build containers in their build pipelines.
This is the reason I wanted to understand why you cared to know where the files are stored. As there might be a more significant issue underneath that question.
@rimelek I didn’t know, the old way to build images stored files in the /tmp folder. Though, it has been years since I used the non buildkit version to build images.
1 Like
First of all, I don’t know much about Docker. I’m just a beginner
The cause of the problem is that I mistakenly executed the command to build a Docker image in a folder containing sensitive files. When I saw a log like ‘Sending build context to Docker daemon 899.5 MB’, I thought Docker would send these sensitive files to external servers, such as Docker’s official website. When I searched with Google and saw the official documents of Docker, I can’t find where to send these files, so I created this discussion here
Because these sensitive files are very important and cannot be known by others, I want to determine whether the sensitive files have been disclosed by knowing the location where they were sent
Now it makes sense. Then @rimelek is indeed the answer to your question. But bear in mind what I wrote last, as it’s easy to make mistakes and unintentionally leak information.
Your advice is also important to me, thank you