本文永久链接: 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 架构永远是一门艺术，而不是科学。