什么是 GitOps？
GitOps 使用 Git 存储库作为单一事实来源，来提供基础架构即代码。这种实践提交的代码会检查 CI 流程，而 CD 流程会检查并应用安全防护、基础架构即代码或为应用框架设置的任何其他边界等方面的要求。它可以让 IT 人员跟踪对代码进行的所有变更，从而轻松进行更新，并且在需要回滚时提供版本控制。
GitOps 可提供：
- 标准的应用开发工作流
- 更强的安全性，便于提前设置应用要求
- 通过 Git 存储库获得更高的可靠性、可见性及版本控制
- 在任何集群、云和本地环境保持一致
构建 GitOps 框架时，可以许多其他工具可一起使用。例如，Git 存储库、Kubernetes、持续集成/持续交付（CI/CD）工具和配置管理工具。
用 GitOps 方法在 Kubernetes 上实现持续交付
观看 OpenShift.tv 频道的"Galaxy 的 GitOps 指南"了解更多信息（美东时间隔周周四下午 3 点直播）
为什么要选择 GitOps？
GitOps 秉承了 DevOps 文化的理念和方法，并且能够提供一个框架，以便您付诸行动，逐步取得成果。根据年度 DevOps 现状报告，践行 DevOps 的企业在应用和代码创新速度以及稳定性方面取得了巨大改进。
通过使用开发人员熟悉的基于 Git 的相同工作流，GitOps 可将现有流程，从应用开发扩展到到部署、应用生命周期管理和基础架构配置。应用生命周期中的每个变更都可在 Git 存储库中审计跟踪。通过 Git 进行变更意味着开发人员终于可以做他们想做的事情：按照自己的步调编码，无需等待运维团队分配或批准资源。
对于运维团队，更清楚地掌握变更，也意味着能够快速跟踪和重现问题，提高整体安全性。借助最新的审计跟踪，企业可降低不必要变更的风险，并在代码进入生产阶段之前更正它们。
从开发到生产的快速代码变更方式可使企业更加敏捷地响应业务和竞争格局变化。
如何入门 GitOps
要开始使用 GitOps，您需要有支持声明式管理的基础架构。正因为如此，GitOps 经常被用作 Kubernetes 和云原生应用开发的运维模式，并且可以实现对 Kubernetes 的持续部署。
但 GitOps 并不一定要求使用 Kubernetes。GitOps 这种技术也可应用于其他基础架构和部署流程。
与 Kubernetes 一样，Ansible 也是一个理想的状态引擎，能够对传统 IT 系统进行声明式建模，因此可用于GitOps。Ansible 用户既可以管理 Kubernetes 上的应用，也可以管理现有 IT 基础设施上的应用，还可以通过 Ansible 模块的一个控制平面同时管理这两种应用。
GitOps 可用于构建开发流程、对应用进行编码、管理配置、置备 Kubernetes 集群以及在 Kubernetes 或容器注册中心进行部署。
红帽如何支持 GitOps
红帽® OpenShift® 是一个声明式 Kubernetes 平台，管理员可使用 GitOps 原则进行配置和管理。在基于 Kubernetes 的基础架构和应用中作业，可以跨集群和开发周期实现一致性。红帽 OpenShift 整合了对跨本地和公共云资源的应用的管理，方便您：
- 检查集群的状态是否相似（配置、监控、存储），从而在开发周期中尽早明确应用限制。
- 通过从已知状态恢复集群，跨多个集群回滚代码变更。
- 跨多个红帽 OpenShift 集群，部署提交至 Git 的变更。
- 在混合云中关联模板化配置。
红帽可与 ArgoCD 和 Tekton 等开源项目协作，实施用于 GitOps 的框架。安装 OpenShift Pipelines Operator，并了解红帽 OpenShift GitOps operator 如何通过 Argo 开发新工具，来管理现有红帽 OpenShift 部署中的 GitOps。
用于 Kubernetes 的红帽高级集群管理可提供 Kubernetes 集群生命周期的多集群管理。红帽高级集群管理使用订阅和渠道框架以及放置规则，从而可跨多个集群在预期状态模式中自动部署应用。
不管您的系统当前状态如何，红帽 Ansible® 自动化平台都可使其进入预期状态。采用 YAML 编写的 Ansible Playbook（通常位于源代码管理系统中）会描述系统的预期状态。
借助 Ansible 自动化平台，GitOps 实践除了可以应用于 Kubernetes，还可以应用于传统 IT 系统，如网络、云和裸机。Ansible 自动化平台中内置了自动化 Webhook，可以为开展 IaC 和 GitOps 实践提供支持。Webhook 支持您以原生方式将 Git 存储库与 Ansible 自动化平台连接起来。一旦建立了存储库链接，Ansible 自动化平台就会从 Git 系统中捕获 Git 提交，并使用这些事件来触发自动化作业，以更新项目、管理库存和执行部署。
通过将红帽高级集群管理、红帽 OpenShift GitOps 和红帽 Ansible 自动化平台相集成，DevOps 团队可确保批量管理与维护相应的配置，从而改进 CI/CD 管道。
准备好开始使用红帽 OpenShift 来开展 GitOps 了吗？
GitOps 工作流是什么样的？
我们可以认为 GitOps 是基础架构即代码（IaC） 的一种演变，它使用 Git 作为基础架构配置的版本控制系统。IaC 通常采用声明式方法来管理基础架构，定义系统的预期状态，并跟踪系统的实际状态。
与 IaC 一样，GitOps 也要求您声明式描述系统的预期状态。通过使用声明式工具，您所有的配置文件和源代码都可以在 Git 中进行版本控制。
CI/CD 流程通常由外部事件触发，比如代码被推送到了存储库中。在 GitOps 工作流中，要进行变更，需要通过拉取请求来修改 Git 仓库的状态。
要使用 GitOps 工作流发布新版本，需要在 Git 中提出拉取请求，这样可以变更集群的声明状态。GitOps Operator 是 GitOps 流程与编排系统之间的桥梁，它会接收提交（commit），并从 Git 中拉取新的状态声明。
一旦这些变化被批准和合并，它们将自动应用于实时基础架构。开发人员可以继续使用他们的标准工作流以及 CI/CD 实践。
同时搭配使用 Kubernetes 与 GitOps 时，通常使用 Kubernetes Operator。Operator 会将存储库中的预期状态与所部署基础架构的实际状态进行比较。每当注意到实际状态与存储库中的预期状态存在差异时，Operator 便会更新基础架构。Operator 还可以监控容器镜像存储库，并以同样的方式进行更新，从而部署新的镜像。
GitOps 中还有一个重要概念——可观察性，指可观察的任何系统状态。GitOps 的可观察性有助于您确保观察到的状态（或实际状态）与预期状态一致。
使用拉取请求和 Git 之类的版本控制系统能让部署过程清晰可见。这样一来，您便可查看和跟踪对系统进行的任何变更，提供审计跟踪，并在出现问题时进行回滚变更。
GitOps 工作流可以提高生产率，加快开发和部署速度，同时提高系统的稳定性和可靠性。
GitOps 与 DevOps 之间有何区别？
GitOps 和 DevOps 的确在原则和目标上有着相同之处。DevOps 更侧重于文化转变，旨在为开发团队和运维团队提供一种协同工作方式。
而 GitOps 则为您提供工具和框架来采用 DevOps 实践，如协作、CI/CD 和版本控制，并将其应用于基础架构自动化和应用部署。开发人员可以在自己已经熟悉的代码存储库中作业，而运维部门则可以将其他必要组件落实到位。
