Terraform管理云资源实践

背景

Terraform是一款开源的Cli工具,网上的很多文章都是单机安装一个然后创建个目录就去操作云资源;如果在高可用的前提,如何将Terraform cli变成一个嵌入运维流程的一个组件?不仅仅是人编写tf模板然后去apply?

自动化的驱动Terraform,无非包含这几个步骤:

  • 初始化Terraform
  • 填充资源模板
  • apply资源
  • show资源

初始化Terraform

创建一个云资源目录,如cloudxxx-test001

云资源的目录下需要有Terrafor的Provider信息,以及实例声明信息。

创建好了模板文件,就需要初始化Terraform,以及下载Provider插件,建议提前下载好插件到指定的目录,使用容器可以直接打到镜像里

这样初始化直接指定plugin地址:

复制代码
/usr/local/bin/terraform init -plugin-dir=/Users/lixiangli/.terraform.d/plugins

注意:确保插件地址内有你声明的插件版本

由于Terraform apply是不支持选择apply哪个资源,因此上面的实现方式可以发现,一个目录是放一个云资源。为了让每次操作的影响范围是可控的。这种方式会带来一个问题,就是state的文件存储也必须是隔离的,否则出现的情况是apply 资源cloudxxx-test001时 cloudxxx-test002会被直接删除。

模板文件生成

通过代码的方式去驱动Terraform, 无法避免的一步就是生成所对应的云资源的模板文件,我们这边使用golang,所以找到需要对接的云的Provider的文档然后定义成如下:

复制代码
resource "ucloud_disk" "ucloud_disk_{{ .ObjectMeta.UID }}" {
  availability_zone = "{{ .Spec.Zone }}"
  name              = "{{ .Spec.InstanceName }}"
  disk_size         = "{{ .Spec.InstanceSize }}"
  disk_type         = "{{ .Spec.InstanceType }}"
  charge_type       = "{{ .Spec.ChargeType }}"
}

在程序运行时动态填充这些模板即可

选择合适的状态存储

Terraform是个有状态的组件,如果部署多个实例的话,官方默认的state文件的模式必然是无法满足需求的。

所以我们这边选择的是etcdv3

配置如下:

复制代码
terraform {
  required_providers {
    ucloud = {
      source = "ucloud/ucloud"
      version = "~>1.23.0"
    }
  }
  backend "etcdv3" {
    endpoints = ["http://127.0.0.1:2379/"]
    lock      = true
    prefix    = "/terraform-state/clouddisk/77c2d636-7a59-11eb-9d32-12caef3c0b88"
    cacert_path = ""
    cert_path = ""
    key_path = ""
  }
}
provider "ucloud" {
    public_key  = "xxxxxxx"
    private_key = "xxxxxx"
    region      = "cn-bj2"
    project_id  = ""
}

backend的prefix资源加了uuid,实际上是为了解决上面一个目录是放一个云资源锁带来的问题,也就是说那个uuid实际上是对应的单独资源id,每个资源都有单独的state文件

如何支持多云

支持多云是Terraform的强项,支持多云依然需要在上次软件做好一定的屏蔽工作。

Terraform需要做的就是准备好多套云的tf模板去填充

如腾讯云:

复制代码
resource "tencentcloud_cbs_storage" "tencentcloud_disk_{{ .ObjectMeta.UID }}" {
  storage_type      = "{{ .Spec.InstanceType }}"
  storage_name      = "{{ .Spec.InstanceName }}"
  storage_size      = "{{ .Spec.InstanceSize }}"
  availability_zone = "{{ .Spec.Zone }}"
  project_id        = "{{ .Spec.ProjectID }}"
}

如优刻得:

复制代码
resource "ucloud_disk" "ucloud_disk_{{ .ObjectMeta.UID }}" {
  availability_zone = "{{ .Spec.Zone }}"
  name              = "{{ .Spec.InstanceName }}"
  disk_size         = "{{ .Spec.InstanceSize }}"
  disk_type         = "{{ .Spec.InstanceType }}"
  charge_type       = "{{ .Spec.ChargeType }}"
}

上层的数据结构可以声明成一样的,所有的差异由tf模板来屏蔽

相关推荐
分布式存储与RustFS19 小时前
RustFS 该跟 stable 还是 nightly?两条版本线的分工、风险与回退,一张表说清
运维·云原生·开源·对象存储·分布式存储·s3·性能基准
ggaofeng1 天前
k8s中的dns
云原生·容器·kubernetes
我不会起名字3222 天前
Pod 一直 Pending:调度器 5 类失败原因与 kubectl describe 的正确读法
云原生·kubernetes·调度·排查
risc1234562 天前
万变不离其宗
人工智能·低代码·云原生
T.O.P_KING2 天前
Falco vs. Tetragon:云原生运行时安全选型指南
安全·云原生
七夜zippoe2 天前
把 OpenClaw Agent 搬进 K8s:容器化部署全记录
ai·云原生·容器·kubernetes·openclaw
March.s2 天前
Kubernetes 全景导览:从部署演进到云原生底座
云原生·kubernetes·dubbo
熊出没2 天前
云原生架构落地实践:Kubernetes 生产级配置与 Service Mesh 流量治理
云原生·架构·kubernetes·istio
迪康Defender2 天前
终端安全运维:浅谈迪康端点安全一体化管理系统工具箱实用能力
运维·安全·信息可视化·自动化·运维开发·学习方法·远程工作
CCblandy3 天前
一致性哈希到底省了多少搬迁?本机实测 3 轮:取模 6→7 搬 85.8%,V=128 只搬 14.3%,虚拟节点太少会被倾斜骗
后端·python·云原生·性能优化·架构