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 :

```text
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` |
| Icinga 2 | `serveurs_icinga2` | `playbooks/groupes/serveurs_icinga2.yml` | `icinga2` |
| Icinga Web 2 | `serveurs_icingaweb2` | `playbooks/groupes/serveurs_icingaweb2.yml` | `icingaweb2` |
| Icinga BPM | `serveurs_icinga_bpm` | `playbooks/groupes/serveurs_icinga_bpm.yml` | `icinga_bpm` |
| 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` |
| 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` |

## 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 |
| `idm-01` | OpenLDAP, Keycloak |
| `data-01` | PostgreSQL, Redis |
| `obs-01` | Prometheus, Loki, Grafana |
| `mon-01` | 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` | `client_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_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.

2. `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.

3. `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é

4. `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.

5. `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.

6. `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

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

8. `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.

9. `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

10. `serveurs_icinga2`
    - Service central : supervision active, checks, alertes.
    - Intégration à prévoir : `clients_supervision`.
    - Raison : Icinga doit surveiller l'infrastructure déjà instrumentée.

11. `serveurs_icingaweb2`
    - Service central : interface web Icinga.
    - Intégration à prévoir : PostgreSQL, NGINX, Keycloak si retenu.
    - Raison : l'interface dépend du moteur Icinga et de la couche web.

12. `serveurs_icinga_bpm`
    - Service central : vues métiers Icinga.
    - Intégration à prévoir : modèles de dépendances des services.
    - Raison : BPM devient utile quand les premiers services critiques existent.

### Phase 5 - Services applicatifs internes

13. `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.

14. `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é.

15. `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.

16. `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.