Greptime 的 GitOps 实践

什么是 GitOps

当我们谈及 GitOps 时，我们必须首先聊聊 IaC（Infrastructure as Code）。事实上，IaC 并非新概念，而是由来以久。我们日常开发都在不知不觉地使用 IaC，比如：

使用 Vagrantfile 来创建虚拟机；
使用 Vimscript 来配置个性化的 Vim 编辑器；
使用 Dockerfile 来构建容器；

等等。上述所提及的配置工具本质上就是 IaC 工具。顾名思义，IaC 的核心就是用代码化的方式来构建基础设施，小到一个容器镜像，大到一个超大型的复杂集群，都能实现一次编写，到处部署。

步入云计算时代后，开发者也迫切需要 IaC 来描述公有云上的资源。像 AWS 和 GCP 这类公有云厂商都提供了其云服务的资源化 API，以方便用户使用 API 来定义自己的基础设施。与此同时，像 Terraform 和 Pulumi 这类更先进的 IaC 工具，基于公有云的 API 做了更简洁的抽象，进而为开发者定义云上资源提供了更好的 IaC 选择。

到了如今的云原生时代，K8s 成了容器编排事实上的标准。许多服务都以容器化的方式运行在 K8s 中，而 K8s 原生的声明式和面向资源的 API 天然就适配了 YAML 这种配置语言。我们可以把 YAML 当作“汇编语言”来描述 K8s 中的服务，YAML 成了定义 K8s 服务的 IaC。GitOps 则是基于 IaC 之上的一套 DevOps 工作流。没有 IaC，也就没有办法建立 GitOps。

GitOps 的关键要素是：

所有基础设置都必须 IaC 化；
用 Git 来管理 IaC 代码，并复用 Git 工作流。我们可以使用 Pull Requests 来提交变更和 Code Review，用 Git History 来做变更审计；

简而言之：GitOps 把我们的基础设施配置也变成一个纯粹的代码项目来维护。

为什么使用 GitOps

使用 GitOps 有很多好处，我们认为以下几点尤为关键：

Single Source of Truth：基础设施的所有配置细节可以代码化维护，从而避免配置漂移、雪花实例等这一类常见的配置问题。
用代码化方式解决持续集成中的各种问题：我们可以用各种编程的方式来解决持续集成的问题，比如配置不同 CI 插件来做变更检查；为配置代码编写测试代码等。这种模式为持续集成提供了极大的灵活度。
规模化运维能力：我们不再需要 ClickOps，代码就是开发人员最好的杠杆。我们可以用较低的代价来管理较大规模的集群。

关键技术决策

Greptime 是一家致力于构建下一代云原生时序数据库的初创公司，我们没有任何运维开发上的历史包袱，因此我们从 Day 1 就积极拥抱 GitOps。

我们在设计 GitOps 时遵循以下几个简单的原则：

落地为王：先实现 GitOps 最关键的几个要素，然后再持续迭代和改进。一定要把 IaC 项目也当作一个代码项目持续迭代，允许初期存在不完美之处，但一定要保证有充足的弹性进行后期迭代。
简单务实：避免使用过于复杂的技术方案，尽可能选择相对成熟、封装较少且易于维护的技术。

因此，我们做了如下关键的技术决策：

使用 Monorepo：我们将云上基础设施和 K8s 服务代码都统一维护在一个叫 greptime-config 的代码仓库中。我们只有一条时间线，那就是 main 分支，main 分支永远真实地反应当前基础设施的状态。整个仓库会开放给所有 Greptime 内部的开发者，任何人都可以提交代码，只要通过了 Owner 的 Code Review，每一个人能很便捷地修改基础设施。仓库也不会存放任何敏感数据，所有的敏感数据都会预先用 sealed-screts 服务进行加密存储或者存储于 GitHub Secrets。
使用 Terraform 描述了云上基础设施：Terraform 是目前描述云上资源生态最好的 IaC 工具，而且 HCL 这门 DSL 也相对简单易用。此外，我们还使用 Terragrunt 来简化 Terraform 代码。基于 Terraform，我们可以很方便地运维 EKS、RDS、S3、Load Balancer 等这类云上资源。
使用 Helm 来打包 K8s 服务：Helm 本质上是一个 YAML 的客户端渲染引擎，它只对 K8s 原生的 YAML 做了很薄的封装，因此易用性不够。但是 Helm 是目前 K8s 生态服务的打包的事实标准，而且整体逻辑足够简单，因此我们还是选用 Helm 来打包服务。
使用 Argo CD 来部署 K8s 服务：Argo CD 是今年从 CNCF 毕业的开源项目。它可以 Watch 我们的代码仓库并实时地进行部署和配置校准，同时还有一个好用的 Web UI 和活跃的社区，整体架构也不难维护。实际使用时，我们全局会用一个 Argo CD 元集群来管理多个地域不同的 K8s 集群的服务。
使用 GitHub Action：由于我们使用 GitHub，所以很自然地使用 GitHub Action。我们通过给 GitHub Action 配置不同的 Action，很方便地集成了一系列功能。一旦我们的代码合并入 main 分支，GitHub Action 便开始为我们进行部署。

综上，我们 Greptime 的 GitOps 的整体架构可如下图所示：

展望未来

我们认为，GitOps 可以成为 xOps 的基石：

我们使用 Infracost 这类工具，可以很方便地监控云上费用，从而实施高效的 FinOps；
通过编写不同的 CI 插件，我们可以很容易地集成各种安全的变更防御策略，在用户提交代码之时就进行检查和阻断。基于这种模式，我们未来也很容易在 CI 中加载安全规则来实施 DevSecOps；
集成 IM（比如 Slack Bot）来实现 ChatOps，更进一步，我们还可以引入类似于 ChatGPT 这类大语言模型（LLM）来辅助日常运维：比如让 ChatGPT 帮忙生成配置接着再自动发起 Code Review；

GitOps 是一个充满想象力的 DevOps 实践，我们会在后续的业务迭代中不断探索 GitOps 更多的可能性。