GitOps提供了一种自动化的管理基础架构的方法。它通过使用许多团队已经使用的DevOps最佳实践来做到这一点，例如版本控制，代码审查和CI/CD管道。
由于DevOps具有提高生产力和软件质量的巨大潜力，因此公司一直在采用它。在此过程中，我们找到了使软件开发生命周期自动化的方法。但是，当涉及到基础架构的设置和部署时，它仍然主要是手动过程。
借助GitOps，团队可以自动化基础架构的配置过程。这是由于可以使用声明文件将基础结构编写为代码（IaC）。我们可以将它们存储在Git存储库中，就像存储应用程序开发代码一样。
GitOps如何工作？
GitOps概念最初由Kubernetes管理公司Weave w orks提出。因此，围绕GitOps的讨论主要是在Kubernetes的背景下进行的。向在容器中运行的微服务的转变带来了对业务流程平台的需求。基于容器的应用程序可能很复杂，并且难以进行供应和管理。GitOps通过应用DevOps世界中成熟的技术来帮助简化此过程。
如今，这个想法已成为DevOps爱好者的青睐，代表了IaC概念的升级模型。它围绕三个主要组成部分：
- 基础架构即代码
- 拉取要求
- CI/CD
让我们分别看看它们。
基础架构即代码
IaC是作为声明文件（存储为代码）来配置和管理基础结构的一种做法。通过利用IaC和版本控制团队，可以优化所有操作程序。
GitOps围绕IaC的声明式模型。这就是为什么Kubernetes是实现的一个很好的例子。声明式意味着配置更多是对预期状态的声明，而不是一组命令。例如，在Kubernetes中，您可以在清单中定义服务所需的Pod数量。然后，系统将自行处理。无需工程师编写命令脚本即可获得所需的容器编号。
任何符合声明性模型的云原生软件都可以视为代码。我们使用AWS CloudFormation（一种声明性工具）编写AWS基础架构。这意味着我们可以将基础架构本身视为代码。将所需状态声明为代码。系统应用更改以自动实现该状态。
话虽如此，声明性模型并不是必须在GitOps中受益。您也可以在命令式定义的环境中执行操作。
拉取要求
GitOps概念背后的主要思想是版本控制系统是真实的唯一来源 。我们将Git用作应用程序代码的变更管理系统。我们也可以将其用于基础结构代码。因此，整个声明文件集都位于一个可以协作的地方。这使我们能够使用Git的关键概念-对操作更改的Pull 请求。
在应用开发工作流程中，我们使用一个主分支作为发布分支。开发人员从主分支创建功能分支。开发特定功能或故事，完成后创建Pull 请求以将其合并回主分支。相同的方法对于基础结构代码很方便。
创建拉取请求可使代码在集成到代码库的另一个分支之前，先经过代码审查过程。代码审查阻止不良代码进入测试或生产环境。这对于基础结构代码而言甚至更为重要。通过代码审查获得正式批准对审核和故障排除很有帮助。
Git组织
GitOps中的部署过程至少需要两个存储库：应用程序存储库和环境配置存储库。第一个包含应用程序的源代码及其部署清单。第二个包含使用每个环境的声明性规范描述的整个系统的期望状态。您可以在代码存储库中将环境描述为开发，测试，生产环境，其中包含可以在该环境的特定版本中运行的应用程序和基础结构服务。
对于基础设施，主分支可以代表一个环境。我们可以在功能分支中实现更改。然后创建一个拉取请求以合并主分支中的更改。这样一来，我们就可以实现协作，同时对谁进行了哪些更改保持透明。由于所有更改都是在Git中提交的，因此这对于从根本原因进行问题跟踪也很有用。
GitOps可与任何基于Git的系统一起使用，例如GitHub，BitBucket或GitLab。它不依赖于任何工具或技术。
CI/CD
要实现完整的GitOps实施，您需要一个CI/CD管道。借助自动交付管道，每次Git存储库中发生更改时，您都可以将基础结构更改交付到指定的环境。这里有管道将您的Git pull请求连接到业务流程系统。当您通过拉取请求触发管道时，业务流程系统将执行任务。
GitOps部署策略有两种可能性：推和拉管道。它们之间的区别在于您确保部署环境类似于所需基础结构的方式。
推管道
许多流行的CI/CD工具都在使用这种策略。我们将应用程序的源代码及其部署清单存储在一个存储库中。当应用程序代码中发生新更新时，构建管道将触发。管道构建容器映像并将更改推送到环境。该策略可支持任何类型的基础架构，因此带来了更大的灵活性。缺点是它使CI/CD工具可以写入您的环境。
基于推送的GitOps部署
拉管道
社区认为对于GitOps，拉管道方法是一种更安全的做法。通过这种方法，引入了操作员。操作员是管道和业务流程工具之间的组件。它不断将环境存储库中的目标状态与已部署的基础架构中的实际状态进行比较。如果操作员检测到任何更改，便会更改基础结构以适合环境存储库。同样，可以监视映像注册表以识别要部署的映像的新版本。这就是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？
- 建立稳定的代码审查和测试过程仔细检查代码更改可能会指出一些明显的操作，例如添加全局变量。它可以防止错误代码被释放。然后，您可以通过请求提交经过验证的代码，从而使开发人员无法直接提交任何更改。查看并合并拉取请求后，即可触发管道。这是保持高标准代码和后续系统稳定性的第一步。
- 测试，测试，测试集成GitOps意味着具有高级自动化，需要对发布的应用程序进行彻底的测试。即使GitOps允许您相对轻松地回滚，释放经过良好测试用例的良好代码也可以使您的过程更加可靠。
- 专注于监控GitOps允许可重复的操作流程，可追溯系统状态的改进，推出和回滚。仔细的监视可以帮助您识别并防止任何意外的漂移和系统配置更改。因此，在开始使用GitOps之前，请复查您的监视技能，并以他们可以处理此更改的方式来增强它们。
- 拥抱文化具有较长发布时间的常规流程限制只能使您退缩。拥有DevOps文化意味着运用最佳战略，这将帮助团队理解开发和运营行动的价值。同时，他们必须共同协作以创建整体稳定的基础架构，更快速，更流畅地执行应用程序以及有效地管理系统。缺乏DevOps文化会阻止您享受GitOps的好处。
为什么选择GitOps？
GitOps是一种非常好的工作流程模式，可以帮助您有效地处理云基础架构。GitOps可以为工程团队提供众多优势，包括更好的协调性，透明度，稳定性和系统耐用性。
