サイトのテーマやプラグインのインストール/アップデート中にサイトがオフラインになるのは正常ですか？
「いいね！」 1
サイトの再構築中はサイトがオフラインになるのは普通のことです。
解決策としては、2コンテナインストールを使用する方法があります。これにより、新しいコンテナを構築できるため、ダウンタイムは1分未満になります。または、「すぐに戻ります」ページを表示するように工夫する方法もあります。これはダウンタイムを変えるものではありませんが、サイトがダウンしていることを認識していることが全員に伝わります。
誰もが、これらの解決策の少なくとも1つは難しすぎて、手間をかける価値がないと考えています。
「いいね！」 4
プラグインとは異なり、テーマやテーマコンポーネントのインストールやアップデートにはオフライン時間は必要ありません。
「いいね！」 4
言及されたメソッドに関するドキュメントはありますか？また、ディスコースの観点からSEOに非常に適していることを考えると皮肉なことに思えますが、読み込み中に中断があり、Googleボットがサイトをクロールできません。
新しいプラグインのインストールはどのくらいの頻度で発生すると想定していますか？これは通常、非常にまれなことです。
コンテナが切り替わる際に、サービスへの影響はほとんどなく、オンラインでプラグインを更新できます。
「いいね！」 2
返信ありがとうございます。
「いいね！」 1
時間があるときに Add an offline page to display when Discourse is rebuilding or starting up を見てみてください。
「いいね！」 2
こんにちは:wave: よくわかりませんが、間違っているかもしれませんが（まだ試していません）、これはコア機能ですか？ discourse/templates には offline-page.template.yml という新しいテンプレートが数か月前にあり、その中で GitHub - discourse/discourse-offline-page: offline page for discourse をトリガーしています。これは、Discourse の読み込み中に表示される静的な HTML サイトです。また、discourse_docker の PR もあります: FEATURE: add offline page template by featheredtoast · Pull Request #752 · discourse/discourse_docker · GitHub
「いいね！」 3
それは半分しか当たらないように思えますか？ 再構築が正しいと理解していれば、起動時には表示されますが、再構築時には表示されません。
nginx が利用可能だが rails が利用できない場合に、GitHub - discourse/discourse-offline-page: offline page for discourse から静的 HTML ファイルを取得して提供するテンプレートを追加します。
^ GitHub PR
「いいね！」 2
しかし、正しい方向への一歩です。@Don（そして@featheredtoast !）ありがとうございます。
ええ、@Firepup650、なぜそれが見えなかったのか不思議に思っていましたが、その理由を答えてくれたのだと思います！
ここには良い:male_detective: 
がいくつかありますね！
これは、nginxコンテナが別個に構築される、恒久的な標準2コンテナセットアップへの事前ステップなのでしょうか？！??! 
「いいね！」 2
お見通しの通り、オフラインページ提供をより広く可能にするための取り組みが進行中です。言及されているコミットとリポジトリはそのための基盤ですが、まだ（現時点では）実装されていません。
「いいね！」 5
理由あって、ユーザーの誰も、チャットで再構築中にそれが見えません。そのため、ユーザーが単に書いたメッセージを失うというインシデントがいくつか発生しています。
すでにログインしているユーザーに対してダウンタイムをまったく通知しない状況は、Discourse における最大の単一の UX 問題であると私は思います。このアプリの性質上、その理由を理解することはできますし、開発者は当初から（下書きやその他のいくつかの状況と同様に）自分たちを追い詰めてしまったようなものですが、それは問題そのものをなくすものではありません。
いくつかの回避策があります。Discourse の前に Nginx をリバースプロキシとして使用し、調整されたエラーページを表示することが 1 つです。管理者が問題に直面した場合、回答は「標準のものしかサポートしていません」となります。それが私がそれを却下した実際の理由です。
2 つの異なるコンテナが 1 つのソリューションです。少なくともダウンタイムは非常に短くなります。それについては警告が多すぎるため、その道を進むのは少し怖いです。
または、時々アップグレードし、発生前にユーザーに通知し、パブリックアクセスをシャットダウンすることもできます。はい、それは 1 つのソリューションですが…今や 2024 年であり、私の環境では銀行システムしかそれを使用していません 
ステージングサーバーを使用することは行うべきことです。まあ、それは企業レベルのソリューションであり、適切に行われれば高価で非常に困難な方法であり、独自の IT チームを愛しています。
したがって、新しいリークされた計画🤣は確かに実際の改善です。まあ、別のコンテナが必要な場合は、飛び込む時だと思います。
「いいね！」 1
データコンテナを再構築する必要がある場合を除き、まったく同じです。
「いいね！」 1
しかし、ダウンタイムは20分よりもはるかに短いですよね？
「いいね！」 1
チャットには、ページをキャッシュできる通常のサイト表示とは異なるものが含まれている可能性があります。これは、リアルタイムアクセスの方が優れているためだと考えられます。
同意します。計画されたメンテナンスのアナウンスは、昔のDOSベースのダイヤルアップBBSのように行うのが最善だと思います。システムメッセージで、計画されたメンテナンスシャットダウンが近づいており、指定された時間にユーザーをログアウトさせるという警告を表示するオプションがありました。当時は、ネットワーク化されたBBS間でメールパケットを処理するためによく行われていました。
「いいね！」 1
はい。通常、ダウンタイムは1分未満ですが、コンテナを1つ再構築している間、もう1つを再構築するには十分なRAMまたはスワップが必要です。
「いいね！」 1