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等各家的資源編排服務相比,主要有幾個特點:
1.開源
從誕生之初,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"
...
}
對資源的定義包含如下幾個部分:
-
為資源類型,定義目前資源的類型,告訴Terraform這個Resource是阿裡雲的虛拟機還是其他資源,如VPC、SLB等。alicloud_instance
-
為資源名稱,資源名稱用來辨別所定義的資源,在同一個模闆(即目前運作目錄下所有以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.html3.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,後續将持續推出一系列文章來介紹更多進階的功能,盡情期待。