Daniel Allaire
120fe93576
Ce site n heberge aucune production : les deux ecosystemes habitent SITE-Chezlepro. Il existe pour les REPRENDRE. Son underlay declare donc les deux index, 17 et 23. Le README dit ce qu une reprise demande — trois gestes, et le plan du locataire ne bouge pas — et ce que ce site doit porter pour qu elle aboutisse. IL DIT AUSSI CE QUI N EST PAS RESOLU : les sauvegardes vivent sur le depot du site de PRODUCTION. Si ce site brule, elles brulent avec lui, et il ne resterait ici que de quoi reconstruire des machines vides. Un site de reprise sans la donnee reprend l infrastructure, pas le service. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
169 lines
9.7 KiB
YAML
169 lines
9.7 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
|
|
|
|
# CE SITE EST UN SITE DE REPRISE (2026-09-13).
|
|
#
|
|
# Il n'heberge aucune production : celle de TechnoLibre vit chez Chezlepro, et celle de
|
|
# Chezlepro chez lui. Ce site existe pour les REPRENDRE — l'une ou l'autre, ou les deux —
|
|
# lors d'un exercice ou d'un sinistre.
|
|
#
|
|
# Les deux index sont donc declares. Ce n'est pas une intention : c'est ce qui permet a
|
|
# `make instances` de garder l'unicite, et au SDN d'allouer les VNets des deux le jour ou
|
|
# on les demande.
|
|
#
|
|
# UN LOCATAIRE N'APPARTIENT A AUCUN SITE. Reprendre, c'est faire pointer son symlink
|
|
# `underlay.yml` ici, reprendre les intrants par `make site-intrants`, et redeployer
|
|
# depuis son propre depot. Le plan du locataire ne change pas.
|
|
tenants:
|
|
OPS-Chezlepro: 17
|
|
OPS-Technolibre: 23
|
|
|
|
# CE QUI ROUTE ENTRE LES ZONES D'UN LOCATAIRE — `sdn`, COMME CHEZLEPRO.
|
|
#
|
|
# En EVPN, le routage ET le filtrage inter-zone d'un locataire vivent sur le nœud :
|
|
# aucun VLAN de locataire ne circule sur le fil, seulement du VXLAN encapsulé. Le devis
|
|
# switch cesse alors d'émettre VLAN de locataire, SVI et ACL — vérifié le 2026-09-13 :
|
|
# sept VLAN émis (les six du site plus le transit), zéro SVI.
|
|
#
|
|
# L'inter-locataire, lui, sort du VRF et passe par la frontière, qui le police.
|
|
routage_tenants: sdn
|
|
|
|
# LE COMMUTATEUR, ET C'EST UNE CORRECTION (2026-09-13). Ce champ portait `portail`, la
|
|
# frontière, parce qu'on avait cru qu'il n'y avait rien entre la fabric et l'OPNsense.
|
|
# Il y a bien un commutateur — comme à Chezlepro, et à la même place. C'est lui qui
|
|
# porte l'underlay ; la frontière ne fait que la bordure nord/sud.
|
|
routeur: arche-1
|
|
|
|
dialecte: binardat
|
|
mtu_overlay: 1450
|
|
|
|
# UN SEUL LOCATAIRE POUR L'INSTANT, et l'inter-locataire passe déjà par la frontière.
|
|
# Même valeur qu'à Chezlepro. À revoir le jour où un deuxième écosystème s'installe.
|
|
acl_inter_tenant: false
|
|
|
|
# `rstp` plutôt que `mstp` : un seul commutateur, donc aucune instance par VLAN à
|
|
# distinguer. La topologie reste l'étoile de Chezlepro — un centre, des feuilles.
|
|
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.
|
|
# UN SEUL PLAN D'ADMINISTRATION, ET C'EST UNE DIFFÉRENCE ASSUMÉE AVEC CHEZLEPRO.
|
|
#
|
|
# Chezlepro sépare `management` (le plan d'admin du site) de `grappe-controle` (où
|
|
# vivent l'interface web et l'API de Proxmox). Cette séparation y a une cause
|
|
# historique : ses trois nœuds existaient AVANT Set-OPS, sur un réseau qui leur était
|
|
# déjà propre.
|
|
#
|
|
# Ici, un seul nœud et un terrain vierge : un second réseau ne séparerait rien. Il
|
|
# obligerait seulement à router entre les deux pour que le poste de l'exploitant —
|
|
# posé sur l'admin — atteigne une API posée ailleurs.
|
|
#
|
|
# L'exploitant se donne une adresse secondaire dans ce réseau et atteint d'un coup la
|
|
# frontière (.1), le nœud (.41) et le rebond vers les machines du site.
|
|
- nom: management
|
|
description: Gestion du nœud, API Proxmox, 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: vmbr0, mtu: 1500 }
|
|
- { nom: site-autorite, description: Autorité de certification, vlan: 32, sous_reseau: 10.31.32.0/24, pont: vmbr0, mtu: 1500 }
|
|
- { nom: site-genome, description: Forge et cache de paquets, vlan: 33, sous_reseau: 10.31.33.0/24, pont: vmbr0, mtu: 1500 }
|
|
- { nom: site-service, description: Noms (DNS autoritaire), vlan: 34, sous_reseau: 10.31.34.0/24, pont: vmbr0, mtu: 1500 }
|
|
- { nom: site-sauvegarde, description: Dépôt de sauvegarde mutualisé, vlan: 35, sous_reseau: 10.31.35.0/24, pont: vmbr0, mtu: 1500 }
|
|
- { nom: site-supervision, description: Supervision et observabilité, vlan: 36, sous_reseau: 10.31.36.0/24, pont: vmbr0, mtu: 1500 }
|
|
|
|
# TRANSPORT DU VXLAN ENTRE VTEP. Exigé par `routage_tenants: sdn` — c'est le réseau
|
|
# dans lequel les tunnels des locataires sont encapsulés. Il ne porte JAMAIS de
|
|
# trafic de gestion, et aucune machine de locataire ne le voit.
|
|
#
|
|
# Chezlepro l'adresse en 192.168.50.0/24 ; ici il DÉRIVE de l'index du site, comme
|
|
# tout le reste. Les deux sites ont vocation à être reliés : deux transports VXLAN
|
|
# au même adressage produiraient une panne dont le message ne parle pas d'adressage.
|
|
- nom: underlay-vxlan
|
|
description: Transport VXLAN entre VTEP — aucun trafic de gestion
|
|
vlan: 50
|
|
sous_reseau: 10.31.50.0/24
|
|
mtu: 1500
|
|
|
|
hotes:
|
|
# L'UNIQUE NŒUD. `via` = l'interface physique qui porte le trunk vers la frontière.
|
|
- { nom: atelier, reseau: management, ip: 10.31.0.41, role: hyperviseur, via: vmbr0 }
|
|
- { nom: atelier, reseau: underlay-vxlan, ip: 10.31.50.41, role: hyperviseur, via: <<IFACE>> }
|
|
- { nom: atelier, reseau: transit-frontiere, ip: 10.0.4.41, role: hyperviseur, via: <<IFACE>> }
|
|
|
|
# LE COMMUTATEUR, entre la fabric et la frontière. Une seule patte, sur le plan de
|
|
# gestion : c'est par là qu'on le configure, et le devis n'a pas besoin d'autre chose.
|
|
- { nom: arche-1, reseau: management, ip: 10.31.0.3, role: switch }
|
|
|
|
# LA PASSERELLE AMONT — la boîte du fournisseur d'accès, en amont de la frontière.
|
|
# Déclarée pour que le devis sache où s'arrête notre responsabilité.
|
|
- { nom: routeur-site, reseau: management, ip: 10.31.0.254, role: passerelle_amont }
|
|
|
|
# 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: portail, reseau: management, ip: 10.31.0.1, role: frontiere }
|
|
- { nom: portail, reseau: transit-frontiere, ip: 10.0.4.1, role: frontiere }
|
|
- { nom: portail, reseau: site-pilotage, ip: 10.31.31.1, role: frontiere }
|
|
- { nom: portail, reseau: site-autorite, ip: 10.31.32.1, role: frontiere }
|
|
- { nom: portail, reseau: site-genome, ip: 10.31.33.1, role: frontiere }
|
|
- { nom: portail, reseau: site-service, ip: 10.31.34.1, role: frontiere }
|
|
- { nom: portail, reseau: site-sauvegarde, ip: 10.31.35.1, role: frontiere }
|
|
- { nom: portail, 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:
|
|
# MÊME VMID QUE PARTOUT AILLEURS DANS LA FLOTTE. Le gabarit est le même actif d'un
|
|
# site à l'autre ; lui donner un numéro par site obligerait à le chercher.
|
|
# LE VMID N'EST PLUS DECLARE ICI (2026-09-13). Il vivait a la fois dans
|
|
# `plan/10-intrants.yml` (`gabarit:`) et ici — et les deux ont diverge : le plan
|
|
# disait 9006, ce champ 99998, que le plan nomme justement `precedent`.
|
|
#
|
|
# Les machines du SITE naissaient donc de l'ancien gabarit et celles des
|
|
# LOCATAIRES du nouveau, sans que rien ne le dise — les deux clonent.
|
|
#
|
|
# `site_machines` lit desormais `underlay.gabarit()`, c'est-a-dire le PLAN DU
|
|
# SITE. Le motif d'origine tient toujours : cette source ne depend d'aucun
|
|
# symlink `instance`, donc le site ne clone jamais le gabarit d'un tenant.
|
|
# `local-lvm` — le stockage que Proxmox pose à l'installation. Sur un nœud unique il
|
|
# n'y a rien d'autre, et c'est honnête de le dire : quinze clones complets y tiennent
|
|
# ou n'y tiennent pas, et c'est la première chose à mesurer sur place.
|
|
stockage: local-lvm
|
|
clone_complet: true
|