Lewin's Blog

记一次个人网站的运维过程

发布于 更新于
一年没动，动一次遭了九九八十一难

域名证书

又是一年免费域名证书到期，不得已只能登上腾讯云例行更新证书。

愕然发现，腾讯云提供的免费证书由1年有效期降低为3个月有效期了，有点难受。也没办法，云服务器的有效期还有3年，域名和备案也不想动，那证书也就先不动了，就这样凑合着过吧。

折腾了一阵子，等审核到第二天，新的证书终于签发了。

顺手清理了一下以前遗留下来的验证DNS解析记录。

GPG密钥续期

把新证书更新到代码仓库中，提交，嘿，屋漏偏逢连夜雨，GPG密钥过期导致git提交失败了。

前后折腾了两三个小时，终于把GPG密钥更新完毕。过程记录在Git GPG sign 用法这篇文章中。

构建镜像

所需的文件都准备好了，该打包docker镜像了。

咦，我电脑上的docker怎么没了呢？看来我是写了太久前端，都快要忘记后端怎么写了。

咦，怎么连wsl子系统都进不去了，哦原来之前装mumu安卓模拟器的时候把windows的虚拟化功能关闭了。

又是好一顿折腾，终于把虚拟化给打开了，进入了ubuntu子系统。

安装docker又该怎么装来着？由于 docker desktop 只对小规模企业免费，在公司使用将可能面临法律风险，所以稳妥的方式是自己想办法在ubuntu中安装社区版。

还好子系统现在有了 systemd 可以直接装 docker-ce 了，是个好消息。好吧，要用这个特性，得先更新wsl版本。直接更新wsl又会遭遇网络问题，还得借助梯子。

更新完毕之后，参考标准Linux系统的步骤，一通 apt 命令之后，嘿，docker ps运行成功了耶~~

在运行以前写好的构建发布脚本，不出意外却又令人悲伤的是，又卡住了。因为是新安装的docker，还没保存私有镜像仓库的登录态，所以推镜像的时候被拒绝了。我的账号在哪里来着，哦，腾讯控制台可以查。密码又记在哪里了来着，试一试，居然对了。

一边在敲代码，一边脚下还被蚊子骚扰着，杭州的夏天挺讨厌的。

k8s部署

镜像上传完了，继续执行部署脚本，结果又卡住了。这次是因为 k8s 的证书也过期了……

参考这篇文章执行以下命令就可以更新证书了（相比于以前，精简了太多）：

sudo kubeadm certs renew all
sudo systemctl restart kubelet
sudo cp ~/.kube/config ~/.kube/old-$(date --iso)-config
sudo cp /etc/kubernetes/admin.conf ~/.kube/config

好了，证书问题是搞定了，kubectl 接受命令了。

然后又发现！kubectl rollout restart 命令没反应了！我还尝试了kubectl scale命令同样没有反应，重启kubelet没用，重启ubuntu也没用，我想要滚动重启的 deploy 它的数量永远是那1个旧的pod……

解决方案是重启相关服务（kube-apiserver, kube-controller-manager, kube-scheduler and etcd），现在我的本地k8s这些服务是运行在容器中的，因此我需要命令kubelet去重启这些服务，操作为：

sudo mv /etc/kubernetes/manifests /etc/kubernetes/manifests-backup
# 稍等一会儿...
sudo mv /etc/kubernetes/manifests-backup /etc/kubernetes/manifests

简单测试，个人博客网站终于恢复服务了。此时是晚上12点39分，可以安心回家睡觉了。可喜可贺。

反思

  1. 用提供接口的免费证书提供商，实现自动更新证书。

应该有很多人都知道 Let’s Encrypt ，它最大的特色是支持脚本自动化申请和更新证书，理论上可以长时间自动运行而无需人工干预，不像腾讯云那样快到期了需要手动申请下载证书。

不过我仍然暂时不打算做这个自动化，因为它需要的权限有点多（在服务器上运行脚本自动设置HTTP或者DNS验证），而且运维这个东西频率太低，说不准什么时候又会改变政策或者服务商，做一遍的投产比很低。哪怕从学习的角度来说也没意义，因为基本上都是根据教程或者博客照葫芦画瓢，没多少自我思考的部分。

  1. GPG密钥有必要吗

GPG这个东西就我观察来看，依然是个很小众的工具，在使用过程中也经常遇到这样那样的奇怪问题（除了我写在博客里的，实际上还有更多）。

要说有用的话，也可以说有点用，可以用于证明git提交是不是自己亲自提的还是他人代劳/篡改的，但是又不大，因为实际应用范围太小，没有形成标准规范，大家都是各玩各的。

  1. 构建流程需要全自动化吗，也就是持续部署（CD）

我的博客文章以及网站代码都是以git仓库的形式托管在Github的，其实如果能够充分利用 Github Actions 来实现持续部署，还是非常顺滑的。早些年我就是这么干的。

不过后来几次运维方式调整之后，依赖了一些外部的服务，这样就涉及到登录令牌/证书如何储存和传递的问题。理论上是有很多解决办法的，例如 Github 自带的 Secret 变量，例如像我在公司项目中那样用HTTP封装代替ssh直连来降低权限要求，等等。不过既然那些玩法我都已经玩过了没有学习的需求了，那我选择还是维持现在手动构建部署的简单流程。

  1. k8s还有必要吗，要不直接docker算了？

以前端工程师的职业要求来说，会基本使用k8s已经足够算得上强大；以全栈工程师的职业要求来说，多踩踩坑积累一些经验是非常有必要的。因此我选择继续坚持使用k8s。