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.<index>.0.0/24` | 1500 | frontière `.1`, commutateurs, OOB/IPMI, admin hyperviseur |
| Sortie des tenants | 40 | `10.<index>.4.0/24` | 1500 | frontière `.1`, nœuds de sortie |
| Transport VXLAN | 11 | `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.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.<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.<index>.0.1/24` ; le
transit en `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`](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`.