De la idea al estado.

IaC

• Terraform automatiza la creación, modificación y eliminación de infraestructura mediante configuración declarativa.
• Sus providers permiten trabajar con diferentes nubes y servicios desde un flujo común.
• Empieza con HCL y proyectos pequeños; el curso practica principalmente con Azure.

IaC

• IaC describe redes, servidores y otros componentes en archivos que se pueden versionar y reutilizar.
• Los scripts y las CLI de cada nube automatizan tareas; Terraform organiza un flujo declarativo de infraestructura.
• Crear, probar y limpiar entornos reproducibles reduce trabajo manual y recursos abandonados.

IaC

• El curso presenta HCL y el ecosistema de providers como razones para adoptar Terraform.
• Además de nubes, existen integraciones para servicios como GitHub y herramientas locales.
• Practicar localmente permite aprender antes de desplegar; cambiar de nube exige adaptar los recursos específicos.

IaC

• La práctica usa Ubuntu dentro de WSL y el repositorio oficial de HashiCorp.
• El procedimiento comprende actualizar paquetes, configurar la clave de firma y agregar el repositorio.
• Comprueba la instalación con terraform --version; consulta la guía vigente para los comandos de instalación.

IaC

• Prepara una cuenta de Azure y entiende la suscripción antes de desplegar recursos.
• El registro incluye verificación de identidad y configuración de autenticación multifactor.
• Revisa límites y condiciones del crédito gratuito; el curso no sustituye las condiciones vigentes de facturación.

IaC

• Instala Azure CLI en el mismo entorno de trabajo y verifica que az esté disponible.
• Usa az login; si corresponde, az login --use-device-code ofrece un flujo alternativo.
• Comprueba la suscripción activa con az account show. La CLI puede aportar autenticación; el provider realiza las llamadas a Azure.

IaC

• Crea un directorio de práctica y un main.tf para el tutorial inicial de Docker.
• Abre el proyecto con code . y familiarízate con los bloques HCL.
• El curso propone extensiones de Terraform para resaltado, autocompletado y detección temprana de errores.

Fundamentos

• Busca integraciones en Terraform Registry y revisa su mantenimiento y documentación.
• required_providers declara source y restricciones de versión; provider configura la integración.
• Un proyecto puede combinar Azure, AWS, Kubernetes u otros providers, con recursos específicos para cada servicio.

Fundamentos

• Un resource group organiza recursos relacionados dentro de una suscripción de Azure.
• Declara azurerm_resource_group con name y location; az account list-locations ayuda a explorar regiones.
• terraform init prepara backend, providers y módulos; aparecen .terraform/ y .terraform.lock.hcl.

Fundamentos

• plan compara configuración, estado e infraestructura y muestra las acciones propuestas.
• Lee los errores y completa requisitos del provider, como features y el ID de suscripción.
• terraform plan -out=plan.out guarda un plan revisable. Es un artefacto sensible de esa ejecución, no una plantilla universal.

Fundamentos

• terraform apply plan.out ejecuta el plan guardado que revisaste.
• Los nombres locales de bloques resource del mismo tipo deben distinguirse, aunque sus nombres en Azure sean otros.
• Comprueba el resultado y el grupo de recursos en el portal. Genera un nuevo plan para cada cambio.

Fundamentos

• destroy propone eliminar los recursos administrados por el estado y solicita confirmación interactiva.
• Inspecciona lo que se eliminará y comprueba después la limpieza en Azure.
• La clase practica limpieza de entornos desechables para controlar costos; no conviertas destruir y recrear en una corrección automática.

Fundamentos

• Organiza un ejercicio con configuración AzureRM y un resource group.
• Ejecuta init, plan -out=plan.out y apply plan.out desde el directorio correcto.
• Verifica lo desplegado. init también se repite al clonar, añadir módulos o modificar la configuración del backend.

Variables y estado

• Declara entradas con variable, type, description y, cuando corresponda, default; refiérelas como var.nombre.
• Separa declaraciones y valores: los archivos .tf definen variables y los .tfvars asignan valores.
• Usa -var-file para archivos elegidos y una muestra sin secretos para documentar. variables.tf es una convención, no un nombre obligatorio.

Variables y estado

• Los bloques output exponen atributos como nombre, ubicación o ID de recursos.
• Define value con una referencia al recurso; revisa outputs al planear y al aplicar.
• Agruparlos en outputs.tf mejora la lectura y prepara interfaces para integraciones o módulos.

Variables y estado

• azurerm_storage_account referencia el nombre y ubicación del resource group.
• Configura account_tier y account_replication_type; el ejemplo usa Standard y LRS.
• El nombre exige 3–24 caracteres alfanuméricos en minúsculas. sensitive = true oculta outputs habituales, pero no cifra el estado.

Variables y estado

• Separa providers, recursos y salidas en archivos con responsabilidades claras.
• El provider aztfmod/azurecaf genera nombres mediante azurecaf_name, prefijos y opciones de aleatoriedad.
• Usa el atributo result como nombre del recurso y ejecuta init al agregar el provider; generar un nombre no reserva su disponibilidad global.

Variables y estado

• El estado relaciona las direcciones de Terraform con recursos y atributos reales.
• El archivo local JSON puede incluir claves y cadenas de conexión; exclúyelo de Git y controla su acceso.
• Quitar un resource de la configuración puede producir una eliminación en el siguiente plan. El estado es una instantánea, no un historial completo.

Variables y estado

• Prepara el alojamiento del estado: resource group, storage account y contenedor de blobs.
• Declara backend azurerm con storage_account_name, container_name y key por proyecto o entorno.
• Mantén las credenciales fuera del código; configura la autenticación y realiza una migración explícita cuando exista estado local.

