Oh man that’s tragic. So sorry to hear 
7 个赞
https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/8
@sam 和这个话题明确了，尽管 bitnami 刚刚解决了，但这永远不会被解决……
至少我们得到了问题的答案，那就是“否”。
首先，关于避免使用 root 的问题呢？使用 fakeroot 表明主要的障碍是硬编码的路径（例如 /var）。否则，除了当前设置存在的各种错误和问题之外，它本可以正常工作。
看到如此出色的软件却有着如此糟糕设计的强制性设置流程，真是令人遗憾，这基于对容器化普遍存在的误解。我清楚这是出于最好的意愿；然而，其结果是除了爱好者环境之外，无法在任何地方部署。
1 个赞
我们的镜像以 discourse 用户身份运行，我认为官方镜像也是如此。
但无论如何，很高兴“企业”界对此感兴趣，因为它比业余爱好者拥有更多的时间/金钱 
我相信社区会感谢您为改进生态系统所做的贡献！
1 个赞
这绝对不正确，我们使用 Nomad 将我们的镜像部署到机器集群中，此刻有超过 10000 个 Discourse 容器在 AWS 和 Metal 上运行。
3 个赞
这些工具需要 root 权限才能运行，并且需要访问主机的 /var。
我经常与开源社区和公司合作，以改进他们的容器设置。我很乐意提供帮助和/或考虑资助以获得更合理的容器化设置。
它不是强制性的。只是如果你需要指导来完成设置，那么这就是方法。例如，我曾帮助过使用 gke、eks、ecs 的客户。如果你需要帮助来满足你的特定需求，欢迎联系我。
/var 不是硬编码的；我最近与某人合作过，他将其放在 /var/www/discourse 中（这似乎是个非常糟糕的主意，因为它有将秘密数据提供给网络的风险，但这是“政策”）。
它并非设计糟糕，而是如果你今天而不是十年前设计它，它就是设计糟糕。它当时是一个好的设计，并且对于许多不懂系统管理的人来说，它仍然能很好地运行他们的基础设施。
2 个赞
我猜你没有依赖官方工具，比如 discourse-setup，它需要 root 权限才能执行，并且可能用于本地设置。
请查看 discourse-setup 源代码。如果您熟悉 Discourse 的配置和性能调优，则不是必需的。
Launcher 会完成所有繁重的工作，从生成的 yml 构建镜像。
2 个赞
一切都可以完成，但在我看来这是不必要的努力。
- 在每个命令前使用
fakeroot - 可以通过编辑 yaml 文件更改
/var：sed -i \"s;host: /var/discourse;host: $PWD/discourse;g\" containers/*.yml --skip-connection-test（通过查看代码找到，因为脚本无法在有反向代理时检查连接）- 我看到一些与 certbot 相关的东西，我知道我需要弄清楚如何禁用它，因为 SSL 卸载通常在外部完成
containers/app.yml的端口可以更改为使用>= 1024的端口，但这似乎还不够：Error starting userland proxy: error while calling PortManager.AddPort(): cannot expose privileged port 443
我不想说得很难听，但将多个服务运行在同一个容器中一直是一个糟糕的设计，因为它意味着几乎无法了解单个服务发生了什么，需要设置一个 Docker 外部的自定义日志解析机制，没有有用的健康检查，无法轻松依赖外部数据库等。如果这是你在业务中运行的唯一服务，那么这样做是可以的，但如果其他所有服务都开始这样做，使用容器的大部分好处就消失了。
我很乐意提交一些 PR 和文档，让 Discourse 在没有 root 访问权限的 Docker 兼容环境中运行，但分离服务并进行标准设置将是一项艰巨的任务，而且不能保证会被合并。
如果您不同意 Discourse 的基本构建方式，您是否考虑过使用其他产品？
3 个赞
好的，我明白了。
Discourse 对自托管工具的看法很强硬。这使他们能够为大多数想要部署 Discourse 的不太有经验的管理员提供有效的支持。你可以同意或不同意，我过去也有些难过，但现在我更理解了 
如果你有不同于大多数人所期望的快速启动和运行的需求，那么你基本上是孤军奋战。一旦你知道了这一点，那就没问题了
我们有同样的需求，需要一个独立的 Discourse Docker 镜像。我们在 Kubernetes 上使用 Minio 运行它，让它运行起来有点麻烦，而且仍然需要付出很多努力。我们得到了 Discourse 的一些很好的帮助才得以实现。
我们的工作可以在这里找到：
https://forge.liiib.re/indiehost/tech/infrastructure/charts/-/tree/master/discourse
（它没有足够的文档，也没有经过测试、维护或及时更新，也没有自动化，而且可能有点定制化，但就是这样）
如果有人有兴趣改进它，请随时来提交 PR，或在这里聊天：https://matrix.to/#/#libresh:liiib.re
但是的，Discourse 团队对 Discourse 社区版本有强烈的看法。你可以同意或不同意，但他们为大多数人提供了大部分支持，据我所知，这是非常出色的支持，所以我认为这是一个正确的决定
6 个赞
这些是 Discourse 的打包方式的基本方面，而不是 Discourse 本身，后者是一款出色的软件，但您说得对，我应该考虑不同的解决方案。
2 个赞
欢迎移除 PostgreSQL 和 Redis 的模板（以及 SSL 和 Let’s Encrypt），并使用您自己的模板。
2 个赞
谢谢分享。我还找到了 GitHub - literatecomputing/docker-compose-discourse: Launch Discourse with docker-compose and similar 和 bitnami 的镜像。主要问题是这些解决方案不受官方支持。我想知道是否可以有一个社区支持的替代 Docker 设置，而不是拥有各种自定义存储库，因为将精力分散在多个地方效率不高。
1 个赞
你说得对，设置确实可以更改。如果我能轻松地让它运行起来，我会尝试发送一些 PR 来改进现有的工具或文档，例如在不使用 root 的情况下运行它。这应该与开发团队的意见一致，同时也能让一些要求更高的系统管理员松一口气。
9 年过去了，看起来 Docker 的惯用方法已经被 Bitnami 的 Discourse 所涵盖？
但在本论坛的其他地方，有人声称它是一个内存占用大户且不受支持。我惊讶地发现，在云端运行它时，标准的设置仍然存在如此多的阻碍。
如今，许多服务，如 redis、postgres 和 s3 兼容存储，都易于在 digitalocean、supabase、aws 等不同主机之间进行设置和迁移，因此后端是可移植的。运行 Discourse 的虚拟机似乎也应该易于通过确定性构建进行扩展/替换。遗憾的是，它如此接近这个理想，却被阻碍了。
正如另一位用户所说，这令人惊讶：
线程前面提到的，使这更容易可能会阻碍商业机会的逻辑很奇怪。商业利益相关者将有员工来处理复杂的构建，所以这比任何人受到的影响都大。我的个人用例是我运行一个非常大的（无利润）社区。因此，它既不属于业余爱好者（按规模），也不属于商业（按收入）。
1 个赞
嗯……我正在考虑设置一个论坛/社区版块，很自然地想到了使用 Discourse（因为我喜欢最终用户体验），但又一次我遇到了完全糟糕的安装/管理障碍……
多年来，我非常喜欢用简单的 docker-compose 文件运行一切，添加一些额外的元素（数据库、用于 s3 兼容存储的 minio 等等），但不行……Discourse 在这方面仍然非常糟糕。
抱歉，但有一个愚蠢的“启动器”来启动东西？
然后升级过程说明：
通过运行以下命令手动创建新的基础镜像：
./launcher rebuild my_image
抱歉——手动重建镜像？搞什么鬼……这就像在使用/运行 docker，但实际上并没有使用它……
./launcher rebuild app 能用吗？这是常规命令。
另外，你是否遵循了标准的安装指南？
我没有什么建设性的意见，所以我请求你尝试升级 Mastodon 服务器、Pixelfed、Moodle…… Discourse 确实 难以置信地简单。
一个手动命令就是一个障碍 
2 个赞