Contrainte de l'exploitant apres avoir vu backup-01 et collab-01 crees avant l'AC et le DNS. Ma premiere reponse etait incomplete : un clone est bien inerte, mais un echec a la 12e VM coute 40 minutes sans rien deployer, et le journal donne l'impression que le moteur ignore ses couches. Mesure avant de coder : - enregistrements A : DEJA derives du plan (zone generee depuis hotes_actifs) - zone inverse / PTR : n'existe NULLE PART, aucun role ne touche in-addr.arpa - ordre d'amorcage : aucun, deployer-tout est par couches Le premier point a reduit le travail de moitie — j'allais ecrire un enrolement DNS par hote alors que la zone directe etait deja correcte. Zone inverse derivee du supernet (27.10.in-addr.arpa), PTR issus de la MEME source que les A : pas d'endroit ou elles puissent diverger. Vide si le supernet n'est pas un /16. _amorcer-socle monte l'AC puis le DNS completement avant deployer-tout ; les deux derives de applications.<app>.hote, dans un ordre causal et non alphabetique. Deux exceptions assumees : l'AC s'auto-signe, le DNS pose son propre enregistrement. P10 a attrape un handler que je venais d'inventer (Recharger PowerDNS au lieu de Validate and reload PowerDNS) avant tout deploiement. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| defaults | ||
| handlers | ||
| meta | ||
| tasks | ||
| templates | ||
| README.md | ||
Role serveur_powerdns
Installe et configure PowerDNS Authoritative comme service DNS interne initial.
Ce premier jalon utilise le backend BIND et une zone generee par Ansible depuis
l'inventaire. Cela evite de rendre DNS dependant de PostgreSQL avant que le
service serveur_postgresql soit disponible.
Variables principales :
serveur_powerdns_zoneserveur_powerdns_nameserverserveur_powerdns_contactserveur_powerdns_records
Les hotes actifs portant ansible_host sont ajoutes automatiquement dans la
zone par le template.