verifier / verifier (push) Has been cancelled

Details

documentation : la tournee des 74 documents, parce qu un balayage ne lit pas

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

2026-09-06 16:18:23 -04:00

3.3 KiB

Raw Blame History

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

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ô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.

3.3 KiB Raw Blame History