翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
統合モデルのリファレンス
パイプラインのリリースプロセスに、既存の顧客ツールを構築するのに役立つサードパーティーサービスのための事前構築済みの統合がいくつかあります。パートナー、またはサードパーティーのサービスプロバイダーは、統合モデルを使用して、 で使用するアクションタイプを実装します 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 関数として書き込みます。これは、アクションに使用できるジョブがある 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
として返continue
し、ビルドの一意の ID をcontinuation
トークン CodePipeline として に返すことで、ターミナル結果 CodePipeline がないことを示します。
注記
Lambda 関数は最大 15 分まで実行できます。ジョブを長く実行する必要がある場合は、継続トークンを使用できます。
CodePipeline チームは、ペイロード内の同じcontinuation
トークンを使用して 30 秒後にインテグレーターを呼び出し、完了を確認できるようにします。構築が完了すると、インテグレータはターミナルの成功/失敗結果を返し、そうでない場合は続行します。
実行時にインテグレータ Lambda 関数を呼び出すアクセス許可 CodePipeline を提供する
インテグレータ Lambda 関数にアクセス許可を追加して、 CodePipeline サービスプリンシパル を使用して呼び出すアクセス許可を CodePipeline サービスに提供しますcodepipeline.amazonaws.com
。 AWS CloudFormation または コマンドラインを使用してアクセス許可を追加できます。例については、アクションタイプの使用を参照してください。
ジョブワーカー統合モデル
高レベル ワークフローを綿密に設計した後、ジョブワーカーを作成できます。最終的にはサードパーティーアクションの仕様がジョブワーカーに必要なものを決定しますが、サードパーティーアクションのジョブワーカーの多くは以下の機能を含みます:
-
CodePipeline の使用によるジョブのポーリング
PollForThirdPartyJobs
。 -
ジョブを承認し
PutThirdPartyJobSuccessResult
、AcknowledgeThirdPartyJob
、、および CodePipeline を使用して結果を に返しますPutThirdPartyJobFailureResult
。 -
パイプラインの Amazon S3 バケットからアーティファクトを取得する、またはアーティファクトを配置する。Amazon S3 バケットからアーティファクトをダウンロードするには、署名バージョン 4 の署名 (Sig V4) を使用する Amazon S3 クライアントを作成する必要があります。Sig V4 は に必要です AWS KMS。
Amazon S3 バケットにアーティファクトをアップロードするには、 AWS Key Management Service (AWS KMS). AWS KMS uses を使用して暗号化を使用するように Amazon S3
PutObject
リクエストを設定する必要があります 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
考慮すべきもう 1 つの戦略は、 と ID フェデレーションを使用して既存の ID プロバイダーのシステムとリソースIAMを統合することです。この戦略は、お客様がすでに企業 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/" ] } ] }