Déploiement technique d’une VM AJLSM

AJLSM-DEPLOY — Version 1.0.2

Mise à jour : 19 octobre 2026. Ce guide décrit les scripts du dossier ajlsm-deploy-v1.0.2, à installer dans /opt/ajlsm-deploy/v1. Ce chemin est le répertoire définitif de lancement sur le nœud Proxmox ; les anciennes copies de /usr/local/sbin ne sont pas remplacées implicitement. Les lots NFS, Apache et Matomo précédents sont historiques. Garder scripts, modules et modèles du même lot. Rotation des logs et update.sh hors périmètre.

Périmètre et architecture

Les scripts tournent sur le nœud Proxmox. Ils configurent le clone depuis un projet YAML strict, utilisent QEMU Guest Agent pour les opérations invitées, et SSH pour certaines vérifications/postconfigurations. Le moteur principal orchestre les phases ; les modules spécialisés traitent racine, postconfiguration, NFS, Apache, SQL Matomo, activation Matomo et inventaire des tâches planifiées. Les helpers communs valident le YAML et affichent les commandes suivantes.

Ce n'est pas un gestionnaire complet de l'infrastructure externe. DNS, OPNsense, Ansible, autorisation Eole3 et certificats publics ont leurs procédures. Le script ne détruit pas la VM existante et ne modifie pas TEMPLATE3.

Répertoire définitif et exemple MERCURE3

Les cinq programmes affichent la version 1.0.2 avec --version. Leur --help rappelle le même répertoire et le même exemple que cette page. Ces valeurs sont centralisées dans ajlsm_deploy_version.py. Les suggestions visent les programmes du dossier réellement exécuté : utiliser le lot installé ci-dessous, pas un ancien dossier de recette.

Sur Saturne3, après installation du lot complet selon INSTALLATION-V1.txt :

cd /opt/ajlsm-deploy/v1

Toutes les commandes ./ de cette page se lancent depuis ce répertoire. Depuis un autre répertoire du même nœud, utiliser le chemin absolu du programme sous /opt/ajlsm-deploy/v1 et celui du YAML. Les YAML opérationnels restent sous /etc/ajlsm/deploy/projets/, les journaux sous /var/lib/ajlsm-deploy/cycles/. Les archives/recettes sous /root/ajlsm-deploy ne sont plus le répertoire de lancement v1. Ne pas mélanger les modules ou changer de lot pendant un cycle.

exemples/mercure3-exemple.yaml est un exemple renseigné avec les IP réelles de MERCURE3, pas une préconfiguration générique. Les commandes MERCURE3 de ce guide sont des exemples à adapter au projet. Le nom de la VM, ses DNS et ses fichiers YAML opérationnels existants ne sont pas renommés. En particulier, conserver le chemin du YAML pour la reprise : le journal est indexé par ce chemin absolu. modeles/projet-vierge.yaml demeure le modèle générique sans valeurs.

Prérequis impératif : OS de TEMPLATE3 à jour

Avant TOUT nouveau clonage, maintenir l’OS Ubuntu de TEMPLATE3 à jour. La VM clonée hérite de cet état. Maintenance manuelle distincte : les scripts de déploiement ne mettent pas le modèle à jour. Prévoir une sauvegarde récupérable et une fenêtre sans conflit d’IP avec les clones existants. Ne pas démarrer ni convertir à l’aveugle un modèle marqué template Proxmox.

Dans la console de TEMPLATE3, après vérification de son identité :

hostname -f
cat /etc/os-release
sudo apt update
sudo apt upgrade
apt list --upgradable
if [ -f /var/run/reboot-required ]; then
  cat /var/run/reboot-required
  cat /var/run/reboot-required.pkgs 2>/dev/null || true
fi

Examiner toutes les erreurs, messages APT et paquets retenus/différés. apt update seul ne met pas les paquets à jour. Pas de -y, full-upgrade, do-release-upgrade ou update.sh automatique. Si un redémarrage est demandé :

sudo reboot

Attendre le retour du modèle, puis dans sa console :

hostname -f
uname -r
systemctl --failed
apt list --upgradable
test ! -f /var/run/reboot-required

Examiner les résultats, noter date/OS/noyau dans le registre de maintenance. Après validation, arrêter proprement TEMPLATE3 :

