什么是 GitOps？

GitOps 是一套用于管理基础架构和应用配置的实践，用于扩展现有流程并优化应用生命周期。

GitOps 使用 Git 存储库作为单一事实来源，以交付基础架构即代码（IaC）。IaC 通过代码而不是通过手动流程来管理和置备基础架构。利用 IaC，可以创建包含基础架构规范的配置文件，确保每次都能置备相同的环境。它是实施 DevOps 实践和持续集成/持续交付（CI/CD）的一个重要组成部分。 

GitOps 要求对系统的预期状态进行声明式描述。通过使用声明式工具，所有配置文件和源代码都可以在 Git 中进行版本控制。代码的所有变动都会被追踪记录，这不仅简化了更新流程，同时也提供了版本控制功能，以便在必要时进行回滚。

GitOps 可帮助您实现以下目标：

• 采用标准的应用开发工作流。
• 增强可见性和可审计性，提升安全级别。
• 利用 Git 提供的可见性和版本控制能力，实现更高的可靠性。
• 跨集群、云和本地环境保持一致。

探索红帽 OpenShift GitOps Operator

GitOps 和 DevOps 秉持着一些相同的原则和目标。DevOps 更侧重于文化转变，旨在为开发团队和运维团队提供一种协同工作方式。

GitOps 则为您提供工具和框架来采用 DevOps 实践（比如协作、CI/CD 和版本控制），并将其应用于基础架构自动化和应用部署。

采用 GitOps 意味着流程的改变，团队需要时间进行调整。这需要团队之间更高程度的协作和沟通。虽然建立反馈文化有助于应对相关挑战，但仍无法完全避免问题的产生。

尽管存在这些挑战，GitOps 依然秉承了 DevOps 文化的理念和方法，并且能够提供一个框架，以便您付诸行动，逐步取得成果。

通过使用开发人员熟悉的基于 Git 的相同工作流，GitOps 扩展了现有流程，覆盖了从应用开发到部署、应用生命周期管理以及基础架构配置的各个环节。开发人员可以继续使用他们习惯的代码存储库，而运维部门则可以采用相同的工具和技术来管理基础架构。应用生命周期中的每一次更改都可以在 Git 存储库中追溯并进行审计。

通过 Git 进行更改意味着开发人员终于可以做他们想做的事情：按照自己的步调编码，无需等待运维团队分配或批准资源。

对于运维团队，更清楚地掌握更改情况，也意味着能够快速跟踪和重现问题，从而提升整体安全性。借助最新的审计跟踪，企业组织可降低不必要更改带来的风险，并在代码进入生产阶段之前进行更正。

代码从开发到生产的这些转变，使得企业能够更加敏捷地应对业务及竞争环境的各种变化。

您可以搭配使用多种工具来构建 GitOps 框架，比如 Git 存储库、Kubernetes、持续集成/持续交付（CI/CD）工具和配置管理工具。要选择一套合适的工具，开发人员应明确自身需求，并评估哪些功能可以用作解决方案的一部分。下面列出了一些值得考虑的工具。  

CI 工具

持续集成（CI）是指自动且频繁地将代码更改集成到共享源代码存储库中的做法。进行这些更新时，会触发测试步骤的自动执行，以确保所合并代码更改的可靠性。 

Tekton：Tekton 是一种用于构建 CI/CD 系统的 Kubernetes 原生框架。它旨在为平台工程师和开发人员提供灵活性、最佳实践和标准化流程，以便在各种云平台和本地系统中构建、测试和部署应用。 

Jenkins：Jenkins 是一个基于 Java 的开源自动化服务器。它通过持续测试、构建和部署项目，使开发人员能够轻松地集成自己做出的更改，并且只需要极少的设置。作为 Jenkins 生态系统的扩展，Jenkins X 可帮助实现云端 CI/CD 管道的自动化。 

CD 工具

持续交付和/或持续部署（CD）是一个由两部分组成的过程，涉及代码更改的集成、测试和交付。持续交付是指自动执行 CI 中的构建、单元测试和集成测试后，自动将经过验证的代码发布到存储库。持续部署是持续交付的延伸，指的是自动将开发人员的更改从存储库发布到生产环境，以供客户使用。

Argo CD：Argo CD 是一款适用于 Kubernetes 的声明式持续交付工具。开发团队可以借助该工具来部署和管理应用，而无需深入掌握 Kubernetes 相关知识，也无需拥有 Kubernetes 系统的完整访问权限。通过监控运行中的应用，ArgoCD 能够确保您的应用的实际状态始终与预期状态保持同步。 

开始使用 Argo CD

Flux：一款 GitOps 工具，通过确保集群状态与 Git 存储库同步，在 Kubernetes 集群上实现自动化部署。基于 Kubernetes API 扩展构建，Flux 不仅支持应用部署，还能管理基础架构。

要开始使用 GitOps，您需要有支持声明式管理的基础架构。正因为如此，GitOps 经常被用作 Kubernetes 和云原生应用开发的运维模式，并且可以实现对 Kubernetes 的持续部署。

但 GitOps 并不强制要求使用 Kubernetes。GitOps 这种技术也可应用于其他基础架构和部署管道。GitOps 可用于构建开发管道、编写应用代码、管理配置、置备 Kubernetes 集群以及在 Kubernetes 或容器镜像仓库中进行部署。

使用红帽 OpenShift GitOps

我们可以认为 GitOps 是 IaC 的一种演变，它使用 Git 作为基础架构配置的版本控制系统。IaC 通常采用声明式方法来管理基础架构，即定义系统的预期状态，并跟踪系统的实际状态。

