📖 Scenario: You are creating a Docker image for a simple web application. To keep the image size small and organized, you will use named build stages.
🎯 Goal: Build a multi-stage Dockerfile using named build stages to separate the build environment from the final runtime environment.
📋 What You'll Learn
Create a Dockerfile with two named build stages: builder and final
In the builder stage, use the node:18 image and create a file /app/build.txt with the text Build complete
In the final stage, use the alpine:latest image and copy the /app/build.txt file from the builder stage
Print the contents of /app/build.txt when running the container
💡 Why This Matters
🌍 Real World
Using named build stages helps create smaller, cleaner Docker images by separating build tools from runtime environments.
💼 Career
Many DevOps and software engineering roles require writing efficient Dockerfiles with multi-stage builds to optimize deployment pipelines.
Progress0 / 4 steps
1
Create the builder stage
Create a Dockerfile with a named build stage called builder that uses the node:18 image. Inside this stage, create a directory /app and add a file /app/build.txt containing the text Build complete using a single RUN command.
Docker
Hint
Use FROM node:18 AS builder to name the build stage. Use RUN mkdir /app && echo "Build complete" > /app/build.txt to create the file.
2
Add the final stage
Add a second named build stage called final that uses the alpine:latest image. In this stage, copy the file /app/build.txt from the builder stage to the same path /app/build.txt.
Docker
Hint
Use FROM alpine:latest AS final to start the final stage. Use COPY --from=builder /app/build.txt /app/build.txt to copy the file.
3
Add a command to display the file
In the final stage, add a command to run when the container starts that prints the contents of /app/build.txt using cat.
Docker
Hint
Use CMD ["cat", "/app/build.txt"] to print the file when the container runs.
4
Build and run the Docker image
Build the Docker image with the tag buildstage-demo and run a container from it. The output should be the text Build complete.
Docker
Hint
Use docker build -t buildstage-demo . to build and docker run --rm buildstage-demo to run the container.
Practice
(1/5)
1. What is the main purpose of using named build stages in a Dockerfile?
easy
A. To automatically update Docker images
B. To split the build process into parts and reuse files between them
C. To create multiple Dockerfiles in one file
D. To run multiple containers at the same time
Solution
Step 1: Understand what named build stages do
Named build stages let you divide your Docker build into parts with names, making it easier to manage.
Step 2: Recognize the benefit of reusing files
You can copy files from one named stage to another, which helps keep images smaller and cleaner.
Final Answer:
To split the build process into parts and reuse files between them -> Option B
Quick Check:
Named build stages = split and reuse [OK]
Hint: Named stages let you copy files between build steps [OK]
Common Mistakes:
Confusing named stages with running multiple containers
Thinking named stages create multiple Dockerfiles
Believing named stages update images automatically
2. Which of the following is the correct syntax to name a build stage in a Dockerfile?
easy
A. STAGE node:18 builder
B. BUILD node:18 AS builder
C. FROM node:18 AS builder
D. FROM node:18 WITH builder
Solution
Step 1: Recall Dockerfile syntax for naming stages
The correct syntax uses the FROM instruction followed by the image and AS plus the stage name.
Step 2: Check each option
Only FROM node:18 AS builder uses FROM node:18 AS builder, which is correct syntax.
Final Answer:
FROM node:18 AS builder -> Option C
Quick Check:
Named stage syntax = FROM ... AS ... [OK]
Hint: Use FROM image AS name to name stages [OK]
Common Mistakes:
Using BUILD or STAGE instead of FROM
Omitting the AS keyword
Using WITH instead of AS
3. Given this Dockerfile snippet, what will be the final image size compared to a single-stage build?
FROM node:18 AS builder
RUN npm install
FROM node:18
COPY --from=builder /app/node_modules /app/node_modules
medium
A. Smaller, because only needed files are copied from builder
B. Larger, because it includes both stages fully
C. Same size, because both stages use the same base image
D. Build will fail due to syntax error
Solution
Step 1: Understand multi-stage build effect on image size
Multi-stage builds copy only required files from earlier stages, reducing final image size.
Step 2: Analyze the COPY --from usage
The final stage copies only /app/node_modules from the builder, not the whole builder image.
Final Answer:
Smaller, because only needed files are copied from builder -> Option A
Quick Check:
Multi-stage copy reduces image size [OK]
Hint: Copy only needed files from builder stage to reduce size [OK]
Common Mistakes:
Assuming both stages are fully included in final image
Thinking same base image means same size
Confusing syntax causing build failure
4. Identify the error in this Dockerfile snippet using named build stages:
FROM python:3.12 AS build
RUN pip install -r requirements.txt
FROM python:3.12
COPY --from=builder /app /app
medium
A. The stage name 'build' is misspelled as 'builder' in COPY
B. Missing RUN command in second stage
C. Cannot use COPY between stages
D. FROM instruction must be last in Dockerfile
Solution
Step 1: Check stage names consistency
The first stage is named build, but COPY uses --from=builder, which is incorrect.
Step 2: Understand COPY --from usage
The --from must match the exact stage name to copy files correctly.
Final Answer:
The stage name 'build' is misspelled as 'builder' in COPY -> Option A
Quick Check:
Stage name mismatch causes COPY error [OK]
Hint: Match stage names exactly in COPY --from [OK]
Common Mistakes:
Assuming COPY can't copy between stages
Ignoring stage name spelling
Thinking RUN is required in second stage
5. You want to build a Docker image that compiles a Go app in one stage and produces a small final image with only the binary. Which Dockerfile snippet correctly uses named build stages to achieve this?
hard
A.
FROM alpine:latest
RUN apk add go
WORKDIR /app
COPY . .
RUN go build -o myapp
CMD ["myapp"]
B.
FROM alpine:latest AS builder
RUN apk add go
WORKDIR /app
COPY . .
RUN go build -o myapp
FROM golang:1.20
COPY --from=builder /app/myapp /usr/local/bin/myapp
CMD ["myapp"]
C.
FROM golang:1.20
WORKDIR /app
COPY . .
RUN go build -o myapp
CMD ["myapp"]
D.
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"]
Solution
Step 1: Identify multi-stage build for compiling and 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"]
uses a builder stage with golang image to compile, then copies only the binary to a small alpine image.
Step 2: Check other options for correctness
FROM alpine:latest AS builder
RUN apk add go
WORKDIR /app
COPY . .
RUN go build -o myapp
FROM golang:1.20
COPY --from=builder /app/myapp /usr/local/bin/myapp
CMD ["myapp"]
installs Go in alpine, which is less efficient. Single-stage builds do not use multi-stage builds, so final image is large.
Final Answer:
Uses golang:1.20 AS builder to compile and alpine:latest for the final binary-only image -> Option D
Quick Check:
Multi-stage build with builder and final stage =
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"]
[OK]
Hint: Use builder stage to compile, final stage to copy binary only [OK]
Common Mistakes:
Installing build tools in final image
Not using multi-stage build
Copying entire source instead of just binary
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.