Named build stages in Docker - Step-by-Step Execution

Process Flow - Named build stages

Start Dockerfile

↓

Define Stage 1: base

↓

Build base image

↓

Define Stage 2: final

↓

Use base stage as FROM

↓

Build final image

↓

Finish Build

Dockerfile defines multiple named stages; later stages can use earlier stages by name to copy artifacts, enabling efficient multi-step builds.

Execution Sample

Docker

FROM python:3.12 AS base
RUN pip install flask

FROM base AS final
COPY . /app
CMD ["python", "/app/app.py"]

This Dockerfile builds a base image with Python and Flask, then a final image that copies app files and runs the app.

Process Table

Step	Stage	Instruction	Action	Result
1	base	FROM python:3.12 AS base	Start base stage from python:3.12	Base stage initialized
2	base	RUN pip install flask	Install Flask in base image	Flask installed in base stage
3	final	FROM base AS final	Start final stage using base stage	Final stage initialized with base as base
4	final	COPY . /app	Copy current directory to /app in final image	App files copied to /app
5	final	CMD ["python", "/app/app.py"]	Set command to run app.py	Final image ready with command set
6	-	-	-	Build finished successfully

💡 All stages built; final image ready using named stages for efficient layering

Status Tracker

Variable	Start	After Step 2	After Step 5	Final
base image	none	python:3.12 + Flask installed	same	ready
final image	none	none	base image + app files copied + CMD set	ready

Key Moments - 3 Insights

Why do we name a build stage with AS base or AS final?

Naming stages allows us to refer to them later in the Dockerfile, like in step 3 where 'final' uses 'base' as its starting point, enabling reuse and smaller images.

What happens if we don't name the first stage but try to use it later?

Without a name, you cannot refer to that stage later. The build would fail at step 3 because 'base' would be undefined.

Does the final image include all layers from the base stage?

Yes, the final stage starts FROM the base stage, so it includes all its layers plus any new instructions like copying files.

Visual Quiz - 3 Questions

Look at the execution table at step 3. What does 'FROM base AS final' do?

A Copies files from base to final automatically

B Starts a new stage named final using the base stage as its starting point

C Runs the base stage commands again inside final

D Ends the build process

💡 Hint

Check the 'Action' and 'Result' columns at step 3 in the execution table

At which step are the app files copied into the final image?

A Step 5

B Step 2

C Step 4

D Step 1

💡 Hint

Look for the COPY instruction in the execution table

If we remove 'AS base' from step 1, what will happen at step 3?

A Build will fail because 'base' stage is not defined

B Build will succeed but final stage will be empty

C Build will ignore step 3 and continue

D Build will use python:3.12 again automatically

💡 Hint

Refer to the key moment about naming stages and step 3 in the execution table

Concept Snapshot

Named build stages in Dockerfile:
- Use 'FROM image AS name' to name a stage
- Later stages can use 'FROM name' to start from that stage
- Enables multi-step builds and smaller images
- Copy artifacts between stages easily
- Final image is the last stage built

Full Transcript

This visual execution shows how Dockerfile named build stages work. First, a base stage is created from python:3.12 and Flask is installed. This stage is named 'base'. Next, a final stage starts from 'base' and copies application files into it, then sets the command to run the app. Naming stages allows reuse and efficient builds. The execution table traces each step, showing how stages build up. Variables track the state of base and final images. Key moments clarify why naming is important and what happens if omitted. The quiz tests understanding of stage naming, copying files, and build errors. The snapshot summarizes the key points for quick reference.

Practice

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

1. 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.

2. 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.

3. Final Answer:

   To split the build process into parts and reuse files between them -> Option B

4. 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

1. 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.

2. Step 2: Check each option

   Only FROM node:18 AS builder uses FROM node:18 AS builder, which is correct syntax.

3. Final Answer:

   FROM node:18 AS builder -> Option C

4. 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

1. Step 1: Understand multi-stage build effect on image size

   Multi-stage builds copy only required files from earlier stages, reducing final image size.

2. Step 2: Analyze the COPY --from usage

   The final stage copies only /app/node_modules from the builder, not the whole builder image.

3. Final Answer:

   Smaller, because only needed files are copied from builder -> Option A

4. 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

1. Step 1: Check stage names consistency

   The first stage is named build, but COPY uses --from=builder, which is incorrect.

2. Step 2: Understand COPY --from usage

   The --from must match the exact stage name to copy files correctly.

3. Final Answer:

   The stage name 'build' is misspelled as 'builder' in COPY -> Option A

4. 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

1. 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.

2. 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.

3. Final Answer:

   Uses golang:1.20 AS builder to compile and alpine:latest for the final binary-only image -> Option D

4. 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