Cache mount for faster builds in Docker - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a cache mount in Docker builds?

A cache mount is a way to save and reuse files or data between Docker build steps to speed up the build process by avoiding repeated work.

beginner

How does using a cache mount improve Docker build speed?

It stores intermediate files or dependencies so Docker can reuse them in later builds instead of downloading or compiling again.

intermediate

Which Dockerfile syntax enables cache mounts?

The syntax is: RUN --mount=type=cache,target=/path/to/cache <command>. This tells Docker to use a cache at the specified path during the RUN step.

intermediate

What is the purpose of the 'target' option in a cache mount?

The 'target' option specifies the directory inside the container where the cache will be stored and reused during the build.

intermediate

Can cache mounts be shared across different builds?

Yes, cache mounts can be reused across builds if the cache is stored persistently, which helps speed up builds on the same machine or CI environment.

What does the cache mount do in a Docker build?

A Saves and reuses files between build steps to speed up builds

B Deletes all files after each build step

C Runs the build in a separate container

D Uploads the build to Docker Hub automatically

Cache mounts save files between steps so Docker can reuse them, making builds faster.

Which Dockerfile command syntax uses cache mounts?

A RUN --mount=type=cache,target=/cache <command>

B COPY --cache /cache <command>

C FROM --cache=enabled

D CMD --cache /cache

The RUN command with --mount=type=cache,target=... enables cache mounts during build steps.

What is the role of the 'target' in a cache mount?

A It specifies the base image for the build

B It names the cache for Docker Hub

C It sets the directory inside the container to store cached data

D It defines the network for the build

The 'target' option tells Docker where inside the container to save and reuse cached files.

Can cache mounts help when building the same Docker image multiple times?

A Only if the build uses multiple stages

B No, cache mounts are cleared after each build

C Only if the image is pushed to a registry

D Yes, they speed up repeated builds by reusing cached data

Cache mounts keep data between builds, so repeated builds run faster.

Which of these is NOT a benefit of using cache mounts?

A Faster builds by reusing data

B Automatic image deployment

C Less CPU usage during repeated builds

D Reduced network downloads during build

Cache mounts speed up builds but do not handle image deployment.

Explain how cache mounts work in Docker builds and why they help speed up the process.

Think about how saving work done once can save time later.

Describe the syntax to use a cache mount in a Dockerfile and what each part means.

Look at how the RUN command is extended with --mount.

Practice

1. What is the main purpose of using --mount=type=cache in a Dockerfile during build?

easy

A. To save files between build steps and speed up future builds

B. To permanently store files in the final image

C. To share files between running containers

D. To mount host directories into the container at runtime

Solution

1. Step 1: Understand cache mount purpose

   The --mount=type=cache option is used during build to save files temporarily between build steps.

2. Step 2: Identify effect on build speed

   By saving files like package downloads, it avoids repeating work, making future builds faster.

3. Final Answer:

   To save files between build steps and speed up future builds -> Option A

4. Quick Check:

   Cache mount speeds builds = D [OK]

Hint: Cache mounts save build files to speed up next builds [OK]

Common Mistakes:

• Confusing cache mount with runtime volume mount
• Thinking cache mount stores files in final image
• Assuming cache mount shares files between containers

2. Which of the following is the correct syntax to use a cache mount in a Dockerfile RUN command?

easy

A. RUN --mount=type=volume,target=/root/.cache npm install

B. RUN --cache=type=mount,target=/root/.cache npm install

C. RUN --mount=cache,target=/root/.cache npm install

D. RUN --mount=type=cache,target=/root/.cache npm install

Solution

1. Step 1: Check correct mount syntax

   The correct syntax uses --mount=type=cache,target=... inside the RUN command.

2. Step 2: Validate options

   RUN --mount=type=cache,target=/root/.cache npm install matches the correct syntax exactly; others have wrong keywords or types.

3. Final Answer:

   RUN --mount=type=cache,target=/root/.cache npm install -> Option D

4. Quick Check:

   Correct cache mount syntax = A [OK]

Hint: Use --mount=type=cache,target=... exactly in RUN [OK]

Common Mistakes:

• Using --cache instead of --mount
• Omitting type=cache
• Using type=volume instead of cache

3. Given this Dockerfile snippet:

RUN --mount=type=cache,target=/root/.cache pip install -r requirements.txt
RUN --mount=type=cache,target=/root/.cache pip install -r requirements.txt

What is the expected effect on build time when running the second RUN command?

medium

A. The second RUN command will be slower because cache is cleared

B. The second RUN command will be faster because it reuses cached files

C. The second RUN command will fail due to cache mount conflict

D. The second RUN command ignores cache and runs normally

Solution

1. Step 1: Understand cache mount effect on repeated commands

   The cache mount stores files from the first pip install in /root/.cache.

2. Step 2: Predict second RUN command behavior

   The second RUN reuses cached files, so it runs faster by skipping downloads.

3. Final Answer:

   The second RUN command will be faster because it reuses cached files -> Option B

4. Quick Check:

   Cache reuse speeds second build step = B [OK]

Hint: Cache mount speeds repeated installs by reusing files [OK]

Common Mistakes:

• Assuming cache clears between RUN commands
• Thinking cache causes build failure
• Believing cache is ignored during build

4. You wrote this Dockerfile line:

RUN --mount=type=cache,target=/root/.cache npm install

But the cache is not speeding up builds. What is the likely mistake?

medium

A. The cache mount target directory is incorrect or not used by npm

B. You forgot to add --cache flag instead of --mount

C. Cache mounts only work with Python, not npm

D. You must run docker build with --no-cache option

Solution

1. Step 1: Check cache mount target relevance

   Cache mount must target the directory where npm stores cache files, usually /root/.npm, not /root/.cache.

2. Step 2: Understand npm cache usage

   If the target directory is wrong, npm won't use the cache, so builds stay slow.

3. Final Answer:

   The cache mount target directory is incorrect or not used by npm -> Option A

4. Quick Check:

   Correct cache target directory needed = C [OK]

Hint: Match cache target to tool's actual cache folder [OK]

Common Mistakes:

• Using wrong directory for cache mount target
• Confusing --cache and --mount flags
• Thinking cache mounts only work for some languages

5. You want to speed up a Docker build that uses apt-get update and apt-get install. How can you use cache mounts to optimize this build?

hard

A. Use RUN --mount=type=cache,target=/etc/apt before apt-get update

B. Use RUN --mount=type=cache,target=/var/lib/apt after apt-get install

C. Use RUN --mount=type=cache,target=/var/cache/apt before apt-get update

D. Use RUN --mount=type=cache,target=/usr/bin/apt before apt-get update

Solution

1. Step 1: Identify apt cache directory

   The apt package manager stores downloaded package files in /var/cache/apt.

2. Step 2: Apply cache mount before update

   Mounting cache at /var/cache/apt before apt-get update saves downloaded package lists and speeds up future runs.

3. Final Answer:

   Use RUN --mount=type=cache,target=/var/cache/apt before apt-get update -> Option C

4. Quick Check:

   Cache apt downloads at /var/cache/apt = A [OK]

Hint: Cache package manager download folders to speed builds [OK]

Common Mistakes:

• Mounting wrong directories like /etc/apt or /usr/bin/apt
• Mounting cache after install instead of before update
• Confusing apt cache with config directories