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.
74 lines
2.6 KiB
Markdown
74 lines
2.6 KiB
Markdown
# 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
|