What is a Schema?
One way to define a schema is a blueprint that defines your data structure for your environment. Within Infrahub, it can outline the structure, objects, and relationships of your data. To clarify, this doesn’t refer to individual devices, like a specific router or firewall. Instead, we’re talking about broader categories, such as network devices (which could include routers, switches, etc.) or organizational sites.
The schema is comprised of the larger building blocks used throughout your environment, along with the attributes associated with them, and how they relate to each other.
This article walks through the major concepts contained in the video below.
The Importance of Flexibility in Schema Design
One key aspect of effective schema design is flexibility. As your business evolves, so do your data structure and tooling needs. For instance, if you acquire another business that utilizes a different application, you’ll need to incorporate their data into your existing environment. A flexible schema allows you to merge these data points without requiring substantial changes to your existing data design.
Flexibility also comes into play during tool migrations. If you’re transitioning from an outdated tool, a flexible schema can help you adapt your old data to fit into the new system seamlessly.
Moreover, as you push further into automation, you may discover additional data points that currently exist as custom fields in other applications. By having a flexible schema, you can treat this business data as first-class citizens within your data model, eliminating the need for custom fields.
In Infrahub, flexibility means you can customize and evolve your schema over time to meet your changing needs.
Understanding a Basic Schema
Here’s a very basic schema setup featuring two nodes. We have network device and organization site.
-
version: "1.0"
nodes:
- name: Device
namespace: Network
attributes:
- name: hostname
kind: Text
unique: true
- name: model
kind: Text
- name: Site
namespace: Organization
attributes:
- name: address
kind: Text
- name: contact
kind: TextEach node type has attributes associated with it. For instance, every Network Device will have a hostname and a model number.
For the Organization Site, which we can think of as a physical building, has attributes like address and contact information. The types of these attributes can vary; in our example, we have standard text fields for free-form text entry.
Depending on your company it may be important to enforce uniqueness for certain attributes, such as the hostname for network devices. This is fully controllable within the schema design.
Loading the Schema in Infrahub
In the terminal, using the infrahubctl schema load command, it’s fairly simple to select our schema and load it into our Infrahub environment.
More information on using infrahubctl can be found in the Infrahub documentation
Expanding the Schema
Next, let’s look at how to expand our schema. We’ll add a firmware attribute to Network Device and an email attribute for our Organization Site contact person.
-
version: "1.0"
nodes:
- name: Device
namespace: Network
attributes:
- name: hostname
kind: Text
unique: true
- name: model
kind: Text
- name: firmware
kind: Number
- name: Site
namespace: Organization
attributes:
- name: address
kind: Text
- name: contact
kind: Text
- name: email
kind: EmailWe’ll find a list of attribute types, including text, which we already used in our basic schema. There are many other attribute kind options available that can help customize your schema according to your specific environment needs.
Understanding Namespaces
Finally, let’s talk about namespaces. In our working schema, we defined the network namespace and the organization namespace. This helps prevent node name collisions. Other examples could be having a node named Device in multiple namespaces. Here is an abbreviated example of that.
-
version: "1.0"
nodes:
- name: Device
namespace: Network
- name: Device
namespace: Security
- name: Device
namespace: ServerObviously we would include attributes in a production schema, but this should help visualize the concept of Device existing in the Network, Security, and Server namespaces.
Conclusion
Understanding schema design is a key element to extending how to take infrastructure automation and effectively improve it. It’s a topic worthy of spending time to understand and consider. Here are a few key pages from our documentation to help on that journey.
Let’s get automating!
Github: github.com/opsmill/infrahub | Discord: discord.gg/opsmill |
