Set-OPS-Public/docs/multi-instances.md

Multi-instances — un moteur, N écosystèmes

Set-OPS sépare le moteur (ce dépôt : rôles, playbooks, scripts, GUI) de l'instance (un dépôt distinct : le plan d'un écosystème + son inventaire généré + ses secrets). Un seul moteur pilote autant d'instances que voulu.

« lab vs prod » n'est qu'un cas particulier : ce sont deux instances. Le même mécanisme sert un bac à sable, une production, ou les écosystèmes de plusieurs tenants — c'est le socle multi-tenant souverain.

Une instance = un écosystème autonome

Chaque instance est un dépôt séparé, monté dans le moteur par symlink (instance →). Elle possède tout ce qui lui est propre :

<instance>/
├── plan/                         ← la « méta-classe » (cf. meta-classe.md)
│   ├── nomenclature.yml          réseau, VLAN, fonctions
│   ├── serveurs.yml              VM = fonction + état + overrides
│   ├── applications.yml
│   ├── bases-donnees.yml
│   └── domaines.yml
└── inventories/principal/        ← un seul inventaire par instance
    ├── hosts.yml                 généré (make instancier-appliquer)
    └── group_vars/
        ├── all/
        │   ├── 00-instance.yml   setops_plan_dir, setops_production
        │   ├── 10-intrants.yml   identité (domaine_interne, fuseau)
        │   └── vault.yml         🔒 voûte UNIQUE de l'instance (chiffrée)
        ├── proxmox.yml           cible Proxmox de l'instance
        └── modeles_vm.yml        construction du golden template

Isolation totale entre instances : plan, inventaire, voûte, identité (domaine_interne), réseau (supernet) et cible Proxmox distincts. Une instance ne peut pas toucher l'infra d'une autre.

Choisir l'instance active

Le moteur lit la variable SETOPS_INSTANCE (par défaut le symlink instance).

make instance-courante                          # quelle instance est montée ?
make instance-utiliser NOM=OPS-Chezlepro        # bascule sur la production
make instance-utiliser NOM=OPS-Chezlepro-lab    # bascule sur le bac à sable

Sans toucher au symlink (utile en CI ou pour du parallèle) :

make inventaire-ui SETOPS_INSTANCE=../OPS-ClientX
# ou viser un inventaire précis :
make deployer SETOPS_INVENTAIRE=../OPS-ClientX/inventories/principal/hosts.yml HOTE=…

L'inventaire est détecté de façon rétro-compatible : principal > production > lab (les anciennes instances à double inventaire continuent de marcher).

setops_production — un attribut, pas une catégorie

Le déploiement réel est permis sur toute instance (un bac à sable déploie sur son infra). Le drapeau setops_production (dans group_vars/all/) ne bloque rien : il marque la PRODUCTION pour exiger une confirmation renforcée au déploiement (badge rouge « PROD », bouton Déployer rouge, re-saisie du nom d'hôte). Une instance bac à sable met false et affiche « bac à sable ».

Créer une nouvelle instance

1. Créer un dépôt d'instance frère de Set-OPS-public/ (ex. ../OPS-ClientX), avec la structure ci-dessus. Le plus simple : copier un modèle de exemples/modeles/ ou l'instance bac à sable comme point de départ.
2. Régler l'identité (10-intrants.yml : domaine distinct), le réseau (nomenclature.yml : supernet distinct) et la cible Proxmox (proxmox.yml).
3. Créer la voûte unique depuis le gabarit (cf. config-proxmox.md) : cp exemples/vault.exemple.yml …/group_vars/all/vault.yml puis ansible-vault encrypt.
4. make instance-utiliser NOM=OPS-ClientX puis make instancier-appliquer, make inventaire-ui.

Multi-tenant

Chaque tenant est simplement une instance de plus. Un client = make instance-utiliser NOM=OPS-<Client>, tout son écosystème instancié par le même moteur, isolé. C'est la base concrète de la portabilité des tenants.

Garde-fou de positionnement : si le nombre d'instances explose, le besoin d'un registre (lister/choisir, IPAM, secrets centralisés) relève d'outils établis (NetBox, AWX, un coffre type Vault HashiCorp) à adopter aux seuils, pas à réimplémenter dans le moteur. Cf. positionnement.md.

Adressage fédéré (index d'instance)

Pour que plusieurs écosystèmes coexistent et puissent s'interconnecter sans collision, chaque instance de production reçoit un index (déclaré en tête de plan/nomenclature.yml : index: N). Il pilote :

• le supernet : 10.(10 + index).0.0/16 (zéro chevauchement) ;
• le préfixe VMID : index·catégorie·service·séq (ex. 21101) au lieu du 9 fixe.

Instance	index	Supernet	VMID
Chezlepro	1	10.11.0.0/16	1CSNN
Technolibre	2	10.12.0.0/16	2CSNN
…	N	10.(10+N).0.0/16	N·CSNN
Bacs à sable	(aucun)	172.19.x ad-hoc	9CSNN (défaut)

Sans index déclaré, on retombe sur 9CSNN (rétro-compatible) : c'est ce qu'utilisent les bacs à sable, qui vivent hors fédération (plages jetables 172.19.x) et n'ont pas vocation à s'interconnecter.

Plafond : un index à 1 chiffre = 9 écosystèmes prod fédérés (VMID à 5 chiffres) ; élargir l'index pour davantage. Au-delà d'une poignée d'instances co-localisées, confier l'allocation à un IPAM (NetBox) plutôt qu'au moteur — cf. positionnement.md.

Voir aussi

• meta-classe.md — le plan d'une instance instancie sa flotte.
• config-proxmox.md — voûte unique + cible Proxmox par instance.
• intrants-communs.md — intrants de base d'une instance.