Set-OPS-Public/docs/hebergeur-exploitation.md

Les services d'exploitation de l'hébergeur

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, sleipnir-01, 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.