| 导读 | GitOps提供了一种自动化和管理基础设施的方法。它通过许多团队已经应用的DevOps最佳实践来做到这一点，例如版本控制、代码评审和CI/CD管道。 |
由于DevOps在提高生产率和软件质量方面的巨大潜力，许多公司一直采用DevOps。在这个过程中，我们已经找到了自动化软件开发生命周期的方法。然而，在基础设施设置和部署方面，它仍然主要是一个手动过程。
使用GitOps，团队可以自动化基础设施配置过程。这是因为可以使用声明文件将基础结构编写为代码（IaC）。我们可以将它们存储在Git存储库中，就像存储应用程序开发代码一样。
GitOps的概念最初是由Kubernetes管理公司Weaveworks提出的。所以关于GitOps的讨论主要是在Kubernetes的背景下进行的。向在容器中运行的微服务的转换带来了对编排平台的需求。基于容器的应用程序的供应和管理可能很复杂，也很困难。GitOps通过应用已在DevOps世界中验证过的技术来帮助简化这一点。
如今，这个想法在DevOps的爱好者中很流行，代表了IaC概念的升级模型。它围绕三个主要部分展开：
基础设施即代码
拉取请求
CI/CD
IaC是一种将基础设施作为声明文件（存储为代码）提供和管理的实践。通过利用IaC和版本控制团队可以优化所有的操作过程。
GitOps以IaC的声明式模型为中心。这就是为什么Kubernetes是一个很好的实现示例。声明性意味着配置更多的是对预期状态的声明，而不是一组。例如，在Kubernetes中，您可以在清单中定义服务所需的pods数量。系统会自行处理。工程师不需要编写能够达到所需pod编号的式。
任何符合声明式模型的云本地软件都可以被视为代码。我们使用AWS CloudFormation来编写AWS基础设施，这是一个声明性工具。这意味着我们可以将基础设施本身视为代码。将所需状态声明为代码。系统应用变更来实现自动化状态。
话虽如此，声明式模型在GitOps中并不是必须的。命令式定义的环境也可以这样做。
GitOps概念背后的主要思想是版本控制系统是事实的唯一来源。我们使用Git作为应用程序代码的变更管理系统。我们还可以在基础设施代码中使用它。因此，整个声明文件集都在一个可以协作的地方。这使我们能够使用Git的关键概念——操作更改的pull请求。
在应用程序开发工作流中，我们使用一个主分支作为发布分支。开发人员从主分支创建功能分支。开发一个特定的特性或故事，完成后创建一个pull请求，将其合并回主分支。同样的方法对于基础结构代码也很方便。
在我们将代码集成到代码基的另一个分支之前，创建一个pull request使代码能够经过一个代码审查过程。代码检查可以阻止坏代码进入测试或生产环境。这对于基础架构代码甚至更为重要。通过代码审查获得正式的批准对审计和故障排除有很大帮助。
GitOps中的部署过程至少需要两个repo：应用程序repo和环境配置repo。第一个包含应用程序的源代码及其部署清单。第二个包含对每个环境使用声明性规范描述的整个系统的期望状态。您可以将您的环境描述为代码存储库中的开发、测试、生产，其中包含可以与该环境的特定版本一起运行的应用程序和基础设施服务。
在基础设施的情况下，主要分支可以表示一个环境。我们可以在特性分支中实现变更。然后创建一个pull request来合并主分支中的更改。通过这种方式，我们可以实现协作，同时对谁执行了哪些更改保持透明。这也有利于问题跟踪到根源，因为所有更改都是在Git中提交的。
GitOps可用于任何基于Git的系统，如GitHub、BitBucket或GitLab。它不依赖于任何工具或技术。
要实现完整的GitOps，您需要一个CI/CD管道。使用自动交付管道，每次Git存储库中发生更改时，您都可以将基础结构更改传递到指定的环境中。
这里的管道用于将Git pull请求连接到编排系统。当您使用pull请求触发管道时，业务流程系统将执行该任务。
GitOps部署策略有两种可能:push管道和pull管道。它们之间的区别在于确保部署环境与所需的基础设施相似的方式。
许多流行的CI/CD工具都在使用这种策略。我们将应用程序的源代码及其部署清单存储在一个存储库中。当应用程序代码中发生新的更新时，生成管道将触发。管道构建容器映像并将更改推送到环境中。这种策略带来了更大的灵活性，因为它可以支持任何类型的基础设施。缺点是它允许CI/CD工具访问您的环境。
社区认为Pull管道方法对GitOps来说更安全的实践。通过这种方法，引入了运算符。操作符是管道和编配工具之间的一个组件。它不断地将环境存储库中的目标状态与部署基础设施中的实际状态进行比较。操作员如果检测到任何更改，就更改基础结构以适应环境存储库。另外，还可以监视映像注册表，以确定要部署的映像的新版本。这就是GitOps如此特别的原因。
在GitOps中，只有在环境存储库中发生更改时才会进行环境更新。如果实现的基础设施以未在环境存储库中定义的任何方式更改，系统将恢复所做的任何修改。
对于大多数应用程序，您可能需要多个环境。GitOps允许您创建多个可以更改环境存储库的管道。您可以在环境存储库中使用不同的分支来管理更多的环境。操作员可以通过部署到生产环境来响应一个分支的更改，也可以通过部署到测试来响应另一个分支。
由于GitOps是一个专注于Git工作流、IaC、CI/CD管道、不可变服务器、跟踪和可观察性等现有最佳实践的模型，它代表了Kubernetes云原生应用程序管理的更高级状态。因此，公司目前的经验和经验可以提供很多服务。
持续部署意味着更快、更频繁地部署。由于不同的考虑因素，如系统的状态性、抗停机能力、上游/下游依赖关系以及许多其他组织相关流程和依赖关系，正确的持续部署一直非常具有挑战性。
GitOps允许您这样做，而不必管理一堆工具，因为所有的事情都发生在版本控制系统中。由于使用了部署操作，它提供了结构和自动化。
这也提高了生产率和更快的MTTD（平均部署时间）。自动化的持续部署确保团队每天可以发布30-100倍的更改，从而将平均生产性能提高2-3倍。
MTTR是DevOps团队应该度量的关键指标之一。在微服务体系结构中，即使是很小的问题也很难修复。由于GitOps在版本控制系统中保留了所有更改，并且管理是自动化的，因此可以显著降低MTTR。您已经全面了解了环境是如何变化的，并且错误恢复变得非常容易。
在不深入了解Kubernetes的情况下，开发人员可以使用熟悉的工具（如Git）来更轻松地处理Kubernetes的升级和特性。新的嵌入式开发人员将很容易跟上速度，并在几天内而不是几个月内活跃起来。
因为GitOps有一个用于呈现应用程序、软件和Kubernetes附加修改的框架，所以在整个企业中都有透明的端到端工作流。Git还可以完全复制操作活动。
建立一个稳定的代码评审和测试过程。仔细检查代码更改可以指出一些明显的操作，例如添加全局变量。它可以防止坏代码被释放。然后，您可以通过pull请求提交经过验证的代码，不允许开发人员直接提交任何更改。一旦请求被检查和合并，就可以触发管道。这是维护高标准代码和随后系统稳定性的第一步。
加入GitOps意味着拥有高水平的自动化，这需要对管道发布的应用程序进行彻底的测试。尽管GitOps允许相对容易地回滚，但发布经过良好测试用例的好代码会使流程更加可靠。
GitOps允许可重复的操作过程，改进可跟踪的系统状态、发布和回滚。仔细的监视可以帮助您识别和防止配置中任何意外的偏移和系统更改。所以，在开始使用GitOps之前，回顾一下你的监控技能，并加强你的监控能力，让他们能够应对这种变化。
具有长发布时间的传统流程约束只会阻碍您。采用DevOps文化意味着利用最好的策略，帮助团队理解开发和运营行动的价值。与此同时，它们必须一起协作，以创建一个整体稳定的基础设施，更快、更平稳地执行应用程序，并有效地管理系统。缺乏DevOps文化会妨碍你享受GitOps的好处。
GitOps是一种非常好的工作流模式，它可以帮助你高效地处理云基础设施。GitOps可以为工程团队提供许多优势，包括更好的协调、透明度、稳定性和系统的耐用性。
原文来自：
本文地址：//q13zd.cn/gitops-devops.html编辑：向云艳，审核员：逄增宝
Linux命令大全：
Linux系统大全：
