什么是GitOps | 将DevOps扩展到Kubernetes和其他地方

　　对CI/CD的完整了解超出了本文的范围，但我们需要对CI/CD说几句，因为它是GitOps运作的核心。CI/CD的持续集成部分是由像Git这样的版本控制库支持的:开发人员可以对他们的代码库进行持续的小改进，而不是每隔几个月或几年就推出一个巨大的、单一的新版本。

　　​在编程领域，最近十年，发生了许多革命性的变化。其中之一，便是围绕devop的一系列实践，这些实践将开发和运营团队整合到一个共享的工作流程中，并实现了持续集成和持续交付(CI/CD)，其中devops团队会不断向代码库提供了增量的更新。另一个转变来自相关的转变，从单个代码库，转变到运行在业务平台(如Kubernetes)管理的容器中的基于云的微服务。

　　在集群系统或云中运行的基于容器的应用程序可能很复杂，并且即使使用像Kubernetes这样的平台来协调事物，也很难对其进行配置和管理。GitOps是一组新兴实践，旨在通过应用devops和CI / CD领域的技术来简化此管理任务。

　　GitOps的关键在于基础设施即代码的理念，它采用与devops提供应用程序相同的方法来提供基础设施。因此，不仅应用程序，而且底层的主机和网络都在文件中进行描述，这些文件可以作为版本控制系统中的任何其他代码来处理，然后将真实的应用程序与这些文件中描述的应用程序融合在一起。

　　用GitOps的说法，版本控制系统中的代码是关于应用程序在生产环境中应该是什么样子的唯一来源。

　　GitOps定义

　　Weaveworks是为推广GitOps概念所做的最大努力的公司。我们将详细介绍Weaveworks的角色，但首先，让我们看一下该公司对GitOps的定义，它有两个方面：

　　Kubernetes和其他云原生技术的运行模型，提供了一组最佳实践，这些最佳实践统一了容器化集群和应用程序的部署，管理和监视。

　　通往开发人员管理应用程序体验的途径;端到端CI / CD管道和Git工作流同时应用于运营和开发。

　　换句话说，GitOps是一组专门为管理Kubernetes和类似平台而设计的实践，随着越来越多的开发机构采用devops实践并将代码迁移到云上，它也可以应用于更广泛的应用。但是为了理解GitOps的秘密武器和它所解决的问题，我们需要谈谈它的组成部分。

　　Git定义

　　GitOps中的Git是指Linus Torvalds在2005年开发的非常流行的分布式版本控制系统。Git是一种工具，它允许开发团队在一个应用程序代码库上共同工作，存储他们在将代码合并到生产代码之前对其进行修改的各种代码分支。Git中的一个关键概念是pull request，在这个概念中，开发人员正式要求将他们一直在工作的一些代码集成到代码库中的另一个分支中。

　　Git pull请求为团队成员提供了一个协作和讨论的机会，然后就是否应该将新代码添加到应用程序达成一致意见。Git还存储了较旧版本的代码，这使得在出现错误时很容易回到上一个好版本，并让您快速查看不同版本之间的更改。Git最出名的可能是作为GitHub的基础，GitHub是一种云托管版本控制系统，但是Git本身是一种开源软件，可以部署在任何地方，从公司内部的服务器到你的个人电脑。

　　请注意，虽然我们通常认为Git是一种计算机编程工具，但它实际上并不知道您使用它来做什么内容。Git将乐于将任何文本文件集作为“代码库”，例如，作者可以使用它来跟踪协作工作的编辑。这一点很重要，因为GitOps核心的大部分代码基由声明性配置文件组成，而不是可执行代码。

　　在我们继续之前，还有最后一件事要说:尽管名称中有“Git”，但GitOps实际上并不需要使用Git。已经投入了其他版本控制软件(如Subversion)的公司也可以实现GitOps。但是Git在devops中被广泛用于实现CI/CD，所以大多数GitOps项目最终都将使用Git。

　　CI / CD流程是什么?

　　对CI/CD的完整了解超出了本文的范围，但我们需要对CI/CD说几句，因为它是GitOps运作的核心。CI/CD的持续集成部分是由像Git这样的版本控制库支持的:开发人员可以对他们的代码库进行持续的小改进，而不是每隔几个月或几年就推出一个巨大的、单一的新版本。连续部署部分是由称为管道的自动化系统实现的，这些系统构建、测试并将新代码部署到生产环境中。

