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

11 KiB

Raw Blame History

Multi-instance & fédération

Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.

① Le concept (générique)

Un même moteur peut opérer plusieurs écosystèmes (organisations, clients, environnements). Trois questions se posent :

Isolation — chaque écosystème (tenant) doit être étanche : ses données, son identité, son réseau ne touchent pas ceux des autres.
Cohabitation sans collision — si plusieurs tenants partagent une infrastructure physique (mêmes switches, même hyperviseur), leurs adresses et VLAN doivent être uniques globalement, sinon le réseau se marche dessus.
Découverte — comment le système sait-il quels écosystèmes existent ? Par un registre central (qu'il faut tenir à jour) ou par convention (ils se reconnaissent d'eux-mêmes) ?

② Comment Set-OPS le fait

Un dépôt par écosystème. L'écosystème actif est celui que pointe le symlink instance/. Les autres sont des dépôts frères (../OPS-Chezlepro, ../OPS-Technolibre…).

Découverte par convention, pas de registre. Une instance est un dossier frère avec un plan/nomenclature.yml portant un index. Le code fait glob('../*/plan/nomenclature.yml') — rien à inscrire nulle part. Déposer une instance à côté des autres suffit.

Le seed garantit l'unicité. Chaque tenant a un index distinct → adressage dérivé sans chevauchement possible : VLAN 1000+index×10+zone (les VLAN de deux index différents ne peuvent mathématiquement pas se croiser). Plafond : le 2ᵉ octet IPv4, soit un index de 0 à 255 — en évitant 0, où vivent les réseaux de service du site. (Cette unité annonçait 245, un reste de l'époque où l'adressage valait 10.<10+index> ; ce décalage a été retiré le 2026-08-12, justement pour qu'on lise l'index directement dans l'adresse.)

Gérer la flotte :

make instances — la vue d'ensemble : qui existe, l'active (★), index, VLAN, collision ;
make instance-utiliser NOM=… ou le bouton « Activer » de la GUI (vue Réseau) — basculer ;
make instance-creer NOM=… MODELE=… — créer une instance depuis un modèle ;
make model-creer … — créer/promouvoir un modèle (le produit).

Garde-fous. federe: false exclut un bac à sable local du réseau convergé. La preuve P21 échoue si deux instances fédérées partagent un index.

Qui route les tenants : deux mondes. L'adressage dérive toujours du seed index, mais qui l'applique se déclare — underlay.routage_tenants :

	`switch`	`sdn`
Passerelle d'une zone	SVI sur le commutateur L3	anycast sur chaque hyperviseur
Isolation inter-tenant	ACL de commutateur	VRF (une zone EVPN par tenant)
Sur le fil	VLAN étiquetés par zone	VXLAN — aucun VLAN de tenant ne circule
Inter-tenant	bloqué par ACL	sort du VRF → passe par la frontière

Le .1 d'une passerelle ne change pas d'adresse d'un monde à l'autre : il change de porteur. C'est la même dérivation, appliquée ailleurs.

Le devis du commutateur. make devis-reseau dérive la config à coller. En mode switch : VLAN par zone, SVI, ACL d'isolation. En mode sdn : rien de tout ça — le commutateur redevient un transport IP qui achemine du VXLAN sans le lire, et le devis dit à sa place pourquoi ces sections ont disparu.

Le devis de la frontière. make devis-opnsense dérive la politique de bordure du même registre des flux — les flux pair: externe, que le pare-feu d'hôte saute justement parce qu'ils relèvent de la bordure. Rien n'y est saisi : ni port, ni adresse, ni nom d'hôte.

Le dialecte de CLI. Toutes les CLI de commutateur ne se ressemblent pas. Set-OPS génère par défaut du Cisco, mais connaît aussi le Binardat, qui diffère sur des détails capables de faire passer un VLAN mais fuir un tenant :

	Cisco	Binardat
Masque d'ACL	inversé (wildcard `0.0.255.255`)	normal (`255.255.0.0`)
Commentaire d'ACL	`remark …`	absent (omis)
Route statique	`ip route <réseau> <masque> <saut>`	CIDR : `ip route 0.0.0.0/0 <saut>`

(Le SVI ip address … 255.255.255.0 est en masque normal sur les deux.) Le dialecte est un intrant — section Fabric du panneau — surchargeable par --dialecte ou SETOPS_DIALECTE. Le dépôt public reste générique (cisco).

La leçon qui vaut au-delà de Set-OPS. Trois de ces formes ont été supposées avant d'être confrontées au matériel ; deux étaient fausses. La pire ne levait aucune erreur : switchport trunk allowed vlan **add** … ajoute à la liste courante, et sur un port neuf qui autorise déjà tout, elle ne retranchait rien. La configuration avait l'air d'isoler et n'isolait pas. Une commande acceptée n'est pas une commande qui fait ce qu'on croit.

L'underlay — le sous-sol. Les VLAN tenant (1000+index×10+zone) sont les overlays. En dessous vit la fabric physique partagée par toute la flotte : management des switches et de Proxmox/OOB, iSCSI, Ceph (public + cluster). Elle n'appartient à aucun tenant et ne dérive d'aucun index. On la décrit dans underlay.yml, qui vit dans le dépôt de l'hébergeur (ses switches, ses câbles) et que le moteur monte par symlink à sa racine — comme il monte le plan par instance/. Ce lien ne suit pas make instance-utiliser : la fabric reste celle de l'hébergeur, quel que soit le tenant actif. Gabarit : underlay.yml.example.

