Terraform und OpenTofu vergleichen und migrieren

Terraform und OpenTofu vergleichen und migrieren

0:00 Durch das ganze Seminar zieht sich ein Satz: Terraform oder OpenTofu, beides funktioniert. In diesem Modul nehmen wir diese Gleichsetzung genauer unter die Lupe. Denn die beiden Werkzeuge haben einen gemeinsamen Ursprung, gehen aber seit der Abspaltung eigene Wege. Wir klären, was sie verbindet, was nur das eine kann, und wie man eine bestehende Umgebung von einem Werkzeug auf das andere umzieht, ohne dass etwas kaputtgeht.

0:25 Am Ende steht keine Empfehlung für eines der beiden, sondern etwas Wertvolleres: eine Entscheidung, die begründet, dokumentiert und umkehrbar ist. Unser Beispiel bleibt Saatplan, die interne Anwendung der Gärtnerei Lindenhof eG.

Terraform und OpenTofu vergleichen und migrieren

0:39 Der fünfte Tag schaut über den eigenen Code hinaus. Vier Tage lang haben wir Saatplan beschrieben, getestet, in Pipelines gebracht und betrieben. Jetzt geht es um zwei Fragen, die jedes Team irgendwann einholen: Bleiben wir beim Werkzeug, mit dem wir begonnen haben? Und wie helfen uns KI-Werkzeuge, ohne dass wir die Kontrolle abgeben?

0:58 Das Motto dieses Moduls steht auf der Folie, und es klingt bescheidener, als es ist: Eine Migration ist erst gelungen, wenn der Rückweg noch offen steht.

Gemeinsamkeiten und Unterschiede

1:08 Beginnen wir mit dem, was beide Werkzeuge teilen — und mit der Frage, warum ein gemeinsamer Ursprung noch lange keine Garantie für die Zukunft ist. Stellen Sie sich zwei Geschwister vor, die im selben Haus aufgewachsen sind und dann in verschiedene Städte ziehen. Sie sprechen dieselbe Sprache, aber nach ein paar Jahren hat jedes eigene Redewendungen. So ist es mit Terraform und OpenTofu.

1:31 OpenTofu will kompatibel bleiben, und tatsächlich laufen die meisten Konfigurationen ohne eine einzige Änderung. Doch jedes Release bringt Funktionen, die das andere Werkzeug nicht kennt. Mit Stand Ende September 2026 stehen Terraform 1.16 und OpenTofu 1.13 nebeneinander. Für die Praxis heißt das: Kompatibilität ist kein Zustand, den man einmal feststellt, sondern eine Eigenschaft, die man bei jedem Versionssprung neu prüfen muss.

1:58 Diese Tabelle ist eine Checkliste, und ihre Logik ist einfach: Ein Werkzeugwechsel betrifft nicht nur die Konfiguration, sondern alles, was um sie herum steht. Die ersten Zeilen schauen nach innen — Provider, Registry, Module, Backend. Bei Saatplan sieht das gut aus: Der Docker-Provider liegt in beiden Registries, und das pg-Backend gibt es in beiden Werkzeugen.

2:20 Die unteren Zeilen schauen nach außen, und dort lauern die Überraschungen. Läuft die Pipeline das neue Werkzeug überhaupt? Kennen Linter und Editor seine Eigenheiten? Und der Hinweis unten ist wichtig: Wer auf HCP Terraform oder Terraform Enterprise setzt, hat die Entscheidung im Grunde schon getroffen — dort läuft nur Terraform.

2:40 Der erste Stolperstein ist ein Denkfehler: Weil beide Werkzeuge denselben Ursprung haben, gilt die Kompatibilität als selbstverständlich. Belegen lässt sie sich aber nur mit einem Plan. Der zweite passiert im Review. Die Lock-Datei bekommt neue Provider-Adressen, das sieht nach Rauschen aus — ist aber genau die Änderung, die zählt.

