Docker Fundamentals: Images, Containers, and Writing a Good Dockerfile

Part 9 of 19 · ~2 min

.dockerignore and the Build Context

Around the same time, Priya notices something else: even a one-line change to web's CSS takes a few seconds just to start building, before a single instruction has run. docker build . isn't reading the Dockerfile line by line from the moment you hit enter — the build context it hands to the daemon first is the whole project directory, every file in it, because there's no way to know ahead of time which ones a COPY or ADD further down might reach for. Without a .dockerignore telling it otherwise, that handoff includes node_modules, all of .git's history, the fixtures/ folder of sample receipts from two chapters ago, and anything else that happens to live in the project.

node_modules
.git
.env
*.log
fixtures
dist
coverage
Dockerfile
.dockerignore

You can see exactly what changed by watching the first line docker build ever prints:

# before .dockerignore
Sending build context to Docker daemon  341.2MB

# after
Sending build context to Docker daemon  2.4MB

That 341MB was never going into the image — .git's full history and the sample-receipt fixtures alone accounted for most of it — but every one of those bytes still had to be packaged up and shipped to the daemon before the Dockerfile's first instruction could even start, on every single build.

That slowness is the mild consequence. The sharp one shows up a week later, when Priya is reviewing a web pull request and, out of idle curiosity, runs docker history on the built image — and sees a line that looks distinctly like an environment variable assignment baked into a layer. Marcus had a .env file sitting in his working directory for a local Stripe integration test, forgot it was there, and COPY . . had picked it straight up, because there was still no .dockerignore telling Docker to skip it. The key was test-mode and the branch never got merged, but the near-miss is the lesson: a missing .dockerignore is a real, specific way secrets leak, because a build has no idea which files in a directory are meant to stay local. And a later layer "deleting" that file wouldn't have helped even slightly — you already know why, from the layers chapter.