最小限のダウンタイムで主要なディスコースメンテナンスを実行する方法は？

インストール ホスティング
1

Discourse インスタンスのコアメンテナンスタスクをダウンタイムを最小限に抑えるか排除して実行するためのベストプラクティスに関するディスカッションを開始したいと思います。

UNICORN_WORKERS、DISCOURSE_SIDEKIQ_WORKERS、DISCOURSE_DB_POOL などの重要なリソース設定の変更や、メジャーアップデートの適用のようなタスクでは、通常 launcher rebuild app が必要となり、これにはかなりの時間がかかることがあります。場合によっては 30 分以上かかることもあります。

私の質問は次のとおりです。
システム管理者は、ユーザーが直面するダウンタイムを最小限に抑えて、これらの不可欠なアップデートや設定変更を実行するために、どのような推奨戦略がありますか？

Discourse でサポートされている、または推奨されている、ブルー/グリーンデプロイメントやその他のゼロダウンタイムデプロイメント戦略のような高度なテクニックはありますか？それとも、標準の rebuild プロセスのみがサポートされている方法であり、再構築時間自体の最適化に焦点を当てるべきでしょうか？

大規模または高トラフィックのインスタンスを管理した経験がある方で、メンテナンスのワークフローがどのようになっているか、ご意見をお聞かせください。

洞察をいただければ幸いです！

「いいね！」 1
2

2つのコンテナをインストールした場合、新しいコンテナがビルドされ、古いコンテナは実行されたままになります。ダウンタイムは、新しいコンテナを起動するために必要な時間だけです。唯一の問題は、もう一方のコンテナが実行されている間にコンテナをビルドするために十分なRAMが必要になることです。

スタンドアロンコンテナからWebコンテナとデータコンテナを分離するに移動しますが、通常は新しいVMに移動します。

ダウンタイムをゼロにしたい場合は、新しいコンテナが完全に起動するまで古いコンテナを実行し続けるロードバランサーが必要です。その後、古いコンテナをシャットダウンし、更新後のマイグレーションを実行します。

「いいね！」 7
3

フェイルオーバーで2つのデータコンテナを使用できますか？

通常、データの別個の仮想マシンを使用していますか？

「いいね！」 1
4

Discourse は非常に安定しているため、ほとんどのインストールではこれはほとんど不要です（ただし、非常に高い可用性が要求される場合や、他の人をホストしている場合は検討するかもしれません？！）。

7年間、本番環境の「グリッチ」による停止は一度も経験したことがありません…

Discourse の最も危険な瞬間は、常に再構築時です。

2つのコンテナを設定すると、コミットする前に新しいビルドをブートストラップできますが、もちろん実行時エラーの一部はキャッチできません。

マイグレーションが実行された場合、新しいビルドにコミットする必要がある可能性があるため、通常はそれらのエラーの原因を特定して修正しようとします。ロールバックするのではなく。

一般的に、人々はロールバックしようとしません…

「いいね！」 1
5

大きな再構成を行う際には、新しいVMに移行します。

PostgreSQLミラーを実行することは可能ですが、多くの作業が必要です。

「いいね！」 3
6

リードレプリカの方が良いのではないでしょうか？

「いいね！」 3
7

ええ！レプリカ！それが彼らが使う言葉です。そして、もう一方が死んだら、レプリカにホットスワップできます。

「いいね！」 4