Daniel Allaire
28d278111c
Decision de l exploitant : sites et locataires se partagent la classe A, chacun avec son propre index. L exception du guide — un site derive du meme index que son tenant — disparait. Ce qu elle cachait : le plan d administration du site vit dans 10.17.0.0/24, a l interieur du supernet du locataire OPS-Chezlepro. Pas dangereux, mais 10.17.0.0/16 designait deux choses. Et les zones du site ne derivaient de rien — le site etait la seule partie du systeme sans seed. La seconde liste nait avec cette decision : un site et un locataire peuvent desormais reclamer le meme nombre, et make instances ne voyait que les depots OPS-*. La decouverte lit maintenant SITE-*/underlay.yml et son champ index. Un site sans index declare reste hors du compte. SITE-Technolibre : squelette du deuxieme site pour la visite du 14. Un seul noeud Proxmox en version 9, meme forme que Chezlepro, adresse depuis l index 31. COLLECTE.md liste les 35 valeurs a relever. Reste a l exploitant : OPS-Chezlepro passe a 37, ce qui libere 17 pour le site qui l utilise deja. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
97 lines
4.4 KiB
Markdown
97 lines
4.4 KiB
Markdown
# À relever chez Technolibre — avant de lancer quoi que ce soit
|
|
|
|
> Une ligne non remplie ici est une ligne qui bloquera le déploiement plus tard, à un
|
|
> endroit où le message d'erreur ne dira pas qu'elle manquait.
|
|
> Référence : `docs/preparer-un-site-hebergeur.md` §7, adapté au cas **un seul nœud**.
|
|
|
|
## 1. Le chiffre qui décide de tout
|
|
|
|
```
|
|
SITE 7 VM 20 Go RAM 776 Go provisionnés
|
|
tenant 14 VM 37 Go RAM 460 Go provisionnés
|
|
─────────────────────────────────────────
|
|
TOTAL 21 VM 57 Go RAM ~1,2 To
|
|
```
|
|
|
|
Sur trois nœuds ça se répartit. Sur **un seul**, la même machine porte tout — et la RAM est
|
|
la contrainte dure (le disque se dégonfle en provisionnement fin, pas la mémoire).
|
|
|
|
- [ ] **RAM physique du nœud** : ______ Go → si < 64, décider de réduire AVANT de câbler
|
|
- [ ] **Espace libre du stockage `images`** : ______ Go (viser 1,2 To ; 800 Go à la rigueur)
|
|
|
|
## 2. L'hyperviseur
|
|
|
|
- [ ] **Nom exact du nœud** tel qu'il apparaît dans l'interface : ______
|
|
- [ ] **Version** : `pveversion | head -1` → ______ (attendu : `pve-manager/9.x`)
|
|
- [ ] **Noms exacts des stockages** acceptant le contenu `images` : `pvesm status`
|
|
- [ ] **Ponts** présents : `ip -br link | grep vmbr`
|
|
- [ ] **Adresse de gestion** du nœud : ______
|
|
- [ ] **SDN disponible ?** `pvesh get /cluster/sdn` répond sans erreur : oui / non
|
|
|
|
### 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
|
|
```
|
|
- [ ] **Token ID** + **secret** notés (le secret ne s'affiche **qu'une fois**)
|
|
|
|
## 3. La frontière (OPNsense)
|
|
|
|
- [ ] **IP publique (WAN)** : ______
|
|
- [ ] **Version** : ______
|
|
- [ ] **Interfaces libres** pour les zones du site : ______
|
|
- [ ] **Clé + secret d'API** créés et notés
|
|
- [ ] **Compte `ansible`** en SSH par clé, `sudo` vérifié : `sudo -n -l`
|
|
- [ ] **Une patte face au nœud Proxmox** (le lien de transit) : interface ______
|
|
|
|
## 4. Entre les deux — LA question de forme
|
|
|
|
Ce qu'il y a entre le nœud Proxmox et l'OPNsense décide du mode de routage :
|
|
|
|
- [ ] **Un commutateur capable de SVI et d'ACL** → mode `switch`, modèle : ______
|
|
- [ ] **Un commutateur simple (VLAN seulement)** → l'OPNsense route tout, mode `switch`
|
|
avec l'OPNsense comme routeur
|
|
- [ ] **Un lien direct nœud ↔ OPNsense** → trunk 802.1Q, l'OPNsense route tout
|
|
- [ ] **SDN EVPN sur le nœud** → indépendant du matériel, mais jamais éprouvé sur un
|
|
nœud unique
|
|
|
|
## 5. Cohabitation d'adressage
|
|
|
|
- [ ] `ip route` sur le poste de Mathieu — quelles plages `10.x` sont déjà prises ?
|
|
- [ ] Son réseau bureautique / son VPN utilisent-ils `10.31.x` ou `10.23.x` ? ______
|
|
- [ ] Docker présent sur ses machines d'administration ? (`172.17`+ déjà pris)
|
|
|
|
## 6. Le gabarit
|
|
|
|
- [ ] Gabarit Debian 13 `modeleSetOPS-minimal` : **fait** / **à faire**
|
|
(procédure : `docs/procedure-template-debian13-proxmox.md`, ~30 min)
|
|
- [ ] Si fait : **VMID** ______ , **nom** ______ , **stockage** ______
|
|
- [ ] Vérifier `machine: q35` et `bios: ovmf` — **ne jamais convertir** un i440fx
|
|
|
|
## 7. Les accès réseau nécessaires depuis le poste
|
|
|
|
| Cible | Port | Pour quoi | OK |
|
|
|---|---|---|---|
|
|
| Hyperviseur | 8006 | créer et détruire les VM | [ ] |
|
|
| Hyperviseur | 22 | `pvesh`, `qm`, SDN | [ ] |
|
|
| Frontière | 443 | poser les règles par API | [ ] |
|
|
| Frontière | 22 | SSH, compte `ansible` | [ ] |
|
|
| Zones du site | 22 | SSH vers les VM une fois créées | [ ] |
|
|
|
|
## 8. Les deux paires de secrets
|
|
|
|
Par un canal chiffré, **séparément du reste**, et jamais dans git :
|
|
|
|
- [ ] Token ID + secret de l'hyperviseur → voûte de l'instance
|
|
- [ ] Clé + secret de l'API de la frontière → voûte de l'instance
|
|
|
|
## 9. Ce qui n'a jamais été éprouvé, et qu'il faut regarder de près
|
|
|
|
- [ ] **Proxmox 9** — le moteur n'analyse aucune version et n'appelle que des chemins
|
|
d'API stables, mais rien n'a jamais tourné contre un PVE 9. Surveiller le pare-feu
|
|
(`proxmox-firewall` nftables en 9) et le SDN (passé GA).
|
|
- [ ] **Nœud unique** — pas de Ceph, pas de migration, le gabarit et les clones sont sur
|
|
la même machine. Le SPOF est total et assumé.
|
|
- [ ] **Index 31** — celui du SITE. Vérifier qu'aucune plage `10.31.x` n'existe déjà chez
|
|
Mathieu (`ip route | grep 10.31`). `make instances` garde la fédération.
|