How Docker’s Build Cache Works
- Each
RUN,COPY, orADDinstruction produces a layer. - After a successful build, layers are stored in the local cache.
- On subsequent builds, Docker compares:
- The instruction itself.
- Any files referenced by
COPY/ADD.
- If both match the cached layer, Docker reuses it.
- Any change invalidates that layer and all subsequent layers, triggering a rebuild from that point.
Cache Invalidation Example
Changing the pip install command:pip3 install layer and everything that follows—earlier layers remain cached. Similarly, updating app.py in:
Cache Busting with Combined Instructions
Separatingapt-get update and apt-get install can lead to stale package lists:
Stale package lists may cause installation of outdated or missing packages.
- Forces an update immediately before installation.
- Lists packages alphabetically and on separate lines for readability.
Always include
&& rm -rf /var/lib/apt/lists/* if you want to reduce image size.Version Pinning
Pinning package versions ensures consistent builds across environments:Optimizing Instruction Order
Place instructions that change least frequently at the top of your Dockerfile. This maximizes cache reuse.| Instruction Type | Change Frequency | Caching Benefit |
|---|---|---|
| Base Image & System | Low | Cached once unless you change the base |
| Package Installation | Low–Medium | Reused until you add or remove packages |
| Application Dependencies | Medium | Rebuilt when dependencies change |
| Application Code | High | Only this layer rebuilds on code changes |
Example: Optimal Order
COPY app.py first forces Docker to rerun all subsequent layers on every code update, significantly slowing builds.