Set-OPS-Public/wiki/Virtualisation-et-clonage.md
Daniel Allaire 53d7b4c4c2 durcissement : cloud-init nait avec la VM et ne lui survit pas
cloud-init n est pas un logiciel d installation : c est une SOURCE DE
VERITE EXTERNE. Il se reveille a chaque demarrage et relit le lecteur
attache par l hyperviseur, qui peut redefinir comptes, cles SSH, mots de
passe et reseau. Sur une machine que le plan possede, c est un second
maitre — que le plan ne decrit pas, que make valider ne mesure pas, et
qui parle en premier.

Sa tache est finie a la premiere seconde : c est parce qu il a REUSSI a
poser l adresse et les cles qu Ansible a pu entrer.

TROIS MOITIES, ET ELLES SE DEFONT SEPAREMENT.
 - le GABARIT le garde : sans lui un clone n a ni adresse ni nom ;
 - le SOCLE ne l installe plus : le garder produisait un va-et-vient a
   chaque deploiement, deux changed par passage, idempotence perdue ;
 - le DURCISSEMENT le retire (roles/cloud_init_retrait, en dernier).
P63 garde les trois, plus le CONTENU du role : une coquille vide passerait
les trois premiers controles sans rien fermer. Quatre controles negatifs
rejoues.

CE QUI REND LE RETRAIT SUR EST MESURE, PAS SUPPOSE (obs-01, 2026-09-09) :
/etc/network/interfaces.d/50-cloud-init n appartient a aucun paquet — dpkg
-S ne le trouve pas — et le postrm ne le nomme jamais, meme en purge.
L adresse survit. Le role le verifie quand meme, avant et apres, et n
accuse que si le retrait l a emporte : une VM qui perd ce fichier ne se
plaint pas, elle repart sans adresse et plus personne ne peut entrer.

DEUX CHOIX DITS FRANCHEMENT. cloud-guest-utils reste (growpart : ni
service, ni port, ni source de donnees). Les ~29 paquets orphelins ne sont
pas retires par defaut : autoremove deciderait a partir des drapeaux dpkg,
et un durcissement ne doit pas pouvoir surprendre.

NON DEPLOYE : le code est ecrit, valide et prouve ; il n a pas ete
applique a la flotte. Essai a blanc sur obs-01 : cloud-init a retirer,
configuration reseau intacte.

make prouver : CONFORME, 62 OK, 0 echec, 1 saute (63 preuves).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-09 09:25:42 -04:00

4.4 KiB

Virtualisation & clonage

Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.


① Le concept (générique)

La virtualisation fait tourner plusieurs machines virtuelles (VM) — chacune avec son OS — sur un seul serveur physique (l'hyperviseur). Isolation, densité, souplesse.

Image / golden template : au lieu de réinstaller chaque VM, on prépare une image de référence, propre et durcie, puis on la clone. Rapide et reproductible.

cloud-init : au premier démarrage d'un clone, il lui donne son identité initiale (nom d'hôte, IP, clé SSH, agrandissement du disque). C'est l'amorçage, pas la configuration complète.

Idée-force : la VM devient jetable/reconstructible. Ce qui est précieux, c'est la donnée (voir Sauvegardes), pas la machine.


② Comment Set-OPS le fait

  • Proxmox = l'hyperviseur (cluster).
  • Un golden template (modeleSetOPS) : Debian minimal, durci, avec le compte technique ansible, qemu-guest-agent, cloud-init… — préparé une fois. (Cette unité l'appelait basiqueChezlepro jusqu'au 2026-09-06 : c'est l'ancien nom. Le nom en vigueur est celui qu'enregistre make config sous proxmox_clone_source_nom, et il doit correspondre au nom réel du template dans Proxmox — sinon le clonage ne trouve pas sa source.)
  • Chaque nœud = un clone du template. cloud-init pose l'identité (hostname, IP dérivée de la nomenclature, clé SSH).
  • Puis Set-OPS/Ansible fait la vraie configuration (les rôles).

Séparation nette, à retenir :

Proxmox + cloud-init  ──> identité initiale de la VM
Set-OPS  + Ansible    ──> configuration réelle du serveur

C'est pour ça que l'infra est reconstructible : cloner + reconfigurer = quelques minutes.

Et cloud-init s'efface ensuite. Il ne s'arrête pas après la première seconde : il se réveille à chaque démarrage et relit le lecteur que l'hyperviseur a attaché à la VM — un lecteur qui peut redéfinir les comptes, les clés SSH autorisées, les mots de passe et le réseau. Sur une machine que le plan possède désormais, c'est un second maître : le plan ne le décrit pas, make valider ne le mesure pas, et il parle en premier.

Le durcissement (serveur_durci) le retire donc, une fois qu'il a réussi — et c'est parce qu'il a réussi qu'Ansible a pu entrer. Le gabarit, lui, le garde : sans lui, un clone n'a ni adresse ni nom d'hôte.

Pourquoi ça ne coupe pas le réseau : l'adresse posée à la naissance vit dans /etc/network/interfaces.d/50-cloud-init, un fichier qui n'appartient à aucun paquet — dpkg -S ne le trouve pas, et le postrm ne le nomme jamais, même en purge (mesuré le 2026-09-09). Le rôle le vérifie quand même, avant et après : une VM qui perd ce fichier ne se plaint pas, elle repart sans adresse et plus personne ne peut entrer pour le voir.


③ Pourquoi c'est transférable

Set-OPS Équivalents ailleurs
Proxmox (KVM) VMware · Hyper-V · KVM/libvirt · nuage (EC2, GCE…)
golden template AMI, image cloud, Packer
cloud-init standard de toutes les images cloud

Tu as appris VM/hyperviseur, image de référence, cloud-init, l'infra jetable — pas « Proxmox ».


④ À toi de jouer

  1. Regarde un clone. Dans la GUI (make inventaire-ui), un serveur actif a été cloné du template (bouton « 🖥 Créer la VM »). Son VMID/IP sont dérivés de la nomenclature.
  2. Vois l'identité cloud-init. Sur un nœud : cloud-init query hostname, hostname -f, et l'agrandissement du disque racine (df -h /).
  3. Sépare les deux couches. cloud-init a posé l'identité ; tout le reste (paquets, services, durcissement) vient d'Ansible. Le template, lui, ne contient aucune donnée de clone.
  4. Casse & répare (mentalement + lab). Supprime un nœud non critique et reclone-le depuis le template, puis redéploie : il revient à l'identique. Tu sens que la machine est reconstructible.

Pour aller plus loin (dépôt)

  • Playbooks Proxmox : playbooks/proxmox/ ; rôle cloud_init ; préparation du modèle : playbooks/modeles_vm/.
  • Golden template = actif central (jamais jetable, cloné pour chaque VM).
  • Ce qui est précieux = la donnée : unité Sauvegardes.