Daniel Allaire
95698a36c0
Rafraichir les chemins dans docs secondaires, README de roles, messages, docstrings : inventories/ -> instance/inventories/, docs/<plan>.yml -> instance/plan/<plan>.yml. Correction de chemins de playbooks perimes (preexistants) dans CLAUDE.md/SOLUTION.md : vm_templates/..._prepare| verify|cleanup -> modeles_vm/..._preparer|verifier|nettoyer, et confirm_template_cleanup -> template_cleanup_confirm. Valide : diff vide, ansible-lint 0 echec, make inventaire-verifier. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
5 KiB
Positionnement : ce que Set-OPS fait maison, et quand adopter l'existant
Ce document acte une décision pour ne plus la redébattre à chaque évolution : quelles parties de Set-OPS sont volontairement maison, pourquoi, et à partir de quel seuil il vaudra mieux adopter un outil du marché plutôt que continuer à le réimplémenter.
En une phrase : le cœur de Set-OPS (un plan déclaratif qui génère l'inventaire Ansible) existe déjà sous forme mûre — c'est NetBox. Set-OPS en est une version souveraine, légère et sur-mesure, assumée comme telle. Le risque à surveiller est de réimplémenter NetBox/AWX brique par brique.
1. La carte : chaque facette a un équivalent du marché
| Facette de Set-OPS | Équivalent mûr | Remarque |
|---|---|---|
| Source de vérité déclarative → génère l'inventaire Ansible | NetBox / Nautobot + plugin netbox.netbox.nb_inventory |
Le plus proche du cœur de Set-OPS (le « plan »). |
| GUI qui exécute Ansible (déployer, RBAC, planification) | AWX / Ansible Automation Platform ; Semaphore | Set-OPS a un GUI plus modeste (lancer make). |
| « La définition instancie toute la flotte » | NixOS + Colmena/morph ; Terraform (provider Proxmox) pour créer les VM | L'idée « méta-classe » au sens littéral. |
| Application = entité pivot avec ses dépendances et ressources | Backstage (catalogue de composants + graphe) | Le modèle requiert/utilise/expose y ressemble fortement. |
| IPAM / dérivation d'adressage | NetBox (IPAM natif) | Set-OPS dérive depuis la nomenclature. |
Aucun produit ne fait l'assemblage exact : Proxmox + Ansible + le modèle bespoke (DSN, exposition DNS, dérivation par fonction) en un seul outil souverain et léger. Cet assemblage-là est propre à Set-OPS.
2. Ce que Set-OPS fait sciemment maison (et pourquoi)
- Le plan déclaratif (
instance/plan/serveurs.yml,applications.yml,bases-donnees.yml,domaines.yml,nomenclature.yml) et le générateur d'inventaire (make instancier). - Le modèle application-hub : bindings DSN (portée application/groupe/hôte) et exposition DNS, taillés exactement pour nos concepts.
- Le GUI (Python stdlib, fichier unique) et les validateurs / garde-fous
(diff-vide,
node --check, vérificateurs de registres).
Raisons assumées :
- Souveraineté — mission explicite du dépôt. NetBox + AWX + Backstage = trois applications lourdes à héberger et maintenir (Django + PostgreSQL, etc.). Set-OPS reste possédé en entier, sans dépendance.
- Bon dimensionnement — ~13 VM. NetBox est de la machinerie d'échelle entreprise.
- Modèle sur-mesure — NetBox exprimerait nos DSN / expositions à coups de custom fields et de plugins, moins naturellement que nos registres.
- Maîtrise — chaque ligne est comprise et auditable.
3. Ce que le maison NE fait PAS (et que les outils mûrs ont)
À garder en tête honnêtement — ce sont des fonctions qu'on n'a pas, pas des bugs :
- historique/audit des changements (au-delà de
git) ; - RBAC multi-utilisateurs ;
- détection de conflits IPAM, réservations, gestion d'adresses à grande échelle ;
- webhooks / intégrations tierces, API riche (REST/GraphQL) ;
- écosystème de plugins, communauté, correctifs de sécurité maintenus par d'autres.
4. La règle : plan de contrôle gelé en fonctionnalités
Set-OPS continue d'évoluer pour décrire et déployer l'écosystème (rôles, services, registres applicatifs). En revanche, le plan de contrôle (le GUI, le générateur, l'IPAM, la modélisation) est considéré gelé en périmètre : on ne lui ajoute pas de fonctionnalités de type NetBox/AWX.
Seuils d'adoption (les signaux de bascule)
Adopter l'outil du marché — sans réécrire, en branchant Ansible/notre GUI par-dessus — dès qu'un de ces besoins devient réel :
| Besoin qui apparaît | Adopter |
|---|---|
| RBAC, plusieurs opérateurs, historique d'audit, secrets/credentials centralisés | AWX (exécution) |
| IPAM sérieux, détection de conflits, source de vérité partagée, API/webhooks | NetBox (et nb_inventory remplace notre générateur) |
| Catalogue de services / portail développeur, ownership, scaffolding | Backstage |
| Provisionnement de VM déclaratif et reproductible à plus grande échelle | Terraform (Proxmox) ou NixOS + Colmena |
Test simple : si on se surprend à vouloir réimplémenter une de ces fonctions dans Set-OPS, c'est le signal d'adopter l'outil correspondant plutôt que de prolonger le maison.
5. Décision en vigueur
- On garde le plan de contrôle maison : il fonctionne, il est souverain et bien dimensionné pour aujourd'hui. Pas de réécriture sur NetBox « par principe ».
- On gèle son périmètre fonctionnel (voir §4).
- On réévalue à l'échéance d'un seuil ci-dessus, ou si la charge de maintenance du maison dépasse le coût d'héberger l'outil mûr.