Installations Proxmox automatisées : Preseed, Cloud‑Init et déploiements reproductibles

Quiconque n’installe pas Proxmox VE une fois pour toutes, mais l’exploite comme plateforme pour de nombreux sites, cycles matériels ou environnements clients connaît le problème central : les installations manuelles génèrent de la dérive. De petites différences dans le partitionnement, le réseau, les versions des paquets ou la configuration des dépôts ne se remarquent souvent que des semaines plus tard – par exemple lors du premier mise à jour du noyau, d’un ZFS-scrub ou lorsqu’un nœud doit être ajouté au cluster.

Les installations Proxmox automatisées visent donc moins à « gagner du temps » qu’à la reproductibilité : chaque hôte est construit de la même manière, les changements sont traçables et les scénarios d’erreur peuvent être débogués de façon cohérente sur plusieurs nœuds. En pratique, la voie passe par deux couches : (1) installation automatisée des hôtes (classiquement via Debian-Preseed ou des procédures unattended comparables) et (2) provisionnement standardisé des VM via Cloud-Init. Les deux se recoupent, mais avec des responsabilités différentes : Preseed décide du disk-layout, du bootloader, de la configuration réseau de base et des sources de paquets ; Cloud-Init prend en charge la configuration initiale à l’intérieur de la VM (SSH-Keys, users, réseau, agents, paquets de base).

Cet article explique les composants, les prérequis et les pièges de manière à ce que des administrateurs moins spécialisés puissent suivre en toute sécurité. L’accent est mis sur l’exploitation : étapes de vérification et de rollback, risques, et une démarche qui reste stable en environnements opérationnels réels.

Pourquoi la reproductibilité échoue si souvent avec les hôtes Proxmox

Proxmox VE est basé sur Debian. Cela semble « standard », mais en pratique cela génère des variantes lorsque les installations sont faites manuellement ou lorsque les médias d’installation ne sont pas versionnés. Sources typiques de dérive :

• Schéma de disque et système de fichiers : ext4 vs. ZFS, tailles de partitions différentes, mix UEFI/BIOS. Cela impacte la récupération, les performances et les mises à jour.
• Réseau : noms de bridge, gestion des VLAN, MTU, bonding (Link Aggregation) – de petites différences entraînent des problèmes L2/L3 difficiles à reproduire.
• État des paquets et dépôts : Proxmox-No-Subscription vs. Enterprise Repo, fonctionnement mixte, absence de règles de pinning. Cela aboutit souvent à des versions incohérentes du noyau / de ZFS.
• Durcissement de la sécurité : politique SSH, 2FA, paramètres par défaut du pare-feu. Sans standardisation, les nœuds présentent des niveaux de durcissement différents et sont donc exposés de manière inégale.
• Paramètres de cluster : Corosync (communication de cluster) réagit fortement à la dérive temporelle (NTP), au MTU et aux pertes de paquets. Des valeurs par défaut différentes sont risquées ici.

Des déploiements reproductibles signifient donc : vous définissez un standard de référence pour les hôtes (disk, boot, net, repos, time) et un standard pour les VM (Images, Cloud-Init-User-Data, agents, Policies). Tout ce qui n’est pas défini finira très probablement par provoquer des surprises en production.

Composants : Preseed pour l’installation des hôtes, Cloud-Init pour la couche VM

Termes brièvement positionnés : Preseed est une technique Debian permettant de piloter l’installateur via un fichier de réponses automatisé (« unattended install »). Vous y définissez par exemple la locale, le réseau, le partitionnement et la sélection de paquets. Cloud-Init est un service d’initialisation à l’intérieur d’une VM qui, au premier démarrage, lit et applique une configuration depuis une source de données (p. ex. une ISO « NoCloud », Proxmox Cloud-Init Drive, ou un service de métadonnées). Cloud-Init n’est pas spécifique à Proxmox, mais Proxmox l’intègre très bien via des templates.

Important pour l’architecture : Preseed déploie les hôtes Proxmox ; Cloud-Init déploie les machines invitées. Qui tente de résoudre des problèmes d’hôte (p. ex. bridge incorrect, options ZFS inappropriées) avec Cloud-Init ne fait que déplacer le problème. Inversement, Preseed ne remplace pas une standardisation propre des VM.

Prérequis et décisions de conception (avant la première exécution d’automatisation)

1) Définir le standard matériel et de démarrage

