使用 GitLab 创建动态且可扩展的多云部署管道

Volterra 的解决方案团队设计并维护了 Volterra 平台的许多潜在用例，以展示其潜在价值。 这些用例通常被制作成指导手册，供客户首次亲身体验 Volterra。

解决方案团队希望采用一种更快、自动化的方法，在内部按需部署我们的用例，并且尽可能减少人工输入。 我们的部署涵盖了使用 IaaS 平台（AWS、Azure 和 GCP）和私有数据中心环境（VMware vSphere 和 Vagrant KVM）的混合多云环境。 我们希望通过提供一个可以在任何环境中创建部署的单一工具来简化这些环境的管理，而无需单个用户为每个虚拟化平台或 IaaS 提供商创建额外的访问帐户或管理额外的用户凭据。 该工具还需要扩展以支持多个并发用户和部署。

总而言之，我们希望解决的核心问题是创建一个自动化解决方案用例部署工具，能够以尽可能少的用户输入扩展和处理混合多云环境中的并发部署。

碳变质计划（AC）

为此，我们创建了一个名为 Altered-Carbon 的项目，通常简称为 AC。AC 项目是一个动态 GitLab 管道，能够创建 20 多种不同的 Volterra 解决方案用例。 通过管道自动化，我们创建了单一命令“按钮部署”，允许用户根据需要或通过预定的每日 cron 作业轻松部署多个用例集群。

作为参考，在 AC 中，我们将每个部署称为一个STACK ，将每个唯一用例称为一个SLEEVE 。

项目开发

我们通过将用例 hello-cloud 自动化到第一个 SLEEVE 中开始了 AC 项目的开发。 hello-cloud 用例在 AWS 和 Azure 中创建一个 Volterra 站点，然后将这些站点组合成一个 Volterra VK8s（虚拟 Kubernetes）集群，并使用 VK8s 在两个站点上部署一个包含 10 个 pod 的应用。 我们首先利用 Volterra API 创建了额外的 terraform 模板和 shell 脚本，以便创建 CI/CD 管道可以管理的完全自动化工作流 GitLab。 然后我们开始致力于使该部署方法可重复使用和可扩展。

添加独特的命名约定是我们在设计中解决的下一个问题。 为了允许在单个 Volterra 租户环境中多次部署用例，我们需要确保在每个 STACK 中创建的资源具有唯一的名称，并且不会尝试在同一个 Volterra 租户环境中创建与其他 STACK 名称重复的资源。 为了解决可能出现的命名约定冲突，我们开始在将成为项目核心的管道触发器中融入用户提供的独特环境变量的想法。 环境变量STACK_NAME由 terraform 引入并使用，在与特定 STACK 相关的所有资源名称中包含用户定义的字符串。 AC 管道作业触发条件不是在提交时触发，而是设置为仅在使用 GitLab 项目 CI 触发令牌通过 GitLab 用户 API 调用触发时运行，从而允许通过人工输入或外部 API 调用控制管道。 通过使用类似于以下示例的 API 调用，它允许用户使用单个命令实现创建不存在资源冲突的多个部署的目标。

然后我们尝试从该模型中创建额外的部署选项。 hello-cloud 的 AWS 和 Azure 站点部署也是我们希望使用 AC 独立部署的单独用例。这导致我们在使用 GitLab 时遇到了第一个重大问题。 在 GitLab CI/CD 管道中，项目管道中的所有作业都是连接在一起的。 这是违反直觉的，因为我们的 hello-cloud 部署中需要的许多工作在我们的 AWS 或 Azure 站点部署中并不需要。 我们本质上希望一个 GitLab 项目 CI 管道包含多个独立的管道，这些管道可以在需要时通过单独的 CI 作业集按需触发。

为了解决这个问题，我们在包含 GitLab CI/CD仅/除外选项的管道结构中引入了环境变量 SLEEVE。 这允许根据管道触发器中提供的 SLEEVE 的值来限制在任何管道上触发的 CI 作业。 最后，我们有了最初的 3 个 SLEEVE 选项：simple-aws、simple-azure 和 hello-cloud。 每个 SLEEVE 都会定义用户希望部署的用例（从而控制触发管道中的 CI 作业）和 STACK_NAME 来命名任何触发管道创建的资源。 以下命令结构结合了两个环境变量，是至今仍在使用的最基本的 AC 命令：

下图直观地展示了改变 SLEEVE 环境变量将如何改变 AC 管道每次运行中触发的作业。

SLEEVE“simple-aws”管道：

SLEEVE“hello-cloud”管道：

我们还引入了额外的作业，如果在任何管道触发器中提供了环境变量 DESTROY，这些作业就会被触发。 这将提供一个反向选项来删除由 AC 创建的资源。以下是删除现有 STACK 资源的示例：

其他环境变量存储在 GitLab 中，具有默认值，可以通过向触发命令中添加值来覆盖这些默认值。 例如，我们的 Volterra 租户环境的 API URL 存储在 VOLTERRA TENANT 环境变量中。 如果用户将 VOLTERRA TENANT 环境变量添加到其 API 命令中，这将覆盖默认值并将部署重定向到所需位置。 这对我们的内部测试能力非常重要，因为解决方案团队管理着数十个 Volterra 租户环境，并且需要根据手头的任务在它们之间切换的能力：

