un site prend son propre index, et la garde les compte enfin

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
This commit is contained in:
Daniel Allaire 2026-09-12 14:31:52 -04:00
parent 912a84483f
commit 28d278111c
4 changed files with 44 additions and 37 deletions

View file

@ -59,7 +59,7 @@ Ce qu'il y a entre le nœud Proxmox et l'OPNsense décide du mode de routage :
## 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.0.3x` ou `10.23.x` ? ______
- [ ] 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
@ -93,6 +93,5 @@ Par un canal chiffré, **séparément du reste**, et jamais dans git :
(`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é.
- [ ] **Deuxième site** — `10.0.31–36` est déjà l'adressage du site de Chezlepro. Les
réutiliser ici ferme la possibilité de relier les deux sites (§8 du guide) tant
qu'aucun n'est renuméroté.
- [ ] **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.

View file

@ -41,13 +41,12 @@ dessous de 64 Go, il faut décider de réduire avant de câbler, pas pendant le
## L'adressage
- **Gestion** : `10.23.0.0/24` — la bande basse du supernet de son locataire, que la
dérivation des zones n'alloue jamais (elles commencent à `.16`).
- **Zones du site** : `10.0.31` à `10.0.36` — **identiques à celles de Chezlepro**.
Statu quo décidé le 2026-09-12 : un index se redéploie assez facilement pour qu'une
collision ne justifie pas de revoir la méthode.
> Conséquence connue : les deux sites ne peuvent pas être reliés (§8 du guide de
> préparation) tant qu'aucun des deux n'est renuméroté.
- **Gestion** : `10.31.0.0/24` — l'index du SITE, distinct de celui de son locataire
(23). Le plan d'administration de l'hébergeur ne vit plus chez un de ses clients.
- **Zones du site** : `10.31.31` à `10.31.36` — **même forme que Chezlepro** (le 3e octet
reste le numéro de VLAN), avec l'index du site au 2e octet.
> Décision du 2026-09-12 : sites et locataires se partagent la classe A, chacun avec son
> propre index. Les deux sites peuvent donc être reliés (§8 du guide) sans renumérotage.
- **Chemins** (transit) : `10.0.4.0/24`, comme chez Chezlepro.
## L'ordre des gestes, le jour J

View file

@ -22,7 +22,7 @@ serveurs:
site-ops-01:
etat: actif
reseau: site-pilotage
ip: 10.0.31.11
ip: 10.31.31.11
noeud: <<NOEUD>>
gabarit: { vcpu: 2, memoire: 4096, disque: 40G }
vmid: 9001
@ -67,7 +67,7 @@ serveurs:
site-cache-01:
etat: actif
reseau: site-genome
ip: 10.0.33.21
ip: 10.31.33.21
noeud: <<NOEUD>>
gabarit: { vcpu: 2, memoire: 2048, disque: 120G }
vmid: 9002
@ -77,7 +77,7 @@ serveurs:
site-forge-01:
etat: actif
reseau: site-genome
ip: 10.0.33.11
ip: 10.31.33.11
noeud: <<NOEUD>>
gabarit: { vcpu: 2, memoire: 4096, disque: 80G }
vmid: 9003
@ -113,7 +113,7 @@ serveurs:
site-pki-01:
etat: actif
reseau: site-autorite
ip: 10.0.32.11
ip: 10.31.32.11
noeud: <<NOEUD>>
gabarit: { vcpu: 2, memoire: 2048, disque: 32G }
vmid: 9004
@ -133,7 +133,7 @@ serveurs:
site-dns-01:
etat: actif
reseau: site-service
ip: 10.0.34.11
ip: 10.31.34.11
noeud: <<NOEUD>>
gabarit: { vcpu: 2, memoire: 2048, disque: 40G }
vmid: 9005
@ -175,7 +175,7 @@ serveurs:
site-backup-01:
etat: actif
reseau: site-sauvegarde
ip: 10.0.35.11
ip: 10.31.35.11
noeud: <<NOEUD>>
gabarit: { vcpu: 2, memoire: 2048, disque: 400G }
vmid: 9010
@ -192,7 +192,7 @@ serveurs:
site-mon-01:
etat: actif
reseau: site-supervision
ip: 10.0.36.11
ip: 10.31.36.11
noeud: <<NOEUD>>
gabarit: { vcpu: 2, memoire: 4096, disque: 64G }
vmid: 9011

View file

@ -12,6 +12,13 @@
underlay:
# Le locataire que ce site hébergera. Son index est déjà fédéré (23) et il ne
# change pas : c'est lui qui porte l'adressage d'OPS-Technolibre, ses VLAN et ses VMID.
# L'INDEX DU SITE LUI-MÊME. Déclaré ici, et pas seulement porté par les adresses :
# c'est ce qui le rend visible à la garde des collisions (`make instances`).
# Depuis le 2026-09-12, SITES et OPS partagent la classe A — deux écosystèmes ne
# peuvent donc plus prendre le même nombre, quel que soit leur genre.
index: 31
# Le locataire que ce site hébergera, avec SON index à lui.
tenants:
OPS-Technolibre: 23
@ -32,12 +39,14 @@ underlay:
reseaux:
# PLAN DE GESTION — la seule chose qui doit être unique entre deux sites.
# `10.<index>.0.0/24`, index 23 : la bande basse du supernet du locataire, que la
# dérivation des zones n'alloue jamais (elles commencent à .16).
# `10.<index>.0.0/24`, index 31 : celui du SITE, distinct de celui de son
# locataire (23). Décision du 2026-09-12 : SITES et OPS partagent la classe A,
# chacun avec son propre index — le plan d'administration de l'hébergeur ne vit
# plus dans le supernet d'un de ses locataires.
- nom: management
description: Gestion du nœud, OOB/IPMI, poste de l'exploitant
vlan: null
sous_reseau: 10.23.0.0/24
sous_reseau: 10.31.0.0/24
mtu: 1500
# LIEN VERS LA FRONTIÈRE. Sans lui, la flotte n'a ni sortie ni chemin de retour :
@ -50,15 +59,15 @@ underlay:
mtu: 1500
# LES SIX ZONES DU SITE. Une préoccupation par zone.
# ⚠ Identiques à celles du site de Chezlepro (statu quo décidé le 2026-09-12).
# Conséquence connue : les deux sites ne pourront pas être reliés (§8 du guide)
# tant qu'aucun des deux n'est renuméroté.
- { nom: site-pilotage, description: Runner et pilotage, vlan: 31, sous_reseau: 10.0.31.0/24, pont: <<PONT>>, mtu: 1500 }
- { nom: site-autorite, description: Autorité de certification, vlan: 32, sous_reseau: 10.0.32.0/24, pont: <<PONT>>, mtu: 1500 }
- { nom: site-genome, description: Forge et cache de paquets, vlan: 33, sous_reseau: 10.0.33.0/24, pont: <<PONT>>, mtu: 1500 }
- { nom: site-service, description: Noms (DNS autoritaire), vlan: 34, sous_reseau: 10.0.34.0/24, pont: <<PONT>>, mtu: 1500 }
- { nom: site-sauvegarde, description: Dépôt de sauvegarde mutualisé, vlan: 35, sous_reseau: 10.0.35.0/24, pont: <<PONT>>, mtu: 1500 }
- { nom: site-supervision, description: Supervision et observabilité, vlan: 36, sous_reseau: 10.0.36.0/24, pont: <<PONT>>, mtu: 1500 }
# Même FORME que le site de Chezlepro — le 3e octet reste le numéro de VLAN.
# Ce qui change : le 2e octet porte l'index du site (31) au lieu de 0.
# Les deux sites peuvent donc être reliés (§8 du guide) sans renumérotage.
- { nom: site-pilotage, description: Runner et pilotage, vlan: 31, sous_reseau: 10.31.31.0/24, pont: <<PONT>>, mtu: 1500 }
- { nom: site-autorite, description: Autorité de certification, vlan: 32, sous_reseau: 10.31.32.0/24, pont: <<PONT>>, mtu: 1500 }
- { nom: site-genome, description: Forge et cache de paquets, vlan: 33, sous_reseau: 10.31.33.0/24, pont: <<PONT>>, mtu: 1500 }
- { nom: site-service, description: Noms (DNS autoritaire), vlan: 34, sous_reseau: 10.31.34.0/24, pont: <<PONT>>, mtu: 1500 }
- { nom: site-sauvegarde, description: Dépôt de sauvegarde mutualisé, vlan: 35, sous_reseau: 10.31.35.0/24, pont: <<PONT>>, mtu: 1500 }
- { nom: site-supervision, description: Supervision et observabilité, vlan: 36, sous_reseau: 10.31.36.0/24, pont: <<PONT>>, mtu: 1500 }
hotes:
# L'UNIQUE NŒUD. `via` = l'interface physique qui porte le trunk vers la frontière.
@ -67,14 +76,14 @@ underlay:
# LA FRONTIÈRE, patte par patte. Une ligne par zone qu'elle sert : c'est de là que
# le devis dérive les interfaces d'arrivée des règles (D-61 raisonne en ARRIVÉE).
- { nom: <<FRONTIERE>>, reseau: management, ip: 10.23.0.1, role: frontiere }
- { nom: <<FRONTIERE>>, reseau: management, ip: 10.31.0.1, role: frontiere }
- { nom: <<FRONTIERE>>, reseau: transit-frontiere, ip: 10.0.4.1, role: frontiere }
- { nom: <<FRONTIERE>>, reseau: site-pilotage, ip: 10.0.31.1, role: frontiere }
- { nom: <<FRONTIERE>>, reseau: site-autorite, ip: 10.0.32.1, role: frontiere }
- { nom: <<FRONTIERE>>, reseau: site-genome, ip: 10.0.33.1, role: frontiere }
- { nom: <<FRONTIERE>>, reseau: site-service, ip: 10.0.34.1, role: frontiere }
- { nom: <<FRONTIERE>>, reseau: site-sauvegarde, ip: 10.0.35.1, role: frontiere }
- { nom: <<FRONTIERE>>, reseau: site-supervision, ip: 10.0.36.1, role: frontiere }
- { nom: <<FRONTIERE>>, reseau: site-pilotage, ip: 10.31.31.1, role: frontiere }
- { nom: <<FRONTIERE>>, reseau: site-autorite, ip: 10.31.32.1, role: frontiere }
- { nom: <<FRONTIERE>>, reseau: site-genome, ip: 10.31.33.1, role: frontiere }
- { nom: <<FRONTIERE>>, reseau: site-service, ip: 10.31.34.1, role: frontiere }
- { nom: <<FRONTIERE>>, reseau: site-sauvegarde, ip: 10.31.35.1, role: frontiere }
- { nom: <<FRONTIERE>>, reseau: site-supervision, ip: 10.31.36.1, role: frontiere }
# LE GABARIT ET SON STOCKAGE. Sur un nœud unique, `clone_complet` est le choix sûr :
# un clone lié dépend à vie du gabarit, et il n'y a pas d'autre nœud pour le porter.