Décidez tôt si vous imposez UEFI partout ou si vous tolérez BIOS/Legacy. Un fonctionnement mixte est possible, mais augmente la variance du chargeur de démarrage et des scénarios de secours. Vérifiez aussi : NVMe vs. SATA, contrôleur RAID vs. HBA (Host Bus Adapter) et si vous souhaitez utiliser ZFS. ZFS est un système de fichiers Copy-on-Write avec vérification de sommes intégrée ; il est robuste pour l’intégrité des données, mais exige une planification cohérente de la RAM et des disques.

2) Définir la baseline réseau

Proxmox travaille généralement avec Linux Bridges (commutateur de niveau 2 sur l’hôte), p. ex. vmbr0. Pour les environnements de production, vous devez définir : schéma de nommage (vmbr0, vmbr1), stratégie VLAN (tagged/untagged), MTU (p. ex. 1500 vs. Jumbo Frames) et mode de bonding (p. ex. LACP/802.3ad) incluant les exigences côté switch. Ne pas normaliser cela en amont entraîne plus tard des problèmes de migration à chaud ou une accessibilité asymétrique.

3) Repository et politique de mises à jour

Légal et répandu : utilisation du Proxmox-No-Subscription-Repository. L’essentiel est que tous les nœuds appliquent la même politique. Assurez-vous également que l’heure (NTP/Chrony) et le DNS sont cohérents ; Corosync et les certificats sont sensibles à la dérive temporelle.

4) Secrets, accès et auditabilité

L’automatisation échoue souvent sur la question « comment les mots de passe/clefs arrivent dans le système ». Pragmatique : pour l’installation des hôtes, préférez travailler avec des mots de passe d’installation temporaires (ou injecter des clés SSH ensuite) et appliquer les politiques définitives ensuite via un gestionnaire de configuration (p. ex. Ansible). Documentez où se trouve la source de vérité : dépôt Git pour Preseed/Cloud-Init, stockage d’artefacts pour les images, et un processus de changement pour les mises à jour.

Preseed en pratique : comment naît une installation d’hôte non supervisée

L’image visée : un nœud démarre depuis une ISO ou via PXE, charge un fichier Preseed et installe Proxmox VE sans interaction selon une configuration définie. Pour Proxmox il existe plusieurs méthodes, mais Preseed est une approche éprouvée pour les installations basées sur Debian, notamment si vous souhaitez contrôler strictement le layout du système d’exploitation.

Contenu typique d’un Preseed (et pourquoi c’est important opérationnellement)

• Partitionnement : une disposition de disques reproductible est la base pour le monitoring (seuils d’alerte disque), les mises à niveau et la récupération. Tout particulièrement avec ZFS, l’environnement de démarrage correct est important.
• Réseau : IP statiques vs. DHCP. Pour un cluster, l’adressage statique est courant, au minimum pour le management/Corosync. Le DHCP est possible, mais risqué si les baux changent.

Processus minimal: démarrer depuis ISO/PXE, charger le Preseed, Post-Install

Un schéma éprouvé est le suivant : Preseed réalise l’installation de base de Debian, puis un script Post-Install exécute la configuration des paquets Proxmox, des dépôts, des paramètres du noyau et de la configuration de base. Le Post-Install est important car il permet de versionner les détails spécifiques à Proxmox sans modifier l’installateur.

Exemple : un script Post-Install très simplifié comme modèle de réflexion (pas « one size fits all »). Il établit la politique de dépôts, installe les paquets Proxmox, démarre les services et écrit des fichiers de base. En pratique, vous ajouterez des contrôles, du logging et de la gestion d’erreurs.

#!/usr/bin/env bash
set -euo pipefail

# Baseline: eindeutiges Logging
exec > >(tee -a /var/log/proxmox-bootstrap.log) 2>&1

echo "[+] Setze APT-Quellen (No-Subscription als Beispiel)"
cat > /etc/apt/sources.list.d/pve-no-subscription.list <<'EOF'
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
EOF

echo "[+] Optional: Enterprise-Repo deaktivieren, falls vorhanden"
if [ -f /etc/apt/sources.list.d/pve-enterprise.list ]; then
  sed -i 's/^deb/# deb/' /etc/apt/sources.list.d/pve-enterprise.list
fi

echo "[+] Paketindex aktualisieren"
apt-get update

echo "[+] Proxmox VE installieren (Beispielpakete)"
apt-get -y install proxmox-ve postfix open-iscsi chrony

echo "[+] Zeitdienst aktivieren"
systemctl enable --now chrony

echo "[+] Baseline-Checks"
pveversion -v || true
ip -brief addr || true

echo "[+] Fertig"

