Set-OPS-Public/docs/catalogue-services.md

Catalogue des services

Pour qui : le mainteneur — ce que le moteur sait déployer, sous quel nom de groupe, et jusqu'où c'est éprouvé.

Ce document nomme les services que le moteur sait déployer, et la règle qui lie un groupe à son playbook :

groupe opérationnel -> playbooks/groupes/<groupe>.yml     (P04 le prouve)

Le rôle porte le nom du groupe : serveur_keycloak, client_pki. Il n'y a pas de nom court séparé. Seule exception, serveur_durci : un groupe dont le playbook compose dix rôles de durcissement, et dans cet ordre — hardening_packages, sysctl_hardening, core_dumps, unattended_upgrades, apparmor, auditd, fail2ban_ssh, journald, ssh_hardening, nftables_baseline — plutôt qu'un rôle homonyme.

La nomenclature des VM et des VMID est documentée dans docs/nomenclature-vm.md.

Un service central peut partager un hôte avec d'autres services de la même fonction opérationnelle (plusieurs applications par VM). La relation stricte est entre groupe et playbook, pas entre groupe et VM.

Modèle à jour : chaque service est une application (instance/plan/applications.yml). Voir docs/plan-et-generation.md.

État d'implémentation des rôles

Mise à jour (2026-09-06), vérifiée groupe par groupe contre roles/ et playbooks/groupes/. Les 40 groupes serveur_* / client_* du tableau ci-dessous ont tous leur rôle et leur playbook — 40 fichiers dans playbooks/groupes/, 40 noms distincts cités ici. Aucune capacité annoncée n'est un point d'ancrage vide.

