Layer caching and ordering in Docker - Commands & Configuration

Introduction

Building Docker images can be slow if every step runs from scratch. Layer caching helps speed this up by reusing unchanged steps. Ordering commands well in the Dockerfile makes caching more effective and builds faster.

When you want to speed up Docker image builds by reusing unchanged steps.

When you update your application code often but dependencies rarely change.

When you want to reduce build time during development cycles.

When you want to keep your Docker images small and efficient.

When you want to avoid downloading the same packages repeatedly.

Config File - Dockerfile

Dockerfile

FROM python:3.11-slim

# Install dependencies first to leverage caching
COPY requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir -r /app/requirements.txt

# Copy application code
COPY app/ /app/

WORKDIR /app

CMD ["python", "app.py"]

FROM: sets the base image.

COPY requirements.txt: copies dependency list first to cache this step if unchanged.

RUN pip install: installs dependencies, cached if requirements.txt unchanged.

COPY app/: copies app code, triggers rebuild only if code changes.

WORKDIR: sets working directory.

CMD: runs the app.

Commands

Builds the Docker image named 'my-app' with tag '1.0' using the Dockerfile in the current directory. This creates layers and caches them for future builds.

Terminal

docker build -t my-app:1.0 .

Expected Output

Sending build context to Docker daemon  12.3MB

Step 1/6 : FROM python:3.11-slim

 ---> 3a2f1c4b5d6e

Step 2/6 : COPY requirements.txt /app/requirements.txt

 ---> Using cache

 ---> 7b8c9d0e1f2a

Step 3/6 : RUN pip install --no-cache-dir -r /app/requirements.txt

 ---> Running in 4d5e6f7a8b9c

Collecting flask

Installing collected packages: flask

Successfully installed flask-2.3.2

Removing intermediate container 4d5e6f7a8b9c

 ---> 1a2b3c4d5e6f

Step 4/6 : COPY app/ /app/

 ---> 9f8e7d6c5b4a

Step 5/6 : WORKDIR /app

 ---> Running in 123abc456def

Removing intermediate container 123abc456def

 ---> 0f1e2d3c4b5a

Step 6/6 : CMD ["python", "app.py"]

 ---> Running in abc123def456

Removing intermediate container abc123def456

 ---> 5a6b7c8d9e0f

Successfully built 5a6b7c8d9e0f

Successfully tagged my-app:1.0

→

-t - Assigns a name and tag to the image for easy reference.

Rebuilds the image after changing only the app code. Docker reuses cached layers for dependencies, speeding up the build.

Terminal

docker build -t my-app:1.1 .

Expected Output

Sending build context to Docker daemon  12.5MB

Step 1/6 : FROM python:3.11-slim

 ---> 3a2f1c4b5d6e

Step 2/6 : COPY requirements.txt /app/requirements.txt

 ---> Using cache

 ---> 7b8c9d0e1f2a

Step 3/6 : RUN pip install --no-cache-dir -r /app/requirements.txt

 ---> Using cache

 ---> 1a2b3c4d5e6f

Step 4/6 : COPY app/ /app/

 ---> Running in 9f8e7d6c5b4a

Removing intermediate container 9f8e7d6c5b4a

 ---> 2a3b4c5d6e7f

Step 5/6 : WORKDIR /app

 ---> Running in 789abc123def

Removing intermediate container 789abc123def

 ---> 0f1e2d3c4b5a

Step 6/6 : CMD ["python", "app.py"]

 ---> Running in def456abc123

Removing intermediate container def456abc123

 ---> 6b7c8d9e0f1a

Successfully built 6b7c8d9e0f1a

Successfully tagged my-app:1.1

→

-t - Assigns a new tag to the rebuilt image.

Shows the layers of the image and which steps were cached or rebuilt, helping understand caching effectiveness.

Terminal

docker history my-app:1.1

Expected Output

IMAGE          CREATED         CREATED BY                                      SIZE      COMMENT

6b7c8d9e0f1a   2 minutes ago   CMD ["python", "app.py"]                        0B        

0f1e2d3c4b5a   2 minutes ago   WORKDIR /app                                     0B        

2a3b4c5d6e7f   2 minutes ago   COPY app/ /app/                                 1.2MB      

1a2b3c4d5e6f   10 minutes ago  RUN pip install --no-cache-dir -r /app/requirements.txt  50MB      

7b8c9d0e1f2a   10 minutes ago  COPY requirements.txt /app/requirements.txt      1kB       

3a2f1c4b5d6e   1 day ago       FROM python:3.11-slim                            120MB     

Key Concept

If you order your Dockerfile so that rarely changing steps come first, Docker can reuse cached layers and speed up builds.

Common Mistakes

Copying application code before installing dependencies in the Dockerfile.

This causes Docker to rerun dependency installation every time app code changes, slowing builds.

Copy and install dependencies first, then copy app code to maximize cache reuse.

Changing the requirements.txt file frequently without need.

This invalidates the cache for dependency installation, causing slow rebuilds.

Only update requirements.txt when dependencies actually change.

Summary

Docker builds images in layers and caches each step to speed up future builds.

Ordering Dockerfile commands so dependencies install before app code helps reuse cache.

Use 'docker build' to create images and 'docker history' to inspect layer caching.

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