昨天我們完成了第一個 VM module,成功把散落的資源組裝起來,變成可重複使用的積木。
但光是能用是還不夠的,在實務專案裡,我們應該去思考 如何設計一個好維護、好擴充的 module。今天就是要一起來探討模組設計原則與參數管理。
🐈🐈🐈
一開始寫 module 的時候,可能會覺得「能跑就好」。
但當專案愈來愈大、團隊人數增加時,如果沒有設計規範,會發現 module 會變成難以維護的黑箱。
好的 module 設計,應該像是乾淨的 API:
換句話說,module 設計得好,基礎建設的程式碼就能真正做到「寫一次,多處使用」!
每個 module 應該專注在「一件事」。
例如:
vm
module → 建立 VMnetwork
module → 建立 VPC 與子網路storage
module → 建立 Bucket不要把 VM、VPC、Load Balancer 全都塞在同一個 module,否則就失去抽象化的意義。
簡單來說,我們可以把 module 想成「積木」,而不是「整棟大樓」。
設計變數(variables)時要有取捨。
這樣當我們在呼叫 module 時,就不需要被迫輸入一大串參數,只需要在必要時才調整。
舉個例子:
variable "machine_type" {
description = "機器規格"
type = string
default = "e2-micro" # 提供合理預設值
}
好的 module 介面,應該要是簡單直覺,就像呼叫一個 API!
輸出是 module 的回饋結果,能幫助我們快速取得關鍵資訊。
舉個例子:VM module 不需要把整個 google_compute_instance
都輸出,只要給常用的值(名稱、IP)即可。
這樣能避免 Root module 的程式碼過度依賴底層細節。換句話說,module 的輸出就是它的「對外合約」。
很多人會一開始就想把 module 設計得「什麼需求都能支援」,結果反而太複雜~
建議的做法是:
模組應該有一致的目錄結構,例如:
modules/
├── vm/
│ ├── main.tf
│ ├── variables.tf
│ └── outputs.tf
├── network/
└── storage/
而且會建議每個 module 都有清楚的 README.md
,簡單說明用途、需要哪些參數、會輸出哪些值。
這樣團隊成員在使用時,就不需要花時間再翻 source code 才能理解。
除了 module 自己的變數設計,我們也需要進一步思考整體專案的參數管理:
terraform.tfvars
或環境專屬檔案例如:
dev.tfvars
staging.tfvars
prod.tfvars
這樣就能用同一份 module,搭配不同參數檔,快速建立不同環境。
terraform apply -var-file="dev.tfvar
不要在 module 裡直接寫死值,例如:
zone = "asia-east1-b"
應該改成變數,並提供預設值:
variable "zone" {
default = "asia-east1-b"
像密碼、金鑰這類敏感資訊,應該用以下方式管理:
sensitive = true
的變數或輸出避免寫死在 tfvars 或 Git 版本庫裡。
今天我們聊解到的不再是單純「怎麼寫一個 module」,而是 怎麼寫一個好的 module。
幫大家重點回顧:
我們最終目標是讓 module 成為乾淨、可重複使用的積木,讓團隊能快速、安全地建立基礎設施!
🐈🐈🐈
明天我們會進一步探討 Terraform Registry 上的現成模組。
大家就會發現,很多常見的基礎設施(像 VPC、Security Group)其實已經有人寫好 module 了,我們不一定要從零開始,而是能直接拿來用,站在巨人的肩膀上加速開發!