Stellen Sie sich vor, es ist Freitagnachmittag um 16:30 Uhr. Ein Junior-Entwickler hat gerade eine wichtige Software-Bibliothek manuell in einem laufenden Container aktualisiert, weil das Dockerfile seit Wochen nicht mehr gebaut wurde und die Abhängigkeiten sich widersprechen. Er führt den Befehl aus, um die Änderungen zu sichern, und freut sich, dass alles läuft. Er denkt, er hat den Tag gerettet. In Wirklichkeit hat er gerade eine Zeitbombe gelegt. Drei Monate später stürzt die Datenbank ab. Niemand weiß mehr, welche Version dieser einen Bibliothek damals installiert wurde. Der Quellcode im Git-Repository passt nicht zum laufenden Image. Der Versuch, Create A Docker Image From Container als dauerhafte Lösung zu nutzen, hat das Unternehmen bereits tausende Euro an Ausfallzeit und Forensik-Kosten gekostet. Ich habe das in Projekten oft erlebt: Teams versuchen, die mühsame Automatisierung zu umgehen, indem sie den Zustand eines "kaputtkonfigurierten" Containers einfrieren. Das ist der sicherste Weg in den Wahnsinn.
Die Illusion der Schnelligkeit beim Create A Docker Image From Container
Der größte Fehler, den ich immer wieder sehe, ist die Annahme, dass man Zeit spart. Man hat einen Container, man installiert darin drei Pakete, ändert eine Konfigurationsdatei und denkt sich: "Ich mache jetzt einfach einen Snapshot." Wer den Prozess Create A Docker Image From Container wählt, um ein Dockerfile zu vermeiden, begeht einen Kardinalfehler in der Software-Infrastruktur. Ebenfalls in den Schlagzeilen: python list and for loop.
Das Problem liegt in der fehlenden Reproduzierbarkeit. Ein Docker-Image sollte ein Artefakt sein, das aus Code entsteht. Wenn Sie diesen Vorgang nutzen, um ein Image aus einem laufenden Container zu erzeugen, unterbrechen Sie die Kette der Nachvollziehbarkeit. In einem realen Fall bei einem mittelständischen Logistikdienstleister führte das dazu, dass ein Sicherheitsupdate für eine Java-Laufzeitumgebung nicht eingespielt werden konnte, weil niemand wusste, auf welchem Betriebssystem-Unterbau der "Snapshot" eigentlich basierte. Das Team verbrachte zwei Wochen damit, das Image zu reverse-engineeren. Die Kosten für die Techniker überstiegen die Kosten für ein sauber geschriebenes Dockerfile um das Zehnfache.
Der verborgene Müll in Ihren Layern
Wenn man manuell in einem Container arbeitet, entstehen temporäre Dateien. Logs wachsen, Cache-Verzeichnisse füllen sich, Apt-Listen blähen sich auf. Ein Dockerfile erlaubt es Ihnen, diese Reste in einer einzigen Schicht zu bereinigen. Wenn Sie jedoch den Zustand eines Containers einfrieren, schleppen Sie diesen ganzen Ballast mit. Ich habe Images gesehen, die 2 GB groß waren, obwohl sie nur eine einfache Python-Applikation enthielten. Der Grund? Der Entwickler hatte während der manuellen Einrichtung Testdaten heruntergeladen und sie zwar gelöscht, aber im Dateisystem-Layer des Containers blieben sie für immer erhalten. Große Images bedeuten langsame Deployments, höhere Speicherkosten bei Cloud-Anbietern und eine größere Angriffsfläche für Hacker. Um das größere Bild zu erfassen, lesen Sie den ausgezeichneten Artikel von CHIP.
Warum Create A Docker Image From Container Ihre Sicherheitsstrategie ruiniert
Sicherheit in der IT funktioniert über Transparenz. Ein Security-Scanner wie Trivy oder Grype liest ein Dockerfile und die darin definierten Layer, um Schwachstellen zu finden. Bei einem Image, das manuell aus einem Container erstellt wurde, sieht der Scanner oft nur einen riesigen, undurchsichtigen Block an Daten.
In meiner Praxis habe ich erlebt, wie ein Unternehmen eine Prüfung durch einen externen Auditor nicht bestanden hat, weil die Herkunft der installierten Binärdateien nicht belegt werden konnte. Es gab keine Spur davon, woher das curl-Paket oder die openssl-Bibliothek stammten. War es ein offizielles Repository? War es eine manuell kompilierte Version mit bekannten Sicherheitslücken? Wer diesen Weg geht, verliert die Kontrolle über die Software-Supply-Chain. Das ist in regulierten Branchen wie dem Bankenwesen oder der Medizintechnik ein absolutes Ausschlusskriterium.
Der fatale Verzicht auf Versionierung und GitOps
Ein Dockerfile gehört ins Git. Punkt. Jede Änderung wird durch einen Pull-Request geprüft, getestet und dokumentiert. Wenn Sie stattdessen den Zustand eines Containers manuell sichern, existiert diese Änderung nur in der Docker-Registry.
Stellen wir uns einen Vorher-Nachher-Vergleich vor, um den Unterschied in der täglichen Arbeit zu verdeutlichen:
Szenario Vorher (Manueller Snapshot-Ansatz):
Ein Entwickler stellt fest, dass die Zeitzone im Container falsch eingestellt ist. Er loggt sich per SSH in den laufenden Container ein, führt dpkg-reconfigure tzdata aus, stellt alles ein und erzeugt ein neues Image. Er benennt es app-v2-final-fix. Zwei Wochen später stellt ein anderer Kollege fest, dass die Anwendung bei Sommerzeitumstellungen abstürzt. Er schaut ins Git-Repository, sieht dort aber nur das alte Dockerfile von vor drei Monaten, in dem die Zeitzone noch auf UTC steht. Er ist verwirrt, überschreibt das Image mit einer neuen Version basierend auf dem alten Dockerfile, und die Korrektur des ersten Kollegen ist spurlos verschwunden. Der Fehler tritt erneut in der Produktion auf. Drei Stunden Ausfallzeit, verärgerte Kunden.
Szenario Nachher (Automatisierter Ansatz):
Der Entwickler bemerkt das Zeitzonenproblem. Er öffnet das Dockerfile, fügt zwei Zeilen hinzu, um die Zeitzone korrekt zu setzen, und committet die Änderung in den main-Branch. Die CI/CD-Pipeline baut automatisch ein neues Image, lässt Tests laufen und schiebt es in die Registry. Der Kollege kann jederzeit im Git-Log nachsehen, warum diese Änderung gemacht wurde. Es gibt eine "Single Source of Truth". Wenn etwas schiefgeht, kann man mit einem Klick auf die vorherige Git-Revision zurückrollen.
Wann Sie diesen Prozess trotzdem brauchen könnten
Es gibt genau eine Situation, in der ich diesen Weg akzeptiere: Forensik oder Rettung von Daten. Wenn eine Anwendung in einem Container abgestürzt ist und Sie den Zustand exakt so einfrieren müssen, wie er im Moment des Fehlers war, um ihn später in einer isolierten Umgebung zu untersuchen — dann ist das legitim.
Ich habe das einmal bei einem Kunden gemacht, bei dem eine Datenbank-Migration mitten im Prozess hängen geblieben war. Wir haben den Container angehalten, ein Image daraus gezogen und konnten so auf einem Testserver in aller Ruhe versuchen, die Daten zu retten, ohne das Live-System weiter zu gefährden. Aber das ist eine Rettungsmaßnahme, kein Standard-Workflow für die Softwareentwicklung. Wer das als Teil seines Deployment-Prozesses sieht, hat ein tiefgreifendes Verständnisproblem von Container-Technologie.
Die technische Sackgasse der Layer-Struktur
Docker verwendet ein Union File System. Jede Änderung im Container ist ein Schreibvorgang auf der obersten, beschreibbaren Schicht. Wenn Sie ein Image aus einem Container erstellen, wird diese beschreibbare Schicht einfach festgeschrieben.
Das Problem dabei: Wenn Sie im Container eine 100 MB große Datei löschen, die in einem der unteren Layer vorhanden war, wird sie im neuen Image nicht wirklich gelöscht. Es wird lediglich eine Markierung gesetzt, dass diese Datei nicht mehr sichtbar sein soll. Der Speicherplatz wird weiterhin verbraucht. Ich habe Projekte gesehen, bei denen die Images durch ständiges "Snapshotting" auf mehrere Gigabyte angewachsen sind, obwohl die eigentliche Applikation winzig war. Das treibt die Kosten für die Cloud-Registry in die Höhe und macht das Scaling Ihrer Infrastruktur unerträglich langsam. Ein Auto-Scaling-Event in der Cloud dauert dann nicht mehr 30 Sekunden, sondern fünf Minuten, weil das riesige Image erst über das Netzwerk gezogen werden muss. In Spitzenlastzeiten bricht Ihnen dann das System weg, bevor die neuen Instanzen bereit sind.
Strategien für den Ausstieg aus der Snapshot-Falle
Wenn Sie bereits in dieser Falle sitzen und Ihre gesamte Infrastruktur auf manuell erstellten Images basiert, müssen Sie handeln. Es ist mühsam, aber alternativlos.
- Inventur machen: Listen Sie alle Images auf, für die kein aktuelles Dockerfile existiert.
- Reverse Engineering: Nutzen Sie Tools wie
docker history, um zu sehen, welche Befehle in der Vergangenheit ausgeführt wurden. Das ist Detektivarbeit, aber sie ist notwendig. - Schrittweise Migration: Fangen Sie nicht damit an, alles auf einmal neu zu bauen. Nehmen Sie das wichtigste Image und versuchen Sie, seinen Zustand in einem sauberen Dockerfile nachzubilden.
- Verbot von manuellen Zugriffen: Entziehen Sie den Entwicklern die Berechtigung, manuell Änderungen in Produktions-Containern vorzunehmen. Das klingt hart, schützt aber die Stabilität des Systems.
Es gibt keinen magischen Knopf, der ein manuell verändertes System in sauberen Code zurückverwandelt. Der Weg zurück zur Vernunft führt über Disziplin und Automatisierung. In einem Fall bei einem Berliner Startup haben wir drei Monate gebraucht, um die "Snapshot-Kultur" komplett auszumerzen. Die Belohnung war eine Halbierung der Deployment-Fehler und eine deutlich motiviertere Entwickler-Crew, die sich nicht mehr mit mysteriösen "Geister-Fehlern" herumschlagen musste.
Der Realitätscheck
Machen wir uns nichts vor: Ein Dockerfile zu schreiben ist manchmal nervig. Es dauert länger, die richtige Syntax für ein Multi-Stage-Build zu finden, als einfach schnell apt-get install in einem Terminal einzutippen. Aber Professionalität in der IT misst sich nicht an der Geschwindigkeit des ersten Wurfs, sondern an der Wartbarkeit über drei Jahre hinweg.
Wenn Sie glauben, dass Sie mit manuellen Snapshots schneller ans Ziel kommen, lügen Sie sich selbst in die Tasche. Sie schieben die Arbeit nur auf — und zwar mit Zins und Zinseszinn. Jede Minute, die Sie heute beim Schreiben eines sauberen Dockerfiles sparen, werden Sie später doppelt und dreifach bei der Fehlersuche, beim Skalieren oder bei Sicherheits-Audits bezahlen. Es gibt in der Welt der Container keine Abkürzung, die nicht irgendwann im Sumpf endet. Wer erfolgreich sein will, muss die Langeweile der Automatisierung akzeptieren. Infrastruktur sollte so spannend sein wie fließendes Wasser: Es ist einfach da, es funktioniert immer gleich, und man muss nicht darüber nachdenken. Manuelle Images sind das Gegenteil — sie sind wie ein marodes Rohrsystem, bei dem man nie weiß, wo es als Nächstes leckt.
Die harte Wahrheit ist: Wenn Sie nicht in der Lage sind, Ihr Image jederzeit aus dem Quellcode neu zu bauen, besitzen Sie Ihre Infrastruktur nicht. Sie sind lediglich ein Gefangener des aktuellen Zustands Ihrer Festplatte. Und Festplatten sterben, Container werden gelöscht, und Wissen verblasst. Nur Code bleibt. Wer das ignoriert, spielt mit dem Geld und der Zeit seiner Auftraggeber. Nehmen Sie die Schmerzen des sauberen Engineerings jetzt in Kauf, damit Sie später ruhig schlafen können. Alles andere ist Amateur-Niveau und wird Sie früher oder später einholen. Kein "Schnellschuss" rechtfertigt das Risiko eines instabilen Systems, das niemand mehr versteht. Arbeiten Sie sauber, dokumentieren Sie im Code und lassen Sie die Finger von Abkürzungen, die keine sind.
