CruzCloud Lab — Plataforma GitOps¶
TODO (fase 2+): reescribir esta portada con la narrativa final. Por ahora describe el propósito y la audiencia para que la navegación y el
nav:demkdocs.ymltengan un punto de entrada real.
Este sitio documenta un laboratorio personal de Platform Engineering: un cluster Kubernetes (k3d) corriendo sobre un NAS (ZimaOS), gobernado 100% por GitOps (Gitea + Argo CD), sirviendo una tienda de e-commerce real (Medusa + Next.js) como carga de trabajo de referencia.
No es un tutorial genérico ni una demo de juguete: cada decisión, cada incidente y cada diagrama de este sitio corresponde a un sistema que corre de verdad, con los commits, logs y causas raíz reales que lo probaron.
Para quién es este sitio¶
Este portal sirve a tres audiencias distintas, y está organizado para que cada una pueda entrar por su propia puerta:
- Reclutadores / pares de Platform Engineering — ver
decisiones/para el criterio arquitectónico detrás del stack, yplaybooks/para diagnóstico real de incidentes (no solo "lo arreglé"). - Alguien evaluando este patrón para un caso de negocio real
(tienda desplegable desde ZimaOS) — ver
arquitectura/para el flujo completo y su costo/complejidad real. - Estudiantes empezando con GitOps/Kubernetes (incluye a mi hijo,
7mo semestre de Ingeniería de Sistemas) — empezar por
guia-estudiante/, pensada para alguien que nunca ha visto estos conceptos.
Mapa del sitio¶
| Sección | Qué encontrarás |
|---|---|
| Arquitectura | Diagramas Mermaid del flujo completo, red/exposición, flujo GitOps, glosario |
| Decisiones (ADRs) | Por qué k3d, por qué Argo CD, por qué HTTP/2 sobre QUIC, etc. |
| Playbooks | Incidentes reales, diagnóstico paso a paso, causa raíz, fix |
| Aprendizajes | Qué haría distinto, gotchas de Medusa v2 |
| Guía del estudiante | Ruta de aprendizaje desde cero |
Estado de este sitio¶
Este portal se mantiene vivo junto con el lab. La idea es que cada
página muestre su última fecha de modificación real vía
git-revision-date-localized — por ahora ese plugin está deshabilitado
(ver TODO en mkdocs.yml): el build corre con mkdocs build --strict,
que aborta ante cualquier WARNING, y el plugin no tiene historial git
real que leer desde el contexto de build actual, así que se queda fuera
hasta que ese contexto incluya .git de verdad. Si una página dice
"TODO", es contenido pendiente de una fase posterior, no una promesa
incumplida: la estructura completa se construyó primero a propósito,
para que el contenido se llene sección por sección con el mismo
criterio que el resto del lab.
Desde este commit, el sitio se construye y publica solo: cada push a
main que toca docs/ o mkdocs.yml dispara
.gitea/workflows/deploy-docs.yaml, que hace mkdocs build --strict,
publica la imagen en el Registry de Gitea y Argo CD sincroniza el
Deployment en el cluster (namespace docs-portal). Este párrafo es la
prueba: si lo estás leyendo servido desde el pod real, el pipeline
funcionó de punta a punta.