本文同步刊登於個人技術部落格，有興趣關注更多 Kubernetes、DevOps 相關資源的讀者，請務必追蹤從零開始的軟體工程師之旅，喜歡的話幫我按讚分享、歡迎留言、或是許願想要看的文章。
如果有技術問題也可透過粉絲專頁 討論，技術方面諮詢免錢、需要動手做另計 XD。
上面講解 Terraform 的基本操作流程，提供範本原始碼，以及一步一步導入的詳細步驟。各位應該都可以依照上面幾篇的說明，開始快樂的使用 Terraform 了。
而當使用 Terraform 的規模越來越大，管理的資料越來越多時，開始會出現一些問題，例如重複的 terraform code 越來越多，協同工作 review 不太容易，state 的內容管理與鎖管理，等等。這些問題可以透過一些工作流程的改進，或是導入新的小工具，來改善工作效率。
接下來筆者推薦幾個心得與工具，希望能提升使用 Terraform 的效率與產值
以下幾篇文章，適合已經使用過 terraform 一點時間，有經驗的團隊，並打算更大規模導入 terraform，正在尋求改善的方向。
當公司成功導入 terraform ，並且整合 Git-flow 的工作流程後，應該可以很明顯的感受到，整體的 infrastructure 產出穩定度有大幅提升，畢竟軟體工程中 code review 是穩定度的核心關鍵之一，而導入 terraform 與 infrastructure as code 讓 infrastructure 也能在合理的工作流程中被層層 review。
stable master -> feature/add-new-infra -> PR feature/add-new-infra -> master
feature branch merge 進去 master 之後，就確定是 review 過而且穩定的程式碼，再由工程師 pull 最新的 master ，然後在本地執行 terraform apply，把 infrastructure 生出來。
這樣做本質不會有什麼大問題，畢竟 code 已經是穩定。然而，實務上卻還是會出現偶發的問題。例如：使用錯誤的 credentail 或 context，導致 dev 或 staging 的 infrastructure apply 到 prod 上，直接 p0 issue 大爆發，SRE 都跪著上班。又例如：使用錯誤的 master 版本 apply，結果也是服務掉線，整個 team 跪著上班。
關鍵：團隊整體的安全性，是由程度最菜的同事決定。
對我就是在說你XD。然而人都會菜，而人事成本也是公司經營的關鍵考量，相信所有同事都大神是不切實際的，不如改進工作流程，近一步降低人為操作失誤的可能。人的問題，根本之道還是教育，然而我們可以試著用技術與工具降低風險。
以下的做法，可能會協助避免這個問題。我們要做的就是 CI/CD 的全自動化。
事實上，不同家的 CI/CD server，工作流程都是類似
如果是 Jenkins 的使用者，可以參考 Azure 提供的範例
在人工 apply 的工作流程中，工程師需要自行切換環境，例如 git repo 工作目錄如下
tree
project
├── dev
├── staging
└── prod
cd project/dev; terraform plan # plan staging
cd project/prod; terraform plan # plan prod
這是相對比較安全的做法，在對的資料夾目錄下，就會 apply 到正確的環境，程式碼與環境有緊密的對映。除了以下幾種情形
對很愚蠢，但我都見過（氣血攻心）。
既然導入了自動化，環境的切換可以自動切換，例如
資深工程師只要控制 branch / tag 就可以控制發布。
你說這樣，萬一天兵去自己打 tag 打錯 commit，或是推錯 branch 推到 master或是 release candidate，還不是依樣爆掉。那你可以把 master 與 release branch 鎖起來 (protected branch) ，然後把 tag push 權限鎖住。
你說還是錯
那我...
...們看下一段 orz
雖然說是自動化改善工作流程，然而收回存取權限，對於服務的整體安全性大幅提升，畢竟是可以更改 infrastructure 的管理員帳戶。Terraform 既然能夠新增修改雲端的 infrastructure，這個帳號的權限是相當大的，萬一金鑰(GCP/AWS/Azure credentail) 流出或遭駭，後果都是毀滅性的，例如可以直接刪除服務的 infrastructure，或是修改防火牆的規則，偷埋其他金耀，...等於是整座公有雲送給駭客。所以我們使用 Terraform 應該要慎重考慮存取權限的安全性。
本來是每個 SRE 的本機電腦上，可能都會有這把帳戶權限。
如果是 self-hosted Jenkins server，或是 Github enterprise server，把服務權限移轉到這些服務器，便可以確保金鑰永遠都在公司的防火牆內部網路，更加大幅度的提升整體的安全性。
可以進一步做金鑰權限分割，將底下四個權限透過公有雲的 IAM role 去切割。要是萬一金鑰還是外洩了，可以降低損失。
你說這個不用自動化就可以做，我說如果分割金鑰然後人工自己切換操作，反而會增加操作的複雜度，增加錯誤的機會。然後工程師的痛苦程度，與手上的金鑰數量成正比。
或是利用環境存取金耀分割，把金耀進一步切割成不同的權限，萬一掉了，損害也控制在一個環境之內。例如：
不同環境的 infrastructure ，在創建初期就是透過不同的帳號產生的，彼此不會有不乾淨殘留的帳號權限。
這邊就講兩件事
Terraform Official doc: Running Terraform in Automation
iThome鐵人賽
看影片追技術