Compare commits

..

3 Commits

Author SHA1 Message Date
9d5c8ae3ca Merge pull request 'switch app to official discourse/discourse image (with idempotent migration)' (#16) from discourse-official into main
Reviewed-on: https://git.coopcloud.tech/coop-cloud/discourse/pulls/16
2026-07-07 22:17:09 +00:00
1096c38e34 Update release/next 2026-07-07 22:10:56 +00:00
1f77af93bd feat(db): switch to discourse/postgres image (auto-upgrade)
Some checks failed
cc-ci/testme cc-ci: failure
Move the db off the bitnami-era pgvector:pg17 + hand-rolled pg_upgrade entrypoint
to discourse/postgres:pg18 (pgvector + discourse's auto-upgrade layer). The image
runs the in-place major-version pg_upgrade itself on boot; the recipe configures it
via env:

- a small inline entrypoint injects the db password secret into $DB_PASSWORD (the
  image expects it in the env, no *_FILE support)
- POSTGRES_USER (the install user pg_upgrade must match) defaults to 'postgres' --
  correct for fresh installs and bitnami-origin clusters -- overridable from .env
- POSTGRES_INITDB_ARGS=--no-data-checksums so the new pg18 cluster matches 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 uses POSTGRES_USER for the dump/drop/recreate; fix paths
- document the POSTGRES_USER override in .env.sample, README and the release note
- drop entrypoint.postgres.sh.tmpl

Tested on cctest: pg17->pg18 upgrade preserves data and serves over HTTPS; fresh
install works; backup+restore round-trips.
2026-06-22 19:57:54 +00:00
5 changed files with 35 additions and 29 deletions

View File

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

View File

@ -107,9 +107,6 @@ services:
interval: 30s
timeout: 10s
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
deploy:
labels:

View File

@ -4,25 +4,13 @@
set -e
# discourse/postgres keeps the live cluster at a versioned PGDATA under the
# /var/lib/postgresql mount. Write the dump at the volume root so backupbot's
# `postgresql_data.path: backup.sql` label captures it.
# 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}"
# The bootstrap superuser (install user, oid 10) differs between deployments
# (`postgres` on bitnami-origin clusters, `discourse` on others). Detect it at
# 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)"
# bootstrap superuser for the dump/drop/recreate; same POSTGRES_USER the db service sets
SU="${POSTGRES_USER:-postgres}"
function backup {
pg_dump -U "$SU" "$DB_NAME" | gzip > "$BACKUP_FILE"

View File

@ -1,10 +0,0 @@
This release switches from the bitnami image to the official discourse/discourse
image. Some env vars need to be renamed for this migration; everything else
should happen automatically.
Rename these in your app's .env (the values carry over):
DISCOURSE_SMTP_HOST --> DISCOURSE_SMTP_ADDRESS
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)

31
release/next Normal file
View File

@ -0,0 +1,31 @@
This release switches from the bitnami image to the official discourse/discourse
image. Some env vars need to be renamed for this migration; everything else
should happen automatically.
** WARNING A: renaming env vars
Rename these in your app's .env (the values carry over):
DISCOURSE_SMTP_HOST --> DISCOURSE_SMTP_ADDRESS
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 B: undeploy before deploy
it is necessary to `abra app undeploy` your old discourse app before deploying this version. otherwise the database will get killed and be in a bad state before the migration.
this was a non-fatal error in testing, but still a huge pain.
`abra app undeploy YOURDOMAIN` # cleaning stops your discourse
`abra app deploy YOURDOMAIN` # with the new version
** WARNING C: install user
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'