E179 - Intro a Terraform

Resumen

El episodio 179 de enCoders introduce Terraform, una herramienta de infraestructura como código (IaC) de HashiCorp que permite crear, modificar y destruir recursos en la nube (máquinas virtuales, buckets, redes) a partir de archivos declarativos. Se parte de los problemas de hacer infraestructura a mano (errores, falta de reproducibilidad) y de la ventaja de versionar todo con Git. Se contrasta el enfoque declarativo (Terraform: se define el estado final) con el imperativo (scripts que ejecutan pasos), y a Terraform con Ansible, que configura máquinas ya creadas. Luego se recorre un ejemplo en AWS (main, variables, tfvars, outputs, state) y el flujo init, fmt, validate, plan y apply, además de ejemplos en GCP (Firestore, BigQuery, Vertex) y organización por ambientes. Conclusiones: Terraform es agnóstico de la nube, el state debe guardarse en un backend remoto con locking para trabajo en equipo, y el `plan` sirve también como verificación automática en CI/CD.

Capítulos

• 00:00
  Bienvenida y qué es Terraform (infraestructura como código)Se presenta Terraform como herramienta para estandarizar la creación de ambientes en una nube escribiendo código. Se explica que en una nube hay máquinas virtuales, VPC, conexiones y reglas de acceso.
• 01:08
  El problema de hacer infraestructura a mano: reproducibilidad y erroresHacer el setup a mano es posible, pero reproducirlo exige documentar cada paso y es muy propenso a errores. Se propone aprovechar el enfoque de código para evitarlo.
• 02:49
  Automatización con scripts + control de versiones (la previa a Terraform)Un script `.sh` es reproducible y multiplataforma, y sirve también para encadenar scripts de un pipeline (con la salvedad del ambiente virtual y Docker). Tener código permite versionar cambios con Git (o Mercurial, SVN).
• 05:28
  Documentación técnica: Markdown vs Confluence/WordSe prefiere Markdown con Git para documentación técnica, porque evita mantener un log de cambios manual. Se reconoce que Word o Confluence pueden servir según el público; en Entel usaban Confluence con buenos resultados.
• 07:34
  Declarativo vs imperativo: dos enfoques de IaCEn el enfoque imperativo se dan instrucciones (por ejemplo, "crea una instancia EC2") que se repiten aunque ya exista. En el declarativo solo se define el estado final y el sistema determina qué hacer.
• 09:33
  Cómo funciona Terraform: archivos .tf, HCL y estado finalTerraform es declarativo y usa archivos `.tf` en el lenguaje de HashiCorp. Se define cada elemento con sus características, y con eso el objetivo final. Se aclara que infraestructura es todo lo que sería "hardware" (EC2, S3, Athena).
• 13:29
  Terraform vs Ansible: crear infraestructura vs configurar servidoresTerraform crea, modifica y destruye infraestructura; Ansible se conecta a máquinas ya creadas para ejecutar comandos en masa (updates, instalar Python, configurar WordPress). Son complementarios y se pueden encadenar en un `.sh`. Modificar una máquina con Terraform puede implicar recrearla y perder lo trabajado en ella.
• 17:37
  Demo en AWS: crear instancias manualmente vs con TerraformSe muestra el lanzamiento manual de una instancia EC2 por consola, con par de llaves y falta de permisos. Se plantea el caso de crear 10 instancias para un workshop y destruirlas después, algo que Terraform hace de forma estándar y repetible.
• 19:35
  Por qué el enfoque declarativo importaCon boto3 y sin revisar el estado se crearían máquinas duplicadas. Con Terraform, si de 10 máquinas se borra una, al re-ejecutar solo se recrea la faltante. Se destaca su utilidad en ciencia de datos para ambientes de desarrollo, staging y producción consistentes, y se menciona la analogía de la "lista de compras de hardware".
• 23:19
  Recursos recomendados y setup: instalar Terraform y credenciales cloudSe recomienda el tutorial de DevOps Directive (2 h 40 min) y su repositorio. Se explica la instalación (Brew, Ubuntu, Choco en Windows), `terraform version` (versión 1.x) y la configuración de credenciales con `gcloud` o `aws configure`.
• 26:23
  main.tf, providers y data sourcesEn `main.tf` se define la versión requerida de Terraform y los providers (AWS v5, GCP, Azure, Random), que funcionan como módulos para interactuar con servicios externos. Los `data` permiten recuperar información existente, como la región y la identidad de la cuenta. Se aclara que Terraform es agnóstico de nube (frente a CloudFormation, propietario de AWS), aunque migrar entre nubes no es directo.
