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>
4.2 KiB
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'autredata-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
- 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. - Change le seed, regarde tout suivre. Panneau Intrants → Réseau, change
index(ex. de 1 à 7), « Appliquer le plan ». Toutes les IP basculent de10.11.xà10.17.x, les VLAN de101xà107x— d'un seul chiffre. Puis remets ta valeur. - Sens la source unique.
make instancier(diff), puismake instancier-appliquer: « DIFF VIDE : le plan reproduit exactement l'inventaire » — le plan est la vérité. - Casse & répare. Édite
hosts.ymlà la main (change une IP). Relancemake instancier: il signale l'écart. Ré-applique : le plan écrase ta modification. Tu sens quehosts.ymln'est pas la vérité — le plan l'est. - Éprouve le garde-fou. Ajoute une ligne
supernet: 10.99.0.0/16dans une nomenclature, puismake 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.
- La règle prouvée : unité La preuve (P20).