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

Rôle	VLAN	Sous-réseau	MTU	Qui y vit
Gestion	10	10.0.0.0/24	1500	frontière .1, commutateurs, OOB/IPMI, admin hyperviseur
Transport VXLAN	11	10.0.5.0/24	1500	hyperviseurs seulement
Stockage iSCSI	20	10.0.1.0/24	9000	baie ↔ hyperviseurs
Sortie des tenants	40	10.0.4.0/24	1500	frontière .1, nœuds de sortie

Deux invariants portés par la preuve P23 :

• Un point de routage porte le même dernier octet partout : .1. La passerelle d'un sous-réseau garde cette adresse, quel que soit l'équipement qui l'assure.
• Chaque tenant occupe 10.(10+index).0.0/16. Index 11 → 10.21.0.0/16, index 17 → 10.27.0.0/16. Aucun réseau de l'hébergeur ne doit chevaucher ces blocs : le symptôme d'une collision est un service qui « ne répond pas » sans aucune erreur nulle part.

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.0.0.1/24 ; le transit en 10.0.4.1/24, par où sortent les machines du tenant.

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
Accès	sur place, ou VPN débouchant sur le VLAN 10

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