sudo shutdown -h now

Puis sur Saturne3 :

qm status 506

506 correspond au template_vmid de cette recette : vérifier la valeur du YAML. Le modèle doit être arrêté avant le clonage. Ni le lanceur ni les précontrôles ne certifient automatiquement sa fraîcheur APT. Cette maintenance n’a pas été réalisée par les scripts livrés. Saturne3 et HAProxy ont leur maintenance distincte, non demandée ici. Voir PREREQUIS-OS-ET-PUBLICATION.txt et les documentations Ubuntu : Gestion des paquets et Mises à jour automatiques.

Paramètres prévus avant la création

• Identité projet, environnement et tags : interne, client, prod ; types YAML stricts.
• Ressources, template, stockage, IP privées/VPN/publique, passerelle et DNS.
• Domaines principal, préprod et Matomo définitifs, sans https:// ni chemin.
• NFS existant et droits accordés par l'administrateur du serveur.
• Activation des vhosts distincte de l'installation des logiciels.
• Noms SQL dédiés Matomo, sans secret dans le YAML.

Référence MERCURE3 : hostname mercure3.ajlsm.com, VPN 10.0.0.43, réseau données 192.168.123.27, publique 51.83.117.113. Matomo : mercure3-matomo.pleade.com ; préprod : mercure3-preprod.pleade.com. Ne pas conserver deux VM avec ces mêmes adresses.

Chez OVH, principal A vers 51.83.117.113, domaines secondaires CNAME vers mercure3.ajlsm.com dans la recette. Ne pas publier d'AAAA sans IPv6 opérationnel. Pour un domaine secondaire sur la même IP, réutiliser la VIP/NAT existante si elle et le filtrage traitent déjà le flux requis ; ne pas dupliquer OPNsense. Le trafic public passe par la VIP HAProxy 10.0.0.32, nœuds .30 et .31.

Préconfiguration et contrôle

modeles/projet-vierge.yaml contient des null, jamais une liste [à renseigner]. null est valide pour proxmox.vmid automatique, pas pour un champ obligatoire. Les sections métier peuvent être omises, mais doivent être complètes si présentes. exemples/mercure3-exemple.yaml prépare une recréation volontaire, pas une VM parallèle.

./ajlsm-deploy-yaml ./modeles/projet-vierge.yaml --with-metier --output /etc/ajlsm/deploy/projets/mercure3-initial.yaml
./ajlsm-deploy-yaml /etc/ajlsm/deploy/projets/mercure3-initial.yaml --check
./ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3-initial.yaml --plan
./ajlsm-deploy-check /etc/ajlsm/deploy/projets/mercure3-initial.yaml

Le parcours complet de l'assistant est désormais --with-metier : NFS, domaines Matomo/Apache et SQL dédiés dans le même YAML initial. Sans modèle, utiliser --new --with-metier avec un chemin inexistant. Les valeurs valides existantes sont conservées ; --review les revoit aussi. Le guide détaillé GUIDE-YAML.txt décrit les questions et les activations : Drupal seulement si vérifié, Pleade préprod désactivé en son absence, Matomo Apache false jusqu'à publication-matomo après pause externe. Le mode --with-matomo-site reste une activation MANUELLE distincte, incompatible avec --with-metier ; inutile au cycle guidé actuel. OS du modèle, DNS, OPNsense, ACME sur les deux HAProxy, Ansible/whitelist et autorisation NFS sont rappelés mais pas vérifiés ni enregistrés comme tels.

Les options individuelles restent disponibles : --with-nfs, --with-matomo, --with-apache et --with-matomo-sql ; --review revoit aussi les valeurs valides. --new crée un nouveau chemin. Les fichiers existants ne sont pas écrasés. --check et --yaml-only sont des contrôles locaux, pas une vérification d'infrastructure. Prévoir apache.matomo.activer=false pour le cycle initial ; un projet d'activation true est refusé par le cycle avant toute phase passant par Apache.

Cycle initial : dix-sept étapes

