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