MENU

【闲聊】记录一次T0级事故

September 28, 2022 • 日常

测试测试测试

开端

如你所见,在2022年9月25日和9月26日这两天,我的服务器一直处于崩溃的状态。事情的起因是在9月23日的时候,我注意到我的博客的响应速度下降得非常快,以至于每次打开一个网页到完全加载完毕都需要等待超过200ms,在检查完我服务器后台之后,我发现我的博客在经过了一年左右的使用下,已经囤积了500M的日志,并且还在以一个肉眼可见的速度持续增长。又因为这个博客的后端是我在去年早些时候自己开发的,然后移植了这么一个主题,到现在为止,这个主题的作者也对原版的主题进行了数次的更新,同时typecho也在今年发布了1.2版本,这一切都在诱惑着我切换回typecho。于是,在2022年的9月25日上午十点,我正式开始了服务器的维护。

技术选型

随着最近几年宝塔面板的商业化日益严重,这个面板已经从曾经的 “多功能” 变成了现在的多广告,并且对用户进行了分级,设立了商业用户的专属功能,还无法进行屏蔽,这些让我感到非常的困扰,又因为这个面板曾经爆出过 0day漏洞,且影响了非常多的站长,于是我决定彻底抛弃宝塔面板。

但是失去面板之后,我并不希望因此增大我的维护成本,于是我选择了最近非常火的 docker 环境,通过容器的方式部署所有的服务,并且不再需要宝塔面板的 “编译安装程序” 与 “古老的软件版本”。通过docker的方式,我可以快速的更新当前的程序且不需要考虑他的安全性。

在反向代理服务器方面,我没有再次选择 nginx, 因为我认为,作为一个普通的个人博客,没有太高的qps,因此不需要拥有更高的性能与更复杂的配置方式,所以我选择了更加轻量化且更加人性化的 caddy 作为本次建站的代理服务器,这个代理服务器有一个很 “好” 的特性,就是可以自动部署 https 证书,而不需要我去自己操作,非常省心,这也是我后面崩溃的主要问题。

博客程序还是选择的 typecho 官方提供的docker镜像,这个镜像有自己配置好的伪静态,非常不错。

程序故障

当我对原始的轻量云服务器进行快照备份之后,我便开始了新版本博客的配置工作。

我先是在新的镜像中安装部署了docker环境,然后切换到 root 用户,开始安装 caddy,很快,我就按照 caddy 官网给出的例子,完成了我的第一个示例站点,但是这个站点却开始无法正常访问,每次访问的时候都是响应 http2_protoclxxx ,看样子应该是协议头不正确,但是因为我对 http2 的协议知之甚少,甚至基本上都不怎么了解,到现在我已经感觉非常焦虑了,明明这个服务器在我本地还是可以正常运行的,于是我灵机一动,把本地的配置文件复制了一份到云端,然后重载服务器配置。很好,80 端口已经可以访问了!我很兴奋的尝试通过 443 端口 (https) 进行访问,但是 443 端口却依旧无法正常访问。

就这样,这个问题一直持续到了晚上,我还是没能正常通过 https + 域名 的方式访问这个网站,即使是直接走 ip 也是不行的。

当天晚上八点到十点钟左右,我发现 https 可以访问了,这次的发现让我感到欣喜若狂,但是当我尝试接入阿里云的全站加速 (dcdn) 的时候,我却傻眼了,阿里云的 dcdn 报 502 错误,并且没有给我抛出任何错误。此刻已经距离服务离线12个小时了,我尝试过几次,取消阿里云的全站加速解析,并且尝试重新解析上去的时候,依然是不可用的。 “ 要不通过快照回退到旧版本吧 ” ,我脑子里不停的闪过这样的想法,此刻我已经彻底被这次崩溃搞麻木了。

直到晚上11点多的时候,我发现在我设置好 sni 回源的时候,dcdn 终于成功解析到了我的网站,我的页面暂时恢复了访问!

但是这终究只是昙花一现,当我尝试重新部署容器将我的整个网站数据恢复回来的时候,dcdn 再次无法进行解析。此时时间已经过去了超过14小时,于是我决定,先挂上一个 “ 服务维护中 ” 的牌子,然后再第二天下班回来之后再次尝试修复。

当时选用的404模板

故障恢复

9月26日这天晚上,当我回到家,我重新尝试将阿里云的 dcdn 解析到我的服务器上,非常幸运的是,这次一次性成功了!我非常高兴,连续更换了多台设备测试网络无故障,能够正常访问服务器的时候,我终于缓下来一口气。

接下来就是移除 404 页面,然后配置上博客,最终,在这个程序故障48小时以后,我的博客终于恢复了正常。

故障原因

因为是第一次使用 caddy, 而 caddy 这个服务器有一个非常好的特性,就是他会自动帮忙签署 ssl 证书而不需要用户手动签署,而这个签署的过程,是需要提前将域名的 dns 解析到 caddy 所在的服务器上的,因为 caddy 并不是通过 acme 的方式认证的,他是通过文件的方式实现的,因此,如果没有提前解析,那么 caddy 就无法正常签署证书,这个网站就会处于不可用的状态,所以正确的部署方式是:

dns 解析 => 服务器部署服务 => caddy 代理域名 => 等待域名可以正常访问 => 部署全站加速 

而我这次网站部署的流程,很明显就弄错了我,我将全站加速放在了最前面,这样当然就没有办法正常访问了。而这些操作,都是在我以前的宝塔面板上自动处理了(使用acme的方式自动认证解析,然后认证,然后返回ssl证书文件)。总的来说,还是我自己的技术比较欠缺,见识太少吧。

作者:NorthCity1984
出处:https://grimoire.cn/daily/t0-925.html
版权:本文《【闲聊】记录一次T0级事故》版权归作者所有
转载:欢迎转载,但未经作者同意,必须保留此段声明;必须在文章中给出原文连接;否则必究法律责任

Last Modified: October 15, 2022
Leave a Comment

2 Comments
  1. 这么严重,回家跪键盘跪2个小时反省下

    1. @bboysoul呜呜呜别骂了别骂了@(泪)