Betrieb, Fehler und Upgrades

Betrieb, Fehler und Upgrades

0:00 Die schönste Pipeline hilft wenig, wenn niemand weiß, was zu tun ist, sobald ein Lauf mittendrin abbricht. Und das passiert, früher oder später, in jedem Team. Ein Host ist kurz nicht erreichbar, ein Container wird nicht rechtzeitig gesund, eine Datenbankverbindung reißt ab. Dieses Modul beschäftigt sich mit dem Alltag nach der Einführung: mit fehlgeschlagenen Läufen, mit dem geordneten Weg zurück in einen stabilen Zustand, mit Upgrades, regelmäßigen Prüfungen und der Frage, wer die Läufe überhaupt ausführt.

0:30 Der Leitgedanke ist beruhigend. Ein abgebrochener Lauf ist kein Notfall. Zum Notfall wird er erst, wenn jemand den State nicht liest, bevor er weitermacht.

Betrieb, Fehler und Upgrades

0:40 Im letzten Modul des vierten Tags wechseln wir die Perspektive. Bisher ging es darum, Änderungen sicher in die Welt zu bringen. Jetzt geht es darum, was passiert, wenn das nicht ganz klappt, und wie Infrastruktur über Monate gesund bleibt. Wir lesen Fehlerbilder, planen einen Wiederanlauf, führen ein Provider-Upgrade mit Nachweis durch, ordnen Ausführungsplattformen ein und üben am Ende an einem abgebrochenen Lauf der Saatplan-API.

Fehlgeschlagene Läufe

1:04 Beginnen wir mit dem Moment, in dem die Pipeline rot wird. Die wichtigste Erkenntnis vorweg: Terraform macht nichts rückgängig. Es hält fest, wie weit es gekommen ist — und das ist unser Ausgangspunkt. Viele erwarten von Infrastrukturwerkzeugen das Verhalten einer Datenbank-Transaktion: Entweder alles klappt, oder es wird sauber zurückgerollt. So funktioniert Terraform nicht.

1:28 Stellen Sie sich einen Umzug vor, bei dem der Lastwagen auf halbem Weg liegenbleibt. Die Kisten, die schon in der neuen Wohnung stehen, sind dort, und niemand trägt sie automatisch zurück. Terraform schreibt in den State, was bereits geschafft ist, und laut Dokumentation rollt es einen teilweise angewandten Lauf nicht zurück.

1:46 Ein halb erzeugtes Objekt wird in der Regel als tainted markiert, also als beschädigt. Das ist ehrlicher als ein scheinbares Zurückrollen, verlangt aber, dass Sie nach einem Abbruch genau hinschauen. Diese Tabelle ist eine Art Diagnosekarte für Saatplan. Jede Zeile beschreibt ein Fehlerbild, was dahinter tatsächlich passiert ist, und wo man als Erstes hinschauen sollte.

2:09 Die Unterschiede sind wichtig. Ein abgelaufener Healthcheck heißt, der Container existiert, wurde aber nicht rechtzeitig gesund. Eine abgerissene SSH-Verbindung hinterlässt einen Lauf, der teilweise im State steht. Fehlende Rechte am Docker-Socket sind ein Problem des Ziels, nicht des Codes. Ein belegter Lock bedeutet, dass ein anderer Lauf arbeitet. Und wenn das Backend nicht erreichbar war, liegt der State als Datei im Arbeitsordner.

2:35 Die Fußzeile fasst die Haltung zusammen: Erst lesen, dann handeln. Ein vorschneller zweiter Lauf verwischt genau die Spuren, die Sie brauchen. Diese Meldung gehört zu den wichtigsten, die Terraform ausgibt, und sie wird erstaunlich oft überlesen. Sinngemäß sagt sie: Ich konnte den State nicht ins Backend schreiben, deshalb liegt er als Datei errored punkt tfstate im Arbeitsverzeichnis.

