六大招式，修炼极狐GitLab CI/CD “快” 字诀

本文来自：

李发富 极狐(GitLab) 高级技术支持工程师

众所周知，CI/CD 可以让我们更快、更高质量、更简单的交付软件。而现实中，你是否经常面临以下难点，导致 CI/CD 并没有真正发挥其优势：

从网络安装项目依赖耗时长？

前后端项目未分离，

导致编译、部署及测试效率低？

随着项目增多，多任务 Pipeline 运行慢？

不必要 Job 运行占用了资源和时间？

针对以上问题，我总结了六大招式，希望帮助大家在使用极狐GitLab 时候提升 CI/CD 效率，供参考。

使用 cache

---

在运行项目编译时，可能会安装项目依赖，如果每次都从网络安装，会浪费很多时间。这时候可以使用 cache 功能提供缓存，减少依赖安装时间。

【前提】runner 开启 cache 功能：Advanced configuration | GitLab

python cache

示例：

1.  
   image: python:3.9.7
2.  
    
3.  
   stages:
4.  
     - test
5.  
    
6.  
   variables:
7.  
     PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
8.  
     
9.  
   cache:
10.  
      paths:
11.  
        - .cache/pip/
12.  
      # 已项目 id 区分 cache，如果不区分，就是全局 cache
13.  
      key: $CI_PROJECT_ID
14.  
     
15.  
    job1:
16.  
      stage: test
17.  
      script:
18.  
        - pip install ansible==2.9.2

or

1.  
   image: python:3.9.7
2.  
    
3.  
   stages:
4.  
     - test
5.  
    
6.  
   cache:
7.  
     paths:
8.  
       - pip-cache
9.  
     # 已项目 id 区分 cache，如果不区分，就是全局 cache
10.  
      key: $CI_PROJECT_ID
11.  
     
12.  
    before_script:
13.  
      - export PIP_CACHE_DIR="pip-cache"
14.  
      - mkdir -p pip-cache
15.  
     
16.  
    job1:
17.  
      stage: test
18.  
      script:
19.  
        - pip install ansible==2.9.2

nodejs cache

示例：

1.  
   variables:
2.  
     NPM_CONFIG_CACHE: npm_cache
3.  
     NPM_CONFIG_REGISTRY: https://registry.npm.taobao.org
4.  
    
5.  
   default:
6.  
     cache:
7.  
       paths:
8.  
         - ${NPM_CONFIG_CACHE}
9.  
    
10.  
    build:
11.  
      stage: build
12.  
      image: node:14-alpine
13.  
      script:
14.  
        - node -v
15.  
        - npm -v
16.  
        - npm ci
17.  
        - npm run build
18.  
      artifacts:
19.  
        name: "build-package"
20.  
        paths:
21.  
          - dist
22.  
        expire_in: 1 day

jave maven cache

1.  
   build:
2.  
     image: maven:3.8.5-jdk-11
3.  
     stage: build
4.  
     variables:
5.  
       MAVEN_CLI_OPTS: "-s .m2/settings.xml --batch-mode"
6.  
       MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
7.  
     cache:
8.  
       paths:
9.  
         - .m2/repository/
10.  
          - target/
11.  
        key: $CI_PROJECT_ID
12.  
      script:
13.  
        - mvn package
