Daniel Allaire
53d7b4c4c2
cloud-init n est pas un logiciel d installation : c est une SOURCE DE VERITE EXTERNE. Il se reveille a chaque demarrage et relit le lecteur attache par l hyperviseur, qui peut redefinir comptes, cles SSH, mots de passe et reseau. Sur une machine que le plan possede, c est un second maitre — que le plan ne decrit pas, que make valider ne mesure pas, et qui parle en premier. Sa tache est finie a la premiere seconde : c est parce qu il a REUSSI a poser l adresse et les cles qu Ansible a pu entrer. TROIS MOITIES, ET ELLES SE DEFONT SEPAREMENT. - le GABARIT le garde : sans lui un clone n a ni adresse ni nom ; - le SOCLE ne l installe plus : le garder produisait un va-et-vient a chaque deploiement, deux changed par passage, idempotence perdue ; - le DURCISSEMENT le retire (roles/cloud_init_retrait, en dernier). P63 garde les trois, plus le CONTENU du role : une coquille vide passerait les trois premiers controles sans rien fermer. Quatre controles negatifs rejoues. CE QUI REND LE RETRAIT SUR EST MESURE, PAS SUPPOSE (obs-01, 2026-09-09) : /etc/network/interfaces.d/50-cloud-init n appartient a aucun paquet — dpkg -S ne le trouve pas — et le postrm ne le nomme jamais, meme en purge. L adresse survit. Le role le verifie quand meme, avant et apres, et n accuse que si le retrait l a emporte : une VM qui perd ce fichier ne se plaint pas, elle repart sans adresse et plus personne ne peut entrer. DEUX CHOIX DITS FRANCHEMENT. cloud-guest-utils reste (growpart : ni service, ni port, ni source de donnees). Les ~29 paquets orphelins ne sont pas retires par defaut : autoremove deciderait a partir des drapeaux dpkg, et un durcissement ne doit pas pouvoir surprendre. NON DEPLOYE : le code est ecrit, valide et prouve ; il n a pas ete applique a la flotte. Essai a blanc sur obs-01 : cloud-init a retirer, configuration reseau intacte. make prouver : CONFORME, 62 OK, 0 echec, 1 saute (63 preuves). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
88 lines
4.4 KiB
Markdown
88 lines
4.4 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.
|
|
|
|
*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**.
|