위에서 언급했듯이 호스트의 컨테이너는 install-nginx를 절대 실행하지 않습니다.
이 주제가 특히 유용할지 확신하지 못합니다.
Discourse의 아키텍처를 싫어하시고, 개발자들이 제품을 어떻게 최적화했는지에 대한 설명도 받아들이지 않으시며, Docker에 익숙하지 않은 것으로 보이며, 본인도 인정하듯 질문에서 거짓말을 하고 있어 우리 모두의 시간을 낭비하고 있습니다.
이 주제는 이미 무료 커뮤니티 지원의 범위를 크게 벗어나고 있기 때문에 unsupported-install 태그가 붙어 있습니다. 이 문제가 정말로 중요하시다면 #marketplace에서 새 주제를 시작해 보시는 건 어떨까요? 그렇게 하면 개발자의 시간을 쓰는 대신, 직접 돈을 투자하여 컨설턴트에게 교육을 받을 수 있을 것입니다.
아니요, 죄송합니다. 그러면 위에서 언급한 sed 명령어를 app.yml의 hooks 섹션에 넣어야 한다는 뜻인가요? 부트스트랩 시점에 docker_discourse 저장소의 파일을 수정하는 방법에 대한 예시가 어딘가에 있을까요? 현재 해당 섹션에는 플러그인을 위한 git clone 명령어만 있습니다.
git clone처럼 cmd 섹션에 해당 sed 명령어를 넣을 수도 있을 것 같지만, install-nginx 스크립트가 어느 디렉토리에 위치하게 되는지 모르겠습니다..
또한, app.yml은 어디에 있나요? containers 디렉토리가 저장소에서 비어 있어서 위의 hooks 섹션에 링크를 걸 수 없었습니다 ![]()
이 모든 작업을 수행하는 데 필요한 문서가 이미 meta에 존재합니다. 우리는 모두 매뉴얼 읽기를 건너뛰는 것을 좋아하지만, 이 경우에는 정말로 기본으로 돌아가야 합니다.
솔직히 말해, 당신은 이 모든 것을 거꾸로 진행하고 있습니다.
unsupported-install 태그를 다시 언급하겠습니다. 표준 설치에서 벗어나기로 결정했다면, 추가적인 기술적 부담을 스스로 감당할 것이라는 것이 전제됩니다.
인스턴스를 어떻게 설치했나요?
죄송하지만, 게시하기 전에 문서를 검색하기 위해 노력하고 있습니다. 저는 Discourse 매뉴얼이 정말 있었으면 좋겠고, 이미 #howo 태그가 붙은 많은 주제들을 읽어 보았습니다. 불행히도, Discourse 매뉴얼은 존재하지 않는 것 같습니다.
이 문제에 대한 도움을 감사히 생각하며, 앞으로 이러한 작업을 수행하는 방법에 대한 문서를 찾는 다른 사람들에게도 도움이 될 것이라고 확신합니다…
먼저 discourse-setup을 실행했는데, 결국 깨진 설치 상태가 되었습니다. 그 후 app.yml을 수동으로 편집한 다음 ./launcher rebuild app을 실행했습니다.
Discourse를 더 잘 이해하기 위한 흥미로운 토론인 것 같습니다.
nginx를 사용하는 쪽에 손을 들어주고 싶네요. app.yml을 충분히 수정하여 컴파일 과정에 mod_security 모듈을 추가하고, 내 전용 베이스 이미지를 빌드하는 방식이죠.
Discourse는 복잡한 소프트웨어이고, 그 위에 돌아가는 Rails는 더 쉽게 그리고 일관되게 배포하기가 훨씬 더 복잡합니다. 그래서 스태프가 만든 Docker 이미지에 많은 노력을 기울인 것이죠.
이미지에는 지원되는 설치 환경에서 최대한 잘 동작하도록 하기 위한 수많은 최적화와 블랙매직이 가득합니다.
이 점을 인지하고 퍼즐 조각들을 모두 파악할 수 있다면(예를 들어, Discourse를 실행하는 데 필요한 2~3개의 저장소 등), 원하는 것을 실행하는 것은 불가능하지 않습니다.
자, 당신의 설정이 nginx -> varnish -> apache인 것을 알고 있는데, 왜 베이스 이미지에 mod_security를 추가하고 훅으로 설정한 nginx -> varnish -> Discourse를 실행하지 않습니까?
mod_security를 적용한다고 해서 보안이 실제로 강화될 가능성은 매우, 매우 낮습니다. Discourse를 유지보수하는 팀은 보안을 매우 중시하고 있으므로, mod_security가 해결한다고 알려진 문제들은 이미 대부분 처리되어 있을 가능성이 큽니다. 또한, 이미지(image)에 mod_security를 추가할 경우 Discourse가 작동하지 않게 될 확률은 0보다 상당히 높습니다. mod_security를 설치한 결과 Discourse가 작동하지 않는다면, Discourse를 mod_security와 호환되도록 수정해야 하는 것은 전적으로 사용자의 몫이 됩니다. 이 경우 Discourse 유지보수자에게 합리적인 보안 우려임을 설득해야 하거나, 앞으로 자체 포크(fork)를 직접 유지보수해야 하는 상황에 처하게 됩니다.
이렇게 하는 것에서 좋은 결과는 나오지 않습니다. 좋은 결과가 나올 가능성은 극히 낮습니다.
동의합니다. 또 다른 WAF는 보안 불투명성(security by obscurity)에 가깝습니다.
토론의 보안을 유지하기 위한 실제적인 선제적 노력들이 이루어지고 있습니다:
이 주제는 Discourse를 Apache로 실행하는 것(nginx로 프록시하는 경우와 대조적으로)에 대한 원래 질문에서 벗어나고 있습니다.
하지만 WAF(mod_security 또는 기타)를 Discourse 앞에 배치하는 것에 대한 논의는 커뮤니티에 유용할 것 같아서, Discourse + WAF를 구체적으로 논의하기 위해 별도의 주제를 만들었습니다: