Índice8
Un servidor instalado hace tres años ha vivido lo suyo: un paquete añadido una noche de avería, un ajuste cambiado para un cliente, un servicio lanzado a mano y nunca documentado. Funciona, y nadie sabría rehacerlo idéntico. El día que desaparece, la reconstrucción empieza con una investigación. La infraestructura como código parte del otro extremo: el servidor se describe en archivos, y lo que se modifica es la descripción, no la máquina. Forma parte de las piezas de nuestra guía de la base de infraestructura en la nube.
En resumen
- La infraestructura como código describe la infraestructura en archivos versionados, revisados y reproducibles, en lugar de configurarla a mano.
- Microsoft la presenta como la respuesta a la deriva de los entornos: servidores «copo de nieve», únicos e imposibles de reproducir.
- Para la empresa, sirve ante todo para la recuperación ante desastres, la trazabilidad de los cambios y la libertad de cambiar de proveedor de alojamiento.
- Las herramientas se ordenan por capa: los recursos (Terraform, OpenTofu, Pulumi), la configuración de las máquinas (Ansible, cloud-init), los servicios (Docker Compose).
- Reconstruye la máquina, no los datos: las copias de seguridad y la caja fuerte de secretos siguen siendo imprescindibles.
Lo que significa «infraestructura como código»
Definición
La infraestructura como código
La práctica que consiste en describir servidores, redes, permisos de acceso y servicios en archivos de texto, guardados en un repositorio como el código, y dejar que una herramienta aplique esa descripción.
Microsoft resume el principio en su presentación de la infraestructura como código:
Del mismo modo que un mismo código fuente genera siempre el mismo binario, un modelo de IaC genera el mismo entorno cada vez que se despliega.
El mismo texto nombra el problema que resuelve: sin ella, cada entorno se convierte con el tiempo en un «copo de nieve» (en el original, «snowflake»), una configuración única que ya no se sabe reproducir automáticamente. Insiste en la idempotencia: un comando de despliegue lleva siempre el entorno al mismo estado, sea cual sea su punto de partida. Y en el método: para cambiar algo, el equipo modifica la fuente, no el destino.
Lo que cambia para la empresa
La ventaja no es técnica. Se ve en cuatro situaciones que toda empresa acaba viviendo.
- El servidor perdido. Avería de hardware, error de manipulación, cuenta suspendida: con una descripción al día, la reconstrucción sigue una receta en lugar de una memoria. Es la parte de «relanzar» del plan de recuperación ante desastres.
- El cambio revisado. Una modificación de la infraestructura sigue el mismo camino que una modificación de código: propuesta, revisada, aplicada, conservada en el historial. Se sabe quién abrió qué puerto, cuándo y por qué.
- La copia de prueba. El mismo archivo crea un entorno de pruebas idéntico a la producción, el tiempo de probar una actualización, y luego lo elimina.
- La puerta de salida. Una infraestructura descrita se traslada más fácilmente a otro proveedor de alojamiento: se sabe exactamente qué hay que volver a crear. Es una ventaja en una migración a la nube sin romperlo todo como en una reflexión sobre la dependencia de la nube estadounidense.
El camino de un cambio de infraestructura
- La propuesta
La modificación se escribe en el archivo.
- La revisión
Otra persona la lee, y la herramienta muestra lo que va a cambiar.
- La aplicación
La herramienta lleva la infraestructura al estado descrito.
- El historial
La modificación queda fechada, firmada, reversible.
Los administradores de sistemas no desaparecen en el proceso: son ellos quienes escriben la descripción, la revisan y deciden lo que contiene. Su saber simplemente deja de vivir en una sola cabeza.
Las herramientas, capa por capa
Ninguna herramienta lo hace todo. Se ordenan según lo que describen.
- Los recursos. Máquinas, redes, registros DNS, cuentas de almacenamiento, en uno o varios proveedores. Terraform es la herramienta más extendida; OpenTofu es un derivado libre de ella; Pulumi describe los mismos recursos en un lenguaje de programación. Cada gran nube tiene además su formato, como las plantillas ARM y Bicep en Microsoft Azure o CloudFormation en AWS.
- La configuración de las máquinas. Paquetes, usuarios, reglas de cortafuegos, archivos de configuración: Ansible aplica estos ajustes a una o varias máquinas, cloud-init los coloca en el primer arranque.
- Los servicios. En un servidor que ejecuta contenedores, un archivo Docker Compose describe cada servicio, sus volúmenes de datos, su red y su política de reinicio.
La licencia cuenta en la elección, porque ya cambió una vez:
- 10 de agosto de 2023
HashiCorp anuncia que sus productos, entre ellos Terraform, pasan de la licencia MPL 2.0 a la Business Source License, que prohíbe a los proveedores de servicios competidores integrar las versiones siguientes.
- Tras el anuncio
Varios editores crean OpenTofu, un derivado de Terraform bajo el amparo de la Linux Foundation, presentado como su sustituto directo.
Para una empresa que usa Terraform para sí misma, nada le impide seguir. La elección entre los dos se hace por la gobernanza y los proveedores compatibles, no por miedo a un pleito.
Lo que no reconstruye
Atención
La máquina, no los datos
La infraestructura como código vuelve a crear un servidor vacío y bien configurado. Los clientes del CRM, las facturas, los archivos subidos por los usuarios vienen de las copias de seguridad, y solo de ellas. Las contraseñas y las claves de API no tienen nada que hacer en los archivos de descripción: viven en una caja fuerte, a la que la descripción hace referencia sin contenerlas.
Reconstruir rápido no sirve de nada si los datos no siguen. Nuestra guía de las copias de seguridad de un servidor propio detalla cómo comprobar que una restauración funciona de verdad, y nuestro artículo sobre Postgres gestionado o autoalojado trata el caso de la base de datos. Para los secretos, véase la caja fuerte de secretos y las claves de API robadas.
Lo que hemos aprendido
Sobre el terreno
El 5 de julio de 2026, un comando de limpieza mal dirigido destruyó de golpe los contenedores de diez servicios en nuestro servidor. Los datos, guardados en volúmenes, se salvaron; nuestras reglas de explotación están ahora por escrito. La lección: lo que está descrito y separado de los datos se rehace, lo que solo vive en la máquina se pierde. El sitio que está leyendo aplica la misma idea: su configuración de alojamiento, sus redirecciones y sus cabeceras son archivos de su repositorio, y la puesta en línea se niega a salir si una página vive bajo una dirección redirigida.
Por dónde empezar, sin reescribirlo todo
Nadie necesita describir toda su infraestructura de una vez. El orden que antes rinde:
- Inventariar.
Cada servidor, cada servicio, cada registro DNS, y dónde viven sus datos.
- Describir primero los servicios.
Un archivo por servicio, con sus volúmenes de datos separados: es lo que se vuelve a crear más a menudo.
- Después la máquina.
Paquetes, usuarios, cortafuegos, proxy inverso, en una herramienta de configuración.
- Probar la reconstrucción.
En una máquina nueva, con una copia de seguridad real: el cronómetro dice si la receta funciona.
- Hacer pasar cada cambio por la descripción.
Una modificación hecha a mano en el servidor es una deuda; se traslada a los archivos ese mismo día.
El resto del proyecto
La infraestructura como código se aplica sea cual sea el lugar de alojamiento (servidor dedicado, VPS o nube) y no impone Kubernetes (cuándo una pyme no lo necesita). Hace visibles los recursos que cuestan (las partidas que inflan una factura de la nube), describe el proxy situado delante de los servicios (lo que protege Cloudflare) y se completa con una supervisión que avisa antes que los clientes. Se aplica también a las herramientas autoalojadas (n8n en producción, las herramientas que conviene sacar primero del SaaS, el coste de salir del SaaS a tres años) y a los servidores de IA (el hardware necesario). Los accesos del equipo (un gestor de contraseñas), el correo (Google, Microsoft o proveedor europeo) y las obligaciones de resiliencia (NIS2 en Francia) completan la base.
Nuestra salida del SaaS entrega sus herramientas instaladas en un servidor propio, con copias de seguridad fuera del servidor cuya restauración se ha probado y una documentación de explotación: 5.500 € y tres semanas.
Preguntas frecuentes
¿Es útil la infraestructura como código para un solo servidor?
Sí, y a menudo es ahí donde antes rinde. Un servidor único es un punto de fallo único: si desaparece, todo lo que funcionaba en él debe rehacerse. Describir sus servicios y su configuración en archivos convierte esa reconstrucción en un procedimiento conocido, que se puede probar de antemano en una máquina nueva. La ganancia no depende del número de máquinas.
Terraform u OpenTofu: ¿cuál elegir?
Los dos describen los mismos recursos con el mismo lenguaje; OpenTofu nació como derivado de Terraform tras el cambio de licencia de 2023. Una empresa que describe su propia infraestructura puede usar uno u otro. La elección se hace por la gobernanza del proyecto, los proveedores compatibles y las costumbres del equipo o del proveedor de servicios que la explotará.
¿Hay que describirlo todo antes de empezar?
No. Empiece por los servicios, con sus datos separados, luego la configuración de la máquina y después los recursos del proveedor. Cada etapa tiene valor por sí sola. Lo importante es probar la reconstrucción en una máquina nueva desde la primera etapa, y después hacer pasar cada cambio por los archivos y no por el servidor.
¿Sustituye la infraestructura como código a las copias de seguridad?
No. Vuelve a crear una máquina configurada, pero vacía. Los datos de sus herramientas, como las fichas de clientes, las facturas o los archivos subidos, solo vuelven mediante las copias de seguridad, siempre que se haya probado una restauración. Las dos se complementan: la descripción rehace el servidor, la copia de seguridad devuelve su contenido y el plan de recuperación dice en qué orden.
Fuentes
- Microsoft Learn, What is infrastructure as code? (nueva pestaña)learn.microsoft.com
- HashiCorp, anuncio del 10 de agosto de 2023 (nueva pestaña)hashicorp.com
- OpenTofu, sitio del proyecto (nueva pestaña)opentofu.org
Jim · fundador de Brain Plus AI
Más artículos sobre infraestructura y nube
Guía práctica14 min La guía del tema
Infraestructura en la nube: la base común de todos sus proyectos
Antes del primer proyecto, una base de infraestructura en la nube resuelve de una vez por todas las cuentas, los accesos, las copias de seguridad y el presupuesto, y cada proyecto siguiente la hereda. Qué contiene, dónde montarla, cuánto cuesta y por qué su explotación cuenta más que su instalación.
Entender7 min
Cloud and AI Development Act: triplicar los centros de datos
Presentada el 3 de junio de 2026, la Cloud and AI Development Act quiere triplicar la capacidad de los centros de datos europeos y crear una escala de soberanía en cuatro niveles para las compras públicas de nube. Lo que contiene la propuesta, en qué punto está la negociación y lo que sigue siendo válido para elegir un proveedor de alojamiento hoy.
Entender8 min
Data Act: fin de los costes de salida de la nube en enero de 2027
El 12 de enero de 2027, un proveedor cloud ya no podrá cobrar el cambio de proveedor, y los objetos conectados nuevos ya devuelven sus datos a su usuario. Lo que el Data Act le permite exigir, y lo que no hará en su lugar.