六大招式，修炼极狐 GitLab CI/CD “快” 字诀
本文来自：
李发富 极狐(GitLab) 高级技术支持工程师
众所周知，CI/CD 可以让我们更快、更高质量、更简单的交付软件。而现实中，你是否经常面临以下难点，导致 CI/CD 并没有真正发挥其优势：
从网络安装项目依赖耗时长？
前后端项目未分离，
导致编译、部署及测试效率低？
随着项目增多，多任务 Pipeline 运行慢？
不必要 Job 运行占用了资源和时间？
针对以上问题，我总结了六大招式，希望帮助大家在使用极狐 GitLab 时候提升 CI/CD 效率，供参考。
使用 cache
在运行项目编译时，可能会安装项目依赖，如果每次都从网络安装，会浪费很多时间。这时候可以使用 cache 功能提供缓存，减少依赖安装时间。
【前提】runner 开启 cache 功能：Advanced configuration | GitLab
python cache
示例：
or
nodejs cache
示例：
jave maven cache
使用 needs 改变多阶段执行顺序
默认情况下，同一阶段作业并行运行，不同阶段按顺序执行，存在排队等待时间，致使编译、测试时间被拉长。
我们可以使用 needs 参数改变多阶段执行顺序：Pipeline 定义阶段 Stages，如果全局未定 Stages，则按顺序运行 Build，Test，Deplo。Job 如果未设置 Stage，默认是 Test 阶段。
示例：
使用 needs 参数后：对于前端任务，build fontend 完成后会立即执行下一个阶段的 test fontend，不管 build backend 是否完成。后端的 build backend 任务一样类似。
Web 界面中还可以查看 needs 依赖关系：
使用 rules 减少不必要 Job 运行
很多人会把前后端一起打包和部署，但其实只有前端代码有变化，针对后端的 Job 测试是多余的。因此，可以使用 rules 规则跳过某些不必要 Job。
示例：
当 backend 中有变化时运行 test job；
也可以使用类似的 only: changes 实现。
安装依赖使用国内源
由于国内网络的原因，如果使用默认源的话，安装依赖可能会很慢甚至失败，这时候可以设置国内或者代理解决。
nodejs
or
python
ruby
golang
设置 GOPRIVATE 来跳过私有库，比如常用的 GitLab，中间使用逗号分隔：
Docker 镜像优化
Docker 过大，会造成镜像拉取时间过长，影响 CD 速度。
Docker 镜像体积优化
尽量优化减小 Docker 镜像大小。
1. 使用 Alpine Linux
Alpine Linux 是一个基于 BusyBox 和 Musl Libc 的 Linux 发行版，其最大的优势就是小。一个纯的基础 Alpine Docker 镜像在压缩后仅有 2.67MB。并且不少 Docker 官方镜像都有 Alpine 版本，比如：python:3.9.12-alpine3.15、ruby:2.7.5-alpine3.15 等。
2. 安装最少依赖
如果不是必须，不要安装 vi，wget，curl，ping 等工具。
3. 合并 RUN 指令到一行
Dockerfile 中尽量合并多条指令:
4. 多阶段构建
在 Docker 17.05 版本以后，新引入了 multi-stage builds 这一概念，这将会极大地减小镜像大小。
简单来说，multi-stage builds 支持我们将 Docker 镜像的编译分成多个 “阶段”。比如常见的软件编译的情况，我们可以将编译阶段单独提出来，软件编译完成后直接将二进制文件拷贝到一个新的基础镜像中，这样做最大的好处就是，第二个镜像不再包含任何编译阶段使用的中间依赖，干干净净明明白白。
具体使用方法：Dockerfile 多阶段构建 - leffss - 博客园 (cnblogs.com)
更多 Dockerfile 最佳实践参考：Best practices for writing Dockerfiles | Docker Documentation
使用自建 Docker Hub 镜像仓库
默认情况下，Docker 使用 Docker Hub 的镜像，网络传输较慢。可以搭建本地 Hub 仓库：安装 harbor v2.3.4 - leffss - 博客园 (cnblogs.com) ，加速镜像的 pull 与 push。
Pipeline 中使用本地仓库：
在有了本地 Hub 仓库的情况下，还可以根据本章节【Docker 镜像体积优化】的原则自行打包一些项目编译需要用到的基础镜像，把项目需要用到的基础依赖包或者工具提前打包进去，这样又可以减少 Pipeline 安装依赖的时间。
优化 runner
当项目较多时，CI/CD 任务也会增多，这时候运行 Pipeline 效率会降低。极狐 GitLab 提供共享 runner 给所有项目 CI/CD 任务使用，这里分享两种优化方式：
使用 Tag 标记 runner
在 runner 编辑页面设置 Tags，并且不勾选 Run untagged jobs，这时候此 runner 只运行使用 Tag 选择器的 Job，这样优化 runner 占用率.
示例：
为项目注册专用 runner
点击具体项目，然后在 settings -> CI/CD - Expand 中查看项目 runner 注册用的地址和 token，然后再按照官方文档注册 runner：Registering runners | GitLab 即可。
注册完成后，这个 runner 只会运行当前项目的 Job。
使用 k8s 运行 runner
将 runner 安装到 Kubernetes 集群中来，并且使用 Kubernetes executor，这样子运行 Job 时可以动态的申请集群资源，可以有效避免资源不足的情况。
安装方式参考：使用 K3s 来安装和运行极狐GitLab runner_哔哩哔哩_bilibili 或者 GitLab Runner Helm Chart | GitLab 。
监控 runner 资源占用
通过集成的 gitlab runner prometheus metrics 监控 runner 状态，确保 runner 的正常稳定运行。
以上，就是我基于实践经验总结的 CI/CD 效率优化六大招式，欢迎大家一起交流！
版权声明: 本文为 InfoQ 作者【极狐GitLab】的原创文章。
原文链接:【http://xie.infoq.cn/article/96dddd04c293687e4024c98cf】。
本文遵守【CC BY-NC-ND】协议，转载请保留原文出处及本版权声明。
开源开放，人人贡献 2021-05-19 加入
开放式一体化DevOps平台，助力行业高速协同增长！
评论