Proxmox GitOps: 5 Wege, Ihren Cluster zu automatisieren

Proxmox GitOps funktioniert am besten, wenn Git den beabsichtigten Zustand festhält, Automatisierung vorhersehbare Änderungen anwendet und Menschen weiterhin die Kontrolle über riskante Vorgänge behalten. In Proxmox VE 9.2 kann ein praxistauglicher GitOps-Stack Terraform oder OpenTofu für die Infrastruktur, Ansible für die Konfiguration und CI-Pipelines für Review und Ausführung nutzen.

Der wichtige Teil ist der Scope. GitOps ist eine Möglichkeit, Infrastruktur von einem versionierten Soll-Zustand aus zu betreiben, wobei Änderungen geprüft und per Automatisierung angewendet werden. Es sollte Recovery und Change Control erleichtern. Wenn es einen einfachen Cluster in fünf Schichten YAML verwandelt, die niemand versteht, ist das Design gescheitert.

Dieser Leitfaden basiert auf der Proxmox-VE-9.2-Dokumentation und aktuellen Automatisierungsprojekten mit Stand 15. August 2026. Ich trenne bewusst dokumentierte Fähigkeiten von Dingen, die eine Pipeline technisch tun könnte, aber wahrscheinlich nicht unbeaufsichtigt tun sollte.

Was bedeutet GitOps für Proxmox?

GitOps bedeutet, dass die Konfiguration, die Sie ausführen wollen, in Git gespeichert wird und Änderungen einen kontrollierten Workflow durchlaufen, bevor Automatisierung sie anwendet. Das Repository wird zu einer prüfbaren Aufzeichnung dessen, was existieren sollte und warum es sich geändert hat.

Das heißt nicht, dass jede Proxmox-Einstellung jede Minute abgeglichen werden muss. Ein Homelab kann einen leichtgewichtigen Git-Workflow nutzen. Eine Produktionsplattform kann Pull Requests, Validierung, Freigaben und Environment Promotion hinzufügen.

Die nützliche Frage lautet nicht „Kann das automatisiert werden?" Sie lautet „Würde automatische Reconciliation das sicherer machen?"

Bevor Sie eine GitOps-Schicht hinzufügen, bauen Sie mit dem Proxmox-Installationsleitfaden und einer getesteten Proxmox-Backup-Strategie eine verlässliche Basis auf.

1. Wie kann GitOps Proxmox-VMs und -LXCs provisionieren?

Das erste nützliche GitOps-Muster ist die deklarative Provisionierung von virtuellen Maschinen und Containern. Terraform oder OpenTofu können VM-Name, CPU, Arbeitsspeicher, Disks, Netzwerkschnittstellen, Tags und Initialisierungseinstellungen in Code beschreiben.

Der BPG-Proxmox-Provider stellt Ressourcen für Proxmox-VE-VMs und LXC-Container bereit. Sein Cloud-Init-Leitfaden zeigt, wie Initialisierungsdaten bei der Erstellung an eine VM angehängt werden können.

Das ergibt einen sauberen Workflow:

1. Ein Engineer ändert die Infrastrukturdefinition.
2. Ein Pull Request zeigt genau, was sich geändert hat.
3. Validierung läuft, bevor irgendetwas den Cluster berührt.
4. Eine freigegebene Pipeline wendet die Änderung an.
5. Git zeichnet die gewünschte Konfiguration und die Review-Historie auf.

Dieses Muster ist besonders nützlich für Entwicklungsumgebungen, Branch-Umgebungen, Lab-Cluster und standardisierte Server-Rollen.

Die Hauptgefahr ist Configuration Drift. Wenn Leute weiterhin von Terraform verwaltete VMs manuell in der Proxmox-GUI in ihrer Größe ändern, versucht der nächste Plan möglicherweise, diese Änderungen rückgängig zu machen. Definieren Sie Ownership klar. Entweder wird ein Feld per Code kontrolliert, oder es wird manuell kontrolliert.

