GitOps详解

编程在最近的十年来经历了许多革命性的变化，围绕devop的一系列实践将开发和运营团队整合到一个共享的工作流程中，并实现了持续集成和持续交付（CI / CD），devops团队向代码库提供了不断增量的更新。另一种巨大的转变是从单块代码库到运行在由编排平台（如Kubernetes）管理的容器中的基于云的微服务。在集群系统或云中运行的基于容器的应用程序可能很复杂，并且即使使用像Kubernetes这样的平台来编排事物，也很难对其进行配置和管理。GitOps是一组新兴的实践技术，旨在通过应用devops和CI / CD领域的技术来简化此管理任务。
GitOps的关键是将基础架构作为代码的思想，它采用与devops用来配置应用程序相同的方式来配置基础结构。因此，不仅在文件中描述了应用程序，而且在底层主机和网络中也描述了文件，这些文件可以视为版本控制系统中的任何其他代码，然后使用自动化过程将实际应用程序与那些文件。
用GitOps的话来说，版本控制系统中的代码是有关应用程序在生产中应该是什么样的事实的唯一来源。GitOps是Kubernetes和其他云原生技术的操作模型，提供了一组最佳实践，这些最佳实践统一了容器化集群和应用程序的部署，管理和监视。它是通往开发人员管理应用程序体验的途径；端到端CI / CD管道和Git工作流同时应用于运营和开发。
换句话说，GitOps是一组专门用于管理Kubernetes和类似平台的实践，随着越来越多的开发商店采用devops实践并将代码迁移到云中，GitOps还可使其更广泛的应用。但是，要了解GitOps的秘密之处及其解决的问题，我们需要谈论其中的组件。其核心组件无疑是Git。
GitOps中的Git是指Linus Torvalds在2005年开发的广受欢迎的分布式版本控制系统。Git是一种工具，它使开发人员团队可以在应用程序代码库上一起工作，在将它们合并到一起之前，存储需要修改的各种代码分支生并产代码。Git中的一个关键概念就是pull request，即自己修改源代码后请求对方采纳的一种请求，开发人员提出请求采纳他们修改的一些代码，以集成到代码库中的另一个分支中。通过这个功能，你可以参与到别人开发的项目中，并做出自己的贡献。
Git拉取请求为团队成员提供了机会，在就是否应将新代码添加到应用程序达成共识之前进行协作和讨论。Git还存储了较旧的代码版本，这样可以在出现问题时轻松地退回到上一个好的版本，并快速查看不同版本之间的更改。Git最著名的可能就是GitHub（云托管版本控制系统）的基础，但Git本身是开源软件，可以部署在从内部公司服务器到PC的任何地方。
请注意，尽管我们通常将Git视为一种计算机编程工具，但实际上它与你将其用于什么内容无关。Git会很乐意将任何文本文件集都视为“代码库”，例如，它可以被希望跟踪对协作作品的编辑的作者使用。这一点很至关重要，因为GitOps核心的大部分代码库都由声明性配置文件而不是可执行代码组成。
在我们继续之前要说的最后一件事：尽管“ Git”的名称就在那里，但是GitOps实际上并不需要使用Git。已经投资了其他版本控制软件（例如Subversion）的商店也可以实现GitOps。但是Git在devops世界中广泛用于实现CI / CD，因此大多数GitOps项目最终都将使用Git。
CI / CD是GitOps工作原理的核心。CI / CD 的持续集成是由Git之类的版本控制存储库实现的：开发人员可以对其代码库进行不断的细微改进，而不必每隔几个月或几年就推出巨大的整体式新版本。它的持续部署件通过自动化系统测试和部署新的代码来生产。
事实上，尽管我们一直在谈论代码，这通常会使我们联想起队C或Java或JavaScript之类的编程语言编写的可执行代码的看法。但是在GitOps中，我们管理的“代码”主要由配置文件组成。这不仅仅是一个小细节，而是GitOps整个工作的核心。正如我们已经说过的，这些配置文件是描述系统外观的“单一事实来源”。它们是声明性的，而不是指导性的。这意味着配置文件不会说“启动十台服务器”，而只会说“该系统包括十台服务器”。
GitOps公式的CI（持续集成）部分允许开发人员可以快速推出对这些配置文件的调整和改进。当自动化软件代理尽其所能确保应用程序的活版本反映配置文件中的描述时，CD（持续交付）部分就发生了—用GitOps语言聚合到声明式模型。