README reduit au role du projet et au demarrage rapide. docs/architecture.md (schemas Mermaid), docs/setup.md, docs/usage.md (154 cibles en 13 familles), docs/README.md (index). Documents ranges en conception/, exploitation/, hebergement/, projet/ ; 598 chemins suivis. QUICKSTART.md, SOLUTION.md, architecture-set-ops.md et la carte fondus puis retires. Preuves : P48 lit l'index et conception/mecanismes.md ; les gardes parcourent docs/ sous- dossiers compris (_documents) ; usage.md suit le Makefile dans les deux sens. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
46 lines
2 KiB
Markdown
46 lines
2 KiB
Markdown
# 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/conception/bindings-conception.md` §5.
|
|
|
|
## Usage
|
|
```yaml
|
|
- 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 pointant `instance/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_dir` défini ; voûte déverrouillée (`ANSIBLE_VAULT_PASSWORD_FILE`).
|