Docker Best Practices: 16 Tipps fuer produktionsreife Container

Die meisten Dockerfiles, die ich reviewe, teilen dieselben Probleme: 2 GB grosse Images, wenn 200 MB ausreichen wuerden, 15-minuetige Builds, die 30 Sekunden dauern koennten, Container, die ohne triftigen Grund als root laufen.

Der Container funktioniert lokal, die Tests bestehen, aber sobald er in Produktion geht, haeufen sich die Probleme: ueberlange Deployment-Zeiten, Sicherheitsluecken, explosiver Speicherverbrauch.

Der Unterschied zwischen einem Dockerfile, das "funktioniert", und einem produktionsreifen Dockerfile liegt oft in einem Dutzend Best Practices. Diese Praktiken sind nicht kompliziert, aber sie erfordern ein Verstaendnis davon, wie Docker unter der Haube funktioniert: Layer-System, Build-Cache, Prozessisolierung.

In diesem Artikel werden Sie die 16 wesentlichen Docker Best Practices entdecken, um von Amateur-Images zu professionellen Containern zu gelangen. Wir behandeln Dockerfile-Optimierung, Sicherheit, Performance und Produktionsmuster.

Dieser Artikel stellt jede Praxis praegnant vor. Um tiefer einzutauchen und in echten Umgebungen zu ueben, bietet Train With Docker "Docker Best Practices"-Szenarien, die Sie Schritt fuer Schritt durch die Implementierung jedes Konzepts fuehren.

Dockerfile-Optimierung#

1. Verwenden Sie Multi-Stage Builds#

Multi-Stage Builds sind wahrscheinlich die wirkungsvollste Technik zur Reduzierung Ihrer Image-Groesse. Die Idee: Trennen Sie die Build-Umgebung von der Laufzeitumgebung.

# Stage 1: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: Produktion
FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]

Die erste Stage enthaelt alles, was zum Kompilieren benoetigt wird (TypeScript, devDependencies, Quellcode). Die zweite Stage behaelt nur das absolute Minimum: kompilierten Code und Produktionsabhaengigkeiten.

2. Ordnen Sie Ihre Anweisungen zur Maximierung des Caches#

Docker cached jede Layer. Wenn sich eine Anweisung aendert, werden alle nachfolgenden Anweisungen neu gebaut. Die Reihenfolge Ihrer Anweisungen beeinflusst direkt Ihre Build-Geschwindigkeit.

# Schlecht: Cache wird bei jeder Code-Aenderung ungueltig
COPY . .
RUN npm ci
RUN npm run build

# Gut: Abhaengigkeiten werden separat gecached
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

Die Regel: Platzieren Sie Elemente, die sich selten aendern, zuerst (Systemabhaengigkeiten, dann Pakete, dann Quellcode).

3. Minimieren Sie die Anzahl der Layer#

Jede RUN-, COPY- und ADD-Anweisung erstellt eine neue Layer. Kombinieren Sie verwandte Befehle, um die Anzahl der Layer zu reduzieren.

# Schlecht: 3 Layer
RUN apt-get update
RUN apt-get install -y curl
RUN apt-get clean

# Gut: 1 Layer
RUN apt-get update && \
    apt-get install -y --no-install-recommends curl && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

4. Verwenden Sie eine .dockerignore-Datei#

Die .dockerignore-Datei funktioniert wie .gitignore: Sie schliesst Dateien vom Build-Kontext aus. Ohne sie kopiert Docker alles, einschliesslich node_modules, .git und Ihre Testdateien.

node_modules
.git
.gitignore
*.md
.env*
coverage
.nyc_output
dist

5. Waehlen Sie das richtige Basis-Image#

Die Wahl des Basis-Images beeinflusst die endgueltige Groesse, Sicherheit und verfuegbare Abhaengigkeiten.

Alpine verwendet musl libc anstelle von glibc. In 95% der Faelle funktioniert es einwandfrei. Fuer die restlichen 5% (bestimmte native Binaerdateien) verwenden Sie -slim.

Googles Distroless-Images sind schwerer als Alpine, aber sie enthalten keine Shell, keinen Paketmanager und keine Systemtools. Nur die Runtime (hier Node.js) und ihre Abhaengigkeiten sind vorhanden. Ergebnis: weniger Angriffsflaeche und kein Weg fuer einen Angreifer, Befehle im Container auszufuehren.

