La Infraestructura como Código (Infrastructure as Code, IaC) es la práctica de definir y gestionar la infraestructura —servidores, redes, bases de datos, balanceadores, reglas de seguridad— mediante ficheros de código versionados, en lugar de configurarla a mano por consolas web o comandos sueltos. Igual que el código de tu aplicación vive en un repositorio, la descripción de tu infraestructura también, con todo lo que eso aporta: control de versiones, revisión por pares, reproducibilidad exacta y automatización en pipelines. Importa porque elimina la configuración a mano (lenta, propensa a errores y no documentada), evita la "deriva de configuración" (que el entorno real se desvíe de lo esperado) y permite crear, replicar o destruir entornos completos en minutos de forma fiable. Esta lección cierra el módulo enseñándote los conceptos y las herramientas clave, con Terraform como ejemplo principal.

1. El problema que resuelve IaC.
2. Declarativo frente a imperativo.
3. Comparativa de herramientas: Terraform, CloudFormation y Ansible.
4. Idempotencia: el concepto central.
5. Ejemplo práctico con Terraform.
6. IaC en pipelines de CI/CD.
7. Errores comunes y consejos.
8. Ejercicios y soluciones.

La gestión manual de infraestructura (hacer clic en la consola del proveedor) tiene problemas graves: no es reproducible (montar el mismo entorno dos veces da resultados distintos), no queda documentada (nadie sabe por qué existe esa regla de firewall), no es revisable (no hay forma de revisar un cambio antes de aplicarlo) y produce deriva de configuración (drift): el entorno real diverge poco a poco de lo previsto. IaC convierte la infraestructura en código: una fuente de verdad única, versionada en Git, revisable mediante pull requests y aplicable de forma automática y repetible.

Hay dos enfoques para describir infraestructura:

• Imperativo: das instrucciones secuenciales ("crea un servidor, luego instala esto, luego abre este puerto"). Tú controlas el cómo.
• Declarativo: describes el estado final deseado ("quiero un servidor con estas características y este puerto abierto") y la herramienta averigua qué acciones hacen falta para alcanzarlo desde el estado actual. Es el enfoque dominante en IaC moderna por ser más robusto y fácil de razonar.

Distinción clave a menudo confundida: aprovisionar (crear la infraestructura: VMs, redes) frente a gestionar la configuración (instalar y configurar software dentro de las máquinas). Terraform y CloudFormation destacan en aprovisionar; Ansible destaca en configurar el interior de los servidores. Es muy común combinarlos: Terraform crea las máquinas y Ansible las configura. Terraform usa su propio lenguaje, HCL (HashiCorp Configuration Language); CloudFormation usa YAML/JSON y está atado a AWS.

Idempotencia significa que aplicar la misma operación una o muchas veces produce el mismo resultado final, sin efectos secundarios acumulativos. En IaC es fundamental: ejecutar terraform apply diez veces sobre una configuración que no ha cambiado no debe crear diez servidores, sino dejar el estado tal como está. La herramienta compara el estado deseado (tu código), el estado real (lo que existe en el proveedor) y su fichero de estado (lo que cree que gestiona), y solo aplica la diferencia (el plan). Gracias a la idempotencia, IaC es segura de re-ejecutar, lo que permite automatizarla en pipelines sin miedo a duplicar recursos.

Definamos una instancia de servidor y su grupo de seguridad en AWS con HCL. Terraform funciona en un ciclo: escribir el código, ver el plan (qué va a cambiar) y aplicar.

Explicación bloque a bloque:

• provider "aws": configura el proveedor y la región. Terraform descargará el plugin adecuado.
• variable "instance_type": declara un parámetro con valor por defecto t3.micro, que se puede sobrescribir por entorno (así reutilizas el mismo código en pruebas y producción).
• resource "aws_security_group" "web_sg": crea un grupo de seguridad (un firewall) que permite tráfico entrante (ingress) al puerto 80 desde cualquier IP (0.0.0.0/0).
• resource "aws_instance" "servidor_web": crea la máquina. instance_type = var.instance_type usa la variable. vpc_security_group_ids = [aws_security_group.web_sg.id] referencia al grupo anterior: Terraform detecta esta dependencia y crea primero el grupo de seguridad y luego la instancia, en el orden correcto. Las tags etiquetan el recurso.
• output "ip_publica": tras aplicar, Terraform mostrará la IP pública de la instancia.

El ciclo de trabajo en la terminal:

