Amazon Web Services ブログ

サードパーティソース管理の可視性向上のためのAWS CodePipelineのカスタムソースアクションの使用

以前の「GitとAWS CodePipelineの統合」の記事では、Amazon API GatewayAWS LambdaAmazon S3を使用して、サードパーティのGitリポジトリとAWS CodePipelineを統合する方法の1つを示しました。 このアプローチでは、GitリポジトリをCodePipelineと迅速に統合できますが、多くの利用者がCI/CDパイプラインで使用するソースのメタデータをCodePipelineに提供することはできません。

この記事では、ソースリポジトリから、より多くのメタデータをCodePipelineに提供するための異なる戦略を提供する、CodePipelineカスタムソースアクションについて説明します。最も一般的なソース メタデータは、コミット識別子とコミットメッセージです。Commit識別子は、ソフトウェアライフサイクル全体の変更を追跡するために頻繁に使用されますが、コミットメッセージは人間が判読可能で簡潔な記述を提供します。カスタムソースアクションを使用すると、CodePipelineがCodeCommitやGitHubと統合するのと同じ方法で、任意のソースリポジトリと統合することができ、コミット識別子とコミットメッセージにアクセスできます。

この記事では、API GatewayとLambdaをセットアップしてパイプラインをトリガし、パイプラインをカスタムソースアクションで構成し、カスタムソースアクションからジョブを処理するワーカーを構築します。このアーキテクチャを使用すると、VPCでホストされているか、またはオンプレミスに構築されておりVPCからアクセス可能なソースプロバイダにアクセスできます。

アーキテクチャ オーバービュー


Webhookは、イベントに応答して発生するユーザー定義のHTTPコールバックです。我々のケースでは、Webhooksは新しいリビジョンであるソースリポジトリの変更に応じて発生します。Webhooksは、ソースリポジトリとCodePipelineなどの継続的なインテグレーションツールを統合するための標準的なメカニズムになっています。

ここでは、webhookはAPI GatewayとAWS Lambdaから呼び出されます。LambdaファンクションはStartPipelineExecution APIを呼び出し、CodePipelineの実行をトリガーします。その実行は、ジョブを発行するカスタムソースアクションから開始されます。そのジョブはワーカーによって呼び出され、最新のソースリビジョンを取得し、メタデータを抽出し、パイプラインの残りの部分が利用するための新しいCodePipelineアーティファクトをパブリッシュします。

この例では、Gitリポジトリ(この場合は、GitHub Enterprise)をターゲットにしています。Gitリポジトリのコンテンツを取得する方法は複数ありますが、ここではSSHで認証された単純なgit pullを行います。この例では、VPCからGitリポジトリにアクセスできると仮定しています。もしそうでない場合は、VpcConigをGitPullS3 Lambdaファンクションから削除し、インターネットリソースにアクセスできるようにします。

 

必要なAWSリソースのビルド

 

構築を簡単にするために、この統合を構築するために必要なAWSインフラストラクチャと設定を含むAWS CloudFormationテンプレートを提供します。これには、API Gateway、Lambdaファンクション、およびシンプルなパイプラインが含まれています。AWS CloudFormationスタックのセットアップウィザードを起動するには、任意のリージョンのリンクを選択します。次のAWSのリージョンは、この統合に必要なすべてのサービスをサポートしています。

北バージニア
オレゴン
アイルランド

AWSサービスの一覧とAWSサービスが利用できるリージョンについては、「AWSのリージョンとエンドポイント」を参照してください。

スタックセットアップウィザードは、複数のパラメータの入力を求めるプロンプトを表示します。 これらの値の多くは、GitHub Enterpriseサービスから取得する必要があります。

OutputBucketName: CodePipelineアーティファクトのためのバケット名。

BranchName: パイプラインで使用するブランチ。

GitUrl: クローンするGitリポジトリのHTTPSのURL。ソースリポジトリがインターネットに公開されていない場合は、ソースリポジトリのプライベートIPアドレスを使用していることを確認してください。

ApiSecret: GitHub EnterpriseとGitLabで使用するためのWebhookシークレット。

SourceActionVersion: 使用するカスタムソースアクションのバージョン。 カスタムアクションのバージョンは削除できないため、単一のアカウントでスタックを再作成するたびにこのバージョンをインクリメントする必要があります。

GitPullLambdaVPC: Lambdaファンクションが存在するVPC。このVPCは、対象のソースリポジトリとCodePipelineにアクセスするためのパブリックインターネットの両方にアクセスできる必要があります。

GitPullLambdaSubnet: Lambdaファンクションが存在するサブネット。このサブネットは、ソースリポジトリにアクセスできる必要があり、インターネットへのNATアクセスを持つプライベート(つまり、インターネットゲートウェイを持たない)である必要があります。

これらのパラメータの値を入力したら、ウィザードの手順を完了してスタック作成を開始できます。入力する値が変更された場合は、CloudFormationのスタックアップデートスタックの機能を使用してパラメータを変更できます。スタックの作成が完了したら、WebhookEndpointとPublicSSHKeyを書き留めます。次の手順でこれらの値が必要となります。

 

ソースリポジトリの設定

 

  1. GitHub Enterpriseにサインインし、ソースリポジトリに移動します。
  2. [Settings]タブを選択し、Webhooksを選択します。
  3. [Add Webhook]を選択します。
  4. Payload URLに、WebhookEndpointの値を入力します。Secretには、あなたのWebhookシークレットを入力してください。
  5. [Add Webhook]を選択します。
  6. User settingsに行き、SSHおよびGPG Keysを選択して下さい。AWS CloudFormationのPublicSSHKeyの値で新しいSSHキーを追加します。

コミットのテストとリソースのクリーンアップ

 

webhookをセットアップしたら、新しいコミットをPushします。数分で、正しいリビジョンIDとコミットメッセージを含むパイプラインの新規の実行が表示されます。

このソリューションで使用されているリソースをクリーンアップするには、AWS CloudFormationスタックを削除します。

 

結論

 

このブログ記事が、CI/CDパイプラインにソース管理メタデータを注入するために役に立つと幸いです。いつものように、Blogのコメントにあなたの考えや示唆を添えてください。

 

日本語訳はSA福井が担当しました。原文はこちらです。
https://aws.amazon.com/blogs/devops/using-custom-source-actions-in-aws-codepipeline-for-increased-visibility-for-third-party-source-control/