Compare commits

..
Author SHA1 Message Date
notplantsandnotplants ede639916c docs: clarify install-user check (postgres = no env needed) 2026-06-22 19:31:27 +00:00
notplantsandnotplants 5f50022bb4 docs: drop healthcheck comment; rephrase release note POSTGRES_USER warning + check command 2026-06-22 19:24:49 +00:00
notplantsandnotplants 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
notplants a081d1dba0 Update pg_backup.sh 2026-06-22 18:37:15 +00:00
notplantsandnotplants 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
7 changed files with 76 additions and 69 deletions
+6
View File
@@ -21,3 +21,9 @@ DISCOURSE_DEVELOPER_EMAILS=admin@example.com
#SECRET_SMTP_PASSWORD_VERSION=v1
SECRET_DB_PASSWORD_VERSION=v1
# Postgres bootstrap superuser (the cluster's "install user"). Defaults to
# `postgres`, which matches fresh installs and bitnami-origin clusters. Only set
# this if you are upgrading a cluster that was bootstrapped with a different
# superuser (e.g. `discourse`) — a postgres major upgrade fails unless it matches.
#POSTGRES_USER=postgres
+16
View File
@@ -43,6 +43,22 @@ override) so it works behind the reverse proxy.
abra app run YOURAPPDOMAIN app discourse admin create
```
## Postgres major version upgrades
Handled automatically by the [`discourse/postgres`] image (pgvector + an
auto-upgrade layer). On deploy it finds an older cluster, installs the old
binaries and runs `pg_upgrade` into the new versioned data directory. No manual
dump/restore needed.
`pg_upgrade` must run as the old cluster's bootstrap superuser (its "install
user"). The recipe uses `POSTGRES_USER`, which defaults to `postgres` — the right
value for fresh installs and for clusters that came from the old bitnami recipe.
If your cluster was bootstrapped with a different superuser (e.g. `discourse`),
set `POSTGRES_USER` in the app `.env` before upgrading, otherwise `pg_upgrade`
will refuse with an install-user mismatch.
[`discourse/postgres`]: https://github.com/discourse/discourse-postgres
## Migrating from the previous (bitnami) recipe
The official image stores uploads under `/shared` rather than bitnami's
+1 -2
View File
@@ -1,5 +1,4 @@
export DB_ENTRYPOINT_VERSION=v4
export PG_BACKUP_VERSION=v2
export PG_BACKUP_VERSION=v4
export APP_ENTRYPOINT_VERSION=v2
export APP_INSTALL_SSL_VERSION=v1
export APP_MIGRATE_UPLOADS_VERSION=v1
-35
View File
@@ -1,35 +0,0 @@
#!/bin/bash
# Co-op Cloud wrapper around pgautoupgrade's entrypoint.
#
# pgautoupgrade runs pg_upgrade assuming the old cluster's bootstrap superuser
# (the "install user", oid 10) equals $POSTGRES_USER. That is not always true
# (e.g. a cluster bootstrapped with the default "postgres" superuser and a
# separate "discourse" app role), and a mismatch makes pg_upgrade's consistency
# check fail (pgautoupgrade issue #115). When a major-version upgrade is pending,
# detect the old cluster's real install user and run the upgrade as that user;
# pgautoupgrade handles everything else (old binaries, initdb, pg_upgrade).
set -e
if [ -s "$PGDATA/PG_VERSION" ]; then
OLD_VERSION="$(cat "$PGDATA/PG_VERSION")"
TARGET_VERSION="${PGTARGET%%.*}"
if [ -n "$OLD_VERSION" ] && [ -n "$TARGET_VERSION" ] && [ "$OLD_VERSION" != "$TARGET_VERSION" ]; then
# query the old cluster in single-user mode (no socket/auth needed) with
# pgautoupgrade's bundled old-version binaries
OLD_POSTGRES="/usr/local-pg${OLD_VERSION}/bin/postgres"
if [ -x "$OLD_POSTGRES" ]; then
INSTALL_USER="$(echo 'select rolname from pg_authid where oid = 10;' \
| gosu postgres "$OLD_POSTGRES" --single -D "$PGDATA" template1 2>/dev/null \
| sed -n 's/.*rolname = "\([^"]*\)".*/\1/p' | head -n1)"
if [ -n "$INSTALL_USER" ]; then
echo "cc-db-entrypoint: old cluster (pg$OLD_VERSION) install user is '$INSTALL_USER'; running the pg$TARGET_VERSION upgrade as that user"
export POSTGRES_USER="$INSTALL_USER"
else
echo "cc-db-entrypoint: WARNING could not detect old install user; letting pgautoupgrade use POSTGRES_USER=$POSTGRES_USER"
fi
fi
fi
fi
exec /usr/local/bin/docker-entrypoint.sh "$@"
+28 -19
View File
@@ -63,39 +63,51 @@ services:
start_period: 25m
db:
image: pgautoupgrade/pgautoupgrade:17-trixie
# discourse/postgres = pgvector + discourse's postgres management layer, which
# auto-upgrades an older cluster in place on boot (pg_upgrade into the versioned
# PGDATA /var/lib/postgresql/${MAJOR}/docker); everything is driven by the env below.
image: discourse/postgres:pg18
networks:
- internal
secrets:
- db_password
volumes:
- 'postgresql_data:/var/lib/postgresql/data'
# the image expects the whole cluster tree mounted here (not the data subdir);
# an existing pg17 cluster at the volume root is found and upgraded into /18/docker
- 'postgresql_data:/var/lib/postgresql'
configs:
- source: db_entrypoint
target: /usr/local/bin/cc-db-entrypoint.sh
mode: 0555
- source: pg_backup
target: /pg_backup.sh
mode: 0555
entrypoint: /usr/local/bin/cc-db-entrypoint.sh
# overriding entrypoint drops the image's default CMD, so restore it; the
# wrapper passes "$@" through and pgautoupgrade keys its logic on $1=postgres
command: postgres
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:
# internal-only overlay network; keep all-trust so the app and the
# backup/restore hooks connect without juggling the superuser password
- POSTGRES_HOST_AUTH_METHOD=trust
- POSTGRES_USER=discourse
- POSTGRES_DB=discourse
- POSTGRES_PASSWORD_FILE=/run/secrets/db_password
- PGTARGET=17
- DB_USER=discourse
# pg_upgrade runs as this role and initdb's the new cluster with it; it must
# match the OLD cluster's bootstrap superuser (oid 10). The image default
# `postgres` matches fresh installs and bitnami-origin clusters. Override in
# the app .env (POSTGRES_USER=...) only for a cluster bootstrapped differently.
- POSTGRES_USER=${POSTGRES_USER:-postgres}
# pg18's initdb enables data checksums by default, but pg13-17 clusters here
# have them off and pg_upgrade requires a match -> initialise without them.
- POSTGRES_INITDB_ARGS=--no-data-checksums
healthcheck:
test: "pg_isready -U discourse -d discourse"
interval: 30s
timeout: 10s
retries: 5
# generous: pgautoupgrade may run an in-place pg_upgrade on deploy before
# the server accepts connections — don't let the healthcheck kill an
# in-progress migration
start_period: 10m
start_period: 15m
deploy:
labels:
backupbot.backup: "true"
@@ -142,9 +154,6 @@ configs:
app_migrate_uploads:
name: ${STACK_NAME}_app_migrate_uploads_${APP_MIGRATE_UPLOADS_VERSION}
file: migrate-uploads.sh
db_entrypoint:
name: ${STACK_NAME}_db_entrypoint_${DB_ENTRYPOINT_VERSION}
file: cc-db-entrypoint.sh
pg_backup:
name: ${STACK_NAME}_pg_backup_${PG_BACKUP_VERSION}
file: pg_backup.sh
+16 -13
View File
@@ -1,44 +1,47 @@
#!/bin/bash
# Postgres backup/restore hook for the discourse `db` service.
# Postgres backup/restore hook for the discourse `db` service (discourse/postgres image).
set -e
BACKUP_FILE='/var/lib/postgresql/data/backup.sql'
export PGPASSWORD=$(cat "${POSTGRES_PASSWORD_FILE:-/run/secrets/db_password}")
DB_USER="${POSTGRES_USER:-discourse}"
# dump goes at the volume root so backupbot's backup.sql label finds it
BACKUP_FILE='/var/lib/postgresql/backup.sql'
DATADIR="${PGDATA:-/var/lib/postgresql/18/docker}"
DB_NAME="${POSTGRES_DB:-discourse}"
# bootstrap superuser for the dump/drop/recreate; same POSTGRES_USER the db service sets
SU="${POSTGRES_USER:-postgres}"
function backup {
pg_dump -U "$DB_USER" "$DB_NAME" | gzip > "$BACKUP_FILE"
pg_dump -U "$SU" "$DB_NAME" | gzip > "$BACKUP_FILE"
}
function restore {
cd /var/lib/postgresql/data/
cd "$DATADIR"
# Block all non-local connections so the running discourse app + sidekiq cannot reconnect and
# interfere with the drop/recreate/reimport. Restored on exit.
restore_hba() {
cat pg_hba.conf.bak > pg_hba.conf
rm -f pg_hba.conf.bak
su postgres -c 'pg_ctl reload'
su postgres -c "pg_ctl -D '$DATADIR' reload"
}
cp pg_hba.conf pg_hba.conf.bak
echo 'local all all trust' > pg_hba.conf
su postgres -c 'pg_ctl reload'
su postgres -c "pg_ctl -D '$DATADIR' reload"
trap restore_hba EXIT INT TERM
# terminate any lingering local sessions before recreate
# see https://stackoverflow.com/questions/5108876/kill-a-postgresql-session-connection
psql -U "$DB_USER" -d postgres -c \
psql -U "$SU" -d postgres -c \
"SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname='${DB_NAME}' AND pid<>pg_backend_pid();"
# drop database and then recreate it
psql -U "$DB_USER" -d postgres -c "DROP DATABASE ${DB_NAME} WITH (FORCE);"
createdb -U "$DB_USER" "$DB_NAME"
psql -U "$SU" -d postgres -c "DROP DATABASE ${DB_NAME} WITH (FORCE);"
createdb -U "$SU" "$DB_NAME"
# reimport data
gunzip -c "$BACKUP_FILE" | psql -U "$DB_USER" -d "$DB_NAME" -1 -v ON_ERROR_STOP=1 -f -
# reimport data
gunzip -c "$BACKUP_FILE" | psql -U "$SU" -d "$DB_NAME" -1 -v ON_ERROR_STOP=1 -f -
}
$@
+9
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_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)
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'