# El registry es accesible públicamente sin autenticación para módulos públicos
# URL principal:
# https://registry.terraform.io

# Buscar módulos via CLI (necesita Terraform instalado)
# No hay comando CLI directo para buscar, pero sí puedes ver info de un módulo:
terraform providers

# O usar la API del registry:
curl https://registry.terraform.io/v1/modules/terraform-aws-modules/vpc/aws

# Comprueba en GitHub:
# - Último commit: ¿fue hace menos de 6 meses?
# - Issues abiertos: ¿hay muchos sin respuesta?
# - Pull requests: ¿se revisan y fusionan con regularidad?
# - Releases: ¿hay versiones recientes?

# Verifica el bloque terraform en el módulo:
terraform {
  required_version = ">= 1.3"  # ¿Es compatible con tu versión?
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 4.0"       # ¿Es compatible con tu versión del provider?
    }
  }
}

# Pasos para publicar:

# 1. Crea el repositorio con el nombre correcto
# terraform-aws-mi-servidor (ejemplo)

# 2. Desarrolla el módulo con la estructura correcta

# 3. Crea una cuenta en registry.terraform.io y conecta GitHub

# 4. El registry detecta automáticamente el repositorio por el nombre

# 5. Publica el módulo desde la interfaz del registry

# 6. Crea tags para las versiones:
git tag v1.0.0
git push origin v1.0.0
# El registry detecta el tag y publica la versión automáticamente

# Para versiones posteriores:
git tag v1.1.0
git push origin v1.1.0

terraform-aws-vpc
│        │   │
│        │   └── Función/componente: qué hace el módulo
│        └────── Provider: con qué cloud/tecnología trabaja
└─────────────── Prefijo: siempre "terraform" para módulos publicables

terraform-aws-vpc              # VPC en Amazon Web Services
terraform-google-gke           # Google Kubernetes Engine en GCP
terraform-azurerm-aks          # Azure Kubernetes Service en Azure
terraform-kubernetes-nginx     # NGINX en Kubernetes
terraform-github-repository    # Repositorios en GitHub

modules/
├── networking/        # Kebab-case o snake_case
├── compute-web/
├── database_rds/
└── security-groups/

# Crear el repositorio con el nombre correcto
# En GitHub: New repository → nombre: terraform-local-proyecto

# Clonar el repositorio
git clone https://github.com/tu-usuario/terraform-local-proyecto.git
cd terraform-local-proyecto

# Crear los archivos necesarios
touch main.tf variables.tf outputs.tf README.md
mkdir -p examples/basico
touch examples/basico/main.tf examples/basico/README.md

# main.tf
terraform {
  required_version = ">= 1.0"
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "~> 2.0"
    }
  }
}

resource "local_file" "proyecto" {
  filename        = "${var.directorio}/${var.nombre}.conf"
  content         = var.contenido
  file_permission = var.permisos
}

# variables.tf
variable "nombre" {
  description = "Nombre del archivo de configuración del proyecto."
  type        = string
}

variable "directorio" {
  description = "Directorio destino donde se creará el archivo."
  type        = string
}

variable "contenido" {
  description = "Contenido del archivo de configuración."
  type        = string
  default     = "# Configuración generada por Terraform"
}

variable "permisos" {
  description = "Permisos del archivo en formato octal."
  type        = string
  default     = "0644"
}

# outputs.tf
output "ruta_archivo" {
  description = "Ruta completa del archivo de configuración creado."
  value       = local_file.proyecto.filename
}

output "contenido_guardado" {
  description = "Contenido guardado en el archivo."
  value       = local_file.proyecto.content
}

# examples/basico/main.tf
module "mi_proyecto" {
  source = "../.."   # Apunta al módulo raíz del repositorio

  nombre     = "mi-aplicacion"
  directorio = "/tmp/configs"
  contenido  = "servidor=localhost\npuerto=8080"
}

output "config_creada" {
  value = module.mi_proyecto.ruta_archivo
}

