本文已在下方公众号中发布：听说“一分钟就能部署阿里云ECS集群”？，欢迎大家围观
1 为什么要有资源编排
传统运维模式下，业务上线需经过设备采购，机器上架，网络环境搭建和系统安装等准备阶段。随着云计算的兴起，各大公有云厂商均提供了非常友好的交互界面，用户借助一个浏览器就可以按需采购各种云资源，快速实现业务架构的搭建。
然而，随着业务架构的不断扩展，云资源采购的规模和种类也在持续增加。当用户需要快速采购大量不同类型的云资源时，云管理页面间大量的交互操作反而降低了云资源的采购效率。在阿里云控制台上初始化一个经典的VPC网络架构，从创建VPC、交换机VSwitch到创建Nat网关、弹性IP再到配置路由等工作，大概要花费20分钟甚至更久。同时，工作成果的不可复制性，带来的是跨Region和跨云平台场景下的重复劳动。
事实上，对业务运维人员而言，只关心对资源的配置，无需关心这些资源的创建步骤。如同喝咖啡，只需要告诉服务员喝什么，加不加冰等就够了。如果有一份完整的云资源采购清单，这张清单清楚的记录了所需要购买的云资源的种类，规格，数量以及各云资源之间的关系，然后一键完成购买，并且当业务需求发生变化时，只需要变更清单就可以实现对云资源的快速变更，那么效率就会提高很多。在云计算中这被称作资源编排，目前很多云平台也提供了资源编排的能力，如阿里云的ROS，AWS的CloudFormation等。
将云资源、服务或者操作步骤以代码的形式定义在模板中，借助编排引擎，实现资源的自动化管理，这就是基础设施即代码（Infrastructure as Code，简称IaC），也是资源编排最高效的实现模式。
然而，多种云编排服务带来的是高昂的学习成本、低效的代码复用率和复杂的多云协同工作流程。每一种服务仅限于管理自家的单一云平台上，无法满足对多个云平台，多种层级（如IaaS，PaaS）资源的统一管理。
如何解决如上问题，是否可以使用统一的编排工具，共用一套语法实现对包括阿里云在内的多云的统一管理呢？这就是本文所要介绍的主角 - Terraform。
2 Terraform简介
Terraform是由Hashicorp公司于2014年推出的一个开源项目，是一个典型的IaC工具。在Terraform中，Infrastructure是一个广泛的抽象，几乎涵盖了所有可以被管理的资源和服务，如计算资源虚拟机，存储资源磁盘、对象存储，网络资源虚拟网络、交换机、路由器、IP、负载均衡等，安全资源防火墙、其他安全产品和设备，数据库资源MySQL、PostgreSQL等等。
Terraform与前文提到的ROS等各家的资源编排服务相比，主要有几个特点：
- 开源
从诞生之初，Terraform就是一个开源项目，任何开发者都可以对其贡献代码，完善功能。 - 多云管理
支持对多种云服务的统一管理，各云服务厂商提供自家的管理插件Provider（后文会提到），用户只需要学习统一的Terraform语法，选择不同的Provider，定义不同的资源模板即可。
对不同云服务厂商云资源的描述可以定义在同一个模板中，相互之间不会产生干扰。 - 面向客户端
只要在操作机器上完成对Terraform的安装，就可以通过简单的Terraform命令实现对云资源的一键管理，非常方便，无需再借助与API、SDK等方式整合后进行调用。
目前，市场上的IaC工具大体可以分为两类：一类是配置管理类，典型代表有Ansible，Chef，Puppet等；另一类是以Terraform为代表的资源编排类。运维人员可能对前者更加熟悉，并且认为这些工具也可以实现对资源的管理，比如阿里云的Ansible Module同样可以实现阿里云ECS实例，VPC，SLB等的管理和配置。
但两者存在很大差别：
- 使用场景不同
配置管理工具侧重于操作系统级别配置和管理，如机器的启停，系统软件的安装和配置等，它的目的是为了实现对机器及其上应用的控制和管理，而资源编排解决的是基础设施整体资源栈的编排和管理问题，触达的资源更广。 - 工作模式不同
资源编排是面向声明式的。声明式只关心最终的操作结果，对用户而言，只关心我定义的那堆资源是否都已经创建完成。如果结果和声明的不一致，则会触发变更操作，直到最终状态。而配置管理工具是面向过程式的，过程式需要关心每一步的操作结果，在执行时通常是串行的，直到所有步骤结束，如先创建VPC，VSwitch，安全组，然后再利用创建好的资源创建ECS实例，SLB实例等。可以理解为按顺序自动化执行所有的操作。
阿里云作为国内第一家与 Terraform 集成的云厂商，经过两年多的努力，目前已经提供了超过 148 个 Resource 和 98 个 Data Source，覆盖计算，存储，网络，负载均衡，CDN，容器服务，中间件，访问控制，数据库等超过30款产品，已经满足如SAP，西门子这样大客户的自动化上云需求。从 Terraform 0.12.2 版本开始，阿里云支持将对象存储服务 OSS 作为标准的 Remote State Backend ，开始提供远端存储 State 的能力，在提高 state 安全性的同时，提升多人协作效率。阿里云Modules的注册数量已经达到36个，覆盖多个产品和使用场景，为开发者提供“开箱即用”使用体验。
除此之外，Hashicorp中的其他成员 Packer 和 Vault 也实现了与阿里云的集成，与Terraform一起从镜像制作，到权限控制，到资源编排满足用户和开发者更多的使用场景。
3 阿里云Terraform初探
接下来，本文将通过一些简单的操作和介绍，引导大家在阿里云上快速入门Terraform，后续也会有一系列文章介绍更高级的功能。
3.1 安装Terraform
正如前面提到的，Terraform是一个面向客户端的工具，在使用Terraform之前，需要在本地安装Terraform，可参考官方的安装文档：https://learn.hashicorp.com/terraform/getting-started/install。
如果不想安装，可以使用阿里云提供的在线服务Cloud Shell：https://shell.aliyun.com，内置了Terraform的运行环境。
3.2 Provider：基础设施管理驱动
Provider 是Terraform中一个非常重要的组件，是一个用来管理基础设施的后端驱动，可以理解为Terraform的插件。每个云服务厂商实现面向各家云服务的Provider，其中包含资源元数据的定义，上层请求的处理和后端OpenAPI的调用和响应处理。Terraform调用不同的Provider完成不同类型资源的统一管理。目前大多数云平台均实现了各自的Provider，阿里云提供的Provider为 alicloud 。
Provider无需手动安装，Terraform会在 init 阶段根据模板中的定义自动加载。Provider通过关键 provider 声明，语法如下：
provider "alicloud" {
profile = "terraform"
region = "cn-hangzhou"
}以上代码显示声明了需要加载的Provider插件为 alicloud ，大括号中指定了该Provider的配置，其中 profile 表示阿里云的认证信息可以从Credential文件 ~/.aliyun/config.json 中名为 terraform 的配置信息中读取； region 指明了当前模板中定义的资源会被创建在杭州区域。
如果不想使用 profile ，可以直接在如上配置中硬编码 access_key 和 secret_key ，但是硬编码的方式存在密钥泄漏的风险，不推荐。
运行 terraform init 自动加载Provider：
Provider 也可以省略，即隐式定义。通过环境变量 ALICLOUD_ACCESS_KEY 、 ALICLOUD_SECRET_KEY 和 ALICLOUD_REGION 来设置Provider所需的必填参数。 init 时，Terraform将通过下文即将讲到的Resource和Data Source来识别相应的Provider，进而完成加载。
3.3 Resource：资源的定义和管理
Resource是Terraform中的一个重要概念，是Provider的重要组成部分。每个Resource定义了特定基础设施资源的属性，通过对Create、Update、Read和Delete方法的实现来管理特定资源的生命周期。
3.3.1 Resource 的声明和定义
Resource通过关键字 resource 来声明，对一个特定资源的定义如下：
# 定义一个ECS实例
resource "alicloud_instance" "default" {
image_id = "ubuntu_18_04_64_20G_alibase_20190624.vhd"
instance_type = "ecs.sn1ne.large"
instance_name = "my-first-vm"
...
}对资源的定义包含如下几个部分：
-
alicloud_instance为资源类型，定义当前资源的类型，告诉Terraform这个Resource是阿里云的虚拟机还是其他资源，如VPC、SLB等。 -
default为资源名称，资源名称用来标识所定义的资源，在同一个模板（即当前运行目录下所有以.tf结尾的文件）中对同一资源类型的标识必须唯一。 - 大括号里面的内容为参数配置，用来定义资源属性，比如实例的镜像、规格、名称，VPC的网段等。
上述代码定义了一个阿里云的ECS实例，镜像ID为 ubuntu_18_04_64_20G_alibase_20190624.vhd，规格为 ecs.sn1ne.large，实例名称为 my-first-vm ，更多参数定义可参考官方文档：https://www.terraform.io/docs/providers/alicloud/r/instance.html
3.3.2 Resource 的创建
完成对资源的定义，可以先通过 terraform plan 预览模板中所定义的资源:
shell@Alicloud:~$ terraform plan
...
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# alicloud_instance.default will be created
+ resource "alicloud_instance" "default" {
+ availability_zone = (known after apply)
+ host_name = (known after apply)
+ image_id = "ubuntu_18_04_64_20G_alibase_20190624.vhd"
+ instance_charge_type = "PostPaid"
+ instance_name = "my-first-vm"
+ instance_type = "ecs.sn1ne.large"
...
}
Plan: 1 to add, 0 to change, 0 to destroy.如上输出可知，Terraform将创建一个资源 alicloud_instance.default，其中某些属性如 host_name 为 known after apply，这个意思是说该参数的值需要在执行 terraform apply 之后才能知道，通常这种字段值如果没有显示设置，后端系统将自动生成或者通过其他Resource和Data Source来设置。
确认无误后，执行 terraform apply 开始创建资源：
shell@Alicloud:~$ terraform apply
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# alicloud_instance.default will be created
+ resource "alicloud_instance" "default" {
+ availability_zone = (known after apply)
...
}
Plan: 1 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
alicloud_instance.default: Creating...
alicloud_instance.default: Still creating... [10s elapsed]
alicloud_instance.default: Still creating... [20s elapsed]
alicloud_instance.default: Creation complete after 23s [id=i-bp18hno0jw73fcbrykt7]
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.为了安全起见， apply 之后需要输入 yes 确认，执行完毕后输出创建后的ECS实例 ID为 i-bp18hno0jw73fcbrykt7 。 登录ECS控制台验证如下：
3.3.3 Resource 的变更
对于IaC的工具，资源的变更非常简单，只需要修改模板中定义的属性值即可。Terraform对资源的变更有两种情况：
- 原地变更（update in-place）
即在不改变资源生命周期的情况下，实现对资源自身属性的修改，如变更资源的名称，描述，标签等。 - 重建变更（destroy and then create replacement）
某些资源属性不支持变更，这种情况下，如果修改资源的属性，Terraform将会先删除原有的资源，然后按照最新的模板定义创建新的Resource，间接实现资源的变更操作。
对于不支持变更的属性，阿里云Provider的文档中，会对该属性字段显示声明为ForceNew。
接下来，分别通过修改实例的两个属性来演示如上的两种变更情况。
首先，修改实例的名称为“update-my-first-vm”，并为其增加一个标签 Newtag: "update name" 。跳过 plan 过程直接执行 terraform apply 结果如下：
shell@Alicloud:~$ terraform apply
alicloud_instance.default: Refreshing state... [id=i-bp18hno0jw73fcbrykt7]
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
# alicloud_instance.default will be updated in-place
~ resource "alicloud_instance" "default" {
...
~ instance_name = "my-first-vm" -> "update-my-first-vm"
instance_type = "ecs.sn1ne.large"
...
+ tags = {
+ "Newtag" = "update name"
}
...
}
Plan: 0 to add, 1 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
alicloud_instance.default: Modifying... [id=i-bp18hno0jw73fcbrykt7]
alicloud_instance.default: Modifications complete after 1s [id=i-bp18hno0jw73fcbrykt7]
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.如上所示， update in-place 只改变了实例的名称和新增了一个tag，不需要重新创建实例。
Terraform的展示中， + 表示新增， ~ 表示更新的内容，左边的是旧值，右边的是新值， - 表示即将删除。
在此基础上，如果修改实例所属的资源组 resource_group_id ，则在执行 terraform apply 之后将会导致实例的重建：
shell@Alicloud:~$ terraform apply
alicloud_instance.default: Refreshing state... [id=i-bp18hno0jw73fcbrykt7]
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement
Terraform will perform the following actions:
# alicloud_instance.default must be replaced
-/+ resource "alicloud_instance" "default" {
~ availability_zone = "cn-hangzhou-g" -> (known after apply)
deletion_protection = false
~ host_name = "iZbp18hno0jw73fcbrykt7Z" -> (known after apply)
~ id = "i-bp18hno0jw73fcbrykt7" -> (known after apply)
...
instance_name = "update-my-first-vm"
- internet_charge_type = "PayByTraffic" -> null
~ internet_max_bandwidth_in = -1 -> (known after apply)
+ public_ip = (known after apply)
+ resource_group_id = "rg-aekzryaevt26ofq" # forces replacement
...
}
Plan: 1 to add, 0 to change, 1 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
alicloud_instance.default: Destroying... [id=i-bp18hno0jw73fcbrykt7]
alicloud_instance.default: Still destroying... [id=i-bp18hno0jw73fcbrykt7, 10s elapsed]
alicloud_instance.default: Destruction complete after 10s
alicloud_instance.default: Creating...
alicloud_instance.default: Still creating... [10s elapsed]
alicloud_instance.default: Still creating... [20s elapsed]
alicloud_instance.default: Creation complete after 23s [id=i-bp16oytazedmtelzdgo2]
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.如上所示， resource_group_id 的变更是一个 forces replacement 行为，导致原机器的释放和新机器的创建。
值得注意的是，删除的资源无法实现回滚，数据无法恢复，因此在 apply 前一定要通过 plan 命令仔细查看哪些资源是原地变更，哪些是重建变更，以免造成不可恢复的错误。
3.3.4 Resource 的查看
想要查看创建完的资源，最简单的方式是执行命令 terraform show ，此时终端将会快速展示出所有当前模板中定义的资源及其属性：
shell@Alicloud:~$ terraform show
# alicloud_instance.default:
resource "alicloud_instance" "default" {
availability_zone = "cn-hangzhou-g"
deletion_protection = false
id = "i-bp16oytazedmtelzdgo2"
image_id = "ubuntu_18_04_64_20G_alibase_20190624.vhd"
instance_charge_type = "PostPaid"
instance_name = "update-my-first-vm"
instance_type = "ecs.sn1ne.large"
...
tags = {
"Newtag" = "update name"
}
...
}这种方法固然简单，但是如果当资源非常多的时候，在所有资源中寻找目标资源就比较吃力了。此时，可以通过 terraform state 模式来实现对目标资源的查看。
首先，执行 terraform state list 罗列出当前的所有资源，每个资源显示格式为 <资源类型>.<资源名称> ：
shell@Alicloud:~$ terraform state list
alicloud_instance.default接着，找到对应的资源，执行 terraform state show <资源类型>.<资源名称> 即可实现对目标资源的查看：
shell@Alicloud:~$ terraform state show alicloud_instance.default
# alicloud_instance.default:
resource "alicloud_instance" "default" {
availability_zone = "cn-hangzhou-g"
deletion_protection = false
id = "i-bp16oytazedmtelzdgo2"
image_id = "ubuntu_18_04_64_20G_alibase_20190624.vhd"
instance_charge_type = "PostPaid"
instance_name = "update-my-first-vm"
instance_type = "ecs.sn1ne.large"
...
tags = {
"Newtag" = "update name"
}
...
}可以看到，其结果与只有一个资源时 terraform show 的结果是一致的。
3.3.5 Resource 的释放
通常情况下，资源的释放是通过命令 terraform destroy 来执行，但是这个命令会将模板中所有定义的资源都删除，如下：
shell@Alicloud:~$ terraform destroy
alicloud_instance.default: Refreshing state... [id=i-bp16oytazedmtelzdgo2]
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
- destroy
Terraform will perform the following actions:
# alicloud_instance.default will be destroyed
- resource "alicloud_instance" "default" {
...
- id = "i-bp16oytazedmtelzdgo2" -> null
...
- instance_name = "update-my-first-vm" -> null
...
}
Plan: 0 to add, 0 to change, 1 to destroy.
Do you really want to destroy all resources?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.
Enter a value: yes
alicloud_instance.default: Destroying... [id=i-bp16oytazedmtelzdgo2]
alicloud_instance.default: Still destroying... [id=i-bp16oytazedmtelzdgo2, 10s elapsed]
alicloud_instance.default: Destruction complete after 11s
Destroy complete! Resources: 1 destroyed.如果想要删除其中的某个资源，可以通过 -target=<资源类型>.<资源名称> 来指定要删除的资源，如 terraform destroy -target=alicloud_instance.default ，其结果跟只有一个资源的删除是一致的。
除此之外，归功于Terraform状态的一致性（后面会讲到）的特点，还有一种间接删除资源的方式。上文中提到，当模板发生变更的时候， apply 命令会判断资源不一致而导致触发资源的变更，因此，我们可以在模板中把想要删除的资源定义移除，然后运行 apply 命令来完成资源的移除。
3.4 State：资源的状态存储
细心的读者可能会发现，在执行 show 和 state list 命令时，执行速度非常快，随着命令的结束，资源的属性就被快速展示，而其他命令的执行都需要等几秒钟甚至几分钟，这个跟Terraform的实现机制有关。Terraform在完成资源的创建和修改之后，会将资源的最新的状态和属性存储在一个称之为 state 的文件中，文件名默认为 terraform.tfstate ，文件的默认存储位置是资源模板所在的目录。这个 state 文件可以看作是Terraform存储资源属性的“数据库”，当执行 show 和 state list 命令时，Terraform直接读取的是 state 文件，无需调用云平台的API，而其他的命令需要与API交互后返回。
state 文件非常重要， 它只从属于一个特定的模板，模板变， state 变。因此，如果 state 文件被损坏或者被删除，Terraform会认为其管理的资源发生了变更和移除（虽然实际的资源可能依然存在于云平台），此时再执行 apply 命令将会按照模板的定义变跟或者重建资源，直到模板对资源的定义与 state 中保存的保持一致。
state 与模板的依附关系在团队协作管理的时候尤为重要，在拷贝模板代码的同时，如果想维护同一套资源， state 也需要一起拷贝，这在无形中增加了代码维护的成本。为了解决这个问题，Terraform提供了远端存储 state 的能力 remote state ，正如前文提到的，可以将 state 文件存放在阿里云的OSS上，以实现模板与 state 的管理分离。
模板与 state 的高度一致性也是Terraform的一个亮点，可以说虽然Terraform是面向客户端的，但它也是有状态，这也意味着Terraform所管理的资源，不能通过其他工具和服务（如控制台，阿里云CLI，API等）来变更资源，否则，Terraform会在下次执行 apply 时因为状态的不一致而触发变更。
3.5 Data Source：基础设施的动态查询
对资源的查询是运维人员或者系统最常使用的操作，比如，查看某个Region下有哪些可用区，某个可用区下有哪些实例规格，每个Region下有哪些镜像，当前账号下有多少机器等。通过对资源及其属性的查询可以帮助和引导开发者进行下一步的操作。
除此之外，在编写Terraform模板时，Resource使用的参数有些是固定的静态变量，但有些情况下参数变量不确定或者可选值不清楚或者参数可能随时变化。比如我们创建ECS 实例时，通常需要指定我们自己的镜像ID和实例规格，首先要知道某个镜像ID对应的字符串，特定CPU核数和内存对应的实例规格；创建VSwitch的时候，需要知道某个Region下有哪些可用区等，当然，我们可以通过控制台或者帮助文档手动查询到这些信息，但是一方面查找不方便，另一方面，我们的模板可能随时会更新。如果在代码中硬编码ImageID，InstanceType和可用区等信息，一旦我们更新这些信息，模板就需要重新修改代码，非常不灵活。
在Terraform 中，Data Source 提供的就是一个查询资源的功能，每个Data Source实现对一个特定资源的动态查询：在模板中定义过滤条件，执行 plan 或者 apply 即可动态返回符合条件的资源。在编写Resource代码时非常方便，通过引用的方式可将Data Source的结果动态呈现给Resource。
Data Source通过 data 关键字声明，如下：
// Images data source for image_id
data "alicloud_images" "default" {
most_recent = true
owners = "system"
name_regex = "^ubuntu_18.*_64"
}
data "alicloud_zones" "default" {
available_resource_creation = "VSwitch"
enable_details = true
}
// Instance_types data source for instance_type
data "alicloud_instance_types" "default" {
availability_zone = data.alicloud_zones.default.zones.0.id
cpu_core_count = 2
memory_size = 4
}
resource "alicloud_instance" "web" {
image_id = data.alicloud_images.default.images[0].id
instance_type = data.alicloud_instance_types.default.instance_types[0].id
instance_name = "my-first-vm"
system_disk_category = "cloud_ssd"
...
}如上例子中的ECS Instance没有指定镜像ImageID和实例规格，而是通过 data 引用：Terraform运行时将首先根据镜像名称前缀选择系统镜像，如果同时有多个镜像满足条件，则选择最新的镜像。实例规格也是类似，在符合创建VSwitch的某个可用区下选择2核4G的实例规格进行返回，并将其中的第一个值赋值给Resource Instance。
4 一分钟部署ECS集群
读到此处，我们再回头考虑文章开始提到的：在阿里云控制台上需要20分钟甚至更久的时间来初始化一个经典的VPC网络架构。如果要在这个架构中搭建一个ECS集群，那么花费的时间将会更长。
如图展示了在一个VPC网络环境下，搭建一个单可用区的ECS集群，并通过Nat网关和EIP实现与公网环境的互通。
对于这样的一个网络架构，如果通过控制台来一步步搭建，至少需要十几步的操作和若干页面间的来回切换，费时又费力。但如果交给Terraform来做，借助已经实现的Module terraform-alicloud-ecs-cluster，只需一键就可在1分钟内搞定16个资源。
// 在杭州部署含6个节点的集群
module "cluster" {
source = "terraform-aicloud-modules/ecs-cluster/alicloud"
region_id = "cn-hangzhou"
cluster_size = 6
instance_name = "one-min-deploy-ecs-cluster"
}【此处有视频，可点击链接 听说“一分钟就能部署阿里云ECS集群”？ 】
如果想实现网络架构的跨Region复制或者同时部署，只需修改或者增加Region，执行 apply 命令即可。
// 在杭州部署含6个节点的集群
module "cluster-cn" {
source = "terraform-aicloud-modules/ecs-cluster/alicloud"
region = "cn-hangzhou"
cluster_size = 6
instance_name = "one-min-deploy-ecs-cluster"
}
// 在德国部署含8个节点的集群
module "cluster-eu" {
source = "terraform-aicloud-modules/ecs-cluster/alicloud"
region = "eu-central-1"
cluster_size = 8
instance_name = "one-min-deploy-ecs-cluster"
}
...5 写在最后
Terraform 是一个功能强大、使用简单的资源编排工具，秉承IaC的理念，将资源管理转换为代码模板管理，消除了大量重复的劳动，在大大降低资源管理复杂度的同时，提升了资源管理的灵活性；简单明了的编写语法，无需很深的编程功底，降低了开发者的学习门槛；资源状态的高度一致性，在保证资源有效管理的同时，简化了多人协作的流程和成本。
“提效、降成本”在Terraform帮助企业上云，迁云和管理云中得到了很好的体现。正如上文演示的，一分钟内快速初始化一个含6个节点的ECS集群和多Region的快速复制是对部署效率的极大提升。
阿里云对Terraform的支持力度只会越来越大，保持与阿里云控制台资源管理功能的一致性是阿里云Provider追求的目标，更多的产品和功能将持续不断的体现在Terraform中，基于Terraform Module的解决方案也将陆续推出，真正做到一个工具实现对阿里云所有资源的统一管理。
Terraform的用法非常多样灵活，本文只是带领大家了解Terraform，指导如何在阿里云上使用Terraform，后续将持续推出一系列文章来介绍更多高级的功能，并在“Aliyun开放平台”公众号中同步，尽情期待。
