インテグレータとサードパーティーのアクションタイプがどのように機能するか概念サポートされている統合モデル Lambda 統合モデルジョブワーカー統合モデル

統合モデルのリファレンス

パイプラインのリリースプロセスに、既存の顧客ツールを構築するのに役立つサードパーティーサービスのための事前構築済みの統合がいくつかあります。パートナー、またはサードパーティーサービスプロバイダーは、統合モデルを使用して、で使用するアクションタイプを実装します CodePipeline。

このリファレンスは、でサポートされている統合モデルで管理されるアクションタイプを計画または操作する場合に使用します CodePipeline。

サードパーティーのアクションタイプをとのパートナー統合として認証するには CodePipeline、 AWS パートナーネットワーク () を参照してくださいAPN。この情報は、AWS CLI リファレンスを補足するものです。

インテグレータとサードパーティーのアクションタイプがどのように機能するか

カスタマーパイプラインにサードパーティーのアクションタイプを追加して、顧客リソースのタスクを完了できます。インテグレーターはジョブリクエストを管理し、でアクションを実行します CodePipeline。次の図表は、顧客がパイプラインで使用するために作成されたサードパーティーのアクションタイプを示しています。顧客がアクションを設定すると、アクションが実行され、インテグレータのアクションエンジンによって処理されるジョブリクエストが作成されます。

インテグレータのアクションエンジンによるサードパーティーのアクションタイプとアーティファクトの処理方法を示す画像

図表に示す内容は以下のステップです。

