Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Set-OPS-Public/roles/resoudre_base
History
Daniel Allaire 41413c7f04 deploiement : deux attentes de premier demarrage, et trois defauts leves 
`idm-01` a prouve le routage inter-zone dans le VRF (10.27.19.21 -> 10.27.17.11,
deux passerelles anycast) et leve trois defauts qu'aucun devis ne pouvait
montrer :

1. Le handler de `client_pki` rechargeait `slapd` avant son installation —
   consequence directe de l'ordre retabli. Un consommateur absent n'est pas une
   erreur ; un vrai echec de rechargement reste fatal.

2. `resoudre_base` ne trouvait aucune base de portee `application` : Keycloak
   declare `consommateur: keycloak`, le role cherchait `serveur_keycloak`. Le
   lien est declare dans applications.yml — on le suit au lieu de retirer un
   prefixe a la main.

3. Keycloak attend PostgreSQL, pas encore deploye. Pas un defaut : `deployer`
   ne connait que l'ordre intra-hote, l'ordre inter-hotes est celui de `site`.

Et deux attentes, sans lesquelles on ne peut pas enchainer creation et
deploiement — donc sans lesquelles `myDay` ne reconstruit pas seul : SSH, puis
cloud-init et les maj automatiques. `creer-vm` rend desormais une VM PRETE.
`lock_timeout: 300` sur chaque tache apt complete l'attente : le verrou peut
etre repris ENTRE deux taches, ce qu'une verification en amont ne previent pas.

Defaut dans l'attente elle-meme : `unattended-upgrades` est un demon, toujours
actif — l'inclure rendait la condition impossible a satisfaire.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 09:30:48 -04:00
..
tasks deploiement : deux attentes de premier demarrage, et trois defauts leves 2026-08-07 09:30:48 -04:00
README.md docs : un README par rôle (12 manquants) + carte remise à l'état du code 2026-07-29 11:32:06 -04:00

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 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).