Builder pattern before multi-stage in Docker - Step-by-Step Execution

Process Flow - Builder pattern with multi-stage

Start: Write Dockerfile

↓

Build full image with builder tools

↓

Run build commands inside image

↓

Copy build artifacts from builder

↓

Create smaller runtime image

↓

Copy artifacts into runtime image

↓

Final image ready for deployment

This flow shows the builder pattern with multi-stage builds: build everything in the builder stage, then copy artifacts to a smaller runtime image.

Execution Sample

Docker

FROM node:14 as builder
WORKDIR /app
COPY package.json ./
RUN npm install
COPY . ./
RUN npm run build

FROM node:14-slim
WORKDIR /app
COPY --from=builder /app/build ./build
CMD ["node", "build/index.js"]

This Dockerfile builds the app in a full node image, then copies only the build output to a smaller runtime image.

Process Table

Step	Action	Image State	Result
1	Start with 'node:14' as builder	Builder image created	Ready to install dependencies
2	Copy package.json	package.json in /app	Files ready for npm install
3	Run npm install	node_modules installed	Dependencies ready
4	Copy source code	Source code in /app	Ready to build
5	Run npm run build	Build output in /app/build	Build artifacts created
6	Start new image 'node:14-slim'	Clean runtime image	Smaller base image
7	Copy build artifacts from builder	Build files in runtime image	Only needed files copied
8	Set CMD to run app	Runtime image ready	Image ready to run app
9	Build complete	Final image created	Ready for deployment

💡 All build steps done; final image contains only runtime files, no build tools

Status Tracker

Variable	Start	After Step 3	After Step 5	After Step 7	Final
/app contents	empty	package.json + node_modules	package.json + node_modules + source + build output	build output only	build output only
Image size	base size	larger (with node_modules)	even larger (with build tools)	smaller (runtime only)	smaller (runtime only)

Key Moments - 3 Insights

Why do we need two FROM lines in the Dockerfile?

Because the first FROM creates the builder image with all tools to build the app, and the second FROM creates a smaller runtime image. This is shown in execution_table steps 1 and 6.

How do build artifacts get from the builder image to the runtime image?

They are copied using COPY --from=builder, as shown in step 7 of the execution_table.

Why is the final image smaller than the builder image?

Because it only contains the build output and runtime dependencies, not the full build tools or source code, as shown by the variable_tracker for image size after step 7.

Visual Quiz - 3 Questions

Look at the execution_table at step 5. What is present in the builder image?

A Source code, node_modules, and build output

B Only build output

C Only source code and build output

D Empty /app directory

💡 Hint

Check the 'Image State' column at step 5 in execution_table

At which step does the runtime image get the build artifacts copied in?

A Step 4

B Step 6

C Step 7

D Step 8

💡 Hint

Look for the COPY --from=builder action in execution_table

If we skipped step 3 (npm install), what would happen to the build output?

A Build output would be created normally

B Build would fail due to missing dependencies

C Build output would be empty but image size same

D Runtime image would be larger

💡 Hint

Step 3 installs dependencies needed for build, check execution_table step 3

Concept Snapshot

Builder pattern with multi-stage uses multiple FROM lines.
First stage builds app with all tools.
Second stage is smaller runtime.
Build artifacts copied using --from.
Final image is smaller and cleaner.

Full Transcript

This visual execution shows how the builder pattern works with multi-stage Docker builds using multiple FROM lines. First, a full image with build tools is created. Then the app is built inside it. After that, a smaller runtime image is created. Build artifacts are copied from the builder image to the runtime image. This reduces final image size by excluding build tools. The execution table traces each step from starting the builder image, installing dependencies, building the app, to copying artifacts and setting the runtime command. The variable tracker shows how the /app directory contents and image size change after key steps. Key moments clarify why two FROM lines are needed, how copying works, and why the final image is smaller. The quiz tests understanding of image contents at each step and consequences of skipping steps. This pattern leverages Docker multi-stage builds for efficient images.

Practice

1. What is the main purpose of the builder pattern in Docker before multi-stage builds were introduced?

easy

A. To run multiple containers simultaneously

B. To separate the build environment from the final runtime environment

C. To automatically update Docker images

D. To manage Docker volumes efficiently

Solution

1. Step 1: Understand the builder pattern concept

   The builder pattern splits the process into two parts: building the app and running it.

2. Step 2: Identify the benefit of separation

   This separation keeps the final image small by excluding build tools and files.

3. Final Answer:

   To separate the build environment from the final runtime environment -> Option B

4. Quick Check:

   Builder pattern = separate build and run [OK]

Hint: Builder pattern means build and run are separate stages [OK]

Common Mistakes:

• Confusing builder pattern with running multiple containers
• Thinking it manages volumes or updates automatically
• Assuming it is about Docker networking

2. Which Dockerfile snippet correctly implements the builder pattern before multi-stage builds?

easy

