Fix BRouter first-deploy issues discovered during cutover

Three fixes after the first cd-brouter run on the dedicated host:

1. **BRouter 1.7.8 → 1.7.9** (`docker/brouter/Dockerfile`). Planet RD5
   segments on brouter.de are now version 11; 1.7.8's `lookups.dat`
   is v10, causing `lookup version mismatch (old rd5?)
   lookups.dat=10 E10_N45.rd5=11` on every route request.

2. **cd-brouter.yml: docker login to ghcr.io before pull**.
   ghcr.io/trails-cool/brouter is private, and the dedicated host's
   Docker daemon isn't logged in by default. Extract DEPLOY_GHCR_TOKEN
   from SOPS at runner side, pass to the SSH step via envs, and
   `docker login` before `docker compose pull`. Credential is
   `::add-mask::`-ed so it doesn't show in logs.

3. **Drop custom healthcheck** on the brouter service. The image
   strips wget/curl post-build, and /bin/sh in the base doesn't
   support /dev/tcp, so there's no in-image way to do an HTTP probe.
   Real health is observed via Caddy's upstream 502 behavior on
   outage and the Planner-side `brouter_request_duration_seconds`
   metric. caddy's `depends_on` drops from service_healthy to
   service_started.

End-to-end verified on the dedicated host after applying the compose
fix manually:
- Caddy enforces auth: 403 without header, proxies with.
- BRouter 1.7.9 will resolve the segment-version error once the image
  is rebuilt.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Ullrich Schäfer 2026-04-23 23:21:46 +02:00
parent 9e598fb6a1
commit 3c4c1eebd8
No known key found for this signature in database
GPG key ID: A32FF691A0F752D9
3 changed files with 21 additions and 8 deletions

View file

@ -33,12 +33,10 @@ services:
max-file: "3"
labels:
trails.cool.service: "brouter"
healthcheck:
test: ["CMD-SHELL", "wget -q -O- http://localhost:17777/ >/dev/null 2>&1 || exit 1"]
interval: 30s
timeout: 5s
retries: 3
start_period: 60s
# No custom healthcheck: the BRouter image strips wget/curl post-build,
# and /bin/sh in the base image doesn't support /dev/tcp. Real health
# is observed via Caddy upstream (502 on outage) and the Planner-side
# brouter_request_duration_seconds metric.
caddy:
image: caddy:2-alpine
@ -46,7 +44,7 @@ services:
restart: unless-stopped
depends_on:
brouter:
condition: service_healthy
condition: service_started
# Bind ONLY to the vSwitch IP on the host — the dedicated host's
# public IP remains unaffected. UFW further restricts this to traffic
# sourced from the flagship's private IP (10.0.0.2).