# terraform-local-proyecto

Módulo de Terraform para gestionar archivos de configuración de proyectos.

## Uso

## Variables de entrada

| Variable | Tipo | Obligatoria | Default | Descripción |
|---|---|---|---|---|
| nombre | string | Sí | - | Nombre del archivo |
| directorio | string | Sí | - | Directorio destino |
| contenido | string | No | Comentario | Contenido del archivo |
| permisos | string | No | "0644" | Permisos del archivo |

## Outputs

| Output | Descripción |
|---|---|
| ruta_archivo | Ruta completa del archivo creado |
| contenido_guardado | Contenido guardado |

# Commitear todos los cambios
git add .
git commit -m "feat: implementación inicial del módulo"
git push origin main

# Crear el primer tag de versión
git tag v1.0.0
git push origin v1.0.0

# Ahora en registry.terraform.io:
# 1. Sign in with GitHub
# 2. Publish → Module
# 3. Seleccionar el repositorio "terraform-local-proyecto"
# 4. ¡El registry lo detecta automáticamente!

# Desarrollar el cambio
# ... modificar archivos ...

# Commitear con mensaje descriptivo siguiendo convenciones
git add .
git commit -m "feat: añadir soporte para permisos de directorio"
git push origin main

# Crear nuevo tag (versión MENOR porque es nueva funcionalidad)
git tag v1.1.0
git push origin v1.1.0
# El registry detecta el tag y publica la nueva versión automáticamente

# Para usar módulos del registry privado, configura las credenciales
# en el CLI de Terraform:

# 1. Obtener un token de API de Terraform Cloud
# app.terraform.io → User Settings → Tokens

# 2. Configurar el token localmente
terraform login app.terraform.io
# Abre el navegador para autenticación

# 3. Usar el módulo privado en tu configuración
module "mi_modulo_privado" {
  source  = "app.terraform.io/mi-organizacion/nombre-modulo/provider"
  version = "~> 1.0"

  # Variables del módulo
  variable_1 = "valor"
}

# Los módulos privados se publican desde VCS (GitHub Enterprise, GitLab, etc.)
# Proceso en Terraform Cloud:

# 1. Navega a: app.terraform.io → Registry → Publish Module
# 2. Conecta tu VCS provider
# 3. Selecciona el repositorio del módulo
# 4. El naming sigue la misma convención: terraform-<provider>-<nombre>
# 5. Los tags de git crean versiones automáticamente

# Para equipos que no pueden usar git tags directamente,
# Terraform Cloud Enterprise permite publicar via API:
curl \
  --header "Authorization: Bearer $TOKEN" \
  --header "Content-Type: application/vnd.api+json" \
  --request POST \
  --data @module.json \
  "https://app.terraform.io/api/v2/organizations/mi-org/registry-modules"

# main.tf

