企业官网建设流程全解析

1. 从“概念”到“实践”：为什么Harness Engineering值得你投入

如果你在软件开发或运维领域摸爬滚打了一段时间，大概率已经对“DevOps”、“CI/CD”、“平台工程”这些词听得耳朵起茧了。工具链越来越长，配置越来越复杂，一个看似简单的部署流程，背后可能是Jenkins、Ansible、Terraform、Kubernetes YAML、监控告警脚本等一系列组件的“缝合”。团队新人上手需要数周，老手维护也常常疲于奔命，更别提跨团队、跨项目的标准化和最佳实践推广了。这正是Harness Engineering要解决的核心痛点：它不是一个单一的工具，而是一种通过平台化、智能化手段，将软件交付的复杂性和不确定性“驾驭”（Harness）起来的工程实践与平台能力。

简单来说，Harness Engineering的目标是让软件交付——从代码提交到生产环境上线——变得像按一个按钮那么简单、可靠且可观测。它通过一个统一的平台，将CI、CD、功能管理、云成本优化、混沌工程、安全扫描等能力整合在一起，并用大量的自动化、机器学习模型来替代人工决策和繁琐配置。比如，自动判断部署是否成功、自动回滚、自动验证云资源配置成本是否最优。这听起来有点像“银弹”，但在实际接触和初步实践后，我发现它的价值并非空谈，尤其对于正在经历快速扩张、寻求交付效率与稳定性双重提升的团队而言，它提供了一套非常落地的思路和工具集。

那么，谁适合开始第一个Harness Engineering实践？我认为主要有三类角色：一是正在为CI/CD流程碎片化、维护成本高而头疼的DevOps工程师或平台团队；二是希望提升部署频率、减少变更失败率的研发团队负责人；三是任何对现代化软件交付体系感兴趣，想了解如何通过平台能力赋能研发效能的工程师。即使你只是好奇，跟着本文的步骤走一遍，也能对“平台工程”和“智能软件交付”有一个非常具体和感性的认识。我们不会停留在概念层面，而是直接动手，用一个最经典的场景——将一个简单的Web应用部署到Kubernetes集群，来开启你的第一次Harness实践。

2. 实践前的核心认知：Harness平台的核心组件与逻辑

在直接动手之前，有必要快速梳理一下Harness平台的核心组件及其扮演的角色。这能帮助你在后续配置时，清楚地知道自己每一步在做什么，而不是机械地复制粘贴。Harness将软件交付生命周期分解为若干个模块，每个模块解决一个特定领域的问题，并且它们之间可以无缝协作。

2.1 核心模块一览

• Harness CI (Continuous Integration):负责代码的构建、测试和打包。它与其他CI工具（如Jenkins、GitLab CI）的关键区别在于深度集成和“智能化”。例如，它可以利用“测试智能”功能，基于代码变更分析，只运行受影响的测试用例，大幅缩短CI流水线执行时间。
• Harness CD (Continuous Delivery):这是Harness的招牌能力，负责将构建好的制品安全、可靠地部署到各种环境（如Kubernetes、ECS、服务器等）。其核心在于采用了声明式的执行模型和强大的审批与验证机制。你定义“最终状态”（如K8s Deployment的YAML），Harness CD负责计算出如何安全地达到该状态，并在过程中自动进行健康检查。
• Harness Feature Flags (FF):功能管理模块。允许你在不重新部署代码的情况下，动态开启或关闭功能特性。这对于灰度发布、A/B测试、快速关闭问题功能至关重要。它与CD模块紧密集成，可以在部署的同时管理功能开关。
• Harness Cloud Cost Management (CCM):云成本管理。通过自动发现云资源、分析使用情况、提供优化建议（如调整实例大小、识别闲置资源），帮助团队优化云上开支。在部署流程中，它可以作为一个验证步骤，确保新的部署不会导致成本异常飙升。
• Harness Security Testing Orchestration (STO):安全测试编排。集成各种安全扫描工具（如SonarQube, Snyk, Checkmarx），在CI/CD流程中自动执行安全测试，并将结果反馈到流水线中，实现安全左移。
• Harness Chaos Engineering (CE):混沌工程。主动在环境中注入故障（如杀死Pod、模拟网络延迟），以验证系统的韧性，确保部署的稳定性。

