How are you managing DCIM/IPAM information—such as prefixes, VLANs, IP addresses, devices, and DNS—in an Infrastructure-as-Code or GitOps-style workflow? I've been considering tools like NetBox or Nautobot with Terraform/OpenTofu, using Git as the source of truth. Do you store the data declaratively in Git, or treat the DCIM/IPAM platform as authoritative and use Git mainly for automation? I'm also interested in how you handle manual changes and drift—for example, adding a machine or changing an existing machine's IP—and how that information is consumed later by DHCP, DNS, configuration management, or deployment pipelines.
3 Answers
One workable pattern is to let engineers make requests through the IPAM interface, then have the system generate a pull request. After review and approval, a pipeline applies the change. That gives less experienced engineers a safe self-service workflow without requiring them to edit the repository directly.
We use an IPAM/DNS/DHCP platform as the authoritative source. Our automation talks to its API, and keeping IPAM current automatically keeps DNS records consistent. It costs more than maintaining an entirely custom system, but having one authoritative source simplifies automation and reduces drift.
Our CMDB is authoritative for hosts and includes each machine’s IP assignment. Whenever a relevant field changes, a pipeline regenerates the Kea DHCP configuration containing the reservations and deploys it. This has worked reliably because manual changes are captured in the CMDB and automatically propagated to the service that needs them.
That can make the platform owner a bottleneck, though. Another approach is to keep the IPAM system protected and have engineers submit structured data through their own tooling or APIs. The pipeline can validate it, run tests, show a diff, and then update the platform and downstream systems.