Wie optimierst du die Größe von Docker-Images und die Build-Performance?

Question

Accepted Answer

Die Optimierung von Docker-Images beinhaltet die Verringerung der **Größe** (kleiner, schneller, sicherer) und die Verbesserung der **Build-Performance** (schnellere Builds durch Caching). Techniken umfassen minimale Base-Images, Multi-Stage-Builds, Layer-Optimierung, BuildKit und durchdachtes Dockerfile-Design.

## Verringerung der Image-Größe

```text
✓ MINIMAL base images:
  - alpine (tiny, ~5MB) — but musl libc can cause compatibility issues for some apps
  - slim variants (e.g. python:3.12-slim) — smaller than full, fewer compat issues
  - DISTROLESS — only the app + runtime, NO shell/package manager (smallest, most secure)
  - scratch — empty base (for static binaries, e.g. Go) → minimal image
✓ MULTI-STAGE builds — build with tools, ship only the artifact (huge size savings)
✓ Combine RUN layers + clean up IN the same layer:
  RUN apt-get update && apt-get install -y x && rm -rf /var/lib/apt/lists/*
  (cleanup in a SEPARATE layer doesn't shrink the image — the files are in the earlier layer)
✓ .dockerignore — keep junk out of the context/image
✓ Remove caches, temp files, dev dependencies in production images
```

## Verbesserung der Build-Performance

```text
✓ LAYER CACHING — order Dockerfile so stable layers (deps) come before volatile (code)
✓ BUILDKIT (DOCKER_BUILDKIT=1 / default in modern Docker) — faster, parallel builds,
  better caching, build secrets, cache mounts
✓ CACHE MOUNTS — RUN --mount=type=cache,target=/root/.npm npm install
  → persist package-manager caches BETWEEN builds (don't re-download every time)
✓ Registry cache / --cache-from — reuse cached layers in CI (where the cache is cold)
```

## Multi-Stage + Distroless Beispiel

```dockerfile
FROM golang:1.22 AS build
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o app .

FROM gcr.io/distroless/static     # no shell, no OS — tiny and secure
COPY --from=build /app/app /app
ENTRYPOINT ["/app"]
# → final image is a few MB: just the static binary (vs ~800MB with the full golang image)
```

## Warum es wichtig ist

Die Optimierung von Docker-Image-Größe und Build-Performance ist wichtiges Senior-Level-Wissen, da es direkt **Deployment-Geschwindigkeit, Speicherkosten, Sicherheit und Entwickler-Produktivität** beeinflusst und daher praktisch bedeutsam für produktionsqualitative Containerisierung ist. **Die Verringerung der Image-Größe** ist wichtig, weil kleinere Images schneller deployed und gepullt werden, weniger Speicher kosten und **sicherer sind** (weniger Pakete = kleinere Angriffsfläche): Die Verwendung von **minimalen Base-Images** (Alpine, Slim, und besonders **Distroless** – enthält nur die App und Runtime ohne Shell oder Package-Manager, das kleinste und sicherste – oder `scratch` für statische Binaries), **Multi-Stage-Builds** (nur Artifacts versenden) und sorgfältige **Layer-Optimierung** (RUN-Befehle mit Cleanup im *selben* Layer kombinieren, da Cleanup in einem separaten Layer die Image-Größe nicht wirklich verringert – ein häufiges Missverständnis) können Images dramatisch verkleinern (z. B. von ~800MB auf wenige MB). **Die Verbesserung der Build-Performance** ist wichtig, da langsame Builds die Entwickler-Produktivität und CI-Durchsatz beeinträchtigen: Die Nutzung von **Layer-Caching** (Ordering für stabil-vor-volatil), **BuildKit** (schnellere parallele Builds mit besserem Caching) und besonders **Cache-Mounts** (Persistierung von Package-Manager-Caches zwischen Builds, sodass Dependencies nicht jedes Mal neu heruntergeladen werden – ein bedeutender Speedup) und Registry-Cache für CI machen Builds schneller.

Das Verständnis dieser Techniken – und subtiler Punkte wie warum Cleanup im selben Layer wichtig ist und wie Distroless sowohl Größe als auch Sicherheit verbessert – zeigt die notwendige Tiefe für wirklich optimierte Images.

Da Image-Größe und Build-Speed echte, fortlaufende Auswirkungen auf Deployment, Kosten, Sicherheit und Produktivität haben, und da diese Optimierungstechniken (minimale/Distroless-Bases, Multi-Stage-Builds, korrektes Layer-Cleanup, BuildKit-Cache-Mounts) das Erreichen schlanker, schneller, sicherer Images ermöglichen, ist das Verständnis von Docker-Image- und Build-Optimierung wichtiges Senior-Level-Wissen für produktive Containerisierung und eine Schlüsselfähigkeit, die professionelle, optimierte Docker-Nutzung auszeichnet und die Expertise widerspiegelt, die beim Erstellen effizienter, sicherer Container-Images im großen Maßstab erwartet wird.