Set-OPS-Public/wiki/Virtualisation-et-clonage.md

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.

Ce que ça ne fait pas : ça ne reprend pas la main à l'hébergeur. qemu-guest-agent reste sur chaque VM — il doit y être, c'est par lui que la création confirme qu'une machine existe — et l'API de l'hyperviseur expose sur son dos exec, file-write, set-user-password, shutdown : strictement plus que le lecteur cloud-init. Ce qui est fermé est plus étroit, et bien réel : une réapplication automatique, à chaque démarrage, depuis un support que le plan ne possède pas, et un interpréteur Python complet lancé en root au démarrage. Qu'un hyperviseur puisse tout faire chez ses invités est une propriété de la virtualisation, pas de cloud-init.

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.