私のアップデートにエラーが発生しました
api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
修正にご協力ください。
やあ！
あなたの質問に答えているわけじゃないけど、ただ好奇心が湧いただけ。なぜメンテナンスページが必要だと思うの？ 設置するのは結構めんどうくさいし、得られるメリットもほとんどないように思えるけど。
私のインスタンスは、アップデートのために月に5分ダウンするくらいで、それくらいが限界だよね。
プラグインのインストールなど、大きな変更を加えるたびに、それが完了するまで20分ほどかかることがありました。
このような作業は毎週、いや毎月行われるものではないので、大した問題ではありません。しかし、新規訪問者にとって、何かが正常に動作していないことを示す不格好なページは、良い第一印象を与えません。サイトがダウンしていることを知らないリピーターにとっても、コミュニティ全体が閉鎖されたのではないかと「パニックモード」に陥らせ、中にはすぐにメールを送って状況を確認しようとする人もいるかもしれません。
訪問者、新旧を問わず、現在何が起こっているのかを伝えるのは、ちょっとした気配りとして良いと思います。
Claudeが提案したこのアプローチが数分で完了し、その後すぐに修正が必要になるものではないなら、その時間は無駄にはならないでしょう。
私はCloudflare CDNの背後にdual container buildを使用しています。デュアルコンテナはダウンタイムを最小限に抑え、私の2つのメインの本番環境フォーラムはどちらも再構築中に最大30秒間のオフライン時間しかありません。メンテナンスページがあるのは気に入っています。なぜなら、デフォルトのWebサーバーのダウンページは醜く、オフラインになる時間がどれくらいかについてのヒントが何も与えられないからです。
これを行うためのドキュメントは現在こちらにあります：
わあ！そのような詳細な手順の説明、本当に感謝しています！
私はあなたの返信をメモに保存しましたので、すぐにDiscourseを再インストールする際に、再度参照します。インストールが完了したら、たとえ時間がかかっても、必ず結果をお知らせします。現在はいくつかのコーディング作業を完了させており、その後で再びDiscourseに集中します。
また、「Webサーバーがダウンしています」ページが醜く、経験のないユーザーにはそのメッセージがあまり意味を持たない点には同意します。カスタムメッセージを含むシンプルなメンテナンスページを設けることは、設定に多少の手間がかかる場合でも、常に好ましい選択肢です。
改めて、この情報を共有するために時間を割いてくださったことに、心から感謝申し上げます。他の人々もこの情報を有益だと感じると願っています 
ここに問題の核心があります。
これは単純な変更ではなく、心配し維持しなければならない追加のインフラが必要になりますし、私見では、数秒のダウンタイムに対してそれだけの価値はありません。
おっしゃることはわかりますが、それは単なる一例に過ぎません。本当に何か壊れてしまい、数秒以上かかって修復が必要な場合はどうなるのでしょうか？
また、プラグインのインストール後、あなた方は数秒のダウンタイムしか経験していないようですが、私は20分近くダウンタイムを経験しました。なぜそのような違いが生じるのでしょうか？
2つのコンテナ構成（両方の投稿でリンクされており、変更不可能な依存関係）では、./launcher bootstrap web_only を使用して新しいビルドをブートストラップします（この間、サイトは100%正常に動作します）。その後、すでに構築された新しいコンテナを単純に破壊し、すぐに起動します（これには数秒しかかかりません）。
ああ、わかりました。それはまだ2コンテナのセットアップに関する話ですね。完全に2コンテナのセットアップを構築するのは労力の割に得られないと言っているのかと誤解していました。あなたが言っている「労力の割に得られない」というのは、そのメンテナンスページの追加作業のことですよね？
個人的には、イエスです。
30〜60秒の間に新しいナビゲーションが表示されるウェブ閲覧者に対して二重の保険（belt and braces）を設けたい場合は、メンテナンスページを表示することは妥当です。
ただし、その利点と、それを支えるインフラを維持するために必要な時間を比較衡量する必要があります。
なるほど、わかりました。ありがとうございます。
では、ここで質問です。2つのコンテナがある場合、それでも20分程度かかるのは変わりませんが、唯一の違いは、稼働していない方のコンテナで処理を実行させておき、準備が整ったら切り替えることができるという点です。この理解で合っていますか？
はい、コンテナのビルドにはまだ少し時間がかかります。なお、コミュニティへの通常サービスを提供しながら並行してこのプロセスを実行するには、サーバーが十分に強力である必要があります（最も重要なのは、まず十分なメモリを確保することです。したがって、SWAP領域が十分にあることを確認することが非常に重要です）。ビルド処理では少なくとも1つのCPUコアが専有されるため、サーバーには1～2つ多いコア数を持つことを検討してください。
しかも、サーバーのパフォーマンスは劣っているように見えます…？この種のセットアップには、少なくとも4GBのメモリと3コア（“vcpu”）を推奨します…
別のトピックで質問されていたため、参考までに（編集：誤った）回答を記載します：Any cheaper alternatives to Hetzner? - #2 by Canapin
これがそれに合致する唯一のものですが… 価格の差がすごい…
仕方なく、まずは1つのコンテナで構築して、資金（
）が揃ったらアップグレードすることにします。
情報をありがとう、ロバート！
私はそれに反対で、メンテナンスページを設ける価値があると思います。私の経験では、人々が Discourse のエラーページを最初にみたとき、まずリフレッシュボタンを押します。そうすると、コンテナの切り替えが完了すると自動的にサイトを再読み込みする、わずかな時間のメンテナンスページが表示されます。設定するのはそれほど手間ではなく、一度設定すれば済みます。デュアルコンテナ構成での再構築中、ブートストラップ部分はバックグラウンドで実行され、ユーザーはサイトを继续使用できます。一時的なダウンタイムを引き起こすのはコンテナの切り替え部分です（標準のシングルコンテナ構成とは異なります）。
サーバーのコストと選択は全く別の問題であり、別のトピックで議論されるべきです。
今はちょうど中間地点にいるような気がします。@merefield の方も含め、お二人の言いたいことはよくわかります。そんな機能があるのは素敵なアイデアですし、一度設定すればあとは放置で済むなら、それほど大したことではないのかもしれませんね？
一方で、最悪の場合に60秒もかかるのであれば、誰もがちょうど0秒のタイミングでサイトにアクセスして60秒待つわけではありません。5秒、20秒、60秒……人によって見せられる「未完成なページ」の時間は異なります。また、返信を読みながらいたり、書きながらいたりする間にはその切り替えが起きるため、そもそもそのページを見ない人もいるでしょう（そう思います？）。例えば、SENDボタンを押す前や、トピックの読み終わってREPLYを押す前、あるいは他のページに遷移する前に切り替えが完了している場合です。
nginxのルーティングに関する私の懸念は、単一コンテナ構成における20分という時間に関連していました。2コンテナ構成のオプションがあり、20分から最大でも60秒程度に短縮できるなら、本当にそれが重要な問題なのか疑問です。特に、トラフィックの少ない時間帯に、数秒間サービスが停止することをトップに告知できるなら、大きな問題にはならないでしょう？
じっくり考えてみる必要があります。もし良いサーバープランが見つかったら、2コンテナ構成は確実に導入するつもりです。
私のような初心者にもわかるように、これを明確に説明していただけますか？ ワーカーについてはまだ慣れていません…
放置しておいても問題がないなら、なぜワーカーのルートページを追加したり削除したりするのですか？ つまり、メンテナンスページを追加する場合、一度設定すれば、それ以降はCloudflareにアクセスする必要なく、単一コンテナの場合と同様に、常にTerminal経由でSSH接続してサーバー上ですべての操作を行うことができるのでしょうか？
@merefield は、これ（メンテナンスページ、ワーカーなど）もメンテナンスが必要なものだと指摘していました。そのため、これは「設定して忘れる」タイプのものなのか、それとも時々何かを行う必要があるのか疑問に思っています。