极狐GitLab|云原生时代，关于GitOps你知道多少？

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

云原生是近几年最火爆的技术热词之一，几乎所有的云计算产品都会或多或少跟云原生发生关联。关于云原生，现在有一个大家都接受的定义：云原生技术使企业能够在现代动态环境中构建和运行可扩展的应用程序，如公有云、私有云和混合云。容器、服务网格、微服务、不可变的基础设施和声明式API是云原生的典型技术。其中，云原生应用程序的部署是重点，因为它与GitOps密切相关。

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

上述模式属于“push”模式，这是一种很常用的模式，很容易实现一键式部署。但是也存在一些问题，就是没法保证仓库清单(包括配置仓库和镜像仓库)和集群侧的实际情况相一致，集群侧的实际情况没法准确地在集群侧体现出来。长此以往，很容易发生“配置漂移”及安全合规问题。而想要解决这个问题，我们可以借助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的实践，则需要基础设施即代码(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让所有变更的发起和应用都聚焦在极狐GitLab仓库中，开启了云原生时代基础设施管理和应用程序持续交付的新篇章。GitOps能够带来“快速进行变更更新和回滚”、“人员工作体验的提升”、“安全性提高”、“合规审计容易做”等好处，但同时也存在着一些挑战，诸如“协作文化的建立”、“敏感信息的处理”、“Git Workflow的建立”等问题，但随着技术的发展，我们相信，这些困难也会被一一攻克的。