AWS CloudFormation 與 Terraform：難以抉擇？ 本文旨在協助您做出更明智的選擇。
雲計算已徹底改變了 DevOps 的世界。 它不僅僅是一個流行語，它真實存在，並正在改變我們開發和維護應用程式的方式。 雖然有數不清的理由說明您應該為各種規模的企業採用雲計算，但其中一個限制是，您必須手動配置基礎架構。
您需要前往您的雲供應商的控制台，告訴他們您想要什麼。 這對於小型使用案例來說還可以接受，但如果不同的用戶都在控制台中進行配置變更，情況會怎樣呢？ 您最終可能會得到一個極度複雜的基礎架構，而且維護起來會越來越困難。 沒有有效的方法可以協作或追蹤雲端基礎架構的變更。 其實，方法是有的，那就是基礎架構即代碼 (Infrastructure as Code)。
基礎架構即代碼是雲計算中一個非常流行的術語。 它是使用代碼管理 IT 基礎架構的過程。 沒錯，您沒聽錯。 相較於前往控制台手動執行所有操作，基礎架構即代碼 (IAC) 允許您編寫配置文件，然後配置您的雲端基礎架構。 IAC 為我們帶來了一致性、簡單快速的維護，並且避免了人為錯誤。
將 IAC 與 Amazon Web Services 結合使用
AWS 是全球領先的雲計算服務，其市場佔有率是緊追其後的雲供應商的兩倍。 AWS 上有超過 200 項服務，可以滿足各種各樣的使用案例。
當您開始將 IAC 與 AWS 結合使用時，您通常會將選擇範圍縮小到 AWS CloudFormation 和開源工具 Terraform。 在嘗試在這兩者之間做出選擇時，理解這兩個工具提供的眾多功能可能會讓人感到不知所措。 在本文中，我們將探討 AWS CloudFormation 和 Terraform 之間的差異，以幫助您確定哪種工具更適合您的需求。
Terraform 與 AWS CloudFormation：差異比較
模組化
在大型組織中使用 IAC 時，模組化可能是選擇正確工具的關鍵因素。
CloudFormation
CloudFormation 沒有對模組的原生支援。 它允許您使用一種稱為巢狀堆疊的東西作為模組。
例如，您可以針對組織中如何佈建 S3 儲存貯體制定標準配置。 因此，您建立一個標準的 CloudFormation 模板來建立 S3 儲存貯體。 現在，當最終使用者想要建立 S3 儲存貯體時，他們可以使用此 CloudFormation 模板作為巢狀堆疊，以建立標準的 S3 儲存貯體。
AWS 還有一個鮮為人知的服務，AWS 服務目錄，它可以協助您實現 AWS CloudFormation 的模組化。 Service Catalog 是一項 AWS 服務，專為希望限制 AWS 服務範圍以滿足合規性、安全性、成本或效能要求的組織而設計。 您猜怎麼著？ AWS Service Catalog 在後端使用 CloudFormation 模板。
讓我們通過一個例子快速理解這一點。 如果使用不當，S3 儲存貯體很快就會對您的機密資料造成災難性的影響。 讓我們舉相同的例子，您希望有一種標準方式來說明您希望如何在組織中使用 S3。 第一個選項是建立巢狀堆疊模板，它可以應用於其他 CloudFormation 堆疊，效果也一樣好。
如果您不希望用戶必須將此標準模板用作巢狀堆疊，您可以使用 AWS Service Catalog。 服務目錄將允許用戶從控制台的 UI 中使用此標準模板並指定一些參數，以進行輕微的自定義。 這將允許您控制如何在 AWS 帳戶中佈建基礎架構，並防止出現任何不需要的情況。
Terraform
Terraform 具有對模組的原生支援。 它允許您建立與 AWS CloudFormation 非常相似的標準配置，並將其用於其他 Terraform 配置。
由於 Terraform 是一個開源工具，您還可以在 Terraform Registry 中找到並使用一些預製的開源模組。 您也可以使用自己的配置建立自己的模組，並將它們託管在私有模組註冊表上。
就個人而言，如果模組化是一個很大的需求，我更喜歡使用 Terraform 而不是 CloudFormation。
在 CloudFormation 中使用巢狀堆疊不像在 Terraform 中使用模組那麼容易。 主要因素是，將資料從 CFN 模板傳遞到巢狀堆疊可能相當複雜。
沒有可以共享 CloudFormation 模板的標準位置。 您可以使用 AWS 服務目錄，但這只是您通過控制台執行一些建立基礎架構規則的一種方法。 我們更喜歡以程式碼為主。 使用服務目錄時，雖然一些複雜的任務被封裝在 CloudFormation 檔案中，您仍然需要通過手動任務去控制台，並指定參數來配置您的基礎架構。
另一方面，Terraform 擁有一套建立、維護和共享模組的方法。 您可以在 Terraform 模組註冊表中查看模組的確切要求，並非常輕鬆地在您的 Terraform 檔案中使用它們。
對基礎架構的控制和治理
如果您想限制您的人員可以在您的 AWS 帳戶中建立的資源：AWS CloudFormation 和 Terraform 都提供了實現此目的的方法。
讓我們首先談談 CloudFormation。 CloudFormation 本身不對模板的使用方式提供任何控制，但您可以使用 AWS IAM 策略，僅允許 AWS 帳戶中的用戶僅使用標準 CloudFormation 模板來建立資源。 在我們的 S3 儲存貯體示例中，您可能希望限制用戶的所有「S3 建立」權限，只允許他們從 AWS 服務目錄或巢狀堆疊建立 S3 儲存貯體。
Terraform 允許您使用策略即代碼工具來控制用戶可以建立哪些資源，Sentinel。 Sentinel 允許您執行細粒度、基於邏輯的策略，以允許或拒絕用戶通過 Terraform 執行的操作。 例如，您可以拒絕所有建立 S3 儲存貯體的資源，只允許用戶從標準模組建立 S3 儲存貯體。
狀態管理
AWS CloudFormation 和 Terraform 都需要追蹤它們維護的資源。
Terraform 將基礎架構的狀態儲存在狀態檔案中。 該檔案預設儲存在本地，但您可以將其儲存在 S3 等遠端後端，並允許多個用戶對同一組基礎架構進行變更。
CloudFormation 不維護狀態檔案，至少不是我們可以看得到的。 CloudFormation 是一項託管服務，因此它會在後台進行所有狀態維護和檢查。
AWS CloudFormation 和 Terraform 都可以讓您檢查將對您的基礎架構進行哪些變更。 在 Terraform 中，您可以執行命令 「terraform plan」以及 Terraform 計劃如何應用您的配置變更。 在 CloudFormation 中，用戶可以通過變更集查看此資訊。
語言
Terraform 使用 HashiCorp 配置語言 HCL，這是一種由 HashiCorp 建立的語言。 它與 JSON 非常相似，具有額外的內建特性和功能。
CloudFormation 模板以 YAML 或 JSON 格式編寫。
日誌記錄和回滾
AWS CloudFormation 和 Terraform 都具有良好的日誌記錄功能。 以我的經驗，錯誤和問題很容易（大部分）排查。
CloudFormation：預設情況下，CloudFormation 會在堆疊變更失敗的情況下回滾您的所有變更。 這是一個很好的功能，可以出於任何除錯目的禁用。
Terraform：Terraform 不會在失敗時自動回滾您的變更。 這不是問題，因為您始終可以執行 `terraform destroy` 命令來刪除半配置的配置，並再次重新啟動 Terraform 運行。
範圍
Terraform 不僅限於 AWS 雲。 在 Terraform 和 CloudFormation 之間進行選擇時，最重要的因素是 Terraform 支援其他雲供應商和服務。
因此，如果您打算將 IAC 用於多個雲平台，Terraform 是您的最佳選擇。 CloudFormation 雖然是一個強大的工具，但僅限於 AWS。 通過使用 Terraform，您可以設置基礎架構並將應用程式部署在多個雲平台中，從而使您的應用程式更加可用和健壯。
功能支援
通常，隨著 AWS 推出新的服務和功能，CloudFormation 將會在 Terraform 之前更新，因為它是 AWS 服務。 截至目前，這兩種工具都涵蓋了這些服務的大部分服務和功能。 這可能是使用 Terraform 的一個小缺點，但是我們確實有解決方案。
您還可以在 Terraform 代碼中建立 CloudFormation 堆疊。 因此，如果您使用 Terraform，且其不具有某項功能，您可以在 Terraform 代碼中臨時設置 CloudFormation 堆疊。
技術支援
付費的 AWS 技術支援計劃也涵蓋 CloudFormation 支援。
HashiCorp 也為 Terraform 提供付費的技術支援計劃。
結論
AWS CloudFormation 和 Terraform 都是功能強大且完全開發的工具。 上述差異將幫助您做出明智的決定，根據您的要求選擇工具。 作為個人建議，如果您計劃在未來使用多個雲平台，或目前正在使用多個雲，您應該使用 Terraform 作為滿足您所有需求的一站式商店。 如果您正在尋找僅適用於 AWS 的 IAC 工具，AWS CloudFormation 和 Terraform 都是不錯的選擇。
如果您有興趣學習 Terraform，請查看這些線上課程。