Was sind Multi-Stage-Builds und warum verwendet man sie?

Question

Accepted Answer

**Multi-Stage-Builds** verwenden mehrere `FROM`-Stages in einer einzigen Dockerfile — die Anwendung wird in einer Stage gebaut (mit allen Build-Tools) und nur die finalen Artefakte werden in eine saubere, minimale finale Stage kopiert. Dies erzeugt **deutlich kleinere, sicherere** Production-Images.

## Das Problem: Build-Tools blähen das Image auf

```text
Building an app needs build tools (compilers, dev dependencies, SDKs), but the
FINAL image shouldn't include them:
  → they bloat the image (larger size, slower deploys)
  → they increase the attack surface (more software = more vulnerabilities)
→ You want only the built artifact + its runtime in the final image.
```

## Multi-Stage-Build

```dockerfile
# STAGE 1: "build" — has all the build tools (compile/bundle the app)
FROM node:20 AS build
WORKDIR /app
COPY package*.json ./
RUN npm install              # includes dev dependencies, build tools
COPY . .
RUN npm run build            # produces /app/dist

# STAGE 2: final — a clean, minimal image with ONLY the built artifact
FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html   # copy ONLY the build output
# → the final image has NO build tools, no dev dependencies — just nginx + the built files
```

Das `--from=build` kopiert Artefakte aus der Build-Stage in das finale Image. Das finale Image **schließt alles aus der Build-Stage aus, außer dem, was Sie explizit kopieren** — daher landen Build-Tools, Dev-Abhängigkeiten und Source nicht in Production.

## Vorteile

```text
✓ SMALLER images — only the runtime + artifacts (often 10x+ smaller)
✓ More SECURE — fewer packages = smaller attack surface (no compilers/build tools)
✓ Faster deploys/pulls (smaller images transfer faster)
✓ One Dockerfile — build and final image together (no separate build scripts)
→ Common for compiled languages (Go, Rust, Java) and Node/frontend builds.
```

## Warum es wichtig ist

Multi-Stage-Builds zu verstehen ist wertvoll für **die Erstellung kleiner, sicherer Production-Images**, daher ist es wichtiges praktisches Wissen für die Erstellung produktionsreifer Docker-Images.

Das Problem, das es löst, ist real und verbreitet: Das Bauen einer Anwendung erfordert **Build-Tools** (Compiler, SDKs, Dev-Abhängigkeiten), die das **finale Production-Image nicht enthalten sollte** — ihre Aufnahme bläht das Image auf (größere Größe, langsamere Deployments und Pulls) und erhöht die **Angriffsfläche** (mehr installierte Software bedeutet mehr potenzielle Anfälligkeiten). **Multi-Stage-Builds** lösen dies elegant durch die Verwendung mehrerer `FROM`-Stages: Die Anwendung wird in einer Stage mit allen Tools gebaut, dann werden **nur die finalen Artefakte** (`--from=build`) in eine saubere, minimale finale Stage kopiert, die alles andere ausschließt.

Dies erzeugt Images, die **dramatisch kleiner** sind (oft 10x+ kleiner — nur die Runtime und Artefakte) und **sicherer** (keine Build-Tools oder unnötige Pakete zur Ausnutzung), während alles in einer einzigen Dockerfile bleibt (keine separaten Build-Scripts).

Dieses Muster ist Standard für kompilierte Sprachen (Go, Rust, Java, wo der Compiler zur Laufzeit nicht benötigt wird) und für Frontend-/Node-Builds (wo Build-Tooling und Source nicht in Production benötigt werden).

Da kleine, sichere Production-Images für Deployment-Geschwindigkeit, Speicher und Sicherheit wichtig sind, und da Multi-Stage-Builds die Standard-, effektive Technik sind, um sie zu erreichen (Trennung der Build-Umgebung von der schlanken Runtime-Image), ist das Verständnis von Multi-Stage-Builds — des Bloat-/Sicherheitsproblems, das sie lösen, wie sie funktionieren und ihre Vorteile — wertvoll, häufig angewendetes Wissen für die Erstellung produktionsreifer Docker-Images, eine Best Practice, die in echten Dockerfiles weit verbreitet ist, und eine Schlüsselkompetenz für die Erstellung effizienter, sicherer containerisierter Anwendungen.