SITE-TechnoLibre/underlay.yml

# 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 — `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