不知道大家還記不記得在前面的章節中我有提到在 Terraform 的世界中 Provider 是翻譯官～ Terraform 會用自己的語言（HCL）描述基礎建設，但要跟 GCP、AWS Azure 等等不同雲服務溝通就必須要靠 Provider 把這些清單翻譯成對應的 API 呼叫。

今天我們要針對 Provider 聚焦在三個主題：

1. 多雲部署時的 Provider 配置。
2. 版本管理。
3. 認證設定

🐈🐈🐈

多雲部署

想想看如果今天我們的需求是

• 將主要的儲存放在 GCP Cloud Storage
• 備份放到 AWS S3
• 並用 Cloudflare 管理 DNS

這時候就沒辦法單純只使用一個 Prvider 來翻譯了！就需要配置不只一個 Provider，像這樣：

terraform {
  required_providers {
    google     = { source = "hashicorp/google", version = "~> 5.0" }
    aws        = { source = "hashicorp/aws", version = "~> 5.0" }
    cloudflare = { source = "cloudflare/cloudflare", version = "~> 4.0" }
  }
}

provider "google" {
  project = "my-demo-project"
  region  = "asia-east1"
}

provider "aws" {
  region = "ap-southeast-1"
}

provider "cloudflare" {}

Terraform 的 Provider 有很多不同種類與來源，可以在 Terraform Registry 找到不同的 Provider，主要的三大類型：

但要特別注意選擇的 Provider 是否還有在維護喔～

Provider Alias

有時候在同一個專案中，會需要同時操作多個不同「身份」的 Provider。有可能是：

• 不同地區
• 不同專案
• 不同權限
• 不同 API

這時候就可以透過 Alias 幫 Provider 加上一個「代號」，讓 Terraform 知道要用哪個 Provider 來部署資源。這邊舉個常見的例子，如果我們需要同時在台灣（asia-east1）與美國（us-central1）建立資源，就可以這樣寫：

provider "google" {
  region = "asia-east1"
}

provider "google" {
  alias  = "us"
  region = "us-central1"
}

resource "google_compute_instance" "vm_taiwan" {
  name         = "vm-tw"
  provider     = google
  machine_type = "e2-micro"
  zone         = "asia-east1-b"
}

resource "google_compute_instance" "vm_us" {
  name         = "vm-us"
  provider     = google.us
  machine_type = "e2-micro"
  zone         = "us-central1-a"
}

這裡的 google.us 就是告訴 Terraform：「這台 VM 要用別名 us 的 Provider，也就是部署在美國。」

版本管理

想像一下，如果同一個團隊裡的翻譯官各自用不同的翻譯字典，會發生什麼事？

🙍🏻‍♀️ A 翻譯官用 5.9 版字典
🙍🏻‍♂️ B 翻譯官用 5.11 版字典

結果呢？同一句話，可能被翻出兩種完全不同的意思。

在 Terraform 裡，這就會變成 不同人跑出來的基礎建設配置不一致： 有人建立成功，有人錯誤，有人甚至建立了不同的資源！

Terraform 的解法

為了避免這種「字典混亂」的狀況，我們需版本鎖定 (version pinning)：

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.10" # 允許小版本更新，但大版本不變
    }
  }
}

這樣做有幾個好處：

• 確保整個團隊用的都是「同一本字典」
• 避免小更新變成大改版造成破壞性變更

而且 Terraform 在初始化後，會生成一個 .terraform.lock.hcl，這份檔案就像是「團隊統一版的字典清單」，保證大家翻譯時用的版本一模一樣。

補充一下：版本約束的寫法說明

• 精確版本：= 5.10.0 最穩定，生產環境常用
• 悲觀約束：~> 5.10 允許 5.10.x 的更新，避免大版本變動
• 範圍：>= 5.0, < 6.0 彈性大，但風險也高

升級流程

當然～我們也不能永遠卡在舊版本，升級也要有流程：

1. terraform init -upgrade → 把字典更新到最新允許的版本
2. terraform plan → 試翻譯一遍，確認新的字典沒有亂翻
3. 沒問題後再提交 .terraform.lock.hcl → 團隊全體升級

版本管理的核心，就是「確保所有翻譯官用的字典一致」。
這樣不管誰來執行 Terraform，結果都會一樣，才不會有人說 A 建立成功、B 卻爆炸。

認證設定

即使翻譯官再專業，如果沒有 工作證，也進不了會場。
在 Terraform 裡，Provider 中的認證 就是翻譯官的工作證，確保它有權限操作雲端資源。這邊舉兩個例子：

GCP

provider "google" {
  credentials = file("service-account.json")  # 工作證
  project     = "my-project"
}

AWS

provider "aws" {
  region     = "ap-northeast-1"
  access_key = var.aws_access_key  # 工作證
  secret_key = var.aws_secret_key
}

特別提醒

記得不要把金鑰寫死在程式碼裡，這樣版本控制一提交就曝光，安全風險非常高～
建議使用環境變數或 CI/CD Secret Manager 提供。
這樣做的好處：

• 翻譯官自動帶著工作證進場
• 程式碼不用存敏感資訊，安全又方便
• 團隊每個人都能使用同一份程式碼，環境不同但認證安全

總結一下

今天我們深入探討了 Terraform Provider 的三個核心主題：多雲部署、版本管理與認證設定。

掌握這三個概念，就能確保基礎建設部署穩定、一致又安全，也讓團隊協作更順暢。當然，Provider 能做到的不只這些，它還能支援多身份配置、動態 Provider，甚至自訂 Provider，但那些就是比較進階的應用，但目前對我來說有點越級打怪了，等未來我升級了有機會再跟大家分享😆