Saltar a contenido

Decisiones de diseño

Este registro explica las elecciones que definen Cloud Delivery Lab. Confirmada significa que la memoria expresa el motivo y el código permite relacionarlo con una implementación. Observada significa que el comportamiento está en el código, pero no se atribuye al autor una intención que no haya explicado. Las mejoras propuestas aparecen separadas de las capacidades existentes.

Decisiones con motivación documentada

D01. GitLab como punto de trabajo común

Estado: confirmada. La memoria plantea reducir la dispersión entre herramientas de planificación, código, automatización, artefactos y operación. El grupo reúne repositorios, plantillas, Registry, estados y agentes.

La ventaja buscada es una trazabilidad más sencilla y menos integraciones externas que mantener. La contrapartida es depender de las capacidades, permisos y evolución de GitLab. Centralizar el trabajo no convierte todas las tareas operativas en acciones disponibles en su interfaz: la memoria reconoce límites de operación avanzada en Kubernetes.

Evidencia: memoria PDF 16–18 y 62–66; impresas 10–12 y 56–60. Mapa de repositorios.

D02. Separar aplicación, manifiestos, CI e infraestructura

Estado: confirmada. La aplicación produce artefactos; los repositorios de despliegue guardan la versión deseada; cicd-templates normaliza la entrega; terraform-modules crea su base cloud.

Esta separación permite revisar cada responsabilidad por separado y seguir el cambio de código hasta el manifiesto. También exige permisos entre proyectos y consistencia en los contratos. Actualmente la entrega de frontend y backend es independiente; no hay una promoción transaccional de ambos.

Evidencia: memoria PDF 29–30; impresas 23–24; plantilla de promoción y aplicación.

D03. Plantillas CI reutilizables

Estado: confirmada. Los dos proyectos de aplicación incluyen las mismas plantillas para evitar duplicidad y compartir criterios. La memoria propone trasladar este patrón a otros proyectos.

Los includes actuales usan ref: main. Esto permite que las siguientes ejecuciones adopten cambios de plantilla sin modificar cada app, pero también dificulta reproducir una configuración histórica sólo a partir del commit de aplicación. Fijar tags o SHA es una evolución posible, no el comportamiento actual.

Evidencia: memoria PDF 35–36; impresas 29–30; includes del backend.

D04. Imágenes trazables en GitLab Registry

Estado: confirmada. Las imágenes usan la rama normalizada y el SHA del código. La memoria destaca la relación entre artefacto y cambio, y la integración de autenticación con CI.

La referencia facilita localizar y volver a seleccionar una versión. El etiquetado por SHA no crea por sí mismo una política de inmutabilidad ni asegura que la imagen se conserve indefinidamente; el rollback depende de disponibilidad y permisos de descarga.

Evidencia: memoria PDF 42–48; impresas 36–42; construcción y push.

D05. Aplicación pequeña y manifiestos Kubernetes nativos

Estado: confirmada. Se elige un caso sencillo de frontend, backend y MySQL para centrar el esfuerzo en DevOps. Los manifiestos YAML nativos reducen complejidad de empaquetado en el demostrador.

La plantilla de promoción contempla values.yaml si encuentra Chart.yaml, pero el job de despliegue termina con error ante un chart. Por tanto, no se documenta Helm como alternativa funcional de entrega de aplicaciones. Helm sí se utiliza para componentes de plataforma, como GitLab Agent.

Evidencia: memoria PDF 31–32 y 56; impresas 25–26 y 50; tratamiento de manifests y charts.

D06. Cuatro raíces de IaC por proveedor

Estado: confirmada. Red, Kubernetes, base de datos y plataforma separan dominios y dependencias. La plataforma se aplica sobre un clúster ya creado.

Los estados independientes permiten un orden explícito de provisión y retirada. También crean dependencias de outputs y credenciales entre raíces; su recuperación debe mantener coherencia entre los cuatro estados. No son ocho entornos totalmente independientes: son cuatro capas de cada implementación cloud.

Evidencia: memoria PDF 50–55; impresas 44–49; DAG de infraestructura y estados.

D07. Nodos privados, salida por NAT y tamaño de laboratorio

Estado: confirmada en su intención general. La memoria motiva los nodos privados para reducir exposición directa y la salida NAT para alcanzar servicios externos. En AWS justifica t3.small por coste contenido.

El código mantiene bases privadas, pero los endpoints de administración de clúster son públicos por defecto. Privacidad de nodos y restricción de acceso al API server son decisiones diferentes. Los tamaños pequeños tampoco representan un ensayo de capacidad de producción; la configuración regional de GKE debe valorarse por sus nodos totales y zonas.

Evidencia: memoria PDF 49–55; impresas 43–49; defaults EKS y defaults GKE.

Comportamientos observados cuyo motivo no se presume

ID Elección observada Efecto Estado de la explicación
D08 OpenTofu ejecuta configuraciones .tf Imagen CI con OpenTofu 1.12.1; la memoria ya lo menciona Motivo de elegir este ejecutor pendiente de confirmación del autor
D09 Infraestructura inicia con destroy y pro El operador debe revisar acción y entorno al lanzar el pipeline No se presupone que sea un valor recomendado para uso habitual
D10 Despliegue de app automático en main protegida No hay aprobación manual en la plantilla vigente La memoria muestra también un diseño manual anterior
D11 Parsers de seguridad admiten fallo Un exit 1 por High/Critical no constituye un bloqueo obligatorio Motivo de mantener los resultados como no bloqueantes no documentado
D12 GKE recibe el manifiesto de Ingress AWS La publicación externa no es reproducible sólo con ese fichero Posible configuración externa pendiente de aclarar
D13 ENVIRONMENT cambia nombres de estado No separa automáticamente nombres y tags cloud No se documenta un modelo completo de aislamiento dev/pre/pro
D14 Ejemplos de telemetría en GitLab Evidencia histórica de ingestión, no configuración de instrumentación versionada Origen y alcance de las señales pendientes de documentación

Las preguntas abiertas se mantienen como tales: no se atribuyen a coste, licencia, urgencia o preferencia personal sin evidencia. Hallazgos recoge su impacto operativo y fuentes delimita la revisión.

Evolución propuesta

Propuesta Decisión que requiere
Versionar plantillas CI y herramientas Cadencia de actualización, compatibilidad y responsable de promoción
Definir gates de seguridad y pruebas funcionales Qué bloquea, qué admite excepción y cómo queda aprobada
Crear configuración de exposición por proveedor Hostnames, certificados, controlador y estrategia de overlays
Parametrizar entornos de forma completa Identidad de recursos, cuentas/proyectos, redes, estados y permisos
Instrumentar observabilidad reproducible Señales, retención, exportación y objetivos de servicio
Añadir espera de rollout y smoke tests Criterios para considerar una entrega válida

Este repositorio de documentación implementa una evolución adicional: mantener Markdown bilingüe y publicarlo mediante MkDocs/Pages. Su pipeline de publicación es nuevo respecto a los repositorios de aplicación examinados.

Fuentes