对于我们的第一个实践，我们将聚焦在最核心的CI和CD模块上，完成从代码到部署的完整闭环。理解它们之间的数据流至关重要：CI模块产出制品（如Docker镜像），CD模块消费这些制品并将其部署到目标环境。

2.2 关键概念：连接器、流水线、阶段与步骤

Harness通过一系列抽象概念来组织你的交付流程，理解它们的关系是成功配置的基础：

1. 连接器 (Connector):这是Harness与外部系统通信的桥梁。例如，连接你的Git仓库（GitHub, GitLab, Bitbucket）、容器镜像仓库（Docker Hub, ECR, GCR）、云提供商（AWS, GCP, Azure）或Kubernetes集群。几乎所有操作都始于创建一个正确的连接器。
2. 流水线 (Pipeline):一个完整的交付流程，由多个阶段组成。例如，一个典型的流水线可能包含“构建”、“部署到预发”、“人工审批”、“部署到生产”等阶段。
3. 阶段 (Stage):流水线中的一个逻辑分组，代表一个大的交付目标，如“CI阶段”或“CD阶段”。一个阶段内包含具体的执行步骤。
4. 步骤 (Step):最基础的操作单元。Harness提供了丰富的内置步骤，如“运行Shell命令”、“构建Docker镜像”、“部署Kubernetes负载”、“发送HTTP请求”等。你也可以创建自定义步骤。

我们的实践路径将严格按照“配置连接器 -> 创建CI阶段构建镜像 -> 创建CD阶段部署应用”的顺序进行。这个过程中，我会穿插我初次实践时遇到的“坑”和总结的经验，让你少走弯路。

3. 环境准备与初始配置：打下稳固的地基

任何实践都需要一个起点。对于Harness，你可以选择其SaaS平台（Harness.io）或自托管版本。对于个人学习和第一个实践，强烈建议使用SaaS免费版，它提供了足够的功能和资源，无需操心基础设施维护。访问Harness.io注册账号即可开始。

3.1 创建第一个项目与配置核心连接器

登录后，首先需要创建一个项目。项目是组织流水线、连接器、环境等资源的顶层容器。你可以创建一个名为“First-Harness-Practice”的项目。

接下来，配置三个最关键的连接器，这相当于给Harness配上了“手”和“脚”：

1. Git连接器：连接你的代码仓库。假设我们使用GitHub，仓库里有一个简单的Node.js应用（例如一个Express.js写的“Hello World”服务）。在连接器配置中，选择GitHub，推荐使用Personal Access Token (PAT)进行认证，因为它比SSH密钥更易于管理，且权限可控。创建PAT时，至少需要授予repo权限。

   注意：Harness在测试连接时，可能会因为网络问题超时。如果遇到，请确认你的PAT权限足够，并且Harness的SaaS服务能访问你的GitHub仓库（对于公开库通常没问题，私有库需确保网络连通性）。

2. Docker Registry连接器：连接你的镜像仓库，用于推送CI构建出的镜像。这里我们使用Docker Hub作为示例。认证方式选择“用户名/密码”，填入你的Docker Hub账号信息。

   经验之谈：对于生产环境，强烈建议使用私有仓库（如AWS ECR、Google GCR、Harbor）并配置基于角色的访问控制。Docker Hub的拉取速率限制在CI/CD高频使用时可能会成为瓶颈。

3. Kubernetes集群连接器：连接你的目标部署环境。Harness支持多种方式，对于新手，最推荐使用主账号令牌方式。你需要在目标K8s集群上创建一个ServiceAccount并授予足够的权限（如cluster-admin），然后获取其对应的Token和K8s API Server地址。

   • 在本地或云上准备一个K8s集群（Minikube, Kind, 或云厂商的托管K8s如EKS, GKE）。
   • 执行以下命令创建ServiceAccount和ClusterRoleBinding：

     kubectl create serviceaccount harness-deployer -n default kubectl create clusterrolebinding harness-deployer-admin --clusterrole=cluster-admin --serviceaccount=default:harness-deployer

   • 获取Token和Server地址：

     # 获取Token kubectl get secret $(kubectl get serviceaccount harness-deployer -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode # 获取Server地址（如果是Minikube，通常是 https://192.168.49.2:8443） kubectl cluster-info

   • 在Harness中创建K8s连接器，选择“主账号令牌”，填入上述信息。

3.2 理解Harness的配置即代码：Git体验