Pourquoi ce schéma fonctionne : Preseed vous évite l’installation interactive, le Post-Install place la politique Proxmox souhaitée dans un artefact versionnable. Pourquoi cela peut échouer : le réseau/DNS n’est pas encore stable, les miroirs sont inaccessibles, ou la disposition des disques ne correspond pas à votre matériel (p. ex. des noms de périphériques qui changent).

Pièges courants avec Preseed (et comment les atténuer)

• Les noms de périphériques ne sont pas stables: /dev/sda peut devenir /dev/sdb demain. Solution : autant que possible, travailler à partir des WWN/numéros de série ou de by-id. Si cela n’est pas possible, vous devrez standardiser davantage la conception matérielle.
• UEFI vs. BIOS: Un nœud en mode incorrect entraîne des problèmes de démarrage ou une gestion manquante de la partition système EFI. Solution : standardiser les réglages du BIOS et les vérifier à l’avance via une liste de contrôle.
• Pilotes/Firmware: L’installateur ne voit pas la NIC ou le HBA. Solution : définir des standards de firmware, éventuellement adapter le média d’installation ou patcher au préalable via Out-of-Band (IPMI/iDRAC/iLO).
• Course réseau: Preseed/Post-Install attend le réseau, mais le lien n’est pas encore up ou le VLAN est incorrect. Solution : réseau d’installation aussi simple que possible (untagged), activer les bonds/VLANs complexes uniquement après la mise en place de base.

Cloud-Init dans Proxmox: rendre les déploiements de VM reproductibles

Lorsque l’hôte est standardisé, intervient la deuxième couche : les VMs doivent être créées à partir de templates et recevoir, au premier démarrage, des paramètres définis. Cloud-Init est précisément conçu pour cela. Sous Proxmox, on crée typiquement un VM-Template (p. ex. compatible Debian/Ubuntu/Alma/RHEL), on active Cloud-Init, et on clone des VMs à partir de ce template. Proxmox crée alors un disque Cloud-Init contenant les Metadata/User-Data.

Ce que Cloud-Init peut faire de manière fiable (et ce qu’il ne peut pas)

• Peut : nom d’hôte, clés SSH, utilisateurs, configuration réseau, paquets de base, premières commandes (« runcmd »), paramètres proxy.
• Peut de façon limitée : agencement de stockage complexe dans la VM (possible, mais sujet aux erreurs si les images varient).
• Ne peut pas : remplacer la configuration Proxmox côté hôte (bridges, backends de stockage, configuration du cluster).

Exemple : User-Data Cloud-Init comme profil standardisé

Ce YAML est conçu comme un exemple explicite. Il montre : utilisateurs, clé SSH, base de paquets et premières étapes de durcissement. L’idempotence est importante : Cloud-Init s’exécute principalement au premier démarrage ; néanmoins le résultat doit être net et stable, même si une VM est RESTaurée à partir d’un snapshot.

#cloud-config
preserve_hostname: false
hostname: vm-standard
manage_etc_hosts: true

users:
  - name: ops
    groups: [sudo]
    shell: /bin/bash
    sudo: ["ALL=(ALL) NOPASSWD:ALL"]
    ssh_authorized_keys:
      - "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... ops@example"

disable_root: true
ssh_pwauth: false

package_update: true
package_upgrade: false
packages:
  - qemu-guest-agent
  - chrony
  - curl
  - ca-certificates

runcmd:
  - [ systemctl, enable, --now, qemu-guest-agent ]
  - [ systemctl, enable, --now, chrony ]
  - [ sh, -c, "sed -i 's/^#PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config" ]
  - [ systemctl, RESTart, ssh ]

Pourquoi cela compte en exploitation : le QEMU Guest Agent permet à Proxmox de contrôler proprement les adresses IP et les arrêts ; sans agent, les fenêtres de maintenance et l’automatisation deviennent rapidement peu fiables. Chrony stabilise l’horloge dans les VMs ; cela réduit les erreurs liées à TLS, à l’intégration Kerberos/AD ou aux applications en cluster.

Pièges typiques de Cloud-Init sous Proxmox

• Cloud-Init n’est pas installé dans l’image : la VM ignore alors le User-Data. Solution : garantir la qualité du template, tester avant mise en production.
• Conflits de rendu réseau : selon la distribution, netplan, NetworkManager ou ifupdown interviennent. Solution : définir une ligne standard par OS et configurer Cloud-Init en conséquence.
• Accès SSH interrompu : clés incorrectes, utilisateur erroné, pare-feu dans la VM. Solution : tester l’accès console via Proxmox, analyser les logs de Cloud-Init.

