Set-OPS-Public/wiki/Multi-instance-et-fédération.md
Daniel Allaire 0eae97c6ec underlay : monté par symlink depuis le dépôt de l'hébergeur
Il vivait gitignoré à la racine du moteur : consommé par deux générateurs,
validé par P23, versionné nulle part. La dizaine de modifications de la
journée n'était récupérable d'aucune façon, et un clone frais repartait du
gabarit.

Il appartient à l'hébergeur — ses switches, ses câbles — pas au moteur, qui
est générique, ni à un tenant, qui n'en possède pas. Chezlepro est ici
hébergeur ET tenant, d'où la confusion initiale.

Le moteur le monte par symlink 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.

Vérifié : les deux devis sortent identiques octet pour octet avant et après,
P23 verte, 24 preuves. Symlink brisé (clone sans dépôt frère) : dégrade
proprement, sections omises au lieu d'échouer. Cas exercé.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 17:05:12 -04:00

6.6 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 : 245 écosystèmes fédérés (borne IPv4).

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.

Le devis du commutateur. make devis-reseau dérive des nomenclatures fédérées la config à coller dans le switch : les VLAN par zone, les SVI (ip address …, passerelles) et les ACL d'isolation (default-deny inter-tenant — un tenant ne parle qu'à lui-même, le reste passe par OPNsense). C'est le pendant matériel de l'isolation logique.

Le dialecte de CLI. Toutes les CLI de switch ne se ressemblent pas. Set-OPS génère par défaut du Cisco (cisco), mais connaît aussi le Binardat (binardat), qui diffère sur deux pièges qui font 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)

(Le SVI ip address … 255.255.255.0 est en masque normal sur les deux — rien à changer.) Choisir le dialecte : make devis-reseau DIALECTE=binardat, la variable d'environnement SETOPS_DIALECTE=binardat (défaut permanent), ou l'option --dialecte. La GUI (vue Réseau, lecture seule) suit l'environnement. Le dépôt public reste générique (cisco).

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.

Underlay VLAN Sous-réseau
management (switches, Proxmox, OOB) 10 10.0.0.0/24
stockage / iSCSI 20 10.0.1.0/24
ceph-public 30 10.0.2.0/24
ceph-cluster 31 10.0.3.0/24

make underlay l'affiche et le valide : VLAN < 1000 et sous-réseaux hors des supernets tenant (10.(10+index).0.0/16) — aucune collision possible avec les overlays. 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 VLAN/adressage VRF, VLAN, namespaces Kubernetes, VPC
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

  1. Vois la flotte. make instances : l'active (★), les index, les VLAN, le statut fédéré/local. Repère qui est en production.
  2. Bascule. GUI, vue Réseau, bouton « Activer » sur une autre instance (ou make instance-utiliser NOM=…). Toutes les vues suivent — sans redémarrer.
  3. 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.
  4. Éprouve le garde-fou de collision. Essaie de créer une instance avec un index déjà pris : refus avant toute copie. Puis make prouverP21 veille sur la fédération.
  5. 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.
  6. (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).