The build cache and .dockerignore

Why builds are fast the second time

Run docker build twice in a row and the second run finishes instantly with CACHED next to every step. Docker reuses the layer from last time when it can prove nothing changed.

The cache rule, worth memorizing:

1. An instruction's layer is reused if the instruction text is unchanged and any files it copies are unchanged
2. The moment one step misses the cache, every step after it rebuilds too, because each layer builds on the previous one

Rule 2 is why order matters. Put the things that change rarely (dependencies) near the top, and the things that change constantly (your code) near the bottom.

The classic pattern, explained

Now the Dockerfile from lesson 3-1 makes full sense:

COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

Why copy requirements.txt alone first, then everything later? Because of what changes between builds:

• You edit server.py and rebuild. requirements.txt is unchanged, so the COPY and the whole pip install layer are cache hits. Only the final COPY . . reruns. Build time: about a second
• If instead the Dockerfile said COPY . . before pip install, any code edit would invalidate that copy, and rule 2 would force pip to reinstall every package on every build. Build time: minutes, every time

Same image either way. Wildly different feedback loop.

.dockerignore

COPY . . copies the whole build context, which can drag in junk: the .git history, node_modules/, virtualenvs, .env files with secrets. That bloats the image, slows the build, and can leak credentials.

The fix is a .dockerignore file next to your Dockerfile, same idea as the .gitignore you know from the git course:

.git
node_modules
__pycache__
.env
*.log

Anything listed is excluded from the build context, so COPY . . never sees it. Every real project should have one, and .env belongs in it for the same reason it belongs in .gitignore. Secrets get a proper home in lesson 8-2.