Discourse の読み取り専用モード

:bookmark: このガイドでは、Discourse で利用可能な各種の読み取り専用モード、それらの有効化・無効化方法、および各モードを使用すべきシナリオについて解説します。

:person_raising_hand: 必要なユーザーレベル:管理者

Discourse 上で活発なオンラインコミュニティを運営する際、管理者が一時的にユーザーの活動を制限する必要がある場合があります。このような状況には、サーバーのメンテナンス、バックアップの促進、サーバーの移行などが含まれます。そのような時期には、ユーザーのアクセスを完全に遮断することなく、フォーラムの活動を制限することが不可欠です。

Discourse では、サイト内のさまざまな種類のインタラクションを一時的に停止するために、管理者が有効にできるさまざまな読み取り専用モードが用意されています。

このガイドでは、これらのモード、特にそれらの有効化・無効化方法、および特定のモードが交錯する状況への対処法について詳しく説明します。

読み取り専用モードの理解

Discourse は、さまざまな管理ニーズに対応するために、2 つの異なるレベルの読み取り専用モードをサポートしています。それらは以下の通りです。

  1. 完全な読み取り専用モード
  • フォーラム内のすべての書き込み操作を制限し、投稿、コメント、いいねなどのコンテンツの作成や変更をすべてのユーザーから禁止します。
  • フォーラムを現在の状態で事実上「凍結」し、ユーザーが既存のコンテンツを読み取り、ナビゲートできる一方で、データベースへの影響を与えないようにします。
  • データベースの現在の状態を維持するために、管理者サイト設定やサイトのカスタマイズの変更を無効にします。
  • 一般ユーザーの新しいフォーラムログインを無効にします。管理者は、管理者用メールログインフロー(/u/admin-login)を使用してログインできます。
  • API 呼び出しは読み取り(GET)可能ですが、書き込み(POST/PUT/DELETE)はできません。
  • キューイングされた送信ウェッブフックは配信されますが、それらをトリガーするアクションがブロックされるため、新しいウェッブフックはトリガーされません。
  • 受信ウェッブフック(メールのバウンス)は 503 レスポンスでブロックされます。メールプロバイダーは、独自のバックオフスケジュールに従って再試行します。
  1. スタッフのみ書き込み可能モード
  • フォーラム内の書き込み操作(投稿、コメント、いいねなど)を一般ユーザーに制限します。スタッフ以外のユーザーは読み取り専用操作に制限されますが、アカウントにログインすることは可能です。
  • 管理者およびモデレーターの活動は通常通り続行されます。管理者はサイト設定を変更でき、スタッフユーザーは投稿、いいね、プロフィールの変更などの書き込み操作を実行できます。
  • API 呼び出しは読み取り(GET)可能です。書き込み(POST/PUT/DELETE)は、スタッフ用 API キーを持つ場合のみ可能です。
  • キューイングされた送信ウェッブフックは配信されます。スタッフのアクションによって新しい送信ウェッブフックがトリガーされ、これも成功しますが、スタッフ以外のユーザーのアクションによってウェッブフックはトリガーされません。
  • 受信ウェッブフック(メールのバウンス)は 503 レスポンスでブロックされます。メールプロバイダーは、独自のバックオフスケジュールに従って再試行します。

これらのモードにより、重要な管理期間中のフォーラムの運用性を柔軟に管理することが可能になります。

読み取り専用モードの有効化・無効化方法

:warning: 管理者は、異なる読み取り専用モード間の移行を慎重に管理する必要があります。読み取り専用モードを有効にする前に、以前に有効化されたモードが無効化されていることを確認してください。

完全な読み取り専用モード

Rails コンソール経由

Discourse のインストールにアクセスできる場合は、./launcher enter appで Docker コンテナに入り、その後 rails cで Rails コンソールを開いた後、Discourse の Rails コマンドラインインターフェースを使用して以下のコマンドを実行してください。

Discourse.enable_readonly_mode(Discourse::USER_READONLY_MODE_KEY)

管理パネル経由

Web インターフェースを介して管理者アクセスがある場合は、Admin > Backups > Enable Read-Only Mode に移動して読み取り専用モードを有効にできます。

読み取り専用モードを無効にするには、以下の Rails コマンドを実行してください。

Discourse.disable_readonly_mode(Discourse::USER_READONLY_MODE_KEY)

または、管理パネルを使用して Admin > Backups > Disable Read-Only Mode に移動してください。

スタッフのみ書き込み可能モード

:discourse: スタッフのみ書き込み可能モードは、Discourse の Rails コンソールからのみ有効化・無効化できます。Discourse によってホストされているサイトの場合は、このモードの有効化または無効化を希望する場合は team@discourse.org までご連絡ください。

スタッフのみ書き込み可能モードを有効にするには、以下の Rails コンソールコマンドを使用してください。

Discourse.enable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY)

無効にするには:

Discourse.disable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY)

ベストプラクティス

  • タイムリーなコミュニケーション: 予定されている読み取り専用期間について事前にコミュニティに通知し、適切な期待値を設定します。
  • テスト: 重要な操作中にこれらのモードを実装する前に、トラフィックの少ない時期にテストを行い、その影響を理解します。
  • ドキュメント: 各モードがいつ、なぜ有効化または無効化されたかについて詳細な記録を保持し、将来の運用計画を支援します。

