GitOps 是 DevOps 中的下一件大事吗？
现在，许多组织将 DevOps 视为其数字化转型战略的一部分，因为它鼓励责任共担、透明和更快反馈的文化。然而，随着开发和运维团队之间的差距缩小，流程也在缩减。
Git 也是如此，它是当今世界上使用最广泛的版本控制系统。随着公司采用 DevOps 方法，工具也随之演变，GitOps 是一套允许开发人员执行更多与 IT 运维相关的任务的实践。
什么是 GitOps？
从核心上来讲，GitOps 是基于代码的基础架构和操作程序，依赖 Git 作为源代码控制系统。这是基础架构即代码 (IaC) 的演变，也是 DevOps 最佳实践，它利用 Git 作为单一数据源，以及创建、更新和删除系统架构的控制机制。更简单地说，这是使用 Git 拉取请求来验证和自动部署系统基础架构修改的实践。
除了 Git 作为关键的 DevOps 机制外，GitOps 还用于描述增强 Git 默认功能的工具。这些工具主要用于基于 Kubernetes 的基础架构和应用的操作模型。DevOps 社区正在开发和讨论将 GitOps 工具引入其他非 Kubernetes 平台，例如 Terraform。
GitOps 可根据 Git 存储库的状态确保系统的云基础架构立即可复制。拉取请求会修改 Git 存储库的状态。一旦批准并合并，拉取请求将自动重新配置实时基础架构并将其同步到存储库的状态。这种实时同步拉取请求工作流程是 GitOps 的核心精髓。
相关资料
Git 速查表
查看解决方案
了解 Bitbucket Cloud 的 Git
GitOps 的历史
Git 是一款用于软件开发的关键任务工具，支持拉取请求和代码审查工作流程。拉取请求可提高代码库传入变更的可见性，并鼓励针对变更进行沟通、讨论和审查。
拉取请求是协作软件开发中的关键功能，它改变了团队和企业构建软件的方式。拉取请求为以前不透明的流程带来了透明度和可衡量性。Git 拉取请求帮助将 DevOps 流程演变为软件开发。系统管理员通常对变更犹豫不决，而现在他们正在采用敏捷和 DevOps 等新的软件开发实践。
系统管理成为职业的历史可以说是相当草率。系统管理员以前需要通过连接和配置物理服务器机架中的计算机或通过云配置 API 来手动管理硬件。除了手动配置流程外，大量的手动配置工作也是常规例行程序。管理员将保留命令式脚本和配置的自定义集合，将它们拼凑在一起，然后将它们放在不同的地方。这些脚本随时可能中断或丢失。由于没有定期记录或共享自定义工具链，因此协作极具挑战性。
DevOps 运动源于这种原始的系统管理困境。DevOps 借鉴了软件工程的最佳创意，并将其应用于系统管理，在系统管理中，拼凑在一起的工具变成了版本控制代码。
IaC 是 DevOps 最大的发现之一。以前，系统管理员倾向于使用自定义命令式脚本来配置系统。命令式软件遵循一系列步骤来实现所需状态，例如：
命令式软件通常容易出错，并且很容易通过更改事件顺序而中断。现代软件开发已从命令式模式转向声明式软件模式。
声明式软件遵循预期状态的声明，而不是一系列命令。以下是命令式和声明式 DevOps 语句的比较。
虽然命令式陈述可能包括：
- 在这台计算机上安装操作系统
- 安装这些依赖关系
- 从此 URL 下载代码
- 将代码移至此目录
- 对另外 3 台机器执行此操作 3 次
它的声明式版本将简单地写成：4 台计算机有来自此 URL 的软件，安装在此目录中。
IaC 鼓励和推广声明式系统管理工具，而不是自定义命令式解决方案。这导致了 Docker 容器、Ansible、Terraform 和 Kubernetes 等技术的兴起，这些技术使用静态声明式配置文件。人类可读性和一致的可重复状态是有益的结果。这些配置文件自然被添加到 Git 中以进行跟踪和审查。这已经接近了，但不完全是 GitOps。
在 DevOps 历史上，许多传统的系统管理问题已经得到解决。配置文件和工具现在存储在中央位置，记录在案，可供许多团队成员访问。提交和拉取请求用于跟踪对配置的修改，促进协作讨论和审查。这个阶段唯一剩下的问题是配置仍然感觉与实时系统断开连接。配置提取请求获得批准并合并到代码存储库后，将手动更新实时系统以匹配静态代码存储库状态。这正是 GitOps 解决的问题。
GitOps 的想法最初是由企业 Kubernetes 管理公司 WeaveWorks 策划和分享的，此后在整个 DevOps 社区备受欢迎。GitOps 是上面讨论的 IaC 和声明式配置的扩展。GitOps 为拉取请求工作流程增添了一些魔力，该工作流程可将实时系统的状态与静态配置存储库的状态同步。
GitOps 的优势
GitOps 具有许多与敏捷功能分支软件开发工作流程相同的优势。第一个主要优势是由于使用了常用工具，因此易于采用。Git 是版本控制系统的事实标准，也是大多数开发人员和软件团队的常用软件开发工具。这使熟悉 Git 的开发人员可以轻松成为跨职能贡献者并参与 GitOps。
使用版本控制系统可以让团队跟踪对系统配置的所有修改。这提供了“数据源”和宝贵的审计线索，以便在出现意外情况时进行审查。团队可以查看 GitOps 历史记录并查看何时引入了回归。此外，此审计记录可用作合规性或安全审计的参考。修改或更新加密证书等内容时，GitOps 历史记录可用作证据。
GitOps 为组织围绕中央代码存储库的基础架构需求提供了透明度和清晰度。将所有系统配置包含在中央存储库中有助于扩大团队成员的贡献投入。通过 Bitbucket 等托管 Git 服务发出的拉取请求具有丰富的代码审查和讨论评论工具。这会建立被动通信回路，使整个工程团队能够观察和监控基础架构的变化。
GitOps 可以极大地提高 DevOps 团队的工作效率。它使他们能够快速尝试新的基础架构配置。如果新的变更未按预期运行，则团队可以使用 Git 历史记录将变更还原到已知的良好状态。这非常强大，因为它在复杂的基础架构中启用了熟悉的“撤销”功能。
GitOps 的工作原理
GitOps 程序由底层编排系统执行。GitOps 本身是一种不可知论的最佳实践模式。当今许多流行的 GitOps 解决方案主要使用 Kubernetes 作为编排系统。一些支持直接操作 Terraform 的替代 GitOps 工具集即将上市。
要实现完整的 GitOps 安装，需要一个管道平台。Jenkins、Bitbucket Pipelines 或 CircleCI 是一些流行的管道工具，它们是 GitOps 的补充。管道可自动执行并弥合 Git 拉取请求与编排系统之间的差距。建立管道钩子并通过拉取请求触发后，命令将执行到编排片段。
GitOps 专门引入的一种新模式或组件是 GitOps“运算符”，这是一种介于管道和编排系统之间的机制。拉取请求启动管道，然后触发运算符。运算符检查存储库的状态和编排的开始时间并进行同步。运算符是 GitOps 的神奇组件。
GitOps 示例
想象一下，一个团队发现了性能瓶颈或流量激增，而该团队发现负载均衡器未按预期运行。他们调查保存基础架构配置的 GitOps 代码存储库，并找到配置和部署负载均衡器的特定文件。他们可以在他们的在线 Git 托管网站上查看。经过一番审查和讨论后，他们发现负载均衡器的某些配置值不是最优的，需要进行调整。
团队成员打开了一个新的拉取请求，用于优化负载均衡器值。拉取请求由第二个团队成员审阅和批准，并合并到存储库中。合并会启动 GitOps 管道，这会触发 GitOps 运算符。运算符看到负载均衡器配置已变更。它通过系统编排工具证实这与团队集群上的实时数据不匹配。
运算符向编排系统发送信号以更新负载均衡器配置。其余工作由编排器处理，并自动部署新配置的负载均衡器。然后，该团队监视新更新的实时系统，以查看其恢复正常状态。这是一个理想的 GitOps 场景。我们进一步扩展一下，演示 GitOps 实用工具。
假设团队没有略微调整负载均衡器值以使其更优化，而是做出部署全新的负载均衡器类型的激进决定。他们认为当前的负载均衡器存在根本缺陷，他们想尝试其他选择。工作流程与值调整相同。该团队创建了一个拉取请求，该请求引入了全新的负载均衡器配置并删除了旧配置。它通过管道获得批准并进行部署。
不幸的是，该团队发现这种新型负载均衡器与其集群中的其他一些服务不兼容。新的负载均衡器会导致严重的流量故障和用户操作中断。幸运的是，由于团队拥有完整的 GitOps 管道，他们可以快速撤销这些负载均衡器变更。该团队将再次提出拉取请求，将存储库恢复到旧的已知功能负载均衡器。GitOps 管道将再次记录这一点，并自动部署。它将迅速改善基础架构，提高团队的可靠性得分。
摘要
GitOps 是一种非常强大的工作流程模式，用于管理现代云基础架构。尽管 DevOps 社区主要关注 Kubernetes 集群管理，但它正在向其他非 Kubernetes 系统应用和发布 GitOps 解决方案。GitOps 可以为工程团队带来许多好处，包括改善通信、可见性、稳定性和系统可靠性。GitOps 体验的核心要求之一是像 Bitbucket 这样的现代托管 Git 平台。
分享此文章
下一主题
推荐阅读
将这些资源加入书签，以了解 DevOps 团队的类型，或获取 Atlassian 关于 DevOps 的持续更新。
Bitbucket 博客
DevOps 学习路径
