v3.4.0からv2026.7.2へアップグレードする前に知っておくべきこと

サポート インストール
1

Ubuntu上でDockerベースのDiscourseを運用しており、オープンソースプロジェクトの一部として引き継いだ環境の責任者です。これまで数年間、git pull && ./launcher rebuild app を実行し、その後 /admin/update の管理画面からアップグレードを行っていました。しかし、2024年1月にdocker_manager起因の破壊的変更によるアップグレードで痛い目に遭ったため（該当コミットのコメントはこちら、ロールバックされたコミットはこちらを参照）、それ以来、安易にアップグレードしなくなりました。

現在、2.5年が経過しており、アップグレードのペースを取り戻す必要がありますが、前回の破損したアップグレードのことがまだ少し怖いです。v3.4.0からv2026.7.2へのアップグレードを試みる前に、何を知っておくべきかについて助言をいただければと思います。当サイトでは追加プラグインを使用しておらず、特別な設定として認識しているのは、メインのコミュニティサイトとのSSOのためにDiscourse Connect URLを使用している点のみです。

単純に以下を実行すればよいのでしょうか？

cd /var/discourse
git pull
./launcher rebuild app

その後、管理画面から更新するだけです。v3.4.0からv2026.7.2への移行において、注意すべき中間ステップはありますか？

よろしくお願いいたします。

Cory

2

または…（緊張している場合は）…バックアップを取っておき（いずれにせよ）、新しいサーバーをセットアップしてバックアップを復元し、完了後にドメインを新しいサーバーに向けます。

直面する大きな問題は、Postgres の主要なアップグレード（18 への移行）があることです。新しいサーバーを構築すれば、そのアップグレードプロセスを扱う必要はありません。

また、依存しているプラグインやテーマコンポーネントがメンテナンスされていないという小さなリスクもあります。特に、あまり活動的でないサードパーティによって作成されたものである場合はそうです。

緊張するのは、経験豊富な Discourse SA（システム管理者）が、コミットする前にブートストラップ更新を行うことができるよう、2 コンテナ構成を使用している理由です（ただし、大きな Postgres アップグレード時にはあまり役に立ちませんが、そのようなアップグレードは稀にしか発生しません）。

3

ご返信ありがとうございます。このアイデアは気に入りましたので、この方法を試してみます！

4

今日、マイグレーションを試みましたが、discourse_dockerのメインブランチにある破壊的変更（breaking change）に再び即座に遭遇しました：

このコミットはビルドを失敗させ、インストール/セットアップを壊しますが、それでもメインブランチにマージされました。まさに私が心配していたことが起きたのです。

./launcher bootstrap app を実行すると、以下が出力されます：

rake aborted!
Don't know how to build task 'assets:precompile:pretty_text' (See the list of available tasks with `rake --tasks`)
Did you mean?  assets:precompile

公式のインストール手順の一部として提供されているメインブランチに、このような破壊的変更がマージされるのはなぜですか？ ビルドの失敗は無視されているのでしょうか？ 私が確認しているのと同じエラーが、失敗ログにそのまま記載されています：

Screenshot 2026-09-06 at 8.26.24 PM
Screenshot 2026-09-06 at 8.26.24 PM2096×926 217 KB

以前のコミットにチェックアウトすることで、マイグレーションのステップを続行することができましたが、テストされていないコミットがメインにマージされることでアップグレードが壊れるのはこれで2回目です。

5

Hey @corywright、ご迷惑をおかけして申し訳ありません。現在のESRにはそのジョブが含まれておらず、パッチはこちらで進行中です。

すぐに修正いたします。また、将来のリグレッションを防ぐために、ESRターゲットをスモークテストのターゲットに追加するよう手配します。

6

そのオプションを、インプレースアップグレードではなく提案してくださったこと、改めて感謝いたします。結果的にこちらのほうがはるかにうまくいき、新しいOSのクリーンなコピーから始めることができました。