Providers: arquitectura de plugins y configuración

Los providers son el puente entre Terraform y las APIs externas. Entender su arquitectura de plugins, niveles de soporte y configuración avanzada es fundamental para el examen.

Contenido

Arquitectura de plugins
Niveles de providers
required_providers y versiones
.terraform.lock.hcl
Múltiples configs con alias
Herencia de providers en módulos

Arquitectura de plugins

Terraform se divide en dos componentes principales que se comunican mediante un protocolo RPC sobre gRPC:

Terraform Core

• Lee y parsea los archivos HCL
• Construye el grafo de dependencias
• Gestiona el estado (tfstate)
• Coordina la ejecución del plan
• Se comunica con los providers via gRPC
• Binario: terraform

Terraform Providers (plugins)

• Implementan los recursos y data sources
• Contienen la lógica de cada API (AWS, Azure…)
• Se descargan en .terraform/providers/
• Son binarios separados del core
• Cada provider es un proceso aparte (RPC)
• Desarrollados por HashiCorp, partners o comunidad

💡 Por qué plugins separados

Separar Core de Providers permite que: (1) el core no necesite recompilarse al añadir nuevas APIs, (2) los providers puedan tener su propio ciclo de release, (3) cualquier empresa pueda crear su propio provider sin modificar Terraform Core.

Niveles de providers

Nivel	Mantenido por	Namespace en registry	Ejemplos
Official	HashiCorp	hashicorp/	hashicorp/aws, hashicorp/azurerm, hashicorp/google
Partner	Empresa tecnológica con acuerdo HashiCorp	empresa/	datadog/datadog, mongodb/mongodbatlas, pagerduty/pagerduty
Community	Comunidad open-source	cualquiera/	kreuzwerker/docker, hashicorp/dns (deprecated examples)

🎯 Para el examen

Los providers official son mantenidos por HashiCorp y tienen el mayor nivel de soporte y pruebas. El source de un provider official siempre empieza con hashicorp/. En el examen pueden preguntarte la diferencia entre official, partner y community.

required_providers y versiones

Siempre declara los providers que usas en el bloque required_providers dentro de terraform . Especificar la versión es una buena práctica obligatoria en producción.

terraform {
  required_version = ">= 1.6.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"        # >= 5.0.0, < 6.0.0
    }
    random = {
      source  = "hashicorp/random"
      version = "= 3.5.1"       # versión exacta
    }
    datadog = {
      source  = "DataDog/datadog"
      version = ">= 3.20.0"
    }
  }
}

Operador	Significado	Ejemplo
~>	Pessimistic constraint: solo incrementa el último segmento	~> 5.0 = >=5.0, <6.0 \| ~> 5.2.1 = >=5.2.1, <5.3
>=	Mayor o igual que	>= 5.0 = cualquier versión 5.0 o mayor
<=	Menor o igual que	<= 5.9 = hasta 5.9 inclusive
=	Versión exacta (pin duro)	= 5.31.0 = solo esa versión
!=	Excluye una versión específica	!= 5.10.0 = cualquiera excepto 5.10.0
>	Estrictamente mayor que	> 5.0 = desde 5.0.1 en adelante

💡 ~> es el operador más usado en el examen

~> 5.0 significa "5.x pero no 6.x". ~> 5.2.1 significa "5.2.x pero no 5.3". La diferencia está en qué segmento es el "último" que puede incrementar.

.terraform.lock.hcl

Después de terraform init, se genera el lock file que fija las versiones exactas instaladas, incluso si el constraint permite un rango.

# .terraform.lock.hcl — generado automáticamente, SÍ se commitea
provider "registry.terraform.io/hashicorp/aws" {
  version     = "5.31.0"          # versión exacta instalada
  constraints = "~> 5.0"          # constraint del required_providers
  hashes = [
    "h1:HASH_PARA_PLATAFORMA_ACTUAL",
    "zh:HASH_VERIFICACIÓN_CRUZADA",
  ]
}

# Para añadir hashes de otras plataformas (ej: CI usa Linux, devs usan Mac):
# terraform providers lock -platform=linux_amd64 -platform=darwin_arm64

✅ Por qué commitear el lock file

• Garantiza que todos usan la misma versión exacta del provider
• Evita que un init en otro equipo instale una versión diferente
• Permite auditar qué versión de provider generó un cambio concreto
• Terraform lo actualiza solo cuando ejecutas init -upgrade

⚠️ No confundir con tfstate

• El lock file fija versiones de PROVIDERS (no de recursos)
• El tfstate fija el estado de los RECURSOS creados
• Lock file: sí se commitea | tfstate: no se commitea (usar backend remoto)

Múltiples configs con alias

Cuando necesitas múltiples configuraciones del mismo provider (por ejemplo, dos regiones de AWS o dos cuentas), usas el argumento alias.

# Dos regiones de AWS en el mismo módulo
provider "aws" {
  region = "us-east-1"
  # Sin alias = provider por defecto
}

provider "aws" {
  alias  = "west"
  region = "us-west-2"
}

# Usar el provider con alias en un recurso
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  # Usa el provider por defecto (us-east-1)
}

resource "aws_vpc" "disaster_recovery" {
  provider   = aws.west          # referencia: nombre_provider.alias
  cidr_block = "10.1.0.0/16"
}

# Pasar provider con alias a un módulo
module "vpc_west" {
  source = "./modules/vpc"
  providers = {
    aws = aws.west               # mapa de providers para el módulo
  }
}

Herencia de providers en módulos

Los módulos hijos heredan el provider por defecto del módulo raíz automáticamente. Solo necesitas el argumento providers cuando usas alias o quieres sobrescribir el provider heredado.

Escenario	Necesita providers = {}?	Motivo
Módulo usa un solo provider, mismo que root	❌ No	Hereda automáticamente el provider por defecto del root
Módulo usa provider con alias	✅ Sí	Debes mapear qué alias del root corresponde al provider del módulo
Módulo necesita un provider diferente al root	✅ Sí	El root pasa explícitamente el provider correcto al módulo
Módulo multi-provider (ej: aws + random)	✅ Sí	Cada provider del módulo debe mapearse explícitamente

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Un módulo de Terraform necesita crear recursos en dos cuentas de AWS diferentes. ¿Cómo se configura esto correctamente?