SITE-TechnoLibre/README.md

SITE-TechnoLibre — site de reprise

Pour qui : l'exploitant, quand il prépare ou joue une reprise.

Ce site n'héberge aucune production. Celle de Chezlepro vit chez Chezlepro, celle de TechnoLibre aussi — les deux écosystèmes habitent SITE-Chezlepro. Ce site-ci existe pour les reprendre, lors d'un exercice ou d'un sinistre.

C'est pourquoi son underlay.yml déclare les deux index : 17 et 23.

Ce qu'une reprise demande

Un écosystème se reconstitue depuis son propre dépôt. Reprendre, c'est :

1. faire pointer le symlink underlay.yml du moteur vers ce site ;
2. reprendre les sept intrants par make site-intrants ;
3. redéployer depuis le dépôt du locataire.

Le plan du locataire ne change pas. Seul change le site qu'il habite.

Ce que ce site doit porter pour qu'une reprise aboutisse

Les mêmes services prêtés que le site de production — cache, forge, noms, dépôt — plus la fabrique. Un site de reprise qui n'a pas de forge ne peut pas servir le génome ; un site qui n'a pas de cache fait sortir chaque machine sur Internet.

Ce qui n'est pas encore résolu

Les sauvegardes ne sont pas ici. Chaque écosystème dépose sur le dépôt de son site de production. Si ce site brûle, ses sauvegardes brûlent avec lui — et il ne resterait ici que de quoi reconstruire des machines vides.

Un site de reprise sans la donnée reprend l'infrastructure, pas le service. C'est la question à trancher avant de qualifier ce site de « site de reprise » devant quiconque.

Ce qui le distingue du site de Chezlepro

	Chezlepro	Technolibre
Nœuds Proxmox	3 (asgard, gandalf, vishnu)	1
Version	PVE 8.4	PVE 9
Stockage partagé	Ceph NVMe + TrueNAS iSCSI	local au nœud
Clones	liés, sur stockage partagé	complets — pas d'autre nœud pour porter le gabarit
Frontière	OPNsense	OPNsense

Trois conséquences directes :

1. Le SPOF est total et assumé. Le gabarit, ses clones et le site entier sont sur la même machine. Perdre le nœud, c'est tout perdre — d'où l'importance du dépôt de sauvegarde hors nœud dès le premier jour.
2. clone_complet: true. Un clone lié dépend à vie de son gabarit ; sans second nœud, ce lien n'achète rien et coûte une dépendance.
3. Proxmox 9 n'a jamais été éprouvé. Le moteur n'analyse aucune version et n'appelle que des chemins d'API stables, mais c'est la première fois. Surveiller le pare-feu (proxmox-firewall nftables depuis la 9) et le SDN (passé GA).

Le chiffre à vérifier en premier

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 un seul nœud, la même machine porte tout, et la RAM est la contrainte dure. En dessous de 64 Go, il faut décider de réduire avant de câbler, pas pendant le déploiement.

L'adressage

• 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

1. Remplir COLLECTE.md en entier — une ligne vide bloque plus tard, ailleurs.
2. Reporter les valeurs dans underlay.yml, plan/10-intrants.yml, opnsense.yml.
3. Trancher le mode de routage devant le matériel (COLLECTE.md §4).
4. Gabarit : vérifier ou fabriquer (docs/procedure-template-debian13-proxmox.md).
5. Voûte : y déposer les deux paires de secrets, jamais dans git.
6. make underlay — le devis lit le site réel et refuse ce qui ne concorde pas.
7. make site-creer CONFIRMER=true, puis le socle.

Voir aussi

• docs/preparer-un-site-hebergeur.md — ce qu'un hébergeur doit fournir
• docs/implanter-un-tenant-sur-un-site.md — y poser OPS-Technolibre ensuite
• docs/hebergeur-exploitation.md — l'exploitation courante