这些可选的环境变量可用于在需要时对部署添加更高级别的控制，但对于不想管理这些额外开销的用户，可以提供更简单的默认部署选项。 它还允许我们轻松地在暂存环境和生产环境的部署之间切换，这对于我们最大的 AC 消费者来说至关重要。

解决方案用例： 每晚回归测试

如前所述，AC 中的每个 SLEEVE 代表一个 Volterra 用例，这通常是客户与产品的第一次互动。 确保这些用例功能齐全且无错误是给产品留下良好第一印象的关键。 在创建 AC 之前，测试用例以确认它们功能齐全并且与最新的 Volterra 软件和 API 版本保持同步是一项耗时的任务。 每个用例所需的手动部分对回归测试造成了限制，回归测试进行得不够频繁，而且容易出现人为错误。

然而，通过 AC 自动化，可以使用每日计划的作业来触发使用 SLEEVE 的任何特定用例的部署，然后删除部署完成或部署失败后创建的资源。 这在暂存和生产环境中都使用过，以测试最近的更改是否影响了用例部署或导致了 Volterra 软件中的错误。 然后，我们将能够更新在用例指南中发现的错误或快速捕获 Volterra 软件错误并提交解决方案单。

我们创建了一个单独的存储库和管道，其中包含计划作业，这些作业将使用 GitLab API 触发命令来同时使用不同的 SLEEVE 生成多个堆栈。 每个烟雾测试作业都将通过触发创建具有独立 AC 管道的堆栈来开始。 然后，烟雾测试作业将从管道触发调用的标准输出和 GitLab API 中获取管道 ID，以监视其触发的管道的状态。 当管道完成（无论成功或失败）时，它将在创建的相同 STACK 上运行销毁管道，以便在测试后删除资源。

下图详细描述了此过程，并展示了它在 AC 中为其创建和销毁命令触发的作业：

当烟雾测试管道失败时，我们能够提供可在 AC 触发器中使用的环境变量来重现问题。 这可以在我们的技术问题单中提供，以便我们的开发人员轻松地重新创建失败的部署。 然后，随着更多 SLEEVES 的完成，我们向 CI 管道添加了越来越多的作业，以实现更大的测试覆盖范围。 为了进一步提高这些测试的可见性，我们添加了 Slack 集成，并让烟雾测试作业将每个管道运行的成功或失败消息以及链接和详细信息发送到 Altered-Carbon 和 Smoke-Test 项目中相应的 CI 网页。

堆栈记录保存和管道 Web URL 导航

随着 AC 的发展、解决方案团队的更多用户以及创建越来越多的堆栈，项目的复杂性也随之增加。 这开始在导航 GitLab Pipeline Web UI 时产生根本问题。我们以一种非常非传统的方式使用 GitLab 管道，这使得 GitLab 管道 Web UI 难以用于跟踪与我们正在创建的 STACK 相关的单个管道运行。

通过 GitOps 工作流管理部署的 GitLab 管道似乎最适合用于静态定义的集群集。 在这种情况下，GitLab 管道的每次运行都会影响相同的集群和资源。 在这种情况下，这些集群的部署历史是 GitLab Web UI 中可视化的管道历史。但是，AC 是动态的，可处理不断变化的资源集，其中每个管道运行都可以利用完全不同的作业集，在不同的虚拟化提供商中管理不同的资源堆栈。 SLEEVE 和 STACK 约定产生的这种区别意味着很难确定哪个管道对应哪个堆栈。 例如，我们可以看看 AC 的 GitLab CI/CD 管道 Web UI：

从这个角度来看，如果不单独查看每个管道，我们就无法确定哪个 STACK 或 SLEEVE 正在发生变化。 当每天运行数百条管道时，找到创建或销毁任何一个特定 STACK 的特定管道运行或找到有关所述 STACK 的具体细节可能会很繁琐。 为了在 AC 开发早期解决这个问题，我们添加了一个简单的记录保存系统。 一项作业将在名为 stack-records 的任何管道之前运行。 此作业将在创建时收集有关堆栈的详细信息，并生成一个 json 文件，该文件将上传到用于存储我们的 tfstate 备份的 S3 存储桶中。 下面我们看到一个堆栈记录的例子：

stack-record.json 文件包含每个堆栈的详细信息，例如：

• 使用了哪个 Volterra 租户环境。
• 使用了什么SLEEVE。
• 如果 STACK 当前处于“应用”状态，或者其资源已被删除且处于“销毁”状态。
• 哪个 GitLab 用户创建了堆栈。
• 工作组列出了有权限更改 STACK 的其他用户。
• 最重要的是，管道数组将包含针对堆栈运行的每个管道运行的 Web URL、谁触发了管道、管道是否应用或销毁了堆栈以及管道何时被触发。

