工作这么多年以来,种类 CI/CD 工具都有些接触。但唯独最青睐的还是 Jenkins ,她的灵活性、定制化、插件覆盖度等都是一度好评。

我有多个服务、站点,虽然没什么流量,但一直做为我自己调研的目标和学习的途径。在实际使用 Jenkins 时,也屡试不爽。但随着服务数量的增加,是越来越不好维护。当然,这里并不是说 Jenkins ,因为跟我本身能力有很大关系,没有好与不好,只有合适不合适。

Jenkins

由于本身我不是运维同学,只是出于学习的目的而使用。但应用时发现以下的方便:

1. 配置不方便管理。即使用 jenkinsfile 对 Jenkins 一些配置依赖还是有的。
2. 维护成本高。系统升级、版本升级等软件相关的,还有宕机、不小心删除等未知因素。迁移起来比较麻烦。当然使用 Docker Jenkins config 可以省一些事。

基于这些特点,我自己也有一些小研究。包括凭证管理、remote hostname 管理、环境变量管理等。虽然已经完全实现了我的单台验证、确认再发布生产、多机部署、刷新 CDN 缓存等需求,但始终感觉差点东西。。。

GitHub Actions

其实一开始就知道有她,但个人原因也没时间研究。昨天趁着端午假期,好好看了看,写了写 demo 。当然期间有各种报错,提交了超过50次才大概了解整体思路。

我发现她更贴合我想象中的她。于是,我准备把我所有的构建、部署、单测都迁移到 GitHub Actions 。这是一项伟大的工程,可能周期比较长。但总归有目标是好的,就像我之前提的 博客架构升级 一样,现在我 CDN 、Service Worker 也已经用上了。虽然可能有些问题,但确实落地了。

需求

遵循:

1. 尽量使用凭证远端管理,机器上是无状态的运行。
2. 数据库使用 RDS ,使用账号区分角色的权限。
3. 镜像仓库使用 ghcr.io
4. 配置远程化,私有仓库。

1. 博客

我的前端小武博客是多机部署,并且需要支持一些开发需求。如:

1. Pull Request 时,自动部署:https://pr-id.dev.xuexb.com ,由于运行时是2个容器(Nginx 、Node.js),这块需要动态无 reload 转发,参见:upyun/slardar 。
2. 合并到 v5 分支后,自动部署:https://v5.xuexb.com ,并刷新 CDN 缓存。
3. 推送 v** 标签时,自动部署到多机的生产环境,并刷新 CDN 缓存。考虑先部署一个单台 STG 机器,验证通过后手动同意触发全量部署
4. 所有的提交,都需要进行 Docker build 验证,关注是否有错误。

2. web-oauth-app

1. 推送 v** 标签时,自动部署到多机的生产环境。
2. 所有的提交,都需要进行 Docker build 验证,关注是否有错误。

3. Docker

其她 Docker 化应用,支持自动化部署。

4. Auto SSL

每3个月自动续签所有域名证书,并部署&重启。

---

最后,抽空就动手开干吧!

发表于 2022年06月04日 13:58:43 ,添加在分类 前端技术 下 ,并被添加「 github CI/CD 」标签 ,最后修改于 2022年06月04日 14:01:33