Daniel Allaire
ac7fe93165
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>
91 lines
4.2 KiB
Markdown
91 lines
4.2 KiB
Markdown
# 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) |
|
||
|---|---|
|
||
| Supernet | `10.(10+index).0.0/16` |
|
||
| Sous-réseau de zone | `10.(10+index).(15+zone).0/24` |
|
||
| 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).
|