Apache + SSL + Discourse: 다음 단계는?

제품 지원 자체 호스팅
1

Apache와 함께 Discourse를 설치하는 방법에 대한 해결책을 일주일 동안 찾아본 끝에, Discourse의 Nginx 중심 설계 특성상 Apache 뒤에서 Discourse에 SSL을 활성화하는 것은 사실상 불가능해 보이므로, 다음 단계에 대한 조언을しぶしぶ 구하게 되었습니다.

현재 호스팅 환경 구성:

  • Digital Ocean $10 드롭렛
  • Ubuntu 18.04
  • HTML 프론트페이지용 Let’s Encrypt SSL이 적용된 Apache
  • PHP, MySQL, phpMyAdmin
  • Webmin (SSL 없음)
  • Discourse

WordPress를 설치할 수 있는 유연성을 유지하길 원하므로, Apache가 WordPress와 더 나은 호환성을 유지한다는 것을 읽은 바에 따라 Nginx로 전환하는 것이 최선의 길이라고 확신하지 못합니다.

목표: Discourse를 별도의 드롭렛으로 분리하지 않고, Discourse를 포함하여 도메인 전체에 SSL을 활성화하는 것입니다. 이를 위해 Nginx를 제한적으로 사용해야 한다면 괜찮습니다. 이 복잡한 상황을 해결하기 위해 어떤 튜토리얼을 찾아봐야 할지 방향만 알려주시면 됩니다.

감사합니다.

2

이 링크를 시도해 보셨나요? Set up Discourse on a server with existing Apache sites

3

유사한 구성을 찾고 있는데, 현재 진행 단계가 저보다 앞서 있는 것 같습니다. 구성에 대해 몇 가지 확실하지 않은 부분이 있어, 괜찮으시다면 답변해 주시겠어요?

  1. 리버스 프록시를 사용 중이신가요?
  2. 리버스 프록시가 SSL을 처리하고 있나요?
  3. 다른 서버들은 SSL을 사용하지 않고 리버스 프록시에 SSL 처리를 의존하고 있나요, 아니면 각 서버마다 SSL을 적용하여 다층 방어를 구현하고 있나요?
  4. 리버스 프록시와 서버 간의 통신은 포트가 아닌 소켓으로만 이루어지고 있나요?
5

참고로, 저는 프로덕션 환경에서 Discourse 앞에 Apache2와 nginx를 리버스 프록시로 배치하여(유닉스 소켓 사용) 광범위한 테스트를 수행해 보았으며, nginx가 "훨씬 빠르다"고 할 수는 없습니다.

이 구성에서 nginx는 “조금 더 빠르지만”, 그 속도 차이는 사용자가 체감하기 어렵습니다.

또한 웹마스터 도구(Google PageSpeed, Lightspeed)의 페이지 속도 테스트를 시간 평균으로 보면, 두 리버스 프록시 간에 유의미한 차이가 나타나지 않습니다.

이 참고 의견은 이론이나 다른 사람들의 글을 반복한 것이 아니라, 실제 프로덕션 환경에서의 테스트에 기반하고 있습니다.

우리는 서버에 이미 LAMP 애플리케이션이 호스팅되어 있어 여러 웹사이트(가상 호스트)를 운영하기를 선호하기 때문에, 모든 Discourse 인스턴스를 Apache2 리버스 프록시 뒤에 실행하고 있습니다(처음에는 nginx 리버스 프록시를 사용했습니다).

nginx 대신 Apache2를 리버스 프록시로 사용하려는 모든 분에게 말씀드리지만, 전혀 문제가 없습니다! 이 사실 덕분에 Discourse는 더 넓은 사용자/호스팅 기반(Apache2와 nginx 사용자)에서 쉽게 활용할 수 있게 되었습니다.

10

@fzngagan 처음부터 다시 시작하는 게 아닙니다. 그리고 그 튜토리얼은 CentOS용인데, 제 게시글에서 분명히 Ubuntu를 사용한다고 명시했었습니다.

@EricGT 제가 제 own thread에서 공유한 해결책을 확인해 보세요. Nginx나 CentOS를 사용하지 않으면 지원을 구하는 것은 사실상 불가능하기 때문입니다 — 이 스레드에서 제 질문에 대한 답변을 받지 못한 채 오히려 Apache와 Nginx에 대한 주제와 무관한 논쟁만 오가는 상황이 그 증거입니다.

