Multi-stage builds for smaller images in MLOps - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Purpose of Multi-stage Builds

Why do we use multi-stage builds in Dockerfiles when creating container images?

A To reduce the final image size by separating build and runtime environments

B To increase the build time by adding more steps

C To make the image compatible only with specific operating systems

D To add multiple entry points to the container

💡 Hint

Think about how build tools and runtime dependencies differ.

Multi-stage builds allow you to use one stage to compile or build your application and then copy only the necessary artifacts to a smaller runtime image. This reduces the final image size and improves efficiency.

💻 Command Output

intermediate

Output of Multi-stage Docker Build

Given this Dockerfile snippet, what will be the size difference between the final image and the build stage image?

FROM python:3.12-slim AS build
RUN pip install --no-cache-dir numpy

FROM python:3.12-slim
COPY --from=build /usr/local/lib/python3.12/site-packages /usr/local/lib/python3.12/site-packages
CMD ["python3"]

A Both images have the same size

B Final image is larger because it includes all build dependencies

C Final image is smaller because it excludes build tools and caches

D Final image will fail to build due to missing dependencies

💡 Hint

Consider what is copied from the build stage to the final stage.

The build stage installs numpy and any build dependencies, but only the installed packages are copied to the final image. Build tools and caches are excluded, making the final image smaller.

❓ Configuration

advanced

Correct Multi-stage Dockerfile Syntax

Which Dockerfile snippet correctly uses multi-stage builds to compile a Go application and produce a small final image?

A

FROM alpine:latest AS build
WORKDIR /app
COPY . .
RUN go build -o app

FROM golang:1.20
COPY --from=build /app/app /app
CMD ["/app"]

B

FROM alpine:latest
WORKDIR /app
COPY . .
RUN go build -o app
CMD ["./app"]

C

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

D

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

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

💡 Hint

Remember the build stage needs the Go compiler, but the final image should be minimal.

Option D uses golang image to build the app, then copies the compiled binary to a small alpine image. Option D reverses the stages causing build failure. Options C and D do not use multi-stage builds.

❓ Troubleshoot

advanced

Troubleshooting Missing Files in Final Image

You created a multi-stage Dockerfile but the final image is missing some files needed at runtime. What is the most likely cause?

A Files were not copied from the build stage to the final stage using <code>COPY --from=build</code>

B The base image in the final stage is too large

C The build stage did not run any commands

D The Dockerfile is missing a <code>CMD</code> instruction

💡 Hint

Think about how files move between stages in multi-stage builds.

If files are not explicitly copied from the build stage to the final stage, they won't be present in the final image. The COPY --from=build command is essential.

🔀 Workflow

expert

Optimizing CI Pipeline with Multi-stage Builds

You want to optimize your CI pipeline to build and test a Node.js app using multi-stage Docker builds. Which workflow best reduces build time and image size?

A Install all dependencies and run tests in the final stage only

B Use a build stage to install dependencies and run tests, then copy only production files to final stage

C Run tests outside Docker, then build a single-stage Docker image with all files

D Use multiple final stages each with different dependencies for testing and production

💡 Hint

Consider how multi-stage builds can separate testing and production environments.

Option B uses multi-stage builds to run tests in the build stage and copies only production files to the final image, reducing size and improving pipeline efficiency. Other options either increase image size or complicate the workflow.

Practice

1. What is the main benefit of using multi-stage builds in Docker?

easy

A. They enable Docker images to run on any operating system without modification.

B. They create smaller and cleaner Docker images by separating build and runtime stages.

C. They automatically update the base image to the latest version.

D. They allow running multiple containers simultaneously.

Solution

1. Step 1: Understand multi-stage build concept

   Multi-stage builds separate the build environment from the runtime environment in Dockerfiles.

2. Step 2: Identify the benefit of separation

   This separation removes unnecessary build tools from the final image, making it smaller and cleaner.

3. Final Answer:

   They create smaller and cleaner Docker images by separating build and runtime stages. -> Option B

4. Quick Check:

   Multi-stage builds = smaller images [OK]

Hint: Multi-stage builds reduce image size by splitting build and runtime [OK]

Common Mistakes:

• Confusing multi-stage builds with running multiple containers
• Thinking multi-stage builds update base images automatically
• Assuming multi-stage builds change OS compatibility