Étape	Simulation / lecture	Exécution
clonage	--dry-run	--clone
ressources	--resources-dry-run	--configure-resources
premier-demarrage	--first-boot-dry-run	--first-boot-apply
extension-racine	--root-grow-dry-run	--root-grow-apply
identite	--system-dry-run	--system-apply
netplan	--network-dry-run	--network-apply
activation-reseau	--network-enable-dry-run	--network-enable
audit-ssh	--ssh-audit	audit, pas de simulation distincte
securisation-ssh	aucune	--ssh-secure
mot-de-passe	aucune	--password-ajlsm
tls	aucune	--tls-apply
nfs	--nfs-dry-run puis --nfs-check	--nfs-apply
apache	--apache-dry-run	--apache-apply
matomo-sql	--matomo-sql-dry-run	--matomo-sql-prepare
tomcat-cron	--scheduled-dry-run	--scheduled-apply
taches-planifiees	--scheduled-audit	aucune modification
publication-matomo	--matomo-guided-dry-run	--matomo-guided

Le clone est isolé avant premier démarrage. L'extension racine suit le premier démarrage et ne doit pas être confondue avec le disque virtuel déjà agrandi. Puis identité, réseau, SSH, mot de passe et certificat interne sont traités. Les phases métier non demandées sont ignorées explicitement.

Attente réseau pendant l'isolation

Le journal MERCURE3 transmis montre wait-online en attente 120 secondes avant activation des carriers ; le réseau est ensuite online sur les deux cartes. Le lot ajoute une dispense conditionnelle liée à l'UUID pendant l'isolation, dès que QGA est disponible. Les phases first-boot et system l'installent après les confirmations et gardes ; network-enable la retire après ses contrôles puis vérifie le fonctionnement normal de wait-online avant onboot. Le repli réseau remet la dispense après réisolation. Pas de mask/disable, pas de changement Netplan optional ou de TEMPLATE3. Les simulations n'écrivent aucun fichier. Ce correctif reste à recetter sur un clone ; il ne nécessite pas de reconstruire la VM actuelle pour continuer les étapes métier. Voir CORRECTIF-WAIT-ONLINE.txt pour les deux fichiers gérés, limites et reprise.

./ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3-initial.yaml

Les confirmations OUI/NON, défaut NON, et saisies natives restent interactives. Pas d'arrêt entre commandes réussies ; arrêt au premier refus ou erreur. --agent-timeout est transmis aux phases, défaut 300 secondes, pas un timeout global. Après diagnostic, --from reprend l'étape incluse sans refaire les précédentes. Un --plan n'exécute rien mais ne garantit ni Proxmox ni l'infrastructure externe.

NFS : autorisation manuelle guidée

Dépôt d'exemples : 192.168.123.202:/var/data/pleade.com-data/data, point local identique, mode ro. Un autre dépôt est paramétrable ; plusieurs dépôts de MERCURE3 restent une exception manuelle. Le script affiche le fichier exports et la ligne à adapter sur Eole3, sans s'y connecter en administrateur. L'autorisation de 192.168.123.27 en ro a été réalisée dans la recette. Les autres exports et données doivent être conservés. Pas de chmod/chown récursif.

Apache, Drupal et Pleade

Six fichiers gérés sous /etc/apache2/sites-available : HTTP et TLS pour Drupal, préprod et Matomo ; fichier robots préprod séparé. Activation par symlinks selon le YAML, manifeste, sauvegarde, syntaxe candidate et reload avec tentative de restauration locale sur erreur. Une interruption brutale demande un diagnostic. Un vhost préparé n'installe pas un logiciel et ne valide pas une application. Les fichiers gérés modifiés hors déploiement provoquent un refus, pas un écrasement.

Drupal hérité a été vérifié utilisable avec MariaDB et drupal_template ; son vhost principal est actif dans la recette. Pas de personnalisation SQL Drupal dédiée dans ce lot. Pleade n'est pas installé, sa préprod reste désactivée ; pas d'appel à update.sh. Les futurs slecture et internet ne sont pas publiés.

Matomo : préparation SQL puis activation coordonnée

Base et compte locaux dédiés : matomo_mercure3, sans adoption de matomo_template. Configuration préparée root privée dans /var/lib/ajlsm-matomo-sql ; ne pas transmettre ces fichiers. En fin de cycle, publication-matomo affiche la pause externe, demande une attestation OUI/NON puis active Matomo avec le MÊME YAML. Il passe activer=true en mémoire uniquement ; le YAML initial reste intact. En mode manuel, après SQL :

./ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3-initial.yaml --matomo-guided-dry-run
./ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3-initial.yaml --matomo-guided

L’activation coordonnée conserve Drupal/Pleade. Le mode historique reste possible : --with-matomo-site crée une copie d’activation, ensuite utilisée par --matomo-site-dry-run puis --matomo-site-apply. Ne pas utiliser --apache-apply seul pour cette transition et ne pas relancer le clonage avec la copie d'activation. Le module désactive les anciens vhosts Matomo connus, sauvegarde le cache, installe la configuration privée et active le projet avec contrôle HTTPS local. Les sauvegardes peuvent contenir des secrets.

Certificats en prérequis et pause avant activation

Recommandation : DNS puis challenge ACME stateless prêts, émettre/déployer les certificats publics en prérequis, avant même le clonage backend. Le challenge HAProxy ne dépend pas de Matomo. Une pause reste obligatoire à publication-matomo pour vérifier les certificats et le routage restreint sur LES DEUX nœuds. NON arrête proprement le cycle ; --resume reprend après préparation externe. Aucune commande ACME/Ansible n’est exécutée par le script et l’attestation humaine ne constitue pas une vérification automatisée.

Le certificat interne généré dans le clone n'est pas le certificat public. Les certificats publics sont vérifiés/générés avec acme.sh sous l'utilisateur acme sur les deux HAProxy, l'un après l'autre. Connexion hpr puis sudo -i, pas root SSH. Conserver le challenge HTTP-01 stateless avant la whitelist. Émission et déploiement Matomo ont réussi sur les deux nœuds lors de la recette. Un certificat valide pour le même domaine n'est pas à refaire parce que le backend est recréé ; revérifier validité, déploiement et renouvellement.

Ansible ajoute ACL du domaine, refus hors whitelist, redirection HTTPS et backend SNI vers 10.0.0.43:443. Matomo interne MERCURE3 : allowed_ajlsm uniquement. Pour un client, prévoir AJLSM et whitelist client selon les règles préprod. Le backend conserve ssl verify none : l'identité du backend n'est pas validée.

ansible-playbook -i inventory ./plays/deploy.haproxy.yml --syntax-check
ansible-playbook -i inventory ./plays/deploy.haproxy.yml --limit haproxy01.ajlsm.lan --check --diff
ansible-playbook -i inventory ./plays/deploy.haproxy.yml --limit haproxy02.ajlsm.lan --check --diff

Examiner tous les diffs puis appliquer séparément en retirant --check, attendre le succès du premier nœud avant le second. Aucun lancement Ansible automatique depuis Proxmox. Le check-mode n'est pas l'application réelle. Recette transmise : deux applications réussies, validation et restart signalés, aucun failed/unreachable. Avertissement Python découvert /usr/bin/python3.10, non bloquant dans ces exécutions. Aucun changement d'interpréteur ici.

Tester HTTPS sans -k depuis l'IP autorisée puis hors whitelist. Résultats transmis : 200 avec en-tête Matomo via VPN bureau, 403 hors whitelist. Un HTTP 200 n'est pas une validation d'installation fonctionnelle.

Tâches planifiées : correction ciblée puis audit

--scheduled-audit inventorie crontabs root/ajlsm/www-data, fichiers système, noms des scripts périodiques, timers systemd et instances Tomcat. Les commandes et arguments privés ne sont pas affichés. L'audit historique et l'inventaire avant traitement confirment 13 lignes Tomcat et trois processus, sans Pleade détecté. Après cycle du 18 octobre : zéro tâche Tomcat active pour les trois instances vides ; processus déjà lancés conservés et archivage mensuel inchangé. Les tâches des autres comptes, timers utilisateurs et contenus des scripts restent hors audit. L'inventaire seul n'effectue aucune désactivation. Code 0 = inventaire obtenu, pas tâches approuvées. Rotation des logs inchangée.

