Infrastructure as Code einordnen

Infrastructure as Code einordnen

0:00 Willkommen zum Seminar Terraform und OpenTofu in der Praxis. Vor uns liegen fünf Tage und vierzehn Module, und sie folgen einem klaren Weg. Am ersten Tag legen wir das Fundament: Begriffe, Kommandozeile, die Sprache HCL. Am zweiten modellieren wir Ressourcen, bauen Module und kümmern uns um den State. Der dritte Tag gehört Geheimnissen, Umgebungen und der Übernahme von Bestand. Am vierten geht es um Tests, Pipelines und den laufenden Betrieb.

0:27 Und am fünften Tag vergleichen wir die Werkzeuge, sprechen über Migration und über KI-gestützte Infrastruktur. Dieses erste Modul klärt, was Infrastructure as Code eigentlich verspricht, wie die Bausteine zusammenspielen und warum Sie heute zwischen zwei Werkzeugen wählen müssen.

Infrastructure as Code einordnen

0:44 Der erste Tag schafft das Handwerkszeug. In diesem Modul geht es noch nicht ums Tippen, sondern ums Verstehen: Was heißt es, Infrastruktur zu beschreiben statt sie Schritt für Schritt aufzubauen? Danach folgen die Kommandozeile mit ihrem Kernzyklus und die Sprache, in der Konfigurationen geschrieben werden. Am Ende des Tages steht unser Beispiel Saatplan zum ersten Mal als Code da.

Gewünschter und tatsächlicher Zustand

1:06 Beginnen wir mit der Idee, die alles Weitere trägt. Sie ist einfach zu formulieren und hat erstaunlich weitreichende Folgen: Wir sagen dem Werkzeug nicht, was es tun soll, sondern was am Ende da sein soll. Stellen Sie sich zwei Arten vor, einen Tisch zu decken. Die eine ist eine Anleitung: Teller holen, Besteck daneben, Gläser rechts.

1:27 Die andere ist ein Foto des fertig gedeckten Tisches. Mit dem Foto in der Hand sieht jeder sofort, was fehlt, was zu viel ist und was verrückt wurde. Genau so arbeitet eine Terraform-Konfiguration: Sie ist das Foto. Vor jeder Änderung vergleicht das Werkzeug drei Dinge — Ihre Beschreibung, den zuletzt bekannten Zustand und das, was tatsächlich existiert.

1:49 Daraus entsteht ein Plan, den Sie lesen können, bevor irgendetwas passiert. Das ist der eigentliche Gewinn: Änderungen werden prüfbar, bevor sie wirken. Diese vier Zeichen werden Sie das ganze Seminar über begleiten, und es lohnt sich, sie früh zu verinnerlichen. Erstellen und Entfernen sind selbsterklärend. Spannend ist der Unterschied zwischen Ändern und Ersetzen. Ändern heißt: Das Objekt bleibt, nur eine Eigenschaft wird angepasst.

2:16 Ersetzen heißt: Das alte Objekt verschwindet, ein neues entsteht. Bei einem Container ist das meist harmlos, bei einer Datenbank kann es Daten kosten. Und Sie entscheiden das nicht selbst — der Provider legt für jedes Argument fest, was eine Änderung auslöst. Der Plan verrät es Ihnen mit dem Hinweis forces replacement. Den sollten Sie nie überlesen.

Konfiguration, Provider, State und Zielsystem

2:39 Wer den Plan verstehen will, muss wissen, woher er kommt. Dahinter stehen vier Bausteine, die sauber getrennte Aufgaben haben — und die meisten Missverständnisse entstehen, wenn man zwei davon verwechselt. Lesen Sie diese Schichten von oben nach unten wie eine Übersetzungskette. Oben steht, was Sie schreiben: Dateien im Repository saatplan-infra, versioniert in Git wie jeder andere Code.

