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
93 lines
5.4 KiB
YAML
93 lines
5.4 KiB
YAML
# Underlay de SITE-Technolibre — l'infrastructure PHYSIQUE de l'hébergeur.
|
|
#
|
|
# UN SEUL NŒUD PROXMOX, en version 9. C'est la différence de fond avec le site de
|
|
# Chezlepro : pas de Ceph, pas d'iSCSI, pas de migration, pas de fabric de stockage.
|
|
# Le gabarit et ses clones vivent sur la même machine — le SPOF est total, et assumé.
|
|
#
|
|
# Dérivé du modèle `exemples/modeles/socle` (« un seul commutateur, pas de fabric de
|
|
# stockage séparée — le point de départ honnête d'un petit hébergeur »), adapté.
|
|
#
|
|
# ⚠ TOUT CE QUI EST MARQUÉ <<…>> EST À RELEVER SUR PLACE. Voir COLLECTE.md.
|
|
---
|
|
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
|
|
|
|
# CE QUI ROUTE ENTRE LES ZONES D'UN LOCATAIRE — à trancher devant le matériel.
|
|
# `switch` : un commutateur porte les SVI et les ACL (mode par défaut du moteur)
|
|
# `sdn` : EVPN sur le nœud, un VRF par locataire (éprouvé à 3 nœuds, jamais à 1)
|
|
# Voir COLLECTE.md §4 : la réponse dépend de ce qu'il y a entre le nœud et l'OPNsense.
|
|
routage_tenants: <<SWITCH_OU_SDN>>
|
|
routeur: <<NOM_DU_ROUTEUR>> # le commutateur, ou la frontière si elle route tout
|
|
dialecte: <<cisco|binardat>> # dicte la forme des ACL et des routes du devis
|
|
mtu_overlay: 1450
|
|
# À `false` quand le matériel ne sait pas lier une ACL à une interface de routage.
|
|
acl_inter_tenant: <<true|false>>
|
|
|
|
stp:
|
|
mode: rstp
|
|
topologie: etoile
|
|
|
|
reseaux:
|
|
# PLAN DE GESTION — la seule chose qui doit être unique entre deux sites.
|
|
# `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.31.0.0/24
|
|
mtu: 1500
|
|
|
|
# LIEN VERS LA FRONTIÈRE. Sans lui, la flotte n'a ni sortie ni chemin de retour :
|
|
# elle serait routée jusqu'à la bordure puis muette — très difficile à diagnostiquer.
|
|
- nom: transit-frontiere
|
|
description: Lien nœud Proxmox <-> OPNsense, et sortie par défaut des locataires
|
|
vlan: 40
|
|
sous_reseau: 10.0.4.0/24
|
|
passerelle_sortie: 10.0.4.1
|
|
mtu: 1500
|
|
|
|
# LES SIX ZONES DU SITE. Une préoccupation par zone.
|
|
# 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.
|
|
- { nom: <<NOEUD>>, reseau: management, ip: <<IP_NOEUD>>, role: hyperviseur }
|
|
- { nom: <<NOEUD>>, reseau: transit-frontiere, ip: 10.0.4.41, role: hyperviseur, via: <<IFACE>> }
|
|
|
|
# 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.31.0.1, role: frontiere }
|
|
- { nom: <<FRONTIERE>>, reseau: transit-frontiere, ip: 10.0.4.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.
|
|
materialisation:
|
|
vmid_modele: <<VMID_GABARIT>>
|
|
stockage: <<STOCKAGE>>
|
|
clone_complet: true
|