Cloud & DevOps

Terraform & Infrastructure as Code

Intermediate 7 modules • 18 hours •59 € VAT included

Curso orientado a gestionar infraestructura de forma declarativa con Terraform, entendiendo no solo la sintaxis de HCL sino también el valor real de plan, state, backends remotos, módulos, variables, colaboración y gobierno de IaC.

Terraform permite describir infraestructura como código y reconciliar lo declarado con el estado real de recursos. El valor práctico no está únicamente en ejecutar `terraform apply`, sino en trabajar con un workflow seguro, predecible y colaborativo. Este curso cubre desde fundamentos y providers hasta diseño modular, estado remoto, drift, seguridad y un proyecto final orientado a operación real.

The first module is free. Request information about full-course access.

Please note: the course material (modules, exam, glossary and labs) is written in Spanish. Only the site interface is available in English. A good reading level of Spanish is required.

On sale soon. The first module is free: sign up and start.

hola@itlabcert.com

Request received. We will reply to your email within 48 working hours. No need to send it again.

For myself For my company or team

I have read and accept the privacy policy. We will only use your data to reply to you.

hola@itlabcert.com

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:

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.
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.
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

Concepto	Significado
Declarativo	Describes estado final, no pasos detallados de ejecución
Provider	Plugin que traduce configuración a una API o plataforma
Resource	Objeto gestionado por Terraform
Plan	Vista previa de adiciones, cambios o destrucciones

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.

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.

What you will learn

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.

Module contents

Desarrollo teorico
Contenido ampliado
Puntos clave
Checklist operativa
Errores frecuentes
Practica sugerida
Preguntas de autoevaluacion
Cierre