本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
Service Catalog Puppet
Service Catalog Puppet 是使用 AWS Boto3 API 在 Python 中實作。此工具提供數種強大的功能來設定和佈建 Service Catalog 產品。開發人員可以使用做為資訊清單的 YAML 範本來設定 Service Catalog 產品和產品組合佈建資訊。Service Catalog Puppet 佈建工作流程支援比 Service Catalog 需要更複雜部署程序的產品。它們也支援效能最佳化，以在積極的時段內大規模佈建產品。
Service Catalog Puppet 會存取 Service Catalog CloudFormation 範本，以在部署時佈建產品。它會直接呼叫 CloudFormation 來部署產品的佈建範本堆疊，並略過 Service Catalog 自己的堆疊集佈建程序所施加的限制。如果佈建範本使用巨集來包含其他 CloudFormation 指令碼或使用巢狀 CloudFormation 指令碼，您必須在佈建工作流程的引導部分中提供目標帳戶中這些指令碼的存取權。
如需詳細資訊：
-
請參閱 Service Catalog Puppet 文件
和 GitHub 儲存庫 。 -
如果您想要使用 Service Catalog Puppet SDK 以程式設計方式與工具互動，以啟動產品和產品組合佈建，請參閱 SDK 文件
。 -
GitOps
是管理 Service Catalog Puppet 環境的預設機制。
Service Catalog Puppet 相當容易讓開發人員學習。它需要熟悉 CloudFormation，才能實作產品佈建範本和 YAML 範本，才能實作資訊清單。有很好的研討會可以讓新開發人員加快速度，例如自行安排進度的研討會
支援佈建工作流程
Service Catalog Puppet 使用 Python Luigi 任務協同運作引擎來實作引導和佈建工作流程。這些工作流程中的所有步驟都會實作為 Luigi 工作流程任務。如需 Luigi 的概觀及其與其他熱門工作流程工具的比較，請參閱 Data Revenue 部落格中的 Airflow 相對於 Luigi 相對於 Argo 相對於 MLFlow 相對於 KubeFlow
Luigi 允許 Service Catalog Puppet 控制與工作流程任務相關聯的工作者數量，以及控制工作流程的其他層面，以獲得更佳的擴展和效能。Service Catalog Puppet 也提供 depends_on 機制
佈建模式
Service Catalog Puppet 支援三種執行模式：中樞、輻條和非同步
在所有佈建模式中，Service Catalog Puppet 會直接實作產品佈建，而無需呼叫 Service Catalog 的佈建程序。您可以設定佈建資訊清單，以在現有的 Service Catalog 堆疊集限制條件中使用角色和目標帳戶規格。Service Catalog Puppet 會使用此資訊，透過 Luigi 工作流程進行自己的佈建。
除了直接指定 OUs 或帳戶之外，您還可以根據帳戶標記方法定義產品組合佈建的目標。在以帳戶標籤為基礎的佈建中，產品組合產品會佈建到具有指定資訊清單佈建標籤集中所有標籤的所有帳戶。例如，如果您想要將產品組合產品發行到美國東部區域的所有機構生產帳戶，您可以指定標籤 type:prod、 partition:us-east和 scope:institutional-client。您也可以宣告帳戶和 OU 排除，以禁止佈建到具有您指定標籤OUs 或帳戶，或佈建到屬於 OU 指定目標成員的帳戶。如需帳戶標記的詳細資訊，請參閱 Service Catalog Tools 文件
Hub 模式
在中樞佈建模式中，發言帳戶的所有 Luigi 工作流程都會從指定的中樞帳戶管理。中樞帳戶會擔任 IAM 角色，允許它在發言帳戶中執行動作，但任務的管理是從中樞帳戶內部進行。中樞帳戶會同步等待，直到所有發言帳戶佈建任務成功完成或失敗為止。然後報告最終狀態。中樞帳戶模式是最舊且最成熟的佈建模式。不過，許多使用者已移至輻條佈建模式，以實現更大的佈建並行和速度。
呼叫模式
在輻條模式中，Service Catalog 中樞帳戶會啟動 Luigi 工作流程，以在指定的引導式輻條帳戶中執行。語音工作流程完成時，會通知中樞帳戶。發言帳戶中的故障會上升到中樞帳戶。中樞帳戶會輪詢輪輻帳戶，以查看是否已完成並判斷狀態。
輪換模式最不可能要求增加配額 AWS 服務 ，因為幾乎所有項目都在單獨的輪換帳戶中執行。呼叫模式也提供遠高於中樞模式的並行，同時保留中央控制。相較於中樞模式，它可以提高 800% 的佈建速度。呼叫模式支援透過產品DependsOn之間的關係進行產品鏈結，這可確保已佈建相依的產品。包含鏈結產品的產品也可以佈建元件鏈結產品。您也可以使用特殊化 AWS Lambda 函數呼叫來執行必要的步驟。一個輻條中的故障與其他輻條隔離。
在最多 7 個區域中擁有超過 980 個帳戶的企業會使用 呼叫模式。這些企業通常可以在一小時內將產品佈建至其基礎設施中的所有區域和帳戶。
注意
這些結果可能會因聯網基礎設施、工作負載和 AWS 組織中樞和發言帳戶的配額等因素而有所不同。它們也取決於佈建的產品資源、其固有建立時間，以及其對其他資源的相依性。
Aysnc 模式
非同步模式會在語音帳戶中啟動佈建工作流程，但不會等待或接收來自語音的完成回應。
快取
Service Catalog Puppet 用來最佳化工作流程速度的另一個機制是快取代表工作流程中步驟的常見任務。當快取任務完成時，它會將其輸出寫入 Amazon Simple Storage Service (Amazon S3)。下次在具有相同參數的相同工作階段中調用任務時，Service Catalog Puppet 會使用快取的值，而不是重新執行任務。如需詳細資訊，請參閱 Service Catalog Puppet 文件中的快取
DevSecOps 生命週期支援
Service Catalog Puppet 包含管理 DevSecOps 管道的支援。您可以使用 Service Catalog Tools 動作 （如 Service Catalog Puppet 概觀
為了確保在廣泛生產使用之前偵測到與產品變更相關的任何問題，Service Catalog Puppet 至少需要一個 Canary 帳戶才能進行初始部署。測試並取得新版本的可信度後，您可以將其提升為非 Canary 生產帳戶。如果您發現任何問題，您可以轉返發行版本，並在問題解決時重新導入。當您使用此方法時，如果您發行對生產帳戶有問題的 Canary 版本，則可能會發生生產問題。或者，您可以在發佈變更至生產環境之前，針對每個產品變更執行完整迴歸測試。這會在 CI/CD 程序中帶來額外的額外負荷，但有助於避免生產問題。DevSecOps 管理員有責任為其開發團隊判斷最佳的功能發行案例和方法。
Service Catalog Puppet 允許多個團隊同時開發和測試 Service Catalog 產品解決方案的佈建。根據最佳實務，多個開發人員不應同時變更產品。反之，您可以將產品分解為更精細的元件，以進行個別的同時修改。
Service Catalog Puppet 也透過提供靜態和單元測試功能的聲明陳述式來協助自動化測試。您可以使用政策模擬器來測試服務控制政策 (SCPs) 和 IAM 政策。這些技術上是end-to-end測試，但可用於系統整合測試 (SIT) 環境。如需詳細資訊，請參閱 Service Catalog Puppet 文件中的使用政策模擬
成熟度、完整性和支援
雖然 Service Catalog Puppet 並未正式支援 AWS 服務，但已廣泛採用。過去幾年，大型組織已使用此工具，在所需的佈建時段內成功且集中地將產品佈建至數百個 OU 帳戶。它已證實可大規模提供容錯產品佈建。遇到 Service Catalog Puppet 問題的使用者可以將他們記錄在 GitHub 儲存庫
