Daniel Allaire
5bc3bceac1
Some checks failed
verifier / verifier (push) Has been cancelled
La revision a commence par un balayage par motifs — chemins morts, cibles make absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque tout le reste : un motif ne voit que ce qui s exprime en motif. make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus haut. Il fallait lire pour la voir. 74 documents lus un par un. 66 corriges, 8 exacts. CE QUI ETAIT FRANCHEMENT FAUX AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre des VM reelles. Elle a ete rasee et remontee depuis zero trois fois. ecosysteme-chezlepro.md, le document montre a un client, portait la meme phrase : il se sous-vendait gravement. courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n est construit alors qu il rapporte des mesures datees du role en fonctionnement. hebergeur-exploitation.md disait rien n est fait d un depot qui existe. filiation-emancipation.md se contredisait a deux ecrans de distance. DES MODELES DECRITS D APRES UN MONDE ANTERIEUR Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le donnaient en exemple d integration FACULTATIVE — il est universel depuis le 2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki qui avait raison. CE QUI CASSE AU PREMIER ESSAI Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le FABRIQUE et le critere R2 de l epreuve d operateur independant. preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait detruite : raser derive du plan, il ne la detruira jamais — le risque est l inverse. Un mot de passe d essai en clair dans un depot public. DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux declarations reelles : 12 annonces, 21 reels. Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une erreur ajoute l assurance a l erreur. CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il nomme existe. P29 tient les positions d authentification, personne ne tient les habilitations. make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
72 lines
3.3 KiB
Markdown
72 lines
3.3 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.
|
|
|
|
---
|
|
|
|
## ③ 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**.
|