In this second part of our series on Generators and services, we delve deeper into the practical aspects of creating a Generator that streamlines the delivery of new sites.
This post aims to provide a comprehensive overview of the process, focusing on the use case, design requirements, workflow, and a live demonstration of the Generator in action. If you missed our first article and video in this series, be sure you check those out.
. . . . .
Recap of Generators
Generators are generic plugins that query data and create new nodes and relationships based on the results. They can play a crucial role in automating the creation of new objects, services, and other elements within infrastructure management and deployment frameworks. The logic behind these Generators determines how effectively they can automate processes.
. . . . .
Defining the Generator use case
For our Generator, the primary use case is to automate the delivery of new sites. This involves creating a consistent and repeatable process for setting up new infrastructure. Our deliverables will include the creation of devices within Infrahub and the artifacts necessary for launching new sites. We’ll also record our design requirements and map out the general Generator workflow.
. . . . .
Design requirements
Before diving into the workflow, we’ll clarify our design requirements. This includes decisions about hardware configurations, naming conventions, and the relationships between devices.
Hardware configuration
We'll implement two configurations:
- Single-homed configuration: This setup uses a single router, firewall, and switch, suitable for less critical applications and sites.
- Dual-homed configuration: For more critical infrastructures, we'll set up two routers, two firewalls, and a single switch to ensure redundancy and fault tolerance.
Naming conventions
(site)-(device)-(incrementor)(site)– a shortname for any given site(device)– the type of device(incrementor)– incremented for each device at the site
Relationships
- We'll keep this simple and just map our devices to the sites
. . . . .
Map the workflow
In our next article we’ll dive into the actual code that runs our Generator. But for now we’ve outlined, in psuedocode, what this workflow should look like.
function generate(site):
validate site data
if homing == "single_homed":
create 1 router, 1 firewall, 1 switch
else if homing == "dual_homed":
create 2 routers, 2 firewalls, 1 switch
link devices to sites
return successRunning the Generator
Generators can be ran one of two ways: the command line or the UI. When developing a Generator it’s best to run it from the command line. Using the UI works better once a Generator has been completed and is ready to be used in production. While we only show one example below, we actually run this twice for the demo in the video.
Below we can see the Generator running and creating our devices for the Chicago site. To help us track the Generator running in the development stage, additional code has been added to output information to the console.
Once the Generator has run successfully, we'll see the 2 routers, 2 firewalls, and switch have been generated for the Chicago site.
Conclusion
In this article, and video, we’ve continued to expand our understanding on how a Generator can start to help us deliver our services in a repeatable and reliable fashion. The continuing articles in the series will further enhance the delivery of our service of a fully functional site through our Generator.
Stay tuned as we continue on this path in crafting our Generator tailored to specific needs, enhancing our capabilities through Infrahub.
To learn more about Generators today, check out the following links to our documentation:
