社区支持的官方 Docker 镜像

开发
21

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 :+1:. 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.

11 个赞
22

Thanks for creating this thread @pierreozoux!

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.

3 个赞
23

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 :slight_smile:

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.

7 个赞
24

大家好！

我来自一个规模较大的意大利社区，我们使用 Discourse 作为论坛工具。
虽然我们都热爱 Discourse，但也注意到在通过某种“标准”流程将其部署到 Kubernetes 时存在一些困难。

我完全理解维护者们的难处 :slight_smile: 我在开放网络基金会（Open Networking Foundation）工作了多年，最大的挑战之一就是将 CORD（我们最大的平台之一）从基于脚本的安装方式迁移到使用 Dockerfile、docker-compose 以及托管在 DockerHub 上的 Docker 镜像，并配合 helm-charts 进行部署。尽管这样做存在一定的顾虑，而且很难找到一种适用于所有场景的通用解决方案，但我可以肯定地说，从最初的部署开始，我们就切实感受到了其中的益处。

通常，最关键的一步是转变思维，让现有的工具发挥其最佳作用 :slight_smile: Docker 的安装流程是标准化的、简单易用且文档完善。而脚本往往是定制化的，通常需要额外的定制和维护。
此外，完全没有理由不能使用原始的 Docker 镜像或 helm-charts 作为 Discourse 的依赖项（例如 unicorn、postgres、redis 等）。

我建议先从基础入手（例如为每个组件提供 Dockerfile、docker-compose 配置，并设置 DockerHub 的自动构建）。一旦完成这些工作（包括相应的软件和文档修改），开发 helm-charts 将变得非常简单。

我非常乐意提供帮助，甚至可以一起通话，讨论上述方案的优缺点。

在简要调研过程中，我还注意到 Bitnami（在 Docker 领域非常知名）推出了一些镜像（https://github.com/bitnami/bitnami-docker-discourse#how-to-use-this-image）。我想知道这是他们独立开展的工作，还是与你们协调进行的。这可能是一个非常好的起点。如果你们与他们没有合作关系，我建议将其作为一个可行的方向。虽然不确定他们是否会免费提供支持，但这确实是一个可能性。
顺便一提，我已经在他们的仓库中提出了一个 issue，以了解更多已完成的工作（https://github.com/bitnami/bitnami-docker-discourse/issues/132）。

请告诉我你们的想法，以及我是否可以在任何方面提供帮助。

1 个赞
26

你好 @Luca_Prete，你查看过上面 @pierreozoux 的工作以及团队的回复了吗？

大多数 Docker 打包工作将需要与 pups 在 launcher 后台执行的操作相匹配，包括为 Postgres、Sidekiq 等进行一些自定义配置设置。@unteem 出于个人需求，按照 pups 为早期 Discourse 版本所做的操作进行了跟进。保持 Docker 镜像与官方发布版本同步颇具挑战性。如果能将整个流程展开，并以标准的 Docker 方式走一遍路径，将会很有趣。如果存在一条可行的路径可以采用标准设置，我想这里很多人都会非常高兴。

2 个赞
27

@hellekin 谢谢。

我还没有。我相信那里有很多内容，但我通常倾向于远离——至少在工作方面——单用户（而非社区支持）的工作，原因很简单：它们日后可能难以维护。

具体路径确实取决于平台的一些细节。

在我看来，针对您的情况，一个可能的解决方案是首先了解标准镜像（如 Postgres、Redis 等）如何在没有特定定制的情况下与 Discourse 配合使用。

我认为这一点很重要，因为它使您能够在任何安装 Discourse 的地方依赖外部标准服务（这些服务可以安装在物理硬件、虚拟机、某些容器上，或者以 Chart 依赖的形式安装在 Kubernetes 中）。

这些服务中的每一个通常都允许使用一些启动脚本来创建数据库等……这应该不会太困难。

然后，我会创建一个合适的 Dockerfile（这也自动成为希望在不使用 Docker 的情况下安装 Discourse 的用户的快速入门指南）。

接下来是 docker-compose.yaml（这基本上与 Bitnami 在其 GitHub 上公开的内容相同）。

到了这一步，您应该能够在几秒钟内，通过一条命令，使用标准依赖镜像，以“微服务”形式在笔记本电脑上启动 Discourse，而无需任何自定义脚本。

最后但同样重要的是 Kubernetes 的乐趣（几个 YAML 文件，可能打包成 Helm Charts 的形式），可以发布到官方稳定仓库，或者至少在流程的初期发布到您自托管的仓库。

28

@unteem 并非孤军奋战 :slight_smile: 我们是一起合作的。
我们之所以这样做，是因为我们托管了多个 Discourse 实例。
我们最初使用 Docker，现在已迁移到 Kubernetes。

我们将相关工作迁移到了 Log in to Librehosters 也参与其中）。我们计划在接下来的几周或几个月内加大对我们工作的宣传。

维护这项工作确实非常痛苦……为了修复我的构建问题，我在这个提交上 literally 花费了数小时甚至数天：

不管怎样，我们目前正在开发 Kubernetes Operator。我们首先从 Nextcloud 开始，然后是 RocketChat，接下来很可能是 Discourse。

在此期间，您可以在以下地址找到我们使用的 Docker 镜像代码：

镜像本身位于：