アクション定義が登録され、で利用可能になります CodePipeline。サードパーティーのアクションは、サードパーティープロバイダのカスタマーに対して実行できます。
プロバイダーのお客様は、でアクションを選択して設定します CodePipeline。
アクションが実行され、ジョブはでキューに入れられます CodePipeline。ジョブの準備がで完了すると CodePipeline、ジョブリクエストが送信されます。
インテグレーター (サードパーティーポーリングのジョブワーカーAPIsまたは Lambda 関数) は、ジョブリクエストを受け取り、確認を返し、アクションのアーティファクトを処理します。
インテグレータは、ジョブ結果と継続トークンを含む成功/失敗出力を返します (ジョブワーカーは成功/失敗を使用するAPIsか、Lambda 関数は成功/失敗出力を送信します）。

アクションタイプのリクエスト、表示、および更新に使用できる手順については、アクションタイプの使用を参照してください。

概念

このセクションでは、サードパーティーのアクションタイプについて以下の用語を使用します。

アクションタイプ

同じ継続的デリバリーのワークロードを実行するパイプラインで再利用できる反復可能なプロセス。アクションタイプは、Owner、Category、Provider、および Version 。例:



            {

                "Category": "Deploy",
                "Owner": "AWS",
                "Provider": "CodeDeploy",
                "Version": "1"
            },

同じタイプのアクションはすべて、同じ実装を共有します。

アクション

アクションタイプの単一のインスタンス。パイプラインのステージ内で発生する個別のプロセスの1つです。これには、通常、このアクションが実行されるパイプラインに固有のユーザー値が含まれます。

アクションの定義

アクションおよび入出力アーティファクトの構成に必要なプロパティを定義するアクションタイプのスキーマ。

アクションの実行

顧客のパイプラインでのアクションが成功したかどうかを判断するために実行されたジョブの集まり。

アクション実行エンジン

アクションタイプで使用される統合タイプを定義するアクション実行設定のプロパティ。有効な値は、JobWorker および Lambda です。

Integration

アクションタイプを実装するためにインテグレータによって実行されるソフトウェアについて説明します。 CodePipeline は、サポートされている 2 つのアクションエンジン JobWorkerおよびに対応する 2 つの統合タイプをサポートしますLambda。

インテグレータ

アクションタイプの実装を所有している人。

ジョブ

パイプラインと顧客コンテキストを使用して統合を実行するための作業です。アクションの実行は、1 つ以上のジョブで構成されます。

ジョブワーカー

顧客入力を処理してジョブを実行するサービス。

サポートされている統合モデル

CodePipeline には 2 つの統合モデルがあります。

Lambda 統合モデル: この統合モデルは、でアクションタイプを操作するための推奨方法です CodePipeline。Lambda 統合モデルは、アクションの実行時に Lambda 関数を使用してジョブリクエストを処理します。
ジョブワーカー統合モデル: ジョブワーカー統合モデルは、サードパーティー統合で以前に使用されたモデルです。ジョブワーカー統合モデルでは、に連絡するように設定されたジョブワーカーを使用して、 CodePipeline APIsアクションの実行時にジョブリクエストを処理します。

比較のために、次の表に 2 つのモデルの特徴を示します。

	Lambda 統合モデル	ジョブワーカー統合モデル
説明	インテグレータは、統合を Lambda 関数として書き込みます。Lambda 関数は、アクションに使用できるジョブがある CodePipeline たびにによって呼び出されます。Lambda 関数は、使用可能なジョブをポーリングするのではなく、次のジョブリクエストが受信されるまで待機します。	インテグレータは、インテグレーションをジョブワーカーとして書き込み、顧客のパイプラインで利用可能なジョブを常にポーリングします。次に、ジョブワーカーはジョブを実行し、 CodePipeline を使用してジョブ結果をに送信します CodePipeline APIs。
インフラストラクチャ	AWS Lambda	Amazon EC2インスタンスなどのインテグレータのインフラストラクチャにジョブワーカーコードをデプロイします。
開発作業	統合にはビジネスロジックのみが含まれます。	統合は、ビジネスロジックを含めるだけでなく、と CodePipeline APIsやり取りする必要があります。
Opsの努力	インフラストラクチャは AWS リソースにすぎないため、運用の労力が少なくなります。	ジョブワーカーはスタンドアロンのハードウェアを必要とするため、オペレーションの労力が高くなります。
最大ジョブのランタイム	統合を 15 分以上アクティブに実行する必要がある場合は、このモデルを使用できません。このアクションは、プロセスを開始する (顧客のコードアーティファクトの構築を開始するなど)、終了時に結果を返す必要があるインテグレータを対象としています。インテグレータがビルドの終了を待ち続けることはお勧めしません。代わりに、継続を返します。 CodePipeline は、インテグレータのコードから継続を受信した場合、さらに 30 秒で新しいジョブを作成し、ジョブが終了するまでジョブをチェックします。	このモデルを使用すると、非常に長時間実行されるジョブ (時間/日) を維持できます。

Lambda 統合モデル

サポートされる Lambda 統合モデルには、Lambda 関数の作成と、サードパーティーアクションタイプの出力の定義が含まれます。

からの入力を処理するように Lambda 関数を更新する CodePipeline

新しい Lambda 関数の作成アクションタイプのパイプラインで利用可能なジョブがあるときに実行される Lambda 関数にビジネスロジックを追加できます。たとえば、顧客とパイプラインのコンテキストを考えると、顧客のためのサービスでビルドを開始したい場合があります。

次のパラメータを使用して、からの入力を処理するように Lambda 関数を更新します CodePipeline。

形式:

jobId:
- システムによって生成されたジョブの固有の ID 。
- 型: 文字列
- パターン:[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}
accountId:
- ジョブの実行時に使用する顧客の AWS アカウントの ID。
- 型: 文字列
- Pattern: [0-9]\{12\}
data:
- 統合がジョブの完了に使用するジョブに関するその他の情報。
- 次のいずれかのマップが含まれます。
  - actionConfiguration:
    
    アクションの設定データ。アクション設定フィールドは、顧客が値を入力するためのキー値のペアのマッピングです。キーは、アクションを設定するときに、アクションタイプ定義ファイル内のキーパラメータによって決定されます。この例では、Username そして Password フィールドに情報を指定するアクションのユーザーよって値が決定される。
    
    タイプ : 文字列から文字列へのマッピング、オプションで提供
    
    例:
    
    "configuration": { "Username": "MyUser", "Password": "MyPassword" },
  - encryptionKey:
    
    キーなど、アーティファクトストア内のデータの暗号化に使用される AWS KMS キーに関する情報を表します。
    
    内容 : データ型タイプ encryptionKey 、オプションで提供
  - inputArtifacts:
    
    作業対象のアーティファクト (テスト、構築アーティファクトなど) に関する情報のリスト。
    
    目次 : データ型のリスト Artifact、オプションで提供
  - outputArtifacts:
    
    アクションの出力に関する情報のリスト。
    
    目次:データ型のリスト Artifact、オプションで提供
  - actionCredentials:
    
    AWS セッション認証情報オブジェクトを表します。これらの認証情報は、 AWS STSによって発行される一時的な認証情報です。これらは、パイプラインのアーティファクトをに保存するために使用される S3 バケット内の入出力アーティファクトにアクセスするために使用できます CodePipeline。
    
    これらの認証情報には、アクションタイプ定義ファイル内の指定されたポリシーステートメントテンプレートと同じ権限もあります。
    
    内容 : データ型タイプ AWSSessionCredentials 、オプションで提供
  - actionExecutionId:
    
    アクションの実行の外部 ID。
    
    型: 文字列
  - continuationToken:
    
    ジョブを非同期的に続行するためにジョブに必要な、デプロイメント ID などのシステム生成トークン。
    
    タイプ : 文字列、オプションで提供

データ型:

encryptionKey:
- id:
  - キーを識別する際に使用された ID。 AWS KMS キーには、キー ID、キー ARN、またはエイリアスを使用できますARN。
  - 型: 文字列
- type:
  - キーなどの暗号化 AWS KMS キーのタイプ。
  - 型: 文字列
  - 有効な値: KMS
Artifact:
- name:
  - アーティファクトの名前。
  - タイプ : 文字列、オプションで提供
- revision:
  - アーティファクトのリビジョン ID 。オブジェクトのタイプに応じて、コミット ID (GitHub) またはリビジョン ID (Amazon S3) を指定できます。
  - タイプ : 文字列、オプションで提供
- location:
  - アーティファクトの位置。
  - 内容 : データ型タイプ ArtifactLocation 、オプションで提供
ArtifactLocation:
- type:
  - ロケーション内のアーティファクトのタイプ。
  - タイプ : 文字列、オプションで提供
  - 有効な値: S3
- s3Location:
  - リビジョンを含む S3 バケットの場所。
  - 内容 : データ型タイプ S3Location 、オプションで提供
S3Location:
- bucketName:
  - S3 バケットの名前。
  - 型: 文字列
- objectKey:
  - S3 バケット内のオブジェクトのキー。バケット内のオブジェクトを一意に識別します。
  - 型: 文字列
AWSSessionCredentials:
- accessKeyId:
  - セッションのアクセスキー。
  - 型: 文字列
- secretAccessKey:
  - セッションのシークレットアクセスキー。
  - 型: 文字列
- sessionToken:
  - セッションのトークン。
  - 型: 文字列

例:


{
    "jobId": "01234567-abcd-abcd-abcd-012345678910",
    "accountId": "012345678910",
    "data": {
        "actionConfiguration": {
            "key1": "value1",
            "key2": "value2"
        },
        "encryptionKey": {
            "id": "123-abc",
            "type": "KMS"
        },
        "inputArtifacts": [
            {
                "name": "input-art-name",
                "location": {
                    "type": "S3",
                    "s3Location": {
                        "bucketName": "inputBucket",
                        "objectKey": "inputKey"
                    }
                }
            }
        ],
        "outputArtifacts": [
            {
                "name": "output-art-name",
                "location": {
                    "type": "S3",
                    "s3Location": {
                        "bucketName": "outputBucket",
                        "objectKey": "outputKey"
                    }
                }
            }
        ],
        "actionExecutionId": "actionExecutionId",
        "actionCredentials": {
            "accessKeyId": "access-id",
            "secretAccessKey": "secret-id",
            "sessionToken": "session-id"
        },
        "continuationToken": "continueId-xxyyzz"
    }
}

Lambda 関数の結果をに返す CodePipeline

インテグレータのジョブワーカーリソースは、成功、失敗、または継続の場合に有効なペイロードを返す必要があります。

形式:

result : ジョブの結果。
- 必須
- 有効な値 (大文字と小文字は区別されません)
  - Success : ジョブが正常に終了したことを示します。
  - Continue ：ジョブが正常に実行され、ジョブワーカーが同じアクションの実行に対して再呼び出された場合など、続行する必要があることを示します。
  - Fail : ジョブが失敗し、ターミナルであることを示します。
failureType : 失敗したジョブに関連付ける障害タイプ。

パートナーアクションの failureType カテゴリは、ジョブの実行中に発生した障害のタイプを示します。インテグレータは、ジョブの失敗の結果をに返すときに、失敗メッセージとともにタイプを設定します CodePipeline。
- オプション。結果が Fail の場合に必須。
- result が Success または Continue の場合は、null にする必要があります。
- 有効な値:
  - ConfigurationError
  - JobFailed
  - PermissionsError
  - RevisionOutOfSync
  - RevisionUnavailable
  - SystemUnavailable
continuation : 現在のアクション実行内で次のジョブに渡される継続状態。
- オプション。結果が Continue の場合に必須。
- result が Success または Fail の場合は、 null にする必要があります。
- プロパティ:
  - State : 渡すステートのハッシュ。
status : アクション実行のステータス。
- オプション。
- プロパティ:
  - ExternalExecutionId : ジョブに関連付けるオプションの外部実行 ID またはコミット ID。
  - Summary : 発生した事象の要約。障害シナリオでは、これがユーザーに表示される障害メッセージになります。
outputVariables : 次のアクションの実行に渡されるキーと値のペアのセット。
- オプション。
- result が Continue または Fail の場合は、 null にする必要があります。

例:


{
    "result": "success",
    "failureType": null,
    "continuation": null,
    "status": {
        "externalExecutionId": "my-commit-id-123",
        "summary": "everything is dandy"
    },
    "outputVariables": {
        "FirstOne": "Nice",
        "SecondOne": "Nicest",
        ...
    }        
}

継続トークンを使用して、非同期プロセスの結果を待つ

continuation トークンは Lambda 関数のペイロードと結果の一部です。これは、ジョブの状態をに渡し CodePipeline 、ジョブを継続する必要があることを示す方法です。例えば、インテグレーターがリソースでお客様のビルドを開始した後、ビルドが完了するまで待機しませんが、を resultとして返し、ビルドの一意の ID をcontinuationトークン CodePipeline としてにcontinue返すことで、ターミナル結果 CodePipeline がないことを示します。

注記

Lambda 関数は最大 15 分まで実行できます。ジョブを長く実行する必要がある場合は、継続トークンを使用できます。

CodePipeline チームは、ペイロードで同じcontinuationトークンを使用して 30 秒後にインテグレータを呼び出し、完了をチェックできるようにします。構築が完了すると、インテグレータはターミナルの成功/失敗結果を返し、そうでない場合は続行します。

実行時にインテグレータ Lambda 関数を呼び出すアクセス許可 CodePipeline を付与します。

インテグレータ Lambda 関数にアクセス許可を追加して、 CodePipeline サービスプリンシパルを使用して呼び出すアクセス許可を CodePipeline サービスに付与しますcodepipeline.amazonaws.com。 AWS CloudFormation またはコマンドラインを使用してアクセス許可を追加できます。例については、アクションタイプの使用を参照してください。

ジョブワーカー統合モデル

高レベルワークフローを綿密に設計した後、ジョブワーカーを作成できます。最終的にはサードパーティーアクションの仕様がジョブワーカーに必要なものを決定しますが、サードパーティーアクションのジョブワーカーの多くは以下の機能を含みます:

CodePipeline を使用したジョブのポーリングPollForThirdPartyJobs。
ジョブを承認し、AcknowledgeThirdPartyJob、、PutThirdPartyJobSuccessResultおよび CodePipeline を使用して結果をに返しますPutThirdPartyJobFailureResult。
パイプラインの Amazon S3 バケットからアーティファクトを取得する、またはアーティファクトを配置する。Amazon S3 バケットからアーティファクトをダウンロードするには、署名バージョン 4 の署名 (Sig V4) を使用する Amazon S3 クライアントを作成する必要があります。には Sig V4 が必要です AWS KMS。

Amazon S3 バケットにアーティファクトをアップロードするには、 AWS Key Management Service （AWS KMS) による暗号化を使用するように Amazon S3 PutObjectリクエストも設定する必要があります。は AWS KMS を使用します AWS KMS keys。アーティファクトをアップロードするために AWS マネージドキーまたはカスタマーマネージドキーのどちらを使用するかを知るには、ジョブワーカーがジョブデータを調べ、暗号化キープロパティを確認する必要があります。プロパティが設定されている場合は、の設定時にそのカスタマーマネージドキー ID を使用する必要があります AWS KMS。キープロパティが null の場合、特に設定 AWS マネージドキーされていない限り、 AWS マネージドキー. CodePipeline uses を使用します。

