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

本文转自Rancher Labs

在过去十年的编程中，出现了一些革命性的转变。其中之一是源于围绕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是 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... ），值得你花时间去了解。在他们看来，GitOps表明了做为devops的理念的逻辑延伸。具体来讲，GitOps是对基础架构即代码（IaC）这一律念的阐述，而基础架构自己就是DevOps环境下产生的一种思想。在Atlassian看来，GitOps弥补了现有DevOps技术与分布式、云托管应用的特殊需求之间的关键差距，现有DevOps技术是为了解决系统管理问题而发展起来的。各个云厂商提供的自动融合是GitOps的特别之处。

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

• 可观察性：GitOps系统为复杂的应用提供了监控、日志、跟踪和可视化功能，所以开发人员能够看到什么地方出现了故障，在哪里出现了故障。
• 版本控制和变动管理：很明显，这是使用Git这样的版本控制系统的一个关键优点。有缺陷的更新能够轻松回滚。
• 易于采用：GitOps创建在许多开发人员已经掌握的开发技能之上。
• 提升生产力：GitOps 能够像开发项目和 CI/CD 那样提升工做效率。
• 审计：有了Git，每个操做均可以追踪到一个特定的提交，这样就能够很容易地追踪到错误的缘由。

即便你不使用Kubernetes，GitOps也颇有可能早晚会成为你工做流程的一部分。