2:59 Der dritte kommt von außen: Ein eingebundenes Registry-Modul nutzt eine neuere Sprachfunktion, und das fällt erst beim Wechsel auf. Und der vierte ist fast schon komisch, aber häufig: Die Testumgebung läuft längst mit tofu, nur die Pipeline ruft weiter terraform auf. Dann verwalten zwei Werkzeuge dieselbe Umgebung, und keiner hat es gemerkt.

Eigene Funktionen von OpenTofu

3:20 Wenn sich die Wege trennen, dann an konkreten Funktionen. Sehen wir uns an, was nur OpenTofu kann — und, fairerweise, auch das, was nur Terraform kann. Dieses Beispiel zeigt eine Funktion, die nur OpenTofu kennt: eine ganze Schar von Provider-Konfigurationen aus einer einzigen Map. Stellen Sie sich vor, die Gärtnerei betreibt Saatplan auf mehreren Docker-Hosts, jeder über eine eigene SSH-Adresse erreichbar.

3:45 Statt für jeden Host einen Provider-Block abzuschreiben, beschreibt man das Muster einmal, und for_each erzeugt daraus je Host eine Instanz. Zwei Dinge sind dabei Pflicht, und genau die stehen in den Beschriftungen: Der Provider braucht einen Alias, und die Ressource, die ihn nutzt, wählt ihre Instanz über den Schlüssel aus — mit einem eigenen for_each, nicht mit dem des Providers.

4:07 Elegant, aber eben nur in OpenTofu lauffähig. Hier geht es um ein Problem, das jeder kennt, der Module schreibt. Vor dem ersten apply ist eine ID noch unbekannt, und der Plan kann nicht sagen, ob sie später leer sein wird. Wer im aufrufenden Code darauf eine Bedingung baut, bekommt im Plan nur ein Achselzucken. OpenTofu 1.13 bringt dafür Hinweisfunktionen.

4:30 Mit ihnen sagt das Modul ausdrücklich: Dieser Wert wird nie null sein. Der Aufrufer kann sich dann schon im Plan darauf verlassen, nicht erst nach dem Anwenden. Unten stehen weitere Funktionen dieser Familie. Das Prinzip ist immer dasselbe: Wissen, das der Autor hat, wird dem Werkzeug mitgeteilt, damit der Plan aussagekräftiger wird.

4:51 Diese Tabelle ist keine Rangliste, sondern eine Landkarte. Oben stehen Funktionen, die OpenTofu mitbringt — von der Verschlüsselung von State und Plan bis zur Möglichkeit, einzelne Ressourcen beim Planen auszuschließen. Weiter unten zeigt sich, dass auch Terraform eigene Wege geht, etwa mit action-Blöcken und terraform query.

5:10 Wer also sagt, das eine Werkzeug könne einfach mehr, macht es sich zu leicht. Die letzte Zeile verdient einen besonderen Blick: Experimentelle Funktionen sind spannend, können sich aber mit jedem Release ändern. Für Saatplan bleiben sie deshalb ein Ausblick. Grundsätzlich gilt: Jede Zeile, die Sie nutzen, bindet Sie ein Stück fester an eines der beiden Werkzeuge.

Der Migrationsablauf

5:32 Genug verglichen. Jetzt ziehen wir um — und zwar so vorsichtig, dass wir jederzeit wieder zurück können. Ein Umzug beginnt bekanntlich nicht mit dem Möbelwagen, sondern mit den Kisten. Die Reihenfolge dieser Kette ist kein Zufall, sie folgt einem Prinzip: Erst beobachten, dann handeln. Am Anfang steht die Sicherung, und zwar von Code und State.

5:54 Dann initialisiert OpenTofu das Verzeichnis, und der entscheidende Moment ist der erste Plan. Er muss leer sein. Ein leerer Plan bedeutet: OpenTofu sieht die Welt genauso wie Terraform vorher. Erst dann folgt das Anwenden, und ganz am Ende eine kleine echte Änderung. Und der Hinweis unten ist die wichtigste Regel des ganzen Kapitels: Zeigt der Plan Änderungen, wird nicht angewendet, um weiterzukommen.

