範圍

明確界定可部署架構的範圍至關重要，因為它應該足夠全面，包括所有必要資源，但足夠集中，以避免不必要的複雜性。

最佳實踐是將通常作為單元共同部署、需要相似存取權限且具有相同生命週期的基礎架構資源納入其中。 例如，讓我們考量 VPC landing zone 可部署架構。 此可部署架構具有明確定義的範圍，其中包括下列基礎架構資源:

這些資源通常作為一個整體部署，需要類似的網路管理權限，並具有相同的生命週期，這意味著它們：

• 會一起建立，例如當佈建新的 VPC 及其相關聯的子網路、公用閘道和安全群組時。
• 一起更新，例如當對 VPC 的網路配置進行變更時，需要更新子網路、公用閘道及安全群組。
• 一起刪除，例如當 VPC 解除任務且移除其所有相關聯資源 (包括子網路、公用閘道及安全群組) 時。

可組合

可部署架構的一個基本原則是可組合性，它可以透過將多個可部署架構堆疊在一起來創建更廣泛的可部署架構。 此模組化方法容許自動化資源的最大彈性及重複使用性。

為了達到可組合性，應該將可部署的架構設計成:

• 將透過輸出值顯示的資訊量最大化，但讓輸出類型保持簡單。 此實務可讓可部署架構自動化在各種實務範例中重複使用，並使它成為各種自動化解決方案的多用途建置區塊。

• 容許對現有已部署資源的選用參照，例如資源群組、IBM® Key Protect for IBM Cloud® 或 Hyper Protect Crypto Services 實例，以及 IBM Cloud Secrets Manager 實例等。 然後，使用者可以配置現有實例或部署至現有資源群組，以增加自動化的通用性。 Secrets Manager 可部署架構 是此原則在實際運作中的絕佳範例。 透過容許使用者重複使用現有的 Secrets Manager 實例、資源群組及 KMS 加密金鑰，此自動化提供高度彈性及適應性。 例如，您可以：

  • 透過傳遞現有實例的 ID 來配置現有 Secrets Manager 實例，並在現有實例中建立密鑰群組。
  • 與現有金鑰管理系統 (例如 Key Protect 或 Hyper Protect Crypto Services) 整合。
  • 部署在現有資源群組中，或建立具有可自訂命名慣例的新資源群組。

或者，此可部署架構也容許從頭開始建立新的 Secrets Manager 實例、新的資源群組及其他資源，以提供獨立式解決方案。

透過採用可組合性，可部署架構可透過與其他可部署架構堆疊，輕鬆整合為更複雜的解決方案架構。 例如，Retrieval Augmented Generation Pattern 展示了如何結合多種可部署架構 (包括 Secrets Manager 可部署架構) 來建立複雜的解決方案。 可部署的架構在設計時已考慮到可組合性，為這些複雜的解決方案奠定了基礎。

當可部署架構堆疊在一起時，每個成員可部署架構會維持其獨立的組態狀態，允許個別部署、更新或取消部署。 此模組化方法可讓成本、合規性、支援及品質保證從包含的可部署架構中衍生出來，而整體解決方案則保持其獨特的版本描述及參考架構。 如需詳細資訊，請前往 堆疊可部署架構的意義？

可消費性

設計可部署的架構時應謹記可使用性，讓使用者易於瞭解及部署。 為了達到此目的，可部署架構應該提供綜合性文件，其中包括下列各項:

必要條件

部署所需的軟體相依關係及基礎架構需求。

詳細輸入變數及輸出值說明

包括目的、資料類型及預設值。

必要的最小許可權

執行可部署架構自動化的必要許可權。

圖表和架構對映

視覺化呈現可部署架構的元件和關係。

簡化的配置

易於部署及管理。

所需資源減少

將可部署架構最佳化，以將硬體和資源需求降至最低，例如降低 CPU 和記憶體需求，使其更經濟且更有效率。

簡化部署

更快速且更容易開始使用。

