Dockerfile Layer Caching
20 min
Docker caches each Dockerfile instruction as its own layer, and reuses a cached layer as long as that instruction (and everything before it) hasn't changed. The moment ONE instruction changes, that layer AND every layer after it must rebuild from scratch — layers before the change stay cached. This is exactly why instruction ORDER matters: putting slow, rarely-changing steps (installing dependencies) before fast, frequently-changing ones (copying application code) keeps routine code changes cheap to rebuild.
def find_rebuild_point(current_instructions, cached_instructions):
for i in range(len(current_instructions)):
if i >= len(cached_instructions) or current_instructions[i] != cached_instructions[i]:
return i
return None
If COPY . . came BEFORE the pip install step instead, changing even a single line of application code would invalidate the cache starting from that copy -- forcing pip install to rerun on EVERY code change, turning a 2-second rebuild into a multi-minute one for no good reason.
Write `find_rebuild_point(current_instructions, cached_instructions)`: compare the two instruction lists position by position. Return the index of the FIRST instruction that differs (or is new), since that instruction and everything after it must rebuild. Return `None` if every instruction matches (a full cache hit).
Why do well-written Dockerfiles put `COPY requirements.txt .` and `RUN pip install ...` BEFORE `COPY . .` (copying the rest of the application code)?
You can determine which Dockerfile layers must rebuild after a change, and understand why instruction ORDER is a real, deliberate performance decision, not an arbitrary style choice.