diff --git a/workloads/docs-portal/docs/decisiones/0012-practica-multicloud-gcp-azure.md b/workloads/docs-portal/docs/decisiones/0012-practica-multicloud-gcp-azure.md new file mode 100644 index 0000000..2a0820f --- /dev/null +++ b/workloads/docs-portal/docs/decisiones/0012-practica-multicloud-gcp-azure.md @@ -0,0 +1,277 @@ +# ADR 0012 — Práctica multi-cloud: GCP y Azure DevOps en paralelo al lab ZimaOS + +**Estado:** aceptada — Fase 1 (Google Workspace) en ejecución en esta +misma sesión; Fases 2-4 quedan documentadas como roadmap, explícitamente +no implementadas hasta que se pidan en una sesión futura. +**Fecha:** 2026-09-20 + +## Contexto + +El lab GitOps de CruzCloud (ZimaOS + k3d + Gitea + Argo CD) ya prueba en +vivo, con rigor de ADR, patrones que después se pueden proponer en +trabajo real con clientes — pero corre íntegro sobre hardware propio, +sin tocar ningún proveedor de nube público. Dos motivaciones concretas +empujan a abrir una segunda línea de práctica en paralelo: + +1. **Practicar herramientas que el cliente actual restringe.** Ciertas + plataformas/herramientas de nube no están disponibles en el entorno + de trabajo del cliente actual — la única forma real de ganar + experiencia con ellas es un entorno propio. +2. **Preparar propuestas de arquitectura con evidencia, no solo teoría.** + Poder decir "ya lo corrí, así se ve, esto cuesta X" en una propuesta + a un cliente vale más que una descripción de manual. +3. **Portafolio.** Los mismos ADRs, diagramas y decisiones documentadas + que ya sostiene este lab sirven como muestra de trabajo verificable. + +**Alcance confirmado explícitamente por el usuario, no asumido:** + +- **Entorno paralelo, no migración.** ZimaOS sigue siendo el lab + principal — nada de lo de acá reemplaza nada de lo ya construido. +- **Cuentas personales únicamente.** Nunca credenciales del cliente + actual ni de ningún cliente futuro — separación total. +- **Costo cero o mínimo**, con alertas de presupuesto como red de + seguridad desde el primer recurso pago que se cree (ver + [Análisis de costo](#analisis-de-costo-explicito) más abajo). +- Mismo rigor documental que el resto del lab: un ADR por decisión + arquitectónica real, diagramas Mermaid, cifras verificadas en vivo o + contra fuente primaria (no contra un blog de terceros sin + corroborar — ver el caso del supuesto MCP "oficial" de Google + Workspace en la [Fase 1](#fase-1-ejecutar-en-esta-sesion-google-workspace)). + +## Diagrama del lab actual (ZimaOS) + +Versión simplificada, con solo los componentes relevantes para la +comparación de este ADR — el diagrama completo (con Traefik, +`serverlb`, cada `Host` de Ingress, etc.) vive en +[Visión general](../arquitectura/vision-general.md). + +```mermaid +flowchart LR + User(["Usuario"]) -->|HTTPS| CF["Cloudflare Tunnel
(sin puertos abiertos)"] + CF --> NPM["Nginx Proxy Manager
enrutamiento por dominio"] + NPM --> K3D["k3d
(cluster K8s local, Docker)"] + + subgraph K3D_INT["Dentro de k3d"] + ARGO["Argo CD"] -->|sync| APPS["Apps reales
(ecommerce, docs-portal)"] + GIT["Gitea
(auto-alojado)"] -.->|watch repos| ARGO + end + K3D --> K3D_INT +``` + +**Costo real:** $0 — hardware propio (NAS ZimaOS), sin proveedor de +nube de por medio. + +## Diagrama Fase 1 — entorno paralelo en GCP (VM + k3s) + +**Esto NO es GKE administrado.** Es una VM `e2-micro` corriendo k3s +self-managed, elegida específicamente para mantener el costo real en +$0 — GKE (administrado, ver [Fase 4](#fase-4-documentar-no-ejecutar-gke-real-con-spot-auto-apagado)) +no tiene una vía 100% gratuita permanente (ver el análisis de costo +más abajo). + +```mermaid +flowchart LR + User(["Usuario / Claude"]) -->|SSH / kubectl| VM["Compute Engine e2-micro
Always Free — us-west1/us-central1/us-east1
NO es GKE administrado"] + + subgraph VM_INT["Dentro de la VM"] + K3S["k3s
(single-node, self-managed)"] + ARGO2["Argo CD
(instancia propia, no la de ZimaOS)"] -->|sync| APPS2["Manifiestos del nuevo repo
(mismo patrón base+overlay
de platform-templates)"] + end + VM --> VM_INT + + GIT_EXISTENTE["Gitea existente
gitea.cruzcloud.net
(reusado, repo nuevo, NO uno nuevo)"] -.->|watch| ARGO2 +``` + +**Por qué reusar el Gitea existente en vez de levantar uno nuevo en +GCP:** el objetivo es practicar el patrón GitOps completo (Kustomize +base+overlay + Argo CD sincronizando) con el mínimo de piezas nuevas — +levantar un segundo Gitea solo sumaría superficie a mantener sin +enseñar nada nuevo sobre GCP en sí. El *cómputo* (la VM, k3s) es lo que +cambia de proveedor; el origen de verdad (Git) se queda donde ya +funciona. + +**Costo real:** $0 — `e2-micro` es Always Free **de forma permanente** +(no es el trial de $300/90 días), siempre que la VM viva en +`us-west1`, `us-central1` o `us-east1` y no supere 1 instancia +no-preemptible + 30 GB-mes de disco persistente estándar + 1 GB/mes de +salida hacia Norteamérica — límites reales del programa, verificados +contra la documentación oficial de Google Cloud.[^1] + +## Fase futura (no implementada) — GKE real con Spot + auto-apagado + +Marcada explícitamente como **fase futura, no implementada** — ver +[Fase 4](#fase-4-documentar-no-ejecutar-gke-real-con-spot-auto-apagado) +para cuándo se decidiría ejecutarla. + +```mermaid +flowchart LR + TF["Terraform
(provisiona todo)"] --> GKE["GKE Standard
1 cluster zonal"] + GKE --> NP["Node pool
Spot VMs (e2-small)"] + + SCHED["Cloud Scheduler
(cron: apagar/prender)"] -->|invoca| FN["Cloud Run/Functions
job de auto-apagado"] + FN -->|resize node pool
a 0 / de vuelta| NP + + style GKE fill:#333,stroke:#f90,color:#fff + style NP fill:#333,stroke:#f90,color:#fff + style SCHED fill:#333,stroke:#f90,color:#fff + style FN fill:#333,stroke:#f90,color:#fff +``` + +### Mecanismo de auto-apagado: comparación antes de recomendar + +Dos mecanismos reales existen para esto; se investigaron ambos antes de +elegir uno, sin asumir cuál es "obviamente" mejor: + +| | Escalar node pool a 0 | Destruir/recrear cluster completo (`terraform apply`/`destroy` programado) | +|---|---|---| +| Qué apaga | Solo el cómputo (los nodos) | Todo, incluido el control plane | +| Ahorra el fee de control plane ($0.10/hora) | No — pero **ya está cubierto por el crédito mensual de $74.40** para un único cluster, así que no hay nada real que ahorrar ahí | Sí, pero es un ahorro sobre algo que ya es $0 | +| Tiempo de "volver a prender" | ~1-3 min (crear nodos sobre un cluster que ya existe) | ~5-10 min (crear el cluster entero de cero) | +| Piezas para automatizarlo | Cloud Scheduler → Cloud Function/Run → 1 llamada a la API de GKE (resize node pool) | Cloud Scheduler → runner con Terraform + credenciales + state remoto seguro → `apply`/`destroy` completo | +| Riesgo de drift/config perdida | Bajo — el cluster nunca se borra | Mayor — cualquier cosa hecha fuera de Terraform se pierde en cada destroy | +| Patrón documentado en la industria | Sí, es el patrón estándar (Cloud Scheduler + Pub/Sub + Cloud Function), con casos reales de ~30% de ahorro de cómputo en clusters no-críticos[^2] | Existe, pero es la opción menos común para este caso puntual | + +**Recomendación (sin implementar todavía):** escalar el node pool a +0/de vuelta vía Cloud Scheduler + Cloud Function, no destruir/recrear +el cluster completo. Razón concreta: el crédito de $74.40/mes **ya +cubre el fee de control plane de un único cluster exista o no exista +un nodo adentro** — destruir el cluster entero no ahorra nada sobre +ese componente porque ya es $0, y a cambio suma la complejidad real de +manejar Terraform state de forma segura dentro de un cron job +automatizado, más un tiempo de arranque 3-5x más largo. La única razón +real para preferir destruir/recrear sería eliminar *toda* huella en +GCP entre usos (por ejemplo, para no depender de que el crédito +mensual siga existiendo) — no es el caso acá. + +## Tabla comparativa + +| | Lab actual (ZimaOS) | GCP Fase 1 (VM + k3s) | GCP Fase futura (GKE + Spot) | +|---|---|---|---| +| Cómputo | NAS propio, Docker/k3d | Compute Engine `e2-micro` | GKE Standard, node pool Spot `e2-small` | +| ¿Kubernetes administrado? | No (k3d local) | No (k3s self-managed) | Sí (GKE Standard) | +| Control plane | N/A (local) | N/A (k3s corre en la misma VM) | $0.10/hora — cubierto por crédito de $74.40/mes para 1 cluster | +| Cómputo de nodos | $0 (hardware propio) | $0 (Always Free permanente) | ~$7-10/mes (Spot `e2-small`, sin cubrir por ningún crédito) | +| GitOps | Argo CD + Gitea, ambos autoalojados | Argo CD propio en la VM, mismo Gitea reusado | Igual que Fase 1, sobre GKE | +| Costo mensual real | $0 | $0 | ~$7-10/mes (no $0) | +| Estado | En producción, uso diario | A ejecutar esta sesión (Parte 2/3) | Documentado, no implementado | + +## Análisis de costo explícito + +**No existe un GKE administrado 100% gratis de forma permanente.** El +crédito de $74.40/mes por cuenta de facturación cubre exactamente el +fee de control plane ($0.10/hora) de **un** cluster zonal Standard o +Autopilot — nunca el cómputo real. GKE Autopilot factura desde el +primer pod que se programa (vCPU/memoria/almacenamiento por pod), sin +ningún equivalente al Always Free de Compute Engine; GKE Standard sí +puede correr sobre un único nodo Spot/preemptible barato (~$7/mes para +un `e2-small`, verificado contra tarifas actuales), pero ese cómputo +nunca es gratis.[^3] + +**La única ruta de costo cero real y permanente es Compute Engine +`e2-micro` (Always Free) + k3s self-managed** — exactamente la Fase 1 +de este ADR. No es el trial de $300/90 días (que expira y no es +"gratis", es prepago con reloj corriendo); es un beneficio permanente +del programa de nivel gratuito de Google Cloud, activo mientras la VM +cumpla los límites de región/tamaño/tráfico ya descritos arriba. + +**Activar cualquier billing account de GCP requiere tarjeta igual**, +incluso para quedarse exclusivamente en recursos Always Free — Google +verifica el medio de pago aunque el cargo real sea $0. Detalle no +obvio, verificado contra documentación oficial: **las alertas de +presupuesto no se pueden configurar mientras la cuenta esté operando +sobre crédito gratuito de prueba** — hace falta pasar la cuenta de +facturación a estado "paga" (el uso real sigue siendo $0 si no se sale +del Always Free) para que la opción de crear un presupuesto/alerta +quede disponible.[^4] **Recomendación:** hacer ese paso — pasar a +cuenta de facturación paga — como parte del setup inicial, y configurar +de inmediato una alerta de presupuesto en **$1-5 USD** como red de +seguridad, antes de crear ningún recurso más allá de lo cubierto por +Always Free. + +## Secuencia de fases + +Todas documentadas acá; **solo la Fase 1 se ejecuta en esta sesión.** +Las Fases 2-4 no se implementan sin pedido explícito en una sesión +futura — quedan como roadmap, no como trabajo en curso. + +### Fase 1 (ejecutar en esta sesión) — Google Workspace + +MCP de Google Workspace vía cuenta personal, para las iniciativas ya +en curso. Detalle de la investigación previa a implementar (qué MCP +usar, oficial vs comunitario) en la Parte 3 de esta conversación — +resumen: **no existe un MCP oficial de Google Workspace** publicado +por Google (se verificó explícitamente buscando en los GitHub +`google`/`googleworkspace` oficiales — no aparece ninguno; un solo +blog de terceros afirma que "ya existe uno oficial" sin que ninguna +otra fuente lo corrobore, así que se descarta esa afirmación por no +verificable). `taylorwilsdon/google_workspace_mcp` es la opción +comunitaria más completa y activamente mantenida (120+ herramientas, +OAuth 2.1, +2500 estrellas) — es la que se usa, etiquetada como +comunitaria, no oficial. + +### Fase 2 (documentar, no ejecutar) — Terraform aislado + +Instalar el marketplace oficial de HashiCorp Agent Skills, y practicar +aprovisionando algo mínimo y desechable en GCP. Nota para cuando se +ejecute: HashiCorp también publica un **MCP Server de Terraform** +propio y oficial (`hashicorp/terraform-mcp-server`, integra con el +Terraform Registry y HCP Terraform) — es una pieza distinta a los +Agent Skills (el MCP es el "tubo" hacia herramientas reales; los +Skills son paquetes de conocimiento/instrucciones) y vale la pena +evaluar si se usan juntos o solo uno de los dos en ese momento. + +### Fase 3 (documentar, no ejecutar) — Azure DevOps en paralelo + +MCP oficial `microsoft/azure-devops-mcp` (confirmado como el oficial y +activamente mantenido por Microsoft, hay varios forks/alternativas +comunitarias que no son la vía recomendada). Replicar el mismo +pipeline DevSecOps que ya corre en Gitea Actions para este lab +(Gitleaks → Trivy → Semgrep → Syft → Cosign) como Azure Pipelines YAML, +en un proyecto personal — mismo objetivo de práctica que la Fase 1: +tener el patrón ya probado para proponerlo en trabajo con clientes que +usen Azure DevOps. + +### Fase 4 (documentar, no ejecutar) — GKE real con Spot + auto-apagado + +Solo si se decide conscientemente asumir el costo bajo pero no-cero +(~$7-10/mes, ver el análisis de costo arriba) — vía Terraform, node +pool Spot, y el mecanismo de auto-apagado recomendado en la sección de +arriba (escalar a 0, no destruir/recrear el cluster). + +## Opciones consideradas + +| Opción | A favor | En contra | +|---|---|---| +| Entorno paralelo en GCP+Azure (elegido) | Practica exactamente lo que el cliente actual restringe; portafolio con evidencia real; ZimaOS sigue intacto | Dos entornos más que mantener; curva de aprendizaje de dos proveedores nuevos a la vez | +| Migrar el lab completo a un solo cloud | Un solo entorno que mantener | Pierde justo lo que se quiere conservar (costo $0, control total de hardware); no es lo que se pidió | +| Solo AWS (el "default" de la industria) | Ecosistema más grande | El cliente actual ya usa/restringe otras plataformas específicas — practicar AWS no cierra esa brecha puntual | +| GKE administrado desde el día 1 (saltear la VM self-managed) | Más parecido a "producción real" desde el inicio | Rompe el requisito de costo cero explícito del usuario — ningún tier de GKE es gratis de forma permanente | + +## Decisión + +Se abre una línea de práctica multi-cloud paralela al lab ZimaOS, en +cuentas personales, arrancando por Compute Engine `e2-micro` (Always +Free) + k3s self-managed en GCP como Fase 1 de cómputo, y Google +Workspace vía MCP comunitario (`taylorwilsdon/google_workspace_mcp`) +como primer MCP a configurar en esta sesión. Terraform, Azure DevOps y +GKE administrado quedan documentados como Fases 2-4, sin implementar. + +## Consecuencias + +- **Se gana** un segundo entorno real, documentado con el mismo rigor + de ADR que ya sostiene el lab, listo para mostrar en propuestas a + clientes — sin tocar nunca credenciales de cliente. +- **Se sacrifica/queda como deuda técnica:** la Fase 1 de GCP usa k3s + self-managed, no un Kubernetes administrado real — cualquier lección + específica de operar GKE (autoscaling nativo, node pools, IAM de + GCP) queda pendiente hasta la Fase 4, y esa fase sí tiene costo real + (~$7-10/mes) que hoy no se está pagando. +- **Para revertir:** dar de baja la VM `e2-micro` y (si se llegó a + crear) el node pool de la Fase 4 — ningún componente de este ADR + toca o depende del lab ZimaOS existente, así que no hay nada que + revertir de ese lado. + +[^1]: [Compute Engine Free Tier — Google Cloud](https://cloud.google.com/free/docs/compute-getting-started), [GCP Free Tier Complete Guide 2026](https://agentdeals.dev/gcp-free-tier-2026) +[^2]: [Reduce Your GKE Bill with Cloud Scheduler by Scaling to Zero](https://chimbu.medium.com/reduce-your-gke-bill-with-cloud-scheduler-by-scaling-to-zero-during-off-peak-hours-9796bb4f7b8b), [Scaling GKE Standard Clusters to Zero](https://medium.com/@gustavo.romerobenitez_34616/scaling-gke-standard-clusters-to-zero-56bf5270510e) +[^3]: [GKE Pricing Guide 2026 — Sedai](https://sedai.io/blog/google-cloud-kubernetes-cluster-cost), [e2-small pricing — Economize](https://www.economize.cloud/resources/gcp/pricing/compute-engine/e2-small/), [Google Kubernetes Engine pricing — Google Cloud](https://cloud.google.com/kubernetes-engine/pricing) +[^4]: [Google Cloud Free Trial FAQs](https://cloud.google.com/signup-faqs), [Create, edit, or delete budgets and budget alerts — Google Cloud](https://docs.cloud.google.com/billing/docs/how-to/budgets) diff --git a/workloads/docs-portal/mkdocs.yml b/workloads/docs-portal/mkdocs.yml index 6d0da90..0032b96 100644 --- a/workloads/docs-portal/mkdocs.yml +++ b/workloads/docs-portal/mkdocs.yml @@ -99,6 +99,7 @@ nav: - "0009 · Checkout real": decisiones/0009-checkout-real.md - "0010 · Pago y envío reales": decisiones/0010-pago-envio-reales-y-storefront.md - "0011 · Ambiente de Staging": decisiones/0011-ambiente-staging.md + - "0012 · Práctica multi-cloud GCP/Azure": decisiones/0012-practica-multicloud-gcp-azure.md - Plantilla ADR: decisiones/plantilla-adr.md - Playbooks: - Crashloop Medusa: playbooks/incidente-crashloop-medusa.md