Cool good to know, thanks for your feedback
The first post says this
Is this the only way to do it? We don’t have nginx running outside docker
Yes, that’s the only way. The idea is to install a webserver (nginx recommended) to serve the request, if Discourse is up it routes it there. If not it does something else. All the installation process is explained step by step.
「いいね！」 2
こんにちは、
はじめに
その解決策をありがとうございます、@fefrei さん！https://community.hiveeyes.org/ でこの機能を導入し、完璧に動作しています。
その他の考察
ただし、@mlinksva さんの以下の関連質問をここで参照させていただきたいと考えています。
この点も私たちにとって共感できるものであり、/errorpages の解決策だけではまだ解決されていない課題だからです。これは、汎用的なテキスト「申し訳ありませんが、そのトピックを読み込めませんでした。接続の問題が原因の可能性があります。」を改善することに関するものです。より詳細に説明できるよう努めます。
discourse_offline.html の提供
ユーザーが初めてサイトに訪れる場合には、これは完璧です。
「申し訳ありません」のテキストを別のものにする
しかし、Discourse 内で移動する際には、以下のように警告が表示されます。
理由について何も示されていません。
すでにご存じかと思いますが、このテキストを変更できるカスタマイズ機能があるはずです。見逃していた可能性もあります。また、Maintenance Mode? で説明されている通り、機能「管理者 » バックアップ » 読み取り専用を有効化」が既にこの問題を解決するかどうかは調査していません。
いずれにせよ、このトピックを改めて取り上げることは理にかなっていると考えており、もし無意味なことだったとしてもご容赦いただければ幸いです。
よろしくお願いいたします、
Andreas.
追伸：@staff さん：この議論が、適切な Nginx や Web サーバーの設定詳細についてやや制御不能な方向へ展開してしまったため、これらの投稿を「オフラインページの Web サーバー設定」のような適切な名前のトピックに分割する抜本的なリファクタリングを提案いたします。適切なタイトルを見つけることは間違いありません。もしこの提案が気に入っていただければ、実行していただけることを感謝申し上げます。
しかし、すぐにカスタマイズ可能なサイトテキストブロックとして見つかった今、私たちは実際にばかげた気分になっています:
– https://community.hiveeyes.org/admin/customize/site_texts/js.topic.server_error.description
標準テキスト js.topic.server_error.description を以下のように変更しました:
お聞きいただき、ありがとうございます ;]。
「いいね！」 3
ふむ。そのテキストを変更しても実際に機能するかどうかは確信が持てません。この箇所を修正する際に、何か特別な考慮事項はありますか？
また、サイトがダウンしていた特定の時間帯には、以下のように異なるメッセージが表示されていたことを付け加えさせてください。
この部分も変更する方法について、ご存知でしょうか？
「いいね！」 1
それを使っていますが、カスタムのオフラインウェブページを作成したいのに、うまくいきません。
素晴らしいガイドです。
ただ、この証明書の自動更新に関するいくつかのコマンドも記載してくだされば、完璧なガイドになったのにと思います。
ここに記載されているリンクは見たのですが、そのリンクには証明書の新規インストール方法や更新方法しか書かれていません。
「自動更新」の方法についてのガイダンスが見つかりませんでした。
ありがとうございました。
「いいね！」 1
良い指摘ですね！元の投稿のこのセクションをすでに更新しました 
「いいね！」 1
アップグレード時に、より一般的な500エラーが表示されていることに、他にも気づいている方はいますか？たまたまタイミングが悪かったのかもしれません。
「いいね！」 1
コンテナが再構築中に停止されている場合、500 エラーを返す実行中のプロセスは存在しません。
「いいね！」 4
冒頭で提案されたように、これらの手動ステップを回避するために、別の Docker コンテナを使用しようとした人はいますか？
はい、多くの方が移行されています。詳しくは Move from standalone container to separate web and data containers をご覧ください。なお、コンテナを分離した構成はインストールがより複雑であり、Meta の多くのガイドは単一コンテナ（スタンドアロン）のインストールを前提としています。コンテナを分離する前に、2 つのコンテナがそれぞれ何を行うのか、今後どのようにそれらとやり取りするのかを理解してください。特に重要な点として、./launcher コマンドのターゲットとして app はもはや有効ではなくなります。
「いいね！」 5
ふむ、このトピックにはなぜか2つの投稿で「nginx in front」という記述が残っていますね。
ところで、私が本当にやりたいのは
- ここで議論されているオフラインページを導入すること
- ウェブサーバー上で HTTP → HTTPS へのリダイレクトと、ルートドメイン → www へのリダイレクトを設定することです。Cloudflare は使いたくありません。ロシアではその一部の IP アドレスがブロックされているためです。
つまり、私の理解では、web コンテナだけでそれを実現する方法を調べればよいのですね 
今は混乱しています。
これらの目標のどちらも、個別のコンテナ設定を必要としません。上記の両方のステップを設定したいと考えており、かつ独立して個別のコンテナを探しているのでしょうか？それとも、上記を完了するために個別のコンテナが必要だと考えて、それらを見ていたのでしょうか？
私の理解では、オフライン（再構築）ページの処理は、実行されていないため、同じコンテナ内には配置できません。そのため、現在のトピックで提案されている解決策は、その前面に nginx を追加することです。しかし、このトピックで議論されたように、多くの手動手順が必要で OS 固有のものとなるため、この前面の nginx 用に別の Docker コンテナを使用する方が、より信頼性が高く、保守が容易だと考えました。
ああ、今わかった。その場合は、以前リンクしたトピックは無視してください。Discourse の Web サーバーとデータベースを分離する話でした。ここではそれは不要です。
Nginx を OS に直接インストールするのではなく、Docker コンテナ内でインストールすることも可能ですが、Discourse 固有のガイドは存じ上げていません。この方法を選択する場合は、このトピックの OP（オフラインページを作成し、その前に Nginx プロキシをインストールするために必要な変更）を理解し、Docker の仕組み、特に 2 つの Docker コンテナ間のネットワーク設定に精通していることを確認してください。また、この設定は私たちが経験したことがないため、提供できるサポートは限られる可能性がある点にご注意ください。
これもう動作しなくなっていることに気づきました。
11 月上旬に @fefrei のアプローチを実装したときは確かに動作していました。おそらく、コンテナを手動で停止して git pull を実行し、/admin/upgrade を使用していなかったことが原因かもしれません。
「いいね！」 1
4件の投稿が新しいトピックに分割されました：再構築時にネイティブのオフラインページをサポートする
私たちは最近、全く同じことを試しましたが、オフラインページが正常に機能しました。
現在、/admin/upgrade を通じてオンラインアップグレードを実行しましたが、Discourse がオフラインにならないことがわかりました！これが最近改善されたのか、それとも単に今回は運が良かっただけなのかはわかりませんが、重要なダウンタイムを経験することなくオンラインアップグレードが実行されている様子を見るのは素晴らしいことです。
Docker Manager（/admin/upgrade）を使用してアップグレードを実行する場合、Discourse がオフラインになることは決してありません。通常、オフラインになりますか？もしそうであれば、その件について Support トピックを開始すべきです。