我已经阅读了像 这个 这样的帖子以及其他相关讨论，看起来到目前为止，还没有一种简单的方法可以将 Discourse 镜像部署到 ECS、GKE 或任何您喜欢的容器编排平台并使其轻松运行……
我使用 Terraform 来管理 Elasticache 集群、RDS 实例和 ECS 集群。我只需要能够说：“这是我的 Discourse 镜像，以及用于连接 Postgres、Redis、SMTP 等的环境变量。”
2020 年有类似这样的解决方案吗？似乎之前所有围绕这一话题的讨论都没有得出令人满意的结论，我们仍然受限于 Discourse 的自定义脚本，这些脚本违背了容器惯例，并且破坏了与人们使用容器的惯用方式之间的兼容性……
我两天前回复了一个类似的问题
这是一个错误的假设。所有这些都是 Discourse 的组成部分，需要在容器内由 Discourse 进行控制，以确保成功部署。
如果你进入复杂的多容器场景，那仅对拥有大量资金的大型客户是_必要_的，我建议你使用我们的企业托管服务。
但为什么这需要那个奇怪的引导脚本来启动容器并充当编排器呢？
为什么 Discourse 镜像不能接受环境变量，并在其入口点中主动连接所有那些资源、创建所需的表等？其他依赖外部持久化层的服务/Web 应用已成功以这种方式容器化。你只需将它们部署到 ECS、EKS 或类似平台，告知它们数据库的位置等，一切就能顺利运行。Discourse 是否也能这样操作？
正因为我们是相反的情况——一个没有大量预算的非营利组织——所以我们希望尽可能降低成本，将所有企业应用部署到单个 AWS ECS 主机上。但这要求各个应用能够被良好地容器化，并能定义为 ECS 任务定义，即自包含的 Docker 镜像。
嗯，算是吧——既然 Discourse 可以轻松部署在每月 5 美元的 VPS 上，只需一个标准的单 Docker 镜像安装，那么为了从这笔费用中挤出几分钱，却大幅增加安装难度和后续维护复杂度，真的值得吗？保持简单吧！
如上链接所述，您可以构建容器并使用 Kubernetes 启动它们。我曾为一些客户部署过 GKE，他们坚持这样做是因为他们被该平台绑定。
如果您的目标是节省成本，那么每月 5 到 10 美元是最佳选择。
我们的工具针对最普遍的用户群体进行了优化：即没有专门 IT 人员来管理容器编排的小型团队。
不过，如果你需要全面上云，相关功能也是可用的。可参考的源代码仓库是：
其中的 samples/web_only.yml 文件展示了如何使用外部资源。
此外，launcher 脚本也支持通过 bootstrap 子命令构建自定义的 Docker 镜像。