Awesome! I’ve bookmarked this post, and if anybody asks how to run Discourse in Kubernetes or Swarm, I’ll be sure to point them at your images . Advantage of being not-an-employee: my word doesn’t have to carry the weight of being Official™.
They, on the other hand, benefit immensely from having One Official™️ Way of deploying Discourse. CDCK is not going to take on the load of maintaining a deployment system that they themselves don’t use and is massive overkill for most self-hosters. And if they don’t maintain it, they ain’t endorsing it. Brand protection demands it.
I recently reached critical appreciation for discourse and got interested in hosting a deployment. I’m currently hosting JupyterHub, GitLab and Mattermost - everything through Helm charts and would very much like to do the same with Discourse.
Some background about Helm / Kubernetes:
A Helm chart is a set of configurable Kubernetes resources, and Kubernetes resources are for example a Deployment Kubernetes resource that makes a given docker image run at all time. Installing something can end up becoming a single line command + some configuration.
I would be happy to at least review code and make some PRs to fix various things in a Helm chart for discourse if it would be developed. I’m currently a maintainer of JupyterHub’s Helm chart and have various contributions to other charts.
I think it’s actually possible / feasible to break up Discourse into a set of kube pods, but have fun sizing the resource requirements for the web and sidekiq runners
If insane levels of infrastructure failure tolerance is not a business requirement for you, just use the singleton fat container, it’s going to be order of magnitude cheaper & easier for the same level of steady state service.
저는 Discourse를 포럼 도구로 사용하는 이탈리아의 상당히 큰 커뮤니티에서 왔습니다.
우리는 Discourse를 매우 좋아하지만, 일종의 “표준” 절차에 따라 Kubernetes에 배포하는 데 몇 가지 어려움도 관찰했습니다.
유지보수 담당자들의 고충을 잘 이해합니다 저는 수년 동안 Open Networking Foundation에서 근무했으며, 가장 큰 과제 중 하나는 가장 큰 플랫폼 중 하나인 CORD를 스크립트 기반 설치 방식에서 Dockerfile/docker-compose 및 DockerHub에 호스팅된 Docker 이미지 + helm-charts 방식으로 전환하는 것이었습니다. 이 과정에서 상당한 두려움이 따르며, 모든 경우에 적합한 단일 솔루션이 실제로 존재하지는 않지만, 첫 배포부터 그 이점을 확실히 확인할 수 있었습니다.
보통 가장 큰 걸림돌은 기존 도구가 가장 잘할 수 있는 일을 맡기도록 마인드셋을 전환하는 것입니다. Docker에는 표준적이고 쉽고 이미 잘 문서화된 설치 절차가 있습니다. 반면 스크립트는 커스텀 요소가 많아 종종 맞춤화와 유지보수가 필요합니다.
또한 Discourse의 종속성(예: unicorn, postgres, redis 등)으로 원래의 Docker 이미지/helm-charts를 사용할 수 없는 데에는 정말 이유가 없습니다.
우선 기본 사항을 해결하는 것을 제안합니다(예: 각 컴포넌트에 대해 Dockerfile, docker-compose, 그리고 DockerHub 자동 빌드를 갖추는 것). 이것이 완료된 후(적절한 소프트웨어 및 문서 수정과 함께), helm-charts 개발은 가장 쉬운 부분입니다.
제안된 솔루션들의 장단점을 논의하기 위해 함께 통화하는 것까지 포함하여, 도움을 드릴 수 있다면 매우 기쁩니다.
안녕하세요 @Luca_Prete, 위에 있는 @pierreozoux님의 작업과 팀의 답변을 확인해 보셨나요?
대부분의 Docker 패키징 작업은 launcher가 백그라운드에서 수행하는 pups의 동작과 일치시키는 것이며, 여기에는 Postgres, Sidekiq 등에 대한 일부 사용자 지정 구성 설정이 포함됩니다. @unteem은 Discourse의 이전 버전에서 pups가 수행한 과정을 따라가며 자신의 필요를 충족시켰습니다. 공식 릴리스와 Docker 이미지를 최신 상태로 유지하는 것은 어려운 일입니다. 전체 과정을 표준 Docker 방식으로 풀어 보고 그 경로를 따라가 보는 것은 흥미로울 것입니다. 표준 설정을 사용할 수 있는 실행 가능한 경로가 있다면, 여기 있는 많은 분들이 매우 기뻐할 것이라 생각합니다.
아직 해본 적이 없습니다. 분명히 많은 부분이 있을 거라고 생각하지만, 개인적으로 작업에서는 단일 사용자(커뮤니티 지원과 대조적으로) 기반의 작업을 피하는 편입니다. 나중에 유지보수가 어려워질 수 있다는 단순한 이유 때문입니다.
구체적인 경로는 플랫폼의 세부 사항에 따라 달라집니다.
저의 관점에서 당신의 경우에 가능한 해결책은, 특정 커스터마이징 없이 표준 이미지(Postgres, Redis, …)가 Discourse와 어떻게 작동하는지 이해하는 것부터 시작하는 것입니다. 이 부분이 중요하다고 생각하는 이유는, Discourse를 설치하는 어디에서든 외부의 표준 서비스(물리 하드웨어, VM, 컨테이너, k8s의 차트 의존성 형태로 설치 가능)에 의존할 수 있게 해주기 때문입니다.
이러한 각 서비스는 일반적으로 db 생성 등을 위해 시작 스크립트를 사용할 수 있게 허용합니다… 그렇게 어렵지 않을 것입니다.
그 다음으로 적절한 Dockerfile을 생성하겠습니다. (이것은 자동으로 Docker 없이 Discourse를 설치하기를 원하는 사용자를 위한 빠른 시작 가이드가 됩니다.)
그리고 docker-compose.yaml이 이어집니다. (이것은 bitnami가 자신의 github에 공개하는 것과 거의 동일합니다.)
이 시점에는 커스텀 스크립트 없이, 표준 의존성 이미지를 사용하여, 몇 초 만에, 하나의 명령어로, “마이크로” 서비스 형태로 노트북에서 Discourse를 띄울 수 있어야 합니다.
마지막으로, 하지만 가장 중요하지 않은 것은 아닙니다. Kubernetes 관련 작업이 있습니다. (몇 개의 yaml 파일, 아마도 helm-charts 형태로 패키징될 것입니다) 이는 공식 안정 버전 저장소에 게시되거나, 아니면 최소한 프로세스의 초기 단계에서는 자체 호스팅된 저장소에 게시될 것입니다.
제가 할 수 있는 말은, 우리에게 잘 작동한다는 것입니다 함께 나누고 모험을 감수할 마음이 있다면, 자유롭게 합류하세요 우리는 재미있게 일하고 있습니다
우리는 지원을 제공하지 않습니다. 시간이 부족해서입니다. 하지만 PR을 보내주시면 환영합니다. 정말로 공식 Discourse 우산 아래에서 이 작업을 수행할 수 있기를 바랍니다. 그렇게 하면 훨씬 쉬울 것입니다.
하지만 결국, 저는 Discourse 팀을 점점 이해하게 됩니다. 그들은 커뮤니티를 위해 지원하는 도구가 하나뿐이며, 그것이 잘 작동합니다. 기술적으로 숙련되지 않은 사용자에게도 좋은 지원을 제공하며, 이는 정말 좋습니다. 문제가 생기면 git pull && 재빌드하면 99%의 문제가 해결됩니다 다른 도구를 지원하는 것은 큰 위험이라는 것을 이해합니다. 제대로 지원되지 않거나 잘 수행되지 않으면 프로젝트에 어떤 식으로든 해를 끼칠 수 있습니다. 다시 한번, Discourse 팀의 힘든 노력에 감사드립니다
제 유일한 문제는 우리가 각자 자체 솔루션을 개발하는 경우가 많다는 것이며, 협업할 수 있는 유일한 방법은 여기서 업스트림으로 협업하는 것입니다.
실제로 한 가지 방법은 discourse_docker에 runit/anacron/nginx/postgres 없이 super_base라고 불리는 다른 이미지를 가지고, base가 super_base에 기반을 두도록 해서, 이를 우리의 k8s 배포에 재사용하는 것입니다. 이것이 작동할 것 같습니다
사람들이 정기적으로 여기에 포스트를 올리며, 그것들이 여기저기서 제대로 작동하지 않는다고 합니다.
제가 해온 일은 launcher를 사용해 이미지를 빌드한 후, 그 이미지를 리포지토리에 푸시하고 kubernetes로 배포하는 것입니다. 그리고 제로 다운타임 업그레이드도 스크립트로 만들어두었습니다. 제가 설정해준 클라이언트들에게는 이 정도가 과도한 투자(overkill)에 가깝습니다. 저는 (거의) 표준적인 설정(traefik이 여러 사이트를 리버스 프록시하는 것만 추가했을 뿐)으로 일반 하드웨어에서 월 300만 페이지뷰를 호스팅하고 있습니다.
다양한 플러그인 세트를 포함한 이미지 세트를 공개하는 것도 고려해봤지만, 문제는 그것들에 문제가 발생하면 여기서 지원을 받을 수 없다는 점입니다.
이러한 오퍼를 제공하는 것을 고려해 보고 있습니다(물론 ‘공식적인’ 것은 아닙니다). 하지만 여기에서 추가적인 지원 문제를 일으키지 않도록 해야 하고, 유지보수와 지원을 위해 들이는 시간에 대한 보상을 받아야 합니다. 이 두 가지 문제를 어떻게 해결해야 할지 잘 모르겠지만, 예산이 있으시다면 편하게 연락 주십시오.
. Advantage of being not-an-employee: my word doesn’t have to carry the weight of being Official™.