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`](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`.