Ne pas recopier de table ici. Cette unité en portait une, figée, et aucune de ses cinq lignes n'était encore vraie après la bascule d'adressage de la fabric (D-77/D-78, terminée le 2026-08-22). Un underlay n'est pas un modèle : c'est la description d'un matériel particulier, propre à un hébergeur. On le demande :
make underlay        # affiche l'underlay monté, et le valide
Ce qu'on y trouve chez l'hébergeur de référence, à titre d'illustration seulement : un plan d'administration sans VLAN (segment physique, 10.17.0.0/24), le contrôle de la grappe à part (vmbr0, 192.168.11.0/24), un transit vers la frontière, un réseau de transport VXLAN, trois réseaux de stockage sur leur propre fabric en MTU 9000, et les zones du site lui-même — l'hébergeur est aussi un exploitant, ses machines vivent là.

Deux choses à retenir, qui ne dépendent d'aucune table.

Les fabrics. Tous les réseaux ne partagent pas les mêmes câbles. Le stockage jumbo peut vivre sur ses propres commutateurs ; le devis de l'une ne déclare alors rien de l'autre, et le dit — HORS PERIMETRE. Un devis est une configuration qu'on applique, pas un inventaire.

Le transit. C'est le lien entre le routeur et la frontière, et sans lui la flotte n'a ni sortie ni chemin de retour. Il vit dans l'underlay parce qu'il est partagé : la frontière route vers tous les tenants par ce même saut, il ne peut donc dériver d'aucun index.

Le piège qui a coûté une passe de déploiement. La route aller ne suffit pas. Sans route de retour vers le réseau d'administration, la réponse d'une VM sort par une autre interface que celle où l'état a été créé, et le pare-feu la jette en silence — ni réponse, ni message d'erreur. Symptôme déroutant : la passerelle répond au ping, aucun hôte derrière elle n'est joignable. On cherche une règle de pare-feu ; c'est une route manquante à l'autre bout.

En mode sdn, le transport porte du VXLAN : le MTU des réseaux de la fabric du routeur doit valoir l'overlay déclaré plus 50 octets d'encapsulation. make underlay le refuse en dessous, et le dit — sous ce seuil, le ping passe et les transferts échouent, la panne la plus coûteuse à diagnostiquer de cette couche.

make underlay l'affiche et le valide : VLAN < 1000, et pas de chevauchement accidentel avec un supernet de tenant. « Accidentel », parce qu'il en existe un voulu : le plan d'administration de l'hébergeur occupe la bande basse du /16 d'un tenant (D-77). Les zones d'un tenant commencent au 3ᵉ octet 16 ; la bande 0-15 lui est libre. Ce n'est pas une collision, mais il faut le déclarer (bande_basse_de:) — sinon le validateur ne peut pas faire la différence, et il refuse. make devis-reseau en émet la config (section 0) et l'ajoute au trunk. La preuve P23 garde la règle ; elle est sautée si aucun underlay.yml n'est défini.

③ Pourquoi c'est transférable

Set-OPS	Équivalents ailleurs
un moteur, N tenants	multi-tenancy SaaS, cloud accounts/projects
isolation par VRF (zone EVPN)	VRF matériel, VPC, namespaces Kubernetes
découverte par convention	convention over configuration (Rails, etc.)
tenants NetBox	modèle de source de vérité multi-tenant

Tu as appris le multi-tenant, l'isolation réseau, la convention plutôt que la configuration — pas « le symlink de Set-OPS ».

④ À toi de jouer

Vois la flotte. make instances : l'active (★), les index, les VLAN, le statut fédéré/local. Repère qui est en production.
Bascule. GUI, vue Réseau, bouton « Activer » sur une autre instance (ou make instance-utiliser NOM=…). Toutes les vues suivent — sans redémarrer.
Crée une instance. make instance-modeles (les modèles dispo), puis make instance-creer NOM=OPS-Test MODELE=socle INDEX=4. Un écosystème neuf, en une commande.
Éprouve le garde-fou de collision. Essaie de créer une instance avec un index déjà pris : refus avant toute copie. Puis make prouver → P21 veille sur la fédération.
Casse & répare. Donne à deux instances fédérées le même index (édite une nomenclature), make instances : la bannière de collision s'allume ; make prouver : P21 échoue. Corrige l'index : tout redevient vert.
(Avancé) Promeus un produit. Une instance qui tourne et se prouve peut devenir un modèle vendable : make model-creer MODE=instance SOURCE=OPS-… NOM=… — elle est généralisée (identité → exemple.*, secrets retirés) et validée.

Pour aller plus loin (dépôt)

Le guide complet : docs/multi-instances.md.
Le seed et la dérivation : unité Le plan & l'adressage dérivé.
L'isolation réseau (VLAN, ACL, OPNsense) : make devis-reseau + scripts/devis_reseau.py.
Les garde-fous prouvés : unité La preuve (P21).

11 KiB Raw Blame History Unescape Escape