我的更新过程中出现了一个错误
api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
请帮我修复它。
嘿！
我不是在回答你的问题，只是出于好奇。你为什么觉得需要维护页面？设置起来似乎挺麻烦，而且收益甚微。
我的实例每个月停机更新大概5分钟，基本上就这样了。
每当我进行重大更改，例如安装插件时，有时需要花费20分钟。
考虑到这些操作并非每周甚至每月都要进行，这倒不是什么大问题。但对于新访客来说，看到那个显示“某些功能无法正常工作”的丑陋页面，并不会留下良好的第一印象。即使是那些不知道网站会停机的老访客，也可能因此陷入“恐慌模式”，以为整个社区被关闭了或发生了其他严重事故，其中一些人甚至会立刻发邮件问我到底发生了什么。
我认为，无论是新访客还是老访客，告知他们当前正在发生的事情，都是一个贴心的细节。
如果Claude提出的这种方案只需花费几分钟，且之后无需再频繁调整，我相信这绝对是一笔值得投入的时间。
我在 Cloudflare CDN 后面使用了 双容器构建。双容器最大限度地减少了停机时间，我的两个主要生产论坛在重建期间最多离线 30 秒。我喜欢使用维护页面，因为默认的 Web 服务器停机页面很难看，而且无法提示用户离线时间有多长。
相关文档现已发布在此：
哇！我非常感谢你提供的详细步骤！
我已经把你的回复保存到我的笔记里了，这样当我不久后再次安装 Discourse 时，就可以回来参考。我一定会告诉你进展如何，即使安装过程需要花一些时间。目前我正在完成一些编码工作，之后才会重新专注于 Discourse。
我也同意“web serve is down”页面很难看，而且对于没有经验的用户来说，这条信息意义不大。拥有一个带有自定义消息的简单维护页面总是更好的选择，即使这需要一些设置工作。
再次非常感谢你抽出时间分享这些。希望其他人也能从中受益 
问题就在这里。
这并非一个简单的改动，还涉及需要担忧和维护的额外基础设施，恕我直言，为了几秒钟的停机时间，这完全 不 值得。
我明白你的意思，但那只是其中一种情况。如果真的出现严重故障，我需要花更多时间（不止几秒钟）来修复怎么办？
另外，你是怎么做到只有几秒钟的停机时间的？我安装插件后，看到的停机时间大约是20分钟。
因为在双容器设置（我们在帖子中都链接了，且是不可或缺的依赖项）中，你使用 ./launcher bootstrap web_only 引导新构建（在此期间你的网站仍保持 100% 正常运行），然后你只需销毁并立即启动刚刚构建好的新容器（这只需几秒钟）。
哦，好的，那还是针对双容器部署方案的。我原以为你是在说完全搭建双容器部署方案不值得费这个劲。你的意思是，不值得做的只是那个维护页面所增加的额外工作，对吧？
个人而言，是的。
如果你希望为在30到60秒内通过全新导航出现的网页访问者提供双重保障，那么使用维护页面是合理的。
你需要权衡这样做的好处与维护相关基础设施所需的时间。
现在我明白了。谢谢。
那么我现在想问：使用 2 个容器时，那大约 20 分钟的时间依然存在，唯一的区别是我可以在非实时运行的那个容器上执行操作，等准备就绪后再进行切换。是这样吗？
是的，构建容器仍然需要一些时间。顺便提一下，你需要确保你的服务器配置足够强大，以便在正常为社区提供服务的同时，能够并行进行该构建过程（最关键的是确保有足够的内存——因此务必确保你有足够的交换空间）。构建过程还会占用至少一个 CPU 核心，因此建议你的服务器拥有多 1 或 2 个核心。
对于这种配置，我建议至少使用 4GB 内存和 3 个核心（“vcpu”）……
作为参考，因为有人在另一个话题中问过，（编辑：错误）答案是：Any cheaper alternatives to Hetzner? - #2 by Canapin
这是唯一符合要求的……价格差异真大……
我想我现在得先用单个容器搭建，等时机成熟（
）再升级。
谢谢你的信息，Robert！
我持不同意见，我认为设置维护页面是值得的。根据我的经验，当用户看到 Discourse 错误页面时，他们做的第一件事通常是刷新页面，随后会看到简短的维护页面，并在容器切换完成后自动重新加载网站。设置起来并不复杂，而且只需配置一次。在采用双容器配置进行重建时，引导阶段会在后台进行，用户仍可使用网站；导致短暂停机的是容器切换过程（这与标准的单容器配置不同）。
服务器成本和选择是完全不同的问题，应该放在另一个独立的话题中讨论。
我想我现在处于中间立场。我理解你的意思，也理解 @merefield 的观点。拥有这个功能确实是个不错的点缀，而且如果只需设置一次，我想也不算什么大碍吧？
同时，如果最坏情况下确实需要长达 60 秒，并非每个人都会在 0 秒整访问网站并被迫等待 60 秒。有些人可能会看到丑陋的页面 5 秒，有些 20 秒，有些 60 秒。甚至有些人根本不会看到它（我想是这样？），例如，如果他们只是在阅读回复或撰写回复，这个切换可能在他们点击“发送”之前，或者在他们停止阅读主题并点击“回复”（或访问其他页面）之前就已经完成了。
我对 nginx 路由方案的顾虑，更多是与单容器设置中 20 分钟的问题有关。既然可以选择使用 2 个容器，并将时间从 20 分钟缩短到最多 60 秒，我在想这是否真的还重要？尤其是，如果我能够在顶部添加一个公告，说明服务将在低流量时段短暂中断几秒钟，这应该就不会成为大问题了吧？
我得坐下来好好想想。不过，如果我能找到划算的服务器优惠，双容器设置肯定是我打算实施的方案。
你能否用我能理解的简单方式解释一下？我对 Workers 还不太熟悉……
如果一直保留没有问题，为什么还要添加和删除 Workers 路由页面呢？所以，如果我添加了维护页面，我是否真的只需设置一次，之后就可以一直通过终端 SSH 连接到服务器，像操作单个容器那样在那里完成所有操作，而无需再访问 Cloudflare？
@merefield 提到维护页面、Workers 等也需要维护，所以我想知道这真的是“设置后就不用管了”的东西，还是说偶尔需要做一些操作？