Harness的一个强大特性是，几乎所有配置（流水线、连接器、秘密等）都可以保存为YAML文件，并存储在你的Git仓库中。这意味着你的交付流程可以和应用程序代码一样进行版本控制、代码审查和协作。在项目设置中，启用“Git体验”，并将你的项目与一个Git仓库分支关联起来。此后，你对流水线的任何修改，都会生成一个提交，需要合并到关联分支后才会生效。这带来了审计追踪和变更安全性的巨大好处。对于第一个实践，你可以先跳过这一步，在Harness UI中直接配置，以快速获得反馈。但在后续正式使用时，强烈建议启用Git体验。

4. 构建你的第一条CI流水线：从代码到镜像

有了连接器，我们就可以开始构建CI流水线了。我们的目标是：当代码推送到GitHub仓库的main分支时，自动构建一个Docker镜像并推送到Docker Hub。

4.1 创建流水线与CI阶段

在项目中，点击“创建流水线”，给它起个名字，比如“nodejs-app-ci-cd”。Harness会引导你创建第一个阶段。选择“构建”作为阶段类型，这实际上就是CI阶段。

在CI阶段的配置中，你需要定义“执行”：即这个阶段在哪里运行你的构建任务。Harness提供了托管构建基础设施（称为“构建农场”）和自托管构建机两种选择。对于免费版和个人实践，直接使用Harness托管的“云构建农场”是最简单的，它提供了包含常用构建工具（Docker, Node, Maven等）的虚拟机环境。

4.2 配置“克隆代码”与“构建并推送Docker镜像”步骤

CI阶段内部由一系列步骤组成。Harness提供了可视化编辑器，你只需拖拽或添加步骤即可。

1. “克隆代码”步骤：这是一个内置步骤。你需要指定之前创建的Git连接器，以及仓库地址、分支（如main）、克隆目录等。这一步会将你的应用代码拉取到构建环境中。

2. “构建并推送Docker镜像”步骤：这是CI的核心。在这个步骤的配置中，你需要：

   • 连接器：选择之前创建的Docker Registry连接器。
   • 仓库：填写完整的镜像仓库路径，例如yourdockerhubusername/my-nodejs-app。
   • 标签：定义镜像标签。这里有一个非常实用的技巧：使用Harness的表达式。例如，你可以使用<+pipeline.sequenceId>作为标签的一部分，这是一个每次流水线运行都会自动递增的唯一数字，非常适合追踪构建。也可以使用Git提交SHA的前几位：<+codebase.commitSha>.substring(0,7)。这样，每个镜像都有唯一且可追溯的标签。
   • Dockerfile：指定Dockerfile的路径，通常是代码根目录下的Dockerfile。

4.3 编写Dockerfile与测试运行

确保你的代码仓库根目录有一个简单的Dockerfile，例如：

FROM node:18-alpine WORKDIR /usr/src/app COPY package*.json ./ RUN npm ci --only=production COPY . . EXPOSE 3000 CMD ["node", "app.js"]

同时，确保有app.js和一个package.json文件。

配置完成后，点击“运行”来执行流水线。你会在日志中看到Harness自动启动一个构建环境，拉取代码，执行docker build和docker push。如果一切顺利，你的镜像就会被推送到Docker Hub。

踩坑记录：我第一次实践时，在“构建并推送”步骤中直接写了固定的镜像标签如v1.0，导致多次运行后，Docker Hub上始终是同一个标签，无法区分每次构建。后来才学会使用表达式动态生成标签，这是生产级CI/CD的基本要求。另一个常见问题是构建环境中的Docker守护进程版本与本地不同，导致某些Dockerfile指令（如--platform）可能不兼容，需要注意。

5. 创建CD流水线：将镜像部署到Kubernetes

CI流水线成功产出制品（Docker镜像）后，下一步就是通过CD流水线将其部署出去。在Harness中，CI和CD可以是同一个流水线中的两个阶段，也可以是独立的流水线并通过触发器关联。为了清晰，我们在同一个流水线中新增一个CD阶段。

5.1 添加CD阶段与配置服务

在刚才的CI流水线后面，点击“添加阶段”，选择“部署”作为类型。这会创建一个CD阶段。

CD阶段的核心配置围绕两个概念：服务和环境。

• 服务 (Service):定义你要部署什么。对于K8s，就是你的工作负载定义（Deployment, Service, ConfigMap等）。Harness允许你直接引用Git仓库中的K8s manifest文件，或者使用“Harness服务”通过UI动态生成。
• 环境 (Environment):定义你要部署到哪里。它关联了之前创建的K8s集群连接器，并可以定义环境特定的配置变量和密钥。

