使用GitLab构建动态、可扩展的多云部署流水线

Alex Cohen

Volterra解决方案团队设计并维护了Volterra平台的众多潜在用例，以展示其潜在价值。这些用例通常会编写成操作指南，帮助客户首次亲自体验Volterra。

解决方案团队希望采用一种更快捷的自动化方法，在内部按需部署用例，并尽可能减少人工干预。部署范围涵盖混合多云环境，包括IaaS平台（AWS、Azure和GCP）以及私有数据中心环境（VMware vSphere和Vagrant KVM）。我们希望通过提供一个可在任何环境中创建部署的统一工具，简化这些环境的管理，同时无需每位用户为各个虚拟化平台或IaaS提供商创建额外的访问账户或管理额外的用户凭据。该工具还需要具备扩展能力，以支持多个用户和部署并发运行。

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

Altered-Carbon项目（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的应用。我们先创建更多terraform模板和shell脚本，并利用Volterra API构建可由GitLab CI/CD流水线管理的全自动化工作流。随后，我们着手让这种部署方法可复用且可扩展。

接下来，我们在设计中解决了如何添加唯一命名约定的问题。为了在单个Volterra租户环境中多次部署该用例，需要确保每个STACK中创建的资源都有唯一名称，避免与同一Volterra租户环境中其他STACK的资源重名。为解决潜在的命名约定冲突，我们开始在流水线触发器中引入由用户提供的唯一环境变量，这一机制后来成为项目的核心。我们引入了环境变量STACK_NAME，terraform使用该变量，将用户定义的字符串加入与特定STACK关联的所有资源名称中。AC流水线作业不再由提交触发，而是仅在GitLab用户使用GitLab Project CI Trigger Token发起API调用时运行，从而可通过人工输入或外部API调用控制流水线。通过类似以下示例的API调用，用户只需一条命令即可创建多个部署，同时避免资源冲突。

随后，我们尝试基于此模型创建更多部署选项。hello-cloud的AWS和Azure站点部署也是独立的用例，我们希望使用AC分别进行部署。这让我们遇到了使用GitLab时的第一个重大问题。在GitLab CI/CD流水线中，项目流水线内的所有作业都相互关联。这与我们的预期不符，因为hello-cloud部署所需的许多作业并不适用于AWS或Azure站点部署。实际上，我们希望在一个GitLab项目CI流水线中包含多个独立流水线，并可在需要时按需触发各自的一组CI作业。

为解决此问题，我们在管道结构中引入了环境变量 SLEEVE，并结合使用 GitLab CI/CD 的 only/except 选项。这样便可根据管道触发器中提供的 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存储在VOLTERRATENANT环境变量中。如果用户在API命令中添加VOLTERRATENANT环境变量，就会覆盖默认值，并将部署重定向到所需位置。这对内部测试能力非常重要，因为解决方案团队管理着数十个Volterra租户环境，需要根据当前任务在这些环境之间切换：

这些可选环境变量可在需要时用于增强对部署的控制，同时为不希望管理这些额外开销的用户提供更简单的默认部署选项。借助这些变量，我们还可以轻松切换预发布环境和生产环境中的部署，这对我们最大的AC使用方至关重要。

解决方案用例：夜间回归测试

如前所述，AC中的每个SLEEVE都代表一个Volterra用例，而这些用例往往是客户首次接触该产品的途径。确保这些用例正常运行且没有缺陷，是让客户对产品形成良好第一印象的关键。在创建AC之前，需要测试这些用例，以确认其正常运行，并与最新的Volterra软件和API版本保持同步，这是一项非常耗时的工作。每个用例都包含需要手动完成的部分，因而限制了回归测试的开展，导致测试频率不足，而且容易出现人为错误。

不过，借助AC自动化，可以通过每日计划任务，使用SLEEVE触发任意特定用例的部署，并在部署完成或失败后移除所创建的资源。此方法同时用于预发布环境和生产环境，以测试任一环境中的近期变更是否影响了用例部署，或导致Volterra软件出现缺陷。这样，我们就能更新用例指南中发现的缺陷，或快速发现Volterra软件缺陷并提交解决工单。

我们创建了单独的代码仓库和流水线，其中的计划作业会使用GitLab API触发命令，通过不同的SLEEVE并发生成多个堆栈。每个冒烟测试作业首先会触发一条独立的AC流水线来创建堆栈。随后，冒烟测试作业会从流水线触发调用的stdout中获取流水线ID，并使用GitLab API监控其所触发流水线的状态。流水线完成后（无论成功还是失败），该作业都会针对其创建的同一STACK运行销毁流水线，以移除测试后留下的资源。

下图详细说明了此流程，并展示了其创建和销毁命令在AC中触发的作业：

当冒烟测试流水线失败时，我们可以提供可在AC触发器中使用的环境变量，以重现问题。我们可以将这些变量添加到技术问题工单中，方便开发人员重现部署失败。随后，随着更多SLEEVES完成，我们逐步向CI流水线添加更多作业，以扩大测试覆盖范围。为进一步提高这些测试的可见性，我们还集成了Slack，让冒烟测试作业发送每次流水线运行的成功或失败消息，并附上Altered-Carbon和Smoke-Test项目中相应CI网页的链接及详细信息。

