Wenn die Produktion abstürzt: Warum Image-Traceability und Rollback unverzichtbar sind

Eine neue Version Ihrer Anwendung geht live. Fünf Minuten später melden Nutzer Fehler. Die erste Frage im Team-Chat lautet: „Welche Version läuft gerade?“

Wenn niemand diese Frage schnell beantworten kann, verlieren Sie wertvolle Zeit. Minuten werden zu Stunden, während Leute Deployment-Logs durchforsten, Registry-Tags prüfen und herumfragen, was eigentlich deployed wurde. Bis Sie wissen, welches Image in der Produktion läuft, ist der Schaden bereits gewachsen.

Diese Situation ist häufiger, als die meisten Teams zugeben. Und sie passiert, weil zwei Dinge als optional behandelt wurden: genau zu wissen, was läuft, und eine zuverlässige Möglichkeit zu haben, zu etwas zurückzukehren, das funktioniert hat.

Traceability beginnt beim Build

Die Fähigkeit nachzuvollziehen, was in der Produktion läuft, beginnt in dem Moment, in dem Sie Ihr Container-Image bauen. Wie Sie dieses Image taggen, bestimmt, ob Sie es später eindeutig identifizieren können.

Tags wie v1.2.3 oder production sind für Menschen nützlich. Sie helfen Ihnen, Versionen auf einen Blick zu erkennen. Aber Tags sind für die Rückverfolgbarkeit nicht zuverlässig. Ein Tag ist nur ein Label, das auf ein Image zeigt, und dieses Label kann sich ändern. Das Image myapp:production könnte heute auf Version 1.2.3 und morgen auf Version 1.3.0 zeigen. Wenn Sie nur Tags verfolgen, wissen Sie nie genau, welche Version tatsächlich läuft.

Die zuverlässige Quelle der Wahrheit ist der Image-Digest. Ein Digest ist ein eindeutiger Hash, der aus dem Inhalt des Images generiert wird. Wenn zwei Images denselben Digest haben, sind sie identisch. Keine Mehrdeutigkeit, kein Risiko durch falsches Taggen, keine überschriebenen Labels. Wenn Sie genau wissen müssen, was läuft, brauchen Sie den Digest.

Den Digest aufzeichnen, nicht nur den Tag

In Ihrer Pipeline sollten Sie den Digest jedes Images erfassen, das jede Stufe durchläuft. Wenn ein Image gebaut wird, zeichnen Sie seinen Digest auf. Wenn es die Sicherheitsprüfung besteht, zeichnen Sie ihn erneut auf. Wenn es ins Staging und dann in die Produktion befördert wird, behalten Sie diesen Digest in Ihren Deployment-Aufzeichnungen.

Wo speichern Sie diese Informationen? Der praktischste Ort ist Ihr Deployment-Manifest. Ein Deployment-Manifest ist die Datei, die Ihrem System sagt, wie der Container ausgeführt werden soll. In Kubernetes ist das eine YAML-Datei. In Docker Compose ist es eine Compose-Datei. Jedes Mal, wenn Sie deployen, sollte das Manifest den exakten Digest referenzieren, nicht nur den Tag.

So sieht das in einem Kubernetes-Deployment aus:

Um den Digest in Ihrer Pipeline zu erfassen, verwenden Sie eine Sequenz wie diese:

# Image bauen und pushen
docker build -t myregistry.com/myapp:latest .
docker push myregistry.com/myapp:latest

# Digest aus der Registry erfassen
export DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' myregistry.com/myapp:latest)
echo "Deploye Image: $DIGEST"

# Digest im Deployment-Manifest verwenden
sed "s|image: myregistry.com/myapp:latest|image: $DIGEST|" deployment.yaml > deployment-digest.yaml
kubectl apply -f deployment-digest.yaml

Dadurch wird sichergestellt, dass Ihr Deployment immer den exakten Image-Inhalt referenziert, nicht einen veränderbaren Tag.

Das folgende Sequenzdiagramm zeigt, wo die Digest-Aufzeichnung und der Rollback in den Deployment-Lebenszyklus passen:

spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myregistry.com/myapp@sha256:a1b2c3d4e5f6...

Beachten Sie den @sha256:...-Teil. Das ist der Digest. Wenn Sie dieses Format verwenden, sagen Sie Kubernetes, dass es genau dieses Image ausführen soll, nicht das, worauf latest gerade zeigt.

Indem Sie den Digest in Ihrem Manifest aufzeichnen, erstellen Sie eine dauerhafte Aufzeichnung. Sie können zu jedem Zeitpunkt zurückblicken und genau wissen, welches Image lief. Sie können sehen, wann es deployed wurde, wer das Deployment ausgelöst hat und welche Änderungen damit kamen.

Ohne diese Aufzeichnung raten Sie nur. Und Raten während eines Incidents ist teuer.

Rollback: Das Sicherheitsnetz, das Sie bauen, bevor Sie es brauchen

Traceability gibt Ihnen die Antwort auf „Was läuft gerade?“ Rollback gibt Ihnen die Antwort auf „Wie kommen wir zu etwas zurück, das funktioniert hat?“

