什么是 GitOps?好吧，GitOps 是一个软件开发框架，它使组织能够持续交付软件应用程序，同时使用 Git 作为单一事实来源有效地管理 IT 基础设施。GitOps 是 DevOps 的一个子集，它结合了基础架构即代码 (IaC) 和 DevOps 最佳实践，创建了一个操作模型，用于管理架构并根据 Git 存储库的状态即时复制系统的云基础架构。
虽然有多种软件开发工具和解决方案，但基础设施管理一直是一项复杂的任务。它需要专业知识来构建和维护基础设施。DevOps彻底改变了软件开发领域，并通过“基础架构即代码 (IaC)”方法增强了基础架构管理能力。
虽然 IaC 使开发人员能够将配置声明为代码并自动化系统基础架构，但在代码、测试、暂存和生产环境之间保持实时同步仍然是一个挑战。GitOps 扩展了 IaC 的功能，允许开发人员在 Git 中声明每个资源并在整个基础架构中自动维护所需的状态。继续阅读以了解有关 GitOps 的更多信息!
1. GitOps：它是一种版本控制方法吗?
版本控制系统在 DevOps 环境中起着至关重要的作用。VCS 是一种软件工具，使组织能够跟踪和管理代码更改。它将对代码所做的每一次更改都存储在一个唯一的数据库中。版本控制系统允许团队无缝协作进行代码开发，从而加快上市时间，同时最大限度地减少中断。当出现错误时，团队可以快速恢复到早期版本，而不会中断其他工作。GitOps 利用 Git VCS 来提高 CI/CD 管道的效率。
Git 是开发者圈子中最流行的版本控制系统。由于大多数开发人员都熟悉 Git，因此使用 GitOps 项目变得很容易。在 GitOps 环境中，Git 充当单一事实来源。环境中的每个资源都在 Git 存储库中进行了描述性声明。当发出 Git “拉取请求”并批准更改时，实时基础架构会自动重新配置，以与 Git 存储库中声明的所需状态同步。Flux 运算符用于监控 Git 拉取请求并将生产集群聚合到 Git 存储库的所需状态。
2. GitOps 原理
以下是 GitOps 的四个关键原则。
声明性描述
由于 Git 充当所有 DevOps 操作的单一事实来源，因此整个系统在 Git 中使用 .yaml 文件进行声明性描述。对应用程序、基础架构、部署和环境所做的更改都通过 Git 进行管理。例如，Kubernetes 配置和环境配置可以通过 Helm 通过可重用的图表进行管理。应用程序代码可以在 Dockerfile 中声明，Terraform 可以声明基础设施。不仅可以快速部署容器和回滚，还可以在灾难发生时重现整个集群基础设施。
版本控制
由于版本控制系统充当声明和管理基础架构所需状态的中央存储库，因此您可以试验新功能并在需要时快速回滚/恢复。提交时，会存储提交者信息、提交时间戳和提交 ID 等详细信息。因此，您可以完全跟踪在任何给定时间点对基础架构状态所做的所有更改。
查看整个变更审计跟踪的能力为组织中的团队带来了透明度。当基础设施和应用程序作为版本化的工件可用时，审计也变得容易。
自动化
声明式描述的优点是您可以在 Git 代码中声明系统所需的状态，然后自动化系统以将所有批准的更改应用到系统。通过实施集成到持续部署管道中的反馈控制循环，您可以自动化部署。虽然它显着增加了您每天所做的更改数量，但它也减少了平均部署时间。
保证
当所需状态与系统的实际状态不匹配时，软件代理会立即提醒您配置更改。使用这种自我修复方法，您可以放心获得高质量的软件开发环境。
3. GitOps 的需求
创新是技术世界的一个持续过程。云计算技术的出现彻底改变了 IT 行业，为软件开发环境带来了速度和规模。DevOps 使组织能够有效地管理这种敏捷性，并使用 CI/CD 管道、版本控制系统、代码审查系统和基础设施管理解决方案更快更好地无缝交付代码。然而，自动化更侧重于开发人员。
所有DevOps 实践都促进了开发过程的轻松自动化。然而，基础设施自动化仍然是一个复杂的过程，需要经过认证的专业人员和基础设施管理方面的专业知识。
现代基础设施应该足够灵活和健壮，以扩展和管理持续部署。虽然 Puppet、Chef 和 Ansible 等配置管理工具可帮助您将基础架构保持在所需状态，但它们不会将应用程序和 IaC 组合成一个有凝聚力的单元。此外，它们的效率不足以管理整个云堆栈。GitOps 正好适合这个目的。
GitOps 是一个创新的框架，允许开发人员将基础设施声明为 Git 存储库中的代码，并轻松集中管理基础设施自动化。 GitOps 通过将应用程序和基础设施即代码集成为一个有凝聚力的单元来扩展IaC 工具的功能，以便开发和运营团队共享一个 Git 存储库代码来管理在其上运行的基础设施和应用程序。
现在您已经了解了 GitOps，重要的是要了解它不仅仅是部署自动化和配置管理。它使开发人员能够轻松处理复杂的基础架构操作并提高生产力。借助回滚/还原功能和可操作的警报功能，它可以缩短恢复时间和上市时间。使用 GitOps，在云中管理 CI/CD 操作既简单又经济高效。
4. GitOps 是如何工作的?
GitOps 架构使开发人员能够使用 Git 作为唯一的事实来源来管理基础设施操作。在典型的 DevOps 开发环境中，CI 组件处于管道的最前沿。CI 组件将 VCS 视为为构建操作提供输入的服务，将 CD 视为用于部署代码的服务。它获取代码，运行自动化测试，并使用 CD 自动化将批准的代码推送到生产环境。
这是一个典型的 DevOps CI/CD 管道：
1. 开发者编写代码并提交到版本控制系统。
2. CI 服务器获取代码并在其上运行自动化测试。
3. 当发现错误/错误时，发送代码进行更正。
4. 审核通过的代码自动推送到容器镜像仓库。
5. 自动化部署工具将容器推送到生产环境。
6.容器编排工具用于管理容器。
在这里，CI 组件是 CI/CD 管道的核心。但是，GitOps 将版本控制系统 Git 推到了中心。在这个架构中，Git 无缝地管理部署和操作。由于开发人员最熟悉 Git 和拉取请求，因此使用 GitOps 变得很容易。拉取请求是审查请求，其中将代码推送到存储库的开发人员请求批准将代码与存储库合并。
这是 GitOps 环境中的典型工作流程：
1. 开发人员向 Git 存储库发出拉取请求。
2. 代码由相关人员审核通过。
3. 然后将代码合并到 Git 存储库中。
4. 当检测到更改时，触发 CI 构建管道。CI 工具会自动运行测试。一旦代码通过了所有测试，它就会构建镜像并将其推送到镜像容器中。
5. 部署 Automator 检测到映像存储库的更改，从注册表中拉取它，并更新配置存储库 YAML 文件。
6. 部署同步器检测集群中的变化。它从配置存储库中提取更改并使用新功能更新过时的集群。
考虑一个使用Kubernetes集群和 Flux CD 来管理 Kubernetes 的 GitOps 环境。Kubernetes 集群的状态首先在 Git 存储库中声明。没有事先声明，没有工作负载进入 Kubernetes 集群。声明工作负载描述并将其推送到 Git 存储库。部署的集群状态应始终与 Git 中声明的状态同步。Flux 作为部署同步器运行。它部署在 Kubernetes 中，并使用控制循环来拉取 git 存储库并检查是否推送了任何新提交。当应用新的提交时，它会立即将集群状态收敛到新声明的状态。
此外，Flux 还会检查容器镜像注册表是否有更新。当找到新镜像时，Flux 将使用最新的容器镜像标签更新 Git 上的集群清单文件，然后将集群状态与最新的提交重新同步。这意味着容器实例始终使用最新的容器映像运行。它还确保集群状态始终与 Git 存储库中的声明完美同步。如果您需要回滚某个功能，您可以简单地使用 Git repo 恢复到早期版本，Flux 会自动将集群状态同步到该版本。同样，在灾难期间，您可以简单地重新部署 Git 存储库中的最新提交，以恢复上次工作的集群状态。
使用 GitOps，您无需向开发人员提供写入权限。相反，Flux 将根据 Git 存储库声明更新、删除或创建集群内的资源。通过实施基于角色的访问控制 (RBAC)，您可以为 Flux 服务帐户配置所需的权限并执行所需的操作，而无需将集群凭据暴露在外部。
5. GitOps 的优势
以下是 GitOps 提供的一些关键优势。
更快的上市时间
在 DevOps 环境中，更快的部署是默认要求。然而，GitOps 将其提升到一个新的水平，因为部署发生在源代码中。随着代码的开发和推送到 Git，它会使用相同的部署工具自动部署。您不必切换工具这一事实使此过程更快更好。
可靠性
GitOps 允许您通过单击按钮来还原/回滚更改。您可以快速试验新功能并在代码出现意外行为时撤消它们。它还提高了生产力水平，同时可靠和安全。
改进的开发人员体验
GitOps 更加关注开发人员。借助 Git 等开发人员端工具的使用，开发人员可以很好地控制部署基础架构，并且可以轻松管理和监控部署。持续的反馈循环帮助他们更频繁地识别错误、进行更改并将代码推送到生产环境。他们可以在整个基础架构中使用一组工具。
轻松审核
在 GitOps 环境中，每个更改都是通过存储库进行的。因此，您可以在任何给定时间点检查分支历史记录，以查看完整的部署历史记录以及对代码所做的每次更改的历史记录。免费的审计跟踪功能从本质上简化了审计任务。此外，每个团队成员都可以检查 Git 存储库并了解整个开发生命周期中发生的情况。它还使您的审计任务变得容易。
跨基础架构的标准化操作
GitOps 使您能够为跨应用程序、部署和附加组件的变更管理创建标准模型。这意味着您拥有以 Git 为中心的端到端工作流程，这些工作流程在整个基础架构中都是一致的。它还提供了对 CI/CD 管道的更大可见性。
6. GitOps 最佳实践
尽管 GitOps 为开发环境提供了速度和规模，但使用正确的策略是利用该框架的关键。
管理回购
首先，传统的开发团队使用多个存储库来获得他们正在开发的服务的明确所有权。但是，当项目规模扩大时，它会变得复杂。每个团队只能监控其存储库，并且获得对整个项目的可见性变得令人生畏。因此，最小化存储库是一个好主意。对于小公司来说，一个 repo 就足够了。中型公司可以为每个团队使用一个 repo，而大型企业可以为每个服务使用一个 repo。每个团队可以使用一个存储库，然后在需要时向其中添加多个分支。这意味着团队可以在项目上无缝协作。
关于存储库的另一个好主意是使用两个——一个用于应用程序代码，另一个用于部署配置。这意味着不会部署每个提交，并且每个人都无法释放。这也意味着您可以控制谁可以拥有更好的发布管理流程。
管理清单
当您提交对清单的更改而不对其进行测试时，您很可能会在预生产阶段遇到几个问题。一个好主意是在提交更改之前在本地运行 CLI 命令以生成清单。您还应该确保外部修改不会更改 Git 清单。因此，将远程基础或依赖项固定到特定提交。
管理有状态的应用程序和服务
在 Kubernetes 中管理有状态的应用程序和服务是一项繁琐的任务。建议尽可能使用 Kubernetes 运算符，而不是使用手动脚本。强烈建议使用拉取请求而不是推送。它还将避免在集群外暴露集群凭据。您可以使用 Git webhook 自动执行整个环境中的重复过程。
7. 使用 GitOps 持续交付
持续交付是一种软件开发方法，其中代码不断构建、测试并部署到生产中。跨职能团队使用版本控制系统协作开发应用程序。每个更改都经常与分支合并。对于每次更改，都会创建一个构建，在该构建上执行自动化测试。成功的构建将自动部署到生产环境。
一开始，GitOps 似乎为持续部署提供了优于持续集成的优势。但是，GitOps 使 CD 变得简单高效，从而使 CI 能够更快更好地交付。在传统的 CI/CD 管道中，CI 处于中心位置并管理构建和部署。虽然 CI 经常将代码发布到生产环境，但将配置与其同步是一项挑战。混合多方面基础设施的存在加剧了这一挑战。
GitOps 描述性地声明存储库中每个资源的状态。因此，对应用程序代码和清单的更改会立即反映在生产集群中。它提供了可见性和洞察力，以确保所有生产环境的一致性。通过保证生产集群状态的可预测性和一致性，开发人员可以快速构建应用程序并将其部署到多集群基础设施，同时获得对移动到生产环境的代码所做的每一次更改的可追溯性和可见性。使用 GitOps，CI 变得更快、更舒适、更好。
8. 使用 GitOps 的基础设施即代码
基础架构即代码是一种使用配置文件进行 IT 基础架构管理的创新理念。GitOps 是 IaC 的一个很好的例子，但它在实现上有所不同。它扩展了 IaC 工具的功能。在 GitOps 中，IT 基础架构的所需状态由源代码控制存储和控制。在这里，不可变容器用作可部署的工件，并使用编排工具将它们聚合到 Git 清单中声明的状态。Git 充当中央数据源，而其他 IaC 框架使用多个存储库或 git 和数据库的组合来管理基础架构。
虽然 IaC 工具使您能够管理 IT 基础架构，但它们不足以控制整个云原生堆栈。但是，GitOps 足以处理整个云原生堆栈。您可以使用 IaC 工具并扩展其功能以使用 Git 执行基础架构更新。当清单更新时，Kubernetes 操作员触发收敛机制，其中更改应用于集群，直到状态收敛到 Git 中声明的状态。当检测到分歧时，它将自动发送警报。您可以配置算子自动触发收敛机制。
9. GitOps 工具
以下是一些使您能够构建结果驱动的 GitOps 环境的工具。
吉特
Git 是 GitOps 环境的核心。它托管代码、配置和文档，以跨基础架构部署和管理集群。整个过程是自动化的，其中“自动化者”读取 Git 存储库，检测 Git 中代码和配置的更改，并将它们应用到基础设施中的相应集群。
舵
Helm 是一个流行的 Kubernetes 包管理器。它使组织能够使用 Helm Charts 定义和安装完整的 Kubernetes 应用程序。通过自定义挂钩和就地升级，您也可以轻松更新 Kubernetes 应用程序。Helm 图表包含排列成特定目录结构的 YAML 模板文件。使用 Helm，您可以优化 Kubernetes 的 CI/CD 环境。
通量
Flux 是 GitOps 中的另一个关键操作符，可确保 Git 存储库配置在生产集群上自动实施。它不断读取 Git Repos 并检测代码和配置文件的更改，并将 Kubernetes 生产集群聚合到 Git 中声明的所需状态。Flux 帮助您将容器镜像无缝部署到生产集群。对集群的更改可以轻松恢复到以前的版本。
标志
Flagger 是一个流行的 Kubernetes 渐进式交付运营商。使用诸如金丝雀发布、A/B 测试和蓝/绿等 Flagger 渐进式交付技术，开发人员可以自信地将代码推送到生产环境。金丝雀版本允许开发人员在生产环境中测试新功能，并在需要时安全回滚。随着负载缓慢上升，开发人员可以监控关键性能指标并评估新功能对生产环境的影响。使用 Flagger 和 FluxCD，您可以轻松构建用于金丝雀部署的自动化 GitOps 管道。
10. 总结
在回顾了 GitOps 是什么之后，我们可以得出结论，随着多种技术、工具和框架的涌入，现代云基础设施日益复杂。GitOps 提供了强大的操作流程来管理这个复杂的云系统基础设施。在确保实时生产集群始终以所需状态运行的情况下，组织可以奢侈地整合新功能以提供出色的客户体验、提高生产力并减少中断。
然而，GitOps 仍处于初级阶段。虽然 GitOps 支持 Kubernetes 和非 Kubernetes 集群，但大多数 GitOps 操作员旨在管理 Kubernetes 集群。展望未来，您可以期望 GitOps 操作员跨基础设施管理所有类型的集群。
