KubeVela篇11：可持续测试应用部署之Mock基础设施

Mock接口是我们常用的功能测试方案，有时候依赖的接口未开发完成或者依赖的第三方接口不提供测试环境等，只有Mock才能跑通流程。

我们基于KubeVela开发的云原生应用交付平台，提供如初始化基础设施导入、中间件部署共用基础设施等相关能力的测试，需要依赖基础设施。虽然terraform是面向公司内部的混合云平台，但是测试都要跨部门配置效率太低了，而且这种模式无法支持持续测试。

为了解决测试问题，Mock才是最高效的方案。为此，我们实践了两种Mock基础设施申请的方案，最终选择一种最高效的方案作为长期执行的方案。

方案一：实现混合云的钓鱼平台

通过kubevela部署application，其中基础设施组件会渲染成configuration资源，由terraform controller去创建Job，Job创建Pod，Pod执行terraform命令去申请资源。

我们利用hostAlias去实现mock掉terraform通过混合云提供的terraform provider向混合云申请资源的请求，然后实现一个web服务伪装成混合云。

apiVersion: v1
kind: Pod
metadata:
  name: proxy-test-pod
  namespace: default
spec:
  containers:
    - name: curl
      image: "alpine"
      command:
        - "sh"
        - "-c"
        - "touch /dev/shm/debug && tail -f /dev/shm/debug"
  hostAliases:
    - ip: 192.168.88.88
      hostnames:
        - api.mycloud.com
  terminationGracePeriodSeconds: 15

注意，如果你们用的是阿里云的或者aws的terraform provider，由于伪装https服务器需要有证书，如果没有证书这个方案就行不通了。

方案二：实现Mock组件

通过webhook在application资源创建/更新的时候，将需要Mock的组件替换为自定义的Mock组件，最终kubevela会将组件渲染成自定义的一个CR，然后由自定义控制器实现Mock逻辑，如创建output对应的Secret资源，tfstate Secret资源等。

关键技术点：

• Webhook
• Operator
• KubeVela自定义组件

得益于KubeVela提供的自定义组件的能力，通过自定义Mock组件，将原本渲染成terraform-controller的Configuration资源，改为渲染成MockConfiguration资源。使得我们声明的application.yaml不仅适用于测试，无修改修改就可以直接部署在线上环境，确保了应用部署的application.yaml不会因为上线时做了错误的修改，导致测试没问题而线上无法部署成功的问题。

最核心的部分是Mock组件的定义。每种基础设施资源对应一种组件，我们可能只定义一个Mock组件，也可以为每种基础设施组件定义一个Mock组件，我们选择后者。

案例是定义一个mycloud-vpc-mock组件，组件的workload是自定义的CRD：MockConfiguration，该Mock组件用于mock mycloud-vpc组件。

"mycloud-vpc-mock": {
  alias: ""
  annotations: {}
  attributes: {
   workload: definition: {
    apiVersion: "nebula.lizhi.fm/v1"
    kind:       "MockConfiguration"
   }
   status: {
    healthPolicy: #"""
     isHealth: (context.output.status.apply.state == "Available")
     """#
    customStatus: #"""
     applyStatus: {
      message: *"" | string
     } & {
      if context.output.status.apply != _|_ && context.output.status.apply.message != _|_ {
       message: (context.output.status.apply.message)
      }
     }
     message: applyStatus.message
     """#
   }
  }
  description: "Mock mycloud-vpc Terraform Component Apply"
  labels: {
   "mock-terraform-component": "mycloud-vpc"
  }
  type: "component"
}

template: {
  output: {
   apiVersion: "nebula.lizhi.fm/v1"
   kind:       "MockConfiguration"
   metadata: {
    name:      context.name
    namespace: context.namespace
   }
   spec: {
    variable: {
     vpc_name:      parameter.vpc_name
    }
    backend:                    parameter.backend
    providerRef:                parameter.providerRef
    writeConnectionSecretToRef: parameter.writeConnectionSecretToRef
   }
   status: {}
  }
  outputs: {}
  parameter: {
   vpc_name:      string
   backend: {
    secretSuffix: string
   }
   providerRef: {
    name:      string
    namespace: string
   }
   writeConnectionSecretToRef: {
    name:      string
    namespace: string
   }
  }
}

总结

方案一的好处是，上层使用上没有任何区别，整条链路上没有任何改动。而方案二会修改application.yaml，且不会跑terrafrom-controller的逻辑，整条链路实际上是不完整的，导致测试覆盖率低，有一些底层的问题无法在测试阶段发现，例如terraform-controller可能存在严重的bug。

方案一的缺点也很明显，因为需要mock非常多的接口，而且还需要对混合云提供的terraform provider的代码或者相关接口非常熟悉才可以。学习使用成本太高，效率没有方案二高。 最终出于对学习使用成本和效率方案的追求，我们选择使用方案二作为上层功能测试的Mock方案。