从 0 到企业级私有云 ｜ CI/CD + GitOps 全链路实战（Jenkins + ArgoCD）从代码提交到自动上线，完整打通企业级交付链路

本文共 2000+ 字，阅读约需要 10 分钟。

本文基于之前完整实战环境，构建 Jenkins + Harbor + ArgoCD + Gitea 的 CI/CD + GitOps 自动化交付体系。从代码提交到应用上线，全流程自动化，并深入理解其背后的企业级架构设计思想。

🎯 本文目标

构建一套企业级标准交付链路：

代码提交 → 自动构建 → 自动发布 → 自动部署 → 自动修复

并解决核心问题：

👉 如何让“部署”变成一件可控的事情？

二、整体架构设计

2.1 架构总览

开发者 → Gitea（源码仓库） → Jenkins（CI）
                 ↓
          Harbor（镜像仓库）
                 ↓
       GitOps Repo（部署声明）
                 ↓
             ArgoCD（CD）
                 ↓
          Kubernetes（运行环境）

2.2 架构分层

这套系统不是“工具堆叠”，而是分层设计：

🔹 1. 开发层

• 开发者编写代码
• 提交 Git

git push

🔹 2. CI 层（持续集成）

核心组件：Jenkins + Kaniko

职责：

• 拉取代码
• 构建镜像
• 推送 Harbor

👉 输出结果：

Docker Image（唯一交付物）

🔹 3. GitOps 控制层（核心）

核心组件：GitOps Repo（Gitea）

职责：

记录“期望状态”

例如：

image: my-app:v1.0.15

👉 这是整个系统的：

唯一事实源（Single Source of Truth）

🔹 4. CD 层（持续部署）

核心组件：ArgoCD

职责：

• 监听 Git
• 对比状态（Diff）
• 自动同步（Sync）

🔹 5. 运行时层

核心组件：Kubernetes

职责：

• 拉取镜像
• 滚动更新
• 维持副本数

🔥 架构核心原则

CI 负责生成变更
Git 负责声明变更
CD 负责执行变更
Kubernetes 负责运行变更

三、完整流程拆解

🧭 Step 1：开发者提交代码

git push

🧭 Step 2：Jenkins 自动触发构建

触发方式：

• Webhook（推荐）
• 或轮询

Jenkins 做的事情：

✅ 2.1 拉取代码

Gitea → Jenkins

✅ 2.2 构建镜像（Kaniko）

源码 → Docker Image

👉 使用 Kaniko，避免 Docker 权限问题

✅ 2.3 推送镜像

my-app:v1 → my-app:v2

🧭 Step 3：更新 GitOps 仓库（关键步骤）

Jenkins 不会部署应用，只做一件事：

👉 修改 YAML：

image: my-app:v1
→
image: my-app:v2

然后：

git commit
git push

👉 GitOps 仓库变更记录

🧭 Step 4：ArgoCD 检测变化

ArgoCD 持续执行：

Git（期望状态） vs 集群（当前状态）

发现：

版本不一致

👉 ArgoCD Diff 页面

🧭 Step 5：自动同步（Sync）

ArgoCD 自动执行：

kubectl apply（内部执行）

触发：

• Deployment 更新
• Pod 重建

🧭 Step 6：Kubernetes 滚动更新

kubectl get pods -w

观察：

• 新 Pod 启动
• 旧 Pod 终止

🧭 Step 7：用户访问新版本

NodePort / Ingress → Service → Pod

四、Jenkins + kubectl vs. GitOps (ArgoCD)

两种方案各有适用场景，不能简单说谁对谁错。下面从实际工程角度对比两种模式。

4.1 方案对比：Jenkins + kubectl vs. GitOps (ArgoCD)

4.2 为什么小型团队偏爱 Jenkins + kubectl？

• 流程短、反馈快：代码推送 → Jenkins 构建 → 立即 apply，几分钟内看到结果。
• 负担低：不需要额外学习 ArgoCD 的 Application、Project 等概念。
• 灵活度高：可以在 Jenkinsfile 中随时加入任意 Shell 脚本，应对临时需求。

但它也有明显的隐患：

• 某次手动 kubectl edit修改了副本数，下次部署时可能被覆盖，也可能残留，状态不可预测。
• 回滚需要找到上一次的镜像标签或 YAML 文件，紧急情况下容易出错。
• 审计时需要同时查看 Jenkins 日志和 Git 提交，信息割裂。

4.3 为什么生产环境更推荐 GitOps？

• Git 是唯一事实来源：集群状态永远等于 Git 仓库中的声明，杜绝手动修改带来的“幽灵配置”。
• 可审计、可回滚：每次变更都有 Git commit，回滚就是一次 git revert，符合软件工程最佳实践。
• 自动自愈：即使有人误操作删除了 Pod，ArgoCD 也会自动修复，减少凌晨告警。
• 状态可视化：ArgoCD UI 提供实时的 Diff 视图、同步状态、健康状态，运维体验大幅提升。

但它也有代价：

• 引入 ArgoCD 组件增加了系统复杂度，需要额外维护。
• 部署延迟比直接 kubectl稍高（可通过 Webhook 优化）。
• 团队需要适应“修改 Git 触发部署”的新习惯。

4.4 🔥 核心结论：不是替代，而是演进

CI/CD 只是执行工具
是否可控，取决于状态管理方式

• Jenkins + kubectl是 CI/CD 的“手动挡”，适合起步阶段，让团队快速跑通流程。
• GitOps + ArgoCD是“自动巡航”，适合规模化、生产化阶段，让系统更稳定可控。

两种模式并非互斥，部分团队采用混合模式：日常开发环境用 Jenkins 直接部署以追求速度，生产环境走 GitOps 以保证安全合规。

最终的选择取决于团队规模、业务要求和对稳定性的权衡。本文采用 GitOps 方案，是为了演示从“能用”到“可控”的进阶路径，帮助读者理解声明式运维的核心价值。

五、核心收获

✅ 1. CI 与 CD 解耦

• Jenkins 只负责构建
• ArgoCD 负责部署

✅ 2. Git 成为系统核心

• 所有状态来自 Git
• 所有变更可追溯

✅ 3. GitOps 带来的能力

• 自动部署
• 自动回滚
• 自动修复

✅ 4. Kaniko 是最佳实践

• 无需特权
• 更安全

七、后续进阶方向

🚀 灰度发布

• Argo Rollouts

🚀 多环境

dev / test / prod

🚀 安全

• Secrets
• RBAC

🚀 可观测性

• Prometheus
• Grafana
• Loki / ELK

八、总结

这套系统真正解决的不是“部署自动化”，而是：

让部署变得可控

从：

“我执行了部署”

到：

“系统根据 Git 自动完成部署”