极狐GitLab 企业级 CI/CD 规模化落地实践指南（一）

业界已经达成共识：CI/CD 是落地实践 DevOps 的重要手段，其本质是将软件交付流程中的步骤自动化运行起来，从而提高软件交付效率。随着企业规模扩大（人员增加、产品增多等），高效构建 CI/CD 成为研发效能提升的关键。

极狐GitLab CI 内置于极狐GitLab 一体化平台，提供开箱即用的 CI/CD 能力，也是受众多用户喜爱的 CI 工具之一。极狐GitLab CI 独特的设计机制和企业级功能特性，能够帮助企业在大规模落地 CI/CD 实践时，提高 CI/CD 构建效率、降低 Pipeline 维护成本，同时还能保持足够的安全合规性。

本文从 CI/CD Pipeline 的构建入手，讲述极狐GitLab CI 三大方面的使用：

1. 通过 template 、component 来缩短 Pipeline 编写时间、提高维护性；
2. 通过 Runner 的“花式”玩法来满足不同场景下的 CI/CD Pipeline 运行需求，同时降低使用成本；
3. 用合规框架来保障 CI/CD Pipeline 的合规使用。

template 引用，减少代码冗余，增强 CI/CD 构建扩展性

在企业内部，一种很常见的场景就是：不同团队或者不同产品线都有自己独有的项目，每个项目都有对应的 CI/CD 流水线，随着项目的增多，流水线的数量也会不断增加，一个企业内部有可能存在数百甚至上千条流水线。

因为 CI/CD 流水线是软件交付（从编码到上线）的自动化展现形式，因此大部分流水线之间会有比较高的相似度，甚至有一些 stage 或者 job 是完全一样的，比如在云原生交付场景下需要将应用程序打包成镜像，使用极狐GitLab CI 进行构建的代码如下：

build:
  image: docker:latest
  stage: build
  services:
    - docker:20.10.7-dind
  script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:1.0.0 .
    - docker push $CI_REGISTRY_IMAGE:1.0.0

此外，如果都是 java 或者 golang 项目，其编译或者测试的命令可能也是类似的。这种“重复”会随着流水线的增加而增加，以下问题也会随之而来：

问题 1：代码冗余，低效实践

如果每一条流水线都有一个 stage 或者 job 是相似的，大约有 10 行代码，那么数百上千条流水线，其重复的代码数量就是成千上万条。这种代码冗余在软件研发领域本身就是一种低效实践，如果不及时进行重构，随着项目的演进，就会变成技术债。

问题 2：维护性难，工作量大

在对 CI/CD Pipeline 进行优化的过程中，需要对流水线的部分内容进行改造，比如需要升级 dind 的版本，抑或为了安全地构建镜像，将构建方式从 dind 转向 kaniko，那么对应的代码就要变成：

  `services:
    - docker:24.0.3-dind
 `

及：

build:
  stage: build
  image:
    name: registry.jihulab.com/jh-xiaomage-devops/go-demo/kaniko:debug
    entrypoint: [""]
  script:
    - mkdir -p /kaniko/.docker
    - echo "{\"auths\":{\"${CI_REGISTRY}\":{\"auth\":\"$(printf "%s:%s" "${CI_REGISTRY_USER}" "${CI_REGISTRY_PASSWORD}" | base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json
    - >-
      /kaniko/executor
      --context "${CI_PROJECT_DIR}"
      --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
      --destination "${CI_REGISTRY_IMAGE}:1.0.0"

这时就要对所有的流水线进行改造，数百条乃至上千条流水线的改造将是一个巨大的工作量，且大量代码的“复制粘贴”过程，很难避免不出错。

在软件研发领域，解决冗余代码的重要手段就是通过抽象 + 复用：也就是将相同（或者相似）的内容抽象成模版，将模版“存储”在某一个地方，其他地方只需要简单引用模版即可。

