SITE-TechnoLibre/COLLECTE.md
Daniel Allaire 7db59ebfe9 un seul plan d administration : grappe-controle retire
Ce site declarait deux reseaux d administration, calques sur Chezlepro : `management`
(le plan d admin) et `grappe-controle` (interface web et API de Proxmox).

Cette separation a une cause HISTORIQUE chez Chezlepro : ses trois noeuds existaient
avant Set-OPS, sur un reseau qui leur etait deja propre — et que le poste de
l exploitant atteint par routage, pas en s y posant.

Ici, un seul noeud et un terrain vierge : le second reseau ne separait rien. Il
obligeait seulement a router entre les deux pour que le poste — pose sur l admin —
atteigne une API posee ailleurs.

L exploitant se donne une adresse secondaire dans 10.31.0.0/24, exactement comme il le
fait deja pour 10.17.0.x et 10.37.0.x chez lui, et atteint d un coup la frontiere
(.1), le noeud (.41) et le rebond.

- reseau `grappe-controle` retire ; le noeud et la passerelle amont reviennent sur
  `management` (10.31.0.41 et 10.31.0.254)
- `proxmox_api_host` suit : 10.31.0.41
- COLLECTE.md dit ou le poste doit se poser

Verifie : devis SDN conforme (1 zone, 6 VNets), devis reseau emet les VLAN 31-36, 40
et 50 avec zero SVI, contrat du site inchange.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-13 18:28:50 -04:00

7.6 KiB
Raw Permalink Blame History

À relever sur place — TechnoLibre

Tout ce qui pouvait être décidé l'a été le 2026-09-13. Ce qui suit n'est pas un choix : ce sont des FAITS que seul le matériel peut dire. Treize valeurs, pas trente-cinq.

Ce qu'il faut Où le lire Pourquoi personne ne peut le décider
<<IFACE>> ip -br link sur le nœud Le nom de la carte réseau dépend du matériel (eno1, enp1s0…)
<<IP_PUBLIQUE>> OPNsense, interface WAN Donnée par le fournisseur d'accès
<<IP_FRONTIERE_ADMIN>> OPNsense, interface de gestion Dépend du plan d'adressage existant sur place
<<optN>> ×9 OPNsense → Interfaces → Assignments Les noms optN sont attribués dans l'ordre de création
`<<lan optN>>` Idem
proxmox_api_token_id Datacenter → Permissions → API Tokens Délivré par le nœud à la création
proxmox_api_token_secret Idem — affiché une seule fois Ne se relit jamais ; le noter tout de suite
vault_opnsense_api_key System → Access → Users → api keys Délivré par la frontière
vault_opnsense_api_secret Téléchargé avec la clé, même fichier Idem

Le piège des optN. Le devis raisonne en ARRIVÉE : une règle posée sur la mauvaise patte ne correspond jamais, et rien ne le signale. Relever les neuf noms exacts avant de poser quoi que ce soit, y compris celui de la patte face au nœud Proxmox — elle manquait chez Chezlepro et toutes les règles entrantes des locataires tombaient dans le vide.

Ce qui est mesuré, pas relevé. local-lvm accueille quinze clones complets, soit environ 600 Go. Vérifier vgs et df -h AVANT de lancer la matérialisation : c'est la seule décision de ce document qui peut encore changer, et elle se prend avec un chiffre.

Les quatre jetons vont dans la voûte, pas dans un fichier de plan :

cd ../Set-OPS-public
ANSIBLE_VAULT_IDENTITY_LIST="$(python3 scripts/voutes.py identites)" \
  ansible-vault edit ../SITE-Technolibre/underlay.vault.yml

Ils y sont déjà déclarés, vides. C'est volontaire : une clé absente donne une erreur de variable indéfinie, une clé vide donne l'assertion du rôle — qui dit quoi manque et où le prendre. Les dix autres secrets du site sont déjà engendrés.


Ce qui a été décidé, et qu'il suffit de confirmer

