Infrastractor As Code中Code与物理资源同步的原理分析

上篇文章讲到《企业应用如何解决Multi-Cloud的基础设施管理及应用部署问题》,其核心是使用Terraform的模板管理基础设施,虽然Terraform的中文资料较少,好在阿里云Terraform官方仓库的Example目录中提供了大量的模板参考,参考这些模板将能够管理常用的云服务。

什么是Infrastractor As Code(IaC)

基础设施即代码(IaC)的概念已经被人们所熟知,其核心就是“告别手工配置基础设施的时代,用自定义脚本来配置基础设施”。目前也有很多的自动化工具来实现自定义脚本,如Terraform、Ansible、Chef、Puppet、SaltStack等等。IaC的好处是可以将脚本做为基础设施的文档,可以做版本管理,每次的变更都有历史记录,还有些人基于这些脚本生成任何人都能看懂的基础设施关系图、图表等等。

但在实践中很多人在后续的变更中不再使用脚本变更,而是直接在管理系统中或其他方式手动修改基础设施,导致脚本丧失了作为追溯依据的价值。所以对于IaC其重中之重是通过脚本再次更新资源、以及物理资源的变更与脚本的同步问题,本文将深入讲解Terraform的核心之一State的原理,通过其原理对其运作机制有更进一步的认识,从而达到灵活创建/更新/同步云资源的目的。

state的原理

Terraform可以轻松的做到通过Code(下面统称为模板)更新物理资源,以及物理资源更新后与模板的差异对比,这些都源于其State文件(运行apply命令后生成的tfstate文件)。下图是各个命令运行后模板与State与物理资源的各种关系变化。

Infrastractor As Code中Code与物理资源同步的原理分析

实例讲解

下面就以一台云服务器的全生命周期管理来讲解创建、更新、物理资源变更、释放时的各种变化。

1.创建一台经典网络下的云服务器模板如下:


resource "alicloud_instance" "webserver" {
    count = 1
    availability_zone = "cn-beijing-b"
    security_groups = ["****"]
    allocate_public_ip = true
    instance_charge_type = "PostPaid"
    instance_type = "ecs.n1.small"
    internet_charge_type = "PayByTraffic"
    internet_max_bandwidth_out = 5
    system_disk_category = "cloud_efficiency"
    image_id = "ubuntu_140405_64_40G_cloudinit_20161115.vhd"
    instance_name = "tf_snat"
    tags {
        role = "webserver"
    }
}

运行


terraform apply

在阿里云的ECS控制台可以看到新创建的云服务器。

2.修改Tag:添加一个标签,模板tags部分增加如下内容:


datacenter = "beijing"

完整的模板如下:


resource "alicloud_instance" "webserver" {
    count = 1
    availability_zone = "cn-beijing-b"
    security_groups = ["****"]
    allocate_public_ip = true
    instance_charge_type = "PostPaid"
    instance_type = "ecs.n1.small"
    internet_charge_type = "PayByTraffic"
    internet_max_bandwidth_out = 5
    system_disk_category = "cloud_efficiency"
    image_id = "ubuntu_140405_64_40G_cloudinit_20161115.vhd"
    instance_name = "tf_snat"
    tags {
        role = "webserver"
        datacenter = "beijing"
    }
}

运行


terraform plan

会对比tfstate文件,返回变更差异:

Infrastractor As Code中Code与物理资源同步的原理分析

如果确认要变更物理资源,执行


terraform apply

3.如果物理资源有变更,比如其他管理员使用控制台或其他工具更新了标签,增加了标签"renew = 2018",执行


terraform refresh

将会根据物理资源更新tfstate文件,再次运行:


terraform plan

将会看到模板与state文件的差异:

Infrastractor As Code中Code与物理资源同步的原理分析

此时有两个选择:如果想以物理资源的变更为基准,可以更新模板,添加tag;如果想以模板为基准,可以直接执行terraform apply命令更新物理资源。

4.如果想释放这台云服务器,执行


terraform destroy

将根据state文件的记录删除这台云服务器。

本文详细讲解了terraform使用状态逼近的方法使得IaC中的Code和物理环境一致,使用状态文件tfstate来描述状态的变更,了解了这点之后大家可以灵活运用此文件做到模板与物理资源的同步问题,基于此基础设施的管理会更有序,其上的应用部署也会更有序。

大家有问题也可以在https://github.com/alibaba/terraform-provider的Issue中提问。

上一篇:GOPS全球运维大会深圳峰会第一天会议分享


下一篇:移动终端app测试点归纳(持续更新)