간단한 주의사항: 제로부터 VPS 환경을 구축하는 것은 비교적 처음이지만, 웹 호스팅(특히 공유 호스팅과 매니지드 데디케이트드 서버)에 대한 충분한 경험을 가지고 있어 무엇을 해야 하는지 대략적인 방향을 잡고 튜토리얼을 이해할 수 있는 수준입니다.
그럼에도 불구하고, 저는 현재 DigitalOcean의 가장 저렴한 드롭렛을 실험 목적으로 사용하고 있습니다. 저는 취미로 서버를 관리하는 사람이며, 트래픽이 매우 많을 것으로 기대하지 않고, 단순히 게임 디자인을 위한 인스턴스와 콘텐츠 크리에이터 커뮤니티를 위한 인스턴스 두 개를 생성하여 각각 일종의 프론트페이지(아마도 WordPress)와 그에 수반되는 Discourse 포럼을 제공하려는 것입니다.
Discourse가 포트 80을 사용하도록 결정했기 때문에 Apache와 잘 어울리지 않는다는 점과, 우회 방법이 존재하지만 그 방식이 다양하고 결과가 확인되지 않으며, Discourse 측에서 공식적으로 "이것이 작동한다"는 확인을 받지 못했다는 점은 알고 있습니다.
이토록 훌륭한 플랫폼이 웹 서버를 함께 관리하는 것을 이렇게 방해하는 방향으로 설계된 이유에 대해 약간 혼란스럽지만, 지금까지 소프트웨어에 대한 경험이 제 관심을 충분히 불러일으켜 작동하는 방법을 찾아보려 합니다. WordPress 통합 기능이 존재하며 기능 페이지에서 홍보되고 있다는 것을 보았지만, 다시 한번 말하지만 Discourse는 스탠드얼론으로만 설계된 것처럼 보입니다.
하지만 제대로 작동하게 만드는 데 문제가 많은 것으로 보이며, 특히 SSL 관련 문제가 두드러집니다.
웹사이트용 드롭렛 하나와 Discourse 전용 드롭렛 하나를 각각 실행하는 것이 더 간단한 방법일까요? 서브도메인의 DNS 레코드를 Discourse 드롭렛으로 변경하면 문제가 해결될 것 같습니다. 다만 포럼 하나를 위해 서버 두 대를 운영하는 것이 다소 이상하게 느껴집니다.
최대한의 존중을 담아 말씀드리지만, Discourse는 기본적으로 자체 서버가 필요합니다. 같은 VPS에서 Discourse와 웹 서버를 병렬로 실행하기 위해 리버스 프록시를 사용하는 것은 성공과 실패가 반반인 경우가 많으며, 댓글이나 다른 불만 사항들에서도 이를 알 수 있습니다. 또한 SSL이 정상적으로 작동할지 아닐지도 불확실합니다. 게다가 같은 서버에 Discourse 두 인스턴스를 실행하는 것은 사실상 불가능합니다. 저에게 이런 것들은 모두 장애물처럼 느껴집니다. XenForo나 Invision과 같은 고급 플랫폼을 포함한 다른 포럼 소프트웨어 중에도 이 정도 노력과 불확실성을 요구하는 것은 없습니다. Discourse는 비싼 패키지들이므로, Discourse에서 돈을 안 내는 대신 얻는 것이 이런 부분인 것 같습니다. 새로운 사용자로서 이러한 모든 장벽을 바라보면, Discourse는 다른 것(즉, 웹사이트)은 전혀 고려하지 않고 설계된 것처럼 느껴집니다.
참고로, 제 원래 게시물에서 언급했듯이 저는 Discourse를 원클릭 배포로 설치했습니다. 따라서 Apache(또는 튜토리얼을 찾을 수 없다면 Nginx)를 같은 서버에서 실행하려면 모든 것을 역순으로 진행해야 할 것입니다. Discourse를 주요 포럼 플랫폼으로 사용할 계획이라면, 하나의 커뮤니티를 위해 두 개의 서버를 운영하는 것에는 관심이 없습니다. 그것은 그저 어리석은 일입니다.
@Benjamin_D 제가 겪는 문제는 여기서 제공되는 모든 튜토리얼이 제 현재 환경의 일부 요소를 누락하고 있다는 점입니다. Apache를 다루는 튜토리얼은 CentOS를 기반으로 하고 있는데, 저는 Ubuntu를 사용하거든요. Kane York의 다른 튜토리얼은 Nginx를 사용하는데, 앞서 언급했듯이 저는 Apache를 사용하고 있습니다.
또한 제가 하는 작업이 지나치게 복잡한 것도 아닙니다. DigitalOcean, Linux + Ubuntu 18.04를 사용하며 모든 것을 드롭렛에 호스팅하고 있고(서드파티 스토리지 미사용) 등입니다. 메일 솔루션으로는 Mailgun을 사용 중인데, 이 서비스는 받은 편지함을 제공하지 않는 것으로 알고 있습니다. 당장은 괜찮습니다.
사실, Discourse는 현재 지구상에서 가장 뛰어난 포럼 및 커뮤니티 구축 오픈소스 소프트웨어입니다(개인적 의견). 그 이유는 많지만, 몇 가지만 언급하자면 다음과 같습니다:
Discourse는 오픈소스이며, 강력한 커뮤니티와 매우 똑똑하고(또한 능력이 있는) 핵심 개발 팀을 보유하고 있습니다.
Discourse는 프로덕션 환경에서 Docker 컨테이너로 실행되도록 설계되어 있으며, 이는 많은 이점이 있습니다:
Discourse는 외부 웹 서버나 데이터베이스가 필요 없이 standalone mode(스탠드얼론 모드)로 쉽게 배포할 수 있습니다.
Discourse는 multi-container mode(멀티 컨테이너 모드)로 쉽게 배포할 수 있어 더 높은 안정성과 무중단 업그레이드를 제공합니다.
Discourse는 Docker Swarm과 Kubernetes를 사용하여 매우 높은 가용성 구성으로 배포할 수도 있으며, 이 경우 Discourse는 "온디맨드"로 확장 및 축소될 수 있습니다.
Discourse는 백업과 복원이 쉽습니다. 표준 Discourse 백업을 OOTB(Out of the Box, 별도 설정 없이)로 생성한 후, 전 세계 어디에서나 새롭고 깨끗한 Docker 컨테이너에 복원할 수 있습니다.
Discourse는 Apache2와 nginx 리버스 웹 프록시 서버 뒤에 쉽게 실행됩니다. 이 또한 많은 장점이 있으며, 몇 가지를 들자면:
Discourse는 Docker가 노출하는 TCP/IP 포트나 UNIX 도메인 소켓을 통해 기존 웹 서버(nginx 또는 Apache2)에서 적은 노력으로 실행할 수 있습니다.
리버스 프록시 뒤에 웹 기반 앱을 실행하는 것은 이미 잘 정립된 방식입니다. 이 설정은 Discourse에 고유한 것은 아니지만, Discourse는 이에 대한 지원을 제공합니다.
리버스 프록시 뒤에서 SSL을 설정하는 것은 매우 간단하며, 지원되는 무료 LETSENCRYPT를 사용하여 certbot -d my.great-discourse.site 명령만으로 간단히 처리할 수 있습니다.
Discourse는 GitHub에서 커밋 단위로 완전히 문서화되어 있어 누구나 코드 변경 사항을 추적할 수 있습니다.
Discourse는 점진적인 비즈니스 모델을 가지고 있으며, 여기에는 몇 가지 주요 이점이 포함됩니다:
Discourse의 핵심 소프트웨어와 많은 훌륭한 플러그인, 테마, 구성 요소는 무료입니다.
Discourse는 meta에서 표준 구성 지원을 포함한 무료 지원을 제공합니다.
Discourse는 자체 호스팅을 원하지 않거나 더 “손을 덜 대고” 운영하기를 선호하는 사람들을 위한 상용 호스팅을 제공합니다.
Discourse는 커뮤니티 내에서 상용 컨설팅과 플러그인 개발을 장려하여 실행 가능한 비즈니스 생태계를 조성합니다.
더 많은 장점이 있지만, 여기서 마무리하겠습니다!
저(우리)는 핵심 Discourse 팀이 내린 모든 결정에 동의합니까? 그리고 그들이 우리(또는 저)의 모든 아이디어와 제안에 동의합니까?
물론 아닙니다. 그리고 그들이, 우리, 또는 제가 그렇게 할 필요도 없습니다. 우리는 자유롭게 제안하고, 코드 수정 제안, PR을 제출할 수 있으며, 핵심 Discourse 팀은 이러한 제안들을 열린 마음으로 대할 것입니다.
그러나 결국, 핵심 팀은 Discourse 커뮤니티를 하나의 방향으로 조화롭게 이끌어 나가야 합니다. 이는 서로 다른 문화권의 수백 명의 사람들이 다른 구성을 원하고, 다른 우선순위, 비즈니스 모델, 아이디어를 가지고 있을 때 쉬운 일이 아닙니다.
즉, Discourse에서 "회피"할 것(여러분의 주제 제목 표현)은 없습니다. 특히 리버스 프록시 설정과 Docker 숙련도는 그렇습니다. 많은 사람들(저도 포함)이 Discourse 때문에 Kubernetes로 전환하고 있습니다. 이는 Discourse뿐만 아니라 다른 웹 앱들도 마찬가지입니다.
Discourse는 “방해 요소”(다시 말하지만, 여러분의 표현입니다)와는 “가장 거리가 먼” 것입니다. 그리고 컨테이너 기반으로 설계되어 있기 때문에, 숙련된 시스템 관리자가 Discourse를 어떻게 확장 가능한 프로덕션 환경에 배포할 수 있는지에 대해서는 "하늘이 한계"입니다. 또한 초보자가 standalone mode로 쉽게 배포할 수 있을 정도로 단순합니다.
제대로 이해했다면, 한쪽에서는 nginx가 특정 서브도메인을 수신하여 Apache로 리다이렉트하고, 다른 쪽에서는 서브도메인을 Discourse가 실행 중인 컨테이너로 리다이렉트하는 구성을 원하시는 것이 맞나요 (app.yml에서 올바른 포트를 노출하거나 web.socketed 템플릿을 사용하여 설정하는 방식). 아니면 Apache를 프록시로 사용하고 계신 건가요?
가까우긴 하지만 아닙니다. 다시 한 번 말씀드리면, 저는 Linux + Ubuntu 18.04를 사용 중입니다. Apache를 사용하여 표준 HTML 웹사이트(향후 WordPress)를 서빙하고 있으며, 서브도메인 아래에 Discourse를 설치해 두었습니다. 이제 Apache가 이미 80번과 443번 포트를 사용 중이므로, 이 두 포트의 트래픽을 새로운 포트들로 리디렉션하는 리버스 프록시를 어떻게 설정해야 하는지(해당 튜토리얼에 따라) 파악해야 합니다. Nginx는 경험도 없고 Apache와 함께 사용해서 설정이 더 복잡해지길 원하지 않기 때문에 사용에 관심이 없습니다.
저는 고급 개발자가 아닙니다. 저는 프론트엔드에 대해 유창하게 이해하고 있고, 패널에 대해서는 기본적인 이해, SSH에 대해서는 제한적인 이해를 가진 사람일 뿐이며, 그 외의 모든 것에 대해서는 거의 이해하지 못합니다(이것이 제가 튜토리얼을 사용하는 이유입니다).
제 최종 목표는 각각의 프론트 페이지를 가진 두 개의 도메인과 Discourse의 여러 인스턴스(각 웹사이트마다 하나씩)를 갖추는 것입니다. 단순한 작업입니다.
