我们的团队使用
GitLab+Kubernetes+ArgoCD的组合实现GitOps，取得了很好的实践效果。
如今，许多组织将DevOps视为其数字化转型战略的一部分，因为它鼓励一种责任共享、高度透明和快速反馈的文化。随着开发团队和运营团队之间的鸿沟缩小，流程也随之简化。
Git，当今世界上最为广泛使用的版本控制系统，也遵循着这一趋势。随着企业采纳DevOps方法论，相关的工具也经历了变革，进而发展出了GitOps。GitOps是一套实践方法，它允许开发人员执行更多与IT运营相关的任务。
什么是GitOps
GitOps的核心是基于代码的基础设施和操作流程，它依赖Git作为源代码控制系统。它是基础设施即代码（IaC）的演进，也是DevOps的最佳实践，它利用Git作为系统架构创建、更新和删除的唯一来源和控制机制。更简单地说，它是使用Git拉取请求来验证和自动部署系统基础设施修改的实践。
除了Git作为关键的DevOps机制外，GitOps还用于描述增强Git默认功能的工具。这些工具最初主要与基于Kubernetes的基础设施和应用程序的操作模型一起使用。DevOps社区内正在进行持续的开发和讨论，以便将GitOps工具引入其他非Kubernetes平台，例如Terraform。
GitOps确保系统的部署状态可以根据Git仓库的状态实时变更。拉取请求会修改Git仓库的状态。一旦请求得到批准并合并，它将自动重新配置并部署现网设施以与代码仓库的状态保持同步。这种实时同步的拉取请求工作流程是GitOps的核心本质。
GitOps的发展史
Git是软件开发中至关重要的工具，它支持拉取请求和代码审查工作流程。拉取请求提高了对代码库即将发生更改的可见性，并鼓励对更改进行沟通、讨论和审查。
拉取请求是协作式软件开发中的关键功能，改变了团队和企业构建软件的方式。拉取请求为之前不透明的过程带来了透明度和可衡量性。Git拉取请求帮助推动了DevOps过程向软件开发的演进。通常对改变持谨慎态度的系统管理员现在正在接纳新的软件开发实践，如敏捷开发和DevOps。
系统管理作为一门技术，历史上并不那么整洁。系统管理员以前会手动管理硬件，要么通过连接到物理服务器机架中的机器并进行配置，要么通过云配置API进行配置。除了手动配置过程外，大量的手动配置工作也是常规任务。管理员会保留自定义的命令脚本和配置集合，将它们拼凑在一起，并放在不同的地方。这些脚本随时可能崩溃或丢失。由于自定义工具链没有定期记录或共享，因此协作具有挑战性。
DevOps运动起源于这个原始的系统管理领域。DevOps从软件工程中借鉴了最好的想法，并将它们应用于系统管理，将那些拼凑起来的工具变成了版本控制的代码。
IaC是DevOps的最大启示之一。之前，系统管理员更喜欢使用自定义的命令式脚本来配置系统。命令式软件遵循一系列步骤来实现所需的状态，命令式软件往往容易出错，并且很容易因为事件顺序的改变遭到破坏。
现代软件开发已经逐渐摒弃命令式模式，转向声明式软件模式。声明式软件遵循对预期状态的声明，而不是命令序列。下面是命令式与声明式DevOps语句的对比：
命令式语句可能如下所示：
- 在这台机器上安装操作系统
- 安装这些依赖项
- 从这个URL下载代码
- 将代码移动到这个目录
- 对另外三台机器重复上述操作三次
而声明式版本则简洁地表示为：
- 四台机器从该URL获取软件，并安装在此目录下。
IaC鼓励和推广声明式系统管理工具，而不是自定义的命令式解决方案。这导致了Docker容器、Ansible、Terraform和Kubernetes等技术的出现，它们利用静态声明式配置文件。可读性和一致的可重现状态是这些技术带来的好处。这些配置文件自然地被添加到Git中进行跟踪和审查。但这只是接近GitOps，而不是真正的GitOps。
在DevOps历史发展的这个阶段，许多传统的系统管理问题已经得到解决。配置文件和工具现在存储在中央位置，由许多团队成员记录和访问。使用提交和拉取请求来跟踪配置的修改，并促进协作讨论和审查。这个阶段唯一剩下的问题是配置仍然感觉与实时系统脱节。一旦配置拉取请求被批准并合并到仓库中，实时系统需要手动更新以匹配静态仓库的状态。这正是GitOps要解决的问题。
GitOps的想法最初由WeaveWorks提出并分享，WeaveWorks是一家企业级Kubernetes管理公司，自此GitOps的理念在DevOps社区中得到了广泛传播。GitOps是上述讨论的IaC和声明式配置的扩展。GitOps为拉取请求工作流程添加了一些优秀的能力，将实时系统的状态与静态配置仓库的状态同步。
使用GitOps的好处
GitOps与敏捷开发有许多相同的优势。其首要优势在于采用通用工具的便利性。Git作为版本控制系统的公认标准，是大多数开发人员和软件团队的常用开发工具。这使得熟悉Git的开发者能够轻松地成为跨职能贡献者，参与到GitOps中。
使用版本控制系统可以让团队跟踪系统配置的所有修改。这提供了一个“事实来源”和有价值的审计轨迹，以便在出现问题或行为异常时进行审查。团队可以查看GitOps的历史记录，确定何时引入了回归问题。此外，这个审计轨迹还可以用作合规性或安全性审计的参考。例如，当加密证书被修改或更新时，GitOps历史记录可以用作证明。
GitOps为组织的基础设施需求带来了透明度和清晰度，这些需求围绕一个中央仓库展开。将所有系统配置包含在中央仓库中有助于扩大团队成员的贡献输入。通过托管Git服务（如Bitbucket）提交的拉取请求提供了丰富的代码审查和讨论注释工具。这构建了一个被动的沟通循环，使得整个工程团队能够观察和监控基础设施的变更。
GitOps可以大大提高DevOps团队的生产力。它允许团队快速试验新的基础设施配置。如果新变更的行为不符合预期，团队可以使用Git历史记录将变更回滚到已知的良好状态。这是非常强大的功能，因为它在复杂的基础设施中启用了熟悉的“撤销”功能。
GitOps的工作原理
GitOps流程由底层的编排系统执行。GitOps本身是一种与具体技术无关的最佳实践模式。如今许多流行的GitOps解决方案主要使用Kubernetes作为编排系统。同时，市场上也出现了一些支持直接Terraform操作的替代GitOps工具集。
要实现完整的GitOps安装，需要一个管道平台。Jenkins、Bitbucket Pipelines或CircleCi等是与GitOps相辅相成的流行管道工具。这些管道可以自动化并弥合Git拉取请求与编排系统之间的鸿沟。一旦建立了管道钩子并从拉取请求中触发，就会向编排组件执行命令。
GitOps中特别引入的一个新模式或组件是GitOps“操作符”。它是一种位于管道和编排系统之间的机制。一个拉取请求会启动管道，进而触发操作符。操作符检查仓库的状态并启动编排，以将它们进行同步。操作符是GitOps中的关键组件。
GitOps应用案例
设想一个团队识别到了一个性能瓶颈或流量激增的问题，并注意到负载均衡器没有按预期工作。他们查看存储基础设施配置的GitOps仓库，找到配置和部署负载均衡器的特定文件。经过一些审查和讨论，他们发现负载均衡器的一些配置值不够优化，需要进行调整。
团队的一名成员打开了一个新的拉取请求，用于优化负载均衡器的值。该拉取请求经过第二名团队成员的审查和批准后，合并到仓库中。合并操作触发了GitOps管道，进而触发了GitOps操作符。操作符发现负载均衡器的配置已更改。它通过与系统编排工具的确认，发现这与团队集群上实时运行的状态不匹配。
操作符指示编排系统更新负载均衡器的配置。编排器处理剩余的工作，并自动部署新配置的负载均衡器。然后，团队监控新更新的实时系统，以确保其恢复到健康状态。这是一个理想的GitOps场景。让我们进一步扩展这个场景，以展示GitOps的实用性。
想象一下，团队不再只是对负载均衡器的值进行微调以使其更优化，而是做出了一个大胆的决定，即部署一种全新的负载均衡器类型。他们认为当前的负载均衡器存在根本性的问题，并希望尝试一个替代方案。工作流程与之前的配置值调整相同。团队创建了一个拉取请求，该请求引入了全新的负载均衡器配置并删除了旧的配置。经过批准后，该更改通过管道进行了部署。
不幸的是，团队发现这种新型的负载均衡器与集群中的其他服务不兼容。新的负载均衡器导致关键流量失败，并中断了用户操作。幸运的是，由于团队拥有完整的GitOps管道，他们可以迅速撤销这些负载均衡器更改。
团队将创建另一个拉取请求，将仓库回滚到已知且功能正常的旧负载均衡器配置。这个更改同样会被GitOps管道注意到，并自动进行部署。这将迅速恢复故障基础设施，并提高团队的可靠性。
总结
GitOps是一种极其强大的工作流程模式，用于管理现代云基础设施。尽管它主要关注Kubernetes集群管理，但DevOps社区正在将GitOps解决方案应用于其他非Kubernetes系统，并发布相关实践。GitOps可以给工程团队带来诸多好处，包括提高沟通效率、增强可见性、提升稳定性以及系统可靠性。实现GitOps体验的核心要求之一是拥有一个托管的Git平台，比如Bitbucket。