6:19 Dann wird untersucht, warum — oder zurückgerollt. So sieht der Umzug der Testumgebung in der Praxis aus, und er ist erstaunlich unspektakulär. Zuerst ein eigener Branch, damit die Änderung reviewbar bleibt. Dann zieht noch Terraform den aktuellen State aus dem pg-Backend und legt eine Kopie ab — das ist die Versicherung.

6:39 Danach übernimmt OpenTofu: Version prüfen, initialisieren, planen. Das Ziel steht als Kommentar daneben: keine Änderungen. Worauf es wirklich ankommt, steht unten. Beim Initialisieren lädt OpenTofu den Provider aus seiner eigenen Registry und ergänzt die Lock-Datei. Diese Änderung gehört in den Commit. Wer sie weglässt, bekommt beim nächsten Lauf womöglich einen anderen Provider.

7:04 Warum reicht der leere Plan nicht? Weil er nur eine Hälfte beweist. Er zeigt, dass OpenTofu den bestehenden State richtig lesen kann. Ob es die Umgebung künftig auch verwalten kann, zeigt erst eine Änderung, die wirklich angewendet wird. Das ist wie bei einem neuen Schlüssel: Dass er ins Schloss passt, ist schön. Ob er sich auch drehen lässt, merken Sie erst beim Aufschließen.

7:26 Für Saatplan nehmen wir dafür ein zusätzliches Label am Web-Container — folgenlos für den Betrieb und im Plan eindeutig zu erkennen. Danach läuft derselbe Kreislauf noch einmal, und ein zweiter leerer Plan schließt den Nachweis ab. Schwieriger wird es, wenn Konfigurationen voneinander abhängen, weil eine den Remote State der anderen liest. Dann stellt sich die Frage nach der Richtung.

7:50 Dieses Diagramm stellt beide Wege gegenüber, und die Logik dahinter ist eine Frage des Vertrauens. Dass OpenTofu einen Terraform-State liest, ist zuverlässig zugesichert. Der umgekehrte Weg ist es nicht. Deshalb migriert man von unten nach oben: zuerst die Konsumenten, zuletzt die Quelle. Ein angenehmer Nebeneffekt: Muss man zurück, betrifft das nur wenige Konfigurationen statt aller, die mitlesen.

8:14 Es ist dieselbe Vorsicht wie beim ganzen Kapitel — den Schaden im Fehlerfall klein halten. Die Fehler beim Umzug haben eines gemeinsam: Sie passieren unter Zeitdruck. Der erste: Gesichert wird nur der Code im Git, der State im pg-Backend nicht — dabei ist er das Einzige, was sich nicht neu schreiben lässt. Der zweite ist der gefährlichste.

8:36 Der erste Plan zeigt Änderungen, und jemand wendet sie an, damit es weitergeht. Damit ist der Nachweis verloren. Der dritte betrifft die Abhängigkeiten: Ein vergessener Konsument liest plötzlich einen State, den OpenTofu geschrieben hat. Und der vierte ist ein Dauerzustand, den man vermeiden sollte: Beide Werkzeuge laufen abwechselnd gegen dieselbe Umgebung. Eine Umgebung braucht genau ein zuständiges Werkzeug.

Eine Werkzeugentscheidung treffen

9:01 Technisch ist die Migration geschafft. Bleibt der Teil, den kein Befehl erledigt: die Entscheidung selbst — und die Frage, wie lange man sie noch rückgängig machen kann. Ein Werkzeugwechsel ist keine Tür, die einmal zufällt, sondern eine, die sich langsam schließt. Solange die Konfiguration nur Gemeinsames nutzt, führt der Weg zurück zu Terraform problemlos. Jede Funktion, die nur OpenTofu kennt, macht ihn aufwendiger.

9:27 Und eine Stelle ist endgültig: Ist der State verschlüsselt, kann Terraform ihn nicht mehr lesen. Das ist ausdrücklich keine Warnung vor diesen Funktionen, sie haben ihren Wert. Es ist ein Plädoyer dafür, sie bewusst einzusetzen. Wer sich den Rückweg offenhalten will, bündelt das Werkzeugeigene in Dateien mit der Endung tofu.

