个人开发运维之路心得与回顾

前言

2020年4月10号。

今天是很吉利的日子，正好发工资，哈哈。

升级 k3s、rancher，改造 CI/CD 流程，接入 helm 和 k3s， 再用 traefik 做反代从云服务器转移流量到家里，折腾了差不多一个周，边学边用，边用边学，总算是基本跑通了整体的流程。

目前公司的研发运维体系越来越完善了，在这个过程中自己也学到了很多新东西，学以致用，也可以拿来完善下个人业余的开发运维体系。

回顾

回顾还在学校的时候，对服务器还是懵懵懂懂的状态，啥也不懂，用腾信云撸了个学生优惠的服务器，买了个域名，顶多也就用来搞搞 ss，那会儿还装了个图形界面的 windows server，用 ftp 服务器来当网盘用，挫到掉渣，哈哈。

16 毕业之后开始忙于工作，开发这一块就已经有学不完的知识，运维相关的东西，差不多到了 18 年才开始好好的学习。

17年之前，公司的 docker 也是刚开始使用，基本是调 sh 脚本，然后docker run 的状态，连 docker-compose 都没开始用，CI/CD 也没有，还是用着 walle 手工触发上线，个人就更不用说了，写代码都还写不好，也没空去专门捣鼓服务器。

趁着新用户优惠的时候，入了一个 1核2G 的垃圾服务器，随便玩一玩，那会儿个人开发水平也差，不知道可以玩什么，也没有能力做个人项目，顶多部署部署博客，基本还是纯学习为主，服务器也基本上是闲置的，为我国的云服务事业发展做贡献了。

那时候用服务器，都还不怎么习惯用命令行来管理，尝试过 alinode，宝塔这种图形化管理界面，反正各种瞎搞，乱了就一键重装系统，现在偶尔在 flarum 论坛的群里，看到有人想用宝塔面板装 flarum，就仿佛看到了以前弱爆了的自己。

18 年和同事一起，买了几个云服务器，准备搭搭论坛玩，那会儿也是各种菜菜的折腾，啥都以省钱为主，想着用自建的 minio 存图片，用免费的 CDN，自己打 Docker 镜像，等等等等。

18、19 年左右，公司的 CI/CD 逐步正规化，并开始使用 k8s，在这个过程中，也是逐步的学到了各种东西。

变迁

现在回忆起来是真的能折腾，就我个人写东西来说，就折腾过无数方案。

大一的时候用有道云笔记，大三大四的时候开始用为知笔记，毕业之后开始尝试写博客，用博客园，用 CSDN，最后 hexo 来自己部署。

部署的时候，用 github page，后来用嫌速度慢用 gitee page，后来自己打 Docker 镜像，但是手动上线又太麻烦，然后又开始用 gitlab ci，自动打完镜像之后之后 scp env 到服务器上，然后重新 docker-compose up。

这样顺便把代码仓库也从 gitub 迁往 gitee，然后又迁往了 gitlab。

既然用了 gitlab ci 了，那是不是 runner 可以 self-host 了呢？于是闲置笔记本派上了用场，装个 ubuntu，个人服务器有了。

既然都有个人服务器了，那服务是不是也可以布在自己的机器上了呢？

于是光猫改桥接，路由器端口映射，定时任务触发 DNS 更新， 一系列操作之后，项目都部署到了自己的笔记本上，但是这样服务一多吧，管理起来又麻烦了，docker ps 看着就乱。

但是 k8s 小户人家又玩不起，于是 k3s 登场了，既然都上 k3s了，那 CD 的过程，也得从 ssh 到服务器上执行 docker-compose up --build -d 进化进化了，于是 kubectl apply 用起来。

但是 kubectl apply 的话，也嫌麻烦，给项目写个 k8s 资源的 yaml 文件吧，又没啥好的模板替换方式，全部 sed -i 显得自己太菜了。

于是 helm 可以派上用场了，总之各种折腾之后，现在是越来越好用了。

git flow 管理分支，commitizen 规范提交，standard-version 自动发版，gitlab ci 来 CI/CD，镜像往阿里云镜像服务上推。

然后develop 分支就部署到 k3s 的 <项目名>-dev 命名空间下，打 git tag 的时候就触发线上环境的部署，用 tag 做镜像标签，部署到 k3s 的 <项目名>-prod 命名空间下，ingress 也在 CI/CD 的时候自动配置好，这样项目部署完成后，就可以直接用 项目名.dev.xxx.com 和 项目名.prod.xxx.com 来访问啦。

然后云服务器上通过 traefik 做反向代理，将流量转回家里的服务器，一方面解决了云服务器性能不够的问题（主要是因为穷），一方面也解决了家庭宽带 80 端口无法访问的问题，同时也避免了家里服务器的 ip 直接暴露出去。

不过云服务的带宽是个问题，所以部分强依赖带宽的服务（云盘）等，就考虑在云服务器上直接 302 好了，虽然会暴露服务器的 ip，但是这部分服务本来就是私人用的，所以问题也不大。

全部流程自动化、规范化，美滋滋，感觉一般小公司、小团队都没我这个流程规范了。

git 提交记录 gitlib pipeline k3s 集群 rancher 管理界面

总结

就我个人而言，在学校里所学专业是通信、电子硬件相关的，业余培训是网络相关的，工作之后又开始搞软件开发，虽然说硬件和网络相关的东西都差不多忘干净了，但是毕竟稍稍有那么些底子。

相对运维同学来说，我的运维水平确实是菜的掉渣，但是毕竟更了解开发这一块，所以在改造 CI/CD 的流程的时候，我能够更好的去往符合开发的需求的方向去靠，如何和分支、标签管理结合起来，如何更好的 CD 到不同的环境满足项目管理需求等等。

待办

• 给 k3s 集群和 traefik 配置 ssl 证书
• 整理 k3s 集群中旧项目到对应的 namespace 和 project
• CI/CD 加入对已存在镜像版本的判断，避免重复构建
• 学习下 github action，对比下是不是比 gitlab ci 更好用
  • 如果 github action 可以的话，尝试建个 org，看能不能一定程度上替代 gitlab 的 group
• 买个 intel NUC8i5，替换掉现在 cpu 性能弱爆了的旧笔记本
  • k3s 迁移到新机器