共计 2662 个字符，预计需要花费 7 分钟才能阅读完成。
| 导读 | 在这篇文章中，我们将探索 GitOps 如何为基于容器化和微服务开发云原生解决方案的组织提供最佳服务。 |
GitOps 是一种自动化和管理基础设施和应用程序的模型，它通过许多团队已经使用过的相同 DevOps 最佳实践来完成，例如版本控制、代码审查和 CI/CD 管道等等。在实施 DevOps 过程中，我们虽然在软件开发生命周期找到了自动化的方法，但在基础设施安装和部署方面，仍然需要手工处理。使用 GitOps，团队可以自动化基础设施配置过程。这得益于我们能够将基础架构作为代码 (IaC)编写、在 Git 仓库中对代码进行版本控制以及基于云交付进行持续部署。
因为它具有提高生产力和软件质量的巨大潜力，很多公司一直在采用 GitOps，而它也最适合开发基于容器化和微服务的云原生解决方案的组织。
GitOps 带来的基础设施自动化的增长创造了为应用程序开发人员开发更具有“自助服务”方法的机会。熟练的开发人员可以使用基础设施即代码来声明他们的云资源需求，而不是协商云资源。这成为对基础设施的期望状态，集中存储起来并可以用作代码中声明的需求与运行环境的实际状态之间的不可变参考点。
自助服务方法解放了开发人员。它让开发人员更有效率，使他们能够专注于创新，并让他们的应用程序更快地推向市场。此外，它避免了开发人员和运营人员需要协商资源时可能引入的泥潭。
另一方面，经常存在一种误解，即运营自动化程度的提高意味着运营团队需要更少的人员，并且运营在管道中的角色正被边缘化。我们的观点恰恰相反; 我们认为 GitOps 和内部开发平台等现代方法为 Ops(平台团队)提供了振奋人心的机会，以提高他们的技能并为组织创造更多价值。在一个采用 GitOps 的高水平的云原生软件开发组织中，您可能会发现正是因为存在一个不断壮大的平台团队才让一切工作正常。
平台团队使用的实际技术可能会有所不同。在某些情况下，这可能只是一个封闭的 PaaS 解决方案。在其他情况下，它可以是创建适合组织需求的定制平台各种工具的组合。这使他们能够对基础设施资源和架构施加更大的影响和控制，并创建“护栏”，以执行简单、高效和标准化的云原生应用程序部署方法。
GitOps 有助于改善开发人员和运营团队之间的协作，提高他们的生产力，并增加部署频率。它使开发人员无需了解底层基础架构即可贡献功能，从而增强了开发人员的体验。同时，它通过代码审查和批准来控制操作。通过这些改进，团队可以更快、更安全地发布，以保持其在市场中的地位。
如果想让公司实施的 GitOps 模型发挥最大优势，例如整体工作流程的标准化和一致性，您需要考虑以下几点。
声明你的 IaC。
使用 Git 仓库进行 IaC 开发。
将属于应用程序代码生命周期一部分的实践也复制到基础架构代码中。
使用 Docker 和 Kubernetes 等技术，将您的环境、版本、配置和依赖项定义为代码，并确保它们在运行时得到强制执行。
逐渐将 GitOps 模型扩展到可以定义为代码的任何事物，例如安全性、策略、合规性以及基础架构之外的所有操作。
声明式代码提高了可读性和可维护性。CloudFormation、Terraform、Pulumi 和 Crossplane 是一些可能的声明性语言，您可以使用这些语言来定义您的基础架构配置。
当一切都定义为代码时，您可以使用 Git 仓库进行开发并探索诸如版本控制、协作和审计等内容。
一个正确的 Git 流程包括：
主分支，通常代表一个环境，如 dev、test、stage、prod 和在该环境上运行的状态。
当开发人员需要对代码进行更改时，他们会从主分支创建一个新分支。
当更改准备就绪时，开发人员会创建一个拉取请求，该请求应该由运营团队审核以验证和批准。安全和合规专家也可以参与此阶段，正确地验证环境的状态。
一旦获得批准，代码就可以合并到主分支并交付到测试或生产环境。
使用此工作流程，您可以跟踪谁进行了哪些更改并确保环境具有正确的代码版本。
图 2：GitOps 工作流程
如果您已经通过功能分支使用了Git 流程系统的拉取请求特性，那么您无需在 GitOps 的新流程上投入太多。此外，由于您的基础设施 (和其他操作) 也被定义为代码，您将能够实施相同的代码审查实践。
CI 流程负责构建应用程序代码并将其打包到容器镜像中。
CD 流程执行使最终状态与仓库代码中描述的系统所需状态保持一致的自动化操作。
最终，GitOps 将 CI 和 CD 视为两个独立的过程——CI 是一个开发过程，而 CD 是一个操作过程。
通常用于分离这些进程的 GitOps 方法是引入另一个 Git 仓库作为中介者。此仓库包含有关环境的信息，并且每次提交都会触发部署过程。另外会有一个组件，称为操作器，位于管道和编排工具之间。该操作器会不断将环境仓库中的目标状态与部署的基础设施中的实际状态进行比较，如果操作器检测到任何更改，它就会更改基础设施以匹配环境仓库。此外，它还监控镜像仓库以识别要部署的镜像的新版本。这样，CI 过程永远不会触及底层基础设施(例如，Kubernetes 集群)。
图 3：基于拉取的 GitOps 部署
将构建管道与部署管道解耦是针对错误配置的强大保护，这样做有助于实现更高的安全性和合规性。
GitOps 作为一种运营模型，使用了许多团队都知道的 DevOps 实践。使用 GitOps，您可以自动化基础设施配置过程，并将 Git 用作基础设施配置变更的单一事实来源。因此，要创建成功的 GitOps 模型，您需要对环境进行声明性定义。
如果您的团队中也有拉取请求工作流程，那就最好不过了。为了能够在基础架构代码上进行协作并创建操作更改，您应该提交一个拉取请求。随后，高级 DevOps 工程师和安全专家会审查该拉取请求以验证更改并在一切正常的情况下将它们合并到主分支中。
对于完整的 GitOps 实施，您需要 CI/CD 自动化设置参数并配置底层环境以及部署定义的代码。
最后，公司内部应该有一种支持性的组织文化。根据我们的经验，GitOps 方法很自然地形成了一种结构，在这种结构中，开发人员将会受益于自助服务基础设施资源自动化的增长，而平台工程师则可以在组织中扮演更有影响力的角色。这将是一种双赢的方法，使团队中的每个人都更团结一致，感到充实。
