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

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

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

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

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

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

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

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

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

概念

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

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

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

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

Lambda 統合モデル

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

Lambda 関数を更新して CodePipeline からの入力を処理します。

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

以下のパラメータを使用して Lambda 関数を更新し、 CodePipeline からの入力を処理します。

形式:

データ型:

例:

{
    "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",
    "failureType": null,
    "continuation": null,
    "status": {
        "externalExecutionId": "my-commit-id-123",
        "summary": "everything is dandy"
    },
    "outputVariables": {
        "FirstOne": "Nice",
        "SecondOne": "Nicest",
        ...
    }        
}

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

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

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

ランタイム時にインテグレーターの Lambda 関数を呼び出す権限を CodePipeline に提供します。

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

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

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

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

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

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

Amazon EC2 の詳細を参照し、統合に適しているかどうかを判断します。詳細については、「Amazon EC2 - 仮想サーバーのホスティング」を参照してください。Amazon EC2 インスタンスのセットアップについては、「Amazon EC2 Linux インスタンスの使用開始」を参照してください。

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

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

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

JSON

{
  "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/"  
      ]              
    }
  ]
}