2. Which of the following is the correct syntax to start a new stage named 'builder' in a Dockerfile?

easy

A. FROM ubuntu AS builder

B. STAGE builder FROM ubuntu

C. NEW STAGE builder FROM ubuntu

D. BUILD STAGE builder FROM ubuntu

Solution

1. Step 1: Recall Dockerfile multi-stage syntax

   To start a new build stage, Dockerfile uses 'FROM <image> AS <name>'.

2. Step 2: Match correct syntax

   Only 'FROM ubuntu AS builder' matches the correct syntax for naming a stage.

3. Final Answer:

   FROM ubuntu AS builder -> Option A

4. Quick Check:

   Stage naming uses 'FROM ... AS ...' [OK]

Hint: Use 'FROM image AS name' to start a new build stage [OK]

Common Mistakes:

• Using 'STAGE' keyword which does not exist
• Writing 'NEW STAGE' instead of 'FROM ... AS ...'
• Confusing 'BUILD STAGE' with Dockerfile syntax

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

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

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

medium

A. The final image will fail to build due to missing Go compiler in the second stage.

B. The final image will be large because it includes the entire Go build environment.

C. The final image will be small because it only copies the built binary from the builder stage.

D. The final image will include both Alpine and Go base images merged.

Solution

1. Step 1: Analyze multi-stage build steps

   The first stage builds the Go binary using the full Go environment. The second stage uses a minimal Alpine image.

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

   Only the compiled binary '/app/myapp' is copied from the builder stage to the final image, excluding build tools.

3. Final Answer:

   The final image will be small because it only copies the built binary from the builder stage. -> Option C

4. Quick Check:

   Copying only binary = smaller final image [OK]

Hint: Final image size shrinks by copying only needed files [OK]

Common Mistakes:

• Assuming the entire build environment is included in final image
• Thinking the build fails due to missing compiler in second stage
• Believing base images merge into one large image

4. Identify the error in this Dockerfile snippet using multi-stage build:

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

FROM node:18
COPY --from=builder /app/dist ./dist
CMD ["node", "./dist/server.js"]

medium

A. The COPY command in the second stage has incorrect source path syntax.

B. The first stage is missing a WORKDIR declaration.

C. The CMD command is missing square brackets for JSON array syntax.

D. The second stage should use a smaller base image like 'node:18-alpine' to reduce size.

Solution

1. Step 1: Review base images used in both stages

   Both stages use 'node:18', which is a full Node image including build tools.

2. Step 2: Suggest optimization for smaller final image

   Using a smaller base like 'node:18-alpine' in the second stage reduces image size by excluding unnecessary tools.

3. Final Answer:

   The second stage should use a smaller base image like 'node:18-alpine' to reduce size. -> Option D

4. Quick Check:

   Use lightweight base images in final stage [OK]

Hint: Use lightweight base images in final stage for smaller images [OK]

Common Mistakes:

• Thinking COPY syntax is incorrect when it is valid
• Believing CMD needs different syntax here
• Assuming WORKDIR is missing in first stage

5. You want to build a Python app with dependencies installed only during build, but keep the final image minimal. Which multi-stage Dockerfile snippet achieves this best?

hard

A. FROM python:3.12 AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

FROM python:3.12-slim
COPY --from=builder /app /app
CMD ["python", "/app/app.py"]

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

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

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

Solution

1. Step 1: Understand requirement for minimal final image

   Dependencies should be installed in a build stage, not in the final image, to keep it small.

2. Step 2: Analyze options for multi-stage usage

   FROM python:3.12 AS builder
   WORKDIR /app
   COPY requirements.txt .
   RUN pip install -r requirements.txt
   COPY . .
   
   FROM python:3.12-slim
   COPY --from=builder /app /app
   CMD ["python", "/app/app.py"]

   uses a builder stage to install dependencies and copies only the app to a slim final image, achieving minimal size.

3. Final Answer:

   Option A correctly uses multi-stage build to keep final image minimal. -> Option A

4. Quick Check:

   Install dependencies in builder, copy to slim final image [OK]

Hint: Install dependencies in builder stage, copy only needed files to slim image [OK]

Common Mistakes:

• Installing dependencies directly in final image increasing size
• Not using multi-stage build at all
• Running app in builder stage instead of final stage