与 IaC 一样，GitOps 也要求您声明式描述系统的预期状态。通过使用声明式工具，您所有的配置文件和源代码都可以在 Git 中进行版本控制。

CI/CD 管道通常由外部事件触发，比如将代码推送到存储库中。在 GitOps 工作流中，要进行更改，需要通过拉取请求来修改 Git 存储库的状态。 

若要使用 GitOps 工作流发布新版本，需要先在 Git 中提交一个更改集群声明状态的拉取请求。随后，GitOps Operator 会检测到该提交，并从 Git 中拉取新的状态声明。  

这些更改一经批准并合并，便会自动应用到实际运行的基础架构中。开发人员可以继续使用他们的标准工作流和 CI/CD 实践，因为 CD 由 GitOps 引擎负责，该引擎既可独立运行，也可作为 CI 编排解决方案的一部分协同运行。

当 GitOps 与 Kubernetes 结合使用时，通常会使用 Kubernetes Operator。Operator 会将存储库中的预期状态与所部署基础架构的实际状态进行比较。每当注意到实际状态与存储库中的预期状态存在差异时，Operator 便会更新基础架构和应用。

可观测性是 GitOps 中的一个重要概念，它是指可观测的任何系统状态。在 GitOps 中，可观测性有助于您确保观测到的状态（或实际状态）与预期状态一致。虽然 GitOps 提供了对其部署资源的观测能力，但它本身并不是一个通用的监控工具。相较之下，红帽® OpenShift® Observability 是一套全面的工具，它利用指标、日志、跟踪和事件，帮助您克服上述局限性，并在应用系统与 Git 存储库之间建立反馈循环。GitOps 与 OpenShift Observability 协同工作，通过监控、分析和故障排除，能帮助您深入了解应用系统的运行状况。 

使用拉取请求和 Git 之类的版本控制系统，可提高部署流程的可见性。这样一来，您便可查看和跟踪对系统进行的任何更改、提供审计跟踪，并在出现问题时回滚更改。

GitOps 工作流可以提高生产率，加快开发和部署速度，同时提高系统的稳定性和可靠性。

了解有关 GitOps 工作流的更多信息

红帽提供了一系列产品来支持您的 GitOps 工作流。红帽 OpenShift 是一个统一的应用平台，管理员可遵循 GitOps 原则对其进行配置和管理，从而在 Kubernetes 集群和整个开发生命周期中实现一致性。红帽 OpenShift 整合了对分布在本地和公共云资源上的应用的管理，方便您：

• 检查集群的状态是否相似（配置、监控、存储），从而在开发周期中尽早明确应用限制。
• 通过从已知状态恢复集群，跨多个集群回滚代码更改。
• 在多个红帽 OpenShift 集群上部署提交至 Git 的更改。
• 在混合云中关联模板化配置。

红帽 OpenShift GitOps Operator 可提供与 Git 存储库、持续集成/持续交付（CI/CD）工具和 Kubernetes 集成的工作流，以实现更快、更安全、可扩展的软件开发，且不会影响质量。借助它，您可以在应用开发平台内直接构建和集成声明式 Git 驱动的 CD 工作流。传统上，您的 CI/CD 工具会是像 Jenkins 或 Tekton 这样的单一工具，但现在变成了两个工具。您可以使用 Jenkins 或 Tekton 进行 CI，而使用 GitOps 作为 CD 引擎。红帽与 Argo CD 等开源项目协作，实施 GitOps 框架。安装红帽 OpenShift GitOps Operator，并通过 Argo 开发新工具，以管理现有红帽 OpenShift 部署中的 GitOps。

OpenShift GitOps 可用于云服务、自管理环境和边缘计算。AWS 上的红帽 OpenShift 服务（ROSA）、微软 Azure 红帽 OpenShift（ARO）和红帽 OpenShift 专业版（OSD）等托管式云服务，有助于企业组织提高运维效率，重新专注于创新，并快速构建、部署和扩展应用。 

红帽 OpenShift 自管理版本（比如红帽 OpenShift 虚拟化引擎）可提供红帽 OpenShift 在部署、管理和扩展虚拟机（VM）方面的虚拟化功能。OpenShift GitOps 支持自动部署虚拟机，与 OpenShift 虚拟化引擎搭配使用，可帮助用户根据虚拟化需求迁移和管理其虚拟机。红帽构建的 MicroShift 将 Kubernetes 的强大功能和可扩展性带到边缘，使得应用程序只需编写一次，即可在所需之处运行：靠近数据源或靠近最终用户的位置。

红帽 Kubernetes 高级集群管理可提供 Kubernetes 集群生命周期的多集群管理。红帽高级集群管理采用订阅和渠道框架，结合放置规则，能够在多个集群中自动部署应用，并确保其符合预期状态模式。Kubernetes 高级集群管理使用 OpenShift GitOps 作为 GitOps 引擎。它提供了一系列功能，包括应用集管理、Argo 实例管理和 GitOps 集群配置以及策略部署辅助。 

不管您的系统当前状态如何，红帽 Ansible® 自动化平台都可使其进入预期状态。Ansible Playbook 以 YAML 语言编写，描述了系统的理想状态，这些配置文件通常保存在源代码控制中。Ansible 可作为 GitOps 工作流中的高效工具组件。Argo 和 GitOps 仅适用于 Kubernetes，而 Ansible 可用于 Kubernetes 之外的自动化任务，特别是那些需要执行命令式操作的任务。通过将红帽高级集群管理、红帽 OpenShift GitOps 和红帽 Ansible 自动化平台相集成，DevOps 团队可确保批量管理与维护相应的配置，从而改进 CI/CD 管道。

学习在 Kubernetes 上遵循 GitOps 实践的真实示例