Docker multi-stage builds are a game-changer for reducing container image sizes and improving security. By using multiple
Why Use Multi-Stage Builds?
In traditional Docker workflows, developers often struggle with bloated images containing compilers, source code, and unnecessary build dependencies. This not only wastes storage and bandwidth but also increases the attack surface of your application.
Multi-stage builds solve this by allowing you to copy only the finalized artifacts from the build stage into the final image.
Practical Example: Go Application
Here is a standard Dockerfile implementing a multi-stage build for a Go application:
Key Takeaways
1. Named Stages: Using
2. Selective Copying: The
3. Smaller Footprint: The final image size drops dramatically, often from hundreds of megabytes down to just a few megabytes, depending on the base image (like using
FROM instructions in a single Dockerfile, you can use a heavy SDK image to build your application and a minimal runtime image for the final production container.Why Use Multi-Stage Builds?
In traditional Docker workflows, developers often struggle with bloated images containing compilers, source code, and unnecessary build dependencies. This not only wastes storage and bandwidth but also increases the attack surface of your application.
Multi-stage builds solve this by allowing you to copy only the finalized artifacts from the build stage into the final image.
Practical Example: Go Application
Here is a standard Dockerfile implementing a multi-stage build for a Go application:
Code:
# Stage 1: Build the binary
FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o myapp .
# Stage 2: Create the production image
FROM alpine:3.19
WORKDIR /root/
# Copy only the compiled binary from the builder stage
COPY --from=builder /app/myapp .
EXPOSE 8080
CMD ["./myapp"]Key Takeaways
1. Named Stages: Using
AS builder allows you to reference specific stages later in the Dockerfile.2. Selective Copying: The
--from=builder flag is the magic that extracts just what you need, leaving behind the Go toolchain, cache, and source code.3. Smaller Footprint: The final image size drops dramatically, often from hundreds of megabytes down to just a few megabytes, depending on the base image (like using
scratch or alpine).