# 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..0.0/24` | 1500 | frontière `.1`, commutateurs, OOB/IPMI, admin hyperviseur | | Sortie des tenants | 40 | `10..4.0/24` | 1500 | frontière `.1`, nœuds de sortie | | Transport VXLAN | 11 | `10..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.17.0.0/24` ; index 11 → `10.11.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..(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..0.1/24` ; le transit en `10..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`](sdn-evpn.md) — pourquoi une zone EVPN par tenant. - [`config-proxmox.md`](config-proxmox.md) — les intrants côté hyperviseur, et le token. - [`frontiere-opnsense.md`](frontiere-opnsense.md) — la frontière, hors flotte Ansible. - [`procedure-template-debian13-proxmox.md`](procedure-template-debian13-proxmox.md) — fabriquer `modeleSetOPS`.