Antes de escribir tu primera configuración real, es fundamental entender el modelo mental con el que trabaja Terraform. Sin este fundamento conceptual, los comandos y los archivos de configuración parecen arbitrarios. Con él, todo cobra sentido inmediatamente.

En esta lección aprenderás los cuatro pilares conceptuales de Terraform (proveedores, recursos, estado y el ciclo plan/apply), los comandos que usarás a diario, y la estructura de archivos que Terraform crea en tu directorio de trabajo.

Un proveedor es un plugin que Terraform usa para comunicarse con una plataforma externa. Cada proveedor expone un conjunto de recursos y fuentes de datos que Terraform puede gestionar.

Piensa en los proveedores como "adaptadores": Terraform habla un lenguaje universal (HCL), y los proveedores hacen de traductores entre ese lenguaje y las APIs específicas de cada plataforma.

Los proveedores se distribuyen a través del Terraform Registry (registry.terraform.io). Existen tres categorías:

• Oficial: Desarrollados y mantenidos por HashiCorp (AWS, Azure, GCP, Kubernetes...)
• Partner: Desarrollados y mantenidos por empresas que se han asociado con HashiCorp (Datadog, MongoDB, PagerDuty...)
• Community: Desarrollados y mantenidos por la comunidad (cualquier persona puede publicar un proveedor)

Cada proveedor tiene su propia configuración. El proveedor de AWS necesita región y credenciales. El proveedor local (para archivos locales) no necesita ninguna configuración especial porque no accede a ningún servicio externo.

Un recurso representa un componente de infraestructura que Terraform crea, gestiona y destruye. Es el elemento más fundamental en Terraform.

Ejemplos de recursos:

• Una instancia EC2 en AWS
• Un grupo de recursos en Azure
• Una tabla en DynamoDB
• Un registro DNS en Route53
• Un archivo en el sistema de archivos local
• Un repositorio en GitHub

Desglose de cada parte:

• resource: palabra clave que indica que este bloque define un recurso
• "tipo_del_recurso": cadena en formato <proveedor>_<tipo> que identifica exactamente qué tipo de infraestructura crear (por ejemplo, aws_instance, azurerm_resource_group, local_file)
• "nombre_local": un nombre que tú eliges, usado para referenciar este recurso desde otros lugares del código. Solo existe dentro de Terraform, no se usa para nombrar el recurso en la plataforma externa.
• El bloque { } contiene los argumentos que configuran el recurso. Qué argumentos están disponibles y cuáles son obligatorios depende de cada tipo de recurso.

Los recursos pueden referenciarse entre sí usando la sintaxis <tipo>.<nombre>.<atributo>:

Terraform detecta automáticamente esta dependencia y crea el VPC antes que la subred.

El estado (state) es el mecanismo que Terraform usa para rastrear qué infraestructura existe en el mundo real. Se almacena en un archivo llamado terraform.tfstate en formato JSON.

El estado es el puente entre tu configuración (lo que quieres) y la realidad (lo que existe). Sin el estado, Terraform no sabría:

• Qué recursos ya ha creado
• Cuáles son los IDs reales asignados por el proveedor (como el ID de una instancia EC2)
• Qué atributos tienen los recursos para que otros recursos puedan referenciarlos

Considera este escenario: creas una instancia EC2 con Terraform. AWS le asigna automáticamente el ID i-0123456789abcdef0. Si luego quieres modificar esa instancia (cambiar el tipo), Terraform necesita saber que el recurso llamado aws_instance.servidor_web en tu código corresponde a la instancia con ID i-0123456789abcdef0 en AWS. Esa información está en el estado.

Advertencia importante: Nunca edites el archivo terraform.tfstate manualmente. Si necesitas modificar el estado, usa los comandos terraform state que veremos más adelante. Editar el archivo a mano puede dejarlo en un estado inconsistente y corromper tu infraestructura.

terraform plan lee tu configuración y el estado actual, calcula qué cambios son necesarios y los muestra, pero no ejecuta nada. Es completamente seguro ejecutarlo en cualquier momento.

La salida del plan usa un sistema de símbolos:

Ejemplo de salida de terraform plan:

El (known after apply) aparece en atributos que solo se conocen después de crear el recurso (como el ID que asigna AWS).

terraform apply ejecuta los cambios planificados. Por defecto, muestra el plan y pide confirmación antes de proceder:

Para automatización (en CI/CD), puedes usar el flag -auto-approve para omitir la confirmación:

Consejo: Nunca uses -auto-approve en entornos de producción a menos que tengas muy claro lo que va a ocurrir. El paso de confirmación es una salvaguarda importante.

terraform init

Lo que hace terraform init:

1. Lee los bloques terraform {} y required_providers {} del código
2. Descarga los proveedores necesarios al directorio .terraform/providers/
3. Descarga los módulos externos al directorio .terraform/modules/
4. Crea (o migra) el backend de estado
5. Genera el archivo .terraform.lock.hcl con los hashes exactos de los proveedores

