peter
f7dd98f6e5
A follow-up review of the previous fix caught that M1's DAYBOOK_HOST_DATA_DIR override wasn't carried through to the backup step or checklist - both still hardcoded deploy/data. Exactly when the override matters (a host with a separate/larger volume), the backup would silently tar the wrong directory while the checklist still read as complete. Backup and checklist now derive the path from deploy/.env instead of restating it. Also documents in docker-compose.yml why the .env interpolation only resolves correctly when invoked as `docker compose -f deploy/docker-compose.yml`, per a non-blocking note from the same review. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
29 lines
1 KiB
YAML
29 lines
1 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:
|
|
test: ["CMD", "curl", "-fsS", "http://127.0.0.1:8000/api/capabilities"]
|
|
interval: 30s
|
|
timeout: 5s
|
|
retries: 5
|
|
start_period: 20s
|