Commit graph

13 commits

Author SHA1 Message Date
1aa3da8de5 Corriger l'erreur de syntaxe JS qui cassait tout le GUI
dessinerServeurs contenait une apostrophe mal echappee (l\\'inventaire)
qui, une fois rendue, terminait prematurement la chaine JS : une seule
erreur de syntaxe fait tomber tout le script -> page inutilisable.
Remplace par l'apostrophe typographique (sans echappement).

Garde-fou : scripts/verifier_gui.py extrait le JS embarque et le passe a
`node --check` (saute si node absent), integre a make inventaire-verifier.
py_compile ne voyait pas le JS ; ce trou est desormais ferme.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-23 21:28:52 -04:00
1c96fb0acc Phase 2 : le serveur (VM) entre dans le plan (lecture seule)
Registre docs/serveurs.yml (VM = fonction + etat + placement/taille),
bootstrape depuis l'inventaire qui reste autorite. La derivation
nomenclature (fonction+rang -> VMID/IP/VLAN/passerelle) est portee en
Python (source unique) et reconciliee avec l'inventaire.

- inventory_rules : deriver_nomenclature, fonction_seq, charger/valider/
  reconcilier_serveur.
- scripts/serveurs.py : lister / verifier / bootstrap + cibles make,
  integre a inventaire-verifier.
- GUI : vue Serveurs (lecture seule) plan + derive + statut reconciliation.

Bootstrap : 13 serveurs, tous reconcilies (le derive reproduit exactement
l'inventaire -> diff vide atteignable en Phase 3).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-23 20:44:08 -04:00
dd664dcddb Phase 2 (debut) : vue Chaine holistique
La vue Chaine de make inventaire-ui montre, par application, l'ensemble
de ses liens (expose, requiert, bases/DSN, port) : on voit comment VM,
applications, bases et domaines s'articulent.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-23 20:22:33 -04:00
113e78ee02 Phase 1b : renommer nomenclature domaines -> fonctions
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>
2026-06-23 20:20:40 -04:00
27bb51d007 Refonte application-hub Phase 1 : liens explicites
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>
2026-06-23 20:10:15 -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
18513a3bf0 Ameliorer la vue des dependances inventaire 2026-06-21 21:40:45 -04:00
1d25338d26 Ajouter les dependances causales des groupes 2026-06-21 21:31:03 -04:00
72c3ac6007 Consolider le flux operationnel des inventaires 2026-06-21 20:47:44 -04:00
f941b66d39 Preparer la gestion planifiee des services 2026-06-21 20:35:03 -04:00