记录一次汗流浃背的网站回滚

起因

昨晚,猛然间发现halo的邮件通知服务没有开通,于是乎开始研究相关事项。一开始是打算用gmail当smtp服务器的,但是研究发现这个功能好像对个人用户关闭了,遂作罢。于是盘算着要不干脆自己在服务器上搭一个邮件系统,这时我隐约记得1panel的应用商店里有相关的服务,便兴冲冲地打开1panel准备大干一场。

经过

然后噩梦就此开场。当我输入1panel的地址后,浏览器转了一会,然后给我返回了503错误代码。我直接傻了,虽然以前1panel也不是没有崩过,但是好歹还是能有个大概的界面的,我还是第一次遇到返回503的情况。我的第一反应是坏了,不会是网站被打了吧,于是赶忙登上cloudflare看看情况,但是发现一切正常。我又想是不是只是暂时性抽风,于是清除了cookie,再次尝试访问,然而并没有什么用,还是503。为了确认服务器的状况,我又尝试访问服务器上的其他内容,然而其他的服务都很正常,唯独1panel怎么弄都登不上。于是我心一横,决定直接重启服务器,俗话说重启解决99%的问题,这一次·······很不幸是那1%。重启过后的服务器依然不能登录1panel,1panel的界面依旧返回503。无奈之下,使用ssh登录服务器看看到底是什么情况。

通过翻阅1panel的相关文档,发现可以使用1pctl status 来查看当前1panel的运行状态,结果返回了一个绿色的running ,说明1panel一切正常。这直接给我整不会了,明明运行正常,那为啥会给我返回503错误代码?于是我接着试着用1pctl reset 重置系统信息,依然不行。最后我实在没有办法了,想着大不了我重装一次1panel总不会再有问题了吧?殊不知,我将会因为这个大胆的决定而折腾一天。

原本我以为,1panel只不过是一个服务面板,就算删除也不应当影响到服务器中的docker。事实证明我太天真了。在1panel应用商店中安装的docker应用,很多情况下都会把容器内部的目录映射到1panel的data文件夹下,这就导致了在删除1panel的同时也会删除这部分数据。我这里是直接把mysql的数据删了,导致所有依赖mysql的容器都出现了问题。

不幸之中的万幸是服务器上最依赖mysql的应用就是halo了,而halo的数据我每天都有备份。用官方的说法是halo的备份恢复不依赖环境,在任何部署条件下都可以恢复,哪怕数据库不一样都可以。而halo的备份恢复也很简单,只要在备份界面上传备份文件即可。不过这里也让我满头大汗了一会,因为这里说是可以直接通过下载地址获取备份文件,我就直接把服务器上的备份文件的下载链接填进去了,然而结果是虽然系统提示我恢复成功,实际上没有任何变化。最后不得已只能把备份文件下载下来,再通过上传窗口传上去才让恢复机制起了作用。说实话当时挺忐忑的,要是这么干都不行恐怕我估计就直接自暴自弃直接放弃博客了。

结果

在忙活了一通之后,总算让网站恢复了正常。又是一通手忙脚乱,1panel也重装成功,当我以为一切都可以结束的时候,1panel又给我弹出了503错误。我不知道该如何形容我当时的心情,绝望?无奈?还是一种无力回天的自嘲?不过冷静下来后,我终于开始认识到问题可能不是出在服务端,可能出在我这边。我的手中有2个梯子,一个主用,一个备用。主用的梯子什么都好,就是不知道为什么登录不上Googlecloud,而备用的梯子则可以做到这一点。那天我用过Googlecloud,于是一直使用的是备用的梯子,而我平时都是使用主用梯子登录1panel的。想到这,我赶忙把梯子切换回来,结果不出所料,这次成功登录了。看着那熟悉的界面,我感到一阵恍惚,想说点什么又无语凝噎,只好自我安慰到至少结果还不错,就当是长个记性了。

ps:我想了很久也想不明白我又没有做屏蔽规则,为啥一个梯子能登录一个不行?想了半天可能觉得是加密的问题?因为我之前都是偷懒直接用ip和端口号登录的,难道那个备用梯子不支持非https?于是我去nginx中设置了一下,将1panel映射到一个二级域名下,结果备用梯子就可以顺利登录了······就当是这样吧。