Mantenerlo funcionando es un trabajo en sí mismo.

Se espera que cualquier servicio desplegado así ya tenga un target de Prometheus, un monitor de Uptime Kuma, y a poder ser un dashboard de Grafana antes de desplegarse — esa expectativa es de lo que trata en realidad la siguiente sección.

Esta web — la que sirve la página que estás leyendo — es un buen ejemplo concreto, porque un único pipeline despliega dos tipos de artefacto genuinamente distintos desde el mismo monorepo.

git push → GitHub webhook → Jenkins
  → docs: mkdocs build --strict → rsync to the internal proxy
  → webpage: Docker build → Harbor push → Compose deploy on the public-facing host
  → health check both projects
  → notify Telegram per project, or once on pipeline failure
  → agent workspace cleaned either way

Unas cuantas decisiones de diseño detrás de esto, que merece la pena conocer en lugar de simplemente asumir:

• Los docs se despliegan por rsync, no por container. El sitio de docs es HTML estático; empaquetarlo como imagen solo para redesplegarlo a través de Harbor añadiría un round-trip al registry para nada. El proxy ya sirve los archivos directamente, así que Jenkins solo necesita hacer build y copiar.
• La webpage se despliega como imagen. Se construye desde apps/webpage, se publica en Harbor etiquetada por commit corto y número de build, y se redespliega vía Compose en el host expuesto al público.
• Los dos proyectos se redespliegan en cada push, con o sin detección de rutas. La lógica de detección de rutas se seguía rompiendo en escenarios de first-build y replay en Jenkins, de formas fáciles de pasar por alto. Los dos builds son lo bastante pequeños como para que reconstruirlo todo cada vez sea más simple y seguro que intentar ser listo con ello.
• Telegram es toda la ruta de notificación. Un mensaje de éxito por proyecto desplegado, un mensaje de fallo con la stage que falló, el commit, y un enlace a la consola si el pipeline se rompe. Nada de email, ningún dashboard que tenga que acordarme de revisar.
• El workspace del build siempre se limpia, tanto si hay éxito como si hay fallo. cleanWs() se ejecuta incondicionalmente en post { cleanup {} }, así que una ejecución fallida nunca deja artefactos a medio construir con los que tropiece la siguiente.

El stack detrás de esa tabla se divide en cinco piezas, cada una haciendo exactamente un trabajo:

Prometheus hace scrape cada 15 segundos, y los targets que varían por host o segmento vienen de archivos JSON de file_sd_configs en lugar de la config principal — añadir una máquina suele ser editar un archivo de targets, no reescribir Prometheus en sí.

Grafana Alloy envía los logs de cada host que lo ejecuta a Loki, guardados 30 días en almacenamiento local en filesystem. El ruler de Loki ya apunta al mismo Alertmanager que usa el alerting de métricas, así que el alerting basado en logs puede reutilizar exactamente esa ruta en cuanto esas reglas se escriban de verdad — ahora mismo, todavía no existe ninguna.

Alertmanager y Uptime Kuma notifican los dos a través de Telegram, pero están respondiendo preguntas distintas. Alertmanager dispara según lo que dicen las métricas que va mal — CPU alta, un target que se queda callado, una base de datos sin conexiones libres — con las alertas críticas repitiéndose más rápido que las warnings, y una warning para un host suprimida mientras ya está disparada una alerta crítica para ese mismo host. Uptime Kuma no mira métricas en absoluto; es una comprobación de fuera hacia dentro, si este endpoint responde de verdad o no. El solape es deliberado: uno detecta degradación interna que el otro no puede ver, el otro detecta «simplemente inalcanzable» incluso cuando todas las métricas internas siguen pareciendo bien.

Un puñado de reglas evita que todo el stack se desmadre a medida que crece:

• Todo host nuevo recibe node_exporter y Grafana Alloy. Sin excepciones — esa es la base mínima antes de instalar nada más en él.
• cAdvisor solo donde Docker corre de verdad. No tiene sentido hacer scrape de métricas de containers en un host que no tiene ninguno.
• Uptime Kuma solo donde importa la accesibilidad de cara al usuario. No todos los servicios internos necesitan una comprobación de fuera hacia dentro — solo los que la gente, o los clientes, usan de verdad.
• Las reglas de alerta existen solo para condiciones sobre las que alguien debería actuar. Ninguna alerta sin una acción detrás, o es solo ruido que se acaba silenciando una semana después.
• Las reglas de firewall siguen las rutas de scrape, no al revés. Las métricas no tienen un bypass por ser métricas — que Prometheus llegue a un exporter de base de datos sigue siendo una regla explícita y estrecha.

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

