mreach
(M. Reacher)
1
現在、単純な更新以外のメンテナンスを行っている際、サイトをオフラインにするか読み取り専用モードに設定する場合、訪問者に対して何が起こっているのか、またはシステムがどれくらいの間アクセス不能になる見込みなのかを伝える方法がありません。
私はすでにここに記載されているNginxの方法を用いてオフラインページを作成しました（さらにこちらとこちらの手順を踏んで改良しました）が…
システムがダウンしている間、管理者がステータス更新やメッセージを訪問者に提供し、期待値を管理すると同時に、訪問者が状況を推測するのではなく、良好な印象を持てるようにする、包括的なオフラインモードがあると素晴らしいでしょう。
参考のため、@jomaxro によってこのスレッドが分岐するきっかけとなった元の発言を以下に記します：
ここで本当に必要とされるのは、この手法を取り入れつつ、システムがオフラインまたはメンテナンスモードになっている間にユーザーに対してカスタマイズされたメッセージを提供できる、統合されたオフライン/メンテナンスモードです。
これはアップグレードマネージャーに統合される可能性があります（アップグレードマネージャーを「Discourse システムマネージャー」に名前変更し、アップグレード、ログ、プロセス、バックアップをこの領域で一元管理します）。
これにより、システムはより堅牢になり、管理者とユーザーの両方にとって親しみやすく、有用なものになります。
「いいね！」 6
jomaxro
(Joshua Rosenfeld)
2
公式のアップグレード用プラグインであるDocker Managerは、ダウンタイムを引き起こしません。プラグインの変更は不要で、すでにダウンタイムなしのアップグレードに対応しているためです。この#howtoが扱う問題は、コマンドラインから実行されるアップグレード（再構築）です。これらは、RubyバージョンやPostgresなどの基盤となる依存関係をアップグレードする必要がある場合など、年に数回と頻度は低く必要とされます。Docker Managerは、Discourse全体と同様に、再構築中はダウンするため、そのようなアップグレードを処理することはできません。このトピックで提供されているNginxプロキシソリューションのように、Discourseの外側で解決策を講じる必要があります。
「いいね！」 7
mreach
(M. Reacher)
3
うーん、Discourse の性質とより一貫性のある他の選択肢があると思います… この案をすぐに却下するのではなく、特に管理者が何らかの理由でメンテナンスのためにサイトを停止する必要がある場合、この点における全体的な体験を向上させる方法について話し合いましょう。
一つ考えられるのは、OP が提案した Nginx プロキシ解決策を Docker 設定に組み込むことです。そうすれば、Discourse のユーザーと管理者、そしてサポート担当者（このフォーラムにいるあなたのような方々）にとって、より予測可能で管理しやすく、一貫性のあるものになります。ここで提示されたような、切り離された解決策を扱う必要がなくなるからです。
「いいね！」 1
jomaxro
(Joshua Rosenfeld)
4
このコンセプトを却下するつもりはありません。Discourse プラグインを使ってこれを解決するのはうまくいかない、と単に述べているだけです。適切な議論のために、この議論を専用の #feature トピックに移動させましょう。
@mreach さん、OP を編集して、あなたが求めていることと、それがどのように機能してほしいかを詳しく記述してください。必要に応じてタイトルも編集してください。
「いいね！」 1
sam
(Sam Saffron)
5
./launcher rebuild app の実行中にダウンタイムを最小限に抑えたい場合は、マルチコンテナ構成が必要です。
これはすでにドキュメント化されていますが、より複雑なセットアップとなります。
単一コンテナモードで launcher rebuild を実行し、「オフライン」ページを表示させるには、「サイトがオフライン中」を示す専用コンテナにコンテナを切り替える必要があります。不可能ではありませんが、完璧に動作させるには約 2 週間のエンジニアリングリソースが必要です。コンテナの再構築は非常に稀であり、すでに中断なしで再構築を行う方法がドキュメント化されていることを考慮すると、現時点ではこの機能の開発資金を確保することは難しいと考えています。
「いいね！」 9
pfaffman
(Jay Pfaffman)
6
サムさんの意見に賛成です。「サイトがダウンした」ページを作成するだけの余裕があるなら、むしろサイトをダウンさせないために時間を使うべきでしょう。ただし、Add an offline page to display when Discourse is rebuilding or starting up のようなオフラインページの追加を検討しているのかもしれません。
2コンテナ構成のインストールでは、ほとんどの場合アップグレード時のダウンタイムを最小限に抑えられます。ただし、新しいコンテナのビルド中にマイグレーションが実行され、稼働中のサイトがクラッシュするケースが稀にあります。これを回避する方法はありますが、やや複雑で、そのような更新は非常に稀にしか発生しません。
また、DNS を再設定するか、Elastic IP（または Digital Ocean が呼ぶ名称）を使用し、ステータスメッセージを含む Web サーバーを備えた Droplet（または AWS が呼ぶ名称）を起動することも可能です。
「いいね！」 2
mreach
(M. Reacher)
7
ところで @jomaxro、私の投稿をこの新しいトピックにどうやって分けたんですか？どのような手順を踏んだのか教えていただけますか？とても役立つ情報だと思います。標準の Discourse には、そのための方法が見当たりません。
「いいね！」 1
mreach
(M. Reacher)
9
おお、素晴らしい。その件が終わった後、このトピックについてあれこれ探っていた時に、5回も見落としていたに違いないですね。
「いいね！」 1