平台中心
首页 / 平台管理 / 流水线管理 / 平台工程 CI/CD / 流水线策略

流水线策略

概述

流水线策略是平台工程 CI/CD 提供的一项重要功能，旨在帮助平台团队有效地管理和控制业务团队的软件开发交付流程。通过制定和实施一系列详尽的规则和策略，平台团队能够统一管理软件交付的安全性和合规性，提升交付质量。

本文档将对策略定义、策略约束范围以及提供相应的示例，详细说明如何创建并使用策略约束业务侧的流程及交付质量。

策略定义

策略约束的具体判断逻辑是由引用的规则确定的，定义策略时，需要理解策略与规则的关系以及策略字段的用法。

策略与规则

apiVersion: policies.katanomi.dev/v1alpha1
kind: Policy #资源类型
metadata:
  name: policy-sonar-analysis #资源名称
spec:
  phases:
    - BuildRunResultChanged
  scopes:
    - apiVersion: builds.katanomi.dev/v1alpha1
      kind: BuildRun
      nameRegex: .*
  checks: #规则检查
    - ruleRef:
        kind: ClusterRule
        name: sonarqube-analysis-coverage #引用的规则名称
      params:
        - name: coverage #规则中定义的变量参数名称
          value: 60.0

策略字段说明

  1. 对于策略而言, 主要存在三部分配置 spec.scopes, spec.checks 以及 spec.phases，在 spec.scopes 中通过 kind 和 apiVersion 指定资源类型 ,通过 nameRegex 和 selector 对具体资源进行过滤。

  2. 如果 nameRegex 与 selector 规则同时存在，则需要资源同时满足。如果没有提供 nameRegex 或者 selector 配置，则不会对资源进行校验。

  3. 支持同时指定对多种资源进行过滤，在存在 scope 配置时，kind 与 apiVersion 为必填字段。

资源 阶段 描述 其他 资源定义
构建 BuildRunDefinitionReady 构建定义准备完成时 默认策略 Build + BuildSpec(Build 资源类型以及 spec 中的构建流程详细定义信息)
构建 BuildRunResultChanged 构建产生结果时 BuildRun
构建 BuildRunCompleted 构建结束时 BuildRun
流水线 DeliveryRunDefinitionReady 发布定义准备完成时 默认策略 Delivery + DeliverySpec(Delivery 资源类型以及 spec 中的发布流程详细定义信息)

  1. 在 spec.checks 中指定多个策略 check 规则，多个 check 之间为且的关系，每个 check 包含 ruleRef all 以及 any 的配置， 三种配置可以同时存在，并且按照且的关系处理对资源进行规则校验，每条配置后规则对应的是一个 clusterRule，通过 ruleRef 指定 clusterRule 时， kind 和 name 为必填值。

  2. 如果需要提供 params 参数，参数 name 为必填值。

在 spec.phases 中指定该策略被生效的阶段，目前针对构建和流水线，支持的阶段见上面的表格。

phases 中可以指定多个 phase，意味着在这些阶段都会生效。可以参看以下使用场景配置 phases：

约束范围及资源分发

定义策略内容之后，需要明确策略的约束范围，即哪些项目，哪些命名空间下的流水线会受到对应策略的约束。且已创建的资源需要分发到对应的集群中生效。构建的策略、规则资源需要同步分发到构建所在的业务集群，流水线的策略、规则，需要同步分发到 global 集群。

  1. 平台通过 labelSelector 筛选 ResourceSyncer 资源中的 spec.namespaces 确定需要同步策略资源的命名空间，从而确定约束范围。

  2. 多个 labelSelector 的关系为或的关系，只要命名空间符合其中一个 labelSelector，就会被同步。labelSelector 支持的操作可以 参看官方文档 。

  3. 命名空间与项目相关的 label 如下所示，在为项目所属命名空间分配资时，可以使用如下 label 进行配置：

  1. 使用 labelSelector 可以实现如下两个常用的场景：
spec:
  # namespaces 下 labelSelector 为 OrED 的关系
  namespaces:
    # 通过 labelSelector 过滤相关命名空间 labelSelector 内各个条件为 AndEd 的关系
    # 详见: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#resources-that-support-set-based-requirements
    # 筛选 labels 中包含 key 为 cpaas.io/project 并且 value 为 devops 或者 ait 的命名空间
    - matchExpressions:
        - key: cpaas.io/project
          operator: In
          values:
            - devops
            - ait

    # 通过 labelSelector 过滤相关命名空间 labelSelector 内各个条件为 AndEd 的关系
    # 详见: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#resources-that-support-set-based-requirements
    # 筛选 labels 中包含 key 为 cpaas.io/inner-namespace 并且 value 为 devops 或者 ait 的命名空间
    - matchExpressions:
        - key: cpaas.io/inner-namespace
          operator: In
          values:
            - devops
            - ait
spec:
  # namespaces 下 labelSelector 为 OrED 的关系
  namespaces:
    # 通过 labelSelector 过滤相关命名空间 labelSelector 内各个条件为 AndEd 的关系
    # 详见: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#resources-that-support-set-based-requirements
    # 筛选 labels 中包含 key 为 cpaas.io/project 的命名空间
    - matchExpressions:
        - key: cpaas.io/project
          operator: Exists

    # 通过 labelSelector 过滤相关命名空间 labelSelector 内各个条件为 AndEd 的关系
    # 详见: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#resources-that-support-set-based-requirements
    # 筛选 labels 中包含 key 为 cpaas.io/inner-namespace 的命名空间
    - matchExpressions:
        - key: cpaas.io/inner-namespace
          operator: Exists

策略场景示例

示例一：平台团队要求全平台业务侧测试覆盖率必须大于 60%，以满足公司代码质量规范要求

