Ein häufiges Missverständnis beim Wechsel von AWS zu Proxmox ist die Angst vor dem "Click-Ops". DevOps-Teams befürchten, ihre modernen GitOps-Workflows zu verlieren und wieder wie 2010 Server manuell zu installieren.

Die Realität: Proxmox ist fully automatable. Aber der Weg dorthin ist etwas steiniger als bei AWS, weil man sich für den richtigen Terraform Provider entscheiden und Cloud-Init meistern muss.

In diesem technischen Deep-Dive zeigen wir, wie OutaCloud hochskalierbare Cluster automatisiert – und wie Sie den Terraform State sicher bei Hetzner lagern.

Inhaltsverzeichnis

Die Provider-Wahl: Telmate vs. BPG
- A) Der Platzhirsch: Telmate (telmate/proxmox)
- B) Der Herausforderer: BPG (bpg/proxmox)
Die Geheimwaffe: Cloud-Init Templates
Der Code: main.tf Beispiel (Telmate)
State Management: Wohin mit dem tfstate?
- Die Lösung: Hetzner Object Storage
Fazit: Gleicher Workflow, bessere Hardware
Sie wollen Ihre Terraform-Module migrieren?

Die Provider-Wahl: Telmate vs. BPG

Anders als bei AWS, wo es einen offiziellen Provider von HashiCorp gibt, setzt Proxmox auf Community-Provider. Es gibt zwei große Player, und die Wahl entscheidet über Ihre Möglichkeiten.

A) Der Platzhirsch: Telmate (telmate/proxmox)

Dies ist der am weitesten verbreitete Provider. Er ist stabil, battle-tested und für 90% aller "VM-Deployments" perfekt geeignet.

Stärke: Sehr gute Dokumentation, riesige Community, stabil für Standard-VMs und LXC-Container.
Schwäche: Hinkt bei neuen Proxmox-Features (wie SDN) manchmal hinterher.

B) Der Herausforderer: BPG (bpg/proxmox)

Dieser Provider ist moderner und näher an der Proxmox API. Er wird oft bevorzugt, wenn man tief in die Netzwerkkonfiguration eingreifen will.

Stärke: Unterstützt Proxmox SDN (Software Defined Network) nativ, besseres Handling von ISO-Uploads und komplexen ACME/Zertifikats-Themen.
Schwäche: Konfiguration ist teilweise komplexer (XML/SSH wrapping).

Unsere Empfehlung für den Start: Nutzen Sie Telmate für Compute-Ressourcen. Es fühlt sich am ehesten wie der AWS-Provider an.

Die Geheimwaffe: Cloud-Init Templates

Terraform kann VMs erstellen, aber es kann sie nicht konfigurieren (User, SSH-Keys, IP-Adressen). Bei AWS macht das die "User Data". Bei Proxmox nutzen wir Cloud-Init.

Bevor Sie Terraform ausführen können, benötigen Sie ein "Golden Image" (Template) in Proxmox, das Cloud-Init installiert hat.

So erstellen Sie das Template (einmalig auf dem Proxmox Host):

# 1. Ubuntu 22.04 Image laden
wget https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img

# 2. VM erstellen & Disk importieren
qm create 9000 --name "ubuntu-cloud-template" --memory 2048 --net0 virtio,bridge=vmbr0
qm importdisk 9000 jammy-server-cloudimg-amd64.img local-lvm

# 3. Cloud-Init Drive hinzufügen (WICHTIG!)
qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-0
qm set 9000 --ide2 local-lvm:cloudinit

# 4. Boot-Reihenfolge & Serial Console (für Terraform Logs)
qm set 9000 --boot c --bootdisk scsi0
qm set 9000 --serial0 socket --vga serial0

# 5. Zum Template konvertieren
qm template 9000

Jetzt haben Sie ein Template (ID 9000), das Terraform klonen kann.

Der Code: main.tf Beispiel (Telmate)

Hier ist ein produktives Beispiel, das eine VM auf einem Hetzner-Proxmox-Host deployt, eine statische IP vergibt und Ihren SSH-Key hinterlegt.

