💡 近日，由微软和英特尔联合发起的第二届开源云原生开发者日（Open Source Cloud Native Developer Day）上海站顺利落幕。极狐(GitLab) 资深云原生架构师郭旭东在会上进行了《深度探索 GitOps 平台的更多可能》主题演讲，与众多开发者共赴技术 “狂飙” 之旅。

以下内容整理自本次演讲。Enjoy～

什么是 GitOps ？

关于 GitOps 的定义，千人千面。我们这里将 GitOps 概括为一个公式：

XaC：Everything as Code，这是 GitOps 的重要特性之一：一切皆代码。例如 Infrastructure as Code 基础设施即代码；
MR&PR：PullRequst & MergeRequest，合并请求；
CI + CD ：Continuous Integration & Continuous Deployment/Delivery，持续集成与持续交付或部署。

GitOps 拥有四个关键原则：

声明式描述：由于 Git 充当所有 DevOps 操作的单一事实来源，因此整个系统在 Git 中使用 .yaml 文件进行声明性描述。声明式描述目标的性质，让计算机明白目标和结果，而非流程。它不用告诉计算机问题领域，从而避免随之而来的副作用；
版本控制：需要的系统状态在 Git 中进行版本管理，可以完全跟踪在任何给定时间点对系统状态所做的所有更改；
自动化：可以在 Git 代码中声明系统所需的状态，然后自动化系统以将所有批准的更改应用到系统；
保证：当所需状态与系统的实际状态不匹配时，软件代理会提醒配置更改，来确保差异的修正和告警。

同时，GitOps 也具有幂等性特性，即同一个操作，无论执行多少次，跟执行一次的效果一样。这是一个重要的特性，使得 GitOps 模型在各种异常情况下都能正确恢复。

因此，GitOps 在版本管理、分支策略、代码审查、历史记录、用户体验等方面天生具备优势。

如何构建高质量的 GitOps 平台？

GitOps 平台则是一种将 GitOps 工具与其他工具和服务集成在一起的平台，旨在提供更完整的 DevOps 自动化解决方案。

GitOps 平台通常需要提供以下能力：

GitOps 工具管理：将不同的 GitOps工具集成在一起，可以自动管理应用程序的部署、配置和更新。
自动化流水线：提供自动化管道，从代码提交到应用程序部署和监控全过程自动化。
代码审查：由于每一次代码提交都可能直接影响到云等基础设置，因此每次修改都需要充分 Review。
安全工具：提供安全性功能，如自动化漏洞扫描、访问控制和加密等。

2 种平台方案

搭建 GitOps 平台需要综合考虑成本 + 效率 + 体验，通常有两种方案：

1. DIY（ Do It Yourself）工具链

通过多个工具，自己组合形成一个 GitOps 平台。

这种方式有其弊端，例如：

工具链比较脆弱，可能导致整个软件研发端到端过程的不稳定性；
数据分散在各个系统中，通常需要保存多份，往往导致审计非常困难；
众多工具链所带来的运维工作既有风险，成本也昂贵。

2. AIO（ All In One）平台

DevOps 功能都集中在一个平台，工程师只需要在一个平台上完成整个软件开发生命周期。

这种方式的好处是：

花更少的时间维护工具，投入更多的时间研发软件产品；
通过单一的用户数据库和审核，保证工作的可跟踪性、可追溯性和可审核性；
自动化重复的工作任务，提供更高的工作吞吐量和效率；
确保整个软件的开发和运维过程是安全、一致且防篡改。

极狐GitLab 即是这样的一体化安全 DevOps 平台，并经过了数百万开发者的应用检验。

2 种仓库设计

「Multi-Repo」和「Mono-Repo」是两种代码仓库的管理风格：

Multi-Repo：多仓库，每个项目都用一个 Git 仓库托管。
Mono-Repo：单体仓库，统一用一个 Git 仓库管理所有的项目。

这两种模式，各有利弊，需要根据实际情况来选择：

Multi-Repo 模式把一个大问题分成几个小问题来解决，通过问题的细化，减少复杂度，从而让工作更加顺手，更加有保障；但其也有不可忽视的问题：为了保证一个功能的完整运行，即使再小的改动，也可能需要对所有的 Repo 进行更新，这是一个繁重的工作。

在 Mono-Repo 模式下，所有设计文档、源代码等都放在一个 Repo 里面，一次提交可以解决所有的问题；其最大的问题是随着程序规模不断增加，代码量、文档等随之增加，整个 Repo 会越来越大。

分支策略

分支策略可以理解为当一个团队需要就同一个项目进行协同时，如何借助 Git 这样的代码管理工具或软件协同管理工具来实现协同效应的管理机制。

分支策略主要分为单分支策略和多分支策略，二者的核心区别在于：

单分支更多强调的是长期分支，存在于整个项目生命周期中。
多分支更多强调的是短期分支，为临时目的而创建，一旦它们完成了职责并且代码被集成到主线（或另一个长期分支)中，就会被删除。

如果问 10 个不同团队是如何使用 Git 分支的，可能会得到 10 个不同答案。没有所谓的“最佳”分支策略，应该综合分析项目情况，找到最适合团队的策略。

GitOps 规模化

企业实现 GitOps 规模化，需要核心关注 4 个点：

➤ 实践复用

如果无法提高复用性，管理员需要投入大量时间精力在权限开通/关闭、加减成员等繁琐事务上，而高质量的复用能力，可以节约大量的人力和成本。

➤ 服务可用

无论 100、1000 还是 10000 用户规模，都需要确保服务可用。

➤ 集成拓展

需要确保能够随时拓展多种应用或产品集成。

➤ 变更审批

变更审批是必要的，尤其是在安全审批上，一点疏漏，可能造成全盘崩溃。

极狐GitLab GitOps 最佳实践

极狐GitLab GitOps 组件

极狐GitLab 推出极狐GitLab Kubernetes Agent Server（KAS），是用安全和云原生方式实现极狐GitLab 与 Kubernetes 集成的组件，实现以下功能：

GitOps Workflow ：在项目仓库里编写任意 K8s 对象的描述文件 (.yaml 或者 .json 格式)，都能实时部署到 K8s 集群中，无需执行 CI/CD；
CI/CD Workflow ：执行 CI/CD Pipeline 时，容器内注入了 KubeConfig 等 K8s 集群连接信息；可以在容器内执行 KubeCtl 、 Helm 等命令连接 K8s集群再执行部署。

图：极狐GitLab GitOps 组件概览

极狐GitLab GitOps 工作流程

极狐GitLab GitOps Workflow 使用 Pull 模型：极狐GitLab 作为单一可信源，当可信源侧的文件清单发生变更时，集群侧能够及时捕捉到此变更，从而完成变更清单部署。

极狐GitLab Kubernetes Agent 由两部分组成：位于集群侧的极狐GitLab Kubernetes Agent（agentk）和位于极狐GitLab 侧的极狐GitLab Kubernetes Agent Server (GitLab KAS)，能够很好的完成上述的GitOps Workflow。