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>
95 lines
5 KiB
Markdown
95 lines
5 KiB
Markdown
# 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 :
|
|
|
|
1. **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.
|
|
2. **Bon dimensionnement** — ~13 VM. NetBox est de la machinerie d'échelle entreprise.
|
|
3. **Modèle sur-mesure** — NetBox exprimerait nos DSN / expositions à coups de
|
|
*custom fields* et de plugins, moins naturellement que nos registres.
|
|
4. **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.
|