# 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** (`basiqueChezlepro`) : Debian minimal, durci, avec le compte technique
  `ansible`, qemu-guest-agent, cloud-init… — préparé **une fois**.
- 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.

---

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