翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
パイプライン、ステージ、アクションを作成する
AWS CodePipeline コンソールまたは AWS CLI を使用してパイプラインを作成できます。パイプラインには少なくとも 2 つのステージが必要です。パイプラインの第 1 ステージは、ソースステージである必要があります。パイプラインには、ビルドまたはデプロイステージである他のステージが少なくとも 1 つ必要です。
重要
パイプライン作成の一環として、CodePipeline は、ユーザーが指定した S3 アーティファクトバケットをアーティファクトとして使用します (これは S3 ソースアクションで使用するバケットとは異なります)。S3 アーティファクトバケットがパイプラインのアカウントとは異なるアカウントにある場合は、S3 アーティファクトバケットが によって所有 AWS アカウント されており、安全で信頼できることを確認してください。
パイプライン AWS リージョン とは異なる にあるアクションをパイプラインに追加できます。クロスリージョンアクションは、 AWS のサービス がアクションのプロバイダーであり、アクションタイプまたはプロバイダータイプがパイプラインとは異なる AWS リージョンにあるアクションです。詳細については、「CodePipeline にクロスリージョンアクションを追加する」を参照してください。
Amazon ECS をデプロイプロバイダとして使用して、コンテナベースのアプリケーションを構築およびデプロイするパイプラインを作成することもできます。Amazon ECS でコンテナベースのアプリケーションをデプロイするパイプラインを作成する前に、イメージ定義ファイルのリファレンス の説明に従ってイメージ定義ファイルを作成する必要があります。
CodePipeline は、ソースコードの変更がプッシュされたときにパイプラインを開始するように、変更検出方法を使用してします。この検出方法はソースタイプに基づいています。
-
CodePipeline は Amazon CloudWatch Events を使用して、CodeCommit ソースリポジトリとブランチの変更や S3 ソースバケットの変更を検出します。
注記
コンソールを使用してパイプラインを作成または編集すると、変更検出リソースが作成されます。 AWS CLI を使用してパイプラインを作成する場合は、追加のリソースを自分で作成する必要があります。詳細については、「 CodeCommit ソースアクションと EventBridge」を参照してください。
カスタムパイプラインを作成する (コンソール)
コンソールでカスタムパイプラインを作成するには、アクションで使用するソースファイルの場所とプロバイダーに関する情報を指定する必要があります。
コンソールを使用してパイプラインを作成する場合、ソースステージに加えて、以下のいずれかまたは両方が必要です。
-
ビルドステージ
-
デプロイステージ
パイプラインウィザードを使用する場合、CodePipeline はステージの名前 (ソース、ビルド、ステージング) を作成します。これらの名前は変更できません。ステージの後半で、より詳細な名前 (たとえば、BuildToGamma または DeployToProd) を使用することもできます。
ステップ 1: パイプラインの作成と名前付け
にサインイン AWS Management Console し、http://console.aws.amazon.com/codesuite/codepipeline/home
で CodePipeline コンソールを開きます。 -
[Welcome (ようこそ)] ページで、[Create pipeline (パイプラインの作成)] を選択します。
CodePipeline を初めて使用する場合は、Get Started を選択します。
-
[ステップ 1: 作成オプションを選択する] ページの [作成オプション] で、[カスタムパイプラインを構築する] オプションを選択します。[Next (次へ)] を選択します。
-
[ステップ 2: パイプラインの設定を選択する] ページで、[パイプライン名] にパイプラインの名前を入力します。
1 つの AWS アカウントで、 AWS リージョンで作成する各パイプラインには一意の名前が必要です。名前は、異なるリージョンのパイプラインに再利用できます。
注記
パイプラインを作成したら、その名前を変更することはできません。その他の制限についての詳細については、「AWS CodePipeline のクォータ」を参照してください。
-
[パイプラインのタイプ] で、次のいずれかのオプションを選択します。パイプラインのタイプによって特徴および価格が異なります。詳細については、「パイプラインのタイプ」を参照してください。
-
V1 タイプのパイプラインは、標準のパイプライン、ステージ、アクションレベルのパラメータを含む JSON 構造になっています。
-
V2 タイプのパイプラインは、V1 タイプと同じ構造で、Git タグやパイプラインレベルの変数に対するトリガーなど、追加のパラメータがサポートされています。
-
-
[Service role (サービスロール)] で、次のいずれかの操作を行います。
-
New service role を選択して、CodePipelineに IAM での新しいサービスロールの作成を許可します。
-
IAM で作成済みのサービスロールを使用するには、[Existing service role (既存のサービスロール)] を選択します。[ロール ARN] で、リストからサービスロール ARN を選択します。
注記
サービスロールが作成された日時によっては、追加の をサポートするようにアクセス許可を更新する必要がある場合があります AWS のサービス。詳細については、CodePipeline サービスロールにアクセス許可を追加する を参照してください。
サービスロールとそのポリシーステートメントの詳細については、「CodePipeline サービスロールを管理する」を参照してください。
-
-
(オプション) [変数] で [変数を追加] を選択し、パイプラインレベルの変数を追加します。
パイプラインレベルの変数の詳細については、「変数リファレンス」を参照してください。パイプラインの実行時に渡されるパイプラインレベルの変数のチュートリアルについては、「チュートリアル: パイプラインレベルの変数を使用する」を参照してください。
注記
パイプラインレベルの変数の追加はオプションですが、パイプラインレベルの変数に値が設定されていない場合、パイプラインの実行は失敗します。
-
(オプション) [詳細設定] を展開します。
-
[アーティファクトストア] で、以下のいずれかの操作を行います。
-
デフォルトの場所を選択して、パイプライン用に AWS リージョン 選択した のパイプラインに、デフォルトとして指定された S3 アーティファクトバケットなどのデフォルトのアーティファクトストアを使用します。
-
S3 アーティファクトバケットなどのアーティファクトストアがパイプラインと同じリージョンに既に存在する場合は、[Custom location (カスタムの場所)] を選択します。[バケット] で、バケット名を選択します。
注記
これはソースコードのソースバケットではありません。パイプラインのアーティファクトストアです。パイプラインごとに S3 バケットなどの個別のアーティファクトストアが必要です。パイプラインを作成または編集するときは、パイプラインリージョンにアーティファクトバケットと、アクションを実行している AWS リージョンごとに 1 つのアーティファクトバケットが必要です。
詳細については、入力および出力アーティファクトおよびCodePipeline パイプライン構造リファレンスを参照してください。
-
-
[暗号化キー] で、次のいずれかの操作を行います。
-
CodePipeline のデフォルトを使用してパイプラインアーティファクトストア (S3 バケット) 内のデータを暗号化 AWS KMS key するには、デフォルトの AWS マネージドキーを選択します。
-
カスタマーマネージドキーを使用してパイプラインアーティファクトストア (S3 バケット) 内のデータを暗号化するには、[カスタマーマネージドキー] を選択します。 キー ID、キー ARN、またはエイリアスの ARN を選択します。
-
-
[Next (次へ)] を選択します。
ステップ 2: ソースステージを作成する
-
[ステップ 3: ソースステージを追加する] ページの [ソースプロバイダー] で、ソースコードが保存されているリポジトリのタイプを選択し、必要なオプションを指定します。選択したソースプロバイダーに応じて、次のような追加のフィールドが表示されます。
-
Bitbucket Cloud、GitHub (GitHub アプリ経由)、GitHub Enterprise Server、GitLab.com,または GitLab セルフマネージドの場合:
-
接続 で、既存の接続を選択するか、新規の接続を作成します。GitHub ソースアクション用の接続を作成または管理するには、「GitHub コネクション」を参照してください。
-
パイプラインのソース場所として使用するリポジトリを選択します。
トリガーを追加するか、トリガータイプをフィルタリングするかを選択し、パイプラインを開始します。トリガーの操作の詳細については、「コードプッシュまたはプルリクエストイベントタイプでトリガーを追加する」を参照してください。glob パターンを使用したフィルタ処理の詳細については、「構文での glob パターンの使用」を参照してください。
-
Output artifact format で、アーティファクトのフォーマットを選択します。
-
デフォルトのメソッドを使用して GitHub アクションからの出力アーティファクトを保存するには、CodePipeline default を選択します。アクションは、Bitbucket リポジトリからファイルにアクセスし、パイプラインアーティファクトストアの ZIP ファイルにアーティファクトを保存します。
-
リポジトリへの URL 参照を含む JSON ファイルを保存して、ダウンストリームのアクションで Git コマンドを直接実行できるようにするには、[Full clone (フルクローン)] を選択します。このオプションは、CodeBuild ダウンストリームアクションでのみ使用できます。
このオプションを選択した場合は、CodePipeline のトラブルシューティング で示されるように CodeBuild プロジェクトサービスロールの権限を更新する必要があります。Full clone オプションを使用する方法を示すチュートリアルについては、チュートリアル: CodeCommit パイプラインソースで完全なクローンを使用する を参照してください。
-
-
-
Amazon S3 については:
-
[Amazon S3 の場所] で、S3 バケットの名前と、バージョニングが有効になっているバケット内のオブジェクトへのパスを指定します。バケット名とパスの形式は以下のようになります。
s3://
bucketName
/folderName
/objectName
注記
Amazon S3 がパイプラインのソースプロバイダーである場合、ソースファイルあるいはファイルを 1 つの [.zip] に圧縮し、その [.zip] をソースバケットにアップロードすることができます。解凍されたファイルを 1 つアップロードすることもできます。ただし、.zip ファイルを想定するダウンストリームアクションは失敗します。
-
S3 ソースバケットを選択すると、CodePipeline はこのパイプライン用に作成される Amazon CloudWatch Events ルールと AWS CloudTrail 証跡を作成します。[Change detection options (変更検出オプション)] で、デフォルト値を受け入れます。これにより、CodePipeline は Amazon CloudWatch Events と AWS CloudTrail を使用して、新しいパイプラインの変更を検出できます。[Next (次へ)] を選択します。
-
-
AWS CodeCommit の場合:
-
Repository name で、パイプラインのソース場所として使用する CodeCommitリポジトリの名前を選択します。[Branch name] で、ドロップダウンリストから使用するブランチを選択します。
-
Output artifact format で、アーティファクトのフォーマットを選択します。
-
デフォルトのメソッドを使用して CodeCommit アクションからの出力アーティファクトを保存するには、CodePipeline default を選択します。アクションは、CodeCommit リポジトリからファイルにアクセスし、パイプラインアーティファクトストアの ZIP ファイル中にアーティファクトを保存します。
-
リポジトリへの URL 参照を含む JSON ファイルを保存して、ダウンストリームのアクションで Git コマンドを直接実行できるようにするには、[Full clone (フルクローン)] を選択します。このオプションは、CodeBuild ダウンストリームアクションでのみ使用できます。
このオプションを選択する場合、
codecommit:GitPull
に示すように、CodeBuild サービスロールに CodeBuild GitClone のアクセス権限を CodeCommit ソースアクションに追加します。 の許可を追加する必要があります。また、codecommit:GetRepository
に示すように、CodePipeline のサービス・ロールに CodePipeline サービスロールにアクセス許可を追加する の許可を追加する必要もあります。Full clone オプションを使用する方法を示すチュートリアルについては、チュートリアル: CodeCommit パイプラインソースで完全なクローンを使用する を参照してください。
-
-
CodeCommit リポジトリ名とブランチを選択すると、Change detection options にメッセージが表示されて、このパイプライン用に作成される Amazon CloudWatch Events ルールが示されます。[Change detection options (変更検出オプション)] で、デフォルト値を受け入れます。これにより、CodePipeline は、 Amazon CloudWatch Events を使用して、新しいパイプラインの変更を検出できます。
-
-
Amazon ECR については:
-
Repository name で、Amazon ECR リポジトリの名前を選択します。
-
[Image tag] で、イメージの名前とバージョンを指定します (最新でない場合)。
-
[出力アーティファクト] で、デフォルトの出力アーティファクト (例: MyApp) を選択します。これには、次のステージで使用するイメージの名前およびリポジトリの URI が含まれます。
Amazon ECR ソースステージを含む、CodeDeploy ブルー-グリーンデプロイを用いての Amazon ECS のパイプラインの作成に関するチュートリアルについては、チュートリアル: Amazon ECR ソース、ECS - CodeDeploy 間のデプロイでパイプラインを作成する を参照してください。
パイプラインに Amazon ECR のソースステージを含めると、変更をコミットしたときにソースアクションによって、出力アーティファクトとして
imageDetail.json
のファイルが生成されます。imageDetail.json
ファイルの詳細については、「Amazon ECS Blue/Green デプロイアクション用の imageDetail.json ファイル」を参照してください。 -
注記
オブジェクトとファイルのタイプは、使用するデプロイシステム (Elastic Beanstalk や CodeDeploy など) と互換性があることが必要です。サポートされているファイルのタイプは .zip、.tar、.tgz ファイルなどです。Elastic Beanstalk でサポートされているコンテナのタイプの詳細については、Customizing and Configuring Elastic Beanstalk Environments と Supported Platforms を参照してください。CodeDeploy によるデプロイのリビジョンの詳細については、Uploading Your Application Revision と Prepare a Revision を参照してください。
-
-
自動再試行のステージを設定するには、[ステージ障害時の自動再試行を有効にする] を選択します。自動再試行の詳細については、「ステージ障害時の自動再試行を設定する」を参照してください。
-
[Next (次へ)] を選択します。
ステップ 4: ビルドステージを作成する
デプロイステージを作成する予定の場合、このステップはオプションです。
-
ステップ 4: ビルドステージの追加ページで、次のいずれかを実行し、次へを選択します。
-
テストまたはデプロイステージを作成する場合は、ビルドステージをスキップを選択します。
-
ビルドステージのコマンドアクションを選択するには、[コマンド] を選択します。
注記
コマンドアクションを実行すると、 AWS CodeBuildで別途料金が発生します。
[コマンド] で、アクションのシェルコマンドを入力します。コマンドアクションの詳細については、「コマンドアクションリファレンス」を参照してください。
-
CodeBuild などの他のビルドプロバイダーを選択するには、[その他のプロバイダー] を選択します。[ビルドプロバイダー] から、ビルドサービスのカスタムアクションプロバイダーを選択し、そのプロバイダーの設定詳細を入力します。Jenkins をビルドプロバイダとして追加する方法の例については、「チュートリアル: 4 ステージのパイプラインを作成する」を参照してください。
-
[ビルドプロバイダ] から、[AWS CodeBuild] を選択します。
リージョンで、リソースが存在する AWS リージョンを選択します。リージョンフィールドは、このアクションタイプとプロバイダータイプに対して AWS リソースが作成される場所を指定します。このフィールドは、アクションプロバイダーが AWS のサービスである場合にのみ表示されます。リージョンフィールドは、パイプラインと同じ AWS リージョンにデフォルト設定されます。
[プロジェクト名] で、ビルドプロジェクトを選択します。CodeBuild にビルドプロジェクトがすでにある場合は、それを選択します。または、CodeBuild でビルドプロジェクトを作成し、その後でこのタスクに戻ります。CodeBuild User Guide 中の Create a Pipeline That Uses CodeBuild の指示に従います。
Environment variables で、ビルドアクションに CodeBuild 環境変数を追加するには、Add environment variable を選択します。各変数は、次の 3 つのエントリで構成されます。
-
[名前] には、環境変数の名前またはキーを入力します。
-
[値] には、環境変数の値を入力します。変数タイプに Parameter を選択した場合は、この値が AWS Systems Manager Parameter Store に既に保存されているパラメータの名前であることを確認します。
注記
機密情報、特に AWS 認証情報を保存するために環境変数を使用することは強くお勧めしません。CodeBuild コンソールまたは CLI AWS を使用すると、環境変数がプレーンテキストで表示されます。機密の値の場合は、代わりに [パラメータ] 型を使用することをお勧めします。
-
(オプション) [型] に、環境変数の型を入力します。有効な値は、[プレーンテキスト] または [パラメータ] です。デフォルトは [プレーンテキスト] です。
(オプション) Build type で、次のいずれかを選択します。
-
各ビルドを 1 回のビルドアクション実行で実行するには、Single build を選択します。
-
同じビルドアクションの実行で複数のビルドを実行するには、Batch build を選択します。
(オプション) バッチビルドを選択した場合、Combine all artifacts from batch into a single location を選択して、すべてのビルドアーティファクトを 1 つの出力アーティファクトに配置します。
-
-
-
自動再試行のステージを設定するには、[ステージ障害時の自動再試行を有効にする] を選択します。自動再試行の詳細については、「ステージ障害時の自動再試行を設定する」を参照してください。
-
[Next (次へ)] を選択します。
ステップ 5: テストステージを作成する
ビルドステージまたはデプロイステージを作成する場合は、このステップはオプションです。
-
ステップ 5: テストステージの追加ページで、次のいずれかを実行し、次へを選択します。
-
ビルドまたはデプロイステージを作成する場合は、テストステージをスキップを選択します。
-
テストプロバイダーで、テストアクションプロバイダーを選択し、適切なフィールドに入力します。
-
-
[Next (次へ)] を選択します。
ステップ 6: デプロイステージを作成する
ビルドステージをすでに作成している場合、このステップはオプションです。
-
ステップ 6: デプロイステージの追加ページで、次のいずれかを実行して、次へを選択します。
-
前のステップでビルドまたはテストステージを作成した場合は、デプロイステージをスキップを選択します。
注記
このオプションは、ビルドステージまたはテストステージを既にスキップしている場合は表示されません。
-
[デプロイプロバイダ] で、デプロイプロバイダ用に作成したカスタムアクションを選択します。
リージョンでは、クロスリージョンアクションの場合のみ、リソースが作成される AWS リージョンを選択します。[リージョン] フィールドは、このアクションタイプとプロバイダータイプに対して作成済みの AWS リソースの場所を示します。このフィールドには、アクションプロバイダーが AWS のサービスであるアクションのみが表示されます。リージョンフィールドは、パイプラインと同じ AWS リージョンにデフォルト設定されます。
-
[デプロイプロバイダ] で、デフォルトプロバイダ用の以下のフィールドを使用できます。
-
CodeDeploy
Application name で、既存の CodeDeploy アプリケーションの名前を入力または選択します。[デプロイグループ] に、アプリケーションのデプロイグループの名前を入力します。[Next (次へ)] を選択します。アプリケーション、デプロイグループ、または両方を CodeDeploy コンソールで作成することもできます。
-
AWS Elastic Beanstalk
Application name で、既存の Elastic Beanstalk アプリケーションの名前を入力または選択します。[環境名] に、アプリケーションの環境を入力します。[Next (次へ)] を選択します。アプリケーション、環境、または両方を Elastic Beanstalk コンソールで作成することもできます。
-
AWS OpsWorks Stacks
[スタック] で、使用するスタックの名前を入力または選択します。[レイヤー] で、ターゲットインスタンスがあるレイヤーを選択します。[デプロイ] で、更新およびデプロイするアプリケーションを選択します。アプリケーションを作成する必要がある場合は、[Create a new one in AWS OpsWorks] を選択します。
でスタックとレイヤーにアプリケーションを追加する方法については AWS OpsWorks、「 AWS OpsWorks ユーザーガイド」の「アプリケーションの追加」を参照してください。
CodePipeline でシンプルなパイプラインをレイヤーで実行するコードのソースとして使用する方法のend-to-endの例については、CodePipeline の使用 AWS OpsWorks Stacks」を参照してください。 AWS OpsWorks
-
AWS CloudFormation
次のいずれかを行います。
-
アクションモードで、スタックの作成または更新を選択し、スタック名とテンプレートファイル名を入力し、 が引き受け AWS CloudFormation るロールの名前を選択します。必要に応じて、設定ファイルの名前を入力し、IAM 機能オプションを選択します。
-
アクションモードで、変更セットを作成または置換を選択し、スタック名と変更セット名を入力し、 が引き受け AWS CloudFormation るロールの名前を選択します。必要に応じて、設定ファイルの名前を入力し、IAM 機能オプションを選択します。
CodePipeline のパイプラインに AWS CloudFormation 機能を統合するための情報については、AWS CloudFormation 「 ユーザーガイド」のCodePipeline を使用した継続的デリバリー」を参照してください。
-
-
Amazon ECS
Cluster name で、既存の Amazon ECS クラスターの名前を入力または選択します。[サービス名] で、クラスターで実行されているサービスの名前を入力または選択します。クラスターとサービスを作成することもできます。[イメージのファイル名] で、サービスのコンテナとイメージを説明するイメージ定義ファイルの名前を入力します。
注記
Amazon ECS デプロイアクションでは、デプロイアクションへの入力として
imagedefinitions.json
のファイルが必要です。ファイルのデフォルトのファイル名は、imagedefinitions.json です。別のファイル名を使用することを選択した場合は、パイプラインデプロイステージを作成するときにそれを指定する必要があります。詳細については、「Amazon ECS 標準デプロイアクション用の imagedefinitions.json ファイル」を参照してください。[Next (次へ)] を選択します。
注記
Amazon ECS クラスターが 2 つ以上のインスタンスで設定されていることを確認してください。Amazon ECS クラスターには、少なくとも 2 つのインスタンスが必要です。1 つはプライマリインスタンスとして維持し、もう 1 つは新しいデプロイに対応するために使用します。
パイプラインを使用したコンテナベースのアプリケーションのデプロイに関するチュートリアルについては、Tutorial: Continuous Deployment with CodePipeline を参照してください。
-
Amazon ECS (Blue/Green)
CodeDeploy アプリケーションとデプロイグループ、 Amazon ECS タスク定義、AppSpec ファイル情報を入力して、Next を選択します。
注記
Amazon ECS (Blue/Green) アクションには、デプロイアクションの入力アーティファクトとして imageDetail.json ファイルが必要です。Amazon ECR ソースアクションがこのファイルを作成するので、Amazon ECR ソースアクションを持つパイプラインは、
imageDetail.json
のファイルを提供する必要はありません。詳細については、「Amazon ECS Blue/Green デプロイアクション用の imageDetail.json ファイル」を参照してください。CodeDeploy を使用して Amazon ECS クラスターへの blue-green デプロイ用のパイプラインを作成するためのチュートリアルについては、チュートリアル: Amazon ECR ソース、ECS - CodeDeploy 間のデプロイでパイプラインを作成する を参照してください。
-
AWS Service Catalog
コンソールのフィールドを使用して設定を指定する場合は [Enter deployment configuration (デプロイ設定の入力)] を選択します。あるいは、個別の設定ファイルがある場合は [設定ファイル] を選択します。製品と設定の情報を入力し、[次へ] を選択します。
パイプラインを使用して製品の変更を Service Catalog にデプロイする方法のチュートリアルについては、「チュートリアル: Service Catalog にデプロイするパイプラインを作成する」を参照してください。
-
Alexa Skills Kit
[Alexa Skill ID (Alexa スキル ID)] に Alexa スキルのスキル ID を入力します。[クライアント ID] と [クライアントシークレット] に、Login with Amazon (LWA) セキュリティプロファイルを使用して生成された認証情報を入力します。[Refresh token (更新トークン)] に、ASK CLI コマンドを使用して生成した更新トークンを入力します。[Next (次へ)] を選択します。
パイプラインにより Alexa スキルをデプロイする方法、LWA 認証情報を生成する方法のチュートリアルについては、「チュートリアル: Amazon Alexa Skill をデプロイするパイプラインを作成する」を参照してください。
-
Amazon S3
[バケット] に、使用する S3 バケットの名前を入力します。デプロイステージへの入力アーティファクトが ZIP ファイルの場合は、[Extract file before deploy (デプロイ前にファイルを展開)] を選択します。[Extract file before deploy (デプロイ前にファイルを展開)] を選択した場合は、オプションで [Deployment path (デプロイパス)] に ZIP ファイルの解凍先を入力できます。選択しなかった場合は、[S3 object key (S3 オブジェクトキー)] に値を入力する必要があります。
注記
ほとんどのソースステージおよびビルドステージの出力アーティファクトは圧縮されます。Amazon S3 zip を除くすべてのパイプラインソースプロバイダーは、ソースファイルを Zip してから、次のアクションに入力アーティファクトとして提供します。
(オプション) Canned ACL で、canned ACL を入力し、Amazon S3 にデプロイされたオブジェクトに適用します。
注記
既定 ACL を適用すると、オブジェクトに適用された既存の ACL が上書きされます。
(オプション) [キャッシュコントロール] で、バケットからオブジェクトをダウンロードするリクエストのキャッシュコントロールパラメータを指定します。有効な値のリストについては、HTTP オペレーションの
Cache-Control
ヘッダーフィールドを参照してください。[Cache control (キャッシュコントロール)] に複数の値を入力するには、各値の間にカンマを使用します。この例に示すように、各カンマの後にスペースを追加できます (オプション)。 上記のエントリ例は、CLI に次のように表示されます。
"CacheControl": "public, max-age=0, no-transform"
[Next (次へ)] を選択します。
Amazon S3 デプロイアクションプロバイダとして を使用するパイプラインを作成する方法のチュートリアルについては、チュートリアル: Amazon S3 をデプロイプロバイダとして使用するパイプラインを作成する を参照してください。
-
-
-
自動再試行のステージを設定するには、[ステージ障害時の自動再試行を有効にする] を選択します。自動再試行の詳細については、「ステージ障害時の自動再試行を設定する」を参照してください。
-
自動ロールバックのステージを設定するには、[ステージ障害時の自動ロールバックを設定] を選択します。自動ロールバックの詳細については、「ステージの自動ロールバックを設定する」を参照してください。
-
[Next step]を選択します。
ステップ 7: パイプラインを確認する
-
ステップ 7: 確認 ページでパイプライン設定を確認し、パイプラインの作成 を選択してパイプラインを作成するか、前の を選択して選択内容に戻って編集します。パイプラインを作成せずにウィザードを終了するには、[Cancel] を選択します。
パイプラインが作成され、コンソールで表示できるようになりました。パイプラインは、作成後に実行されます。詳細については、「CodePipeline でパイプラインと詳細を表示する」を参照してください。パイプラインを変更する方法の詳細については、「CodePipeline でパイプラインを編集する」を参照してください。
パイプラインを作成する (CLI)
を使用してパイプライン AWS CLI を作成するには、パイプライン構造を定義する JSON ファイルを作成し、 --cli-input-json
パラメータを指定して create-pipeline コマンドを実行します。
重要
を使用して AWS CLI 、パートナーアクションを含むパイプラインを作成することはできません。代わりに CodePipeline コンソールを使用する必要があります。
パイプライン構造に関する詳細については、CodePipeline パイプライン構造リファレンス およびCodePipeline API Reference の create-pipeline を参照してください。
JSON ファイルを作成するには、同じパイプラインの JSON ファイルを使用して編集し、create-pipeline コマンドを実行するときにこのファイルを呼び出します。
前提条件:
CodePipeline の使用開始 で CodePipeline 用に作成したサービスロールの ARN が必要です。create-pipeline のコマンドの実行時、パイプライン JSON ファイル中の CodePipeline サービスロールの ARN を使用します。サービスロールの作成の詳細については、「CodePipeline サービスロールを作成する」を参照してください。コンソールとは異なり、 で create-pipeline コマンドを実行すると、CodePipeline サービスロールを作成するオプション AWS CLI はありません。サービスロールがすでに存在している必要があります。
パイプラインのアーティファクトの保存先である S3 バケットの名前が必要です。このバケットはパイプラインと同じリージョンに存在する必要があります。バケット名は、create-pipeline コマンドの実行時にパイプライン JSON ファイルで使用します。コンソールとは異なり、 で create-pipeline コマンドを実行して AWS CLI も、アーティファクトを保存するための S3 バケットは作成されません。バケットが存在している必要があります。
注記
get-pipeline コマンドを使用して、パイプラインの JSON 構造のコピーを取得し、プレーンテキストエディタで構造を変更することもできます。
トピック
JSON ファイルを作成するには
-
ターミナル (Linux、 macOS、あるいは Unix)またはコマンドプロンプト(Windows)で、ローカルディレクトリに新規のテキストファイルを作成します。
-
(オプション) パイプラインレベルでは 1 つ以上の変数を追加できます。この値は CodePipeline アクションの設定で参照できます。パイプラインを作成するときに変数名と値を追加できます。また、コンソールでパイプラインを開始するときに値を割り当てることもできます。
注記
パイプラインレベルの変数の追加はオプションですが、パイプラインレベルの変数に値が設定されていない場合、パイプラインの実行は失敗します。
パイプラインレベルの変数は、パイプラインの実行時に解決されます。すべての変数は不変であり、値が割り当てられた後は更新できません。パイプラインレベルの変数のうち値が解決されたものは、実行ごとの履歴に表示されます。
パイプライン構造の変数属性を使用して、パイプラインレベルの変数を指定します。以下の例では、変数
Variable1
の値はValue1
です。"variables": [ { "name": "Timeout", "defaultValue": "1000", "description": "description" } ]
この構造をパイプラインの JSON に追加するか、次のステップのサンプルの JSON に追加します。名前空間の情報など変数の詳細については、「変数リファレンス」を参照してください。
-
プレーンテキストエディタでファイルを開き、作成する構造を反映するように値を編集します。少なくとも、パイプラインの名前を変更する必要があります。また、変更するかを考慮する必要もあります。
-
このパイプラインのアーティファクトの保存先の S3 バケット。
-
コードのソースの場所。
-
デプロイのプロバイダ。
-
コードをデプロイする方法。
-
パイプラインのタグ。
以下の 2 ステージのサンプルパイプライン構造では、変更を検討する必要があるパイプラインの値を強調表示しています。パイプラインには多くの場合、2 つ以上のステージが含まれます。
{ "pipeline": { "roleArn": "arn:aws:iam::80398EXAMPLE::role/AWS-CodePipeline-Service", "stages": [ { "name": "
Source
", "actions": [ { "inputArtifacts": [], "name": "Source", "actionTypeId": { "category": "Source", "owner": "AWS", "version": "1", "provider": "S3" }, "outputArtifacts": [ { "name": "MyApp" } ], "configuration": { "S3Bucket": "amzn-s3-demo-source-bucket
", "S3ObjectKey": "ExampleCodePipelineSampleBundle.zip
", "PollForSourceChanges": "false" }, "runOrder": 1 } ] }, { "name": "Staging", "actions": [ { "inputArtifacts": [ { "name": "MyApp" } ], "name": "Deploy-CodeDeploy-Application
", "actionTypeId": { "category": "Deploy", "owner": "AWS", "version": "1", "provider": "CodeDeploy" }, "outputArtifacts": [], "configuration": { "ApplicationName": "CodePipelineDemoApplication
", "DeploymentGroupName": "CodePipelineDemoFleet
" }, "runOrder": 1 } ] } ], "artifactStore": { "type": "S3", "location": "codepipeline-us-east-2-250656481468" }, "name": "MyFirstPipeline", "version": 1, "variables": [ { "name": "Timeout", "defaultValue": "1000", "description": "description" } ] }, "triggers": [ { "providerType": "CodeStarSourceConnection", "gitConfiguration": { "sourceActionName": "Source", "push": [ { "tags": { "includes": [ "v1" ], "excludes": [ "v2" ] } } ] } } ] "metadata": { "pipelineArn": "arn:aws:codepipeline:us-east-2:80398EXAMPLE:MyFirstPipeline", "updated": 1501626591.112, "created": 1501626591.112 }, "tags": [{ "key": "Project", "value": "ProjectA" }] }この例では、パイプラインの
Project
タグキーとProjectA
値を含めることによって、タグ付けをパイプラインに追加します。CodePipeline のタグ付けリソースのさらなる詳細については、リソースのタグ付け を参照してください。JSON ファイルの
PollForSourceChanges
パラメータが次のように設定されていることを確認します。"PollForSourceChanges": "false",
CodePipeline は、Amazon CloudWatch Events を使用して、CodeCommit ソースリポジトリとブランチの変更、あるいは S3 ソースバケットの変更を検出します。次のステップには、パイプラインにこれらのリソースを手動で作成する手順が含まれています。フラグを
false
に設定すると、定期的なチェックが無効になります。これは、推奨される変更検出メソッドを使用している場合には、必要ではありません。 -
-
パイプラインとは異なるリージョンでビルド、テスト、またはデプロイアクションを作成するには、パイプライン構造に以下を追加する必要があります。手順については、CodePipeline にクロスリージョンアクションを追加する を参照してください。
-
Region
パラメータをアクションのパイプライン構造に追加します。 -
artifactStores
パラメータを使用して、アクションがある各 AWS リージョンのアーティファクトバケットを指定します。
-
-
その構造で問題がなければ、
pipeline.json
のような名前でファイルを保存します。
パイプラインを作成するには
-
先ほど作成した JSON ファイルを
--cli-input-json
パラメータで指定して、create-pipeline コマンドを実行します。MySecondPipeline
という名前を JSON 内のname
のための値として含む [pipeline.json] という名前の JSON ファイルを使用してMySecondPipeline
という名前のパイプラインを作成するには、コマンドは以下のように見えます:aws codepipeline create-pipeline --cli-input-json file://pipeline.json
重要
ファイル名の前に必ず
file://
を含めてください。このコマンドでは必須です。このコマンドは、作成したパイプライン全体の構造を返します。
-
パイプラインを表示するには、CodePipeline コンソールを開いてパイプラインのリストから選択するか、get-pipeline-state のコマンドを使用します。詳細については、「CodePipeline でパイプラインと詳細を表示する」を参照してください。
-
パイプラインの作成に CLI を使用する場合には、推奨される変更検出リソースを手動でパイプラインに作成する必要があります。
-
CodeCommit リポジトリを使用するパイプラインのために、CodeCommit ソースに対する EventBridge ルールを作成する (CLI) で述べられている CloudWatch Events ルールを手動で作成する必要があります。
-
Amazon S3 ソースを持つパイプラインの場合、「」で説明されているように、CloudWatch Events ルールと AWS CloudTrail 証跡を手動で作成する必要がありますEventBridge と を使用する Amazon S3 ソースアクションへの接続 AWS CloudTrail。
-
静的テンプレートからパイプラインを作成する
テンプレートを使用して、指定したソースコードとプロパティでパイプラインを設定するパイプラインをコンソールで作成できます。アクションに使用するソースファイルの場所とソースプロバイダーに関する情報を指定する必要があります。Amazon ECR のソースアクションを指定するか、CodeConnections でサポートされているサードパーティリポジトリ (GitHub など) を指定できます。
テンプレートは、次のリソースを含むパイプライン AWS CloudFormation のスタックを に作成します。
-
パイプラインを V2 パイプラインタイプで作成します。[パイプラインのタイプ] で、次のいずれかのオプションを選択します。パイプラインのタイプによって特徴および価格が異なります。詳細については、「パイプラインのタイプ」を参照してください。
-
サービスロールをパイプライン用に作成し、テンプレートで参照します。
-
アーティファクトストアを作成します。これを作成するには、パイプライン用に選択した AWS リージョン でパイプラインのデフォルトのアーティファクトストア (デフォルトとして指定した S3 アーティファクトバケットなど) を使用します。
静的テンプレート作成ウィザードに使用されるオープンソースのスターターテンプレートのコレクションを表示するには、https://github.com/aws/codepipeline-starter-templates
静的テンプレートを使用してパイプラインを作成する場合、ユースケースのニーズに応じてテンプレートごとにパイプライン構造が設定されます。例えば、 へのデプロイ用の テンプレート AWS CloudFormation は、この手順の例として使用されます。テンプレートは、以下の構造を持つ DeployToCloudFormationService という名前のパイプラインを生成します。
-
ウィザードで指定した設定のソースアクションを含むビルドステージ。
-
AWS CloudFormationのデプロイアクションおよび関連リソーススタックを含むデプロイステージ。
静的テンプレートを使用してパイプラインを作成する場合、CodePipeline はステージ (ソース、ビルド、ステージング) の名前を作成します。これらの名前は変更できません。ステージの後半で、より詳細な名前 (たとえば、BuildToGamma または DeployToProd) を使用することもできます。
ステップ 1: 作成オプションを選択する
にサインイン AWS Management Console し、http://console.aws.amazon.com/codesuite/codepipeline/home
で CodePipeline コンソールを開きます。 -
[Welcome (ようこそ)] ページで、[Create pipeline (パイプラインの作成)] を選択します。
CodePipeline を初めて使用する場合は、Get Started を選択します。
-
[ステップ 1: 作成オプションを選択する] ページの [作成オプション] で、[カスタムパイプラインを構築する] オプションを選択します。[Next (次へ)] を選択します。
ステップ 2: テンプレートを選択する
テンプレートを選択し、デプロイステージ、オートメーション、または CI パイプラインを使用してパイプラインを作成します。
-
[ステップ 2: テンプレートを選択する] ページで、次のいずれかの操作を行い、[次へ] を選択します。
-
デプロイステージを作成する場合は、[デプロイ] を選択します。ECR または CloudFormation にデプロイするテンプレートのオプションを表示します。この例では、[デプロイ] を選択し、CloudFormation にデプロイすることを選択します。
-
CI パイプラインを作成する場合は、[継続的インテグレーション] を選択します。Gradle への構築など、CI パイプラインのオプションを表示します。
-
自動パイプラインを作成する場合は、[オートメーション] を選択します。Python ビルドのスケジュールなど、オートメーションのオプションを表示します。
-
-
ステップ 3: ソースを選択する
-
[ステップ 3: ソースを選択する] ページの [ソースプロバイダー] で、ソースコードが保存されているリポジトリのプロバイダーを選択し、必要なオプションを指定して [次のステップ] を選択します。
-
Bitbucket Cloud、GitHub (GitHub アプリ経由)、GitHub Enterprise Server、GitLab.com,または GitLab セルフマネージドの場合:
-
接続 で、既存の接続を選択するか、新規の接続を作成します。GitHub ソースアクション用の接続を作成または管理するには、「GitHub コネクション」を参照してください。
-
パイプラインのソース場所として使用するリポジトリを選択します。
トリガーを追加するか、トリガータイプをフィルタリングするかを選択し、パイプラインを開始します。トリガーの操作の詳細については、「コードプッシュまたはプルリクエストイベントタイプでトリガーを追加する」を参照してください。glob パターンを使用したフィルタ処理の詳細については、「構文での glob パターンの使用」を参照してください。
-
Output artifact format で、アーティファクトのフォーマットを選択します。
-
デフォルトのメソッドを使用して GitHub アクションからの出力アーティファクトを保存するには、CodePipeline default を選択します。アクションは、Bitbucket リポジトリからファイルにアクセスし、パイプラインアーティファクトストアの ZIP ファイルにアーティファクトを保存します。
-
リポジトリへの URL 参照を含む JSON ファイルを保存して、ダウンストリームのアクションで Git コマンドを直接実行できるようにするには、[Full clone (フルクローン)] を選択します。このオプションは、CodeBuild ダウンストリームアクションでのみ使用できます。
このオプションを選択した場合は、CodePipeline のトラブルシューティング で示されるように CodeBuild プロジェクトサービスロールの権限を更新する必要があります。[完全クローン] オプションを使用する方法を示すチュートリアルについては、チュートリアル: CodeCommit パイプラインソースで完全なクローンを使用する を参照してください。
-
-
-
Amazon ECR については:
-
Repository name で、Amazon ECR リポジトリの名前を選択します。
-
[Image tag] で、イメージの名前とバージョンを指定します (最新でない場合)。
-
[出力アーティファクト] で、デフォルトの出力アーティファクト (例: MyApp) を選択します。これには、次のステージで使用するイメージの名前およびリポジトリの URI が含まれます。
パイプラインに Amazon ECR のソースステージを含めると、変更をコミットしたときにソースアクションによって、出力アーティファクトとして
imageDetail.json
のファイルが生成されます。imageDetail.json
ファイルの詳細については、「Amazon ECS Blue/Green デプロイアクション用の imageDetail.json ファイル」を参照してください。 -
注記
オブジェクトとファイルのタイプは、使用するデプロイシステム (Elastic Beanstalk や CodeDeploy など) と互換性があることが必要です。サポートされているファイルのタイプは .zip、.tar、.tgz ファイルなどです。Elastic Beanstalk でサポートされているコンテナのタイプの詳細については、Customizing and Configuring Elastic Beanstalk Environments と Supported Platforms を参照してください。CodeDeploy によるデプロイのリビジョンの詳細については、Uploading Your Application Revision と Prepare a Revision を参照してください。
-
ステップ 4: テンプレートを設定する
この例では、CloudFormation へのデプロイが選択されています。このステップでは、テンプレートの設定を追加します。

-
[ステップ 4: テンプレートを設定する] で、[スタック名] にパイプラインの名前を入力します。
-
テンプレートに適用するアクセス許可のプレースホルダー IAM ポリシーを編集します。
-
[パイプラインをテンプレートから作成する] を選択する
-
パイプラインリソースを作成中であることを示すメッセージが表示されます。
ステップ 5: パイプラインを表示する
-
パイプラインを作成したら、CodePipeline でパイプラインを表示し、 AWS CloudFormationでスタックを確認できます。パイプラインは、作成後に実行されます。詳細については、「CodePipeline でパイプラインと詳細を表示する」を参照してください。パイプラインを変更する方法の詳細については、「CodePipeline でパイプラインを編集する」を参照してください。