2:59 Und sie warnt ausdrücklich davor, jetzt einfach noch einmal apply auszuführen, weil sonst ein abgespaltener State entsteht, der die Wiederherstellung erschwert. Der Ausweg steht gleich darunter: Die Datei mit terraform state push zurück ins Backend spielen. In einer Pipeline hat das eine praktische Konsequenz. Der Runner räumt sein Arbeitsverzeichnis nach dem Lauf weg. Wer die Datei nicht vorher als Artefakt sichert, verliert die einzige aktuelle Kopie des State.

3:26 Die vier Stolpersteine zeigen, wie leicht gut gemeinte Rettungsversuche den Schaden vergrößern. Das pg-Backend arbeitet mit Advisory Locks der Datenbank. Die verschwinden mit der Sitzung, und ein force-unlock gibt es dort nicht. Wer nach diesem Befehl sucht, sucht am falschen Ort. Den Lock einfach abzuschalten, um einen Lauf durchzudrücken, ist noch gefährlicher, denn damit können zwei Applies gleichzeitig am selben State arbeiten.

3:51 Den verworfenen Runner, der die einzige Kopie von errored punkt tfstate mitnimmt, kennen wir schon von der vorigen Folie. Und schließlich der Timeout, der als Fehlschlag gilt, obwohl der Container längst läuft. Hier zeigt nicht das Log, sondern der nächste Plan den wahren Stand.

Wiederanlauf und Wiederherstellung

4:08 Nach der Diagnose kommt die Frage, wie man wieder in einen stabilen Zustand findet. Die Antwort klingt paradox, ist aber der Kern dieses Kapitels: Zurück geht es immer vorwärts, nämlich mit einem neuen Plan. Der naheliegende Reflex nach einem missglückten Lauf ist ein Git-Revert. Der Vergleich zeigt, warum das bei Infrastruktur trügt. Ein Revert stellt den Code zurück, nicht die Welt.

4:31 Der nächste Plan aus dem alten Code kann Ressourcen ersetzen oder löschen, und Daten, die in einem Volume verloren gegangen sind, bringt kein Commit zurück. Auch ein Provider lässt sich nicht einfach herabstufen, wenn der State schon im neueren Format vorliegt. Der Wiederanlaufplan geht den umgekehrten Weg. Er beginnt beim tatsächlichen Zustand, sichert vor dem ersten Eingriff, beschreibt für jeden Schritt den erwarteten Plan und lässt die Versionen stehen, bis alles stabil ist.

4:58 Das ist langsamer, aber es ist vorhersehbar. Die fünf Schritte folgen einer einfachen Logik: erst sichern, dann verstehen, dann entscheiden, und erst danach ändern. Zuerst halten Sie alles an und sichern, was Sie später brauchen könnten, auch den State selbst. Dann lesen Sie mit einem Refresh-only-Plan, was tatsächlich existiert, ohne dabei etwas zu verändern. Im dritten Schritt bekommt jede Abweichung eine bewusste Entscheidung.

5:24 Der Wiederanlauf selbst ist dann kein Sonderweg, sondern ein ganz normaler Plan mit Review und Freigabe. Und am Ende steht ein Nachweis: ein leerer Plan, gesunde Container, vorhandene Daten. Die Fußzeile erinnert an eine feine Unterscheidung. Ein tainted-Objekt wird ersetzt, untaint verhindert das. Beides verdient eine Begründung.

5:44 Diese Tabelle ordnet den Schaden dem passenden Werkzeug zu, und sie zeigt eine Stufenleiter. Oben stehen die leichten Fälle, die Terraform mit eigenen Mitteln löst: ein halb erzeugtes Objekt wird ersetzt, ein vorhandenes, aber unbekanntes Objekt über einen import-Block übernommen. In der Mitte geht es um den State selbst, der zurückgespielt oder aus einer Sicherung wiederhergestellt wird. Ganz unten steht der schwerste Fall, ein verlorener Ziel-Host.

