Claude Code & Docker: Container-Entwicklung effizient gestalten

Docker ist aus modernen Entwicklungsworkflows nicht wegzudenken — aber gut geschriebene Dockerfiles sind seltener als man denkt. Zu große Images, unnötige Layers, fehlende Healthchecks, Secrets direkt im Build-Kontext: diese Probleme schleichen sich ein, weil man Docker oft "irgendwie zum Laufen bringt" und dann nicht mehr anfasst.

Claude Code ändert das. Nicht weil es Docker besser kennt als du, sondern weil es deinen gesamten Projektkontext — Dockerfile, docker-compose.yml, .dockerignore, package.json, CI-Konfiguration — gleichzeitig liest und analysiert. Dieser Artikel zeigt, welche Container-Workflows sich dadurch konkret verbessern lassen.

1. Multi-Stage Builds: schlank von Anfang an

Das häufigste Performance-Problem bei Docker-Images ist ein fehlendes Multi-Stage-Build. Ohne es landen Build-Tools, Dev-Dependencies und Zwischendateien im finalen Image — das wird dann 800 MB statt 80 MB groß. Claude Code erkennt dieses Muster sofort:

claude "Optimiere mein Dockerfile mit einem Multi-Stage Build.
Das Projekt ist eine Node.js-API mit TypeScript."

Claude Code liest das bestehende Dockerfile, prüft die package.json auf den Build-Befehl und erzeugt einen sauberen Multi-Stage-Aufbau: eine builder-Stage für den TypeScript-Compile, eine schlanke production-Stage die nur die kompilierten Dateien und node_modules --production enthält.

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

# production
FROM node:20-alpine AS production
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
RUN npm ci --omit=dev
COPY --from=builder /app/dist ./dist
EXPOSE 3000
CMD ["node", "dist/index.js"]

Das Ergebnis: ein Image, das nur das enthält, was zur Laufzeit tatsächlich gebraucht wird. Weniger Angriffsfläche, schnellere Pull-Zeiten, kleinere Registry-Kosten.

2. Layer-Caching richtig nutzen

Docker cached jeden Layer — aber nur dann, wenn sich nichts in den darüber liegenden Layers geändert hat. Die häufigste Caching-Falle: COPY . . vor npm install. Jede Quellcode-Änderung invalidiert dann den Dependency-Layer und erzwingt einen kompletten Neuinstall.

Claude Code erkennt diese Reihenfolge-Probleme automatisch wenn du fragst:

claude "Warum sind meine Docker-Builds so langsam?
Analysiere mein Dockerfile auf Cache-Ineffizienz."

Die korrekte Reihenfolge: zuerst nur die Dependency-Dateien kopieren, installieren, dann den Rest. So wird der npm install-Layer nur dann neu ausgeführt, wenn sich tatsächlich package.json oder package-lock.json geändert haben.

3. .dockerignore: was nicht ins Image gehört

Eine fehlende oder unvollständige .dockerignore-Datei bedeutet, dass COPY . . auch node_modules, .git, lokale .env-Dateien, Test-Fixtures und IDE-Konfigurationen in den Build-Kontext schiebt. Das verlangsamt jeden Build und kann versehentlich Secrets in das Image einbringen.

claude "Erstelle eine vollständige .dockerignore für mein Node.js-Projekt
und erkläre warum jeder Eintrag wichtig ist."

Claude Code liest die Projektstruktur und erstellt eine .dockerignore die auf dein Setup zugeschnitten ist — inklusive der Verzeichnisse die dein spezifisches Framework erzeugt und die niemand manuell kennt.

4. docker-compose.yml: Netzwerke und Volumes sauber konfigurieren

Docker Compose für lokale Entwicklung ist großartig — aber komplex sobald mehrere Services, Datenbanken und persistente Volumes dazukommen. Claude Code hilft dabei, das Setup von Anfang an sauber aufzubauen:

claude "Schreib mir eine docker-compose.yml für eine Node.js-API,
eine PostgreSQL-Datenbank und einen Redis-Cache.
Die API soll nur über ein internes Netzwerk auf DB und Cache zugreifen können."

Das Ergebnis ist ein Compose-File mit expliziten Netzwerkdefinitionen: die Datenbank ist nicht nach außen exponiert, sondern nur im internen backend-Netzwerk erreichbar. Volumes sind benannt statt anonymer Bind-Mounts, damit sie beim nächsten docker compose up erhalten bleiben.

