GitOps初阶指南：将DevOps扩展至K8S

文章来源：RancherLabs / 原文链接

在过去十年的编程中，出现了一些革命性的转变。其中之一是源于围绕DevOps的实践，它将开发和运维团队整合到一个共享的工作流程中，此外还有持续集成和持续交付（CI/CD），通过CI/CD，Devops团队可以向代码库提供持续的更新。另一个变革来自于从单体代码库到基于云的微服务的迁移，这些微服务运行在由Kubernetes等编排平台管理的容器中。

即使有Kubernetes这样的平台来编排协调，在集群系统或云端运行的基于容器的应用程序依旧可能是复杂的、难以调配和管理的。GitOps是一套新兴的实践，旨在通过应用Devops和CI/CD世界的技术来简化这一管理任务。

GitOps的关键是基础设施即代码（IaC）的理念，它采用与DevOps用于提供应用程序一样的方法来提供基础设施。所以，不仅是应用，还有底层的主机和网络都被描述在文件中，这些文件可以像版本控制系统中的其他代码一样，然后由自动化流程来将现实世界的应用与这些文件中描述的应用进行融合。

用GitOps的说法，版本控制系统中的代码是关于应用在生产中应该是什么样子的唯一真相来源（single source of truth）。

定义GitOps

Weaveworks是在GitOps概念普及方面贡献最大的公司。稍后我们会详细介绍Weaveworks在其中扮演的角色，但首先，我们先来看看该公司对GitOps的定义，它有两个方面：

Kubernetes和其他云原生技术的运维模式，为统一部署、管理和监控容器化集群和应用提供了一套最佳实践。
GitOps是一条通往管理应用的开发者体验之路；在这里，端到端的CI/CD流水线和Git workflow可以同时应用于运维和开发。

换句话说，GitOps是一套特定的实践，旨在管理Kubernetes和类似的平台。随着越来越多的开发团队采用DevOps实践，并将代码迁移到云端，GitOps也将会适合更广泛的应用。但要了解GitOps的秘诀和它所能解决的问题，我们需要谈谈它的组成部分。

Git定义

在GitOps中Git指的是由Linus Torvalds在2005年开发的极为流行的分布式版本控制系统。Git是一个工具，它允许开发者团队在一个应用程序代码库上共同工作，存储各种代码分支，在将它们合并到生产代码之前，他们可以对这些代码进行修补。Git 的一个关键概念是拉取请求，即开发人员正式要求将他们正在编写的一些代码整合到代码库的另一个分支中。

Git 拉取请求为团队成员提供了一个协作和讨论的机会，然后再就是否应该将新代码添加到应用程序中达成共识。Git 还会存储旧版本的代码，如果出了问题，可以很容易地回滚到上一个好的版本，并可以让你快速查看两次修改之间的变化。Git 最为人所知的部分可能是作为GitHub 这一云端托管版本控制系统的底层，但 Git 本身也是一个开源软件，可以部署在任何地方，无论是公司内部的服务器还是你的PC。

需要注意的是，虽然我们通常认为Git是一个计算机编程工具，但实际上取决于你如何使用它。Git 很乐意将任何文本文件作为你的 “代码库”，例如，它可以被作者用来记录合作作品的编辑情况。这一点很重要，因为GitOps的核心代码库大多由声明式配置文件而非可执行代码组成。

在我们继续之前，最后要强调一件事——尽管名字中就有 “Git”，但GitOps实际上并不必要使用Git。已经投入使用其他版本控制软件（如Subversion）的团队也可以实现GitOps。但在Devops领域，Git被广泛用于实现CI/CD，所以大多数GitOps项目最终都会使用Git。

什么是CI/CD流程？

关于CI/CD的完整解释其实不在本文讨论的范围内，如果你想充分了解什么是CI/CD可以在公众号后台回复关键词【CI/CD】获得系列文章。但是因为CI/CD是 GitOps 工作的核心，因此我们需要对其进行简单的介绍。CI/CD中的一半持续集成是由版本控制仓库（如Git）实现的。开发者可以对代码库进行持续的小改进，而不是每隔几个月或几年就推出巨大的、单一的新版本。持续部署这一块是通过被称为流水线（pipeline）的自动化系统来实现的，这些流水线可以构建、测试和部署新的代码到生产中。

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

GitOps方程中的CI那一半允许开发人员快速推出对这些配置文件的调整和改进；当自动化软件代理竭尽全力确保应用程序的实时版本能够反映配置文件中的描述时，CD这一部分会以GitOps语言趋向于声明式模型。

GitOps和Kubernetes

正如我们所提到的，GitOps的概念最初是围绕管理Kubernetes应用而出现的。通过我们现在对GitOps的了解，让我们重温一下Weaveworks的GitOps讨论，看看他们是如何描述如何对基于GitOps原则管理的Kubernetes进行更新的。下面是对整个流程的总结：

一个开发者为一个新功能提出Git 拉取请求。
审查和批准代码，然后将其合并到主代码库中。
合并会触发 CI/CD 流水线、自动测试和重建新代码，并将其部署到仓库。
软件代理注意到更新，从仓库中提取新代码，并更新配置仓库中的配置文件（用YAML编写）。
Kubernetes集群中的软件代理根据配置文件，检测到集群已经过时，拉取更改，并部署新功能。

Weaveworks和GitOps

显然，这里的第4步和第5步做了很多繁重的工作。将Git仓库中的 "真理来源 "与现实世界中的Kubernetes应用进行神奇同步的软件代理，就是让GitOps成为可能的魔法。正如我们所说，在GitOps术语中，让实时系统更像配置文件中描述的理想系统的过程叫做融合。当实时系统和理想系统不同步时，那就是分歧。理想情况下，融合可以通过自动化流程来实现，但自动化所能做的事情是有限度的，有时人工干预是必要的。

我们在这里用通用术语描述了这个过程，但事实上，如果你真的去看Weaveworks的页面，我们提到的 “软件代理” 是该公司Weave Cloud平台的一部分。“GitOps” 这个词是由Weaveworks的CEO Alexis Richardson创造的，它的部分作用是让Weaveworks平台对已经沉浸在DevOps和CI/CD世界的开发者有吸引力。

但Weaveworks从未宣称自己垄断了GitOps，GitOps更多的是一种理念和一套最佳实践，而不是某种具体的产品。正如提供CI/CD解决方案的公司CloudBees的博客所指出的那样，GitOps代表了一种开放的、厂商中立的模式，它是针对亚马逊、谷歌和微软等大型云厂商推出的管理型专有Kubernetes解决方案而开发的。CloudBees提供了自己的GitOps解决方案，这个领域的另一些玩家也是如此。

GitOps和DevOps

Atlassian是一家为敏捷开发者制造了许多工具的公司，它有一篇关于GitOps的历史和目的的深度博文（https://www.atlassian.com/git/tutorials/gitops），值得你花时间去了解。在他们看来，GitOps代表了作为devops的理念的逻辑延伸**。具体来说，GitOps是对基础架构即代码（IaC）这一概念的阐述，而基础架构本身就是DevOps环境下产生的一种思想。**在Atlassian看来，GitOps弥补了现有DevOps技术与分布式、云托管应用的特殊需求之间的关键差距，现有DevOps技术是为了解决系统管理问题而发展起来的。各个云厂商提供的自动融合是GitOps的特别之处。

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