ブラウザ経由でDiscourseをアップデートするのと、ターミナルで./launcher rebuild appを使ってアップデートするのとでは、同じプロセスですか？
もしそうなら、プラグインを個別にアップデートできるという点以外に、どちらかの方法に利点はありますか？
私はこの分野の専門家ではないので、もしおかしなことを言っていたら申し訳ありません。
そう質問するのは、ブラウザ経由でのアップデートを試みて2回ともうまくいかなかったからです。1回目はアップデートプロセスが開始されたものの途中で固まってしまい、昨夜（2回目）はアップデートボタンを押して寝たのですが、今朝になっても始まっていませんでした。キャンセルして再起動する必要がありました。
ダウンタイムを最小限に抑える（数秒）ために、可能な限りUIを使用してください。
時折、一部のアップデート（例：Postgresのバージョンアップ）ではコマンドラインでのアップデートが必要になります。これは、そのような場合に必要ですが、標準的なインストールではダウンタイムが発生します。通常は約20分です。オフピーク時間帯を選んでください。
そのような場合は、UIで明らかになるはずです。
プラグインを追加または削除したい場合は、コンソールでの再構築が必要です。
現在アップデート中ですが、フォーラムはまだ動作していますが、時々少し遅くなることに気づきました。これは、フォーラムを完全に機能させないように見えるターミナルを使用する場合と比較して良いことです。明確にしていただきありがとうございます。
私のような専門家でなくてもわかりますか？つまり、ターミナルを使用すべきであることを示すようなメッセージが表示されるのでしょうか？
技術的に言えば、すべてをブラウザで行えるように、いつかこれが変わると思いますか？このプロセスの技術的な詳細がわからないので、質問しています。
またクラッシュしました…
Spinning up 1 Unicorn worker(s) that were stopped initially
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Command was killed with SIGKILL (Forced termination): ember build -prod Docker Manager: FAILED TO UPGRADE
これはよくあることですか？原因と解決策は何でしょうか？
標準インストールでは、常にこのようになると思います。
20分を軽減するために「オフラインです。後で戻ってください」画面を表示するように設定するリソースはここにありますが、これは標準インストールではなく、シンプルでサポートしやすい状態を維持することをお勧めします。
数日前にそれを見ましたが、私には確かに非常に複雑でした。
今アップデートしようとしたときに表示されるエラーを投稿しました。再びクラッシュしました。前の返信にあります。
クラッシュした後、更新を再開するボタンをクリックしましたが、昨夜と同じ状態に再び固まってしまいました。
これは偶然かもしれませんが、気づいたことを共有します。何も起こらない状態に固まったら、更新をリセットします。再起動を試みますが、何も起こりません。その後、すべての更新が含まれるページに戻り、更新ボタンをクリックします。今回は更新が開始されます。リセット後に、再起動ボタンが実際には何も機能しないコードに何か問題があるのかどうかはわかりませんが、私の経験を共有しているだけです。
今、私が説明したことを行った後、再び更新されています。
混乱しています…またクラッシュしましたが、ブラウザをリフレッシュすると、Discourse が最新バージョンであると表示されました…
プラグインがあるメインのアップデートページに移動すると、Discourse が更新されたことが実際に表示されていました 
スワップを作成してみてください。
このエラーメッセージは最近非常に一般的になっており、常にスワップを作成することで修正されていました。Discourseの公式要件は変更されていないため、理由はわかりません。
この単語は以前見たことがありますが、それが何であるか、そして何のためにあるのか全く分かりません。
リンクを共有していただきありがとうございます。必ずそうします。もし問題が発生した場合は、共有します。
DigitalOcean にアクセスすると、私のドロップレットは次のようになっています。
ですので、共有していただいたスワップファイルプロセスは、「対象」となりますよね？私のサーバーはRAMが2GB以下なので。
2GB未満の場合は、スワップファイルを作成することをお勧めします。私の場合は1GBなので、絶対に必要でした。
私の理解では、スワップは基本的にストレージの一部を使用して、より多くのメモリとして使用できるようにするものです。
それなら、./discourse-setup は自動的にスワップを作成すべきでした。システム管理の奥深さには詳しくないので、他の人に詳しく教えてもらいます。
ただし、必要条件を満たしていても、この問題に遭遇したユーザーがいるので、何か怪しい点があります。
インターフェースからのアップデートについては、長年にわたりあまり信頼できるものではありませんでした。なぜなのかははっきりしませんが、時には再構築が成功したときに、理由もなく失敗することがあります。
ターミナルから、すでにスワップがあるかどうかを確認する方法はありますか？（これは私の質問に答えているかもしれません？ 私はシステム管理の秘術に詳しくありません）
わかりました、私だけではないようですね。
少し混乱しています…ターミナルを使用する場合、これら2つは異なるものですか？アップデートと再構築？なぜなら、私は ./launcher rebuild app のみを使用しており、それは常に機能するからです。
わかりました、ありがとうございます。助かります！
申し訳ありません、インターフェースからという意味でした。投稿を修正しました。
なるほど、これで分かりました
私も同じ経験をしています。
欠点は、再構築でフォーラムが完全にシャットダウンしてしまうことですが、まあ、仕方ないですね。
更新
この分野の専門知識がないため、Claude と ChatGPT を使って問題を解決しました。そのため、提案されたとおり swapfile を使用することにしましたが、Discourse のインストール方法によってはすでに swapfile が存在していた可能性があると指摘されました。それを確認するために、ターミナルで次を実行しました。
sudo swapon --show
すると、次のようになりました。
「使用量」列を見て、「RAM が不足している場合に、スワップファイルが物事をスムーズに実行するのを助けるために使用されるのに、スワップファイルが 2GB 中 1.9GB も使用しているなら、それは役に立たないだろう」と思いました。
そこで ChatGPT にスワップファイルをクリア/空にできるか尋ねたところ、次のコマンドが返ってきました。
sudo swapoff -a && sudo swapon -a
それを実行し、処理が終わるのを待ってから、もう一度別のコマンドを実行しました。
sudo swapon --show
これで、次のようになりました。
時々、スワップファイルをクリーン/空にするプロセスを経るのは良いことだと思いますか？
スワップを増やすことを試す価値があります。
コマンドラインからの再構築はより少ないRAMを消費します。
2つのコンテナインストールでは、新しいコンテナをビルドしながら古いものも動作し続けることができます（十分なRAMがあれば）。これにより、ダウンタイムを少なくできます。
ライブラリの基礎部分を更新する必要があるため、コマンドラインから再構築を行う必要があります。これらはUXからは行えません。
次のコマンドを実行できます:
cd /var/discourse
grep swap discourse-setup
これにより、swapを作成するために何を行うかを見ることができます。swapoffを実行してファイルの使用が停止した状態にし、その後、ファイルを拡大する（fallocate）、必要に応じてフォーマットしてswapにする（mkswap）ことができ、その後swapon -aで再び有効にします。
多くのプラグインを使用している場合、合計で5GBまたは6GBの容量が必要になる可能性があります。