counterweight
bf3d21fef7
Nothing in the repo pushes to, authenticates against, or is gated by Uptime
Kuma any more.
── The sixth instance of the banner bug ────────────────────────────────────
memos had `Restart memos` guarded by `uptime_kuma_enabled`, because the
deprecation banner was placed immediately above it and swept it in. It is a
HANDLER, so every memos config change since 2026-09-11 applied to disk and
silently never restarted the service. Ungated.
That is the same failure found in forgejo-runner's self-assert, phoenixd's timer
enable, mempool's three timer enables, fulcrum's restart handler and bitcoind's
restart handler. Every guard was read and asked "monitoring or deployment?"
before being deleted, which is the only reason this was caught.
── What was removed ────────────────────────────────────────────────────────
30 uptime_kuma_enabled guards across 7 unconverted service playbooks, and
the 29 Kuma monitor-creation tasks they gated (embedded Python that drove
the Kuma API, temp credential files, cleanup)
7 dead uptime_kuma_api_url definitions
7 stale DEPRECATED banners
uptime_kuma_enabled and subdomains.uptime_kuma from group_vars/all
healthcheck_push_urls from the vault - 30 push tokens
services/ntfy/setup_ntfy_uptime_kuma_notification.yml -> archive/
The explanatory comments in the six converted roles are KEPT on purpose. They
record why a handler is ungated, and deleting the explanation invites someone
to helpfully re-add the guard.
── The probes moved rather than died ───────────────────────────────────────
Eight per-service health checks were still pushing to Kuma. They are not
superseded by infra/401: that answers "is the unit running", these answer "does
the service actually respond" - an RPC call to bitcoind, a TCP connect to
Fulcrum's Electrum port, an HTTP fetch from Mempool's backend. A process can be
perfectly `active` and useless.
So they were repointed, not deleted. Gatus external endpoints take a POST with
a bearer token and success=true|false where Kuma took a GET with ?status=up, so
report() now maps up/down to true/false internally and no call site changed.
Registered by infra/403 as the `probe` group, one token per host.
Two bugs fixed while in there:
* forgejo-runner's check only ever reported SUCCESS - it exited before pushing
when the runner was down, so a failure was invisible until the heartbeat
window expired. Reporting the failure is the entire point of a check.
* All six healthcheck .service units were mode 0644 and now carry a bearer
token. They are 0600.
Verified: 91 endpoints, 91 UP, 0 DOWN. Every probe triggered by hand and
confirmed arriving. Zero Kuma URLs left in the vault, zero live references in
any playbook or role.
Still standing, deliberately: the Kuma container on watchtower, its Caddy vhost,
and the uptime.contrapeso.xyz DNS record. Turning the service off is a separate
decision from removing the code that talked to it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| defaults | ||
| tasks | ||
| templates | ||
| README.md | ||
mempool
Deploys the Mempool block explorer as a three-container
Docker Compose stack — MariaDB, backend, frontend — on mempool-box, and keeps a
health check on each.
Converted from deploy_mempool_playbook.yml (745 lines) under Plan 6. The
playbook is now 37 lines: this role, plus a second play that publishes the
frontend through Caddy on the edge host.
Phases
docker.yml |
Docker engine: repo, key, packages, service |
deploy.yml |
directories, docker-compose.yml, pull, up, wait-for-healthy |
healthcheck.yml |
three check scripts, three services, three timers |
Three health checks, not one
Mempool is three moving parts and knowing which one is down is the point, so
each gets its own check, unit and timer, driven by the mempool_healthchecks
list:
| checks | |
|---|---|
mariadb |
docker inspect health status of mempool-db |
backend |
GET /api/v1/backend-info |
frontend |
GET / |
Each records its answer in its exit code, which systemd keeps:
systemctl is-failed mempool-backend-healthcheck.service. Reporting elsewhere
is one field per check, push_url, and is the plug-in point for whatever
monitoring exists. Empty means check, exit honestly, report nowhere. The URLs
are credentials, so callers pass them from the vault.
Nothing here is specific to a monitoring product. The embedded Python that
created monitors over the Uptime Kuma API, the /tmp credentials file, the
push-URL file read back and parsed, and three systemd Environment= rewrites
are gone.
MariaDB owns its own data directory
{{ mempool_mysql_dir }} is bind-mounted into the container, which runs as uid
999 and must create files there. The playbook this replaced declared
owner: "{{ ansible_user }}" (1000) on it, which had drifted from reality ever
since the containers were created — unnoticed, because the playbook had not been
run since.
That was not academic. The first real run of this role pulled a newer
mariadb:10.11 and recreated mempool-db; had the chown still been in place,
MariaDB would have come back to a directory it could not write. The role now
ensures the directory exists and leaves ownership to the container.
mempool_frontend_port lives in services_config.yml
Two hosts need it: this role deploys the frontend on mempool-box, and the Caddy
play proxies to it from the edge host. A role default is invisible to the second
play, so the value lives in service_settings.mempool.frontend_port and the role
default derives from it.
Expect changed=2 on a converged host
Pull Mempool images and Deploy Mempool containers with docker compose are
bare command: tasks with no changed_when, so they always report changed.
That is the idempotent floor, not drift. Everything else reports ok.
mariadb:10.11 is a moving tag, so a run can pull a newer patch release and
recreate the database container. Pin it if that is not what you want.