Daniel Allaire
5bc3bceac1
Some checks failed
verifier / verifier (push) Has been cancelled
La revision a commence par un balayage par motifs — chemins morts, cibles make absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque tout le reste : un motif ne voit que ce qui s exprime en motif. make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus haut. Il fallait lire pour la voir. 74 documents lus un par un. 66 corriges, 8 exacts. CE QUI ETAIT FRANCHEMENT FAUX AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre des VM reelles. Elle a ete rasee et remontee depuis zero trois fois. ecosysteme-chezlepro.md, le document montre a un client, portait la meme phrase : il se sous-vendait gravement. courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n est construit alors qu il rapporte des mesures datees du role en fonctionnement. hebergeur-exploitation.md disait rien n est fait d un depot qui existe. filiation-emancipation.md se contredisait a deux ecrans de distance. DES MODELES DECRITS D APRES UN MONDE ANTERIEUR Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le donnaient en exemple d integration FACULTATIVE — il est universel depuis le 2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki qui avait raison. CE QUI CASSE AU PREMIER ESSAI Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le FABRIQUE et le critere R2 de l epreuve d operateur independant. preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait detruite : raser derive du plan, il ne la detruira jamais — le risque est l inverse. Un mot de passe d essai en clair dans un depot public. DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux declarations reelles : 12 annonces, 21 reels. Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une erreur ajoute l assurance a l erreur. CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il nomme existe. P29 tient les positions d authentification, personne ne tient les habilitations. make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
200 lines
10 KiB
Markdown
200 lines
10 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, **révisé le 2026-09-05**. La moitié du constat a été levée
|
||
entre-temps ; l'autre tient toujours, et il faut distinguer les deux.
|
||
|
||
**Ce qui a une maison désormais** : les **VM du site** ont leur inventaire Ansible
|
||
(`scripts/site_inventaire.py` — 7 machines, 23 groupes, dérivé d'`underlay.yml` sans
|
||
fichier intermédiaire), leur socle, leur durcissement, leurs sauvegardes et leur
|
||
supervision (`site-mon-01`, depuis le 2026-09-02).
|
||
|
||
**Ce qui n'en a toujours pas** : les **équipements** eux-mêmes — hyperviseurs,
|
||
commutateurs, frontière. C'est là que le constat d'origine reste entier.
|
||
|
||
| Besoin | État |
|
||
|---|---|
|
||
| Supervision des hyperviseurs, commutateurs, frontière | personne — `site-mon-01` ne voit que les VM du site |
|
||
| Journaux de ces équipements | personne |
|
||
| Sauvegarde de leurs configs (`running-config`, `config.xml`, `/etc/pve`) | personne — **vérifié le 2026-09-05, aucun rôle ne les touche** |
|
||
| Résolution des noms d'underlay (`asgard`, `bifrost-3`, `bifrost-1`) | personne — **vérifié : `site-dns-01` ne les résout pas** |
|
||
| 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 **a désormais son inventaire Ansible** — `scripts/site_inventaire.py`, dynamique
|
||
plutôt que généré, parce qu'un site ne dérive de rien : sa déclaration *est* déjà sa forme
|
||
finale. Ce qui reste à faire, c'est d'y loger les **équipements**, qui n'y sont pas.
|
||
|
||
**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 l'hébergeur — FAIT
|
||
|
||
> **Cette section disait « Rien n'est fait » jusqu'au 2026-09-06.** Le dépôt existe :
|
||
> **`SITE-Chezlepro`**, frère de `OPS-Chezlepro`, et le symlink `underlay.yml` du moteur y
|
||
> pointe (`../SITE-Chezlepro/underlay.yml`).
|
||
|
||
Le raisonnement qui l'a motivé, et qui vaut pour tout hébergeur : `underlay.yml` et
|
||
`proxmox-hebergeur.yml` décrivent une **infrastructure** — des câbles, des VLAN, un
|
||
cluster ; le plan d'un tenant décrit une **organisation** — ses serveurs, ses applications,
|
||
ses comptes. Un tenant peut déménager ; une fabric ne déménage pas. Les garder dans le même
|
||
dépôt obligeait, à chaque commit, à trancher lequel des deux on touchait.
|
||
|
||
Ce que le dépôt de l'hébergeur porte aujourd'hui :
|
||
|
||
| Fichier | Ce qu'il décrit |
|
||
|---|---|
|
||
| `underlay.yml` | la fabric physique — réseaux, VLAN, MTU, commutateurs, hyperviseurs |
|
||
| `proxmox-hebergeur.yml` | l'API du cluster, ses nœuds, ses stockages, ses ponts |
|
||
| `opnsense.yml` | la frontière nord/sud (paramètres non sensibles) |
|
||
| `underlay.vault.yml` | ses secrets à lui — **voûte séparée**, clé séparée (2026-08-28) |
|
||
| `plan/` | ses **propres VM** : sept machines de service (pilotage, autorité, génome, cache, sauvegarde, supervision, DNS) |
|
||
|
||
C'est cette dernière ligne qui a le plus changé : l'hébergeur n'est plus seulement un
|
||
porteur de fabric, **c'est un exploitant** — avec son inventaire (`scripts/site_inventaire.py`),
|
||
son socle, son durcissement, ses sauvegardes et sa supervision.
|
||
|
||
## 9. Le plan d'administration, et ce qu'il n'est pas
|
||
|
||
> **Les adresses de cette section ont toutes changé** avec la bascule D-77/D-78, terminée le
|
||
> 2026-08-22. Elle désignait `10.0.0.0/24` et les « VLAN 11 (transport VXLAN) et 40 (sortie
|
||
> tenant) » ; `10.0.0.0/24` n'existe plus, et le transport est passé au VLAN 50.
|
||
|
||
Le plan d'**administration** — `10.17.0.0/24`, dans la bande basse du supernet du tenant
|
||
Chezlepro (D-77) — est réservé aux **équipements** et à l'exploitant. Il n'a **aucun VLAN** :
|
||
c'est un segment physique, et **aucun pont d'hyperviseur ne le touche**, donc aucune VM ne
|
||
peut y naître. Le validateur refuse d'ailleurs qu'on y déclare une machine.
|
||
|
||
Distinct de lui, le **contrôle de la grappe** (`192.168.11.0/24`, `vmbr0`) porte l'interface
|
||
web de Proxmox et le dialogue entre nœuds.
|
||
|
||
Aucun trafic tenant ne traverse ni l'un ni l'autre — ni encapsulé, ni décapsulé. C'est
|
||
précisément la raison d'être du **VLAN 50** (transport VXLAN) et du **VLAN 40** (transit vers
|
||
la frontière) : les avoir sortis de ces domaines de diffusion. *(Le transport a porté le
|
||
numéro 11 jusqu'à la bascule ; `192.168.11.0/24` étant pris par le contrôle de la grappe, il
|
||
est passé au 50.)*
|