devops
fb5cf8bc98
Agrega lo que faltaba para desplegar workloads/docs-portal/ (ya existente sin commitear): deployment/service/ingress + kustomization siguiendo el patrón de workloads/nginx, Applications de workload y gobernanza separadas, y el workflow de Gitea Actions (build+push a Gitea Registry, bump de versión en el manifiesto) siguiendo el mismo patrón que build.yaml/build-medusa.yaml.
52 lines
2.3 KiB
Markdown
52 lines
2.3 KiB
Markdown
# Guía del estudiante — ruta de aprendizaje sugerida
|
|
|
|
> Escrita para alguien que **nunca ha visto GitOps ni Kubernetes**. Si
|
|
> ya conoces estos conceptos, probablemente quieras saltar directo a
|
|
> [Arquitectura](../arquitectura/vision-general.md) o
|
|
> [Decisiones](../decisiones/0001-por-que-k3d.md).
|
|
|
|
> **TODO (fase 2+):** convertir esto en una ruta paso a paso completa,
|
|
> con ejercicios o preguntas de verificación al final de cada parada.
|
|
> Por ahora es el esqueleto de la ruta.
|
|
|
|
## Antes de empezar
|
|
|
|
No hace falta saber Kubernetes de antemano. Sí ayuda tener claro qué es
|
|
un contenedor Docker — si eso todavía no es familiar, empieza por ahí
|
|
antes de seguir.
|
|
|
|
## Ruta sugerida
|
|
|
|
1. **[Conceptos básicos](conceptos-basicos.md)** — qué es un contenedor,
|
|
qué es Kubernetes, qué problema resuelve.
|
|
2. **[Glosario](../arquitectura/glosario.md)** — términos clave
|
|
(GitOps, tunnel, Argo CD, manifest) explicados en una frase antes del
|
|
detalle técnico.
|
|
3. **[Visión general de arquitectura](../arquitectura/vision-general.md)**
|
|
— el diagrama completo: cómo llega una petición desde el navegador
|
|
hasta la aplicación real.
|
|
4. **[Flujo GitOps](../arquitectura/gitops-flujo.md)** — qué pasa
|
|
exactamente entre que alguien hace `git push` y el cambio queda
|
|
corriendo.
|
|
5. **Un playbook real** — empieza por
|
|
[el incidente del crashloop de Medusa](../playbooks/incidente-crashloop-medusa.md):
|
|
es un buen ejemplo de cómo se descarta una hipótesis con evidencia en
|
|
vez de adivinar.
|
|
6. **Una decisión de arquitectura (ADR)** — lee
|
|
[por qué k3d](../decisiones/0001-por-que-k3d.md) para ver cómo se
|
|
documenta un trade-off real, no solo la elección final.
|
|
|
|
## Si esto se convierte en proyecto de grado
|
|
|
|
Este lab es candidato razonable de base para un proyecto de grado
|
|
porque ya tiene: infraestructura real corriendo, incidentes reales
|
|
documentados con causa raíz, y decisiones arquitectónicas explícitas
|
|
en vez de implícitas. La sección de
|
|
[aprendizajes](../aprendizajes/notas-sueltas.md) es un buen punto de
|
|
partida para encontrar preguntas de investigación abiertas (deuda
|
|
técnica, mejoras pendientes) en vez de inventar un tema desde cero.
|
|
|
|
**TODO:** definir aquí, en una sesión futura, el alcance concreto de
|
|
ese posible proyecto de grado (¿extender el lab? ¿documentar y
|
|
analizar el patrón? ¿construir sobre él?).
|