맞아요. 그게 말이 되네요. 그리고 저는 Mailgun을 사용하는 게 괜찮을 것 같아요.
멀티사이트를 설정하기 시작하면 이 모든 걸 더 잘 이해하게 될 거예요!
@alltiagocom 님과 비슷한 상황이라 끼어들어 봅니다. 저는 메인 커뮤니티용으로 Hetzner의 작은 서버에 Discourse를 설치해 두고 있지만, 사용법을 익히면 몇몇 Facebook 그룹을 Discourse로 이전하는 것을 배경에서 계속 고민하고 있습니다.
저는 « Wordpress multisite »에는 익숙하지만, Discourse 멀티사이트는 더 복잡한 과정이 필요하다는 걸 이해하고 있습니다. 두 개 이상의 독립 사이트를 운영하거나 멀티사이트를 사용하는 것 중 어느 쪽이 더 수고롭지 않을지 궁금합니다.
이 부분에 대한 조언을 주실 수 있을까요?
멀티사이트는 확실히 유지보수 부담이 적어 두통이 줄어들겠지만, 사용자마다 결과는 다를 수 있습니다.
디스커스 초보자를 위해 두 개의 사이트만 실행하는 것을 권장합니다.
리버스 프록시 없이 멀티사이트를 실행하는 방법에 대한 주제를 만들었지만, 지금은 내용이 구식이 되었습니다.
변경해야 하는 것은 다음 부분이라고 생각합니다.
위 내용을 아래 새로운 설정으로 대체할 수 있습니다.
DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com
제가 드리고 싶은 의견입니다. 하루 종일 제 오래된 노트, ChatGPT, Claude, Discourse AI 봇, 그리고 여기서 공유된 몇 가지 토픽의 도움을 받아 이 문제를 해결하기 위해 노력했고(전체 과정에 대해 메모를 계속 남기면서) 그 결과입니다.
리버스 프록시를 추가해야 하는 지점에 도달할 때까지 모든 것이 정상적으로 작동하는 것 같았습니다. 정상적으로 작동하고 있던 제 첫 번째 인스턴스가 갑자기 작동하지 않았습니다. Discourse AI 봇에 몇 가지 질문을 더 했지만, 제 가입 첫날이라 봇이 더 이상 작동하지 않았습니다. 이는 봇의 신규 사용자에게 부과되는 제한 사항입니다. 매우 도움을 주었던 Claude도 제가 무료 버전을 사용 중이라 더 이상 응답하지 않았습니다. ChatGPT는 모든 도구 중 가장 신뢰성이 떨어지므로, 그 답변은 항상 상당한 의심을 가지고 받아들이게 됩니다…
그리고 다시 포럼에 와서 관련 토픽을 읽기 시작했고, 그중 일부는 @pfaffman님이 작성한 것이었습니다. 그게 결정적이었습니다. 너무 복잡했고, 제가 무엇을 질문해야 할지 이해하기에도 너무 많은 기술 용어가 사용되어 있었습니다.
요약하면: 제 첫 번째 인스턴스는 작동하고 있으므로, 변경하기 전의 상태로 되돌리기로 했습니다(app.yml 파일을 변경 전 상태로 편집 중입니다. 이 글을 쓰는 동안 재구축이 진행되고 있습니다).
솔직히 말해서, 첫 번째 큰 장벽을 넘기만 하면 더 많은 커뮤니티를 추가할 수 있는 잠재력이 있지만, 월 4달러를 아끼기 위해 이 모든 복잡성을 감수할 가치가 있는지 의문입니다. Hetzner에서 서버를 설정하고 Discourse를 설치하는 방법을 이미 알고 있으므로, 지금은 2개의 커뮤니티에 집중하고 월 8달러를 지불한 뒤 다른 일을 하기로 했습니다. 몇 달 전 Digital Ocean에서 드롭렛 하나에 12달러를 지불했던 것을 고려하면, 원한다면 3개의 커뮤니티에 같은 금액을 지불하는 노력도 감당할 수 있습니다.
어쨌든, 저는 이런 모험이 항상 흥미롭다고 생각합니다. 과정에서 새로운 것을 배우게 되니까요. 결국, 단순히 "할 수 있을지 모르겠으니 안 하겠다"고 말하는 대신, 왜 하고 싶지 않은지 설명할 수 있게 되었기 때문입니다.
여기서 시간을 내어 도움을 주신 모든 분들께 감사드립니다. 그리고 이 토픽이 저처럼 같은 것을 시도하고자 하는 다른 분들에게 도움이 되기를 바랍니다.
끝!
제가 말한 이유가 바로 이겁니다. 전략을 다시 생각해봐야 해요. 당신이 이루려 했던 것은 불가능한 것은 아니에요. 이전에 누군가가 해낸 적이 있으니까요. 하지만 이를 제대로 해내려면 담론에 대한 상당한 이해가 필요합니다.
담론이 어떻게 작동하는지 더 알고 싶다면, 여가 시간에 계속 실험해 보시길 추천합니다. 여기 있는 우리 대부분이 그렇게 배웠거든요.
(대부분) 이해하는 데까지 제가 인정하기 싫을 정도로 오랜 시간이 걸렸습니다!
저는 지원되는 Discourse 멀티사이트 설치를 **명령어 단위 런북(command-by-command runbook)**으로 문서화하고 있습니다.
이전에 “하나의 서버에 여러 개의 독립적인 설치” 방식을 실험해 보았지만, 해당 구성은 지원되지 않습니다. 이 게시물은 지원되는 멀티사이트 아키텍처에만 초점을 맞추며, 명시적인 단계를 선호하는 사람들을 위해 선형 형식으로 재작성되었습니다.
이 구성이 무엇인지 (지원됨)
- 하나의 Discourse 앱 컨테이너 (
app) multisite.yml을 통해 활성화된 멀티사이트- 공유 Postgres + Redis (Discourse에서 관리)
- **유닉스 소켓(unix sockets)**을 통한 연결 (Docker 네트워크 불필요)
- 여러 호스트네임이 내부적으로 개별 사이트로 라우팅됨
이 구성이 아닌 것
- HAProxy 뒤의 여러 독립적인 Discourse 컨테이너
- 앱 노드를 드레인(drain)하여 수행하는 롤링 리빌드(rolling rebuilds)
- 사이트별 SMTP 자격 증명 (SMTP는 공유됨)
운영 참고 사항 (기대치 설정을 위해)
리빌드 / 다운타임
멀티사이트 환경에는 앱 컨테이너가 하나만 있으므로, ./launcher rebuild app은 유일한 노드를 재시작합니다. 즉, 모든 사이트에서 짧은 다운타임이 발생할 것으로 예상됩니다.
인증서 / 호스트 검증
Let’s Encrypt와 호스트 검증이 안정적으로 작동하도록 모든 호스트네임을 DISCOURSE_HOSTNAME_ALIASES에 추가하세요.
백업 / 향후 마이그레이션
각 사이트는 /admin/backups에서 자체 백업을 생성합니다. 나중에 사이트 백업을 독립적인 설치(standalone install)로 복원하는 것이 일반적인 마이그레이션 경로입니다.
전체 지원되는 멀티사이트 런북 (명령어 단위)
0) 호스트 사전 요구 사항
| 단계 | 명령어 |
|---|---|
| 시스템 업데이트 | apt-get update && apt-get upgrade -y |
| 종속성 설치 | apt-get install -y git curl sudo |
1) Discourse Docker 설치
| 단계 | 명령어 |
|---|---|
| 리포지토리 클론 | git clone https://github.com/discourse/discourse_docker.git /var/discourse |
| 디렉터리 진입 | cd /var/discourse |
2) 첫 번째 사이트 설치 (먼저 단일 사이트로)
| 단계 | 명령어 |
|---|---|
| 설정 실행 | ./discourse-setup |
이 과정을 통해 /var/discourse/containers/app.yml이 생성되고 첫 번째 호스트네임(예: forum1.example.com)이 부팅됩니다.
3) 멀티사이트 활성화
| 단계 | 명령어 |
|---|---|
| 설정 디렉터리 생성 | mkdir -p /var/discourse/config |
| 멀티사이트 파일 편집 | nano /var/discourse/config/multisite.yml |
multisite.yml 예시:
forum1:
host_names:
- forum1.example.com
forum2:
host_names:
- forum2.example.com
4) app.yml 편집으로 멀티사이트 + 호스트네임 별칭 활성화
| 단계 | 명령어 |
|---|---|
| app.yml 편집 | nano /var/discourse/containers/app.yml |
다음 내용을 추가하세요:
DISCOURSE_MULTISITE: trueDISCOURSE_HOSTNAME_ALIASES: forum1.example.com,forum2.example.com
5) 리빌드
| 단계 | 명령어 |
|---|---|
| 리빌드 | ./launcher rebuild app |
6) 멀티사이트 DB 마이그레이션
| 단계 | 명령어 |
|---|---|
| 컨테이너 진입 | ./launcher enter app |
| 멀티사이트 마이그레이션 실행 | rails multisite:migrate |
| 종료 | exit |
| 단계 | 명령어 |
|---|---|
| 재시작 | ./launcher restart app |
7) 확인
다음 주소를 방문하세요:
https://forum1.example.comhttps://forum2.example.com
각 사이트에는 고유한 관리자, 사용자, 업로드 파일 및 백업이 있습니다.
8) 백업 / 향후 마이그레이션
사이트별 관리자:
/admin/backups
사이트를 자체 서버로 분리하고 싶다면 나중에 해당 백업을 독립적인 설치(standalone install)로 복원하면 됩니다.
위 내용 중 현재 모범 사례(best practice)와 충돌하는 부분이 있다면, 이 런북을 업데이트하는 데 기꺼이 응하겠습니다. 의도는 시도를 통해 배우는 과정(trial-and-error)을 줄이는 선형적인 지원되는 멀티사이트 체크리스트를 제공하는 것입니다.
와! 다중 사이트(multisite)라는 혼란스러운 세계에서 명확성을 얻기 위해 제가 필요로 했던 바로 그 명확한 가이드네요! 실제로는 생각했던 것보다 훨씬 실현 가능하고 훨씬 더 단순해 보입니다.
단일 컨테이너에서만 실행할 수 있다는 점은 다소 아쉬우지만, 왜 그렇게 해야 하는지 직관적으로 이해가 됩니다. 그 결과, 여러 개의 작고 조용한 셀프호스팅 포럼에 가장 적합할 것 같습니다.
귀하의 답변은 분명히 자체 (위키) 주제를 가질 자격이 있으며, 잘 안내되어 있어야 합니다.
나에게도 좋은 기회가 될 것 같아 
Discourse가 이미 « monosite »로 실행 중이고 이를 multisite로 전환하려는 경우에도 이 내용이 적용됩니까?
수고 많으셨습니다!
감사합니다! 이것은 여전히 현재 지원되는 멀티사이트 관행과 일치합니다. 여기에는 Discourse 멀티사이트의 현재 작동 방식과 충돌하는 내용이 없습니다.
네, 기존 monosite 설치를 multisite로 전환할 때도 동일한 단계가 적용됩니다. monosite은 기본적으로 단일 기본 사이트를 가진 multisite라고 볼 수 있습니다. DISCOURSE_MULTISITE를 활성화하고, multisite.yml을 추가(기존 사이트 포함)한 후, 한 번 재빌드하고, rails multisite:migrate를 제자리에서 실행하면 됩니다.
여기서 더 이상 모범 사례를 반영하지 못하는 부분이 있다면 런북을 업데이트하는 데 매우 기꺼이 협력하겠습니다. 목표는 시행착오를 피하는 선형적이고 지원되는 체크리스트를 제공하는 것입니다.
단일 컨테이너 discourse_docker 멀티사이트 환경에서 multisite.yml을 올바르게 제공해야 하는 방법에 대해 설명해 주실 분 계신가요?
위의 런북에서는 현재 다음과 같이 작성되어 있습니다:
mkdir -p /var/discourse/config
nano /var/discourse/config/multisite.yml
그러나 멀티사이트 문서에서는 app.yml의 before_bundle_exec 후크를 사용하여 다음 파일을 생성하는 방식을 사용합니다:
$home/config/multisite.yml
문서에는 이 후크가 Discourse 애플리케이션 내부에 해당 파일이 올바르게 배치되도록 보장한다고 명시되어 있습니다.
호스트의 /var/discourse/config/multisite.yml이 애플리케이션 컨테이너 내부의 /var/www/discourse/config/multisite.yml로 자동으로 마운트되거나 복사되는 과정을 확인할 수 없었습니다.
내부 PostgreSQL과 Redis를 사용하는 표준 올인원 app 컨테이너의 경우, 런북에서 호스트에 /var/discourse/config/multisite.yml을 직접 생성하는 것 대신 before_bundle_exec 후크를 사용해야 하는 것인가요?
기존의 라이브 단일 사이트 설치 환경에 적용하기 전에 런북을 올바르게 수정하고 싶습니다.
app.yml에 다음과 같은 내용을 추가해야 합니다.
- volume:
host: /var/discourse/shared/multi/multisite.yml
guest: /var/www/discourse/config/multisite.yml
감사합니다 - 호스트 측 파일에는 명시적인 볼륨 매핑이 필요하다는 것이 확인되었습니다.
런북을 수정하여 /var/discourse/shared/multi/multisite.yml를 /var/www/discourse/config/multisite.yml에 마운트하도록 변경할 수 없습니다.
PostgreSQL과 Redis가 Discourse 컨테이너 내부에서 관리되는 표준 올인원 app 컨테이너의 경우, multisite.yml 항목에 host_names만 포함되어 있으면 충분한가요, 아니면 각 사이트별로 database, username, host, pool, timeout과 같은 명시적인 값도 지정해야 하나요?
예를 들어, 두 번째 사이트를 생성하는 데 다음과 같은 설정이 유효한가요?
forum2:
host_names:
- forum2.example.com
제 설정은 다음과 같습니다. host_names:만 남기고 나머지를 모두 삭제하면 어떻게 될지 모르겠습니다. 제 모든 사이트에 대해 이 설정을 반복 적용하고 있습니다.
forum2:
adapter: postgresql
database: forum2_discourse
host: data
password: SEKRET
pool: 25
timeout: 5000
host_names:
- forum2.example.org
이 내용이 app.yml에 있다면 Discourse는 앱 컨테이너의 var/www/discourse/config/multisite.yml 경로에 파일을 생성하며, 내용은 동일합니다. 가이드를 따라가면서 혼란스러울 수 있다는 점은 알고 있습니다. 하지만 멀티사이트 환경에서 두 번째 사이트나 세 번째 사이트를 app.yml에 선언하는 가장 좋은 방법입니다. 저는 멀티사이트와 함께 이메일 송신을 위한 셀프호스팅 postfix, dovecot 설정을 사용 중입니다. 현재까지는 완벽하게 잘 작동하고 있습니다. 저는 postfix를 가상 메일박스(virtual mailboxes)로 구성했습니다. Postfix는 답장 키(reply key)도 유지합니다. 조금 더 작업이 필요하지만, 제 생각에는 더 나은 해결책입니다.