アップグレード

新しいバージョンへの上げ方、マイグレーションが失敗したときに何が起きるか、そしてロールバックがダウングレードではなくバックアップのリストアである理由。

始める前に

バックアップを取ってください。儀式としてではなく、実際のロールバック手段として。他に手段がない理由は下に書きます。

Compose

./backup.sh /var/backups/busabase
docker compose pull
docker compose up -d

migrate が先に走り、完了してからアプリが起動します。失敗すれば非ゼロで終了し、アプリは起動しません — condition: service_completed_successfully がそれを保証します。得られるのは「停止したデプロイとログ内の明確な理由」であって、「中途半端なスキーマの上で動いているデプロイ」ではありません。

docker compose logs migrate

出力には失敗した SQL 文とデータベースのエラーが出ますが、それがどのマイグレーションファイル由来かは出ません。ファイルを特定するには、その文でマイグレーションディレクトリを grep します:

docker compose run --rm --entrypoint sh migrate -c \
  "grep -rl 'this_table_does_not_exist' apps/busabase-cloud/src/db/migrations"

そのファイルをサポートバンドルと一緒に送ってください。スキーマを手で修正しないでください — 部分適用されたマイグレーションはファイルから直せますが、誰かがテーブルを直接編集した後ははるかに直しにくくなります。

オールインワン

docker pull busabase/busabase-premium-allinone:trial
docker rm -f busabase
docker run -d --name busabase \
  -p 3000:3000 \
  -v busabase-data:/data \
  --restart unless-stopped \
  busabase/busabase-premium-allinone:trial

これを新規インストールではなくアップグレードにしているのが -v busabase-data:/data です。同じボリューム名、同じデータ。省略すると、データが消えたように見える真っさらな新インスタンスができます。

ここでもマイグレーションは起動時に走り、失敗は致命的です: 理解できないスキーマに対してリクエストを捌くのではなく、コンテナが停止します。

ロールバック

下向きのマイグレーション経路はありません。カラムを追加したマイグレーションに、「その後書き込まれた行をどうするか」を知っている逆操作は存在しません。

したがってロールバックとは「前のイメージタグを動かし、アップグレード前に取ったバックアップをリストアする」ことです。手順はこれだけで、だからこそバックアップの手順は省略できません。

BUSABASE_IMAGE=busabase/busabase-premium:<前のタグ> docker compose up -d
# その後 /docs/self-hosted/backup-restore に従ってリストア

反映されたか確認する

curl -s http://localhost:3000/api/health

応答の version フィールドが、実際にリクエストを捌いているビルドを教えてくれます。古いイメージがキャッシュされていたホストでは特に、思い込まずに確認する価値があります。