Modulo 01. IaC y fundamentos de Terraform

Objetivo del modulo

Comprender el modelo declarativo de Terraform y por qué IaC mejora repetibilidad, revisión y gobierno de la infraestructura.

Resultados esperados

• Explicar qué significa describir infraestructura de forma declarativa.
• Entender el papel de init, plan y apply.
• Distinguir IaC seria de simples scripts de provisión.

Desarrollo teorico

Infrastructure as Code (IaC) busca tratar la infraestructura con los mismos principios que el software: versionado en control de fuentes, revision por pares, repetibilidad, trazabilidad de cambios y automatizacion. En lugar de crear recursos manualmente a traves de consolas web o scripts ad hoc, IaC declara la infraestructura deseada en ficheros de configuracion que se almacenan en un repositorio y se aplican de forma controlada.

Por que IaC importa. Sin IaC, la infraestructura sufre de configuration drift (divergencia entre lo que se cree que existe y lo que realmente existe), falta de trazabilidad (quien cambio que y cuando), dificultad para reproducir entornos (el entorno de produccion no se puede replicar para pruebas) y dependencia de conocimiento tribal (solo una persona sabe como esta configurado el servidor). IaC resuelve estos problemas al convertir la infraestructura en un artefacto versionable, revisable y ejecutable de forma automatica.

Terraform y el enfoque declarativo. Terraform adopta un enfoque declarativo: defines el estado deseado de la infraestructura y la herramienta calcula como reconciliarlo con el estado actual. Esto lo diferencia de scripts puramente imperativos (Bash, PowerShell, Ansible ad hoc), donde se ejecutan pasos secuenciales sin un modelo claro del resultado final esperado. En el modelo declarativo, si declaras tres instancias EC2 y ya existen dos, Terraform crea solo una mas. Si borras una del fichero, Terraform la destruye. El fichero de configuracion es siempre la fuente de verdad.

HCL: el lenguaje de Terraform. Terraform usa HashiCorp Configuration Language (HCL), un lenguaje disenado para ser legible por humanos y facil de procesar por maquinas. No es un lenguaje de programacion completo, sino un DSL (Domain-Specific Language) para declarar infraestructura. Sus elementos basicos son bloques, argumentos y expresiones:

resource "aws_s3_bucket" "datos" {
  bucket = "empresa-datos-prod"
  tags = {
    Environment = "production"
    ManagedBy   = "terraform"
  }
}

Providers y recursos. Terraform no habla directamente con AWS, Azure o GCP. Los providers son plugins que traducen la configuracion HCL a llamadas API concretas de cada plataforma. Existen providers para centenares de servicios: AWS, Azure, GCP, Kubernetes, GitHub, Cloudflare, Datadog, PagerDuty y muchos mas. Un resource declara un objeto que Terraform gestionara a lo largo de su ciclo de vida (creacion, modificacion, destruccion).

El ciclo init, plan, apply. El flujo basico de trabajo tiene tres fases:

1. terraform init: Descarga e inicializa los providers necesarios, configura el backend de estado y prepara el directorio de trabajo. Se ejecuta una vez al empezar o cuando cambian providers o backend.
2. terraform plan: Compara la configuracion HCL con el state almacenado y con el estado real de la infraestructura, generando una propuesta de cambios. El plan muestra exactamente que recursos se van a crear, modificar o destruir. Este paso es critico porque actua como contrato de cambio: permite revisar impactos antes de tocar infraestructura real.
3. terraform apply: Ejecuta los cambios propuestos en el plan. Si se aprueba, Terraform crea, modifica o destruye los recursos necesarios y actualiza el fichero de estado.

Adicionalmente, terraform destroy elimina todos los recursos gestionados por la configuracion, y terraform fmt formatea el codigo HCL de forma estandar.