(Le chiffre lu ici jusqu'au 2026-09-06 était 29, mesuré le 2026-08-18 : le catalogue a grandi de onze groupes — site, runners, résolveur, artefacts — sans que la phrase suive. C'est ce genre d'écart que la preuve P57 garde désormais.)

Éprouvés sur VM réelles. Le 2026-08-13, la flotte a été reconstruite depuis zéro — 43 groupes, 0 échec, 37 minutes. L'épreuve a été rejouée deux fois le 2026-09-02, sur un dépôt qui avait beaucoup bougé depuis : 15/15 hôtes puis 14/14, 0 échec, make valider à 0 échec sur 13 hôtes. Ce n'est donc plus « du code validé » : chaque rôle a repris une machine nue et l'a menée à l'état voulu — et il l'a refait après coup.

Ce que la reconstruction couvre, par capacité :

Capacité	Rôles	Ce qui est éprouvé
Socle et durcissement	serveur_debian, serveur_durci (dix rôles composés)	clone du gabarit doré → machine conforme
Confiance	serveur_step_ca, client_pki	mTLS avec SAN dérivés du plan, renouvellement
Noms	serveur_powerdns, client_resolveur	autoritaire interne + résolveur local
Identité	serveur_openldap, serveur_keycloak	LDAPS, SSO OIDC, fédération LDAP automatisée (tasks/federation-ldap.yml), exposé par le plan (auth.<domaine>)
Passerelle SSO	serveur_oauth2_proxy	SSO devant une app sans OIDC natif (éprouvé sur Icinga Web 2)
Données	serveur_postgresql, serveur_redis	bases et comptes dérivés du registre, TLS verify-full
Courriel	serveur_postfix, serveur_dovecot, serveur_rspamd	SMTP→LDAP→LMTP→IMAP, antispam, DKIM
Edge	serveur_nginx	terminaison TLS, publication des expose: du plan
Observabilité	serveur_prometheus, serveur_loki, serveur_grafana	métriques, journaux, tableaux sous SSO
Supervision	serveur_icinga, serveur_icingaweb2	Icinga 2 + IcingaDB + Web 2 + BPM, au SSO
Forge	serveur_forgejo	Git + PostgreSQL + SSO OIDC
Collaboration	serveur_nextcloud, serveur_collabora (natif, plus de conteneur)	déployés par la reconstruction, base et client OIDC dérivés du plan — usage (dépôt de fichier, édition partagée) non consigné comme preuve
Plateforme webapp	serveur_web_frontal, serveur_web_dorsal	sites statiques et webapps natives (venv + systemd + nginx), zéro conteneur
Sauvegardes	serveur_backup, client_backup	restic hors-nœud, restauration éprouvée (2026-08-12 : la donnée revient)
Exploitation	serveur_ops	le poste depuis lequel l'ecosysteme se reconstruit : Ansible epingle, genome clone depuis sa propre forge, cle SSH propre — sans la voute ni son mot de passe
Source d'artefacts	serveur_artefacts, client_artefacts	deux faces sur un seul service. Cache apt (apt-cacher-ng) : les paquets viennent de chez soi, pas de six serveurs etrangers — mode hors ligne pour prouver ce que le cache detient vraiment. Et depot des binaires directs (LocalDirs) : Forgejo, Keycloak, Nextcloud, oauth2-proxy ne vivent dans aucun depot apt et etaient tires d'Internet par CHAQUE runner — 570 Mo mesures le 2026-09-12. Meme port, meme regle de pare-feu, garde P70
Runner de tenant	serveur_ops_tenant	le pouvoir de configurer : la voute de l'ecosysteme, deposee CHIFFREE sur son propre runner. Sans elle un runner calcule son inventaire et ne peut rien en faire — chaque role qui demande un secret echoue sur son assertion. N'atteint ni la fabric ni la frontiere
Runner de site	serveur_ops_site	le pouvoir de materialiser : creer et detruire des VM sur la fabric. Detient la voute du SITE, chiffree, et n'entre JAMAIS chez un tenant — reserve a l'ecosysteme de l'hebergeur
Resolution	serveur_resolveur, client_resolveur	UN resolveur recursif par tenant (Unbound), qui recurse depuis la racine et delegue la zone souveraine a PowerDNS. Remplace les N demons locaux d'avant le 2026-08-24
Cache du site	serveur_cache_site	designe LE cache que les ecosystemes voisins prennent comme amont : Debian telecharge une fois pour toute la fabric, et le cache ne voit que des requetes agregees. Reserve a l'ecosysteme de l'hebergeur
Forge du genome du site	serveur_forge_site	designe LA forge dont les ecosystemes de ce site se reproduisent (D-81), et l'ouvre a eux. Marqueur : serveur_forgejo installe.
Resolveur du site	serveur_resolveur_site	designe LE resolveur que les ecosystemes de ce site interrogent tant qu'ils n'ont pas le leur. Marqueur : serveur_resolveur installe.
Depot de sauvegarde du site	serveur_backup_site	designe LE depot ou les ecosystemes de ce site posent leur etat tant qu'ils n'ont pas le leur. Marqueur : serveur_backup installe.
Agents de flotte	client_metrique, client_journal, client_smtp, client_sante	collecte, relais et rapport de santé sur toute la flotte

Rôles retirés (2026-07-04, supersédés ou hors conception) : serveur_sendmail (→ Postfix), client_dns (→ plancher /etc/hosts + client_resolveur), client_ldap (login LDAP au niveau OS, hors design).

Ce que « éprouvé » ne dit pas. La reconstruction prouve que le moteur mène une machine nue à l'état voulu. Elle ne dit rien de la tenue d'un service sous charge, ni de sa mise à jour dans le temps — deux questions distinctes, et non traitées ici.

Services centraux

Le playbook est toujours playbooks/groupes/<groupe>.yml, et le rôle porte le nom du groupe : la table ne répète donc ni l'un ni l'autre.

Service	Groupe
Socle Debian	serveur_debian
Durcissement (compose onze rôles)	serveur_durci
step-ca (AC interne + ACME)	serveur_step_ca
PowerDNS (autoritaire interne)	serveur_powerdns
OpenLDAP (source de vérité des identités)	serveur_openldap
Keycloak (SSO OIDC, fédéré à l'annuaire)	serveur_keycloak
oauth2-proxy (SSO devant une app sans OIDC natif)	serveur_oauth2_proxy
PostgreSQL	serveur_postgresql
Redis	serveur_redis
NGINX — edge : TLS, mandataire inverse, WAF	serveur_nginx
Postfix (MTA)	serveur_postfix
Dovecot (mailstore IMAP/LMTP)	serveur_dovecot
rspamd (antispam, DKIM)	serveur_rspamd
Prometheus	serveur_prometheus
Loki	serveur_loki
Grafana	serveur_grafana
Icinga 2 + IcingaDB	serveur_icinga
Icinga Web 2 (+ module BPM)	serveur_icingaweb2
Forgejo	serveur_forgejo
Nextcloud	serveur_nextcloud
Collabora	serveur_collabora
Dépôt de sauvegarde restic	serveur_backup

Couche applicative web

La couche applicative web est distincte de l'edge serveur_nginx :

• serveur_nginx est l'edge : mandataire inverse, terminaison TLS, WAF ; il reçoit le trafic externe et le route.
• serveur_web_frontal est la couche présentation web (UI, rendu, assets), servie derrière l'edge.
• serveur_web_dorsal est la couche application web (API, traitement), consommée par les frontaux.

Le « web » de ces deux groupes est implicite par leur position derrière serveur_nginx. Le jour où un service dorsal n'est pas web (worker batch, file, démon), créer un groupe dédié plutôt que d'élargir serveur_web_dorsal.

Couche	Groupe	Ce que le rôle pose
Présentation web (sites statiques)	serveur_web_frontal	nginx + contenu tiré d'un dépôt git souverain (Forgejo), en-têtes de sécurité
Application web (webapps dynamiques)	serveur_web_dorsal	runtime + service systemd + nginx local — venv/paquets, zéro conteneur

Les deux rôles sont codifiés depuis les spikes du 2026-07-05 (site Alliance Boréale pour le frontal ; monregistraire — FastAPI + uvicorn + SQLite — pour le dorsal), et web-frontal-01 / web-dorsal-01 sont actifs dans le plan de référence.

L'exposition ne passe pas par une dépendance de groupe mais par le plan : le champ expose: d'une application fait dériver le vhost de l'edge, les SAN de son certificat et le plancher /etc/hosts. Une seule ligne au plan, aucune recopie.

Lacune nommée : la dépendance causale serveur_web_frontal → serveur_nginx n'est toujours pas déclarée dans docs/dependances-groupes.yml. Le déploiement d'un frontal n'est donc pas refusé quand l'edge est absent — il aboutit à un site que rien ne publie. À déclarer.

Hôtes du plan de référence

Les quatorze hôtes de l'écosystème de référence, tous à l'état actif, tels que les déclare instance/plan/applications.yml. Un modèle plus petit en porte moins : cette table décrit une répartition éprouvée, pas un minimum requis.

Hôte	Applications
infra-pki-01	step-ca
infra-dns-01	PowerDNS
infra-edge-01	NGINX (edge)
edge-mta-01	Postfix, rspamd
infra-mail-01	Dovecot
idm-01	OpenLDAP, Keycloak
data-sql-01	PostgreSQL, Redis
obs-01	Prometheus, Loki, Grafana
mon-01	Icinga 2, Icinga Web 2, oauth2-proxy
forge-01	Forgejo
collab-01	Nextcloud, Collabora
web-frontal-01	site statique
web-dorsal-01	webapp native
ops-01	runner de l'écosystème (serveur_ops, serveur_ops_tenant)

ops-01 manquait de cette table jusqu'au 2026-09-06, alors que le compte annoncé ci-dessus le comptait : quatorze hôtes, treize lignes. C'est le nœud depuis lequel l'écosystème se reconstruit sans le poste de l'exploitant — la pièce la moins visible et la plus structurante de la reconstruction autonome.

Le courriel occupe deux hôtes, et ce n'est pas un détail de taille : edge-mta-01 porte ce qui parle à l'extérieur (Postfix, rspamd), infra-mail-01 ce qui détient les boîtes (Dovecot). La coupure suit l'exposition, pas le logiciel.

Intégrations clientes

Intégration	Groupe	Posée sur
Confiance PKI / ACME	client_pki	tout hôte (universelle)
Métriques Prometheus	client_metrique	tout hôte (universelle)
Journaux vers Loki	client_journal	tout hôte (universelle)
Résolution locale (Unbound)	client_resolveur	tout hôte (universelle)
Source d'artefacts (cache apt)	client_artefacts	tout hôte (universelle)
Santé du nœud (unités en échec)	client_sante	tout hôte (universelle)
Relais SMTP	client_smtp	déclaré par hôte, dans le plan
Sauvegarde restic	client_backup	déclaré par hôte — obligatoire pour tout détenteur d'état (P36)

Universelle ne veut pas dire recopiée : une intégration marquée universelle: true dans son meta/ est posée sur chaque hôte par dérivation, avec l'exemption dérivée du service rendu (P26 : un hôte n'est pas client de ce qu'il sert). Aucune ligne à écrire dans le plan.

client_supervision n'existe pas. Ce catalogue l'a longtemps annoncé ; il n'a jamais eu ni rôle ni playbook, et rien ne l'attend. La supervision s'exerce sans agent sur les hôtes : contrôles actifs depuis le cœur (hostalive) et résultats passifs poussés par l'API par celui qui détient la vérité de terrain. Le nom est retiré plutôt que réservé : une case vide dans un catalogue se lit comme une promesse.

Qui rapporte l'état des sauvegardes a changé le 2026-09-02. Tant que le dépôt vivait dans l'écosystème, il était le seul à voir ce qui était réellement arrivé, et il rapportait pour tout le monde. Depuis que les écosystèmes déposent chez leur hébergeur — qui héberge des octets chiffrés côté client et ne peut pas les juger — chaque nœud vérifie son propre dépôt distant et le rapporte lui-même. La vérification suit la clé, pas le stockage. serveur_icinga se branche sur les deux modèles ; backup-01 a été retiré du plan de Chezlepro, sa VM détruite.

Ordre de déploiement — le raisonnement

L'ordre exécutable n'est pas ici. Il vit dans docs/couches-deploiement.yml et docs/dependances-groupes.yml, que P08 prouve cohérents (41 groupes classés, aucun cycle, aucune arête en arrière) et que make reconstruire suit. Ce qui suit en est le raisonnement, utile pour comprendre pourquoi cet ordre-là — et pour placer un service nouveau. Les phases sont franchies : les « intégrations à prévoir » ci-dessous sont posées.

L'ordre ci-dessous privilégie les dépendances structurantes avant les applications.

Ce raisonnement a été révisé le 2026-09-09 sur un point : l'observabilité et la supervision ne viennent plus en phases 3 et 4, mais juste après la PKI — donc avant presque tout ce qu'elles surveillent. On n'allume pas la lumière une fois la maison finie. Une reconstruction depuis zéro est précisément le moment où l'on a le plus besoin de voir. Les phases ci-dessous gardent leur numérotation, qui dit une parenté logique ; l'ordre exécutable, lui, est dans docs/couches-deploiement.yml (D-86).

Ce qui reste tard, et à dessein : la console (icingaweb2, oauth2_proxy), qui réclame LDAP et Keycloak. L'interface humaine peut attendre ; la mesure, non.

Phase 1 - Fondations transversales

1. serveur_powerdns

   • Service central : DNS interne autoritaire de la zone souveraine. La résolution est une couche distincte (serveur_resolveur / client_resolveur, Unbound), et le plancher /etc/hosts posé par hosts_statiques précède les deux — c'est lui qui permet à l'écosystème de se résoudre DNS éteint. Trois couches, pas un choix de design (docs/dns-interne.md).
   • Raison : les autres intégrations auront besoin de noms stables plutôt que d'adresses IP.

2. serveur_step_ca

   • Service central : autorité de certification interne et ACME.
   • Intégration à prévoir : client_pki.
   • Raison : les autres services auront besoin de certificats fiables avant d'être exposés proprement.

3. serveur_nginx

   • Service central : reverse proxy, terminaison TLS, publication HTTP(S), WAF.
   • Intégration à prévoir : publication des services HTTP derrière le proxy.
   • Raison : plusieurs services seront consommés par navigateur ou API et doivent passer par un point d'entrée cohérent.

4. serveur_postfix

   • Service central : MTA (courriel entrant + sortant interne) + relais SMTP.
   • Intégration à prévoir : client_smtp.
   • Raison : les notifications, réinitialisations de mot de passe et alertes doivent fonctionner tôt.

Phase 2 - Données et identité

5. serveur_postgresql

   • Service central : base de données relationnelle partagée.
   • Intégration à prévoir : bases dédiées par application, comptes applicatifs et sauvegardes.
   • Raison : Keycloak, Grafana, Icinga Web 2, Forgejo et Nextcloud peuvent dépendre de PostgreSQL.

6. serveur_openldap

   • Service central : annuaire interne (source de vérité des identités).
   • Consommateurs : Keycloak (fédération/SSO), courriel (Postfix/Dovecot), apps.
   • Raison : l'annuaire doit exister avant l'identité fédérée et le courriel.

7. serveur_keycloak

   • Service central : SSO/OIDC/SAML.
   • Intégration à prévoir : applications web derrière serveur_nginx.
   • Raison : les applications devraient être branchées au SSO dès leur arrivée plutôt qu'après coup.

Phase 3 - Observabilité minimale

8. serveur_prometheus

   • Service central : métriques.
   • Intégration à prévoir : client_metrique.
   • Raison : les prochains services doivent être mesurables dès leur déploiement.

9. serveur_loki

   • Service central : journaux centralisés.
   • Intégration à prévoir : client_journal.
   • Raison : les journaux centralisés accélèrent le diagnostic des services suivants.

10. serveur_grafana

• Service central : tableaux de bord.
• Intégration à prévoir : datasources Prometheus et Loki, authentification Keycloak.
• Raison : Grafana consolide les métriques et journaux après leur mise en place.

Phase 4 - Supervision active

11. serveur_icinga, puis serveur_icingaweb2
    • Service central : supervision active, interface web et vues métiers (BPM).
    • Intégrations : PostgreSQL, NGINX, et le SSO via serveur_oauth2_proxy — Icinga Web 2 n'a pas d'OIDC natif.
    • Rien à poser sur les hôtes supervisés : contrôles actifs depuis le cœur, résultats passifs poussés par l'API.
    • Raison : ces composants forment une même capacité de supervision et cohabitent sur mon-01.

Phase 5 - Services applicatifs internes

12. serveur_redis

    • Service central : cache et files internes.
    • Intégration à prévoir : Nextcloud et autres applications qui en ont besoin.
    • Raison : Redis est une dépendance applicative, pas une fondation globale.

13. serveur_forgejo

    • Service central : forge Git.
    • Intégration à prévoir : PostgreSQL, NGINX, Keycloak, SMTP, sauvegardes.
    • Raison : la forge devient plus utile après SSO, TLS, SMTP et observabilité.

14. serveur_nextcloud

    • Service central : collaboration fichiers.
    • Intégration à prévoir : PostgreSQL, Redis, NGINX, Keycloak, SMTP, sauvegardes.
    • Raison : Nextcloud dépend de plusieurs fondations et doit arriver après elles.

15. serveur_collabora

    • Service central : édition documentaire en ligne.
    • Intégration à prévoir : Nextcloud, NGINX, certificats.
    • Raison : Collabora est une extension de Nextcloud et doit venir après lui.

Règles d'intégration

• Tout service exposé en HTTP(S) doit prévoir son intégration avec serveur_nginx.
• Tout service avec authentification humaine doit prévoir son intégration avec serveur_keycloak, sauf justification contraire.
• Tout service générant des alertes ou notifications doit prévoir client_smtp.
• Toute VM de service rejoint client_pki, client_metrique, client_journal, client_resolveur et client_artefacts — par dérivation, sans rien écrire (les cinq intégrations marquées universelle: true, P26). La supervision, elle, ne pose rien sur l'hôte.
• Tout hôte qui détient de l'état doit porter client_backup (P36 le refuse sinon).
• Tout service utilisant un certificat interne doit dépendre de client_pki.
• Tout rôle serveur doit documenter ses ports, secrets, sauvegardes, dépendances et groupes clients associés.

Les groupes clients peuvent être ajoutés aux VM existantes quand le service central correspondant est réellement disponible.

Dépendances causales

Les dépendances exécutables sont déclarées dans docs/dependances-groupes.yml.

Le runbook DNS initial est dans docs/dns-interne.md.

Ce fichier sert à deux usages :

• bloquer le déploiement d'un groupe tant que ses prérequis actifs ne sont pas présents ;
• fournir une source exploitable pour les futurs modèles de supervision.

Un hôte peut porter un groupe client à l'état planifié. Le déploiement est refusé tant que le groupe serveur requis n'a pas au moins un hôte actif.