6:10 Dann hilft nur ein Neuaufbau plus die eigene Datensicherung. Besonders wichtig ist die Fußzeile. Das pg-Backend führt keine State-Historie. Wenn Sie keine Sicherung der Datenbank tfstate haben, gibt es auch keinen früheren Stand, auf den Sie zurückgreifen könnten.

Upgrades und regelmäßige Prüfung

6:26 Fehler lassen sich nicht ganz vermeiden, aber man kann ihre Wahrscheinlichkeit senken. Zwei Gewohnheiten helfen dabei: Versionen in kleinen Schritten aktualisieren und regelmäßig prüfen, ob die Welt noch zum Code passt. Ein Provider-Upgrade wirkt harmlos, weil sich im Code oft nur eine Versionsnummer ändert. Tatsächlich kann es das Verhalten jeder Ressource beeinflussen, die dieser Provider verwaltet. Deshalb läuft es hier wie eine echte Änderung.

6:53 Sie tragen die neue Version ein und lesen das Changelog. Dann aktualisiert init mit dem Schalter upgrade die Auswahl im Lock File, und providers lock ergänzt die Prüfsummen für alle Plattformen, auf denen Ihre Runner laufen. Der eigentliche Nachweis ist ein Plan gegen die Testumgebung, der leer ist oder jede Änderung erklärt. Erst danach folgt die Produktion in einem eigenen Lauf.

7:15 Und denken Sie daran: Die Kompatibilitätszusage von Terraform 1 gilt für die Sprache, nicht für Provider. Drift ist der Unterschied zwischen dem, was der Code beschreibt, und dem, was tatsächlich läuft. Er entsteht, wenn jemand am Wochenende schnell etwas von Hand korrigiert, und er bleibt unbemerkt, bis der nächste Plan überraschend groß ausfällt.

7:36 Dieser Workflow schaut deshalb regelmäßig nach, an Werktagen früh am Morgen. Er arbeitet mit einem Environment, das nur lesen darf, und erzeugt einen Plan mit dem Schalter detailed exitcode. Der Trick liegt im Rückgabewert: null heißt keine Änderung, eins heißt Fehler, zwei heißt Drift. Bei zwei öffnet der Lauf ein Issue für das zuständige Team.

7:56 So wird aus einer stillen Abweichung eine sichtbare Aufgabe mit klarem Empfänger. Technik allein trägt keinen Betrieb. Diese Folie beschreibt die organisatorische Seite, und die ist oft der Grund, warum ein Vorfall in einer Stunde statt in einem Tag gelöst ist. Jedes Root Module braucht ein zuständiges Team, festgehalten in den CODEOWNERS.

8:16 Wer was wann freigegeben hat, sollte ohne Detektivarbeit nachvollziehbar sein, und genau das leisten Pull Request, Environment-Freigabe und Plan-Artefakt zusammen. Ein Betriebshandbuch im Repository beantwortet die Fragen, die nachts um drei niemand improvisieren möchte. Und Upgrades kommen in festem Takt. Wer erst aktualisiert, wenn ein Provider-Fehler dazu zwingt, macht große Sprünge unter Zeitdruck. Das ist die ungünstigste Kombination, die es gibt.

Ausführungsplattformen

8:44 Bisher liefen alle Läufe in unserer eigenen Pipeline. Es gibt aber Plattformen, die genau diese Arbeit als Dienst anbieten. Zeit, beide Wege nebeneinanderzulegen — und zu fragen, wer eigentlich OpenTofu ausführt. Diese Tabelle ist im Grunde eine Übersetzungshilfe. Für fast alles, was wir in der eigenen Pipeline gebaut haben, gibt es in HCP Terraform oder Terraform Enterprise ein fertiges Gegenstück.

9:10 Die Warteschlange je Workspace ersetzt unsere concurrency samt State-Lock, Teams und Rechte ersetzen Environments und Branch-Schutz, Health Assessments ersetzen den geplanten Drift-Lauf. Der Unterschied liegt also weniger im Was als im Wer: Betreiben Sie es selbst, oder lassen Sie es betreiben? Achten Sie auf die letzte Zeile.

