Set-OPS/README.md

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.

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 :

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 :

make

Valider le dépôt :

make verifier

Inspecter les inventaires :

make inventaire
make hote-afficher HOTE=web-frontal-01

Ouvrir l'interface locale de gestion d'inventaire :

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 :

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_web_frontal ou client_dns, 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 :

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 :

make preparer-modele
make verifier-modele

Le nettoyage final du template est protégé :

make nettoyer-modele CONFIRMER=true

Déployer ou remettre en conformité une VM Debian clonée depuis le template :

make deployer HOTE=web-frontal-01

Déployer ou remettre en conformité un groupe :

make deployer-groupe GROUPE=serveur_debian

Les déploiements de groupes ciblent automatiquement les hôtes actifs seulement.