Java またはで AWS KMS パラメータを作成する方法を示す例についてはNET、「を使用して Amazon S3 AWS Key Management Service でを指定する AWS SDKs」を参照してください。の Amazon S3 バケットの詳細については CodePipeline、「」を参照してくださいCodePipeline の概念。

ジョブワーカー用にアクセス許可管理戦略を選択して設定する

でサードパーティーアクションのジョブワーカーを開発するには CodePipeline、ユーザーとアクセス許可の管理を統合するための戦略が必要です。

最も簡単な戦略は、 AWS Identity and Access Management （IAM) EC2インスタンスロールを使用して Amazon インスタンスを作成して、ジョブワーカーに必要なインフラストラクチャを追加することです。これにより、統合に必要なリソースを簡単にスケールアップできます。組み込みの統合をと使用 AWS して、ジョブワーカーと間のやり取りを簡素化できます CodePipeline。

Amazon の詳細を確認しEC2、統合に適した選択肢かどうかを判断します。詳細については、「Amazon EC2 - Virtual Server Hosting」を参照してください。Amazon EC2インスタンスの設定については、「Amazon EC2 Linux インスタンスの開始方法」を参照してください。

考慮すべきもう 1 つの戦略は、との ID フェデレーションを使用してIAM、既存の ID プロバイダーシステムとリソースを統合することです。この戦略は、お客様がすでに企業 ID プロバイダーを持っているか、ウェブ ID プロバイダーを使用するユーザーをサポートできるよう設定されている場合に、特に便利です。ID フェデレーションを使用すると、IAMユーザーを作成または管理しなくても CodePipeline、を含む AWS リソースへの安全なアクセスを許可できます。パスワードのセキュリティ要件や認証情報の更新に機能やポリシーを活用できます。サンプルアプリケーションをお客様自身の設計のテンプレートとして使用できます。詳細については、「フェデレーションの管理」を参照してください。