对于 CI/CD Pipeline 来说也是一样。极狐GitLab template 就是极狐GitLab CI 内置的模版引擎功能，可以将抽象之后的模版存储在项目仓库中，其他项目通过 include 语法就可完成 template 的引用。

极狐GitLab template 的用法比较灵活，首先需要将“制作”模版，也就是将“重复”的代码提取出来，保存在一个 YAML 文件中。比如上面的镜像构建内容，可以写到一个 docker-image-build.gitlab-ci.yml 文件中。接下来使用 include 进行引用。根据模版存储的位置不同，include 的引用有以下四种方式：

➤ local

模版位于当前项目中，使用 local 关键字来引用。使用语法如下：

include:  
  - local: '/templates/docker-image-build.gitlab-ci.yml'

➤ file

模版和项目位于同一实例，但是不同仓库，使用 file 关键字来引用。使用语法如下：

include  
  - project: xiaomage/templates  
  - ref: main    
  file: /templates/docker-image-build.gitlab-ci.yml

➤ remote

引用远端仓库中的流水线，通常是不同实例之间的引用。使用语法如下：

include:   
  - remote: 'https://jihulab.com/xiaomage/teamplates/raw/main/docker-image-build.gitlab-ci.yml'

➤ template

极狐GitLab 内置模版的引用。极狐GitLab 根据自身多年的经验，沉淀了众多可以直接复用的模版，使用 template 语法即可使用。最典型的就是极狐GitLab DevSecOps 模版的引用。极狐GitLab DevSecOps 有密钥扫描、依赖项扫描、SAST、DAST、容器镜像扫描、模糊测试及许可证合规检测功能，所有功能两行代码即可开启。

因此，使用 template 能带来以下收益：

收益 1：一处修改，多处生效

如果需要对流水线的内容进行优化，比如将 dind 的版本进行升级，则只需要在模版中进行修改，其他引用的地方会随之生效，真正实现“一处修改，多处生效”，这完全避免了“一处变更，处处修改”所带来的重复劳动，而且流水线的冗余度也会降低。

收益 2：高效构建，简单便捷

template 可以实现多级嵌套，也就是模版里面引用模版。这样做的好处就是，可以将模版的内容细粒度化，可能是一个 stage，也可能是一个 job，比如容器镜像构建是一个模版，容器镜像安全扫描又是一个模版。如果要对新项目构建一条流水线，则可以直接使用多个 template 进行“搭积木”的方式就可快速完成流水线的构建，然后根据项目的实际构建流程来对参数或者流程做一些变更即可。

当然，为了高效的使用模版，还有一个问题需要注意，那就是模版中变量的覆盖。

为了灵活使用模版，使用同一套模版，构建出多个不同的实例。关键在于模版中变量的使用。比如，构建容器镜像时 tag 可能会随着版本的不同而不同，此时可以将 tag 设置为一个变量：

variables:
  IMAGE_TAG: 1.0.0

build:
  image: docker:latest
  stage: build
  services:
    - docker:20.10.7-dind
  script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG .
    - docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG

在引用的地方直接进行变量覆盖即可：

variables:
  IMAGE_TAG: "2.0.0"

include: 
  - remote: 'https://jihulab.com/xiaomage/teamplates/raw/main/docker-image-build.gitlab-ci.yml'

覆盖之后，镜像 tag 的值从默认的 1.0.0 就变成了 2.0.0 ，这样就能满足不同场景的诉求，兼具高效和灵活。

Component，打造 CI/CD Pipeline 单一可信源，简化 CI/CD Pipeline 构建

template 的使用大大降低了用户构建 CI/CD Pipeline 的难度，通过引用 + 参数覆盖的模式就能够快速构建出对应场景的 Pipeline，但是目前并没有一个 template 的单一可信源，来方便用户找到自己想用的 Pipeline，同时也无法让愿意贡献的用户将可用的 template 贡献出来，来共同打造 Pipeline 的繁荣生态。

