ArgoCD+Jenkins持续集成

小记：这篇文章包含知识点有点多，后面文章会提到。这篇文章主要是给公司内部开发看的，包含知识点有 Jenkins，gitlab，KubeSphere，helm，Argo 等技术

1 技术背景

• 传统部署方案更新服务太慢，因为流程里有拉取代码，打包，制作镜像，上传与拉取镜像，启动服务。新的部署方案可以提前打包，制作并上传镜像。更新服务的时候只有拉取镜像与启动服务的操作。
• 传统部署方案需要部署一个服务审批一次，增加多余的人为操作。新的部署方案点一下所有服务并行部署
• 传统部署方案没有开源的部署大盘，不能详细的查看集群状态。新的部署方案集成部署大盘
• 传统部署方案多个集群，多个项目维护复杂。新的部署方案一个页面可以看到多个项目与集群的情况
• 新方案通过 gitops 保证服务编排文件不会变动，并提供备份
• 传统部署方案回滚麻烦，就算预先写好策略也只能回滚一次，执行了在想回滚只能找运维。新的部署方面回滚简单
• 新的部署方案灰度发布过更优雅。并且可以分流，如百分之 80 的流量都访问新部署的节点（但是 dubbo 架构不云原生，无法体验到，只能根据数量做流量权重，比如新节点 1 个，老节点 3 个，百分之 25 的流量分配到新的跌点

2 部署架构图（偷来的，如有冒犯请联系我）

区别

传统方案：全部都交给 Jenkins 操作，并且只能在更新生产环境的时候操作

新方案：Jenkins 的主要作用是打包后制作并上传镜像，生成编排文件上传到 git。更新的时候通过 argo 同步 git 仓库进行更新

3 更新流程

web，h5 等前端静态服务因为放到 oss 上，生产环境更新使用传统部署方案，不过中间增加审批步骤
Jenkins打包制作镜像,argocd负责部署

4 Jenkins 相关

4.1 KubeSphere 的 DevOps 工程

需要更新二方包先更新二方包
jenkins编写参考: Jenkins-pipeline

4.2 点击运行选择项目项目

这个步骤你感觉可以上生产了可以随时更新

4.3 检测代码会钉钉通知是否通过

4.4 如果没通过会停止更新，如果通过会收到钉钉通知

5 argo 相关

配置参考 ArgoCD

我规划是一个只读账户，用来查看日志与 pod 状态。没有操作权限，给所有开发用的
一个管理员账户，有所有权限，只有负责人有这个账户
配置账户参考ArgoCD

5.1 到更新生产的窗口期登录 argo

5.1.1 如果更新多个项目

5.1.2 如果只更新某个项目

点击项目

5.2 更新某个项目的某个服务

进入项目里面

5.3 正常流程点击更新后会更新百分之 25 的实例然后暂停 2 分钟后自动更新

注：目前只有两个阶段，第一阶段看服务能不能正常起来，第二个阶段更新所有节点。后面实例多了会增加第三个阶段，一部分老代码，一部分新代码对外提供服务。

5.4 如果启动没问题的话可以手动点继续更新

5.5 回滚

5.5.1 如果更新过程中有问题的话选择回滚

5.5.2 如果全部都更新完了想回滚

• 注：不管那种方式回滚后想继续更新重复第一步操作

Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io)