Speed Up Docker Builds with Layer Caching and dockerignore

Docker assembles an image by running your Dockerfile one instruction at a time, and every instruction becomes a read-only layer stacked on the one before it. BuildKit caches those layers and reuses them on the next build, but only for as long as their inputs stay unchanged. Each layer is keyed on its instruction plus the contents of any files it reads, so the moment a COPY picks up an edited file, that layer's hash changes and every layer beneath it is rebuilt from scratch. Instruction order is what decides the cost: place your source code above the dependency install and a one-line edit reinstalls every package, but put the dependencies first and the same edit rebuilds in seconds.

Ordering is only half the story. Before a build even starts, the Docker CLI bundles up the build context (every file in your project directory) and ships it to the daemon. Without a .dockerignore, that bundle drags along node_modules, .git, logs, and whatever else is lying in the folder, which slows every build, inflates your COPY instructions, and can quietly bake secrets into image layers. In this lab, you will build a deliberately slow Dockerfile and time what an unnecessary dependency reinstall costs, reorder its instructions into a cache-friendly version, add a .dockerignore to shrink the context, and finish by inspecting the finished layers with docker history and docker diff to see exactly what each build changed.

Objectives

Upon completion of this beginner level lab, you will be able to:

• Explain how Docker's layer cache is keyed and what triggers invalidation for COPY, RUN, and ARG instructions.
• Diagnose a slow Dockerfile by timing rebuilds after a one-line source change and reading the BuildKit CACHED / DONE markers.
• Refactor a Node.js Dockerfile so dependency installation lives in a stable upper layer that survives source edits.
• Author a .dockerignore that excludes node_modules, VCS files, logs, and documentation from the build context.
• Inspect a built image's layer history with docker history and map each layer back to a Dockerfile instruction.
• Use docker diff to compare the running container's filesystem against its image and identify writable-layer changes.

Who is this lab for?

This lab is designed for:

• Developers who have already written a basic Dockerfile and want to speed up their builds in everyday development.
• Platform engineers tuning CI build pipelines for image-heavy services.