• 31:01
  Definiendo recursos: S3 bucket, referencias, tagsUn recurso declara lo que debe existir al final; el nombre interno de referencia es libre. El bucket usa un nombre con cuenta, región y sufijo único (los nombres de bucket son globalmente únicos), `force_destroy` y tags. Se discute fijar versiones con `==` frente a `>=`, y los warnings de deprecación.
• 37:41
  Variables y terraform.tfvars: parametrizando ambientes`variables.tf` define parámetros (aws_region, environment, project_name) con valores por defecto y descripción. `terraform.tfvars` da los valores, como los argumentos de una función, y permite varios archivos para separar ambientes.
• 39:36
  Outputs y terraform state: valores sensibles y cómo Terraform compara cambiosLos outputs imprimen valores conocidos solo tras la creación (como una IP) y pueden servir de entrada a otros scripts de Terraform. Las variables sensibles no se imprimen, pero quedan en el archivo de state, que hay que ignorar en Git. El state permite calcular la diferencia entre lo existente y lo declarado.
• 44:34
  MemesPausa con comunidad: sugerencia de subir el podcast a Spotify, aviso de DataCamp gratis por tiempo limitado, memes sobre IA e ingenieros, sueldos no revelados en ofertas y un agente autónomo que gastó US$85 en 4 minutos. También se comenta que Amazon Q CLI pasó a ser Kiro, como ejemplo de servicios que cambian.
• 54:12
  Terraform en equipos: state, locking y el modelo de negocio (gobernanza y seguridad)Con varias personas surgen pull requests, bloqueo del state y almacenamiento remoto. El núcleo es open source, pero la gobernanza (auditoría, políticas, locking automático) es de pago en el servicio de HashiCorp, comprado por IBM. Se menciona que el cambio de licencia generó alternativas más abiertas, y que el state puede guardarse en un bucket. Sigue una conversación informal sobre PCs antiguos, Windows 7 y OpenClaw.
• 01:05:49
  Demo práctica: init, fmt, validate, plan y apply (y cómo usar plan en CI/CD)`init` descarga los providers, `fmt` formatea, `validate` revisa la sintaxis (se recomienda la extensión oficial de HashiCorp). `plan` muestra qué se creará (+), destruirá (-) o modificará (~); aquí son 4 recursos a agregar, y `apply` falla por falta de permisos en el sandbox. El plan puede usarse en CI/CD para condicionar merges de pull requests.
• 01:14:07
  Backend remoto del state: S3 + locking (DynamoDB) y evitar conflictosEl state local puede moverse a S3 para que todo el equipo vea el mismo estado. Para evitar apply simultáneos hay que bloquear el archivo; se menciona DynamoDB, aunque se aclara que no se ha probado. Terraform solo gestiona lo declarado en el `main`.
• 01:16:58
  Ejemplos en GCP: buckets, Firestore, BigQuery y depends_on para ordenar ejecucionesSe muestran un bucket de GCP con sufijo aleatorio (provider random), una base Firestore y un dataset de BigQuery con dos tablas (logs de predicciones y métricas) con esquema JSON. `depends_on` fuerza el orden en el DAG, ya que por defecto Terraform paraleliza lo que puede.
• 01:22:08
  Terraform para servir modelos: endpoints, artefactos, imágenes y variables de entornoUn ejemplo con Vertex define la ruta del endpoint, el artefacto del modelo en storage, la imagen Docker y la versión, para enviar una fila por POST y recibir la predicción. También se definen variables de entorno como `MODEL_PATH` y el dataset de BigQuery.
• 01:25:21
  Organización por ambientes: workspaces vs archivos .tfvars (dev/stage/prod)Se revisa el repositorio de DevOps Directive con carpetas global, producción y staging, y se critica la duplicación de código. Se propone un mismo `main` con archivos `.tfvars` por ambiente (prod, dev, stage) que cambian sufijos, rangos de IP y otros parámetros, pasando el archivo en `plan`.
• 01:31:36
  CierreSe propone ver en el futuro Terraform con GitHub Actions y repositorios separados para infraestructura y aplicación. Se distingue desarrollo, staging y producción, y los presentadores comentan lo aprendido y se despiden.

Palabras clave