Zum Inhalt springen

Terraform für Linux-Admins: Infrastruktur als Code, ohne Cloud-Käfig

10. November 2026 durch
Terraform für Linux-Admins: Infrastruktur als Code, ohne Cloud-Käfig
Carsten Depping

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 init

Terraform lädt den Provider und baut seine lokale Arbeitsstruktur. Danach prüfen wir den Plan:

terraform plan

Wenn das gut aussieht, wird angewendet:

terraform apply

Terraform 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 list

Details 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 plan

Terraform zeigt ein Update an. Genau das ist der Charme: Vorher sehen, was passiert. Dann:

terraform apply

Aufräumen ohne Restmüll

Wenn die Ressource weg soll:

terraform destroy

Terraform 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 apply

terraform 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.

Terraform für Linux-Admins: Infrastruktur als Code, ohne Cloud-Käfig
Carsten Depping 10. November 2026
Diesen Beitrag teilen