Das Deploy, das keins war

Die CI war grün. Nicht so ein halbherziges Grün – sondern ein selbstsicheres, dreistufiges Grün:

• Build & Transfer ✅
• Deploy Staging ✅
• Verify ✅

Wir schauten auf den Code von letzter Woche.

Kein flaky Test, der zufällig durchgekommen war. Kein Feature Flag, das wir vergessen hatten. Das Deployment lief durch. Die Scripts beendeten sich sauber. Die Container waren gesund. Wir hatten deployed – nur nicht das, was wir dachten.

Ich nenne das inzwischen ein Ghost Deploy: ein Deployment, das erfolgreich abschließt, ohne irgendetwas zu ersetzen.

---

Wie es sich versteckt hat

Der Kontext: die Cashback App, kurz vor dem Launch. Wir konsolidierten 27 Datenbank-Migrationsskripte zu einem einzigen – die letzte Chance, bevor echte Nutzerdaten das unmöglich machen. Routine-Hygiene. Irgendwann dabei schauten wir auf eine Seite, die anders aussehen sollte. Tat sie nicht. Und wir merkten: Staging läuft seit mehreren Releases auf altem Code. Die CI hatte es nie bemerkt.

Wir deployen ohne Registry. Build auf GitHub Actions, als Tarball speichern, per SCP auf EC2 übertragen, docker load, docker compose up -d. Klingt simpel. Das hatten wir dutzende Male gemacht. Das Problem: Jede Annahme, die wir darüber hatten, was „ein neues Image deployen” bedeutet, war falsch.

Es waren vier.

---

Die vier Dinge, die Docker nicht bedeutet

1. docker tag ersetzt kein Image.

Wenn du ein neues Image mit myapp:latest taggst, verschiebst du ein Label. Das neue Image bekommt den Namen. Das alte Image verliert ihn und wird anonym – kein Tag, sitzt im lokalen Image-Store, verbraucht Speicher, geht nirgendwo hin. Das nennt sich Dangling Image. Wir hatten 67 davon. Zusammen: 18,95 GB. Festplattenauslastung: 96 %.

2. docker load garantiert nicht, dass der alte Inhalt weg ist.

Wenn du einen Tarball per SCP auf einen Server überträgst und docker load ausführst, fügst du ein Image hinzu. Das neue Image materialisiert sich. Falls bereits ein myapp:latest-Tag existierte, wird er dem neuen Image zugewiesen. Das alte Image wird zum Dangling Image. Aber nichts stoppt. Kein Container ist betroffen. Nichts startet neu.

3. docker images zeigt das Build-Datum, nicht das Lade-Datum.

Wir haben immer wieder den Timestamp gecheckt. Das Image hatte das heutige Datum – sicher war das neue Image da. Aber der Timestamp wird beim Build-Zeitpunkt eingebrannt, auf dem CI-Rechner. Ein Image, das gestern gebaut und heute per SCP auf den Server übertragen wurde, zeigt gestern als Datum. Es sagt dir, wann es erstellt wurde – nicht, wann es ankam.

4. docker compose up -d interessiert sich nicht für Frische.

Das ist der eigentliche Auslöser des Ghost Deploys.

Compose stellt eine einzige Frage: Läuft bereits ein Container mit dieser Konfiguration? Wenn ja, tut es nichts. Es fragt nicht, ob der laufende Container dasselbe Image verwendet, auf das der Tag jetzt zeigt. Es vergleicht keine Image-IDs. Es ist zustandsbewusst – aber nicht frischebewusst.

Ein laufender Container hält eine Referenz auf eine Image-ID, nicht auf einen Tag-Namen. Als das neue Image geladen und der Tag neu zugewiesen wurde, hat sich die Referenz des Containers nicht aktualisiert. Compose schaute auf den Container, schaute auf die Compose-Datei, fand keinen Unterschied – und ließ alles laufen.

Einwandfrei. Mit dem Code von letzter Woche.

---

Wie die KI den Bug gebaut hat – und dann gefunden hat

Diese Geschichte hat eine Ebene, die es wert ist, benannt zu werden.

Die Deployment-Pipeline wurde nicht von einem DevOps-Engineer geschrieben, der jahrelang mit Docker-Image-Identität gerungen hat. Sie wurde von Cairn – meinem persistenten KI-Orchestrator – in einer einzigen vierstündigen Session gebaut. Den GitHub-Actions-Workflow, den SCP-Transfer, das docker load, das Compose-Deploy – Cairn hat das alles zusammengebaut, während er gleichzeitig drei Frontends refaktorierte und SQL-Migrationen gegen produktives RDS ausführte.

