Déploiement technique d’une VM AJLSM

Déploiement technique d’une VM AJLSM

Document du 16 octobre 2026. Référence : scripts reçus de Saturne3, puis lot de recette avec lanceur du cycle et assistant YAML.

1. Périmètre et résultat de la recette

Le cycle technique a été exécuté sur MERCURE3 sans erreur signalée. Les vérifications finales transmises confirment :

• connexion SSH avec le compte ajlsm ;
• élévation sudo avec le mot de passe défini pendant le cycle ;
• hostname mercure3.ajlsm.com ;
• volume racine ext4 de 97 Gio, dont 85 Gio disponibles lors du contrôle.

Le cycle couvre le clonage, les ressources, l’initialisation du clone, l’extension de la racine, l’identité système, le réseau, SSH, le mot de passe et le certificat TLS interne.

NFS, les configurations applicatives Apache2, Pleade, Drupal et Matomo ne font pas encore partie de ce cycle. Certains logiciels peuvent déjà être présents dans le modèle : leur présence ne constitue pas une configuration applicative du projet.

2. Où exécuter les commandes

Machine	Rôle	Exemple d’invite
Mac de l’administrateur	Transfert des archives par scp	Invite locale du Mac
Saturne3	Préparation YAML, scripts Proxmox et cycle	root@Saturne3
MERCURE3	Vérifications dans la VM	ajlsm@mercure3 ou root@mercure3

Les scripts de déploiement sont exécutés sur Saturne3, pas dans MERCURE3. Après « ssh ajlsm@10.0.0.43 », attendre l’invite de la VM avant de saisir les commandes suivantes. Pour revenir de root@mercure3 à Saturne3 : un exit quitte sudo, puis un second exit ferme SSH.

3. Organisation des fichiers

/root/ajlsm-deploy/
  archives/                         Archives reçues, conservées comme références
  recettes/20261016/
    ajlsm-deploy-cycle/             Lot technique validé et assistant ajouté
    ajlsm-deploy-assistant/         Distribution de l’assistant et tests
    ajlsm-deploy-documentation/     Présent guide et modèles YAML

/etc/ajlsm/deploy/projets/mercure3.yaml   Configuration actuellement utilisée
/usr/local/sbin/                        Scripts installés antérieurement

Le lot de recette contient ajlsm-deploy, ajlsm-deploy-check, ajlsm-deploy-resources, ajlsm-deploy-cycle et les modules ajlsm_deploy_common.py, ajlsm_deploy_rootgrow.py et ajlsm_deploy_postconfig.py. L’assistant ajlsm-deploy-yaml a été ajouté à ce même dossier.

Conserver exécutables et modules ensemble. Utiliser les chemins ./ depuis le dossier de recette pour ne pas appeler une ancienne version de /usr/local/sbin. Les anciennes archives « ajlsm-deploy-revise » et « correction-suggestions » ne sont pas la référence courante : elles précèdent les phases supplémentaires reçues dans l’archive serveur.

Prérequis : Python 3.9 ou supérieur, PyYAML 6, outils Proxmox sur le nœud cible et prérequis du modèle AJLSM. Les phases invitées utilisent notamment l’agent QEMU, ajlsm-clone-init, Python, systemd et Netplan. L’extension actuelle cible ext4/LVM sur /dev/sda3, avec un seul PV et un seul LV.

4. Les deux fichiers de préconfiguration

4.1. projet-vierge.yaml

Ce modèle reprend toute la structure actuelle sans valeur opérationnelle préremplie. Chaque champ doit être renseigné. Seul proxmox.vmid peut rester null : il signifie alors attribution automatique.

Le modèle comporte deux interfaces dont les valeurs sont null. Adapter le nombre d’interfaces avant la saisie si nécessaire. Pour déterminer ce nombre par les questions de l’assistant, utiliser plutôt le mode --new.

Un modèle vierge est volontairement refusé par --check. Il ne doit jamais être passé directement au lanceur du cycle.

4.2. mercure3-reference.yaml

Ce fichier conserve les valeurs du projet validé : modèle 506 sur Saturne3, nom MERCURE3, 8 vCPU, 24576 Mio de RAM maximale, 16384 Mio minimale, disque 100 Gio, extension racine activée et paramètres réseau du projet.

Il permet de reconstruire une nouvelle VM avec la même configuration technique si le modèle, le stockage, les bridges et les préparatifs externes sont toujours disponibles. Il ne sauvegarde ni les données de l’ancienne VM, ni ses UUID, machine-id, clés hôte SSH ou mots de passe. Ces identités sont traitées par le cycle et ne sont pas à recopier.

Avec vmid: null, le VMID de remplacement peut différer de celui de l’ancienne VM. Le VMID 505 observé pendant la recette n’est pas une réservation permanente.

Ne pas lancer cette référence tant que MERCURE3 existe encore. Le clonage refuse un nom déjà présent. Pour tester une deuxième VM en parallèle, définir un autre nom, hostname, des IP distinctes et préparer DNS/OPNsense/Ansible en conséquence.

