Saltar a contenido

Infraestructura: modelo común

Cloud Delivery Lab reproduce la misma aplicación sobre dos implementaciones independientes: Amazon EKS con RDS y Google Kubernetes Engine con Cloud SQL. GitLab coordina los cambios; los proveedores cloud ejecutan las cargas. La portabilidad reside en compartir el flujo de trabajo y los manifiestos de aplicación, con adaptaciones de infraestructura y exposición por proveedor.

Esta documentación describe el código público del commit ae1502b0 de terraform-modules, revisado el 26 de octubre de 2026. Los valores indicados son los predeterminados versionados, no una lectura de los recursos actualmente desplegados ni de las variables privadas de GitLab.

Terraform como código; OpenTofu como ejecutor

Los ocho directorios usan ficheros .tf, bloques terraform, proveedores del ecosistema Terraform y backend HTTP. El pipeline ejecuta tofu, con la imagen registry.gitlab.com/components/opentofu/gitlab-opentofu:4.7.0-opentofu1.12.1-alpine. Por tanto, la descripción precisa es infraestructura escrita en HCL de Terraform y ejecutada en CI mediante OpenTofu. La memoria ya lo indica en §7.2.7, página impresa 45 (PDF 51).

La imagen de un componente no implica que se haya incluido su plantilla: este repositorio define sus propios jobs y llama directamente a tofu. Las funciones del componente oficial que no estén invocadas o configuradas aquí no deben darse por habilitadas.

Ocho raíces, cuatro responsabilidades

Cada combinación de proveedor y capa es una raíz independiente, con su propio backend y estado.

Capa AWS GCP Responsabilidad
network VPC, subredes, NAT y rutas mediante módulo VPC VPC, dos subredes, rangos secundarios, Router, NAT y firewall Conectividad base
kubernetes EKS, node group, IRSA y EBS CSI GKE, node pool, identidad de nodos y capacidades CSI/Workload Identity Plano de control y cómputo
database RDS MySQL y grupos de seguridad Cloud SQL MySQL y Private Service Access Persistencia externa a Kubernetes
platform Namespaces, secreto de DB, Agent y AWS Load Balancer Controller Namespaces, secreto de DB, Agent y cuenta de servicio opcional Preparación del clúster para el despliegue

No son ocho módulos publicados en un registro. Son ocho raíces ejecutables dentro del repositorio llamado terraform-modules; AWS además consume módulos públicos de terceros. No se observa un job de publicación de módulos.

El orden del pipeline es network → kubernetes → database → platform. La destrucción recorre el orden inverso. Las dependencias reales explican por qué hay estados separados:

flowchart TD
    N["network"] --> K["kubernetes"]
    N --> D["database"]
    K -->|"Security group en AWS"| D
    N --> P["platform"]
    K -->|"Endpoint, CA e identidad"| P
    D -->|"Conexión MySQL"| P

La capa platform necesita que el API de Kubernetes exista y sea accesible antes de planificar y aplicar sus recursos Kubernetes y Helm. Separarla también permite retirar los recursos de plataforma antes de eliminar el clúster. Es coherente con la explicación de la memoria, §7.2.7, páginas 44–45 (PDF 50–51).

Qué comparten las dos implementaciones

  • Un namespace de aplicación app y un secreto rest con los datos de conexión MySQL.
  • Un agente de GitLab instalado por Helm para conectar el clúster a GitLab.
  • Estados remotos en el proyecto de infraestructura, con bloqueo HTTP.
  • La selección CLOUD_PROVIDER=aws|gcp, la acción PIPELINE_ACTION=create|destroy y el identificador ENVIRONMENT.
  • Planes guardados que se aplican mediante una aprobación manual por capa.
  • Nodos privados y acceso saliente a Internet para imágenes, servicios y la conexión del agente.

Diferencias que importan al operar

Aspecto AWS predeterminado GCP predeterminado
Región eu-west-1 europe-west1
Red Tres subredes privadas y tres públicas Una privada y una pública reservada; rangos de pods y servicios
Salida Un NAT Gateway compartido Cloud NAT regional para la subred privada
Kubernetes EKS, versión configurada 1.31 GKE regional, canal REGULAR, versión mínima sin fijar
Nodos t3.small, deseado 1, límites 1–3 e2-small, ubicaciones en dos zonas; conteos por zona
Base de datos RDS MySQL 8.0, db.t4g.micro, una AZ Cloud SQL MYSQL_8_0, db-f1-micro, ZONAL
Acceso del ejecutor a Kubernetes aws eks get-token Token OAuth del proveedor Google
Exposición de la aplicación Controlador ALB y manifiesto Ingress AWS No hay variante de Ingress GKE en los repositorios revisados

La infraestructura no configura replicación de bases de datos entre nubes, balanceo global, failover multinube ni conectividad privada entre AWS y GCP. Cada proveedor mantiene su propia base de datos. Desplegar la misma imagen en ambos no sincroniza los datos.

Entornos: el estado no basta para aislar recursos

ENVIRONMENT cambia el prefijo de los estados y los resource_group de CI. Los nombres cloud siguen siendo, por defecto, gitlab-terraform-eks o gitlab-terraform-gke; las etiquetas conservan dev. Un segundo valor de ENVIRONMENT puede crear un estado distinto que intente gestionar nombres ya ocupados. Antes de usar dev, pre y pro simultáneamente hay que decidir cuentas/proyectos, nombres, redes y variables por entorno. Véanse estados y variables.

Límites y pasos externos

El repositorio crea recursos dentro de cuentas cloud y de un proyecto GCP existentes. No declara la facturación, las identidades con las que corre CI, la activación de APIs GCP, el registro inicial de los agentes en GitLab, ni el certificado y DNS usados por el Ingress AWS. Tampoco demuestra por sí solo que una ejecución reciente haya concluido correctamente.

Para recorrer la implementación: AWS, GCP, pipeline, acceso del agente y retirada de recursos. La guía de puesta en marcha reúne los pasos entre repositorios.

Versiones declaradas y reproducibilidad

Dependencia Restricción del snapshot Dónde se usa
Motor compatible HCL required_version >= 1.6.0; CI ejecuta OpenTofu 1.12.1 Ocho raíces
Proveedor AWS >= 5.95.0, < 6.0.0 Cuatro raíces AWS
Proveedor Google >= 7.0.0, < 8.0.0 Cuatro raíces GCP
Proveedor Kubernetes >= 2.25.0, < 3.0.0 Ambas plataformas
Proveedor Helm >= 2.12.0, < 3.0.0 Ambas plataformas
TLS / time / cloudinit >= 3.0.0 / >= 0.9.0 / >= 2.0.0 Raíz EKS
Módulo VPC AWS ~> 5.0 Red AWS
Módulo EKS AWS ~> 20.0 Kubernetes AWS
Submódulos IAM AWS 5.39.0 IRSA EBS y ALB
Charts Agent y ALB Sin versión fijada en los releases Plataforma

Las restricciones no son las versiones efectivamente resueltas en una ejecución. El snapshot no contiene .terraform.lock.hcl, por lo que no se puede reconstruir esa selección exacta únicamente desde Git. Para mejorar la reproducibilidad, registrar y revisar locks por raíz y fijar versiones de charts; cualquier actualización debe volver a probarse. Las restricciones proceden de AWS network, EKS, AWS platform y GCP platform.

Fuentes