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
|
|
|
|
# Le plan & l'adressage dérivé
|
|
|
|
|
|
|
|
|
|
|
|
> **Unité d'apprentissage.** Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## ① Le concept *(générique)*
|
|
|
|
|
|
|
|
|
|
|
|
Une infrastructure a **beaucoup** de valeurs : adresses IP, VLAN, identifiants de VM,
|
|
|
|
|
|
sous-réseaux, passerelles, noms d'hôtes… Deux façons de les gérer :
|
|
|
|
|
|
|
|
|
|
|
|
- **Les saisir à la main** — chaque valeur est décidée et écrite quelque part. Fragile : deux
|
|
|
|
|
|
endroits finissent par se contredire (l'un dit `10.11.13.11`, l'autre `data-01`), et personne
|
|
|
|
|
|
ne sait lequel a raison.
|
|
|
|
|
|
- **Les DÉRIVER d'une source unique** — on ne saisit qu'un **seed** (une graine), et *tout le
|
|
|
|
|
|
reste se calcule*. Il ne peut plus y avoir de contradiction : il n'y a qu'une vérité.
|
|
|
|
|
|
|
|
|
|
|
|
C'est le principe **DRY** (*Don't Repeat Yourself*) appliqué à l'infrastructure, et le principe
|
|
|
|
|
|
de la **source unique de vérité**. Le plan **déclaratif** décrit *l'état voulu* ; l'adressage n'y
|
|
|
|
|
|
est pas *écrit*, il en **découle**.
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## ② Comment Set-OPS le fait
|
|
|
|
|
|
|
|
|
|
|
|
Le **plan** (`instance/plan/`) est la source unique. Cinq registres :
|
|
|
|
|
|
|
|
|
|
|
|
| Registre | Décrit |
|
|
|
|
|
|
|---|---|
|
|
|
|
|
|
| `serveurs.yml` | les VM (fonction, état, intégrations) |
|
|
|
|
|
|
| `applications.yml` | les services et leurs **liens** |
|
|
|
|
|
|
| `bases-donnees.yml` | les bases et qui les consomme |
|
|
|
|
|
|
| `domaines.yml` | les zones DNS publiques |
|
|
|
|
|
|
| `nomenclature.yml` | le **modèle réseau** : zones + placement des fonctions + le **seed `index`** |
|
|
|
|
|
|
|
|
|
|
|
|
**Le seed, c'est `index`.** À partir de lui *seul*, Set-OPS dérive **tout** l'adressage :
|
|
|
|
|
|
|
|
|
|
|
|
| Élément | Formule (modèle 6 zones) |
|
|
|
|
|
|
|---|---|
|
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
|
|
|
|
| Supernet | `10.<index>.0.0/16` |
|
|
|
|
|
|
| Sous-réseau de zone | `10.<index>.(15+zone).0/24` |
|
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
|
|
|
|
| Passerelle | `…(15+zone).1` |
|
|
|
|
|
|
| VLAN sur le trunk | `1000 + index×10 + zone` |
|
|
|
|
|
|
| VMID | `VLAN·octet-hôte·séquence` (9 chiffres) |
|
|
|
|
|
|
|
|
|
|
|
|
`make instancier` **génère** `hosts.yml` depuis le plan. **On n'édite jamais `hosts.yml` à la
|
|
|
|
|
|
main** — c'est un artefact. On édite le plan (ou la GUI), puis « Appliquer le plan ».
|
|
|
|
|
|
|
|
|
|
|
|
La **preuve P20** interdit d'écrire de l'adressage dans la nomenclature : si quelqu'un y remet un
|
|
|
|
|
|
`supernet` ou un `vlan`, `make prouver` échoue. La règle est *tenue par une machine*, pas par la
|
|
|
|
|
|
discipline.
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## ③ Pourquoi c'est transférable
|
|
|
|
|
|
|
|
|
|
|
|
| Set-OPS | Équivalents ailleurs |
|
|
|
|
|
|
|---|---|
|
|
|
|
|
|
| adressage dérivé du seed | `cidrsubnet()` de Terraform, IPAM de **NetBox** (dérive les plages) |
|
|
|
|
|
|
| plan → inventaire généré | tout générateur d'inventaire (`nb_inventory`, CMDB → config) |
|
|
|
|
|
|
| source unique de vérité | principe universel : une valeur, un seul endroit |
|
|
|
|
|
|
| DRY | fondamental du génie logiciel |
|
|
|
|
|
|
|
|
|
|
|
|
Tu as appris **la dérivation, DRY, la source unique de vérité, le déclaratif** — pas « la
|
|
|
|
|
|
nomenclature de Set-OPS ».
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## ④ À toi de jouer
|
|
|
|
|
|
|
|
|
|
|
|
1. **Observe la dérivation.** Vue **Serveurs** de la GUI : chaque carte montre VMID · IP · VLAN.
|
|
|
|
|
|
Aucun n'a été saisi — tous viennent du `index`. Note l'IP d'un hôte.
|
|
|
|
|
|
2. **Change le seed, regarde tout suivre.** Panneau **Intrants → Réseau**, change `index` (ex.
|
|
|
|
|
|
de 1 à 7), « Appliquer le plan ». **Toutes** les IP basculent de `10.11.x` à `10.17.x`, les
|
|
|
|
|
|
VLAN de `101x` à `107x` — d'un seul chiffre. Puis remets ta valeur.
|
|
|
|
|
|
3. **Sens la source unique.** `make instancier` (diff), puis `make instancier-appliquer` :
|
|
|
|
|
|
*« DIFF VIDE : le plan reproduit exactement l'inventaire »* — le plan **est** la vérité.
|
|
|
|
|
|
4. **Casse & répare.** Édite `hosts.yml` à la main (change une IP). Relance `make instancier` :
|
|
|
|
|
|
il **signale l'écart**. Ré-applique : le plan **écrase** ta modification. Tu *sens* que
|
|
|
|
|
|
`hosts.yml` n'est pas la vérité — le plan l'est.
|
|
|
|
|
|
5. **Éprouve le garde-fou.** Ajoute une ligne `supernet: 10.99.0.0/16` dans une nomenclature,
|
|
|
|
|
|
puis `make prouver` : **P20 échoue** (« adressage stocké »). Retire-la : vert. La règle se
|
|
|
|
|
|
*prouve*.
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## Pour aller plus loin *(dépôt)*
|
|
|
|
|
|
- Le plan et sa génération : `docs/plan-et-generation.md`.
|
|
|
|
|
|
- La dérivation, en code : `scripts/inventory_rules.py` (`supernet_de`, `vlan_de`…).
|
|
|
|
|
|
- Le seed multi-instance : unité **[Multi-instance & fédération](Multi-instance-et-fédération)**.
|
|
|
|
|
|
- La règle prouvée : unité **[La preuve](La-preuve)** (P20).
|