为此，极狐GitLab 推出了 CI/CD Component 这一特色功能，其目的就是打造 CI/CD Pipeline 的单一可信源，通过将不同流水线（或者单独的作业）变成不同的 component，然后发布到 component 仓库，其他用户可以在此仓库中通过搜索来找到自己想要的 component，在构建流水线的时候直接引用即可，多个组件的引用就能够快速搭建起整个完整的流水线，这极大的改变了用户使用 CI/CD 的体验。

更为重要的是用户可以将自己认为已经得到实践的一些优秀流水线（或者单独的作业）以 component 的形式发布到 component 仓库，通过不同用户的不断贡献、迭代来共同打造繁荣的 CI/CD Pipeline 生态，最终构建企业内部 CI/CD Pipeline 单一可信源，提高 CI/CD Pipeline 构建效率的同时，安全性也得到了很大的提升。

注意：CI/CD Component 目前处于实验阶段。

CI/CD Component 示意图

因此，componnt 的核心是：component 仓库的构建、 component 的发布及 component 的引用。

Component 仓库的构建

通过创建一个极狐GitLab 仓库，并且将其标记为 component 仓库来构建一个初始的 component 仓库。该仓库至少需要两个文件 README.md 和 template.yml：

• README.md 可以对仓库中包含的 component 进行描述，方便用户学习使用；
• template.yml 就是 component 的具体内容。

可以通过不同的目录结构（分支、tag 等）来实现不同 component 的区分，比如：

├── template.yml
├── README.md
├── .gitlab-ci.yml
├── forntend/
│   └── template.yml
└── backend/
    └── template.yml

上述目录表示，在此 component 仓库中有三个可用的 component：

• 根目录下 template.yml 表示的 component；
• frontend 目录下 template.yml 表示的 component；
• backend 目录下 template.yml 表示的 component。

可以通过项目 → 设置 → 通用 → 可见性、项目功能、通用 → 开启 CI/CD 目录资源来将一个仓库标记为 component 仓库。

Component 的发布

如果需要发布一个 component，则需要将对应的内容写入到某个 template.yml 内，然后将该文件推送至 component 仓库即可。以上述镜像构建为例，将下述内容写入到某个 template.yml 中：

spec:  
  inputs:    
    stage:      
      default: test    
    image:      
      default: docker:latest    
    tags:      
      default: tags    
    image_tag:      
      default: 1.0.0
      
component-job-build-image:  
  image: $[[ inputs.image ]]  
  stage: $[[ inputs.stage ]]  
  tags:    
    - $[[ inputs.tags ]]  
  script:     
    - docker login -u "$REGISTRY_USER" -p "$REGISTRY_PWD" REGISTRY_URL    
    - docker build -t dllhb/cicd-component:$[[ inputs.image_tag ]] .    
    - docker push dllhb/cicd-component:$[[ inputs.image_tag ]]

然后推送至 jh.instance.url/username/component-project 目录下。参数说明：

• jh.instance.url：极狐GitLab 私有化部署实例地址；
• username：极狐GitLab 用户名；
• component-project：component 仓库名称。

上述 component 位于仓库根目录下，有一个 component-job-build-image job。

Component 的引用

如果想要在其他 Pipeline 中引用上述发布的 component，在 .gitlab-ci.yml 中用如下语法引用：

include:  
  - component: jh.instance.url/username/component-project@main    
  inputs:      
    stage: build      
    image: docker:latest      
    tags: cicd      
    image_tag: 2.0.0
    
stages: [build]

需要注意的地方有：

• 在 include 中完整写入 component（也就是 tempate.yml 存在的路径）的路径，通过 @ 来明确引用的是 component 的哪个版本（可以用分支、commit hash、tag 等表示）；
• 在 inputs 中写入具体的参数。

触发 CI/CD Pipeline，可以看到 component-job-build-image job 执行成功：

同样地，如果想要将 dind 的构建方式换为 kaniko，则无需替换上述 component 的内容，只需要再次发布一个以 kaniko 为主题的 component 即可。