terraform {
  required_version = ">= 1.3"

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

# Configuración del provider AWS
provider "aws" {
  region = "eu-west-1"   # Irlanda

  # En producción, las credenciales se gestionan via:
  # - Variables de entorno: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
  # - IAM Role (en EC2 o ECS)
  # - AWS SSO / Identity Center
  # NUNCA las hardcodees en el código
}

# ============================================================
# Datos de contexto: obtenemos información de la cuenta AWS
# ============================================================

# data sources obtienen información existente (no crean recursos)
data "aws_availability_zones" "disponibles" {
  # Filtra por estado: solo zonas "available" (activas)
  state = "available"
}

# ============================================================
# Módulo VPC: crea la red completa
# ============================================================

module "vpc_produccion" {
  # source: identificador único del módulo en el registry
  # Formato: <namespace>/<nombre>/<provider>
  source = "terraform-aws-modules/vpc/aws"

  # version: SIEMPRE especificar. ~> 5.0 acepta 5.x.x pero no 6.x.x
  version = "~> 5.0"

  # --- Configuración básica ---

  # Nombre de la VPC (se usa para nombrar todos los recursos internos)
  name = "vpc-produccion"

  # Bloque CIDR de la VPC: rango de IPs de toda la red
  cidr = "10.0.0.0/16"   # 65,536 IPs disponibles

  # --- Zonas de disponibilidad y subredes ---

  # Usamos las 3 primeras AZs disponibles en la región
  # slice() toma los primeros N elementos de una lista
  azs = slice(data.aws_availability_zones.disponibles.names, 0, 3)

  # Subredes privadas: recursos internos (bases de datos, workers)
  # No tienen acceso directo desde internet
  # Una subred por AZ = alta disponibilidad
  private_subnets = [
    "10.0.1.0/24",   # 256 IPs en AZ-a
    "10.0.2.0/24",   # 256 IPs en AZ-b
    "10.0.3.0/24",   # 256 IPs en AZ-c
  ]

  # Subredes públicas: recursos accesibles desde internet (load balancers, bastiones)
  public_subnets = [
    "10.0.101.0/24",  # 256 IPs en AZ-a
    "10.0.102.0/24",  # 256 IPs en AZ-b
    "10.0.103.0/24",  # 256 IPs en AZ-c
  ]

  # Subredes de base de datos: aisladas, sin acceso a internet
  # (Buena práctica de seguridad: bases de datos en su propia subred)
  database_subnets = [
    "10.0.201.0/24",
    "10.0.202.0/24",
    "10.0.203.0/24",
  ]

  # --- Conectividad a internet ---

  # Internet Gateway: permite a las subredes PÚBLICAS acceder a internet
  # Se crea automáticamente cuando hay public_subnets
  # (No es necesario configurarlo explícitamente)

  # NAT Gateway: permite a las subredes PRIVADAS acceder a internet (salida)
  # pero el tráfico entrante desde internet no puede llegar a ellas
  enable_nat_gateway = true

  # single_nat_gateway = true: UN SOLO NAT para todas las AZs
  # Ventaja: más económico (~$32/mes vs ~$96/mes por 3 NATs)
  # Desventaja: punto único de fallo (si esa AZ falla, las privadas pierden internet)
  # En PRODUCCIÓN real: usa one_nat_gateway_per_az = true
  single_nat_gateway = true

  # --- DNS ---

  # Habilitar resolución DNS en la VPC (necesario para muchos servicios AWS)
  enable_dns_hostnames = true
  enable_dns_support   = true

  # --- Configuración de base de datos ---

  # Crea un "DB subnet group": agrupación de subredes para RDS
  # Necesario si vas a usar el módulo RDS posteriormente
  create_database_subnet_group = true

  # --- Etiquetas ---

  # Tags aplicados a TODOS los recursos que crea el módulo
  tags = {
    Entorno    = "produccion"
    Proyecto   = "tienda-online"
    GestionPor = "terraform"
    Equipo     = "infraestructura"
  }

  # Tags adicionales solo para las subredes públicas
  public_subnet_tags = {
    "kubernetes.io/role/elb" = "1"  # Necesario para AWS Load Balancer Controller en EKS
  }

  # Tags adicionales solo para las subredes privadas
  private_subnet_tags = {
    "kubernetes.io/role/internal-elb" = "1"  # Para load balancers internos en EKS
  }
}

# ============================================================
# Outputs: exponemos información de la VPC para otros módulos
# ============================================================

output "vpc_id" {
  description = "ID de la VPC creada"
  value       = module.vpc_produccion.vpc_id
}

output "subredes_privadas" {
  description = "IDs de las subredes privadas"
  value       = module.vpc_produccion.private_subnets
}

output "subredes_publicas" {
  description = "IDs de las subredes públicas"
  value       = module.vpc_produccion.public_subnets
}

output "subredes_base_datos" {
  description = "IDs de las subredes de base de datos"
  value       = module.vpc_produccion.database_subnets
}

output "cidr_vpc" {
  description = "Bloque CIDR de la VPC"
  value       = module.vpc_produccion.vpc_cidr_block
}

# Inicializar
terraform init

# Ver el plan (sin aplicar)
terraform plan

# El módulo vpc crea aproximadamente:
# - 1 VPC
# - 9 subredes (3 privadas + 3 públicas + 3 de BD)
# - 1 Internet Gateway
# - 1 NAT Gateway + 1 Elastic IP
# - 3 Route tables (1 pública, 1 privada, 1 de BD)
# - 1 DB Subnet Group
# - Varias asociaciones de route tables
# Total: ~25-30 recursos con una sola llamada al módulo

# Buscar en el registry:
# 1. Ve a registry.terraform.io
# 2. Busca "github"
# 3. Selecciona el provider "integrations/github"

# main.tf

terraform {
  required_version = ">= 1.0"

  required_providers {
    # Provider oficial de GitHub (mantenido por Integrations, socio de HashiCorp)
    github = {
      source  = "integrations/github"
      version = "~> 6.0"
    }
  }
}

# Configuración del provider de GitHub
provider "github" {
  # El token se pasa via variable de entorno: GITHUB_TOKEN
  # Nunca lo pongas aquí en el código
  # export GITHUB_TOKEN="ghp_tu_token_aqui"

  owner = "tu-organizacion"  # o tu usuario de GitHub
}

# ============================================================
# Crear repositorios usando el provider directamente
# (sin módulo del registry porque no hay uno verificado ampliamente)
# ============================================================

locals {
  # Definir los repositorios como mapa para usar for_each
  repositorios = {
    "api-backend" = {
      descripcion  = "API REST del backend de la aplicación"
      privado      = true
      auto_init    = true
      topics       = ["api", "backend", "rest"]
    }
    "frontend-web" = {
      descripcion  = "Aplicación web del frontend"
      privado      = false
      auto_init    = true
      topics       = ["frontend", "web", "react"]
    }
  }
}

# Crear los repositorios con for_each
resource "github_repository" "repos" {
  for_each = local.repositorios

  # Nombre del repositorio
  name = each.key

  # Descripción visible en GitHub
  description = each.value.descripcion

  # Visibilidad del repositorio
  visibility = each.value.privado ? "private" : "public"

  # Inicializar con README.md automáticamente
  auto_init = each.value.auto_init

  # Topics (etiquetas) del repositorio
  topics = each.value.topics

  # Configuración de branches
  has_issues   = true
  has_wiki     = false
  has_projects = false

  # Configuración de merge: solo squash y merge commits, no merge commits directos
  allow_squash_merge     = true
  allow_merge_commit     = false
  allow_rebase_merge     = true
  delete_branch_on_merge = true  # eliminar rama al hacer merge de PR
}

# Proteger la rama main en todos los repositorios
resource "github_branch_protection" "main" {
  for_each = local.repositorios

  repository_id = github_repository.repos[each.key].node_id
  pattern       = "main"

  # Requerir pull requests antes de hacer merge
  required_pull_request_reviews {
    dismiss_stale_reviews           = true
    required_approving_review_count = 1
  }

  # Requerir que los checks de CI pasen
  required_status_checks {
    strict = true  # los checks deben ejecutarse sobre la versión más reciente
  }

  # No permitir forzar push a main
  force_push_bypassers  = []
}

# Outputs
output "urls_repositorios" {
  description = "URLs de los repositorios creados en GitHub"
  value = {
    for k, v in github_repository.repos : k => v.html_url
  }
}

output "ssh_clone_urls" {
  description = "URLs SSH para clonar los repositorios"
  value = {
    for k, v in github_repository.repos : k => v.ssh_clone_url
  }
}

# PELIGROSO: sin versión
module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  # Si sale una versión 6.0 con breaking changes, terraform init la usará
}

# CORRECTO: versión bloqueada
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"
}

# staging/main.tf
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.1"   # Probando nueva versión menor
}

# produccion/main.tf
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"   # Versión probada y estable
}