長年にわたり、依存関係が原因でアップデート/アップグレードが失敗することがあります。例えば、DockerのバージョンやOSなどです。
私の考えとしては、Discourseが何らかの依存関係チェックを実行し、基本要件が満たされていることを確認するようにします。チェックが失敗した場合は、必要な詳細情報を提供し、アップデート/アップグレードプロセスを中止します。
これにより、失敗する可能性のあるプロセスのCore Discourseのアップデート/アップグレードを中止することで、フォーラムのダウンタイムを削減できます。
彼らはそれを実現するためにかなり努力しています。うまくいかない可能性のあることはかなりたくさんあります。ほとんどの場合、OS（おそらくDockerも）を最新の状態に保っていない場合は、あなたの責任です。
彼らはDockerのバージョンを確認しようとしており、私が使用しているスクリプトは、問題があると分かっている場合はDockerをアップグレードします（おそらく常にDockerをアップグレードするべきです）。
ベースイメージが少しでも変更された場合は、常にコマンドラインでのアップグレードを強制する方が良いかもしれません。私のダッシュボードはクリックでコマンドラインアップデートを行うので、私はほとんど使用しません。
deosアップデート docker_manager はdockerをアップデートしますか？
私は決して責任転嫁をしようとしているわけではありません。セルフホスト（self hosted）でより具体的に言うと、残念な点は、必ずしもサーバーOSを理解しているとは限らないことです。ほとんどの人はOSをインストールし、一般的に最新の状態に保ちます。しかし、LTS（Long Term Support）の場合、OSのアップグレードを知らなかったり、理解していなかったりすることがよくあります。特にローリングリリース（rolling releases）に慣れている場合はそうです。
例えば、私が手伝っているある会社では、しばらくアップデートしていなかった後、アップデートがあることに気づきました。そこで、Web UIからDockerをアップデートしました。これにより、Discourseをアップデートできるようになりました。
Ubuntu LTSが十分に新しくなかったため、Dockerのアップデートは最小要件を満たしていませんでした。Web UIはアップデートの試行を許可していました。当然、これは失敗し、サイトがダウンしました。
そこで、コマンドラインでリビルド（rebuild）を試みましたが、最小要件が満たされていないため、当然失敗しました。
WebでのアップデートでDockerのバージョンが最小バージョンではないことを識別できれば、サイトをダウンさせることなく、満たされていない依存関係を通知してアップデートプロセスを中止できたはずです。
私は彼らのために大まかに調べました。彼らはサーバー上で他のものも実行しているようです。私は彼らの技術担当者に、LTSをより新しいバージョンにアップグレードするように指示しました。OSをアップグレードして、実行している他のものを壊したくなかったからです。
Webおよびコマンドラインでのリビルドを試みる前に、コンテナ（container）を再起動する簡単な方法はありますか？
./launcher start app を試しましたが、失敗しました。
もう1つ。Discourseサイトがダウンしたため、rsyncを使って新しいサーバーを立ち上げることはできますか？彼らは推奨されているtests-passedの代わりにstableを実行しています。
'do-release-upgrade' を実行し、手動でDockerをアップグレードした場合、postgreqをアップグレードするのに効果的ですか？
Ubuntu LTSでサポートされているバージョン内であれば可能です。ただし、LTSでサポートされているバージョンのみです。この場合、彼らのLTSは寿命が尽きています。そのため、最小Dockerバージョンをサポートしていません。
Ubuntu LTSのバージョンは、アップデートのライフサイクルが4年間だったと思います。
私が一緒に仕事をしている人々はそうではありません。EOL（サポート終了）を過ぎていると伝えても、更新しません。
コンテナ内で実行されているものが、どのバージョンのDockerで実行されているかを知ることができるとは、私はほとんど確信していません。
もしかしたらできるのかもしれません。コンテナ内から実行されているバージョンを確認できるようです。
https://docs.docker.com/engine/api/v1.30/#operation/SystemVersion
だから、もっとうまくやれるかもしれません。もし本当に機能するなら、ダッシュボードに追加できるクールな機能になるでしょう。
通常は機能します。データベースが移行された場合は例外です。
OSが古い場合、新しいVMに移行する方が簡単で安全であることが多いです。理想的には、古いサーバーがまだ動作している間に行います。Discourseサイトをrsyncで別のVPSに移動するを参照してください。
バックアップがある場合は、データベースのコピーをスキップし、データベースのアップグレードをスキップして、新しいデータベースに復元するだけです。
だからこそ、私は更新について言ったのです。EOLの場合はOSのアップグレードが必要です。しかし、指示をあまりよく守らない人がたくさんいるということには同意します。
私が、私が無料で手伝っている会社で管理者になったとき 
私は、彼らがアプリの再構築を実行するために必要なスペースがなかったため、フォーラムがいつかクラッシュすると、1か月以上も言い続けていました。彼らは最小限のサイズのサーバー（7年前）を持っていました。私の記憶が正しければ、合計で25GBのスペースがありました。もちろん、彼らは聞きませんでした。そして、フォーラムを新しいサーバーに移行するために、ここで誰かに支払いをしました。合計ダウンタイムは約2週間、あるいはそれ以上でした。
それが機能するなら、間違いなくクールでしょう。あなたや私のように、ここでそれなりに生活している人々は、問題が発生した後やアドオンやその他のマイナーなサポートの問題を探しているだけの人々と比較して、自分たちをかなり最新の状態に保っています。
わかりました、アドバイスします。ただし、バックアップがどれだけ古いかはわかりません。したがって、彼らの場合はrsyncまたはOSアップグレードを検討する必要があると思われます。
私の個人サーバーは古くなっていたので、たくさんのことを読み、Web/コマンドラインで更新しないように注意しました。rsync手順を使用するのに快適になるまで。そして、あなたとコミュニティがデバッグを手伝ってくれた、いくつかの軽微な問題がまだありました。