14.  
        - ls -l target/*

使用 needs 改变多阶段执行顺序

---

默认情况下，同一阶段作业并行运行，不同阶段按顺序执行，存在排队等待时间，致使编译、测试时间被拉长。

我们可以使用 needs 参数改变多阶段执行顺序：Pipeline 定义阶段 Stages，如果全局未定 Stages，则按顺序运行 Build，Test，Deplo。Job 如果未设置 Stage，默认是 Test 阶段。

示例：

1.  
   stages:
2.  
     - build
3.  
     - test
4.  
     - deploy
5.  
    
6.  
   build fontend:
7.  
     stage: build
8.  
     script:
9.  
       - echo 'build fontend job'
10.  
     
11.  
    build backend:
12.  
      stage: build
13.  
      script:
14.  
        - echo 'build backend job'
15.  
     
16.  
    test fontend:
17.  
      stage: test
18.  
      script:
19.  
        - echo 'test fontend job'
20.  
      needs: ["build fontend"]
21.  
     
22.  
    test backend:
23.  
      stage: test
24.  
      script:
25.  
        - echo 'test backend job'
26.  
      needs: ["build backend"]
27.  
        
28.  
    deploy fontend:
29.  
      stage: deploy
30.  
      script:
31.  
        - echo 'deploy fontend job'
32.  
      needs: ["test fontend"]
33.  
     
34.  
    deploy backend:
35.  
      stage: deploy
36.  
      script:
37.  
        - echo 'deploy backend job'
38.  
      needs: ["test backend"]

使用 needs 参数后：对于前端任务，build fontend 完成后会立即执行下一个阶段的 test fontend，不管 build backend 是否完成。后端的 build backend 任务一样类似。

Web 界面中还可以查看 needs 依赖关系：

使用 rules 减少不必要 Job 运行

---

很多人会把前后端一起打包和部署，但其实只有前端代码有变化，针对后端的 Job 测试是多余的。因此，可以使用 rules 规则跳过某些不必要 Job。

示例：

1.  
   stages:
2.  
     - build
3.  
     - test
4.  
    
5.  
   build job:
6.  
     stage: build
7.  
     script:
8.  
       - echo 'build job'
9.  
    
10.  
    test job:
11.  
      stage: test
12.  
      script: 
13.  
        - echo 'test job'
14.  
      rules:
15.  
        - changes:
16.  
            - backend/*

• 当 backend 中有变化时运行 test job；

• 也可以使用类似的 only: changes 实现。

安装依赖使用国内源

---

由于国内网络的原因，如果使用默认源的话，安装依赖可能会很慢甚至失败，这时候可以设置国内或者代理解决。

nodejs

npm install --registry=https://registry.npm.taobao.org

or

yarn config set registry 'https://registry.npm.taobao.org'

python

pip install --trusted-host mirrors.aliyun.com -i https://mirrors.aliyun.com/pypi/simple -r requirements.txt

ruby

1.  
   gem sources --remove https://rubygems.org/
2.  
   gem sources -a https://gems.ruby-china.com
3.  
   gem sources –l

golang

go env -w GOPROXY=https://goproxy.cn,direct

设置 GOPRIVATE 来跳过私有库，比如常用的 GitLab，中间使用逗号分隔：

go env -w GOPRIVATE=*.gitlab.com

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 中尽量合并多条指令:

1.  
   ...
2.  
   RUN echo 1 \
3.  
     && echo 2
4.  
   ...

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 中使用本地仓库：

1.  
   stages:
2.  
     - build
3.  
    
4.  
   variables:
5.  
     PROJECTNAME: "test"
6.  
     DOCKERHUB: "hub.leffss.com"
7.  
     DOCKERHUBPROJECT: "library"
8.  
    
9.  
   before_script:
10.  
      - docker login ${DOCKERHUB} -u "${DOCKERHUBUSER}" -p "${DOCKERHUBPASS}"
11.  
     
12.  
    after_script:
13.  
      - docker logout ${DOCKERHUB}
14.  
     
15.  
    job1:
16.  
      stage: build
17.  
      script:
18.  
        - docker build --cache-from ${DOCKERHUB}/${DOCKERHUBPROJECT}/${PROJECTNAME}:latest -t ${DOCKERHUB}/${DOCKERHUBPROJECT}/${PROJECTNAME}:${CI_COMMIT_TAG} -t ${DOCKERHUB}/${DOCKERHUBPROJECT}/${PROJECTNAME}:latest .
19.  
        - docker images
20.  
        - docker push ${DOCKERHUB}/${DOCKERHUBPROJECT}/${PROJECTNAME}:${CI_COMMIT_TAG}
21.  
        - docker push ${DOCKERHUB}/${DOCKERHUBPROJECT}/${PROJECTNAME}:latest

在有了本地 Hub 仓库的情况下，还可以根据本章节【Docker 镜像体积优化】的原则自行打包一些项目编译需要用到的基础镜像，把项目需要用到的基础依赖包或者工具提前打包进去，这样又可以减少 Pipeline 安装依赖的时间。

优化 runner

---

当项目较多时，CI/CD 任务也会增多，这时候运行 Pipeline 效率会降低。极狐GitLab 提供共享 runner 给所有项目 CI/CD 任务使用，这里分享两种优化方式：

使用 Tag 标记 runner

在 runner 编辑页面设置 Tags，并且不勾选 Run untagged jobs，这时候此 runner 只运行使用 Tag 选择器的 Job，这样优化 runner 占用率.

示例：

1.  
   stages:
2.  
     - test
3.  
    
4.  
   job1:
5.  
     stage: test
6.  
     script: 
7.  
       - echo 'job1'
8.  
     tag:
9.  
       - "docker"

为项目注册专用 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 效率优化六大招式，欢迎大家一起交流！

这篇好文章是转载于：学新通技术网