還記得昨天文章的最後我們設想了一個情境，當兩個工程師同時要調整配置，這時候狀態檔又該怎麼避免衝突並好好管理呢？今天我們就要來分享團隊合作的關鍵 —— Remote State 以及 Backend～

🐈🐈🐈

為什麼需要 Remote State 呢？

有幾個具體的原因：

1. 共享最新狀態：每個人都能讀取同一份 State，就能避免「我這邊的狀態」和「你那邊的狀態」不一樣。
2. 避免衝突：可以透過狀態鎖確保一次只有一個人能對 State 做變更。
3. 資訊安全：前一篇文中提到 State 中是會明文存放敏感訊息的，如果這些資料都放在自己的電腦中，風險其實很高。但將其安全放在遠端存儲，就能降低洩漏風險。

那 Backend 是什麼呢？

Remote State 比較像是一個概念，但實際上要怎麼存？這時候就要靠 Backend 了！這個角色定義 Terraform 的狀態要存在哪裡？怎麼被存取？有兩種類型：

Local Backend (預設)：

• 狀態檔：terraform.tfstate 在本機
• 適用：個人學習、簡單測試

Remote Backend (以 GCS 為例)：

• 狀態檔：存在 gs://your-bucket/path/to/terraform.tfstate
• 適用：團隊協作、正式環境

官方有提供 Terraform Cloud，但也可以使用其他雲端的存儲服務，例如：GCP Google Storage、AWS S3、Azure Storage 等。

簡單來說，Backend 就是 Remote State 的「存放地點與機制」，而在 GCP 上，最常見的就是透過 GCS 作為 Backend。

狀態鎖 (State Locking)

除了共享狀態以外，另一個很重要的功能就是 狀態鎖。

如果沒有鎖定機制，就會出現「A 更新到一半，B 又寫進去」的情況，結果 state 檔被覆蓋，最後誰也說不清楚基礎建設的真實狀態。

舉例來說，在 GCP 的 Backend（GCS）中，Terraform 會透過 原子操作 (atomic operation) 來確保狀態鎖定：

• 當一個人正在操作時，Terraform 會在 GCS 上加上一個「鎖定檔 (lock file)」。
• 其他人嘗試操作時，會發現鎖已存在，必須等鎖釋放才能繼續。

實際遇到衝突時會看到類似訊息：

Error: Error acquiring the state lock. 
Lock Info: ID=xxx, Operation=xxx, Who=user@company.com

這樣團隊才能避免「同時操作、互相覆蓋」的悲劇發生。

環境分離的最佳實務

在團隊協作中，通常會針對不同環境使用不同的狀態存放路徑：

- dev 環境：gs://company-terraform-state/dev/
- staging 環境：gs://company-terraform-state/staging/
- prod 環境：gs://company-terraform-state/prod/

這樣可以確保各環境的狀態完全隔離，避免誤操作。

團隊合作的關鍵

所以說！使用 Remote State + Backend 後，團隊合作會變得更順暢：

• 不需要再手動傳遞 state 檔。
• 每次操作都能保證一致的狀態來源。
• 配合環境分離（dev / staging / prod 各自使用不同 prefix），團隊管理更清晰。
• 搭配 IAM 權限，控制誰能讀取、誰能修改，安全性更高。

總結一下

Remote State + Backend 的核心價值，就是讓 Terraform 不再只是單機小工具，而能變成真正的團隊協作基礎建設管理平台。

🐈🐈🐈

下一篇我們就會實際操作，把 Day 04 在本機練習的資源狀態轉移到 Remote State（我會用 GCS Backend 來練習）🚀