Network infrastructure as code
In this post, we are going to dive into the concept of infrastructure as code or IaC and how it can be applied while providing Python software development services.
Infrastructure as code is a widely used DevOps term for managing or provisioning the hardware in your infrastructure in an automated and repeatable process. This means that your infrastructure is always maintained in a known and predetermined state, making it easy to use and apply best practices across your entire infrastructure.
In addition, adhering to the Infrastructure as Code principles ensures that your infrastructure is less susceptible to unexpected or unplanned changes. Even if someone manually changed the infrastructure and caused a negative impact, you can easily and immediately reapply the known/good state to restore the service.
Your security team will thank you too, because being able to uniformly ensure that your hardware has good, secure configurations make their job much easier.
Infrastructure fundamentals as code
To build an Infrastructure as Code NetDevOps solution on your own network, it is important to understand the key building blocks, or pillars, of Infrastructure as Code. A solid understanding of the core components, their interactions, and which tools and components belong will enable you to create a powerful and robust IaC solution in your environment.
Infrastructure as code is usually built on four main pillars.
- Source of Truth (SoT) – SoT is often a combination of the following components:
- Version control systems, sometimes also referred to as version control systems, to maintain text files representing the configuration of your infrastructure elements.
- Recording systems, which can be Configuration Management Database (CMDB) or Data Center Inventory Management (DCIM) tools, such as ServiceNow CMDB or NetBox.
- CI/CD – CI/CD stands for Continuous Integration and Continuous Deployment or Delivery and describes the systems used to manage and execute changes or deployments to your infrastructure.
- Tests − Tests allow you to move forward with confidence that the changes made in this process will be successful and will not cause unwanted or unintended changes to your infrastructure.
- Deployment and Configuration Tools – These tools are varied and can take different forms depending on the IaC system you are building. For NetDevOps, these will often be tools or systems that can interact with the network control layer (via SSH or HTTPS) to make changes.
If we were building Infrastructure as the “house” of the Codex, consider the Well of Truth as blueprints.
Network infrastructure as code
When it comes to bringing infrastructure as code into the NetDevOps world specifically, there are two general types of use cases.
The first type uses IaC to deploy the virtual network infrastructure itself. This could include, for example, automatic provisioning of AWS VPC resources to shut down the VPN in your organization or running a virtual firewall on ESX.
The second type is using IaC to deploy configurations to existing network infrastructure (including physical hardware). This could be storing a list of your BGP peers in a file in source control and then applying the appropriate configuration to the routers on your network when you make changes to that file.
The choice of which of these two areas you want to work on first will be up to you, although more often than not in enterprise networks we see what is taken later (setting up the physical hardware) as this is the biggest opportunity to affect the day-to-day operations. Eliminating the need to manually configure VLANs and simply making changes to a file in source control with a CI/CD tool doing the rest is extremely attractive to many organizations.