0 Le plan et l adressage dérivé
Daniel Allaire edited this page 2026-07-23 15:13:18 -04:00
This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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.
  • La règle prouvée : unité La preuve (P20).