daybook/deploy/docker-compose.yml
peter ca8e364010 Fix healthcheck + verify commands; reframe deploy runbook for a capable agent
Real bug: the container healthcheck (and the docs' verify step) hit
/api/capabilities, which returns 403 unauthenticated; curl --fail treats
403 as an error, so a healthy container would report "unhealthy" and the
verify step would look like a failure. Healthcheck now hits /accounts/login/
(200, no auth). Verify commands now print the status code and note not to
use curl -f on the 403.

Also reframed cloud_agent_deploy.md's intro for an Opus-class deploy agent:
it's a guide + Daybook-specific gotchas, not a rigid script — points at the
authoritative sources (repo incl. the git-SSH :2222 note, deploy/ files,
requirements.txt deps auto-installed, entrypoint runs migrate+collectstatic,
docs/deployment.md) and trusts the agent's judgment. Dropped the now-
redundant Source Of Truth section.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-03 14:32:39 +01:00

33 lines
1.3 KiB
YAML

# ${VAR} substitution below (DAYBOOK_BIND_ADDR, DAYBOOK_HOST_DATA_DIR) reads
# from deploy/.env because Compose resolves .env relative to *this file's*
# directory, not the caller's cwd. That relies on being invoked as
# `docker compose -f deploy/docker-compose.yml` from the repo root, per
# deploy/cloud_agent_deploy.md and docs/deployment.md. If that invocation
# pattern ever changes, re-verify these still resolve — a silent fallback to
# the defaults (0.0.0.0 bind, ./data) would be a security regression, not
# just a broken build.
services:
daybook:
build:
context: ..
dockerfile: deploy/Dockerfile
container_name: daybook
restart: unless-stopped
env_file:
- .env
mem_limit: 384m
mem_reservation: 128m
ports:
- "${DAYBOOK_BIND_ADDR:-0.0.0.0}:8000:8000"
volumes:
- ${DAYBOOK_HOST_DATA_DIR:-./data}:/data
healthcheck:
# Hit the login page, not /api/capabilities: capabilities returns 403
# when unauthenticated, and `curl --fail` treats 403 as an error, which
# would mark a perfectly healthy container unhealthy. The login page
# serves 200 without auth and still proves Django is up and responding.
test: ["CMD", "curl", "-fsS", "http://127.0.0.1:8000/accounts/login/"]
interval: 30s
timeout: 5s
retries: 5
start_period: 20s