小编点评

**GitOps 概述** GitOps 是一个自动化和管理基础架构和应用程序的模型，它基于许多团队已使用的 DevOps 最佳实践。 **主要优势** * 提高生产力和软件质量 * 适合开发基于容器化和微服务的云原生解决方案的企业 * 自动化基础架构配置过程 **关键步骤** 1. 声明式代码（Everything as Code） 2. Git 存储库用于 IaC 开发 3. 将基础架构代码中的一部分复制到应用程序代码中 **审查程序** * 主分支：开发环境 * 拉取请求：进行代码更改 * 拉取请求：验证和批准代码 * CI 流程：构建应用程序代码 * CD 流程：执行自动化部署 **优点** * 简化基础架构配置 * 提高开发效率 * 确保代码质量 * 增强基础设施安全

正文

GitOps 是一种自动化和管理基础架构和应用程序的模型，通过许多团队已经使用的相同 DevOps 最佳实践来形成的模型，例如版本控制、代码审查和 CI/CD 流水线。在实施 DevOps 时，我们找到了自动化软件开发生命周期的方法，但在基础设施设置和部署方面，仍然依靠手动过程。借助 GitOps，团队可以自动化基础架构配置过程，同时能够编写 IaC、在 Git 存储库中对代码进行版本控制，以及将持续部署原则应用于云交付。
 

许多公司一直在采用 GitOps，因为 GitOps 具有提高生产力和软件质量的巨大潜力，同时它也最适合开发基于容器化和微服务的云原生解决方案的企业。
 

GitOps 如何优化开发运维环境

GitOps 带来的更好的基础设施自动化，创造了为应用程序开发人员开发“自助服务”的机会。熟练的开发人员可以使用基础设施即代码来声明他们的云资源需求，这成为基础架构的理想状态，因为集中存储并作为代码中规定的要求与实时环境的实际状态之间的不可变参考点。自助服务方法正在解放开发人员，提高了开发人员的工作效率，使他们能够专注于开发和创新，并更快地将应用程序推向市场。此外，自助服务避免了当开发人员和运营商需要协商资源时可能产生的一些问题与矛盾。
 

另一方面，人们经常误认为运维自动化程度的提高意味着运维团队需要的人员更少，并且运维在流水线中的作用被边缘化了。然而并非如此，我们相信 GitOps 和内部开发人员平台等现代方法为运维团队提供了更多机会来提高他们的技能并为企业创造更多价值。运维团队实际使用的技术可能会有所不同。在某些情况下，可能只是一个 PaaS 解决方案。在其他情况下，可能是各种工具的组合从而创建适合企业需求的定制平台。这使运维人员能够对基础设施资源和架构施加更大的影响和控制，并创建“护栏”，强制采用简单、高效和标准化的方法来部署云原生应用程序。
 

GitOps 有助于改善开发人员和运维团队之间的协作，提高他们的生产力，并提高部署频率。GitOps 使开发人员能够在无需了解底层基础架构的情况下贡献功能，从而有效提高了开发人员的体验。同时，它通过代码审查和批准来控制操作。通过这些改进，团队可以更快、更安全地发布软件，从而保持企业在市场中的地位。
 

实施 GitOps 的三个关键步骤

想要获得在公司中实施 GitOps 模型的最显著优势，例如整体工作流程的标准化和一致性，建议企业考虑以下事项。

一切皆代码（Everything as Code）

• 声明 IaC。
• 使用 Git 存储库进行 IaC 开发。
• 将作为应用程序代码生命周期一部分的实践复制到基础架构代码中。
• 使用 Docker 和 Kubernetes 等技术，将环境、版本、配置和依赖项定义为代码，并确保它们在运行时得到执行。
• 逐渐将 GitOps 模型扩展到任何可以定义为代码的事物，例如安全性、策略、合规性和基础设施之外的所有操作。

图片来源：Microtica
 

声明式代码提高了可读性和维护性。CloudFormation、Terraform、Pulumi 和 Crossplane 是一些可用的声明性语言，企业可以尝试使用这些语言来定基础架构的外观配置。当一切都定义为代码时，可以使用 Git 存储库进行开发并探索版本控制、协作和审计等优势。
 

审查程序

正确的 Git 流程包括：

• 主分支，通常代表一个环境，如 dev、test、stage、prod 和在该环境上运行的状态。
• 当开发人员需要对代码进行更改时，他们会从主分支创建一个新分支。
• 当更改准备就绪时，开发人员创建一个拉取请求，该请求应由操作人员审查以验证和批准。安全和合规专家也可以参与此阶段以正确验证环境状态。
• 一旦获得批准，代码就可以合并到主分支中并交付给测试或生产。
• 使用此工作流程，可以跟踪谁进行了哪些更改并确保环境具有正确的代码版本。
  
  图片来源：Microtica
   

如果企业已经通过使用功能分支和拉取请求来利用 Git 流程系统，那就不需要为新的 GitOps 工作流程投入太多。此外，由于基础架构（和其他操作）被定义为代码，企业将能够实施相同的代码审查实践。

独立的构建和部署过程（CI 和 CD）

• CI 流程负责构建应用程序代码并将其打包到容器镜像中。
• CD 过程执行自动化以使最终状态与系统的期望状态一致，如存储库代码中所述。
   

最终，GitOps 将 CI 和 CD 视为两个独立的流程——CI 作为开发流程，CD 作为运营流程。 通常用于分离这些进程的 GitOps 方法是引入另一个 Git 存储库作为中介。这个 repo 包含关于环境的信息，每次提交都会触发部署过程。在流水线和编排工具之间有一个操作器组件。操作员不断地将环境存储库中的目标状态与已部署基础设施中的实际状态进行比较。如果操作员检测到任何更改，则会更改基础架构以适应环境存储库。此外，它还监控镜像仓库以识别要部署的新版本镜像。这样，CI 过程就不会触及底层基础设施（例如，Kubernetes 集群）。

图片来源：Microtica
 

将构建流水线与部署流水线分离是防止错误配置的有力保护措施，有助于实现更高的安全性和合规性。
 

结论

使用 GitOps，企业可以自动化基础架构配置过程，并将 Git 用作基础架构的单一真实来源。因此，要创建成功的 GitOps 模型，需要对环境进行声明性定义。建议企业团队最好具备拉取请求工作流程，以便在基础架构代码上进行协作并创建操作更改。资深 DevOps 工程师和安全专家随后审查拉取请求以验证更改并在一切正常时将它们合并到主分支中。企业需要使用 CI/CD 自动化来供应和配置底层环境以及部署定义的代码，以确保完整的 GitOps 实施。
 

最后，公司内部应当培养一种支持性的文化。GitOps 流程很自然地形成了一种结构，在这种结构中，开发人员可以从自助服务基础设施资源中获得更高的自动化程度，而运维工程师可以在过程中扮演更有影响力的角色。
 

参考链接：
https://danielkummer.github.io/git-flow-cheatsheet/
https://dzone.com/articles/3-steps-to-developing-a-successful-gitops-model