stack-viewer

Esta página corre dentro del cluster que describe. Si la estás viendo, el pipeline completo funcionó.

ambiente: development cluster: k3s-learning namespace: dev pod: stack-viewer-5d74dc7fdf-xkqbx dominio base: dev.cloudcentinel.com

Capas del stack

Infraestructura

k3s-infra

Ansible. Provisiona el servidor, endurece SSH/firewall, instala k3s y hace el bootstrap de Argo CD. No sabe nada de aplicaciones — su trabajo termina cuando Argo CD queda corriendo.

roles/, playbooks/site.yml

Estado deseado

k3s-gitops

Única fuente de verdad que Argo CD sincroniza: charts de Helm por app y las Applications que le dicen a Argo CD qué mirar. Nada de código de aplicación vive acá.

charts/, argocd-apps/

Motor de GitOps

Argo CD

Corre dentro del propio cluster. Hace pull de k3s-gitops, compara contra el estado real y reconcilia — nadie le hace push ni le corre kubectl apply desde afuera.

namespace argocd

Aplicación

stack-viewer (este repo)

Código + Dockerfile + workflow de CI. No tiene un solo YAML de Kubernetes — eso vive centralizado en k3s-gitops, no repartido por cada repo de app.

src, Dockerfile, .github/workflows/

De un commit a este pod

1. Push al repo de la appCódigo nuevo entra a main.

2. CI construye y publica la imagendocker build + push a ghcr.io, tag = SHA del commit.

3. CI edita k3s-gitopsBump de image.tag en values-<ambiente>.yaml, commit + push.

4. Argo CD detecta el diffPoll periódico contra el repo — nadie le avisa manualmente.

5. Argo CD sincronizaAplica el Deployment actualizado contra el cluster real.

6. k3s hace el rolling updateY estás viendo el resultado, ahora mismo, en esta página.