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> |
||
|---|---|---|
| .. | ||
| clients_dns.yml | ||
| clients_journaux.yml | ||
| clients_ldap.yml | ||
| clients_metriques.yml | ||
| clients_pki.yml | ||
| clients_smtp.yml | ||
| clients_supervision.yml | ||
| serveurs_collabora.yml | ||
| serveurs_debian.yml | ||
| serveurs_durcis.yml | ||
| serveurs_forgejo.yml | ||
| serveurs_grafana.yml | ||
| serveurs_icinga.yml | ||
| serveurs_keycloak.yml | ||
| serveurs_loki.yml | ||
| serveurs_nextcloud.yml | ||
| serveurs_nginx.yml | ||
| serveurs_openldap.yml | ||
| serveurs_postgresql.yml | ||
| serveurs_powerdns.yml | ||
| serveurs_prometheus.yml | ||
| serveurs_redis.yml | ||
| serveurs_sendmail.yml | ||
| serveurs_step_ca.yml | ||
| serveurs_web_dorsaux.yml | ||
| serveurs_web_frontaux.yml | ||