Daniel Allaire
1d875f50ec
Le depot couvrait deja « l'hebergeur prepare son materiel » et « un tenant VIVANT change d'hebergeur, sans coupure ». Il manquait le troisieme cas, qui est celui qu'on s'apprete a faire : un tenant dont le plan existe deja prend corps sur un site qui n'a jamais rien porte. Rien a migrer, rien a interrompre — donc ni la sequence de gel/bascule de migration-tenant.md, ni le bootstrap de QUICKSTART. SIX PHASES, chacune fermee par une commande qui INTERROGE le systeme : 0 bureau (index du site = index du tenant, depot hebergeur, gabarit, voute) 1 reconnaissance du cluster -> `make underlay`, `make placement-plan` 2 frontiere -> `make frontiere-plan` 3 gabarit (convertir en template ; un clone de VM vivante en ferait 14 copies) 4 composer les DEUX symlinks (D-80) + les 4 valeurs de placement 5 materialiser -> `make sdn-appliquer` puis `make reconstruire` 6 recette : devis, restauration eprouvee, supervision CE QUE LE RUNBOOK PORTE ET QU'AUCUN AUTRE DOCUMENT NE DIT - Un site NEUF se batit d'emblee dans l'adressage cible (D-77/D-78). Le site historique est encore en 10.0.x et migrera par runbooks §6 ; sur un site vierge la cible ne coute rien. Deux sites en 10.0.0.0/24 rendraient la reprise mutuelle IMPOSSIBLE : deux plans de gestion identiques ne peuvent pas s'atteindre. - L'ordre de `reconstruire` est explique ligne a ligne, dont le piege `make flux` : sans lui nftables tombe en `policy drop` SANS AUCUNE REGLE, la flotte monte, SSH repond, et tout le reste est mur (trouve le 2026-08-10). - Un site a UN SEUL noeud : il est aussi noeud de sortie, aucun pont ne peut etre partiel, aucune haute disponibilite — a dire, pas a laisser supposer. - PVE 9 n'a jamais ete eprouve ici : tout ecart est inconnu jusqu'a mesure. - « Ce qui n'est PAS fait en repartant » : resserrer le compte d'API, le lien inter-sites, le gabarit des deux cotes, la voute hors de son propre site. ANNEXE : les squelettes d'`underlay.yml` et `proxmox-hebergeur.yml` pour un site a un noeud, a remplir depuis la RECONNAISSANCE et jamais de memoire — c'est en recopiant des listes chez chaque tenant qu'elles avaient diverge. Sixieme porte dans la table de routage du README. Les 21 cibles make citees ont ete verifiees comme existantes. prouver 37/37 (P34 : 40 documents declarent leur lecteur), make test 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
229 lines
10 KiB
Markdown
229 lines
10 KiB
Markdown
# Set-OPS — moteur d'écosystèmes numériques souverains
|
|
|
|
**Set-OPS est un moteur Ansible générique** qui permet à un hébergeur de **construire et exploiter un écosystème numérique souverain** — DNS interne, AC/PKI, identité (LDAP + SSO), relais courriel, bases de données, observabilité, applications — sur sa propre grappe **Proxmox**, à partir d'un **plan déclaratif**.
|
|
|
|
Le dépôt est le **moteur** (générique, partageable). Chaque déploiement réel est une **instance** (le plan + l'inventaire d'un hébergeur, dans son propre dépôt). Tu crées la tienne à partir d'un **modèle prêt à déployer** (`exemples/modeles/`).
|
|
|
|
## Par où entrer — selon ce que tu viens faire
|
|
|
|
On n'arrive pas avec un *sujet*, on arrive avec une **situation**. Il y en a cinq :
|
|
|
|
| Ta situation | Ta porte |
|
|
|---|---|
|
|
| « Je veux **monter** mon écosystème sur ma grappe Proxmox » | [`QUICKSTART.md`](QUICKSTART.md) |
|
|
| « Je **prête mon matériel** à quelqu'un qui déploiera dessus » | [`docs/preparer-un-site-hebergeur.md`](docs/preparer-un-site-hebergeur.md) |
|
|
| « Je vais **implanter un tenant existant sur un site neuf** » | [`docs/implanter-un-tenant-sur-un-site.md`](docs/implanter-un-tenant-sur-un-site.md) |
|
|
| « Je viens d'**hériter** d'un écosystème déjà déployé, je dois l'exploiter » | [`wiki/Reprendre-l-écosystème.md`](wiki/Reprendre-l-%C3%A9cosyst%C3%A8me.md) |
|
|
| « Je dois **modifier** le moteur » | [`docs/carte-set-ops.md`](docs/carte-set-ops.md) |
|
|
| « J'**apprends** le métier » | [`wiki/Home.md`](wiki/Home.md) |
|
|
|
|
Et si tu veux d'abord savoir *ce que c'est* : continue simplement ci-dessous.
|
|
|
|
> Le wiki (`wiki/`) est **publié depuis ce dépôt** vers la forge. Une page modifiée dans
|
|
> l'interface de la forge est détruite à la publication suivante : on lit là-bas, on écrit ici.
|
|
|
|
**Souveraineté jusqu'au bout : Set-OPS s'exploite entièrement à la main** — la doc, `make` et le GUI suffisent, **sans aucune IA**. L'outil libère de la dépendance aux géants ; il ne la remplace pas par une dépendance à une IA.
|
|
|
|
---
|
|
|
|
## Mission (la vision derrière l'outil)
|
|
|
|
`Set-OPS` ne se limite plus à l'exploitation : il **définit et construit un écosystème numérique souverain** — une infrastructure interne auto-suffisante, sans dépendance SaaS, décrite en code et pilotée par des registres machine-lisibles qui font office de **source unique de vérité** (`instance/plan/serveurs.yml`, `instance/plan/applications.yml`, `instance/plan/bases-donnees.yml`, `instance/plan/domaines.yml`, `instance/plan/nomenclature.yml`, `docs/dependances-groupes.yml`).
|
|
|
|
Piliers de l'écosystème :
|
|
|
|
- **identité** — machines (PKI / certificats) et utilisateurs (annuaire + SSO) ;
|
|
- **confiance** — autorité de certification interne (ACME) ;
|
|
- **nommage et adressage** — DNS interne et nomenclature dérivable ;
|
|
- **données** — bases relationnelles et cache, avec registre des connexions ;
|
|
- **communication** — relais courriel interne ;
|
|
- **observabilité et supervision** — métriques, journaux, tableaux de bord, supervision active ;
|
|
- **applicatif** — services internes (forge, etc.) et couche web.
|
|
|
|
L'état voulu est **déclaratif et convergent** (appliqué par les groupes Ansible), **souverain** par conception, mais **piloté par l'opérateur** (pas d'auto-remédiation : la boucle n'est pas fermée). Une grande partie est aujourd'hui *définie et validée* avant d'être déployée sur des VM réelles ; le template Debian 13 reste la fondation, pas la finalité.
|
|
|
|
Cadre et règles d'autorité : voir `AGENTS.md` (section « Mission et identité »).
|
|
|
|
## Le plan : on édite, l'inventaire se génère
|
|
|
|
`Set-OPS` se pilote par un **plan**, pas par l'édition directe de l'inventaire.
|
|
`instance/inventories/production/hosts.yml` est **généré** depuis le plan — **ne pas l'éditer à la main**.
|
|
|
|
```
|
|
éditer le PLAN → make instancier (revoir le diff) → make instancier-appliquer → make deployer
|
|
```
|
|
|
|
- **Plan** : `instance/plan/serveurs.yml` (les VM), `instance/plan/applications.yml` (les services et leurs liens), `instance/plan/bases-donnees.yml`, `instance/plan/domaines.yml`, dérivés via `instance/plan/nomenclature.yml`.
|
|
- **GUI** (`make inventaire-ui`) : vues **Serveurs** et **Applications** pour éditer, puis « Appliquer le plan » ; la vue **Inventaire** est en lecture seule.
|
|
- VMID / IP / VLAN sont **dérivés** de la `fonction` ; les groupes d'une VM sont dérivés des applications qui y tournent.
|
|
|
|
Guide complet : **`docs/plan-et-generation.md`**.
|
|
|
|
## Portée transverse
|
|
|
|
Au-delà des piliers ci-dessus, le dépôt couvre des préoccupations transverses, communes à toutes les VM :
|
|
|
|
- templates de VM Proxmox (la fondation) ;
|
|
- groupes de conformité et durcissement ;
|
|
- maintenance ;
|
|
- sauvegardes.
|
|
|
|
## Premier chantier
|
|
|
|
Template Debian 13 Proxmox :
|
|
|
|
```text
|
|
playbooks/modeles_vm/debian13_proxmox_preparer.yml
|
|
playbooks/modeles_vm/debian13_proxmox_verifier.yml
|
|
playbooks/modeles_vm/debian13_proxmox_nettoyer.yml
|
|
```
|
|
|
|
## Principe
|
|
|
|
Le template contient seulement le socle commun.
|
|
|
|
Les services spécialisés seront installés ensuite sur les clones :
|
|
|
|
- NGINX ;
|
|
- PostgreSQL ;
|
|
- MariaDB ;
|
|
- Docker/Podman ;
|
|
- monitoring complet ;
|
|
- applications métier.
|
|
|
|
## Exploitation courante
|
|
|
|
Un `Makefile` fournit les commandes d'exploitation principales.
|
|
|
|
Afficher l'aide :
|
|
|
|
```bash
|
|
make
|
|
```
|
|
|
|
Valider le dépôt :
|
|
|
|
```bash
|
|
make verifier
|
|
```
|
|
|
|
Produire une **preuve de conformité** horodatée (rejoue les preuves du registre des
|
|
affirmations → `docs/audit/preuve-<date>.md` ; mode d'emploi : `docs/audit/README.md`) :
|
|
|
|
```bash
|
|
make prouver
|
|
```
|
|
|
|
Inspecter les inventaires :
|
|
|
|
```bash
|
|
make inventaire
|
|
make hote-afficher HOTE=web-frontal-01
|
|
```
|
|
|
|
Ouvrir l'interface locale de gestion d'inventaire :
|
|
|
|
```bash
|
|
make inventaire-ui
|
|
```
|
|
|
|
Planifier une VM passe désormais par le **plan**, pas par l'édition de l'inventaire :
|
|
|
|
1. déclarer la VM dans `instance/plan/serveurs.yml` (vue **Serveurs** du GUI, ou `make serveurs`) — `fonction`, `etat`, placement ; VMID/IP/VLAN sont dérivés ;
|
|
2. déclarer les services qui y tournent dans `instance/plan/applications.yml` (vue **Applications**) ;
|
|
3. régénérer l'inventaire :
|
|
|
|
```bash
|
|
make instancier # génère + diff sémantique (que va-t-il changer ?)
|
|
make instancier-appliquer # régénère instance/inventories/production/hosts.yml
|
|
```
|
|
|
|
Les anciennes commandes `make hote-planifier` / `hote-ajouter` / `hote-groupes` éditaient l'inventaire **directement** ; elles sont **supplantées** par le plan (l'inventaire est généré, ne pas l'éditer à la main).
|
|
|
|
Chaque groupe opérationnel doit avoir son playbook homonyme dans `playbooks/groupes/`.
|
|
|
|
La conformité normale des VM passe par ces playbooks de groupes. Les rôles de socle et de durcissement sont appliqués par `serveur_debian` et `serveur_durci`, pas par des playbooks de couches séparés.
|
|
|
|
Les groupes opérationnels avec des hôtes, comme `serveur_keycloak` ou `client_pki`, sont validés contre `playbooks/groupes/` par les commandes d'inventaire.
|
|
|
|
Le catalogue des services et intégrations prévus est dans `docs/catalogue-services.md`.
|
|
|
|
Les dépendances causales entre groupes sont dans `docs/dependances-groupes.yml`.
|
|
|
|
Le runbook du DNS interne initial est dans `docs/dns-interne.md`.
|
|
|
|
La nomenclature des noms de VM et des VMID est dans `docs/nomenclature-vm.md`.
|
|
|
|
Créer un clone depuis le modèle Debian 13 via l'API Proxmox :
|
|
|
|
```bash
|
|
make config
|
|
make creer-vm HOTE=web-frontal-01 # VMID/IP/VLAN/passerelle lus dans le plan
|
|
make deployer HOTE=web-frontal-01
|
|
```
|
|
|
|
L'hôte doit d'abord être déclaré dans `instance/plan/serveurs.yml` et l'inventaire régénéré (`make instancier-appliquer`) : `creer-vm` ne prend que `HOTE`, le reste est dérivé.
|
|
|
|
Les valeurs Cloud-Init communes déjà présentes dans le modèle Proxmox sont héritées par les clones.
|
|
|
|
Préparer le golden template Debian 13 Proxmox :
|
|
|
|
```bash
|
|
make preparer-modele
|
|
make verifier-modele
|
|
```
|
|
|
|
Le nettoyage final du template est protégé :
|
|
|
|
```bash
|
|
make nettoyer-modele CONFIRMER=true
|
|
```
|
|
|
|
Déployer ou remettre en conformité une VM Debian clonée depuis le template :
|
|
|
|
```bash
|
|
make deployer HOTE=web-frontal-01
|
|
```
|
|
|
|
Déployer ou remettre en conformité un groupe :
|
|
|
|
```bash
|
|
make deployer-groupe GROUPE=serveur_debian
|
|
```
|
|
|
|
Les déploiements de groupes ciblent automatiquement les hôtes actifs seulement.
|
|
|
|
## Licence
|
|
|
|
Copyright (C) 2026 Daniel Allaire — Chezlepro / Alliance Boréale.
|
|
|
|
Set-OPS est un logiciel **libre** : vous pouvez le redistribuer et/ou le modifier selon les
|
|
termes de la **GNU Affero General Public License** telle que publiée par la Free Software
|
|
Foundation, soit la version 3, soit (à votre choix) toute version ultérieure.
|
|
|
|
Set-OPS est distribué dans l'espoir qu'il sera utile, mais **SANS AUCUNE GARANTIE** ; sans même
|
|
la garantie implicite de QUALITÉ MARCHANDE ou d'ADÉQUATION À UN USAGE PARTICULIER. Voir la GNU
|
|
Affero General Public License pour plus de détails.
|
|
|
|
Le texte intégral fait foi dans le fichier [`LICENSE`](LICENSE) et sur
|
|
<https://www.gnu.org/licenses/agpl-3.0.html>.
|
|
|
|
### Pourquoi l'AGPLv3
|
|
|
|
Libre **et** copyleft fort. Chacun peut utiliser, exécuter, étudier et modifier Set-OPS —
|
|
**y compris commercialement**. En contrepartie, quiconque l'**offre comme service en réseau**
|
|
doit mettre à disposition ses modifications sous la même licence. Cela protège la **souveraineté**
|
|
(pas de captation propriétaire) **sans jamais interdire l'usage commercial** — cohérent avec le
|
|
principe fondateur : *tout est libre*.
|
|
|
|
### Modèle : libre + services
|
|
|
|
Set-OPS est **entièrement libre** ; aucune fonctionnalité n'est réservée ni verrouillée. Les
|
|
revenus, le cas échéant, proviennent de **services autour** du logiciel, jamais de sa fermeture :
|
|
|
|
- support / SLA, **hébergement géré**, formation, intégration, développement sur mesure ;
|
|
- **certification** d'écosystèmes (label *Souverain / Résilient / Exemplaire*).
|
|
|
|
Les artisans et coopératives peuvent exploiter Set-OPS pour **leur propre infrastructure sans
|
|
redevance** : l'usage interne ne déclenche aucune obligation de partage. Le copyleft AGPL ne vise
|
|
que la captation propriétaire (offrir Set-OPS en service fermé sans en partager les évolutions).
|