本文永久链接: https://www.xtplayer.cn/cicd/create-a-full-fledged-gitops-pipeline/

在软件交付领域,GitOps 是近期的热门趋势,它沿袭并扩展了 DevOps、基础架构即代码和 CI/CD 等趋势。我们此前发布了许多关于 GitOps 的入门文章,您可以在公众号后台回复【Git 文章】获取 GitOps 文章合集。

GitOps 的优势可以简单地归纳如下:

  • 自由地审计更改
  • 持续集成和交付
  • 更好地控制更改管理

然而,现实情况却是构建 GitOps 流水线并非易事,它涉及到许多大大小小的决定,而这些决定会给实施工作带来许多麻烦。我们将这些决定称为“GitOps 架构”,它可能会导致实施过程中面临许多挑战。

好的方面是只要有一定的规划和经验,就可以大大减少过渡到 GitOps 交付模式的痛苦。

在本文中,我将通过一家公司的故事来解释其中的一些挑战。这家公司从一个零散的小创业公司采用 GitOps,成长为一家规范的跨国企业。虽然这种加速成长的情况很少见,但它确实反映了大型组织中的许多团队从概念验证,到最小可行性产品(minimum viable product),再到成熟系统的经验。

简单的开始

如果你刚刚开始,最简单的做法是创建一个单一的 Git repo,将所有需要的代码都放在里面。其中可能包括:

  • 应用程序代码
  • Dockerfile,用于构建应用程序镜像
  • 一些 CI/CD 流水线代码(例如 GitLab CI/CD 或 GitHub Actions)
  • Terraform,以配置运行应用程序所需资源

此外,所有的更改都是直接对 master 进行改动,因此更改可以直接生效。

这一方法的主要优势在于你有单一的参考点,以及所有代码都会紧密集成在一起。如果您的所有开发人员都受到完全信任,并且速度就是一切,那么这一方法会持续生效。

不幸的是,随着你的业务量不断增长,这种方法的弊端很快就会显现出来。

首先,随着越来越多的代码被添加到代码库中,代码库规模的膨胀会使得工程师们陷入困惑,因为他们会遇到更多必须解决的更改之间的冲突。如果团队成员大幅增长,那么随之而来的重新分配工作或合并会导致进一步的混乱。

其次,如果您需要分开控制流水线运行,则会遇到困难。有时,您只想快速测试对代码的更改,而不是进行部署以实现完整的端到端交付。这种方法在整体性方面产生了越来越多需要解决的问题,随着这些更改的进行可能会影响其他人的工作。

第三,随着您的成长,您可能会希望工程师和团队之间的责任边界更加细化。这可以通过一个单一的 repo 来实现,并且一个 repo 通常是一个更清晰和更干净的边界。

分离 Repository

随着业务的增长,流水线会越来越拥挤,merge 开始变得痛苦。此外,您的团队也需要专业化,将不同的责任领域划分给不同的成员。

所以你需要将 Repo 分离出来。这时,你首先要面对大量的决定,譬如 repo 应该分离到什么程度?是否需要为应用程序代码建立一个单独的 repo?看起来是不是很合理?然后把 Docker 构建的东西也一起放进去?那这样的分离其实没有什么意义。

那所有团队的 Terraform 代码呢?应该放在一个新的 repo 里吗?这听起来很合理,但是:新创建的中央“平台”团队想要控制对 AWS 中核心 IAM(身份和访问管理)规则定义的访问,而团队 RDS 配置代码也在其中,开发团队需要定期对其进行调整。

所以你决定将 Terraform 分离成两个 repo:一个是“平台”repo,一个是“特定应用程序”repo。这就带来了另一个挑战,因为你现在还需要分离 Terraform 的状态文件。这并不是一个无法解决的问题,但这也并不是您所习惯的快速功能交付,所以产品经理将不得不解释为什么功能请求所需的时间比之前更长。

不幸的是,这些 GitOps 决策还没有既定的最佳实践或模式。

分离的问题还不止于此。以前,流水线内构建的组件之间的协调是微不足道的(因为所有需要的组件都是共处的),而现在你必须协调 repo 之间的信息流。例如:当构建一个新的 Docker 镜像时,这可能需要触发集中式平台 repo 中的部署,同时将新的镜像名称作为触发的一部分传递过来。

同样,这些也不是无法解决的问题,但在构建 GitOps 流水线的早期,这些挑战更容易实现。后来,当步骤、政策和流程更加成熟时,再做出改变就需要付出更多的时间代价。

分布式 vs 集中式