操作流：

  1. 创建规则： 管理员请参看 流水线规则 创建测试覆盖率约束规则，将规则 yaml 文件保存到代码仓库中。
  2. 分发规则资源： 管理员进入 平台管理 视图，在 集群管理 > 集群配置管理 > 创建同步规则，选择保存规则的代码仓库 > 规则文件所在的分支 > 选择资源文件 > 选择源文件目录 > 配置需要同步的目标集群 > 创建，将规则资源同步下发到目标集群中。
  3. 创建策略： 管理员定义约束范围为全平台，定义策略并在策略中引用测试覆盖率约束规则并设置覆盖率阈值为 60.0，将下方示例中的 yaml 文件保存到代码仓库中。
  4. 分发策略资源： 管理员进入 平台管理 视图，在 集群管理 > 集群配置管理 > 创建同步规则，选择保存策略的代码仓库 > 策略文件所在的分支 > 选择资源文件 > 选择源文件目录 > 配置需要同步的目标集群 > 创建，将策略资源同步到目标集群中。
  5. 约束生效： 同步成功后，业务成员执行约束范围内的流水线过程中将会进行策略检测。

注意： 建议将规则资源文件和策略资源文件放在不同的文件目录下，便于管理。

apiVersion: operator.alauda.io/v1alpha1
kind: ResourceSyncer
metadata:
  annotations:
    cpaas.io/description: 分发执行策略到相关命名空间
  name: policy-sonar-analysis
spec:
  # namespaces 下 labelSelector 为 OrED 的关系
  namespaces:
    # 通过 labelSelector 过滤相关命名空间 labelSelector 内各个条件为 AndEd 的关系
    # 详见: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#resources-that-support-set-based-requirements
    # 筛选 labels 中包含 key 为 cpaas.io/project 的命名空间
    - matchExpressions:
        - key: cpaas.io/project
          operator: Exists

    # 通过 labelSelector 过滤相关命名空间 labelSelector 内各个条件为 AndEd 的关系
    # 详见: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#resources-that-support-set-based-requirements
    # 筛选 labels 中包含 key 为 cpaas.io/inner-namespace 的命名空间
    # 若 Global 集群不需要同步资源，则无需添加该配置
    - matchExpressions:
        - key: cpaas.io/inner-namespace
          operator: Exists

  # 配置待同步的策略资源，仅支持配置命名空间级别的资源
  resource:
    apiVersion: policies.katanomi.dev/v1alpha1
    kind: Policy
    metadata:
      name: policy-sonar-analysis
    spec:
      phases:
        - BuildRunResultChanged
      scopes:
        - apiVersion: builds.katanomi.dev/v1alpha1
          kind: BuildRun
          nameRegex: .*
      checks:
        - ruleRef:
            kind: ClusterRule
            name: sonarqube-analysis-coverage #引用的规则名称
          params:
            - name: coverage #规则中定义的变量参数名称
              value: 60.0

示例二：平台团队要求业务侧某个团队的 Builds 流程必须引用平台团队定义的流水线模板

操作流：

  1. 管理员定义流水线模板，模板定义参看文档：DevOps 《用户手册》的 “CI/CD > 构建 > 自定义任务或模板 > 编写自定义模板“。
  2. 管理员将模板保存到代码仓库中，并使用 源管理 将保存的模板分配给业务团队使用。源管理使用指南 参看文档 。
  3. 管理员定义策略约束范围，定义策略在策略中引用开箱即用的规则template-gitsource-resolver-check，并将策略保存到代码仓库中。
  4. 参看示例一的操作流，将策略资源同步到目标集群。
  5. 同步成功后，业务成员执行约束范围内的流水线过程中将会进行策略检测。

注意： 平台提供的开箱即用的规则可直接在策略中引用，不需要手动创建规则，创建策略资源即可。

apiVersion: operator.alauda.io/v1alpha1
kind: ResourceSyncer
metadata:
  annotations:
    cpaas.io/description: 分发执行策略到相关命名空间
  name: policy-template
spec:
  # namespaces 下 labelSelector 为 OrED 的关系
  namespaces:
    # 通过 labelSelector 过滤相关命名空间 labelSelector 内各个条件为 AndEd 的关系
    # 详见: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#resources-that-support-set-based-requirements
    # 筛选 labels 中包含 key 为 cpaas.io/project 并且 value 为 project-a 的命名空间
    - matchExpressions:
        - key: cpaas.io/project
          operator: In
          values:
            - project-a

    # 通过 labelSelector 过滤相关命名空间 labelSelector 内各个条件为 AndEd 的关系
    # 详见: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#resources-that-support-set-based-requirements
    # 筛选 labels 中包含 key 为 cpaas.io/inner-namespace 并且 value 为 project-a 的命名空间
    # 若 Global 集群不需要同步资源，则无需添加该配置
    - matchExpressions:
        - key: cpaas.io/inner-namespace
          operator: In
          values:
            - project-a

  # 配置待同步资源，仅支持配置命名空间级别的资源
  resource:
    apiVersion: policies.katanomi.dev/v1alpha1
    kind: Policy
    metadata:
      name: policy-reference-template
    spec:
      scopes:
        - kind: Build
          apiVersion: builds.katanomi.dev/v1alpha1
          nameRegex: .*
      checks:
        - all:
            - ruleRef:
                kind: ClusterRule
                name: template-gitsource-resolver-check # 内置规则的名称，此规则中约束了必须使用特定源中的自定义模板
              params: # 指定规则中的参数
                - name: url
                  value: https://gitlab.com/group/repository # 源所在代码仓库
                - name: revision
                  value: refs/heads/main # 模板所在分支
                - name: pathInRepo
                  value: a-go-template.yaml # 模板定义文件