Crius
(Crius)
8월 9, 2024, 1:33오후
1
Discourse 버전: 3.4.0.beta1-dev (bf3d8a0a94 )
어제 업데이트를 수행했으며, 여기서 제안된 대로 Cloudflare의 minify 기능을 비활성화해야 했습니다:
Cloudflare의 ‘Auto Minify’ 기능은 최신 버전의 Discourse를 깨뜨릴 수 있습니다. 브라우저 콘솔에서 다음과 같은 오류가 표시됩니다:
Uncaught SyntaxError: Unexpected identifier '#...'
Cloudflare은 이 문제를 인지하고 있으며, 대시보드에 다음과 같은 메시지를 추가했습니다:
참고: 이 기능은 특정 새로운 CSS 및 JS 언어 기능과 완전히 호환되지 않을 수 있으며, 이는 사이트의 기능에 영향을 미칠 수 있습니다.
불행히도, 이 심각한 문제에도 불구하고 기존 사이트의 경우 2024-08-05까지 해당 기능이 활성화된 상태로 유지될 예정입니다. 8월 20일 업데이트: 해당 기능은 여전히 유지되고 있으며, '곧 제거될 예정’이라고 표시되어 있습니다.
이 Cloudflare 기능을 비활성화하고 Discourse 사이트의 기능을 복원하려면 다음을 수행해야 합니다:
Cloudflare 설정의 ‘Content…
그러나 그 이후로 많은 사용자들(저를 포함하여)이 502 (Bad Gateway) 및 529 (Too Many Requests) 오류를 여러 번 경험했습니다.
문제를 완화하기 위해 다음 가이드도 따랐습니다:
Cloudflare를 사용한 Discourse 설정
이 가이드는 Cloudflare를 사용하여 Discourse를 구성하는 방법, 보안 모범 사례 및 문제 해결 팁을 설명합니다.
필요한 사용자 권한: 관리자
자체 호스팅 설치 환경에서는 콘솔 접근 권한이 필요합니다
요약
Cloudflare는 CDN을 통한 성능 향상, DDoS 보호와 같은 추가 보안 계층, 그리고 HTTPS 지원으로 Discourse 인스턴스를 강화할 수 있습니다. 이 가이드는 최적의 구성을 위한 설정 과정과 모범 사례를 다룹니다.
왜 Discourse에 Cloudflare를 사용해야 하는가
Discourse 인스턴스에 Cloudflare를 사용하면 다음과 같은 주요 이점이 있습니다:
성능: Cloudflare의 CDN은 일반 자산에 대한 전 세계 접근성을 향상시켜 전역적으로 사용자 경험을 개선합니다 (출처 )
…
그러나 이러한 오류의 빈도 측면에서는 아무것도 변한 것 같지 않습니다.
업데이트는 어제 오전 11시경에 수행되었습니다. 플러그인 하나를 비활성화하고 싶었기 때문에 전체 재빌드(full rebuild)를 수행했습니다.
서버와 discourse를 모니터링하는 Prometheus+Grafana 인스턴스가 있지만, 서버는 부하 측면에서 정상적으로 보입니다:
Discourse 지표 (어제 오전 11시경 지표의 하락은 컨테이너를 중단시킨 재빌드 때문입니다):
다시 말하지만, 이상한 패턴은 보이지 않습니다.
그러나 이것이 바로 방금 사용자에게 개인 메시지를 보내려 시도한 후의 브라우저 콘솔입니다:
제공할 수 있는 다른 것(모든 종류의 로그 등)이 있다면 언제든 요청해 주세요. 감사합니다.
Crius
(Crius)
8월 9, 2024, 1:37오후
2
아, 도움이 된다면 말씀드리자면, 수많은 “백그라운드” 실시간 작업들도 분명히 지연되고 있습니다.
예를 들어, 이미 읽은 주제들이 읽음으로 등록되지 않는 경우가 있습니다.
Firepup650
(Firepup Sixfifty)
8월 9, 2024, 1:40오후
3
확인을 위해, 해당 단계를 수행한 후 다시 빌드했죠?
Crius
(Crius)
8월 9, 2024, 4:03오후
4
네, 죄송합니다. 깜빡해서 못 적었네요. 사실 저는 이미 오래전에 app.yml 파일에 Cloudflare 템플릿을 추가해 두었습니다. 우리는 처음부터 Cloudflare 뒤에서 운영해 왔습니다.
다음은 app.yml의 일부입니다. 우리는 letsencrypt 대신 자체 인증서를 독립적으로 갱신하고 있기 때문에 letsencrypt 항목은 주석 처리되어 있습니다:
## this is the all-in-one, standalone Discourse Docker container template
##
## After making changes to this file, you MUST rebuild
## /var/discourse/launcher rebuild app
##
## BE *VERY* CAREFUL WHEN EDITING!
## YAML FILES ARE SUPER SUPER SENSITIVE TO MISTAKES IN WHITESPACE OR ALIGNMENT!
## visit http://www.yamllint.com/ to validate this file as needed
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Uncomment these two lines if you wish to add Lets Encrypt (https)
- "templates/web.ssl.template.yml"
# - "templates/web.letsencrypt.ssl.template.yml"
- "templates/cloudflare.template.yml"
## which TCP/IP ports should this container expose?
## If you want Discourse to share a port with another webserver like Apache or nginx,
## see https://meta.discourse.org/t/17247 for details
expose:
- "80:80" # http
- "443:443" # https
[...]
Crius
(Crius)
8월 9, 2024, 6:30오후
6
이 내용이 #installation 채널로 이동된 것을 확인했습니다. 명확히 하자면, 이것은 새로운 설치가 아닙니다.
이 Discourse 인스턴스는 2023년 3월부터 실행되어 왔으며, 이 특정 문제는 발생한 적이 없습니다.
과거에 529와 관련된 문제가 있었으나, 이미 해결되었습니다.
Falco
(Falco)
8월 9, 2024, 8:18오후
8
PostgreSQL이 과부하 상태인 것 같습니다. RAM 대부분이 유휴 상태인 것으로 보이므로, 데이터베이스를 조정해 RAM을 활용하도록 해보고 그 후 상황을 확인해 보세요.
RGJ
(Richard - Communiteq)
8월 9, 2024, 10:43오후
9
/sidekiq/queues는 어떤 모습인가요?
어떤 버전에서 업데이트하고 있나요?
Crius
(Crius)
8월 10, 2024, 12:16오전
10
5월 6일 최신 안정판인 v3.2.1 부터 최신 test-passed까지.
Sidekiq 큐:
Dead job 섹션은 아래 그림과 같으며, 처음부터 동일한 작업인 것 같습니다.
가장 오래된 항목들:
retry에 있는 항목들은 동일한 작업이 반복적으로 재시도되고 있는 것 같습니다.
Crius
(Crius)
8월 10, 2024, 12:18오전
11
하지만… 갑자기 왜 그런 걸까요? 애플리케이션 레이어만 업데이트했을 뿐인데?
저는 discourse prometheus exporter 플러그인을 사용하고 있습니다.
VM에 postgresql exporter를 컨테이너로 추가한다면, discourse postgresql 설치 환경의 메트릭스에 접근할 수 있을까요?
Crius
(Crius)
8월 11, 2024, 11:59오후
12
디스코스의 DB를 미세 조정하는 방법에 대해 더 구체적인 방향을 알려줄 수 있을까요?
Crius
(Crius)
8월 12, 2024, 1:52오후
13
관련이 있는지 확실하지는 않지만, 업데이트 이후에 이런 현상이 발생하기 시작했습니다. 읽지 않은 탭에서 닫기 버튼을 클릭하면 항상 503 오류가 반환됩니다.
Crius
(Crius)
8월 13, 2024, 8:12오전
14
음, 해결책이 없는 것 같으니, stable 버전이 원래… 아시다시피, 안정적 이어야 하니까 최신 stable 버전으로 돌아가는 걸 시도해 볼게요.
지난번처럼 빌드 프로세스를 깨뜨리는 핵심 의존성이 없기를 두 손 모아 빌어봅니다.
RGJ
(Richard - Communiteq)
8월 13, 2024, 8:43오전
15
더 높은 stable 버전이 사용 가능한 경우를 제외하고는, 테스트 통과(tests-passed) 상태에서는 stable로 되돌아갈 수 없습니다. 따라서 다음 기회는 3.4.0이 출시될 때일 텐데, 제 생각에는 크리스마스 전후쯤이 될 것 같습니다…
어쨌든, 언젠가는 이를 감수해야 합니다.
Crius
(Crius)
8월 13, 2024, 8:53오전
16
음, 방금 해봤습니다. 작동하는 것 같습니다. 어쨌든 3.3.0의 어떤 기능도 우리가 신경 쓸 부분이 아니에요.
여전히 문제가 있는지 확인해 보겠습니다. 상황이 나빠진다 해도 여전히 429와 502 에러가 쏟아지는 수준이겠죠, 큰 변화는 아닙니다.
다만, discourse의 Postgres를 더 많은 리소스를 사용할 수 있도록 구성하는 방법에 대한 안내는 감사히 받을 수 있을 것 같습니다.
수정: 3.2.5 버전을 배포했습니다. 시스템이 안정적으로 보입니다.
RGJ
(Richard - Communiteq)
8월 13, 2024, 8:54오전
17
다음 이슈를 등록할 때 이 작업을 했다고 다시 한번 알려주세요
Crius
(Crius)
8월 13, 2024, 8:59오전
18
Richard - Communiteq:
테스트 통과(tests-passed) 버전에서 안정적(stable) 버전으로 되돌아갈 수는 없으며, 더 높은 안정적 버전이 존재하는 경우에만 가능합니다. 따라서 다음 기회는 3.4.0이 출시될 때일 텐데, 아마 크리스마스 무렵이거나 그 이후가 될 것 같습니다.
그리고 언젠가는 이 힘든 과정을 감수해야 할 것입니다.
이슈를 게시할 때 항상 현재 사용 중인 버전을 명시합니다.
이것이 오픈 소스 소프트웨어로 제공되고 있다는 점을 정확히 기억하는 것이 중요하다고 생각합니다. 따라서 다음과 같은 글을 쓰는 대신, 중요한 이슈를 고려해야 합니다:
이것은 사람들이 애써서 “안정적(stable)” 버전으로 전환한 후, 가장 인기 있는 배포 버전이 아니기 때문에 간과되는 버그에 직면하는 또 다른 사례입니다.
stable은 "안정적"을 의미해야 하며, "레거시(구식)"를 의미해서는 안 됩니다.
discourse docker와 같은 핵심 의존성이 태그 시스템 없이 배포되는 사실만으로도, 이슈를 보고하는 사용자에게 응답할 때 좀 더 겸손한 자세를 취하는 것이 마땅합니다.
RGJ
(Richard - Communiteq)
8월 13, 2024, 9:03오전
19
제가 말한 것은 기술적으로 다운그레이드가 불가능한 상황에서 다운그레이드를 했다는 사실을 언급하라는 것이었습니다.
다음 점을 기억하는 것이 중요하다고 생각합니다… 저는 Discourse에서 일하지 않으며, 제 개인 시간을 내어 여러분을 돕고 있다는 것입니다. 따라서 여러분의 톤은 좋아하지 않으며, 여러분의 피드백에 대해 제가 할 수 있는 일도 없습니다.