Discourse 的官方“云原生”Docker 镜像

功能
1

您好，

团队最近取消了通过界面禁用长轮询的支持。这破坏了 bitnami docker 镜像所需的功能，该镜像使用 passenger 并且无法正常工作，请参阅 https://github.com/bitnami/bitnami-docker-discourse/issues/177。bitnami 镜像不直接传递环境变量，因此在有人扩展 bitnami 镜像之前，此功能将无法使用，请参阅 https://github.com/discourse/discourse/pull/16323。

当然，我有一个问题，因为 discourse 已经只通过 docker 容器分发：团队是否有机会维护一个“云原生”docker 镜像？

bitnami 镜像和你们的镜像之间最大的区别在于操作模式。现代基础设施期望您能够自动化安装。通常在 k8s 中使用 helm 完成，但在具有虚拟机的传统环境中，ansible 部署也会产生相同的结果。因此，要使 discourse 与相当被忽视的 bitnami 镜像相媲美，就需要添加一个自动安装程序例程，甚至可能调整 helm 模板。

既然我在这里，让我对 discourse 本身及其“云就绪性”提供一些反馈：

总的来说，当我们尝试将 discourse 整合到当前客户项目的可重复设置中时，很快就发现 discourse 从未在现代基础设施的方面进行过设计。一个例子是需要共享 NFS 存储。这既不可靠，也不可扩展。幸运的是，其中大部分可以重定向到 S3，但仍有一些部分是插件。

有三种方法可以解决插件问题：

  • 存储在数据库中的已评估代码（不推荐）
  • 预打包的 sidecar 容器（在 kubernetes 中，这些容器将用作 initContainers，在 discourse 容器启动前写入易失性存储（例如 tmpfs）（推荐，尽管不太方便）
  • 一个安装程序例程，在启动时从数据库获取当前插件信息及其安装命令，以及一个在运行时安装插件的监视器/侦听器例程（不推荐，因为速度非常慢且容易出错）
3 个赞
2

我认为这里已经对这个问题进行了广泛的讨论：

3 个赞
3

坦白说，既然 bitnami 已经轻松解决了这个问题，也就没有太多可讨论的了。让 discourse 易于部署并非难事。

4

我只想指出，我们在云环境中运行许多 Discourse 站点，并且我们不使用 NFS 存储。资产和上传通过对象存储 (S3) 处理，而源代码（核心和插件）则持久化在引导的容器镜像中。

4 个赞
5

这已经回答过了：幸运的是，其中大部分可以重定向到 S3，但还有一些部分是插件。预先构建一个容器来使用是一种糟糕的做法，因为它增加了通过使用的 Helm 图表无法正确升级的风险。

6

您能详细说明一下吗？我不明白插件如何需要共享的NFS存储。

7

非常抱歉，但我们已经有一个关于此的史诗级话题要讨论了。

我不想将此拆分。如果有任何想法，应该在以下位置讨论：

3 个赞