在此之前您可能听说过“GitOps”，但并不知道它到底是什么，除了GitOps，您可能还听说过DevOps，或者AIOps、GOps等，是的，现在是“Ops”盛行的时代。
GitOps是一种实现持续交付的模型，它的核心思想是将应用系统的声明性基础架构和应用程序存放在Git的版本控制库中。Choerodon猪齿鱼在构建持续交付流水线时参考了GitOps，并进行了实践，俗话说“兵马未动，理论先行”，在本文中，将重点阐述GitOps工作流程的原理和模式，以及将它们应用在生产和大规模运行Kubernetes中的一些实践经验。 在下一篇文章中，将介绍Choerodon猪齿鱼是如何实践和落地GitOps，从而构建了一个可重复且可靠的交付过程。
GitOps，90%的最佳实践，10%有意思的新东西需要我们去构建。 —— 《GitOps - Operations by Pull Request 》来自：https://www.weave.works
这篇文章是根据Weave Cloud的几篇关于GitOps的文章翻译整理而来：
GitOps
GitOps: Operations by Pull Request
The GitOps Pipeline - Part 2
GitOps - Part 3: Observability
GitOps - Part 4: Application Delivery Compliance and Secure CICD
主要内容：
什么是GitOps？ GitOps的应用场景——适合云原生的持续交付 GitOps的基本原则 最佳实践拉式流水线——Pull Request操作 GitOps工作流 可视化 应用交付的合规性和安全的CI/CD GitOps带来的价值 什么是GitOps？ GitOps是一种持续交付的方式。它的核心思想是将应用系统的声明性基础架构和应用程序存放在Git版本库中。
将Git作为交付流水线的核心，每个开发人员都可以提交拉取请求（Pull Request）并使用Git来加速和简化Kubernetes的应用程序部署和运维任务。通过使用像Git这样的简单熟悉工具，开发人员可以更高效地将注意力集中在创建新功能而不是运维相关任务上（例如，应用系统安装、配置、迁移等）。
GitOps: versioned CI/CD on top of declarative infrastructure. Stop scripting and start shipping. https://t.co/SgUlHgNrnY — Kelsey Hightower (@kelseyhightower) January 17, 2018
作为一个有经验项目管理者，或者产品负责人，你一定会思考一个问题：我们项目组在开发过程中应如何管理分支？不错，分支管理将和项目组开发人员日夜伴随，如果采用了一个不合适的分支管理模型，那么可以想象兄弟们得多么的痛苦。
Okay，那么就从分支管理模型开始......
GitOps的主要优点 通过GitOps，当使用Git提交基础架构代码更改时，自动化的交付流水线会将这些更改应用到应用程序的实际基础架构上。但是GitOps的想法远不止于此——它还会使用工具将整个应用程序的实际生产状态与基础架构源代码进行比较，然后它会告诉集群哪些基础架构源代码与实际环境不匹配。
通过应用GitOps最佳实践，应用系统的基础架构和应用程序代码都有“真实来源”——其实是将基础架构和应用程序代码都存放在gitlab、或者github等版本控制系统上。这使开发团队可以提高开发和部署速度并提高应用系统可靠性。
将GitOps理论方法应用在持续交付流水线上，有诸多优势和特点：
安全的云原生CI/CD管道模型 更快的平均部署时间和平均恢复时间 稳定且可重现的回滚（例如，根据Git恢复/回滚/ fork） 与监控和可视化工具相结合，对已经部署的应用进行全方位的监控 GitOps应用场景——满足云原生环境下的持续交付 作为CI / CD流水线的方案，GitOps被描述为软件开发过程的“圣杯”。 由于没有单一工具可以完成流水线中所需的所有工作，因此可以自由地为流水线的不同部分选择最佳工具。可以从开源生态系统中选择一组工具，也可以从封闭源中选择一组工具，或者根据使用情况，甚至可以将它们组合在一起，其实，创建流水线最困难的部分是将所有部件粘合在一起。
不管如何选择构造自己的交付流水线，将基于Git（或者其他版本控制工具）的GitOps最佳实践应用在交付流水线中都是一个不二选择，这将使构建持续交付流水线，以及后续的推广变得更加容易，这不仅从技术角度而且从文化角度来看都是如此。
当然，GitOps也不是万能的，它也有相应的应用场景。
应用都需要运行在多台机器上，它们被组织成不同的环境，例如开发环境、测试环境和生产环境等等。需要将相同的应用部署到不同的机器上。通常需要系统管理员确保所有的机器都处于相同的状态。接着所有的修改、补丁、升级需要在所有的机器中进行。随着时间的推移，很难再确保所有的机器处于相同的状态，同时越来越容易出错。这就是传统的可变架构中经常出现的问题。这时我们有了不可变架构，它将整个机器环境打包成一个单一的不可变单元，而不是传统方式仅仅打包应用。这个单元包含了之前所说的整个环境栈和应用所有的修改、补丁和升级，这就解决了前面的问题。 —— 摘自InfoQ的《关于不可变架构以及为什么需要不可变架构》作者 百占辉
“不可变基础设施”这一概念不是刚刚冒出来的，它也不是必须需要容器技术。然而，通过容器，它变得更易于理解，更加实用，并引起了业内广泛注意。“不可变基础设施”让我们以全新的方式理解和面对应用系统，尤其是使以微服务为代表的分布式系统在部署、运营等方面变得不那么复杂，而有很好的可控性。
那么，如何比较方便地在实际的生产过程中应用“不可变基础设施”，这给业界也提出了另外一个问题。GitOps是在具体Kubernetes的应用实践中出现的 ，GitOps需要依托于“不可变基础架构”才能发挥其作用。在一定程度上说，“不可变基础架构”为GitOps的出现创造了必要的条件，反过来GitOps应用Kubernetes的容器编排能力，能够迅速的使用镜像搭建出应用系统所需的组件。
Kubermetes作为一个云原生的工具，可以把它的“声明性”看作是“代码”，声明意味着配置由一组事实而不是一组指令组成，例如，“有十个redis服务器”，而不是“启动十个redis服务器，告诉我它是否有效”。
借助Kubermetes的声明性特点，应用系统的整个配置文件集可以在Git库中进行版本控制。通过使用Git库，应用程序更容易部署到Kubernetes中，以及进行版本回滚。更重要的是，当灾难发生时，群集的基础架构可以从Git库中可靠且快速地恢复。
Kubernetes等云原生工具的声明性体现在可以对实例、容器、网络、存储、CPU等配置通过一组代码方便的表达出来，Kubernetes等云原生工具可以利用这些配置代码运行出来一套基于容器的应用系统，例如YMAL，
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 1 template: metadata: labels: app: nginx spec: containers: - name: nginx image: registry.choerodon.com.cn/operation-choerodon-dev/nginx-demo:1.13.5-alpine ports: - containerPort: 80 Copy GitOps充分利用了不可变基础设施和声明性容器编排，通过GitOps可以轻松地管理多个部署。为了最大限度地降低部署后的变更风险，无论是有意还是偶然的“配置偏差”，GitOps构建了一个可重复且可靠的部署过程，在整个应用系统宕机或者损坏情况下，为快速且完全恢复提供了所需条件。
GitOps的基本原则 以下是几条在云原生环境中，GitOps的原则：
任何能够被描述的内容都必须存储在Git库中
通过使用Git作为存储声明性基础架构和应用程序代码的存储仓库，可以方便地监控集群，以及检查比较实际环境的状态与代码库上的状态是否一致。所以，我们的目标是描述系统相关的所有内容：策略，代码，配置，甚至监控事件和版本控制等，并且将这些内容全部存储在版本库中，在通过版本库中的内容构建系统的基础架构或者应用程序的时候，如果没有成功，则可以迅速的回滚，并且重新来过。
不应直接使用Kubectl
作为一般规则，不提倡在命令行中直接使用kubectl命令操作执行部署基础架构或应用程序到集群中。还有一些开发者使用CI工具驱动应用程序的部署，但如果这样做，可能会给生产环境带来潜在不可预测的风险。
调用Kubernetes 的API的接口或者控制器应该遵循 Operator 模式
调用Kubernetes 的API的接口或者控制器应该遵循 Operator 模式（什么是Operator 模式？），集群的状态和Git库中的配置文件等要保持一致，并且查看分析它们之间的状态差异。
最佳实践 Git是每个开发人员工具包的一部分。学习起来感觉自然而且不那么令人生畏，而且工具本身也非常简单。 通过使用Git作为应用系统的事实来源，几乎可以操作所有东西。例如，版本控制，历史记录，评审和回滚都是通过Git进行的，而无需使用像kubectl这样的工具。
所以，Git是GitOps形成的最基础的内容，就像第一条原则“任何能够被描述的内容都必须存储在Git库中 ”描述的那样：通过使用Git作为存储声明性基础架构和应用程序代码的存储仓库，可以方便地监控集群，以及检查比较实际环境的状态与代码库上的状态是否一致。所以，我们的目标是描述系统相关的所有内容：策略，代码，配置，甚至监控事件和版本控制等 ，并且将这些内容全部存储在版本库中，在通过版本库中的内容构建系统的基础架构或者应用程序的时候，如果没有成功，则可以迅速的回滚，并且重新来过。
目前大多数CI / CD工具都使用基于推送的模型。基于推送的流水线意味着代码从CI系统开始，通过一系列构建测试等最终生成镜像，最后手动使用“kubectl”将任何更改推送到Kubernetes集群。
很多开发人员不愿意在CI中启动CD部署流程，或者使用命令行工具操作启动CD部署流程的原因可能是这样做会将集群的用户和密码等公布出去。虽然可以有措施保护CI / CD 脚本和命令行，但是这些操作毕竟还是在集群外部非可信区工作的。所以，类似做法是不可取的，会给系统安全带来潜在的风险。
具有集群外读/写（R/W）权限的典型推送流水线：
CI运行测试，输出传递到容器映像存储库。 CD系统自动部署容器（或根据请求，即手动）。 在GitOps中，镜像被拉出并且凭证保留在集群中：
在上节中介绍了GitOps采用拉式模式构建交付流水线，本节将详细地介绍在构建GitOps流水时需要注意哪些事情，有哪些最佳实践。
GitOps的Config Update检测到有镜像 ，从存储库中提取新镜像，然后在Git配置仓库中更新其YAML。然后，GitOps的Deploy Operator会检测到群集已过期 ，并从配置库中提取已更改的清单，并将新镜像部署到群集。
使用群集内部的Deploy Operator，群集凭据不会在生产环境之外公开。一旦将Deploy Operator安装到集群与Git仓库建立连接，线上环境中的任何更改都将通过具有完全回滚的Git pull请求以及Git提供的方便审计日志完成。
由于没有单一工具可以完成流水线中所需的所有工作，可以从开源生态系统中选择一组工具，也可以从封闭源中选择一组工具，或者根据使用情况，甚至可以将它们组合在一起，其实，创建流水线最困难的部分是将所有部件粘合在一起。要实现GitOps，必须要开发出新的组件，用于粘合这些工具，实现拉式交付流水线 。
部署和发布自动化是应用落实GitOps，并使交付流水线工作的基础 。GitOps不仅要保证，当开发人员通过Git更新配置文件集的时候，GitOps流水线要自动根据最新的配置文件状态更新线上环境，而且GitOps还要能够实时比对Git库中配置文件集最新的状态与线上环境最新的状态保持一致。
在上节中提到了两个名词：Config Update 和 Deploy Operator ，根据GitOps的实践，Config Update 和 Deploy Operator是需要进行设计开发的，它们是实现GitOps流水线必须的关键组件。GitOps赋予了它们神奇的魔法，它们既是自动化容器升级和发布到线上环境的工具，可能也要负责服务、部署、网络策略甚至路由规则等任务。因此，Config Update 和 Deploy Operator是映射代码，服务和运行集群之间所有关系的“粘合剂” 。
当然，您可以根据具体的设计，赋予各种其他的功能，但是自动同步是一定需要的，确保如果对存储库进行任何更改，这些更改将自动部署到线上环境中 。
GitOps建议不直接将应用程序部署到线上环境中，而是将应用程序和相关配置打包成镜像，并存储到镜像库中，最后，通过镜像的方式生成容器，并部署到线上环境中。
容器为什么如此重要？在GitOps模型中，我们使用不可变基础架构模式。一旦代码在Git中提交，GitOps就不希望任何其他内容发生变化，这样可以最大限度地降低系统潜在不确定性、不一致性风险。例如，需要将相同的应用部署到不同的机器上。通常需要系统管理员确保所有的机器都处于相同的状态。接着所有的修改、补丁、升级需要在所有的机器中进行。随着时间的推移，很难再确保所有的机器处于相同的状态，同时越来越容易出错。然而，容器是比较完美地解决了这个问题，当然，使用虚拟机是可以的，显然使用容器更加方便。
“可观察性就像生产中的驱动测试一样。如果你不知道如何确定它是否正常工作，请勿接受 pull request。@mipsytipsy “ - Adriano Bastos
在GitOps中，使用Git库来存储应用系统的配置文集和应用程序，它确保开发人员将所有对于应用系统的配置和程序的新增、修改等都通过Git库进行版本控制，使Git成为配置和程序的唯一真实来源。而GitOps的可观察性则是确保线上环境的真实状态与Git库中的保持一致性。本章节将给大家介绍GitOps的可观察性。
在GitOps中，我们使用Git作为系统所需状态的真实来源。例如，如果应用系统宕机，GitOps可以回滚到之前正确状态。而可观察性是系统实际运行状态的真实来源，系统开发人员或者运维人员可以监控系统的状态。这是一张显示流程的图片。
如果大家使用Kubernetes作为云原生环境和容器编排工具，相信大家会有这样的感触，虽然Kubernetes是一个非常棒的编排容器平台，但是随之而来的缺乏友好的可视化管理界面给开发人员或者运维人员带来诸多不便。例如：
我的部署成功了吗？我的系统现在处于工作的状态，我现在可以回家吗？ 我的系统与以前有什么不同？我可以使用Git或我们的系统历史记录来检查吗？ 我的改变是否改善了整体用户体验？（与系统正确性相对） 我在信息中心找不到我的新服务（例如RED指标） 这个故障是否与我上次的服务更新事件有关，还是和其他操作有关系？ 大家可能会想到通过监控服务器的CPU、内存、网络等，以及应用的日志，甚至微服务的调用链等来解决问题。是的，这个没有错，能够得到一些反馈信息，但是使用过类似监控的开发人员或者运维人员也会感觉，这些监控仪表盘给我们大量冗繁的信息，需要认真地甄别，而且有很多信息在这些仪表盘中是获得不到的。这意味着需要创建新的仪表盘，用于监控新的指标和内容。
可观察性可被视为Kubernetes 持续交付周期的主要驱动因素之一，因为它描述了在任何给定时间系统的实际运行状态。观察运行系统以便理解和控制它。新功能和修复程序被推送到git并触发部署管道，当准备好发布时，可以实时查看正在运行的集群。此时，开发人员可以根据此反馈返回到管道的开头，或者将映像部署并释放到生产集群。
在这里GitOps引入一个新的工具：Diffs，用来监控对比系统状态。即：
验证当前线上系统的状态是否和Git库中描述的状态一致，例如，我上一次发布是否符合期望？ 提醒开发人员不一致状态，以及相应的明细信息。 在文章前面讲过，在Git库中存储的实际上是“声明性基础设施”，例如Kubernetes的YAML文件，用以构建应用系统所需的各种组件、域名、网络等配置信息。Diffs需要读取Git库中配置信息，同时，通过API等读取集群的相应信息，并进行比对。
例如，Kubernetes集群：所需的Kubernetes状态可能是“有4个redis服务器”。Diffs定期检查群集，并在数量从4变化时发出警报。一般而言，Diffs将YAML文件转换为运行状态查询。
GitOps是面向发布的操作模型，请参见下图。交付速度取决于团队在此周期中绕过各个阶段的速度。
由于以安全的方式跟踪和记录更改，因此合规性和审计变得微不足道。使用Diffs等比较工具还可以将Git库中定义的集群状态与实际运行的集群进行比较，从而确保更改与实际情况相符。
通过上面文章的叙述，开发人员或者运维人员通过Git操作系统配置和应用程序的新建和更新等。通过Git客户端git commit /git merge的所有操作都会Git库记录下来，审计员可以查看Git，看看谁做了任何更改，何时以及为何以及如何影响正在运行的系统部署。当然，可以根据自身的需求定制不同的交付合规性。相较于直接进入服务器操作或者通过Kubctl操作集群，Git记录了每一个操作步骤，这些可以为合规性和审计提供完整的操作日志。
几乎所有的Git库都提供角色和权限控制，与开发和运维无关的人员没有权限操作Git库。而不是直接把服务器或者集群的操作权限散发出去，这样特别容易引起安全泄露。
GitOps带来的好处 借助GitOps的最佳实践，开发人员可以使用熟悉的Git工具，便捷地将应用程序和其对应的配置文件集持续部署到Kubernetes等云原生环境，提高业务的敏捷度，快速地相应用户的需求，有助于增加企业市场的竞争力。
借助GitOps，可以实现一个完整的端到端的交付流水线。不仅可以实现拉式的持续集成流水线和持续部署流水线，而且系统的运维操作可以通过Git来完成。
更强大的安全保证
几乎所有的Git库都提供角色和权限控制，与开发和运维无关的人员没有权限操作Git库。而不是直接把服务器或者集群的操作权限散发出去，这样特别容易引起安全泄露。
由于以安全的方式跟踪和记录更改，因此合规性和审计变得微不足道。使用Diffs等比较工具还可以将集群状态的可信定义与实际运行的集群进行比较，从而确保跟踪和可审计的更改与实际情况相符。
Choerodon 猪齿鱼 是一个全场景效能平台，基于 Kubernetes 的容器编排和管理能力，整合 DevOps 工具链、微服务和移动应用框架，来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台，同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件，致力帮助企业聚焦于业务，加速数字化转型。
大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：
图：猪齿鱼-工作日历
图：猪齿鱼-查看工作日历任务
图：猪齿鱼-可将工作日历订阅到本地Outlook
图：猪齿鱼-工时日历
图：猪齿鱼-甘特图
Git库是拉式流水线模式的核心，它存储应用程序和配置文件集。开发人员将更新的代码推送到Git代码库; CI工具获取更改并最终构建Docker镜像。GitOps检测到有镜像，从存储库中提取新镜像，然后在Git配置仓库中更新其YAML。然后，GitOps会检测到群集已过期，并从配置库中提取已更改的清单，并将新镜像部署到群集。
这是一个新图，显示部署上游的所有内容都围绕Git库工作的。在“拉式流水线”中讲过，开发人员将更新的代码推送到Git代码库，CI工具获取更改并最终构建Docker镜像。GitOps的Config Update检测到有镜像，从存储库中提取新镜像，然后在Git配置仓库中更新其YAML。然后，GitOps的Deploy Operator会检测到群集已过期，并从配置库中提取已更改的清单，并将新镜像部署到群集。
