Set-OPS-Public/docs/preparer-un-site-hebergeur.md

Préparer un site hébergeur

Pour qui : l'hébergeur qui met son matériel à disposition — il n'a pas besoin de connaître Set-OPS. L'exploitant du tenant lui transmet ce document, puis relit §7 pour savoir ce qu'il doit recevoir en retour.

Set-OPS déploie un écosystème complet (annuaire, SSO, courriel, forge, nuage collaboratif, supervision, sauvegardes) à partir d'un plan. Tout cet adressage se dérive d'un seul chiffre — l'index du tenant.

Ce que la machine ne peut pas deviner, c'est le matériel : le câblage, le nom des stockages, le chemin de sortie vers Internet. C'est l'objet de ce document, et c'est tout ce qui est demandé à l'hébergeur.

1. Le partage des rôles

	Décide quoi	Où ça vit
Hébergeur	réseau physique, pare-feu de bordure, stockage, hyperviseur	underlay.yml et proxmox-hebergeur.yml, dans son dépôt
Tenant	quels services, sur quel nœud/stockage/pont les poser	inventories/*/group_vars/, dans le dépôt du tenant

Cette séparation n'est pas cosmétique. Tant que ces valeurs étaient recopiées chez chaque tenant, elles ont divergé : deux inventaires contradictoires du même cluster, avec des listes de stockages et de ponts différentes. Un hébergeur décrit son matériel une fois.

2. Le plan d'adressage — la seule chose à respecter à la lettre

Un site dérive du même index que son tenant. Il n'y a pas de second registre à tenir : le seul seed de tout l'adressage reste l'index, et l'underlay occupe la bande basse du supernet — celle que la dérivation des tenants n'alloue jamais.

Rôle	VLAN	Sous-réseau	MTU	Qui y vit
Gestion	10	10.(10+index).0.0/24	1500	frontière .1, commutateurs, OOB/IPMI, admin hyperviseur
Sortie des tenants	40	10.(10+index).4.0/24	1500	frontière .1, nœuds de sortie
Transport VXLAN	11	10.(10+index).5.0/24	1500	hyperviseurs seulement
Stockage iSCSI	20	192.168.20.0/24	9000	baie ↔ hyperviseurs
Ceph public	30	192.168.30.0/24	9000	clients ↔ MON/OSD
Ceph cluster	31	192.168.31.0/24	9000	OSD ↔ OSD

Index 17 → gestion en 10.27.0.0/24 ; index 11 → 10.21.0.0/24. Deux sites ne peuvent donc pas se chevaucher, sans qu'on ait rien de plus à décider.

Les VLAN ne changent jamais d'un site à l'autre : ils sont locaux, ils ne traversent aucun lien inter-sites. Un seul modèle mental, et l'adresse de stockage porte son propre numéro de VLAN — 192.168.20.x est sur le VLAN 20.

Pourquoi la bande basse est sûre, et non pas seulement libre aujourd'hui. Les zones d'un tenant sont dérivées en 10.(10+index).(15+categorie).0/24 : leur troisième octet vaut donc 16 au minimum, et croît avec le nombre de zones. Les octets 0 à 15 ne sont jamais alloués — c'est une propriété de la règle, pas une place restée vide. L'underlay y tient largement.

Pourquoi le stockage sort de cet espace. Ces réseaux sont jumbo, non routés, et ne quittent jamais leur site. Ils n'ont donc aucun besoin d'être uniques — et les rendre identiques partout épargne une coordination inutile. Contrepartie assumée : ils ne pourront jamais traverser un lien inter-sites. Sans conséquence, puisque ce qui voyage entre deux sites, c'est l'état (par le dépôt de sauvegarde), pas le stockage bloc.

Un hébergeur qui n'exploite lui-même aucun tenant prend quand même un index : c'est le seed de son site. Une seule règle, aucun cas particulier.

Le MTU n'est pas un détail

Le trafic des VM voyage encapsulé en VXLAN, ce qui coûte 50 octets. Avec un transport à 1500, les VM tournent à 1450 — automatiquement, mais à condition que 1500 passe réellement de bout en bout sur les VLAN 11 et 40. Un MTU rogné en chemin donne le pire des symptômes : les petites requêtes passent, les grosses meurent, et rien n'est signalé.

Le jumbo (9000) sur le stockage est facultatif. À moitié configuré, il ne fonctionne pas du tout — mieux vaut rester à 1500 que le poser sur un seul des trois maillons.

3. La frontière (pare-feu de bordure)

C'est le seul équipement qui route, et l'unique point de passage entre l'extérieur et l'intérieur. Set-OPS pilote ses règles par API : le boîtier reste à l'hébergeur, rien n'y est installé.

Interfaces : le WAN (noter l'IP publique) ; la gestion en 10.(10+index).0.1/24 ; le transit en 10.(10+index).4.1/24, par où sortent les machines du tenant.

Un point de routage porte le même dernier octet partout : .1, quel que soit l'équipement qui l'assure. Invariant porté par la preuve P23.

Un compte pour l'exploitant : un utilisateur ansible avec sa clé publique. Aucun sudo n'est nécessaire — l'outil lit et appelle l'API. Un compte qui ne peut pas devenir root ne peut pas casser le pare-feu par accident.

Une clé d'API : sur OPNsense, System → Access → Users → ansible → API keys → « + ». Le secret n'est affiché qu'une seule fois.

4. Le stockage

Rien de spécifique à Set-OPS : il faut que l'hyperviseur puisse y poser des disques de VM (NFS ou iSCSI). Seuls comptent les stockages qui acceptent le contenu images.

Dimensionnement, mesuré sur un écosystème complet de quatorze machines :

	Mesuré	À prévoir
Disques provisionnés	~460 Go	600 Go
RAM allouée	~37 Go	48 Go (32 à la rigueur, en démarrant par vagues)

5. L'hyperviseur (Proxmox VE)

À noter et transmettre : le nom exact du nœud tel qu'il apparaît dans l'interface, les noms exacts des stockages, et les ponts (vmbrN). Pas les descriptions : les noms, tels qu'ils seront lus par l'API.

Sur un cluster de plusieurs nœuds, un pont doit exister sur tous — un pont partiel est un piège : la VM ne démarre que sur certains nœuds, et l'erreur ne le dit pas.

Le SDN n'est pas à configurer par l'hébergeur. Set-OPS crée le contrôleur EVPN, la zone (un VRF par tenant) et les réseaux. Il faut seulement que le SDN soit disponible et le VLAN de transport en place.

Le compte d'API

pveum user add ansible@pve
pveum aclmod / -user ansible@pve -role Administrator
pveum user token add ansible@pve set-ops --privsep 0

Le Token ID et le secret sont à noter — le secret n'est affiché qu'une fois.

Sur Administrator, autant le dire franchement. Le minimum documenté est VM.Allocate, VM.Clone, VM.Config.*, Datastore.AllocateSpace et les droits SDN. Mais l'outil crée aussi des objets réseau et détruit des VM : partir large le premier jour évite de courir après des 403 pendant le déploiement. Le resserrer ensuite est un rôle sur mesure, dix minutes — et c'est un geste à faire, pas une intention.

6. Le gabarit — et le piège qu'il porte

Toutes les VM sont clonées depuis un même modèle Debian, nommé modeleSetOPS : c'est un artefact du moteur, pas d'un tenant. Une VM Debian minimale avec qemu-guest-agent et cloud-init, convertie en template, suffit.

Ne pas le personnaliser. Un gabarit qui porte une clé privée d'hôte SSH, un /etc/resolv.conf figé ou un compte nominatif recopie tout cela dans chaque clone. C'est arrivé, et il a fallu recapturer le gabarit puis reconstruire pour s'en défaire.

En cas de doute, laisser l'exploitant le fabriquer : c'est une demi-heure, et la procédure est écrite (docs/procedure-template-debian13-proxmox.md).

7. Ce que l'exploitant doit recevoir

Élément	Exemple
IP publique (WAN)	203.0.113.10
Nom du nœud hyperviseur	asgard
Stockages (noms exacts)	TrueNAS, local-lvm
Ponts	vmbr0, vmbr3
RAM et disque disponibles	64 Go / 2 To
Modèle du commutateur	dicte le dialecte de CLI (cisco | binardat)
Domaine public prévu	exemple.ca
Gabarit	fait, ou à faire
index du site	le même que son tenant — voir §2, à fixer avant de câbler
Accès de l'exploitant	sur place, ou lien vers le VLAN de gestion (voir §8)

Et deux paires de secrets, par un canal chiffré et séparément du reste : le Token ID + secret de l'hyperviseur, la clé + secret de l'API de la frontière. Ils n'entrent jamais dans un dépôt git : leur place est la voûte chiffrée de l'instance.

Les accès réseau nécessaires

Cible	Port	Pour quoi
Hyperviseur	8006	créer et détruire les VM
Frontière	443	poser les règles par API
Frontière	22	SSH, compte ansible
Réseau du tenant	22	SSH vers les VM une fois créées

Les VM ont besoin de sortir sur Internet pour leurs paquets système. Le reste — les artefacts applicatifs — est poussé depuis le poste de l'exploitant, pas téléchargé par les machines.

8. Relier deux sites (exploitation à distance, reprise après sinistre)

Deux besoins bien distincts, qu'il ne faut pas confondre :

Les services publiés n'ont besoin de rien. Nuage, forge, courriel, SSO sortent par la frontière en TLS, derrière l'authentification unique. Aucun tunnel n'est requis pour les utiliser, et en ajouter un n'apporterait rien.

Le plan de contrôle, si. L'inventaire adresse les machines par leurs IP privées dérivées ; il n'existe aucun chemin publié vers elles, et il ne peut pas y en avoir sans casser la dérivation. Les API de l'hyperviseur et de la frontière, elles, tournent avec la vérification du certificat désactivée — les exposer publiquement reviendrait à publier les deux surfaces les plus privilégiées sans savoir à qui l'on parle.

Besoin	Forme adaptée
Déployer et exploiter à distance, ponctuellement	accès nomade (poste → site) : une clé, révocable, aucun couplage entre sites
Réplication de sauvegardes, reprise mutuelle	lien site-à-site : il doit tenir sans qu'aucun poste soit allumé

Dans les deux cas, la politique doit être explicite : un lien qui joint simplement deux réseaux défait en silence l'isolation inter-tenant. WireGuard s'y prête bien — ses allowed-ips sont la politique : ce qui n'y figure pas ne traverse pas.

Ce que la reprise mutuelle exige en plus : des plages de gestion distinctes (§2), de la capacité chez le survivant pour faire tourner les deux écosystèmes, un gabarit présent des deux côtés, et la voûte de chaque instance conservée hors de son propre site. Les sauvegardes, elles, sont chiffrées côté client : le site d'accueil héberge du chiffré qu'il ne peut pas lire. La confiance demandée porte sur la disponibilité, pas sur la confidentialité.

9. Ce qu'il ne faut pas faire

• Ne pas créer de VM à la main pour le tenant. Elles sont toutes dérivées du plan ; une VM créée à côté est invisible pour l'outil, qui la détruira sans le savoir.
• Ne pas configurer le SDN : l'outil le fait entièrement.
• Ne pas écrire les secrets dans un fichier partagé ni dans un dépôt git.
• Ne pas contourner un blocage en silence. Un point resté ouvert et signalé se règle en dix minutes ; un contournement non dit se paie en heures, parce que la panne sera cherchée au mauvais endroit.

Voir aussi

• sdn-evpn.md — pourquoi une zone EVPN par tenant.
• config-proxmox.md — les intrants côté hyperviseur, et le token.
• frontiere-opnsense.md — la frontière, hors flotte Ansible.
• procedure-template-debian13-proxmox.md — fabriquer modeleSetOPS.