9:29 Interne Ziele wie unsere Docker-Hosts erreicht ein Cloud-Dienst nur über eigene Agents. Und laut Fußzeile führen beide Produkte Terraform aus, nicht OpenTofu. Wer OpenTofu einsetzt, braucht deshalb einen anderen Blick auf den Markt. Mehrere Anbieter von Ausführungsplattformen, darunter Spacelift, env0, Scalr und Harness, entwickeln OpenTofu selbst mit.

9:50 Dazu kommt Atlantis als quelloffene Lösung, bei der sich je Projekt einstellen lässt, welches Werkzeug ausgeführt wird. Die nüchterne Einschätzung lautet allerdings: Jede dieser Plattformen bringt eigene Vorstellungen von Policies, Freigaben und Rechten mit. Das muss man im Einzelfall prüfen, nicht voraussetzen. Für die Gärtnerei Lindenhof ist das Fazit pragmatisch.

10:12 Die eigene Pipeline bleibt der kleinste gemeinsame Nenner, weil sie mit beiden Werkzeugen funktioniert und keine weitere Abhängigkeit einführt. Die Stolpersteine dieses Kapitels haben alle mit Reihenfolge zu tun. Der erste ist ganz handfest: Ein Worker in der Cloud sieht keine Docker-Hosts im internen Netz. Ohne Agent findet dort schlicht kein Lauf statt. Der zweite ist strategisch.

10:35 Wer eine Plattform auswählt, bevor geklärt ist, wie die States geschnitten werden und wer was freigibt, lässt sich die eigene Organisation vom Werkzeug diktieren. Der dritte wird gern unterschätzt: Ein Plattformwechsel bedeutet einen Umzug des State, und der braucht einen eigenen Plan. Der vierte ist ein Klassiker. Drift-Erkennung ist schnell eingeschaltet, aber ohne zuständiges Team werden ihre Meldungen zu Hintergrundrauschen, das irgendwann niemand mehr liest.

Übung

11:03 Jetzt wird es praktisch. Ein Lauf ist abgebrochen, kurz nachdem der neue API-Container angelegt wurde. Die Frage lautet: Was ist jetzt wirklich da, und wie kommen wir begründet zurück in einen stabilen Zustand? In dieser Übung trainieren Sie eine Fähigkeit, die man im Ernstfall nicht erst lernen möchte: den Zustand nach einem abgebrochenen Apply aus State, Plan und Zielsystem zu rekonstruieren und daraus einen begründeten Wiederanlauf abzuleiten.

11:30 Die Ausgangslage ist nachgestellt. Der Container saatplan-api läuft, aber der Lauf endete mit der Meldung, dass der Container nicht rechtzeitig gesund wurde. Erfolgreich sind Sie, wenn Ihr Plan für jede betroffene Ressource drei Dinge nennt: den Ist-Zustand, die Maßnahme und den erwarteten Plan. Und wenn der ausgeführte Wiederanlauf am Ende mit einem leeren Plan abschließt. Erst dann ist die Infrastruktur wieder dort, wo der Code sie beschreibt.

11:56 Die Schritte wiederholen im Kleinen, was wir im ganzen Modul besprochen haben. Erst lesen Sie das Log und sichern den State. Dann stellen Sie gegenüber, was der State zu kennen glaubt und was auf dem Docker-Host tatsächlich läuft. Mit einem Refresh-only-Plan und einem normalen Plan belegen Sie die Abweichung, statt sie zu vermuten.

12:15 Danach fällt die eigentliche Entscheidung: ersetzen, untaint oder die Konfiguration korrigieren, jeweils mit Begründung. Und zum Schluss geht der Wiederanlauf den gewohnten Weg über Pull Request und Freigabe. Wer mag, nimmt den Bonus aus der Fußzeile mit und spürt einen hängenden Lock in der Datenbank auf. Damit endet der vierte Tag.

12:34 Das nächste Modul stellt Terraform und OpenTofu nebeneinander und widmet sich der Migration.