그렇게 될 수도 있지만, Apache가 더 널리 지원됩니다. Discourse는 사용자에게 사실상 Nginx를 강제하는 유일한 포럼 소프트웨어입니다. 그래서 더 흔하고, 신규 사용자에게 더 쉬우며, 지원을 구하기가 훨씬 더 쉬운 Apache를 유지하는 것을 선호합니다. "튜닝"은 제가 관심 있어 하는 부분이 아닙니다.

그런데도 Discourse 커뮤니티는 이를 적극적으로 지양하고, 그렇게 하려는 사용자에게 지원을 제공하기를 거부하며, 지원되지 않는 튜토리얼 링크를 공유하는 것 외에는 아무것도 하지 않습니다. 저는 여러 스레드를 만들고 더 많은 질문을 했지만, 다른 스레드에서 설정을 공유함으로써 지원에 근접한 도움을 주신 분은 당신뿐이었습니다. 초보자였던 저는 그것을 해석하여 제 환경에 적용할 것을 기대받았죠. 그 외의 모든 반응은 "이 오래된 튜토리얼을 확인해 보세요"라는 말이나 주제와 무관한 수다였습니다. :man_shrugging:

11

글쎄요, 여러 번 명확히 말씀드린 것처럼 시간과 정신 건강상의 제약으로 인해 여기에서 무료로 지원할 수 있는 범위에 한계가 있습니다. 그래서 95% 이상의 사용자에게 잘 작동하는 표준화된 설치 방법을 제공하며, 이 부분은 전적으로 지원합니다.

커스텀 설치를 위한 유료 지원 옵션을 고려하고 계신다면, Marketplace 채널을 추천합니다.

12

이 포럼은 대부분 동료 간 상호 지원(peer-to-peer) 방식이므로, 당신의 발언은 전혀 말이 안 됩니다. 게다가 저는 복잡한 질문을 한 적이 없으며, 단순히 기존 튜토리얼에 대한 설명이나 업데이트를 요청했을 뿐입니다. 그런데 그 튜토리얼들은 계속 링크되고 있지만, 내용이 구식이거나 잘못된 상태입니다. 저는 적절히 설정된 리버스 프록시를 얻기 위해 호스팅 제공업체인 DigitalOcean의 도움을 받아야 했습니다. 오픈소스 소프트웨어를 사용하는데도 이런 상황이니 정말 믿을 수 없는 일입니다.

당신의 답변은 이곳의 '지원’이 사실은 추가 판매(upselling)를 위한 형식에 불과하다는 인상을 줍니다.

23

@OrbitStorm 님께

먼저, 우리는 Apache2 리버스 프록시 뒤에서(여러 인스턴스에서) Discourse를 프로덕션 환경으로 사용 중이며, 설정 과정에서 단 하나의 문제도 겪지 않았습니다. 물론 도움이 필요할 때 “구글을 검색하는” 일반적인 과정은 누구나 망설임 없이 거치죠.

둘째, 저는 Discourse 팀이나 메타 포럼의 누구에게도 Apache2를 리버스 프록시로 지원해 달라고 요청한 적이 없습니다. 왜냐하면 이 구성은 공식적으로 지원되지 않기 때문입니다. (제 지식 범위 내에서) Discourse는 멀티 컨테이너 구성, 리버스 프록시(Apache2), Kubernetes, Docker Swarm 및 거의 무한에 가까운 기타 구성들을 “공식적으로” 지원하지 않습니다. Discourse 팀이 이 훌륭한 소프트웨어를 무료로 제공하고 모든 코드를 오픈소스로 공개하며 GitHub의 모든 커밋을 공개하고 있음에도, "공식적으로 지원하는 구성"의 범위를 제한하는 것은 이해할 수 있고 올바른 일입니다. Jeff가 이 부분을 잘 그리고 매우 정확하게 요약했다고 생각합니다:

글쎄요, 우리가 여러 번 분명히 언급했듯이, 시간과 정신 건강상의 제약으로 인해 여기에서 무료로 지원할 수 있는 것에는 한계가 있습니다. - Jeff A.

셋째, Discourse는 Apache2를 리버스 프록시로 사용하는 것과 같은 “비공식 지원” 구성에 대한 여러 튜토리얼을 제공합니다. 그러나 리버스 프록시 설정은 그 자체로 "Discourse 작업"이 아닙니다. 리버스 프록시 설정은 Discourse를 포함한 모든 백엔드 애플리케이션에 대해 기본적으로 동일한 작업을 수행하는 "일반적인 시스템 관리 작업"입니다.

