关于更新 Discourse 源码、操作系统级依赖、Docker 基础镜像、Ruby gems 等，可以通过两步构建来实现，并在第一步中执行上述任务。
这一步与具体环境无关，甚至可以在 CI 环境中运行（因此您可以在测试环境和生产环境中使用几乎相同的镜像，避免因在不同日期重新构建而可能产生的错误，更不用说减少了停机时间）。
数据库迁移和 assets:precompile 任务仍需在目标机器上执行。数据库迁移在大多数情况下速度很快。另一方面，assets:precompile 是个问题，因为它是耗时最长的步骤。我认为这是因为某些资源需要依赖数据库中定义的环境信息（例如一些 CSS 规则）才能执行。
如果能够将此任务拆分为两部分，其中所有不依赖环境的资源先运行（可以在 CI 环境中执行），第二步仅编译那些依赖数据库等环境信息的资源，那将非常理想。不过，我不清楚从技术角度实现这一方案会有多大难度。
我在以下主题中讨论了分两步引导应用容器的方法：
我所做的更改仅涉及将 Discourse Web 模板拆分为三个文件，但任务本身保持不变。不过，如果 Discourse 团队能够原生支持这一方案，我将无需因 Web 模板的未来变更而手动更新这些内容。