这有很多种做法来实现，比如将 template.yml 放在 component 仓库的另外一个目录（非根目录下，因为根目录下已经有 dind 的 component）、分支、tag 下来表示这是不同的 component；比如针对上述的 component，main 分支表示 dind component，那么可以新建一个 kaniko 分支来存放 kaniko 对应的 component，最后在 .gitlab-ci.yml 中引用的时候指明分支即可：

include:  
  - component: jh-jhma.gitlab.cn/cicd-component/cicd-component-demo@kaniko   
  inputs:      
    stage: build      
    image: gcr.io/kaniko-project/executor:debug      
    tags: cicd      
    image_tag: 2.0.0
    
stages: [build]

当然，镜像也要由原来的 dind 改为 kinako，这只需要修改 inputs 的参数即可。

运行 CI/CD Pipeline 可以得到相同的结果。

component 的引入拉开了极狐GitLab CI/CD 使用新范式的序幕。这种通过用户贡献来打造 CI/CD Pipeline 单一可信源的做法，对于用户构建完整的 Pipeline 有着巨大帮助，不仅加速了 CI/CD Pipeline 的构建，还大大降低了用户学习繁杂 YAML 语法的成本。

以上所演示的代码均存储在极狐GitLab 私有化部署实例上，地址为 https://jh-jhma.gitlab.cn/cicd-component。

Runner，CI/CD 高效构建的利器

Runner 是极狐GitLab CI 的一个重要组件，它能够帮助运行 CI/CD 流水线中所定义的 Job。当研发人员提交代码变更后，极狐GitLab 就会“通知” Runner 去按照 .gitlab-ci.yml 定义的流水线步骤完成变更代码的构建、测试、部署等，此过程中 Runner 会根据所选择的 executor（比如针对 PowerShell 的 shell、针对容器的 docker 等）来针对不同环境进行 Job 的运行。关于 executor 的选择可以参考极狐GitLab 执行器官网。

Runner 像是一个“agent”，接受“server”端（极狐GitLab 实例）的请求，因此为了满足不同场景的需求，Runner 要能够满足在不同 OS、不同 CPU 架构上以不同的安装方式来运行。

专有 + 共享，更多灵活选择

Runner 分为专有和共享两大类：

• 专有：指 Runner 只给指定的项目用，通常是使用项目的一些信息（ Runner register token）来将 Runner 注册到对应的项目下面；
• 共享：指 Runner 是针对整个极狐GitLab 实例的，意味着整个实例下面的所有项目都可以使用这些 Runner，至于如何用、谁先用、谁后用是由极狐GitLab 的内部调度机制来实现的。

专有 Runner 的最大优势在于：

• 节省时间：专有 Runner 只给对应的项目运行 CI/CD 流水线，因此不用排队去等待共享 Runner 来执行 CI/CD 流水线，且随着项目、流水线的增加，排队将耗费大量时间；
• 自主可控：专有 Runner 是用户自己安装在自己可控的服务器上，在使用过程中如果要对流水线过程进行 Debug 或者对 Runner 配置进行修改，甚至想获取某些运行过程中的数据，则可以直接登陆到对应的 Runner 中进行操作。

专有 Runner 的配置信息

共享 Runner 的好处也是显而易见的：用户无需了解 Runner 的过多信息，也无需自己安装运维等。是一种比较省事的方式。

因此，用户可以根据自身的需求，来选择不同方式的 Runner 来完成相应的 CI/CD 流水线运行。

动态扩缩容，提高资源使用率

Runner 可以和云资源动态伸缩的特性紧密绑定，实现 Runner 的动态伸缩：当有 CI/CD 流水线需要运行的时候，Runner 使用一些资源（CPU、内存等）来执行所有 Job，当 CI/CD 流水线运行结束（成功或失败）后，对应的资源被释放，对环境进行恢复。

比如说，可以使用容器来运行 Runner，最典型的就是使用 Kubernetes 来运行极狐GitLab Runner。

