Phase 2: Containers & Orchestration

Dockerfiles & Multi-Stage Builds

Intermediate ~2 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you're making a fantastic science project for school. You've got a detailed instruction sheet, like a super recipe, that tells you exactly how to build it, step by step. To make your project, you gather all your important supplies: maybe glitter, glue, scissors, paintbrushes, special wiring tools, and even a big textbook for research. You use all these things to construct your amazing model volcano or robot. But once your project is perfectly finished and ready to show, do you pack all those tools and the textbook inside the display box with the finished volcano? That would be silly! The box would be huge, heavy, and full of stuff no one needs to see once the project is done.

In the computer world, when we build programs, sometimes we face the same problem. To make a program, you often need lots of special "building tools" – like powerful compilers that turn your ideas into computer language, or testing kits to make sure everything works perfectly. These tools are super important for the making part, just like your glitter and wiring tools. But if we pack all those building tools directly inside the final computer program, it becomes huge and clumsy, taking up too much space and slowing things down.

This is where a clever trick called "multi-stage builds" comes in, just like being smart about packing your science project. It's like saying, "Okay, first, let's use all our building tools in a special 'workshop' to construct the actual computer program. We'll get it just right, testing it and making sure it's perfect." Once the program is completely finished – maybe it's a little game or a calculator – we then carefully pick up only that finished program.

Then, we put that finished program into a brand new, clean box that contains just the program itself, and nothing else. No leftover compilers, no giant testing kits, no research textbooks. Just the neat, ready-to-use program. This final box is much, much smaller, lighter, and easier for computers to handle. So, when computer programs are built this way, it means the final program package is super neat and tidy. It only contains what's absolutely necessary, making it much smaller, faster to share with others, and even safer because all the messy building tools are left behind. This means your programs take up less space, load quicker, and have fewer extra things that could cause problems.

Dockerfiles are the foundational "recipe" for building Docker images. They contain a series of instructions like FROM, RUN, COPY, and CMD, each executed sequentially to construct your image layer by layer. While straightforward for simple applications, building complex software often requires a substantial toolchain – compilers, SDKs, development libraries, and testing frameworks. Including all these build-time dependencies directly in your final production image leads to significant bloat: larger images that take longer to pull, consume more storage, and present a wider attack surface due to the presence of unnecessary tools. This inefficiency is a critical concern for any DevOps Engineer aiming for lean and secure deployments.

This is where multi-stage builds become indispensable. A multi-stage build leverages multiple FROM instructions within a single Dockerfile, each initiating a new, independent build stage. The genius lies in using an early "builder" stage to compile or process your application, generating only the essential artifacts (like a compiled binary, static website files, or a JAR file). Subsequently, a final, much smaller "runtime" stage starts from a minimal base image (e.g., alpine or even scratch) and only copies those necessary artifacts from the previous builder stage using COPY --from=<stage_name>.

By discarding all the build-time tools and intermediate files that aren't needed at runtime, multi-stage builds dramatically reduce the final image size. This results in faster image pulls, less disk space usage, and a significantly smaller attack surface, making your deployed applications more secure and efficient. For a DevOps Engineer, mastering multi-stage builds is fundamental for creating optimized, production-ready container images across various languages and frameworks, ensuring your infrastructure remains lightweight and performant.

Key Takeaways

  • Dockerfiles define how Docker images are built, instruction by instruction.
  • Multi-stage builds use multiple FROM statements to create distinct build and runtime environments within a single Dockerfile.
  • They significantly reduce final image size by separating build dependencies from the runtime artifacts.
  • This technique enhances security by removing unnecessary tools and components from the production image.
  • Use FROM ... AS <stage_name> to define stages and COPY --from=<stage_name> to transfer artifacts.

Code Example

dockerfile
# Stage 1: Build the Go application
FROM golang:1.20-alpine AS builder

WORKDIR /app
COPY go.mod .
COPY main.go .

RUN go mod download
RUN CGO_ENABLED=0 GOOS=linux go build -o /app/server .

# Stage 2: Create a minimal runtime image
FROM alpine:latest

WORKDIR /app
COPY --from=builder /app/server .

EXPOSE 8080
CMD ["/app/server"]

How this code works

This Dockerfile efficiently builds and packages a Go application into a lightweight, runnable Docker image using a technique called multi-stage builds. Its primary job is to separate the build environment (which needs compilers and tools) from the runtime environment (which only needs the compiled application), resulting in a much smaller final image.

The first stage, named builder via FROM golang:1.20-alpine AS builder, prepares the build environment. It uses WORKDIR /app to set the working directory, then COPY go.mod . and COPY main.go . to bring in the application's source code and dependency file. RUN go mod download fetches dependencies, and RUN CGO_ENABLED=0 GOOS=linux go build -o /app/server . compiles the Go application. The subtle part here is CGO_ENABLED=0 GOOS=linux, which ensures the Go binary is statically linked and compatible with the Alpine Linux base in the next stage, avoiding runtime dependency issues.

The second stage starts FROM alpine:latest, a tiny base image perfect for running compiled applications. Crucially, COPY --from=builder /app/server . only copies the compiled binary from the previous builder stage, leaving behind the larger Go compiler and development tools. Finally, EXPOSE 8080 documents the application's port, and CMD ["/app/server"] defines the command to execute when a container starts, running the compiled server. This multi-stage approach results in a significantly smaller and more secure final image.

Resources

Related Articles

Hand-picked reads to go deeper on docker.

Back to DevOps Engineer Roadmap