Multi-stage for different environments in Docker - Step-by-Step Execution

Process Flow - Multi-stage for different environments

Start: Base Stage

↓

Build Stage: Compile/Build

↓

Test Stage: Run Tests

↓

Production Stage: Final Image

↓

Select Stage Based on Environment

↓

Dev Image

↓

Prod Image

↓

Test Image

↓

End

The Dockerfile builds multiple stages for dev, test, and prod environments, then selects the final image based on the environment.

Execution Sample

Docker

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

FROM base AS build
COPY . ./
RUN npm run build

FROM base AS test
COPY . ./
RUN npm test

FROM base AS prod
COPY --from=build /app/dist ./dist
CMD ["node", "dist/server.js"]

This Dockerfile creates separate stages for building, testing, and production, reusing the base stage.

Process Table

Step	Stage	Action	Files/State	Result
1	base	Set working directory and copy package.json	/app/package.json	package.json copied
2	base	Run npm install	/app/node_modules	Dependencies installed
3	build	Copy all source files	/app/src + others	Source files copied
4	build	Run npm run build	/app/dist	Build output created
5	test	Copy all source files	/app/src + others	Source files copied
6	test	Run npm test	Test results	Tests passed
7	prod	Copy build output from build stage	/app/dist	Production files ready
8	prod	Set CMD to start server	CMD set	Image ready for production

💡 All stages completed; final image chosen based on environment variable.

Status Tracker

Variable	base	build	test	prod
Working Directory	/app	/app	/app	/app
package.json	copied	inherited	inherited	inherited
node_modules	installed	inherited	inherited	inherited
Source Files	none	copied	copied	none
Build Output (dist)	none	created	none	copied from build
Test Results	none	none	created	none
CMD	none	none	none	set to start server

Key Moments - 3 Insights

Why do we copy source files again in build and test stages if base already has dependencies?

Base stage only installs dependencies; source files must be copied separately in build and test stages to run build and tests. See execution_table rows 3 and 5.

How does the prod stage get the build output without rebuilding?

Prod stage copies the build output from the build stage using 'COPY --from=build'. This avoids rebuilding. See execution_table row 7.

What decides which stage becomes the final image?

The final image is selected by specifying the target stage during docker build (e.g., --target prod). This is why all stages are built but only one is used.

Visual Quiz - 3 Questions

Look at the execution table, at which step are the tests run?

A Step 6

B Step 4

C Step 7

D Step 2

💡 Hint

Check the 'Action' column for 'Run npm test' in the execution_table.

According to variable_tracker, which stage has the 'CMD' set to start the server?

A test

B build

C prod

D base

💡 Hint

Look at the 'CMD' row in variable_tracker for the 'prod' column.

If we skip copying source files in the build stage, what will happen?

A Build output will be created normally

B Build stage will fail or produce empty output

C Tests will pass anyway

D Prod stage will copy source files automatically

💡 Hint

Refer to execution_table rows 3 and 4 where source files are copied before build.

Concept Snapshot

Multi-stage Dockerfiles let you create separate build steps for dev, test, and prod.
Use 'FROM ... AS stage' to name stages.
Copy files and run commands per stage.
Use 'COPY --from=stage' to reuse outputs.
Select final image with 'docker build --target'.
This keeps images small and environment-specific.

Full Transcript

This visual execution shows how a multi-stage Dockerfile builds different environments: base, build, test, and prod. The base stage sets up dependencies. Build and test stages copy source files and run build or tests. The prod stage copies the build output from build and sets the command to start the server. Variables like working directory, files, and commands change per stage. The final image is chosen by specifying the target stage during build. This approach keeps images efficient and environment-specific.

Practice

1. What is the main purpose of using multi-stage builds in Docker for different environments?

easy

A. To automatically update Docker images from the internet

B. To run multiple containers simultaneously

C. To create smaller and cleaner Docker images by separating build and runtime stages

D. To increase the size of the Docker image for better performance

Solution

1. Step 1: Understand multi-stage build concept

   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 benefit for different environments

   This separation results in smaller, cleaner images optimized for the target environment, such as production.

3. Final Answer:

   To create smaller and cleaner Docker images by separating build and runtime stages -> Option C

4. Quick Check:

   Multi-stage builds = smaller images [OK]

Hint: Remember: multi-stage means build then runtime separate [OK]

Common Mistakes:

