Terraform ist nicht nur für Leute mit Cloud-Account, Hoodie und Kreditkartenlimit gebaut. Wir haben es im Selbstversuch mal trocken auf Linux-Admin-Art benutzt: deklarativ beschreiben, was existieren soll, dann Terraform den Abgleich machen lassen. Keine Klickorgie, kein „wer hat das geändert?“, kein Shell-Skript mit 400 Zeilen emotionalem Ballast.
Was Terraform eigentlich macht
Terraform verwaltet Ressourcen über Provider. Das kann AWS sein, muss es aber nicht. Es gibt Provider für Proxmox, libvirt, DNS, Vault, GitLab, Kubernetes, lokale Dateien und ziemlich viel Zeug, das in echten Admin-Kellern herumsteht.
Der wichtige Gedanke: Du beschreibst den Zielzustand. Nicht: „führe diese Schritte aus“. Sondern: „diese Ressource soll so aussehen“. Terraform vergleicht dann Konfiguration, aktuellen Zustand und seine State-Datei. Danach sagt es dir, was es ändern würde.
Das ist für Linux-Admins erstmal ungewohnt. Wir denken gerne in apt install, systemctl restart, sed -i und einem kleinen Gebet an die Shell-Götter. Terraform tickt anders.
Minimaler Start ohne Cloud
Für den Einstieg nehmen wir den local-Provider. Der baut keine Server, aber zeigt sauber das Prinzip. Eine Datei als verwaltete Ressource. Klingt banal, ist aber didaktisch weniger gefährlich als „wir löschen aus Versehen dein halbes Lab“.
# main.tf
terraform {
required_providers {
local = {
source = "hashicorp/local"
version = "~> 2.5"
}
}
}
provider "local" {}
resource "local_file" "motd" {
filename = "${path.module}/motd.txt"
content = "Managed by Terraform. Bitte nicht von Hand anfassen.\n"
}Dann initialisieren wir das Arbeitsverzeichnis:
terraform initTerraform lädt den Provider und baut seine lokale Arbeitsstruktur. Danach prüfen wir den Plan:
terraform planWenn das gut aussieht, wird angewendet:
terraform applyTerraform fragt nochmal nach. Ja, das ist Absicht. Produktionssysteme mögen keine YOLO-Deployments.
State: die heilige Inventarliste
Nach dem Apply liegt eine terraform.tfstate im Verzeichnis. Das ist keine Deko. Darin merkt sich Terraform, welche realen Ressourcen zu deiner Konfiguration gehören.
Nicht einfach löschen. Nicht achtlos ins öffentliche Git werfen. Je nach Provider stehen dort sensible Daten drin. Im Team nutzt du dafür später Remote State, Locking und saubere Backends. Für den Anfang reicht lokal, aber mit Respektabstand.
Status anzeigen:
terraform state listDetails zur Ressource:
terraform state show local_file.motdÄnderungen deklarativ machen
Ändern wir den Inhalt:
# main.tf
terraform {
required_providers {
local = {
source = "hashicorp/local"
version = "~> 2.5"
}
}
}
provider "local" {}
resource "local_file" "motd" {
filename = "${path.module}/motd.txt"
content = "Managed by Terraform. Änderungen bitte per Merge Request.\n"
}Jetzt wieder:
terraform planTerraform zeigt ein Update an. Genau das ist der Charme: Vorher sehen, was passiert. Dann:
terraform applyAufräumen ohne Restmüll
Wenn die Ressource weg soll:
terraform destroyTerraform entfernt, was es verwaltet. Nicht alles im Verzeichnis. Nicht dein System. Nur Ressourcen aus dem State. Meistens jedenfalls. Provider-Doku lesen bleibt weiterhin ein Lebensmodell.
Warum das für Linux-Admins taugt
Terraform ersetzt kein Configuration Management wie Ansible. Es installiert dir nicht elegant Pakete oder templated jede nginx.conf. Terraform ist stärker bei Infrastruktur: VMs, Netzwerke, DNS-Records, Storage, Secrets-Engines, Projekte, Benutzer, Policies.
Der Workflow ist simpel und ziemlich robust:
terraform fmt
terraform validate
terraform plan
terraform applyterraform fmt formatiert. terraform validate findet groben Unsinn. plan zeigt die Absicht. apply macht ernst.
Unser Fazit aus dem Maschinenraum: Terraform lohnt sich auch ohne Hyperscaler-Wolke. Gerade im eigenen Lab, bei Proxmox, DNS oder internen Plattformen bringt es Ordnung in gewachsene Admin-Magie. Und wenn jemand fragt, wer die Ressource geändert hat, zeigt Git nicht mit dem Finger. Git zeigt mit Commit-Hash.