Explicación: terraform init prepara el directorio. terraform plan es el paso de seguridad clave: muestra exactamente qué va a cambiar antes de tocar nada, lo que permite revisarlo. terraform apply ejecuta el plan y converge al estado deseado (es idempotente: si nada cambió, no hace nada). terraform destroy elimina lo creado, muy útil para entornos de pruebas que se levantan y se tiran.

El verdadero poder de IaC aparece al integrarlo en un pipeline automatizado: cada cambio en la infraestructura pasa por revisión y se aplica solo. Un flujo típico con GitHub Actions:

Explicación: el pipeline se dispara en pull requests y en push a main. En un PR ejecuta terraform plan, de modo que los revisores ven el cambio propuesto en la infraestructura antes de aprobarlo (igual que se revisa código). Solo cuando el cambio se fusiona a main se ejecuta terraform apply -auto-approve, aplicando la infraestructura de forma automática. Así, la infraestructura se gobierna con el mismo rigor que el software: revisión, trazabilidad y despliegue automatizado. Esta práctica se conoce como GitOps cuando el repositorio Git es la fuente de verdad del estado deseado.

• No versionar el fichero de estado correctamente. El estado de Terraform es sensible y crítico: guárdalo en un backend remoto compartido (con bloqueo) y nunca lo subas en texto plano a Git, pues puede contener secretos.
• Editar a mano lo que gestiona IaC. Cambiar recursos por la consola provoca deriva: el código deja de reflejar la realidad. Cambia siempre por código.
• No revisar el plan antes de aplicar. terraform plan existe para evitar sorpresas (como destruir una base de datos sin querer). Léelo siempre.
• Secretos hardcodeados en el código IaC. Usa variables, gestores de secretos o variables de entorno; nunca incrustes credenciales en los .tf.
• Monolitos de IaC gigantes. Un único estado para toda la empresa es frágil y lento. Divide por entornos y dominios (módulos, workspaces).
• Consejo: trata la infraestructura como software desechable y reproducible. Si no puedes recrear un entorno desde cero con un comando, aún no tienes verdadera IaC. Recuerda que en sectores regulados los cambios de infraestructura pueden requerir controles y aprobaciones adicionales; valida el flujo con tu equipo de gobierno y compliance.

1. Explica con tus palabras qué significa que terraform apply sea idempotente y por qué eso es importante para ejecutarlo dentro de un pipeline.
2. Tu compañero ha cambiado a mano el tamaño de una instancia desde la consola del proveedor, pero el código IaC sigue con el valor antiguo. ¿Qué problema se produce y qué hará Terraform en el siguiente apply?
3. Quieres crear máquinas en la nube y, además, instalar y configurar software dentro de ellas. ¿Qué herramientas combinarías y qué rol tendría cada una?

1. Que terraform apply sea idempotente significa que aplicar la misma configuración una o varias veces deja el sistema en el mismo estado final: si nada ha cambiado en el código, no crea ni modifica recursos. Esto es importante en un pipeline porque permite ejecutarlo automáticamente y repetidamente sin miedo a duplicar infraestructura o provocar efectos acumulativos; siempre converge al estado deseado.
2. Se produce deriva de configuración (drift): el estado real diverge del declarado en el código. En el siguiente terraform plan/apply, Terraform detectará que el recurso real no coincide con el deseado y propondrá revertir el cambio manual para volver al valor del código (o mostrará la diferencia para que decidas). Por eso no se debe editar a mano lo que gestiona IaC.
3. Combinaría Terraform (o CloudFormation) para aprovisionar la infraestructura: crear las máquinas, redes y grupos de seguridad; y Ansible para la gestión de configuración: instalar paquetes, desplegar la aplicación y ajustar el sistema operativo dentro de esas máquinas. Terraform crea el "contenedor" físico/virtual y Ansible lo deja listo para funcionar.

Has aprendido qué es la Infraestructura como Código y por qué sustituye a la configuración manual: reproducibilidad, versionado y automatización. Distinguimos el enfoque declarativo del imperativo, comparamos Terraform, CloudFormation y Ansible, entendimos la idempotencia como concepto central, escribimos un ejemplo completo en Terraform y lo integramos en un pipeline de CI/CD con revisión del plan. Con esto cierras el Módulo 8 de Arquitectura en la Nube y Despliegue: ahora dispones de las piezas para diseñar, contenerizar, ejecutar (con o sin servidor) y aprovisionar aplicaciones cloud-native de principio a fin, listas para escalar y operar con fiabilidad en producción.