堆栈记录保存和流水线Web URL导航

随着AC不断发展、解决方案团队的更多用户加入，以及创建的堆栈越来越多，项目复杂性也随之增加。这开始给GitLab Pipeline Web UI中的导航带来根本性问题。我们使用GitLab流水线的方式很不常规，导致难以通过GitLab Pipeline Web UI跟踪与所创建STACK相关的各次流水线运行。

通过GitOps工作流管理部署的GitLab流水线，似乎更适合用于一组静态定义的集群。在这种情况下，GitLab流水线每次运行都会影响相同的集群和资源，而这些集群的部署历史就是GitLab Web UI中显示的流水线历史记录。然而，AC是动态的，所处理的资源集也在不断变化。每次运行流水线时，都可能使用完全不同的一组作业，通过不同的虚拟化提供商管理不同的资源STACK。SLEEVE和STACK约定造成的这种差异，使得确定流水线与STACK之间的对应关系非常困难。例如，可以查看AC的GitLab CI/CD流水线Web UI：

在此视图中，如果不逐一查看每条流水线，就无法确定某条流水线正在更改哪个STACK或SLEEVE。每天运行数百条流水线时，要找到创建或销毁某个特定STACK的具体流水线运行记录，或查找该STACK的具体详细信息，可能会非常繁琐。为尽早解决这一问题，我们在AC开发过程中添加了一个简单的记录系统。每条流水线运行前，都会先运行一个名为stack-records的作业。该作业会在创建堆栈时收集其详细信息并生成一个JSON文件，然后将该文件上传到用于存储tfstate备份的S3存储桶。下面是一个堆栈记录示例：

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

• 使用了哪个Volterra租户环境。
• 使用了哪个SLEEVE。
• STACK当前是以“apply”状态运行，还是其资源已通过“destroy”状态移除。
• 创建该堆栈的GitLab用户。
• 一个工作组，其中列出了有权更改STACK的其他用户。
• 最重要的是，一个pipelines数组，其中包含针对该STACK执行的每次流水线运行的Web URL、流水线触发者、流水线是应用还是销毁了STACK，以及流水线的触发时间。

这样便可记录与任一堆栈关联的所有流水线URL的历史。为进一步简化流程，我们还创建了一个简单的CLI脚本，可通过S3 API调用访问这些文件。使用AC的用户可以利用这些文档跟踪堆栈历史，并通过查看堆栈记录了解这些堆栈的变更时间。

堆栈记录还让我们能够对所部署的流水线实施一定程度的用户控制和错误捕获。例如，AC创建后，Volterra Software的一项变更要求我们开始将创建Volterra站点时使用的站点集群名称（由STACKNAME值派生）的长度限制为17个字符。因此，我们在堆栈记录作业中添加了一项检查：如果STACKNAME超出字符限制，流水线会在运行任何部署步骤之前失败。此外，我们还添加了其他自定义控制措施，例如在AC中设置用户权限级别，以限制哪些用户有权更改由AC控制的特定堆栈。

• 管理员级权限：AC的两名主要开发人员可以创建或销毁任何堆栈，以便进行调试。
  所有者或创建者级权限：适用于最初创建STACK的GitLab用户。该用户的GitLab电子邮件地址会作为创建者记录在堆栈记录中，并且该用户可以创建或销毁堆栈。
• 然后是工作组级权限。可将GitLab用户的电子邮件地址添加到堆栈记录的工作组数组中，使创建者以外的用户能够应用或销毁STACK。
• 不具备上述任何权限级别的用户无法更改stack。如果此类用户尝试更改其无权操作的stack，stack-records作业将在部署任何资源之前失败。

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

如今，AC已成为解决方案团队的核心工具，承担了大部分回归测试和自动化工作。其主要用途包括回归冒烟测试、规模测试、产品计费测试，以及用于产品演示的简化部署。

自动化部署主要用于每晚的回归测试。每晚，我们都会触发部署，在生产环境和预发布环境中测试每个SLEEVE，然后删除所创建的资源。发生变更时，我们可以快速检测到变更并提交错误报告，以便更新指南。目前的测试覆盖范围包括：

• 安全Kubernetes网关。
• Web应用安全。
• 网络边缘应用，用于部署标准的10 Pod“hipster-co”应用和更轻量的单Pod应用。
• Hello-Cloud。
• 跨AWS、GCP、Azure、VSphere和KVM/Vagrant部署的CE单节点、单网络接口Volterra站点。
• 部署在AWS、GCP、Azure、VSphere和KVM/Vagrant上的CE单节点双网络接口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主要面向单节点和单网络接口用例，但近期我们已将SLEEVE的覆盖范围扩展到多节点Volterra站点集群，以及AWS、Azure、GCP、VMWare和KVM/Vagrant平台上的多网络接口用例。

我们还计划改进堆栈记录系统。我们将提高AC记录的详细程度，并引入RDS数据库来存储记录，以增强搜索功能。目标是加快AC环境的搜索速度，并提供更精细的筛选功能，例如按堆栈状态、堆栈创建者等条件查找堆栈。我们还计划利用这些记录构建自定义UI，以便更高效地直观呈现通过AC创建的部署。

关于作者

Alex Cohen

Alex Cohen 的更多博客文章