使用 Terraform 五年的經(jīng)歷讓我吸取到一些重要經(jīng)驗。無論團隊大小、項目性質(zhì)，有五條要點對于配置合乎邏輯且可用的 Terraform 平臺至關重要。

1、了解你的目標受眾

這一點似乎顯而易見，但我也見過一些在這方面犯錯的案例。當組織和規(guī)劃 Terraform 的相關代碼時，無論是將目錄結(jié)構(gòu)標準化還是確定命名規(guī)范，考慮目標受眾是非常重要的。例如：你的團隊是否會使用這些 Terraform 腳本和模塊？你是否會向其他團隊交接工作？你的團隊是否會有新成員加入？你是否正在獨自進行項目開發(fā)？你是否會半年或一年后仍然使用這些配置，還是會將它安排給別人？

這類問題會影響某些決策。理想情況下，無論如何都應該有 ??遠程狀態(tài)??Remote State 和 ??狀態(tài)鎖定??State Locking

命名規(guī)范應該對項目的最終擁有者有意義，而不是只對開發(fā)團隊有意義。如果項目會轉(zhuǎn)交給其他團隊，應該確保他們對命名規(guī)范有發(fā)言權(quán)。如果代碼由非技術(shù)的利益相關者或內(nèi)部安全/ GCR 團隊負責審查，應該確保他們會檢查命名規(guī)范。另外，對于資源名稱，為了讓代碼審查人員更仔細地進行檢查，你應該使用資源標簽，把有關的數(shù)據(jù)分類/隱私需求（高、中、低）標示出來。

2、重用，重用，重用

??Terraform 注冊表?? 為大多數(shù)普通用例提供了現(xiàn)成模塊類庫。我已經(jīng)使用過 VPC 模塊和安全模塊中的大量功能，這些功能只需要提供相關的參數(shù)就能使用。使用不同的參數(shù)，簡單調(diào)用這些模塊對于處理大部分用例已經(jīng)足夠了。盡可能多地重用這些公共模塊，可以避免大量且重復的編碼、測試、檢查、修復、重構(gòu)等操作。

我也發(fā)現(xiàn)，基于使用或變更的頻率劃分模塊和資源大有好處。例如，只使用一次的基礎設施手腳架，例如 VPC 相關設置、安全模塊、路由表、VPC 端點等，可以放在一起。但是像私有托管域條目、自動伸縮模塊、目標模塊、負載均衡器等，每次部署時都會變化，所以把這些與一次性的基礎設施手腳架分離開來，會令代碼檢查更方便，調(diào)試更快速。

3、要明確，而非隱含

Terraform 代碼中有一些常見的模式，它會導致設計中出現(xiàn)錯誤的假設。團隊可以假設用來寫代碼的 Terraform 版本永遠保持不變，外部模塊不會變化，或它們使用的提供者不會變更。當這些外部依賴不可避免地發(fā)生變化時，就會導致一些難以發(fā)現(xiàn)的問題。

無論何處（包括主要的 Terraform 組、提供者組、功能模塊組）都要確保定義是明確的。事先定義版本，可以確保依賴庫是固定的，因此你可以在討論、審查、測試后，明明白白地更新依賴關系。

4、自動化每一處，包括筆記本電腦、共享虛擬機、CI/CD。

在部署的各個階段使用自動化方法，可以避免可能發(fā)生的問題。

在你提交代碼前，使用 ??Git 預提交鉤子?? 運行 ??terraform fmt?? 和 ??terraform validate??。預提交鉤子的作用是確保你的代碼滿足最低程度的格式和語法正確。把這個預提交文件檢入到倉庫，對你的團隊成員都有好處。項目的第一步就進行質(zhì)量控制相關的操作，它雖然表面上是小事一樁，但也很重要，能為項目節(jié)省大量時間。

一切現(xiàn)代化部署工具都有 CI 流程。當你向原始倉庫推送代碼時，可以使用它來運行 SAST 和單元測試工具。我寫過一篇 ??博客??，是關于使用 Checkov 測試 Terraform 代碼的安全性和合規(guī)性，并為組織特定的慣例創(chuàng)建自定義檢查。把這些單元測試工具加入到你的 CI 管道，可以改進代碼質(zhì)量和健壯性。

5、寫個好的 README.md 文件

我們都認為 Terraform 代碼是自文檔化的。的確如此，但是只有當未來的團隊已經(jīng)了解你的公司的命名規(guī)范、開發(fā)指南、機密通信、圈內(nèi)笑話，以及你的倉庫內(nèi)除有效的 Terraform 代碼之外其他所有東西，才會如此。維護 ??README.md?? 文件是個好習慣，它能節(jié)省大量時間，而且團隊成員要為自己向 README 文件提交的任何內(nèi)容負責，這樣也就確保團隊成員的忠誠度。

你的 README 文件至少應該包含在你的工作環(huán)境下（Linux、 Windows、Mac 等等）初始化 Terraform 環(huán)境的步驟，包括 Terraform 的版本信息。它應當確定需要的依賴庫（Checkov、 TerraGrunt 及其他依賴）和其版本，以及團隊使用的方便的 Linux 別名（例如有人喜歡將 ??terraform fmt?? 簡寫為 ??tff??）。最重要的是，需要確定分支和 PR 審核策略和流程、命名規(guī)范和資源標簽的相關標準。

README 文件需要通過這樣的檢驗：如果團隊有新成員加入，能否告訴他們做什么以及如何正確地完成工作？如果不能，在后續(xù)的幾個月內(nèi)，你將面對的是無休止的標準和流程討論會議。

結(jié)束語

這些就是我使用 Terraform 多年后，認為需要傳授給大家的五條有用的建議。