よくある質問

  • 読み取り専用モードの有効化・無効化にどのくらい時間がかかりますか?

    • 変更は即座に反映されます。ただし、移行期間中のユーザーのアクションによっては、ユーザー体験が若干異なる場合があります。
  • 助けてください!読み取り専用モードのためにサイトからロックアウトされてしまいました。再度サイトにアクセスするにはどうすればよいですか?

  • discourse/lib/discourse.rb に他の READ-ONLY モードがリストされていることに気づきましたが、これらのモードは何をするものですか?

    • READONLY_MODE_KEY は主にバックアップとリストアプロセスに使用され、アプリケーション自体によってトリガーされます。このモードは、discourse enable_readonlyおよびdiscourse disable_readonlyを使用して、Discourse コマンドラインインターフェースからも有効化または無効化できます。ただし、このキーはコンテナの再起動後に生存しません。
    • USER_READONLY_MODE_KEY は、管理者が管理インターフェースで読み取り専用ボタンをクリックしたときに使用されます。このキーの特別な点は、ユーザーによって有効化された読み取り専用状態がコンテナの再起動後も維持される必要があるため、有効期限付きキーとして設定されないことです。他のキーは TTL(READONLY_MODE_KEY は 60 秒、PG_READONLY_MODE_KEY は 300 秒)で設定され、アプリが読み取り専用モードに閉じ込められないように、30 秒ごとに有効期限を延長するスレッドがあります。
    • PG_READONLY_MODE_KEY および PG_FORCE_READONLY_MODE_KEY は、PG フェイルオーバーに使用されます。前者は有効期限付きキーとして設定され、後者は有効期限なしです。
「いいね!」 9

違いがわかりません!もし違いがある場合、これらの説明を調整していただけますか?

「いいね!」 1

ガイドを更新し、ここでいくつかの追加の明確化を行いました。読み取り専用モードについて、まだご不明な点がございましたらお知らせください。 :slightly_smiling_face:

「いいね!」 1

しかし、

discourse enable_readonly

は何をするのでしょうか?

READONLY_MODE_KEY を使用しており、ttl を 60 に設定するため、ある時点でオフに戻ります。さて、

このコマンドのデフォルトの動作には何か理由があるのでしょうか?ウェブインターフェイスの読み取り専用モードとは完全に異なるコマンドであることに気づくのに、何年もかかりました。そして、誰かがかつてこれらのキーについて教えてくれようとしたことを思い出しましたが、その重要性を理解できませんでした。

私の意見では、discourse enable_readonly が行うべきは、Discourse.enable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY) のようなことだと思います。ずっと前に気づいていればよかったです!

このような PR を提出できますか?

  desc "enable_readonly", "Enable the readonly mode, allowing staff writes"
  def staff_writes_only
    load_rails

    Discourse.enable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY)
    puts 'The site is now in readonly mode with staff writes permitted.'
  end

これにはあまり詳しくありませんが、enable_readonly_mode がサイトを staff_writes_only_mode に設定するのは混乱を招くと思います。これらは異なるモードであり、特定の操作を実行する際には、スタッフがデータベースへの書き込みを許可されないようにしたい場合があります(たとえば、復元中は削除されます)。

代わりに、ここでいくつかのことを行うことができるかもしれません。

  1. リードオンリーモードがそのタスクの説明にTTLを設定することを明確にする
  2. keep_readonly_mode を呼び出すタスクを追加して、60分以上に延長できるようにする
  3. enable_staff_writes_only および disable_staff_writes_only タスクを追加する
「いいね!」 2

同意しますが、「しばらくの間読み取り専用モードを設定する」よりはるかに混乱が少ないでしょう。

復元スクリプト自体が読み取り専用モードを設定するため、このコマンドの影響を受けないと思います。

設定されたときにX分間設定されていることを宣言する方が良いでしょう。説明を見つけるのはそれほど簡単ではありません。

たぶん。誰がそれを使用するのかはっきりしません。

それは素晴らしいでしょう!

また、rakeタスクとdiscourseコマンドから利用可能なコマンドを混同していないことを明確にする必要があります。

「いいね!」 2

なるほど。これをPRとして提出する可能性はありますか? enable_staff_writes_only および disable_staff_writes_only コマンドについても、可能であれば同様にお願いします。ありがとうございます!

「いいね!」 3

読み取り専用を開始した後、どのクロックが停止するのか知りたいのですが?読み取り専用を設定した後、トピックのバンプは発生しますか?

Web UIで読み取り専用モードが設定されている場合、アップデートも動作しないようです。

UIが更新されたようですが、管理バックアップセクションで読み取り専用モードを無効にするオプションが表示されません。UIからこれを無効にするにはどうすればよいでしょうか?

それは不思議ですね。有効化と無効化のボタンが表示されており、正常に動作しているようです。表示されている画面のスクリーンショットを送っていただけますか?

@Lucian_Chung さん、こんにちは。

また、お使いのサイトがセルフホスティングか、Discourse によるホスティングか、後者の場合はどのプランかについても明記してください。ホスト型サイトでは、一部の条件下では UI から読み取り専用モードを無効化することはできません。