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>
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>
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>
