TLDR:我点击了 Discourse 管理面板中的更新按钮,但更新失败了。我决定重启整个系统并再次尝试更新过程。不幸的是,我的 Discourse 管理面板无法打开。我想让它恢复正常工作。
支持信息:这在一个为 WordPress 网站提供服务的 DigitalOcean VM 中。我几年前设置的,忘记了很多细节,但不知怎么 Nginx 会根据请求的 URL 来决定是为主要内容激活 WP 还是为对话激活 Discourse。WP 端仍然可以工作。
考虑到我在开头提到的那种简单随意的方法,我无法准确指出导致我陷入这种糟糕状态的确切安装错误性质,这并不奇怪。我甚至不知道在哪里可以找到可能包含有关让升级过程重回正轨的线索的日志文件。
任何提示都将非常受欢迎。我对 Web 管理知识不太熟悉,但我熟悉基于 Debian 系统的命令行。上面提到的软件都运行在 Ubuntu 20.04.6 LTS 上,并且我有对相关平台的 SSH 访问权限。谢谢!
pfaffman
(Jay Pfaffman)
2024 年7 月 7 日 00:09
3
您可以尝试
cd /var/discourse
./launcher rebuild app
这或许能解决问题。如果不行,那可能很难猜到原因。
2 个赞
非常感谢您的回复。我将遵循 Jay 的建议并汇报结果。(不过可能需要几个小时后才能汇报。我得先做披萨,然后喂给我的客人。
1 个赞
不幸的是,我的 DigitalOcean VM 似乎太小了。如果我在刚登录后运行 du -sh 命令,它会显示我分配的磁盘 /dev/vda1 大约有 7 GiB 可用空间。在我发出 launcher rebuild app 命令后,会发生大量的下载和解包操作,然后脚本会中止,并提示它只看到 3.3G 可用空间,并且除非有 5G 或更多空间可用,否则它拒绝继续执行。
当然,我已经尽力查找并删除了不必要的文件,但要找到另外 1.7G 的空间来清理将是一个艰巨的任务。对于这种情况,有什么专家建议吗?(无论是关于可以删除的大型目标,还是关于要求启动器降低要求。)
附注:或者,我可以在更强大的机器上重建应用程序,然后将一个合适的文件上传到这个性能不足的小型 VM 吗?或者这是否属于过于晦涩的黑魔法范畴?
尝试执行命令 ./launcher cleanup。此操作可以帮助您清除 Docker 占用的存储空间。
此外,如果您确定之前遵循了官方安装指南,可以执行 ./launcher destroy app 来移除之前损坏的容器。但是,务必确保您的数据库和上传文件存储在宿主文件系统上,而不是容器本身内部。
确实,您可以在另一台机器上执行重建,然后将 Docker 镜像传输到您的虚拟机。但是,您需要在虚拟机上手动执行 rake db:migrate 命令。我不完全确定这种方法是否会引入其他问题。
1 个赞
我不能100%确定,但我愿意尝试一下。我该如何完成保存数据库和上传文件的必要步骤?在进行任何重要操作之前,将 /var/discourse/shared/standalone 目录中的文件复制到某个安全位置是否足够?(是否有指向类似手动恢复项目这种标准流程的指针?)
我认为 @Robert 的务实回应将是大多数处于类似境况的人的最佳选择。我将采取不同的方向,因为我的背景在几个方面都很独特。其中,最重要的是:我的安装是一个小型爱好项目,丢失所有东西会令人失望,但并非毁灭性的。
再次感谢。
pfaffman
(Jay Pfaffman)
2024 年7 月 7 日 18:10
9
如果文件在 shared/standalone 目录中,则安全。
如果您有 WordPress 和 Discourse,则可能需要升级到 2gb/50gb 虚拟机。如果您已删除所有备份并执行了启动器清理,那么您可能有一些可以(哦,您也可以清理 apt 缓存,如果您在 Google 上搜索一下)。
1 个赞
可能与我们刚刚遇到的问题相同,也可能不同:我们正在使用 MaxMind 的 API 进行 IP 地址地理位置转换。旧版本要求在 app.yml 文件中提供 MaxMind API 密钥。最近(未记录?)的更改要求在 app.yml 中同时提供 MaxMind API 密钥和用户名。缺少用户名会导致论坛构建失败。
2 个赞
感谢您,@Frully ,但我认为这是另一个问题。这是阻止我的错误消息:
Status: Downloaded newer image for discourse/base:2.0.20240602-0023
docker.io/discourse/base:2.0.20240602-0023
您在 /var/lib/docker 所在的磁盘上的可用空间少于 5GB。您需要更多空间才能继续
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 25G 21G 3.5G 86% /
下班后我今晚将继续我的故障排除冒险。
朋友们,我将改变策略,采纳 @merefield 的建议,将我的整个设置迁移到一个更大的 VPS。如何将我的资产从损坏的设置转移到新的可用设置将是这项活动中的一项挑战,但我会尝试一些常识性的方法,如果都不奏效,我会开一个新帖子。感谢所有提供帮助的人,我认为可以安全地关闭此帖子了。
4 个赞
后记: 迁移到新主机お过程让我学到了在 Discourse 容器内直接运行 shell 命令的有用知识,相关内容已在另一个帖子 中介绍。该帖子还提供了更多关于节省磁盘空间的信息。
2 个赞