GitOps-用于基础设施自动化的DevOps

【编者的话】GitOps是一个非常好的工作流模式，可以帮助你高效地处理云基础设施。GitOps可以为工程团队提供许多优势，包括系统的更好的协调、透明度、稳定性和耐久性。

GitOps提供了一种自动化和管理基础设施的方法。它通过使用许多团队已经在使用的DevOps最佳实践来做到这一点，比如版本控制、代码审查和CI/CD流水线。

许多公司都在采用DevOps，因为它在提高生产率和软件质量方面具有巨大的潜力。在这个过程中，我们已经找到了自动化软件开发生命周期的方法。但是，当涉及到基础设施的设置和部署时，它仍然主要是一个手动过程。

有了GitOps团队就可以自动化基础设施配置过程。这是由于能够使用声明文件将基础设施编写为代码(IaC)。我们可以将它们存储在Git存储库中，就像存储应用程序开发代码一样。

GitOps是如何工作的?

GitOps的概念最初是由Kubernetes管理公司weave引入的。所以关于GitOps的讨论主要是在Kubernetes的背景下进行的。向在容器中运行的微服务的转换带来了对编排平台的需求。基于容器的应用程序的配置和管理可能非常复杂和困难。GitOps通过应用在DevOps世界中得到验证的技术，帮助简化了这一过程。

如今，这个想法已经在DevOps爱好者中流行起来，代表了IaC概念的升级模型。它围绕着3个主要组成部分:

• 基础设施代码
• 把请求
• CI/CD

让我们分别来看一下。

基础设施即代码

IaC是一种将基础设施配置和管理为声明文件、存储为代码的实践。通过利用IaC和版本控制团队可以优化所有的操作过程。

GitOps以IaC的声明性模型为中心。这就是为什么Kubernetes是一个很好的实现例子。声明性意味着配置更多地是对预期状态的声明，而不是一组命令。例如，在Kubernetes中，你可以在清单中定义服务所需的pod数量。到那时，系统就会自动运转。不需要工程师写一个命令式脚本，应该得到所需的pod数。

任何符合声明式模型的云原生软件都可以被视为代码。我们使用AWS CloudFormation(一种声明性工具)来编写AWS基础架构。这意味着我们可以将基础设施本身视为代码。将所需的状态声明为代码。系统应用更改以自动实现该状态。

话虽如此，声明式模型并不是GitOps中受益的必要条件。你也可以使用命令式定义的环境。

Pull请求

GitOps概念背后的主要思想是版本控制系统是一个单一的真理来源。我们使用Git作为应用程序代码的变更管理系统。我们也可以将其用于基础架构代码。所以所有的声明文件都在一个你可以协作的地方。这使我们能够使用Git的关键概念——操作更改的pull请求。

在一个应用程序开发工作流中，我们使用一个主分支作为发布分支。开发人员从主分支创建特性分支。开发一个特定的特性或故事，完成后创建一个pull请求，将其合并回主分支。同样的方法对基础设施代码也很方便。

创建一个pull请求可以使代码在集成到代码库的另一个分支之前经过一个代码审查过程。代码审查可以阻止糟糕的代码进入测试或生产环境。这对于基础架构代码来说更为重要。通过代码审查获得正式的批准对审核和故障排除有很大帮助。

Git组织

GitOps的部署过程至少需要两个repo:应用程序repo和环境配置repo。第一个文件包含应用程序的源代码及其部署清单。第二个文件包含了整个系统所需的状态，该状态使用每个环境的声明性规范来描述。你可以将你的环境描述为代码存储库中的开发、测试和生产环境，其中包含可以在该环境的特定版本中运行的应用程序和基础设施服务。

在基础设施的情况下，主分支可以表示一个环境。我们可以在特性分支中实现这些更改。然后创建一个pull请求来合并主分支中的变更。通过这种方式，我们可以实现协作，同时透明地了解谁执行了哪些更改。这也有利于跟踪问题的根本原因，因为所有的更改都是在Git中提交的。

GitOps适用于任何基于git的系统，如GitHub、BitBucket或GitLab。它不依赖于任何工具或技术。

CI/CD

为了实现完整的GitOps实现，你需要一个CI/CD流水线。通过使用自动化的交付流水线，每次Git存储库中发生更改时，你都可以将基础设施更改交付到指定的环境。

这里的管道将你的Git pull请求连接到业务流程系统。当你使用pull请求触发流水线时，业务流程系统将执行该任务。

GitOps的部署策略有两种可能: 推式和拉式管道。它们之间的区别在于确保部署环境类似于所需的基础设施的方式。

Push流水线

