# Terraform Workspaces: Isolation von Umgebungen im Datacenter

TL;DR / Management Summary In einer professionellen IT-Infrastruktur müssen Entwicklung (Dev), Test (Staging) und Produktion (Prod) strikt getrennt sein. Mit Terraform Workspaces können wir denselben Code nutzen, um für jede Umgebung einen eigenen State (Artikel 789) zu führen. Ein Senior Admin nutzt Workspaces, um sicherzustellen, dass ein Test-Lauf niemals aus Versehen eine produktive VM in Proxmox löscht, und steuert umgebungsspezifische Parameter (wie RAM oder CPU) via Workspace-Variablen.

# 1. Was ist ein Workspace?

Die logische Trennung.

Standardmäßig arbeitet Terraform im Workspace default.

• Konzept: Jeder Workspace hat seine eigene Instanz der terraform.tfstate Datei.
• Vorteil: Sie können terraform apply in Dev ausführen, ohne dass dies Einfluss auf Prod hat – obwohl Sie die exakt gleichen .tf Dateien nutzen.

# 2. Workspaces in der Praxis

Der Workflow.

# Erstellen und Wechseln

# Neuen Workspace anlegen
terraform workspace new production
terraform workspace new staging

# Zwischen Umgebungen wechseln
terraform workspace select staging

# Nutzung im Code

Sie können den Namen des aktuellen Workspaces in Ihren Ressourcen nutzen:

resource "proxmox_vm_qemu" "server" {
  name = "web-${terraform.workspace}-01"
  # ...
}

# 3. Deep Dive: Workspace-spezifische Variablen

Dynamische Parameter.

Nutzen Sie Maps, um Ressourcen je nach Umgebung unterschiedlich zu dimensionieren:

locals {
  instance_config = {
    default    = { ram = 2048, cores = 1 }
    staging    = { ram = 4096, cores = 2 }
    production = { ram = 8192, cores = 4 }
  }
}

resource "proxmox_vm_qemu" "vm" {
  memory = local.instance_config[terraform.workspace].ram
  cores  = local.instance_config[terraform.workspace].cores
  # ...
}

# 4. Day-2 Operations: State Isolation

Sicherheit für das Backend.

Wenn Sie ein Remote Backend (z.B. S3) nutzen, organisiert Terraform die Workspaces automatisch in Unterverzeichnissen:

• path/to/state/env:/production/terraform.tfstate
• path/to/state/env:/staging/terraform.tfstate
• Wichtig: Stellen Sie sicher, dass Ihre CI/CD Pipeline (Artikel 785) vor jedem Lauf den korrekten Workspace auswählt.

# 5. Troubleshooting & “War Stories”

Wenn die Trennung verschwimmt.

# Top 3 Fehlerbilder

1. Symptom: “Resource already exists”.

   • Ursache: Sie haben in zwei verschiedenen Workspaces die gleiche feste VM-ID oder den gleichen Namen für eine Ressource vergeben.
   • Lösung: Nutzen Sie immer ${terraform.workspace} als Suffix in Namen.

2. Symptom: Unabsichtliche Änderungen in Produktion.

   • Ursache: Admin dachte, er sei im staging Workspace, war aber noch in production.
   • Fix: Zeigen Sie den Workspace im Shell-Prompt an oder nutzen Sie separate Verzeichnisse für Prod/Dev statt nativer Workspaces (siehe Punkt 7).

3. Symptom: Workspace lässt sich nicht löschen.

   • Ursache: Der Workspace enthält noch aktive Ressourcen im State.

# “War Story”: Der “Default” Workspace GAU

Ein Admin nutzte Workspaces für Dev und Prod. Eines Tages führte er terraform destroy aus, ohne vorher den Workspace zu prüfen. Da er sich im default Workspace befand und dieser (durch einen alten manuellen Import) die produktiven Core-Switche enthielt, löschte er die gesamte Netzwerkkonfiguration der Firma. Lehre: Nutzen Sie den default Workspace niemals für echte Ressourcen. Lassen Sie ihn leer als “Sicherheits-Zone”.

# 6. Monitoring & Reporting

Dashboard der Umgebungen.

# Workspace Audit

Nutzen Sie die CLI, um die Divergenz zu prüfen:

• terraform workspace list.
• Aktion: Vergleichen Sie regelmäßig die Ressourcen-Anzahl zwischen den Workspaces, um verwaiste Test-Umgebungen zu finden.

# 7. Fazit & Empfehlung

Workspaces sind ideal für identische Infrastruktur-Kopien.

• Empfehlung: Für kleine bis mittlere Projekte sind native Terraform Workspaces exzellent.
• Wichtig: Wenn Ihre Umgebungen sich massiv unterscheiden (z.B. andere Cloud-Provider oder völlig unterschiedliche Netzwerk-Topologien), nutzen Sie lieber die Verzeichnis-basierte Trennung (Separate Ordner für prod/ und dev/), da dies weniger fehleranfällig für menschliches Versagen ist.

# Anhang: Cheatsheet (Workspace CLI)

# Referenzen

• Terraform Documentation: Workspaces
• HashiCorp: Structure your Terraform Projects
• Best Practices: Terraform Workspaces vs File Structure