Layer caching and ordering in Docker - Step-by-Step Execution

Process Flow - Layer caching and ordering

Start Dockerfile

↓

Read first instruction

↓

Check cache for layer

↓

Use cached

↓

Add layer to image

↓

Next instruction?

No→Finish image

Yes↓

Repeat for next instruction

Docker reads each instruction, checks if a cached layer exists, reuses it if yes, otherwise builds a new layer, then moves to the next instruction.

Execution Sample

Docker

FROM python:3.12
RUN pip install flask
COPY app.py /app/
RUN pip install requests
CMD ["python", "/app/app.py"]

This Dockerfile installs Flask, copies app.py, installs requests, then runs the app.

Process Table

Step	Instruction	Cache Hit?	Action	Image Layers Count
1	FROM python:3.12	No	Build base python image layer	1
2	RUN pip install flask	No	Run pip install flask, create new layer	2
3	COPY app.py /app/	No	Copy app.py into image, create new layer	3
4	RUN pip install requests	No	Run pip install requests, create new layer	4
5	CMD ["python", "/app/app.py"]	No	Execute CMD instruction (no new layer)	4
6	End of Dockerfile		Image build complete	4

💡 All instructions processed; final image has 4 layers.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
Image Layers Count	0	1	2	3	4	4
Cache Hit	N/A	No	No	No	No	No

Key Moments - 3 Insights

Why no cache hits in this build?

This simulates a first-time build with no prior cache available. Docker executes all instructions and creates layers from scratch. In subsequent identical builds, cache hits would occur for matching instructions.

What happens if we change app.py after building the image?

Docker will detect the COPY instruction changes and rebuild that layer and all layers after it (step 3 and onward), invalidating cache for those steps.

Why is layer ordering important for caching?

Because Docker caches layers in order, if an early layer changes, all following layers must be rebuilt (see execution_table steps 3 and 4). Placing frequently changing instructions later helps cache more layers.

Visual Quiz - 3 Questions

Look at the execution table, at which step does Docker first create a new layer?

A Step 2

B Step 1

C Step 3

D Step 5

💡 Hint

Check the 'Cache Hit?' and 'Action' columns for Step 1.

Look at the execution table, which step does NOT create a new layer (layers count unchanged)?

A Step 5

B Step 4

C Step 2

D Step 3

💡 Hint

Look at the 'Image Layers Count' column; it stays 4.

If the COPY instruction changes, what happens to the layers after it?

A They are reused from cache

B Only the COPY layer rebuilds

C They are rebuilt

D Build stops immediately

💡 Hint

Refer to the key moment about layer ordering and cache invalidation.

Concept Snapshot

Docker builds images layer by layer.
Certain instructions (e.g., RUN, COPY) create a new layer.
Docker caches layers to speed up builds.
If an instruction or its inputs change, following layers rebuild.
Order instructions to maximize cache reuse.
Use COPY late if files change often.

Full Transcript

Docker builds images by reading each instruction in the Dockerfile one by one. For each instruction, it checks if a matching cached layer exists. If yes, Docker reuses that layer to save time. If no, it runs the instruction and creates a new layer. This process repeats until all instructions are processed. The order of instructions matters because if an early layer changes, all layers after it must be rebuilt. For example, installing packages early and copying files later helps reuse cache better. The CMD instruction often hits cache because it usually doesn't change the image contents. Understanding this helps optimize Docker builds for speed.

Practice

1. What is the main benefit of ordering instructions properly in a Dockerfile regarding layer caching?

easy

A. It allows running containers faster

B. It reduces the final image size automatically

C. It makes the Dockerfile easier to read

D. It speeds up rebuilds by reusing cached layers

Solution

1. Step 1: Understand Docker layer caching

   Docker caches each build step as a layer. If a step and all previous steps are unchanged, Docker reuses the cached layer.

2. Step 2: Effect of instruction order on caching

   Placing stable instructions early means those layers rarely change and get reused, speeding up rebuilds.

3. Final Answer:

   It speeds up rebuilds by reusing cached layers -> Option D

4. Quick Check:

   Layer caching = faster rebuilds [OK]

Hint: Put stable steps first to reuse cache and speed builds [OK]