Provider Config:

terraform {
  required_providers {
    proxmox = {
      source = "telmate/proxmox"
      version = "3.0.1-rc1"
    }
  }
}

provider "proxmox" {
  pm_api_url  = "https://your-proxmox-host:8006/api2/json"
  pm_user     = "terraform-prov@pve"
  pm_password = var.pm_password
}

Resource Config (Die VM):

resource "proxmox_vm_qemu" "web_server" {
  count       = 3
  name        = "web-${count.index + 1}"
  target_node = "pve-01"

  # Wir klonen das Template von oben
  clone       = "ubuntu-cloud-template"
  full_clone  = true

  # Hardware Specs (vergleichbar mit c6i.large, aber dedicated)
  cores       = 4
  sockets     = 1
  cpu         = "host" # Wichtig für Performance!
  memory      = 8192
  scsihw      = "virtio-scsi-pci"

  # Cloud-Init Magic (User Data)
  ciuser      = "deploy"
  sshkeys     = <<EOF
  ssh-rsa AAAAB3NzaC1yc2E... dein-public-key ...
  EOF

  # Netzwerk (Statische IP via Cloud-Init)
  ipconfig0 = "ip=10.0.0.1${count.index + 1}/24,gw=10.0.0.1"

  # Disk Specs (NVMe)
  disk {
    storage = "local-lvm"
    size    = "50G"
    type    = "scsi"
    ssd     = 1
    discard = "on"
  }
}

State Management: Wohin mit dem tfstate?

In der AWS-Welt nutzen Sie S3 für den Terraform State. Ein lokales tfstate File ist in Teams ein No-Go. Wenn Sie AWS verlassen, wo speichern Sie den State sicher und zentral?

Die Lösung: Hetzner Object Storage

Wir nutzen Hetzner S3 Buckets als Backend. Es ist S3-kompatibel, liegt im gleichen Netzwerk wie Ihre Server (geringe Latenz) und kostet fast nichts.

So konfigurieren Sie das Backend:

terraform {
  backend "s3" {
    bucket = "terraform-state-bucket"
    key    = "prod/infrastructure.tfstate"

    # Hetzner Endpoint (Falkenstein)
    region   = "us-east-1" # Dummy Region (notwendig für Plugin)
    endpoint = "https://fsn1.your-objectstorage.com"

    # Credentials (am besten via Environment Variables übergeben!)
    # access_key = "..."
    # secret_key = "..."

    # Wichtig für S3-kompatible Backends, die nicht AWS sind:
    skip_credentials_validation = true
    skip_region_validation      = true
    skip_metadata_api_check     = true
    force_path_style            = true
  }
}

Tipp: Nutzen Sie export AWS_ACCESS_KEY_ID=... in Ihrer CI/CD Pipeline, um die Credentials nicht im Code zu haben.

Fazit: Gleicher Workflow, bessere Hardware

Der Wechsel zu Bare Metal bedeutet nicht, dass Sie Ihre DevOps-Prinzipien aufgeben.

AWS: Sie schreiben Code -> AWS API -> VM startet.

OutaCloud: Sie schreiben Code -> Proxmox API -> VM startet.

Der Unterschied? Der Code für Proxmox rollt Server aus, die Ihnen dedizierte Leistung bieten, keine Egress-Fees kosten und 100% DSGVO-konform sind. Ihre Entwickler merken im Alltag keinen Unterschied – Ihre Buchhaltung schon.

Sie wollen Ihre Terraform-Module migrieren?

Wir analysieren Ihre bestehenden HCL-Dateien und helfen beim Refactoring auf den Proxmox-Provider.

Starte hier:

Exit AWS – Übersicht unserer AWS-Migrationsservices
AWS zu Hetzner – Unser Migrations-Service für den Wechsel zu Hetzner
Proxmox Support – Unsere Proxmox-Expertise für Ihr Team

Oder kontaktiere uns direkt für eine kostenlose DevOps-Analyse.

Proxmox mit Terraform: Der ultimative Guide zur Automatisierung