GitOps 工作流是什么样的？

GitOps 是一种现代的软件开发和部署方法，它利用 Git 存储库作为单一事实来源，来管理整个基础架构和应用生命周期。在此工作流中，开发人员将代码变更和基础架构配置提交到 Git 存储库时，便会触发自动化的 CI/CD 管道，这些管道会根据 Git 存储库的状态来构建、测试并部署应用和基础架构变更。

运维人员和管理员借助存储在 Git 中的声明式配置文件来定义基础架构预期状态，并运用诸如 Argo CD 等持续同步工具，以确保实际运行环境与 Git 存储库保持一致。这为代码和基础架构带来版本控制、协作功能以及可审计性，最终实现了高效且可靠的软件交付和基础架构管理。

GitOps 有助于对以前的手动流程引入自动化，从而帮助管理集群配置和应用部署。例如，借助 GitOps，您可以跨多集群 Kubernetes 环境管理红帽® OpenShift® 容器平台集群。

以上这些功能有助于缓解多云方法带来的挑战，例如，当工作负载要跨公共云、私有云甚至本地环境迁移时，需要确保一致性、安全性和相互协作。

本文将介绍 GitOps 工作流的基础知识。

在 GitOps 中，Git 存储库是系统和应用配置的单一事实来源。它包含了您环境的基础架构的声明性描述，并与 GitOps 工具（如 Argo CD）处理的自动化流程协同工作。通过自动化处理，可使您的环境的实际状态与预先描述的预期状态保持一致。您还可以使用存储库查看系统状态更改列表，因为 Git 历史记录提供更改跟踪。

此外，将基础架构和配置存储为代码有助于减少 IT 资源的无序蔓延。您可以将集群和应用的配置以代码形式存储在 Git 存储库中。 

基础架构即代码（IaC）是通过代码（而非手动流程）来管理和置备基础架构的方法。

利用 IaC，可以创建包含基础架构规范的配置文件。这样便可更轻松地编辑和分发配置，同时确保每次置备的环境都完全相同。通过对配置规范进行整理和记录，IaC 有助于实现配置管理，并避免发生未记录的临时配置更改。IaC 有两种实施方法：声明式或命令式。

声明式方法会定义系统的预期状态，包括所需的资源以及它们应具有的属性，随后 IaC 工具会为您进行相关配置。该方法还将保留系统对象的当前状态列表。另一方面，命令式方法则定义了实现预期配置所需的特定命令，之后需要以正确的顺序执行这些命令。

许多 IaC 工具都使用声明式方法，并会自动置备所需的基础架构。如果您更改了预期状态，则声明式 IaC 工具会为您应用这些更改。命令式工具则需要您确定该如何应用这些更改。

IaC 是实施 DevOps 实践和持续集成/持续交付（CI/CD）的一个重要组成部分。IaC 免除了开发人员的大部分置备工作，他们只需要执行一个脚本即可让基础架构准备就绪。如此一来，应用部署就不必再等待基础架构，而系统管理员也不用管理耗时的手动流程。

CI/CD 离不开贯穿应用整个生命周期（从集成和测试阶段，到交付和部署）的持续自动化和持续监控。
通过使用 IaC 的 DevOps 方法来协调开发和运维团队，可以减少错误、手动部署及不一致的情况。

我们可以认为 GitOps 是基础架构即代码（IaC）的一种演变，它使用 Git 作为基础架构配置的版本控制系统。 

管道是通过构建、测试和部署代码来驱动软件开发的过程，也称为持续集成和持续交付/部署（CI/CD）。其目标是通过自动化管道，最大限度地减少人为错误，并保持软件发布过程的一致性。管道中使用的工具可包括编译代码、单元测试、代码分析、安全防护和二进制文件创建。对于容器化环境，管道还会将代码打包至容器镜像中，以便跨混合云部署。

CI/CD 是 DevOps 方法的支柱，它使开发人员和 IT 运维团队能够并肩协作部署软件。随着自定义应用已日渐成为公司拉开差距的关键，代码发布的速度也决定着是否具有竞争优势。

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

要使用 GitOps 工作流发布新版本，需要在 Git 中提出拉取请求，这样可以变更集群的声明状态。GitOps Operator 是 GitOps 管道与编排系统之间的桥梁，它会接收提交（commit），并从 Git 中拉取新的状态声明。

