正如我们多年来观察到的，有时更新/升级会因为依赖关系而失败。例如 Docker 版本/操作系统。
我的想法是 Discourse 运行某种依赖性检查，以确保满足基本要求。如果检查失败，它会提供一些关于可能需要什么的详细信息，并中止更新/升级过程。
这将通过中止将要失败的过程来帮助减少论坛停机时间，从而中止 Core Discourse 的更新/升级。
他们很努力地尝试做到这一点。可能出错的事情有很多。一般来说，如果你不及时更新你的操作系统（可能还有 Docker），那就是你的错。
他们会尝试检查 Docker 版本，而且我使用的脚本会在已知 Docker 版本有问题时升级它（也许应该总是升级 Docker）。
我认为如果基础镜像有任何变化，他们最好强制进行命令行升级。我基本上从不使用它，因为我的仪表板可以通过单击来执行命令行更新。
1 个赞
deos 更新 docker_manager 更新 docker 吗？
1 个赞
我绝对没有试图转移责任。更具体地说，自托管（self hosted）的不幸之处在于，不一定了解服务器操作系统（OS）。大多数人安装操作系统后，通常会保持更新。但通常使用LTS（长期支持版本）的人可能不知道或不理解如何升级操作系统，特别是如果他们习惯于滚动发布（rolling releases）。
例如，我帮助的一家公司在一段时间没有更新后，注意到有可用更新。因此，他们通过Web用户界面（UI）更新了Docker，然后允许他们更新Discourse。
由于Ubuntu LTS不够新，Docker更新不符合最低要求。但Web用户界面仍然允许尝试更新，结果当然失败了，导致网站瘫痪。
因此，他们尝试了命令行重建，但由于未满足最低要求，当然也失败了。
如果在Web中更新时，能识别出Docker版本不满足最低要求，就可以中止更新过程，通知未满足的依赖关系，而不会导致网站瘫痪。
我为他们大致检查了一下。因为看起来他们可能在服务器上运行其他东西。我已经指示他们的技术人员研究将LTS升级到更新的版本。因为我不想尝试升级操作系统，以防它破坏他们正在运行的其他东西。
有没有一种简单的方法可以在Web界面和命令行重建尝试之前重启容器？
我尝试了 ./launcher start app
但失败了。
另一件事是，由于Discourse网站宕机的方式，使用rsync启动一个新服务器是否可行？他们运行的是稳定版（stable），而不是推荐的测试通过版（tests passed）。
如果他们运行’:do-release-upgrade’并手动升级Docker，这对于升级postgreq是否有效？
它将在 Ubuntu LTS 支持的版本中。但仅限于 LTS 支持的版本。在这种情况下，他们的 LTS 已经到了生命周期尽头。因此它不支持最低 Docker 版本。
iirc Ubuntu LTS 版本有 4 年的更新寿命。
1 个赞
与我共事的人不是这样。当我告诉他们已过支持期时，他们也不会更新。
我很确定容器内运行的东西无法知道它运行的是哪个版本的 Docker。
也许可以。看起来你可以从容器内部获取这个信息，以查看正在运行的版本。
https://docs.docker.com/engine/api/v1.30/#operation/SystemVersion
所以也许他们可以做得更好。如果它真的有效，那将是添加到仪表板的一件很酷的事情。
它通常是有效的。例外情况是数据库已迁移。
如果操作系统已过时，我通常发现迁移到新的虚拟机更简单、更安全。理想情况下，您应该在旧服务器仍然正常工作时进行迁移。请参阅 将 Discourse 站点迁移到另一台 VPS 并使用 rsync
如果您有备份，可以跳过复制数据库和数据库升级，只需在新数据库上恢复它即可。
1 个赞
这就是我所说的更新。对于已过支持期的系统，需要升级操作系统。但我同意你的看法，确实有各种各样的人不太会听从指示。
当我被升级为我免费帮忙的公司管理员时 
我连续一个多月告诉他们，他们的论坛迟早会崩溃，因为他们没有执行应用程序重建所需的空间。他们有一个（7年前的）小型服务器。我记得总共只有 25g 的空间。他们当然没有听。最后不得不付费请这里的人将论坛迁移到一个新服务器。总停机时间大约两周，可能多一点。
如果能实现，那绝对很酷。像你和我这样几乎一直在线的人，会相对及时地更新自己，相比之下，很多人只在出现问题或寻找插件及其他一些小问题支持时才会访问。
好的，我会告知他们。但是，我不确定备份有多旧。所以可以想象，在他们的情况下，需要探索 rsync 或操作系统升级。
在我自己的服务器快要过时时，我阅读了很多资料，并小心翼翼地避免通过 Web/命令行更新。直到我熟悉了 rsync 程序。而且仍然遇到了一些小麻烦，你和社区帮助我调试了。
1 个赞