BBergleandClaude Sonnet 5
5d4d76203f
Phase 0 deployment: three-service docker-compose.yml (caddy, api, db), a Caddyfile that proxies /api/* to the api service and serves the SPA with index.html fallback, and two Gitea Actions workflows (release.yml builds and pushes both images on a v* tag or manual dispatch; deploy.yml is manual-only and rolls them out to the Unraid host). The non-obvious part is the Docker-outside-of-Docker constraint on this act_runner setup: job containers share the host's Docker daemon over the socket but do NOT share its filesystem, so any command whose correctness depends on a client-side local path (docker cp to a host path, mv/rm -rf on a host path, a bind-mount source path on a `docker run` command line issued from inside a job) silently operates on the ephemeral job container's own throwaway filesystem instead. Two things are safe: a bind mount declared in a compose file's `volumes:` block (resolved by the daemon when `docker compose up` creates the service — this is why db's pgdata bind mount is fine), and a named volume populated by a one-shot `docker run` whose *command* does the copying (this is why the web image's static build output goes into a `web_build` named volume via `docker run -v ... sh -c 'cp -a ...'` in deploy.yml, rather than any `docker cp`). Local verification (see PR description for full detail) caught a real bug: `docker compose run api alembic upgrade head` needs VELODROME_DB_APP_PASSWORD/VELODROME_DB_AUTH_PASSWORD as container env vars to create the two runtime roles, but --env-file alone doesn't inject them since the api service's permanent environment block deliberately omits them (least-privilege — the long-running app should never need role-creation passwords). Fixed by passing them as explicit -e overrides on the migration step, same as VELODROME_DATABASE_URL_MIGRATE. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
68 lines
2.9 KiB
YAML
68 lines
2.9 KiB
YAML
# Phase 0 deployment stack: caddy + api + db.
|
|
#
|
|
# Deliberately NOT included yet: a `worker` service running `procrastinate worker`. Nothing in
|
|
# Phase 0/1 enqueues background jobs — that arrives with the ingestion pipeline. Adding it now
|
|
# would just be an idle container. See docs/PLAN.md's "Service topology".
|
|
#
|
|
# The `web` image (apps/web/Dockerfile) is built and pushed by release.yml but never runs as a
|
|
# service here — its only output is a static /app/build directory. deploy.yml populates the
|
|
# `web_build` named volume from it with a one-shot `docker run`, entirely server-side against the
|
|
# Docker daemon, before `caddy` starts. See deploy.yml for why this has to be done that way
|
|
# (Gitea's runners are Docker-outside-of-Docker: job containers don't share a filesystem with the
|
|
# host, so a client-side host path on a `docker cp`/`docker run -v` issued from inside a job
|
|
# silently resolves against the wrong filesystem and does nothing).
|
|
#
|
|
# Invoke with: docker compose --env-file /mnt/user/appdata/velodrome/.env -f deploy/docker-compose.yml ...
|
|
|
|
services:
|
|
caddy:
|
|
image: caddy:2-alpine
|
|
restart: unless-stopped
|
|
ports:
|
|
- "8090:80"
|
|
volumes:
|
|
- ./Caddyfile:/etc/caddy/Caddyfile:ro
|
|
- web_build:/srv/web:ro
|
|
depends_on:
|
|
- api
|
|
|
|
api:
|
|
image: 192.168.0.3:3000/bbergle/velodrome-api:${TAG:-latest}
|
|
restart: unless-stopped
|
|
environment:
|
|
# Superuser DSN (VELODROME_DATABASE_URL_MIGRATE) is deliberately NOT here — the
|
|
# long-running app process must never hold superuser DB credentials. It's passed only as a
|
|
# one-off `-e` override on the migration step in deploy.yml. See apps/api/README.md's "Why
|
|
# two database connections".
|
|
VELODROME_DATABASE_URL_APP: ${VELODROME_DATABASE_URL_APP}
|
|
VELODROME_DATABASE_URL_AUTH: ${VELODROME_DATABASE_URL_AUTH}
|
|
VELODROME_SECRET_KEY: ${VELODROME_SECRET_KEY}
|
|
VELODROME_ENVIRONMENT: production
|
|
VELODROME_PUBLIC_URL: http://192.168.0.103:8090
|
|
depends_on:
|
|
db:
|
|
condition: service_healthy
|
|
|
|
db:
|
|
image: postgis/postgis:16-3.4
|
|
restart: unless-stopped
|
|
environment:
|
|
POSTGRES_USER: postgres
|
|
POSTGRES_PASSWORD: ${POSTGRES_SUPERUSER_PASSWORD}
|
|
POSTGRES_DB: velodrome
|
|
volumes:
|
|
# Bind-mounted directly (not a named volume) — this is safe under DooD because it's
|
|
# resolved by the Docker daemon when `docker compose up` creates the service, not by any
|
|
# client-side path handling inside a job container. See the header comment above.
|
|
- /mnt/user/appdata/velodrome/pgdata:/var/lib/postgresql/data
|
|
healthcheck:
|
|
test: ["CMD-SHELL", "pg_isready -U postgres"]
|
|
interval: 5s
|
|
timeout: 5s
|
|
retries: 10
|
|
|
|
volumes:
|
|
# Populated from the `web` image's /app/build by a one-shot `docker run` in deploy.yml — never
|
|
# mounted read-write, never written to by any long-running service.
|
|
web_build:
|