Mettre à jour les nœuds d’un cluster Proxmox VE peut devenir une opération délicate, surtout lorsqu’il y a des machines virtuelles en cours d’exécution, des fenêtres de maintenance limitées et plusieurs serveurs à redémarrer un par un. ProxPatch, un projet open source développé par gyptazy, automatise ce processus : il vérifie l’état du cluster, migre les machines virtuelles, applique les mises à jour, redémarre les nœuds si nécessaire et passe au serveur suivant.

Les principaux atouts de ProxPatch en 20 secondes

• Automatise les mises à jour en rolling des nœuds Proxmox VE.
• Migre les machines virtuelles avant toute intervention sur un serveur.
• Utilise des outils natifs comme pvesh, qm et SSH.
• Requiert un minimum de trois nœuds, un quorum stable et un stockage partagé.
• Le projet est encore en phase expérimentale et recommande des tests préalables avant déploiement.

L’objectif est de simplifier une tâche précise d’administration : maintenir à jour les nœuds d’un cluster en limitant l’intervention manuelle et en évitant les interruptions superflues. ProxPatch ne vise pas à remplacer les fonctionnalités de haute disponibilité de Proxmox VE ni à devenir une solution complète de gestion de l’ensemble du cycle de vie de l’infrastructure.

De la déconnexion d’un nœud à sa remise en service

Le fonctionnement de ProxPatch reproduit le même processus qu’un administrateur exécuterait manuellement. La plateforme vérifie l’état du cluster et, lorsqu’une intervention est nécessaire sur un nœud, elle coordonne la migration des machines virtuelles hébergées dessus.

Une fois que le nœud est prêt pour la maintenance, ProxPatch applique les mises à jour via SSH. Ensuite, il détermine si un redémarrage est nécessaire, en contrôle le processus jusqu’à ce que le serveur soit de nouveau opérationnel. Ce n’est qu’à ce moment qu’il enchaîne avec le nœud suivant.

La différence réside dans le fait que ces opérations sont intégrées dans un flux automatisé. Le but déclaré est de privilégier la sécurité plutôt que la vitesse, de maintenir le cluster en fonctionnement et de rendre le processus observable et facile à auditer.

L’outil utilise des composants classiques de Proxmox VE, notamment pvesh, qm et SSH, sans dépendre d’une plateforme d’orchestration externe. Le dépôt indique également qu’il ne nécessite pas de bases de données externes ni de tokens API. Il faut simplement que jq soit installé sur la machine d’où s’exécute l’automatisation pour traiter les réponses JSON.

Ce design réduit la complexité de l’infrastructure et facilite la compréhension du comportement de ProxPatch pour un administrateur familier avec Proxmox et ses outils en ligne de commande.

Préparer le cluster à la migration

L’automatisation ne supprime pas les prérequis techniques nécessaires pour réaliser un entretien en rolling. La documentation de ProxPatch impose un minimum de trois nœuds et exige que le cluster conserve le quorum tout au long du processus.

Elle recommande également l’utilisation d’un stockage partagé, tel que Ceph ou NFS, pour permettre la migration à chaud des machines virtuelles. L’accès SSH avec authentification par clé est la méthode privilégiée pour sécuriser la connexion entre les nœuds.

Ces conditions sont essentielles car ProxPatch doit pouvoir transférer les charges sur un autre nœud avant d’effectuer la mise à jour. En cas d’insuffisance de capacité, d’impossibilité de migrer une VM ou de stockage inadéquat, l’automatisation ne pourra pas compenser cette limitation seule.

L’installation est conçue pour être effectuée depuis un seul nœud du cluster. Le projet insiste sur le fait que le service proxpatch ne doit pas être lancé simultanément sur plusieurs nœuds. Il est possible d’installer ProxPatch via le dépôt Debian de gyptazy ou d’utiliser des paquets Debian précompilés.

La configuration initiale est simplifiée : dans la majorité des cas, il n’est pas nécessaire de créer un fichier supplémentaire. Cependant, un fichier /etc/proxpatch/config.yaml existe pour ajuster certains paramètres. Après installation, le processus peut être lancé via le service systemd fourni.

La compatibilité mentionnée concerne Proxmox VE 8.x et 9.x. Son usage repose ainsi sur une infrastructure qui respecte les prérequis pour maintenir le quorum et réaliser les migrations.

ProxPatch, un projet séparé de ProxLB

Ce projet est lié à ProxLB, une autre solution développée par gyptazy pour faire du load balancing au sein des clusters Proxmox. L’idée initiale était d’intégrer le patching rolling à ProxLB, mais l’absence de certains endpoints dans l’API Proxmox pour gérer mises à jour et redémarrages a conduit à développer ProxPatch comme un outil autonome.

Il s’agit d’un projet spécialisé dans une seule opération. Bien qu’il puisse être utilisé conjointement avec ProxLB, il ne dépend pas de celui-ci. Cette séparation évite également de transformer un outil de load balancing en une plateforme de gestion globale des nœuds.

Cela a une importance pour les administrateurs, car ProxPatch ne vise pas à remplacer les bonnes pratiques existantes : sauvegardes, surveillance, tests en staging, gestion de la configuration ou procédures de récupération. La responsabilité de ces aspects reste entre les mains de l’environnement d’exploitation.

Le dépôt lui-même souligne que le logiciel est encore en phase de développement précoce et doit être considéré comme expérimental. Il recommande vivement de réaliser des tests approfondis en laboratoire ou en environnement de staging avant toute utilisation en production.

Ce warning est crucial étant donné la nature sensible des tâches automatisées : migration, redémarrage, mises à jour critiques, machines virtuelles aux exigences particulières. Une erreur ou un comportement imprévu pourrait transformer une opération banale en incident majeur.

L’intérêt de ProxPatch ne réside pas tant dans la suppression de l’intervention humaine, mais dans la standardisation d’un processus répétitif. Si l’infrastructure remplit les conditions, cet outil peut gérer une séquence complète — vérifier l’état du cluster, migrer les charges, appliquer les mises à jour, redémarrer et valider — sans intervention manuelle à chaque étape.

Ce besoin s’inscrit dans une réalité fréquente en virtualisation : alors que les fonctions fondamentales sont souvent présentes, certaines opérations nécessitent des outils spécifiques. ProxPatch concerne la mise à jour en rolling des nœuds uniquement, évitant de s’éparpiller sur d’autres fonctionnalités pour rester focalisé sur son objectif.

Son évolution dépendra de la robustesse du code, des tests effectués et de sa capacité à gérer des cas plus exceptionnels que dans une configuration idéale. Pour un outil agissant directement sur des serveurs et machines virtuelles, il est indispensable de faire preuve de prudence et de réaliser des tests approfondis, tout comme pour toute automatisation critique.

Questions fréquentes

Qu’est-ce que ProxPatch ?
ProxPatch est un outil open source permettant d’automatiser les mises à jour en rolling dans les clusters Proxmox VE. Il migre les VM, applique les patchs et redémarre les nœuds si nécessaire.

ProxPatch évite-t-il les interruptions de service ?
Conçu pour maintenir la disponibilité des charges en utilisant la migration à chaud, mais cela dépend de la disponibilité du quorum, des capacités du cluster et du stockage compatible.

De combien de nœuds ProxPatch a-t-il besoin ?
La documentation mentionne un minimum de trois nœuds et insiste sur le maintien du quorum tout au long du processus.

ProxPatch est-il prêt pour la production ?
Le dépôt le considère encore comme un projet expérimental en phase initiale. Il recommande de l’expérimenter d’abord dans des environnements de test ou de staging avant toute utilisation en production.