Daniel Allaire
c308c9c5b0
La supervision du SITE etait morte depuis 11:10 et rien ne le disait. icingadb refuse par pg_hba — hostssl impose cote serveur, connexion en clair cote client. icinga2 tournait, redis tournait, les sondes poussaient, et rien n atteignait la base : les verdicts se calculaient dans le vide. La cause est une seconde liste tenue a la main. tls_force allume hostssl ; chaque consommateur avait SON interrupteur a allumer dans les group_vars. Chezlepro avait les trois, le site avait le premier. serveur_forgejo disait pire que rien : sslmode disable ecrit en dur, le contraire de ce que le serveur imposait. resoudre_base expose resoudre_base_db_tls_force, lu dans les hostvars de la machine qui PORTE la base. Les trois interrupteurs en derivent. Un serveur qui ne declare rien ne force rien : on ne casse pas un ecosysteme qui n a pas bascule. P78 refuse une valeur ecrite chez un consommateur, et nomme les deux roles sans reglage TLS plutot que de rendre un vert muet sur eux. Apres : icingadb active, TLSv1.3 vu par PostgreSQL, 16 hotes et 88 services en base. Les cinq sondes des marqueurs du site, INCONNU faute de deploiement, rapportent leur phrase. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q |
||
|---|---|---|
| .. | ||
| tasks | ||
| README.md | ||
resoudre_base
Rôle utilitaire (pas un groupe déployable) : résout l'entrée de base de données d'un
consommateur depuis le registre partagé instance/plan/bases-donnees.yml.
C'est la moitié « binding app→base » de la conception des liaisons — le lien est déclaré
côté base (le registre nomme son consommateur), et résolu dans le rôle consommateur,
pour que le secret ne quitte jamais ce rôle. Cf. docs/bindings-conception.md §5.
Usage
- name: Résoudre la base depuis le registre (rôle partagé)
ansible.builtin.include_role:
name: resoudre_base
vars:
resoudre_base_groupe: serveur_keycloak
Entrée
| Variable | Rôle |
|---|---|
resoudre_base_groupe |
Le groupe consommateur cherché dans le registre |
Sorties (facts, persistent après include_role)
| Fact | Contenu |
|---|---|
resoudre_base_entree |
L'entrée du registre (base, proprietaire, secret, serveur…) |
resoudre_base_db_password |
Mot de passe déréférencé de la voûte (no_log) |
resoudre_base_db_host |
FQDN du serveur de base |
resoudre_base_db_port |
Port (défaut 5432) |
Pourquoi le FQDN (et pas le nom court)
Décision d'architecture : non ambigu en fédération (data-sql-01 existe chez plusieurs
tenants) et nom canonique pour la vérification TLS verify-full. Résolu par le plancher
/etc/hosts (hosts_statiques).
Notes / limites
- Le rôle assère la présence d'une entrée (
base,proprietaire,secret) : aucun consommateur ne peut être déployé sans sa déclaration dans le plan. Message d'erreur explicite pointantinstance/plan/bases-donnees.yml. - Le secret est déréférencé par
lookup('vars', <nom>): le registre ne contient que le nom de la variable de voûte, jamais sa valeur. - Un seul consommateur par entrée (le premier trouvé gagne).
Prérequis
setops_plan_dirdéfini ; voûte déverrouillée (ANSIBLE_VAULT_PASSWORD_FILE).