Variables y estado

• Inicializa el backend y comprueba que Terraform lee y escribe el blob de estado remoto.
• El bloqueo evita escritores simultáneos durante operaciones; se libera cuando termina cada operación.
• El curso usa SAS. La opción es sas_token en minúsculas o ARM_SAS_TOKEN; existen otros métodos de autenticación.

Bloques y comandos

• data consulta un recurso existente sin asumir su administración.
• Lee un resource group por nombre y utiliza data.azurerm_resource_group.nombre.name o .location al crear storage.
• El título usa importar de manera informal: una consulta data no equivale a import ni adopta el ciclo de vida del grupo.

Bloques y comandos

• fmt normaliza el estilo; usa -recursive para recorrer directorios y -check para comprobarlo en CI.
• validate revisa la configuración y consistencia interna después de inicializar dependencias.
• plan usa valores y contexto de ejecución; apply todavía puede fallar por permisos, cuotas o condiciones del servicio.

Recursos Azure

• La arquitectura de práctica reúne resource group, VNet, subnet, IP pública, NSG, NIC, asociación y VM Windows.
• Conecta recursos mediante referencias a IDs; parametriza ubicación, usuario y contraseña.
• La clase prueba RDP en 3389 y verifica el escritorio de Windows Server. Define una política de acceso adecuada antes de usarla fuera del laboratorio.

Recursos Azure

• Una extensión de VM permite agregar IIS a Windows Server desde Terraform.
• CustomScriptExtension ejecuta una instrucción de PowerShell para instalar Web-Server.
• Planea el cambio, aplica y verifica IIS en Server Manager y localhost; ajusta las referencias al nombre real de tu VM.

Módulos

• Agrupa recursos por responsabilidad, por ejemplo red, seguridad y cómputo.
• Cada directorio de módulo contiene configuración, variables de entrada y outputs; los nombres de archivo son convenciones.
• Al separar el código, reemplaza referencias externas por entradas explícitas y expón los IDs que requieren otros módulos.

Módulos

• Expón subnet_id, public_ip_address_id y el ID del NSG mediante outputs.
• El módulo raíz conecta module.vnet y module.nsg con las entradas de module.vm.
• Reinicializa para incorporar módulos, revisa el plan, aplica y verifica; limpia el laboratorio al finalizar.

Módulos

• locals da nombre a expresiones que reutilizas, como prefijos derivados del entorno.
• El bloque es locals en plural y la referencia es local.nombre en singular.
• Las variables reciben entradas externas; los locals calculan valores dentro del módulo y pueden depender de ellas.

Módulos

• Para adoptar un recurso existente, define su configuración y un import con to e id.
• Obtén el identificador del recurso y compara cuidadosamente las propiedades reales con las declaradas.
• Revisa el plan de importación antes de aplicar: adoptar puede incluir modificaciones, y el recurso pasa a quedar bajo gestión del estado.

Módulos

• data proporciona atributos consultados; import asocia un objeto existente con un recurso administrado.
• Ambos pueden dejar información en el estado, pero solo el recurso adoptado entra en tu ciclo de gestión.
• Decide según responsabilidad: consultar infraestructura de otro equipo o asumir explícitamente su administración.

Módulos

• Registry permite descubrir módulos, revisar ejemplos y consultar interfaces de entrada y salida.
• Inspecciona README, código, versiones y mantenimiento antes de integrar uno.
• Las descargas muestran uso, pero no garantizan calidad. Selecciona una versión compatible y comprueba el módulo con tu contexto.

Módulos

• La publicación en el Registry público usa un repositorio con patrón terraform-PROVIDER-NAME.
• Prepara README, licencia y .gitignore; clona el repositorio para trabajar.
• El ejemplo agrupa storage, plan de servicio y function app en un módulo de Azure Functions con entradas y salidas.

Módulos

• Adapta README, nombres y descripciones de variables al módulo que vas a compartir.
• Revisa cambios con git status, prepara archivos y registra un commit antes del push.
• Publica una versión con tag como v1.0.0 para identificar un conjunto reproducible de código y documentación.

Módulos

• Vincula el repositorio elegible con Registry y verifica nombre y versión publicada.
• Consume el módulo desde un proyecto independiente, configura provider y completa las entradas requeridas.
• Ejecuta init y plan; resuelve incompatibilidades y advertencias antes de aplicar y verificar la function app.

CI/CD

• Guarda el workflow en .github/workflows/ y define triggers, runner y directorio de trabajo.
• El ejemplo usa una identidad de servicio y mapea credenciales a ARM_CLIENT_ID, ARM_CLIENT_SECRET, ARM_SUBSCRIPTION_ID y ARM_TENANT_ID.
• Checkout, instalación de Terraform, init, validate y plan forman la primera automatización de integración.

CI/CD

• Agrega un paso de terraform apply plan.out para ejecutar el plan producido por el workflow.
• Pon nombres claros a jobs y pasos para interpretar los resultados en Actions.
• Un runner efímero pierde el estado local entre ejecuciones; configura persistencia antes de repetir despliegues.

CI/CD

• Conecta el workflow al mismo backend remoto para conservar el estado entre runners.
• El ejemplo aloja tfstate en un contenedor de Azure y obtiene SAS desde GitHub Secrets al inicializar.
• Verifica backend y blob de estado. Coordina ejecuciones concurrentes; un commit adicional no sustituye resolver el bloqueo o la causa del fallo.

Documentación

• Busca recursos en la categoría del provider y en la versión que utilizas.
• Distingue argumentos requeridos, opcionales, bloques anidados y atributos exportados.
• Compara ejemplos y formas de modelar redes o reglas; consulta la documentación antes de combinar recursos con bloques inline.