请注意，不要假设用于更新的 Web 界面总是可用的。通过网页进行更新并不总是能成功。某些更新（例如最近更新的数据库版本）需要通过命令行重新构建。这意味着你需要通过 SSH 访问服务器，并使用命令行进行重新构建。
与许多管理员不同，我通常使用 Web 界面进行更新，但我也会保持一个 Shell 窗口处于打开状态，以便在必要时手动运行更新。
所以我走完了整个流程，多亏了 Discourse 的机器人帮忙，这让事情稍微轻松了一些。因为那个原始主题“从独立容器迁移到分离的 web 和数据容器”似乎是十年前写的，我不想把事情搞砸。
经过几轮问答，并做了大量笔记后，我觉得自己对事情的理解稍微深入了一些。我的安装正在运行，所以我想一切应该都已经正确配置好了……？
机器人告诉我，当我需要更新某些确实需要我通过 SSH 操作的内容时，应该按照以下顺序进行：
# 这将花费大约 20 分钟（首次）；之后通常只需 5–15 分钟
# （并非精确的首次引导时间——docker 在后续重建时会缓存层）
sudo ./launcher bootstrap web_only
# 引导成功后，运行：
sudo ./launcher destroy web_only && sudo ./launcher start web_only
# 偶尔检查磁盘空间：
df -h
# 如果由于旧的未使用镜像导致磁盘空间不足：
sudo ./launcher cleanup
然后我就大功告成了。
那个“一年一次”的更新稍微复杂一些，但我也为此做了笔记，我只需要整理一下这些笔记，因为我现在还用不到它们。
上面的工作流程是正确的吗？
感谢大家分享你们的反馈！
请问能否制定一条简单的规则，让我能够考虑到这一点，并知道何时该使用哪种可用的更新选项？
我不是专家，其他人对这些事务的了解比我多得多，但……根据我的经验，永远不要指望通过 Web 界面成功完成升级，始终准备好通过命令行进行重建。最近从 PostgreSQL 15 升级到 18 的过程在这里有详细说明，那是一次毫无悬念的失败，你知道你不可能仅靠 Web 界面升级就蒙混过关。
这其实没那么难，你可以把 Web UI 升级看作是一种便利功能，如果它起作用了……那很好，但要做好它不起作用的准备。至少当它不起作用时，它会给你一个信息丰富的解释，说明发生了什么以及该如何修复。这里许多专业的 Discourse 管理员会告诉你甚至别去尝试。我的论坛规模小、流量低，我输得起，你可能没有这种奢侈。
这些天我在这边发帖不多，但如果你需要关于设置双容器的帮助，或者有任何问题，随时给我发私信。我目前运行着两个独立的双容器论坛，背后都用了 Cloudflare CDN 和兼容 S3 的 R2 对象存储。是的，它确实比单容器复杂一些，但并没有很多人想象的那么难。维护起来超级简单，你还可以用 bash 脚本来让更新变得更加轻松。