Bernard Siebens
d30b163122
Closes every club subdomain with a 503 in that club's own colours, stands the scheduled jobs down, and keeps open exactly what is needed to end it again. The exemptions ARE the feature: - /accounts/ stays open on the base domain. Close it too and you cannot sign in to turn maintenance off -- a lock-down with no key, fixable only from a shell. - /healthz answers on every host. Close it and the load balancer decides the node is dead, stops routing to it, and takes the control panel down with everything else. - migrate and collectstatic are NOT blocked. Maintenance is usually declared in order to run them; a blanket guard on BaseCommand would mean turning the mode off to do the work you turned it on for. Only the domain jobs (archive_overdue_clubs, extend_event_series, import_members_csv) refuse, and they exit non-zero so cron mails you -- a scheduled job that silently skips itself is how a month of billing goes missing. The state is cached with a 10-second TTL, not for ever. Write-through makes the flip instant for the shared Redis of a real deployment, and the TTL is the belt to that braces: on a per-process cache -- a dev box with no Redis, or a misconfigured deploy -- a lock-down that reached only one gunicorn worker would be worse than useless. Live-verified: a club subdomain, its login page and the base domain all 503 while the control panel and the sign-in screens stay up. Also adds the two deployment pieces asked for: compose.behind-proxy.yaml for a dev/test box that already runs Caddy on :80 (app on the loopback, host Caddy proxies to it -- and the host's Caddy still needs the DNS plugin, because the wildcard is still a wildcard), and deploy/backup.sh + restore-check.sh with a cron schedule. The backup writes to a .part file and only lands it once gzip -t says it is readable: a truncated dump that looks like a backup is the failure you find on the day you need it. The weekly restore rehearsal is the only line in that cron that proves the rest work. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
56 lines
1.6 KiB
YAML
56 lines
1.6 KiB
YAML
# A dev/test deployment on a server that ALREADY runs Caddy on :80/:443.
|
|
#
|
|
# docker compose -f compose.behind-proxy.yaml up -d
|
|
#
|
|
# The difference from compose.yaml is only what listens on the network: no caddy service, and
|
|
# web publishes on the loopback instead of the public interface. The host's Caddy reverse
|
|
# proxies to it (see DEPLOYMENT.md, "Behind an existing Caddy").
|
|
#
|
|
# Publishing on 127.0.0.1 and not 0.0.0.0 is the point: bound to all interfaces, a test
|
|
# instance is reachable on http://<server-ip>:8001 with no TLS, bypassing the proxy and every
|
|
# security header with it.
|
|
|
|
name: rosterchief-test
|
|
|
|
services:
|
|
web:
|
|
build: .
|
|
restart: unless-stopped
|
|
env_file: .env.production
|
|
ports:
|
|
- "127.0.0.1:${WEB_PORT:-8001}:8000"
|
|
depends_on:
|
|
db:
|
|
condition: service_healthy
|
|
redis:
|
|
condition: service_started
|
|
healthcheck:
|
|
test: ["CMD", "curl", "-fsS", "http://localhost:8000/healthz"]
|
|
interval: 30s
|
|
timeout: 5s
|
|
retries: 3
|
|
start_period: 20s
|
|
|
|
db:
|
|
image: postgres:17-alpine
|
|
restart: unless-stopped
|
|
environment:
|
|
POSTGRES_DB: ${POSTGRES_DB:-rosterchief}
|
|
POSTGRES_USER: ${POSTGRES_USER:-rosterchief}
|
|
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?set a database password}
|
|
volumes:
|
|
- pgdata:/var/lib/postgresql/data
|
|
healthcheck:
|
|
test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER:-rosterchief}"]
|
|
interval: 10s
|
|
timeout: 5s
|
|
retries: 5
|
|
|
|
redis:
|
|
image: redis:7-alpine
|
|
restart: unless-stopped
|
|
command: ["redis-server", "--save", "", "--appendonly", "no"]
|
|
|
|
volumes:
|
|
pgdata:
|