Common Mistakes:

• Thinking order reduces image size automatically
• Believing order affects container runtime speed
• Confusing readability with caching benefits

2. Which of the following Dockerfile instructions is best placed near the top to maximize cache reuse?

easy

A. RUN apt-get update && apt-get install -y curl

B. ENV APP_ENV=production

C. COPY ./app /app

D. RUN pip install -r requirements.txt

Solution

1. Step 1: Identify stable vs frequently changing instructions

   ENV instructions usually change less often than copying app code or installing packages.

2. Step 2: Place stable instructions early

   Placing ENV early helps cache it and subsequent layers, avoiding rebuilds when code changes.

3. Final Answer:

   ENV APP_ENV=production -> Option B

4. Quick Check:

   Stable instructions early = better cache [OK]

Hint: Put environment variables before copying code [OK]

Common Mistakes:

• Putting COPY before ENV causing cache bust
• Installing packages after code copy
• Assuming RUN commands never change

3. Given this Dockerfile snippet, what happens if you change only app.py and rebuild?

FROM python:3.12
COPY requirements.txt /app/
RUN pip install -r /app/requirements.txt
COPY app.py /app/
CMD ["python", "/app/app.py"]

medium

A. Only the last COPY and CMD steps are rebuilt; earlier layers are cached

B. All layers are rebuilt from the first COPY instruction

C. The RUN step is rebuilt but COPY steps are cached

D. The entire image is rebuilt ignoring cache

Solution

1. Step 1: Identify which layers change

   Changing app.py affects only the COPY app.py step and later steps.

2. Step 2: Understand Docker caching behavior

   Layers before COPY app.py remain unchanged and cached, so only last COPY and CMD rebuild.

3. Final Answer:

   Only the last COPY and CMD steps are rebuilt; earlier layers are cached -> Option A

4. Quick Check:

   Change in later file = rebuild later layers only [OK]

Hint: Change late files to rebuild fewer layers [OK]

Common Mistakes:

• Assuming all layers rebuild on any file change
• Thinking RUN step rebuilds when app.py changes
• Believing CMD step never rebuilds

4. You have this Dockerfile:

FROM node:20
COPY . /app
RUN npm install
CMD ["node", "/app/index.js"]

After changing index.js, the npm install step runs again. Why?

medium

A. Because COPY . /app invalidates cache for all later steps

B. Because package.json was changed

C. Because npm install always runs

D. Because index.js is copied before npm install

Solution

1. Step 1: Analyze Dockerfile order and cache invalidation

   COPY . /app copies all files including index.js before npm install step.

2. Step 2: Effect of changing index.js on cache

   Changing index.js changes the context for COPY . /app, invalidating cache for that step and all following steps, including npm install.

3. Final Answer:

   Because COPY . /app invalidates cache for all later steps -> Option A

4. Quick Check:

   Later COPY changes bust cache for previous RUN [OK]

Hint: Copy package files before code to cache npm install [OK]

Common Mistakes:

• Thinking npm install always runs
• Assuming index.js change affects package.json
• Believing COPY . /app is placed after npm install

5. You want to optimize this Dockerfile for faster rebuilds when source code changes:

FROM python:3.12
COPY . /app
RUN pip install -r /app/requirements.txt
CMD ["python", "/app/app.py"]

What is the best change to improve layer caching?

hard

A. Add ENV variables before COPY

B. Move CMD before RUN to cache install step

C. Copy only requirements.txt first, run pip install, then copy rest of source code

D. Combine COPY and RUN into one step

Solution

1. Step 1: Identify frequent changes and stable files

   Source code changes often, requirements.txt changes less frequently.

2. Step 2: Reorder Dockerfile for caching

   Copy requirements.txt and run pip install first to cache dependencies, then copy source code to avoid reinstalling on code changes.

3. Final Answer:

   Copy only requirements.txt first, run pip install, then copy rest of source code -> Option C

4. Quick Check:

   Separate dependencies copy for caching [OK]

Hint: Copy dependencies first, then source code [OK]

Common Mistakes:

• Moving CMD before RUN (invalid order)
• Combining COPY and RUN loses cache benefits
• Adding ENV doesn't affect caching of installs