4.3. Valeurs acceptées

• projet.environnement et tags : interne, client, prod. Les tags sont une liste sans doublons ; [] est admis.
• CPU, mémoire et taille du disque : entiers strictement positifs ; mémoire minimale inférieure ou égale à la maximale.
• Booléens : utiliser true ou false sans guillemets.
• Interfaces Proxmox : net suivi de chiffres ; interfaces invitées : ens suivi de chiffres.
• Adresses d’interfaces : IPv4/CIDR. Loopback : IPv4/32. Passerelle et DNS : IPv4 sans préfixe.
• Passerelle : interface déclarée et adresse appartenant à son sous-réseau, distincte des adresses de la VM.
• Hostname : nom DNS en minuscules.
• Serveur, bridge et stockage : valeurs adaptées à l’infrastructure ; aucune liste fermée inventée.

Les clés inconnues ou répétées sont refusées. Ne pas ajouter de sections applicatives avant l’évolution coordonnée du schéma et des scripts. Ne pas utiliser [à renseigner] : les crochets créent une liste YAML.

5. Préparer et valider le YAML

Sur Saturne3, se placer dans le lot de recette :

cd /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle

5.1. Vérifier un fichier existant sans le modifier

./ajlsm-deploy-yaml /etc/ajlsm/deploy/projets/mercure3.yaml --check

Le message de succès signifie que les valeurs et leur cohérence locale sont conformes. Il ne certifie pas la préparation des services externes.

5.2. Compléter le modèle vierge

Après extraction du présent lot documentaire :

./ajlsm-deploy-yaml \
  /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-documentation/projet-vierge.yaml \
  --output /root/ajlsm-deploy/recettes/20261016/nouveau-projet.yaml

Toutes les valeurs obligatoires seront demandées. Pour saisir de nouveau le projet MERCURE3, consulter mercure3-reference.yaml comme fiche de paramètres, sans lancer de déploiement.

5.3. Créer sans modèle

./ajlsm-deploy-yaml /root/ajlsm-deploy/recettes/20261016/nouveau-projet.yaml --new

Cette commande est une alternative à la précédente : le chemin doit être inexistant. L’assistant pose les questions, y compris le nombre d’interfaces, sans reprendre implicitement les valeurs de MERCURE3.

5.4. Revoir un projet renseigné

./ajlsm-deploy-yaml /etc/ajlsm/deploy/projets/mercure3.yaml --review \
  --output /root/ajlsm-deploy/recettes/20261016/mercure3-relecture.yaml

• Entrée conserve une valeur existante valide.
• ANNULER, Ctrl-C ou fin d’entrée abandonnent sans enregistrer.
• Tags et DNS sont saisis séparés par des virgules ; [] ou aucun signifie tags vides.
• Saisir auto ou null pour un VMID automatique.
• Après une incohérence, donner le chemin du champ à corriger ; ? affiche les chemins.
• Le résumé complet est présenté avant confirmation OUI/NON d’enregistrement.

L’original reste intact, avec ses commentaires. La copie est réécrite en YAML, sans reprise des commentaires. Aucun fichier existant n’est écrasé. Si une destination existe, choisir un nouveau nom avec --output.

5.5. Préparatifs externes

Avant une création, vérifier séparément la réservation des IP, les déclarations DNS, les règles/routes/NAT nécessaires dans OPNsense et l’inventaire ou les préparatifs Ansible. Ne pas inscrire de mots de passe dans le YAML ; conserver les secrets dans le dispositif prévu pour leur gestion.

L’assistant actuel ne vérifie pas automatiquement ces services et ne marque pas un projet « prêt à déployer » sur cette seule base. Leur intégration reste à réaliser.

Le contrôle Proxmox autonome examine notamment le modèle, ses ressources, le stockage et les bridges. Il concerne une nouvelle création et peut refuser un projet déjà déployé :

./ajlsm-deploy-check /chemin/vers/projet.yaml

6. Afficher le plan puis lancer le cycle

6.1. Plan sans exécution

./ajlsm-deploy-cycle /chemin/vers/projet.yaml --plan

Le plan valide le YAML et affiche les commandes, sans exécuter les phases ni vérifier l’infrastructure. Il doit contenir les 11 étapes, toutes dans le dossier de recette.

6.2. Cycle réel pour une nouvelle VM

./ajlsm-deploy-cycle /chemin/vers/projet.yaml

Le lanceur exécute les phases réelles, sans simulation automatique. Il attend seulement les confirmations, les saisies nécessaires et la fin de chaque commande. Il s’arrête sur refus ou erreur. Il ne répond pas à la place de l’administrateur et ne capture pas les mots de passe.