確保可部署架構易於使用的另一個資料類型是提供多種變異，包括快速入門變異。 應該提供可部署架構的快速入門版本，這在執行時更便宜且更快速。 例如，VPC landing zone 上 Red Hat OpenShift Container Platform 的 QuickStart 變異 可部署架構會在單一區域中建立完全可自訂的 Virtual Private Cloud (VPC) 環境，並在安全 VPC 中提供單一 Red Hat OpenShift 叢集來處理工作負載。 此快速入門變異是針對示範及開發目的而設計，每月執行的成本低於 400 美元。

相反地，Red Hat OpenShift Container Platform on VPC landing zone 可部署架構的標準版本基於 IBM Cloud Framework for Financial Services 參照架構，會在 Virtual Private Cloud (VPC) 網路上建立安全且符合標準的 Red Hat OpenShift Container Platform 工作量叢集，但每月執行成本超過 $4,000 美元。 此外，它還包含進階功能，例如管理 VPC 服務、工作負載 VPC 服務、隔離管理 VPC 和工作負載 VPC，以及進階網路安全架構決策。

程式碼品質

利用鏈結和程式碼格式化。 施行一致的編碼樣式及格式化，讓程式碼易於讀取及維護。 偵測程式碼中的錯誤和警告，以防止部署期間發生問題。 除 Terraform 程式碼外，還可考慮在可部署架構中納入與所有資源相關的任何工具，例如 Bash 腳本、Python 腳本、YAML 和 JSON 檔案，以及 Golang。

範例：

• terraform_fmt，以格式化 Terraform 程式碼。
• go-fmt 以格式化 Go 程式碼。
• black，以格式化 Python 程式碼。
• isort 以排序 Python 匯入項目。
• flake8，以檢查 Python 程式碼是否有錯誤和警告。
• shellcheck，以檢查 Shell Script 是否有錯誤和警告。
• golangci-lint，以檢查 Go 程式碼是否有錯誤及警告。

配置驗證

請使用靜態驗證來檢查可部署架構的語法和配置，以確保它正確且一致。 請驗證可部署架構的配置，以防止在部署期間發生錯誤。 同樣地，請考慮不只是 Terraform 程式碼，並納入與可部署架構中所有資源相關的任何工具，例如 Bash 腳本、Python 腳本、YAML 與 JSON 檔案，以及 Golang。

範例：

• terraform_validate，以驗證 Terraform 配置。
• checkov，以檢查 Terraform 程式碼中是否有安全和相符性問題。
• tflint，以檢查是否有錯誤和警告。
• detect-secrets，以偵測程式碼中的密鑰。
• hadolint，以檢查 Docker 檔案是否有錯誤和警告。
• helmlint，以檢查 Helm 圖表是否有錯誤和警告。

測試

在測試基礎架構程式碼時，沒有單純的單元測試，就像您在應用程式碼中可能想到的那樣。 相反地，測試策略包括將基礎架構部署至實際環境、驗證它是否運作，然後取消部署它。

連續整合

為了確保可部署架構的可靠性、一致性和可維護性，建議採用左移方法，在開發週期早期整合品質檢查和測試。 這種方法有助於及早捕捉錯誤和問題報告，減少下游問題的可能性，並改善整體品質。

在此方法中，建議使用下列品質檢查:

用戶端品質控制

在確定程式碼之前，應該使用用戶端 Git 確定連結鉤 在開發人員機器上執行檢查。 這包括檢查編碼標準、語法錯誤及機密資料。 預先確定 之類的工具可用來自動化此處理程序。

CI 實務

應遵循持續整合 (CI) 的最佳作法。 任何軟體工程產品的一般實務適用於可部署架構開發，包括:

• 使用小型聚焦拉取要求 (PR)，以促進及時檢閱並減少合併衝突。
• 定期將程式碼變更整合至主要分支，以防止長壽命特性分支，並減少合併複雜性。
• 實作自動化測試和程式碼檢閱，以確保程式碼品質和一致性。
• 持續驗證可部署架構的配置和語法，以確保正確性和一致性。

配置項目管線

應該設定 CI 管線以自動化這些實務，確保可部署架構中的每一個程式碼變更都有系統地測試及驗證。 此管線可確保可部署架構正確且一致地運作，且會提早捕捉任何錯誤或問題報告。