Warum wir packer-plugin-proxmox geforkt haben

Jede VM, die wir betreiben, beginnt als Packer-Build. ISO booten oder Basis-Image klonen, Provisioner durchlaufen lassen, als Proxmox-Template einfrieren. Dieses Template ist das Fundament für jeden Kubernetes Node, jeden Datenbankserver und jede Edge-VM. Reproduzierbarkeit ist dabei keine Kür: Dieselbe Packer-Konfiguration muss montags dasselbe Template erzeugen wie freitags, im Juni wie im Dezember.

Das Packer-Plugin von Hashicorp für Proxmox wird seit einiger Zeit nicht mehr weiterentwickelt. Wir haben es geforkt.

Der Fork liegt unter github.com/natrontech/packer-plugin-proxmox. Er ist ein Ersatz für das upstream Plugin von Hashicorp. Umstellen: eine Zeile.

Warum wir Packer mit Proxmox einsetzen

Wie Proxmox unsere Infrastruktur antreibt, haben wir in einem früheren Beitrag beschrieben. Kurzfassung: Alle unsere Hypervisoren laufen auf Proxmox VE, jedes VM-Template bauen wir mit Packer. Packer erlaubt es, Templates als Code zu definieren, in Git zu versionieren und in der CI zu bauen. Kein manuelles Klicken durch die Proxmox-Oberfläche.

Damit das funktioniert, müssen Builds reproduzierbar sein. Ein Template ist ein Ausgangspunkt, den wir hundertfach klonen. Liefern zwei Builds aus derselben Konfiguration unterschiedliche Templates, verliert man die Kontrolle darüber, was tatsächlich in der Infrastruktur läuft.

Das Problem mit dem upstream Plugin

Das upstream Plugin hashicorp/packer-plugin-proxmox funktioniert für einfache Anwendungsfälle gut. Aber neue Issues wurden schlecht adressiert. Pull Requests, die echte Betriebsprobleme adressierten, lagen monatelang offen.

Wir haben von upstream v1.2.3 geforkt und betreiben den Fork seither.

Was wir geändert haben

Cloud-init-Paket-Upgrades kontrollieren (Proxmox 8)

Das ist die Änderung, die den Fork ausgelöst hat.

In Proxmox 7 lief apt upgrade beim ersten VM-Start standardmässig nicht. In Proxmox 8 hat sich das umgekehrt: ciupgrade ist jetzt standardmässig aktiv, cloud-init führt beim ersten Boot ein vollständiges Paket-Upgrade durch.

Für normale VM-Deployments sind automatische Upgrades beim ersten Boot oft unproblematisch. Für Packer-Template-Builds sind sie es nicht. Wenn ciupgrade aktiv ist, zieht jeder Packer-Build die Paketversionen rein, die am jeweiligen Tag verfügbar sind. Ein Template aus Woche 23 enthält andere Pakete als eines aus Woche 24. Die Konfiguration ist identisch, der Output nicht.

Das upstream Plugin bot keine Möglichkeit, das zu kontrollieren. Wir haben cloud_init_upgrade_packages ergänzt:

source "proxmox-iso" "ubuntu" {
  # ...
  cloud_init                  = true
  cloud_init_upgrade_packages = false
}

false deaktiviert Upgrades, der Build liefert jedes Mal dasselbe Template. true erzwingt Upgrades explizit.

Disk-Replikation während Builds überspringen

Proxmox unterstützt Storage-Replikation: Disks können über Cluster-Knoten hinweg repliziert werden. Das upstream Plugin bot keine Möglichkeit, die Replikation einzelner Disks zu deaktivieren. Wir haben skip_replication ergänzt:

disks {
  type             = "scsi"
  disk_size        = "50G"
  storage_pool     = "local-lvm"
  skip_replication = true
}

Read-only-Disks

Manche Templates enthalten ein Daten-Volume, das nach dem Build nicht mehr beschreibbar sein soll. Dafür gibt es jetzt read_only:

disks {
  type         = "scsi"
  disk_size    = "10G"
  storage_pool = "local-lvm"
  read_only    = true
}

Unterstützt für scsi- und virtio-Disk-Typen. Das Plugin prüft das zur Build-Zeit und lehnt die Konfiguration ab, wenn read_only auf einem Disk-Typ gesetzt wird, der es nicht unterstützt.

Fehlerbehebungen

Neben den neuen Features haben wir mehrere Bugs behoben, die zu stillem Fehlverhalten führten, etwa beim Nameserver-Parsing und bei Fehlermeldungen in network_adapters.

Zum Fork wechseln

hashicorp/proxmox im required_plugins-Block durch natrontech/proxmox ersetzen:

packer {
  required_plugins {
    proxmox = {
      version = ">= 1.3.0"
      source  = "github.com/natrontech/proxmox"
    }
  }
}

packer init installiert das neue Binary. Alle bestehenden Konfigurationsoptionen funktionieren weiterhin. Die neuen Optionen cloud_init_upgrade_packages, skip_replication und read_only sind alle optional mit sinnvollen Defaults, bestehende Configs müssen also nicht angepasst werden.

Releases werden auf GitHub veröffentlicht.

Wer mehr über Proxmox erfahren möchte, findet in unserem Whitepaper zur Proxmox-Migration weiterführende Informationen zu Planung und Betrieb.

Ausblick

Wir beobachten upstream und halten den Fork synchron, sofern der upstream wieder aktiv wird.

Wer Packer auf Proxmox betreibt und von neueren Features und Bugfixes profitieren möchte, kann mit einer einzigen Zeile auf unseren Fork wechseln. Bestehende Konfigurationen laufen unverändert weiter. Der Fork ist Open Source, Beiträge sind willkommen.