make instancier genere hosts.genere.yml (gitignore) depuis le plan
(serveurs.yml + applications.yml + nomenclature.yml) et compare
SEMANTIQUEMENT a l'inventaire actuel via ansible-inventory --list.
- scripts/instancier.py : generer + comparer (host vars derives, groupes
derives = socle + services (applications) + integrations (clients_*) + etat).
- serveurs.py bootstrap capture les clients_* comme 'integrations' par VM.
- inventory_rules : valide 'integrations'.
Resultat : DIFF VIDE -- le plan reproduit exactement les 13 hotes. La
bascule (hosts.yml genere + UI editant le plan) reste NON effectuee :
elle attend une validation explicite.
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>
Leve la collision de nom entre les familles fonctionnelles de la
nomenclature (infra-pki, web-frontal...) et les domaines DNS.
- docs/nomenclature.yml : cle domaines -> fonctions (+ commentaires).
- inventory_gui.py : domaineDe/infoDomaine -> fonctionDe/infoFonction,
nomenclature.fonctions, libelles et placeholder alignes.
- inventory_rules.py : docstring.
Aucun role ni inventaire impacte (nomenclature lue a la planification).
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>
serveurs_nginx derive ses vhosts de docs/domaines.yml (bloc exposition) :
pour chaque exposition web ciblant cet edge, un server block est genere
(expositions.conf.j2). Amont = entree 'amont' explicite, sinon
http://<IP interne de la cible>:<port> resolu depuis l'inventaire. Une
exposition non resolvable (cible sans hote actif, ou sans port) est listee
mais non publiee.
- defaults : serveurs_nginx_groupe (edge cible), serveurs_nginx_publier_expositions.
- Les sites declares a la main coexistent.
- Ajout du port 3000 a l'exposition forge.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Registre declaratif docs/domaines.yml pour la publication externe des
hostnames, symetrique de docs/bases-donnees.yml. Modele d'autorite :
primaire cache + secondaires. Le bloc « exposition » est le binding
nom public -> service interne (cible) -> edge, destine a trois
consommateurs (zone publique, vhosts nginx, ACME).
- inventory_rules.py : charger_domaines, valider_domaines,
fqdn_exposition, expositions_du_groupe, AUTORITES_DNS.
- scripts/domaines.py : CLI miroir (lister / verifier).
- Makefile : cibles domaines / domaines-verifier + validation dans
inventaire-verifier.
Premiere entree reelle : forge.alliance-boreale.ca -> serveurs_forgejo.
Secondaires, mail et DNSSEC laisses a renseigner (structurel, pas
encore operationnel ; l'interne chezlepro.internal n'est pas touche).
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>
