아니, 정말 안타깝네요. 그런 소식을 들어서 너무 속상해요 
https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/8
@sam 님과 이 토픽을 보면, bitnami가 이미 그렇게 했음에도 불구하고 이 문제가 해결될 일은 없을 것임을 명확히 알 수 있습니다.
적어도 우리 질문에 대한 답은 '아니오’라는 것을 알게 되었죠.
그냥 애초에 root를 사용하지 않는 건 어떨까요? fakeroot를 사용해보면, 주된 장애 요인은 하드코딩된 경로(예: /var)라는 것을 알 수 있습니다. 현재 설정의 다양한 버그와 문제점을 제외하면, 이 방식이 작동할 수 있을 것입니다.
이처럼 훌륭한 소프트웨어가 컨테이너화에 대한 일반적인 오해에 기반한, 매우 부실하게 설계된 필수 설정 절차를 가지고 있다는 점은 아쉬운 일입니다. 최선의 의도로 이루어졌다는 점은 분명하지만, 그 결과는 취미 환경 밖에서는 어디에도 배포할 수 없는 것이 되어버렸습니다.
우리의 이미지는 discourse 사용자로 실행되며, 공식 이미지 역시 그러하다고 생각합니다.
하지만 어쨌든, “기업” 세계가 관심을 갖는 것은 정말 좋은 일입니다. 아마추어 세계보다 시간과 자원이 훨씬 많으니까요. 
커뮤니티가 생태계를 개선하기 위한 여러분의 기여를 높이 평가할 것이라고 확신합니다!
이것은 분명히 사실이 아닙니다. 우리는 nomad를 사용하여 이미지를 여러 기기의 플릿(fleet)에 배포하고 있으며, 현재 이 순간에도 AWS와 메탈 서버에서 10,000개 이상의 discourse 컨테이너가 실행 중입니다.
이 도구들은 실행하려면 루트 권한이 필요하며, 호스트의 /var에 접근할 수 있어야 합니다.
저는 오픈소스 커뮤니티와 기업들과 협력하여 컨테이너 설정을 개선하는 일을 자주 합니다. 더 합리적인 컨테이너화 된 설정을 갖기 위해 도움을 드리거나/또는 자금 지원을 고려해 주시면 기꺼이 도와드리겠습니다.
그것은 필수적인 것이 아닙니다. 설정을 위해 손을 잡아주어야만 한다면, 그것이 그 방법인 것입니다. 저는 예를 들어 gke, eks, ecs를 사용하는 고객들을 도운 적이 있습니다. 특정 요구 사항에 도움이 필요하시면 언제든 저에게 연락해 주세요.
/var는 하드코딩되어 있지 않습니다. 최근 /var/www/discourse에 설치한 사람과 함께 일했는데, 이는 웹에 기밀 데이터를 노출할 위험이 있어 매우 나쁜 아이디어로 보였지만, 그것은 그들의 "정책"이었습니다.
잘 설계되지 않은 것이 아닙니다. 10년 전이 아니라 오늘 기준으로 설계한다면 그렇게 보일 수 있다는 것입니다. 당시에는 좋은 설계였고, 여전히 그들의 인프라를 실행하는 데, 그리고 시스템 관리에 대해 아무것도 모르는 많은 사람들에게도 잘 작동하고 있습니다.
아마도 루트 권한이 필요하며 로컬 설정을 위해 설계된 공식 도구인 discourse-setup에 의존하지 않고 계신 것 같습니다.
discourse-setup 소스를 확인해 보세요. Discourse 구성 및 성능 튜닝에 익숙하시다면 필수 사항은 아닙니다.
Launcher는 생성된 yml 파일을 기반으로 이미지를 빌드하는 모든 중대한 작업을 처리합니다.
모든 것이 가능하지만, 제 생각에는 불필요한 노력으로 보입니다.
- 모든 명령어 실행 전에
fakeroot사용 - yaml 파일을 편집하여 /var를 변경할 수 있습니다:
sed -i "s;host: /var/discourse;host: $PWD/discourse;g" containers/*.yml --skip-connection-test(스크립트가 리버스 프록시가 있는 경우 연결을 확인하지 못하기 때문에 코드를 확인하여 발견함)- SSL 오프로딩은 일반적으로 외부에서 수행되므로 비활성화하는 방법을 알아내야 할 것임을 이미 알고 있는 certbot 관련 사항을 발견함
- containers/app.yml의 포트를 변경하여 1024 이상의 포트를 사용할 수 있지만, 이것만으로는 충분하지 않은 것 같습니다:
Error starting userland proxy: error while calling PortManager.AddPort(): cannot expose privileged port 443
나쁜 의도는 없으나, 단일 컨테이너에서 여러 서비스를 실행하는 것은 항상 잘못된 설계였습니다. 이는 개별 서비스에 대해 무슨 일이 일어나고 있는지 알 수 있는 방법이 거의 없거나 전혀 없기 때문이며, Docker 외부에서 사용자 정의 로그 파서 메커니즘을 설정해야 하고, 유용한 헬스체크를 사용할 수 없으며, 외부 데이터베이스에 쉽게 의존할 수 없기 때문입니다. 비즈니스에서 실행하는 유일한 서비스라면 가능할 수 있지만, 다른 모든 서비스가 그렇게 하기 시작하면 컨테이너를 사용하는 대부분의 이점이 사라집니다.
루트 접근 권한 없이 Docker 호환 환경에서 Discourse가 작동하도록 만드는 PR과 문서를 보내는 데 기꺼이 참여하겠습니다. 하지만 서비스들을 분리하고 표준 설정을 갖추는 것은 메인라인으로 채택될 것이라는 보장 없이 큰 작업이 될 것입니다.
Discourse의 근본적인 구조에 동의하지 않으신다면, 다른 제품을 사용하는 것을 고려해 보셨나요?
아, 이제 더 잘 이해가네요.
Discourse는 자체 호스팅을 위한 도구 선택에 대해 꽤나 단호한 입장을 가지고 있습니다. 덕분에 Discourse를 배포하려는 경험 많지 않은 관리자 대부분에게 효율적인 지원을 제공할 수 있습니다. 동의할 수도 있고 아닐 수도 있지만, 저도 예전에는 좀 아쉬운 마음이 있었지만 지금은 더 잘 이해하게 되었습니다 
대부분의 사람들이 원하는 것처럼 빠르게 실행 가능한 환경을 원하는 것이 아니라 다른 요구 사항이 있다면, 주로 혼자 해결해야 합니다. 일단 방법을 알게 되면 괜찮습니다
저희도 스탠드얼론 Discourse Docker 이미지에 대한 동일한 요구 사항이 있습니다. Kubernetes와 Minio를 함께 사용하고 있는데, 실행 가능하게 만드는 데 꽤나 고생했고, 여전히 많은 노력이 필요합니다. Discourse 팀에서도 이를 가능하게 하는 데 도움을 많이 주셨습니다.
저희의 작업물은 여기에서 확인할 수 있습니다:
https://lab.libreho.st/libre.sh/docker/discourse/-/blob/master/Dockerfile
https://forge.liiib.re/indiehost/tech/infrastructure/charts/-/tree/master/discourse
(문서화, 테스트, 유지보수, 제때 업데이트, 자동화 측면에서 충분하지 않으며, 아마도 다소 커스텀된 부분이 있습니다. 있는 그대로의 모습입니다)
개선하는 데 관심이 있으시다면, 주저하지 말고 PR을 보내거나 여기에서 채팅하세요: https://matrix.to/#/#libresh:liiib.re
하지만 그렇습니다, Discourse 팀은 Discourse 커뮤니티 버전에 대해 강한 의견을 가지고 있습니다. 동의할 수도 있고 아닐 수도 있지만, 그들은 사용자의 대부분에게 지원을 제공하고 있으며, 제가 직접 본 바로는 정말 놀라운 지원입니다. 그래서 좋은 결정이었다고 생각합니다
이것들은 Discourse 자체보다는 Discourse의 패키징 방식에 관한 근본적인 측면입니다. Discourse는 훌륭한 소프트웨어이지만, 말씀하신 대로 다른 해결책을 고려해야겠습니다.
postgres와 redis(그리고 ssl 및 let’s encrypt) 템플릿을 제거하고 직접 작성한 템플릿을 사용해도 됩니다.
공유해 주셔서 감사합니다. 저도 https://github.com/literatecomputing/docker-compose-discourse와 bitnami의 이미지를 찾았습니다. 문제는 이러한 솔루션들이 공식적으로 지원되지 않는다는 점입니다. 여러 개의 커스텀 리포지토리를 운영하는 것보다 커뮤니티가 지원하는 대안 Docker 설정을 마련하는 것이 어떨까 하는 생각이 듭니다. 노력을 여러 곳에 분산시키는 것은 효율적이지 않을 테니까요.
맞아요, 설정은 실제로 변경할 수 있습니다. 큰 노력 없이 실행할 수 있게 되면, 기존 도구나 문서를 개선하기 위해 PR을 보내 보겠습니다. 예를 들어 루트 권한 없이 실행하는 방법 같은 것 말이죠. 이는 개발팀의 의견과도 부합할 것이며, 더 까다로운 요구를 하는 시스템 관리자들에게도 도움이 될 것입니다.
9년이 지난 지금, 관용적인 Docker 구성은 bitnami의 discourse에 의해 커버되는 것 같습니다.
하지만 이 포럼의 다른 곳에서는 RAM을 많이 소모하고 지원되지 않는다는 주장이 있습니다. 클라우드에서 구동하기 위해 정석적인 설정을 시도해 봤을 때 여전히 상당한 마찰이 있다는 사실에 놀랐습니다.
요즘 redis, postgres, S3 호환 스토리지와 같은 많은 서비스는 digitalocean, supabase, aws 등 서로 다른 호스트 간에 설정하고 이동하는 것이 쉬워져 백엔드가 휴대성이 있게 되었습니다. Discourse를 실행하는 VM도 결정론적인 빌드를 통해 확장하거나 교체하기가 쉬워야 할 것 같습니다. 이 이상적인 상태에 매우 근접해 있음에도 불구하고 제약을 받는 것은 아쉬운 일입니다.
다른 사용자가 말했듯이, 이것은 놀라운 일입니다:
이 스레드 초반에 암시된 논리, 즉 이 과정을 더 쉽게 만들면 상업적 기회가 저해될 수 있다는 주장은 이상합니다. 상업적 관심사는 복잡한 빌드를 처리할 인력을 갖추고 있으므로, 이는 누구보다 솔로 개발자에게 더 큰 영향을 미칩니다. 저의 개인적인 사용 사례는 매우 큰 규모(비영리)의 커뮤니티를 운영하는 것입니다. 따라서 규모 면에서는 취미 수준이 아니며, 매출 면에서는 상업적 성격도 아닙니다.
음… 포럼/커뮤니티 보드를 만들어 보려고 고민 중인데, 당연히 Discourse를 사용해보려 했어요 (사용자 경험을 중요하게 생각해서요). 하지만 역시 설치/관리 과정에서 완전히 적대적인(?) 장벽에 부딪혔습니다.
몇 년 동안 모든 것을 단순한 docker-compose 파일로 실행하는 방식에 완전히 익숙해졌고, 여기에 데이터베이스, S3 호환 스토리지용 MinIO 같은 추가 요소들을 몇 가지 더 넣는 식으로 운영해 왔거든요. 하지만 Discourse는 이 부분에서도 여전히 매우 까다롭습니다.
사과할 일이 아닌데, 시작을 위해 어설픈 "launcher"를 사용해야 한다니요?
그리고 업그레이드 과정에서는 이렇게 나와요:
./launcher rebuild my_image를 실행하여 새 베이스 이미지를 수동으로 생성하세요.
죄송하지만 - 이미지를 수동으로 재빌드해야 한다는 건요? 대체 뭔 소리죠… 도커를 사용하면서 실제로는 도커를 사용하지 않는 것과 같은 느낌입니다…
./launcher rebuild app 명령이 작동하나요? 보통 이 명령을 사용합니다.
또한, 표준 설치 가이드를 따랐나요?
건설적인 코멘트를 할 것이 없어서, Mastodon 서버, Pixelfed, Moodle 등을 업그레이드해 보시라고 제안합니다. Discourse는 정말 믿을 수 없을 정도로 쉽습니다.
수동으로 명령 하나만 입력해도 장벽이 됩니다 