Commit graph

6 commits

Author SHA1 Message Date
17f65efb18 Decouplage moteur/instance Phase 2a : sortir le plan
Les 5 registres (serveurs/applications/bases-donnees/domaines/nomenclature)
quittent docs/ pour instance/plan/. Localisation :
- scripts : variable d'env SETOPS_INSTANCE (defaut <depot>/instance) ;
- roles/playbooks : variable setops_plan_dir (group_vars d'instance).

docs/ ne garde que les guides .md + dependances-groupes.yml (moteur).
.ansible-lint exclut instance/plan/ (registres de donnees).

Non destructif : diff vide, ansible-lint 0 echec, include_vars via
setops_plan_dir teste. (Phase 2b : l'inventaire.)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-24 09:10:49 -04:00
ca0f95da28 Mettre les noms de roles et playbooks au singulier
serveurs_* -> serveur_, clients_ -> client_, suffixes pluriels au
singulier (serveur_web_dorsal/frontal, client_metrique, client_journal).

Renommage par tokens exacts : repertoires de roles, playbooks de groupes,
group_vars, variables internes des roles (serveur_nginx_*, conformite
ansible-lint), groupes du plan, constantes de code, docs. Faux-amis
preserves (serveurs_bd, scripts/serveurs.py, fonctions Python). Groupes
d'etat gardes au pluriel (hotes_actifs/planifies, modeles_vm).

Valide : ansible-lint 0 echec (0 var-naming), diff vide de la generation,
node --check, tous les registres. Ajout de .ansible-lint excluant docs/
(registres de donnees, pas du contenu Ansible).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-23 23:18:52 -04:00
abd6395a13 Faire de l'application une entite de premiere classe (BD multi-portee)
Une VM peut porter plusieurs applications ; c'est l'application, pas l'hote,
a laquelle une base se lie via son DSN.

- docs/applications.yml : nouveau registre application -> groupe, hote.
- docs/bases-donnees.yml : champ 'portee' (application|groupe|hote, defaut
  groupe). Une application A (groupe G, hote H) recoit les bases ou
  (portee=application ET consommateur=A) OU (portee=groupe ET consommateur=G)
  OU (portee=hote ET consommateur=H). Plusieurs DSN par application.
- inventory_rules.py : charger/valider_applications, applications_de_hote,
  bases_de_application, PORTEES_BD ; valider_bases croise portee=application
  avec le registre des applications.
- CLI : scripts/applications.py + bases_donnees.py --portee ; cibles make
  applications / applications-verifier ; integre a inventaire-verifier.
- GUI : vue Applications (CRUD), portee + consommateur dynamique dans Bases,
  vue Chaine par application (DSN resolus par hote).
- filter_plugins/registres.py : meme regle de resolution exposee a Ansible
  (source unique). Playbooks web_dorsaux/web_frontaux iterent sur les
  applications de l'hote (scaffold ; deploiement applicatif s'y insere).

Services en grappe (keycloak/icingadb/forgejo) restent en portee groupe.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-23 13:38:30 -04:00
33b1933a6d Rendre explicites les bindings appli<->BD (consommateur, multi-BD)
Modele:
- Chaque base porte un "consommateur" (le groupe applicatif qui l'utilise) et un
  "usage" (principale/cache...). Une application peut avoir plusieurs bases.
- Le binding appli<->base n'est plus une convention de nom mais un champ gere.

Regles partagees (inventory_rules): consommateur requis a la validation;
helper bases_du_groupe(registre, groupe).

GUI (make inventaire-ui):
- Vue "Bases": menu deroulant Consommateur + champ Usage par base -> on fait les
  connexions ici; plusieurs bases par appli supportees.
- Vue "Chaine" detaillee: chaque groupe affiche ses roles ET ses bases avec leur
  chaine de connexion (appli -> base -> serveur de BD -> hote).

CLI (bases_donnees.py): ajouter-base --consommateur --usage; lister affiche
"base <- consommateur (usage): DSN".

Roles serveurs_keycloak / serveurs_forgejo / serveurs_icinga: resolution de leur
base par consommateur (groupe), plus de cle codee en dur.

Valide: ansible-lint (roles), node --check (JS), round-trips GUI et CLI,
multi-BD verifie (serveurs_web_dorsaux -> 2 bases), make inventaire-verifier.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 19:44:05 -04:00
25d0c73275 Gerer les bases de donnees par chaines de connexion (GUI + CLI)
Registre multi-serveurs (docs/bases-donnees.yml):
- Section serveurs_bd: serveurs de BD nommes (type/hote/port/groupe).
- Chaque base reference un serveur nomme; la chaine de connexion derivee fait
  le lien appli <-> BD. L'hote n'est plus code en dur dans les roles applicatifs.

Regles partagees (scripts/inventory_rules.py):
- charger_bases_donnees, valider_bases, chaine_connexion (GUI et CLI s'appuient dessus).

GUI (make inventaire-ui):
- Vue "Bases": serveurs, bases et chaines de connexion (mot de passe masque),
  gestion complete (ajout/edition/retrait), endpoint POST /api/bases (valide, jeton).

CLI (scripts/bases_donnees.py):
- lister/verifier/ajouter-serveur/ajouter-base/retirer-*; cibles make bases et
  bases-verifier; registre valide dans make inventaire-verifier.

Roles migres: serveurs_postgresql (filtre par serveur nomme relie a son groupe),
serveurs_keycloak / serveurs_forgejo / serveurs_icinga (hote et port depuis le registre).

Valide: ansible-lint (roles migres), node --check (JS), round-trips GUI et CLI.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 19:14:12 -04:00
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