3:02 Darunter das Werkzeug selbst, Terraform oder OpenTofu, das Konfiguration und State liest und den Plan berechnet. Bemerkenswert ist die dritte Schicht: Das Werkzeug kennt kein einziges Zielsystem selbst. Das übernimmt der Provider, ein Dolmetscher, der den Plan in API-Aufrufe übersetzt. Ganz unten das Zielsystem, in diesem Seminar der Docker-Daemon.

3:24 Diese Trennung erklärt, warum dieselbe Sprache für Docker, Cloud und vieles mehr funktioniert — nur der Dolmetscher wechselt. Das ist die kleinste sinnvolle Konfiguration: ein Provider und eine Ressource. Der Provider-Block sagt, mit welchem Docker-Daemon gesprochen wird. Der Ressourcen-Block beschreibt ein Netzwerk. Achten Sie auf die doppelte Namensgebung, denn sie verwirrt anfangs fast jeden. Der Typ docker_network kommt vom Provider.

3:52 Der Name saatplan ist nur für den Code gedacht, damit Sie die Ressource an anderer Stelle referenzieren können. Und saatplan-netz ist der Name, unter dem das Netzwerk tatsächlich in Docker erscheint. Drei Namen, drei Welten. Wer das einmal auseinanderhält, liest jede Konfiguration deutlich leichter. Der State ist der unscheinbarste der vier Bausteine und gleichzeitig der wichtigste.

4:15 Denken Sie an das Inventarbuch eines Lagers: Es verbindet jeden Eintrag auf dem Papier mit genau einem Regal. Ohne dieses Buch wüsste niemand, ob das Netzwerk in Docker eines ist, das wir selbst angelegt haben, oder ein fremdes. Der State merkt sich außerdem Abhängigkeiten, damit beim Abbau die Reihenfolge stimmt, und er hält zuletzt gelesene Werte bereit.

4:36 Geht er verloren, hält das Werkzeug alles Vorhandene für unbekannt und will es neu anlegen. Deshalb bekommt der State ab Modul sechs ein eigenes Zuhause.

Werkzeuge abgrenzen

4:46 Terraform ist nicht das einzige Werkzeug, das sich um Infrastruktur kümmert. Bevor wir losschreiben, klären wir, wer wofür zuständig ist — denn zwei Werkzeuge, die dasselbe Objekt verwalten, streiten sich irgendwann. Die Tabelle wirkt wie eine Werkzeugsammlung, aber das Prinzip dahinter ist ein einziges: der Lebenszyklus.

5:06 Was gemeinsam entsteht und gemeinsam wieder verschwindet, gehört zu einem Werkzeug. Netzwerk, Volume und Container von Saatplan entstehen und vergehen zusammen, also verwaltet sie Terraform oder OpenTofu. Was in einem Image steckt, entscheidet der Image-Build, nicht die Infrastruktur. Und Ansible pflegt Systeme, die schon da sind.

5:26 Sehen Sie sich die rechte Spalte an: Vieles ist bei Saatplan gar nicht im Einsatz. Auch das ist eine Erkenntnis — nicht jedes Werkzeug muss in jedes Projekt. Drei Begriffe, die oft in einem Atemzug fallen, aber verschiedene Ebenen beschreiben. Infrastructure as Code ist das Handwerk — so wie Mauern ein Handwerk ist. Platform Engineering ist das Bauunternehmen, das aus diesem Handwerk ein Angebot macht, das andere Teams nutzen können, ohne jeden Stein zu kennen.

5:56 GitOps wiederum ist eine Arbeitsweise: Ein Agent im Zielsystem zieht ständig nach, was im Repository steht. Terraform und OpenTofu ticken anders. Sie arbeiten in Läufen — planen, freigeben, ausführen, und dann ist Ruhe. Dieser Unterschied ist keine Schwäche, er gibt Ihnen einen klaren Moment der Kontrolle.

Terraform und OpenTofu als Auswahlentscheidung

