feat(docs-portal): pipeline GitOps y manifiestos K8s para el portal MkDocs
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.
This commit is contained in:
@@ -0,0 +1,73 @@
|
||||
# Glosario
|
||||
|
||||
> Pensado para alguien que ve estos términos por primera vez. Definiciones
|
||||
> cortas primero, detalle técnico después. Se irá expandiendo en fases
|
||||
> siguientes — por ahora cubre los términos que ya aparecen en el resto
|
||||
> del sitio.
|
||||
|
||||
## GitOps
|
||||
|
||||
**En una frase:** el estado deseado del sistema vive en Git, y un
|
||||
proceso automático (no una persona con `kubectl`) se encarga de que el
|
||||
cluster real coincida con lo que dice Git.
|
||||
|
||||
**Detalle:** en vez de ejecutar comandos contra el cluster a mano, se
|
||||
edita un archivo YAML, se hace commit, y una herramienta (aquí, Argo CD)
|
||||
detecta el cambio y lo aplica. Si alguien cambia algo directo en el
|
||||
cluster sin pasar por Git, GitOps lo revierte (`selfHeal`) — Git es la
|
||||
única fuente de verdad.
|
||||
|
||||
## Tunnel (Cloudflare Tunnel)
|
||||
|
||||
**En una frase:** una forma de exponer un servicio interno a internet
|
||||
sin abrir puertos en el router/firewall.
|
||||
|
||||
**Detalle:** un proceso (`cloudflared`) corre dentro de la red local y
|
||||
abre una conexión saliente hacia Cloudflare. El tráfico público llega a
|
||||
Cloudflare y viaja hacia adentro por esa misma conexión — no hace falta
|
||||
port-forwarding ni IP pública propia.
|
||||
|
||||
## Argo CD
|
||||
|
||||
**En una frase:** el "robot" que sincroniza el cluster Kubernetes con
|
||||
lo que está escrito en Git.
|
||||
|
||||
**Detalle:** vigila uno o más repos Git, compara el estado declarado
|
||||
(manifiestos YAML/Kustomize) contra el estado real del cluster, y
|
||||
aplica la diferencia. Ver [flujo GitOps](gitops-flujo.md).
|
||||
|
||||
## Manifest (manifiesto)
|
||||
|
||||
**En una frase:** un archivo YAML que describe qué quieres que exista
|
||||
en Kubernetes (un Deployment, un Service, un Ingress...).
|
||||
|
||||
**Detalle:** Kubernetes no se controla escribiendo código imperativo
|
||||
("crea un pod"), sino declarando el resultado deseado ("quiero 2
|
||||
réplicas de esta imagen corriendo"). El manifiesto es ese documento.
|
||||
|
||||
## App of Apps
|
||||
|
||||
**En una frase:** un patrón donde una Application de Argo CD no
|
||||
despliega una app directamente, sino que despliega *otras*
|
||||
Applications.
|
||||
|
||||
**Detalle:** en este lab, `application.yaml` (raíz) vigila la carpeta
|
||||
`apps/` de `apps-registry`; cada archivo ahí dentro es una Application
|
||||
hija que a su vez apunta a un workload real. Permite agregar una app
|
||||
nueva con un solo archivo YAML nuevo.
|
||||
|
||||
## Kustomize
|
||||
|
||||
**En una frase:** una forma de componer manifiestos de Kubernetes sin
|
||||
plantillas (a diferencia de Helm).
|
||||
|
||||
**Detalle:** un archivo `kustomization.yaml` lista qué recursos YAML
|
||||
incluir y qué parches aplicarles, sin necesidad de un lenguaje de
|
||||
templating separado.
|
||||
|
||||
## TODO
|
||||
|
||||
- Namespace, ResourceQuota, LimitRange, NetworkPolicy
|
||||
- Ingress vs. Service vs. Deployment
|
||||
- StatefulSet (por qué Postgres lo usa y el frontend no)
|
||||
- Init container
|
||||
Reference in New Issue
Block a user