ProxPatch : mise à jour rolling automatisée de Proxmox

Patcher un Proxmox seul, c’est apt full-upgrade et un reboot. Patcher dix clusters de cinq à huit noeuds chacun, c’est la même opération répétée cinquante fois : drainer le noeud, migrer les VM, mettre à jour, redémarrer, attendre que le quorum revienne, passer au suivant. C’est long, mécanique, et c’est exactement le genre de tâche où on finit par oublier une étape.

ProxPatch automatise ce rouleau. C’est un outil écrit en Rust par gyptazy (l’auteur de ProxLB ), qui fait une seule chose : la mise à jour rolling d’un cluster Proxmox VE, sans interrompre les charges qui tournent.

Le problème qu’il règle#

Quand on maintient plusieurs clusters avec beaucoup de noeuds, la mise à jour manuelle ne pose pas de difficulté technique : elle pose un problème de temps et de constance. Chaque noeud demande la même séquence, et plus il y en a, plus la probabilité d’enchaîner deux reboots avant que le quorum soit revenu augmente. C’est là qu’on casse un cluster.

ProxPatch enlève cette charge. On l’installe, on l’active, et il déroule la procédure correcte sur chaque noeud, dans l’ordre, en validant l’état du cluster entre chaque étape. Le gain n’est pas dans la rapidité brute (il prend son temps, c’est voulu), il est dans le fait de ne plus avoir à surveiller l’opération.

Comment ça marche#

Le flux est volontairement simple et auditable. Pas de base de données, pas de token API, pas de framework d’orchestration : il s’appuie uniquement sur les outils Proxmox natifs (pvesh, qm, SSH) et la relation de confiance SSH déjà présente entre les noeuds d’un cluster.

À chaque cycle, ProxPatch exécute deux passes :

Passe 1 — Préparation (tous les nœuds, sans redémarrage)#

Inventaire via pvesh : ressources des nœuds, VM en cours et leur consommation mémoire.
Ce n’est pas qu’un simple apt update : c’est un apt dist-upgrade via SSH sur chaque nœud : apt-get update && DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade.
Détection du flag /var/run/reboot-required pour savoir si un noyau (ou autre) impose un redémarrage.

Passe 2 — Rolling reboot (uniquement les nœuds qui en ont besoin)#

Pour chaque nœud nécessitant un reboot : calcul d’un plan de migration, puis évacuation à chaud des VM (pvesh create /nodes/NODE/qemu/VMID/migrate -target TARGET -online 1 -with-local-disks 1).
Contrôle de santé : tous les nœuds online et quorum sain. Si le cluster est dégradé, ProxPatch s’arrête sans redémarrer.
Reboot du nœud, attente de son retour, vérification de réintégration au cluster, nouveau contrôle de santé avant de passer au suivant.

Si ProxLB est installé, il est stoppé pendant le patching puis relancé à la fin, pour éviter qu’il rejoue un rééquilibrage en plein milieu.

Pré-requis : un cluster PVE 8.x ou 9.x, au moins trois noeuds, le quorum maintenu pendant l’opération, du stockage partagé (Ceph, NFS) pour la migration à chaud, un accès SSH par clé sans mot de passe entre noeuds, et jq installé sur le noeud qui fait tourner ProxPatch.

Un point à connaître : ProxPatch est un démon. Une fois le service systemd démarré, il reboucle automatiquement toutes les six heures. L’intervalle est codé en dur dans le binaire et n’est pas configurable pour l’instant (ni dans le fichier de configuration, ni via un flag). Ce n’est pas un cron qu’on déclenche, c’est un processus qui patche en continu. À garder en tête pour la suite.

Installation#

ProxPatch s’installe sur un seul noeud du cluster. Depuis ce noeud, il découvre les autres via SSH et orchestre l’ensemble à distance. Ne pas activer le service sur plusieurs noeuds en même temps : deux instances simultanées sur le même cluster, c’est la panne assurée.

En ligne (recommandé) : dépôt APT#

bash
# Ajout du dépôt officiel gyptazy
curl https://git.gyptazy.com/api/packages/gyptazy/debian/repository.key \
  -o /etc/apt/keyrings/gyptazy.asc

echo "deb [signed-by=/etc/apt/keyrings/gyptazy.asc] \
  https://packages.gyptazy.com/api/packages/gyptazy/debian trixie main" \
  | tee -a /etc/apt/sources.list.d/gyptazy.list

apt-get update
apt-get install -y proxpatch

Remplacer trixie par bookworm selon la version de Proxmox.

Hors-ligne (airgap) : paquet .deb#

