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. 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.

## 8. 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.