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

Chaque site porte un numéro, et tout son adressage en dérive : 10.<site>.x.0/24. Le premier hébergeur est le site 0, le deuxième le site 1, et ainsi de suite.

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

Les VLAN ne changent pas d'un site à l'autre : ils sont locaux, ils ne traversent jamais un lien inter-sites. Un seul modèle mental vaut mieux qu'une seconde table à retenir. Seules les plages L3 diffèrent.

Pourquoi ce numéro de site, alors qu'un seul hébergeur n'en a pas besoin. Le jour où deux sites doivent se joindre — reprise après sinistre mutuelle, sauvegardes croisées, exploitation à distance — deux sites qui portent 10.0.0.0/24 ne peuvent pas être reliés : chaque routeur croit que le réseau est chez lui. Décider ce chiffre coûte une minute avant de câbler ; renuméroter un site vivant, c'est refaire les baies, les hyperviseurs et la frontière. C'est la décision la moins chère et la plus irréversible de tout ce document.

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.<site>.0.1/24 ; le transit en 10.<site>.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
Numéro de site	0, 1… — voir §2, à décider 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.