什么是 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 或容器注册中心进行部署。
Ansible 和红帽 Ansible 自动化平台有什么区别？
准备好开始使用红帽 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 和版本控制，并将其应用于基础架构自动化和应用部署。开发人员可以在自己已经熟悉的代码存储库中作业，而运维部门则可以将其他必要组件落实到位。
红帽如何支持 GitOps
红帽® OpenShift® 是一个声明式 Kubernetes 平台，管理员可使用 GitOps 原则进行配置和管理。在基于 Kubernetes 的基础架构和应用中作业，可以跨集群和开发周期实现一致性。红帽 OpenShift 整合了对跨本地和公共云资源的应用的管理，方便您：
- 检查集群的状态是否相似（配置、监控、存储），从而在开发周期中尽早明确应用限制。
- 通过从已知状态恢复集群，跨多个集群回滚代码变更。
- 跨多个红帽 OpenShift 集群，部署提交至 Git 的变更。
- 在混合云中关联模板化配置。
红帽可与 ArgoCD 和 Tekton 等开源项目协作，实施用于 GitOps 的框架。安装红帽 OpenShift Pipelines Operator，并了解红帽 OpenShift GitOps Operator 如何通过 Argo 开发新工具，进而管理现有红帽 OpenShift 部署中的 GitOps。
AWS 上的红帽 OpenShift 服务（ROSA）是一个完全托管的统包式应用平台，让企业可以提高运维效率、重新专注于创新，并在原生 AWS 环境中快速构建、部署和扩展应用。
这意味着 ROSA 可帮助团队管理不同区域的集群，使用自助工具创建和部署集群，并自动执行安全补丁和升级。例如，ROSA 为管理员和基础架构团队提供与应用所有者相同的益处，从而促进应用现代化。
红帽 Kubernetes 高级集群管理可提供 Kubernetes 集群生命周期的多集群管理。红帽高级集群管理使用订阅和渠道框架以及放置规则，从而可跨多个集群在预期状态模式中自动部署应用。
不管您的系统当前状态如何，红帽 Ansible® 自动化平台都可使其进入预期状态。用 YAML 编写的 Ansible Playbook 描述了系统的理想状态，其通常保留在源代码控制中。
借助 Ansible 自动化平台，GitOps 实践除了可以应用于 Kubernetes，还可以应用于传统 IT 系统，如网络、云和裸机。您可以使用 webhook 将 Ansible 自动化平台与 Git 存储库集成。设置存储库链接后，Ansible 自动化平台便会从 Git 系统中捕获 Git 提交，并使用这些事件来触发自动化作业以更新项目、管理清单以及执行部署。
您可以通过 Webhook 在源代码控制系统中发生事件时自动激活自动化。这样一来，便不再需要 Jenkins 等其他 CI/CD 工具来监控存储库并在变更的同时启动自动化作业，不仅简化 GitOps 工作流，也精简了运维。Ansible 自动化平台可与各种开发和部署工具结合使用，因此，您可以使用偏好的工具和流程来定制 GitOps 工作流。
通过将红帽高级集群管理、红帽 OpenShift GitOps 和红帽 Ansible 自动化平台相集成，DevOps 团队可确保批量管理与维护相应的配置，从而改进 CI/CD 管道。
