原创 吴就业 146 0 2023-07-23
本文为博主原创文章,未经博主允许不得转载。
本文链接:https://wujiuye.com/article/2a581b383725451b8f2ad2f9652d4a41
作者:吴就业
链接:https://wujiuye.com/article/2a581b383725451b8f2ad2f9652d4a41
来源:吴就业的网络日记
本文为博主原创文章,未经博主允许不得转载。
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。
- 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
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架构图]
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命令执行后,会产生一个状态文件,状态文件记录了输入输出。
我们本地执行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"
}
}
声明:公众号、CSDN、掘金的曾用名:“Java艺术”,因此您可能看到一些早期的文章的图片有“Java艺术”的水印。
如何Debug Terraform Controller;如何让Configuration可以指向私有仓库;为云资源编写ComponentDefinition;验证流程是否跑通。
terraformProvider、multiclusterProvider、oamProvider、configprovider、kube这些provider的Install方法注册了很多操作处理方法。这些方法就是提供给CUE中调用的方法。
kubevela安装一个Application的过程,就是执行工作流上的每个步骤的过程,并且当我们未配置工作流,kubevela会自动为组件的部署生成一个工作流步骤。
通过前面的章节,我们已经学习了解terraform,并通过vpc资源例子,为私有云/混合云开发了terraform provider,这一节介绍如何将我们开发的mycloud terraform provider整合到kubevela控制平台上,以通过在application中声明一个kubevela组件的方式去申请基础设施资源。
订阅
订阅新文章发布通知吧,不错过精彩内容!
输入邮箱,提交后我们会给您发送一封邮件,您需点击邮件中的链接完成订阅设置。