2. Wie sollte Ansible in Proxmox GitOps passen?

Ansible passt natürlich nach der Provisionierung, weil es sowohl die Proxmox-Infrastruktur als auch die darauf laufenden Betriebssysteme konfigurieren kann. Die aktuelle community.proxmox-Collection enthält Module für Instanzen, KVM-VMs, Cluster, ACLs, Pools und SDN-Objekte.

Ich bevorzuge es, die Zuständigkeiten einfach zu halten. Terraform erstellt Infrastruktur. Ansible konfiguriert Systeme. Git und CI steuern, wann welche Schicht läuft.

Zum Beispiel könnte ein Pull Request eine neue Monitoring-VM hinzufügen. Terraform erstellt sie aus einer Standardvorlage. Cloud Init gibt ihr eine Netzwerkidentität und einen SSH-Schlüssel. Ansible installiert die Monitoring-Software, wendet die Konfiguration an und registriert sie beim Rest der Umgebung.

Diese Abfolge lässt sich leichter debuggen als ein einziges riesiges Tool, das versucht, jede Schicht zu verwalten.

Ansible kann über das Modul community.proxmox.proxmox_cluster auch Proxmox-Cluster erstellen und ihnen beitreten. Ich würde Änderungen an der Cluster-Mitgliedschaft trotzdem hinter eine explizite Freigabe stellen. Corosync und Quorum sind keine guten Orte für beiläufige, fortlaufende Reconciliation.

3. Kann GitOps LXC-Anwendungsplattformen verwalten?

Ja, und genau hier werden Projekte wie Proxmox-GitOps interessant. Das Projekt beschreibt eine in sich geschlossene GitOps-Umgebung zur Provisionierung und Orchestrierung von Linux-Containern auf Proxmox VE und führt Proxmox VE 8.4 bis 9.2 in seinen Anforderungen auf.

Sein Modell behandelt ein Monorepository als Soll-Zustand und nutzt eine mehrstufige Pipeline, um Container-Infrastruktur zu bootstrappen und auszurollen. Es nutzt außerdem Ansible als Teil der Container-Provisionierung.

Das ist mehr als eine Sammlung von Skripten. Es ist ein Betriebsmodell.

Der Vorteil ist Reproduzierbarkeit. Ein Container sollte sich aus Code heraus ersetzen lassen, statt jahrelang von Hand repariert zu werden.

Der Preis ist Abstraktion. Wenn die Pipeline fehlschlägt, müssen Sie Git, CI, Proxmox-Authentifizierung, LXC-Verhalten, Netzwerk und das darunterliegende Konfigurationstool verstehen. Wenn nur eine Person den Stack versteht, haben Sie den Bus-Faktor automatisiert.

Für einfacheres App-Deployment ist der Proxmox-Helper-Scripts-Leitfaden vielleicht besser geeignet. GitOps rechtfertigt seine Komplexität, wenn Wiederholbarkeit und Change Control wichtiger sind als Einrichtungsgeschwindigkeit.

4. Sollten Updates von Git aus gesteuert werden?

Git ist ein guter Ort, um die Update-Policy zu deklarieren, aber unbeaufsichtigte Updates über einen gesamten Proxmox-Cluster hinweg brauchen Leitplanken. Versionsänderungen können den Kernel, QEMU, das Storage-Verhalten, Treiber und Cluster-Dienste betreffen.

Ein sichereres Muster besteht darin, Policy und Workflow in Git zu speichern, während die Ausführung stufenweise bleibt.

Definieren Sie zum Beispiel, welches Repository ein Node nutzt, zu welcher Wartungsgruppe er gehört, welche Vorprüfungen bestehen müssen und ob Workloads vor einem Reboot migriert werden müssen. Die Pipeline kann die Änderung vorbereiten, Prüfungen ausführen und vor der Produktivumgebung für eine Freigabe anhalten.

Proxmox VE 9.2 fügt HA-Arm- und Disarm-Steuerungen für geplante Wartung hinzu. Das ist operativ nützlich, macht es aber nicht überflüssig zu verstehen, was das Update verändert.

