Terraform e Infraestructura como Código (IaC): fundamentos, estructura de proyecto y conexión con Azure

Crear infraestructura “a mano” en el portal de Azure no escala: es difícil de repetir, de auditar y de versionar. La Infraestructura como Código (IaC) resuelve eso, y Terraform es hoy una de sus herramientas más populares. Acá verás los fundamentos, la estructura básica de un proyecto nuevo, cómo conectarlo con Azure y en qué se diferencia de ARM.

¿Qué es la Infraestructura como Código (IaC)?

IaC es gestionar tu infraestructura (redes, servidores, bases de datos, storage) mediante archivos de código versionados en lugar de clics manuales. Beneficios:

• Repetible: el mismo código crea el mismo entorno una y otra vez (dev, QA, prod idénticos).
• Versionado: vive en Git — historial, revisiones y rollback.
• Auditable: los cambios se revisan en pull requests antes de aplicarse.
• Idempotente: aplicar dos veces no duplica nada; converge al estado deseado.

Fundamentos de Terraform

Terraform (de HashiCorp) es declarativo: describís el estado deseado y él calcula cómo llegar. Conceptos clave:

• HCL: el lenguaje de configuración (archivos .tf).
• Providers: plugins que hablan con cada plataforma (azurerm para Azure, aws, google, etc.). Es multi-nube.
• State (estado): Terraform guarda un archivo de estado que mapea tu código con los recursos reales. Es central — debe ir en un backend remoto compartido y con bloqueo.
• Flujo: init → plan → apply (y destroy para eliminar).

terraform init      # descarga providers y configura el backend
terraform plan      # PREVISUALIZA los cambios (sin aplicar)
terraform apply     # aplica los cambios
terraform destroy   # elimina lo creado

El plan es una de sus mejores cualidades: ves exactamente qué se va a crear, cambiar o destruir antes de tocar nada.

Estructura básica de un proyecto nuevo

Un proyecto Terraform ordenado separa responsabilidades en archivos. Una estructura recomendada:

mi-proyecto/
├── providers.tf      # providers y versiones requeridas
├── backend.tf        # configuración del estado remoto
├── main.tf           # los recursos
├── variables.tf      # variables de entrada
├── outputs.tf        # valores de salida (IPs, nombres, etc.)
├── terraform.tfvars  # valores concretos (NO secretos)
└── modules/          # módulos reutilizables
    └── red/
        ├── main.tf
        ├── variables.tf
        └── outputs.tf

• providers.tf / backend.tf: el “esqueleto” — qué providers usás y dónde vive el estado.
• main / variables / outputs: el patrón estándar de todo módulo.
• modules/: empaquetá piezas reutilizables (una red, una base de datos) y reusalas entre entornos.
• Entornos (dev/prod): separalos con distintos .tfvars o carpetas/workspaces, reutilizando los mismos módulos.

Conectar Terraform con Azure: parámetros importantes

Para Azure se usa el provider azurerm. Tres cosas a tener en cuenta:

1. El bloque del provider (con features)

terraform {
  required_version = ">= 1.5"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}   # obligatorio, aunque vaya vacío
}

Fijá la versión del provider (version) para builds reproducibles.

2. Autenticación

Lo recomendado es un Service Principal y pasar las credenciales por variables de entorno (nunca en el código):

export ARM_SUBSCRIPTION_ID="tu-subscription-id"
export ARM_TENANT_ID="tu-tenant-id"
export ARM_CLIENT_ID="app-id-del-service-principal"
export ARM_CLIENT_SECRET="secreto-del-service-principal"

Para desarrollo local también podés autenticarte con az login (Azure CLI). En pipelines, lo ideal es un Service Principal o Managed Identity.

3. Estado remoto (backend azurerm)

Guardá el estado en un blob de Azure Storage — así el equipo comparte el mismo estado y Terraform aplica bloqueo (evita aplicaciones simultáneas):

terraform {
  backend "azurerm" {
    resource_group_name  = "rg-tfstate"
    storage_account_name = "sttfstate001"
    container_name       = "tfstate"
    key                  = "prod.terraform.tfstate"
  }
}

Y un recurso de ejemplo:

resource "azurerm_resource_group" "main" {
  name     = var.rg_name
  location = var.location
}

Terraform vs ARM (y Bicep)

ARM templates son el lenguaje nativo de Azure (JSON). Bicep es la evolución moderna de ARM: un DSL más limpio que compila a ARM, también nativo de Azure. Terraform es de un tercero (HashiCorp), multi-nube y con su propio estado.

Cuándo usar cada uno: Terraform si trabajás multi-nube, ya tenés experiencia con él, o querés su ecosistema y vista previa. ARM/Bicep si sos 100% Azure, querés integración nativa, soporte inmediato de features nuevas y no querés administrar un archivo de estado.

Conclusión

IaC convierte tu infraestructura en algo repetible, versionado y auditable; Terraform lo hace de forma multi-nube y con una vista previa muy clara. Empezá con una estructura ordenada (providers, backend, variables, módulos), autenticá con un Service Principal y guardá el estado remoto desde el día uno.

Seguí leyendo: Configurar Azure SQL serverless · Diseño y Arquitectura.

En Grupo TANDEM diseñamos e implementamos infraestructura en Azure con IaC, lista para escalar y auditar. Si querés montar tu base de Terraform bien desde el inicio, conversemos.