# Terraform on SUSE: Infrastruktur per Code im SUSE-Stil

TL;DR / Management Summary Terraform ist das Standard-Tool, um SLES-Instanzen in der Cloud (AWS, Azure, GCP) oder lokal auf Proxmox/OpenStack bereitzustellen. In der SUSE-Welt nutzen wir Terraform nicht nur zum Erstellen der VMs, sondern integrieren den Prozess direkt in den SUSE Manager Bootstrap. Ein Senior Admin nutzt spezialisierte SUSE Cloud Images und automatisiert die Registrierung via user_data.

# 1. Einführung & Architektur

Provisioning im SUSE-Kontext.

Terraform baut die VM, Cloud-Init (Artikel 054) registriert das System bei SUSE, und Salt (Artikel 169) konfiguriert die Applikation.

# Der Deployment-Stack (Mermaid)

graph TD
    A[Admin: Terraform CLI] --> B[Provider: OpenStack / AWS]
    B --> C[VM Instance: SLES 15]
    C --> D[Cloud-Init: Register at SCC]
    D --> E[SUSE Manager: Bootstrap]
    E --> F[SaltStack: Configuration]
    subgraph "IaC Control"
        A
    end

# 2. SUSE Cloud Images nutzen

Optimiert für die Cloud.

SUSE stellt unter SLES Cloud Images vorkonfigurierte Abbilder bereit.

# Beispiel: Terraform Ressource für SLES

resource "openstack_compute_instance_v2" "sles_server" {
  name            = "sles-prod-01"
  image_name      = "SLES15-SP5-Cloud-Image"
  flavor_name     = "m1.medium"
  
  # Übergabe der Cloud-Init Daten zur Registrierung
  user_data = <<-EOF
    #cloud-config
    runcmd:
      - SUSEConnect -r YOUR_REG_CODE -e admin@company.com
  EOF
}

# 3. Terraform & SUSE Manager Integration

Zentrale Kontrolle ab Minute 1.

Ein professionelles Deployment fügt den neuen Server sofort zum SUSE Manager hinzu.

# Bootstrap via Terraform

Nutzen Sie den remote-exec Provisioner, um das Bootstrap-Skript auszuführen:

provisioner "remote-exec" {
  inline = [
    "curl -k https://suse-manager.local/pub/bootstrap/bootstrap.sh | bash"
  ]
}

# 4. Day-2 Operations: ALP (Adaptive Linux Platform)

Blick in die Zukunft.

SUSE ALP ist der Nachfolger von SLES und setzt massiv auf Containerisierung. Terraform wird hier genutzt, um Immutable Hosts (Transactional Systems) bereitzustellen, die ihre Workloads in WebAssembly oder Containern ausführen.

# 5. Troubleshooting & “War Stories”

Wenn der Plan die Realität trifft.

# Story 1: “Der hängende SCC-Connect”

Symptom: Terraform meldet “Success”, aber der Server hat keine Repositories. Ursache: Der SUSEConnect Befehl im user_data ist fehlgeschlagen (z.B. durch DNS-Probleme), aber Terraform wertet den Erfolg von Cloud-Init nicht standardmäßig aus. Lösung: Nutzen Sie wait_for_fulfillment oder prüfen Sie den Status via SSH im Post-Provisioning.

# Story 2: “Machine-ID Kollision”

Symptom: Terraform klont eine VM-Disk 10x. Alle 10 Server erscheinen im SUSE Manager als ein einziger Host. Ursache: Das genutzte Image war kein echtes “Cloud-Image”, sondern ein Snapshot einer laufenden VM inkl. /etc/machine-id. Lösung: Stellen Sie sicher, dass Ihr Image vor dem Snapshot mit virt-sysprep oder cloud-init clean bereinigt wurde.

# 6. Fazit & Empfehlung

• Images: Nutzen Sie immer die offiziellen “JeOS” (Just Enough OS) oder Cloud-Images von SUSE.
• Modularität: Bauen Sie Terraform-Module für Standard-SLES-Setups (z.B. HA-Cluster).
• Wahl: Terraform ist ideal für die Cloud. Für rein lokale Proxmox-Setups ohne API-Zugriff ist oft AutoYaST (Artikel 125) die bessere Wahl.

# Anhang: Cheatsheet