Betrieb & Monitoring
Terraform / OpenTofu
Terraform und der Fork OpenTofu sind Infrastructure-as-Code-Tools: Infrastruktur deklarativ in HCL, per State gesteuert (OpenTofu MPL-2.0, Terraform BUSL).
- Deklarative Infrastruktur in HCL
- State als Quelle der Wahrheit
- Provider für viele Clouds/APIs
- Workflow: plan und apply
- OpenTofu MPL-2.0, Terraform BUSL
Terraform ist das verbreitete Werkzeug für Infrastructure as Code: Man beschreibt den gewünschten Endzustand von Infrastruktur deklarativ in HCL, und Terraform berechnet und führt die nötigen Schritte aus. Sein Kernkonzept ist der State, ein Abbild der real existierenden Ressourcen. Seit HashiCorp 2023 auf die quellverfügbare BUSL umstellte, existiert mit OpenTofu ein quelloffener Fork (MPL-2.0) unter der Linux Foundation, der weitgehend kompatibel ist.
Dieser Artikel erklärt das deklarative Prinzip und HCL, den State samt Remote Backend und Locking, Provider und Module, den Workflow init/plan/apply/destroy, das Thema Drift, die Lizenz-Historie und den OpenTofu-Fork sowie die Abgrenzung zu Ansible. Wie sich das in ein Pull-Betriebsmodell einbetten lässt, zeigt GitOps.
1. Deklarativ in HCL
Statt Schritt-für-Schritt-Anweisungen beschreibt man in HCL den Soll-Zustand: welche Ressourcen existieren sollen, mit welchen Eigenschaften. Terraform/OpenTofu ermittelt daraus über einen Abhängigkeitsgraphen die Reihenfolge und legt unabhängige Ressourcen parallel an. Bausteine sind Resources (verwaltete Objekte), Data Sources (lesender Zugriff), Module (wiederverwendbare Sammlungen) sowie Variablen und Outputs.
HCL: virtuelle Maschine auf Proxmox deklarieren (verkürzt)
resource "proxmox_vm_qemu" "web01" {
name = "web01"
target_node = "pve1"
cores = 2
memory = 4096
disk {
size = "40G"
storage = "local-zfs"
}
}2. Der State als Quelle der Wahrheit
Terraform führt eine State-Datei (Standard terraform.tfstate, JSON), die das Mapping zwischen HCL-Ressourcen und realen Objekten enthält. Der State ist die Single Source of Truth über den Ist-Zustand und ermöglicht, Änderungen als Diff zu berechnen. Im Team gehört er in ein Remote Backend (S3, Azure Blob, GCS, Consul) mit State Locking, das gleichzeitige Schreibzugriffe verhindert.
Der State enthält Secrets im Klartext
Sensible Werte (Passwörter, API-Keys, generierte Zugangsdaten) landen im State als Klartext-JSON, auch als „sensitive“ markierte. Wer den State lesen kann, liest die Geheimnisse. Pflicht sind daher: Remote-Backend mit Verschlüsselung, strenge Zugriffsrechte, Audit-Logging und niemals den State in Git einchecken. OpenTofu bietet ab 1.7 zusätzlich native State-Verschlüsselung.
3. Provider und Module
Provider sind Plugins, die Terraform mit Ziel-APIs verbinden. Das Registry umfasst über 1.000 Provider in drei Stufen: offizielle (AWS, Azure, GCP, Kubernetes), Partner (etwa VMware, Datadog) und Community (etwa Proxmox). Module kapseln wiederverwendbare Ressourcen-Sammlungen und werden versioniert eingebunden, ein Best Practice für reproduzierbare Deployments. OpenTofu nutzt ein eigenes Registry, das die Provider über eine Kompatibilitätsschicht bereitstellt.
4. Workflow: init, plan, apply, destroy
Der Kern-Workflow hat vier Schritte: init (Provider/Module laden), plan (Diff aus Soll und State berechnen, ohne etwas zu ändern), apply (die geplanten Änderungen nach Bestätigung ausführen) und destroy (verwaltete Ressourcen gezielt abbauen). Der plan-Schritt ist das Sicherheitsnetz: Er zeigt vor jeder Änderung genau, was angelegt, geändert oder gelöscht würde.
Der plan-Schritt vor jedem apply ist nicht lästige Bürokratie, sondern der Kern der Methode. Ein Review des Plans vor dem Merge verhindert, dass eine unscheinbare Änderung in der Konfiguration unbemerkt eine produktive Datenbank neu anlegt.
5. Drift, Lizenz und OpenTofu
Drift bezeichnet die Abweichung zwischen dem State und der Realität, etwa durch manuelle Änderungen in der Cloud-Konsole; plan erkennt das und zeigt es als unerwartete Differenz. Lizenzseitig stand Terraform bis August 2023 unter MPL-2.0, danach unter der quellverfügbaren BUSL 1.1 (interne Nutzung erlaubt, konkurrierende Managed-Services nicht). Als Reaktion entstand der Community-Fork OpenTofu unter der Linux Foundation, der unter MPL-2.0 bleibt, weitgehend drop-in-kompatibel ist und eigene Funktionen wie State-Verschlüsselung mitbringt.
6. Abgrenzung zu Ansible
Terraform/OpenTofu und Ansible ergänzen sich: Terraform provisioniert Infrastruktur deklarativ mit State (VMs, Netze, Cloud-Ressourcen), Ansible konfiguriert bestehende Systeme prozedural und idempotent. Eine verbreitete Aufteilung lautet „Terraform baut, Ansible konfiguriert“. Der wesentliche technische Unterschied ist der State: Terraform verfolgt damit, was es angelegt hat; Ansible kennt kein solches State-File und stellt den Zustand über Idempotenz her.
7. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Deklarativ, reproduzierbar, in Git versionierbar | State ist ein kritisches Asset; Fehler können teuer werden |
| Multi-Cloud über mehr als 1.000 Provider | Secrets liegen im State als Klartext; Backend muss abgesichert sein |
| plan zeigt Änderungen vor der Ausführung | Lernkurve bei HCL, State und Provider-Ökosystem |
| Module-Ökosystem für Wiederverwendung | Terraform-BUSL erfordert Lizenzprüfung bei kommerziellen Produkten |
| OpenTofu als lizenz-reine, offene Alternative | Kein Config-Management; ergänzt sich erst mit Ansible |
Häufige Fragen zu Terraform / OpenTofu
OpenTofu ist ein 2023 entstandener Community-Fork von Terraform, nachdem HashiCorp auf die quellverfügbare BUSL umstellte. OpenTofu steht weiterhin unter der offenen MPL-2.0, läuft unter der Linux Foundation und ist weitgehend drop-in-kompatibel; inzwischen hat es eigene Funktionen wie State-Verschlüsselung. Für streng offene Lizenzierung ist OpenTofu die naheliegende Wahl.
Der State ist das Abbild der real verwalteten Ressourcen und damit die Grundlage jeder Diff-Berechnung. Geht er verloren oder wird er inkonsistent, weiß Terraform nicht mehr, was es verwaltet. Zudem enthält er Secrets im Klartext. Deshalb gehört er in ein verschlüsseltes Remote-Backend mit Locking und strengen Zugriffsrechten, niemals in Git.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Terraform / OpenTofu im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.