Valeur Raison
Index du site 31 Les sites prennent leur propre index depuis le 2026-09-12
Plan d'administration 10.31.0.0/24 Un seul — frontière .1, nœud .41, passerelle amont .254
Adresse du poste une secondaire dans 10.31.0.0/24 De là, l'API Proxmox, la frontière et le rebond sont tous joignables
Nœud Proxmox atelier À poser comme nom d'hôte à l'installation
Frontière portail Étiquette dans la carte ; l'OPNsense peut garder son nom réel
Domaine du site socle.internal Distinct de technolibre.internal, qui est au locataire
Routage des locataires sdn (EVPN sur le nœud) Sans commutateur L3, le mode switch obligerait la frontière à porter douze interfaces routées
ASN 65031 Dérivé de l'index — deux sites reliés ne peuvent pas collisionner
Contrôleur EVPN EVPN0031 Objet de cluster : nommé d'après le site, pas d'après son premier locataire
Pont vmbr0 Un seul, VLAN-aware — sans seconde carte, d'autres ponts ne sépareraient rien
Gabarit 99998 Le même dans toute la flotte

1. Le chiffre qui décide de tout

SITE      7 VM    20 Go RAM    776 Go provisionnés
tenant   14 VM    37 Go RAM    460 Go provisionnés
         ─────────────────────────────────────────
TOTAL    21 VM    57 Go RAM    ~1,2 To

Sur trois nœuds ça se répartit. Sur un seul, la même machine porte tout — et la RAM est la contrainte dure (le disque se dégonfle en provisionnement fin, pas la mémoire).

  • RAM physique du nœud : ______ Go → si < 64, décider de réduire AVANT de câbler
  • Espace libre du stockage images : ______ Go (viser 1,2 To ; 800 Go à la rigueur)

2. L'hyperviseur

  • Nom exact du nœud tel qu'il apparaît dans l'interface : ______
  • Version : pveversion | head -1 → ______ (attendu : pve-manager/9.x)
  • Noms exacts des stockages acceptant le contenu images : pvesm status
  • Ponts présents : ip -br link | grep vmbr
  • Adresse de gestion du nœud : ______
  • SDN disponible ? pvesh get /cluster/sdn répond sans erreur : oui / non

Compte d'API

pveum user add ansible@pve
pveum aclmod / -user ansible@pve -role Administrator
pveum user token add ansible@pve set-ops --privsep 0
  • Token ID + secret notés (le secret ne s'affiche qu'une fois)

3. La frontière (OPNsense)

  • IP publique (WAN) : ______
  • Version : ______
  • Interfaces libres pour les zones du site : ______
  • Clé + secret d'API créés et notés
  • Compte ansible en SSH par clé, sudo vérifié : sudo -n -l
  • Une patte face au nœud Proxmox (le lien de transit) : interface ______

4. Entre les deux — LA question de forme

Ce qu'il y a entre le nœud Proxmox et l'OPNsense décide du mode de routage :

  • Un commutateur capable de SVI et d'ACL → mode switch, modèle : ______
  • Un commutateur simple (VLAN seulement) → l'OPNsense route tout, mode switch avec l'OPNsense comme routeur
  • Un lien direct nœud ↔ OPNsense → trunk 802.1Q, l'OPNsense route tout
  • SDN EVPN sur le nœud → indépendant du matériel, mais jamais éprouvé sur un nœud unique

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.31.x ou 10.23.x ? ______
  • Docker présent sur ses machines d'administration ? (172.17+ déjà pris)

6. Le gabarit

  • Gabarit Debian 13 modeleSetOPS-minimal : fait / à faire (procédure : docs/procedure-template-debian13-proxmox.md, ~30 min)
  • Si fait : VMID ______ , nom ______ , stockage ______
  • Vérifier machine: q35 et bios: ovmf — ne jamais convertir un i440fx

7. Les accès réseau nécessaires depuis le poste

Cible Port Pour quoi OK
Hyperviseur 8006 créer et détruire les VM [ ]
Hyperviseur 22 pvesh, qm, SDN [ ]
Frontière 443 poser les règles par API [ ]
Frontière 22 SSH, compte ansible [ ]
Zones du site 22 SSH vers les VM une fois créées [ ]

8. Les deux paires de secrets

Par un canal chiffré, séparément du reste, et jamais dans git :

  • Token ID + secret de l'hyperviseur → voûte de l'instance
  • Clé + secret de l'API de la frontière → voûte de l'instance

9. Ce qui n'a jamais été éprouvé, et qu'il faut regarder de près

  • Proxmox 9 — le moteur n'analyse aucune version et n'appelle que des chemins d'API stables, mais rien n'a jamais tourné contre un PVE 9. Surveiller le pare-feu (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é.
  • 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.