一旦这些变化被批准和合并，它们将自动应用于实时基础架构。开发人员可以继续使用他们的标准工作流以及 CI/CD 实践。

在工作流中搭配使用 Kubernetes 与 GitOps 时，通常使用 Kubernetes Operator。

Kubernetes Operator 是一种封装、部署和管理 Kubernetes 应用的方法。它是一种特定于应用的控制器，可扩展 Kubernetes API 的功能，来代表 Kubernetes 用户创建、配置和管理复杂应用的实例。该 Operator 基于基本 Kubernetes 资源和控制器概念构建，但又涵盖了特定于域或应用的知识，用于实现其所管理软件的整个生命周期的自动化。

在 GitOps 中，Operator 会将存储库中的预期状态与所部署基础架构的实际状态进行比较。每当注意到实际状态与存储库中的预期状态存在差异时，Operator 便会更新基础架构。Operator 还可以监控容器镜像存储库，并以同样的方式进行更新，从而部署新的镜像。

可观测性是指能够通过检查系统或应用的输出、日志和性能指标来监控、测量和理解系统或应用的状态。在现代软件系统和云计算中，可观测性在确保应用和基础架构的可靠性、性能和安全性方面发挥着越来越重要的作用。

可观测性超越了传统的监控，能够帮助团队确定问题的根本原因。它能为利益相关者提供关于其应用程序和业务的洞察和信息，包括预报和预测可能出现的问题。

可观测性的好处：

• 更高的可靠性：在局面恶化之前检测并解决问题，最大限度减少停机时间，并确保系统依然可供用户使用。
• 高效的故障排除：深入了解系统行为，从而快速确定问题的根本原因并高效地解决问题。
• 优化的性能：确定需要优化的领域，如系统中的瓶颈或未充分利用的资源，从而提高资源分配效率并改进性能。
• 数据驱动的决策：接收最新的系统性能和行为信息，实现数据驱动决策和持续改进。

红帽® OpenShift® Observability 旨在解决现代架构方面的复杂性，它能在各种可观测性工具和技术之间搭建桥梁，创造统一的可观测性体验。该平台经过精心设计，可实时呈现、监控和分析各种系统指标、日志、跟踪和事件，帮助用户快速排除问题，以免对应用或最终用户造成影响。

红帽 OpenShift GitOps 是为您安装并配置 Argo CD 实例的 Operator。它可管理基础架构配置和应用部署，围绕这些配置存储库组织部署过程。该过程始终以至少两个存储库为核心：包含源代码的应用存储库以及定义应用预期状态的环境配置存储库

为了维护集群资源，红帽 OpenShift GitOps 使用开源工具 Argo CD，来处理应用的持续集成和持续部署（CI/CD）的持续部署部分。在红帽 OpenShift GitOps 中，Argo CD 的角色类似于控制器，它会根据 Git 存储库中定义的应用状态描述和配置进行监控。它将定义的状态与实际状态进行比较，然后报告偏离指定描述的任何配置。

管理员可以根据这些报告将配置重新同步到定义的状态，这一步可以通过手动或自动操作。在自动化流程中，配置本质上具有“自我修复”的能力，能够自动检测和纠正问题。

换而言之，红帽 OpenShift GitOps 可助力实现一种卓越的 GitOps 工作流。在此流程中，开发人员将他们的代码和配置更改提交到 Git 存储库，这些提交进而又触发自动化的 CI/CD 管道。这些管道负责根据 Git 存储库的状态来构建、测试和部署应用及基础架构。在这种情况下，红帽 OpenShift GitOps 就是使用存储在 Git 中的声明式配置文件来定义基础架构预期状态的 Operator。然后，Argo CD 会确保实际环境始终与 Git 存储库中指定的状态保持一致。这种方法有助于针对代码和基础架构实现版本控制、促进协作并提高可追溯性，最终简化软件交付和基础架构管理，同时提高可靠性。

现在，您已经从概念上理解了 GitOps 工作流如何提高工作效率，加快开发和部署速度，同时提升系统的稳定性和可靠性。

接下来，您可以亲自尝试一下使用 GitOps 进行开发。