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>
make applications-bootstrap : un groupe serveurs_* (hors socle debian/
durcis) sur un hote = une application. Les entrees existantes (pg-principal,
forge avec port/expose/requiert) sont preservees ; le reste est complete
depuis les appartenances de groupes de l'inventaire.
Resultat : 18 applications couvrant tous les services (multi-applis par VM
preservee : data-01 = postgresql+redis, obs-01 = grafana+loki+prometheus...).
Permettra au generateur de Phase 3 de deriver les groupes -> diff vide.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
L'application porte tous ses liens (groupe=capacite, hote=VM, port,
requiert, expose). L'exposition DNS quitte docs/domaines.yml et vit sur
l'application via 'expose' ; domaines.yml ne decrit plus que les zones.
- inventory_rules : expositions_des_applications + domaine_parent ;
valider_applications valide requiert / expose / port.
- serveurs_nginx derive ses vhosts des applications (expose + edge),
resolvant application -> hote -> IP (role + template reecrits).
- filter plugin : expose la nouvelle regle a Ansible.
- CLI : applications.py --port/--requiert/--expose ; domaines.py affiche
les expositions derivees des applications.
- GUI : champs Port/Requiert/Expose sur la fiche Application (persistes ;
corrige la perte de champs a la sauvegarde) ; l'API expose les domaines.
Le groupe n'est plus une cible de liaison, seulement une capacite.
Renommage nomenclature.domaines -> fonctions : Phase 1b. Generation de
l'inventaire depuis le plan : Phase 3.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
