Ansible Limit When Using Netbox as Inventory

I’m currently using Ansible to template a large and growing number of devices for an ISP that I’m working for. The last part of the process is to use Netbox as a source of truth to write the configs using Jinja2 templates. The work is done as part of a CI/CD pipeline, and runs on a specific Gitlab Runner instance – finally the config is pre-staged onto the device’s filesystem to be checked by a engineer before deployment.

I’ve been finding the growing list of hosts a bit hard work, and, seemingly undocumented in the Netbox docs is how to put a site-specific limit on the playbook run. This is easily done in regular Ansible by using .ini-style host file groups like this:

[siteA]
sitea-router001
sitea-router002

[siteB]
siteb-router001
siteb-router002

You can then do ‘ansible-playbook -l siteB’ to restrict what gets generated. How you do this when Netbox is the source of inventory is less clear.

It turns out that sites are pre-pended in Netbox with the string ‘sites_’. So, in your dynamic inventory file (in my case, called nb-inventory.yml) you need to tell it to group hosts by site by including the sites keyword under the group_by section:

plugin: netbox.netbox.nb_inventory
api_endpoint: https://YOURURLHERE
token: YOURTOKENHERE
validate_certs: False
config_context: False
group_by:
  - device_roles
  - sites

query_filters:
  - has_primary_ip: 'true'

compose:
  ansible_network_os: platform.slug

Then, the command to retrieve hosts by site is:

ansible-playbook main.yml -i nb-inventory.yml -l sites_sitea

This should return something like the following:

    "sites_sitea": {
        "hosts": [
            "sitea-router001",
            "sitea-router002"
        ]
    }

Et voila…

3 Challenges for Network Engineers Adopting Ansible

Ansible, ansible, ansible seems to be all we hear these days. There are lots of resources out there all trying to convince us this is the new way get stuff done. The reality is quite different – adoption of tools like this is slow in the networking world, and making the move is hard for command-line devotees.

Here are the three main problems I encountered in my adoption of Ansible as a modern way to manage devices:

Issuing Junos Commands Using Ansible raw Module

If you want to issue something quick on a lot of devices, you don’t need to write a whole Ansible playbook to do that.  In fact you don’t really need the Junos module installed.

Ansible expects there to be Python on the managed device.  As you can read in this PacketPushers blog, it pushes the module out to the device and tries to execute it there.  Junos is going to get on-box Python at some point, but right now that’s roadmap (or SOPD if you must).

Ansible and Junos Notes

I’m working on a project to push out configs to Juniper devices and upgrade them if necessary. Ultimately it will be vendor-independent.  In the first instance I thought about writing it all in Python, but there’s really no need because quite a lot of legwork has already been done for you in the form of ‘PyEz’ and the Junos Ansible core modules.

Juniper give you a few examples to get you started, but don’t really explain what each of the lines in the YAML file does, but I guess they expect you to figure that out.  Below are a few notes on things I discovered – perhaps obvious to some, but they might help someone else.