Esa última parte — node_exporter y Grafana Alloy en cada host — es lo que mantiene honesta la sección de observability de arriba. Una máquina que no está reportando métricas dentro de un intervalo de scrape desde que se pone en marcha se trata como un bug de setup, no como una tarea de limpieza para después.

$ ./bootstrap-host.sh vm-207
==> creating admin user, disabling root SSH login
==> disabling password authentication
==> installing node_exporter, grafana-alloy
==> registering Prometheus target: node-internal
[ok] vm-207 reporting metrics — 1 scrape interval elapsed

Reiniciar un nodo de Proxmox para una actualización de kernel o trabajo de hardware sigue la misma disciplina en la dirección contraria: primero drenarlo — hacer live-migrate de lo que se pueda mover, parar deliberadamente lo que no — confirmar que no queda nada corriendo en local, y luego reiniciar y vigilar que se reincorpore al cluster. Los nodos van de uno en uno, nunca más, porque el cluster necesita al menos dos de los tres sanos para mantener el quorum; el siguiente no empieza hasta que pvecm status muestra que el anterior ha vuelto del todo.

$ qm list --node pve02        # live-migrate anything running
$ pct list --node pve02       # stop what can't move
$ qm list --node pve02 && pct list --node pve02
(empty — pve02 is clear)
$ reboot
...
$ pvecm status | grep Quorate
Quorate: Yes

Service defined → VLAN chosen → address and DNS assigned
  → proxy/firewall path reviewed → observability added
  → persistence risk noted → documentation updated

Las dos decisiones que de verdad importan son en qué segmento aterriza y cuál de los tres proxies lo expone — las dos se derivan directamente de qué es el servicio, no de la comodidad:

Todo lo que viene después de esa ubicación sigue de forma mecánica: la regla de firewall más estrecha que encaje con la ruta real, nunca un allow amplio de segmento a segmento; los agentes de observability estándar; un monitor de Uptime Kuma si es de cara al usuario; y, si almacena algo, una nota explícita de que esos datos todavía no tienen backup — fingir lo contrario le quitaría el sentido a escribir nada de esto con honestidad.

$ pvecm status
Quorum information
------------------
Nodes:            3
Quorate:          Yes

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 pve01 (local)
0x00000002          1 pve02
0x00000003          1 pve03

Los runbooks que existen hoy, agrupados por lo que cubren:

La segunda es la automatización, o la falta de ella ahora mismo. El setup base de máquinas — la secuencia de bootstrap cubierta antes, en mantener los hosts consistentes — todavía se escribe a mano en cada host nuevo, no se ejecuta desde Ansible o OpenTofu. Es consistente porque sigo el mismo runbook cada vez, no porque una máquina lo imponga, que es una garantía notablemente más débil.

Una más, pequeña: uno de los tres nodos todavía no tiene Wake-on-LAN configurado correctamente. La razón es tan trivial como pueda serlo — nadie ha conectado un monitor para cambiar el ajuste de BIOS correspondiente — y como ese nodo ya tiene gestión de energía out-of-band, no ha sido lo bastante urgente como para arreglarlo.

Las dos carencias grandes están registradas, no ignoradas — el backlog completo y actual (objetivos de backup, pruebas de restauración, rollout de identidad y secrets, infrastructure-as-code) vive en /roadmap, archivado como una lista de tareas honesta y no como una lista de deseos.

• Ansible y OpenTofu deberían haber empezado el primer día, no ahora. Cuando esto eran dos máquinas, adoptar infrastructure-as-code casi no habría costado nada. Con el desparrame actual de hosts y servicios, incorporarlo ahora es fricción real y constante — tanta que sigo sin llegar a hacerlo, que es exactamente la carencia de automatización descrita arriba. Hacerlo pronto habría mantenido sincronizada la configuración de cada host sin tocar cada una a mano.
• Segmentar la red mereció la pena, complejidad incluida. Ocho segmentos y las reglas de firewall que los acompañan hacen que los cambios del día a día sean genuinamente más trabajo de lo que sería con una red plana. Volvería a tomar la misma decisión — el aislamiento que consigue vale la fricción de mantenerlo.

Desde aquí: /system cubre lo que existe de verdad — el hardware, la red, los servicios que este pipeline despliega y que este stack vigila. /security cubre cómo se controla el acceso a todo ello. /roadmap es el backlog actual, en orden.