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
4.4 KiB
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 techniqueansible, qemu-guest-agent, cloud-init… — préparé une fois. (Cette unité l'appelaitbasiqueChezleprojusqu'au 2026-09-06 : c'est l'ancien nom. Le nom en vigueur est celui qu'enregistremake configsousproxmox_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-initpose 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
- 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. - Vois l'identité cloud-init. Sur un nœud :
cloud-init query hostname,hostname -f, et l'agrandissement du disque racine (df -h /). - 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.
- 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ôlecloud_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.