云原生架构与 GitOps 实战
王炜
前腾讯云 CODING 架构师
6217 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 44 讲
云原生架构与 GitOps 实战
15
15
1.0x
00:00/00:00
登录|注册

38|GitOps 为什么成为云原生交付的事实标准?

你好,我是王炜。
这节课,我想和你分享一下 GitOps 的历史和发展过程。
时间回到 2017 年,一家做 Kubernetes 解决方案的初创公司 Weaveworks 首次提出了 GitOps,在那个 DevOps 盛行的年代,GitOps 绝对是具有创造性的。Weaveworks 对 GitOps 的定义是:利用云原生工具和云服务进行应用程序部署和管理的最佳实践,定位是 DevOps 的进一步扩展。
除了给出定义,Weaveworks 还开源了 FluxCD。没错,它就是现在和 ArgoCD 竞争的 CNCF 毕业项目。它们的作用都是监听 Git 仓库的变化,和集群内的对象进行对比,并自动应用有差异的部分。
不过,需要注意的是,GitOps 并不等于 FluxCD 或者 ArgoCD,它代表的是一种工程实践的方法。那么,为什么这个方法会成为应用交付的事实标准呢?到底要怎么理解 GitOps,相比较传统的交付过程,它独特的优势是什么?
首先,我们需要先理解 GitOps 到底是什么?

GitOps 是什么?

根据 Weaveworks 的总结,我们可以简单地把 GitOps 概括为下面两件事。
它是一种管理模型,也是一种云原生技术,负责为应用程序的部署、管理和监控提供统一的最佳实践。
它提供了一种实现开发者自助发布的路径,统一了开发团队和运维团队。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

GitOps已成为云原生交付的事实标准,自2017年Weaveworks首次提出GitOps以来,它已经成为云原生工具和云服务进行应用程序部署和管理的最佳实践。GitOps的核心概念是利用Git作为单一来源,实现声明式、版本化和不可变的自动化部署。其优势包括提升发布效率、优化开发者体验、提高稳定性和可靠性、标准化和一致性以及更强的安全性。GitOps的变革性影响主要体现在将应用交付从推模式转变为拉模式,补充了基础设施即代码的不足,并逐渐取代了传统的DevOps模式。GitOps的发展和应用为云原生交付带来了巨大的变革,成为了云原生应用交付的标准。 虽然DevOps比GitOps支持更广泛的应用程序模型,但随着容器化和Kubernetes技术的普及,DevOps的优势已经不再明显。GitOps的工具链相对更轻量,更符合云原生快速发展的标准。随着GitOps在开发者群体中的认可度越来越高,DevOps很可能会淡出开发者的技术选型。 总的来说,GitOps吸收了DevOps的优势,同时也借鉴了SRE(网站可靠性)的思想,给我们带来了颠覆式的应用交付体验。GitOps的发展和应用为云原生交付带来了巨大的变革,成为了云原生应用交付的标准。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《云原生架构与 GitOps 实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(4)

  • 最新
  • 精选
  • 林龍
    老师,不知道我的理解对不对 1.devops的做法是。我们一般提交代码到git后jenkins的做法是执行一系列命令完成部署,由于k8s是一个非常重要的组件所以不允许jenkins执行操作k8s相关的命令 2.如果把yaml文件放在了git中,由k8s去监听git的变化,把被动变成主动。同时让k8s的命令操作不允许外部来执行。 3.通过git记录可以监控/记录k8s的操作记录,让变更有据可查。 4.项目git代码与git yaml配置分离可以很好的避免让开发直接操作配置文件导致k8s的变更(自己公司遇到了有人改了jenkins流水线,导致构建失败)

    作者回复: 👍是的,这几点都总结得非常正确。

    2023-03-06归属地:广东
    5
  • Waylon
    "在推模式下,CI 或者 CD 修改集群对象时,它需要在集群外部取得集群的凭据..... 而 GitOps 通过 Operator 在集群内实现了拉的模式,在解决凭据安全问题的同时....." 老师,文中提到的,如果以ArgoCD为例,ArgoCD部署在本集群的话,确实是不需要额外添加kubeconfig做认证,但是生产环境下,通常都是多个集群,如果让ArgoCD支持多集群部署,也需要用argocd命令添加kubeconfig,进而将目标集群添加到ArgoCD. 额外添加的kubernetes cluster,相对于ArgoCD 而言,也是外部集群呀,同样是通过kubeconfig获取了集群认证凭据,进而才能通过gitrepo协调吗。 所以老师,我对于您描述的上述信息,不是特别理解,希望可以再进一步答疑解惑。

    作者回复: 无论是单集群还是多集群,凭据实际上都不会离开集群。只不过多集群的管理方式相当于把其他集群的凭据报错在了 Argo CD 的运行集群中。 另外多集群的方式有两种,你提到的是其中一种方式,另一种是为每一个集群部署一个 Argo 实例。

    2023-03-26归属地:北京
    2
    1
  • 思绪走了灬光✨
    老师想请教一下,对于大部分的业务开发人员来说,主要工作都在业务的CRUD,gitops所涉及到的各种k8s概念的yaml配置,是否适合让所有业务开发人员来掌握呢?

    作者回复: 不适合,所以需要有专门的 DevOps 人员来解决发布流程的问题,而对于开发人员来说,他只需要关注自己的交付物,也就是制品(jar 包,Docker镜像等)是没问题的即可。

    2023-06-10归属地:北京
    2
  • 夜空中最亮的星
    GitOps 确实会越来越多的使用了
    2023-03-06归属地:北京
收起评论
显示
设置
留言
4
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部