# 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**.