本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
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 文件
中樞模式
在中樞佈建模式中,發言帳戶的所有 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 儲存庫