这是关于我发布的组合示例为何不使用通用 PG 镜像的说明。
嗯……但您不认为这会让其他方式变得更复杂吗？
明白了！ 
作为一名 Docker 大师，这对您来说应该都很容易吧？
3 个赞
正如我过去几天一直在解释的那样，有了当前提供的解决方案，一切都变得不那么容易了 
长话短说；
一个简单的 Discourse 镜像（类似于 bitnami 的镜像），加上一堆环境变量来配置基本的东西（比如访问 redis、数据库），就足够了，但出于某些原因，这完全不可行…… 
我在这里分享概念验证，以实现这一目标。
对于一个简单的插件来说，当然可以，但我们不能假设一个插件会是某种样子——有些插件需要额外的设置、需要安装额外的 gem、额外的 gem 依赖项或需要 apt-get install 的外部程序。这些都应该被整合到自定义镜像中。
很高兴看到这个实现，但这并非易事。
关于 Web 更新，Discourse 操作员也不需要了解 CLI 或 docker。
1 个赞
你只需要用启动器（你可以通过 GitHub Actions 来获取）构建自己的镜像，将其推送到一个仓库，然后用环境变量启动。你仍然需要迁移数据库、预编译资源并将它们推送到 S3。你可以迁移数据库并 skip_post_deployment_migrations，这样旧容器就可以在新的容器启动和运行之前继续工作，然后关闭它并运行其余的迁移。但这对于一个比你想要了解的更不了解 Discourse 的人来说太复杂了。而且有很多很多事情可能会出错，这就是为什么目前的解决方案，尽管存在你所说的所有糟糕之处，但对于成千上万不知道 bash 是什么的人来说，却是最好的解决方案。
在大多数情况下，你只需要运行 ./launcher rebuild app，除了每几年需要升级一次数据库时，你必须执行两次。你无法通过 docker-compose 获得这种级别的简单性。如果 docker-compose 在他们开始时就可以使用，他们可能会选择它而不是自己制作，但这并不是事情的发展方式。
如果你想使用 Bitnami 镜像，你可以这样做，但在这里你得不到太多帮助。我敢打赌它对很多人来说也很有用。
1 个赞
嗯……对于一个应该通用且与平台无关的语言/环境来说，依赖底层的操作系统包管理器似乎相当奇怪……
这正是我之前提到的，Discourse 似乎非常固守于管理 PHP 软件/论坛的“旧”方式
所以，总结一下整个讨论（也许可以把它放在第一条消息中，避免反复讨论）：
- Discourse 是为“普通人”量身定制和专注的，整个设置都是为了满足他们的需求
- 考虑到 Ruby（环境）有点奇怪，以及（1）在官方 Discourse 仓库中提供足够通用的官方 docker 镜像几乎是不可能的
正确吗？
我会稍微换种说法
鉴于没有官方镜像（默认情况下）提供除启动器之外的其他设置 Discourse 的方式，这使得启动器成为默认的，基本上是（推荐的）设置 Discourse 的唯一方式，有人可能会争辩说原始陈述仍然有效
但这只是文字游戏。
无论如何——主题是：
Discourse 能否提供不需要引导的频繁 Docker 镜像？
从整个讨论来看，似乎是：“不，Discourse 不能/不想提供不需要引导的频繁 Docker 镜像”，证毕。
因此，建议在顶部添加一条评论，说明不会提供此类镜像将节省大量麻烦
这是一个不正确的假设
我们尚未优先发布包含一组特定插件的官方镜像
我们正在考虑这项工作，我们有很多关于如何做到这一点的想法，这仅仅不是公司的优先事项
5 个赞
另一位同事的翻译：“未来可能会发生，也可能不会……鉴于它不是优先事项/不在路线图上，发生的几率微乎其微”
不过，更严肃地说——这种带有合理插件捆绑包的基本设置将非常酷！
感谢您的意见！ <3
供您参考 - 我已经设置了一种方法，可以在开发环境中构建 Discourse 镜像，并将其部署到服务器，从而无需使用启动脚本。
有关更多讨论，请参阅我创建的拉取请求中的此处。
我设置此项的方式使其与 Discourse 的官方 Docker 设置完全兼容，因此您不必担心此解决方案会失去支持或中断。
关于此工作原理的 TLDR 是，我让 Docker 镜像负责在启动时执行引导命令（而不是 launcher 脚本）。
1 个赞
很棒的方法。
另外：有趣的 launcher v2 (GitHub - discourse/launcher: Discourse Launcher CLI)！
2 个赞