Infrastructure as Code

Infrastructure as Code (IaC) involves representing infrastructure in a code format, typically using YAML or JSON files, allowing easy parsing by configuration management systems. In broader IT contexts, IaC extends beyond network infrastructure to encompass cloud resources and servers, sometimes referred to as Network as Code (NaC). IaC serves as a foundational element in NetDevOps.

Treating network infrastructure configurations as code streamlines adoption of DevOps workflows for network engineering teams. These configurations, versioned like application code, necessitate the use of Version Control Systems (VCS) such as Git. Implementing IaC enables network teams to track changes, perform audits, and swiftly rollback if necessary. This section explores the significance of IaC, especially in the realm of NetDevOps.

What IaC Means for Network Engineers

IaC entails managing and provisioning network infrastructures through machine-readable definition files rather than manual command-line inputs on each network device. Configurations typically comprise key-value pairs in YAML or JSON format, representing variables such as interface IP addresses, VRF route-distinguishers, or router IP prefix-lists. These values can be manually entered or sourced from Operations Support Systems (OSS) or Business Support Systems (BSS) like IP Management platforms or Inventory Databases.

Key features and benefits of IaC include:

• VCS-based configuration storage.
• Validation and testing of configurations before deployment.
• Versioned configuration tracking.
• Self-documenting change management through version control.

The Benefits of Source Control

Representing infrastructure as code brings several advantages, particularly with source control:

• Versioning facilitates tracking and documenting changes.
• Peer review and approval processes ensure quality.
• Continuous Integration (CI) processes automate testing before deployment.
• Rollback capabilities ease reverting changes if issues arise.
• Self-documentation provides insights into change history and contributors.

Example of an IaC YAML File

Here's a sample YAML file for BGP configuration:

---
local_as: 65004
neighbors:
  - ip: "10.10.4.1"
    remote_as: 65003
  - ip: "10.10.70.1"
    remote_as: 65009
advertised_networks:
  - ip: "10.10.3.0"
    mask: 24
  - ip: "10.10.2.0"
    mask: 24

This snippet defines the local AS, neighbor IPs with corresponding remote AS, and advertised networks for BGP configuration.

Source of Truth

Establishing a Single Source of Truth (SSoT) for device configurations is crucial for successful IaC implementation. Clear policies delineating the SSoT and its usage are imperative to prevent chaos. Device configurations should no longer serve as the SSoT; instead, data should be derived from a singular authoritative source for each data domain. Auditing systems compare device configurations to the SSoT and rectify discrepancies. Maintaining one source of truth per data domain ensures consistency and accuracy in configuration management.