Daniel Allaire 5ace6bdb95 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

4.2 KiB

Raw Blame History

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.<index>.0.0/16`
Sous-réseau de zone	`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 de 10.11.x à 10.17.x, les VLAN de 101x à 107x — d'un seul chiffre. Puis remets ta valeur.
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é.
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.
É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.
La règle prouvée : unité La preuve (P20).

4.2 KiB Raw Blame History Unescape Escape