Multi-stage builds in Microservices - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the base image for the build stage.

Microservices

FROM [1] AS builder

Drag options to blanks, or click blank then click option'

Apython:3.9-slim

Bnode:18-alpine

Cubuntu:latest

Dalpine:edge

Attempts:

3 left

💡 Hint

Common Mistakes

Using a generic OS image like ubuntu without necessary build tools.

Choosing an image that does not match the application language.

The node:18-alpine image is a lightweight base suitable for building Node.js applications in the builder stage.

2fill in blank

medium

Complete the code to copy source files into the builder stage.

Microservices

COPY [1] /app

Drag options to blanks, or click blank then click option'

A.

B/src

C/app

D./build

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect source paths that do not exist in the build context.

Copying only partial files causing build failures.

The dot . means copying all files from the current directory into the /app directory inside the container.

3fill in blank

hard

Fix the error in the final stage to copy only the built files from the builder stage.

Microservices

COPY --from=[1] /app/dist /app

Drag options to blanks, or click blank then click option'

Abuilder

Bfinal

Cbuild

Dsource

Attempts:

3 left

💡 Hint

Common Mistakes

Using a stage name that does not exist causing build errors.

Copying from the wrong stage resulting in missing files.

The --from=builder flag copies files from the stage named builder, which contains the built application.

4fill in blank

hard

Fill both blanks to define the final image and set the working directory.

Microservices

FROM [1]
WORKDIR [2]

Drag options to blanks, or click blank then click option'

Anode:18-alpine

B/app

C/usr/src/app

Dubuntu:20.04

Attempts:

3 left

💡 Hint

Common Mistakes

Using a heavy base image increasing final image size.

Not setting the working directory causing command failures.

The final image uses node:18-alpine for a lightweight runtime, and the working directory is set to /usr/src/app where the app files are copied.

5fill in blank

hard

Fill all three blanks to complete the multi-stage Dockerfile snippet for building and running a microservice.

Microservices

FROM [1] AS builder
COPY [2] /src
RUN npm install && npm run build
FROM [3]
COPY --from=builder /src/dist /app
CMD ["node", "/app/index.js"]

Drag options to blanks, or click blank then click option'

Anode:18-alpine

B.

Cnode:18-slim

D/src

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up source paths causing copy errors.

Using the same image for both stages increasing image size.

The builder stage uses node:18-alpine for building. The source files are copied from the current directory .. The final stage uses node:18-slim for a smaller runtime image.

Practice

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

easy

A. They reduce the final image size by separating build and runtime stages.

B. They allow running multiple containers simultaneously.

C. They automatically scale microservices based on load.

D. They enable containers to communicate over a network.

Solution

1. Step 1: Understand multi-stage build purpose

   Multi-stage builds separate the build environment from the runtime environment to avoid including unnecessary build tools in the final image.

2. Step 2: Identify the main benefit

   This separation reduces the final image size, making containers smaller and faster to deploy.

3. Final Answer:

   They reduce the final image size by separating build and runtime stages. -> Option A

4. Quick Check:

   Multi-stage builds = smaller images [OK]

Hint: Focus on build vs runtime separation for smaller images [OK]

Common Mistakes:

• Confusing multi-stage builds with container orchestration
• Thinking multi-stage builds scale services automatically
• Assuming multi-stage builds enable container networking

2. Which of the following is the correct syntax to name a build stage in a Dockerfile for multi-stage builds?

easy

A. FROM node:18 WITH builder

B. STAGE node:18 builder

C. BUILD node:18 AS builder

D. FROM node:18 AS builder

Solution

1. Step 1: Recall Dockerfile syntax for naming stages

   In Dockerfiles, the AS keyword is used after FROM to name a build stage.

2. Step 2: Match correct syntax

   Only FROM node:18 AS builder correctly names the stage 'builder'.

3. Final Answer:

   FROM node:18 AS builder -> Option D

4. Quick Check:

   Stage naming uses 'AS' keyword [OK]

Hint: Look for 'FROM ... AS stageName' syntax [OK]

Common Mistakes:

• Using incorrect keywords like BUILD or STAGE
• Omitting the AS keyword
• Placing stage name before FROM

3. Given the following Dockerfile snippet, what will be the size impact 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 be large because it includes the full Go environment.

B. The final image will be small because only the built binary is copied.

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

D. The final image will contain both Go and Alpine layers.

Solution

1. Step 1: Analyze the build stage

   The first stage uses the full Go environment to build the binary 'myapp'.

2. Step 2: Analyze the final stage

   The final stage uses a minimal Alpine image and copies only the built binary from the builder stage.

3. Step 3: Determine final image size impact

   Since only the binary is copied, the final image is small and does not include the Go environment.

4. Final Answer:

   The final image will be small because only the built binary is copied. -> Option B

5. Quick Check:

   Copying only binary = small image [OK]

Hint: Final image size depends on copied artifacts, not build tools [OK]

Common Mistakes:

• Assuming build tools stay in final image
• Thinking COPY copies entire build context
• Confusing build and runtime stages

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

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

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

medium

A. The stage name 'builder' used in COPY is incorrect; it should be 'build'.

B. The second FROM should use a lighter image like alpine.

C. The CMD syntax is invalid and will cause runtime error.

D. COPY command should copy from current stage, not from another.

Solution

1. Step 1: Check stage naming consistency

   The first stage is named 'build' but the COPY uses '--from=builder', which does not exist.

2. Step 2: Identify the error impact

   This mismatch causes a build failure because Docker cannot find the 'builder' stage.

3. Final Answer:

   The stage name 'builder' used in COPY is incorrect; it should be 'build'. -> Option A

4. Quick Check:

   Stage names must match exactly [OK]

Hint: Match stage names exactly in COPY --from [OK]

Common Mistakes:

• Using wrong stage names in COPY
• Ignoring case sensitivity in stage names
• Assuming COPY defaults to previous stage

5. You want to optimize a microservice Docker image using multi-stage builds. The build stage requires many tools, but the runtime only needs the compiled binary and config files. Which approach best achieves a minimal, secure final image?

hard

A. Use a single-stage build with all tools and source code included.

B. Install all build tools in the final image to allow debugging in production.

C. Use a multi-stage build: build with full tools, then copy only binary and config to a minimal base image.

D. Build the binary outside Docker and copy it directly into the final image.

Solution

1. Step 1: Understand build vs runtime needs

   The build stage needs many tools, but runtime only needs the binary and configs for security and size.

2. Step 2: Choose best multi-stage build approach

   Using multi-stage builds to copy only necessary artifacts into a minimal base image reduces size and attack surface.

3. Step 3: Evaluate other options

   Installing all tools in final image increases size and risk; single-stage builds are inefficient; building outside Docker loses reproducibility.

4. Final Answer:

   Use a multi-stage build: build with full tools, then copy only binary and config to a minimal base image. -> Option C

5. Quick Check:

   Multi-stage builds optimize size and security [OK]

Hint: Copy only needed files to minimal image for best results [OK]

Common Mistakes:

• Including build tools in final image
• Skipping multi-stage builds for simplicity
• Building outside Docker losing environment consistency