GitOps是一组最佳实践和原则，将版本控制系统（例如 Git、GitHub、GitLab、BitBucket）视为中央存储库或单一事实来源，以声明方式代码存储，然后将其用于部署。
GitOps 方法以 Kubernetes 应用程序为中心。在高性能 IT 组织中，使用 Git 等版本控制来进行基础架构管理和代码部署自动化正在成为一种越来越普遍的做法。
通过使用 GitOps，开发人员现在可以在不了解Kubernetes 基础架构的情况下将他们的应用程序独立部署到 Kubernetes 中。这意味着开发人员在 Git 中合并请求的那一刻将进行部署过程。理论上，Kubernetes Operater会观察新变化（或称为期望状态）与实际集群之间的差异。将启动一个自动化pipeline来执行构建、测试并将工件存储在存储库中。Kubernetes reconciler尝试将所需的定义与正在运行的集群进行同步。
GitOps 的特点是：
二、为什么使用 GitOps？
提高可见性和可审计性
由于所有更改都通过 Git，并且更改和部署都存储可见。因此，利益相关者从软件开发和基础设施即代码的角度了解系统中正在发生的事情。如果在生产或发布过程中出现问题，很容易审核并找到谁做了哪些更改。
执行更快的软件交付
Git repo 可用于版本控制系统、评审系统、自动化和部署生产环境的流程。
当开发人员执行代码提交时，他不必依赖任何人将他的代码部署到 Kubernetes 集群中。使用 webhook，Git 可以自动触发部署管道并将新配置或应用程序更改推送到开发、测试或生产环境。
在了解工作模型之前，让我们先快速了解一下 GitOPs 的工作原理
三、实施 GitOps 时要记住的工作原则
1. 声明式：
使用 Gitops，您应该通过声明式语言配置最终应用程序和基础设施。声明式语言是非常高级的编程语言，其中程序指定要做什么而不是如何做。当您的应用程序在 Git 中以声明方式进行版本控制时，您将维护一个单一的事实来源。这很容易部署到 Kubernetes 管理的容器中。此外，您可以使用声明性语言创建任意数量的 Kubernetes pod 副本。
2.版本控制：
使用版本系统，最显着的优势是您可以在出现任何问题时回滚到之前的应用程序状态。
3.自动化：
批准的更改需要自动应用于系统。一旦应用程序以声明方式存储在 Git 中，就必须自动化将 Git 中所做的任何更改应用到生产环境中。
最好的部分是您不需要任何凭据即可对集群进行更改。自动化工具可以载入您的 Kubernetes 帐户或命名空间，并可以启动部署。
4.保障性：
像 Argo CD 这样的agent可以持续监控 Git，并在 Git 存储库的状态与生产中运行的内容不匹配时发出通知。这些agent还确保您的整个系统是自我修复的，即，在发生故障的情况下，可以使用配置文件重新启动 pod。并且可以避免任何潜在的人为错误。
四、GitOps 是如何工作的？
开发人员被分配编写代码或业务逻辑并将其推送到不同的环境，如开发、测试和生产。理想情况下，他们将在 Git 中创建拉取请求，然后推送所有代码并将拉取请求合并到主分支。
现在，假设您有三个环境，即开发测试和生产环境，每个分支都映射到各自的 Kubernetes 集群或命名空间。
将更改推送到该特定分支后，将有一个相关的自动化管道负责将代码投入生产。这意味着，只要该特定分支管道流程有代码提交，该管道就会帮助测试和验证软件是否适合发布。如果开发人员合并了一个开发分支，并且一旦成功，他们最终将执行拉取请求以将更改合并到生产分支中。
在合并请求之后，更改将被部署到生产环境中。如果有回滚需求，您可以创建另一个拉取请求以回滚到之前的状态。
Kubernetes 的 GitOps 风格交付将如下所示：
当用户去更改 Git 仓库中的代码时，它会创建一个容器镜像，并将一个容器镜像推送到容器注册表，最终更新为配置更新。
一旦您创建了合并到不同分支的拉取请求，即完成代码提交后，管道会测试这些是否能够通过各个测试用例。
这就是 GitOps 帮助团队和解决自动化问题的方式。
因此，GitOps 可以概括为以下两件事：
一条端到端 CI/CD 管道工作流应用于运维和开发。
提供一组最佳实践，统一部署、管理和监控容器化集群和应用程序。
OpsMx Enterprise for Spinnaker (OES)可帮助您实现 GitOps。OES 具有高度可扩展性，可保护多云持续交付平台，以更快、更频繁地发布软件。
现在，让我们来看看如何？
五、使用 OpsMx Enterprise for Spinnaker 实施 GitOps
假设您已将 Kubernetes 部署所需的所有 YAML 文件和其他文档存储在 Git 存储库中。您将需要一个发布编排工具来自动化部署过程。
现在，OES 可以帮助您自动部署 Kubernetes 应用程序。因此，一旦您在 Git 存储库中的合并请求完成，就会使用 Webhook 从 Git 触发 OES 管道。
（是的，我们也在构建一个operater来查找任何不同步状态并将您的代码投入生产）
然后，管道将运行以下阶段：依次构建、测试、部署、验证和发布。
![]()
1. 代码提交阶段：
在这个阶段，开发者需要创建一个新的拉取请求。他可以执行必要的修改并将拉取请求与主分支合并。合并完成后，SCM 可以触发事件——通过 webhook 调用 OES 管道。
![]()
![]()
2.构建阶段
OES 管道将执行称为 Build 的第一阶段。该管道将触发（例如）Jenkins 或 Google Cloud Build 中的构建作业。理想情况下，构建作业将配置为从 Git 中的特定路径获取配置文件（YAML 文件）。构建过程完成后，构建作业将生成一个可部署的工件并将其推送到 Docker Hub 或 JFrog Artifactory 等存储库中。
![]()
![]()
3. 部署：
在部署阶段，您可以创建工件和 Kubernetes 资源/清单以进行部署。您可以在阶段中添加更多阶段，例如测试、安全扫描、策略检查。
![]()
![]()
4. Kubernetes 集群健康：
达到所需状态后，在部署后阶段 Spinnaker 提供诸如 Kubernetes 集群的健康状况、正在运行的 pod 数量、负载均衡器的状态等信息。
![]()
![]()
一旦将更改部署到 Kubernetes 集群并达到所需状态，GitOps 循环就结束了。即使在所需状态正在运行时，也可能出现意外的性能和异常的软件行为。最终会引发 L0 事件，或者最坏的情况是回滚到以前的版本。
因此，我们建议在您的管道中实施合规性和验证，作为确保发布高质量软件和生产无风险的关键要素。
OpsMx Enterprise for Spinnaker (OES) 提供数据和智能模块，以在每个管道阶段执行策略和安全检查。它还提供部署和生产验证，通过分析来自监控解决方案的日志和指标来突出发布的性能和质量回归.
2.构建阶段
3. 部署：
