{"id":15324,"date":"2026-10-08T16:37:07","date_gmt":"2026-10-08T09:37:07","guid":{"rendered":"\/de\/tutorials\/?p=15324"},"modified":"2026-10-08T16:54:47","modified_gmt":"2026-10-08T09:54:47","slug":"docker-best-practices","status":"publish","type":"post","link":"\/de\/tutorials\/docker-best-practices\/","title":{"rendered":"Docker Best Practices f\u00fcr das Erstellen und Ausf\u00fchren von Containern"},"content":{"rendered":"

Docker Best Practices sind bewährte Richtlinien, mit denen Sie Container sicher und effizient erstellen, ausführen und verwalten.<\/p>

Docker bündelt Anwendungen und ihre Abhängigkeiten in portablen Containern, die sich in unterschiedlichen Umgebungen konsistent ausführen lassen.<\/p>

Einheitliche Umgebungen vereinfachen Entwicklung und Bereitstellung. Für eine zuverlässige Containerisierung reicht es jedoch nicht aus, eine Anwendung lediglich in einem Image zu verpacken.<\/p>

Die wichtigsten Best Practices betreffen daher die Bereiche, die sich in realen Umgebungen besonders stark auswirken: Image-Optimierung, effiziente Builds, Container-Sicherheit, Secret-Verwaltung, Observability und die Vorbereitung auf die Orchestrierung.<\/p>

Zusammen sorgen diese Maßnahmen dafür, dass sich Container über ihren gesamten Lebenszyklus hinweg einfacher bereitstellen, skalieren, absichern und verwalten lassen.<\/p>

1. Verwenden Sie offizielle und schlanke Basis-Images<\/h2>

Offizielle Images stammen von vertrauenswürdigen Maintainern und bieten damit eine sicherere Grundlage für Ihre Container. Schlanke Images enthalten weniger Pakete, Tools und Bibliotheken im finalen Image.<\/p>

Minimalistische Basis-Images wie Alpine beschränken sich auf die wesentlichen Komponenten, die zum Ausführen einer Anwendung erforderlich sind, und halten Container dadurch schlank.<\/p>

\n\n\n

\n
\n \n \n <\/svg>\n

\n Profi-Tipp <\/p>\n <\/div>\n

Bevorzugen Sie für Produktions-Workloads Distroless-Images, etwa die von Google bereitgestellten Varianten, wenn Sie die Angriffsfläche so klein wie möglich halten möchten. Alpine-basierte Images eignen sich dagegen, wenn Sie während der Entwicklung eine Shell oder einen Paketmanager für das Debugging benötigen.<\/p>\n <\/div>\n \n\n\n\n<\/p>

Größere Allzweck-Images enthalten mehr Systemprogramme und Abhängigkeiten. Dadurch müssen im Laufe der Zeit auch mehr Komponenten gepatcht, gescannt und abgesichert werden. Jedes zusätzliche Paket enthält Code, der gepflegt werden muss. Wenn Sie nicht benötigte Komponenten entfernen, reduzieren Sie Schwachstellen und beschleunigen das Erstellen, Herunterladen und Starten von Images.<\/p>

2. Fixieren Sie Versionen von Basis-Images für reproduzierbare Builds<\/h2>

Fixieren Sie bestimmte Versionen von Basis-Images, damit Builds reproduzierbar bleiben und sich nicht unerwartet verändern. Allgemeine Tags wie latest<\/code> schaffen Unsicherheit, da sich das zugrunde liegende Image jederzeit ändern kann.<\/p>

Ein Dockerfile, das heute funktioniert, kann morgen ein anderes Image erzeugen, obwohl sich am Anwendungscode nichts geändert hat.<\/p>

Durch die Versionsfixierung werden Deployments berechenbarer, da für jeden Build dieselbe Version des Basis-Images verwendet wird.<\/p>

Tags wie node:22.11-alpine<\/code> oder python:3.12-slim<\/code> helfen, unbemerkte Änderungen an Abhängigkeiten, unerwartete Paket-Updates und Kompatibilitätsprobleme zu vermeiden, die sich nach dem Deployment nur schwer diagnostizieren lassen.<\/p>

Teams, die noch stärkere Garantien benötigen, können zusätzlich zu Versions-Tags auch Image-Digests fixieren. Ein Image-Digest verweist auf einen bestimmten Image-Build und stellt sicher, dass Docker<\/a> jedes Mal exakt dasselbe Image abruft.<\/p>

Der Nachteil ist der zusätzliche Wartungsaufwand, da fixierte Digests nicht automatisch aktualisiert werden. Sicherheitspatches und neue Releases müssen manuell geprüft und im Dockerfile aktualisiert werden.<\/p>

3. Schreiben Sie effiziente Dockerfiles<\/h2>

Achten Sie beim Schreiben von Dockerfiles auf Image-Größe, Build-Geschwindigkeit und Sicherheit. Der Aufbau des Dockerfiles bestimmt, wie viele Layer Docker erstellt, wie viele Daten das finale Image enthält und wie effizient spätere Builds bereits zwischengespeicherte Arbeit wiederverwenden können.<\/p>

Effiziente Dockerfiles vermeiden unnötige Abhängigkeiten und entfernen temporäre Dateien nach der Paketinstallation.<\/p>

Build-Tools, Paket-Caches, Protokolle und heruntergeladene Archive sollten nicht im Runtime-Image verbleiben, sofern die Anwendung sie nicht benötigt. Zusätzliche Dateien vergrößern das Image und erhöhen die Zahl der Komponenten, die gescannt, gepatcht und gepflegt werden müssen.<\/p>

Auch die Verwaltung der Layer ist wichtig. Fassen Sie zusammengehörige Befehle in einer einzigen RUN<\/strong>-Anweisung zusammen, um unnötige Layer zu vermeiden. Ein kleineres Image ist allerdings nur dann von Vorteil, wenn spätere Entwickler nachvollziehen können, wie es erstellt wird, und die Anweisungen sicher aktualisieren können.<\/p>

Vorhersehbar aufgebaute Dockerfiles lassen sich langfristig leichter pflegen. Eine klare Reihenfolge der Anweisungen, explizit definierte Abhängigkeiten und gut lesbare Befehle verringern unerwartete Build-Ergebnisse und erleichtern die Fehlersuche bei Deployments.<\/p>

4. Reduzieren Sie die Image-Größe mit Multi-Stage-Builds<\/h2>

Trennen Sie mit Multi-Stage-Builds die für den Build benötigten Tools von den Runtime-Abhängigkeiten. Build-Tools, Compiler, Paketmanager und Quelldateien werden nur während des Builds benötigt.<\/p>

Das finale Image<\/strong> enthält lediglich die kompilierte Anwendung und die Dateien, die für deren Ausführung erforderlich sind.<\/p>

Multi-Stage-Builds verkleinern Images, indem sie Komponenten ausschließen, die zur Runtime nicht benötigt werden. Kleinere Images lassen sich schneller übertragen und starten und benötigen weniger Speicherplatz.<\/p>

Werden Build-Tools und Entwicklungsabhängigkeiten entfernt, verringert sich außerdem die Angriffsfläche, da im laufenden Container weniger Komponenten verfügbar sind.<\/p>

Besonders effektiv sind Multi-Stage-Builds bei kompilierten Anwendungen und Projekten mit umfangreichen Build-Abhängigkeiten.<\/p>

Sprachen, Runtimeumgebungen und Bibliotheken wie Go, Java, .NET, Node.js und React<\/a> profitieren häufig von diesem Ansatz, weil die Build-Umgebung deutlich größer ist als die Runtime-Umgebung.<\/p>

\n\n\n

\n
\n \n \n <\/svg>\n

\n Profi-Tipp <\/p>\n <\/div>\n

Ein einfaches Multi-Stage-Dockerfile verwendet für jede Stage eine eigene FROM<\/code>-Anweisung. Benennen Sie die Build-Stage, zum Beispiel mit FROM node:20-alpine AS builder<\/code>, führen Sie die Build-Schritte aus und beginnen Sie anschließend eine neue Stage mit einem schlanken Basis-Image. Kopieren Sie darin mit COPY --from=builder<\/code> ausschließlich die kompilierten Ausgabedateien.<\/p>\n <\/div>\n \n\n\n\n<\/p>

Durch diese Trennung bleiben Produktions-Images schlank, ohne den Entwicklungsworkflow unnötig zu verkomplizieren.<\/p>

5. Optimieren Sie die Nutzung des Docker-Build-Caches<\/h2>

Nutzen Sie den Docker-Build-Cache effizient, um Build-Zeiten zu verkürzen und unnötige Arbeit bei erneuten Builds zu vermeiden. Docker speichert jede Anweisung als wiederverwendbaren Layer. Unveränderte Teile des Build-Prozesses können dadurch aus dem Cache übernommen werden, statt jedes Mal neu erstellt zu werden.<\/p>

\n
\"Diagramm