更新のためにWebインターフェースを使用しても、常に動作するとは限らない点に注意してください。Webページからの更新が常に成功するわけではありません。特定の更新（例えば、非常に新しいデータベースバージョンの更新など）では、コマンドラインから再構築を行う必要があります。これは、SSH経由でサーバーにアクセスし、コマンドラインを使用して再構築を行うことを意味します。
多くの管理者とは異なり、私は通常、更新にはWebインターフェースを使用していますが、必要に応じて手動で更新を実行できるようにシェルをオープンした状態にしています。
そこで私はDiscourseのボットの助けを借りて、一連のプロセスをすべて通しました。元トピック「スタンドアロンコンテナからWebコンテナとデータコンテナの分離へ移行」は10年前に書かれたものだったため、何かを壊したくなかったのですが、ボットのおかげで少し楽になりました。
いくつかの質問と、多くのメモを取った結果、もう少し物事が理解できたと思います。私のインストールは動作しているので、おそらくすべてが正しく設定されているのでしょう……？
ボットによると、実際にSSHで作業が必要なアップデートを行う場合、以下の順序で実行すべきだと言っていました。
# 初回は約20分かかります。以降は通常5〜15分です
# （正確な初回ブートストラップ時間ではありません — dockerは再ビルド時にレイヤーをキャッシュします）
sudo ./launcher bootstrap web_only
# ブートストラップが正常に完了したら、次を実行します:
sudo ./launcher destroy web_only && sudo ./launcher start web_only
# 時々、ディスク容量を確認します:
df -h
# 古い未使用イメージによりディスク容量が逼迫している場合は:
sudo ./launcher cleanup
```\n
これで問題ないはずです。
「年に一度」のアップデートはもう少し複雑ですが、その点についてもメモを取っています。今は使用しないので、これらのメモを整理する必要があるだけです。
上記のワークフローは正しいですか？
フィードバックを共有してくださった皆さん、ありがとうございます。失礼ですが、この点を考慮に入れ、利用可能な各更新オプションをいつ使用すべきかを判断するための単純なルールを教えていただけますか？
私は専門家ではありません。他の人々の方がこれらの事項に精通していますが…私の経験からすると、決してWebインターフェースでの成功を当てにしてはいけません。常にコマンドラインからの再構築に備えておくべきです。最近のPostgreSQL 15から18へのアップグレードはここに詳述されていますが、これは決定打でした。Webインターフェースのアップグレードでは乗り切れないと分かります。
それほど難しいことではありません。Web UIのアップグレードは利便性のためにあると捉え、うまくいけば素晴らしいですが、うまくいかない場合にも備えておいてください。少なくとも、うまくいかない場合、何が起きたのか、そして修正するために何をすべきかについて、有益な説明が表示されます。ここでは、多くのプロのDiscourse管理者が、試すこと自体を無駄だと言うでしょう。私のフォーラムは小規模でトラフィックも少ないので、賭けをしても許容できますが、皆さんにはその余裕がないかもしれません。
最近、ここではあまり投稿していませんが、デュアルコンテナのセットアップで助けが必要だったったり、質問があれば、気軽にDMしてください。私はCloudflare CDNの背後で、S3互換のR2オブジェクトストレージを使った、2つの独立したデュアルコンテナフォーラムを運用しています。シングルコンテナよりも少し複雑ですが、多くの人が思うほど難しいわけではありません。メンテナンスも非常に簡単で、bashスクリプトを使えば、更新作業もさらに楽になります。