2026-07-05 01:11:52 -04:00
|
|
|
# Modèle : socle
|
2026-06-24 20:17:46 -04:00
|
|
|
|
2026-07-05 01:11:52 -04:00
|
|
|
Infrastructure de base souveraine — **4 VM** : edge (nginx), DNS (PowerDNS),
|
|
|
|
|
PKI (step-ca), magasin courriel (Dovecot). Le point de départ minimal, extensible
|
|
|
|
|
vers un écosystème complet (voir modèle `integral`).
|
2026-06-24 20:17:46 -04:00
|
|
|
|
2026-07-05 01:11:52 -04:00
|
|
|
Zones : Frontière (VLAN 16) · Services-infra (VLAN 19). VMID `ip-miroir` 9 chiffres.
|
|
|
|
|
Copier vers `OPS-<tenant>`, adapter `index`/domaine/intrants, puis `make instancier`.
|
modèles : l'underlay devient modélisable, et P17 le valide
Un modèle décrivait un tenant — ses services, ses zones, ses bases. Tous les
hébergeurs n'ont pas le même matériel : l'infrastructure physique mérite le
même traitement.
Le modèle public gagne un underlay volontairement minimal (un commutateur,
pas de fabric de stockage séparée), point de départ honnête d'un petit
hébergeur. Les montages plus riches sont d'autres modèles, conformément à la
doctrine : un générique public, les étoffés en privé.
Le modèle contient désormais deux moitiés qui ne vont pas au même endroit :
`plan/` et `inventories/` chez le tenant, `underlay.yml` chez l'hébergeur.
`modeles.py verifier` le valide (P17), facultativement et sur sa cohérence
INTERNE seulement — pas contre les tenants fédérés réels, un modèle étant un
gabarit et non un site déployé. Il a fallu rendre paramétrables deux
hypothèses du validateur, qui lisait la nomenclature de l'instance active et
globait les dépôts frères ; comportement par défaut inchangé.
Cinq cas de rejet exercés : VLAN empiétant sur la plage tenant, passerelle au
mauvais dernier octet (lue dans la nomenclature du modèle), routeur inconnu,
sortie hors du lien, port déclaré deux fois.
Preuves : 24 OK, 0 échec.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 17:11:18 -04:00
|
|
|
|
|
|
|
|
## Deux moitiés, deux propriétaires
|
|
|
|
|
|
|
|
|
|
Ce modèle en contient **deux**, qui ne vont pas au même endroit :
|
|
|
|
|
|
|
|
|
|
| Fichiers | Décrit | Copier vers |
|
|
|
|
|
|---|---|---|
|
|
|
|
|
| `plan/`, `inventories/` | les **services** d'une organisation | `OPS-<tenant>` |
|
|
|
|
|
| `underlay.yml` | le **matériel** qui les porte | `OPS-<hébergeur>` |
|
|
|
|
|
|
|
|
|
|
Un tenant qui se fait héberger prend la première moitié seulement : l'underlay appartient à
|
|
|
|
|
qui possède les commutateurs. Chez un hébergeur qui est aussi son propre tenant, les deux
|
|
|
|
|
atterrissent dans le même dépôt — c'est un cas particulier, pas la règle.
|
|
|
|
|
|
|
|
|
|
L'underlay fourni est **volontairement minimal** : un seul commutateur, pas de fabric de
|
|
|
|
|
stockage séparée. Tous les hébergeurs n'ont pas le même matériel ; les montages plus riches
|
|
|
|
|
(étoile à trois commutateurs, paire en MLAG, stockage jumbo dédié) relèvent d'autres modèles.
|
|
|
|
|
|
|
|
|
|
Il est **facultatif** : un modèle sans `underlay.yml` reste valide. Présent, il est vérifié
|
|
|
|
|
pour sa cohérence interne par la preuve **P17**, sans être confronté aux tenants réels — un
|
|
|
|
|
modèle est un gabarit, pas un site déployé.
|