우리는 Discourse, Docker Registry 및 기타 Docker 컨테이너와 앱 등 여러 웹 애플리케이션 앞에 Apache를 리버스 프록시로 운영하고 있습니다. Apache2(또는 nginx)를 리버스 프록시로 사용하는 것은 Discourse와 직접적인 관련이 없습니다. 이는 일반적인 시스템 관리 작업입니다.

넷째. 애플리케이션을 위해 Apache2를 리버스 프록시로 설정하는 방법에 대한 방대한 정보가 인터넷에 있습니다. Discourse 팀을 이 문제로 압박하는 것은 당신의 주장에 전혀 필요하지도, 유용하지도 않습니다. 사람들을 압박하고 “사기극(charade)” 같은 용어를 사용하는 것은 부정확할 뿐만 아니라 당신의 주장(또는 여기 있는 누구에게도)에 도움이 되지 않습니다.

따라서 @OrbitStorm 님을 위해 요약하자면 (이것은 당신의 주제에 대한 제 마지막 게시물이므로, 주의 깊게 읽어 주십시오), J. A. 님의 친절하고 인내심 있는 말을 포함하여 이전에 언급된 내용과 같이 당신에게는 여러 선택지가 있습니다.

  1. 인터넷으로 가서 Apache2를 리버스 프록시로 설정하는 방법을 쉽게 배울 수 있습니다(우리가 한 방법입니다). 이 일반적인 시스템 관리 작업을 배우는 것은 당신에게 재미있고 무료입니다.

  2. 배우기를 원치 않거나, 스스로 “파헤칠” 수 없거나, 시간이 없다면 누군가를 고용해 이 작업을 맡길 수 있습니다.

  3. 여기 게시물을 올려서 성토하고, 메타와 이 포럼을 "사기극"이라 부르며, 비공식 지원 구성에서 당신 개인을 지원하도록 사람들을 압박하기 위해 모든 사람에게 모욕을 퍼붓는 것입니다.

Discourse 사용자이자 수십 년 경력의 시스템 관리자로서, 저는 #3(메타 팀에게는 압박과 협박이 통하지 않을 것이므로, 이 부분은 확신할 수 있습니다)를 선택하지 말고, 도움이 되는 데 돈을 쓰지 않으려면 #1을 고려하시기를 강력히 권합니다.

Discourse를 위해 Apache2를 리버스 프록시로 설정하는 것은 실제로 매우 쉽습니다. 이 주제에 대한 Discourse 메타 게시물(일부는 최신, 일부는 오래된)이 몇 가지 있고, 웹 애플리케이션을 위해 Apache2를 리버스 프록시로 설정하는 방법에 대한 수많은 튜토리얼이 인터넷에 있습니다. 기법은 동일합니다. 리버스 프록시 모드로 실행할 때 유닉스 소켓을 노출하는 것을 권장합니다.

솔직히 말하면, Discourse를 위해 Apache2를 가상 호스트 리버스 프록시로 설정하는 것은 재미있는 일입니다. 왜 스트레스를 받으며, 이 훌륭한 소프트웨어를 만들고 무료로 나눠주는 사람들에게 모욕을 게시하십니까? Discourse는 무료 선물입니다! 공식적으로 지원되는 구성 외에 Discourse를 구성하려는 경우, 아무도 당신을 막지 않을 것입니다!

마지막으로 @OrbitStorm 님께, 저는 (팀 멤버가 아닌 Discourse 사용자로서) 메타에서 지원을 위해 압박하는 당신의 접근 방식을 변경하시기를 강력히 권고합니다. 앞서 말했듯이, 저는 “공식적으로 지원되지 않는” 구성으로 Discourse를 운영하며, 다른 사람들을 돕기 위해(이 훌륭한 커뮤니티에 보답하기 위해) 업데이트와 코드를 여기에 게시해 왔습니다. 저를 포함한 이전의 다른 사용자들도 이미 Apache2를 리버스 프록시로 설정하는 데 쉽게 따라 할 수 있는 작동하는 코드를 게시했습니다.

친절하게도 #1(직접 하기) 또는 #2(누군가를 고용해 하기) 중 하나를 선택해 주시고, 현재 #3(메타 팀을 위협하고, 압박하고, 모욕하기)에 대한 당신의 접근 방식을 중단해 주십시오. #3을 선택하시려면, 우리의 유닉스와 리눅스 포럼으로 가서 거기에서 원하시는 대로 저를 압박하십시오, 원하시는 대로 :slight_smile:

24

요약: 대체 무슨 소리야?