Container-Sicherheit#

6. Fuehren Sie niemals als root aus#

Standardmaessig laufen Docker-Container als root. Dies ist ein grosses Sicherheitsproblem: Wenn ein Angreifer Ihre Anwendung kompromittiert, hat er root-Privilegien im Container.

FROM node:20-alpine

# Erstellen Sie einen Nicht-root-Benutzer
RUN addgroup -g 1001 -S nodejs && \
    adduser -S nextjs -u 1001

WORKDIR /app
COPY --chown=nextjs:nodejs . .

# Wechseln Sie den Benutzer vor CMD
USER nextjs

CMD ["node", "index.js"]

7. Begrenzen Sie Linux Capabilities#

Standardmaessig gewaehrt Docker Ihren Containern eine Reihe von Linux Capabilities (Systemberechtigungen). Die meisten sind fuer eine Standardanwendung unnoetig und stellen ein Sicherheitsrisiko dar.

# Entfernen Sie alle Capabilities und fuegen Sie nur die notwendigen hinzu
docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE myapp

Gaengigste Capabilities:

Fuer Docker Compose:

services:
  app:
    image: myapp
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

8. Verwenden Sie minimale Basis-Images#

Je mehr Pakete ein Image enthaelt, desto groesser ist seine Angriffsflaeche. Googles Distroless-Images enthalten nur Ihre Anwendung und ihre Runtime-Abhaengigkeiten, ohne Shell oder Systemtools.

FROM node:20-alpine AS builder
WORKDIR /app
COPY . .
RUN npm ci && npm run build

FROM gcr.io/distroless/nodejs20-debian12
COPY --from=builder /app/dist /app
WORKDIR /app
CMD ["index.js"]

Der Nachteil: Es ist unmoeglich, docker exec zum Debuggen zu verwenden. Das ist beabsichtigt. In der Produktion sollten Sie keine Shell in Ihren Containern benoetigen.

9. Scannen Sie Ihre Images auf Schwachstellen#

Docker-Images koennen CVEs (bekannte Schwachstellen) in ihren Systempaketen oder Abhaengigkeiten enthalten.

# Mit Docker Scout (in Docker Desktop integriert)
docker scout cves <image>

# Mit Trivy (Open Source)
trivy image <image>

# Mit Snyk
snyk container test <image>

Integrieren Sie diese Scans in Ihre CI/CD. Ein Scan, der eine kritische Schwachstelle entdeckt, sollte das Deployment blockieren.

10. Verwalten Sie Ihre Secrets richtig#

Legen Sie niemals Secrets in Ihr Dockerfile oder Image. Sie bleiben im Layer-Verlauf erhalten.

# NIEMALS: Das Secret bleibt im Image
ENV DATABASE_URL=postgres://user:password@host/db

# BESSER: Verwenden Sie Docker Secrets (Build-Zeit)
# Das Secret wird waehrend des Builds temporaer in /run/secrets/ gemountet
# Es wird niemals in eine Image-Layer geschrieben
RUN --mount=type=secret,id=db_url \
    export DATABASE_URL=$(cat /run/secrets/db_url) && \
    npm run migrate

# Zum Bauen mit diesem Secret:
# docker build --secret id=db_url,src=.env .

# IN PRODUKTION: Uebergeben Sie Secrets zur Laufzeit
docker run -e DATABASE_URL=$DATABASE_URL myapp

Fuer Docker Swarm und Kubernetes verwenden Sie deren native Secrets-Mechanismen.

Performance und Image-Groesse#

11. Bereinigen Sie Caches in derselben Layer#

Paketmanager hinterlassen Caches. Wenn Sie sie in einer separaten Layer bereinigen, bleibt der Cache in vorherigen Layern erhalten.

# Python
RUN pip install --no-cache-dir -r requirements.txt

# Node.js
RUN npm ci --only=production && npm cache clean --force

# Debian/Ubuntu
RUN apt-get update && \
    apt-get install -y --no-install-recommends package && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

12. Verwenden Sie COPY anstelle von ADD#