你的业务正在增长,你正在构建越来越多的应用程序和服务。越来越明显的是,在如何构建和部署应用程序方面,你需要某种结构上的一致性。中央平台团队需要尝试执行这些标准。但是你可能会遭到开发团队的反对,他们认为与在 DevOps 和 GitOps 出现之前,在集中式 IT 中他们被赋予了更多的自治和控制权。

如果上述情况您觉得似曾相识,那可能是因为 GitOps 和应用架构领域的单体与微服务争论之间有些类似。就像你在这些争论中看到的那样,随着系统的成熟,规模和范围的扩大,分布式和集中式 IT 之间的紧张关系会越来越频繁地出现。

从某种层面上来说,你的 GitOps 流程就像其他分布式系统一样,如果你设计得不好,其中一个部分出现问题可能会产生难以预料的问题。

环境

在你决定分离 repo 的同时,你意识到你需要一种一致的方式来管理不同的部署环境。而直接上线已经行不通了,因为此时需要 QA 团队,在上线之前测试更改。

现在你需要为你的应用镜像在测试和 QA 环境中指定不同的 Docker 标签,你可能还希望在不同的环境中启用不同大小的实例大小或副本功能。你如何在源码中管理这些不同环境的配置?一个比较直接的方法是为每个环境建立一个单独的 Git 仓库(如:super-app-dev,super-app-qa,super-app-live)。

分离 repo 有 “泾渭分明” 的好处,就像我们在上面划分 Terraform 代码时看到的那样。然而,很少有人最终会喜欢这种解决方案,因为大多数团队不具备 Git 知识和相关专业水平,进而在不同的 repo 之间移植更改。更为复杂的是,repo 之间必然会存在很多重复的代码,而且随着时间的推移,也可能会出现很多漂移(drift)。

如果你想把事情保持在一个单一的 repo 中,你至少有三种选择:

  • 每个环境都有一个目录
  • 每个环境都有一个分支
  • 每个环境有一个标签

同步步骤选择

如果你严重依赖 YAML 生成工具或模板,您可以考虑另一种方式。例如,Kustomize 强烈鼓励基于目录的环境分离。如果您使用的是原始 YAML,那么分支或标记的方法会更适合您。

运行时环境颗粒度

然而,在您的运行时环境中,可以选择您想要什么级别的分离。在集群层面,如果您使用的是 Kubernetes,你可以在以下几种情况下选择:

  • 一个集群管理所有
  • 每个环境一个集群
  • 每个团队一个集群

在极端情况下,你可以把所有的环境放到一个集群中。不过通常情况下,在大多数组织中至少有一个单独的集群用于生产。

一旦你想好了你的集群策略,在命名空间层面,你仍然可以选择:

  • 每个环境都有一个命名空间
  • 每个应用程序/服务拥有一个命名空间
  • 每个工程师拥有一个命名空间
  • 每个构建都有一个命名空间

平台团队通常从 “dev”、“test”、“prod” 的命名空间设置开始,然后才意识到他们想要更精细地分化团队的工作。

你也可以混合和匹配这些选项——例如,为每个工程师提供”desk testing “命名空间,以及每个团队的命名空间。

总 结

我们在这里只是对成熟的 GitOps 流程所需的决策领域做了一些简单的介绍。如果您的企业真的成长为那家跨国企业,你也可以考虑 RBAC/IAM 等要求。

通常情况下,推出 GitOps 会让人觉得只是一种投资,可能最终没有太多令人满意的产出。但是在 GitOps 之前,团队常常会经历混乱和延迟,因为没有人能够确定任何东西应该是什么状态。这些都会导致二次成本,因为审计人员会进行抽查,而因意外和未记录的更改而导致的中断则占据了员工大量的注意力,这是一个很高的成本。

然而,随着你的 GitOps 流程的愈发成熟,好处倍增,该流程会解决许多之前存在的问题。但更多的时候,你面临的压力是要更快地展现出 GitOps 流程的优势。

目前 GitOps 最大的挑战是,没有既定的模式或是最佳实践来指导你的选择。GitOps 顾问,通常也只是引导团队找到最适合他们的解决方案,并根据经验将团队往某些方向引导。

但我观察到的情况是,早期因为看起来 “太复杂”而被放弃的选择,往往后来都会为此后悔。这并不意味着你应该直接跳到为每个构建创建一个命名空间,每个团队拥有一个 Kubernetes 集群的程度,原因有二:

  • 每当你给 GitOps 架构增加复杂性时,你最终都会增加交付一个可行的 GitOps 解决方案的成本和时间
  • 你可能真的永远都不需要这种设置

在我们接受这个领域的可行标准之前,正确的 GitOps 架构永远是一门艺术,而不是科学。