DEV Community

Cover image for Providers y Resources: Los Pilares de Infrastructure as Code
Hassel Muñoz
Hassel Muñoz

Posted on

Providers y Resources: Los Pilares de Infrastructure as Code

#terraform #iac #providers #resources

El Problema Real

Cuando trabajas con múltiples proveedores cloud (AWS, Azure, GCP) o herramientas (Kubernetes, GitHub), gestionar la infraestructura manualmente genera inconsistencias, errores humanos y documentación desactualizada. Necesitas un modelo declarativo que sea agnóstico y repetible.

Qué Son Providers y Resources

En el contexto de Infrastructure as Code, particularmente en Terraform, estos son los dos conceptos fundamentales:

Providers son plugins que actúan como intérpretes entre tu código y los servicios reales. Cada provider contiene la lógica necesaria para comunicarse con una API específica (AWS, Azure, Kubernetes, etc.). Son los "conectores" de tu infraestructura.

Resources son los objetos concretos que declaras dentro de un provider: instancias EC2, buckets S3, redes virtuales, pods de Kubernetes. Representan la infraestructura que quieres crear, modificar o destruir.

Cómo Funciona en la Práctica

Todo comienza con la configuración del provider. Indicamos qué servicio queremos usar y cómo acceder a él:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}
Enter fullscreen mode Exit fullscreen mode

Luego declaramos los resources que queremos. Cada resource tiene un tipo (definido por el provider) y un nombre lógico:

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "web-server-prod"
  }
}

resource "aws_s3_bucket" "app_data" {
  bucket = "my-app-data-bucket"
}
Enter fullscreen mode Exit fullscreen mode

Cuando ejecutas terraform plan y terraform apply, Terraform usa el provider AWS para traducir tu declaración a llamadas API reales, creando exactamente lo que especificaste.

Ejemplo Técnico Real

Supongamos que necesitas un entorno básico en AWS con una instancia y un bucket S3 asociado. Sin IaC, harías clicks en la consola. Con providers y resources:

  1. El provider AWS obtiene credenciales de tu entorno
  2. Los resources aws_instance y aws_s3_bucket se validan contra el schema del provider
  3. Terraform genera un plan mostrando exactamente qué se creará
  4. Se aplica el plan y los recursos se crean idénticamente cada vez

Si necesitas otro entorno idéntico, ejecutas el mismo código en otra región. Cero inconsistencias.

Beneficios en Entornos Reales

Reproducibilidad: El mismo código genera idéntica infraestructura en dev, staging y producción. No hay sorpresas.

Versionado: Tu infraestructura vive en Git. Ves quién cambió qué, cuándo y por qué.

Colaboración: Los equipos no necesitan acceso directo a consolas. Todo pasa por code review.

Velocidad: Provisionar un ambiente completo toma minutos, no horas.

Recuperación ante desastres: Reconstruir infraestructura es cuestión de ejecutar el código.

Buenas Prácticas Clave

Organiza providers en módulos reutilizables. No hardcodees valores: usa variables para región, ambiente, tamaños de instancias. Valida la sintaxis con terraform validate y usa terraform plan siempre antes de aplicar cambios.

Implementa estado remoto (S3 con DynamoDB para locks) para trabajo en equipo. Documentar qué hace cada resource es tan importante como codificarlo.

Cierre

Providers y resources no son conceptos avanzados, son los fundamentos de cualquier estrategia moderna de infraestructura. Dominarlos correctamente te ahorra estrés operativo, reduce errores y escala tu capacidad de entregar infraestructura rápidamente. Comienza mapeando un proyecto pequeño para internalizar el modelo declarativo.

Top comments (0)