N°	Étape	Commande réelle	Simulation facultative
1	Clonage	--clone	--dry-run
2	Ressources	--configure-resources	--resources-dry-run
3	Premier démarrage isolé	--first-boot-apply	--first-boot-dry-run
4	Extension partition/LVM/ext4	--root-grow-apply	--root-grow-dry-run
5	Identité système	--system-apply	--system-dry-run
6	Préparation Netplan	--network-apply	--network-dry-run
7	Activation réseau	--network-enable	--network-enable-dry-run
8	Audit SSH	--ssh-audit	Aucune option dédiée
9	Sécurisation SSH	--ssh-secure	Aucune option dédiée
10	Mot de passe ajlsm	--password-ajlsm	Aucune option dédiée
11	Certificat TLS interne	--tls-apply	Aucune option dédiée

L’extension racine est indispensable quand etendre_volume_racine vaut true. Agrandir le disque Proxmox ne suffit pas : la partition, le PV LVM, le LV et ext4 doivent aussi être étendus. Cette phase doit figurer après le premier démarrage, avant la personnalisation système. Avec false, la phase annonce sa désactivation.

Le démarrage et la personnalisation se font réseau isolé. Netplan est préparé avant activation des liens. La phase d’activation contrôle le réseau et applique demarrage_auto.

Le certificat TLS interne ne constitue pas, à lui seul, une configuration des applications du projet ou un certificat publiquement reconnu.

6.3. Mode manuel

Chaque phase peut être lancée séparément avec ./ajlsm-deploy suivi du YAML et de son option. Après succès, le lot courant affiche deux lignes pour l’étape suivante : Simulation et Exécution. Si la simulation n’existe pas, il le signale. Aucune suggestion n’est exécutée automatiquement.

Les simulations peuvent consulter l’invité et émettre des sondes ARP selon la phase : elles ne sont pas toutes des contrôles hors ligne. L’absence de réponse ARP ne remplace pas la réservation des adresses dans l’inventaire réseau.

7. Erreur, annulation et reprise

Conserver la sortie complète et diagnostiquer la phase fautive avant de reprendre. Une phase peut être partiellement effectuée ; le lanceur n’effectue ni suppression de VM ni restauration globale automatique.

./ajlsm-deploy-cycle /chemin/vers/projet.yaml --from extension-racine

--from inclut l’étape indiquée et saute les précédentes à la demande de l’administrateur. Il ne certifie pas leur état. Les contrôles propres aux phases restent actifs. Le lanceur ne possède pas de journal persistant global de progression.

Ne pas relancer le cycle depuis le clonage sur une VM existante pour terminer une étape. Ne pas relancer des étapes déjà terminées uniquement parce qu’une commande manuelle les suggère. Les suggestions suivent l’ordre théorique et ne constituent pas un inventaire de l’état de la VM.

Codes de sortie : 0 succès, 1 annulation, 2 erreur. Le lanceur normalise les autres codes d’échec de ses sous-processus en erreur et ne poursuit pas.

8. Vérifications finales

Sur Saturne3, avec le VMID réellement annoncé au clonage :

qm list
qm status VMID
qm config VMID

Remplacer VMID par l’identifiant vérifié. Contrôler le nom, les CPU, la RAM, le disque, les liens réseau et onboot selon le YAML.

Depuis Saturne3, ouvrir la connexion et attendre l’invite de la VM :

ssh ajlsm@10.0.0.43

Dans MERCURE3, saisir sudo -i, attendre l’authentification et l’invite root, puis :

hostname
lsblk
df -hT /
ip -br addr
ip route
resolvectl status

Résultat vérifié pendant la recette : hostname mercure3.ajlsm.com, racine ext4 97 Gio. Les tailles disponibles évoluent avec l’utilisation. Les commandes SSH et TLS du cycle vérifient leurs propres résultats ; compléter par les tests d’accès attendus dans le réseau cible.

9. Reconstruire MERCURE3 ultérieurement

1. Conserver le fichier mercure3-reference.yaml, le lot de scripts validé et l’identification du modèle utilisé.
2. Comparer la référence au YAML effectivement utilisé avant reconstruction ; actualiser les changements d’infrastructure.
3. Identifier et sauvegarder les données à conserver : le YAML n’est pas une sauvegarde de VM.
4. Vérifier explicitement l’identité de l’ancienne VM et traiter séparément son arrêt et sa suppression volontaire. Le cycle ne détruit jamais automatiquement une VM existante.
5. Contrôler DNS, OPNsense, Ansible et les réservations d’IP. Ne pas laisser deux VM actives avec les mêmes adresses.
6. Valider la référence avec --check, afficher le --plan, puis lancer le cycle sur la référence après libération de la cible.
7. Relever le nouveau VMID et effectuer les vérifications finales.

On retrouve ainsi les paramètres de la VM, sans chercher à reproduire ses anciennes identités techniques.

10. Suites prévues

Prévoir les paramètres NFS, sites Apache2, Pleade, Drupal et Matomo dans le même YAML lorsque leurs exigences seront définies. Modifier ensemble le schéma, l’assistant, les modèles, les précontrôles, les phases et leur documentation. Documenter les références aux secrets plutôt que leurs valeurs.

L’intégration des contrôles DNS, OPNsense et Ansible précédera une déclaration automatisée de disponibilité du projet. Le modèle actuel ne contient pas encore ces nouvelles sections.