アクセス権限を付与するには、ユーザー、グループ、またはロールにアクセス許可を追加します。

のユーザーとグループ AWS IAM Identity Center：

アクセス許可セットを作成します。「AWS IAM Identity Center ユーザーガイド」の「権限設定を作成する」の手順に従ってください。
ID プロバイダーIAMを通じてで管理されるユーザー：

ID フェデレーションのロールを作成します。IAM ユーザーガイドの「サードパーティー ID プロバイダーのロールの作成 (フェデレーション）」の指示に従ってください。
IAM ユーザー：
- ユーザーが担当できるロールを作成します。「 IAMユーザーガイド」のIAM「ユーザーのロールの作成」の手順に従います。
- (お奨めできない方法) ポリシーをユーザーに直接アタッチするか、ユーザーをユーザーグループに追加する。IAM ユーザーガイドの「ユーザーへのアクセス許可の追加 (コンソール）」の指示に従ってください。

次は、サードパーティージョブワーカーで使用するために作成する可能性があるポリシーの例です。このポリシーは例に過ぎず、そのまま提供されています。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "codepipeline:PollForThirdPartyJobs",
        "codepipeline:AcknowledgeThirdPartyJob",
        "codepipeline:GetThirdPartyJobDetails",
        "codepipeline:PutThirdPartyJobSuccessResult",
        "codepipeline:PutThirdPartyJobFailureResult"
      ],
      "Resource": [
        "arn:aws:codepipeline:us-east-2::actionType:ThirdParty/Build/Provider/1/"  
      ]              
    }
  ]
}

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

LambdaInvoke

イメージ定義ファイルのリファレンス