La phase tomcat-cron a été autorisée pour ne pas reproduire ces tâches inutiles sur les nouveaux clones. --scheduled-dry-run affiche les lignes reconnues à commenter ; --scheduled-apply demande OUI/NON, sauvegarde la crontab ajlsm et commente ces seules lignes avec un marqueur réversible. Elle ne lance aucune commande de démarrage, arrêt ou nettoyage Tomcat. Le cycle l'exécute en étape 15, puis audite le résultat en étape 16.

Critères conservateurs : répertoire Pleade présent et entièrement vide, webapps absent d'autre application et lien pleade vers le chemin attendu, pas de contexte externe dans conf/Catalina/localhost. Une implantation non vérifiable ou un contenu partiel conserve les tâches. Une commande inconnue visant une instance vide bloque la phase, sans modification partielle. Seules les formes exactes des commandes héritées auditées sont reconnues.

Sauvegarde privée : /var/backups/ajlsm-scheduled/transaction-* ; journal : /var/lib/ajlsm-scheduled/transaction.json. Vérification identité/UUID et empreinte de la crontab avant application, relecture après installation. Restauration tentée sur erreur contrôlée si elle n'écrase pas un changement concurrent détecté. Sinon journal conservé et reprise bloquée pour examen manuel. Le verrou ne protège pas contre crontab -e dans un autre terminal : ne pas modifier simultanément les tâches ou déployer une application pendant la phase. L'interface crontab ne fournit pas de comparaison-installation atomique face aux outils extérieurs. Les @reboot des premiers démarrages du clone peuvent déjà avoir lancé Tomcat : seuls les lancements futurs sont neutralisés. Pas de réactivation automatique lors d'une installation Pleade ultérieure.

Finalisation fonctionnelle, hors déploiement piloté

L'installateur Matomo a confirmé « Tables créées » dans la recette. Création du superadministrateur, premier site, fin de l'assistant et intégration du suivi restent manuelles. Ne pas laisser un installateur inachevé ouvert durablement. Lire FINALISATION-MATOMO.txt : reprise directe tablesCreation et avertissement sur systemCheck qui supprime la configuration locale préparée en version auditée. Diagnostics applicatifs non annoncés comme faits. Ne pas partager de secrets.

Point d’arrêt et reprise depuis tout répertoire

Le nouveau lanceur conserve un journal privé sur Saturne3 dans /var/lib/ajlsm-deploy/cycles/, mode 600, historique par exécution. Il n’enregistre ni mots de passe, ni sortie complète des phases. Il suit étape courante, dernière réussite, dates UTC, codes de sortie, empreintes du YAML/lot, hôte et identité VMID/UUID de la cible. Un verrou protège ce journal, pas les interventions d’un autre administrateur.

Avec chemins absolus, depuis n’importe quel répertoire du même nœud :

/opt/ajlsm-deploy/v1/ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3-initial.yaml --status
/opt/ajlsm-deploy/v1/ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3-initial.yaml --resume

--status ne contacte pas Proxmox et ne crée aucun journal. --resume reprend la première étape non réussie, avec contrôles et confirmations habituels. Une faute « ouii » à tls se reprend donc à tls sans reclonage. La reprise refuse les changements de nœud, YAML, code/ordre ou d’identité VM enregistrée. Elle ne relance pas un cycle déjà terminé. Après coupure brutale, en_cours signifie résultat inconnu : examiner les journaux transactionnels, l’état et les processus avant reprise. Le journal n’est pas une preuve de conformité permanente de l’infrastructure.

--from étape reste une reprise explicite après diagnostic, qui démarre un nouveau journal et marque les étapes antérieures ignorées, pas vérifiées. Ne pas effacer les journaux pour contourner une erreur. Les anciens lots sans journal ne permettent pas --resume rétroactif : consulter leur sortie console puis reprendre avec --from. Pour la VM actuelle, l’application de la dernière simulation Matomo n’est pas confirmée. Contrôler avant de reprendre à publication-matomo, sans clonage.

Détails de sécurité conservés de la documentation du 16 octobre

L’audit SSH lit la clé ED25519 via QEMU, vérifie son format binaire, puis compare indépendamment celle exposée par ssh-keyscan. Une divergence refuse la suite. Après concordance seulement, sauvegarde et remplacement atomique possible de /root/.ssh/known_hosts sur Saturne3 ; les autres hôtes sont conservés, y compris traitement ciblé des anciennes entrées hachées de l’IP du clone. --ssh-audit n’est donc pas entièrement sans écriture. --ssh-secure vérifie la syntaxe/effectivité et les connexions par clé avant/après reload ; le mot de passe local reste utile à sudo. --password-ajlsm utilise passwd interactif masqué ; aucun secret dans le YAML.

