DevOps扩展到K8S
版本控制系统中的代码是有关应用程序在生产中应该是什么样的事实的唯一来源
编程的最后十年经历了许多革命性的变化。其中之一来自围绕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也使其自身有可能实现更广泛的应用。但是，要了解GitOps的秘密之处及其解决的问题，我们需要讨论其中的组件。
Git定义
GitOps中的Git是指Linus Torvalds在2005年开发的广受欢迎的分布式版本控制系统。Git是一种工具，它使开发人员团队可以在应用程序代码库上一起工作，存储他们修改过的各种代码分支，然后再合并到其中。生产代码。Git中的一个关键概念是请求请求，在该请求中，开发人员正式要求他们一直在努力的一些代码，以将其集成到代码库中的另一个分支中。
推荐白皮书
Git拉取请求为团队成员提供了机会，在就是否应将新代码添加到应用程序达成共识之前进行协作和讨论。Git还存储了较旧的代码版本，这样可以在出现问题时轻松地退回到上一个好的版本，并让您快速查看不同版本之间的更改。Git可能最著名的是GitHub（云托管版本控制系统）的基础，但是Git本身是开源软件，可以部署在从内部公司服务器到PC的任何地方。
请注意，虽然我们通常将Git视为一种计算机编程工具，但实际上它与您将其用于什么内容无关。Git会很乐意将任何文本文件集视为您的“代码库”，例如，它可以被希望跟踪对协作作品的编辑的作家使用。这很重要，因为GitOps核心的许多代码库都由声明性配置文件而不是可执行代码组成。
在我们继续之前要说的最后一件事：尽管“ Git”的名称就在那里，但GitOps实际上并不需要使用Git。已经投资其他版本控制软件（例如Subversion）的商店也可以实现GitOps。但是Git在devops世界中广泛用于实现CI / CD，因此大多数GitOps项目最终都将使用Git。
CI / CD流程是什么？
对CI / CD的完整介绍不在本文的讨论范围之内（请参阅InfoWorld的解释器），但是我们需要对CI / CD谈几句话，因为它是GitOps工作原理的核心。CI / CD 的持续集成是由Git之类的版本控制存储库实现的：开发人员可以对其代码库进行不断的细微改进，而不必每隔几个月或几年就推出巨大的整体式新版本。的持续部署件通过自动化系统称为成为可能管线该构建，测试和部署新的代码来生产。
再说一次，我们在这里一直在谈论代码，通常这会唤起人们对用诸如C或Java或JavaScript这样的编程语言编写的可执行代码的看法。但是在GitOps中，我们管理的“代码”主要由配置文件组成。这不仅是一个小细节，而且是GitOps的核心。正如我们已经说过的，这些配置文件是描述系统外观的“单一事实来源”。它们是声明性的，而不是指导性的。这意味着配置文件不会说“启动十台服务器”，而只会说“该系统包括十台服务器”。
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首席执行官Alexis Richardson创造的，其部分目的是使Weaveworks平台吸引那些已经热衷于devop和CI / CD世界的开发人员。
但是Weaveworks从来没有宣称对GitOps的垄断，这不仅仅是特定产品，更是一种哲学和一套最佳实践。值得注意的是，作为提供CI / CD解决方案的公司CloudBees的博客，GitOps代表了一种开放的，与供应商无关的模型 ，该模型是为响应由Amazon，Google和Microsoft等大型云供应商推出的托管专有Kubernetes解决方案而开发的。 。CloudBees提供了自己的GitOps解决方案，该领域的许多参与者也是如此。
GitOps和devops
Atlassian是一家为敏捷开发人员提供大量工具的公司，其关于GitOps的历史和目的的深入博客文章值得您花时间。在他们看来，GitOps代表了作为开发者而来的想法的逻辑扩展。具体来说，GitOps是对基础设施即代码概念的详细说明，它本身就是从devops环境产生的想法。正如Atlassian所见，GitOps弥合了现有devops技术之间的重要鸿沟，该技术已发展为解决系统管理问题，并且与分布式云托管应用程序的特定需求有关。各种云供应商提供的自动融合使GitOps与众不同。
尽管GitOps今天仍然专注于Kubernetes，但我们希望我们已经阐明了它如何适用于更广泛的分布式，基于云的应用程序世界。一个博客帖子由开源安全厂商WhiteSource概述GitOps的优势：
可观察性：GitOps系统提供对复杂应用程序的监视，日志记录，跟踪和可视化，因此开发人员可以看到发生了什么事以及在哪里。
版本控制和变更管理：显然，这是使用版本控制系统（如Git）的主要好处。有缺陷的更新可以轻松回滚。
易于采用：GitOps建立在许多开发人员已经具备的devops技能的基础上。
生产力：GitOps可以提高devop和CI / CD带来的生产力。
审核：借助Git，可以将每个操作都跟踪到特定的提交，从而可以轻松地查找错误原因。
即使您不使用Kubernetes，GitOps迟早也有可能成为您工作流程的一部分。