如果您通过用户界面进行更新，最终会收到一条消息，提示您必须进行命令行更新。这取决于基础 Discourse 镜像，而不是 Debian。
2 个赞
而且使用两容器方法根本不会有 GUI 更新按钮，对吗？
GUI 更新来自 discourse_docker 插件。如果您有该插件，您就有 GUI 更新。
当在图像处理工具中发现漏洞时，过去确实发生过远程代码执行，这意味着你离系统被入侵仅一步之遥。
Clear Linux 为 Linux 的启动速度设定了标准。这是了不起的工作，我全心全意地支持。
1 个赞
哦，那确实改变了一些事情。出于某种原因，我一直认为 GUI 更新程序无法与非标准的 2 容器安装配合使用。在这种情况下，只要管理员技术能力过硬，2 容器安装似乎就没有太多缺点。我肯定想要 GUI 更新，例如，如果我只带手机旅行，并且有重要的 Discourse 安全更新发布，我至少可以在没有 SSH 访问权限的情况下进行应用。
1 个赞
这是我的看法。你基本上只需要足够留意，就能知道何时需要重建数据容器以应对 Postgres 或 Redis 的升级。你还需要知道如何执行 ./launcher bootstrap web_only && ./launcher destry web_only; ./launcher start web_only，但这并不难。你也可以只执行 ./launcher rebuild web_only，但这会在重建期间导致网站下线。
2 个赞
为了完整起见：Web UI 构建通常不会有任何停机时间；引导/销毁/启动会有极小的停机时间，我只会像平常一样进行，并提供外部维护页面，就像这里记录的外部 nginx 一样。但无论如何，这都是一种好做法，即使只是为了将 IPv6 地址放入容器中。
很好，谢谢。使用两个容器的安装方式，当容器需要重建时，您仍然会收到 Discourse 仪表板通知吗？在这种情况下，我是否可以确定是仅重建应用程序容器还是也重建数据容器？
1 个赞
是的。我现在看到了，因为我还没有应用“只有版本已更改”的 3.1.0.beta1 更新。
1 个赞
这种情况属于“一切正常，直到它不再正常”——当 UI 更新失败时，人们会惊慌失措，不知道该运行 git pull; ./launcher rebuild app 来解决问题。我认为每次 GUI 更新失效时都会发生这种情况。它又发生了：
我觉得这种恐慌凸显了拥有一个一致的、正常的更新机制来避免这种体验的价值。
与此同时，我也遇到了一个不那么频繁但同样存在的问题：引导程序破坏了正在运行的系统：零停机时间更新偶尔会像这样中断，平均一年一两次？所以不要在引导和销毁/启动之间拖延。
我应该更新文本以使其更清晰，我接下来会这样做。
我还没有部署 LibreTranslate，但正在考虑部署它以使我的网站更具国际可用性。
如果我成功部署，我打算将其编辑到首帖中。
2 个赞