Why multi-stage builds reduce image size in Docker - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why do multi-stage builds reduce Docker image size?

Which explanation best describes why multi-stage builds help reduce the final Docker image size?

A They merge all layers into a single layer to reduce overhead.

B They allow copying only the necessary artifacts from build stages, excluding build tools and temporary files.

C They remove all unused files from the base image before starting the build.

D They compress the image layers automatically during the build process.

💡 Hint

Think about how build tools and temporary files affect image size and what multi-stage builds let you do with them.

Multi-stage builds let you use multiple FROM statements. You can build your app in one stage with all tools, then copy only the final app files to a smaller base image. This excludes build tools and temporary files, reducing image size.

💻 Command Output

intermediate

Output size difference with multi-stage build

Given the following Dockerfile snippet, what will be the approximate size difference between the final image using multi-stage build versus a single-stage build?

FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

FROM alpine:latest
COPY --from=builder /app/myapp /myapp
CMD ["/myapp"]

A The final image is empty because no files are copied.

B The final image is larger because it includes both Go compiler and Alpine base.

C The final image size is the same as the builder stage.

D The final image is much smaller because it excludes the Go compiler and source files.

💡 Hint

Consider what files and tools are present in each stage and what is copied to the final image.

The builder stage includes the Go compiler and source code, which are large. The final stage copies only the compiled binary to a small Alpine base image, making the final image much smaller.

❓ Configuration

advanced

Identify the correct multi-stage Dockerfile snippet

Which Dockerfile snippet correctly uses multi-stage builds to reduce image size by building a Node.js app and copying only the production files?

A

FROM node:18
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
CMD ["node", "dist/index.js"]

B

FROM node:18 AS build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

FROM node:18-slim
WORKDIR /app
COPY --from=build /app ./
CMD ["node", "dist/index.js"]

C

FROM node:18 AS build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

FROM node:18-slim
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]

D

FROM node:18 AS build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

FROM node:18-slim
WORKDIR /app
COPY --from=build /app/package.json ./
CMD ["node", "dist/index.js"]

💡 Hint

Look for copying only the build output and production dependencies, not the entire source.

Option C copies only the build output folder and node_modules from the build stage to the smaller base image. Option C copies the entire /app folder including source files, increasing size. Option C copies only package.json, missing build output. Option C is single-stage.

❓ Troubleshoot

advanced

Why does the final image include build tools despite multi-stage build?

A developer uses a multi-stage Dockerfile to build a Java app but notices the final image is still very large and contains build tools. What is the most likely cause?

A They copied the entire build directory including build tools instead of only the compiled jar.

B They used a multi-stage build but forgot to specify the final CMD instruction.

C They used an Alpine base image which is larger than the build image.

D They did not run 'docker system prune' after building.

💡 Hint

Think about what files are copied from the build stage to the final image.

If the entire build directory is copied, it includes build tools and temporary files, making the final image large. Only the compiled artifact (e.g., jar file) should be copied.

✅ Best Practice

expert

Best practice for minimizing image size with multi-stage builds

Which practice best helps minimize Docker image size when using multi-stage builds for a compiled language project?

A Use a minimal base image in the final stage and copy only the compiled binary and necessary config files.

B Install all build tools in the final stage to ensure compatibility.

C Copy the entire source code and build tools to the final stage for debugging.

D Use a single-stage build with all dependencies to simplify the Dockerfile.

💡 Hint

Consider what files are essential to run the app and what can be left out.

Using a minimal base image and copying only the compiled binary and necessary config files keeps the final image small and efficient. Including build tools or source code increases size unnecessarily.

Practice

1. Why do multi-stage builds in Docker help reduce the final image size?

easy

A. Because they run containers faster

B. Because they use a single large base image for all stages

C. Because they copy only the necessary files from build stages to the final image

D. Because they install all dependencies in every stage

Solution

1. Step 1: Understand multi-stage build process

   Multi-stage builds use multiple FROM statements to separate build and runtime environments.

2. Step 2: Identify file copying behavior

   Only necessary artifacts are copied from build stages to the final image, excluding build tools and dependencies.

3. Final Answer:

   Because they copy only the necessary files from build stages to the final image -> Option C

4. Quick Check:

   Copying only needed files = smaller image [OK]

