私のやりたいことは、例えば再構築プロセス中にオフラインになったときに、「このサイトはメンテナンス中です」というページを表示することです。
このトピックは基本的に私がやりたいことですが、標準的でないセットアップが必要なようです。標準的なインストールでこれを簡単に行う方法はありますか？よろしくお願いします！
現時点では、そのようなものはありません。
「いいね！」 3
実際には、この手順では「標準インストール」（つまり、公式のDiscourse Dockerガイドを使用）が使用され、Nginxはコンテナの外に再デプロイされます。
この手順は最初は恐ろしく見えるかもしれませんが、実際はそうではありません。もしよろしければ、お手伝いできます。
聞きたかった答えではありませんでしたが、それでも明確な回答に感謝します。
プロセス自体はそれほど心配していませんが、将来的に新しいプラグインをインストールするような簡単なことを行う際に、このセットアップに追加の考慮事項が必要になるかどうかの方が心配です。それとも、一度セットアップしたら、二度と考える必要がないようなものなのでしょうか？
2020年にこれを追加して以来、NGINXの設定を編集したのは2回だけです。どちらの場合も、Discourseで制限を更新した後に大きなファイルをアップロードする設定を調整する必要がありました。
静的ページを提供し、Discourseのリバースプロキシとして機能するために外部NGINXを使用する場合、通常は適切にセットアップすれば変更は必要ありません。
「いいね！」 3
外部 nginx は、静的なエラーページ以外にもう一つ価値のあるものをもたらします。それは、IPv6 ユーザーのソース IP アドレスの正しい属性です。フォーラムが IPv6 でアクセス可能で、外部 nginx 設定を使用していない場合、IPv6 でサイトにアクセスするすべてのユーザーは、172.x.y.z のローカルアドレスから来ているように表示されます。これは、スパマーのような悪意のあるサイトユーザーに対処しようとする際には役立ちません。
新しいプラグインを追加する場合も、まったく同じです。
メンテナンスが行われることをユーザーが認識し、それが完了するまで待つだけなので、更新が容易になると考えています。
注意しておきたい唯一のことは、certbot が証明書を正しく更新していることを確認することです。これは外部 nginx を使用しないデフォルトの設定に組み込まれていますが、外部 nginx を使用する場合は、外部 certbot も使用し、証明書を更新するように設定されていることを確認する必要があります。そして、certbot をインストールするすべての方法がこれを処理するわけではありません。
お問い合わせのドキュメントには次のように記載されています。
パッケージリポジトリから certbot をインストールした場合、通常、更新は自動的に行われます。それ以外の場合は、証明書の有効期限が切れる前に
letsencrypt renew && systemctl reload nginx.serviceを実行することをリマインダーに設定してください！
ただし、リマインダーを設定するのは良い方法ではありません。あなたは必ず忘れてしまい、letsencrypt から証明書の有効期限が切れることを警告するメールを見逃した場合、サイトは動作しなくなります。幸いなことに、これは簡単に回避できます。
自動更新が設定されていない場合は、次の方法で設定します。
/etc/systemd/system/certbot.service ファイルを次の内容で作成します。
[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true
/etc/systemd/system/certbot.timer ファイルを次の内容で作成します。
[Unit]
Description=Run certbot twice daily
[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200
Persistent=true
[Install]
WantedBy=timers.target
次に、systemd に新しいファイルについて通知します。
# systemctl daemon-reload
# systemctl enable --now certbot.timer
「いいね！」 1
2つのコンテナを使用する場合、ダウンタイムは1分未満であり、そのようなページは実際には必要ありません。
「いいね！」 1
いくつかの調査の結果、私のスキルレベルでは、Nginxよりも2つのコンテナのメンテナンスの方がはるかに要求の厳しい仕事であることが明らかになりました。
「いいね！」 2
ああ、なるほど。私の視点からすると、それはほとんど同じですが、日付コンテナをいつ更新する必要があるかに注意する必要があります。それはまれですが、注意が必要です。そして、それが起こると、サイトはしばらくの間ダウンします。
それも本当ですね。常にトレードオフがあります。アップデート/アップグレードのためにフォーラムがダウンしている時間と、個別のコンテナのメンテナンスに必要な時間（特に、すべてを台無しにして修正を探し始め、フォーラムが同時にダウンした場合など）とのトレードオフです。
「いいね！」 2
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.