Give the staging database its own name
The staging database now runs as qrmaster_test instead of reusing the production name. Container and volume already kept the two apart, but a hand-typed psql session against two databases both called `qrmaster` looks identical on either side - the distinct name is what makes the wrong window obvious before a DELETE lands in it. The base compose file hardcodes `pg_isready -d qrmaster` in the db healthcheck, so the overlay has to override the probe as well. Without it the container stays unhealthy and web never starts, because it waits on service_healthy. Verified against `docker compose config`: staging resolves to qrmaster_test in POSTGRES_DB, DATABASE_URL and the healthcheck, while production still resolves to qrmaster. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -12,6 +12,12 @@ services:
|
||||
container_name: qrmaster-test-db
|
||||
# Production already publishes 5435 on the host.
|
||||
ports: !reset []
|
||||
# The base file hardcodes the database name in the probe. Staging uses its own name so a
|
||||
# hand-typed psql session makes it obvious which instance you are on - without this
|
||||
# override the probe would check a database that does not exist, the container would stay
|
||||
# unhealthy and web (depends_on: service_healthy) would never start.
|
||||
healthcheck:
|
||||
test: ["CMD-SHELL", "pg_isready -U postgres -d qrmaster_test"]
|
||||
# Only on the internal network. `db` and `redis` are network aliases assigned per
|
||||
# compose project, so leaving them on the shared external network would make `db`
|
||||
# resolve to two containers and this stack could reach the production database.
|
||||
|
||||
Reference in New Issue
Block a user