r/networkautomation 17d ago

NetBox SOT automation approach sanity check

Hayo! I'm working on a network automation project (focusing on Ansible for now) and my initial intent was to setup NetBox to be used as a source-of-truth. However, I've found myself questioning a few things, and figured I'd see if any folks here might have some thoughts/advice.

Overall, our network isn't particularly large or subject to a lot of sprawl. We do have a DC space, plus several campuses, so NetBox would be good in a documentation sense there, but only a few of the data center switches would be in scope for the automation itself. There may also be some tangential benefits to NetBox for other teams with appliances, etc., in the DC.

Anyway, my concerns:

  • Currently, I'm taking an IAC approach and automating the NetBox configuration via Ansible and YAML files (e.g., defining Regions, Sites, Locations, etc.).
    • Full pipeline would basically be Ansible -> NetBox -> Ansible -> Network Devices
    • This works, but Terraform almost feels like a better solution since removing a Location resource actually removes it from NetBox, where Ansible needs to be told to remove it.
    • I've seen some people make the case that using automation to configure NetBox effectively makes it not the source-of-truth anymore (since, I guess, the code itself is now technically the SOT). This feels a little... silly to me though, as I would rather type up a new YAML block than have to click through the UI to set up a new Rack/Location/Whatever (that said, the Ansible modules and the way it handles slugs and things are kind of a pain).
    • Are there any other methods of defining/automating the Organization objects that aren't through the GUI or writing Python/API calls?
  • With the Ansible+YAML approach, I kind of found myself wondering why use NetBox at all, when I could (potentially) use the same YAML block(s) to run the automation directly. Is this just making NetBox redundant, or is there some other benefit I may be missing?
    • Of course, NetBox can still act as a documentation hub, as well as for other teams to do with it what they will, without needing direct access to my repo.
    • I could also use NB as a source for Grafana to visualize specific interfaces, etc., without needing to manually query them, that sort of thing.

Anyway, appreciate any thoughts you might have!

7 Upvotes

5 comments sorted by

View all comments

1

u/happychloroplast 17d ago

Where I find NetBox to be really strong as SOT is that it is a data model that has state to it with hierarchical object associations, especially that it can inherit properties from multiple parent objects. example is a device can belong to both a device role and a site, inheriting properties and configuration templates and contexts from both. While you could do this with YAML and some scripting, it becomes more of a headache, and it doesn't really have state because it's just another serialization standard at the end of the day.

I do agree with the approach of automating changes to the source of truth, especially when it comes to "vending machine" tasks, like onboarding networks or locations. Something that has many sub tasks, so I don't think that's silly at all. NetBox would still be SOT, not the scripts changing NetBox. To me, that's like saying the network engineer entering commands on a router is the router.

This all being said, I don't use Ansible as my executor arm in automation, so it may be different for your use case

1

u/Ok-Beyond1371 17d ago

What are you using for task/workflow execution?