Terraform vs. otras herramientas de IaC. Terraform no es la unica opcion. AWS CloudFormation es nativo de AWS pero solo funciona en ese proveedor. Azure Bicep/ARM Templates es nativo de Azure. Pulumi permite usar lenguajes de programacion generales (Python, TypeScript, Go) en lugar de un DSL. Ansible es mas adecuado para gestion de configuracion que para aprovisionamiento de infraestructura. La fortaleza de Terraform es su naturaleza multi-cloud y multi-proveedor: una misma herramienta y sintaxis para gestionar recursos en AWS, Azure, GCP, Kubernetes y decenas de otros servicios.

State: la pieza invisible pero critica. Terraform necesita un fichero de estado (state) para recordar que recursos gestiona y mapear la configuracion HCL a los recursos reales en la plataforma. Sin el state, Terraform no sabe que existe y intentaria crear todo desde cero. El state se genera automaticamente con apply y se almacena por defecto en un fichero local (terraform.tfstate), aunque en equipos reales se centraliza en un backend remoto (S3, Azure Blob, GCS, Terraform Cloud) con bloqueo para evitar aplicaciones concurrentes.

Contenido ampliado

Puntos clave

• Terraform declara estado deseado, no secuencias manuales de clics.
• Plan es una pieza de control, no un simple paso intermedio.
• IaC aporta valor cuando se integra con revisión y versionado.

Checklist operativa

• Entender qué provider y recursos intervienen.
• Revisar siempre el plan antes de aplicar.
• Versionar el código de infraestructura.

Errores frecuentes

• Ejecutar apply sin leer cambios.
• Confundir Terraform con un script de shell largo.
• No tratar IaC como artefacto revisable de equipo.

Practica sugerida

Explica el ciclo init -> plan -> apply sobre un ejemplo sencillo de red y máquina virtual.

Preguntas de autoevaluacion

• ¿Qué diferencia hay entre declarativo e imperativo?
• ¿Por qué plan es tan importante en Terraform?
• ¿Qué gana un equipo al versionar infraestructura?

Cierre

Terraform aporta orden cuando la infraestructura deja de depender de cambios manuales y empieza a expresarse como un estado deseado revisable y repetible.

Modulo 02. Providers, recursos y ciclo plan/apply

Objetivo del modulo

Entender como Terraform traduce configuracion HCL a cambios reales sobre plataformas y servicios a traves de providers, y dominar el ciclo plan/apply como mecanismo de control.

Resultados esperados

• Identificar el papel de providers y recursos en la configuracion.
• Explicar dependencias y cambios detectados en un plan.
• Evitar aplicar cambios sin comprender su impacto.
• Distinguir entre update in-place y replacement forzado.

Desarrollo teorico

El provider es el puente entre Terraform y la plataforma destino. Cada provider (AWS, Azure, GCP, Kubernetes, GitHub, Cloudflare, PagerDuty o cualquier sistema con API) traduce la configuracion HCL a llamadas API concretas. Cuando configuras un recurso aws_instance, el provider de AWS sabe como hablar con la API de EC2 para crear, modificar o destruir esa instancia. Sin providers, Terraform seria un lenguaje sin efectos.

Configuracion de providers. Los providers se declaran en el bloque terraform y se configuran con credenciales y parametros de conexion:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-west-1"
}

La restriccion de version (~> 5.0) es importante: permite actualizaciones menores pero bloquea cambios mayores que podrian romper compatibilidad. En equipos profesionales se usa un .terraform.lock.hcl para fijar versiones exactas de providers, similar a un lockfile de dependencias en desarrollo.

Recursos y data sources. Un resource declara un objeto que Terraform gestionara (crear, modificar, destruir). Un data consulta informacion existente sin gestionarla. La diferencia es critica: un recurso entra en el ciclo de vida de Terraform; un data source solo lee.

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name = "vpc-produccion"
  }
}

data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"]
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
  }
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
  subnet_id     = aws_subnet.public.id
}

Grafo de dependencias. Terraform construye un DAG (directed acyclic graph) con las dependencias entre recursos. Si aws_instance.web referencia aws_subnet.public.id, Terraform sabe que debe crear la subnet antes que la instancia. Esto es automatico para referencias explicitas, pero a veces existen dependencias implicitas que requieren depends_on para forzar el orden.

