Compare commits

..

5 Commits

Author SHA1 Message Date
ede639916c docs: clarify install-user check (postgres = no env needed) 2026-06-22 19:31:27 +00:00
5f50022bb4 docs: drop healthcheck comment; rephrase release note POSTGRES_USER warning + check command 2026-06-22 19:24:49 +00:00
a5a3b36755 feat(db): use POSTGRES_USER in pg_backup; document it in release note
- pg_backup.sh: use the db service's POSTGRES_USER (default postgres) for the
  dump/drop/recreate instead of detecting the superuser at runtime, since the
  recipe now sets that env var; one-line the constants comment
- release note: explain the in-place pg_upgrade + the POSTGRES_USER override
- bump PG_BACKUP_VERSION v4

Verified on cctest: backup + restore via the hooks round-trips with POSTGRES_USER.
2026-06-22 18:46:17 +00:00
a081d1dba0 Update pg_backup.sh 2026-06-22 18:37:15 +00:00
f783d9988b feat(db): switch to discourse/postgres image (auto-upgrade, no custom entrypoint file)
Replace the bitnami-era pgvector:pg17 db + hand-rolled pg_upgrade entrypoint
with discourse/postgres:pg18 (pgvector + discourse's auto-upgrade layer, as
suggested on coop-cloud/discourse#16). The image runs the in-place major-version
pg_upgrade itself on boot, so the recipe just configures it via env:

- the db password secret is read into $DB_PASSWORD by a small inline entrypoint
  (the image expects it in the env, no *_FILE support; the base image's
  POSTGRES_PASSWORD_FILE can't be used because run-postgres.sh pre-generates
  POSTGRES_PASSWORD). No separate entrypoint file/config any more.
- POSTGRES_USER (the install user pg_upgrade must match) defaults to the image's
  'postgres' -- correct for fresh installs and bitnami-origin clusters -- and is
  overridable from the app .env for a cluster bootstrapped with another superuser.
- POSTGRES_INITDB_ARGS=--no-data-checksums so the new pg18 cluster matches the
  pre-18 clusters (pg18 initdb enables checksums by default; pg_upgrade needs a
  match).

- mount postgresql_data at /var/lib/postgresql (versioned PGDATA .../18/docker)
- pg_backup.sh: detect the superuser at runtime; fix paths for the new layout
- document POSTGRES_USER override in .env.sample and README
- bump PG_BACKUP_VERSION v3; drop DB_ENTRYPOINT_VERSION + entrypoint.postgres.sh.tmpl

Verified on cctest: pg17->pg18 upgrade (install user 'postgres', checksums off)
preserves data and serves over HTTPS; fresh install also works.
2026-06-22 18:23:22 +00:00
5 changed files with 23 additions and 49 deletions

View File

@ -1,5 +1,4 @@
export DB_ENTRYPOINT_VERSION=v7 export PG_BACKUP_VERSION=v4
export PG_BACKUP_VERSION=v3
export APP_ENTRYPOINT_VERSION=v2 export APP_ENTRYPOINT_VERSION=v2
export APP_INSTALL_SSL_VERSION=v1 export APP_INSTALL_SSL_VERSION=v1
export APP_MIGRATE_UPLOADS_VERSION=v1 export APP_MIGRATE_UPLOADS_VERSION=v1

View File

@ -1,20 +0,0 @@
#!/bin/bash
# Co-op Cloud entrypoint wrapper for the discourse/postgres image.
#
# The image (https://github.com/discourse/discourse-postgres) handles everything
# itself, including the in-place major-version pg_upgrade on boot. The only thing
# it can't do for us is read the docker secret: it expects the DB password in the
# DB_PASSWORD / POSTGRES_PASSWORD env vars (no *_FILE support), so inject it from
# /run/secrets here, then hand off to the image's real entrypoint.
#
# The install user and data-checksum settings the upgrade needs are passed as
# plain env vars in compose.yml (POSTGRES_USER, POSTGRES_INITDB_ARGS).
set -e
if [ -f /run/secrets/db_password ]; then
DB_PASSWORD="$(cat /run/secrets/db_password)"
export DB_PASSWORD
export POSTGRES_PASSWORD="$DB_PASSWORD"
fi
exec run-postgres.sh postgres

View File

@ -65,8 +65,7 @@ services:
db: db:
# discourse/postgres = pgvector + discourse's postgres management layer, which # discourse/postgres = pgvector + discourse's postgres management layer, which
# auto-upgrades an older cluster in place on boot (pg_upgrade into the versioned # auto-upgrades an older cluster in place on boot (pg_upgrade into the versioned
# PGDATA /var/lib/postgresql/${MAJOR}/docker). The cc-db-entrypoint wrapper only # PGDATA /var/lib/postgresql/${MAJOR}/docker); everything is driven by the env below.
# injects the password secret; everything else is driven by the env below.
image: discourse/postgres:pg18 image: discourse/postgres:pg18
networks: networks:
- internal - internal
@ -77,13 +76,18 @@ services:
# an existing pg17 cluster at the volume root is found and upgraded into /18/docker # an existing pg17 cluster at the volume root is found and upgraded into /18/docker
- 'postgresql_data:/var/lib/postgresql' - 'postgresql_data:/var/lib/postgresql'
configs: configs:
- source: db_entrypoint
target: /usr/local/bin/cc-db-entrypoint.sh
mode: 0555
- source: pg_backup - source: pg_backup
target: /pg_backup.sh target: /pg_backup.sh
mode: 0555 mode: 0555
entrypoint: /usr/local/bin/cc-db-entrypoint.sh entrypoint:
- /bin/bash
- -c
- |
if [ -f /run/secrets/db_password ]; then
DB_PASSWORD="$$(cat /run/secrets/db_password)"
export DB_PASSWORD POSTGRES_PASSWORD="$$DB_PASSWORD"
fi
exec run-postgres.sh postgres
environment: environment:
# internal-only overlay network; keep all-trust so the app and the # internal-only overlay network; keep all-trust so the app and the
# backup/restore hooks connect without juggling the superuser password # backup/restore hooks connect without juggling the superuser password
@ -103,9 +107,6 @@ services:
interval: 30s interval: 30s
timeout: 10s timeout: 10s
retries: 5 retries: 5
# generous: on a major-version bump the image installs the old binaries and
# runs pg_upgrade on first boot before the server accepts connections —
# don't let the healthcheck kill an in-progress migration
start_period: 15m start_period: 15m
deploy: deploy:
labels: labels:
@ -153,9 +154,6 @@ configs:
app_migrate_uploads: app_migrate_uploads:
name: ${STACK_NAME}_app_migrate_uploads_${APP_MIGRATE_UPLOADS_VERSION} name: ${STACK_NAME}_app_migrate_uploads_${APP_MIGRATE_UPLOADS_VERSION}
file: migrate-uploads.sh file: migrate-uploads.sh
db_entrypoint:
name: ${STACK_NAME}_db_entrypoint_${DB_ENTRYPOINT_VERSION}
file: cc-db-entrypoint.sh
pg_backup: pg_backup:
name: ${STACK_NAME}_pg_backup_${PG_BACKUP_VERSION} name: ${STACK_NAME}_pg_backup_${PG_BACKUP_VERSION}
file: pg_backup.sh file: pg_backup.sh

View File

@ -4,25 +4,13 @@
set -e set -e
# discourse/postgres keeps the live cluster at a versioned PGDATA under the # dump goes at the volume root so backupbot's backup.sql label finds it
# /var/lib/postgresql mount. Write the dump at the volume root so backupbot's
# `postgresql_data.path: backup.sql` label captures it.
BACKUP_FILE='/var/lib/postgresql/backup.sql' BACKUP_FILE='/var/lib/postgresql/backup.sql'
DATADIR="${PGDATA:-/var/lib/postgresql/18/docker}" DATADIR="${PGDATA:-/var/lib/postgresql/18/docker}"
DB_NAME="${POSTGRES_DB:-discourse}" DB_NAME="${POSTGRES_DB:-discourse}"
# The bootstrap superuser (install user, oid 10) differs between deployments # bootstrap superuser for the dump/drop/recreate; same POSTGRES_USER the db service sets
# (`postgres` on bitnami-origin clusters, `discourse` on others). Detect it at SU="${POSTGRES_USER:-postgres}"
# runtime over the local trust socket rather than hard-coding a name.
detect_superuser() {
local u name
for u in discourse postgres; do
name="$(psql -U "$u" -d "$DB_NAME" -tAc 'select rolname from pg_roles where oid = 10' 2>/dev/null | tr -d '[:space:]')"
if [ -n "$name" ]; then echo "$name"; return 0; fi
done
echo postgres
}
SU="$(detect_superuser)"
function backup { function backup {
pg_dump -U "$SU" "$DB_NAME" | gzip > "$BACKUP_FILE" pg_dump -U "$SU" "$DB_NAME" | gzip > "$BACKUP_FILE"

View File

@ -8,3 +8,12 @@ Rename these in your app's .env (the values carry over):
DISCOURSE_SMTP_USER --> DISCOURSE_SMTP_USER_NAME DISCOURSE_SMTP_USER --> DISCOURSE_SMTP_USER_NAME
DISCOURSE_SMTP_AUTH --> DISCOURSE_SMTP_AUTHENTICATION DISCOURSE_SMTP_AUTH --> DISCOURSE_SMTP_AUTHENTICATION
DISCOURSE_SMTP_PROTOCOL --> DISCOURSE_SMTP_ENABLE_START_TLS (takes a boolean true/false, not the old tls/ssl value, so translate it rather than copying it straight across) DISCOURSE_SMTP_PROTOCOL --> DISCOURSE_SMTP_ENABLE_START_TLS (takes a boolean true/false, not the old tls/ssl value, so translate it rather than copying it straight across)
WARNING: if your deployment's database has an "install user" other than `postgres`
(some older deployments do), you must set the POSTGRES_USER env var in your .env
for this migration, otherwise the postgres upgrade aborts with an install-user
mismatch.
Check your old deployment's install user before upgrading (if this command returns postgres, then you do not need to set this env):
abra app run YOURAPPDOMAIN db -- psql -U discourse -tAc 'select rolname from pg_roles where oid = 10'