Managing thousands of DNS records in a GitOps fashion using Ansible and NS1
summary
Red Hat moves DNS from legacy BIND into a GitOps pipeline using GitLab, Ansible Automation Platform, and NS1: an ns1 Ansible role plus a set of playbooks and a per-zone inventory (one file per zone) drive AAP job templates and workflows, triggered by GitLab CI with a custom runner script that applies GitLab CI limits to only changed zones. Migration starts from ~500 zones and thousands of records (redhat.com had ~1,800 records), now at 926 zones and >5,000 records, >500 merged changes, rare human-caused failures and a few API rate-limit hits.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 2:11GitOps for DNS management
- 5:26Current DNS automation setup
- 9:01Ansible inventory for zones
- 12:56GitLab CI/CD with Ansible
- 19:29Migrating Bind zones to GitLab
- 21:40DNS change workflow
- 23:30Access control challenges
- 25:16Results and benefits
- 27:50Future improvements
- 30:01Q&A
related talks
22mHow We Un-Scattered Our DNS Setup and Unlocked New Automation Options
44mAnsible powered Network automation
35mGitOps or a Journey to a Production Incident and Swiftly Back Again
36mPulling the Puppet Strings with Ansible
48mHow We Manage Infrastructure Across 1,000+ Servers Using ansible
32mInfra: Give Developers Autonomy with OctoDNS
45mDeploying and managing IdM with Ansible
54mAutomating your DNS