Rollback ist der Prozess, Ihre Anwendung auf eine frühere Version des Images zurückzusetzen, die als stabil bekannt war. Aber Sie können das mitten in einem Incident nicht effektiv tun. Sie müssen sich vor dem Deployment darauf vorbereiten.

Eine gute Rollback-Strategie beginnt mit drei Fragen:

1. Ist das vorherige Image noch in der Registry verfügbar?
2. Ist das vorherige Deployment-Manifest noch nutzbar?
3. Ist das vorherige Image mit der aktuellen Konfiguration kompatibel?

Viele Teams speichern ihre Deployment-Manifeste in Git. Jedes Mal, wenn sie deployen, committen sie das Manifest mit dem exakten Digest. Wenn etwas schiefgeht, können sie das Manifest auf einen früheren Commit zurücksetzen und neu deployen. Das ist einfach, auditierbar und funktioniert in verschiedenen Umgebungen.

In Kubernetes können Sie kubectl rollout undo verwenden, um zu einer früheren Revision zurückzukehren. Dieser Befehl funktioniert, weil Kubernetes einen Verlauf der Deployment-Revisionen speichert. Aber Sie müssen konfigurieren, wie viele Revisionen behalten werden sollen. Zu wenige, und Sie verlieren die Fähigkeit, weit genug zurückzurollen. Zu viele, und Sie verbrauchen Cluster-Speicher für Verlauf, den Sie vielleicht nie brauchen.

Wann Rollback funktioniert und wann nicht

Rollback ist schnell und effektiv bei Problemen auf Anwendungsebene. Wenn eine neue Version einen Fehler in der Geschäftslogik eingeführt hat oder ein Library-Update etwas kaputt gemacht hat, stellt das Zurücksetzen auf das vorherige Image den Dienst schnell wieder her.

Aber Rollback ist kein Allheilmittel. Wenn das Problem im Datenbankschema liegt, hilft das Zurücksetzen des Anwendungs-Images möglicherweise nicht. Die Datenbank könnte sich bereits in einem Zustand befinden, den der alte Anwendungscode nicht verarbeiten kann. Wenn das Problem in einer Konfiguration liegt, die getrennt vom Image geändert wurde, bleibt die fehlerhafte Konfiguration beim Zurücksetzen des Images allein bestehen.

Kennen Sie die Grenzen Ihres Rollback-Mechanismus. Testen Sie ihn regelmäßig. Stellen Sie sicher, dass Ihr Team weiß, wann er eingesetzt werden kann und wann eine andere Lösung gesucht werden muss.

Nach dem Rollback: Die Ursache beheben

Rollback stellt den Dienst wieder her. Es behebt nicht das Problem. Sobald Sie zurückgerollt haben und die Nutzer nicht mehr betroffen sind, beginnt die eigentliche Arbeit.

Das Image, das das Problem verursacht hat, muss repariert werden. Die Pipeline sollte mit der korrigierten Version weiterlaufen. Dieses neue Image durchläuft denselben Prozess: bauen, scannen, befördern, deployen. Der Rollback war ein Sicherheitsnetz, nicht das Ende der Reise.

Einige Teams machen den Fehler, Rollback als letzten Schritt zu betrachten. Sie rollen zurück, erklären den Incident für behoben und machen weiter. Derselbe Fehler taucht im nächsten Release wieder auf, weil niemand die Ursache untersucht hat. Lassen Sie das nicht passieren.

Praktische Checkliste

Gehen Sie vor Ihrem nächsten Produktions-Deployment diese Checkliste durch:

• Jedes Image in der Pipeline wird per Digest referenziert, nicht nur per Tag
• Deployment-Manifeste sind mit dem exakten Digest in der Versionskontrolle gespeichert
• Vorherige Images werden in der Registry für mindestens die letzten N Versionen aufbewahrt
• Die Rollback-Prozedur ist dokumentiert und in einer Nicht-Produktionsumgebung getestet
• Das Team kennt den Unterschied zwischen Problemen, die per Rollback behoben werden können, und solchen, die einen anderen Ansatz erfordern

Was das für Ihr Team bedeutet

Traceability und Rollback sind keine fortgeschrittenen Themen. Sie sind grundlegende operative Hygiene. Sie brauchen keine komplexe Plattform oder teure Werkzeuge, um sie zu implementieren. Sie brauchen Disziplin darin, wie Sie Images taggen, wie Sie Deployments aufzeichnen und wie Sie sich auf den Moment vorbereiten, in dem etwas schiefgeht.

Wenn die Produktion das nächste Mal abstürzt, wird die erste Frage immer noch sein: „Welche Version läuft?“ Mit Image-Traceability haben Sie die Antwort in Sekunden. Und mit einem getesteten Rollback-Mechanismus können Sie den Dienst in Minuten statt Stunden wiederherstellen.

Bauen Sie das Sicherheitsnetz, bevor Sie es brauchen. Ihr zukünftiges Ich, das um 2 Uhr morgens debuggt, wird es Ihnen danken.