La personnalisation système conserve dans la VM /var/lib/ajlsm/system-personalisation/state.json et backup/. Ce journal décrit une transaction, pas le cycle global. Ne pas l’effacer pour forcer une reprise. La phase TLS vérifie le certificat interne /etc/ssl/ajlsm/server.crt, utilise si nécessaire /usr/local/sbin/ajlsm-init-tls.sh déjà présent dans le modèle, puis contrôle Apache. Cela ne valide pas les applications ou le TLS public. Le README applicatif /home/ajlsm/README ne doit pas être remplacé par le README-ajlsm-deploy de l’outil. Le document README-TEMPLATE3.txt est proposé séparément, pas installé automatiquement.

Validation YAML stricte : clés inconnues/répétées et types incorrects refusés ; environnement/tags interne, client, prod, sans doublons ; tags [] admis ; entiers positifs, mémoire minimale <= maximale, booléens true/false ; interfaces netN/ensN uniques, IPv4/CIDR, loopback /32, DNS sans préfixe. Passerelle dans le sous-réseau de son interface et distincte de la VM. Serveur, bridge et stockage sont à adapter à l’infrastructure, sans liste fermée inventée. Les sections métier sont désormais prises en charge : l’interdiction historique d’ajouter metier ne s’applique plus à ce schéma.

Manuels, reprise et validation du lot

Pages section 8 de la version 1.0.2 du 19 octobre : deploy, cycle, yaml, check, resources. Lecture locale avec man ./man8/ajlsm-deploy.8 ; sauvegarde et installation optionnelle décrites dans INSTALLATION-MANUELS.txt, sans copier les scripts. Le lancement définitif se fait dans /opt/ajlsm-deploy/v1, sans copier les programmes du nœud dans /usr/local/sbin. La commande invitée /usr/local/sbin/ajlsm-init-tls.sh reste distincte et n'est pas déplacée. Conserver le lot complet, modules et modèles, sans mélanger les versions. Une installation du lot ne remplace pas une recette complète sur Proxmox. Tests locaux sous tests/, résultats dans RAPPORT-TESTS.txt ; QGA, SQL, PHP et services simulés. Ils ne prouvent pas la réussite d'un déploiement distant. Une restauration de phase n'annule pas SQL ni les actions web ultérieures. Ne pas effacer un journal transaction.json pour forcer une reprise.

Réconciliation de la page reçue du 16 octobre et état de recette

Cette procédure remplace les indications historiques « 11 étapes », « NFS/Apache/Matomo hors cycle » et « aucun journal global ». Le nouveau lot compte 17 étapes avec publication protégée, mais la finalisation fonctionnelle Matomo reste indépendante. L’ancien man reproduit intégralement dans la page du 16 octobre n’est pas recopié ici : les cinq sources man8 de ce lot sont la référence de version, sans procédure concurrente. Les anciens chemins du 16 octobre restent des archives, pas le lot courant.

Le cycle 16 étapes du lot consolide-taches a été exécuté sur un clone recréé le 18 octobre, reprise TLS après faute de saisie incluse. Hostname et racine ext4 97 Gio confirmés. Tâches Tomcat neutralisées pour les instances vides ; les processus déjà lancés n’ont pas été arrêtés. Le correctif wait-online et le nouveau cycle 17 étapes avec journal restent à valider sur Proxmox. Les tests locaux ne sont pas une nouvelle recette distante. La capture « Tables créées » et la première activation Matomo concernent le clone antérieur : ne pas les attribuer automatiquement au clone actuel. Le succès nominal ne valide pas le repli réseau après panne.

Le modèle TEMPLATE3 n’a pas été modifié par ces scripts. Cela ne démontre pas l’absence de toute autre intervention. Sa mise à jour OS demandée est une maintenance à réaliser/valider séparément avant le prochain clonage. Aucun nettoyage serveur ni envoi SVN n’est exécuté par cette livraison.