terraform plan

terraform destroy

Cuando ejecutas terraform init, Terraform crea un directorio oculto llamado .terraform en tu directorio de trabajo. Este directorio contiene:

Junto con el directorio .terraform, terraform init también crea (o actualiza) el archivo .terraform.lock.hcl:

El propósito del lockfile es garantizar que todos los miembros del equipo y los pipelines de CI/CD usen exactamente la misma versión del proveedor, incluso si hay nuevas versiones disponibles.

Regla de oro: Agrega .terraform/ a tu .gitignore (no commitear los binarios de proveedores), pero sí commitea .terraform.lock.hcl (garantiza reproducibilidad del entorno).

Terraform construye automáticamente un grafo de dependencias dirigido acíclico (DAG) entre los recursos. Este grafo determina en qué orden crear, modificar o destruir los recursos.

Cuando un recurso referencia un atributo de otro recurso, Terraform detecta automáticamente la dependencia:

Terraform creará estos recursos en orden: VPC → Subred → Instancia.

A veces dos recursos están relacionados lógicamente pero Terraform no puede detectar la dependencia automáticamente. En ese caso usas depends_on:

Para cada uno de los siguientes escenarios, indica qué comando o comandos de Terraform deberías usar y explica por qué.

Escenario A: Acabas de clonar un repositorio de Terraform de tu empresa por primera vez y quieres empezar a trabajar.

Escenario B: Has modificado el tipo de instancia de un servidor de t2.micro a t2.small en el archivo .tf y quieres ver exactamente qué va a cambiar antes de aplicarlo.

Escenario C: Tu compañero menciona que cambió manualmente el nombre de un bucket S3 desde la consola web de AWS. Quieres que el estado de Terraform refleje ese cambio.

Escenario D: Necesitas destruir únicamente un recurso específico (una base de datos de prueba) sin tocar el resto de la infraestructura.

Escenario E: Quieres ver qué recursos gestiona actualmente Terraform y cuáles son sus IDs reales.

Escenario F: Antes de commitear tus cambios, quieres asegurarte de que el código HCL no tiene errores de sintaxis y está bien formateado.

Escenario A:

Siempre debes ejecutar terraform init antes de cualquier otra operación en un directorio de trabajo nuevo o clonado.

Escenario B:

terraform plan es la herramienta perfecta para previsualizar cambios. Mostrará que el recurso será modificado (~) con el cambio de t2.micro a t2.small.

Escenario C:

refresh actualiza el estado con los valores actuales del proveedor sin crear ni modificar recursos.

Escenario D:

El flag -target permite destruir solo el recurso especificado. El resto de la infraestructura no se ve afectada.

Escenario E:

Escenario F:

Error: Error: Inconsistent dependency lock file

Causa: Has agregado o cambiado un proveedor pero no has ejecutado terraform init.

Un principiante ejecuta terraform apply directamente sin revisar el plan. El apply muestra el plan y pide confirmación, pero muchos escriben yes sin leerlo. Esto puede resultar en la destrucción accidental de recursos.

Buena práctica: Separa siempre el plan del apply:

El estado es un archivo JSON y es tentador editarlo directamente. Nunca lo hagas. Usa los comandos terraform state:

El archivo de estado puede contener información sensible (contraseñas, claves API). No debes commitearlo en repositorios públicos. Usa siempre un backend remoto (como S3, Terraform Cloud, etc.) para el estado.

En tu .gitignore:

Algunos principiantes piensan que terraform plan es solo un paso opcional. En realidad, siempre debes revisar el plan antes de aplicar, especialmente en producción. Un plan te puede mostrar que vas a destruir un recurso que no querías destruir.

En esta lección has aprendido los cuatro pilares conceptuales de Terraform:

• Proveedores: Plugins que conectan Terraform con plataformas externas (AWS, Azure, GitHub...). Se declaran en el bloque required_providers y se configuran con el bloque provider.
• Recursos: La unidad básica de infraestructura. Se declaran con el bloque resource "tipo" "nombre" y representan un componente concreto (un servidor, una base de datos, un archivo).
• Estado: El archivo terraform.tfstate que mantiene el mapa entre tu configuración y la infraestructura real. Es el corazón de Terraform y nunca debe editarse manualmente.
• Plan vs Apply: terraform plan muestra qué va a cambiar sin ejecutar nada. terraform apply ejecuta los cambios. Siempre revisa el plan antes de aplicar.

También has aprendido los comandos principales (init, plan, apply, destroy, show, state, validate, fmt) y cuándo usar cada uno, así como la estructura de archivos que Terraform crea en tu directorio de trabajo.

En la siguiente lección pondrás todo esto en práctica creando tu primera configuración real de Terraform: crearás archivos en tu sistema local usando el proveedor hashicorp/local, sin necesidad de credenciales de nube, y ejecutarás el ciclo completo init → plan → apply → show → destroy.