COPY macht genau das, was der Name sagt: Dateien kopieren. ADD macht dasselbe, extrahiert aber automatisch Archive (.tar, .gz) und kann Dateien von einer URL herunterladen. Diese impliziten Verhaltensweisen machen das Dockerfile weniger lesbar und koennen Sicherheitsluecken einfuehren, wenn eine URL kompromittiert ist oder ein Archiv unerwartete Dateien enthaelt. Bevorzugen Sie COPY fuer seine Vorhersehbarkeit.

# Bevorzugen
COPY ./src /app/src

# Vermeiden (es sei denn, Sie muessen ein Archiv extrahieren)
ADD ./src /app/src

Build Best Practices#

13. Fuegen Sie Labels fuer Metadaten hinzu#

Labels helfen bei der Identifizierung und Dokumentation Ihrer Images.

LABEL org.opencontainers.image.title="Meine Anwendung"
LABEL org.opencontainers.image.description="Backend API"
LABEL org.opencontainers.image.version="1.2.3"
LABEL org.opencontainers.image.authors="[email protected]"
LABEL org.opencontainers.image.source="https://github.com/org/repo"

Diese Labels folgen der OCI-Spezifikation und werden von Docker Hub, GitHub Container Registry und anderen Registries erkannt.

14. Implementieren Sie Health Checks#

Ein Health Check ermoeglicht es Docker (und Orchestratoren) zu ueberpruefen, ob Ihre Anwendung tatsaechlich funktioniert.

HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1

Ohne Health Check betrachtet Docker einen Container als "healthy", sobald er startet, selbst wenn die Anwendung nach 5 Sekunden abstuerzt.

15. Verstehen Sie den Unterschied zwischen ENTRYPOINT und CMD#

• ENTRYPOINT: definiert den Hauptbefehl (selten ueberschrieben)
• CMD: definiert Standardargumente (leicht ueberschreibbar)

# Empfohlenes Muster
ENTRYPOINT ["node"]
CMD ["index.js"]

# Ermoeglicht:
docker run myapp                    # Fuehrt node index.js aus
docker run myapp other-script.js    # Fuehrt node other-script.js aus

Verwenden Sie die Exec-Form ["cmd", "arg"] anstelle der Shell-Form cmd arg. Die Exec-Form ermoeglicht eine bessere Signal-Behandlung.

Logging und Observability#

16. Schreiben Sie Ihre Logs nach stdout/stderr#

Docker erfasst automatisch alles, was nach stdout und stderr geht. Schreiben Sie nicht in Log-Dateien.

// Gut: stdout
console.log(JSON.stringify({ level: 'info', message: 'User logged in', userId: 123 }));

// Schlecht: Datei
fs.appendFileSync('/var/log/app.log', 'User logged in\n');

Das JSON-Format strukturiert Ihre Logs fuer Aggregationstools (ELK, Datadog, CloudWatch).

# Leiten Sie Logs nicht in Dateien um
CMD ["node", "index.js"]

# Nicht so:
CMD ["node", "index.js", ">", "/var/log/app.log"]

Orchestrierung und Produktion#

Sobald Ihre Images optimiert sind, gelten einige zusaetzliche Praktiken zur Laufzeit.

Begrenzen Sie Ressourcen, um zu verhindern, dass ein Container den Server monopolisiert:

docker run --memory="512m" --cpus="0.5" myapp

Konfigurieren Sie Restart-Policies fuer Resilienz:

docker run --restart=unless-stopped myapp

Verwenden Sie Rolling Updates mit Docker Swarm oder Kubernetes fuer unterbrechungsfreie Deployments.

Fazit#

Diese 16 Docker Best Practices decken die wesentlichen Aspekte ab: Build-Optimierung, Sicherheit, Performance und Produktionsbereitschaft. Systematisch angewendet, verwandeln sie Amateur-Dockerfiles in professionelle Konfigurationen.

Das Wichtigste: Verstehen Sie, warum jede Praxis existiert. Multi-Stage Builds reduzieren die Groesse, weil sie Build und Runtime trennen. Der Cache funktioniert pro Layer, daher ist die Reihenfolge wichtig. Nicht-root-Container begrenzen die Auswirkungen einer Kompromittierung.

Dieser Artikel streift jede Praxis, ohne in Implementierungsdetails einzutauchen. Um selbst Hand anzulegen, bietet Train With Docker "Docker Best Practices"-Szenarien, mit denen Sie jedes Konzept in vorkonfigurierten Umgebungen ueben koennen, ohne lokal etwas installieren zu muessen.