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 は、デベロッパーが簡単に学習できます。製品プロビジョニングテンプレートと YAML テンプレートを実装してマニフェストを実装するには、CloudFormation に精通している必要があります。セルフペースのワークショップなど、新しいデベロッパーを高速化するための優れたワークショップがあります。

ワークフローのプロビジョニングのサポート

Service Catalog Puppet は、Python Luigi タスクオーケストレーションエンジンを使用してブートストラップとプロビジョニングのワークフローを実装します。これらのワークフローのすべてのステップは、Luigi ワークフロータスクとして実装されます。Luigi の概要と、他の一般的なワークフローツールとの比較については、「データ収益ブログ」の「Airflow vs Luigi vs Argo vs MLFlow vs KubeFlow」を参照してください。

Luigi を使用すると、Service Catalog Puppet はワークフロータスクに関連付けられたワーカーの数を制御し、ワークフローの他の側面を制御して、スケーリングとパフォーマンスを向上させることができます。Service Catalog Puppet は、製品とステップの依存関係を管理し、製品のプロビジョニングをオーケストレーションするための depends_on メカニズムも提供します。この機能は、きめ細かな製品定義と複雑な依存関係を実装して運用管理するのに役立ちます。

プロビジョニングモード

Service Catalog Puppet は、ハブ、スポーク、非同期の 3 つの実行モードをサポートしています。3 つのモードはすべて、Service Catalog で既に定義されているポートフォリオ内で製品をプロビジョニングします。ターゲットアカウントへの Service Catalog 製品共有に依存し、Service Catalog 管理者と起動ロールを使用して、これらのターゲットでのプロビジョニングを実現します。Service Catalog Puppet は、YAML 設定ファイルで提供されるロール設定に基づいて、同じ組織内でブートストラップステップを実行します。このツールは、単一のハブアカウントから複数の組織へのプロビジョニングもサポートしています。このシナリオでは、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 関数呼び出しを使用して、必要なステップを実行することもできます。1 つのスポークの障害は、他のスポークから分離されます。

スポークモードは、最大 7 つのリージョンに 980 を超えるアカウントを持つ企業で使用されます。これらの企業は、通常、インフラストラクチャ内のすべてのリージョンとアカウントに 1 時間以内に製品をプロビジョニングできます。

注記

これらの結果は、ネットワークインフラストラクチャ、ワークロード、 AWS 組織のハブアンドスポークアカウントのクォータなどの要因によって異なる場合があります。また、プロビジョニングされる製品リソース、固有の作成時間、他のリソースへの依存関係にも依存します。

Aysnc モード

非同期モードでは、スポークアカウントでプロビジョニングワークフローが開始されますが、スポークから完了応答を待機したり受信したりすることはありません。

キャッシュ

Service Catalog Puppet がワークフローの速度を最適化するために使用するもう 1 つのメカニズムは、ワークフローのステップを表す一般的なタスクをキャッシュすることです。キャッシュされたタスクが完了すると、出力が Amazon Simple Storage Service (Amazon S3) に書き込まれます。次回同じパラメータで同じセッションでタスクが呼び出されると、Service Catalog Puppet はタスクを再実行する代わりにキャッシュされた値を使用します。詳細については、Service Catalog Puppet ドキュメントの「キャッシュ」を参照してください。

DevSecOps ライフサイクルのサポート

Service Catalog Puppet には、DevSecOps パイプラインの管理のサポートが含まれています。Service Catalog Tools アクション (Service Catalog Puppet の概要を参照) を使用して、テストを自動化し、推奨される Canary アカウントを含む AWS ライフサイクルアカウント全体で製品をプロモーションできます。詳細については、Service Catalog Puppet ドキュメントの「環境の管理」を参照してください。

Service Catalog Puppet では、製品変更に関連する問題が本番環境で広く使用する前に確実に検出されるようにするために、初期デプロイに少なくとも 1 つの Canary アカウントが必要です。新しいリリースをテストして信頼を得ると、Canary 以外の本番稼働用アカウントに昇格できます。問題を特定した場合は、リリースをロールバックして、問題が解決したときに再導入できます。このアプローチを使用すると、問題のある Canary バージョンを本番稼働用アカウントにリリースすると、本番稼働用の問題が発生する可能性があります。代替方法として、変更を本番環境にリリースする前に、製品変更ごとに完全な回帰テストを実行できます。これにより、CI/CD プロセスで追加のオーバーヘッドが発生しますが、本番の問題を回避するのに役立ちます。開発チームに最適な機能リリースシナリオとアプローチを決定するのは、DevSecOps 管理者の責任です。

Service Catalog Puppet を使用すると、複数のチームが Service Catalog 製品ソリューションのプロビジョニングを同時に開発およびテストできます。ベストプラクティスとして、複数の開発者が同時に製品を変更しないでください。代わりに、製品をよりきめ細かなコンポーネントに分割して、個別の同時変更を行うことができます。

Service Catalog Puppet は、静的およびユニットテスト機能を提供するアサーションステートメントによるテストの自動化にも役立ちます。Policy Simulator を使用して、サービスコントロールポリシー (SCPs) と IAM ポリシーをテストできます。これらは技術的にはend-to-endのテストですが、システム統合テスト (SIT) 環境で使用できます。詳細については、Service Catalog Puppet ドキュメントの「ポリシーシミュレーションの使用」および「サービスコントロールポリシーの適用」を参照してください。

成熟度、完全性、サポート

Service Catalog Puppet は公式にはサポートされていませんが AWS のサービス、広く採用されています。このツールは、過去数年間にわたって大規模な組織によって使用され、希望するプロビジョニング期間内に数百の OU アカウントに製品を正常に一元的にプロビジョニングするために使用されます。大規模な耐障害性製品のプロビジョニングを提供することが証明されています。Service Catalog Puppet で問題が発生したユーザーは、GitHub リポジトリに記録して、この AWS Labs ソリューションの寄稿者による解決に役立てることができます。