Ich würde außerdem vermeiden, „latest" ohne Einschränkung zum Soll-Zustand zu machen. Infrastruktur-Automatisierung sollte auf ein geprüftes Paket-Set oder ein freigegebenes Release-Fenster abzielen, nicht jeder Änderung hinterherjagen, nur weil ein Repository sie veröffentlicht hat.

5. Wie kann GitOps Disaster Recovery verbessern?

GitOps ist bei der Recovery am wertvollsten, wenn das Repository genug Informationen enthält, um Infrastruktur wiederherzustellen, ohne dass sich jemand an jede Einstellung erinnern muss. VM-Definitionen, Netzwerk-Intent, Rollenzuweisungen, Gast-Konfiguration und Deployment-Skripte können alle die Recovery-Zeit verkürzen.

Aber Git ist kein VM-Backup.

Ein Repository stellt keine Datenbank-Disk, kein Windows-Systemvolume und kein LXC-Dataset wieder her. Halten Sie Workload-Backups getrennt und testen Sie sie. Der Proxmox-Backup-Leitfaden deckt die Recovery-Seite ab, die Infrastruktur-Code nicht ersetzen kann.

Ich denke gerne in zwei Schichten der Recovery. Git baut das Skelett wieder auf. Backups stellen die zustandsbehafteten Daten wieder her.

Das legt auch einen nützlichen Test offen. Wenn Ihr Proxmox-Host verschwindet, kann ein neuer Administrator das Repository lesen und verstehen, wie die Umgebung wiederhergestellt wird? Wenn die Antwort Nein lautet, ist Ihr Code vielleicht automatisiert, aber Ihr Recovery-Prozess ist nicht dokumentiert.

Was sollte Proxmox GitOps niemals blind automatisieren?

Beginnen Sie nicht damit, Storage-Zerstörung, Ceph-Topologie, Quorum-Mitgliedschaft, HA-Fencing-Verhalten, Firewall-Policy und privilegierte Zugangsdaten fortlaufend abzugleichen. Diese Bereiche haben einen großen Explosionsradius.

Stellen Sie destruktive Aktionen hinter eine Prüfung. Nutzen Sie getrennte Zugangsdaten für Read, Plan und Apply, wo Ihr Tooling das erlaubt. Schützen Sie Secrets außerhalb des Repositorys. Testen Sie Änderungen gegen eine Nicht-Produktivumgebung.

Denken Sie auch daran, dass API-Zugriff Macht bedeutet. Community-Tooling kann exzellent sein, aber jeder Token sollte nur die minimalen Berechtigungen haben, die für seine Aufgabe nötig sind.

Welchen Proxmox-GitOps-Stack würde ich bauen?

Ich würde es klein halten. Git hostet den Soll-Zustand und die Review-Historie. Terraform oder OpenTofu provisioniert VMs und LXCs. Ansible übernimmt die Konfiguration. Ein CI-Runner führt Validierung und freigegebene Applies aus. Proxmox Backup Server oder eine andere getestete Backup-Plattform schützt zustandsbehaftete Workloads.

Ich würde nicht mit automatischer Reconciliation jedes Cluster-Objekts beginnen. Automatisieren Sie zuerst die langweilige, wiederholbare Arbeit. Provisionieren Sie eine Test-VM. Bauen Sie sie von Grund auf neu. Fügen Sie Konfiguration hinzu. Beweisen Sie, dass eine zweite Person die Pipeline verstehen kann.

Wenn das funktioniert, erweitern Sie den Scope.

Ein kleines Team mit zehn stabilen VMs braucht vielleicht gar kein GitOps. Die Proxmox-GUI, dokumentierte Abläufe und Backups können ein besseres System sein als eine Automatisierungsplattform, die niemand pflegt. GitOps wird wertvoll, wenn Änderungshäufigkeit, Skalierung oder Recovery-Anforderungen den zusätzlichen Aufwand rechtfertigen.