Terraform lernen: Infrastruktur als Code

Ein paar Klicks im Azure- oder AWS-Portal, schnell eine VM hier, ein Storage-Account dort, und schon läuft der Prototyp. Drei Wochen später weiß niemand mehr, was wie eingerichtet wurde, welche Ressource zu welchem Projekt gehört und warum die Kosten explodieren. Genau hier wird Terraform spannend: Du beschreibst deine Infrastruktur als Code und machst sie damit nachvollziehbar, wiederholbar und versionierbar.

Was „Infrastruktur als Code“ in der Praxis bedeutet

Infrastruktur als Code (IaC) heißt: Du beschreibst deine Infrastruktur in Dateien, nicht per Handklick im Portal. Das ist mehr als nur „Skripten“:

• Der gewünschte Zielzustand ist definiert: Welche Ressourcen sollen existieren, mit welchen Eigenschaften.
• Das System errechnet selbst, welche Änderungen nötig sind, um von Ist zu Soll zu kommen.
• Alles landet im Git-Repository, inklusive Review, Branches und Historie.
• Du kannst dieselbe Definition mehrfach ausrollen, zum Beispiel für Test, Staging und Produktion.

Im Vergleich zur klickbasierten Cloud-Verwaltung bringt dir Terraform vor allem:

• Nachvollziehbarkeit: Du siehst im Code, was eingerichtet ist. Kein Ratespiel im Portal.
• Reproduzierbarkeit: Eine Umgebung lässt sich immer wieder identisch anlegen, auch nach einem Crash.
• Teamfähigkeit: Änderungen werden im Code diskutiert, nicht mündlich nebenbei im Büro.
• Automatisierung: Terraform-Skripte lassen sich in CI/CD-Pipelines integrieren.

Die Portale von Azure, AWS oder Google Cloud sind gut zum Erkunden und für Einzelaktionen. Für ernsthafte, längerlebige Setups werden sie schnell zur Fehlerquelle. Terraform ist hier dein Werkzeug, um Ordnung in das Cloud-Chaos zu bringen.

Terraform-Provider: Wie Terraform mit deiner Cloud spricht

Terraform selbst kennt deine Cloud nicht. Es nutzt sogenannte Provider, um mit APIs zu sprechen, zum Beispiel:

• „hashicorp/azurerm“ für Microsoft Azure
• „hashicorp/aws“ für Amazon Web Services
• „hashicorp/google“ für Google Cloud Platform
• „hashicorp/kubernetes“ für Kubernetes-Cluster

Ein Provider übernimmt dabei:

• Authentifizierung: Wie Terraform sich bei der Plattform anmeldet.
• Ressourcen-Typen: Welche Ressource du anlegen kannst, zum Beispiel „azurerm_resource_group“.
• Lebenszyklus: Erstellen, Ändern, Löschen von Ressourcen.

Ein minimaler Provider-Block für Azure sieht zum Beispiel so aus:

terraform {
 required_providers {
 azurerm = {
 source = "hashicorp/azurerm"
 version = "~> 4.0"
 }
 }
}

provider "azurerm" {
 features {}
}

Wichtige Punkte im Umgang mit Providern:

• Versionen pinnen: Lege eine Versionsbeschränkung fest, damit ein Provider-Update deine Konfiguration nicht unbemerkt bricht.
• Authentifizierung sauber lösen: Nutze Service Principals, Managed Identities oder Profile, keine hart codierten Zugangsdaten.
• Provider pro Workspace oder Umgebung konfigurieren: Zum Beispiel unterschiedliche Subscriptions oder Accounts.

Terraform unterstützt auch mehrere Provider gleichzeitig. Du kannst also in einer Konfiguration Ressourcen in Azure, GitHub und Cloudflare verwalten.

Terraform-State: Die Wahrheit über deine Infrastruktur

Terraform braucht eine Informationsquelle, um zu wissen, was bereits existiert. Diese Quelle ist der sogenannte State. Standardmäßig ist das eine Datei „terraform.tfstate“ im Projektverzeichnis.

Der State enthält:

• Welche Ressourcen Terraform angelegt hat.
• Welche Attribute diese Ressourcen aktuell haben (soweit bekannt).
• Zuordnung zwischen Konfiguration und realen Objekten in der Cloud.

Ohne State könnte Terraform nicht berechnen, was sich ändern muss. In der Praxis musst du beim State besonders auf drei Dinge achten:

1. Speicherort

Für Experimente auf dem eigenen Rechner reicht die lokale „terraform.tfstate“. Für Teams ist das gefährlich:

• Konflikte, wenn mehrere Personen parallel arbeiten.
• Kein zentrales, verlässliches Bild der Infrastruktur.
• Risiko von Datenverlust, wenn jemand den Ordner löscht.

Im Team solltest du den State in einem Remote Backend speichern, zum Beispiel:

• Azure Storage Account
• AWS S3 Bucket
• Terraform Cloud

So kann Terraform auch ein Locking durchführen, damit nicht zwei „terraform apply“-Läufe gleichzeitig am selben State schrauben.

2. Sicherheit

Im State können sensible Daten stehen, etwa Kennwörter oder Verbindungsstrings. Daher:

• State-Datei nicht per Mail verschicken oder irgendwo in Ticketsysteme kopieren.
• State nicht unverschlüsselt in öffentlich erreichbaren Buckets ablegen.
• State-Datei niemals in Git einchecken.

3. Lifecycle des States

Wenn du Ressourcen außerhalb von Terraform änderst oder löschst, weiß der State nichts davon. Typische Folgen:

• Terraform will gelöschte Ressourcen wieder anlegen.
• Terraform will Attribute zurückdrehen, die du manuell geändert hast.

Daher gilt: Wenn Terraform eine Ressource verwaltet, ändere sie nur über Terraform, nicht im Portal. Falls du doch im Portal eingreifen musst, plane ein, den State sorgfältig mit der Realität zu synchronisieren, zum Beispiel mit „terraform import“.

Plan und Apply: Trockenübung vor der echten Änderung

Der typische Terraform-Workflow dreht sich um zwei Befehle:

• „terraform plan“: Terraform liest die Konfiguration und den State und berechnet, was sich ändern müsste. Du siehst eine Liste von geplanten Aktionen: Ressourcen, die erstellt, geändert oder gelöscht werden.
• „terraform apply“: Terraform wendet die geplanten Änderungen an. Standardmäßig wird vorher noch einmal ein Plan berechnet und zur Bestätigung angezeigt.

Das Plan/Apply-Prinzip hat mehrere Vorteile gegenüber klickbasierten Änderungen in der Cloud-Konsole:

• Transparenz: Du siehst, was passieren wird, bevor es passiert.
• Sicherheit: Im Team kann jemand anderes den Plan prüfen, zum Beispiel im Rahmen eines Pull Requests.
• Reproduzierbarkeit: Der Plan hängt nur von Code und State ab, nicht davon, wer welche Klicks gemacht hat.

Ein sinnvoller Workflow im Alltag:

1. Konfiguration ändern, zum Beispiel eine neue Ressource ergänzen.
2. „terraform fmt“ ausführen, damit der Code formatiert ist.
3. „terraform validate“ laufen lassen, um Syntaxfehler früh zu erkennen.
4. „terraform plan“ prüfen, ob die Änderungen wie erwartet sind.
5. Erst danach „terraform apply“.

In CI/CD-Pipelines wird häufig bei jedem Commit automatisch ein „terraform plan“ erstellt und als Artefakt oder Kommentar bereitgestellt. Menschen entscheiden dann bewusst, wann ein „apply“ ausgelöst wird.

Module: Terraform-Strukturen wiederverwendbar machen

Ohne Struktur landet schnell alles in wenigen, riesigen „main.tf“-Dateien. Das macht Projekte unübersichtlich und fehleranfällig. Terraform-Module sind der Weg, Ordnung und Wiederverwendbarkeit zu schaffen.

Ein Modul ist im Kern:

• Ein Ordner mit Terraform-Dateien.
• Eingangsvariablen („variables.tf“).
• Optional Ausgaben („outputs.tf“).

Du kannst Module auf zwei Arten nutzen:

1. Lokale Module

Struktur in deinem Projekt, zum Beispiel:

• „modules/network“
• „modules/app_service“
• „modules/monitoring“

Ein Beispielaufruf:

module "network" {
 source = "./modules/network"
 resource_group_name = var.resource_group_name
 location = var.location
}

2. Externe Module

Zum Beispiel aus einem Git-Repository oder dem Terraform Registry. Das ist praktisch, wenn du Standard-Bausteine für dein Unternehmen zur Verfügung stellst, etwa ein „Standard VNet“-Modul für alle Projekte.

Gute Modul-Praxis:

• Klar definierte Eingaben und Ausgaben.
• Keine versteckten Abhängigkeiten, zum Beispiel hart codierte Ressourcennamen.
• Sinnvolle Defaults, aber keine zu starke Magie.
• Dokumentation, wie das Modul zu verwenden ist.

