Daniel Allaire
ac85278366
La refonte de ce matin posait une convention. Une convention qu'on n'outille pas tient tant que quelqu'un y pense : c'est le raisonnement de D-70, applique au corpus documentaire. Etat de depart mesure : 2 documents sur 34 declaraient leur lecteur. Les 32 autres disaient leur SUJET — ce qui avait enfoui le runbook de reprise le plus utile du depot au §6 de autorisation.md. Les 38 le declarent desormais, lecteur determine document par document et non colle au gabarit : l'exploitant (devis, migration de tenant, cycle de vie, gabarit d'or), le mainteneur (conceptions, registres, carte), le lecteur externe (ecosysteme-chezlepro), l'agent IA (MISE-A-JOUR-CODEX-CLAUDE). Deux exemptions DERIVEES, pas listees — un chemin en dur aurait vieilli a la premiere page ajoutee : un document qui s'annonce genere, et un fragment sans titre. Les 13 exemptes verifies un par un ; aucun document ecrit a la main n'est exempte par accident. La preuve ne lit que l'EN-TETE, ce qui empeche frontiere-opnsense.md et plan-et-generation.md — qui parlent de generation dans leur corps — d'etre exemptes a tort. Eprouvee dans les deux sens. Elle a echoue seule des sa premiere execution en nommant deux documents que mon inventaire avait manques (docs/audit/). Puis test negatif delibere : declaration retiree de meta-classe.md -> ECHEC la nommant ; restauree -> OK. Ce qu'elle ne teste pas : que le lecteur declare soit le BON. Ca se juge en revue ; elle garantit qu'on a du y penser. P01–P34. Comptes perimes corriges au passage (AGENTS.md et devis-services.md annoncaient encore 30 preuves). Verifie : prouver.py 0 (34 OK), plan-recette inchange. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
172 lines
8.3 KiB
Markdown
172 lines
8.3 KiB
Markdown
# Les services d'exploitation de l'hébergeur
|
||
|
||
> **Pour qui :** le **mainteneur** — quels services l'hébergeur se doit à lui-même, et de quoi chacun doit survivre.
|
||
|
||
> **Décision du 2026-08-04.** Tout ce qu'un hébergeur fait tourner n'appartient pas à un
|
||
> tenant. Ce document dit où va quoi, et pourquoi certains services ne peuvent pas vivre
|
||
> dans l'overlay qu'ils observent. **Rien n'est construit** : la décision est consignée,
|
||
> le chantier reste devant.
|
||
|
||
## 1. Le test qui tranche
|
||
|
||
Pour chaque service, une seule question : **de quoi doit-il survivre ?**
|
||
|
||
Un service qui observe ou répare la fabric ne peut pas dépendre de la fabric. Mettez
|
||
Prometheus dans une zone EVPN pour surveiller les hyperviseurs, et le jour où le VXLAN
|
||
tombe vous perdez la supervision **et** la raison de la panne en même temps. Pire pour les
|
||
sauvegardes : on veut restaurer la configuration d'un commutateur précisément quand le
|
||
réseau est cassé.
|
||
|
||
C'est le motif *in-band / out-of-band*, et il ne se contourne pas.
|
||
|
||
## 2. Trois catégories, pas deux
|
||
|
||
**Le tenant de l'hébergeur** — son courriel, sa forge, son nuage, son site. L'hébergeur
|
||
*comme entreprise*. Aucune différence avec un client : même plan, même machinerie, mêmes
|
||
preuves, même EVPN. Chezlepro est ici hébergeur **et** tenant, ce qui a longtemps masqué
|
||
la distinction (D-13).
|
||
|
||
**Les opérations de l'hébergeur** — ce qui fait tenir la fabric. Doit rester **hors
|
||
overlay**.
|
||
|
||
**Le plan de contrôle** — Set-OPS lui-même, les dépôts, la voûte. Déjà dehors, sur le
|
||
poste de l'opérateur et sa forge. Rien à changer.
|
||
|
||
## 3. Ce qui n'a pas de maison aujourd'hui
|
||
|
||
Constaté le 2026-08-04 : **aucun équipement de l'hébergeur n'est dans un inventaire
|
||
Ansible**, et rien ne sauvegarde leurs configurations.
|
||
|
||
| Besoin | État |
|
||
|---|---|
|
||
| Supervision des hyperviseurs, commutateurs, frontière | personne |
|
||
| Journaux de ces équipements | personne |
|
||
| Sauvegarde de leurs configs (`running-config`, `config.xml`, `/etc/pve`) | personne |
|
||
| Résolution des noms d'underlay (`asgard`, `bifrost-3`, `bifrost-1`) | personne |
|
||
| Certificats pour leurs interfaces web | personne |
|
||
|
||
Ce n'est pas un oubli de conception : ces besoins tombaient entre les chaises. Ils ne sont
|
||
d'aucun tenant, et `underlay.yml` ne décrit que du matériel, sans service.
|
||
|
||
## 4. Où ça va
|
||
|
||
**Dans le dépôt de l'hébergeur** — celui qui porte déjà `underlay.yml` et
|
||
`proxmox-hebergeur.yml`. Ses services d'exploitation lui appartiennent au même titre que
|
||
sa fabric ; les loger ailleurs recréerait la confusion qu'on vient de défaire.
|
||
|
||
Ce dépôt n'a pas d'inventaire Ansible aujourd'hui : c'est ce que le chantier ajoutera.
|
||
|
||
**Rattachement réseau : un pont VLAN ordinaire, jamais un VNet du SDN.** C'est la
|
||
contrainte qui découle du §1, et la seule qui distingue ces VM de celles d'un tenant.
|
||
|
||
## 5. Ce que ça ne change pas
|
||
|
||
Les **commutateurs** et la **frontière** restent hors flotte : le premier n'a pas d'agent,
|
||
la seconde se pilote par API. Ils reçoivent des devis, pas des rôles (D-23).
|
||
|
||
Les **hyperviseurs** sont un cas différent, et la doctrine « hors flotte » les englobait à
|
||
tort : ce sont des machines Debian, joignables en SSH. Rien n'empêche de les gérer par
|
||
Ansible depuis l'inventaire de l'hébergeur — c'est même la seule façon d'y poser un
|
||
`node_exporter` et un expéditeur de journaux.
|
||
|
||
## 6. Question ouverte, non tranchée
|
||
|
||
**L'index du tenant propre de l'hébergeur.** L'idée d'un `0` réservé — local par
|
||
construction, donc jamais à coordonner entre hébergeurs, et jamais porté par un tenant qui
|
||
déménage — est séduisante et reste **en attente**.
|
||
|
||
Deux obstacles mesurés le 2026-08-04, à lever avant :
|
||
|
||
- l'index 0 produit les VNI `1001`–`1006`, et le parc hérité utilise déjà `1001`
|
||
(TechnoLibre historique, 8 VM) et `1003` (KBR). C'est une condition de **séquence** :
|
||
la place se libère quand l'ancien monde s'éteint ;
|
||
- **P21** vérifie l'unicité des index entre dépôts frères. Si tout hébergeur a un tenant
|
||
`0`, poser deux dépôts d'hébergeurs côte à côte déclencherait une fausse collision — il
|
||
faudrait exempter `0`, donc inscrire dans la garde que cette valeur est locale.
|
||
|
||
À noter au passage : la convention héritée était déjà `1000 + numéro de tenant`. La formule
|
||
de Set-OPS (`1000 + index×10 + zone`) en est un raffinement, pas une invention.
|
||
|
||
## 7. La vocation du dépôt réseau : une interface normalisée
|
||
|
||
Ce dépôt n'est pas seulement un rangement. Il porte le **contrat entre l'Alliance Boréale
|
||
et ses hébergeurs** : si chacun présente la même interface, un tenant se déplace de l'un à
|
||
l'autre sans rien changer chez lui.
|
||
|
||
Il sert aussi de **couche d'abstraction du matériel**. Le tenant est encapsulé dans sa zone
|
||
SDN EVPN, et le VRF devient la frontière de ce qu'il a le droit de connaître.
|
||
|
||
| Ce que l'hébergeur fournit | Ce que le tenant en voit |
|
||
|---|---|
|
||
| une zone EVPN par tenant | son VRF, dérivé de son `index` |
|
||
| six VNets et leurs sous-réseaux | ses passerelles `.1`, dérivées |
|
||
| un pool | son regroupement |
|
||
| un chemin de sortie vers la frontière | « l'extérieur » |
|
||
| des classes de nœud et de stockage | un besoin, pas un nom d'équipement |
|
||
|
||
**Le tenant ne nomme aucun de ces objets.** C'est la mesure de sa portabilité.
|
||
|
||
### Où en est-on, mesuré
|
||
|
||
Aucun tenant ne nomme un commutateur, un VLAN, une adresse d'underlay ni une zone EVPN :
|
||
tout dérive de son `index`. Au 2026-08-04, les **seules** mentions d'équipement de
|
||
l'hébergeur, dans les deux dépôts de tenants :
|
||
|
||
```
|
||
proxmox_clone_noeud: asgard
|
||
proxmox_clone_stockage: TrueNAS
|
||
proxmox_clone_pont: vmbr1 / vmbr3 ← corrigé, voir ci-dessous
|
||
```
|
||
|
||
Trois valeurs, dans un seul fichier. L'architecture tenait déjà la promesse avant qu'on
|
||
l'ait formulée.
|
||
|
||
### La troisième n'était pas seulement non portable : elle était fausse
|
||
|
||
`proxmox_clone_pont` faisait brancher la VM sur `vmbr1` **avec une étiquette VLAN** —
|
||
l'ancien monde. En SDN, une VM appartient à son **VNet**. C'est ce qu'il a fallu corriger à
|
||
la main sur `infra-pki-01`, et les treize suivantes auraient suivi.
|
||
|
||
Le VNet est **dérivable** : `index` + zone de sécurité → `t17serv`, comme le VMID et
|
||
l'adresse le sont déjà. `deriver_nomenclature()` expose désormais la zone, `instancier`
|
||
émet `proxmox_pont` et une **étiquette vide** (le VNet porte déjà le tag), et la chaîne va
|
||
jusqu'à `make creer-vm`.
|
||
|
||
C'est le meilleur argument pour cette vocation : **ce qui n'est pas dérivé finit par
|
||
diverger du réel.**
|
||
|
||
### Ce qui reste à abstraire
|
||
|
||
`noeud` et `stockage` désignent de vraies offres de l'hébergeur. Un tenant ne peut pas les
|
||
emporter — mais il ne devrait pas non plus les nommer. L'interface normalisée les rendrait
|
||
**abstraits** : le tenant déclare un besoin, l'hébergeur publie la correspondance.
|
||
`proxmox_noeuds` et `proxmox_stockages` sont déjà chez lui ; il manque la classe, pas le
|
||
catalogue.
|
||
|
||
## 8. Un dépôt à part pour le réseau (décidé, non fait)
|
||
|
||
`underlay.yml` et `proxmox-hebergeur.yml` vivent aujourd'hui dans `OPS-Chezlepro`, qui est
|
||
aussi le dépôt du **tenant** Chezlepro. C'est ce qui a permis de démarrer, et c'est ce qui
|
||
oblige, à chaque commit, à trancher si l'on touche à l'infrastructure ou à l'organisation.
|
||
|
||
Ils décrivent des objets différents : l'un une **infrastructure** — des câbles, des VLAN,
|
||
un cluster —, l'autre une **organisation** — ses serveurs, ses applications, ses comptes.
|
||
Un tenant peut déménager ; une fabric ne déménage pas.
|
||
|
||
Le dépôt réseau de l'hébergeur porterait donc `underlay.yml`, `proxmox-hebergeur.yml`, et
|
||
plus tard l'inventaire des services d'exploitation (§4). Le symlink qui désigne
|
||
l'hébergeur pointerait vers lui plutôt que vers son tenant — ce qui rendrait enfin la
|
||
distinction visible dans les chemins eux-mêmes.
|
||
|
||
**Rien n'est fait.** La bascule demande de déplacer deux fichiers, de refaire le symlink,
|
||
et de vérifier que les trois générateurs qui les lisent suivent.
|
||
|
||
## 9. Le VLAN de gestion, et ce qu'il n'est pas
|
||
|
||
`10.0.0.0/24` est réservé à l'**IPAM, la gestion des équipements et l'OOB/IPMI**. Accès
|
||
sysadmin uniquement.
|
||
|
||
Aucun hyperviseur n'y a d'adresse, aucune VM n'y est branchée, aucun trafic tenant ne le
|
||
traverse — ni encapsulé, ni décapsulé. C'est précisément la raison d'être des VLAN 11
|
||
(transport VXLAN) et 40 (sortie tenant) : les avoir sortis de ce domaine de diffusion.
|
||
|