3.1 KiB
+++ title = "Corregir despliegue de clusterlog en Caddy y dar persistencia al runner de Gitea Actions" description = "Bloque de Caddy faltante para clusterlog.mcps-epcm.org agregado; runner nativo de Gitea Actions pasado de proceso manual a systemd." date = 2026-08-19T18:56:10Z authors = ["gen"] slug = "mem-20260819-51dea9-corregir-despliegue-de-clusterlog-en-caddy-y-dar-persistencia-al-runner-de-gitea-actions" template = "memory.html"
[taxonomies] categories = ["memorias"] tags = ["caddy", "clusterlog", "gitea-actions", "systemd"] systems = ["caddy", "gitea-runner", "mcps-hpc-01"]
[extra] id = "MEM-20260819-51DEA9" kind = "memory" author_id = "gen" author_fingerprint = "SHA256:JhN1Tt4jYqWoJIznDJ6QkMAiOR6HFHr3xLz9aBJqmPg" risk = "medium" ticket = "" review_required = true review_policy = "all-active" reviewer_snapshot = true reviewers = ["gen"] started_at = "" finished_at = "" duration_minutes = 0 agent = "claude-code" +++
Contexto
clusterlog.mcps-epcm.org (contenedor nginx clusterlog, 10.89.0.4:80 en mcps-net) y su DNS ya existían, pero la página no cargaba: faltaba el bloque correspondiente en /mnt/cephfs/hot/caddy/Caddyfile. Al revisar la infraestructura se encontró además que el runner de Gitea Actions (act_runner v0.2.13, ya registrado contra Gitea, uuid 5844d409-..., nombre de runner mcps-hpc-01, label ubuntu-latest:host, corre jobs directo en el host sin contenedores) llevaba 7 tareas procesadas corriendo a mano como proceso del usuario gen, sin systemd, sin sobrevivir a un reinicio. De paso se encontró, sin corregir, que la cuenta ACME de Let's Encrypt de todo Caddy #2 usa como contacto angel.pacheco@mcps-epcm.org, correo restringido en un offboarding en curso — los avisos de renovación fallida ya no le llegan a nadie; pendiente cambiar el email global del bloque { email ... } del Caddyfile.
Cambios realizados
- Agregado el bloque de Caddy para clusterlog.mcps-epcm.org en /mnt/cephfs/hot/caddy/Caddyfile, mismo patrón DNS-01 vía Route53 que el resto de dominios
- Creado /etc/systemd/system/gitea-runner.service (User=gen, WorkingDirectory=/opt/gitea-runner, ExecStart=/opt/gitea-runner/act_runner daemon, Restart=always), habilitado; se terminó el proceso manual y se levantó por systemd conservando el mismo uuid/identidad de runner ya registrado, sin re-registrar nada
Comandos relevantes (secretos redactados)
caddy validate
caddy reload
systemctl enable --now gitea-runner.service
Validación
- caddy validate limpio antes de hacer reload
- curl sirviendo 200 en la ruta del manual real de clusterlog.mcps-epcm.org tras el reload, sin downtime del resto de sitios detrás de Caddy
- Certificado Let's Encrypt emitido en ~30s tras el reload
- El runner levantado por systemd conservó el mismo uuid/identidad ya registrado en Gitea
Riesgo y reversión
Quitar el bloque agregado del Caddyfile y ejecutar caddy reload revierte clusterlog.mcps-epcm.org al estado anterior (dominio sin servir). Para el runner, systemctl stop gitea-runner.service y volver a correr ./act_runner daemon a mano restauraría el modo anterior, sin persistencia (no recomendado).