CI/CD Your Nautobot Data
This project aims to give the reader one possible solution to use CI/CD with Nautobot, Nautobot Design Builder, and Github Actions.
Project Location
Nautobot Design Builder
Nautobot Design Builder is a Nautobot application designed to manage data at scale in a consistent, programmatic and repeatable way. According to the docs: “Design Builder is a Nautobot application for easily populating data within Nautobot using standardized design files. These design files are just Jinja templates that describe the Nautobot objects to be created or updated.”
There are several use cases for Design Builder, including:
- Building new site data with variable form entry data. ie:
- User inputs qty of routers and switches, runs Design Job
- Design Job creates new site, devices, VLANs, Prefixes, IPs, Cable runs, Circuits, etc.
- Provisioning new services, ie L2VPN, L3VPN, etc.
- Populating and maintaiting fixed data, ie Manufacturers, Device Types, Locations, etc.
It’s worth exploring this application and all its capabilities to understand how it can be used in your environment.
Leveraging Design Builder with Github Actions for CI/CD
One feature of this app is that Design Jobs can be imported into Nautobot via Git Datasource. Therefore, a user can define Nautobot data in a Design Job inside a git repository, sync the Job into their Nautobot instance, run the Job, and the data will be declaritively updated.
If we toss CI into the mix, we can define a workflow as follows:
- User clones the Designs repo, creates a feature branch
- User updates data in repository (Add VLAN to an interface trunk, for example)
- User pushes code back to repo and opens a PR
- Github actions runs CI against the submitted code. CI steps:
- Run the Design Job against a fresh Nautobot instance on a github actions runner, ensuring data validity
- If CI passes, the Design Job changes are synced to the production Nautobot instance and the Job is run there which updates production Nautobot data
This workflow opens a world of possibilities on the CI front. It could be enhanced in several ways by including configuration management, config sanity checks, suzieq and batfish checks, pre/post deployment checks, config push, etc. It all depends on what your desired workflows are.
If you’re curious, perhaps the most useful bit of this project is the CI file. Take a look there and you’ll get a general idea of the overall CI/CD process.