本文整理自文章:https://mp.weixin.qq.com/s/rHf5goV66_ItfqRg9wpG4Q
1 前言
DevOps起源于2007年,是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运行和质量保障(QA)部门之间的沟通、协作与整合。它是一种重视”软件开发人员(Dev)”和”IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。通过自动化”软件交付”和”架构变更”的流程,来是的构建、测试、发布软件能够更加快捷、频繁和可靠。它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运维工作必须紧密合作。
DevOps优势明显:能够对各种修改需求做出快速的反应、能实现灵活的安全部署与编排、能够简历完善的协作与沟通渠道、能快速地识别出代码中的错误和漏洞、开发团队聚焦关键问题,不必过度专注于各项安全功能。
基于云原生技术的DevOps时代,全面体现在全栈自动化和云原生工具生态能力。
全栈自动化体现为:
- 流水线自动化
- 故障自愈
- 支持跨数据中心调度
- 以整套环境为单位交付
云原生工具生态丰富:
- k8s原生类CI/CD系统
- 服务可视化编排
- 滚动升级发布
- 流量接入/灰度发布能力
2 DevOps系统选型分析
当今市面上开源的DevOps系统工具种类繁多,如何正确、高效且符合云原生技术发展趋势等多重维度来选型DevOps工具,对企业进行数字化转型尤为重要。
对于分析开源界主流DevOps CI/CD工具系统:
- Jenkins作为老牌CI/CD工具,具备一定的技术历史北京,但明显感觉太重,Jenkins的pipeline语法学习成本较高,非kubernetes原生态工具
- Spinnaker持续交付平台,是一款专注于多云平台的CD平台,功能专注于持续交付,对于CI/CD并不擅长
- Gitlab虽自带CI/CD系统,但非kubernetes原生,考虑低耦合设计,为避免和Gitlab耦合,不想用gitlab-ci
- Tekton是Google开源的kubernetes原生CI/CD系统,作为CDF四个初始项目之一,基于kubernetes CRD可以自定义的pipeline流水线,但在工作流控制上的支持较弱
- Argo是一款遵循声明式Gitops理念的持续部署工具,应用定义、配置和环境信息是声明式的且可以进行版本控制,应用部署和生命周期管理是全自动化的且可审计,支持对多环境、多kubernetes集群上的应用进行统一部署和管理
结合以上分析,选择Tekton+ArgoCD进行云原生的DevOps实践
3 Tekton+ArgoCD 实践-场景
准备工作:
- 准备git repo
- Tekton Pipeline、app code、kubernetes deploy三部分
- 安装Tekton/ArgoCD客户端、Tekton Operator、ArgoCD Operator和ArgoCD服务端环境
- 创建ArgoCD的应用
- 创建Tekton Pipeline
- 运行Tekton Pipeline更新Infra Repo中的内容
- 创建Webhook并配置Code Repo的Webhook
- 运行Tekton Pipeline
- 手动执行tkn pipeline start
- Gitlab上修改即提交Code,webhook触发
场景描述如下:
- 应用代码放在Code Repository中,代码变化后会通过Webhook触发Tekton的Pipeline运行
- Tekton的Pipeline先从Code Repository中获得应用代码,然后Build成Image,随后将应用Image推送到容器云平台内部的Image Registry中。最后在更新Infra Repository中的部署配置
- ArgoCD发现Infra Repository中的部署配置发生变化后自动同步到容器云平台
- 容器平台根据新的部署配置从其内部的Image Registry获取最新的应用Image,然后部署到容器云平台
- ArgoCD+Argo Rollouts支持blue/green、canary多种部署方式,结合开源的keptn做SLI/SLO及自动化测试
4 基于 Argocd-Rollouts 进行 blue/green canary 发布
在云计算技术或云原生技术出现之前,一些互联网公司也有灰度发布的需求,也会基于一些开源工具做定制化研发,如使用Nginx等,使用其定制开发一些基于Request Header流量切分、基于服务权重的流量切分、基于Cookie的流量切分等的规则引擎。
目前业内流行的blue/green、canary发布技术有几类,引入和改进适合自身场景的灰度发布技术很重要,比如:
- 可以使用服务网格istio的gateway+virtualservice+destinationrule做灰度发布,但由于istio自身技术栈具有一定深度,要全面账务其技术运用和维护需要一定的成本,故只为了进行灰度发布选用istio会导致学习成本和应用成本过高
- 另外也可以基于kubernetes的Ingress进行配置Ingress Annotations来实现不同场景下的灰度发布和测试,其本质就是Nginx的应用
- 第三类则是使用基于ArgoCD-Rollouts进行blue/green,canary发布。既然我们选择了使用Tekton+ArgoCD做DevOps系统工具,为保持技术栈统一则继续深度使用基于云原生的ArgoCD-Rollouts进行灰度发布。提前编写好yaml编排文件