许多流行的CI/CD工具都在使用这种策略。我们将应用程序的源代码及其部署清单存储在一个存储库中。当应用程序代码中发生新的更新时，构建管道将触发。管道构建容器映像并将更改推送到环境。这种策略带来了更多的灵活性，因为它可以支持任何类型的基础设施。缺点是它允许CI/CD工具访问你的环境。

Pull流水线

社区认为，pull pipeline方法对GitOps来说是一种更安全的做法。利用这种方法，引入了算子。算子是管道和业务流程工具之间的组件。它不断地将环境存储库中的目标状态与已部署基础设施中的实际状态进行比较。如果算子检测到任何更改，则更改基础设施以适应环境存储库。此外，还可以监视映像注册表，以识别要部署的新版本的映像。这就是GitOps如此特别的原因。

在GitOps中，只有在环境存储库中发生了更改时，才会发生环境更新。如果实现的基础设施以环境存储库中未定义的任何方式发生更改，系统将恢复所做的任何修改。

对于大多数应用程序，可能需要多个环境。GitOps允许你创建多个可以更改环境存储库的流水线。你可以在环境存储库中使用单独的分支来管理更多的环境。运维人员可以通过部署到生产环境来响应一个分支的变更，也可以通过部署到测试环境来响应另一个分支的变更。

GitOps的好处是什么?

使用DevOps最佳实践

由于GitOps是一个专注于现有Git工作流、IaC、CI/CD管道、不可变服务器、跟踪和可观察性的最佳实践的模型，它代表了Kubernetes的云原生应用程序管理的更先进的状态。因此，目前的技术栈和经验在公司内部可以服务很多。

持续部署-简化

持续部署意味着更快、更频繁地部署。由于不同的考虑因素，例如系统的有状态性、宕机阻力、上游/下游的依赖关系，以及许多其他组织相关的过程和依赖关系，适当的持续部署已经非常具有挑战性。

GitOps允许你做到这一点，而不需要管理一堆工具，因为所有的事情都发生在版本控制系统中。多亏了部署操作员，它提供了结构和自动化。

这也提高了生产力和更快的MTTD(平均部署时间)。自动化持续部署确保团队每天可以交付30-100倍以上的更改，将平均生产性能提高2-3倍。

低MTTR(平均修复时间)

MTTR是DevOps团队应该衡量的关键指标之一。在微服务体系结构中，即使是很小的问题也很难修复。由于GitOps将所有更改保存在版本控制系统中，并且管理是自动化的，因此有可能显著降低MTTR。你可以全面了解环境是如何变化的，错误恢复也变得非常容易。

简化Kubernetes管理

在不完全了解Kubernetes的情况下，开发人员可以使用熟悉的工具(如Git)更容易地处理Kubernetes的升级和特性。新的嵌入式开发人员将很容易地跟上速度，并且在几天内就能活跃起来，而不是几个月。

改进了整个公司的标准化

你可以在整个企业中拥有透明的端到端工作流，因为GitOps有一个用于呈现应用程序、软件和Kubernetes附加组件修改的框架。Git还完全重现了你的操作活动。

如何准备GitOps?

建立稳定的代码审查和测试过程

仔细检查代码更改可以指出一些明显的操作，如添加全局变量。它可以防止坏代码被发布。然后，你可以通过拉请求提交验证过的代码，不允许开发人员直接提交更改。一旦pull请求被审查和合并，就可以触发管道。这是维护高标准代码和随后的系统稳定性的第一步。

测试,测试,测试

合并GitOps意味着拥有高层次的自动化，这需要对流水线发布的应用程序进行彻底的测试。尽管GitOps允许你相对容易地回滚，但发布经过良好测试用例的良好代码会使你的进程更加可靠。

重点监控

GitOps允许重复的操作过程，改进可跟踪的系统状态，推出和回滚。仔细的监视可以帮助你识别和防止配置中任何非预期的漂移和系统更改。因此，在开始使用GitOps之前，请检查你的监控技能，并加强它们，使它们能够处理这种变化。

拥抱文化

传统的流程约束和较长的发布时间只能拖你的后腿。生活在DevOps文化中意味着利用最佳战略，帮助团队理解开发和运维行动的价值。与此同时，他们必须一起协作，以创建整体稳定的基础设施，更快速、更顺利地执行应用程序，并有效地管理系统。缺乏DevOps文化将阻碍你享受GitOps带来的好处。

为什么采用GitOps?

GitOps是一个非常好的工作流模式，可以帮助你高效地处理云基础设施。GitOps可以为工程团队提供许多优势，包括系统的更好的协调、透明度、稳定性和耐久性。

原文链接： GitOps–DevOps for Infrastructure Automation