News

Structured data instead of individual text files

In the open source environment, plain text files, e.g. in a YAML or JSON format, are frequently used for (software) configurations and other data that are evaluated by means of an automated process. For a long time, our Ansible setups, which we use to automate a majority of our installation and maintenance processes, obtained their data about our inventory from a large number of such YAML files.

Our recent switch to NetBox now explicitly represents connections in the NetBox database that were more or less apparent in these YAML configs, ultimately providing additional protection against errors. You can navigate through the inventory via the web-based interface of NetBox and, for example, see the occupancy of server racks or check which devices share a chassis.

Comprehensive and flexible

NetBox supports a wealth of information about every device. In addition to location, position in rack, device type and network details, it is also possible to record e.g. whether the cooling air flows from the front of the device to the back or vice versa. For cloudscale, the most relevant recorded data are, in particular, the role that a device fulfills, i.e. whether it is a storage server, a switch or a monitoring system, to name but a few.

The tasks that we automated in Ansible then use the API to obtain the hosts they are to be applied on from NetBox; the same goes for host-specific configs, such as MAC addresses. The interfaces required for this are provided by the inventory plugin contained in the NetBox Ansible Collection. We use caching to improve the performance for more complex playbooks, too. The required data are collected once at the beginning of the playbook run, maintained for the whole run and then discarded to ensure that the next run also starts with the most up-to-date data.

In our precisely structured Ansible setups, (physical and virtual) hosts are frequently allocated to more than just a single Ansible group, although NetBox is limited to at most one role per device. This is why, in order to be able to represent the existing structure in NetBox, we decided to only allocate the primary child group (lowest group in the inheritance tree) as a role for the device. Any further child groups are recorded in NetBox using "tags". We then transform these special tags into groups by means of an internally developed Ansible plugin and add these as a variable to the host in question at playbook runtime.

More than networking

NetBox is officially aimed at network engineers. However, its claim to offer "a cohesive, extensive, and accessible data model for all things networked" makes it clear that the area of application is considerably broader. This means that our customers can also represent their virtual servers in NetBox, together with properties, such as the specific cloud location, IP addresses, private networks, etc. In combination with our Ansible Collection, it is even possible to import existing cloud setups into NetBox.

As a "source of truth", NetBox can ultimately also take on a managing role, with new virtual servers being first recorded in NetBox and then, based on this data, automatically created and configured by Ansible.

NetBox represents a powerful tool to further automate tasks surrounding the inventory. Thanks to it being open source, we can also contribute our own improvements back to the community. With NetBox as a "source of truth", everyone involved can rely on correct data about the inventory, both via Ansible playbooks and in the web-based GUI.

A reliable basis.
Your cloudscale team