Configuration management tools, version control and Terraform for networks

Why use a configuration management tool?

Typing the same change on fifty switches is slow and invites mistakes, and over time devices drift away from the standard. A configuration management tool stores the desired configuration as code, applies it to many devices in the same way, and can report or fix drift. Combined with version control, every change becomes reviewable and reversible.

Comparing the main tools

Two more ideas help you compare them. Declarative tools let you describe the end state ("VLAN 30 exists with this name") and work out the steps; imperative or procedural tools run the steps you list in order. And good tools are idempotent: running them again when nothing has changed makes no changes. Ansible is covered in detail in Ansible and NetDevOps.

Version control with Git

A version control system records every change to a set of files: who changed what, when and why. Git is the standard, usually hosted on a platform such as GitHub, GitLab or Bitbucket. Older centralised systems such as Subversion are still found but rarely chosen for new work.

• Keep playbooks, templates, Terraform code and even device configuration backups in Git.
• Make changes on a branch, then open a pull (or merge) request so a colleague reviews them before they reach the main branch.
• Pipelines can test every change automatically before it is deployed.
• If a change causes trouble, you can see exactly what changed and revert it.

The commands are covered in Git basics for engineers.

Terraform: infrastructure as code

Terraform describes infrastructure in a declarative language called HCL. Providers are plug-ins that translate the code into API calls for a platform: every major cloud, and many network and security products, have one. Terraform keeps a state file listing what it created, so it knows what to change or delete next time. In 2023 HashiCorp moved Terraform to a source-available licence, and the community fork OpenTofu, hosted by the Linux Foundation, continues under an open-source licence with largely the same language.

resource "aws_vpc" "campus_cloud" {
  cidr_block = "10.200.0.0/16"
  tags = { Name = "campus-cloud" }
}

resource "aws_subnet" "app" {
  vpc_id     = aws_vpc.campus_cloud.id
  cidr_block = "10.200.10.0/24"
}

terraform init
terraform plan
terraform apply
terraform destroy

Treat the state file as sensitive: it can contain secrets. Store it in a protected remote backend with locking so two people cannot apply at once. A common split is Terraform to build infrastructure (networks, gateways, virtual appliances) and Ansible to configure what runs on it. Try it safely in Lab: Terraform basics.

Real-world example: one standard for three environments

A fictional online retailer had test, staging and production networks in the cloud that had been built by hand and no longer matched. A firewall rule that existed only in staging hid a bug until it reached production. The team rewrote all three networks as one Terraform module with a small variables file per environment, kept in Git. Changes now go through a pull request; the pipeline runs terraform plan and posts the plan for review, and only an approved merge runs apply. Drift is found the next morning, when a scheduled plan reports any difference between the code and the real network.