Saltar a contenido

El proyecto

Cloud Delivery Lab demuestra cómo gestionar el ciclo de vida DevOps de una aplicación desde GitLab: planificación, edición del código, compilación, validación, publicación de imágenes, aprovisionamiento de infraestructura, despliegue y operación. Terraform define los recursos y OpenTofu ejecuta los planes desde CI. AWS y Google Cloud aportan dos implementaciones de infraestructura para una misma aplicación demostradora.

La documentación describe el código público revisado el 26 de octubre de 2026. El nombre visible del grupo es Cloud Delivery Lab; su ruta sigue siendo gabriel-canals-tfm. Los enlaces de evidencia se fijan a los commits examinados. Esta revisión no comprueba que las cuentas, clústeres, imágenes o endpoints históricos continúen activos.

Qué resuelve

El proyecto conecta responsabilidades que suelen mantenerse separadas: código fuente, plantillas de automatización, imágenes, manifiestos de ejecución y estado de infraestructura. Un cambio puede relacionarse con el commit que lo originó, la imagen construida y el commit que actualizó el manifiesto de Kubernetes.

GitLab es la interfaz de trabajo y el sistema de coordinación. Los jobs ejecutan herramientas especializadas —Maven, Docker, OpenTofu y kubectl— y los proveedores alojan los recursos. La centralización describe dónde se coordina el ciclo; no elimina las APIs, credenciales o dependencias de esas herramientas.

Capacidad Implementación versionada Dónde profundizar
Código y entrega de la aplicación Dos proyectos Java, Dockerfiles y entradas de CI Aplicación demostradora
Automatización compartida build.yml, test.yml y deploy.yml Pipelines
Artefactos trazables JAR como artifact; imagen etiquetada con rama y SHA Build y release
Estado deseado Dos repositorios con manifiestos Kubernetes Despliegue
Infraestructura Cuatro raíces de configuración por proveedor Infraestructura
Estado y acceso al clúster Backend HTTP de GitLab y GitLab Agent Estado, acceso
Documentación Este repositorio MkDocs, español e inglés y pipeline de Pages Publicación

La aplicación como demostrador

El caso práctico es una aplicación de gestión de usuarios formada por un frontend Java, una API Java y MySQL. Permite comprobar que la imagen se construye, la configuración llega al contenedor y la aplicación accede a una base de datos privada. Su lógica funcional no es el centro del proyecto.

Los manifiestos actuales crean los Deployments web y rest en app, con una réplica por componente. Ambos exponen el puerto 8080 en ejecución. El Dockerfile del frontend declara EXPOSE 8081, pero la configuración de Spring y el manifiesto usan 8080: la declaración del Dockerfile no cambia el puerto del proceso.

Qué significa multinube aquí

Existen raíces separadas para AWS/EKS/RDS y GCP/GKE/Cloud SQL. El pipeline de infraestructura selecciona un proveedor con CLOUD_PROVIDER; el de aplicación selecciona un clúster con DEPLOY_TARGET. Los proyectos de aplicación examinados fijan DEPLOY_TARGET: gke.

Cada ejecución de despliegue apunta a un clúster. El código no implementa sincronización de las bases, failover entre proveedores ni promoción atómica a ambos. Compartir el modelo de automatización permite comparar implementaciones y desplegar en cualquiera de los dos destinos; no demuestra por sí solo una arquitectura activa-activa.

Alcance y madurez

La memoria presenta el trabajo como una base para desarrollo y preproducción, y reconoce límites al trasladarlo a sistemas mayores. El código conserva decisiones de laboratorio que requieren revisión antes de una reproducción nueva: valores iniciales de infraestructura destroy/pro, nombres de recursos compartidos entre entornos, acceso público a los API servers, validadores de seguridad que admiten fallo y configuración de ingress específica de AWS.

Los hallazgos se explican con su efecto práctico en diferencias y puntos abiertos. No se han ejecutado cambios de infraestructura, despliegues ni pruebas contra cuentas del autor para preparar esta documentación.

Cómo recorrer la documentación

Fuentes