这提供了与任何一个堆栈相关的所有管道 URL 的记录历史记录，并且创建了一个可以通过 S3 API 调用访问这些文件的简单 CLI 脚本，以进一步简化该过程。 使用 AC 的用户可以使用这些文档来跟踪堆栈的历史记录，并通过查看堆栈记录来查看这些堆栈何时发生变化。

堆栈记录还允许我们对部署的管道实现一定级别的用户控制和错误捕获。 例如，在创建 AC 之后对 Volterra 软件所做的更改迫使我们开始将用于创建 Volterra 站点的站点集群名称（从 STACK NAME 值派生的值）限制为 17 个字符。 因此，我们在堆栈记录作业中添加了一项检查，如果堆栈名称违反了字符限制，则在运行任何部署步骤之前会导致管道失败。 添加了其他自定义控制，例如在 AC 中添加用户权限级别，以限制哪些用户有权更改由 AC 控制的特定堆栈。

• 管理员级别的权限，其中 AC 的顶级两名开发人员有能力为调试目的创建或销毁任何堆栈。- 所有者或创建者级别适用于最初创建 STACK 的 GitLab 用户。 他们的 GitLab 电子邮件值作为创建者记录在堆栈记录中，并且具有创建或销毁堆栈的能力。
• 然后我们有工作组级别的权限，GitLab 用户电子邮件可以添加到堆栈记录工作组数组中，授予创建者以外的用户应用或销毁 STACK 的权力。
• 不具备这些权限级别的用户将无法更改堆栈。 如果这样的用户试图更改他们没有权限的堆栈，那么堆栈记录作业将在部署任何资源之前失败。

内部使用和当前测试覆盖范围

如今，AC 已成为解决方案团队的核心，提供我们大部分的回归测试和自动化。 我们发现它的主要用途是回归烟雾测试、规模测试、产品计费测试以及产品演示中使用的简化部署。

自动化部署在我们每晚的回归测试中找到了最大的消耗者。 每天晚上，我们都会通过触发部署并拆除创建的资源来针对生产和登台环境测试每个 SLEEVES。 当发生变化时，我们能够快速检测到并提交错误报告以更新我们的指南。 我们目前的测试范围包括：

• 安全 Kubernetes 网关。
• Webapplication安全。
• 部署我们的标准 10 pod“hipster-co”应用和更轻量级的单 pod应用的网络边缘应用s。
• 你好，云。
• 跨 AWS、GCP、Azure、VSphere 和 KVM/Vagrant 的 CE 单节点单网络接口 volterra 站点。
• CE 跨 AWS、GCP、Azure、VSphere 和 KVM/Vagrant 的单节点双网络接口 volterra 站点。
• 扩展 CE 单节点单网络接口 volterra 站点部署（使用 GCP、VSphere 和 KVM），创建多个 ce 单节点单 nic 站点来测试 Volterra 扩展能力。
• 跨 AWS、GCP、Azure、VSphere 和 KVM/Vagrant 的 CE 单节点多网络接口 volterra 站点。
• 跨 AWS、GCP、Azure、VSphere 和 KVM/Vagrant 的 CE 多节点单网络接口 volterra 站点。
• 跨 AWS、GCP、Azure、VSphere 和 KVM/Vagrant 的 CE 多节点多网络接口 volterra 站点。

我们还拥有专门的规模测试套件，可以自动同时部署多达 400 个站点，以测试 Volterra 软件的扩展功能，并且已经使用 GCP、vSphere 和 KVM 进行了测试。

用例的快速自动化部署使得解决方案团队成员可以专注于其他任务，提高内部效率。 解决方案团队经常使用 AC 部署数十个 KVM、GCP 和 vSphere 站点来录制视频演示，从而节省了我们创建 Volterra 站点的时间，以便在现有的自动化基础上创建更复杂的基础架构。 这也用于日常 cron 作业，通过在记录计费信息的专门 Volterra 租户上自动部署 AWS、Web 应用程序安全、安全 Kubernetes 网关和网络边缘应用用例来测试 Volterra 平台的计费功能。

未来计划和路线图

我们对 AC 的使用已经取得了非常成功的结果，并且在不久的将来还会有更多的功能和改进添加到项目中。

该项目最大的新增功能是不断增加新的 SLEEVE 选项以涵盖额外的用例部署。 对于每个添加的新 SLEEVE，我们都会在夜间回归烟雾测试中添加一项新工作，为解决方案部署项目提供更多覆盖。 以前的大多数套管都专注于单节点和单网络接口用例，但我们最近将 SLEEVE 覆盖范围扩展到多节点 Volterra 站点集群和跨 AWS、Azure、GCP、VMWare 和 KVM/Vagrant 平台的多网络接口用例。

我们还致力于改进我们的堆栈记录系统。 我们将提高 AC 记录的详细程度，并通过合并 RDS 数据库存储来增强我们的记录的搜索功能。 我们的目标是能够提供更快的 AC 环境搜索和更具选择性的搜索功能，例如基于堆栈状态、堆栈创建者等的堆栈查找。 使用这些记录构建自定义 UI 以更有效地可视化使用 AC 创建的部署也在我们的计划中。