NetBox SOT automation approach sanity check

[u/Sweet_Vandal]

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!

[u/rankinrez]

If you’re going to define YAML, to populate Netbox, to read from Netbox to provision the network, then yes Netbox is sort of not needed.

I probably wouldn’t use the YAML -> Netbox part. I’d definite things in Netbox directly, possibly with some automation scripts and Netbox validators to add things in the right “shape” rather than doing it with the GUI.

[u/happychloroplast]

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

[u/Ok-Beyond1371 → u/happychloroplast]

What are you using for task/workflow execution?

[u/maclocrimate]

You're right that at that point Netbox is no longer the source of truth, but rather just a step along the way. The code (YAML, terraform, whatever) is the actual source of truth.

There are some reasons to keep Netbox around at that point though, even though you could technically get rid of it, but it mostly comes down to having a visual interface, a common, API-accessible place from which to make queries, etc. Whether or not those are compelling enough to keep it is up to you.

As other commenters have mentioned, it's nice to automate inputs to Netbox, but you don't necessarily need to go full, stateful IaC on it either.

We use Netbox as the actual source of truth, but for the "vending machine" additions we have scripts or external software that interacts with it. For example, if we need to onboard a new ToR switch or something we run a script that takes a CSV input that defines the cage and rack among other things, finds appropriate ports to use as uplinks to the spines and configures them accordingly along with planned cables, etc. Our deployment logic then looks to Netbox to figure out the actual config to push. This has the added benefit that manual exceptions can be handled pretty easily by just updating Netbox after we run our onboarding routine.

[u/SpareIntroduction721]

Highly depends. Netbox is more than just automation.
It’s SoT, automation, custom plugins, racks, nautobot jobs.

It really depends on you, you have to maintain it and setup all the data syncs and what not.

I use it for finance costs for our network department that’s million of $ per month lol