目前，当我们进行任何类型的维护（除了简单的更新）并希望将网站离线或设置为只读时，无法向访客提供有关正在发生的情况或系统预计不可用多长时间的说明。
我已经通过 此处描述的 Nginx 方法 创建了一个离线页面（并参考 此处 和 此处 的步骤对其进行了改进），但……
如果能有一个全面的离线模式，让管理员在停机期间向来访用户发布状态更新和消息，从而管理预期，并让用户对当前情况感到安心，而不是猜测可能发生了什么，那就太好了。
为了留存记录，以下是 @jomaxro 提出的引发此次拆分的原始评论：
这里真正需要做的是集成一个离线/维护模式，该方法应包含上述技术，并允许在系统处于离线和/或维护模式时向用户发送自定义消息。
这或许可以集成到升级管理器中（将“升级管理器”重命名为“Discourse 系统管理器”，并将升级、日志、进程和备份全部整合在此区域）。
这将使系统更稳定、更友好，对管理员和用户都更有用。
Docker Manager 是我们官方支持的升级插件，它不会导致任何停机时间。因此，通常无需对该插件进行任何更改，因为它已经支持无停机升级。本 howto 所解决的问题是通过命令行执行的升级（重建）。这类操作一年仅需进行几次，通常在我们需要升级底层依赖项（如 Ruby 版本或 Postgres）时才会进行。
无法让 Docker Manager 处理此类升级，因为在重建期间，Docker Manager 和所有 Discourse 组件都会处于停机状态。任何解决方案都必须位于 Discourse 之外，例如本主题提供的 Nginx 代理解决方案。
嗯，我认为这里还有其他方案，能更好地与 Discourse 的特性相融合……与其直接否定这个概念，不如我们来探讨如何在此方面提升整体体验，尤其是当管理员出于某种原因需要关闭站点进行维护时。 有一个想法：为什么不将 OP 提到的 Nginx 代理方案整合到 Docker 部署中呢？这样对于 Discourse 的用户、管理员以及支持人员（比如您这样在论坛上的朋友）来说，方案会变得更加可预测、易于管理且一致，而不必处理像这里提出的那样解耦的解决方案。
我并非要否定这个想法，只是想说明使用 Discourse 插件来解决这个问题行不通。让我将讨论移至专门的 #feature 主题以便深入探讨。
@ mreach，请编辑原始帖子，详细说明你的需求以及你希望其如何运作。如有需要，也可以随时修改标题。
如果您希望在执行 ./launcher rebuild app 时尽量减少停机时间，您需要采用多容器架构。
这已有文档说明。这是一个更复杂的配置。
若要在单容器模式下让 launcher rebuild 显示“离线”页面，我们需要用一个专门的“站点离线”容器替换当前容器。这并非不可能，但需要大约两周的工程开发时间才能完美实现。考虑到容器重建的频率极低，且我们已有文档说明如何实现无中断的重建，我认为目前无法为此投入资金。
我同意 Sam 的观点：如果你有能力制作一个“站点已宕机”页面，那你更应该把时间花在确保站点根本不宕机上。不过，也许你确实需要这个：https://meta.discourse.org/t/adding-an-offline-page-when-rebuilding/45238。
大多数情况下，双容器安装方案可实现最小化停机时间的升级。有时，构建新容器时会执行导致运行中站点崩溃的迁移操作。虽然有一种方法可以规避，但相当复杂，而且这类更新发生的频率很低。
你也可以重定向 DNS（或使用弹性 IP，或 Digital Ocean 称之为“弹性 IP
顺便问一下 @jomaxro，你是怎么把我的帖子拆分到这个新话题里的？你具体采取了哪些步骤？了解这些会非常有用……我在默认的 Discourse 中没看到相关的操作方法。
哦，不错，在那之后我在这个话题上摸索时，肯定漏看了5次。