Linux运维：Jenkins+Argocd

Jenkins + ArgoCD 完整配合流程（GitOps 标准架构）

这是当前云原生最主流的 CI/CD 架构 ，也是面试必考点。核心逻辑是：Jenkins 负责 CI（构建打包），ArgoCD 负责 CD（部署同步），两者通过 Git 仓库解耦，实现真正的 GitOps。

一、核心分工（一句话讲清楚）

Jenkins ：只做代码提交→编译→测试→构建镜像→推送镜像这部分（纯CI）
ArgoCD ：只做Git仓库配置→同步到K8s集群这部分（纯CD）
中间桥梁：Git 仓库（专门存放 K8s 部署配置文件，如 Deployment、Service 等）

和纯 Jenkins 部署的本质区别：

纯 Jenkins：Jenkins 直接调用 kubectl apply 部署到集群
Jenkins+ArgoCD：Jenkins 只更新 Git 仓库里的镜像标签，ArgoCD 自动把 Git 状态同步到集群

二、完整部署流程（面试必背）

复制代码

开发者提交代码 → Git代码仓库 → Jenkins自动触发 → 拉取代码 → 编译打包 → 构建镜像 → 推送镜像仓库 → Jenkins更新Git配置仓库的镜像标签 → ArgoCD检测到Git变化 → 自动同步到K8s集群 → 验证部署状态 → 通知结果

三、详细步骤（实战+面试通用）

前置准备（一次性配置）

两个 Git 仓库 ：
- 代码仓库：存放业务代码（如 Spring Boot、前端代码）
- 配置仓库：专门存放 K8s 部署文件（deployment.yaml、service.yaml 等）
ArgoCD 部署：在 K8s 集群中安装 ArgoCD，创建应用并关联配置仓库
Jenkins 配置：安装 Git、Docker、Pipeline 插件，配置代码仓库、镜像仓库、配置仓库的凭证

步骤1：Jenkins 执行 CI 流程

和之前纯 Jenkins 流程完全一样，直到推送镜像完成：

开发者提交代码到代码仓库
Git 通过 Webhook 触发 Jenkins 构建
Jenkins 拉取代码、编译打包、运行单元测试
构建 Docker 镜像，打上版本号（如 v1.0.0-${BUILD_NUMBER}）
推送镜像到 Harbor/Docker Hub 镜像仓库

步骤2：Jenkins 更新 Git 配置仓库（关键桥梁）

这是和纯 Jenkins 部署唯一不同的地方 ：

Jenkins 不直接部署到集群，而是修改配置仓库中 deployment.yaml 里的镜像标签，然后提交推送到 Git。

示例 Pipeline 代码（更新镜像标签）

groovy 复制代码

stage('更新Git配置仓库') {
    steps {
        // 克隆配置仓库
        git url: 'https://git.example.com/demo/k8s-config.git', branch: 'main', credentialsId: 'git-config-credential'
        
        // 替换deployment.yaml中的镜像标签
        sh """
            sed -i "s|image: harbor.example.com/demo/spring-boot-demo:.*|image: harbor.example.com/demo/spring-boot-demo:${IMAGE_TAG}|g" deployment.yaml
        """
        
        // 提交并推送修改
        sh """
            git config user.name "jenkins"
            git config user.email "jenkins@example.com"
            git add deployment.yaml
            git commit -m "Update image to ${IMAGE_TAG}"
            git push origin main
        """
    }
}

步骤3：ArgoCD 自动同步部署

ArgoCD 会每隔3分钟（可配置）轮询 Git 配置仓库，一旦发现配置文件有变化，就会自动将最新的配置同步到 K8s 集群。

ArgoCD 工作原理：

持续对比 Git 仓库中的期望状态 和 K8s 集群中的实际状态
如果不一致，自动执行 kubectl apply 将集群状态同步为 Git 状态
支持自动同步、手动同步、回滚到任意 Git 提交版本

步骤4：验证与通知

ArgoCD 同步完成后，Jenkins 可以调用 ArgoCD API 验证部署状态
通过钉钉/企业微信通知团队部署结果
运行自动化测试验证服务可用性

四、为什么要这么配合？（面试必问优势）

配置可追溯：所有部署变更都记录在 Git 中，谁改了、改了什么、什么时候改的一目了然
回滚极其简单 ：出问题直接回滚到 Git 上的任意一个提交版本，比 kubectl rollout undo 更可靠
权限分离：Jenkins 不需要 K8s 集群的操作权限，只需要 Git 仓库权限，安全性更高
集群状态一致：ArgoCD 会持续保证集群状态和 Git 一致，防止有人手动修改集群配置导致不一致
多环境管理方便：不同环境（dev/test/prod）对应 Git 不同分支，ArgoCD 分别同步

五、面试标准答案

Jenkins 和 ArgoCD 是 CI 和 CD 的最佳组合，采用 GitOps 架构：

Jenkins 负责持续集成，当开发者提交代码后，自动完成代码拉取、编译打包、测试、构建镜像并推送到镜像仓库，然后更新 Git 配置仓库中的镜像标签。

ArgoCD 负责持续部署，它会持续监控 Git 配置仓库的变化，一旦发现配置更新，就自动将最新的部署配置同步到 K8s 集群，保证集群状态和 Git 仓库中的期望状态一致。

这种架构实现了 CI 和 CD 的解耦，具有配置可追溯、回滚方便、安全性高、多环境管理简单等优势，是当前云原生环境下的标准 CI/CD 方案。

一、核心澄清

这两个都是Git代码仓库，不是部署在Jenkins或K8s机器上，而是统一托管在Git服务器（GitLab/GitHub/Gitee）上，Jenkins和ArgoCD都是从这个Git服务器拉取代码和配置。

二、生产环境标准：必须分开成两个独立仓库

这是GitOps架构的核心最佳实践，也是面试必答点：

权限严格分离
- 开发人员只能提交代码到代码仓库，没有配置仓库的修改权限
- 只有DevOps/运维人员才能修改配置仓库，防止开发人员随意改动生产环境的部署参数
变更完全隔离
- 代码提交只会触发CI构建，不会影响集群部署
- 配置变更（如调整副本数、修改环境变量）只会触发ArgoCD同步，不会重新编译打包
多环境管理清晰
- 配置仓库用不同分支/目录对应不同环境（dev/test/prod）
- 代码仓库用feature分支开发，合并到main分支触发构建
审计追溯方便
- 代码变更和配置变更分开记录，出问题时能快速定位是代码问题还是配置问题

四、绝对不要做的事

❌ 不要把K8s配置文件直接写在Jenkins Pipeline里
❌ 不要把密码、密钥等敏感信息直接存在配置仓库
❌ 不要让开发人员拥有生产环境配置仓库的写入权限

面试标准答案

生产环境中，代码仓库和配置仓库应该是两个完全独立的Git仓库，托管在统一的Git服务器上。这样可以实现权限分离、变更隔离和清晰的多环境管理，符合GitOps的最佳实践。小型测试项目为了方便，可以将配置文件放在代码仓库的单独目录下。