Module sind der Schlüssel, um in größeren Umgebungen nicht im Terraform-Spaghetti-Code zu versinken.

Workspaces: Mehrere Umgebungen mit derselben Konfiguration

Irgendwann brauchst du mehr als nur „eine“ Umgebung. Typisch sind zum Beispiel:

• „dev“ für Entwicklung
• „test“ oder „staging“
• „prod“ für Produktion

Mit Terraform-Workspaces kannst du dieselbe Konfiguration für mehrere logische Umgebungen verwenden. Jeder Workspace hat dabei einen eigenen State. Standardmäßig gibt es den Workspace „default“, du kannst weitere anlegen:

terraform workspace new dev
terraform workspace new prod
terraform workspace list
terraform workspace select dev

In deinem Code kannst du den aktuellen Workspace abfragen, zum Beispiel:

locals {
 env = terraform.workspace
}

Damit kannst du Ressourcennamen oder Tags anpassen, etwa „myapp-dev“ oder „myapp-prod“.

Workspaces sind hilfreich, haben aber auch Fallstricke:

• Sie sind kein Ersatz für saubere Trennung in unterschiedlichen Accounts oder Subscriptions.
• Ein Fehler in der Konfiguration kann sich auf alle Workspaces auswirken.
• Die Logik im Code sollte nicht zu sehr von „terraform.workspace“ abhängen, sonst wird es unübersichtlich.

Eine bewährte Praxis in vielen Teams: Für wirklich getrennte Welten (zum Beispiel verschiedene Azure-Subscriptions) lieber getrennte Terraform-Projekte oder zumindest getrennte Backends nutzen, und Workspaces eher für kleinere Varianten.

Terraform vs. klickbasierte Cloud-Verwaltung: Was wann sinnvoll ist

Ganz ohne Portal wirst du auch mit Terraform nicht auskommen. Die Frage ist eher: Wofür nutzt du was?

Typische Einsatzbereiche für Terraform:

• Basis-Infrastruktur für Projekte: Netzwerke, Ressourcengruppen, Identitäten.
• Standardisierte Services, die du in mehreren Projekten brauchst.
• Komplexe Setups, bei denen viele Ressourcen zusammenspielen.
• Wiederholbare Umgebungen für Tests oder Schulungen.

Typische Einsatzbereiche für das Portal oder die CLI:

• Einmalige Ad-hoc-Analysen, zum Beispiel Logs ansehen.
• Exploratives Arbeiten: Neue Services ausprobieren, um sie zu verstehen.
• Kleinstanpassungen, die bewusst nicht im IaC abgebildet werden sollen.

Wichtig ist, dass du dir im Team klare Regeln gibst:

• Welche Ressourcen verwalten wir über Terraform, welche nicht?
• Wer darf im Portal Änderungen vornehmen und in welchem Umfang?
• Wie gehen wir mit manuellen Änderungen um, die trotzdem passieren?

In vielen Münchner Unternehmen hat sich bewährt: Alles, was dauerhaft und geschäftskritisch ist, wird konsequent per Terraform verwaltet. Das Portal bleibt Werkzeug für Diagnose, Monitoring und gelegentliche Einmalaktionen.

Wie du sinnvoll mit Terraform startest

Um Terraform zu lernen, brauchst du keine riesige Umgebung. Ein pragmatischer Einstieg:

1. Eine kleine Cloud-Spielwiese anlegen, zum Beispiel ein eigenes Azure-Subscription oder AWS-Account mit Kostenlimit.
2. Terraform lokal installieren und einen einfachen Provider konfigurieren.
3. Mit einer winzigen Ressource starten, zum Beispiel eine Ressourcengruppe oder ein S3-Bucket.
4. Plan/Apply-Workflow verinnerlichen und bewusst mit „terraform destroy“ experimentieren.
5. Danach Module und Workspaces hinzunehmen, sobald du mehr als eine Handvoll Ressourcen hast.

Wenn du lieber strukturiert mit Anleitung lernst, sind Präsenzschulungen oder Live-Online-Trainings eine gute Abkürzung, gerade wenn du mit Kolleginnen und Kollegen aus einem Projektteam gemeinsam startest. Aktuelle Termine und passende Kurse findest du bei cmt.de.

Entscheidend ist: Terraform ist kein „Alles oder nichts“. Du kannst klein anfangen, Erfahrungen sammeln und Schritt für Schritt mehr Infrastruktur in Code überführen. Je früher du das tust, desto weniger Zeit verlierst du später mit Suchen, Korrigieren und Nachbauen von „irgendwie“ geklickten Cloud-Setups.