• Thinking multi-stage runs multiple containers
• Believing it automatically updates images
• Assuming it increases image size

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

easy

A. STAGE node:18 build

B. FROM node:18 AS build

C. BUILD node:18 AS build

D. FROM node:18 WITH build

Solution

1. Step 1: Recall Dockerfile stage naming syntax

   Docker uses the syntax 'FROM <image> AS ' to name a build stage.

2. Step 2: Check each option

   Only FROM node:18 AS build uses the correct 'FROM ... AS ...' syntax; others are invalid Dockerfile commands.

3. Final Answer:

   FROM node:18 AS build -> Option B

4. Quick Check:

   Stage naming = FROM ... AS ... [OK]

Hint: Look for 'FROM ... AS ...' to name stages [OK]

Common Mistakes:

• Using 'STAGE' or 'BUILD' keywords incorrectly
• Forgetting the AS keyword
• Using 'WITH' instead of AS

3. Given this Dockerfile snippet, what will be the size characteristic of the final image?

FROM node:18 AS build
RUN npm install
FROM node:18-slim
COPY --from=build /app/node_modules /app/node_modules

medium

A. The final image will be smaller because it only copies needed files from build stage

B. The final image will be the same size as the build stage

C. The final image will fail to build due to missing files

D. The final image will be large because it includes all build tools

Solution

1. Step 1: Analyze the multi-stage build steps

   The first stage installs dependencies with full Node image; the second stage uses a smaller Node image and copies only node_modules from the build stage.

2. Step 2: Understand image size impact

   Because only necessary files are copied, the final image is smaller than the full build environment image.

3. Final Answer:

   The final image will be smaller because it only copies needed files from build stage -> Option A

4. Quick Check:

   Copying from build stage reduces final image size [OK]

Hint: Copy only needed files from build stage to keep image small [OK]

Common Mistakes:

• Assuming all build tools are included in final image
• Thinking the build will fail due to missing files
• Believing final image equals build stage size

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

FROM python:3.12 AS build
RUN pip install -r requirements.txt
FROM python:3.12-slim
COPY --from=builder /app /app

medium

A. The COPY command syntax is incorrect

B. The requirements.txt file is missing

C. The base images are incompatible

D. The stage name 'builder' does not match the first stage name

Solution

1. Step 1: Check stage names consistency

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

2. Step 2: Verify COPY command correctness

   The COPY syntax is correct, but the source stage name is wrong, causing build failure.

3. Final Answer:

   The stage name 'builder' does not match the first stage name -> Option D

4. Quick Check:

   Stage names must match exactly in COPY --from= [OK]

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

Common Mistakes:

• Using wrong stage name in COPY
• Confusing syntax errors with naming errors
• Assuming base images cause this error

5. You want to build a Docker image that uses a heavy build environment only during build, but produces a minimal runtime image for production. Which multi-stage Dockerfile snippet correctly achieves this?

hard

A. FROM golang:1.20 AS build
WORKDIR /app
RUN go build -o app .
FROM alpine:latest
COPY --from=build /app/app /app/app
CMD ["/app/app"]

B. FROM alpine:latest AS build
RUN apk add go
WORKDIR /app
RUN go build -o app .
FROM golang:1.20
COPY --from=build /app/app /app/app
CMD ["/app/app"]

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

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

Solution

1. Step 1: Identify build and runtime separation

   FROM golang:1.20 AS build WORKDIR /app RUN go build -o app . FROM alpine:latest COPY --from=build /app/app /app/app CMD ["/app/app"] uses golang image for building, then copies only the built app to a minimal alpine image for runtime.

2. Step 2: Check other options for correctness

   FROM alpine:latest AS build RUN apk add go WORKDIR /app RUN go build -o app . FROM golang:1.20 COPY --from=build /app/app /app/app CMD ["/app/app"] builds in alpine but runs in golang image, which is opposite of desired minimal runtime. Options C and D do not separate build and runtime stages.

3. Final Answer:

   Option A correctly uses multi-stage build for minimal runtime image -> Option A

4. Quick Check:

   Build heavy, run minimal = FROM golang:1.20 AS build WORKDIR /app RUN go build -o app . FROM alpine:latest COPY --from=build /app/app /app/app CMD ["/app/app"] [OK]

Hint: Build in heavy image, copy to minimal runtime image [OK]

Common Mistakes:

• Building in minimal image causing slow builds
• Running heavy image in production
• Not separating build and runtime stages