Saltar a contenido

ADR-0003 · Deploy por git pull + hot-reload en la VM, con imágenes latest

  • Estado: aceptado
  • Decisores: Hugo Quintero (único autor del repo)
  • Fecha de la decisión: no registrada. El workflow existe desde el primer commit del repo (2026-03-11, 1390638).

Contexto y problema

El stack es solo configuración (YAML, reglas, dashboards JSON). Cambiar un umbral o un target debía llegar a producción en minutos, sin construir imágenes ni interrumpir la recolección de métricas. Trabaja una sola persona, sin entorno de staging del stack.

Opciones consideradas

  1. GitHub Actions entra por SSH a la VM, hace git pull sobre el checkout de main en /opt/monitoring, llama a /-/reload de Prometheus y Alertmanager y corre docker compose up -d --remove-orphans.
  2. Construir imágenes con la config incluida y desplegarlas por tag.
  3. Gestor de configuración (Ansible) o GitOps con agente en la VM.

No hay registro escrito de la evaluación.

Decisión

Opción 1. El repo es el estado desplegado: lo que está en main es lo que corre. Prometheus habilita --web.enable-lifecycle para el reload caliente. Las imágenes de Prometheus, Alertmanager, Grafana y Blackbox se usan con tag latest; solo Loki está fijado (3.0.0).

Consecuencias

Positivas

  • Deploy en menos de un minuto y sin reiniciar Prometheus: no se pierden scrapes ni se corta el remote_write.
  • Rollback = git revert (ver runbook). Historial completo de cada cambio de umbral o target.

Negativas / deuda asumida

  • git pull exige que el árbol en la VM esté limpio y en main; un cambio hecho a mano en el servidor deja el próximo deploy en conflicto.
  • No hay validación previa (promtool check config) en el workflow y los curl -s de reload no usan -f: una regla mal escrita hace fallar el -/reload, Prometheus sigue con la config anterior y Actions queda en verde igual.
  • Tag latest: un docker compose pull o una recreación del contenedor puede traer una versión mayor nueva de Prometheus/Grafana sin aviso, y no hay forma de volver a la anterior desde el repo. Fijar versiones es la deuda que más se re-discute.
  • El reload no cubre blackbox.yml, loki/config.yml ni cambios de datasources de Grafana: esos requieren reiniciar el contenedor a mano.