Déploiements reproductibles comme processus : artefacts, gestion des versions, vérifications

L’automatisation n’est opérationnellement robuste que si vous traitez le processus comme une chaîne d’approvisionnement : les entrées sont versionnées, les résultats vérifiables, et les erreurs entraînent des arrêts nets plutôt que des hôtes/VMs à moitié configurés.

Artefacts que vous devriez versionner explicitement

• Fichier Preseed et toutes les références (scripts pré/post-installation, listes de paquets).
• VM-Templates (source de l’image, date de build, version Cloud-Init). Idéalement en tant que « Golden Image » : une image de base approuvée par version d’OS.
• Profils Cloud-Init (User-Data, Network-Data, Vendor-Data si utilisé).
• Runbooks : étapes d’installation et de récupération, y compris les commandes de vérification.

Étapes de vérification : ce que vous devez automatiser après chaque déploiement d’hôte

Une checklist pratique que vous pouvez implémenter comme script ou pipeline :

• Version du kernel/Proxmox conforme aux attentes (pas d’états mixtes dans le cluster).
• Storage-Basis : ZFS-Pool présent/healthy ou LVM-Thin correctement monté ; pas de périphériques défectueux.
• Réseau : Bridge up, VLAN/MTU corrects, IP de management joignable, DNS/NTP ok.
• Services de base : pvedaemon/pveproxy en cours d’exécution ; service de temps synchronisé.
• Minimum de sécurité : politique SSH, accès root conforme à la politique, paramètres firewall par défaut (côté hôte) documentés.

Exemple : un petit check d’état d’hôte, facile à intégrer dans un runbook (la sortie est volontairement lisible par l’humain, pas parfaitement « machinable »).

#!/usr/bin/env bash
set -euo pipefail

fail=0

check() {
  local name="$1"; shift
  echo "==> $name"
  if "$@"; then
    echo "OK"
  else
    echo "FAIL"
    fail=1
  fi
  echo
}

check "Proxmox-Version" pveversion
check "Services" systemctl is-active pveproxy
check "Zeitstatus" chronyc tracking
check "Netzwerk (Kurz)" ip -brief addr

# ZFS optional
if command -v zpool >/dev/null 2>&1; then
  check "ZFS Pool" zpool status
fi

exit "$fail"

PXE, ISO ou « hands off » via Out-of-Band : quelle stratégie de boot convient ?

Pour les installations Proxmox automatisées, il existe plusieurs canaux de transport pour la mise en place. Le choix dépend moins de la technique que de la réalité opérationnelle (sites distribués, Remote Hands, contraintes de sécurité) :

• ISO avec Preseed : mise en œuvre rapide, adaptée aux petits environnements. Risque : « dérive des clés USB » — quelqu’un utilise un ancien ISO.
• PXE-Boot (démarrage réseau) : contrôle centralisé, idéal pour un grand nombre d’hôtes. Prérequis : infrastructure réseau/DHCP/TFTP/HTTP et segmentation claire.
• Médias virtuels hors bande (IPMI/iDRAC/iLO) : pratique pour des sites distants. Risque : firmwares différents, médias virtuels instables, lenteur.

Bonnes pratiques : quel que soit le procédé — assurez-vous que les versions de l’installateur et des Preseed/Script soient couplées (p. ex. via des URL fixes avec chemin de version) et que l’on puisse identifier de façon unique dans les logs avec quoi un hôte a été construit.

Dépannage : lorsque l’automatisation était « verte », mais que l’hôte ne fonctionne pas correctement

Une erreur fréquente : « installation unattended » ne vaut pas automatiquement « correct ». Les erreurs typiques n’apparaissent qu’au moment de la jonction au cluster, sous charge stockage ou au premier redémarrage. Une méthodologie de diagnostic structurée permet d’économiser des heures.

Symptôme 1 : le nœud ne démarre pas (après installation sans surveillance)

• Cause : incompatibilité UEFI/BIOS, chargeur d’amorçage mal installé, mauvais disque choisi.
• Vérification : mode de démarrage dans le BIOS, ordre d’amorçage, démarrage en rescue et contrôle des partitions.
• Mesure corrective : standardisez le mode de démarrage, forcez la sélection du disque via des identifiants stables ; consignez dans l’installateur la décision de périphérique.
• Repli : installation manuelle selon la baseline, puis appliquer le script post-install identique afin de minimiser la dérive.

Symptôme 2 : problèmes de cluster après le déploiement (Corosync instable)

