昨天我們談論到 Remote State 與 Backend 的重要性，知道團隊協作不能只靠本機的 State 檔案。今天就要來實戰練習～將我們在第四天建立在本地的資源，改用 Google Cloud Starage 作為 Backend，讓狀態檔能集中存放並與團隊共享！

🐈🐈🐈

今天的目標

我們的目標很明確：就是把原本存在本地端的 terraform.tfstate 這隻狀態檔搬到 GCS Bucket。讓之後的 plan 與 apply 都會直接讀寫到 GCS 中！

建立 GCS Bucket

首先我們要先創建一個用來存放 State 的 bucket：

要記得開啟 Object Versioning，這樣在狀態檔被錯誤覆蓋時，還可以回復到過去的版本喔！這邊幫大家筆記一下在配置時看到的兩個選項：

Max. number of versions per object

• 每個物件最多保留多少個歷史版本。
• 如果填 1 就只會有最新版本，就幾乎沒有回覆就檔的能力！所以會建議至少配置 2 或以上喔！這樣才有開啟這個配置的作用～

Expire noncurrent versions after X days

• 舊版本會在幾天後自動刪除，可以控制儲存成本，避免版本無限累積造成額外的成本喔～
• 官方是建議 7 天（特別是 Standard storage class 情況下是最划算的），不過實際天數還是依照團隊需求去調整喔～

專案配置 backend

接著我們回到在第四天本地配置的專案中，我們要修改 main.tf 加入 backend 的設定：

terraform {
  backend "gcs" {
    bucket = "terraform-state-try"
    prefix = "day07"
  }
}

• backend：我選擇使用 GCS，大家可以依照自己選擇的去調整。
• bucket：剛剛我們建立的 bucket 名稱。
• prefix：這其實就是「資料夾路徑」的意思，可以用來區分不同環境或專案，例如：dev/、stage/、prod/ 等等。

執行 terraform init

配置好之後，我們要重新執行 init，讓 Terraform 知道我們有新的配置是要把 State 改存到 backend 中！

terraform init

• 這邊 Terraform 會自動偵測到你有本地 State，並會詢問你是否要把 State 搬到 Remote Backend？輸入 yes

登愣！這時候就會輸出成功的訊息啦：

然後我們去 GCS 確認一下：

這樣就成功把 Terraform 儲存 State 的位置改成 backend 了！

💡 小提醒：IAM 權限配置

在今天的實作中，因為我的本機已經有設定了 ADC（Application Default Credentials），所以不需要特別配置就能成功寫入 GCS。但大家在實際配置時一定要特別注意 IAM 的權限設定！

以 Google Cloud Platform 為例需的基本權限有：

• Storage Object Admin (roles/storage.objectAdmin)：用於讀寫 state 檔案。
• Storage Legacy Bucket Reader (roles/storage.legacyBucketReader) ：用於列出 bucket 內容。

配置方式選擇：

1. 使用 Service Account
2. 為使用者帳號配置權限
3. 在 CI/CD 環境中使用 Workload Identity

大家一定要遵循最小權限原則，只給予必要的權限～才不會有權限過大所產生的風險喔！

沒有正確的 IAM 配置，就會遇到 403 Forbidden 或 storage: insufficient permissions 的錯誤訊息喔！所以如果你在實作上有遇到相關的錯誤不用太緊張，去檢查一下 IAM 的配置就可以囉～

總結一下

今天我們成功透過將 Terraform State 從本地端遷移到 Google Cloud Storage 解決了團隊協作會遇到的核心問題，幫大家回顧兩個重點：

• 在創建 GCS Bucket 要記得開啟 Object Versioning 確保狀態檔的版本管理。
• IAM 權限配置的重要，這也是實作上容易忽略掉的地方喔！

🐈🐈🐈

明天我們要試著用 Terraform 在雲端上建立第一台 VM ～🤩✨