안녕하세요,
저는 R-Pi 4에 Discourse와 Cloudflared를 설치했고, 원래 게시물의 지침을 따랐습니다. 그런데 Discourse의 호스트에 무엇을 입력해야 할지 모르겠습니다. cloudflared 터널이 전달해 주니까 그냥 localhost를 입력하면 될까요?
아마 @Falco 님이 도와주실 수 있지 않을까요?
참고로, 기존 게시물을 다시 올린 점 죄송합니다.
2개의 좋아요
이 가이드를 위해 도메인을 소유하고 있어야 하므로, host 값은 Discourse와 터널에 설정한 도메인 아펙스 또는 서브도메인이 됩니다.
2개의 좋아요
즉, 호스트 값에는 Discourse를 배치하려는 서브도메인을 입력해야 한다는 뜻인가요?
2개의 좋아요
네, Discourse가 설치될 URL이어야 합니다.
3개의 좋아요
정말 괜찮으신가요?
그렇게 하면 다음과 같은 오류가 발생합니다:
제가 뭔가 잘못한 것 같으신가요?
Discourse 호스트명을 Discourse를 설치하려는 정확한 서브도메인으로 설정했습니다.
R-Pi4에서 CLI를 통해 Cloudflared를 설치했습니다(여기에 적힌 대로: Set up your first tunnel · Cloudflare One docs) 그리고 서비스로 실행하고 있습니다.
그리고 저는 꽤 확신하지만, 원본 게시물에 언급된 대로 Discourse를 설치했습니다.
2개의 좋아요
도메인을 공유해 주시겠어요?
DM으로 보내도 될까요? 아무한테나 보여지는 건 좀 꺼려져서요.
1개의 좋아요
올바른 도메인을 설정했으니 이제 작동하나요?
2개의 좋아요
네! 이제 부팅이 됐어요! 도움 주셔서 감사합니다! 다만 STMP에서 사용 중인 메일 제공업체인 MailJet에서 문제가 있어요. 인증 이메일을 사전에 차단하고 있더라고요..
2개의 좋아요
게시물이 기존 주제에 병합되었습니다: MailJet의 대안은 없나요?
안녕하세요, 드디어 정상적으로 설치하는 데 성공했어요! 작은 질문이 하나 있는데, 4GB RAM을 탑재한 R-Pi 4 Model B가 얼마나 많은 활동량과 회원 수를 감당할 수 있다고 생각하세요?
2개의 좋아요
좋은 질문입니다. Discourse와 같은 복잡한 시스템에서는 사용자 수와 서버 부하 간의 직접적인 상관관계를 파악하기 어렵기 때문에, RaspberryPi 시스템의 주요 병목 현상이 저장소 IOPS에 있다는 점을 인정하는 것이 타당합니다.
따라서 필요한 리소스의 대부분이 프로세스 RSS와 Linux 캐싱을 포함한 RAM에 있다면 매끄러운 경험을 누릴 수 있을 것입니다. Cloudflare가 캐싱 CDN 역할을 한다는 사실도 상당한 도움이 되며, 시간이 지나면 업로드용 객체 스토리지 사용 (S3 & 클론)을 활용하여 Pi 환경의 수명을 더 오래 유지할 수도 있습니다.
6개의 좋아요
docker의 일부에서 이 오류가 발생했습니다
FAILED
--------------------
Pups::ExecError: /usr/local/bin/ruby -e 'if ENV["DISCOURSE_HOSTNAME"] == "discourse.example.com"; puts "Aborting! Domain is not configured!"; exit 1; end' failed with return #<Process::Status: pid 115 exit 1>
Location of failure: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params "/usr/local/bin/ruby -e 'if ENV[\"DISCOURSE_HOSTNAME\"] == \"discourse.example.com\"; puts \"Aborting! Domain is not configured!\"; exit 1; end'"
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
9ba0db264ae559f3f748cc1e42a8683ea0b4e355b0d45da0f472afea7ff7c472
이는 도메인이 올바르게 설정되어 있지 않다는 뜻입니다. 이 기능이 작동하려면 유효한 도메인이 필요합니다. ./discourse-setup을 다시 실행하거나 app.yml 파일을 편집하여 수정하세요.
1개의 좋아요
답장 감사합니다.
RockPi4에 성공적으로 배포했습니다. 
3개의 좋아요
@Falco 님,
가이드대로 설정한 것 같은데, 뭔가 이상한 점을 발견했어요.
컨테이너 설정에서 SSL 템플릿을 로드하지 않고 있고, DISCOURSE_FORCE_HTTPS 환경 변수를 true로 설정해 두었습니다. 이 변수가 정확히 무엇을 하는지 모르겠지만, SiteSetting.force_https를 true로 설정하고 관리 대시보드에서 비활성화되지 않도록 숨기는 역할을 할 것 같다는 추측을 하고 있습니다.
제 CF(Cloudflare) 터널 설정은 다음과 같습니다:
ingress:
- hostname: dc.example.com
service: http://dc:80 # dc는 제 discourse 스탠드얼론 앱 컨테이너 이름입니다
문제는, http://dc.example.com을 방문하면 https로 리다이렉트되지 않는다는 것입니다. 이것이 예상되는 동작인가요?
재현해 볼 수 있을까요? 버그인 것 같기도 해서요.
관련된 CF 설정은 다음과 같습니다:
- SSL/TLS > 개요 > SSL/TLS 암호화 모드: full (full (strict)가 아님)
- SSL/TLS > 엣지 인증서 > 항상 HTTPS 사용: off
CF에서 리다이렉트를 수행할 수 있다는 것(Always Use HTTPS 또는 일괄 리다이렉트 규칙 사용)은 알고 있지만, force_https가 켜져 있다면 discourse가 이를 처리하여 모든 내부 URI를 리다이렉트할 것이라고 생각했습니다. 의견 주실 수 있을까요?
리다이렉트 문제를 무시하더라도, DISCOURSE_FORCE_HTTPS나 SiteSetting.force_https의 값과 관계없이 https://dc.example.com을 탐색하는 것은 정상적으로 작동합니다.
수정: force_https가 실제로 우리에게 무엇을 해주는지 이해하지 못하고 있는 상태에서 (아마도 SSL 템플릿이 포함되지 않으면 아무것도 하지 않는 걸까요?), 터널 설정이 그대로라면 discourse가 실제로 모든 것을 https로 리다이렉트하는 경우 터널 설정이 작동하지 않을 것 같다는 생각이 들었습니다. 그렇게 되면 argotunnel이 http(예: service: http://dc:80)로 discourse에 접근할 수 없으므로, 아마도 다음 중 하나를 해야 할 것 같습니다:
- 리다이렉트는 CF에 맡기거나
- discourse가 인증서를 사용하고 cloudflared가 https로 discourse 오리지널 서버에 접근하도록 설정하기 (
service: https://dc:443)
어쨌든, 이 사항을 고려하여 argotunnel 가이드를 업데이트할 수 있을까요?
2개의 좋아요
아, 맞습니다. 제 테스트 TLD인 .dev가 HTTPS 전용이라는 걸 놓치고 있었네요:
이 문제를 해결하기 위해 페이지 규칙을 사용하라고 가이드를 업데이트했습니다. 알려주셔서 감사합니다!
3개의 좋아요
하지만 질문이 있습니다.
Consolidated Pageviewshow에서 익명 조회 수가 높게 나타나고 있는데, 이는 DDoS 공격 때문이라고 생각합니다. 서버 CPU 사용률이 60%까지 올라갔고 크롤러는 아주 적은 수준이거든요. DDoS 공격으로부터 보호하려면 어떻게 해야 할까요? 답변 미리 감사합니다.
1개의 좋아요
cloudflared/argotunnel과 별개로 Cloudflare를 리버스 프록시로 사용하면, 기본적으로 ddos 보호 기능을 활용할 수 있습니다. DNS 레코드에서 ‘오렌지 구름’ 아이콘을 활성화하면 됩니다.
1개의 좋아요