From 28d278111c4565f639f0fb1ddbb7f7ecd154aeba Mon Sep 17 00:00:00 2001 From: Daniel Allaire Date: Sat, 12 Sep 2026 14:31:52 -0400 Subject: [PATCH] un site prend son propre index, et la garde les compte enfin MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q --- COLLECTE.md | 7 +++---- README.md | 13 ++++++------- plan/serveurs.yml | 14 +++++++------- underlay.yml | 47 ++++++++++++++++++++++++++++------------------- 4 files changed, 44 insertions(+), 37 deletions(-) diff --git a/COLLECTE.md b/COLLECTE.md index 5da1ed9..df19154 100644 --- a/COLLECTE.md +++ b/COLLECTE.md @@ -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. diff --git a/README.md b/README.md index 80638bb..2d20022 100644 --- a/README.md +++ b/README.md @@ -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 diff --git a/plan/serveurs.yml b/plan/serveurs.yml index 73adb8a..96bbc7c 100644 --- a/plan/serveurs.yml +++ b/plan/serveurs.yml @@ -22,7 +22,7 @@ serveurs: site-ops-01: etat: actif reseau: site-pilotage - ip: 10.0.31.11 + ip: 10.31.31.11 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: <> 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: <> 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: <> 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: <> 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: <> 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: <> gabarit: { vcpu: 2, memoire: 4096, disque: 64G } vmid: 9011 diff --git a/underlay.yml b/underlay.yml index b8f26c6..ba66306 100644 --- a/underlay.yml +++ b/underlay.yml @@ -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..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..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: <>, mtu: 1500 } - - { nom: site-autorite, description: Autorité de certification, vlan: 32, sous_reseau: 10.0.32.0/24, pont: <>, mtu: 1500 } - - { nom: site-genome, description: Forge et cache de paquets, vlan: 33, sous_reseau: 10.0.33.0/24, pont: <>, mtu: 1500 } - - { nom: site-service, description: Noms (DNS autoritaire), vlan: 34, sous_reseau: 10.0.34.0/24, pont: <>, mtu: 1500 } - - { nom: site-sauvegarde, description: Dépôt de sauvegarde mutualisé, vlan: 35, sous_reseau: 10.0.35.0/24, pont: <>, mtu: 1500 } - - { nom: site-supervision, description: Supervision et observabilité, vlan: 36, sous_reseau: 10.0.36.0/24, 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: <>, mtu: 1500 } + - { nom: site-autorite, description: Autorité de certification, vlan: 32, sous_reseau: 10.31.32.0/24, pont: <>, mtu: 1500 } + - { nom: site-genome, description: Forge et cache de paquets, vlan: 33, sous_reseau: 10.31.33.0/24, pont: <>, mtu: 1500 } + - { nom: site-service, description: Noms (DNS autoritaire), vlan: 34, sous_reseau: 10.31.34.0/24, pont: <>, mtu: 1500 } + - { nom: site-sauvegarde, description: Dépôt de sauvegarde mutualisé, vlan: 35, sous_reseau: 10.31.35.0/24, pont: <>, mtu: 1500 } + - { nom: site-supervision, description: Supervision et observabilité, vlan: 36, sous_reseau: 10.31.36.0/24, 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: <>, reseau: management, ip: 10.23.0.1, role: frontiere } + - { nom: <>, reseau: management, ip: 10.31.0.1, role: frontiere } - { nom: <>, reseau: transit-frontiere, ip: 10.0.4.1, role: frontiere } - - { nom: <>, reseau: site-pilotage, ip: 10.0.31.1, role: frontiere } - - { nom: <>, reseau: site-autorite, ip: 10.0.32.1, role: frontiere } - - { nom: <>, reseau: site-genome, ip: 10.0.33.1, role: frontiere } - - { nom: <>, reseau: site-service, ip: 10.0.34.1, role: frontiere } - - { nom: <>, reseau: site-sauvegarde, ip: 10.0.35.1, role: frontiere } - - { nom: <>, reseau: site-supervision, ip: 10.0.36.1, role: frontiere } + - { nom: <>, reseau: site-pilotage, ip: 10.31.31.1, role: frontiere } + - { nom: <>, reseau: site-autorite, ip: 10.31.32.1, role: frontiere } + - { nom: <>, reseau: site-genome, ip: 10.31.33.1, role: frontiere } + - { nom: <>, reseau: site-service, ip: 10.31.34.1, role: frontiere } + - { nom: <>, reseau: site-sauvegarde, ip: 10.31.35.1, role: frontiere } + - { nom: <>, 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.