翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
CodeCommit 内のモノリポジトリの変更を自動的に検出し、さまざまな CodePipeline パイプラインを開始する
Helton ribeiro、Petrus Batalha、Ricardo Morais (Amazon Web Services)
概要
注意: AWS Cloud9 は新規顧客には利用できなくなりました。の既存のお客様は、通常どおりサービスを AWS Cloud9 引き続き使用できます。詳細はこちら
このパターンは、 でモノレポベースのアプリケーションのソースコードの変更を自動的に検出し AWS CodeCommit 、マイクロサービスごとに継続的インテグレーションと継続的デリバリー (CI/CD) オートメーション AWS CodePipeline を実行するパイプラインを で開始するのに役立ちます。このアプローチは、モノレポベースのアプリケーション内の各マイクロサービスに専用の CI/CD パイプラインを持たせることができることを意味します。これにより、可視性が向上し、コードの共有が容易になり、コラボレーション、標準化、発見が容易になります。
このパターンで説明されているソリューションは、モノレポ内のマイクロサービス間での依存関係分析を実行しません。ソースコードの変更のみを検出し、一致する CI/CD パイプラインを開始します。
このパターンでは、 を統合開発環境 (IDE) AWS Cloud9 として使用し AWS Cloud Development Kit (AWS CDK) 、 MonoRepoStackと の 2 つの CloudFormation スタックを使用してインフラストラクチャを定義しますPipelinesStack。MonoRepoStack スタックは、 にモノレポ AWS CodeCommit を作成し、CI/CD パイプラインを開始する AWS Lambda 関数を作成します。PipelinesStack スタックはパイプラインインフラストラクチャを定義します。
重要
このパターンのワークフローは概念実証 (PoC) です。テスト環境でのみ使用することをお勧めします。このパターンのアプローチを本番環境で使用する場合は、 AWS Identity and Access Management (IAM) ドキュメントの「IAM のセキュリティのベストプラクティス」を参照して、IAM ロールと に必要な変更を加えます AWS のサービス。
前提条件と制限事項
前提条件
アクティブな AWS アカウント。
AWS Command Line Interface (AWS CLI)、インストールおよび設定済み。詳細については、 AWS CLI ドキュメントAWS CLIの「 のインストール、更新、アンインストール」を参照してください。
ローカルマシンにインストール済みの Python 3 と
pip。詳細については、Python のドキュメントを参照してください。 AWS CDKがインストールされ設定済みであること。詳細については、 AWS CDK ドキュメントの「Getting started with the AWS CDK」を参照してください。
IDE AWS Cloud9 がインストールされ、設定されています。詳細については、 AWS Cloud9 ドキュメントの「セットアップ AWS Cloud9」を参照してください。
GitHub の AWS CodeCommit monorepo multi-pipeline triggers
リポジトリが、ローカルマシンでクローン済み。 CodePipeline でビルドしてデプロイするアプリケーションコードを含む既存のディレクトリ。
AWS クラウドでの DevOps のベストプラクティスに関する知識と経験。DevOps の知識を高めるには、 パターンを使用します。DevOps プラクティスと 規範ガイダンスウェブサイトを使用して、マイクロサービスと疎結合アーキテクチャを構築 AWS Cloud9します。 AWS
アーキテクチャ
次の図は、 を使用して、 MonoRepoStackと の 2 つの AWS CloudFormation スタックを持つインフラストラクチャ AWS CDK を定義する方法を示していますPipelinesStack。

この図表は、次のワークフローを示しています:
ブートストラッププロセスでは、 AWS CDK を使用して AWS CloudFormation スタック
MonoRepoStackと を作成しますPipelinesStack。MonoRepoStackスタックは、アプリケーション用の CodeCommit リポジトリと、各コミットの後に開始されるmonorepo-event-handlerLambda 関数を作成します。PipelinesStackスタックは、Lambda 関数によって開始されるパイプラインを CodePipeline に作成します。各マイクロサービスにはインフラストラクチャパイプラインが定義されている必要があります。microservice-nのパイプラインは Lambda 関数によって開始され、CodeCommit のソースコードに基づいて分離された CI/CD ステージを開始します。microservice-1のパイプラインは Lambda 関数によって開始され、CodeCommit のソースコードに基づいて分離された CI/CD ステージを開始します。
次の図は、 アカウントPipelinesStackでの AWS CloudFormation スタックMonoRepoStackと のデプロイを示しています。

