GitOps 和 DevOps 有什么区别？

2024-04-22 15:46:03

GitLab 是一个全球知名的一体化 DevOps 平台，很多人都通过私有化部署 GitLab 来进行源代码托管。极狐GitLab ：https://gitlab.cn/install?channel=content&utm_source=**** 是 GitLab 在中国的发行版，专门为中国程序员服务。可以一键式部署极狐GitLab。

学习极狐GitLab 的相关资料：

  1. 极狐GitLab 官网：https://gitlab.cn
  2. 极狐GitLab 官网文档：https://docs.gitlab.cn
  3. 极狐GitLab 论坛：https://forum.gitlab.cn/
  4. 极狐GitLab 安装配置：https://gitlab.cn/install
  5. 极狐GitLab 资源中心：https://resources.gitlab.cn

搜索【极狐GitLab】公众号，后台输入加群，备注gitlab，即可加入官方微信技术交流群。

GitOps：又一次造词运动？


伴随着DevOps在近些年的火爆，围绕xOps产生了很多概念，诸如DevSecOps，AIOps，MLOps，ChatOps等等，当然还有今天讲述的主角GitOps。

人们在xOps这条造词之路上越走越远，也从“一环”(Ops)到了“二环”(DevOps，AIOps，ChatOps等)再到了“三环”(DevSecOps，DevBizOps GitSecOps等)，“四环”在等待大家一起创造修建。

在这里插入图片描述

诚然，“造词运动”产生的概念让人们目不暇接，每一个点都意味着有新东西出来，让本来就不够用的脑容量更加捉襟见肘，唯有“躺平”以应对。但是，就算“躺平”也要在“躺平”之前吃点“干货”，要不就算躺不废，也得被躺饿死。GitOps便是“躺平”之前的最佳能量棒。

GitOps这个词出现于2017年，是由Weaveworks公司根据多年云计算基础设施和应用程序管理经验而提出的一个概念。可以看出GitOps是非常年轻的，它的出现与云计算的大力推进有关，也可以大胆、准确点说与云原生有关。

大名鼎鼎的云原生(Cloud Native)

现如今，没听过云原生都不好意思跟别人交流，不知道云原生都没法跟别人说组织在上云。云原生概念的提出在2013年，经过了这几年的演进，成立了发展势头火爆的CNCF(Cloud Native Computing Foundation)基金会，也对与云原生的定义，有了一个大家都接受的定义：

云原生技术使企业能够在现代动态环境中构建和运行可扩展的应用程序，如公有云、私有云和混合云。容器、服务网格、微服务、不可变的基础设施和声明式API是云原生的典型技术。

注：Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

关于云原生的更多内容，在这儿不多赘述，大家可以查看CNCF官网。云原生应用程序的部署是我们重点讨论的，因为它与GitOps密切相关。

云原生系统(基础设施和应用程序)管理之痛


一般情况下可以使用下面的持续交付系统(示意图)来完成云原生应用程序的部署与交付。

在这里插入图片描述

上述模式属于“push”模式，我称之为“一杆子到底梭哈型”(流程从左到右走到底)，这是一种很常用的模式，很容易实现一键式部署。但是也存在一些问题：

  • 配置仓库里清单文件(包括应用和基础设施)描述的内容是否和Kubernetes集群侧的实际情况是否一致。

  • 镜像有更新时不能够自动同步至集群侧(除非每次从头到位走一遍部署流程)。

  • 安全合规问题(有可能需要操作人员通过kubectl 命令做一些集群操作)。

简而言之，就是没法保证仓库清单(包括配置仓库和镜像仓库)和集群侧的实际情况相一致，集群侧的实际情况没法准确地在集群侧体现出来。长此以往，很容易发生“配置漂移”(所想不等于所得，且见下文)及安全合规问题。

注：从上图看，编码、构建、镜像打包等都在极狐GitLab 上完成，所谓 All in JiHu GitLab and One-stop shop DevOps platform。

然而，“山重水复疑无路，柳暗花明又一村”。云原生的其中一个自带属性：声明式是解决这个问题的关键点，关于声明式的理解以及解题思路可以查看如下示意图：

在这里插入图片描述

声明式系统有个特点：能够帮我们自动完成应用程序(或基础设施系统)的描述状态和实际状态的自动同步，保证两者能保持一致。比如，应用部署清单里面应用程序是一个副本(replicas=1)，那么集群侧应用程序就会是一个pod。借助于这个特点，上述“push”模型的问题可以做如下解答：

既然声明式系统可以用文件清单来描述(典型如yaml文件)，那么既然是文件就可以存储到极狐GitLab上(发挥了版本控制系统的功能)。开发人员或者运维人员想修改某些内容(应用程序属性、基础设施配置)的时候，只需要修改文件清单即可(修改完毕提MR，方便Review)，此时这个变更就会被自动同步至集群侧。所以现在只需要找一个方法能够自动实现这种变更监听和变更自动同步即可，而这正是今天的主角GitOps要做的事情。

呼之欲出的GitOps

前面铺垫了这么多，GitOps终于出现了，关于GitOps有这么几个特性：

  • 以声明式系统(包括基础设施和应用程序)为基座(典型如Kubernetes)。

  • 以Git(典型如极狐GitLab)为单一可信源。

  • 一切皆代码(应用程序 & 基础设施)。

使用GitOps，上述的“push”模型就变为了下面的“pull”模型：

在这里插入图片描述

“Pull” 模型的关键就是：单一可信源(如极狐GitLab)与Kubernetes集群的集成，当可信源侧的文件清单发生变更的时候，集群侧能够及时捕捉到此变更，从而完成变更清单的部署。而极狐GitLab Kubernetes Agent正是为了解决这个问题而诞生的。极狐GitLab Kubernetes Agent 有两部分组成：位于集群侧的极狐GitLab Kubernetes Agent(agentk)和位于极狐GitLab侧的极狐GitLab Kubernetes Agent Server(GitLab-KAS)，能够很好的完成上述的 GitOps Workflow。也敬请期待后续的专文解析与实战。

