Qué servidores gestiono y cómo los llevo con GitOps

Rubén García Hernando

Arquitecto de software e investigador

No sabría entender este trabajo sin la investigación. Tras tres años en el CERN, al volver a Bilbao decidí trabajar por mi cuenta y seguir investigando y aprendiendo. Creo que emprender es el reto profesional definitivo, y a la vez una expresión de creatividad y un reclamo de libertad.

Zetesis viene del griego ζήτησις, indagación: buscar la causa antes de proponer la solución.

Gestiono los servidores de mis proyectos y de algunos clientes. Unos están en dos casas y otros son cuatro servidores alquilados en internet. Casi toda su configuración vive en un único repositorio de git, y un cambio en ese repositorio llega solo a la máquina que toca.

Este post es el mapa: qué máquinas hay, de qué se encarga cada una y cómo se despliega lo que corre en ellas. La red que las une, con VyOS, el túnel entre las casas y Tailscale, la cuento en el siguiente.

Dos casas en una sola red y cuatro servidores en internet

Cada casa tiene su router, y un túnel cifrado permanente entre los dos las une en una sola red: desde una máquina de la primera casa llego a las de la segunda como si estuvieran en la misma habitación. Los cuatro servidores de internet son VPS, máquinas virtuales alquiladas con IP pública. Las casas no se abren a internet; el tráfico público entra por los VPS.

De qué se encarga cada máquina

Máquina	Dónde	Se encarga de	Cómo se despliega
Cluster de Kubernetes de producción	Casa 1	Zetesis RAG y el resto de aplicaciones propias	Argo CD
Cluster de Kubernetes de plataforma	Casa 1	Los secretos (Infisical), las imágenes y los charts (Harbor), la base de datos compartida y las métricas, los logs y las trazas	Argo CD
Router	Una en cada casa	Cortafuegos, salida a internet y el túnel entre las casas	Configuración en git
Servidor Docker	Uno en cada casa	Domótica y servicios de la casa	Agente que revisa git
NAS	Casa 2	Copias de seguridad de todo lo demás	A mano
VPS de entrada	Internet	Recibe el tráfico web y lo reenvía al servicio que toca	Agente que revisa git
VPS de preproducción	Internet	La preproducción de otro producto propio	Agente que revisa git
Dos VPS de clientes	Internet	Webs y foros	Agente que revisa git

Las máquinas por su función, sin sus nombres.

Los dos clusters usan Talos Linux y tienen un solo nodo cada uno. El de producción corre en una máquina virtual sobre Proxmox, y el de plataforma, en un mini PC dedicado. Los routers y los servidores Docker también son máquinas virtuales de Proxmox, que permite tener varias en un mismo equipo.

Por qué separar las responsabilidades

Separarlas sirve para que un fallo se quede donde ocurre. Si se cae la preproducción, producción ni se entera. Si se cae el cluster de plataforma, las aplicaciones de producción siguen funcionando con los secretos y las imágenes que ya tienen, aunque no puedo desplegar nada nuevo hasta que vuelva. Y las copias están en la otra casa: si pierdo la primera, los datos siguen en la segunda.

Separar no da alta disponibilidad. Cada cluster tiene un solo nodo, y si ese nodo se para, se para lo que corre en él.

Una carpeta por máquina en un solo repositorio

La configuración de estas máquinas está en un repositorio de git, con una carpeta por máquina que dice qué contenedores corren y con qué versión. Para cambiar algo, cambio el fichero y lo subo. No hace falta entrar por SSH en el servidor.

Quién aplica el cambio depende del tipo de máquina. En los clusters lo hace Argo CD, que compara lo que hay en el repositorio con lo que corre en el cluster y corrige la diferencia. En los servidores Docker corre doco-cd, un agente que revisa el repositorio cada tres minutos y, si su carpeta cambió, levanta los contenedores con la configuración nueva. Los routers tienen su configuración en el mismo repositorio, generada a partir de plantillas.

Cuando publico una versión nueva de Zetesis RAG, el CI abre un pull request en este repositorio con la versión nueva, y al aceptarlo Argo CD la despliega. Cada despliegue queda registrado como un commit, con su fecha y lo que cambió.

Los secretos no van en claro en git

Las contraseñas y las claves salen de Infisical. En los clusters las lleva External Secrets Operator, y los servidores Docker las reciben de Infisical al desplegar. Lo poco que tiene que estar en git, como los secretos de los routers o lo necesario para arrancar un cluster desde cero, va cifrado con SOPS. Cómo funciona en Kubernetes lo conté en Infisical y GitOps.

Lo que todavía se hace a mano

Los nodos Proxmox y el NAS se configuran a mano. Si tuviera que rehacer uno, el repositorio no me lo daría hecho y tendría que repetir los pasos. Los nombres de cada máquina y más detalle de cada pieza están en la serie Montar un homelab desde cero.

Seguir leyendo

Esquema de GitOps del vídeo de Zetesis: configuración en Git, imagen en Harbor, Argo CD y Kubernetes, y los secretos de Infisical llegando a los pods por External Secrets

Consultoría de software, negocio e IA

Qué puedo hacer por ti

Estandariza cómo programa tu equipo con IA

Haz que la IA trabaje con el conocimiento de tu empresa

Convierte tu prototipo en un producto vendible

Desbloquea los problemas que rebotan entre negocio y tecnología

Estandariza cómo programa tu equipo con IA

Haz que la IA trabaje con el conocimiento de tu empresa

Convierte tu prototipo en un producto vendible

Desbloquea los problemas que rebotan entre negocio y tecnología

Estandariza cómo programa tu equipo con IA

Haz que la IA trabaje con el conocimiento de tu empresa

Convierte tu prototipo en un producto vendible

Desbloquea los problemas que rebotan entre negocio y tecnología

Cómo trabajo

La primera conversación

El mapa

Criterio

Prueba

Implementación

Lo que he construido

Productos

Zetesis RAG

Graphmarks

Sebastián

Praeco

Escriba

Proyectos

Konect

Homelab

Escohotado

Grafo del CERN

CERNphone

Keycloak

Naiz Fit

Zetesis RAG

Simulador de la Renta

LLMOps

Harbor

Colaboraciones

Rubén García Hernando