Ein Docker-Image von 1,5 GB fühlt sich auf dem eigenen Laptop harmlos an – bis es bei jedem Deploy auf 30 Nodes gezogen wird, die Registry-Rechnung steigt und die CI-Pipeline Minute um Minute beim Pull verbringt. Die Größe deiner Images ist keine kosmetische Frage, sondern wirkt sich direkt auf Geschwindigkeit, Kosten und Skalierbarkeit aus. Dieser Artikel erklärt, an welchen drei Stellen die Image-Größe spürbar wird und wie du den Effekt vorab abschätzt.
Drei Hebel: Pull-Zeit, Speicher, Traffic
Die Größe eines Images schlägt an drei konkreten Stellen durch, die man getrennt betrachten sollte:
- Pull-Zeit: Wie lange dauert es, das Image über die verfügbare Bandbreite herunterzuladen? Bei jedem Deploy, jedem Node und jeder Pipeline-Ausführung neu.
- Registry-Speicher: Wie viel Platz belegen alle gespeicherten Tags und Versionen in deiner Container-Registry? Bei vielen Versionen summiert sich das schnell zu zweistelligen Gigabyte-Werten.
- Deploy-Traffic: Wie viel Datenverkehr entsteht insgesamt, wenn ein Image auf alle Ziel-Nodes verteilt wird? Bei Cloud-Registries kann ausgehender Traffic separat berechnet werden.
Mit dem Docker Image Size Rechner trägst du Image-Größe, Bandbreite, Anzahl der Versionen und der Nodes ein und erhältst sofort Pull-Zeit, Speicherbedarf und den gesamten Deploy-Traffic – eine schnelle Realitätsprüfung, bevor das Image in Produktion geht.
Pull-Zeit: die einfache Formel
Die Download-Zeit hängt von Größe und Bandbreite ab:
Pull-Zeit (Sekunden) = Image-Größe in Megabit ÷ Bandbreite in Mbit/s
Wichtig ist die Umrechnung von Byte auf Bit: Ein 800-MB-Image entspricht 6.400 Megabit. Bei einer 1-Gbit/s-Leitung sind das rund 6,4 Sekunden pro Pull – klingt wenig, wird aber bei 50 Nodes und mehreren Deploys am Tag zur spürbaren Wartezeit. Wer den reinen Übertragungsteil genauer rechnen möchte, kann zusätzlich den Transferzeit Rechner nutzen, der Upload- und Download-Dauer aus Dateigröße und Bandbreite ableitet.
Registry-Speicher: Versionen summieren sich
Jeder Tag, den du pushst, belegt Speicher. Layer-Sharing reduziert den realen Bedarf zwar, weil identische Layer nur einmal gespeichert werden – aber sobald sich eine Basisschicht ändert, vervielfacht sich der Verbrauch. Eine grobe Obergrenze ergibt sich aus:
Registry-Speicher = Image-Größe × Anzahl aufbewahrter Versionen
Wer 20 Versionen eines 600-MB-Images vorhält, blockiert ohne aufgeräumte Tag-Strategie rund 12 GB. Eine konsequente Retention-Policy, die alte Tags automatisch löscht, ist hier der wirksamste Hebel.
So werden Images schlank
Die wirkungsvollsten Maßnahmen, um die Image-Größe zu senken, lassen sich in wenigen Punkten zusammenfassen:
- Multi-Stage-Builds: Trenne Build- und Laufzeitumgebung. Nur das fertige Artefakt landet im finalen Image, nicht der gesamte Compiler-Stack.
- Schlanke Base-Images:
alpineoderdistrolessstatt eines vollständigen Debian sparen oft mehrere hundert Megabyte. - Layer zusammenfassen: Mehrere RUN-Befehle in einem Layer bündeln und Caches im selben Schritt löschen, damit sie nicht im Image landen.
- .dockerignore nutzen: Build-Artefakte, Git-Historie und lokale Konfiguration gehören nicht ins Image.
Warum sich der Aufwand rechnet
Ein von 1,2 GB auf 200 MB geschrumpftes Image reduziert die Pull-Zeit um den Faktor sechs, senkt den Registry-Speicher entsprechend und verkleinert den Deploy-Traffic bei jedem Rollout. In einer CI/CD-Pipeline, die hundertmal am Tag läuft, summieren sich diese Sekunden zu Minuten echter Wartezeit und damit zu Geld. Gerade in Cloud-Umgebungen, in denen ausgehender Traffic abgerechnet wird, ist ein schlankes Image direkter Kostenvorteil.
Fazit
Image-Größe ist eine der unterschätzten Stellschrauben im Container-Betrieb. Wer Pull-Zeit, Registry-Speicher und Deploy-Traffic vorab durchrechnet, erkennt früh, wo Optimierung den größten Effekt hat. Eine schnelle Einschätzung liefert der Docker Image Size Rechner; weitere Werkzeuge für Infrastruktur und Entwicklung findest du unter kotsch.tech/webtools.
Häufige Fragen
Reduziert Layer-Sharing den Registry-Speicher wirklich?
Ja, identische Layer werden in der Registry nur einmal gespeichert. Wenn deine Images eine gemeinsame Basisschicht teilen, fällt der reale Verbrauch deutlich geringer aus als die simple Multiplikation. Sobald sich aber eine frühe Schicht ändert, müssen alle darauf aufbauenden Layer neu gespeichert werden.
Wie groß sollte ein Image idealerweise sein?
Es gibt keine feste Grenze, aber für die meisten Anwendungen sind 100 bis 300 MB ein gutes Ziel. Statische Binaries in einem distroless-Image kommen sogar unter 50 MB aus. Alles über 1 GB ist ein Hinweis, dass Build- und Laufzeit nicht sauber getrennt sind.
Spielt die Image-Größe auch beim Cold Start eine Rolle?
Ja, besonders bei Serverless-Containern und Auto-Scaling. Wenn ein neuer Node das Image erst ziehen muss, bevor der Container startet, verlängert ein großes Image die Anlaufzeit spürbar. Kleine Images skalieren schneller hoch.