翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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 を学ぶのは難しいことではありません。製品プロビジョニングテンプレートと YAML テンプレートを実装し、マニフェストを実装するには、CloudFormation に精通している必要があります。自分のペースで学習できるワークショップなど、開発者がすばやく新しい知識を学べる、優れたワークショップを利用できます。

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

Service Catalog Puppet では、Python Luigi タスクオーケストレーションエンジンを使用してブートストラップとプロビジョニングのワークフローを実装します。これらのワークフローのステップはすべて、Luigi ワークフロータスクとして実装されます。Luigi の概要と他の一般的なワークフローツールとの違いについては、「Data Revenue ブログ」の「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 ワークフローを使用した独自のプロビジョニング処理を行います。

OU またはアカウントを直接指定するのに加え、アカウントのタグ付けのアプローチに基づいて製品ポートフォリオのプロビジョニングターゲットを定義できます。アカウントタグベースのプロビジョニングでは、ポートフォリオ製品は、指定されたマニフェストのプロビジョニングタグセットのすべてのタグを持つすべてのアカウントにプロビジョニングされます。例えば、米国東部リージョンのすべての機関の本番稼働用アカウントにポートフォリオ製品を発行する場合は、タグ type:prod、 partition:us-east、scope:institutional-client を指定します。アカウントと OU 除外を宣言して、指定したタグを持つ OU もしくはアカウント、または OU を指定したターゲットのメンバーアカウントへのプロビジョニングを禁止することもできます。アカウントをタグ付けする方法の詳細については、「Service Catalog ツールのドキュメント」を参照してください。

ハブモード

ハブプロビジョニングモードでは、スポークアカウントのすべての Luigi ワークフローが、指定した中央ハブアカウントで管理されます。ハブアカウントは、スポークアカウントでアクションを実行できる IAM ロールを担いますが、タスクの管理はハブアカウント内で行われます。ハブアカウントは、すべてのスポークアカウントのプロビジョニングタスクが完了するまで (正常に完了するか失敗するかにかかわらず) 同期的に待機します。次に、最終ステータスをレポートします。ハブアカウントモードは最も古く、最も成熟したプロビジョニングモードですが、多くのユーザーがプロビジョニングの同時実行性と速度を向上させるためにスポークプロビジョニングモードに移行しています。

スポークモード

スポークモードでは、Service Catalog ハブアカウントが Luigi ワークフローを開始し、ブートストラップされた指定のスポークアカウントで実行します。スポークのワークフローが完了すると、ハブアカウントに通知されます。スポークアカウントで発生した障害は、ハブアカウントに通知されます。ハブアカウントはスポークアカウントをポーリングして完了したかどうか確認し、ステータスを判断します。

スポークモードではほぼすべてのワークフローが個別のスポークアカウントで実行されるため、AWS のサービス クォータの引き上げが必要になる可能性はほとんどありません。また、スポークモードはハブモードよりもはるかに高い同時実行性を維持しながらも、一元的な管理を維持できます。これにより、プロビジョニングのスピードをハブモードよりも 800% 向上させることができます。スポークモードでは、製品間の DependsOn 関係を通じた製品のチェイニングに対応しています。そのため、依存する製品が確実にプロビジョニングされてから次の製品が実行されます。チェイニングされた製品で構成される製品は、コンポーネントがチェイニングされた製品をプロビジョニングすることもできます。特殊な AWS Lambda 関数呼び出しを使用して、必要なステップを実行することもできます。1 つのスポークの障害は他のスポークから分離されます。

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

非同期モード

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

キャッシュ

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

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

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

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

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

Service Catalog Puppet はまた、静的なユニットテスト機能を提供するアサーションステートメントによってテストを自動化するのにも役立ちます。ポリシーシミュレータを使用して、サービスコントロールポリシー (SCP) と IAM ポリシーをテストできます。これらは実質的にはエンドツーエンドテストですが、システム統合テスト (SIT) 環境でも使用できます。詳細については、「Service Catalog Puppet ドキュメント」の「Using policy simulations」および「Applying service control policies」を参照してください。

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

Service Catalog Puppet は公式にサポートされている AWS のサービスではありませんが、広く採用されています。このツールは過去数年間、大企業によって使用され、数百の OU アカウントに、要求される期間内で製品を正常かつ一元的にプロビジョニングしてきました。耐障害性を実現しながら大規模に製品をプロビジョニングできることが証明されています。Service Catalog Puppet で問題が発生した場合は、GitHub リポジトリに記録して、この AWS ラボの寄稿者に解決してもらうことができます。