wiki : l'axe « méthode » (plan dérivé, multi-instance, preuve, glossaire)
Le wiki enseignait les fondamentaux SERVICES mais pas la MÉTHODE. Quatre pages
au moule à 4 temps (concept -> Set-OPS -> transférable -> à toi de jouer), avec
exercices concrets :
- Le plan & l'adressage dérivé (un seed, tout en découle).
- Multi-instance & fédération (un moteur, N écosystèmes ; découverte par
convention, garde-fou P21).
- La preuve (ne jamais affirmer plus que ce qu'on prouve ; make prouver P01-P21).
- Glossaire (24 concepts ; était « à venir »).
Raccordées dans Home.md et _Sidebar.md (section « Flotte & preuve »). Le wiki
pointe vers docs/, ne recopie pas. 855 -> 1573 lignes, 22 pages, aucun lien mort.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 15:05:56 -04:00
|
|
|
|
# Glossaire
|
|
|
|
|
|
|
|
|
|
|
|
Les concepts-clés de Set-OPS, en une phrase chacun. Les mots *en italique* renvoient à une autre
|
|
|
|
|
|
entrée. Le détail vit dans les **unités d'apprentissage** et le dépôt (`docs/`).
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
**Adressage dérivé** — Les IP, VLAN, VMID, sous-réseaux ne sont pas saisis : ils se **calculent**
|
|
|
|
|
|
depuis le *seed*. Cf. [Le plan & l'adressage dérivé](Le-plan-et-l-adressage-dérivé).
|
|
|
|
|
|
|
|
|
|
|
|
**Binding (liaison)** — Relation déclarative entre entités du plan (app→app, app→base) résolue par
|
|
|
|
|
|
le moteur, sans coder de variables à la main. Cf. [Liaisons (bindings)](Liaisons-bindings).
|
|
|
|
|
|
|
|
|
|
|
|
**DIFF VIDE** — État sain où le *plan* reproduit **exactement** l'inventaire généré : la source de
|
|
|
|
|
|
vérité et l'artefact concordent. Vérifié par `make instancier`.
|
|
|
|
|
|
|
|
|
|
|
|
**Fédération** — Ensemble des *instances* qui cohabitent sur une infrastructure partagée, chacune
|
|
|
|
|
|
avec son *index* unique. Cf. [Multi-instance & fédération](Multi-instance-et-fédération).
|
|
|
|
|
|
|
|
|
|
|
|
**`federe: false`** — Drapeau marquant un *bac à sable* local, **exclu** du réseau convergé (il ne
|
|
|
|
|
|
provisionne pas ses VLAN sur les switches de production).
|
|
|
|
|
|
|
|
|
|
|
|
**Hôte fantôme** — Erreur de plan : une application posée sur un hôte **non déclaré** dans les
|
|
|
|
|
|
serveurs. Refusé par la preuve **P06** et par la création de modèle.
|
|
|
|
|
|
|
|
|
|
|
|
**Idempotence** — Rejouer la même description N fois donne le même résultat (`changed=0` après la
|
|
|
|
|
|
1ʳᵉ fois). Cf. [Infra as Code & idempotence](Infra-as-Code-et-idempotence).
|
|
|
|
|
|
|
|
|
|
|
|
**Index (seed)** — Le **seul** intrant d'adressage d'une instance. Détermine supernet
|
adressage : le decalage de +10 est retire, l'index se lit dans l'adresse
supernet_de rendait 10.(10+index).0.0/16. Personne ne savait plus pourquoi : ni le
commentaire de la constante, ni le wiki, ni le commit fondateur 36a882b ne le
justifiaient. Trois endroits consultes, zero raison ecrite.
Ses deux effets constates :
- il reservait 10.0-10.9 sous la plage tenant. Utile tant que l'underlay vivait
la — mais D-77 l'a fait entrer dans la bande basse de son propre /16, ce qui a
vide cette reserve de son role la veille ;
- il eloignait le premier tenant de 10.0.0.0/16, la plage la plus repandue en
reseau domestique. Ce risque revient donc aux index bas, et c'est ASSUME.
En echange l'index se lit directement dans l'adresse (17 -> 10.17.x.x) et le
plafond passe de 245 a 255 ecosystemes federes.
Chezlepro (17) 10.27.0.0/16 -> 10.17.0.0/16
Technolibre (11) 10.21.0.0/16 -> 10.11.0.0/16
lab (1) 10.11.0.0/16 -> 10.1.0.0/16
Doc alignee : les trois pages du wiki, multi-instances.md (plafond et exemple
devenus faux arithmetiquement), sdn-evpn.md, le libelle de la GUI, la docstring
d'underlay.py, D-77, et le document de preparation d'un site hebergeur. Les
CONSTATS DE TERRAIN dates sont laisses tels quels : ce sont des mesures.
CE COMMIT NE RENUMEROTE RIEN. Il change ce que le plan DERIVE ; l'inventaire
applique porte toujours 10.27.x.x et les quatorze VM tournent dessus. Appliquer
sans reconstruire rendrait la flotte injoignable — le renumerotage est une
operation a part, a mener a froid.
Au passage, retire un debris : une copie de conflit Nextcloud de
serveur_powerdns/defaults/main.yml, IDENTIQUE a l'original, commitee par accident
dans 1295eea et jamais chargee par Ansible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-12 16:16:08 -04:00
|
|
|
|
(`10.<index>`), VLAN (`1000+index×10+zone`), VMID. Unique par instance fédérée.
|
wiki : l'axe « méthode » (plan dérivé, multi-instance, preuve, glossaire)
Le wiki enseignait les fondamentaux SERVICES mais pas la MÉTHODE. Quatre pages
au moule à 4 temps (concept -> Set-OPS -> transférable -> à toi de jouer), avec
exercices concrets :
- Le plan & l'adressage dérivé (un seed, tout en découle).
- Multi-instance & fédération (un moteur, N écosystèmes ; découverte par
convention, garde-fou P21).
- La preuve (ne jamais affirmer plus que ce qu'on prouve ; make prouver P01-P21).
- Glossaire (24 concepts ; était « à venir »).
Raccordées dans Home.md et _Sidebar.md (section « Flotte & preuve »). Le wiki
pointe vers docs/, ne recopie pas. 855 -> 1573 lignes, 22 pages, aucun lien mort.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 15:05:56 -04:00
|
|
|
|
|
|
|
|
|
|
**Instance** — Un écosystème réel (un *tenant*) : `../OPS-<nom>`, avec ses valeurs concrètes
|
|
|
|
|
|
(domaine, *voûte*, index). L'active est celle que pointe le symlink `instance/`.
|
|
|
|
|
|
|
|
|
|
|
|
**ip-miroir** — Schéma de VMID à 9 chiffres où le numéro **contient** l'IP et le tenant
|
|
|
|
|
|
(`VLAN·octet-hôte·séquence`) — lisible d'un coup d'œil.
|
|
|
|
|
|
|
|
|
|
|
|
**Modèle** — Un *plan* **générique** réutilisable (valeurs *placeholder*, sans *voûte*), dans le
|
|
|
|
|
|
dépôt privé `Set-OPS-Modeles`. Le socle public en est la preuve libre. On en crée une instance
|
|
|
|
|
|
(`instance-creer`) ; on en fabrique un (`model-creer`).
|
|
|
|
|
|
|
|
|
|
|
|
**Nomenclature** — Le registre du **modèle réseau** : zones, placement des fonctions, et le *seed*
|
|
|
|
|
|
`index`. Ne contient **aucun** adressage (il en dérive — preuve P20).
|
|
|
|
|
|
|
|
|
|
|
|
**Le plancher** — La première couche de résolution de noms : `/etc/hosts` posé par le socle, avant
|
|
|
|
|
|
même que le DNS soit debout. Cf. [DNS & résolution](DNS-et-résolution).
|
|
|
|
|
|
|
|
|
|
|
|
**Plan** — La source unique de vérité (`instance/plan/` : serveurs, applications, bases, domaines,
|
|
|
|
|
|
nomenclature). On l'édite ; l'inventaire en est **généré**, jamais l'inverse.
|
|
|
|
|
|
|
|
|
|
|
|
**Preuve (Pxx)** — Une vérification rejouable du harnais `make prouver` qui garde une classe
|
|
|
|
|
|
d'erreur. Cf. [La preuve](La-preuve).
|
|
|
|
|
|
|
|
|
|
|
|
**Socle** — L'infrastructure de base souveraine (DNS, PKI, edge TLS, relais courriel) — le modèle
|
|
|
|
|
|
minimal public, extensible.
|
|
|
|
|
|
|
|
|
|
|
|
**Tenant** — Synonyme d'*instance* dans le contexte de la *fédération* : un écosystème isolé parmi
|
|
|
|
|
|
d'autres.
|
|
|
|
|
|
|
|
|
|
|
|
**Voûte (vault)** — Le fichier chiffré des secrets d'une instance (`vault.yml`, Ansible Vault).
|
|
|
|
|
|
**Jamais** dans un *modèle* ni versionné ; seul le gabarit `vault.yml.example` l'est.
|
|
|
|
|
|
|
|
|
|
|
|
**Zone** — Un domaine de sécurité (un `/24` + un VLAN) : Frontière, Identité, Données,
|
|
|
|
|
|
Services-infra, Observabilité, Applications. Un pare-feu les sépare.
|