6:15 Jetzt zu der Frage, die viele Teams gerade beschäftigt. Es gibt zwei Werkzeuge mit gemeinsamer Herkunft und fast gleicher Sprache. Welches nimmt man — und wie sehr bindet man sich damit? Diese Tabelle erzählt eine Trennungsgeschichte. Bis 2023 gab es nur Terraform, offen lizenziert. Dann wechselte HashiCorp im August 2023 die Lizenz, und aus der letzten offenen Linie entstand OpenTofu als Fork, heute getragen von der Linux Foundation.

6:44 Seitdem gehen beide eigene Wege: eigenes Kommando, eigene Registry, eigene Versionszählung. Terraform gehört inzwischen zu IBM. Wichtig für die Einordnung: Die Versionsnummern lassen sich nicht direkt vergleichen. Eine höhere Zahl heißt nicht, dass ein Werkzeug weiter ist. Beide sind lebendig, beide erscheinen regelmäßig neu. Die Entscheidung zwischen ihnen ist deshalb keine zwischen alt und neu.

7:10 Die gemeinsame Basis ist groß, aber an den Rändern wird es interessant. Terraform setzt auf die Plattform des Herstellers: Stacks und HCP Terraform, Support und Betrieb aus einer Hand. OpenTofu hat dagegen Funktionen ins Werkzeug selbst gebracht, die Terraform so nicht kennt — etwa die Verschlüsselung von State und Plänen oder das gezielte Auslassen einzelner Ressourcen.

7:32 Ein Detail mit Folgen: OpenTofu liest zusätzlich Dateien mit eigener Endung, die Vorrang haben. Damit lässt sich eine Konfiguration für beide Werkzeuge pflegen. Behalten Sie dieses Bild im Kopf, wir kommen am fünften Tag beim Vergleich und bei der Migration ausführlich darauf zurück. Wie entscheidet man nun? Nicht nach Sympathie, sondern nach vier nüchternen Fragen. Die Lizenz: Für die interne Nutzung erlauben beide alles.

7:57 Die Business Source License greift erst, wenn Sie selbst ein konkurrierendes Angebot auf Terraform-Basis bauen wollen. Der Support: Brauchen Sie einen Herstellervertrag, oder genügen Community und kommerzielle Anbieter? Die Funktionen: Heute ist die Schnittmenge groß, aber neue Funktionen entstehen getrennt. Und die Plattform: Wer HCP Terraform nutzt oder plant, hat die Werkzeugfrage meist schon mitbeantwortet.

8:22 Mein Rat: Treffen Sie die Entscheidung bewusst und schreiben Sie die Begründung auf.

Docker als Zielplattform dieses Seminars

8:28 Bleibt die Frage, wogegen wir eigentlich üben. Ein Cloud-Konto bringt Kosten, Wartezeiten und Zugangsfragen mit. Wir wählen einen Weg, der echte Ressourcen liefert und trotzdem auf jedem Rechner läuft. Unser Zielsystem ist Docker. Der Provider kreuzwerker/docker spricht die Docker-API an und behandelt Images, Container, Netzwerke und Volumes als Ressourcen — genau so, wie ein Cloud-Provider virtuelle Maschinen und Datenbanken behandelt.

8:55 Das ist kein Spielzeug, sondern ein vollwertiges Zielsystem mit echtem Zustand, echten Abhängigkeiten und echten Fehlern. Der Provider kann gegen den lokalen Daemon arbeiten oder per SSH gegen einen entfernten Docker-Host. So bauen wir ohne Cloud-Konto und ohne Rechnung alles, was ein Infrastruktur-Team im Alltag braucht: Netze, Speicher, Dienste, die voneinander abhängen.

