Daniel Allaire
f89b097b26
La premiere redaction se lisait comme une emancipation. Elle n en est pas une, et il valait mieux le dire que de laisser un lecteur presse en conclure trop. Retirer cloud-init n ote AUCUN pouvoir a l hebergeur. qemu-guest-agent est au gabarit — il doit y etre (P56) — et l API Proxmox expose sur son dos, sur toute VM vivante de la flotte, un pouvoir strictement plus grand que le lecteur cloud-init. Releve le 2026-09-09 sur edge-mta-01, avec le jeton du site : exec, exec-status, file-read, file-write, set-user-password, shutdown. Ce que D-85 ferme est donc precis et etroit : une reapplication AUTOMATIQUE a chaque demarrage, depuis un support que le plan ne possede pas et qu aucune preuve ne lit ; et le code de cloud-init lui-meme, un interpreteur Python complet execute en root au boot avec ses ~29 dependances. La mainmise d un hyperviseur sur ses invites est une propriete de la VIRTUALISATION, pas de cloud-init — elle appelle sa propre decision, qui n est pas prise. LE SEUIL EST NOMME. L alternative existe et sa piece est deja au gabarit : poser adresse et cle par agent/file-write + agent/exec, sans reseau. Aujourd hui ce serait reimplementer un standard, ce que positionnement.md interdit, au moment le plus fragile et pour le pire mode de panne — une VM injoignable. Le jour ou une premiere seconde ne pourra plus etre amorcee par Proxmox (autre hyperviseur, metal nu, hebergeur sans API), ce chemin devient LE chemin portable. La nuance est portee partout ou l affirmation est faite : D-85, le README et l entete du role, AGENTS.md, le wiki. make prouver : CONFORME, 62 OK, 0 echec, 1 saute. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
97 lines
5 KiB
Markdown
97 lines
5 KiB
Markdown
# 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**.
|