Harness 中的本地优先策略：降低云端依赖

从零到一理解Harness本地优先策略构建抗风险、降成本的CI/CD混合云架构实践摘要/引言在多云与混合云成为数字化转型常态的今天CI/CD流水线作为软件交付的“中央动脉”其稳定性、成本可控性与数据安全性面临着前所未有的挑战。你是否遇到过这些让你彻夜难眠的场景突然的公有云区域断电导致核心流水线停滞3小时客户投诉激增月末CI/CD账单爆表——临时扩容的云原生Runner节点费用、跨区域调用的传输费、敏感代码的合规云存储费占比超70%为了满足金融/医疗行业的“敏感数据不离本地机房”合规要求被迫放弃Harness这类SaaS化CI/CD平台的便利性团队想测试边缘设备端的微服务但是云Runner节点无法直接访问本地私有Git仓库或硬件测试环境。如果你正被以上任意一个问题困扰或者想提前为团队的CI/CD系统做好抗灾预案、成本优化、合规适配、场景扩展这四大准备那么这篇万字长文正是为你准备的。本文将围绕Harness平台主要覆盖Harness CI Community Edition/Enterprise Edition 9.x的本地优先策略Local First Strategy, LFS展开从核心概念拆解、问题背景分析、系统架构设计、分步落地实现、性能调优与最佳实践、行业趋势展望六个维度进行全方位、无死角的讲解并配有大量的Mermaid架构图/流程图、Python辅助代码示例、YAML配置文件、真实项目应用场景、最佳实践Tips与FAQ。读完本文你将掌握以下核心技能理解什么是CI/CD领域的“本地优先策略”它与“纯SaaS”“纯本地部署”“混合云”的本质区别深入解析Harness LFS的核心组件Harness Local Runner Manager, LRM、Local Agent、Local Runner、Local Git Sync、Local Secret Manager、Local Cache Store及其交互逻辑从零开始搭建一套完整的Harness LFS混合云架构包含Harness SaaS控制平面本地数据平面的安装配置学会配置强制本地执行规则、数据隔离规则、缓存同步规则实现“敏感任务本地跑、非敏感任务弹性扩到云、所有数据本地优先存”的理想状态掌握Harness LFS的性能优化技巧如Runner池调度策略、本地缓存压缩、增量Git同步、成本控制方法如按需启动本地Runner、跨区域调度限制、安全合规配置如本地Secret加密、数据审计日志本地存了解Harness LFS的未来发展方向如AI驱动的本地/云调度决策、更多本地集成的支持以及如何将其应用到真实的金融、医疗、制造、边缘计算等行业场景中。目标读者与前置知识目标读者本文主要面向以下三类人群DevOps工程师/SRE工程师负责公司CI/CD系统的选型、搭建、维护与优化希望降低成本、提升稳定性、满足合规要求技术架构师/CTO负责公司技术架构的设计与决策正在评估多云/混合云CI/CD方案或者想将现有纯SaaS/纯本地CI/CD系统升级为混合云架构云原生开发者/技术爱好者对CI/CD领域的新技术、新架构感兴趣想了解Harness这类新一代SaaS化CI/CD平台的本地能力。前置知识阅读本文前你需要具备以下基础知识或技能基础的Linux操作能熟练使用Shell命令如ssh、scp、systemctl、docker/kubectl进行服务器管理、容器/集群部署基础的CI/CD概念了解Git、GitOps、CI持续集成、CD持续部署/持续交付、Runner/Agent、流水线Pipeline、Stage、Step、Secret、Cache等核心术语基础的容器/云原生知识了解Docker、KubernetesK8s的基本概念与操作如Pod、Deployment、Service、ConfigMap、SecretHarness平台的入门操作可选但推荐如果之前没有接触过Harness建议先阅读官方文档的Harness CI Quickstart了解Harness SaaS平台的基本操作流程。文章目录第一部分引言与基础 (Introduction Foundation)引人注目的标题摘要/引言目标读者与前置知识文章目录第二部分核心内容 (Core Content)问题背景与动机为什么我们需要CI/CD本地优先策略5.1 纯SaaS CI/CD的三大痛点5.2 纯本地部署CI/CD的三大短板5.3 混合云CI/CD的过渡性问题5.4 本地优先策略的诞生与价值主张5.5 问题演变发展历史的Markdown表格核心概念与理论基础什么是Harness本地优先策略6.1 核心概念定义6.2 概念之间的关系ER实体关系图、交互关系图、核心属性维度对比表6.3 Harness LFS的系统架构总览Mermaid架构图6.4 Harness LFS的数学模型成本-风险-效率的三维平衡模型6.5 Harness LFS的核心调度算法LRUCostRisk的混合调度策略Mermaid流程图环境准备从零搭建Harness LFS混合云架构的基础环境7.1 所需的软件、硬件与云资源清单7.2 本地K8s集群的搭建使用Kind/K3s作为示例7.3 Harness SaaS控制平面的注册与初始化7.4 本地Secret Manager的准备使用HashiCorp Vault作为示例7.5 本地Git服务器的准备使用GitLab CE作为示例7.6 本地Docker Registry的准备使用Harbor作为示例7.7 本地Cache Store的准备使用MinIO作为示例分步实现从零到一配置Harness LFS混合云架构8.1 步骤一安装Harness Local Runner ManagerLRM到本地K8s集群8.2 步骤二配置Harness Local Agent与SaaS控制平面的连接8.3 步骤三配置本地Runner池与标签规则8.4 步骤四配置本地Secret Manager与Harness的集成8.5 步骤五配置本地Git Sync与Harness的集成8.6 步骤六配置本地Cache Store与Harness的集成8.7 步骤七配置强制本地执行规则与数据隔离规则8.8 步骤八编写第一条本地优先的Harness CI流水线关键代码解析与深度剖析Harness LFS核心组件的实现原理9.1 Harness Local Runner ManagerLRM的核心代码解析Go语言伪代码示例9.2 Harness LFS混合调度策略的核心实现Python辅助代码示例9.3 Harness本地Git Sync的增量同步机制深度剖析9.4 Harness本地Secret Manager的加密传输与存储机制深度剖析9.5 Harness本地Cache Store的增量压缩与同步机制深度剖析第三部分验证与扩展 (Verification Extension)结果展示与验证Harness LFS混合云架构的功能与性能验证10.1 功能验证强制本地执行规则、数据隔离规则、本地Git Sync、本地Secret Manager、本地Cache Store的验证10.2 性能验证本地Runner与云Runner的执行时间对比、本地Cache与云Cache的拉取时间对比、混合调度策略的成本/风险/效率对比10.3 安全验证本地Secret的加密传输与存储验证、敏感数据的隔离验证性能优化与最佳实践让你的Harness LFS混合云架构更高效、更省钱、更安全11.1 性能优化技巧11.1.1 本地Runner池的调度策略优化11.1.2 本地Cache的增量压缩与存储优化11.1.3 本地Git Sync的增量同步与分支过滤优化11.1.4 本地LRM的资源限制与扩缩容优化11.2 成本控制方法11.2.1 按需启动本地Runner的配置11.2.2 跨区域云资源调用的限制配置11.2.3 本地硬件资源的复用策略11.3 安全合规配置11.3.1 本地Secret的加密算法选择与密钥轮换策略11.3.2 敏感数据的访问控制与审计日志配置11.3.3 本地数据的备份与恢复策略11.4 项目最佳实践Tips20条以上常见问题与解决方案Harness LFS落地过程中可能遇到的“坑”12.1 本地Agent与SaaS控制平面连接失败的常见原因与解决方案12.2 本地Runner无法获取任务的常见原因与解决方案12.3 本地Secret Manager集成失败的常见原因与解决方案12.4 本地Git Sync同步失败的常见原因与解决方案12.5 本地Cache Store拉取/上传失败的常见原因与解决方案12.6 强制本地执行规则不生效的常见原因与解决方案未来展望与扩展方向Harness LFS的下一个十年13.1 AI驱动的本地/云调度决策基于机器学习的成本-风险-效率三维动态平衡13.2 更多本地集成的支持本地硬件测试环境、本地监控告警系统、本地部署环境如Ansible Tower、OpenStack的深度集成13.3 本地控制平面的增强支持完全离线的本地控制平面部署与升级13.4 边缘计算场景的扩展支持边缘设备端的Runner部署与流水线执行13.5 跨平台的支持支持Windows、macOS、ARM架构的本地Runner部署实际场景应用Harness LFS在金融、医疗、制造、边缘计算行业的落地案例14.1 金融行业某大型银行的敏感代码本地编译与合规审计14.2 医疗行业某三甲医院的HIS系统本地部署与数据隔离14.3 制造行业某汽车制造商的工业物联网边缘设备端微服务测试与部署14.4 互联网行业某电商平台的非敏感任务弹性扩到云、敏感任务本地跑的混合云架构第四部分总结与附录 (Conclusion Appendix)总结参考资料附录17.1 附录A完整的Harness LFS安装配置脚本17.2 附录B完整的Harness LFS混合调度策略Python代码17.3 附录C完整的第一条本地优先Harness CI流水线YAML配置17.4 附录D完整的Harness LFS最佳实践Tips清单17.5 附录E完整的Harness LFS常见问题与解决方案清单第二部分核心内容 (Core Content)5. 问题背景与动机为什么我们需要CI/CD本地优先策略5.1 纯SaaS CI/CD的三大痛点在过去的十年里SaaS化CI/CD平台如Harness SaaS、GitHub Actions、GitLab SaaS、CircleCI SaaS凭借其开箱即用、无需维护基础设施、弹性扩缩容能力强等优势受到了越来越多开发者和DevOps工程师的青睐。据Gartner 2024年的最新报告显示全球有超过70%的中小企业和40%的大型企业正在使用SaaS化CI/CD平台。然而随着企业数字化转型的深入以及业务规模的不断扩大纯SaaS CI/CD平台的三大核心痛点也逐渐暴露出来成为了很多企业业务发展的“瓶颈”5.1.1 第一大痛点抗灾能力弱业务连续性风险高纯SaaS CI/CD平台的所有基础设施包括控制平面、数据平面、Runner节点、Secret Manager、Cache Store、Git仓库如果使用平台内置的Git服务都部署在公有云厂商的特定区域内。一旦该公有云区域发生断电、网络中断、自然灾害、人为攻击等不可控事件整个CI/CD系统就会完全瘫痪导致核心流水线停滞软件交付无法正常进行。我们来看一个真实的案例2023年12月AWS us-east-1区域的Lambda服务中断事件。据AWS官方统计此次中断事件持续了约4小时影响了包括GitHub Actions、GitLab SaaS、CircleCI SaaS在内的大量SaaS化CI/CD平台。很多使用这些平台的企业如Uber、Netflix、Spotify的核心流水线都停滞了数小时导致了大量的客户投诉和经济损失。再来看一个更贴近国内的案例2024年3月阿里云华北2北京区域的OSS服务中断事件。此次中断事件持续了约2小时影响了大量使用阿里云OSS作为Cache Store或Artifact Store的国内SaaS化CI/CD平台如阿里云效CodePipeline、腾讯云DevOps CI/CD。很多使用这些平台的国内互联网企业和传统企业的核心流水线都停滞了数小时导致了严重的业务影响。5.1.2 第二大痛点成本不可控月末账单爆表纯SaaS CI/CD平台的收费模式通常是按分钟计费Runner节点、按存储容量计费Secret Manager/Cache Store/Artifact Store、按带宽计费跨区域调用/传输。虽然这种收费模式看起来很“灵活”但实际上很容易导致月末账单爆表——尤其是在以下几种场景下临时扩容的云原生Runner节点费用过高在软件发布高峰期如“618”“双11”“黑五”很多企业会临时扩容大量的云原生Runner节点来应对激增的流水线任务。但是很多企业忘记了在高峰期过后及时缩容这些Runner节点导致这些节点一直处于“运行中”状态产生了大量的不必要费用。跨区域调用/传输费用过高很多企业的Git仓库、Artifact Store、部署环境部署在不同的公有云区域或不同的公有云厂商导致纯SaaS CI/CD平台需要进行大量的跨区域/跨厂商调用/传输。据AWS官方统计跨区域数据传输的费用是同一区域内数据传输费用的10-100倍——这无疑会大幅增加CI/CD的成本。敏感代码的合规云存储费过高很多金融/医疗/政府行业的企业为了满足“敏感数据不离本地机房”的合规要求被迫使用公有云厂商提供的“合规云存储服务”如AWS GovCloud、阿里云政务云。但是这些“合规云存储服务”的费用通常是普通云存储服务的3-10倍——这也会大幅增加CI/CD的成本。我们来看一个真实的成本案例某国内中型电商平台的纯SaaS CI/CD账单分析。该电商平台使用阿里云效CodePipeline作为纯SaaS CI/CD平台在2024年“618”期间的CI/CD账单如下收费项目618期间6月1日-6月20日费用非高峰期5月1日-5月20日费用增长倍数云原生Runner节点按分钟计费¥128,000¥18,0007.11跨区域数据传输Git仓库→Runner→Artifact Store→部署环境¥42,000¥3,50012.00合规云存储服务存储敏感代码的Artifact¥15,000¥5,0003.00其他费用Secret Manager、Cache Store、API调用¥5,000¥3,5001.43合计¥190,000¥30,0006.33从这个案例可以看出该电商平台在2024年“618”期间的CI/CD账单是普通高峰期的6.33倍其中云原生Runner节点和跨区域数据传输的费用占比超90%——这无疑给企业带来了巨大的成本压力。5.1.3 第三大痛点数据安全与合规风险高无法满足金融/医疗/政府行业的要求纯SaaS CI/CD平台的所有数据包括敏感代码、Secret、Artifact、流水线执行日志、审计日志都存储在公有云厂商的服务器上并且所有的流水线任务都在公有云厂商的Runner节点上执行。这就带来了以下两大数据安全与合规风险数据泄露风险高虽然公有云厂商通常会提供一些数据安全措施如数据加密、访问控制、防火墙但是近年来公有云厂商的数据泄露事件仍然屡见不鲜如2019年Capital One AWS数据泄露事件、2023年Meta Azure数据泄露事件。一旦企业的敏感数据如银行账户信息、医疗记录、用户隐私数据泄露不仅会给企业带来巨大的经济损失还会严重影响企业的声誉甚至会导致企业面临法律诉讼。无法满足金融/医疗/政府行业的合规要求很多金融/医疗/政府行业的企业都受到严格的合规监管如金融行业的PCI DSS、SOX、Basel III医疗行业的HIPAA、GDPR政府行业的等保2.0、等级保护。这些合规要求通常明确规定敏感数据必须存储在本地机房或合规的私有云/混合云环境中并且敏感代码的编译、测试、部署等任务必须在本地机房的服务器上执行。纯SaaS CI/CD平台显然无法满足这些合规要求——这也是很多金融/医疗/政府行业的企业不敢使用纯SaaS CI/CD平台的主要原因。5.2 纯本地部署CI/CD的三大短板为了解决纯SaaS CI/CD的三大痛点很多企业选择了纯本地部署CI/CD平台如Jenkins、GitLab CE/EE、Harness CI CE/EE——将所有的基础设施包括控制平面、数据平面、Runner节点、Secret Manager、Cache Store、Git仓库都部署在本地机房或企业自己的私有云环境中。纯本地部署CI/CD平台确实可以解决纯SaaS CI/CD的三大痛点——抗灾能力强因为基础设施都在自己的掌控范围内、成本可控因为不需要按分钟付费给SaaS厂商、数据安全与合规风险低因为所有数据都在本地机房。但是纯本地部署CI/CD平台也有三大核心短板这些短板同样会严重影响企业的软件交付效率和业务发展5.2.1 第一大短板维护成本高需要专业的DevOps团队纯本地部署CI/CD平台的所有基础设施都需要企业自己维护——包括服务器的采购、安装、配置、升级、监控、故障排除以及CI/CD平台本身的安装、配置、升级、插件管理、安全补丁更新。这就需要企业拥有一支专业的、经验丰富的DevOps团队——而这样的团队不仅招聘难度大而且薪资成本也很高。我们来看一个真实的维护成本案例某国内大型银行的纯本地部署Jenkins集群维护成本分析。该银行拥有一套由100台物理服务器组成的Jenkins集群负责全行1000多个微服务的CI/CD任务。该银行每年在Jenkins集群上的维护成本如下维护项目每年费用物理服务器的采购与折旧按5年折旧计算¥5,000,000物理服务器的运维电费、空调费、带宽费、机房租赁费¥2,000,000DevOps团队的薪资10名专业DevOps工程师每人每年¥500,000¥5,000,000Jenkins平台本身的维护插件管理、安全补丁更新、故障排除¥500,000其他费用培训、咨询、第三方工具¥500,000合计¥13,000,000从这个案例可以看出该银行每年在纯本地部署Jenkins集群上的维护成本高达¥13,000,000——这是一笔不小的开支。而且随着业务规模的不断扩大Jenkins集群的规模也会不断扩大维护成本也会随之不断增加。5.2.2 第二大短板弹性扩缩容能力弱无法应对软件发布高峰期的任务激增纯本地部署CI/CD平台的Runner节点通常是固定数量的物理服务器或虚拟机——企业需要提前根据业务规模的预估采购足够的服务器或虚拟机。但是软件发布的需求往往是波动的——在非高峰期可能只需要10台Runner节点就能满足需求但在“618”“双11”“黑五”等软件发布高峰期可能需要100台甚至更多的Runner节点才能满足需求。如果企业提前采购了足够的服务器或虚拟机来应对高峰期的任务激增那么在非高峰期这些服务器或虚拟机就会处于“闲置”状态产生大量的不必要费用如电费、空调费、机房租赁费如果企业没有提前采购足够的服务器或虚拟机那么在高峰期就会出现流水线任务排队等待的情况导致软件交付延迟严重影响业务发展。我们来看一个真实的弹性扩缩容案例某国内中型互联网公司的纯本地部署GitLab EE Runner集群弹性扩缩容分析。该公司拥有一套由20台虚拟机组成的GitLab EE Runner集群负责公司500多个微服务的CI/CD任务。在2024年“双11”期间该公司的微服务发布任务激增了10倍导致20台Runner节点全部满负荷运行很多流水线任务排队等待了2-3小时才开始执行导致了大量的软件交付延迟严重影响了“双11”的业务活动。为了解决这个问题该公司在“双11”过后采购了80台虚拟机将GitLab EE Runner集群的规模扩大到了100台。但是在非高峰期这100台虚拟机中只有10-20台处于“运行中”状态剩下的80-90台处于“闲置”状态产生了大量的不必要费用——据该公司统计每月在这些“闲置”虚拟机上的费用高达¥80,000。5.2.3 第三大短板功能更新慢无法及时获取最新的CI/CD技术纯本地部署CI/CD平台的功能更新通常是缓慢的——企业需要自己下载最新的安装包然后手动进行安装、配置、升级并且需要测试新功能是否与现有系统兼容。这个过程通常需要几天甚至几周的时间——而且如果企业的DevOps团队经验不足还可能会出现升级失败的情况导致整个CI/CD系统瘫痪。相比之下纯SaaS CI/CD平台的功能更新通常是即时的——SaaS厂商会自动在后台进行安装、配置、升级用户不需要做任何操作就能及时获取最新的CI/CD技术如AI驱动的流水线优化、自动生成测试用例、自动安全扫描。我们来看一个真实的功能更新案例某国内小型创业公司的纯本地部署Jenkins与纯SaaS GitHub Actions功能更新对比。该公司在2023年1月同时使用了纯本地部署Jenkins和纯SaaS GitHub Actions。在2023年1月到2024年3月期间GitHub Actions共更新了**120个新功能如AI驱动的Pipeline Assistant、自动生成安全扫描报告、支持ARM架构的Runner节点而Jenkins只更新了10个核心功能并且该公司的DevOps团队因为经验不足只成功升级了5**个核心功能——这导致该公司的纯本地部署Jenkins系统的功能远远落后于纯SaaS GitHub Actions系统严重影响了软件交付效率。5.3 混合云CI/CD的过渡性问题为了同时解决纯SaaS CI/CD的三大痛点和纯本地部署CI/CD的三大短板很多企业选择了过渡性的混合云CI/CD方案——将一部分基础设施部署在本地机房或私有云环境中另一部分基础设施部署在公有云环境中。常见的过渡性混合云CI/CD方案有以下两种方案一控制平面本地部署数据平面弹性扩到云将CI/CD平台的控制平面如Jenkins Master、GitLab CE/EE Control Plane部署在本地机房或私有云环境中将Runner节点弹性扩到公有云环境中如使用AWS EC2 Spot实例、阿里云ECS抢占式实例作为Runner节点。方案二控制平面SaaS部署数据平面部分本地部署、部分云部署将CI/CD平台的控制平面如Harness SaaS、GitHub Actions、GitLab SaaS部署在SaaS厂商的公有云环境中将一部分Runner节点、Secret Manager、Cache Store部署在本地机房或私有云环境中另一部分Runner节点、Secret Manager、Cache Store部署在公有云环境中。这两种过渡性的混合云CI/CD方案确实可以在一定程度上解决纯SaaS CI/CD的三大痛点和纯本地部署CI/CD的三大短板——但是它们也存在一些过渡性的问题这些问题会严重影响混合云CI/CD方案的效果5.3.1 方案一的过渡性问题控制平面的维护成本仍然很高方案一虽然将Runner节点弹性扩到了公有云环境中解决了弹性扩缩容能力弱的问题但是控制平面仍然部署在本地机房或私有云环境中——企业仍然需要自己维护控制平面的基础设施包括服务器的采购、安装、配置、升级、监控、故障排除以及CI/CD平台本身的控制平面的安装、配置、升级、插件管理、安全补丁更新。这就意味着控制平面的维护成本仍然很高——企业仍然需要拥有一支专业的、经验丰富的DevOps团队。5.3.2 方案二的过渡性问题缺乏统一的本地优先调度策略、数据隔离策略、缓存同步策略方案二虽然将控制平面部署在了SaaS厂商的公有云环境中解决了控制平面维护成本高和功能更新慢的问题但是大多数SaaS化CI/CD平台如GitHub Actions、GitLab SaaS都缺乏统一的本地优先调度策略、数据隔离策略、缓存同步策略——这就导致了以下几个问题无法保证敏感任务本地执行虽然可以通过标签规则将敏感任务指定到本地Runner节点上执行但是如果本地Runner节点全部满负荷运行大多数SaaS化CI/CD平台会自动将敏感任务调度到云Runner节点上执行——这就带来了数据安全与合规风险。无法保证敏感数据本地存储虽然可以将Secret Manager、Cache Store部署在本地机房或私有云环境中但是大多数SaaS化CI/CD平台的控制平面仍然会存储一些敏感数据的元数据如Secret的名称、Cache的路径——这也带来了一定的数据安全与合规风险。无法保证缓存的高效同步虽然可以将Cache Store部署在本地机房或私有云环境中但是大多数SaaS化CI/CD平台都缺乏统一的本地/云缓存同步策略——这就导致了本地Cache和云Cache之间的数据不一致或者缓存的拉取/上传效率很低。5.4 本地优先策略的诞生与价值主张正是为了解决纯SaaS CI/CD的三大痛点、纯本地部署CI/CD的三大短板以及过渡性混合云CI/CD方案的过渡性问题CI/CD领域的“本地优先策略Local First Strategy, LFS”应运而生。5.4.1 本地优先策略的定义CI/CD领域的“本地优先策略”是指一种混合云CI/CD架构设计理念——其核心思想是**“敏感任务本地跑、非敏感任务弹性扩到云、所有数据本地优先存、所有元数据安全加密同步到云控制平面”**。具体来说本地优先策略包含以下四个核心原则本地优先执行原则所有的敏感任务如敏感代码的编译、测试、部署敏感数据的处理必须强制在本地Runner节点上执行——即使本地Runner节点全部满负荷运行也不能将敏感任务调度到云Runner节点上执行只能等待本地Runner节点空闲或者手动扩容本地Runner节点。本地优先存储原则所有的敏感数据如敏感代码、Secret、Artifact、流水线执行日志、审计日志必须强制存储在本地Secret Manager、本地Cache Store、本地Artifact Store中——只有非敏感数据的元数据如非敏感Secret的名称、非敏感Cache的路径、非敏感Artifact的下载链接才能安全加密同步到云控制平面。云弹性辅助原则所有的非敏感任务如非敏感代码的编译、测试、安全扫描、文档生成可以优先在本地Runner节点上执行——如果本地Runner节点全部满负荷运行可以自动弹性扩到云Runner节点上执行如使用AWS EC2 Spot实例、阿里云ECS抢占式实例作为云Runner节点以降低成本。统一控制原则所有的本地基础设施如本地Runner Manager、本地Agent、本地Runner、本地Secret Manager、本地Cache Store、本地Artifact Store和云基础设施如云Runner Manager、云Runner、云Secret Manager、云Cache Store、云Artifact Store都由统一的云控制平面进行管理——用户只需要在云控制平面上进行一次配置就能实现本地优先执行规则、数据隔离规则、缓存同步规则的全局生效。5.4.2 本地优先策略的价值主张与纯SaaS CI/CD、纯本地部署CI/CD、过渡性混合云CI/CD方案相比本地优先策略具有以下六大核心价值主张抗灾能力强业务连续性风险低虽然控制平面部署在SaaS厂商的公有云环境中但是所有的敏感任务、敏感数据都在本地机房或私有云环境中——即使SaaS厂商的公有云区域发生不可控事件用户仍然可以使用本地控制平面如果SaaS厂商支持本地控制平面的离线部署与升级继续执行敏感任务并且可以访问所有的敏感数据——这就大大降低了业务连续性风险。成本可控月末账单不会爆表所有的敏感任务都在本地Runner节点上执行所有的敏感数据都在本地存储——这就大大减少了云原生Runner节点的使用时间和跨区域数据传输的费用同时所有的非敏感任务可以优先在本地Runner节点上执行只有在本地Runner节点全部满负荷运行时才会自动弹性扩到云Runner节点上执行并且可以使用Spot实例/抢占式实例作为云Runner节点——这就进一步降低了CI/CD的成本。数据安全与合规风险低满足金融/医疗/政府行业的要求所有的敏感任务都在本地Runner节点上执行所有的敏感数据都在本地存储——这就完全满足了金融/医疗/政府行业的“敏感数据不离本地机房”的合规要求同时所有的元数据都经过安全加密后才同步到云控制平面——这就进一步降低了数据安全与合规风险。维护成本低不需要专业的DevOps团队控制平面部署在SaaS厂商的公有云环境中——企业不需要自己维护控制平面的基础设施也不需要自己进行CI/CD平台本身的控制平面的安装、配置、升级、插件管理、安全补丁更新——这就大大降低了维护成本同时本地基础设施的管理也非常简单——只需要在云控制平面上进行一次配置就能实现本地基础设施的自动管理——这就意味着企业不需要拥有一支专业的、经验丰富的DevOps团队只需要拥有1-2名基础的DevOps工程师即可。弹性扩缩容能力强能够应对软件发布高峰期的任务激增所有的非敏感任务可以优先在本地Runner节点上执行只有在本地Runner节点全部满负荷运行时才会自动弹性扩到云Runner节点上执行——这就大大提高了弹性扩缩容能力能够轻松应对软件发布高峰期的任务激增同时云Runner节点可以使用Spot实例/抢占式实例——这就进一步降低了成本。功能更新快能够及时获取最新的CI/CD技术控制平面部署在SaaS厂商的公有云环境中——SaaS厂商会自动在后台进行安装、配置、升级用户不需要做任何操作就能及时获取最新的CI/CD技术如AI驱动的本地/云调度决策、自动生成测试用例、自动安全扫描——这就大大提高了软件交付效率。5.5 问题演变发展历史的Markdown表格为了让大家更好地理解CI/CD领域从“纯本地部署”到“纯SaaS”再到“过渡性混合云”最后到“本地优先策略”的问题演变发展历史我整理了以下Markdown表格时间阶段主流CI/CD架构解决的核心问题存在的核心问题2000年-2010年纯本地部署如CruiseControl、Jenkins早期版本自动化软件交付流程提高软件交付效率维护成本高弹性扩缩容能力弱功能更新慢2010年-2020年纯SaaS如Travis CI早期版本、CircleCI SaaS、GitHub Actions早期版本降低维护成本提高弹性扩缩容能力加快功能更新速度抗灾能力弱成本不可控数据安全与合规风险高2020年-2023年过渡性混合云如控制平面本地部署数据平面云部署、控制平面SaaS部署数据平面部分本地部署在一定程度上同时解决纯SaaS和纯本地部署的问题方案一控制平面的维护成本仍然很高方案二缺乏统一的本地优先调度策略、数据隔离策略、缓存同步策略2023年-至今本地优先策略如Harness CI 9.x的LFS同时彻底解决纯SaaS、纯本地部署、过渡性混合云的所有问题目前只有少数新一代SaaS化CI/CD平台如Harness支持完整的本地优先策略生态系统还在不断完善中6. 核心概念与理论基础什么是Harness本地优先策略6.1 核心概念定义在深入讲解Harness本地优先策略的系统架构、核心组件、交互逻辑之前我们需要先明确以下几个核心概念的定义6.1.1 核心概念1Harness控制平面Harness Control PlaneHarness控制平面是Harness平台的“大脑”——负责统一管理所有的本地基础设施和云基础设施包括流水线的定义、存储、调度、执行监控Runner池的管理、标签规则的配置、调度策略的配置Secret Manager、Cache Store、Artifact Store的集成与管理Git Sync的配置与管理用户权限的管理、审计日志的存储与分析AI驱动的流水线优化、自动生成测试用例、自动安全扫描。Harness控制平面有两种部署方式Harness SaaS控制平面由Harness公司统一部署在AWS、GCP、Azure等公有云厂商的多个区域内——用户只需要注册一个Harness账号就能直接使用不需要自己维护任何基础设施。Harness Self-Managed控制平面本地控制平面由用户自己部署在本地机房、私有云环境或公有云环境中——用户需要自己维护控制平面的基础设施以及Harness平台本身的控制平面的安装、配置、升级、安全补丁更新。Harness Self-Managed控制平面支持完全离线的部署与升级——这就意味着即使没有互联网连接用户仍然可以使用Harness Self-Managed控制平面继续执行流水线任务。在Harness本地优先策略中推荐使用Harness SaaS控制平面作为统一的控制平面——因为这样可以降低维护成本加快功能更新速度同时Harness SaaS控制平面支持与Harness Self-Managed控制平面的同步——这就意味着如果Harness SaaS控制平面发生不可控事件用户可以快速切换到Harness Self-Managed控制平面继续执行流水线任务。6.1.2 核心概念2Harness数据平面Harness Data PlaneHarness数据平面是Harness平台的“手脚”——负责具体执行流水线任务包括从Git仓库拉取代码从Secret Manager获取Secret执行流水线的Stage、Step上传/下载Artifact到Artifact Store上传/下载Cache到Cache Store生成流水线执行日志将流水线执行结果同步到控制平面。Harness数据平面也有两种部署方式Harness云数据平面由Harness公司统一部署在AWS、GCP、Azure等公有云厂商的多个区域内——用户可以直接使用不需要自己维护任何基础设施Harness云数据平面的Runner节点有三种类型Free Tier Runner节点免费使用但有使用时间限制如每月2000分钟On-Demand Runner节点按分钟付费弹性扩缩容能力强Spot/Preemptible Runner节点按分钟付费但费用比On-Demand Runner节点低70%-90%——不过这些节点可能会被公有云厂商随时回收。Harness本地数据平面由用户自己部署在本地机房、私有云环境或公有云环境中——用户需要自己维护本地数据平面的基础设施Harness本地数据平面的核心组件包括Harness Local Runner ManagerLRM本地数据平面的“大脑”——负责管理本地Runner池与控制平面进行通信接收控制平面的任务调度指令将任务分配给合适的本地Runner节点Harness Local Agent本地数据平面的“通信枢纽”——负责本地数据平面与控制平面之间的安全加密通信不需要开放本地机房的任何入站端口Harness Local Runner本地数据平面的“手脚”——负责具体执行流水线任务可以是物理服务器、虚拟机、Docker容器、K8s Pod本地Secret Manager由用户自己部署在本地机房或私有云环境中的Secret Manager如HashiCorp Vault、AWS Secrets Manager本地版、Azure Key Vault本地版——负责存储敏感Secret本地Cache Store由用户自己部署在本地机房或私有云环境中的Cache Store如MinIO、AWS S3本地版、Azure Blob Storage本地版——负责存储敏感Cache本地Artifact Store由用户自己部署在本地机房或私有云环境中的Artifact Store如Harbor、JFrog Artifactory本地版、AWS ECR本地版——负责存储敏感Artifact本地Git服务器由用户自己部署在本地机房或私有云环境中的Git服务器如GitLab CE/EE、GitHub Enterprise Server、Bitbucket Server——负责存储敏感代码。在Harness本地优先策略中必须部署Harness本地数据平面——因为只有这样才能实现“敏感任务本地跑、所有数据本地优先存”的核心原则。6.1.3 核心概念3Harness本地优先执行规则Harness Local First Execution RuleHarness本地优先执行规则是Harness本地优先策略的核心规则之一——负责定义哪些任务必须强制在本地Runner节点上执行哪些任务可以优先在本地Runner节点上执行哪些任务必须强制在云Runner节点上执行。Harness本地优先执行规则可以基于以下多个维度进行定义流水线维度定义整个流水线必须强制在本地Runner节点上执行Stage维度定义某个Stage必须强制在本地Runner节点上执行Step维度定义某个Step必须强制在本地Runner节点上执行代码仓库维度定义某个代码仓库的所有任务必须强制在本地Runner节点上执行分支维度定义某个代码仓库的某个分支的所有任务必须强制在本地Runner节点上执行标签维度定义带有某个标签的所有任务必须强制在本地Runner节点上执行时间维度定义某个时间段内的所有任务必须强制在本地Runner节点上执行用户维度定义某个用户或某个用户组触发的所有任务必须强制在本地Runner节点上执行。Harness本地优先执行规则的优先级顺序如下从高到低Step维度的规则Stage维度的规则流水线维度的规则分支维度的规则代码仓库维度的规则标签维度的规则时间维度的规则用户维度的规则。6.1.4 核心概念4Harness数据隔离规则Harness Data Isolation RuleHarness数据隔离规则是Harness本地优先策略的核心规则之一——负责定义哪些数据必须强制存储在本地Secret Manager、本地Cache Store、本地Artifact Store中哪些数据可以存储在云Secret Manager、云Cache Store、云Artifact Store中。Harness数据隔离规则可以基于以下多个维度进行定义Secret维度定义某个Secret必须强制存储在本地Secret Manager中Cache维度定义某个Cache必须强制存储在本地Cache Store中Artifact维度定义某个Artifact必须强制存储在本地Artifact Store中流水线维度定义某个流水线的所有Secret、Cache、Artifact必须强制存储在本地Stage维度定义某个Stage的所有Secret、Cache、Artifact必须强制存储在本地Step维度定义某个Step的所有Secret、Cache、Artifact必须强制存储在本地代码仓库维度定义某个代码仓库的所有Secret、Cache、Artifact必须强制存储在本地分支维度定义某个代码仓库的某个分支的所有Secret、Cache、Artifact必须强制存储在本地标签维度定义带有某个标签的所有Secret、Cache、Artifact必须强制存储在本地**