首页 / 平台管理 / 流水线管理 / 流水线存储策略 / 设置构建/发布流水线存储策略（Alpha）

设置构建/发布流水线存储策略（Alpha）

在日常功能迭代过程中，项目人员使用流水线对业务进行自动化处理时，将持续生成大量流水线执行记录和测试报告。执行记录和测试报告均保存在平台组件 etcd 中，若不及时处理，会降低 etcd 存储性能，影响平台整体使用。

针对该问题，平台提供了完善的清理和归档机制，支持从 etcd 中按需清理执行记录，或将执行记录归档到其他存储中，满足数据存储需求的同时也可平衡存储压力。

清理执行记录

统一为集群中的每条构建或发布流水线配置清理策略。平台会根据清理策略清理 etcd 中的执行记录，减少对存储性能的影响。

操作步骤

在左侧导航栏中，单击 流水线及归档管理 > 归档存储设置。
单击 构建/发布流水线。
在 清理策略 页签中，单击。
参考以下说明配置相关参数。
- 每条流水线最多保留：为了避免执行记录过多影响 etcd 存储性能，建议您设置每条流水线最多保留的执行记录数。
- 每条流水线默认保留：尽管清除执行记录可以优化存储资源，但建议不要过度清除执行记录。相反，推荐设置默认保留一定数量的流水线执行记录，以便在需要的时候进行追溯和分析，快速发现流水线使用问题。
说明：设置了默认保留数值后，DevOps 中所有新建流水线都会默认按此规则清理执行记录。同时，平台支持流水线使用者在 DevOps 修改某条流水线的最多保留数，且数值不可超过此处设置的最多保留数值。如需给已有流水线设置清理策略，可参考下面的 批量给流水线设置清理策略。
单击更新。

批量给流水线设置清理策略

如果环境中存在大量流水线需要设置清理策略，每条手动配置会比较繁琐，您可通过脚本的方式批量设置清理策略。下面针对构建、发布流水线分别提供了脚本示例。

注意：在启用归档策略不久的环境中，执行该操作可能由于历史记录还未来得及存档于数据库中就已被清理。建议在确保新产生的构建、发布流水线执行记录（BuildRun、DeliveryRun）中也带有 finalizer archive.katanomi.dev/resource 的情况下执行该操作。具体命令可以参考：

构建：kubectl get buildruns.builds.katanomi.dev {name} -n {namespace} -o jsonpath='{.metadata.finalizers}' | grep "archive.katanomi.dev/resource"

发布流水线：kubectl get deliveryruns.deliveries.katanomi.dev {name} -n {namespace} -o jsonpath='{.metadata.finalizers}' | grep "archive.katanomi.dev/resource"

构建

需在构建的集群中执行脚本。

给当前集群所有命名空间下的构建设置清理策略，只保留最近 3 条执行记录，示例如下：

#!/bin/bash

items=$(kubectl get ns --no-headers | awk '{print $1}')
for ns in ${items};
do
  builds=$(kubectl get builds.builds.katanomi.dev --no-headers -n ${ns} | awk '{print $1}')
  for build in ${builds};
  do
     kubectl patch --type='merge' builds.builds.katanomi.dev ${build} -p '{"spec":{"historyLimits": {"count": 3} } }' -n ${ns}
  done
done

发布流水线

需在 global 集群中执行脚本。

给所有项目下的发布流水线设置清理策略，只保留最近 3 条执行记录，示例如下：

#!/bin/bash

items=$(kubectl get ns --no-headers | awk '{print $1}')
for ns in ${items};
do
  deliveries=$(kubectl get deliveries.deliveries.katanomi.dev --no-headers -n ${ns} | awk '{print $1}')
  for delivery in ${deliveries};
  do
     kubectl patch --type='merge' deliveries.deliveries.katanomi.dev ${delivery} -p '{"spec":{"historyLimits": {"count": 10} } }' -n ${ns}
  done
done

归档执行记录或测试报告

为了更好地跟踪流水线构建和发布历史，您还可为集群中的每条构建流水线或发布流水线配置归档策略，以将流水线执行记录或测试报告转存到指定存储中。如果已经配置了清理策略，归档策略可确保即使平台从 etcd 清理了执行记录、测试报告，您仍可正常查询已归档的执行记录、测试报告。

说明：

对于流水线，平台从 etcd 中清理了执行记录后，通过归档策略您可正常查询该记录，但无法在记录中进行阶段重试。
支持归档的测试报告类型为：Pytest 接口自动化测试报告、Robot Framework 接口自动化测试报告。

配置归档存储

根据待归档资源准备可用存储，并确保 global 集群、运行流水线的集群均可正常访问存储。
- 用于归档执行记录：使用关系型数据库 MySQL 8.0 或 ProgreSQL 12。
- 用于归档测试报告：使用对象存储 MinIO 。
说明：存储实例各部署一个即可。存储实例使用的存储类可以跟构建默认存储类一致，也可单独指定。
在存储中需至少创建一个数据库（或存储桶）。

支持使用不同数据库（或存储桶）来分别存储归档数据。例如，创建 db-devops-archive-builds 和 devops-archive-deliveries 数据库分别用于存储构建记录和发布记录。
切换至平台，在左侧导航栏中，单击 流水线及归档管理 > 归档存储设置。
在 存储设置 页签中，单击创建。

参考以下说明配置相关参数。

参数	说明
名称	存储实例的名称。
存储类型	用于归档执行记录：Database 用于归档测试报告：MinIO
工具	用于归档执行记录：MySQL、PostgreSQL 用于归档测试报告：MinIO
版本	（选择 Database 类型的存储时需配置）数据库版本。
访问地址	存储实例的访问地址，例如集群外访问地址 192.168.100.100:30000 。
凭据	存储访问凭据，用于访问归档数据库或桶。
数据库名称或桶名称	需与存储上的数据库或桶名称一致。

配置归档策略

配置后，您可在被归档的执行记录详情页看到 Archived 标识。归档后的执行记录与归档前无差异，但测试报告归档后您可在执行记录详情页看到详细的测试结果，例如：用例执行详情。

操作步骤

在左侧导航栏中，单击 流水线及归档管理 > 归档存储设置。
单击 构建/流水线。
在 归档策略 页签中，单击。
参考以下说明配置相关参数。

构建记录归档/发布记录归档
- 平台会自动选择所需存储（Database 类型）。
- 单击添加，设置流水线的执行记录保留规则。例如：每条流水线主分支至少保留 3 条执行记录 表示构建流水线的主分支进行构建时，即使设置了清理策略，也至少有 3 条最近的执行记录保留供查询。
- 开启归档策略后，为了减少存储空间，降低存储成本，建议定期清理归档存储中的执行记录。
测试报告归档
- 平台会自动选择所需存储（MinIO 类型）。
- 开启归档策略后，为了减少存储空间，降低存储成本，建议定期清理归档存储中的测试报告。
单击更新。