Daniel Allaire
e006dee693
Supprimés (supersédés / hors-conception) : serveur_sendmail (→ Postfix), client_dns (→ plancher + client_unbound), client_ldap (login LDAP OS, hors design). Rôles + playbooks de groupe retirés. Nettoyage des références : - dependances-groupes.yml : entrées client_dns/client_ldap retirées + entrées mortes des scaffoldings (nextcloud/collabora/client_supervision) ; deps périmées corrigées (client_smtp → serveur_postfix ; serveur_keycloak → serveur_postgresql, la raison parlait à tort de Nextcloud). - 6 modèles d'exemple : app mail serveur_sendmail → serveur_postfix. - README, AGENTS : listes/glossaire nettoyés. - catalogue-services : listes, tables, roadmap ; note « rôles retirés ». - nomenclature-vm : infra-mail-01 → serveur_dovecot (était faux). - courriel-conception, dns-interne (re-ciblé client_unbound), pouvoirs, intrants, READMEs (client_smtp/forgejo/openldap/unbound). ansible-lint : 0 échec (366 fichiers). instancier OK. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
206 lines
8.8 KiB
Markdown
206 lines
8.8 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/`).
|
|
|
|
> 👉 **Tu débarques avec une grappe Proxmox et tu veux monter ton écosystème ? Commence par [`QUICKSTART.md`](QUICKSTART.md).**
|
|
|
|
**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
|
|
```
|
|
|
|
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).
|