我注意到任务 rake assets:precompile 需要数据库连接：这意味着该任务只能在“运行时”（部署后）执行，而不能在“构建时”（构建容器镜像时）执行。由于该任务耗时较长，这可能会带来不便。
由于我不是 Ruby/Rails 开发者，我做了一些调研，发现这种行为在 Rails 4 之前可以被禁用，而此后开发者们不得不采用一些变通方法（例如使用空数据库连接）。当然，后者需要对应用程序有深入的了解，以避免破坏任何功能。
在寻找更好的解决方案时，我发现了这个提交，其理念似乎与此类似。因此，我的问题如下：
我们将主题存储在数据库中（在管理界面中进行编辑），因此 CSS 内容位于 PostgreSQL 中。因此，您需要在构建时建立数据库连接，才能对这些内容进行预编译。
感谢您的信息！
是否可以考虑将本地化文件的构建单独实现（在构建时运行）？
此外，我可以想象某些环境（至少对我来说是这样）可能不希望允许更改主题：在这种情况下，是否有可能为 CSS 提供替代的存储方案？
我们曾讨论过一种开关，用于禁用整个自定义界面（Customization UI），从而允许在构建时编译 CSS 文件，并在构建过程中将其上传到对象存储（即与 JS 核心/插件相同的处理方式）。
然而，这是一个非常小众的场景，仅对具有企业级部署需求的用户有吸引力，而对网络上 99% 的社区毫无价值。因此，这不在我们的路线图之中，且与开发新功能或性能优化工作相比，投入资源在此项目上很难说服团队。
能否请您提供更多关于您的环境和用例的信息？
很高兴得知这个想法已经被讨论过。我理解，进行这项变更所需的工作量可能过大，难以证明其合理性。
在我的情况下，Discourse 将与一个现有网站关联，因此会有一个固定的自定义主题以匹配该网站的风格：动态更改它并无意义。
哦，我指的是在“构建时”无法连接到数据库的使用场景。
哦，好吧，当我构建镜像时，我是在开发笔记本上操作的。镜像随后会被推送到仓库，最终的系统（DigitalOcean 上的 VPS）会从中拉取。数据库位于 VPS 的卷中，因此无法在我的笔记本上更新：这需要我停止 Discourse，将数据库通过 rsync 同步到笔记本上，构建并推送镜像，最后再重启 Discourse……
所以您是在同一个 Droplet 中同时运行数据库和应用程序吗？
在这种情况下，遵循我们的官方安装指南即可。该指南会在同一个 Droplet 中部署应用程序和数据库，从而为您提供一个功能完整的站点。该站点支持通过 Web 界面进行更新，也可选择通过命令行配合完整镜像重建的方式进行更新。
如果你是指“直接运行在宿主机上”，那并不是。它们运行在容器中，具体来说是 podman 容器。理想情况下，我会将容器拆分为多个（一个用于 Discourse，一个用于 PostgreSQL，一个用于 Redis……），但这与我们正在讨论的问题相关，因此我目前还不确定正确的行动方案。
这在我看来不太安全。我通常会在部署到生产环境之前，先在开发环境中测试容器。此外，理想情况下容器应当是只读的。
你可以拆分这些容器，然后在另一个短暂存在的 Droplet 中运行镜像引导过程。由于 Droplet 按小时计费，这将非常便宜。你甚至可以利用 Droplet 私有网络，在数据库容器主机和“构建”容器主机之间进行通信。
哈哈，谢谢你的建议，但这会变得复杂。此外，这无法解决问题，因为我们仍然需要停止 Discourse 并等待引导过程，否则可能会出现数据不一致的情况。
看来我们只能接受升级时的长时间停机（迁移和预编译需要 5-6 分钟）。不过，如果你能在问题追踪器中保留一个低优先级的议题，并附上本话题的链接，我会非常感激。
谢谢，并继续加油！
[quote=“matpen, 帖子：12, 主题：126779”]
看来我们在升级时需要忍受较长的停机时间（迁移和预编译需要 5-6 分钟）。[/quote]
不，情况并非如此。
[quote=“sam, 帖子：2, 主题：40341”]
如果重建时间是你非常关心的问题，我强烈建议你运行一个专用的数据容器。
这样，你可以在现有站点运行期间进行引导，这意味着通过启动器升级时，你只需面对几秒钟的中断。[/quote]
这应该只有“几秒钟”，而不是 5-6 分钟，但你需要专用的数据容器和 Web 容器。这取决于你想优先保障什么。
此外，根据基准测试，在快速服务器上重建大约需要 3 分钟。
好的，明白了，谢谢。在这种情况下，我肯定会拆分容器，这本身也是更优的架构。
不过，我不太明白这会有什么区别？如果我没记错的话，所有容器都会共享宿主机的所有 CPU（除非另有配置），因此在这两种情况下，进程都应该并行运行。我是不是漏掉了什么？
在旧容器运行期间，新容器正在启动。之后，您可以快速关闭旧容器并启动新容器，从而缩短停机时间。