ユーザーがアプリケーションのマイクロサービスの 1 つでコードを変更します。
ユーザーは、ローカルリポジトリから CodeCommit リポジトリに変更をプッシュします。
プッシュアクティビティは、CodeCommit リポジトリへのすべてのプッシュを受け取る Lambda 関数を開始します。
Lambda 関数は、 AWS Systems Managerの機能として Parameter Store のパラメータを読み取り、最新のコミット ID を取得します。パラメータには
/MonoRepoTrigger/{repository}/{branch_name}/LastCommit命名形式があります。パラメータが見つからない場合、Lambda 関数は CodeCommit リポジトリから最後のコミット ID を読み取り、戻り値をパラメータストアに保存します。コミット ID と変更されたファイルを特定すると、Lambda 関数は各マイクロサービスディレクトリのパイプラインを識別し、必要な CodePipeline パイプラインを開始します。
ツール
AWS Cloud Development Kit (AWS CDK) は、コードでクラウドインフラストラクチャを定義し、それをプロビジョニングするためのソフトウェア開発フレームワークです CloudFormation。
Python
は、すばやく作業し、システムをより効果的に統合できるプログラミング言語です。
コード
このパターンのソースコードとテンプレートは、GitHub の AWS CodeCommit monorepo multi-pipeline triggers
ベストプラクティス
このサンプルアーキテクチャには、デプロイされたインフラストラクチャのモニタリングソリューションは含まれていません。このソリューションを本番環境にデプロイしたい場合は、モニタリングを有効にすることをお勧めします。詳細については、 AWS Serverless Application Model (AWS SAM) ドキュメントのCloudWatch Application Insights を使用してサーバーレスアプリケーションをモニタリングする」を参照してください。
このパターンで提供されるサンプルコードを編集するときは、 AWS CDK ドキュメントのクラウドインフラストラクチャを開発およびデプロイするためのベストプラクティスに従ってください。
マイクロサービスパイプラインを定義するときは、 AWS CodePipeline ドキュメントのセキュリティのベストプラクティスを確認してください。
cdk-nag
ユーティリティを使用して AWS CDK 、コードのベストプラクティスを確認することもできます。このツールは、パックごとにグループ化された一連のルールを使用してコードを評価します。使用可能なパックは次のとおりです。
エピック
| タスク | 説明 | 必要なスキル |
|---|---|---|
仮想 Python 環境を作成します。 | AWS Cloud9 IDE で、仮想 Python 環境を作成し、次のコマンドを実行して必要な依存関係をインストールします。
| 開発者 |
の AWS アカウント と AWS リージョン をブートストラップします AWS CDK。 | 次のコマンドを実行して、必要な AWS アカウント とリージョンをブートストラップします。
| 開発者 |
| タスク | 説明 | 必要なスキル |
|---|---|---|
サンプルコードをアプリケーションディレクトリに追加します。 | サンプルアプリケーションコードを含むディレクトリを、複製された GitHub AWS CodeCommit monorepo multi-pipeline triggers | 開発者 |
| アプリケーションのコードのディレクトリ名とパイプラインの名前を、複製されたリポジトリ内の | 開発者 |
パイプラインを作成します。 | リポジトリの ファイルの 1 つをコピーして、アプリケーションの要件に応じて変更を加えることができます。 | 開発者 |
|
例えば、次のコードは、
| 開発者 |
| タスク | 説明 | 必要なスキル |
|---|---|---|
AWS CloudFormation スタックをデプロイします。 |
リポジトリの名前は、 注記
| 開発者 |
CodeCommit リポジトリを検証します。 |
重要 CloudFormation スタックはモノレポが保存されている CodeCommit リポジトリを作成するため、変更のプッシュを開始した場合は | 開発者 |
CloudFormation スタックの結果を検証します。 | 次のコマンドを実行して、 CloudFormation
| 開発者 |
| タスク | 説明 | 必要なスキル |
|---|---|---|
CloudFormation スタックをデプロイします。 | AWS CloudFormation
注記
以下の出力例は、実装の最後に
| 開発者 |
AWS CloudFormation スタックの結果を検証します。 | 次のコマンドを実行して、 AWS CloudFormation
| 開発者 |
| タスク | 説明 | 必要なスキル |
|---|---|---|
AWS CloudFormation スタックを削除します。 |
| 開発者 |
パイプラインの S3 バケットを削除します。 |
| 開発者 |
トラブルシューティング
| 問題 | ソリューション |
|---|---|
AWS CDK 問題が発生しました。 | AWS CDK ドキュメントの「一般的なAWS CDK 問題のトラブルシューティング」を参照してください。 |
マイクロサービスコードをプッシュしましたが、マイクロサービスパイプラインは実行されませんでした。 | セットアップの検証 ブランチ設定を確認します。
設定ファイルを検証します。
コンソールでのトラブルシューティング AWS CodePipeline は以下をチェックします。
AWS Lambda トラブルシューティング:
|
すべてのマイクロサービスを再デプロイする必要があります。 | すべてのマイクロサービスの再デプロイを強制するためには、2 つのアプローチがあります。要件に合ったオプションを選択してください。 アプローチ 1: Parameter Store でパラメータを削除する このメソッドでは、デプロイに使用された最後のコミット ID を追跡する Systems Manager Parameter Store 内の特定のパラメータを削除します。このパラメータを削除すると、システムは新しい状態として認識するため、次のトリガーですべてのマイクロサービスを強制的に再デプロイします。 手順:
メリット:
デメリット:
アプローチ 2: 各モノレポサブフォルダにコミットをプッシュする この方法では、マイナーな変更を行い、モノレポ内の各マイクロサービスサブフォルダにプッシュし、個々のパイプラインを開始します。 手順:
メリット:
デメリット:
|
関連リソース
CDK Pipelines を使用した継続的な統合と配信 (CI/CD) (AWS CDK ドキュメント)
aws-cdk/pipelines モジュール (AWS CDK API リファレンス)