KubeVela篇07：terraform controller实现原理

terraform-controller是一个专门负责terraform一类的组件”安装”的Operator，通过打包成helm，再封装成kubevela的Addon，由kubevela安装到管控集群，为其它terraform provider插件提供模块定义支持。

从前面kubevela安装一个Application的原理我们了解到，当一个如alibaba-vpc等基础设施资源组件随Application“安装”时，kubevela会将这类组件渲染为Configuration资源对象，然后apply到管控集群。接着就由terraform-controller监听Configuration资源事件，负责后续的云资源申请并将结果输出了。

另外，要能够正常申请云资源，我们还使用vela config create命令创建出一个Provider资源对象，在Application.yaml声明云资源组件的时候配置providerRef，引用这个Provider资源对象。kubevela在渲染Configuration资源对象的时候会传给Configuration资源对象。

Configuration、Provider两种资源类型就是terraform controller提供的两种CRD。

terraform controller的crd - Configuration：资源配置文件，terraform controller会根据Configuration资源的spec转成tf代码文件然后启动个job去apply。

apiVersion: terraform.core.oam.dev/v1beta1
kind: Configuration
metadata:
  name: alibaba-oss-bucket-sample
spec:
  hcl: |
    resource "alicloud_oss_bucket" "bucket-acl" {
      bucket = var.bucket
      acl = var.acl
    }

    output "BUCKET_NAME" {
      value = "${alicloud_oss_bucket.bucket-acl.bucket}.${alicloud_oss_bucket.bucket-acl.extranet_endpoint}"
    }

    variable "bucket" {
      description = "OSS bucket name"
      default = "vela-website"
      type = string
    }

    variable "acl" {
      description = "OSS bucket ACL, supported 'private', 'public-read', 'public-read-write'"
      default = "private"
      type = string
    }

  backend:
    secretSuffix: oss
    inClusterConfig: true

  variable:
    bucket: "vela-website"
    acl: "private"

  writeConnectionSecretToRef:
    name: oss-conn
    namespace: default

  providerRef:
    name: alibaba-sample
    namespace: default

Provider：terraform provider的名称、区域、访问凭证的配置，由Configuration资源的providerRef属性引用。

apiVersion: terraform.core.oam.dev/v1beta1
kind: Provider
metadata:
  name: alibaba-sample
spec:
  provider: alicloud
  region: cn-beijing
  credentials:
    source: Secret
    secretRef:
      namespace: vela-system
      name: alicloud-account-creds
      key: credentials

对应支撑这两种CRD的分别是provider_controller和configuration_controller。

[terraform-controller架构图]

terraform-controller架构图

provider_controller只是在Provider资源创建后校验是否能够从Provider解析出凭证（Credentials），凭证用于执行terraform命令，访问terraform提供者。

configuration_controller在Configuration资源创建/更新/删除，或是输入变量变更时，负责执行terraform代码，申请/删除云资源。

configuration_controller不会直接执行terraform命令，而是创建一个Job去执行，这个Job会拉起一个POD，里面有四个容器，每个容器负责执行一条命令，每个容器使用的docker镜像可能也不同，命令执行完容器就会退出。

这四个容器分别是：

负责将挂盘的.tf代码文件copy到/data目录下，原因是第（3）个容器执行terraform init命令是在/data目录下执行，这是oamdev/docker-terraform镜像设置的工作目录。
如果需要从远程拉取.tf代码文件，则执行git clone命令拉取代码。
执行terraform init命令。
执行terraform apply命令，或者是执行terraform destroy命令。

当terraform apply命令执行完成后，configuration_controller不断从“状态文件”获取输出，然后写入writeConnectionSecretToRef指定的Secret资源对象。

而当terraform destroy命令执行完成后，将会自动清理configuration_controller生成的一些资源对象，以及删除Job。

整体流程如下图所示：

terraform controller 工作原理

terraform命令执行后，会产生一个状态文件，状态文件记录了输入输出。

我们本地执行terraform命令，默认状态文件(terraform.tfstate)就输出到当前路径。而terraform controller默认配置使用k8s backend作为远程状态存储实现，就是下面这段代码，由terraform controller生成，namespace、secret_suffix默认取Configuration资源的namespace和name。

    terraform { 
        backend "kubernetes" {          
             secret_suffix  = "%s"
             in_cluster_config = true
             namespace  = "%s" 
        }
    }

参考文献

terraform controller开源项目README.MD

KubeVela篇07：terraform controller实现原理

参考文献

文章推荐