GitOps 简介

GitOps 简介

在本系列文章中，我们将解释一些 GitOps 理论，然后深入探讨使用 Terraform、Azure 和 GitHub 进行实践。我们将首先了解 GitOps——它的起源、它到底是什么，以及它如何与基础设施即代码 (IaC) 术语以及持续集成 (CI) 和持续部署 (CD) 的管道概念相关联。

在本文中，我们将回顾软件工程实践的历史以及它们如何促成 GitOps 的演变。

曾经，有瀑布模型

很长一段时间，软件都采用瀑布方法开发——这种方法将整个软件开发生命周期作为一个单一的、大型的工作单元完成。在这种模型中，客户第一次使用软件是在发布日。由于周期如此之长，开发团队需要很长时间才能获得反馈并有机会发布新版本。

这对于当时可用的软件分发方法来说运行良好——更短的周期是不切实际的。这种工作方式为运营团队提供了充足的时间来为发布日配置基础设施。

然后，敏捷方法出现了

可以说，在软件开发中采用敏捷方法的主要好处是，可以进行更小的更改并更频繁地发布——这得益于新分发方法（摆脱实体媒介）的普及。

这种方法确实能够更快地发布代码，但运营团队使用的工具和实践有时无法支持增加的变更频率。

DevOps 成为一种趋势

这是 DevOps 演变的一个原因——旨在推动一种开发人员和运营团队更紧密协作的文化。通过协作，他们能够自动化构建、测试和部署，以支持敏捷带来的更快的发布节奏。

然而，应用程序的规模和复杂性不断增长，系统由大量的微服务构建而成——并且这些系统的需求也在增长。因此，基础设施解决方案需要能够动态扩展和减少基础设施资源以响应负载。这正是云非常擅长的事情。

开发人员从与运营团队的密切合作中受益匪浅，但所有由此产生的云服务管理起来都很复杂。而且，使用旧方法，很容易忘记我们拥有哪些基础设施、我们需要哪些基础设施，以及两者是否匹配。

然后，有了 GitOps

事后看来，这似乎很明显。为了使运营活动跟上开发人员的节奏，他们应该采用与应用程序开发相同的 DevOps 最佳实践，并将其应用于自动化基础设施配置。

这种方法的核心是 Git 源代码控制，它被用作当前部署基础设施的单一真相来源。在此之上，我们有三个核心组件：IaC（基础设施即代码）、拉取请求和 CI/CD。

基础设施即代码

GitOps 最显著的变化是使用了 Git。Git 是一种版本控制系统，它跟踪代码随时间的变化。要使用 Git，我们现在需要以代码形式表示我们的基础设施。这是 GitOps 的关键组件之一，称为基础设施即代码 (IaC)，我们使用代码来描述我们基础设施的期望状态。

拉取请求作为变更关卡

运营团队使用 Git 工作流在一个共享的真相来源上协作。拉取请求是 Git 工作流的关键部分。它是工作在存储库克隆上的人请求将他们在其克隆中进行的更改拉入主存储库的一种方式。

当打开拉取请求时，通常需要进行代码审查。这是其他团队成员检查新代码、编写建议更改的评论并授予批准的机会（存储库将被设置为阻止任何未经批准的传入代码，就像我们基础设施所有更改的“关卡”）。

由于 Git 会保留所有更改的历史记录，因此它也充当清晰的审计日志。

持续集成和部署

持续集成 (CI) 是从 DevOps 借鉴的另一个最佳实践。它指的是自动化我们将代码更改与存储库集成的方式。它有助于多个贡献者将更改合并到共享的中央存储库中，以减少由于更改导致的问题而产生不利影响的风险。这是通过自动运行工具实现的，当添加新代码时（通常在拉取请求中）执行测试。在上面图表中显示的工作流中，我们可以看到我们的基础设施更新只有在满足两个条件后才能从拉取请求中合并：

1. 团队批准代码审查
2. 自动化检查（或测试）全部通过

持续部署 (CD) 是指一种设置，其中所有拉入存储库的新更改都会自动部署到生产环境（如果它们通过拉取请求检查）。这是一个理想的目标，它要求您的所有流程，特别是您的测试，都非常出色。一些团队也选择通过手动批准来控制生产环境。无论您的 CD 成熟度如何，一个共同的主题是用于自动化所有基础设施配置步骤的“管道”（或工具）。

CD 也可以指持续交付，其中存储库始终保持可发布状态——即使您没有部署每次更改。虽然您的发布节奏是应用程序开发中的偏好问题，但较短的发布周期和较小的更改可以降低风险。纯粹主义者可能会争辩说，对于 GitOps，这是不可协商的，因为存储库应该反映生产的当前状态。但我们可以争辩说，如果从部署管道到存储库的审计跟踪到位，那么在任何时间点，我们的存储库是反映当前状态还是未来的期望状态，都是清晰的。

关于推送与拉取部署的快速说明

GitOps 部署可以是推式或拉式。它们在保持环境处于期望状态的方式上有所不同。拉式是首选，因为它更安全，并且能更好地支持持续交付，但推式更容易上手，而且 Terraform 专为推式部署而设计。

推式对于那些来自应用程序开发的人来说会更熟悉。当应用程序代码在存储库中更新时，会触发一个构建管道，最终将更改推送到生产环境。它不会自动注意到直接对环境进行的任何更改。

拉式部署不是由代码更改触发的。我们需要一个“操作员”服务，它不断将存储库代码中的期望状态与已部署基础设施中的实际当前状态进行比较。如果它发现更改，它会拉取更改，更新基础设施以匹配存储库。

摘要

GitOps 为组织提供了一个单一的统一工具，用于管理其基础设施和应用程序开发，并在 DevOps 改进协作的基础上发展。这有很多好处，包括：

• 灾难恢复——这允许您快速重新部署任何或所有基础设施。或者，您可以回滚和前进到 Git 日志中的任何时间点，以部署您的基础设施的特定期望状态。
• 安全性——使用 Git 意味着所有更改都记录在历史记录中。这些更改的详细信息可以记录在拉取请求和 Git 提交消息中，回答基础设施更改的“谁、什么、为什么”等审计问题。GitOps 还降低了共享登录凭据的风险，因为开发人员不再需要访问服务器。
• 自文档化部署——对您的环境所做的所有更改都通过您的 Git 存储库。您只需查看您的主分支上的最新提交即可确切了解生产中的内容——无需远程连接到服务器来审计状态。

在下一篇文章中，我们将把理论付诸实践，使用 Terraform 编写一些 IaC，将其推送到 GitHub 上的 Git 存储库，并尝试使用带有拉取请求的代码审查流程来合并基础设施更改到我们的代码中。

要了解更多关于 GitOps 的信息以及如何使用 GitOps 管理部署到 Kubernetes 的应用程序的配置，请查阅资源如何将 GitOps 与 Microsoft Azure 结合使用。