出大招了，这个顶级 CI/CD 产品，最近甩出了两个“王炸”

极狐GitLab CI 自 16.0 版本以来，陆续引入了 CI/CD component 和 CI/CD Catalog 两个重量级功能，提高了 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 代码冗余，提升构建效率。

为了进一步提升 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: test
    image:
      default: docker:20.10.7-dind
    image_tag:
      default: 1.0.0
    tags:
      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@main
    inputs:
      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。

CI/CD Catalog（目录）

“赠人玫瑰，手有余香”，好东西要学会分享。

CI/CD Catalog（目录，下面统称目录）是一个集中式的 Hub中式的 hub，开发人员或企业/组织可以将其开发且经过验证的cCI/CD Component 发布到目录中，这样其他开发人员或企业/组织就能够通过浏览/查找 CI/CD 目录来找到符合企业自身需求的 component，然后直接使用这些 component 来快速构建流水线。速构建流水线。

任何人都可以创建 component 并发布到目录中，因此，CI/CD 目录解决了 CI/CD component 的三个问题：易发现性、复用性及开放性。 CI/CD 目录能帮助企业打造内部的 CI/CD component 单一可信源。

极狐GitLab 自 16.1 版本开始引入目录功能（Experimental），在 16.7 版本中将其升级为 Beta 版本。

下面为大家揭秘极狐GitLab CI/CD 目录的用法。

将项目标记为目录资源

首先要将存放 component 的项目标记为目录，发布的 component 才能够被其他用户检索、使用。通过项目 --> 通用 --> 可见性、项目功能、权限 --> CI/CD 目录资源（Beta） 来开启此功能。

注意：在创建项目的时候，一定要写清楚项目描述以及 README.md，这些是能够帮助用户快速了解此 component 功能的重要信息。

发布 component 到目录资源

将项目下的 component 发布到目录资源中非常简单，在 .gitlab-ci文件中写入如下内容即可：

create-release:
  stage: deploy
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  script: echo "Creating release $CI_COMMIT_TAG"
  rules:
    - if: $CI_COMMIT_TAG
  release:
    tag_name: $CI_COMMIT_TAG
    description: "Release $CI_COMMIT_TAG of components in $CI_PROJECT_PATH"

上面的代码显示，当创建 tag的时候，就会自动触发此流水线，然后发布一个同 tag的 component 到目录资源中。比如，当创建 3.0.0tag 的时候，就会触发流水线自动执行：

构建日志会显示，3.0.0的 component 发布成功，同时给出了 component 对应的地址。

最后可以在下面的检索步骤中，在 CI/CD 目录中看到对应的 component。

检索 CI/CD 目录

一旦 component 发布成功，就可以在目录中检索到了。通过极狐GitLab 侧边栏中的搜索或转到 --> 探索 --> CI/CD 目录来找到自己发布或自己所需的 component。

上面的图中，在 CI/CD 目录中就有两个可用的 component：cicd-catalog（版本 1.0.0）和 docker-image-build（版本 3.0.0）。点击想用的 component 就可以在对应的 README 文件中看到 component 对应的功能和使用方法。

使用目录资源中的 component 和单独使用一个 component 没有什么不同，只需要使用 include:component语法即可在 CI/CD 流水线中引用。

未来可期

CI/CD component 和 CI/CD 目录当前都在 Beta 版本，还没有 GA，但是这两个功能毫无疑问将为用户加速构建 CI/CD 流水线带来极大的便利，企业如果用好这两个功能，就能进一步管理好企业内部的 CI/CD 流水线。

关注【极狐GitLab】获取更多 DevOps 行业最佳实践。

标签：CI,出大招,image,component,CD,流水线,目录
From： https://www.cnblogs.com/jihugitlab/p/17995718