我们先配置服务。选择“Kubernetes”作为部署类型。在“服务定义”中，选择“从Git仓库引用”。这里再次使用你的Git连接器，并指定存储K8s manifest文件的路径（例如k8s/manifests/）。这意味着你的应用部署定义也和代码一起进行版本控制。

在你的代码仓库中创建k8s/manifests/deployment.yaml文件，内容如下：

apiVersion: apps/v1 kind: Deployment metadata: name: my-nodejs-app spec: replicas: 2 selector: matchLabels: app: my-nodejs-app template: metadata: labels: app: my-nodejs-app spec: containers: - name: app image: <+artifact.image> # 关键：这是一个Harness表达式，将被CI产出的实际镜像替换 ports: - containerPort: 3000 resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"

注意image字段的值<+artifact.image>。这是一个Harness表达式，它会在运行时被替换为CI阶段实际构建并推送的镜像全名（包括标签）。这是连接CI和CD阶段的关键。

5.2 配置环境与执行策略

接下来配置环境。创建一个新环境，命名为“dev”，并选择之前创建的K8s集群连接器。环境创建后，你可以在其中定义配置变量，比如环境名称、API端点等，这些变量可以在manifest中引用。

现在，回到CD阶段的“执行”配置。这里你需要定义执行策略，即Harness如何应用你的K8s manifest。Harness CD提供了多种策略，最常用的是：

• 滚动更新 (Rolling):默认策略。逐步用新Pod替换旧Pod，确保服务不中断。
• 蓝绿部署 (Blue Green):同时部署一套新版本（绿），测试通过后，将流量从旧版本（蓝）切换到绿。
• 金丝雀部署 (Canary):将一小部分流量导入新版本，验证通过后再逐步扩大比例。

对于我们的第一个实践，选择“滚动更新”即可。Harness的强大之处在于，它会自动计算部署差异，并按照Kubernetes的最佳实践来执行更新，你无需手动编写kubectl apply或处理复杂的就绪探针逻辑。

5.3 配置制品来源与触发条件

最后，我们需要告诉CD阶段去哪里获取制品（即Docker镜像）。在CD阶段的“服务”配置中，找到“制品”部分，添加一个制品源，类型选择“Docker Registry”，并关联你之前创建的Docker Registry连接器。在“镜像路径”中，填写yourdockerhubusername/my-nodejs-app。这里不需要指定标签，因为标签会通过前面提到的<+artifact.image>表达式动态传递。

为了让整个流程自动化，我们可以配置触发器。在流水线设置中，添加一个“GitHub推送”触发器。配置为监听main分支的推送事件。这样，每次你向main分支提交代码，整个CI/CD流水线就会自动启动。

6. 运行、验证与排错：完成首次部署闭环

配置完成后，手动运行一次流水线，或者向GitHub仓库推送一次代码变更，来触发自动化流程。

6.1 观察流水线执行

在Harness的流水线执行视图中，你可以清晰地看到每个阶段的进行状态。CI阶段会显示构建日志，CD阶段则会展示详细的部署过程。Harness CD的界面非常直观，它会将部署分解为多个步骤：初始化、获取制品、准备清单、应用清单、等待稳态、健康检查等。你可以看到它创建了新的ReplicaSet，并逐步缩放旧的Pod。

6.2 验证部署结果

部署成功后，你需要验证应用是否真的在K8s集群中运行。你可以通过Harness界面直接查看部署的Pod状态，也可以使用kubectl命令：

kubectl get pods -l app=my-nodejs-app kubectl get svc # 如果你还创建了Service，可以获取ClusterIP或NodePort进行访问

为了从外部访问，你需要在K8s中创建一个Service（NodePort或LoadBalancer类型），并将对应的manifest文件也加入Git仓库。然后，通过访问对应的IP和端口，应该能看到你的“Hello World”应用。

6.3 常见问题与排错思路

第一次实践很少能一帆风顺。以下是我遇到或常见的一些问题及排查方向：

1. CI阶段失败：构建超时或网络错误。

   • 检查点：确认Harness构建农场的网络可以访问你的Git仓库和Docker Registry。对于Docker Hub，偶尔会有连接问题，可以尝试在步骤中增加超时时间，或考虑使用镜像加速器。