当执行 CI/CD 时，Kubernetes 会动态创建一个 pod，pod 会根据 .gitlab-ci.yml 文件中描述的 stage 以及对应的镜像来生成相应的容器（所有容器在一个 pod 内，共享 pod 内部资源），流水线的运行都在容器内部，当流水线运行结束，pod 会删除，运行过程中的数据、所需的资源会被释放。

此外，还可以使用云厂商提供的 serverless 产品实现 Runner 的动态扩所容，提高资源的使用率。

合规流水线，助力流水线的安全合规使用

流水线使用过程中还会遇到一个场景：某一个流程是需要所有项目的流水线都必须运行的，比如在镜像构建结束必须进行镜像安全扫描，如果有安全漏洞就需要终止流水线的运行。这种情况下的解决方案往往是针对所有项目在流水线中使用 include 加入容器镜像扫描环节，但是随着项目数量的增多（成百乃至上千），这意味着巨大的重复工作量，而且无法确保操作的精准度。

而正确的解决方案就是：合规流水线。

合规流水线是极狐GitLab CI/CD 流水线内置的一个安全功能，主要是确保群组内的所有项目都能够运行指定的合规作业。通过在群组级别配置好合规框架，选择好每个项目都必须运行的合规流水线作业，则此群组下面的所有项目都会运行此合规作业，甚至后续在该群组下新创建的项目也会默认执行此合规作业。

合规流水线的使用，首先需要在群组级别进行合规框架的配置。在群组 → 设置 → 通用 → 合规框架中，选择新建合规框架，然后填入合规框架名称、描述、合规流水线配置（也就是合规流水线所存储的位置），最后选择一个背景颜色即可。

如将此合规框架设置为群组的默认合规框架，则此群组下面新建的项目都会默认使用此合规框架，默认运行此合规流水线，而且在项目页面会有合规框架的标签生成。

接着需要将合规流水线写入到此群组下面的一个项目（比如 Compliance-Pipeline）中。以容器镜像构建和扫描流水线为例，在 .gitlab-ci.yml 文件中写入如下内容：

include: 
  - remote: 'https://jihulab.com/xiaomage/teamplates/raw/main/docker-image-build.gitlab-ci.yml'
  - template: Security/Container-Scanning.gitlab-ci.yml

后续所有的新建项目都会执行容器镜像构建和容器镜像扫描这两个作业，而不是项目自带的流水线。

如果想要项目自带的流水线也被执行，只需要将合规流水线的内容和项目自带流水线的内容进行合并即可。比如自带流水线需要使用 cosgin 对打包的容器镜像进行签名和验证，防止镜像被篡改：

stages:
  - singature
  - verfication

image-singature:
  stage: singature
  tags:
    - cosign
  image: 
    name: dllhb/cosign:1.0.0
    entrypoint: [""]
  before_script:
    - mkdir ~/.docker
    - cat "$DOCKER_CRED_FILE" > ~/.docker/config.json
    - cat "$COSIGN_KEY" > /tmp/cosign.key
    - export COSIGN_PASSWORD="$COSIGN_PASSWORD"
  script:
    - cosign sign --key /tmp/cosign.key $CI_REGISTRY_IMAGE:1.0.0

image-verfication:
  stage: verfication
  tags:
    - cosign
  image: 
    name: dllhb/cosign:1.0.0
    entrypoint: [""]
  before_script:
    - cat "$COSIGN_PUB" > /tmp/cosign.pub
    - export COSIGN_PASSWORD="$COSIGN_PASSWORD"
  script:
    - cosign verify --key /tmp/cosign.pub $CI_REGISTRY_IMAGE:1.0.0

需要将上述流水线引入到合规流水线当中：

include:
  - project: 'Compliance-Pipeline-Group/regular-pipeline'
    file: '.gitlab-ci.yml'

最终该群组下的其他项目的流水线都会执行容器镜像的打包、扫描、签名及验证这四个步骤。

因此合规框架的选择，是为了标记某些项目必须满足某些合规要求或者需要额外的监督，然后通过执行合规流水线来完成合规工作的完成。