• Cause : dérive horaire, MTU/VLAN incohérents, perte de paquets, liaisons d’interface réseau incorrectes.
• Vérification : statut NTP/Chrony, MTU sur toutes les interfaces concernées, configuration des switches, compteurs d’erreurs de lien.
• Mesure corrective : planifier un réseau Corosync séparé, maintenir une MTU cohérente, considérer NTP comme indispensable dans le Preseed/Post-Install.

Symptôme 3 : Cloud-Init est ignoré

• Cause : Cloud-Init absent dans le template, datasource incorrecte, mauvais device (Cloud-Init Drive non attaché).
• Vérification : consulter les logs Cloud-Init dans la VM, vérifier l’état des paquets, onglet matériel de Proxmox : Cloud-Init Drive présent ?
• Mesure corrective : processus de release du template : « Cloud-Init-Selftest » avant mise en production (cloner une fois, démarrer, vérifier SSH et l’agent).

Stratégie de rollback et de repli : comment RESTer opérationnel

L’automatisation sans plan de repli est risquée, car en cas d’échec vous ne perdez pas seulement « une machine » mais potentiellement tout un rollout. Une stratégie opérationnelle pratique se compose de trois niveaux :

• Niveau 1 : critères d’abandon : l’installation doit échouer immédiatement si des prérequis centraux manquent (DNS, repo, disk layout). Pas d’hôtes « à moitié installés » en production.
• Niveau 2 : rebuild plutôt que repair : si la construction d’un nœud est incohérente, réinstaller est souvent plus rapide et plus sûr que déboguer dans une dérive en cours d’exécution.
• Niveau 3 : repli versionné : conservez la dernière version Preseed/template connue bonne. Les rollouts s’effectuent par vagues (Canary-Node en premier).

Pour les VM en plus : si le provisioning Cloud-Init échoue au premier démarrage, « supprimer la VM et la re-cloner » est dans de nombreux environnements l’option la plus propre — à condition que les données applicatives ne résident pas sur le disque root de la VM, mais sur des disques/volumes séparés ou soient gérées via des sauvegardes/processus de RESTauration.

Bonnes pratiques issues de l’exploitation : ce qui aide vraiment à long terme

Traiter les templates comme des releases

Un VM-Template est un artefact comme un paquet : vous avez besoin d’un état de version, d’un changelog (quels paquets, quel noyau, quel état de Cloud-Init) et d’un court test d’acceptation. Sans cela, c’est le chaos des «Golden Image» : personne ne sait quel template a quelles particularités.

Limiter les modifications et les mesurer

Surtout avec Proxmox, les modifications au niveau de l’hôte (noyau, ZFS, pilotes NIC) ont un impact opérationnel. Ne déployez pas «tout d’un coup». Utilisez d’abord un Canary-Node, validez le stockage (Scrub/IO), le réseau (MTU/VLAN) et les migrations, puis seulement la large échelle.

Documentation sous forme de Runbook plutôt que texte continu

Pour les équipes d’administration, en cas d’incident c’est la procédure qui compte : «Si X, alors Y». Maintenez donc un Runbook avec des points de contrôle fixes et des critères d’arrêt clairs. Si vous élaborez déjà des documents opérationnels spécifiques à Proxmox : des contenus comme le design de stockage (ZFS/Ceph/LVM-Thin), le dépannage du démarrage des VM et les parcours de mise à niveau s’intègrent bien comme liens internes dans votre système de connaissances.

Conclusion : les installations Proxmox automatisées sont moins affaire d’outillage que de discipline

Les installations Proxmox automatisées fonctionnent durablement si vous séparez proprement la couche hôte et la couche VM : Preseed (plus Post-Install) rend l’hôte reproductible, Cloud-Init rend les déploiements de VM reproductibles. Ce qui compte, ce ne sont pas les 30 premières minutes d’installation, mais les mois qui suivent : mises à jour uniformes, comportement de stockage et réseau cohérent, et mécanisme de rollback clair.

Si vous mettez cela en place comme un processus – avec des artefacts versionnés, des tests d’acceptation pour les templates, des Canary-Rollouts et une stratégie de repli «reconstruire plutôt que réparer» – la dérive se réduit sensiblement. Et si un node tombe en panne, vous pouvez non seulement le remplacer, mais le remplacer de manière démontrable identique.

Pour ce sujet, Proxmox Ve Unattended Install et Debian Preseed sont également importants. Cet article situe ces aspects de façon compréhensible et montre ce qui compte au quotidien.