Chezlepro/Set-OPS
Archived
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
This repository has been archived on 2026-06-26. You can view files and clone it, but cannot push or open issues or pull requests.
Set-OPS/docs/catalogue-services.md
Daniel Allaire 8f6de3ebe2 Construire l'ecosysteme de services et outiller l'inventaire 
Registres (source unique):
- docs/nomenclature.yml: domaines, VMID, plan d'adressage 10.1.0.0/16 segmente.
- docs/bases-donnees.yml: bases applicatives (1 appli -> 1 base -> 1 owner -> 1 DSN).

Roles de service:
- Reseau/edge/PKI/mail: nginx, step_ca, sendmail.
- Donnees/identite: postgresql (consommateur du registre BD), redis, openldap, keycloak.
- Observabilite: prometheus, loki, grafana.
- Supervision: icinga (coeur; Icinga Web 2 differe). Forge: forgejo.

Integrations clientes:
- clients_metriques, clients_journaux, clients_pki, clients_ldap, clients_smtp.

Inventaire et outillage:
- make inventaire-ui: refonte (cartes, theme sombre, onglets, vue Chaine VM->groupes->
  playbooks->roles), saisie du provisioning, auto-proposition depuis la nomenclature,
  deploiement securise (verifier/deployer, jeton anti-CSRF, verrou, mot de passe vault),
  robustesse reseau (connexions fermees, favicon).
- Makefile: cible verifier-deploiement; detection d'un group_vars de production chiffre.
- Scission serveurs_web -> serveurs_web_frontaux/dorsaux; migration de l'adressage vers
  10.1.x; retrait des hotes de test; planification des hotes; requirements.yml.

Chaque role valide en --syntax-check et ansible-lint (profil production).
Secrets references depuis Ansible Vault (jamais en clair); roles non testes live.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 18:06:11 -04:00

195 lines
10 KiB
Markdown
Raw Permalink Blame History

# 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` |
| 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.
Reference in a new issue View git blame Copy permalink