Discourse의 읽기 전용 모드

:bookmark: 이 가이드에서는 Discourse에서 사용할 수 있는 다양한 읽기 전용(Read-Only) 모드, 각 모드를 활성화 및 비활성화하는 방법, 그리고 각 모드를 사용해야 하는 시나리오에 대해 설명합니다.

:person_raising_hand: 필요한 사용자 권한: 관리자

Discourse에서 활기찬 온라인 커뮤니티를 관리하다 보면 관리자가 사용자 활동을 일시적으로 제한해야 하는 경우가 있습니다. 이러한 상황은 서버 유지보수, 백업 처리, 서버 이전 등 다양한 형태로 발생할 수 있습니다. 이러한 시기에 사용자 접근을 완전히 차단하지 않으면서도 포럼 활동을 제한하는 것이 중요합니다.

Discourse는 사이트 내에서 다양한 유형의 상호작용을 일시적으로 동결할 수 있도록 관리자가 활성화할 수 있는 다양한 읽기 전용(Read-Only) 모드를 제공합니다.

이 가이드에서는 이러한 모드, 특히 활성화 및 비활성화 방법과 특정 모드가 겹치는 상황을 처리하는 방법에 초점을 맞추어 살펴봅니다.

읽기 전용 모드 이해하기

Discourse는 다양한 관리 요구 사항에 부합하도록 두 가지 다른 수준의 읽기 전용 모드를 지원합니다. 다음과 같습니다:

  1. 전체 읽기 전용 모드 (Full Read Only-Mode)
  • 포럼의 모든 쓰기 작업을 제한하여 사용자가 게시, 댓글, 좋아요와 같은 콘텐츠 생성 또는 수정을 방지합니다.
  • 포럼이 현재 상태로 사실상 "동결"되도록 하여, 사용자는 데이터베이스에 영향을 주지 않고 기존 콘텐츠를 읽거나 탐색할 수 있습니다.
  • 데이터베이스의 현재 상태를 보존하기 위해 관리자 사이트 설정 또는 사이트 사용자 정의 변경을 비활성화합니다.
  • 일반 사용자의 새 포럼 로그인을 비활성화합니다. 관리자는 관리자 이메일 로그인 플로우(/u/admin-login)를 사용하여 여전히 로그인할 수 있습니다.
  • API 호출은 읽기(GET)는 가능하지만, 쓰기(POST/PUT/DELETE)는 불가능합니다.
  • 대기 중인 발신 웹훅은 전달되지만, 웹훅을 트리거하는 작업이 차단되므로 새 웹훅은 트리거되지 않습니다.
  • 수신 웹훅(이메일 바운스)은 503 응답으로 차단됩니다. 이메일 제공업체는 자체 백오프 스케줄에 따라 재시도합니다.
  1. 스태프 쓰기 전용 모드 (Staff Writes Only-Mode)
  • 일반 사용자의 포럼 내 쓰기 작업(게시, 댓글, 좋아요 등)을 제한합니다. 비스태프 사용자는 읽기 전용 작업으로 제한되지만, 여전히 계정에 로그인할 수 있습니다.
  • 관리자 및 모더레이터의 활동이 정상적으로 계속되도록 허용합니다. 관리자는 사이트 설정을 변경할 수 있고, 스태프 사용자는 게시, 좋아요, 프로필 수정과 같은 쓰기 작업을 수행할 수 있습니다.
  • API 호출은 읽기(GET)가 가능합니다. 스태프 API 키만 쓰기(POST/PUT/DELETE)를 수행할 수 있습니다.
  • 대기 중인 발신 웹훅은 전달됩니다. 스태프의 작업은 새 발신 웹훅을 트리거할 수 있으며 이는 성공적으로 처리되지만, 비스태프 사용자의 작업은 웹훅을 트리거하지 않습니다.
  • 수신 웹훅(이메일 바운스)은 503 응답으로 차단됩니다. 이메일 제공업체는 자체 백오프 스케줄에 따라 재시도합니다.

이러한 모드는 중요한 관리 기간 동안 포럼의 운영 유연성을 보장합니다.

읽기 전용 모드 활성화/비활성화 방법

:warning: 관리자는 다른 읽기 전용 모드 간의 전환을 신중하게 관리해야 합니다. 어떤 읽기 전용 모드를 활성화하기 전에 이전에 활성화된 모드가 비활성화되었는지 확인하십시오.

전체 읽기 전용 모드

Rails 콘솔을 통한 방법

Discourse 설치 환경에 접근 권한이 있다면, Docker 컨테이너에 ./launcher enter app 명령으로 진입한 후 rails c 명령으로 Rails 콘솔을 열고 다음 명령을 실행하십시오:

Discourse.enable_readonly_mode(Discourse::USER_READONLY_MODE_KEY)

관리자 패널을 통한 방법

웹 인터페이스를 통해 관리자 접근 권한이 있다면, 관리자(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)

모범 사례

  • 적시 소통: 적절한 기대치를 설정하기 위해 계획된 읽기 전용 기간에 대해 커뮤니티에 사전에 알리십시오.
  • 테스트: 이러한 모드를 중요한 작업 중에 구현하기 전에, 그 영향을 이해하기 위해 트래픽이 적은 시간에 테스트를 수행하십시오.
  • 문서화: 향후 운영 계획 수립을 돕기 위해 각 모드가 언제, 왜 활성화 또는 비활성화되었는지에 대한 상세한 기록을 유지하십시오.

