Set-OPS/docs/catalogue-services.md

Catalogue des services Chezlepro

Ce document fixe les noms de groupes et de playbooks pour les prochains services.

La règle reste :

groupe opérationnel -> playbooks/groupes/<groupe>.yml

Les playbooks ajoutés maintenant sont des points d'ancrage. Ils ne doivent pas installer un service tant que le rôle correspondant n'existe pas et que ses variables, secrets et prérequis sont documentés.

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 du même domaine opérationnel. La relation stricte est entre groupe et playbook, pas entre groupe et VM.

Services centraux

Service	Groupe	Playbook	Rôle futur
Keycloak	serveurs_keycloak	playbooks/groupes/serveurs_keycloak.yml	keycloak
OpenLDAP	serveurs_openldap	playbooks/groupes/serveurs_openldap.yml	openldap
PostgreSQL	serveurs_postgresql	playbooks/groupes/serveurs_postgresql.yml	postgresql
Loki	serveurs_loki	playbooks/groupes/serveurs_loki.yml	loki
Plateforme Icinga	serveurs_icinga	playbooks/groupes/serveurs_icinga.yml	icinga
Prometheus	serveurs_prometheus	playbooks/groupes/serveurs_prometheus.yml	prometheus
Grafana	serveurs_grafana	playbooks/groupes/serveurs_grafana.yml	grafana
Forgejo	serveurs_forgejo	playbooks/groupes/serveurs_forgejo.yml	forgejo
Sendmail MTA	serveurs_sendmail	playbooks/groupes/serveurs_sendmail.yml	sendmail
step-ca	serveurs_step_ca	playbooks/groupes/serveurs_step_ca.yml	step_ca
PowerDNS	serveurs_powerdns	playbooks/groupes/serveurs_powerdns.yml	serveurs_powerdns
Redis	serveurs_redis	playbooks/groupes/serveurs_redis.yml	redis
NGINX WAF et reverse proxy	serveurs_nginx	playbooks/groupes/serveurs_nginx.yml	nginx
Nextcloud	serveurs_nextcloud	playbooks/groupes/serveurs_nextcloud.yml	nextcloud
Collabora	serveurs_collabora	playbooks/groupes/serveurs_collabora.yml	collabora

Couche applicative web

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

• serveurs_nginx est l'edge : mandataire inverse, terminaison TLS, WAF ; il reçoit le trafic externe et le route.
• serveurs_web_frontaux est la couche présentation web (UI, rendu, assets), servie derrière l'edge.
• serveurs_web_dorsaux 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 serveurs_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 serveurs_web_dorsaux.

Couche	Groupe	Playbook	Rôle futur
Présentation web (frontends)	serveurs_web_frontaux	playbooks/groupes/serveurs_web_frontaux.yml	web_frontaux
Application web (backends)	serveurs_web_dorsaux	playbooks/groupes/serveurs_web_dorsaux.yml	web_dorsaux

Hôtes planifiés : web-frontal-01 et web-frontal-02 dans serveurs_web_frontaux ; web-dorsal-01 dans serveurs_web_dorsaux. Aucun n'est encore actif (à créer puis activer).

Dépendance d'intégration prévue : serveurs_web_frontaux devra publier via serveurs_nginx (règle « tout service exposé en HTTP(S) passe par l'edge »). Cette dépendance n'est pas encore déclarée dans docs/dependances-groupes.yml (les deux groupes sont vides) ; elle sera ajoutée avec le rôle web_frontaux, lorsque des frontaux actifs devront publier via l'edge.

Hôtes planifiés

Hôte	Services
infra-pki-01	step-ca
infra-edge-01	NGINX WAF et reverse proxy
infra-mail-01	Sendmail MTA
infra-dns-01	PowerDNS
idm-01	OpenLDAP, Keycloak
data-01	PostgreSQL, Redis
obs-01	Prometheus, Loki, Grafana
mon-01	Plateforme Icinga : Icinga 2, Icinga Web 2, Icinga BPM
forge-01	Forgejo
collab-01	Nextcloud, Collabora

Intégrations clientes

Intégration	Groupe	Playbook	Rôle futur
Résolution DNS interne	clients_dns	playbooks/groupes/clients_dns.yml	clients_dns
Confiance PKI / ACME	clients_pki	playbooks/groupes/clients_pki.yml	client_pki
Authentification LDAP	clients_ldap	playbooks/groupes/clients_ldap.yml	client_ldap
Supervision Icinga	clients_supervision	playbooks/groupes/clients_supervision.yml	client_supervision
Métriques Prometheus	clients_metriques	playbooks/groupes/clients_metriques.yml	client_metriques
Journaux vers Loki	clients_journaux	playbooks/groupes/clients_journaux.yml	client_journaux
Relais SMTP	clients_smtp	playbooks/groupes/clients_smtp.yml	client_smtp

Ordre d'implémentation recommandé

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

Phase 1 - Fondations transversales

1. serveurs_powerdns

   • Service central : DNS interne autoritaire et/ou résolution interne selon le design retenu.
   • Intégration à prévoir : clients_dns.
   • Raison : les autres intégrations auront besoin de noms stables plutôt que d'adresses IP.

2. serveurs_step_ca

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

3. serveurs_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. serveurs_sendmail

   • Service central : relais SMTP sortant.
   • Intégration à prévoir : clients_smtp.
   • Raison : les notifications, réinitialisations de mot de passe et alertes doivent fonctionner tôt.

Phase 2 - Données et identité

5. serveurs_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. serveurs_openldap

   • Service central : annuaire interne.
   • Intégration à prévoir : clients_ldap.
   • Raison : l'identité Unix et l'annuaire doivent exister avant les intégrations d'authentification avancées.

7. serveurs_keycloak

   • Service central : SSO/OIDC/SAML.
   • Intégration à prévoir : applications web derrière serveurs_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. serveurs_prometheus

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

9. serveurs_loki

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

10. serveurs_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. serveurs_icinga
    • Service central : supervision active, interface web et vues métiers Icinga.
    • Composants prévus : Icinga 2, Icinga Web 2, Icinga BPM.
    • Intégrations à prévoir : clients_supervision, PostgreSQL, NGINX, Keycloak si retenu.
    • Raison : ces composants forment une même capacité de supervision et gagnent à cohabiter sur mon-01 au départ.

Phase 5 - Services applicatifs internes

12. serveurs_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. serveurs_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. serveurs_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. serveurs_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 serveurs_nginx.
• Tout service avec authentification humaine doit prévoir son intégration avec serveurs_keycloak, sauf justification contraire.
• Tout service générant des alertes ou notifications doit prévoir clients_smtp.
• Toute VM de service doit rejoindre clients_metriques, clients_journaux et clients_supervision quand les services centraux correspondants existent.
• Tout service utilisant un certificat interne doit dépendre de clients_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.