博客技术改造之容器化

在给博客添加更多的新功能之前，还是决定先把技术架构升个级。一方面是一直欠缺点K8S的详细操作，另一方面也是理论结合实战的一种尝试，“纸上谈兵”的技术道路终归是行不通的 :p 。本文从总体上描述升级前后的结构变化，以及目前获得的一些便捷之处。

说明：由于云服务器资源有限，升级前后都仅仅是在单台机器上。

改造前

博客部分

涉及两个git仓库, hexo-blog 内容部分 以及 hexo-theme-diaspora 主题部分. 通过命令行 nohup hexo server 的方式提供服务.

微服务部分

涉及一个git仓库 social-binding , 该项目的规划是提供社交应用的集成. 通过命令行 nohup java -jar ... 的方式提供服务.

Web服务

全权由 nginx 完成, 包括常规的路由规则定义, 以及TLS证书. 可以看到的是, 由于 LetsEncrypt 没有对阿里云的支持(当然阿里云本身也不会支持这个), 所以要保证有效期, 我一直是通过 certbot 命令去人工维护的.

改造后

服务器整体改造为了基于 K8S 的部署方式. 要问为什么单机可以用 K8S, 请戳 K3S.

博客部分

这部分没什么明显变化，目前仅仅是将整个博客目录以 Volume 的形式挂载到了 hexo-blog pod 里

微服务部分

调整为了预先构建可运行的 Docker image 到 阿里云容器镜像服务，以通用的 K8S Deployment的形式进行部署。

Web服务

全权由 Traefik Ingress Controller 完成. 暴露服务的方式为 K8S 推荐的 Ingress, 由它来映射对外端口和 Pod 内的端口。

关于 Traefik Ingress 作些特别的说明：为什么这里用了两个 Ingress? 原因是：需要转发 /socialbinding 到 social-binding Service 的 / 路径, 也就是 stripprefix. 我使用的 K3S 版本为 k3s version v1.17.4+k3s1 (3eee8ac3) , 其自带的 Traefik 版本为 1.7.19, 该版本实现 stripprefix 的方式是给 Ingress 加上 label, 而另一边的 ingress-hexo-blog 本身是不需要 stripprefix 的, 所以只能用两个 Ingress. Traefik 2.0 引入了新的概念叫 middlewares 可以更简洁的满足需求, 从而只使用一个 Ingress 即可.

另一方面的改动是 TLS 机制. 改造后, ACME 的验证机制不再使用 DNS Challenge而是 HTTP01, 证书由 cert-manager 提供, Ingress 的证书请求由 cert-manager 来完成, 详细的步骤均已在上图中用 蓝色的、带序号的 线条做了标记.

获得了什么

做了这么大的改动, 那得到了什么?

首先，TLS 证书现在不用再手动维护，我也不用再在阿里云的DNS控制台去做 DNS Challenge 的 TEXT Record 解析。

其次，微服务 social-binding 其实是会涉及到(比如, 数据库、微信公众号平台信息)敏感配置信息的。 现在可以通过容器控制环境变量, 然后 Java 的 system property 来提供这些信息。改造前，是通过没有提交到 git 仓库的独立的配置文件里提供的(为什么不能提交? 因为我用的是公开仓库, 所以必须非常小心).

别的方面，就是 K8S 化后, 可以支持将来我的博客功能的更多的微服务的发版和伸缩，毕竟基础上去了。通过阿里云容器镜像的回调功能还可以改进CD方面的能力。