9:47 OpenTofu bevorzugt sie, Terraform liest sie gar nicht. Diese Tabelle erinnert daran, dass sich Werkzeuge nicht nur durch neue Funktionen verändern, sondern auch durch das, was wegfällt. Manches kündigt sich an: Erst gibt es Warnungen, eine Version später ist die Funktion verschwunden. Anderes ist tückischer, weil es leise geschieht — wenn eine Funktion plötzlich andere Bytes liefert, kann das dazu führen, dass Ressourcen ersetzt werden.

10:13 Und manches betrifft gar nicht den Code, sondern die Rechner, auf denen das Werkzeug läuft. Die Moral steht unten auf der Folie: Upgrade-Hinweise liest man, bevor die neue Version in der Pipeline landet. Danach liest man sie auch — aber dann unter Druck. Eine Werkzeugentscheidung, die nur in den Köpfen existiert, ist in einem Jahr eine Legende. Deshalb halten wir sie fest, und zwar in einer Reihenfolge, die sich bewährt hat.

10:38 Zuerst das Warum: Was war der Anlass, was soll erreicht werden? Dann der Beleg, also genau die Nachweise aus der Migration. Danach die Spielregeln: Welche werkzeugeigenen Funktionen sind erlaubt, und ab wann? Der vierte Schritt ist der ehrlichste, denn er beschreibt den Rückweg — und das Datum, an dem man ihn bewusst aufgibt. Zum Schluss ein Termin für die Überprüfung.

11:01 Das Ganze landet als Architecture Decision Record direkt neben dem Code im Repository.

Übung

11:06 Jetzt sind Sie dran. In der Übung wechselt die Testumgebung von Saatplan das Werkzeug — mit allem, was dazugehört, vom Backup bis zur schriftlichen Entscheidung. In dieser Übung geht es weniger ums Umschalten als ums Belegen. Das Lernziel ist eine Migration, die nachvollziehbar und umkehrbar bleibt — also eine, die auch jemand verstehen kann, der nicht dabei war.

11:28 Am Ende stehen drei Nachweise: ein Plan ohne Änderungen, ein Label, das tatsächlich am Container hängt, und eine Entscheidung, die im Repository liegt. Beachten Sie den Hinweis: Nur die Testumgebung wechselt, die Produktion bleibt bei Terraform. Das ist kein halber Schritt, sondern bewusst so gewählt. Eine gemischte Übergangsphase ist in echten Projekten der Normalfall, und genau dort zeigt sich, ob Grenzen sauber gezogen sind.

11:54 Die fünf Schritte folgen dem Kapitel über den Migrationsablauf, und der rote Faden heißt: Jeder Schritt sichert den nächsten ab. Das Backup des State steht am Anfang, weil ohne es kein Rückweg existiert. Das Initialisieren ist der Moment, in dem Sie die Lock-Datei bewusst ansehen, statt sie durchzuwinken. Der leere Plan ist die Bedingung für alles Weitere — fehlt er, wird nicht angewendet. Dann die kleine Änderung als Beweis, dass OpenTofu die Umgebung wirklich führt.

12:21 Und zum Schluss die Entscheidung samt Rückweg auf Papier. Nehmen Sie den letzten Schritt ernst: Er ist der Teil, den Ihre Kolleginnen in einem Jahr noch lesen. Die Stolpersteine dieser Übung kommen alle aus der Umgebung, nicht aus dem eigentlichen Befehl. Die Pipeline baut die Testumgebung weiter mit Terraform und überschreibt still den Nachweis, den Sie gerade erbracht haben.

12:43 Im Decision Record steht zwar ein Rückweg, aber nicht, wer ihn auslösen darf — und im Ernstfall diskutiert man dann erst über Zuständigkeiten. Die Lock-Datei bleibt uncommittet, und der nächste Lauf lädt einen anderen Provider. Und schließlich der Klassiker: Die Produktion wird aus Versehen mit tofu initialisiert. Im nächsten Modul bleibt die Frage nach der Kontrolle aktuell, nur mit einem neuen Helfer: KI-Werkzeugen, die HCL schreiben.