networks:
  backend:
    driver: bridge
  frontend:
    driver: bridge

volumes:
  postgres_data:
  redis_data:

5. Secrets sicher handhaben

Die richtige Methode für Secrets in Docker hängt von der Umgebung ab. Für lokale Entwicklung genügt eine .env-Datei die nie ins Git-Repository committed wird. Für Produktion sind Docker Secrets oder externe Secret-Manager (Vault, AWS Secrets Manager) die richtige Wahl.

claude "Zeig mir wie ich Datenbankpasswörter und API-Keys sicher
in mein Docker-Setup integriere. Lokale Entwicklung und Produktion
sollen unterschiedlich behandelt werden."

Claude Code erklärt den Unterschied zwischen environment (Werte direkt), env_file (aus Datei) und Docker Secrets (verschlüsselt im Swarm), und zeigt welche Methode für welchen Kontext passt. Die Kernregel bleibt immer gleich: Secrets kommen aus der Laufzeitumgebung, nicht aus dem Build-Prozess.

6. Healthchecks: Container-Stabilität sicherstellen

Ohne Healthcheck gilt ein Container als "running" sobald der Prozess gestartet ist — egal ob die Anwendung tatsächlich bereit ist. In docker-compose-Setups mit Abhängigkeiten (depends_on) führt das zu Race-Conditions: die API startet, bevor die Datenbank bereit ist.

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

Claude Code fügt Healthchecks nicht nur ins Dockerfile ein, sondern aktualisiert auch die docker-compose.yml so dass depends_on mit condition: service_healthy arbeitet:

depends_on:
  db:
    condition: service_healthy
  redis:
    condition: service_healthy

Das ist der Unterschied zwischen einem Compose-Setup das manchmal funktioniert und einem das zuverlässig funktioniert.

7. Docker in CI/CD integrieren

In GitHub Actions oder GitLab CI wird Docker für reproduzierbare Build-Umgebungen genutzt — aber schlecht konfiguriert verdoppeln Container die Build-Zeit statt sie zu halbieren. Der häufigste Fehler: kein Layer-Caching in der CI-Pipeline.

claude "Erstelle eine GitHub Actions Workflow-Datei die mein Docker-Image
baut, cached und in die GitHub Container Registry pusht.
Layer-Caching soll aktiviert sein."

Claude Code liest die bestehende CI-Konfiguration wenn vorhanden, prüft ob bereits ein Registry-Login existiert, und erstellt einen Workflow mit docker/build-push-action und explizitem Cache-Export nach type=gha. Das kann Build-Zeiten von 8 Minuten auf unter 2 Minuten reduzieren, wenn sich Dependencies nicht geändert haben.

• Cache-Key → auf package-lock.json oder requirements.txt basieren, nicht auf HEAD
• Multi-Platform Builds → linux/amd64,linux/arm64 für Apple Silicon Kompatibilität
• Image-Tags → immer mit Git-SHA taggen, nie nur latest

8. Claude Code-Tipps für den Docker-Alltag

Ein paar Prompts die ich regelmäßig nutze und die konsistent gute Ergebnisse liefern:

# Image-Größe analysieren
claude "Analysiere warum mein Docker-Image so groß ist und zeige
die 5 größten Einsparungspotenziale."

# docker-compose debuggen
docker compose up 2>&1 | claude "Was geht hier schief und warum?"

# Dockerfile-Review
claude "Reviewe mein Dockerfile auf Security-Probleme, unnötige Layers
und fehlende Best Practices."

Der letzte Prompt ist besonders nützlich: Claude Code prüft dabei auch ob der Container als root läuft (sollte er nicht), ob --no-cache-dir bei pip-Installs gesetzt ist, ob COPY --chown korrekt verwendet wird, und ob der CMD-Befehl die Signal-Weiterleitung unterstützt (exec-Form statt Shell-Form).

"Ein gutes Dockerfile ist kein einmaliges Dokument — es entwickelt sich mit dem Projekt. Claude Code liest den aktuellen Stand und empfiehlt was heute relevant ist, nicht was vor zwei Jahren Standard war."

Verwandte Artikel die auf diesen Themen aufbauen:

• Claude Code Debugging — Bugs in Minuten statt Stunden finden
• Claude Code für Unternehmen — Deployment, Zugriffskontrolle und Team-Workflows