使用 Terraform 和 GitHub Actions 对基础设施进行自动化安装测试

1. 测试是海上的航标

项目越复杂、规模越大，越能体现测试的价值和重要性。

测试保证了方向的正确性。就像航行时，海上出现的航标，可以用来检验、纠正路线。便于掌舵人，随时了解动态，做出调整。

测试决定了迭代的速度。随着 Scrum 等敏捷开发方法的实践，交付的节奏在加快。测试是交付质量的保障，如果测试跟不上，敏捷将无法落地。

测试很重要，但却是一本经济账。太少，不足以保障质量；太多，维护成本又很高。卡住关键点位，才能获得高的性价比。

再来看看需要测试的产品。KubeSphere 很小，却又很大。说它很小，是因为只是 Kubernetes 上的应用负载，并不对原生的 Kubernetes 进行改造。说它很大，是因为集成了很多可选的组件，提供了整套的解决方案。在日常的开发过程中，有两个地方汇聚了高密度的价值: 主仓库和安装程序。主仓库，汇聚了开发者的每次变更；安装程序，汇聚了各个组件在用户安装时的行为。

比较之下，我认为安装更加需要额外的自动化测试，而且也更好测试。安装是用户体验的第一印象，更加贴近用户端。下面来看看，我在测试安装程序上做的工作吧。

2. 使用 KubeSphere 测试 KubeSphere

这是一个有趣的做法，使用 KubeSphere 创建新的 KubeSphere ，并实现自测。听起来有点像自举，自己创建自己，自己测试自己。这样就有了安装程序的第一版自动化测试。

每天对单节点、多节点、高可用三种安装方式进行自动化测试。安装之后，也会做一些 API 和 UI 层的测试，可以参考文档《基于 Kubernetes 和 Jenkins 搭建自动化测试系统》，还有一些拨测用来实时验证线上服务是否正常，《使用 Jenkins 进行服务拨测》。

下面说一下测试流程:

创建一条创建集群的流水线
运行 API 自动化测试
运行 UI 自动化测试，在新机器上创建一条创建集群的流水线。

就这样大概测试了半年，后来由于安装程序变更，最终创建并销毁了近 500 个集群后，暂停已有大半年时间。测试期间，我也对测试的边界进行了整理，比如操作系统、系统版本、云厂商、安装方式等。

3. 使用 Terraform 和 GitHub Actions

在上一个版本中，主要是通过 IaaS 的 API 去创建和删除云主机，然后安装测试软件。最近安装程序又出现了几次问题，影响到用户体验，我想用 Terraform 和 GitHub Actions ，应该会有很好的自动化测试方案。

3.1 先看看效果

如上图，执行策略有两种:

每天早上定时执行一次
每次合并 PR 执行一次

在执行完成之后，Actions 会向 Slack 发送一条通知:

如果有异常，需要进入 Actions 的日志页面查看详情。

3.2 为什么是 Terraform 和 GitHub Actions

Terraform 提供的能力是，只需要描述资源，Terraform 就会帮你调用 IaaS 的接口，管理这些资源的生命周期。下面是配置一个流量型 EIP 的示例:

resource "qingcloud_eip" "init"{
  name = "tf_eip"
  description = ""
  billing_mode = "traffic"
  bandwidth = 50
  need_icp = 0
}

通过 terraform apply 和 terraform destroy 命令，可以随时创建和销毁描述的资源。当然，也可以使用代码仓库管理这些 Iac，实践 GitOps 。

GitHub Actions 是 GitHub 提供的 CICD 服务，对公开仓库免费，无时长限制。只需要在 .github/workflows/ 目录下，使用 Yaml 定义流程即可使用。

3.3 提交 Iac 配置准备测试

Iac ，基础设施即代码，是一种理念，像管理代码一样管理基础设施。这里需要将软件改造成 Iac 的描述方式:

一个 EIP
一个防火墙
一个防火墙规则
一个云主机
一个安装资源

使用 Terraform 的 DSL 描述这些资源。

另一方面就是 GitHub Actions 的 Workflows 的编写。这一部分主要是执行的流程:

安装 Terraform
初始化 IaaS 秘钥
Terraform 创建资源
安装 KubeSphere 并检测是否符合预期
Terraform 销毁资源
Slack 发送通知

这里有个小的技巧，给步骤 4 设置超时时间，将 5、6 设置为 always ，也就是说无论成功还是失败，都会销毁 IaaS 资源节约成本，还会推送执行结果到 Slack。

3.4 如何给 GitHub Actions 配置 Slack 通知

首先需要在 Workflows 描述文件中，添加如下内容:

env:
  SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
steps:
  - name: slack
    uses: 8398a7/action-slack@v3
    with:
      status: ${{ job.status }}
      fields: repo,message,commit,author,action,eventName,ref,workflow,job,took
    if: always()

其中的 SLACK_WEBHOOK_URL 是推送通知的 API 地址，需要配置在 Actions 页面的 Secrets 中。

接着访问 Slack 的开发者页面，创建 Slack App ，然后获取 SLACK_WEBHOOK_URL 值。主要分为如下步骤:

打开 https://api.slack.com/apps?new_app=1 ，选择 Workspace，创建 app

进入新建的 Slack App ，点击【Incoming Webhooks】添加 Webhook 之后，就可以获取到 Webhook URL 。

4. 总结

目前测试 Case 相对单一，后续需要继续扩充。考虑不同维度选项的组合，通过 matrix 批量组合执行。

其实，Terraform 和 GitHub Actions 的方式也不是最优的。GitHub Actions 支持运行 Kind (使用一个 Docker 容器运行 Kubernetes)。如果能对接上 Kind ，完全使用 GitHub Actions 进行自动化测试会更好。

另外就是可以引入 Chaos 类型的工具，在系统健壮性、高可用方面进行测试。

推荐订阅源

陈少文的网站