당신은 원본 주제에 실제로 답변하지도 않은 채 이 긴 글을 작성했는데, 심지어 공격받고 있지조차 않은 것을 마치 구원하러 나온 영웅처럼 나서려는 무의미한 시도를 하고 있습니다. 당신은 나를 “따돌림꾼”(웃기시네?)이라고 규정했는데, 이유는 내가 지능에 대한 인신공격을 퍼부으며 이 스레드를 Nginx를 위한 자신의 연단으로 삼은 남자의 주제와 무관한 헛소리에 반응했기 때문이라고 합니다 (이 포럼이 신규 사용자에게 얼마나 독성이 강한 문화를 양산하는지에 대한 증거로, 해당 댓글들은 conveniently 삭제되었습니다). 당신의 첫 번째 게시물도 내 질문에 실제로 답하지 않으면서 답변하는 식이라 크게 다르지 않았습니다. 당신은 이 문제의 일부입니다.

당신은 의무를 입에 올리고 있지만, 여기에서 당신은 논쟁을 벌이기 위해(스티븐이 그랬던 것처럼) 내 스레드에 지속적으로 응답하고 있습니다. 인기 있는 호스팅 구성(*W3Techs에서 이전에 인용된 바와 같이 Apache 점유율 67%)에 대한 지원을 요청하는 것을 금지하는 규칙이 있다는 것을 알지 못했습니다. 동의하지 않았다면 내 스레드에 답변하지 않고 그냥 두었으면 되었을 텐데, 당신은 적대적으로 굴며 대화를 엉망으로 만들기를 선택했습니다.

당신은 내가 “낡은 튜토리얼을 수용하고는 다시는 돌아오지 않는다는” 기존 관행에 따르지 않는다고 내 말을 의도적으로 왜곡하고 있습니다. 이는 이 설정에 관한 스레드들이 거의 모두 미해결 상태로 방치되는 요인 중 하나입니다(즉, 당신 같은 사람들의 따돌림). 정말로 내가 게시하기 전에 충분한 조사를 하지 않았다고 생각합니까? 나는 예상되는 결과를 수용했지만, 내 처지에 있는 다른 사람들(예: EricGT)이 거창한 "답변"들로 모든 것이 무시당해 사라지기 전에 가치 있는 무언가를 제공해 주기를 바랐습니다.

나는 16년 동안 게임 개발에 종사해 왔지만, 불과 5일 만에 이곳에서 경험한 수준의 비전문성과 사소한 악의는 본 적이 없습니다. 이건 레딧 수준의 유치함이며, 완전한 농담입니다.

또한, 이것이 그 증거입니다. 믿을 수가 없습니다.

25

프록시 뒤의 앱과 SSL 구성이 무슨 상관이 있는지 이해가 안 됩니다 :thinking: .
app.yml에서 SSL 템플릿이 비활성화된 상태라면요? nginx, apache, haproxy, traefik 모두 기본적으로 동일한 스니펫/서버 블록/가상 호스트 개념을 사용하며, 기본적으로 SSL을 켜고, 호스트에서 인증서가 어디에 위치하는지, 그리고 몇 가지 SSL 매개변수를 지정하는 방식입니다. 여기서 위험한 요소가 있을 수도 있나요?

제가 생각하기에 여러분이 찾고 있는 해결책은 Discourse와 관련이 없으며 Apache와 관련이 있을 것입니다. 그리고 다른 리버스 프록시와 마찬가지로, 가상 호스트를 갖춘 표준 SSL Apache 구성이 Discourse에서도 잘 작동할 것이라고 믿습니다. 하지만 제가 좀 낙관적일지도 모르겠습니다 :roll_eyes: .
다만, 암호화에 문제가 있었던 기억이 나네요. 도커 컨테이너 내에서 사용 중인 암호화 방식을 주의 깊게 복사/붙여넣기(해당 줄이 매우 깁니다)하도록 하세요.

이 미끄러운 비탈길에 대해 말씀드리자면, 이건 좀 오프트랙으로 스키를 타는 것과 비슷합니다. 좋은 시도이지만, 산악 구조대에서는 매우 불쾌해하는 행동입니다. 그리고 스키를 잘 타는 숙련자가 아니라 아직 배우는 단계에서 협곡에 빠진다면 상황이 꽤 달라질 수 있다는 점도 인정합니다.
전문가든 아니든, 친절하게 대해주세요.

image
image1200×742 243 KB

26

자, 다들 이 주제에서 좀 쉬어가는 게 좋겠어요. 우리가 할 수 있는 만큼 최대한 도와드렸으니까요.