9:17 Und was wir hier lernen, ist auf jeden anderen Provider übertragbar. Hier sehen Sie den ersten Container unseres Beispiels: die Weboberfläche von Saatplan. Saatplan ist die interne Anwendung der Gärtnerei Lindenhof eG, mit Web, API und einer PostgreSQL-Datenbank. Achten Sie auf zwei Dinge. Erstens: Der Container erhält sein Image nicht als Text, sondern als Verweis auf eine eigene Image-Ressource.

9:42 Daraus erkennt das Werkzeug von selbst, dass erst das Image da sein muss und dann der Container — eine Abhängigkeit, die Sie nirgends ausdrücklich hinschreiben. Zweitens: Der Port-Block verbindet einen internen mit einem externen Port. Genau solche Ports werden später in der Übung zur Frage, was nach außen gehört. Ein berechtigter Einwand: Docker ist nicht die Cloud. Diese Gegenüberstellung zeigt, was trotzdem gilt.

10:08 Links steht alles, was Sie hier lernen und eins zu eins mitnehmen: Pläne lesen, State führen, Abhängigkeiten, Module, Variablen, Tests und Pipelines. Das ist der eigentliche Kern des Seminars. Rechts steht, was in der Cloud hinzukommt: Identitäten und Rollen, Regionen, Kosten und Quoten, Netze als eigene Objekte. Das sind keine neuen Prinzipien, sondern mehr Ressourcentypen und mehr Vorsicht.

10:32 Wer das Handwerk an Docker beherrscht, muss in der Cloud vor allem den neuen Provider kennenlernen, nicht ein neues Denken.

Übung

10:40 Zeit, das Gelernte anzuwenden. Bevor wir Saatplan als Code beschreiben, nehmen wir die Anwendung auseinander — denn beschreiben lässt sich nur, was man vorher sauber zerlegt hat. Die Gärtnerei Lindenhof eG plant mit Saatplan Aussaat, Umtopfen und Auslieferung für ihre Betriebe und den Versandhandel. Bisher läuft die Anwendung in Containern, die jemand von Hand gestartet hat. In dieser Übung schreiben Sie noch keine Zeile Code.

11:07 Sie üben etwas, das jedem Code vorausgeht: eine bestehende Anwendung in Teile zerlegen und jedem Teil einen Verwaltungsweg zuweisen. Gehört etwas zu Terraform oder OpenTofu, gehört es ins Image, oder wird es bewusst gar nicht verwaltet? Fertig sind Sie, wenn jeder Bestandteil genau eine Antwort hat — und eine Begründung dazu.

11:26 Der Weg führt vom Konkreten zum Grundsätzlichen. Zuerst die Bestandsaufnahme: Was läuft heute, welche Netze und Volumes gibt es? Dann der genauere Blick auf Web, API und Datenbank — Image, Ports, Daten, Konfiguration. Erst danach kommt die eigentliche Entscheidung je Teil, und sie wird mit dem Lebenszyklus-Prinzip aus dem dritten Kapitel leicht.

11:47 Der vierte Schritt ist eine kleine Sicherheitsübung: Welche Ports gehören wirklich nach außen? Die Datenbank jedenfalls nicht. Und zum Schluss die offenen Fragen sammeln, statt sie zu verdrängen. Diese Liste ist der Bauplan für alles, was in den nächsten Modulen entsteht. Die Fallen dieser Übung haben eines gemeinsam: Man verwaltet zu viel.

12:08 Die Datenbankinhalte gehören nicht in die Zuordnung — Terraform verwaltet das Volume, also den Behälter, nicht die Daten darin. Konfigurationsdateien der API wandern gern ins IaC, obwohl sie mit dem Image leben und sterben. Der Docker-Daemon selbst ist Voraussetzung, nicht Ergebnis. Und Ports werden aus reiner Gewohnheit veröffentlicht, auch der der Datenbank. Wer hier sauber trennt, spart sich später viel Ärger.

12:34 Im nächsten Modul geht es an die Kommandozeile: Wir legen das Repository an und bringen Saatplan zum ersten Mal ans Laufen.