멀티사이트와 컨테이너 여러 개를 사용하는 것의 장단점에 대해 아시는 분 계신가요?
현재 저는 Discourse 인스턴스 3개를 별도의 컨테이너로 운영하고 있으며, 포럼 2~3개를 추가로 Discourse로 전환하는 것을 고려하고 있습니다. 같은 서버(64GB RAM, SSD 사용)에서 실행될 예정이라 앞으로 가장 좋은 방법이 무엇인지 궁금합니다.
가능한 한 독립적으로 운영되기를 선호하므로, 각 인스턴스를 개별적으로 업그레이드하고 백업 및 복원할 수 있으며, 하나의 인스턴스에 문제가 생겨도 다른 인스턴스에 영향을 주지 않기를 바랍니다.
어떤 방법이 좋을까요? 주의해야 할 장단점이 있을까요?
멀티사이트 환경에서는 개별 업그레이드가 불가능하며, 사용하는 플러그인도 분리할 수 없습니다. 이러한 설정은 모두 루트 멀티사이트에 의해 정의됩니다. 단, 설정, 테마 및 백업은 개별적으로 처리할 수 있습니다.
일반적으로 SSL 인증서 관리를 위해 프록시를 앞에 배치해야 합니다.
실제로 저는 Let’s Encrypt를 사용하여 여러 도메인에 대한 인증서를 발급받고, 주 도메인으로 리다이렉트하지 않는 방법을 찾아냈습니다. Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy
@AstonJ, 제 howto(사용 설명서)를 테스트해 볼 의향이 있으신가요? 작동한다는 데 90%는 확신하지만, 마지막으로 테스트한 것이 몇 주 전이라 제 자신 외의 다른 사람에게도 이 안내서가 제대로 "작동"하는지 완전히 확신하지는 못하겠습니다.
모든 사이트에 동일한 플러그인을 사용하고 동시에 업그레이드하기를 원하신다면 멀티사이트(multisite) 구성이 적합합니다.
ACP를 통해 사용하지 않는 플러그인을 그냥 비활성화할 수 있을 것 같습니다(포럼 중 하나에서는 필요 없는 플러그인이 하나뿐인 것 같습니다). 그래서 멀티사이트를 사용하는 데 어떤 이점이 있는지에 따라 달라질 것 같습니다. 구체적으로 성능과/또는 안정성 측면에서 이점이 있을까요?
@Blake가 PG를 컨테이너로 따로 분리해서 실행하지 않는 것은 미친 짓이라고 한 번 포스트한 것 같은데(멀티사이트와 다른 개념인가요?) 그래서 이걸 해볼까 생각 중입니다. 참고로 블레이크가 한 말을 인용하지 마세요. 제가 꿈에서 본 것일 수도 있으니까 
저는 HAProxy를 사용 중인데 SSL 인증서를 처리해주므로 괜찮을 것 같습니다.
제이, 이점에 따라 달라질 것 같습니다. 큰 차이가 없다면 현재처럼 계속 진행해도 괜찮습니다. 설정과 관리가 비교적 쉬워졌으니까요. 하지만 멀티사이트로 전환하는 데 큰 이점이 있다면 확실히 관심이 있습니다 
다른 이점은 rails와 nginx를 각각 하나만 더 실행하면 되므로 필요한 추가 RAM 용량이 훨씬 적다는 점입니다. 다만 RAM 용량이 충분하므로, 이미 작동하는 방식을 따르는 것이 최선의 아이디어처럼 들리기 시작합니다.
안녕하세요. 멀티사이트의 사용자를 결합하여, 한 사이트에서 가입하면 모든 멀티사이트에 동시에 가입되도록 할 수 있을까요 (마젠토처럼)? 또는 디스코스를 사용하는 상위 변형 방식, 예를 들어 연동(federation)과 유사한 방식으로, 알림이 동기적으로 작동하여 1번 사이트의 사용자가 2번 사이트의 알림을 받을 수 있게 하는 것은 어떨까요? 채팅도 마찬가지입니다.
저는 동일한 큰 방향성을 가지고 있지만 주제가 다른 4개의 커뮤니티를 운영하고 있으며, 이 커뮤니티들이 서로 긴밀하게 통합되기를 원합니다
한 사이트를 Discourse Connect 인증 서버로 설정하고, 나머지 모든 사이트가 해당 서버를 통해 인증하도록 구성할 수 있습니다.
멀티사이트 설정, 컨테이너 여러 개, 또는 다른 방식이 필요한지 고민하고 있습니다.
현재 독립적인 커뮤니티 3개를 운영 중인데, 그중 두 개는 유사한 주제(각기 다른 두 학교의 대학 스포츠)를 다루고, 나머지 하나는 요리와 베이킹에 대한 커뮤니티입니다.
ISP의 IP 주소 제한 때문에 이 커뮤니티들을 모두 동일한 서버에 두되, 서로 다른 URL로 접근할 수 있도록 하기를 원합니다. 예를 들어 다음과 같은 구조를 생각하고 있습니다:
foo.bar.com/team1
foo.bar.com/team2
foo.bar.com/cooking
team1.bar.com이 foo.bar.com/team1로 리다이렉트되는 방식이거나, 별도의 가상 서버를 사용하는 것도 괜찮습니다. (Apache가 이를 할 수 있다는 것을 알고 있으므로, nginx도 직접적으로든 프록시 서버를 앞에 두든 유사한 방식으로 처리할 수 있다고 가정하고 있습니다.)
이상적으로는 foo.bar.com 자체가 이러한 독립적인 커뮤니티들의 관문 역할을 하여, 각 커뮤니티가 무엇인지 그리고 어떻게 접근할 수 있는지를 설명하는 역할을 하기를 바랍니다. 각 커뮤니티의 일부 카테고리는 웹 검색에 노출되도록 웹 크롤러가 접근할 수 있도록 공개적으로 읽을 수 있게 하고 싶습니다.
이것이 멀티사이트 설정인지, 멀티컨테이너 설정인지, 아니면 완전히 다른 무엇인지 알려 주실 수 있나요?
상황에 대해 업데이트를 드리려고 합니다.
일부 연구를 거친 후, 저는 멀티사이트 설정(현재는 컨테이너 1개)을 사용해야겠다고 결정했습니다. 외부 nginx 사이트를 통해 설정을 설명하고, 트래픽을 개별 discourse 사이트로 유도하기 위해서입니다. 이렇게 하면 list1 사용자들이 list2의 콘텐츠를 다룰 필요 없이, 두 사이트 모두 읽기 전용 액세스(및 웹 크롤러)에 열려 있도록 할 수 있습니다. 웹 크롤러를 만족시키기 위해 robots.txt를 조정해야 할 수도 있습니다.
멀티사이트 설정 예제는 도움이 되었지만, unix 소켓으로 작동시키지 못했습니다(게이트웨이 오류). 결국 포워딩을 다른 포트에 설정하고, 컨테이너 내부에서 해당 포트를 443으로 리다이렉트하는 방식으로 해결했습니다.
app.yml 파일에서는 SSL 템플릿은 활성화했지만 letsencrypt 템플릿은 활성화하지 않았습니다.
테스트베드 사이트는 작동하게 만들었고, 이제 프로덕션 사이트를 전환할 때 발생할 수 있는 문제를 찾고 있습니다. hopefully 이번 달 말이나 다음 달에 전환할 예정입니다.
인증서 문제는 외부 서버 쪽에서 처리하고 있지만, 컨테이너 내에서 https를 요구하도록 설정하여 수정한 ‘보안되지 않음’ 문제에 부딪혔습니다. 최신 인증서와 키를 컨테이너의 /shared/ssl 디렉토리에(ssl.crt와 ssl.key로) 복사하는 작업을 cron을 통해 실행하는 태스크를 설정했습니다. 인증서가 변경될 때(7월인 것 같습니다) 새 인증서가 로드되도록 컨테이너 내부의 nginx를 재로드하도록 강제해야 하는지 확실하지 않습니다.
discourse 관련 함정 하나를 발견했습니다:
컨테이너의 /etc/nginx/conf.d/discourse.conf 파일에는 다음과 같은 코드 조각이 있습니다(도메인 이름은 변경됨):
if ($http_host != ‘site1.my.domain’) {
rewrite (.*) https://site1.my.domain$1 permanent
}
이것 때문에 site2.my.domain이 site1.my.domain으로 리다이렉트되고 있었으므로, 주석 처리해야 했습니다.
참고: 컨테이너를 재빌드하면 이 편집을 다시 해야 합니다. 이를 피하는 방법이 있을까요?
이로 인해 브라우저 관련 함정에 부딪혔는데, 이제 firefox가 해당 리다이렉트를 영구적인 것으로 표시하고 있었기 때문에 브라우저 캐시를 삭제해야 했습니다. (이걸 파악하는 데 너무 오랜 시간이 걸렸습니다!)
또 다른 이상한 점 하나를 발견했습니다.
테스트베드 사이트에서는 https를 요구하는 매개변수가 두 사이트 모두 체크되어 있지 않았습니다. 프로덕션 사이트에서는 해당 매개변수가 설정 파일에 아예 존재하지 않습니다. 이는 두 사이트 간의 차이와 관련이 있을 것으로 추측합니다.
즉:
개별 VPS를 사용하면 멀티 컨테이너보다 유연성이 더 클 수 있지만, 멀티사이트보다 RAM 사용량이 더 많을까요?
하지만 하나의 큰 서버를 사용할 수 있다면 멀티 컨테이너가 유리할 수 있을까요?
아마도 매우 최적화된 대규모 구현에는 k8나 어떤 형태의 초 대규모 컨테이너 기술이 포함될 수 있겠죠?
그러나 비용 절감이 우선시되고 사이트들이 동일한 플러그인 구성을 가진 매우 동질적인 중규모 환경이라면, 멀티사이트가 최선의 선택일까요?
모든 사이트가 동일한 플러그인과 동일한 SMTP 설정을 사용할 수 있다면, 멀티사이트(multisite)가 바로 여러분이 원하는 것입니다.
무엇이든 다르게 설정해야 한다면, 각 사이트마다 별도의 컨테이너가 필요합니다. 참고: 웹 전용 컨테이너로 분리된 모든 사이트를 처리하기 위해 단일 데이터베이스 컨테이너를 사용하는 것을 권장합니다.