Daniel Allaire
db2d6f6bf0
Mesure avant de decider : ~21 Mo de RSS par VM pour 28 a 189 requetes servies. Le gain de cache est negligeable ; ce qu'on recupere, c'est un demon au lieu de cinq et un endroit a regarder au lieu de cinq. Pas sur la frontiere : un resolveur de SITE devrait connaitre la zone interne de chaque tenant, et un tenant dont le resolveur vit chez l'hebergeur ne peut plus s'emanciper avec. La recursion est generique, la zone interne ne l'est pas. L'autoritatif se replie sur 127.0.0.1:5300 -- derive de la colocalisation, pas declare a la main. Son port devient `derive` dans meta/flux.yml : les deux lient 53 mais sur des adresses differentes. Deux pieges. Unbound refuse d'interroger une loopback par defaut : sans lever do-not-query-localhost, toute la zone rendait SERVFAIL. Et le plancher /etc/hosts MASQUAIT la panne -- getent repondait, dig disait SERVFAIL. La tache de validation du role avait raison contre moi. client_unbound n'installant plus Unbound, son nom mentait : client_resolveur. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
34 lines
1.7 KiB
YAML
34 lines
1.7 KiB
YAML
---
|
|
# INTÉGRATION CLIENTE : désigner le résolveur de l'écosystème.
|
|
#
|
|
# CE RÔLE N'INSTALLE PLUS RIEN (2026-08-24). Il posait un Unbound sur CHAQUE VM — N démons
|
|
# identiques, ~21 Mo chacun, pour quelques centaines de requêtes. Le résolveur est
|
|
# désormais un service du tenant (`serveur_resolveur`), et ce rôle ne fait plus qu'une
|
|
# chose : écrire `/etc/resolv.conf`.
|
|
#
|
|
# L'ancien nom mentait dès lors qu'il n'installait plus Unbound — d'où `client_resolveur`.
|
|
|
|
# DÉRIVÉ de l'inventaire : l'hôte qui porte le résolveur. Aucun résolveur au plan rend une
|
|
# valeur vide, et le rôle ne touche à rien (voir `client_resolveur_actif`).
|
|
client_resolveur_hote: >-
|
|
{{ (groups['serveur_resolveur'] | default([]) | first | default('')) }}
|
|
client_resolveur_adresse: >-
|
|
{{ hostvars[client_resolveur_hote].ansible_host | default('')
|
|
if client_resolveur_hote else '' }}
|
|
|
|
# L'INTÉGRATION SUIT L'EXISTENCE DU SERVICE — elle ne se déclare pas. Un écosystème sans
|
|
# résolveur garde la résolution d'amorçage posée par cloud-init : c'est un choix valide,
|
|
# pas une panne.
|
|
client_resolveur_actif: "{{ (groups['serveur_resolveur'] | default([])) | length > 0 }}"
|
|
|
|
client_resolveur_zone_interne: "{{ domaine_interne }}"
|
|
client_resolveur_resolv_conf: "/etc/resolv.conf"
|
|
|
|
# --- BASCULE PROTÉGÉE ---------------------------------------------------------
|
|
#
|
|
# Réécrire /etc/resolv.conf peut couper toute la flotte si la cible est mauvaise. Le rôle
|
|
# exige donc une confirmation ET vérifie que le résolveur répond DÉJÀ — pour l'interne et
|
|
# pour l'Internet — avant de basculer quoi que ce soit.
|
|
client_resolveur_apply: false
|
|
client_resolveur_confirm: false
|
|
client_resolveur_attente_reconnexion: 120
|