Infrastructure as Code (IaC) for Data Centers: From Physical Rack to Repository
Infrastructure as code is not only for cloud. Applied well, it eliminates the reliance on the operator’s memory to configure switches, UPS, PDUs, and even rack capacity. Applied poorly, it adds complexity without return.
What can be versioned and what cannot
What can (and should) be versioned: configuration of switches and routers (Ansible, Terraform), rack capacity and allocation (Terraform + custom scripts), UPS/PDU policies (manufacturer APIs), and documentation as code (Markdown + Git).
What is difficult to version: physical cabling, room layout, point-to-point connections. These still depend on manually maintained diagrams, but at least they can reference versioned files.
Tools by layer
- Network layer: Ansible is the standard for switch configuration (Cisco, Arista, Juniper). Terraform for abstraction of VLANs, routing, and ACLs in multi-vendor.
- Compute layer: Terraform to provision VMs and bare metal. Ansible for post-installation configuration. Packer for reproducible base images.
- Power and environmental layer: manufacturer APIs (APC, Vertiv, Schneider) allow querying and controlling PDUs, UPS, sensors. Terraform providers exist for the main ones.
- Documentation: versioned documentation in Git (Markdown or AsciiDoc) is always better than loose Word/PDF documents. ‘Documentation drift’ is combated with CI.
The most expensive mistake that is repeated
Having the documentation in a Word document on a single laptop of the owner. When that person leaves, the documentation leaves with them. The migration to a new operator takes months and mistakes are made.
The solution is not just to move to Git: it is to make changes to the infrastructure REQUIRE a commit. Without that culture, Git becomes another repository that nobody maintains.
How to introduce IaC without breaking operation
Three recommended phases: 1) document the current state with discovery tools (Device42, netbox, RVTools), 2) write the configuration as code for critical components, 3) introduce GitOps where changes go through PR and review before being applied.
The secret is to start with the most stable (core switch configuration) before the most dynamic (daily VLAN changes). The dynamic requires more maturity from the team.
GitOps for physical infrastructure: what it looks like
A typical change: the operator needs to add a VLAN. In the traditional model, they edit the switch via SSH. In GitOps, they open a PR with the change, another operator reviews, the PR is merged, and a bot applies the change to the switch via IaC.
The change remains in the repo history. If something fails, the rollback is to revert the commit. If a new operator arrives, the repo is the complete documentation.
Concrete benefits
- Reduction of change time: what previously took a maintenance window now takes a PR.
- Automatic audit: each change has an author, date, and review.
- Reproducibility: spinning up a new DC (DR, expansion) takes hours instead of weeks.
- Operational continuity: knowledge does not leave when the operator leaves.
When it is NOT suitable
In very small operations (a single operator, stable infrastructure for years), IaC is overhead without return. In operations with high staff turnover or constant growth, it is indispensable.
The approximate threshold: when you have 3+ switches, 2+ operators, or change configuration more than once a month, IaC already justifies its cost.
Sources
[1] Ansible Network Automation — Cisco and multi-vendor documentation — https://docs.ansible.com/ansible/latest/network/
[2] Terraform — Infrastructure as Code (HashiCorp) — https://developer.hashicorp.com/terraform
[3] NetBox — Open source infrastructure management — https://github.com/netbox-community/netbox
[4] GitLab — GitOps for infrastructure — https://about.gitlab.com/topics/gitops/
