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.