El ciclo plan/apply en profundidad. terraform plan compara la configuracion actual con el state almacenado y con el estado real de la infraestructura (consultando a los providers). El resultado es una lista de acciones propuestas:

• + create: recurso nuevo que no existe en el state.
• ~ update in-place: modificacion de atributos que no requiere recreacion.
• -/+ replacement: destruccion y creacion porque un atributo inmutable cambio.
• - destroy: recurso que ya no esta en la configuracion.

La distincion entre update in-place y replacement es la fuente de mas incidentes con Terraform. Si cambias el ami de una instancia EC2, Terraform la destruye y crea una nueva porque ami es un atributo inmutable (force replacement). Si cambias un tag, lo actualiza in-place. Un operador que solo lee el resumen numerico ("1 to change") sin verificar el tipo de cambio puede destruir un servidor de produccion sin darse cuenta.

# Nunca aplicar sin leer el plan
terraform plan -out=plan.tfplan
# Revisar detenidamente el output
terraform apply plan.tfplan

Guardar el plan en un fichero (-out=plan.tfplan) y aplicar ese fichero exacto es una practica de seguridad esencial en produccion. Evita que cambios ocurridos entre plan y apply causen sorpresas.

Credenciales y aislamiento. Los providers necesitan credenciales para operar. Nunca deben hardcodearse en el fichero HCL. Las practicas recomendadas son variables de entorno, ficheros de credenciales protegidos, roles asumidos via IAM o integracion con vaults de secretos. Ademas, en equipos que gestionan multiples entornos (desarrollo, staging, produccion), cada entorno debe tener su propio provider configurado con credenciales y permisos aislados.

Contenido ampliado

Puntos clave

• Los providers son esenciales para traducir configuracion a accion real sobre cualquier API.
• El plan no solo cuenta recursos; describe el tipo exacto de impacto.
• Cambios pequenos en codigo pueden provocar recreaciones destructivas.
• Guardar el plan en fichero y aplicar ese fichero es practica obligatoria en produccion.
• Las credenciales nunca van en el codigo; se gestionan via variables de entorno o vaults.
• Fijar versiones de providers con lockfile evita cambios inesperados.

Checklist operativa

• Revisar recursos afectados y tipo de cambio (create, update, replace, destroy).
• Detectar cambios destructivos o recreaciones forzadas por atributos inmutables.
• Confirmar credenciales y provider correctos antes de aplicar.
• Guardar plan en fichero antes de apply en entornos de produccion.
• Verificar que el lockfile esta versionado con el resto del codigo.
• Revisar dependencias implicitas que puedan requerir depends_on.

Errores frecuentes

• Confiar solo en el resumen numerico del plan sin leer los detalles.
• No comprender la diferencia entre update in-place y replacement.
• Mezclar providers o credenciales sin aislar entornos.
• Hardcodear credenciales en ficheros HCL.
• No fijar versiones de providers y sufrir cambios inesperados tras actualizacion.
• Aplicar plan sin guardarlo en fichero en entornos criticos.

Practica sugerida

Crea una configuracion Terraform con un provider AWS que declare una VPC, una subnet y una instancia EC2. Ejecuta terraform plan, identifica cada cambio propuesto y su tipo. Luego modifica el ami de la instancia y observa como el plan cambia de update a replacement. Documenta que revisarias antes de aprobar ese plan en produccion.

Preguntas de autoevaluacion

• Que problema resuelve el provider y que pasa si no se configura correctamente.
• Por que un cambio de AMI fuerza recreacion mientras un cambio de tag no.
• Que revisarias antes de aplicar un plan sobre produccion.
• Que diferencia hay entre un resource y un data source.
• Por que guardar el plan en fichero antes de aplicar es una practica de seguridad.

Cierre

El verdadero control en Terraform aparece cuando entiendes como cada provider y recurso convierte tu codigo en cambios concretos y cuando distingues perfectamente un update inocuo de un replacement destructivo antes de pulsar apply.