A. FROM node:14
WORKDIR /app
COPY . .
RUN npm install && npm run build
CMD ["npm", "start"]

B. FROM node:14 AS builder
WORKDIR /app
COPY . .
RUN npm install && npm run build
FROM nginx:alpine
COPY --from=builder /app/build /usr/share/nginx/html

C. FROM node:14
RUN npm install
COPY . .
CMD ["npm", "start"]

D. FROM nginx:alpine
COPY . /usr/share/nginx/html
RUN npm install

Solution

1. Step 1: Identify builder pattern before multi-stage

   Before multi-stage, builder pattern used separate Dockerfiles or manual copying, not the --from syntax.

2. Step 2: Check each option

   FROM node:14 AS builder WORKDIR /app COPY . . RUN npm install && npm run build FROM nginx:alpine COPY --from=builder /app/build /usr/share/nginx/html uses multi-stage syntax (--from=builder), which was not available before multi-stage builds.

3. Final Answer:

   FROM node:14 WORKDIR /app COPY . . RUN npm install && npm run build CMD ["npm", "start"] -> Option A

4. Quick Check:

   Before multi-stage, no --from usage [OK]

Hint: Before multi-stage, no --from in COPY command [OK]

Common Mistakes:

• Choosing multi-stage syntax before it existed
• Confusing build and runtime commands
• Ignoring the CMD instruction

3. Given this Dockerfile before multi-stage builds:

FROM node:14
WORKDIR /app
COPY . .
RUN npm install && npm run build
CMD ["node", "server.js"]

What is the likely size impact on the final image?

medium

A. The image will be large because build tools and source files remain

B. The image will be small because only build output is copied

C. The image size is minimal due to automatic cleanup

D. The image size depends only on the base image

Solution

1. Step 1: Analyze the Dockerfile steps

   The Dockerfile copies all source files and runs build inside the same image.

2. Step 2: Understand image size impact

   Since build tools and source files remain, the image size is larger than needed.

3. Final Answer:

   The image will be large because build tools and source files remain -> Option A

4. Quick Check:

   Single-stage build keeps all files, so image is large [OK]

Hint: Single-stage build keeps all files, making image large [OK]

Common Mistakes:

• Assuming build output only is copied
• Thinking Docker cleans up build files automatically
• Ignoring the COPY . . step

4. You have two Dockerfiles: one for building and one for running. You want to copy build artifacts from the builder image to the runtime build context manually. Which command correctly copies files from a stopped builder container named 'builder' to the runtime build context?

medium

A. docker cp ./build builder:/app/build

B. docker copy builder:/app/build ./build

C. docker cp builder:/app/build ./build

D. docker copy ./build builder:/app/build

Solution

1. Step 1: Understand docker cp syntax

   The correct syntax is 'docker cp <container>:<source_path> <destination_path>'.

2. Step 2: Match command to copy from container to local

   docker cp builder:/app/build ./build correctly copies from container 'builder' path to local './build'.

3. Final Answer:

   docker cp builder:/app/build ./build -> Option C

4. Quick Check:

   docker cp container:path local_path [OK]

Hint: Use 'docker cp container:path local_path' to copy files out [OK]

Common Mistakes:

• Using 'docker copy' instead of 'docker cp'
• Reversing source and destination paths
• Trying to copy from local to container incorrectly

5. You want to manually implement the builder pattern before multi-stage builds by using two Dockerfiles: Dockerfile.build and Dockerfile.run. Which sequence of commands correctly builds and prepares the final image with only the build output copied?

hard

A. docker build -f Dockerfile.build -t app-builder . && docker run --name builder app-builder && docker cp builder:/app/dist ./dist && docker rm builder && docker build -f Dockerfile.run -t app-runtime .

B. docker build -f Dockerfile.run -t app-runtime . && docker build -f Dockerfile.build -t app-builder .

C. docker build -f Dockerfile.run -t app-runtime . && docker run --name builder app-builder && docker cp builder:/app/dist ./dist

D. docker build -f Dockerfile.build -t app-builder . && docker create --name builder app-builder && docker cp builder:/app/dist ./dist && docker rm builder && docker build -f Dockerfile.run -t app-runtime .

Solution

1. Step 1: Build the builder image and create a container

   Use 'docker build' with Dockerfile.build, then 'docker create' to make a stopped container for copying files.

2. Step 2: Copy build output and build runtime image

   Copy files from the builder container, remove it, then build the runtime image with Dockerfile.run.

3. Final Answer:

   docker build -f Dockerfile.build -t app-builder . && docker create --name builder app-builder && docker cp builder:/app/dist ./dist && docker rm builder && docker build -f Dockerfile.run -t app-runtime . -> Option D

4. Quick Check:

   Build, create, copy, remove, then build runtime [OK]

Hint: Create container to copy files, then build runtime image [OK]

Common Mistakes:

• Using 'docker run' instead of 'docker create' for copying
• Building runtime image before copying build output
• Not removing temporary builder container