如您所见，我们近期在这方面投入了不少时间，因此我们已经有了标签和流水线。我们需要添加自动化功能以实现每周构建。

我们还有一个 Helm Chart：
https://git.indie.host/indiehost/helm-discourse
但正如您所看到的，它并没有得到很好的维护。

我可以说的是，这对我们来说运行良好 :slight_smile: 如果您想加入我们一起前行，并且感到跃跃欲试，欢迎随时加入我们 :slight_smile: 我们玩得很开心 :slight_smile:

我们实际上并不提供太多支持，因为时间有限，但如果您提交 PR，我们会非常欢迎。我真心希望我们能在官方的 Discourse 项目框架下开展这项工作，那样会容易得多。
但归根结底，我开始理解 Discourse 团队的做法。他们只支持一种社区工具，而且运行良好。他们为非技术用户提供了出色的支持，这真的很棒。如果出现问题，只需执行 git pull && rebuild，就能解决 99% 的问题 :slight_smile: 我理解支持另一种工具存在很大风险，如果支持不到位或实施不当，可能会在某种程度上损害项目。再次感谢 Discourse 团队的辛勤工作 :slight_smile:
我唯一的问题是，可能有很多人都在开发自己的解决方案，而目前唯一的协作方式就是向上游贡献。

实际上，一种可行的做法是在 discourse_docker 中增加一个名为 super_base 的镜像，不包含 runit、anacron、nginx 和 postgres，然后其他镜像基于 super_base 构建，这样我们也可以在 Kubernetes 部署中复用它？我觉得这样应该可行 :slight_smile:

您怎么看？

Discourse 有在使用 Kubernetes 吗？我很好奇 :slight_smile:

7 个赞
29

@pierreozoux 感谢您的回复！

我觉得你们做得非常棒，我很乐意尽己所能做出贡献 :slight_smile:

我还有更多时间仔细研究了 Bitnami 团队所做的工作。好消息是，他们已经将容器分离了。您有机会查看过吗？您怎么看？

以下是用于 Web 和 Sidekiq 容器的 Dockerfile：bitnami/discourse Dockerfile

我无法直接粘贴 docker-compose 的链接，但您可以通过我在该主题帖中之前发布的链接轻松找到它。

在同一仓库中还有一个 Kubernetes YAML 文件：https://github.com/bitnami/bitnami-docker-discourse/blob/master/test.yaml

从 Docker 镜像开始，您觉得有什么潜在问题吗？软件是否已经足够“更新”？

目前似乎缺少的是 Helm Chart，应该按照稳定版图表所采用的最佳实践来完成。

大家怎么看？是否有必要联合起来，将你们的文件整合到他们的工作中？

30

这完全等同于 DEV: Bump uglifyjs · discourse/discourse_docker@c87937d · GitHub 所做的更改。如果你正在 fork 这个镜像，建议考虑同时从上游仓库合并这些更改。

这基本上就是我们维持现状的动机。

添加任何我们内部不使用的功能，只会导致它们很快失效并被弃用，从而给依赖它们的每个人带来更多麻烦。我们在项目中已经多次遇到过这种情况。

如果社区愿意着手处理这个问题，那也没问题。

不，我们不使用 k8s。

6 个赞
31

只是需要维护的依赖项实在太多了。

人们经常在这里发帖说这些镜像以某种方式无法正常工作。

我目前的做法是使用 launcher 构建镜像，将它们推送到某个仓库，然后通过 Kubernetes 进行部署。我还编写了实现零停机升级的脚本。不过，对于我服务的那些客户来说，这显然是过度设计了。我在普通硬件上托管着每月 300 万次的页面浏览量，采用的是（大部分）标准配置（仅通过 Traefik 反向代理多个站点）。

我曾考虑发布一组包含不同插件组合的镜像，但问题是，如果这些镜像出现任何问题，用户将无法在这里获得支持。

5 个赞
32

这个话题有什么更新吗？是否有或将来会有可用于 Kubernetes 部署的官方 Discourse 镜像？

33

不会的。我使用的解决方案是：先引导新镜像，将其推送到仓库，然后启动它，待新 Pod 启动后，再执行升级后的迁移操作。

5 个赞
34

有更新吗？仍然没有官方的 Helm Chart 将 Discourse 安装到 Kubernetes？

1 个赞
35

还没有，这也不在我们的路线图上。

请参阅 Can Discourse ship frequent Docker images that do not need to be bootstrapped? 以获取背景信息。

36

我一直在考虑做一个这样的提议（而且它不会是“官方的”），但需要确保它不会在这里引起额外的支持问题，并且能支付我维护和支持它所花费的时间。我对此如何解决这两个问题几乎没有头绪，但如果你有预算，请随时与我联系。

1 个赞
37

我们已经成功地使用我们自己的 Docker 镜像通过 Helm 托管 Discourse 几个月了。
（之前我们也使用自己的镜像，通过 compose）

并且支持 s3/minio。

https://forge.liiib.re/indiehost/tech/infrastructure/charts/-/tree/master/discourse

（但文档确实不足，并且“开放”以开设账户和贡献。
如果有需求，在这里或私信，我们可以开放 :)）

@pfaffman 如果您找到乐意支持您时间的人，我们很乐意合作！

我们为一些小型社区托管 Discourse，主要在法国，属于共同体运动的一部分。
（例如 https://forum.chatons.org/ 是我们免费托管的最大社区）

6 个赞