Compare commits
2 Commits
9b33fd8761
...
upgrade-c1
| Author | SHA1 | Date | |
|---|---|---|---|
| 0d7519e9ef | |||
| c10c04c520 |
@ -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
|
||||
|
||||
13
README.md
13
README.md
@ -47,10 +47,15 @@ abra app run YOURAPPDOMAIN app discourse admin create
|
||||
|
||||
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. The recipe
|
||||
adds a small entrypoint wrapper that injects the password secret and detects the
|
||||
old cluster's real install superuser (oid 10), so the upgrade works whether that
|
||||
user is `postgres` or `discourse`. No manual dump/restore needed.
|
||||
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
|
||||
|
||||
|
||||
3
abra.sh
3
abra.sh
@ -1,5 +1,4 @@
|
||||
export DB_ENTRYPOINT_VERSION=v6
|
||||
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
|
||||
|
||||
@ -1,87 +0,0 @@
|
||||
#!/bin/bash
|
||||
# Co-op Cloud entrypoint wrapper for the discourse/postgres image.
|
||||
#
|
||||
# discourse/postgres (https://github.com/discourse/discourse-postgres) is pgvector
|
||||
# plus a management layer that auto-upgrades an older cluster on boot. It does the
|
||||
# heavy lifting (apt-installs the old binaries, runs pg_upgrade, writes the new
|
||||
# cluster to the versioned PGDATA). This wrapper only fills the two gaps it leaves:
|
||||
#
|
||||
# 1. Secrets: the image reads DB_PASSWORD / POSTGRES_PASSWORD from the process
|
||||
# env (no *_FILE support), so inject them from the docker secret.
|
||||
# 2. Install user: the image runs `pg_upgrade --username="$POSTGRES_USER"` and
|
||||
# initdb's the new cluster with $POSTGRES_USER, but never detects the OLD
|
||||
# cluster's real bootstrap superuser (the install user, oid 10). pg_upgrade
|
||||
# aborts unless the new cluster's install-user name matches the old one. Real
|
||||
# deployments differ: some were bootstrapped with `postgres` as the install
|
||||
# user (+ a separate `discourse` app role), others with `discourse` itself.
|
||||
# So detect oid 10 from the old cluster and export POSTGRES_USER to match
|
||||
# before handing off to the image's run-postgres.sh.
|
||||
set -e
|
||||
|
||||
# --- 1. secret injection -----------------------------------------------------
|
||||
if [ -f /run/secrets/db_password ]; then
|
||||
pw="$(cat /run/secrets/db_password)"
|
||||
export DB_PASSWORD="$pw"
|
||||
export POSTGRES_PASSWORD="$pw"
|
||||
fi
|
||||
|
||||
# --- 2. install-user detection (only matters on the upgrade path) ------------
|
||||
NEW_MAJOR="$(postgres --version | sed -rn 's/^[^0-9]*([0-9]+).*/\1/p')"
|
||||
|
||||
# Newest existing cluster under the data mount (same search the image uses).
|
||||
PGVER_FILE="$(find /var/lib/postgresql -maxdepth 3 -type f -name PG_VERSION 2>/dev/null \
|
||||
| xargs -I{} sh -c 'printf "%s " "{}"; cat "{}"' \
|
||||
| sort -nk2,2 | tail -n1 | awk '{print $1}')"
|
||||
|
||||
if [ -n "$PGVER_FILE" ]; then
|
||||
OLD_DIR="$(dirname "$PGVER_FILE")"
|
||||
OLD_MAJOR="$(cat "$PGVER_FILE")"
|
||||
if [ "$OLD_MAJOR" != "$NEW_MAJOR" ]; then
|
||||
echo "cc-db-entrypoint: existing pg${OLD_MAJOR} cluster at ${OLD_DIR}, image is pg${NEW_MAJOR} -> detecting install user"
|
||||
OLD_BIN="/usr/lib/postgresql/${OLD_MAJOR}/bin"
|
||||
if [ ! -x "$OLD_BIN/pg_ctl" ]; then
|
||||
echo "cc-db-entrypoint: installing postgresql-${OLD_MAJOR} to read the old cluster"
|
||||
apt-get update
|
||||
apt-get install -y --no-install-recommends "postgresql-${OLD_MAJOR}" >/dev/null
|
||||
fi
|
||||
chown -R postgres "$OLD_DIR" 2>/dev/null || true
|
||||
|
||||
# Briefly start the old cluster on a local socket only, ask it for oid 10.
|
||||
gosu postgres "$OLD_BIN/pg_ctl" -D "$OLD_DIR" -w \
|
||||
-o "-c listen_addresses= -c unix_socket_directories=/tmp" start >/dev/null 2>&1 || true
|
||||
detected=""
|
||||
for login_role in discourse postgres; do
|
||||
detected="$(gosu postgres psql -h /tmp -U "$login_role" -d postgres -tAc \
|
||||
'select rolname from pg_roles where oid = 10' 2>/dev/null | tr -d '[:space:]')"
|
||||
[ -n "$detected" ] && break
|
||||
done
|
||||
gosu postgres "$OLD_BIN/pg_ctl" -D "$OLD_DIR" -w stop >/dev/null 2>&1 || true
|
||||
|
||||
if [ -n "$detected" ]; then
|
||||
echo "cc-db-entrypoint: old cluster install user is '$detected' -> POSTGRES_USER=$detected"
|
||||
export POSTGRES_USER="$detected"
|
||||
else
|
||||
echo "cc-db-entrypoint: WARNING could not detect old install user; leaving POSTGRES_USER=${POSTGRES_USER:-<image default>}"
|
||||
fi
|
||||
|
||||
# pg_upgrade refuses to run if the old and new clusters disagree on data
|
||||
# checksums. PostgreSQL 18's initdb enables checksums by default, but the
|
||||
# older clusters in this recipe's lineage (pg13-17) were created without
|
||||
# them, so initdb the new cluster to match. Default to OFF (the lineage
|
||||
# reality) and only enable when the old cluster positively reports them on.
|
||||
csum=""
|
||||
if [ -x "$OLD_BIN/pg_controldata" ]; then
|
||||
csum="$("$OLD_BIN/pg_controldata" "$OLD_DIR" 2>/dev/null \
|
||||
| awk -F: '/checksum version/{gsub(/[^0-9]/,"",$2); print $2}')"
|
||||
fi
|
||||
if [ "$csum" = "1" ]; then
|
||||
echo "cc-db-entrypoint: old cluster data checksums ON -> initdb new cluster --data-checksums"
|
||||
export POSTGRES_INITDB_ARGS="${POSTGRES_INITDB_ARGS:+$POSTGRES_INITDB_ARGS }--data-checksums"
|
||||
else
|
||||
echo "cc-db-entrypoint: old cluster data checksums OFF (version='${csum:-unknown}') -> initdb new cluster --no-data-checksums"
|
||||
export POSTGRES_INITDB_ARGS="${POSTGRES_INITDB_ARGS:+$POSTGRES_INITDB_ARGS }--no-data-checksums"
|
||||
fi
|
||||
fi
|
||||
fi
|
||||
|
||||
exec run-postgres.sh postgres
|
||||
34
compose.yml
34
compose.yml
@ -3,7 +3,7 @@ version: "3.8"
|
||||
|
||||
services:
|
||||
app:
|
||||
image: discourse/discourse:3.5.3
|
||||
image: discourse/discourse:2026.1.5
|
||||
networks:
|
||||
- proxy
|
||||
- internal
|
||||
@ -65,8 +65,7 @@ services:
|
||||
db:
|
||||
# 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). The cc-db-entrypoint wrapper
|
||||
# injects the password secret and detects the old cluster's install user.
|
||||
# PGDATA /var/lib/postgresql/${MAJOR}/docker); everything is driven by the env below.
|
||||
image: discourse/postgres:pg18
|
||||
networks:
|
||||
- internal
|
||||
@ -77,27 +76,37 @@ services:
|
||||
# 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
|
||||
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_DB=discourse
|
||||
- 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: a postgres major-version upgrade (apt install old binaries +
|
||||
# pg_upgrade) runs in the entrypoint before the server accepts connections —
|
||||
# don't let the healthcheck kill an in-progress migration
|
||||
start_period: 15m
|
||||
deploy:
|
||||
labels:
|
||||
@ -107,7 +116,7 @@ services:
|
||||
backupbot.restore.post-hook: "/pg_backup.sh restore"
|
||||
|
||||
redis:
|
||||
image: redis:7.4-alpine
|
||||
image: redis:8.8-alpine
|
||||
networks:
|
||||
- internal
|
||||
volumes:
|
||||
@ -145,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
|
||||
|
||||
18
pg_backup.sh
18
pg_backup.sh
@ -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"
|
||||
|
||||
@ -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
31
release/next
Normal 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'
|
||||
Reference in New Issue
Block a user