Il y a 389 articles et 19 utilisateurs inscrits (ce bandeau est défini dans MediaWiki:Sitenotice)

« AJLSM-DEPLOY — Déploiement automatisé des VM Proxmox » : différence entre les versions

De AJLSM
Aller à la navigation Aller à la recherche

Jlarvers (discussion | contributions)

3 groupes d'utilisateurs
2 791 modifications
annuler
VisuelWikicode
Page créée avec « = AJLSM-DEPLOY — Déploiement automatisé des VM Proxmox = {{Note|Documentation validée le 15 octobre 2026 sur Saturne3, à partir du déploiement complet de MERCURE3.... »
 
Contenu remplacé par « Obsolète : Voir Déploiement_technique_d’une_VM_AJLSM »
 
(Une version intermédiaire par le même utilisateur non affichée)
Ligne 1 : Ligne 1 :
= AJLSM-DEPLOY — Déploiement automatisé des VM Proxmox =
Obsolète :


{{Note|Documentation validée le 15 octobre 2026 sur Saturne3, à partir du déploiement complet de MERCURE3.}}
Voir [[Déploiement_technique_d’une_VM_AJLSM]]
 
== 1. Présentation ==
 
'''ajlsm-deploy''' est un outil Python permettant de déployer une nouvelle machine virtuelle Proxmox à partir de la VM modèle TEMPLATE3.
 
L'objectif est de standardiser les déploiements AJLSM tout en conservant un contrôle humain à chaque étape.
 
Le script permet notamment :
 
* Le clonage complet d'une VM modèle.
* La configuration des ressources CPU, RAM et disque.
* Le premier démarrage avec les interfaces réseau isolées.
* La personnalisation du hostname et des identifiants système.
* La configuration réseau Netplan.
* La vérification de la disponibilité des adresses IPv4.
* L'activation contrôlée du réseau.
* La configuration du démarrage automatique.
* La vérification des opérations effectuées.
 
Chaque phase est indépendante.
 
'''Aucune phase suivante n'est exécutée automatiquement.'''
 
L'administrateur décide de poursuivre après examen des résultats.
 
== 2. Infrastructure de référence ==
 
=== 2.1. Serveur Proxmox ===
 
{| class="wikitable"
! Élément
! Valeur
|-
| Hyperviseur
| Saturne3
|-
| Système
| Proxmox VE 9.2.1 lors de la recette
|-
| VM modèle
| TEMPLATE3
|-
| VMID modèle
| 506
|-
| Stockage
| local-zfs
|-
| Script principal
| /usr/local/sbin/ajlsm-deploy
|-
| Répertoire des projets
| /etc/ajlsm/deploy/projets/
|}
 
=== 2.2. Scripts ===
 
Le script principal est installé dans :
 
<syntaxhighlight lang="bash">
/usr/local/sbin/ajlsm-deploy
</syntaxhighlight>
 
Les scripts complémentaires utilisés lors du développement sont :
 
<syntaxhighlight lang="text">
ajlsm-deploy-check
ajlsm-deploy-resources
</syntaxhighlight>
 
Ils assurent respectivement les précontrôles et la configuration des ressources.
 
'''Attention :''' vérifier leur emplacement et leur version lors de toute maintenance. La recette finale a confirmé l'installation du script principal, mais ne constitue pas à elle seule un inventaire des versions de ses dépendances.
 
=== 2.3. Sauvegarde de la version précédente ===
 
Avant l'installation de la version actuelle, une sauvegarde a été créée :
 
<syntaxhighlight lang="bash">
/usr/local/sbin/ajlsm-deploy.bak-20261015
</syntaxhighlight>
 
La nouvelle version a été installée avec :
 
<syntaxhighlight lang="bash">
install -o root -g root -m 750 \
  /root/ajlsm-deploy-review/ajlsm-deploy-network-enable \
  /usr/local/sbin/ajlsm-deploy
</syntaxhighlight>
 
La syntaxe Python et l'identité des deux fichiers ont été vérifiées :
 
<syntaxhighlight lang="bash">
python3 -m py_compile /usr/local/sbin/ajlsm-deploy
 
cmp /usr/local/sbin/ajlsm-deploy \
    /root/ajlsm-deploy-review/ajlsm-deploy-network-enable
</syntaxhighlight>
 
== 3. Prérequis ==
 
=== 3.1. Sur l'hyperviseur ===
 
Les éléments suivants doivent être disponibles :
 
* Python 3.
* PyYAML.
* Les outils Proxmox qm, pvesh et pvesm.
* La commande ip.
* Les scripts AJLSM nécessaires.
* Un stockage Proxmox opérationnel.
* Les bridges réseau définis dans le YAML.
 
Les commandes sont exécutées avec les privilèges root sur le nœud Proxmox concerné.
 
=== 3.2. Dans TEMPLATE3 ===
 
La VM modèle doit disposer :
 
* D'un système Linux compatible avec les scripts.
* De Python 3.
* De systemd.
* De l'agent QEMU.
* De Netplan pour la configuration réseau.
* Du service ajlsm-clone-init.
* Des outils nécessaires à la personnalisation système.
 
TEMPLATE3 doit être arrêtée avant le clonage.
 
=== 3.3. Vérification du modèle ===
 
<syntaxhighlight lang="bash">
qm status 506
qm config 506
</syntaxhighlight>
 
Le résultat attendu est notamment :
 
<syntaxhighlight lang="text">
status: stopped
</syntaxhighlight>
 
L'agent QEMU doit être activé dans la configuration Proxmox.
 
== 4. Configuration YAML ==
 
Chaque projet possède son propre fichier YAML.
 
Exemple :
 
<syntaxhighlight lang="bash">
/etc/ajlsm/deploy/projets/mercure3.yaml
</syntaxhighlight>
 
=== 4.1. Exemple MERCURE3 ===
 
<syntaxhighlight lang="yaml">
projet:
  code: mercure3
  nom: MERCURE3
  environnement: interne
 
proxmox:
  serveur: Saturne3
  template_vmid: 506
  vmid: null
  nom_vm: MERCURE3
 
  cpu:
    sockets: 1
    cores: 8
 
  memoire:
    maximale_mib: 24576
    minimale_mib: 16384
 
  disque_systeme:
    stockage: local-zfs
    taille_gib: 100
    etendre_volume_racine: true
 
  demarrage_auto: true
 
  tags:
    - interne
 
systeme:
  hostname: mercure3.ajlsm.com
 
reseau:
  interfaces:
    - nom: net0
      bridge: vmbr2
      systeme: ens18
      ipv4: 10.0.0.43/24
 
    - nom: net1
      bridge: vmbr1
      systeme: ens19
      ipv4: 192.168.123.27/24
 
  loopback:
    ipv4: 51.83.117.113/32
 
  passerelle:
    ipv4: 10.0.0.4
    interface: ens18
 
  dns:
    - 10.0.0.4
</syntaxhighlight>
 
=== 4.2. Attribution automatique du VMID ===
 
Le paramètre :
 
<syntaxhighlight lang="yaml">
vmid: null
</syntaxhighlight>
 
indique que le VMID doit être déterminé automatiquement par Proxmox.
 
Le script ne doit pas conserver un ancien VMID comme identifiant permanent du projet.
 
Lors de la recette du 15 octobre 2026, Proxmox a réattribué le VMID 505 après suppression de l'ancien clone.
 
'''Le VMID proposé lors d'une simulation n'est pas réservé.'''
 
Il peut donc changer avant le clonage effectif.
 
=== 4.3. Réutilisation pour un nouveau projet ===
 
Pour déployer une autre VM :
 
# Copier le fichier YAML d'exemple.
# Modifier le code et le nom du projet.
# Modifier le hostname.
# Adapter CPU, RAM et disque.
# Définir les interfaces et les adresses IP.
# Vérifier les bridges Proxmox.
# Conserver vmid: null pour une attribution automatique.
# Exécuter les précontrôles.
 
Le nom du fichier YAML n'est pas imposé par le script.
 
== 5. Déploiement d'une nouvelle VM ==
 
La procédure comporte sept phases :
 
# Clonage.
# Configuration des ressources.
# Premier démarrage isolé.
# Personnalisation système.
# Préparation Netplan.
# Vérification de l'activation réseau.
# Activation réseau.
 
Chaque phase comporte une simulation lorsque l'option correspondante est disponible.
 
=== 5.1. Phase 1 — Simulation du clonage ===
 
<syntaxhighlight lang="bash">
ajlsm-deploy \
  /etc/ajlsm/deploy/projets/mercure3.yaml \
  --dry-run
</syntaxhighlight>
 
Cette commande vérifie :
 
* La validité du YAML.
* La présence de TEMPLATE3.
* L'arrêt de la VM modèle.
* La présence de l'agent QEMU.
* Le stockage Proxmox.
* Les ressources demandées.
* Les bridges réseau.
* Les paramètres IP.
* La disponibilité d'un VMID.
 
Exemple de résultat :
 
<syntaxhighlight lang="text">
=== BILAN ===
Erreurs : 0
Avertissements : 1
Précontrôles satisfaits. Aucune modification effectuée.
 
=== PLAN DE CLONAGE ===
Source  : VM 506
Clone    : MERCURE3
VMID    : 505
Stockage : local-zfs
Type    : clone complet
Réseau  : isolation avant premier démarrage
Onboot  : désactivé
Démarrage: aucun
 
[DRY-RUN] Aucune modification effectuée.
</syntaxhighlight>
 
L'avertissement concernant la disponibilité réelle des adresses IP est normal à ce stade : le contrôle réseau actif intervient ultérieurement.
 
=== 5.2. Phase 1 — Clonage effectif ===
 
<syntaxhighlight lang="bash">
ajlsm-deploy \
  /etc/ajlsm/deploy/projets/mercure3.yaml \
  --clone
</syntaxhighlight>
 
Dans la version validée, le script demande :
 
<syntaxhighlight lang="text">
Pour créer la VM 505, saisir CLONER :
</syntaxhighlight>
 
La réponse attendue est :
 
<syntaxhighlight lang="text">
CLONER
</syntaxhighlight>
 
Le script effectue ensuite :
 
* Le clonage complet.
* L'isolation des interfaces.
* La vérification des adresses MAC.
* La vérification de l'arrêt de la VM.
* La désactivation du démarrage automatique.
 
Résultat attendu :
 
<syntaxhighlight lang="text">
=== CLONAGE TERMINÉ ===
VM 505 : MERCURE3
État : arrêtée, réseau isolé, onboot=0
Aucun démarrage effectué.
Prochaine phase : ressources CPU/RAM/disque.
</syntaxhighlight>
 
'''Ne pas démarrer manuellement la VM à ce stade.'''
 
=== 5.3. Phase 2 — Simulation des ressources ===
 
<syntaxhighlight lang="bash">
ajlsm-deploy \
  /etc/ajlsm/deploy/projets/mercure3.yaml \
  --resources-dry-run
</syntaxhighlight>
 
Exemple :
 
<syntaxhighlight lang="text">
=== RESSOURCES : MERCURE3 (VM 505) ===
[OK] VM arrêtée, réseau isolé, onboot=0
[MODIFICATION] CPU : 2 x 4 -> 1 x 8
[MODIFICATION] RAM : 8192 -> 24576 Mio ; balloon : non défini -> 16384 Mio
[MODIFICATION] Disque scsi0 : 32 -> 100 Gio
 
[DRY-RUN] Aucune modification effectuée.
</syntaxhighlight>
 
=== 5.4. Phase 2 — Application des ressources ===
 
<syntaxhighlight lang="bash">
ajlsm-deploy \
  /etc/ajlsm/deploy/projets/mercure3.yaml \
  --configure-resources
</syntaxhighlight>
 
Confirmation actuelle :
 
<syntaxhighlight lang="text">
Pour appliquer les ressources à la VM 505, saisir APPLIQUER :
</syntaxhighlight>
 
Répondre :
 
<syntaxhighlight lang="text">
APPLIQUER
</syntaxhighlight>
 
Résultat attendu :
 
<syntaxhighlight lang="text">
[OK] Ressources configurées et vérifiées.
[OK] VM toujours arrêtée et réseau isolé.
</syntaxhighlight>
 
Le disque virtuel est agrandi à la taille demandée.
 
'''Important :''' l'agrandissement du disque Proxmox et celui du système de fichiers invité sont deux opérations distinctes. Le YAML prévoit une extension du volume racine, mais la sortie de cette phase confirme uniquement la configuration des ressources Proxmox.
 
=== 5.5. Phase 3 — Simulation du premier démarrage ===
 
<syntaxhighlight lang="bash">
ajlsm-deploy \
  /etc/ajlsm/deploy/projets/mercure3.yaml \
  --first-boot-dry-run
</syntaxhighlight>
 
Exemple :
 
<syntaxhighlight lang="text">
=== PREMIER DÉMARRAGE : MERCURE3 (VM 505) ===
[OK] Démarrage automatique désactivé, interfaces isolées
État actuel : stopped
[DRY-RUN] Démarrer la VM 505, réseau isolé
[DRY-RUN] Attendre la réponse de l'agent QEMU (max. 300s)
[DRY-RUN] Vérifier ajlsm-clone-init et l'UUID enregistré
</syntaxhighlight>
 
=== 5.6. Phase 3 — Premier démarrage réel ===
 
<syntaxhighlight lang="bash">
ajlsm-deploy \
  /etc/ajlsm/deploy/projets/mercure3.yaml \
  --first-boot-apply
</syntaxhighlight>
 
Confirmation actuelle :
 
<syntaxhighlight lang="text">
Pour démarrer la VM 505 avec le réseau isolé, saisir DEMARRER :
</syntaxhighlight>
 
Répondre :
 
<syntaxhighlight lang="text">
DEMARRER
</syntaxhighlight>
 
Le script :
 
# Démarre la VM avec ses interfaces isolées.
# Attend la disponibilité de l'agent QEMU.
# Vérifie le service ajlsm-clone-init.
# Contrôle l'UUID matériel du clone.
 
Exemple :
 
<syntaxhighlight lang="text">
[OK] Agent QEMU disponible
[OK] ajlsm-clone-init terminé avec succès
[OK] UUID matériel conforme
[OK] Phase de premier démarrage validée ; interfaces toujours isolées
</syntaxhighlight>
 
==== Particularité : attente réseau au démarrage ====
 
Lors de la recette, la console Proxmox a affiché :
 
<syntaxhighlight lang="text">
Job systemd-networkd-wait-online.service/start running
</syntaxhighlight>
 
Le démarrage s'est poursuivi après environ 60 secondes.
 
Cette attente est cohérente avec l'isolation volontaire des interfaces réseau.
 
Elle n'a pas empêché l'agent QEMU et ajlsm-clone-init de fonctionner.
 
Une amélioration ultérieure de TEMPLATE3 pourra être étudiée pour éviter cette attente inutile pendant les phases isolées.
 
=== 5.7. Phase 4 — Simulation de personnalisation système ===
 
<syntaxhighlight lang="bash">
ajlsm-deploy \
  /etc/ajlsm/deploy/projets/mercure3.yaml \
  --system-dry-run
</syntaxhighlight>
 
Cette phase prépare :
 
* La sauvegarde des fichiers hostname et hosts.
* La sauvegarde des identifiants machine-id.
* La génération d'une nouvelle identité système.
* Le redémarrage isolé.
* Les contrôles après redémarrage.
 
Exemple :
 
<syntaxhighlight lang="text">
État de reprise : nouvelle transaction
 
[DRY-RUN] Sauvegarder hostname, hosts et les deux machine-id dans l'invité
[DRY-RUN] Préparer une identité aléatoire persistante, puis redémarrer isolé
[DRY-RUN] Vérifier boot_id, identité PID1, hostname, hosts et isolation
</syntaxhighlight>
 
=== 5.8. Phase 4 — Personnalisation système ===
 
<syntaxhighlight lang="bash">
ajlsm-deploy \
  /etc/ajlsm/deploy/projets/mercure3.yaml \
  --system-apply
</syntaxhighlight>
 
Confirmation :
 
<syntaxhighlight lang="text">
Cible : VM505 — mercure3.ajlsm.com
Cette opération modifiera l’identité système et redémarrera la VM avec le réseau isolé.
Confirmer (OUI/NON) :
</syntaxhighlight>
 
Répondre :
 
<syntaxhighlight lang="text">
oui
</syntaxhighlight>
 
Le script personnalise l'identité système puis redémarre la VM.
 
Résultat obtenu lors de la recette :
 
<syntaxhighlight lang="text">
[ACTION] Identité disque préparée ; identité active non encore validée
[OK] Agent QEMU disponible
[OK] ajlsm-clone-init terminé avec succès
[OK] Nouveau démarrage et identité active vérifiés ; VM505 toujours isolée
</syntaxhighlight>
 
==== Journal de personnalisation ====
 
Les informations de transaction sont conservées dans l'invité :
 
<syntaxhighlight lang="text">
/var/lib/ajlsm/system-personalisation/state.json
/var/lib/ajlsm/system-personalisation/backup/
</syntaxhighlight>
 
Ces éléments permettent au script de reconnaître une personnalisation déjà effectuée ou une transaction interrompue.
 
'''Ne pas supprimer manuellement ces fichiers pour relancer une personnalisation.'''
 
En cas d'interruption, conserver la VM isolée et examiner les résultats des commandes dry-run avant toute reprise.
 
=== 5.9. Phase 5 — Simulation de la configuration réseau ===
 
<syntaxhighlight lang="bash">
ajlsm-deploy \
  /etc/ajlsm/deploy/projets/mercure3.yaml \
  --network-dry-run
</syntaxhighlight>
 
Le script vérifie les paramètres réseau du YAML.
 
Exemple :
 
<syntaxhighlight lang="text">
Cible : MERCURE3 VM505 ; reseau Proxmox isole
  ens18: 10.0.0.43/24
  ens19: 192.168.123.27/24
  lo: 51.83.117.113/32 ; passerelle: 10.0.0.4 (ens18) ; DNS: 10.0.0.4
 
[DRY-RUN] Sauvegarder le Netplan initial, ecrire la configuration et executer netplan generate
[DRY-RUN] Aucune modification ni activation reseau
</syntaxhighlight>
 
=== 5.10. Phase 5 — Application de Netplan ===
 
<syntaxhighlight lang="bash">
ajlsm-deploy \
  /etc/ajlsm/deploy/projets/mercure3.yaml \
  --network-apply
</syntaxhighlight>
 
Confirmation :
 
<syntaxhighlight lang="text">
Cette operation remplace Netplan dans l'invite, sans activer les interfaces Proxmox.
Confirmer (OUI/NON) :
</syntaxhighlight>
 
Répondre :
 
<syntaxhighlight lang="text">
oui
</syntaxhighlight>
 
Le script :
 
# Sauvegarde la configuration Netplan initiale.
# Écrit la configuration du projet.
# Exécute netplan generate.
# Vérifie que les interfaces Proxmox restent isolées.
 
Résultat obtenu :
 
<syntaxhighlight lang="text">
[OK] Netplan ecrit et netplan generate valide : {"changed": true, "backup": true}
[OK] VM505 toujours isolee ; aucune activation des liens
</syntaxhighlight>
 
'''Important :''' cette phase ne connecte pas les interfaces réseau.
 
=== 5.11. Phase 6 — Simulation de l'activation réseau ===
 
<syntaxhighlight lang="bash">
ajlsm-deploy \
  /etc/ajlsm/deploy/projets/mercure3.yaml \
  --network-enable-dry-run
</syntaxhighlight>
 
Cette commande effectue notamment :
 
* La vérification de l'agent QEMU.
* La vérification du service ajlsm-clone-init.
* La vérification de l'identité de la VM.
* La validation de Netplan.
* Le contrôle ARP des adresses IPv4.
* La vérification de l'isolation réseau.
 
Exemple :
 
<syntaxhighlight lang="text">
[OK] ARP DAD 10.0.0.43 sur vmbr2 (aucune reponse)
[OK] ARP DAD 192.168.123.27 sur vmbr1 (aucune reponse)
[OK] VM505 UUID conforme, clone et Netplan valides, reseau isole
 
[DRY-RUN] Aucune modification. Activation puis controle et repli si erreur.
</syntaxhighlight>
 
==== Contrôle ARP DAD ====
 
ARP DAD signifie Address Conflict Detection.
 
Le script recherche une éventuelle réponse ARP indiquant qu'une adresse IPv4 est déjà utilisée sur le réseau.
 
L'absence de réponse est nécessaire pour poursuivre, mais ne constitue pas une garantie absolue d'absence de conflit.
 
Il convient donc de vérifier également l'attribution des adresses dans l'inventaire réseau AJLSM.
 
=== 5.12. Phase 7 — Activation du réseau ===
 
<syntaxhighlight lang="bash">
ajlsm-deploy \
  /etc/ajlsm/deploy/projets/mercure3.yaml \
  --network-enable
</syntaxhighlight>
 
Confirmation :
 
<syntaxhighlight lang="text">
Activer le reseau de cette VM (OUI/NON) :
</syntaxhighlight>
 
Répondre :
 
<syntaxhighlight lang="text">
oui
</syntaxhighlight>
 
Le script vérifie une nouvelle fois la disponibilité des adresses IPv4 avant l'activation.
 
Il contrôle ensuite :
 
* Les adresses IPv4.
* L'adresse loopback.
* La route par défaut.
* La configuration DNS.
* La réponse de la passerelle.
* Le démarrage automatique conformément au YAML.
 
Résultat obtenu lors de la recette :
 
<syntaxhighlight lang="text">
[OK] ARP DAD 10.0.0.43 sur vmbr2 (aucune reponse)
[OK] ARP DAD 192.168.123.27 sur vmbr1 (aucune reponse)
[OK] Adresses, loopback, route, DNS et ping passerelle valides
[OK] VM505 : reseau actif et controle, onboot conforme au YAML
</syntaxhighlight>
 
Le script prévoit un mécanisme de repli en cas d'échec de l'activation réseau.
 
'''Limite de la recette :''' le chemin nominal a été validé deux fois, mais le repli sur erreur n'a pas encore été testé en situation réelle.
 
== 6. Vérifications finales ==
 
=== 6.1. État de la VM ===
 
<syntaxhighlight lang="bash">
qm status 505
</syntaxhighlight>
 
Résultat attendu :
 
<syntaxhighlight lang="text">
status: running
</syntaxhighlight>
 
=== 6.2. Configuration Proxmox ===
 
<syntaxhighlight lang="bash">
qm config 505
</syntaxhighlight>
 
Vérifier notamment :
 
* Le nom MERCURE3.
* Les 8 vCPU.
* La mémoire de 24576 Mio.
* Le balloon de 16384 Mio.
* Le disque scsi0 de 100 Go.
* Les deux interfaces réseau actives.
* Le démarrage automatique.
 
Contrôle ciblé :
 
<syntaxhighlight lang="bash">
qm config 505 | grep -E '^(name|net[0-9]+|onboot):'
</syntaxhighlight>
 
Résultat attendu :
 
<syntaxhighlight lang="text">
name: MERCURE3
net0: ... link_down=0
net1: ... link_down=0
onboot: 1
</syntaxhighlight>
 
=== 6.3. Vérification du réseau dans l'invité ===
 
Lorsque nécessaire, utiliser la console Proxmox ou l'agent QEMU.
 
Exemples de commandes dans la VM :
 
<syntaxhighlight lang="bash">
hostnamectl
 
ip -br addr
 
ip route
 
resolvectl status
 
systemctl status qemu-guest-agent --no-pager
</syntaxhighlight>
 
=== 6.4. Vérification du volume racine ===
 
Le disque virtuel de 100 Go ne garantit pas, à lui seul, que le volume racine utilise tout cet espace.
 
Vérifier dans l'invité :
 
<syntaxhighlight lang="bash">
lsblk
 
df -hT /
 
pvs
 
vgs
 
lvs
</syntaxhighlight>
 
Les trois dernières commandes concernent les installations utilisant LVM.
 
Adapter les contrôles au partitionnement réel de TEMPLATE3.
 
== 7. Sécurité et principes de fonctionnement ==
 
=== 7.1. Isolation réseau ===
 
La VM est clonée et démarrée avec ses interfaces réseau déconnectées au niveau Proxmox.
 
Cette précaution évite notamment que le clone utilise temporairement les adresses réseau du modèle.
 
Le réseau n'est activé qu'après :
 
# L'initialisation du clone.
# La personnalisation de son identité système.
# La préparation de Netplan.
# La vérification de la disponibilité des adresses IP.
 
=== 7.2. Contrôle de l'identité ===
 
Le script utilise l'identité de la VM Proxmox et son UUID matériel pour vérifier qu'il agit sur la bonne cible.
 
Cette protection est particulièrement importante lorsque le VMID est attribué automatiquement.
 
=== 7.3. Confirmations ===
 
Les opérations modifiant la VM nécessitent une confirmation.
 
Dans la version actuellement installée, les confirmations ne sont pas encore totalement uniformisées.
 
Certaines phases demandent :
 
<syntaxhighlight lang="text">
CLONER
APPLIQUER
DEMARRER
</syntaxhighlight>
 
D'autres utilisent :
 
<syntaxhighlight lang="text">
Confirmer (OUI/NON) :
</syntaxhighlight>
 
Il faut respecter la confirmation affichée par la version exécutée.
 
=== 7.4. Simulations ===
 
Les commandes dry-run permettent d'examiner la cible et les modifications prévues.
 
Elles ne doivent pas être considérées comme une garantie absolue que l'application réussira.
 
L'état de Proxmox, de la VM ou du réseau peut évoluer entre la simulation et l'exécution.
 
=== 7.5. Reprise après incident ===
 
En cas d'erreur :
 
# Ne pas poursuivre automatiquement avec la phase suivante.
# Examiner la sortie complète du script.
# Vérifier l'état réel de la VM.
# Conserver les journaux et sauvegardes.
# Vérifier l'isolation réseau avant toute reprise.
 
Ne pas supprimer les fichiers de transaction de personnalisation pour forcer une nouvelle exécution.
 
== 8. Tableau récapitulatif des commandes ==
 
{| class="wikitable"
! Phase
! Simulation
! Application
|-
| Clonage
| <code>--dry-run</code>
| <code>--clone</code>
|-
| Ressources
| <code>--resources-dry-run</code>
| <code>--configure-resources</code>
|-
| Premier démarrage
| <code>--first-boot-dry-run</code>
| <code>--first-boot-apply</code>
|-
| Système
| <code>--system-dry-run</code>
| <code>--system-apply</code>
|-
| Configuration réseau
| <code>--network-dry-run</code>
| <code>--network-apply</code>
|-
| Activation réseau
| <code>--network-enable-dry-run</code>
| <code>--network-enable</code>
|}
 
Toutes les commandes reçoivent le même fichier YAML.
 
Exemple :
 
<syntaxhighlight lang="bash">
ajlsm-deploy \
  /etc/ajlsm/deploy/projets/mercure3.yaml \
  --OPTION
</syntaxhighlight>
 
Remplacer OPTION par le mode souhaité.
 
== 9. Maintenance ==
 
=== 9.1. Vérification de la syntaxe ===
 
<syntaxhighlight lang="bash">
python3 -m py_compile /usr/local/sbin/ajlsm-deploy
</syntaxhighlight>
 
=== 9.2. Affichage des options ===
 
<syntaxhighlight lang="bash">
ajlsm-deploy --help
</syntaxhighlight>
 
=== 9.3. Sauvegarde avant modification ===
 
Avant toute mise à jour :
 
<syntaxhighlight lang="bash">
cp -a /usr/local/sbin/ajlsm-deploy \
  /usr/local/sbin/ajlsm-deploy.bak-$(date +%Y%m%d-%H%M%S)
</syntaxhighlight>
 
Si les scripts complémentaires sont modifiés, les sauvegarder également.
 
=== 9.4. Restauration de la version précédente ===
 
La version sauvegardée le 15 octobre 2026 peut être restaurée avec :
 
<syntaxhighlight lang="bash">
install -o root -g root -m 750 \
  /usr/local/sbin/ajlsm-deploy.bak-20261015 \
  /usr/local/sbin/ajlsm-deploy
</syntaxhighlight>
 
'''Attention :''' cette version ne possède pas nécessairement toutes les fonctions de la version actuelle.
 
Vérifier la compatibilité avec les scripts complémentaires avant toute restauration.
 
== 10. Améliorations prévues ==
 
Les améliorations suivantes ont été décidées à l'issue de la recette.
 
Elles ne sont pas encore intégrées dans la version installée.
 
=== 10.1. Uniformisation des confirmations ===
 
Toutes les phases utiliseront :
 
<syntaxhighlight lang="text">
Confirmer (oui/non) :
</syntaxhighlight>
 
Comportement souhaité :
 
* oui : exécuter.
* non : annuler.
* Réponse vide : annuler.
* Autre réponse : annuler.
 
Les majuscules et minuscules devront être acceptées.
 
=== 10.2. Affichage des commandes suivantes ===
 
Après chaque phase réussie, le script proposera les commandes permettant de poursuivre.
 
Exemple :
 
<syntaxhighlight lang="text">
============================================================
[OK] RESSOURCES CONFIGURÉES
============================================================
 
VM : 505 (MERCURE3)
 
PROCHAINE ÉTAPE : PREMIER DÉMARRAGE
 
1. Simulation :
 
  ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml \
    --first-boot-dry-run
 
2. Application :
 
  ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml \
    --first-boot-apply
 
============================================================
</syntaxhighlight>
 
'''Ces commandes seront uniquement affichées, jamais exécutées automatiquement.'''
 
=== 10.3. Aide intégrée ===
 
Améliorer :
 
<syntaxhighlight lang="bash">
ajlsm-deploy --help
</syntaxhighlight>
 
L'aide devra être organisée par phases et rédigée en français.
 
=== 10.4. Manuel système ===
 
Créer une page de manuel accessible avec :
 
<syntaxhighlight lang="bash">
man ajlsm-deploy
</syntaxhighlight>
 
Elle devra présenter :
 
* Les prérequis.
* La syntaxe des commandes.
* Le format YAML.
* Les différentes phases.
* Les contrôles de sécurité.
* Les procédures de reprise.
* Les exemples d'utilisation.
 
=== 10.5. Optimisation de TEMPLATE3 ===
 
Étudier l'attente de 60 secondes observée lors du premier démarrage isolé.
 
Vérifier si systemd-networkd-wait-online est nécessaire et, le cas échéant, adapter son comportement sans perturber les dépendances réseau.
 
== 11. Fichiers de développement et nettoyage ==
 
Le répertoire utilisé pour la recette est :
 
<syntaxhighlight lang="bash">
/root/ajlsm-deploy-review/
</syntaxhighlight>
 
Il contient notamment :
 
<syntaxhighlight lang="text">
ajlsm-deploy
ajlsm-deploy-check
ajlsm-deploy-resources
ajlsm-deploy-network-enable
INSTRUCTIONS-TEST.txt
</syntaxhighlight>
 
Le fichier INSTRUCTIONS-TEST.txt correspond à une ancienne phase de développement.
 
Il ne décrit pas l'ensemble des fonctionnalités réseau désormais disponibles.
 
Il doit donc être considéré comme obsolète.
 
Après vérification et archivage éventuel, il pourra être supprimé :
 
<syntaxhighlight lang="bash">
rm /root/ajlsm-deploy-review/INSTRUCTIONS-TEST.txt
</syntaxhighlight>
 
Ne pas supprimer les autres fichiers de développement tant que leur rôle et leur emplacement définitif n'ont pas été vérifiés.
 
== 12. Historique des validations ==
 
{| class="wikitable"
! Date
! Opération
! Résultat
|-
| 15/10/2026
| Installation du script avec activation réseau
| Validée
|-
| 15/10/2026
| Premier déploiement MERCURE3
| Validé
|-
| 15/10/2026
| Suppression du premier clone
| Effectuée
|-
| 15/10/2026
| Second clonage complet depuis TEMPLATE3
| Validé
|-
| 15/10/2026
| Configuration CPU/RAM/disque
| Validée
|-
| 15/10/2026
| Premier démarrage isolé
| Validé
|-
| 15/10/2026
| Personnalisation système
| Validée
|-
| 15/10/2026
| Configuration Netplan
| Validée
|-
| 15/10/2026
| Contrôle ARP des adresses IPv4
| Validé
|-
| 15/10/2026
| Activation réseau et contrôles
| Validée
|-
| À réaliser
| Test du repli automatique sur échec réseau
| Non testé
|-
| À réaliser
| Harmonisation des confirmations et aide intégrée
| Non réalisée
|}
 
== 13. Conclusion ==
 
La procédure de déploiement AJLSM a été validée par deux déploiements successifs de MERCURE3.
 
Le second déploiement a été effectué depuis une VM modèle arrêtée, après suppression du premier clone.
 
Toutes les phases ont été exécutées successivement avec leurs contrôles.
 
Le réseau a été activé uniquement après personnalisation du système et vérification de sa configuration.
 
'''Le fonctionnement nominal de la chaîne de déploiement est validé.'''
 
Les principaux travaux restants concernent l'ergonomie, la documentation intégrée, la vérification de l'extension du volume racine et les essais du mécanisme de repli réseau.
 
[[Catégorie:Infrastructure]]
[[Catégorie:Proxmox]]
[[Catégorie:Déploiement]]
[[Catégorie:AJLSM]]

Dernière version du 16 octobre 2026 à 16:18

Obsolète :

Voir Déploiement_technique_d’une_VM_AJLSM

Récupérée de "https://mediawiki.ajlsm.com/index.php?title=AJLSM-DEPLOY_—_Déploiement_automatisé_des_VM_Proxmox&oldid=6492"