자주 묻는 질문 (FAQ)

  • 읽기 전용 모드를 활성화/비활성화하는 데 얼마나 걸립니까?

    • 변경 사항은 즉시 적용됩니다. 그러나 전환 기간 동안의 사용자 행동에 따라 사용자 경험이 약간 달라질 수 있습니다.
  • 도움말! 읽기 전용 모드 때문에 제 사이트에 잠금이 걸렸습니다 - 사이트를 다시 접근하려면 어떻게 해야 합니까?

  • discourse/lib/discourse.rb에 나열된 다른 READ-ONLY 모드가 있는 것을 확인했습니다. 이 모드들은 무엇을 하는 것입니까?

    • READONLY_MODE_KEY는 주로 백업 및 복원 프로세스에 사용되며 애플리케이션 자체에 의해 트리거됩니다. 이 모드는 discourse enable_readonlydiscourse disable_readonly 명령으로 Discourse 커맨드 라인 인터페이스에서도 활성화 또는 비활성화할 수 있습니다. 그러나 이 키는 컨테이너 재시작 후에도 유지되지 않습니다.
    • USER_READONLY_MODE_KEY는 관리자가 관리자 인터페이스에서 읽기 전용 버튼을 클릭할 때 사용됩니다. 이 키의 특별한 점은 사용자가 활성화한 읽기 전용 모드가 컨테이너 재시작 후에도 유지되어야 하므로 만료되는 키로 설정하지 않는다는 것입니다. 다른 키들은 TTL(READONLY_MODE_KEY는 60초, PG_READONLY_MODE_KEY는 300초)과 함께 설정되며, 애플리케이션이 읽기 전용 모드에 영원히 갇히지 않도록 30초마다 만료 기간을 연장하는 스레드가 있습니다.
    • PG_READONLY_MODE_KEYPG_FORCE_READONLY_MODE_KEY는 PG 페일오버에 사용됩니다. 전자는 만료되는 키로 설정되고, 후자는 만료되지 않는 키로 설정됩니다.
9개의 좋아요

I can’t see a difference! Could these descriptions be tweaked accordingly, if indeed there is a difference?

1개의 좋아요

I’ve updated the guide to provide some additional clarity here, please let us know if you still have any questions about any of the read-only modes. :slightly_smiling_face:

1개의 좋아요

But what does

discourse enable_readonly do?

It uses READONLY_MODE_KEY, which sets that ttl to 60, so it turns back off at some point. Now I see that

Is there some reason that this is the default behavior for this command? It’s taken me nearly a decade to learn that this command is totally different from the web interface readonly mode even after being burned a bunch of times. And I now remember that someone tried to tell me about these keys once and I failed to understand their significance.

IMHO a much more sane thing for discourse enable_readonly to do would be to do a Discourse.enable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY). I wish I’d noticed that many years ago!

Could I submit a PR something like this:

  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

I’m not too familiar with this, but I think it would be confusing for enable_readonly_mode to set the site to a staff_writes_only_mode. They are different modes, when doing certain operations, you’d want staff to not be allowed writes on the DB (during a restore, for example, they’ll get removed).

Maybe instead we can do a few other things here:

  1. clarify that the readonly moed sets a TTL in that task’s description
  2. add a task that invokes keep_readonly_mode so it can be extended to more than 60 mins
  3. add enable_staff_writes_only and disable_staff_writes_only tasks
2개의 좋아요

I would agree, but it would be much less confusing than “set read only mode for a while”.

I’m pretty sure that the restore script sets read-only mode itself, so it’s not affected by this command.

I’d rather it proclaim that it is set for X minutes when it’s set. It’s not that easy to find the description.

Perhaps. I’m not clear who would use it.

That would be great!

Also, we need to be clear that we’re not conflating the rake tasks with the commands available through the discourse command.

2개의 좋아요

Makes sense. Any chance you can submit this as a PR? Same for the enable_staff_writes_only and disable_staff_writes_only commands, if possible. Thanks!

3개의 좋아요

I’m curious which clocks’ stop after starting read-only? will topic bumps happen after setting read-only?

it also looks like updates don’t work if read only mode is set by the web UI

UI가 업데이트된 것 같아 관리자 백업 섹션에서 읽기 전용 모드를 비활성화하는 옵션을 찾을 수 없습니다. UI를 통해 이 기능을 비활성화하는 방법은 무엇인가요?

이상하네요. 활성화와 비활성화 버튼을 볼 수 있고, 정상적으로 작동하는 것 같습니다. 현재 보이는 화면의 스크린샷을 보내주실 수 있을까요?

안녕하세요 @Lucian_Chung님,

자신의 사이트가 자체 호스팅인지, 아니면 Discourse에서 호스팅되는지, 후자인 경우 어떤 플랜인지도 함께 알려 주세요. 호스팅 사이트의 경우 특정 조건에서는 UI에서 읽기 전용 모드를 비활성화할 수 없습니다.