前
目前Infra 的占比部分在日常的工作占比略高。一直在考虑自己做接口来把一些常用的操作和流程自动化来执行。但是一直觉得不够优雅,在云的接口上抹烂泥的感觉。
所以就对相关的解决方式进行预研,遇上了Terraform,一个实现 IaC(infrastructure as Code)的方案。
这篇文章就简单的记录下,在目前环境下的接入方法。涉及到
- 原始方式的单实例导入
- Terrformer 的批量资源导入
存量资源导入到Terrform
先指定provider,之后 terraform init
来进行环境初始化
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 3.0"
}
}
}
provider "aws" {
region = "eu-central-1"
}
添加新的VM空配置,来承载后面的导入的vm状态
resource "aws_instance" "myvm" {
ami = "unknown"
instance_type = "unknown"
}
执行导入操作
terraform import aws_instance.myvm <Instance ID>
把id对应的VM 实例状态导入至我们生命的 aws实例中。
之后执行 terraform plan
可以看到现在的state和实际上的state 的差异以及预计改变。
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
# aws_instance.myvm will be updated in-place
~ resource "aws_instance" "myvm" {
id = "i-0b9be609418aa0609"
~ instance_type = "t2.micro" -> "unknown"
~ tags = {
- "Name" = "MyVM" -> null
}
# (27 unchanged attributes hidden)
# (6 unchanged blocks hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.
这里需要修正上面我们制定的缺省的 ami 和 instance_type。所以这里我们修改tf 的内容为。
resource "aws_instance" "myvm" {
ami = "ami-00f22f6155d6d92c5"
instance_type = "t2.micro"
tags = {
"Name": "MyVM"
}
}
这里我们还可以使用
terraform state show alicloud_instance.myvm -no-color > cvm.tf
来进行这个实例的全部状态的导出,。但是会多很多无用的状态以及一些不受控制的状态,需要进行plan查看后逐一进行删减
之后再执行 terraform plan 会发现,提示已经是No changes.,说明我们的VM的状态已经和本地的状态保持一致了。也就是我们完成了资源的导入。
一键导入大杀器
存量资源的单个导入是比较低效且慢的。这里就找到了一个第三方来进行一键导入的神器。由google 的sre团队研发。支持Azure/GCP/AWS/Cloudflare
新版本的terraform 可能会出现初始化错误,这里使用
terraform state replace-provider -auto-approve "registry.terraform.io/-/aws" "hashicorp/aws"
在使用的时候可能存在部分资源导入之后的属性值不兼容的问题,需要对tf中的资源进行手动删除,对应的 state 也需要rm 掉。