Infraestructura como código (IaC) para data centers: del rack físico al repositorio

Infraestructura como código no es solo para cloud. Aplicada bien, elimina la dependencia de la memoria del operador para configurar switches, UPS, PDUs, e incluso la capacidad de racks. Aplicada mal, agrega complejidad sin retorno.

Qué se puede versionar y qué no

Lo que sí se puede (y conviene) versionar: configuración de switches y routers (Ansible, Terraform), capacidad y asignación de racks (Terraform + scripts personalizados), políticas de UPS/PDU (APIs del fabricante), y documentación como código (Markdown + Git).

Lo que es difícil de versionar: cableado físico, layout de sala, conexiones punto a punto. Estos siguen dependiendo de diagramas mantenidos manualmente, pero al menos pueden referenciar archivos versionados.

Herramientas por capa

1. Capa de red: Ansible es el estándar para configuración de switches (Cisco, Arista, Juniper). Terraform para abstracción de VLANs, routing, y ACLs en multi-vendor.
2. Capa de cómputo: Terraform para provisionar VMs y bare metal. Ansible para configuración post-instalación. Packer para imágenes base reproducibles.
3. Capa de energía y ambiente: APIs de los fabricantes (APC, Vertiv, Schneider) permiten consultar y controlar PDUs, UPS, sensores. Terraform providers existen para los principales.
4. Documentación: la documentación versionada en Git (Markdown o AsciiDoc) es siempre mejor que documentos Word/PDF sueltos. El ‘documentation drift’ se combate con CI.

El error más caro que se repite

Tener la documentación en un Word en una sola laptop del dueño. Cuando esa persona se va, la documentación se va con ella. La migración a un nuevo operador toma meses y se cometen errores.

La solución no es solo mover a Git: es hacer que los cambios a la infraestructura REQUIERAN commit. Sin esa cultura, Git se vuelve otro repositorio que nadie mantiene.

Cómo introducir IaC sin romper operación

Tres fases recomendadas: 1) documentar el estado actual con herramientas de descubrimiento (Device42, netbox, RVTools), 2) escribir la configuración como código para los componentes críticos, 3) introducir GitOps donde los cambios pasan por PR y revisión antes de aplicarse.

El secreto es empezar por lo más estable (configuración de switches core) antes de lo más dinámico (cambios diarios de VLAN). Lo dinámico requiere más madurez del equipo.

GitOps para infraestructura física: cómo se ve

Un cambio típico: el operador necesita agregar una VLAN. En el modelo tradicional, edita el switch vía SSH. En GitOps, abre un PR con el cambio, otro operador revisa, el PR se mergea, y un bot aplica el cambio al switch vía IaC.

El cambio queda en el historial del repo. Si algo falla, el rollback es revertir el commit. Si el operador nuevo llega, el repo es la documentación completa.

Beneficios concretos

1. Reducción de tiempo de cambio: lo que antes tomaba una ventana de mantenimiento ahora toma un PR.
2. Auditoría automática: cada cambio tiene autor, fecha, y revisión.
3. Reproducibilidad: levantar un DC nuevo (DR, expansión) toma horas en lugar de semanas.
4. Continuidad operativa: el conocimiento no se va cuando el operador se va.

Cuándo NO conviene

En operaciones muy pequeñas (un solo operador, infraestructura estable por años), IaC es overhead sin retorno. En operaciones con alta rotación de personal o crecimiento constante, es indispensable.

El umbral aproximado: cuando tienes 3+ switches, 2+ operadores, o cambias configuración más de una vez al mes, IaC ya justifica su costo.

Fuentes

[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/