# 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 : ```text groupe opérationnel -> playbooks/groupes/.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.`) | | 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/.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.