Archived

This repository has been archived on 2026-06-26. You can view files and clone it, but cannot push or open issues or pull requests.

Daniel Allaire ca0f95da28 Mettre les noms de roles et playbooks au singulier

serveurs_* -> serveur_, clients_ -> client_, suffixes pluriels au
singulier (serveur_web_dorsal/frontal, client_metrique, client_journal).

Renommage par tokens exacts : repertoires de roles, playbooks de groupes,
group_vars, variables internes des roles (serveur_nginx_*, conformite
ansible-lint), groupes du plan, constantes de code, docs. Faux-amis
preserves (serveurs_bd, scripts/serveurs.py, fonctions Python). Groupes
d'etat gardes au pluriel (hotes_actifs/planifies, modeles_vm).

Valide : ansible-lint 0 echec (0 var-naming), diff vide de la generation,
node --check, tous les registres. Ajout de .ansible-lint excluant docs/
(registres de donnees, pas du contenu Ansible).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-23 23:18:52 -04:00

2 KiB

Raw Blame History

DNS interne Chezlepro

Le service DNS interne est la premiere capacite de plateforme.

Groupes

serveur_powerdns -> service DNS central PowerDNS Authoritative
client_dns       -> integration cliente DNS

client_dns depend de serveur_powerdns dans docs/dependances-groupes.yml.

Zone initiale

La zone initiale est :

chezlepro.internal

Elle est definie dans :

inventories/production/group_vars/serveur_powerdns.yml

Enregistrement automatique

Le role serveur_powerdns genere la zone a partir de l'inventaire.

Les hotes qui remplissent ces conditions sont ajoutes automatiquement :

hote dans hotes_actifs
ansible_host defini

Exemple :

web-frontal-01 ansible_host=10.1.15.31
-> web-frontal-01.chezlepro.internal A 10.1.15.31

Les enregistrements additionnels explicites sont dans serveur_powerdns_records.

Backend PowerDNS

Le premier jalon utilise le backend BIND de PowerDNS.

Raison :

pas de dependance prematuree a PostgreSQL ;
zone lisible et generee par Ansible ;
idempotence simple ;
bon point de depart pour la supervision.

Quand serveur_postgresql sera stable, il sera possible de migrer vers un backend SQL si le besoin operationnel le justifie.

Clients DNS

Le role client_dns valide :

qu'un serveur serveur_powerdns actif existe ;
que la zone repond a une requete SOA ;
que le nom de l'hote existe dans la zone.

La modification du resolver local est protegee :

client_dns_apply: true
client_dns_confirm: true

Sans ces deux variables, le role valide les prerequis mais ne modifie pas /etc/resolv.conf.

Cette protection est volontaire : une mauvaise configuration DNS peut couper la resolution de noms.

Surveillance a prevoir

Les premiers checks utiles :

service pdns actif ;
port UDP/TCP 53 disponible ;
SOA de chezlepro.internal resoluble ;
enregistrement ns1.chezlepro.internal resoluble ;
enregistrements des hotes actifs presents ;
serial de zone attendu ;
latence de resolution.

2 KiB Raw Blame History