| 本文将介绍GitOps的工做原理，它的启动与运行，以及如何在Kubernetes中配合使用GitOps，以团队的DevOps体验. |
英国做家Aldous Huxley曾说：“速度是真正的乐趣之源。”我认为生活如此，软件领域亦然。随着DevOps以及GitOps之类辅助实践的兴起，软件从架构设计到代码被部署到生产环境的速度是愈来愈快。html
实际上，DevOps是经过定义一组实践和文化的转变，来提升咱们生成代码的速度，并保证代码的可靠性。DevOps自己只是一个广义术语，不一样的组织和团队在其核心原理上开发出了各类具体的实践，其中包括：ChatOps、DevSecOps、AIOps、以及一种称为GitOps的较新的实践。linux
GitOps的出现和兴起，主要得益于软件开发行业对于Kubernetes的普遍采用。在各种组织向Kubernetes的迈进过程当中，开发团队的逐步成长，以及对于扩展集群的管理实践会变得势在必行。所以GitOps旨在将Git和Kubernetes结合在一块儿，为开发人员提供某种形式的操做模型、以及基于Kubernetes的基础架构和应用程序。能够说，在Kubernetes开发的过程当中，GitOps可以在确保“速度”的基础上，实现软件方案的持续交付。git
下面，咱们来看看GitOps的工做原理，它的启动与运行，以及如何在Kubernetes中配合使用GitOps，以团队的DevOps体验。github
GitOps秉承了DevOps的核心理念--“构建它并交付它(you built it you ship it)”。它可以让开发人员在本身所选的Git工具中，提出拉式请求，触发Kubernetes集群的部署，从而使得Git成为惟一的来源。编程
显然，该思想是将基于推式的管道替换为基于拉式的管道，从而使得开发人员可以直接根据其拉式请求执行部署。而一旦开发人员执行合并或打开请求，该基础结构就会在部署过程当中触发一系列的事件。GitOps运算符(operator)只要检测到此类变化，就会致使另外一个运算符声明的更改，并将其部署到集群之中。例如，您可使用以下工具栈来实现GitOps：架构
- 将Bitbucket做为您的Git VCS(译者注：Version Control System，版本控制系统)工具。
- 用Docker存储您的各类镜像。
- 用Amazon S3来存储各类Helm图表。
- 用AWS Lambda拉取图表，并提交给集群存储库。
- 用Weaveworks Flux检测集群存储库中的更改，并作相应的调整。
固然，在您的工具栈中，实现此类功能的实际基础架构可能会有所不一样，可是其机制倒是类似的。函数
以下是能够实现的GitOps工做流：工具
- 使用Bitbucket管道之类的CI(持续集成)工具，将各类Docker镜像推送到Quay之类的托管(hosting)工具处。
- 各类云功能函数从主存储bucket处，将不一样的配置和helm图表复制到主git存储库中。
- 诸如Weaveworks Flux之类的GitOps运算符，会根据各类配置图表去更新集群，并经过Lambda函数提取不一样的helm图表。
固然，上述技术栈中所描述的每一个工具都有着对应的替代方案，开发团队能够选择最适合的工具，以实现DevOps的目标。例如，同属于Atlassian套件的Jira功能就可以轻松地与Bitbucket协同发挥做用。所以，若是一个拉式请求在Bitbucket中被建立，就会自动将Jira中的问题发送到自定义的“部署”上。这将大幅简化从设计到发布的DevOps实践过程。测试
相似地，当考虑到经过GitOps实现的持续交付机制可能出现失败时，咱们能够添加其余的监控工具，以提供急需的可见性。例如，Thundra.io可被用于监控S3触发的AWS Lambda函数，以确保在将更改提交给集群存储库时，不会发生任何故障。ui
同理，咱们也能够利用Thundra.io的集成功能，将警报发送给Opsgenie之类的报警工具，进而通知合适的值班人员，以快速解决那些由拉式请求触发的部署所引起的任何问题。
可见，咱们彻底能够经过向GitOps引擎添加更多的功能，以提升GitOps实践过程当中的可靠性和便利性。
总的说来，GitOps可以为Kubernetes的部署提供融合、幂等、肯定性和自动化等方面的功能。根据Kubernetes强大的收敛机制，它将不断尝试去改变集群的状态，让各类收敛应用都具备相同的结果。并且这些都会自动而迅速地被触发。
Kubernetes的编排器(orchestrator)会持续将各类更改应用到集群中，直到集群收敛到配置更新所定义的状态为止，也就是要知足开发人员或SRE人员所指望的配置状态。这不但适用于全部的Kubernetes资源，还可以被用到自定义资源(Custom Resource Definitions，CRD)或Kubernetes的扩展。
整个GitOps的过程始于在Git存储库中定义某个所需的状态，而后Git被定位为惟一的来源。此外，咱们须要保障提交过来的更改可以与群集相配，以便标记处群集是已经收敛到了所需的状态，仍是已偏离了该状态。
当指望状态与实际状态不相同时，Kubernetes中的收敛运算符会主动尝试着补足这两个状态之间的差别，即：根据那些针对Git的提交，触发更改的“差别”警报，以标识处仍然须要进一步的收敛。所以，这就意味着，全部的提交都会产生对于集群的可验证的、且幂等的更改。固然，Kubernetes也可能按需产生回滚。就其机制而言，回滚能够被看做是进一步收敛到之前的状态。
最后，若是系统中再也不存在“差别”警报、或仅存在“聚合”警报，那么该机制就认为实际状态已经达到了所需的状态。实际上，咱们可使用回调、或回写事件的方法，来设置此类聚合状态。
至此，咱们能够认识到：GitOps依赖于IAC(译者注：基础架构即代码)的概念。即：以编程的方式定义了基础架构，而基础架构的实际状态也会随着发生相应的变化。这种就是咱们在前文中提到的基于拉式的部署方式，它与传统的基于推式的部署有所不一样。
如您所知，DevOps是一个广阔的领域，它不只仅限于软件行业。而GitOps则只是在软件行业朝着更加敏捷、可靠的方向发展过程当中，一种新兴的开发实践。更准确地说，随着技术趋势的变化，开发实践必须适应可用的技术，而GitOps是团队和组织如何跟踪技术发展，持续推动开发实践的一种优秀示例。值得一提的是，诸如Weaveworks Flux之类的运算符，能够很好地帮助您在集群启用GitOps。固然，您也能够选用Spinnaker之类的其余代替方案。
此外，考虑到持续部署可能会给生成环境带来风险，咱们能够经过添加诸如Thundra.io和Opsgenie之类的工具，来对系统进行全覆盖性的测试，以减小风险点，保证必定的可观察性和事件管理能力。
总的来讲，咱们能够将GitOps视为一种实践，它可以利用Kubernetes的核心力量，来加快软件从设计到发布的所有过程。咱们只有掌握了GitOps的工做原理，才能充分发挥Kubernetes在容器服务方面的巨大潜力，为持续部署与持续交付保驾护航。