极狐GitLab 是 GitLab 在中国的发行版，专门面向中国程序员和企业提供企业级一体化 DevOps 平台，用来帮助用户实现需求管理、源代码托管、CI/CD、安全合规，而且所有的操作都是在一个平台上进行，省事省心省钱。可以一键安装极狐GitLab，详情可以参考极狐GitLab 下载安装官网。
GitLab 中文版学习资料
- 驭码CodeRider 官网：https://coderider.gitlab.cn/
- GitLab 中文版官网：https://gitlab.cn
- GitLab 中文文档：https://docs.gitlab.cn
- GitLab 中文下载安装：https://gitlab.cn/install
关联阅读
- include 语法减少 CI/CD Pipeline 代码冗余，提升构建效率
- 极狐GitLab 企业级 CI/CD 规模化落地实践指南（一）
计算机中的所有问题都可以通过增加一个间接层来解决。
—— David Wheeler（大卫·惠勒）
编写 CI/CD 流水线是 DevOps 工程师最常见的工作。当有新功能、新工具需要添加到 CI/CD 流水线中时，DevOps 工程师就要去改造流水线；当有新项目启动时，DevOps 工程师就需要从零到一构建新的流水线。
很多时候，快速构建流水线的方法往往是copy --> paste --> modification。虽然项目不同，但是 CI/CD 流水线的步骤都很相似（构建、测试、部署等）。克隆一份既有项目的流水线，再根据新项目的不同点做一些改动，就能完成新流水线的打造。
当然，如果新项目少的时候，这种方式也是一种很快乐的方式，毕竟 copy & paste 是一种费体力而不费脑力的劳作方式，而且很容易出成绩（一个项目的流水线可以洋洋洒洒搞出上百行甚至几百行的流水线代码）。
但是随着新项目数量的增加，这种手工劳作方式容易体力不支；如果 copy 的模版出现了问题，则需要对所有的流水线都去做修改，这时候就容易升天，更别说对所有流水线进行版本管理、安全补丁等日常维护了。
复用性：CI/CD 工具的必选项
上面的问题体现了 CI/CD 流水线构建的核心诉求之一 —— 复用。简单理解复用，就是将有共性的流水线块抽象出来（比如 Java 项目的构建、容器镜像的构建），将它们当作“模版”，其他人无需重复造轮子（copy & paste），只要简单引用就能使用这些流水线块来快速构建流水线，而且后期的维护也会变得很简单。这就是文章开头大卫·惠勒的名言在 DevOps 领域的实践了。
极狐GitLab CI 是一款成熟、用户体量超大的 CI/CD 工具。复用性也是其这几年 CI/CD 功能演进的一个重要方向。之前就有 template 功能，方便用户引用不同的模版来快速构建流水线，而且极狐GitLab 本身还内置了很多安全检测的模版，比如 SAST、DAST、容器镜像扫描等，用户可以直接用 include: template 语法来在 CI/CD 中引用。关于 include 的详细用法，可以参考过往的技术内容 include 语法减少 CI/CD Pipeline 代码冗余，提升构建效率。
关注极狐GitLab 公众号，后台回复“白皮书”关键字，免费领取极狐GitLab CI/CD 企业级实践白皮书。
为了进一步提升 CI/CD 流水线的复用性、可用性，极狐GitLab 在过去的几个版本中又引入了两个堪称王炸级别的功能 —— CI/CD component 和 CI/CD Catalog。
CI/CD component
极狐GitLab 自 16.0 版本引入 component 功能（Experimental），在 16.6 版本中将其升级为 Beta 版本。目前最新版本为 16.8。
component 是一种 CI/CD 流水线块（block），可以将某一个作业设置为一个 component，然后发布到 component 仓库中，这样其他用户就可以通过 include: component 语法来直接使用此 component 了。component 有三个要素：component 仓库、component 的发布以及 component 的引用。component 仓库有特殊的目录结构，可以在一个仓库中放多个 component。一个 component 仓库一般包含：
- README.md：详细描述此仓库中的 component 以及对应的功能和用法。
- templates 目录：所有的 component 配置都包含在此目录下。可以将包含 component 内容的 YAML 文件直接放置在 template 根目录下，也可以新建一个子目录，放置在子目录下。
- .gitlab-ci.yml文件：实现 component 的测试和发布自动化。
- LICENSE.md：许可证信息，标明该仓库的许可使用信息。比如使用 Apache 2.0 或 MIT。
templates
├── LICENSE.md
├── README.md
├── second-component
│ └── template.yml
├── docker-build-image.yml
└── third-component├── backend│ └── template.yml└── frontend└── template.yml
上述的目录结构包含了 4 个可用的 component，每一个 YAML 文件都代表一个 component。比如根目录下的 template.yml文件内容为：
spec:inputs:stage:default: testimage:default: docker:20.10.7-dindimage_tag:default: 1.0.0tags:default: jh-gitlab
---
component-job-build-image:image: $[[ inputs.image ]]stage: $[[ inputs.stage ]]tags:- $[[ inputs.tags ]]script:- docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY- docker build -t dllhb/cicd-component:$[[ inputs.image_tag ]] .- docker push dllhb/cicd-component:$[[ inputs.image_tag ]]
这是一个构建 docker 容器镜像并将其推送到极狐GitLab 内置的容器镜像仓库的 component。其他用户可以使用jh.instance.url/org-name/component-repo-name路径来将此 component 引用到自己的流水线中。在 .gitlab-ci.yml文件写入如下内容即可完成该 component 的引用：
include:- component: jihulab.com/jh-xiaomage-devops/cicd-catalog/docker-image-build@maininputs:stage: build image: docker:20.10.7-dind tags: jh image_tag: 1.0.0
触发 CI/CD 流水线可以看到具体的构建过程。
关于 CI/CD component 的详细使用和解读，可查看技术文章极狐GitLab 企业级 CI/CD 规模化落地实践指南（一）。component 能够让用户在构建 CI/CD 流水线时，不用再重复造轮子，但是如何让优秀、安全的 component 让更多的用户看到并使用呢？答案就是下一篇文要讲的 CI/CD Catalog。
