电商网站建设渠道,全国公示信用信息系统,关于网站开发相关法律条款,网站开发服务计入什么科目目录
template 引用#xff0c;减少代码冗余#xff0c;增强 CI/CD 构建扩展性
问题 1#xff1a;代码冗余#xff0c;低效实践
问题 2#xff1a;维护性难#xff0c;工作量大
➤ local
➤ file
➤ remote
➤ template
收益 1#xff1a;一处修改#xff0c;多…目录
template 引用减少代码冗余增强 CI/CD 构建扩展性
问题 1代码冗余低效实践
问题 2维护性难工作量大
➤ local
➤ file
➤ remote
➤ template
收益 1一处修改多处生效
收益 2高效构建简单便捷
Component打造 CI/CD Pipeline 单一可信源简化 CI/CD Pipeline 构建
Component 仓库的构建
Component 的发布
Component 的引用 RunnerCI/CD 高效构建的利器
专有 共享更多灵活选择
动态扩缩容提高资源使用率
合规流水线助力流水线的安全合规使用 极狐GitLab CI 内置于极狐GitLab 一体化平台提供开箱即用的 CI/CD 能力也是受众多用户喜爱的 CI 工具之一。极狐GitLab CI 独特的设计机制和企业级功能特性能够帮助企业在大规模落地 CI/CD 实践时提高 CI/CD 构建效率、降低 Pipeline 维护成本同时还能保持足够的安全合规性。
本文从 CI/CD Pipeline 的构建入手讲述极狐GitLab CI 三大方面的使用 通过 template 、component 来缩短 Pipeline 编写时间、提高维护性 通过 Runner 的“花式”玩法来满足不同场景下的 CI/CD Pipeline 运行需求同时降低使用成本 用合规框架来保障 CI/CD Pipeline 的合规使用。
template 引用减少代码冗余增强 CI/CD 构建扩展性
在企业内部一种很常见的场景就是不同团队或者不同产品线都有自己独有的项目每个项目都有对应的 CI/CD 流水线随着项目的增多流水线的数量也会不断增加一个企业内部有可能存在数百甚至上千条流水线。 因为 CI/CD 流水线是软件交付从编码到上线的自动化展现形式因此大部分流水线之间会有比较高的相似度甚至有一些 stage 或者 job 是完全一样的比如在云原生交付场景下需要将应用程序打包成镜像使用极狐GitLab CI 进行构建的代码如下
build:image: docker:lateststage: buildservices:- docker:20.10.7-dindscript:- 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: buildimage:name: registry.jihulab.com/jh-xiaomage-devops/go-demo/kaniko:debugentrypoint: []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.0build:image: docker:lateststage: buildservices:- docker:20.10.7-dindscript:- 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.0include: - 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.0component-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-projectcomponent 仓库名称。
上述 component 位于仓库根目录下有一个 component-job-build-image job。
Component 的引用
如果想要在其他 Pipeline 中引用上述发布的 component在 .gitlab-ci.yml 中用如下语法引用
include: - component: jh.instance.url/username/component-projectmain inputs: stage: build image: docker:latest tags: cicd image_tag: 2.0.0stages: [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比如针对上述的 componentmain 分支表示 dind component那么可以新建一个 kaniko 分支来存放 kaniko 对应的 component最后在 .gitlab-ci.yml 中引用的时候指明分支即可
include: - component: jh-jhma.gitlab.cn/cicd-component/cicd-component-demokaniko inputs: stage: build image: gcr.io/kaniko-project/executor:debug tags: cicd image_tag: 2.0.0stages: [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。 RunnerCI/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 会动态创建一个 podpod 会根据 .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- verficationimage-singature:stage: singaturetags:- cosignimage: name: dllhb/cosign:1.0.0entrypoint: []before_script:- mkdir ~/.docker- cat $DOCKER_CRED_FILE ~/.docker/config.json- cat $COSIGN_KEY /tmp/cosign.key- export COSIGN_PASSWORD$COSIGN_PASSWORDscript:- cosign sign --key /tmp/cosign.key $CI_REGISTRY_IMAGE:1.0.0image-verfication:stage: verficationtags:- cosignimage: name: dllhb/cosign:1.0.0entrypoint: []before_script:- cat $COSIGN_PUB /tmp/cosign.pub- export COSIGN_PASSWORD$COSIGN_PASSWORDscript:- cosign verify --key /tmp/cosign.pub $CI_REGISTRY_IMAGE:1.0.0需要将上述流水线引入到合规流水线当中
include:- project: Compliance-Pipeline-Group/regular-pipelinefile: .gitlab-ci.yml最终该群组下的其他项目的流水线都会执行容器镜像的打包、扫描、签名及验证这四个步骤。
因此合规框架的选择是为了标记某些项目必须满足某些合规要求或者需要额外的监督然后通过执行合规流水线来完成合规工作的完成。