2. CD阶段失败：镜像拉取错误。

   • 检查点：这是最常见的问题。首先确认<+artifact.image>表达式解析出的完整镜像路径和标签是否正确（可以在执行详情中看到）。其次，确认你的K8s集群节点有权限从Docker Hub拉取镜像（如果是私有仓库，需要在K8s中创建imagePullSecrets，并在Harness的服务定义中配置）。

3. CD阶段失败：权限不足。

   • 检查点：检查Harness使用的K8s ServiceAccount（我们之前创建的harness-deployer）是否拥有在目标命名空间创建Deployment、Service等资源的权限。我们的配置使用了cluster-admin，权限足够，但在生产环境中应遵循最小权限原则。

4. 部署成功但应用无法访问。

   • 检查点：检查Pod日志 (kubectl logs <pod-name>)，看应用是否正常启动。检查Service的Selector是否与Pod的Label匹配。检查网络策略是否阻止了流量。

Harness的一个优点是它的详细日志和可视化状态。当部署失败时，它通常会给出明确的错误信息，并指向具体的步骤或资源。学会阅读这些日志是排错的关键。

7. 超越基础：探索Harness Engineering的进阶价值

成功完成一次基础的CI/CD部署，只是Harness Engineering能力的冰山一角。它的真正威力在于解决那些在规模化、复杂化交付过程中才会凸显的痛点。当你熟悉了基础操作后，可以从以下几个方向深化实践，体会其“智能”与“平台”特性。

7.1 部署验证与自动回滚：让稳定性成为默认选项

传统的部署脚本或工具，在应用更新后，往往需要人工去检查日志、监控图表来判断是否成功。Harness CD内置了部署验证功能。你可以在CD阶段中添加“验证”步骤，例如：

• Harness内置健康检查：自动监控K8s Deployment的Pod状态、就绪探针。
• Prometheus验证：连接到你的Prometheus，编写查询来验证关键指标（如错误率、延迟）在部署后是否保持在正常阈值内。
• 自定义Shell脚本验证：运行一个脚本，从内部或外部调用应用的健康检查端点。

如果验证失败，Harness可以自动触发回滚，将应用恢复到上一个稳定版本。你只需要在“故障策略”中配置“在验证失败时回滚”。这大大减少了因糟糕部署导致的线上事故影响时长和运维人员的心理负担。

7.2 使用功能开关实现无损发布与渐进式交付

将新功能部署到生产环境，并不意味着要立即对所有用户开放。通过集成Harness Feature Flags，你可以实现更精细的发布控制。

1. 在代码中，使用Harness FF SDK包裹新功能代码块。
2. 在CD流水线中，部署包含新功能的代码版本，但功能开关默认关闭。
3. 部署完成后，在Harness FF控制台，逐步将开关开放给内部员工、小部分用户，最后全量用户。
4. 如果在灰度过程中发现问题，只需在控制台关闭开关，即可瞬间“熄灭”问题功能，无需回滚整个版本或紧急发布热修复。

这实现了发布与发布的解耦，极大地降低了发布风险，并赋能了A/B测试等数据驱动决策。

7.3 成本感知部署与优化建议

在CD阶段集成Harness Cloud Cost Management (CCM)，可以在部署前后进行成本检查。例如，你可以设置一个策略：如果本次部署预计会导致月度成本增长超过10%，则流水线暂停，需要人工审批。或者，CCM可以分析你当前的K8s资源请求和限制，给出优化建议（如“你的Pod内存请求设置过高，可下调至XX MiB”），并将这些建议直接反馈到部署流程中，实现成本控制的左移。

7.4 安全扫描集成（STO）

在CI阶段中，插入一个“安全测试”步骤，配置Harness STO来调用Snyk或Trivy等工具，对代码依赖和构建出的Docker镜像进行漏洞扫描。如果发现高危漏洞，可以配置策略让流水线失败，阻止带有已知安全漏洞的镜像被部署到环境中。

从第一个简单的部署实践出发，逐步将这些能力集成到你的交付流中，你会真切感受到Harness Engineering所倡导的“软件交付平台”如何将分散的、手动的、易错的流程，整合成一个连贯的、自动化的、智能的、安全可靠的“流水线”。它不是一个替代你现有知识的工具，而是一个将你的知识和最佳实践固化、放大并降低执行成本的平台。开始你的第一个实践，就是迈出了驾驭软件交付复杂性的第一步。