What if you could build your app in one place but run it in a completely different, lightweight environment?
Why Multiple FROM statements in Docker? - Purpose & Use Cases
Imagine you want to build a software image that needs two different environments: one to compile your code and another to run it. You try to install everything in one big image manually.
This manual way makes your image huge, slow to build, and hard to maintain. You waste time downloading unnecessary tools and risk mixing incompatible software.
Using multiple FROM statements lets you create separate stages in your Dockerfile. You build your code in one stage, then copy only the needed parts to a smaller final image. This keeps things clean and efficient.
FROM ubuntu:20.04
RUN apt-get update && apt-get install -y build-essential python3
COPY . /app
RUN make /appFROM build-image AS builder
COPY . /app
RUN make /app
FROM runtime-image
COPY --from=builder /app/bin /app/binYou can create smaller, faster, and more secure images by separating build and runtime environments cleanly.
A developer compiles a complex app with many tools, then ships only the final executable in a tiny image for production, saving bandwidth and startup time.
Manual single-stage images become large and slow.
Multiple FROM statements create build stages for efficiency.
Final images contain only what is needed to run the app.
Practice
FROM statements in a Dockerfile?Solution
Step 1: Understand the role of
TheFROMin DockerfileFROMstatement sets the base image for building a Docker image.Step 2: Recognize multi-stage build benefits
Using multipleFROMstatements allows building in stages, copying only needed files to the final image, reducing size.Final Answer:
To create multi-stage builds that reduce final image size -> Option AQuick Check:
Multiple FROM = multi-stage build [OK]
- Thinking multiple FROM runs multiple containers
- Confusing FROM with environment variable setting
- Assuming FROM defines runtime commands
builder?Solution
Step 1: Recall the correct COPY syntax for multi-stage
The correct flag to copy from another stage is--from=stage_name.Step 2: Match the option with correct syntax
Only COPY --from=builder /app/build /app uses--from=builder, which is valid syntax.Final Answer:
COPY --from=builder /app/build /app -> Option BQuick Check:
Copy from stage uses --from [OK]
- Using --stage or --source instead of --from
- Misspelling the flag name
- Omitting the equals sign (=) after --from
FROM node:18 AS builder RUN npm install && npm run build FROM nginx:alpine COPY --from=builder /app/build /usr/share/nginx/html
Solution
Step 1: Analyze the multi-stage build steps
The first stage builds the app with Node.js. The second stage uses nginx base image.Step 2: Understand the COPY --from usage
The built files from the builder stage are copied into nginx image, but Node.js layers are not included.Final Answer:
Final image only contains nginx and the built files, keeping it small -> Option CQuick Check:
Multi-stage copy keeps final image small [OK]
- Assuming all build layers stay in final image
- Thinking COPY --from copies the entire image
- Confusing build failure with missing files
FROM python:3.12 AS builder RUN pip install -r requirements.txt FROM alpine COPY --from=build /app /app
Solution
Step 1: Check stage names in FROM statements
The first stage is named 'builder', but COPY uses 'build' which is undefined.Step 2: Understand COPY --from requires exact stage name
Stage names must match exactly; otherwise, Docker throws an error.Final Answer:
The stage name 'build' does not match the defined stage 'builder' -> Option AQuick Check:
Stage names must match exactly in COPY --from [OK]
- Assuming similar names are accepted
- Thinking base image order matters here
- Ignoring COPY destination path correctness
Solution
Step 1: Identify the build stage with Go compiler
Stage named 'builder' uses golang image to compile the app.Step 2: Use a minimal runtime image for final stage
The final stage uses alpine (small image) and copies only the binary from builder.Step 3: Verify COPY --from syntax and CMD
COPY uses --from=builder to get binary; CMD runs the binary correctly.Final Answer:
FROM golang:1.20 AS builder WORKDIR /app COPY . . RUN go build -o myapp FROM alpine COPY --from=builder /app/myapp /myapp CMD ["/myapp"] -> Option DQuick Check:
Multi-stage build with builder and minimal final image [OK]
- Using scratch without proper setup
- Copying files without --from flag
- Building in final stage instead of builder
Ready to prove it?
Pass the test and this pattern moves unknown
