Gestionar infraestructura de forma manual ha sido la norma durante decadas: un administrador accede a un panel web o una consola SSH, crea una maquína virtual, configura la red, monta un disco y repite el proceso para cada servidor nuevo. El problema es que este enfoque no escala, no es reproducible y es propenso a errores humanos. Cuando tienes 5 servidores es manejable; cuando tienes 50 o 500, cada cambio manual se convierte en un riesgo operativo.
Infrastructure as Code (IaC) resuelve este problema definiendo la infraestructura en ficheros de texto versionables, revisables y ejecutables de forma automática. Y dentro del ecosistema IaC, Terraform de HashiCorp se ha convertido en el estándar de facto para el aprovisionamiento de infraestructura en entornos cloud, on-premise e hibridos.
En este artículo explicamos que es IaC, como funciona Terraform, su lenguaje HCL, los providers más relevantes, la gestión de estado, los modulos, una comparativa con otras herramientas y las buenas prácticas para automatizar infraestructura de produccion.
Que es Infrastructure as Code
Infrastructure as Code es la práctica de definir y gestionar infraestructura (servidores, redes, almacenamiento, firewalls, DNS, balanceadores) mediante código fuente en lugar de procesos manuales. Los ficheros de configuración describen el estado deseado de la infraestructura, y una herramienta de IaC se encarga de crear, modificar o destruir los recursos necesarios para alcanzar ese estado.
Los beneficios fundamentales de IaC son la reproducibilidad (el mismo código produce el mismo entorno cada vez), la auditabilidad (cada cambio queda registrado en el control de versiones), la velocidad (desplegar un entorno completo tarda minutos, no días) y la eliminación del drift (la infraestructura real coincide siempre con lo que describe el código).
IaC se divide en dos grandes enfoques: el declarativo (describes el estado final y la herramienta calcula los pasos) y el imperativo (describes paso a paso lo que hay que hacer). Terraform sigue el enfoque declarativo, lo que simplifica enormemente la gestión de infraestructura compleja.
Que es Terraform
Terraform es una herramienta open source de Infrastructure as Code creada por HashiCorp en 2014. Permite definir infraestructura en un lenguaje declarativo llamado HCL (HashiCorp Configuration Language), planificar los cambios antes de aplicarlos y ejecutarlos de forma segura y repetible contra cualquier proveedor de infraestructura.
El flujo de trabajo de Terraform se basa en tres comandos principales: terraform init (inicializa el directorio de trabajo y descarga los providers necesarios), terraform plan (calcula la diferencia entre el estado actual y el estado deseado, mostrando que recursos se crearan, modificaran o destruiran) y terraform apply (ejecuta los cambios planificados contra la API del proveedor).
Lo que diferencia a Terraform de otras herramientas es su arquitectura basada en providers: plugins que conectan Terraform con las APIs de cada plataforma. Existen providers para AWS, Azure, GCP, Proxmox, VMware, Cloudflare, GitHub, Kubernetes y cientos de servicios más. Esto convierte a Terraform en una herramienta verdaderamente multi-cloud y multi-plataforma.
HCL: El Lenguaje de Terraform
HCL (HashiCorp Configuration Language) es un lenguaje declarativo diseñado para ser legible tanto por humanos como por maquínas. A diferencia de JSON o YAML, HCL soporta variables, funciones, expresiones condicionales, bucles y referencias entre recursos, lo que permite definir infraestructura compleja de forma concisa y mantenible.
Los bloques fundamentales de HCL son: resource (define un recurso de infraestructura como una VM, un disco o una regla de firewall), variable (parametros de entrada reútilizables), output (valores exportados tras la ejecucion), data (consultas de datos existentes en el proveedor) y locals (variables calculadas internas). Un fichero típico de Terraform combina estos bloques para describir un entorno completo.
Concepto clave:
Terraform es declarativo: tu defines QUE infraestructura quieres (3 VMs con 8 GB de RAM y disco NVMe) y Terraform calcula COMO llegar a ese estado. Si ya existen 2 VMs, solo creara la tercera. Si una tiene 4 GB, la actualizara a 8 GB. No necesitas escribir la lógica de cambio.
Providers: Proxmox, AWS, Azure y Más
Los providers son el corazon de la extensibilidad de Terraform. Cada provider traduce los bloques resource de HCL en llamadas API contra la plataforma correspondiente. Los más relevantes para entornos de infraestructura empresarial son:
- dns Proxmox (bpg/proxmox): permite crear y gestionar maquínas virtuales, contenedores LXC, pools de almacenamiento y redes en clusters Proxmox VE. Ideal para automatizar infraestructura on-premise con el mismo flujo que se usa en cloud pública.
- cloud AWS (hashicorp/aws): el provider más maduro del ecosistema, con soporte para EC2, S3, RDS, VPC, Lambda, EKS y cientos de servicios AWS. Permite gestionar infraestructura cloud pública completa desde código.
- cloud Azure (hashicorp/azurerm): soporte completo para Azure Resource Manager, incluyendo VMs, redes virtuales, Azure Kubernetes Service, bases de datos y servicios de almacenamiento.
- settings Otros: GCP, Cloudflare (DNS, WAF), Kubernetes, Helm, Vault, GitHub, GitLab, Datadog, PagerDuty. Terraform puede gestionar no solo infraestructura, sino también configuración de servicios, monitorización y control de acceso.
La capacidad de combinar multiples providers en un mismo proyecto es lo que hace de Terraform la herramienta ideal para entornos hibridos: puedes definir VMs en Proxmox on-premise, registros DNS en Cloudflare y buckets S3 en AWS dentro del mismo fichero de configuración, con dependencias automáticas entre recursos.
Gestión de Estado (State)
Terraform mantiene un fichero de estado (state) que registra la correspondencia entre los recursos definidos en el código y los recursos reales creados en el proveedor. Este state es fundamental para que Terraform pueda calcular las diferencias entre el estado actual y el deseado, y planificar los cambios necesarios.
Por defecto, el state se almacena en un fichero local (terraform.tfstate), pero en entornos de produccion con multiples operadores es imprescindible usar un backend remoto: S3 + DynamoDB para locking, Azure Blob Storage, Google Cloud Storage o Terraform Cloud. El backend remoto garantiza que dos personas no ejecuten terraform apply simultaneamente, evitando conflictos y corrupción del estado.
Buenas prácticas de gestión de estado incluyen: nunca editar el state manualmente, usar terraform state para operaciones de refactoring, habilitar cifrado en reposo del backend (el state puede contener credenciales) y separar el state por entorno (dev, staging, production) mediante workspaces o directorios independientes.
Modulos: Infraestructura Reútilizable
Los modulos de Terraform son paquetes de configuración reútilizables que encapsulan un conjunto de recursos relacionados. Un modulo puede definir, por ejemplo, una VM completa con su disco, red, firewall y DNS, y exponerlo como un componente parametrizable que se invoca con variables de entrada.
La ventaja principal de los modulos es la estandarizacion: en lugar de que cada equipo defina sus recursos de forma diferente, un modulo compartido garantiza que todas las VMs de produccion sigan el mismo patron de configuración (sizing, etiquetado, políticas de backup, reglas de firewall). Además, los modulos se versionan, lo que permite actualizar la configuración base sin romper los despliegues existentes.
El Terraform Registry alberga miles de modulos públicos mantenidos por la comunidad y por los propios proveedores. También es posible crear registros privados para modulos internos de la organización, distribuyendolos a traves de repositorios Git o Terraform Cloud.
Tabla Comparativa: Terraform vs Ansible vs Pulumi vs CloudFormation
La siguiente tabla compara las herramientas de IaC más útilizadas en entornos de produccion:
| Criterio | Terraform | Ansible | Pulumi | CloudFormation |
|---|---|---|---|---|
| Enfoque | Declarativo (HCL) | Imperativo (YAML playbooks) | Declarativo (Python, Go, TS) | Declarativo (JSON/YAML) |
| Multi-cloud | Si, +3.000 providers | Si, via modulos | Si, mismos providers que TF | No, solo AWS |
| Gestión de estado | State file (local o remoto) | Sin estado (agentless) | State file (similar a TF) | Gestionado por AWS |
| Foco principal | Aprovisionamiento de infra | Configuración de servidores | Aprovisionamiento de infra | Aprovisionamiento AWS |
| Curva aprendizaje | Media (HCL es sencillo) | Baja (YAML familiar) | Media-alta (requiere programacion) | Media (verboso en JSON) |
| On-premise | Si (Proxmox, VMware, bare metal) | Si (SSH nativo) | Si (mismos providers) | No |
En la práctica, Terraform y Ansible se complementan: Terraform aprovisiona la infraestructura (crea VMs, redes, discos) y Ansible configura el software dentro de esas maquínas (instala paquetes, configura servicios, gestiona usuarios). Muchos equipos usan ambas herramientas juntas en su pipeline de despliegue.
Buenas Prácticas con Terraform
- check_circle Versionado en Git: todo el código Terraform debe estar en un repositorio Git. Cada cambio de infraestructura se revisa en un pull request antes de aplicarse, igual que el código de aplicación.
- check_circle Backend remoto con locking: usar S3 + DynamoDB, Azure Blob o Terraform Cloud como backend para evitar ejecuciones concurrentes y perdida de estado.
- check_circle Separación por entorno: usar workspaces o directorios independientes para dev, staging y production, evitando que un error en desarrollo afecte a produccion.
- check_circle Modulos versionados: encapsular patrones repetidos en modulos con versionado semántico. Un cambio en el modulo base se propaga de forma controlada.
-
check_circle
Plan antes de apply: siempre ejecutar
terraform plany revisar los cambios antes de aplicarlos. En CI/CD, el plan se ejecuta automáticamente en el PR y el apply solo tras la aprobacion. - check_circle No hardcodear secretos: usar variables de entorno, Vault o el mecanismo de secretos del CI/CD para credenciales. Nunca incluir passwords o API keys en los ficheros .tf.
Terraform para Infraestructura On-Premise
Aunque Terraform se asocia frecuentemente con cloud pública, su valor en entornos on-premise es igual de relevante. Con el provider de Proxmox, Terraform puede crear maquínas virtuales, asígnar recursos de CPU, RAM y almacenamiento, configurar redes VLAN y gestionar contenedores LXC directamente contra la API de Proxmox VE, el hipervisor que útiliza EasyDataHost en sus servidores enterprise.
Esto significa que un equipo puede gestionar su datacenter privado con las mismas prácticas de IaC que usa en AWS o Azure: código versionado, plan antes de apply, modulos reútilizables y pipeline de CI/CD. La diferencia entre aprovisionar una VM en cloud pública o en un cluster Proxmox local se reduce a cambiar el bloque provider en el fichero de configuración.
Además, Terraform permite gestionar entornos hibridos en un solo proyecto: VMs en Proxmox on-premise para las cargas de trabajo sensibles, con backups automatizados en cloud y DNS gestionado en Cloudflare. Todo definido en el mismo repositorio y ejecutado con un único terraform apply.
Ventaja práctica:
Con Terraform + Proxmox, puedes definir toda tu infraestructura on-premise en código: VMs, redes, almacenamiento, firewall. Un nuevo entorno de staging se despliega en minutos con un solo comando, identico a produccion. Se acabaron los entornos que "se parecen" a produccion.
EasyDataHost y la Automatización de Infraestructura
En EasyDataHost aplicamos los principios de Infrastructure as Code en la gestión de nuestra propia plataforma y en los servicios gestionados que ofrecemos a nuestros clientes. Terraform es una pieza central de nuestro stack de automatización, junto con Ansible para la configuración de servidores y pipelines de CI/CD para la entrega continua.
Para los clientes que necesitan automatizar su infraestructura, ofrecemos consultoria y despliegue de Terraform sobre Proxmox, incluyendo el diseño de modulos personalizados, la configuración de backends remotos seguros, la integración con pipelines de CI/CD y la formacion del equipo técnico. El objetivo es que cada cliente pueda gestionar su infraestructura como código, con la misma fiabilidad y repetibilidad que exige un entorno de produccion.
- check_circle Automatización Proxmox: aprovisionamiento de VMs, redes y almacenamiento via Terraform contra la API de Proxmox VE.
- check_circle Modulos personalizados: modulos Terraform adaptados a la arquitectura y las políticas de seguridad de cada cliente.
- check_circle CI/CD integrado: pipelines automatizados donde cada cambio de infraestructura pasa por plan, revisión y apply controlado.
- check_circle Datos en España: toda la infraestructura gestionada reside en nuestro datacenter Tier III+ en Madrid, con soberania de datos garantizada.
Conclusión
Infrastructure as Code no es una moda: es la evolucion natural de la gestión de infraestructura en un mundo donde la velocidad, la reproducibilidad y la fiabilidad son requisitos no negociables. Terraform se ha consolidado como la herramienta de referencia para IaC gracias a su enfoque declarativo, su ecosistema de providers multi-cloud y su capacidad de gestionar infraestructura on-premise y cloud con el mismo flujo de trabajo.
- arrow_right IaC define infraestructura en código versionable, reproducible y auditable.
- arrow_right Terraform usa HCL declarativo con +3.000 providers para cloud, on-premise e hibrido.
- arrow_right La gestión de estado y los modulos permiten escalar la automatización de forma segura.
- arrow_right Terraform + Proxmox lleva las prácticas de IaC al datacenter on-premise con el mismo flujo que en cloud pública.
- arrow_right EasyDataHost ofrece automatización con Terraform sobre Proxmox, modulos personalizados y CI/CD integrado.
Si quieres automatizar tu infraestructura con Terraform o necesitas ayuda para implementar IaC en tu entorno, contacta con nuestro equipo para disenar la solución que mejor se adapte a tus necesidades.