GitOps 之三叉戟


GitOps的实践需要基础设施即代码(Infrastructure as Code，简称 IaC)、Merge Request(MRs)、CI/CD三叉戟的组合拳。

基础设施即代码(IaC)

基础设施即代码是一种基于使用软件开发实践来进行基础设施自动化管理的方法。它强调通过一致的、可重复的程序来对基础设施系统进行修改。当需要对基础设施进行修改时，只需要修改于基础设施相关的代码即可，随后会有自动化来测试这些变更并最终将这些变更应用到基础设施系统中。

GitOps的重要特性之一就是：一切皆代码。以Git为单一可信源，所有与软件开发相关流程中的代码(包括基础设施代码、应用程序源码、配置等)都会存储在Git仓库中。

极狐GitLab很好的与基础设施即代码中的瑞士军刀——Terraform做了集成，可以方便的完成云基础设施的自动化管理。所有管理过程都是通过合并请求(Merge Request)来完成的，当需要对基础设施作某些变更时，只需要修改代码，并提交MR，在所有的修改都被审查和批准后，代码可以被合并到主分支上。一旦代码变化被合并，所有的变化将被部署到生产中。

Merge Request(MR)

当开发或者运维想要对系统(基础设施或者应用程序)做出某些变更时，需要提一个Merge Request，这是一种让多人、多团队进行协作的方式，能更好的对变更进行评审(Review)，提前评估变更的必要性、准确性、安全性等，从而降低变更给系统带来的风险。对系统所有的变更发起点都是代码变更，这样就使安全审计变得简单，因为一切皆代码，所见即所得，评审、审批都在仓库系统中，对于所有人员都是透明可见的，透明度也会增强团队成员之间的信任度和协作性。

CI/CD

当MR创建审核完毕，后续的变更需要CI/CD自动化的流程去完成系统的变更。自动化的流程减少了人为的手动干预，减少了人员误操作所带来的风险，同时能够节省时间，在大规模使用场景中，是非常重要的一环。

GitOps之爽

GitOps让所有变更的发起和应用都聚焦在极狐GitLab仓库中，开启了云原生时代基础设施管理和应用程序持续交付的新篇章，它能够带来以下好处：

  • 快速进行变更更新和回滚

变更的更新和回滚都是通过极狐GitLab的Merge Request来进行，可能是一个命令就能完成，简单高效。

  • 人员工作体验的提升

所有人员可以通过极狐GitLab进行有效的协作，那些邮件、ticket满天飞的日子也将不复存在。极狐GitLab是大家都熟悉的平台，再也不用在不同工具、平台间来回切换来完成系统的变更，大家的学习成本减少了，能更好的关注在业务本身。毕竟安安静静写代码、搞技术是每个人梦寐以求的。

对于新入职的员工来讲，通过阅读极狐GitLab仓库代码，可以快速熟悉业务、环境等内容，并用相应代码快速搭建起开发环境，从而快速融入团队，贡献自己的力量。人员培养成本降低了，工作体验提升了，对于公司来讲，做到了“降本增效”。GitOps充分体现了以人文本的理念。

  • 安全性提高

一切操作都是在极狐GitLab的仓库上，不用再给不同人员赋予不同系统的不同权限，保证了系统的安全性，同时可以在极狐GitLab上通过仓库的鉴权和授权模式严格控制不同人员的不同操作权限。同时，一切变更都是自动化进行，手动操作的减少，会大大降低误操作带来的风险。

  • 合规审计容易做

一切操作(哪个人员在何时做了什么操作)都在极狐GitLab上一目了然(通过MR，comment等)。所谓所见即所得，也让合规审计变得高效、容易。

GitOps之殇


GitOps用着爽，但是依旧面临一些挑战，诸如:

  • 协作文化的建立

极狐GitLab提供了一个用户体验良好的协作平台，但是使用平台的是人，协作是人与人之间、人与平台之间的协作，良好的协作需要每个人都去遵守协作流程和纪律,(诸如任何变更都应该提MR然后Review最后自动化Apply流程，不要手动操作，哪怕几秒能完成的小变更)。从而建立起良好的协作文化。随着公司规模的扩大，异地跨区域的协作变得越来越多，这一块儿是一个挑战，需要每一个人都参与进去，遵守流程和纪律，逐步培养出良好的协作文化。

  • 敏感信息的处理

一切皆代码，意味着用户名、密码、证书、token等敏感信息也要存储到极狐GitLab仓库中，而这是兵家之大忌。不幸中之大幸就是：极狐GitLab和Vault有着完美的结合，能够很好的解决这个问题。关于这部分后续我们会有专门的文章分析并实践。敬请期待。

  • Git Workflow的建立

一切变更的发起、执行都在极狐GitLab上，也就意味着需要建立行之有效的Git Workflow，而这在现如今多云、混合云等基础设施，采用为服务的应用程序来说是个很大的挑战。而这需要大量的测试、运行来逐步建立并完善。

学习极狐GitLab 的相关资料：

  1. 极狐GitLab 官网：https://gitlab.cn
  2. 极狐GitLab 官网文档：https://docs.gitlab.cn
  3. 极狐GitLab 论坛：https://forum.gitlab.cn/
  4. 极狐GitLab 安装配置：https://gitlab.cn/install
  5. 极狐GitLab 资源中心：https://resources.gitlab.cn
上一篇：【数据结构（八）上】二叉树经典习题-3.总结


下一篇：leetcode 23