Sur un cluster isolé d’Internet, on récupère le .deb depuis https://cdn.gyptazy.com/debian/proxpatch/ ou depuis le dépôt GitHub de ProxPatch sur une machine connectée, on le transfère sur un nœud cible, puis on lance l’installation :

bash
# depuis une machine avec accès Internet
wget https://cdn.gyptazy.com/debian/proxpatch/proxpatch_0.1.2_amd64.deb

# transfert vers le noeud cible
scp proxpatch_0.1.2_amd64.deb root@pve-node01:/root/

# installation sur le noeud
dpkg -i proxpatch_0.1.2_amd64.deb

Le paquet dépend de jq. Sur un Proxmox il n’est pas toujours présent, et en environnement déconnecté dpkg ne le tirera pas tout seul. On l’embarque aussi (apt-get download jq côté machine connectée, puis dpkg -i), ou on vérifie au préalable (which jq).

Une configuration ?#

Dans le cas standard, aucune config n’est nécessaire : ProxPatch se connecte en root via la confiance SSH du cluster et découvre les noeuds tout seul.

Si on ne veut pas utiliser root, on peut créer /etc/proxpatch/config.yaml :

yaml
ssh_user: proxpatch
deactivate_proxlb: true

Avec un ssh_user défini, les commandes passent par sudo. L’utilisateur doit donc avoir un sudo sans mot de passe et un accès SSH à tous les noeuds. Un sudoers minimal :

bash
User_Alias  PROXPATCH = proxpatch
Cmnd_Alias  PROXPATCH_CMDS = \
    /usr/bin/pvesh create *, \
    /usr/bin/apt-get update, \
    /usr/bin/apt-get -y dist-upgrade, \
    /usr/sbin/reboot, \
    /sbin/reboot
PROXPATCH ALL=(root) NOPASSWD: PROXPATCH_CMDS

Attention à un détail : depuis la 0.1.2, l’unité systemd ne charge pas de fichier de config par défaut (ExecStart=/usr/bin/proxpatch, sans -c). Créer le YAML ne suffit donc pas, il faut pointer dessus. Le plus propre est un drop-in :

bash

systemctl edit proxpatch

ini
[Service]
ExecStart=/usr/bin/proxpatch -c /etc/proxpatch/config.yaml

Clusters sensibles : on coupe l’automatisme#

C’est le point important. ProxPatch est encore jeune (versions 0.1.x) et l’auteur le qualifie lui-même d’expérimental, à valider en lab avant toute prod. Couplé au fait que c’est un démon qui patche en continu toutes les six heures, ça veut dire qu’un noeud peut se mettre à jour et redémarrer sans intervention humaine.

Pour un homelab ou un cluster de test, c’est exactement ce qu’on veut. ProxPatch est super pour les clusters de dev et de qualif : il automatise la mise à jour rolling et permet de voir si tout fonctionne bien avant de passer en production. Pour un cluster critique, non. Sur ces clusters, on installe le paquet pour avoir le binaire à disposition, mais on coupe l’automatisme :

bash

systemctl disable proxpatch && systemctl stop proxpatch

On garde ainsi la main : on lance ProxPatch manuellement quand on a planifié la maintenance, on l’observe, et il ne se réveille jamais tout seul pour redémarrer un noeud à 3 h du matin un jour de prod.

bash
# lancement manuel ponctuel, en mode debug pour suivre le déroulé
/usr/bin/proxpatch -d

Note : même lancé directement, le binaire entre dans sa boucle (6 h par défaut). Pour un run strictement ponctuel, surveillez et interrompez le processus une fois le cycle terminé.

En résumé#

ProxPatch fait bien une chose : il déroule une mise à jour rolling correcte sur un cluster Proxmox, en migrant les VM et en vérifiant le quorum entre chaque reboot. Sur un parc avec beaucoup de noeuds, c’est du temps et de la charge mentale en moins.

Trois réflexes à retenir :

il s’installe sur un seul noeud par cluster
sur les clusters critiques, faites systemctl disable proxpatch && systemctl stop proxpatch pour garder le déclenchement sous contrôle humain
redémarrez régulièrement vos noeuds pour profiter des mises à jour kernel, selon la criticité de votre infrastructure et des mises à jour de sécurité

Aujourd’hui, j’utilise ProxPatch sur mon cluster personnel et sur quelques clusters de test et de développement au travail. Je n’ai pas rencontré de problème majeur avec ProxPatch. J’ai gagné en temps et en tranquillité d’esprit. Plutôt que passer une journée à gérer les mises à jour manuellement, je peux me concentrer sur d’autres tâches, pendant que mes machines se mettent à jour sans mon intervention.

Sources#

https://github.com/gyptazy/proxpatch