在过去的十年里,编程经历了许多革命性的变化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 / Gitops工作原理的核心是CD。CI / CD 持续集成是由Git等版本控制存储库实现的:开发人员可以不断改进其代码库,而不必每隔几个月或几年推出一个巨大的整体新版本。它通过自动化系统测试和部署新代码生产的连续部署件。
事实上,尽管我们一直在谈论代码,这通常是让我们想起团队C或Java或JavaScript等编程语言编写可执行代码的观点。但在Gitops中,我们管理“代码”主要由配置文件组成。这不仅仅是仅这是一个小细节,而是GitOps整个工作的核心。正如我们所说,这些配置文件描述了系统的外观“单一事实来源”。它们是声明性的,而不是指导性的。这意味着配置文件不会说“启动十台服务器”,而只会说“该系统包括10台服务器”。
CIIITOPS公式部分允许(持续集成)开发人员可以快速启动这些配置文件的调整和改进。当自动化软件代理尽可能确保应用程序的活版本反映配置文件中的描述时,CD(连续交付)部分就发生了—用将Gitops语言聚合到声明模型中。