# 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_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 : ```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.