Hint: Remember: copy only what you need to keep image small [OK]

Common Mistakes:

• Thinking all stages are combined fully
• Assuming all dependencies stay in final image
• Believing multi-stage builds speed up container runtime

2. Which of the following is the correct syntax to copy files from a previous stage named builder in a multi-stage Dockerfile?

easy

A. COPY --from=builder /app/build /app

B. COPY builder:/app/build /app

C. COPY /app/build builder:/app

D. COPY --stage=builder /app/build /app

Solution

1. Step 1: Recall Dockerfile COPY syntax for multi-stage

   The correct syntax uses COPY --from=stageName source destination.

2. Step 2: Match syntax with options

   COPY --from=builder /app/build /app matches the correct syntax exactly.

3. Final Answer:

   COPY --from=builder /app/build /app -> Option A

4. Quick Check:

   Use --from=stageName to copy files [OK]

Hint: Use COPY --from=stageName to copy files between stages [OK]

Common Mistakes:

• Using incorrect flags like --stage
• Trying to copy with colon syntax like builder:/path
• Reversing source and destination paths

3. Given this Dockerfile snippet, what will be the size impact on the final image?

FROM node:18 AS builder
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=builder /app/build /usr/share/nginx/html

medium

A. The final image will be small because only the build output is copied

B. The final image will be empty because no files are copied

C. The final image will be large because it includes all node modules

D. The final image will include the entire node base image

Solution

1. Step 1: Analyze build and final stages

   The builder stage installs node modules and builds the app. The final stage uses a lightweight nginx image.

2. Step 2: Check what is copied to final image

   Only the build output folder /app/build is copied to nginx's html folder, excluding node modules and build tools.

3. Final Answer:

   The final image will be small because only the build output is copied -> Option A

4. Quick Check:

   Copying only build output reduces image size [OK]

Hint: Copy only build artifacts, not full build environment [OK]

Common Mistakes:

• Assuming node modules are copied to final image
• Thinking final image includes builder base image
• Believing no files are copied at all

4. You wrote a multi-stage Dockerfile but the final image is unexpectedly large. Which mistake could cause this?

medium

A. Using a lightweight base image in the final stage

B. Using multiple FROM statements

C. Not naming the build stage

D. Copying the entire build directory including node_modules to the final stage

Solution

1. Step 1: Identify common causes of large final images

   Copying unnecessary files like dependencies increases image size.

2. Step 2: Match mistake to options

   Copying the entire build directory including node_modules to the final stage describes copying the entire build directory including node_modules, which bloats the image.

3. Final Answer:

   Copying the entire build directory including node_modules to the final stage -> Option D

4. Quick Check:

   Copying unneeded files causes large images [OK]

Hint: Avoid copying full build folders with dependencies [OK]

Common Mistakes:

• Thinking multiple FROM statements cause large images
• Believing missing stage names cause size issues
• Assuming lightweight base images increase size

5. You want to build a Go application using multi-stage builds. The first stage compiles the app, and the second stage runs it. Which Dockerfile snippet best reduces the final image size?

hard

A. FROM golang:1.20
WORKDIR /app
COPY . .
RUN go build -o app
CMD ["./app"]

B. FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o app

FROM alpine
COPY --from=builder /app/app /app/app
CMD ["/app/app"]

C. FROM alpine
COPY . .
RUN go build -o app
CMD ["./app"]

D. FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o app
COPY . .
CMD ["./app"]

Solution

1. Step 1: Understand multi-stage build for Go app

   Build the app in a full Go environment, then copy only the compiled binary to a small base image.

2. Step 2: Evaluate options for size reduction

   FROM golang:1.20 AS builder WORKDIR /app COPY . . RUN go build -o app FROM alpine COPY --from=builder /app/app /app/app CMD ["/app/app"] uses golang image to build, then copies only the binary to alpine, minimizing final image size.

3. Final Answer:

   FROM golang:1.20 AS builder WORKDIR /app COPY . . RUN go build -o app FROM alpine COPY --from=builder /app/app /app/app CMD ["/app/app"] -> Option B

4. Quick Check:

   Build in full image, run in minimal image [OK]

Hint: Build in full image, copy only binary to small image [OK]

Common Mistakes:

• Building and running in same large image
• Trying to build in alpine without Go tools
• Copying full source code to final image