# Terraform Deep Dive: Infrastruktur deklarativ bauen

TL;DR / Management Summary Während Ansible das Innere der Server konfiguriert (Config Management), baut Terraform das Äußere (Infrastructure Provisioning). Es erstellt VMs in Proxmox, legt VPCs in AWS an oder konfiguriert Cloudflare-DNS-Records. Durch das Prinzip der “Deklarativität” beschreiben wir den Zielzustand, und Terraform kümmert sich um die Abhängigkeiten und die korrekte Reihenfolge der Erstellung.

# 1. Einführung & Architektur

Provisioning vs. Configuration.

Terraform nutzt Provider, um mit APIs zu kommunizieren. Es speichert den aktuellen Stand der Infrastruktur in einer State-Datei (terraform.tfstate).

graph TD
    A[Admin: *.tf Files] --> B[Terraform CLI]
    B --> C{State File}
    B --> D[Provider: Proxmox]
    B --> E[Provider: AWS/Azure]
    B --> F[Provider: Cloudflare]
    D --> G[VMs / Containers]
    E --> H[VPCs / S3]
    F --> I[DNS Records]

# 2. Erste Schritte: Proxmox VM erstellen

Infrastruktur per Code.

# Schritt 1: Provider definieren (provider.tf)

terraform {
  required_providers {
    proxmox = {
      source = "telmate/proxmox"
      version = "2.9.14"
    }
  }
}

provider "proxmox" {
  pm_api_url = "https://proxmox.company.com:8006/api2/json"
  pm_api_token_id = "terraform@pve!token"
  pm_api_token_secret = "your-secret-uuid"
}

# Schritt 2: Die Ressource definieren (main.tf)

resource "proxmox_vm_qemu" "web_server" {
  name        = "web-server-01"
  target_node = "pve-01"
  clone       = "ubuntu-22-template"
  
  cores   = 2
  memory  = 4096
  
  network {
    model  = "virtio"
    bridge = "vmbr0"
  }
}

# 3. Der Terraform Workflow

Planen, Anwenden, Zerstören.

1. terraform init: Lädt die benötigten Provider herunter.
2. terraform plan: Zeigt eine Vorschau der Änderungen (Was wird hinzugefügt/geändert/gelöscht?).
3. terraform apply: Führt die Änderungen tatsächlich durch.
4. terraform destroy: Löscht die gesamte definierte Infrastruktur.

# 4. Day-2 Operations: State & Backends

Die heilige State-Datei.

In Teams darf die terraform.tfstate niemals nur lokal auf dem Laptop liegen.

• Problem: Zwei Admins führen gleichzeitig apply aus -> Korruption der Infrastruktur.
• Lösung: Remote Backends (z.B. S3 mit DynamoDB Locking oder Gitlab Terraform State).

terraform {
  backend "http" {
    # Beispiel für GitLab Managed State
  }
}

# 5. Troubleshooting & “War Stories”

Wenn der Plan scheitert.

# Story 1: “Der Ghost-Resource-Effekt”

Symptom: Terraform will eine VM löschen, die es gar nicht mehr gibt (manuell in der GUI gelöscht). apply schlägt fehl. Ursache: Der lokale State ist nicht mehr synchron mit der Realität. Lösung: terraform refresh synchronisiert den State mit den APIs. Falls das nicht hilft: terraform state rm <resource_id>.

# Story 2: “Dependency Hell”

Symptom: Terraform versucht eine VM zu erstellen, bevor das Netzwerk-Interface bereit ist. Ursache: Unklare Abhängigkeiten zwischen Ressourcen. Lösung: Nutzen Sie depends_on = [proxmox_network.internal] oder verlinken Sie Ressourcen direkt über ihre IDs (network_id = proxmox_network.internal.id).

# 6. Fazit & Empfehlung

• Modularisierung: Schreiben Sie keine 5000 Zeilen Dateien. Nutzen Sie Terraform Modules, um logische Blöcke (z.B. “Standard-DB-VM”) wiederverwendbar zu machen.
• Variablen: Nutzen Sie variables.tf, um Umgebungen (Dev/Prod) zu trennen.
• Kombination: Nutzen Sie Terraform, um die VM zu erstellen, und geben Sie via Cloud-Init (siehe Artikel 002) die IP an Ansible weiter, um die Software zu installieren.

# Anhang: Cheatsheet