92 lines
4.2 KiB
Markdown
92 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).
|