Er hat in dieser Session sogar einen Docker-Bug gefunden: Images wurden in CI mit :latest getaggt, aber die Compose-Datei erwartete :prod und :staging. Zwei CI-Iterationen, Fix eingespielt. Cairn identifizierte es aus dem GitHub-Actions-Fehlerlog – ohne manuelle Diagnose.

Aber es gibt einen Unterschied zwischen einem Tag-Mismatch – der laut in CI scheitert – und einem Container, der fröhlich auf einem veralteten Image läuft. Das zweite Problem schlägt nicht fehl. Es gelingt – still und leise.

Als das Ghost Deploy also auftauchte – mehrere Releases später, während der Pre-Launch-Wartung –, musste dieselbe KI, die die Pipeline gebaut hatte, herausfinden, was damit nicht stimmte.

Was in dieser Debug-Session passierte, ist es wert, genau beschrieben zu werden.

Cairn erkannte das Muster nicht aus dem Training. Es gab keinen „Das hab ich schon mal gesehen”-Reflex, auf den es hätte zurückgreifen können. Stattdessen tat es das, was ein guter DevOps-Engineer bei einem unbekannten Problem macht: Es hinterfragte, was jeder Schritt in der Pipeline tatsächlich garantiert – einschließlich der eigenen Pipeline.

• Erste Hypothese: Das Image wurde nicht korrekt geladen. Doch, war es.
• Zweite: Compose referenziert den falschen Image-Namen. Nein.
• Dritte: Was überprüft docker compose up -d eigentlich?

Das war der entscheidende Moment. Nicht existiert das Image. Nicht stimmt der Tag. Sondern: Welche Bedingung müsste sich ändern, damit Compose einen Container neu startet?

Die Konfiguration. Nicht der Image-Inhalt. Nicht die Image-ID. Die Konfiguration in der Compose-Datei.

Drei Hypothesen-Zyklen. Jeder davon eliminierte eine falsche Annahme, bevor die richtige Frage auftauchte. Nicht sofort – aber die Form davon war genau die Form, die ein menschlicher DevOps-Engineer bei einer unbekannten Falle zum ersten Mal durchläuft. Hypothese aufstellen. Testen. Eliminieren. Anpassen.

Der Unterschied: keine Frustration. Kein „wird schon stimmen”. Kein Aufhören, weil es spät wurde. Nur die nächste Hypothese.

---

Der Fix und das Race Condition

Der Fix: docker rmi myapp:latest vor docker load, kombiniert mit docker compose up -d --force-recreate. Force-recreate weist Compose an, Container unabhängig von Konfigurationsänderungen neu zu erstellen.

Aber es gibt ein Zeitfenster.

Das Muster, auf das wir uns geeinigt haben: release-bewusst vorgehen.

• Staging: rmi vor jedem Load. Staging darf kurz ausfallen.
• Produktion: rmi nur bei einem echten neuen Release – getrackt über den releases_created-Output von release-please. Zwischen Releases (CI-Reruns, Hotfixes derselben Version) wird das neue Image geladen, ohne das alte Tag zu entfernen, dann force-recreate. Das alte Image wird zum Dangling Image, aber der Container kann noch neu starten, falls beim Laden etwas schiefgeht.

Nach jedem Deploy: docker image prune -f. Dazu docker builder prune -af für den Build-Cache. Sonst passiert diese 67-Image-Akkumulation von 18,95 GB still und leise – bis das nächste Deploy fehlschlägt, weil die Festplatte voll ist, und niemand weiß warum.

---

Was „ohne Registry deployen” wirklich bedeutet

Wenn du in eine Registry pushst und ein Container-Orchestrator von dort pullt, wird Image-Identität für dich verwaltet. Tags, Digests, Content-Addressable Storage – die Infrastruktur trackt Frische. Du musst nicht darüber nachdenken, was docker tag auf Pointer-Ebene macht, weil die Registry Identität korrekt behandelt.

Wenn du einen Tarball per SCP überträgst und docker load ausführst, hast du diesen Job selbst übernommen. Ohne Tooling. Ohne Leitplanken. Jede Annahme, die du von „Images in einer Registry” geerbt hast, muss von Grund auf neu überprüft werden.

Das ist die Art Bug, der sich in kleinen Teams gut versteckt. Das Deployment-Script läuft. Die CI ist grün. Die Container sind gesund. Niemand überprüft, ob die laufenden Container tatsächlich den neuen Code ausführen – warum sollten sie? Die CI hat es doch geprüft.

Die CI hat immer die Wahrheit gesagt. Wir haben nur nicht gefragt, was sie tatsächlich prüft.