我想就最小化或消除停机时间来执行 Discourse 实例核心维护任务的最佳实践展开讨论。
像更改关键资源设置（例如 UNICORN_WORKERS、DISCOURSE_SIDEKIQ_WORKERS、DISCOURSE_DB_POOL）或应用主要更新之类的任务通常需要 launcher rebuild app，这可能需要相当长的时间，有时甚至超过 30 分钟。
我的问题是：
系统管理员有哪些推荐的策略可以最大限度地减少用户可见的停机时间来执行这些重要的更新和配置更改？
是否有任何高级技术，例如蓝绿部署或其他零停机部署策略，是 Discourse 支持或推荐的？或者标准的 rebuild 过程是唯一支持的方法，重点应该放在优化重建时间本身？
我很想听听任何有管理大型或高流量实例经验的人分享他们的维护工作流程。
感谢您的任何见解！
如果您有两个容器的安装，新容器会构建而旧容器会运行。停机时间仅为启动新容器所需的时间。唯一的问题是您需要足够的内存来在另一个容器运行时构建一个容器。
从独立容器迁移到独立的 Web 和数据容器，但我通常会迁移一个新的虚拟机。
如果您想要零停机时间，则需要一个负载均衡器，该负载均衡器在启动新容器之前一直保持旧容器运行。然后，您可以关闭旧容器并执行更新后的迁移。
故障转移时可以有两个数据容器吗？
你通常会为数据使用单独的虚拟机吗？
Discourse 非常稳定，对于大多数安装来说，这几乎是不必要的（但我想您可能会考虑它用于非常高的可用性要求，或者如果您托管其他人？！）
我想我 7 年来从未因生产“故障”而出现过任何中断……
Discourse 在生命周期中最危险的时刻总是重建时。
两个容器的设置使您能够在提交之前引导新的构建，尽管这当然无法捕获一些运行时错误。
问题是，如果您的迁移已运行，您可能需要提交到新的构建，因此您通常会尝试跟踪并修复这些错误的来源，而不是回滚。
通常人们不会尝试回滚……
我会在进行大规模重新配置时迁移到新的虚拟机。
可以运行 PostgreSQL 镜像，但这需要大量工作。
只读副本会不会更好？
是的！复制品！他们用的就是这个词。然后，如果另一个坏了，你就可以热插拔到复制品上。