您好，
有人能就如何构建一个内置了多个插件的 Discourse Docker 镜像（而不是通过用户界面安装）提供建议吗？
背景是——我们希望使用最新的 Discourse 构建版本，即 discourse:stable，根据我在安装指南和其他文档中所读到的，我们可以将其作为基础镜像放在我们自己的 Dockerfile 中，然后执行类似以下的操作：
RUN cd /var/www/discourse/plugins && \
git clone https://github.com/discourse/discourse-chat-integration.git
这将把 discourse-chat-integration 插件添加到构建中。然后在运行时，我们可以传入所有必需的环境变量，例如 DISCOURSE_HOSTNAME、DISCOURSE_SMTP_DOMAIN、DISCOURSE_DB_HOST 等，而不是将它们硬编码在 app.yml 文件中。
如果有人能就以上内容提供建议，将不胜感激。
谢谢。
你不能从 UI 安装插件。你从 YML 文件中安装它们。如果你使用的是你自己没有用启动器（launcher）构建的、尚不受支持的容器，那么你会做你建议的类似的事情。
但那个插件在核心（core）中（但可能还没有在稳定版中？）。
它们实际上并没有硬编码在 YML 文件中。YML 文件用于构建和启动容器。你可以构建它，然后以你想要的任何方式启动它。你可以使用 ./launcher start-cmd container-name（或者类似的东西，你可以查看启动器以查看我是否弄错了）。
所以我想你想要做的是继续使用启动器，添加插件，对容器运行 ./launcher bootstrap app，然后以你想要的方式启动它。你甚至可以将其推送到一个仓库，这样你就可以从其他机器启动它。
是的，我想可能已经没有稳定版了，至少也不会持续太久了。请参阅 RFC: A new versioning strategy for Discourse
非常感谢以上信息。
所以，我们希望在 Kubernetes 集群中运行 Discourse，并希望能够在 CI/CD 工作流程中构建镜像，因此需要自定义 Dockerfile。所有环境变量随后都通过 ConfigMap 和/或 Secret 提供给正在运行的 Pod。我知道这不是受支持的安装方式，但我们至少想使用受支持的方式来构建特定版本的 Discourse 镜像，以便我们可以控制更新时间。
查看现有的 launcher 脚本和 samples/web_only.yml，我认为可以注释掉 volumes 和 links 部分，因为这些将在 Kubernetes 中使用持久卷 (Persistent Volume) 和挂载来完成。然后，我们会在 web_only.yml 中添加固定的环境变量值，使用 bootstrap 命令构建容器，然后将生成的镜像复制到我们自己的仓库中。
对于 Discourse 版本，我们可以监控 Docker Hub 上何时有新版本发布，然后修改 web.template.yml 文件中的 base_image 值。
这样听起来正确吗？
也许可以，但容器通常需要与某个数据库通信才能构建容器。它不需要是实际的数据库（但那样你需要在管道中迁移数据库和预编译资产）。
你可能将 Discourse 升级与基础容器中资源的更新问题混淆了。
如果你不介意使用最新版本，可以参考这个：Is Docker image discourse/discourse considered safe and production-ready? - #14 by JackNZ
我确实设法在没有 db:migrate hook 的情况下成功构建了容器——我不确定它是否会起作用，因为我还没有测试过——这在待办事项列表上 
对于 base_image 值——我假设当发布新的 docker 镜像时它会改变，所以我想我将只采用 main 分支上的内容，因为启动脚本中调用的就是它。
我会查看另一个帖子 
那是个好的开始！在启动新的 Discourse 实例时，您仍然需要迁移数据库。
如果您没有升级 Discourse，就没有理由获取新的基础镜像。所以你并不真正关心是否有新的基础镜像。
谢谢 Jay。我的构建终于成功了，至少 Pod 启动了 我通过使用一个临时数据库更改了我的 CI/CD 构建流程，加入了 db:migrate。
db:migrate 是否总是在启动时执行，因为我的镜像构建将针对一个虚拟数据库/Redis？我目前的方法是在我的 Pod 中的一个 initContainer 中执行 db:migrate 和预编译。
如果 discourse/discourse 镜像很快就能投入生产使用，使用它将是理想的选择。
那应该可行。
如果你对零停机时间升级感兴趣，你应该使用 SKIP_POST_DEPLOYMENT_MIGRATIONS，在旧的 pod 停止后，再用类似 rake db:ensure_post_migrations db:migrate 的命令执行一次迁移。
非常感谢Jay迄今为止提供的所有帮助。
我还有另一个问题
目前，我在部署中设置了几个环境变量，例如 DISCOURSE_BACKUP_LOCATION=s3，我的理解是 Discourse 会使用该值而不是通过 UI 设置并存储在 site_settings 表中的值——这是正确的吗？如果是，是否有任何工具/脚本可以让我检查设置了哪些环境变量并确定其等效的站点设置？
原因——我正试图迁移一个正在运行的 Discourse 实例，为了帮助最小化风险，我暂时不想设置这些环境变量，以防我在新实例中遗漏了任何一个，从而对新实例产生不利影响。我的想法是，我可以检查当前实例中设置了什么，在表中创建相关的设置，备份/恢复到新实例，然后一次一个地移除环境变量。
这听起来合乎逻辑——也许不是，但我认为这是最明智的方法，以防运行实例中的环境变量在新实例中不同/不受支持（运行中 = 旧版 Discourse，新版 = 最新版 Discourse）。
差不多。它们会覆盖数据库中的设置。它们会被写入 /var/www/discourse/config/discourse.conf 或非常类似的文件中。
太棒了。感谢 Jay 提供的所有帮助——这确实是成败之间的区别，让这次部署得以成功