thermograph/deploy/db/Dockerfile.db

26 lines
1.4 KiB
Text
Raw Normal View History

Containerize the app and move the databases to PostgreSQL 18 (#220) Run Thermograph as a docker-compose stack (app + Postgres 18) and standardize the data layer on Postgres, while keeping the test suite on SQLite. - accounts/db.py: DSN-driven engines. On Postgres, a per-worker read-write + read-only asyncpg pair (the RO engine pins read-only transactions, used by the pure-GET endpoints) plus a sync psycopg engine for the notifier thread; the SQLite path is preserved for tests/local (selected when THERMOGRAPH_DATABASE_URL is unset). models.py: boolean server_default -> sa.false(). - store.py / metrics.py: dialect-flexible — Postgres UNLOGGED tables via psycopg when configured, else the existing raw-sqlite3 paths byte-for-byte; sync interfaces and every fail-soft contract preserved. - Alembic (backend/alembic/) manages the accounts schema; the container entrypoint runs `alembic upgrade head` before uvicorn (4 workers). migrate_accounts_to_pg.py copies the accounts data SQLite->PG through the ORM (UUID/bool/JSON coerced), skips access_token, and resets identity sequences. - Dockerfile + docker-compose.yml: app image (uvicorn, 4 workers, loopback 8137) and a Postgres 18 db (2 CPUs) running pg_duckdb (deploy/db/) so the parquet climate cache is queryable in-DB via read_parquet('/parquet/cache/*.parquet'). - deploy.sh/thermograph.service rewired to manage the compose stack; env example, Makefile targets (up/down/db-up), and deploy/POSTGRES-MIGRATION.md cutover runbook. Tests stay on SQLite (dialect fallback) — 323 pass. The full Postgres stack was verified via docker compose: alembic migrations, register/login, the RO endpoint, store/metrics round-trips, and the accounts data migration.
2026-07-20 06:28:23 +00:00
# Thermograph database image: PostgreSQL 18 with pg_duckdb.
#
# pg_duckdb embeds DuckDB inside Postgres, which lets the DB container read the
# app's Parquet climate cache directly for ad-hoc analytics:
#
# SELECT * FROM read_parquet('/parquet/1026_-2857.parquet');
#
# Why FROM the official pg_duckdb image instead of `FROM postgres:18` + compile:
# pg_duckdb links a full DuckDB build, so compiling it from source in this
# Dockerfile would mean pulling the DuckDB toolchain and a long, fragile build.
# The maintainers (duckdb/pg_duckdb, MotherDuck) publish an official PG18 image
# that is genuine PostgreSQL 18.1 on Debian 12 bookworm -- the exact same base
# as the official `postgres:18` image, using the standard postgres
# docker-entrypoint.sh. So POSTGRES_USER / POSTGRES_PASSWORD / POSTGRES_DB /
# PGDATA / /docker-entrypoint-initdb.d / pg_isready all behave identically to
# `postgres:18`; this is a drop-in replacement for the compose `db` service.
#
# Pinned to a specific patch tag (not 18-main) for reproducible builds.
FROM pgduckdb/pgduckdb:18-v1.1.1
# Bake the parquet init script so the image enables the extension on first init
# even without the compose bind mount. It is CREATE EXTENSION IF NOT EXISTS, so
# it is idempotent with the base image's own 0001-install-pg_duckdb.sql.
# Build context is the repo root (see deploy/db/README.md for the compose snippet).
COPY deploy/db/init/ /docker-entrypoint-initdb.d/