　　同样，我们在这里一直在讨论代码，这通常会让人联想到用C、Java或JavaScript等编程语言编写的可执行代码。但在GitOps中，我们管理的“代码”主要是由配置文件组成的。这不仅仅是一个小细节——这是GitOps工作的核心。正如我们所说的，这些配置文件是描述我们的系统应该是什么样子的“真实的单一来源”。它们是陈述性的，而不是启发性的。这意味着配置文件不是说“启动10台服务器”，而是简单地说“这个系统包括10台服务器”。

　　GitOps等式的CI部分允许开发者快速地对这些配置文件进行调整和改进;当自动化软件代理尽其所能确保应用程序的活版本反映配置文件中的描述时，CD的一半就发生了——它用GitOps的语言聚合到声明式模型。

　　GitOps和Kubernetes

　　如前所述，GitOps的概念最初是围绕管理Kubernetes应用程序开发的。有了我们现在对GitOps的了解，让我们再来看看Weaveworks对GitOps的讨论。这里有一个总结:

　　1、开发人员为一个新特性发出一个Git pull请求。

　　2、代码会被审查和批准，然后合并到主代码库中。

　　3、合并将触发CI/CD管道，该管道将自动测试并重新构建新代码，并将其部署到注册表中。

　　4、软件代理注意到更新，从注册表中提取新代码，并更新配置存储库中的配置文件(用YAML编写)。

　　5、Kubernetes集群中的一个软件代理根据配置文件检测集群过期，提取更改并部署新特性。

　　Weaveworks和GitOps

　　显然，步骤4和步骤5是最重要的部分。神奇地将Git存储库中的“真相之源”与真实的Kubernetes应用程序同步的软件代理使GitOps成为可能。正如我们所说的，在GitOps术语中，使动态系统更像配置文件中描述的理想系统的过程称为收敛。(当动态系统和理想系统不同步时，就是发散。)理想情况下，融合可以通过自动化过程来实现，但是自动化所能做的是有限的，有时需要人工干预。

　　我们在这里用通用的术语描述了这个过程，但实际上，如果你真的去看Weaveworks的页面，我们提到的“软件代理”是该公司Weave云平台的一部分。“GitOps”一词是由Weaveworks首席执行官Alexis Richardson创造的，这在一定程度上是为了让Weaveworks平台吸引那些已经沉浸在devops和CI/CD世界的开发者。

　　但Weaveworks从未宣称垄断过GitOps，它更像是一种哲学和一套最佳实践，而不是一种特定的产品。正如CloudBees(一家提供CI/CD解决方案的公司)的博客所指出的，GitOps代表了一种开放的、与供应商无关的模型，这种模型是针对大型云供应商如亚马逊、谷歌和微软推出的托管专有Kubernetes解决方案而开发的。CloudBees提供了自己的GitOps解决方案，该领域的许多参与者也是如此。

　　GitOps和devops

　　Atlassian是一家为敏捷开发人员提供多种工具的公司，它有一篇关于GitOps历史和目的的深度博客，值得你花时间去了解。在他们看来，GitOps代表了devops中各种想法的逻辑延伸。具体地说，GitOps是对“基础设施即代码”概念的精化，它本身就是源自devops环境的一个想法。在Atlassian看来，GitOps填补了现有devops技术与分布式云托管应用程序之间的关键差距，后者已经发展到解决系统管理问题的程度。各种云供应商提供的自动融合正是GitOps的独特之处。

　　尽管GitOps今天仍然专注于Kubernetes，我们希望我们已经明确了它是如何应用于更广泛的分布式、基于云的应用的。开源安全厂商WhiteSource的一篇博客文章概述了GitOps的优势:

　　可观察性：GitOps系统提供对复杂应用程序的监视、日志记录、跟踪和可视化，这样开发人员就可以看到哪里出了问题。

　　版本控制和变更管理：显然，这是使用像Git这样的版本控制系统的一个关键好处。有缺陷的更新可以轻松回滚。

　　易于采用：GitOps建立在许多开发人员已经具备的devops技能之上。

　　生产力：GitOps提高了生产力，就像devops和CI/CD带给其他领域的生产力一样。

　　审计：由于有了Git，每个操作都可以跟踪到一个特定的提交，这使得跟踪错误的原因变得更加容易。

　　即使你不使用Kubernetes, GitOps迟早也会成为你工作流程的一部分。

　　来源： 新钛云服

  　　>>>>>>点击进入云计算专题