devops
0234c20463
mkdocs build --strict aborta ante CUALQUIER WARNING, no solo ante links rotos. El plugin, al no tener .git real en el contexto de build (workloads/docs-portal/, sin .git de la raíz del repo), cae siempre en fallback_to_build_date y emite un WARNING por página — suficiente para tumbar el build bajo --strict (confirmado en run 96, job 108: 33 warnings, todos de este plugin, cero links rotos). Se deshabilita el plugin (comentado en mkdocs.yml y requirements.txt, con TODO fase 2: mover el build a la raíz del repo + fetch-depth:0 para darle historial real) y se revierte la instalación de git en el Dockerfile, que ya no hace falta. index.md actualizado para no prometer fechas reales que hoy no se muestran.
3.3 KiB
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.