Skip to content
NeuralSkills
Bereitstellung

Docker-Optimierung

Docker-Images fuer Produktion optimieren — Build-Zeiten reduzieren, Image-Groessen schrumpfen und Sicherheitsluecken eliminieren.

Fortgeschritten Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

Ihr Docker-Image ist 2 GB gross, braucht 15 Minuten zum Bauen und enthaelt Dutzende bekannter Schwachstellen. Es liefert Node.js-Entwicklungsabhaengigkeiten, Build-Tools und ganze OS-Paketcaches aus, die in der Produktion nichts zu suchen haben. Aufgeblaehte Images bedeuten langsamere Deployments, hoehere Registry-Kosten, groessere Angriffsflaeche und Cold-Start-Latenz, die Ihre Skalierungsstrategie ruiniert.

Der Prompt

Du bist ein Docker-Optimierungsexperte. Analysiere mein Dockerfile und optimiere es fuer Produktion.

MEIN DOCKERFILE:
[Vollstaendiges Dockerfile hier einfuegen]

ANWENDUNGSTYP: [z.B. Node.js API, Python ML Service, Go Microservice, statische Website]
AKTUELLE IMAGE-GROESSE: [z.B. 1,8 GB]
BUILD-ZEIT: [z.B. 12 Minuten]

Optimiere in diesen Dimensionen:
1. **Multi-Stage Builds**: Trenne Build-Abhaengigkeiten von der Laufzeit. Zeige das optimierte Multi-Stage-Dockerfile.
2. **Layer-Caching**: Ordne Anweisungen um fuer maximale Cache-Treffer. Erklaere welche Layer sich haeufig vs. selten aendern.
3. **Base-Image-Auswahl**: Empfehle das kleinste sichere Base-Image (Alpine, Distroless, Scratch) mit Abwaegungen.
4. **Dependency-Pruning**: Identifiziere und entferne Dev-Abhaengigkeiten, Build-Tools, Caches und unnoetige Dateien.
5. **Sicherheitshaertung**: Als Non-Root-User ausfuehren, unnoetige Capabilities entfernen, Read-Only-Dateisystem wo moeglich.
6. **.dockerignore**: Generiere eine umfassende .dockerignore-Datei fuer meinen Projekttyp.
7. **Groessenvergleich**: Zeige erwartete Vorher/Nachher-Image-Groesse fuer jede Optimierung.

Beispielausgabe

Optimierungsergebnisse (Node.js API):
Vorher: 1,8 GB (node:20) → Nachher: 148 MB (node:20-alpine, Multi-Stage)

Wichtigste Aenderungen:
1. Multi-Stage: Build-Stage (npm ci + tsc) → Produktions-Stage (nur dist/ + node_modules --omit=dev)
2. Layer-Reihenfolge: COPY package*.json → RUN npm ci → COPY src/ (npm install gecacht bei Code-Aenderungen)
3. Base: node:20-alpine statt node:20 (spart 900 MB)
4. Pruning: npm prune --omit=dev in Produktions-Stage (spart 340 MB)
5. Sicherheit: USER node, HEALTHCHECK hinzugefuegt, kein Root-Prozess

Wann einsetzen

Verwenden Sie diesen Skill wenn Ihre Docker-Images 500 MB ueberschreiten, Ihre Builds laenger als 5 Minuten dauern oder Sie Container fuer den Produktionseinsatz vorbereiten. Fuehren Sie ihn bei jedem neuen Dockerfile aus oder wenn ein Sicherheitsscan Schwachstellen in Ihrem Base-Image meldet.

Profi-Tipps

  • Reihenfolge bestimmt Caching — setzen Sie selten aendernde Anweisungen (OS-Pakete, Abhaengigkeiten) vor haeufig aendernde (Quellcode). Ein einzelnes falsch platziertes COPY invalidiert alle nachfolgenden Cache-Layer.
  • Nutzen Sie .dockerignore konsequent — ohne diese Datei sendet COPY . . Ihren gesamten Projektkontext (inklusive node_modules, .git und Test-Fixtures) an den Docker-Daemon und verlangsamt jeden Build.
  • Pinnen Sie Ihr Base-Image per Digest — FROM node:20-alpine@sha256:abc123 stellt reproduzierbare Builds sicher. Tags wie latest oder sogar 20-alpine koennen sich unter Ihnen aendern.
  • Messen Sie nach jeder Optimierung — nutzen Sie docker images und docker history zur Verifizierung der Groessenreduktion. Manchmal fuegt eine erwartete Optimierung tatsaechlich Layer hinzu.