No description
counterweight
73340d5fbe
409-line playbook becomes a 16-line playbook plus a 318-line role with phases
split across tasks/{prerequisites,install,configure,service,healthcheck}.yml and
four templates. forgejo_runner_vars.yml is deleted; its content is the role's
defaults.
Applies the Plan 6 Stage 0 decision: keep whatever determines whether the
service is healthy, drop the Uptime Kuma specifics, make the reporting point
pluggable. Gone from the role: the embedded Python that created monitors over
the Kuma API, the /tmp credentials file, token extraction, the systemd
Environment= rewrite, and 8 `when: uptime_kuma_enabled` guards. What remains is
the check itself, its log, the systemd unit and timer, and an honest exit code -
`systemctl is-failed forgejo-runner-healthcheck.service` now answers the
question with no monitoring system involved at all.
Reporting is one variable, healthcheck_push_url, empty by default. Any endpoint
that accepts an HTTP ping plugs in there. A pull-based monitor wants it left
empty and reads unit state instead.
PREMISE CORRECTION: Uptime Kuma is NOT dead. Plan 3 recorded "48 push timers
curling an endpoint that no longer answers" and Plan 6 said the check had
"nowhere to report to". Both wrong - 24+ push scripts across 11 hosts are
pushing successfully right now (HTTP 200). Only the Ansible code and the vault
credentials were decommissioned; the service never stopped. So the existing push
URLs were harvested into a vaulted healthcheck_push_urls dict and are preserved,
keeping this refactor behaviour-neutral. Retiring Kuma stays a deliberate act
rather than a side effect. PLAN_3 and PLAN_6 are corrected.
Verified:
- task-list diff vs the old playbook shows ONLY the five Kuma tasks removed,
everything else identical and in the same order
- first run ok=22 changed=1 (the rewritten health script); both systemd units
and forgejo-runner.service came back ok, so the templates reproduce the
previous files byte-for-byte
- second run ok=22 changed=0, fully idempotent
- still reports "Ping sent successfully (HTTP 200)" from a script containing
zero Uptime Kuma references
- the 4 skipped tasks are genuine already-configured guards, checked not assumed
Two things for the next service:
- import_tasks, not include_tasks. Dynamic includes are opaque to --list-tasks,
which is the primary verification tool here; the first attempt produced a
useless diff.
- `Assert runner is running` was guarded by uptime_kuma_enabled and so had not
run since the decommissioning. It is not monitoring, it is the deployment
checking its own work - the deprecation banner swept it up with the Kuma
plumbing, and a runner that failed to start was deploying "successfully" in
silence. Ungated now. The banner was applied to contiguous blocks, so read
every uptime_kuma_enabled guard and ask whether it is monitoring or deployment.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| ansible | ||
| archive/uptime_kuma | ||
| tofu/nodito | ||
| .gitignore | ||
| 01_infra_setup.md | ||
| 02_vps_core_services_setup.md | ||
| 03_vm_disk_enlargement.md | ||
| README.md | ||
| requirements.txt | ||
Personal infra
My repo documenting my personal infra, along with artifacts, scripts, etc.
How to use
Go through the different numbered markdowns in the repo root to do the different parts.
How to edit secrets
ansible-vault edit ansible/your_file_with_secrets.yml
Assumes that you've set ansible/.vault_pass with chmod 600.
Overview
Services
- Reverse Proxy
- Deployed on Vipy
- Caddy
- Plan install
- File based config
- Crossbackup to Desky via rsync
Uptime Kuma— decommissioned 2026-09-11, seearchive/uptime_kuma/- Deployed on Vipy
- Crossbackup to Desky via rsync
- Vaultwarden
- Deployed on Desky
- Crossbackup to Vipy via rsync
- Gitea
- Deployed on Desky
- Crossbackup to Vipy via rsync
- Immich
- Deployed on Desky
- VPN
- All set up on Vipy
- Bitcoin Knots
- Deployed on Desky
- electrs
- Synapse Server
- Phoenix D + LNBits
- Backups
Infra
- Laptop (Lapy)
- One beefy desktop (Desky)
- One VPS (Vipy)