AWS CodePipeline​ 内に位置している - ユーザーガイド

Transcription

1 AWS CodePipeline 内に位置している ユーザーガイド

2 AWS CodePipeline 内に位置している: ユーザーガイド Copyright 2018 Amazon Web Services, Inc. and/or its affiliates. All rights reserved. Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be affiliated with, connected to, or sponsored by Amazon.

3 Table of Contents... vii AWS CodePipeline とは... 1 AWS CodePipeline の紹介ビデオ... 1 AWS CodePipeline の機能... 1 AWS CodePipeline のクイックルック... 2 入出力アーティファクトの概要... 2 AWS CodePipeline の使用を開始するには... 3 ご意見をお待ちしております... 3 概念... 4 継続的な配信と統合... 4 AWS CodePipeline による... 4 ご利用開始にあたって... 9 ステップ 1: AWS アカウントの作成... 9 ステップ 2: IAM ユーザーを作成または使用する... 9 ステップ 3: IAM 管理ポリシーを使用して IAM ユーザーへ AWS CodePipeline のアクセス許可を割り 当てる... 9 手順 4: AWS CLI をインストールする ステップ 5: AWS CodePipeline コンソールを開く 次のステップ 製品とサービスの統合 AWS CodePipeline アクションの種類との統合 ソース操作の統合 アクション統合をビルドする テストアクションの統合 デプロイ アクションの統合 承認アクションの統合 アクション統合の呼び出し AWS CodePipeline との一般的な統合 コミュニティからの例 ブログの投稿 動画 チュートリアル チュートリアル: シンプルなパイプラインを作成する (Amazon S3 バケットの場合) Amazon S3 バケットの作成 Windows Server Amazon EC2 インスタンスの作成および AWS CodeDeploy エージェントのイ ンストール AWS CodeDeploy でアプリケーションを作成する 最初のパイプラインを作成 別のステージの追加 ステージ間の移行を有効化または無効化する リソースのクリーンアップ チュートリアル: シンプルなパイプラインを作成する (AWS CodeCommit リポジトリの場合) AWS CodeCommit リポジトリの作成 コードのダウンロード コミット プッシュ Amazon EC2 インスタンスの作成および AWS CodeDeploy エージェントのインストール AWS CodeDeploy でアプリケーションを作成する 最初のパイプラインを作成 AWS CodeCommit リポジトリのコードを更新する オプションのステージ管理タスク リソースのクリーンアップ チュートリアル: 4 ステージのパイプラインを作成する 前提条件の設定 パイプラインの作成 ステージの追加 iii

4 リソースのクリーンアップ チュートリアル: CloudWatch イベント ルールをセットアップし パイプラインの状態が変わったとき に E メール通知を送信する Amazon SNS を使用して E メール通知をセットアップする AWS CodePipeline の CloudWatch イベント 通知ルールを作成する リソースのクリーンアップ チュートリアル: GitHub にプッシュされたときに Android アプリケーションをビルドしてテストする Device Farm テストを使用するように AWS CodePipeline を設定する チュートリアル: 変更が Amazon S3 に保存されたときに ios アプリケーションをビルドしてテストす る Device Farm テスト (Amazon S3 の例) を使用するように AWS CodePipeline を設定する ベストプラクティスとユースケース ベストプラクティス AWS CodePipeline リソースで使用するセキュリティのベストプラクティス AWS CodePipeline リソースで使用するモニタリングとログ記録のベストプラクティス Jenkins プラグインを使用するためのベストプラクティス AWS CodePipeline の使用方法の例 Amazon S3 AWS CodeCommit および AWS CodeDeploy で AWS CodePipeline を使用する Use AWS CodePipeline をサードパーティのアクションプロバイダー (GitHub や Jenkins) と使 用する AWS CodePipeline を AWS CodeStar と使用しコードプロジェクトでパイプラインを構築 AWS CodeBuild で AWS CodePipeline を使用してコードをコンパイル 構築 テストを実行 Amazon ECS と AWS CodePipeline を使用してクラウドにコンテナベースのアプリケーション を継続的に配信する Elastic Beanstalk と AWS CodePipeline を使用してクラウドにウェブアプリケーションを継続的 に配信する AWS Lambda と AWS CodePipeline を使用して Lambda ベースアプリケーションとサーバーレ スアプリケーションを継続的に配信する AWS CloudFormation と AWS CodePipeline を使用してクラウドにテンプレートを継続的に配信 する パイプラインの使用 AWS CodePipeline でパイプラインの実行を開始する パイプラインの自動開始に使用される変更検出方法 CloudWatch イベント ルールを使用して AWS CodeCommit パイプラインを自動的に開始する CloudWatch イベント ルールを使用して Amazon S3 パイプラインを自動的に開始する ウェブフックを使用して自動的に GitHub パイプラインを開始する 定期的なチェックを使用して自動的にパイプラインを開始する AWS CodePipeline でパイプラインを手動で開始する Amazon CloudWatch Events を使用して スケジュールに基づいてパイプラインを自動的に実行 する パイプラインの作成 コンテナベースのアプリケーションをデプロイするためのイメージ定義ファイルの作成 パイプラインの作成 (コンソールの場合) パイプラインを作成する (CLI の場合) パイプラインの編集 パイプラインの編集 (コンソールの場合) パイプラインの表示 (AWS CLI の場合) パイプラインの詳細と履歴の表示 パイプラインの詳細と履歴を表示する (コンソール) パイプラインの詳細と履歴を表示する (CLI) パイプラインの削除 パイプラインの削除 (コンソールの場合) パイプラインの削除 (CLI の場合) 実行履歴の表示 実行履歴の表示 他のアカウントからリソースを使用するパイプラインを作成する 前提条件: AWS KMS 暗号化キーの作成 iv

5 ステップ 1: アカウントポリシーおよびロールのセットアップ... ステップ 2: パイプラインの編集... アクションの操作... パイプラインのカスタムアクションの作成... カスタムアクション (CLI) の作成... カスタムアクションのジョブワーカーの作成... パイプラインにカスタムアクションを追加する... パイプラインに Lambda 関数を呼び出す... ステップ 1: パイプラインを作成する... ステップ 2: Lambda 関数を作成する... ステップ 3: AWS CodePipeline コンソールのパイプラインへの Lambda 関数の追加... ステップ4: Lambda 関数でパイプラインをテストします... ステップ 5: 次のステップ... JSON イベントの例... 追加のサンプル関数... 失敗したアクションを再試行する... 失敗したアクションを再試行する (コンソール)... 失敗したアクションを再試行する (CLI)... パイプラインの承認アクションを管理する... 手動の承認アクションに関する設定オプション... 承認アクションのセットアップおよびワークフローの概要... AWS CodePipeline の IAM ユーザーに承認権限を付与する... サービス ロールへの Amazon SNS アクセス許可の付与... 手動の承認アクションの追加... 承認アクションの承認または拒否... 手動の承認通知の JSON データ形式... ステージ移行の操作... 移行を無効化または有効化する (コンソールの場合)... 移行を無効化または有効化する (CLI の場合)... パイプラインのモニタリング... CloudWatch イベント でパイプラインの状態の変更を検出し対応する... パイプライン実行の状態変更ルールの仕組みを理解する... AWS CloudTrail での API コールのログ記録... CloudTrail での AWS CodePipeline 情報... AWS CodePipeline ログファイルエントリの概要... パイプラインの現在のソースリビジョンの詳細を表示する... パイプラインの現在のソースリビジョンの詳細を表示する (コンソールの場合)... パイプラインの現在のソースリビジョンの詳細を表示する (CLI の場合)... トラブルシューティング... パイプラインのエラー: AWS Elastic Beanstalk で設定されたパイプラインは次のようなエラーメッ セージを返します デプロイに失敗しました 提供されたロールに十分なアクセス権限がありませ ん: サービス: AmazonElasticLoadBalancing... デプロイエラー: DescribeEvents アクセス許可がない場合 AWS Elastic Beanstalk デプロイアク ションで設定したパイプラインは 失敗することなく中止します... パイプラインエラー: ソースアクションは次のような不十分な権限メッセージを返します AWS CodeCommit リポジトリ repository-name にアクセスできませんでした パイプラインの IAM ロールにリポジトリにはアクセスするための十分な権限があることを確認してください... パイプラインのエラー: Jenkins のビルドまたはテストアクションは長期間実行されるため 認証情報 や権限がないと失敗します... パイプラインのエラー: GitHub ステージ自分のソースは Git サブモジュールが含まれているが AWS CodePipeline 初期化されていません... パイプラインのエラー: 次のメッセージのパイプラインエラーが表示されます PermissionError: GitHub リポジトリにアクセスできませんでした... パイプラインのエラー: 別の AWS リージョンで作成されたバケットを使用して 1 つの AWS リージョ ンで作成されたパイプラインは コード JobFailed を使用して InternalError を返します... デプロイのエラー: WAR ファイルを含む ZIP ファイルは AWS Elastic Beanstalk に正常にデプロイさ れますが アプリケーションの URL に 404 Not Found エラーが報告されます... v

6 ZIP が外部属性を保持しないときは ソースファイルに GitHub からのファイルアクセス権限は保持さ れません... 別の問題で支援が必要ですか?... 認証 アクセスコントロール セキュリティ設定... 認証... IAM ポリシーを使用したアクセスコントロール... アクセス管理の概要... アイデンティティベースのポリシー (IAM ポリシー) を使用する... AWS CodePipeline コンソールを使用するために必要なアクセス権限... AWS CodePipeline での AWS 管理 (事前定義) ポリシー... AWS CodePipeline サービスロールの管理... お客様が管理するポリシーの例... AWS CodePipeline の権限リファレンス... セキュリティ設定... AWS CodePipeline 用として Amazon S3 に保存したアーティファクトのサーバー側の暗号化を 設定する... GitHub の認証を設定する... データベースパスワードまたはサードパーティの API キーを追跡するためにパラメータストア を使用する... コマンドラインリファレンス... パイプライン構造のリファレンス... AWS CodePipeline のパイプラインおよびステージ構造... AWS CodePipeline のアクション構造の要件... 制限... ドキュメント履歴... 以前の更新... AWS の用語集... vi

7 このガイドの手順では 新しいコンソールデザインがサポートされています 古いバージョンのコンソー ルを選択すると 古い概念が反映され 本ガイドの基本的な手順がそのまま適用されます 新しいコン ソールのヘルプにアクセスするには 情報アイコンを選択します vii

8 AWS CodePipeline の紹介ビデオ AWS CodePipeline とは AWS CodePipeline は ソフトウェアをリリースするために必要な手順のモデル化 視覚化 および自動 化に使用できる継続的な配信サービスです ソフトウェアリリースプロセスのさまざまなステージをすば やくモデル化して設定できます AWS CodePipeline は ソフトウェアの変更を継続的にリリースするた めに必要なステップを自動化します AWS CodePipeline の料金については 料金表 を参照してくだ さい トピック AWS CodePipeline の紹介ビデオ (p. 1) AWS CodePipeline の機能 (p. 1) AWS CodePipeline のクイックルック (p. 2) AWS CodePipeline の使用を開始するには (p. 3) ご意見をお待ちしております (p. 3) AWS CodePipeline の概念 (p. 4) AWS CodePipeline の紹介ビデオ この短いビデオ (3:06) では 定義したリリースプロセスモデルに基づいて コード変更が発生するたびに AWS CodePipeline がコードをビルド テスト およびデプロイする方法について説明します AWS CodePipeline の概要のビデオ AWS CodePipeline の機能 AWS CodePipeline を使用すると アプリケーションをクラウドで自動的に構築 テスト およびデプロ イすることができます 具体的な内容は以下のとおりです リリースプロセスを自動化する: AWS CodePipeline は ソースリポジトリからビルド テスト デプロ イまで リリースプロセスを完全に自動化します ソースステージ以外の任意のステージで手動承認ア クションを含めることで パイプラインを通して変更が移動しないようにすることができます 選択し たシステム上で 1 つのインスタンスまたは複数のインスタンス間で 必要に応じて自動的にリリース することができます 一貫性のあるリリースプロセスを確立する: コードを変更するたびに実行される一貫性のあるステップを 定義します AWS CodePipeline はお客様の基準に従ってリリースの各ステージを実行します 品質を向上しながら配信を高速化: リリースプロセスを自動化して 開発者がコードを段階的にテストお よびリリースし 新しい機能のリリースを顧客に迅速に提供できるようにすることができます お好みのツールを使用: 既存のソース ビルド およびデプロイツールをパイプラインに組み込むことが できます 現在 AWS CodePipeline でサポートされている AWS のサービスとサードパーティーのツー ルの完全なリストについては AWS CodePipeline による製品とサービスの統合 (p. 11) を参照し てください 進捗状況を一目で見る: パイプラインのリアルタイムステータスの確認 アラート詳細の確認 失敗した アクションの再試行 各ステージで最新のパイプライン実行で使用されたソースリビジョンの詳細の表 示 手動でのパイプラインの 再実行が可能です 1

9 AWS CodePipeline のクイックルック パイプライン履歴の詳細を表示: 開始時刻と終了時刻 継続時間 実行 ID など パイプラインの実行の 詳細を表示できます AWS CodePipeline のクイックルック 次の図は AWS CodePipeline を使用したリリースプロセスの例を示しています この例では 開発者がソースリポジトリに変更をコミットすると AWS CodePipeline は自動的に変更を 検出します これらの変更が作成され テストが設定されている場合は それらのテストが実行されま す テストが完了すると ビルドされたコードがテスト用のステージングサーバーにデプロイされます ステージングサーバーから AWS CodePipeline は統合テストや読み込みテストなどの追加テストを実行 します これらのテストが正常に完了し パイプラインに追加された手動承認アクションが承認された 後 AWS CodePipeline はテスト済みと承認済みコードを本番稼働インスタンスにデプロイします AWS CodePipeline は AWS CodeDeploy AWS Elastic Beanstalk または AWS OpsWorks Stacks を使用してアプリケーションを Amazon EC2 インスタンスにデプロイできます AWS CodePipeline は Amazon ECS を使用してコンテナベースのアプリケーションをサービスにデプロイすることもできま す 開発者は AWS CodePipeline で提供される統合ポイントを使用して ビルドサービス テストプロ バイダー その他のデプロイターゲットやシステムなど 他のツールやサービスをプラグインすることも できます パイプラインは リリースプロセスが必要とするのと同じくらいシンプルでも複雑でもかまいません 入出力アーティファクトの概要 AWS CodePipeline は 開発ツールと統合され コード変更を自動的にチェックし 継続的な配信プロセ スのすべての段階を経てビルドおよびデプロイします ステージでは パイプラインの作成時に選択した Amazon S3 アーティファクトバケットに保存されてい る入出力アーティファクトが使用されます AWS CodePipeline は ステージのアクションタイプに応じ て 入力または出力アーティファクトのファイルを圧縮して転送します たとえば ビルドアクションの 開始時に AWS CodePipeline は入力アーティファクト (ビルドするファイル) を取得し ビルドアクショ ンにアーティファクトを提供します アクションが完了すると AWS CodePipeline は出力アーティファ クト (構築済みアプリケーション) を取り出し 次のステージで使用するために出力アーティファクトバ ケットに保存します 2

10 AWS CodePipeline の使用を開始するには [Create Pipeline] ウィザードを使用してステージを設定または選択する場合 1. AWS CodePipeline は ソースリポジトリへのコミットがあると [Source] ステージからの出力アー ティファクトを渡して パイプライン実行を自動的にトリガーします 2. 前のステップの出力アーティファクトは 入力アーティファクトとして [Build] ステージに取り込まれま す [Build] ステージからの出力アーティファクトは 更新されたアプリケーションまたはコンテナに構 築された更新された Docker イメージにすることができます 3. 前のステップの出力アーティファクトは AWS クラウドのステージング環境や本稼働環境など [Deploy] ステージに入力アーティファクトとして取り込まれます アプリケーションをデプロイのフ リートにデプロイすることも ECS クラスターで実行するタスクにコンテナベースのアプリケーション をデプロイすることもできます 次の図は AWS CodePipeline のステージ間の高レベルのアーティファクトワークフローを示していま す AWS CodePipeline の使用を開始するには AWS CodePipeline の使用を開始するには 1. AWS CodePipeline の概念 (p. 4) セクションを読んで AWS CodePipeline の仕組みついて理解 します 2. AWS CodePipeline の使用開始 (p. 9) のステップに従って AWS CodePipeline の使用につい て準備します 3. AWS CodePipeline のチュートリアル (p. 27) チュートリアルのステップに従って AWS CodePipeline を試します 4. AWS CodePipeline でパイプラインを作成する (p. 113) のステップに従って 新規プロジェクトま たは既存プロジェクトに AWS CodePipeline を使用します ご意見をお待ちしております ご意見をお待ちしております お問い合わせの場合には AWS CodePipeline フォーラムをご覧くださ い 3

11 概念 AWS CodePipeline の概念 AWS CodePipeline で使用されている概念と用語 およびリリース自動化の基本概念のいくつかを理解し ていれば 自動リリースプロセスのモデリングと設定が容易になります ここでは AWS CodePipeline を使用する際に知っておかなければならないいくつかの概念を次に示します トピック AWS CodePipeline での継続的な配信と統合 (p. 4) AWS CodePipeline による (p. 4) AWS CodePipeline での継続的な配信と統合 AWS CodePipeline は ソフトウェアの構築 テスト およびデプロイを本番稼働用に自動化する継続的 な配信サービスです 継続的な配信 はリリースプロセスが自動化されるソフトウェア開発方法です すべてのソフトウェア 変更は自動的に構築され テストされ 本番稼働用にデプロイされます 最終的な本番稼働に進む前に 個人 自動テスト またはビジネスルールが最終的なプッシュがいつ行われるかを決定します 正常なす べてのソフトウェア変更は 継続的な配信ですぐに本番稼働にリリースできますが すべての変更をすぐ にリリースする必要はありません 継続的統合は チームのメンバーがバージョン管理システムを使用し 頻繁にマスターブランチなどの同 じ場所に作業を統合するソフトウェア開発のプラクティスです 各変更は 可能な限り迅速に統合エラー を検出するために構築され 検証されます 継続的な統合は ソフトウェアのリリースプロセス全体を本 番稼働まで自動化する継続的な配信と比較して コードの自動構築とテストに重点を置いています 詳細については AWS での継続的な統合と継続的な配信の実施: DevOps でのソフトウェア配信の加 速 を参照してください AWS CodePipeline による AWS CodePipeline は パイプラインによるリリースプロセスワークフローの作成と管理を支援しま す パイプラインは ソフトウェアの変更がリリースプロセスをどのように通過するかを記述するワーク フロー構造です AWS CodePipeline 制限 (p. 252) で説明したように AWS と AWS CodePipeline の制 限内で必要な数のパイプラインを作成することができます 次の図とそれに伴う説明では AWS CodePipeline 固有の用語と これらの概念が互いにどのように関係 しているかについて説明します 4

12 AWS CodePipeline による AWS CodePipeline コンソール AWS Command Line Interface (AWS CLI) AWS SDK またはこれら の組み合わせを使用して パイプラインの作成や管理ができます コンソールを使用して最初のパイプラインを作成すると AWS CodePipeline はパイプラインと同じ リージョンに Amazon S3 バケットを作成し アカウントに関連付けられたそのリージョン内のすべて のパイプラインのアイテムを格納します コンソールを使用してそのリージョンに別のパイプラインを 作成するたびに AWS CodePipeline はバケット内にそのパイプライン用のフォルダを作成します こ のフォルダを使用して 自動リリースプロセスの実行時にパイプラインのアイテムを格納します この バケットには codepipeline-region example という名前が付けられます ここで region はパイプラインを作成した AWS リージョンであり EXAMPLE はバケット名を一意にするため の 10 桁の乱数です AWS CLI を使用してパイプラインを作成する場合 そのバケットがパイプラインと同じ AWS リージョ ン内にあるかぎり そのパイプラインのアーティファクトを任意の Amazon S3 バケットに格納できま す アカウントに許可されている Amazon S3 バケットの制限を超えることが懸念される場合は これ を行うことができます リビジョンは GitHub リポジトリまたは AWS CodeCommit リポジトリへのプッシュされたコミット またはバージョン管理された Amazon S3 バケット内のファイルへの更新など AWS CodePipeline の ソースアクションで設定されたソースに対する変更です 各リビジョンは パイプラインを通して個別 に実行されます 複数のリビジョンを同じパイプラインで処理できますが 各ステージでは一度に 1 つ のリビジョンしか処理できません パイプラインのソースステージで指定された場所でリビジョンが行 われるとすぐに パイプラインを通してリビジョンが実行されます 5

13 AWS CodePipeline による パイプラインに複数のソースアクションが含まれている場合 1 つのソースアクションに対し てのみ変更が検出された場合でも すべてのアクションが再度実行されます AWS CodePipeline は ワークフローを一連のステージに分割します たとえば コードがビルドさ れ テストが実行されるビルドステージが存在する可能性があります コードの更新がランタイム環境 にデプロイされるデプロイステージもあります 同じデプロイステージの異なる環境に複数の並列デプ ロイを設定できます リリースプロセスでは 各ステージにラベルを付けることで トラッキング 管 理 レポートの改善 ( ソース ビルド ステージング など) を行うことができます パイプラインの各ステージには一意の名前があり ワークフローの一部として一連のアクションが含ま れています 1 つのステージでは 一度に 1 つのリビジョンしか処理できません リビジョンは 次の リビジョンが実行される前にステージを通過しなければなりません ステージに設定されたすべてのア クションは ステージが完了したとみなされる前に正常に完了する必要があります ステージが完了す ると パイプラインはそのステージのアクションによって作成されたリビジョンとそのアーティファク トをパイプラインの次のステージに移行します これらの移行を手動で無効にして有効にすることがで きます ステージ要件と構造の詳細については AWS CodePipeline のパイプラインおよびステージ 構造 (p. 244) を参照してください すべてのステージには少なくとも 1 つのアクションが含まれており これはアーティファクトで実行 されるタスクの一種です パイプラインのアクションは ステージ設定の定義に従い 指定された順 序で順番に または同時に実行されます たとえば デプロイステージには 1 つ以上のステージング サーバーにコードをデプロイするデプロイアクションが含まれる場合があります 1 つのアクションで ステージを設定して開始し 必要に応じてそのステージにアクションを追加することができます 詳細 については AWS CodePipeline でパイプラインを編集する (p. 122) および AWS CodePipeline のアクション構造の要件 (p. 245) を参照してください パイプラインを通してリビジョンの実行が開始されると AWS CodePipeline は パイプライン内のア クションとステージによって処理されるファイルや変更を Amazon S3 バケットにコピーします これ らのオブジェクトは アーティファクトと呼ばれ アクションのソース (入力アーティファクト) または アクションの出力 (出力アーティファクト) である可能性があります アーティファクトは 複数のアク ションによって処理することができます すべてのアクションには種類があります 種類に応じて アクションは次のいずれかまたは両方を持つ 場合があります アクションが実行されている間に消費または動作するアーティファクトである入力アーティファク ト アクションの出力である出力アーティファクト パイプラインの各出力アーティファクトには一意の名前が必要です アクションのすべての入力アー ティファクトは そのアクションがステージのアクションの直前であるか あるいはいくつか前のス テージで実行されているかどうかにかかわらず パイプラインの以前のアクションの出力アーティファ クトと一致していなければなりません 次の図は パイプラインで入力アーティファクトと出力アー ティファクトがどのように生成され 消費されるかを示しています 6

14 AWS CodePipeline による 移行は ワークフローの あるステージから次へと継続するパイプラインにおける 1 つのリビジョン の操作です AWS CodePipeline コンソールでは 移行の矢印はステージを接続してステージが発生す る順序を表示します ステージが完了すると デフォルトではリビジョンはパイプラインの次のステー ジに移行します ステージ間への移行を無効にできます これを行うと パイプラインはその移行の 前にステージ内のすべてのアクションを実行しますが その移行を有効にするまでステージまたはア クションは実行されません これは 変更がパイプライン全体で実行されないようにする簡単な方法で す 移行を有効にすると 前のステージで正常に実行された最新のリビジョンが 移行後のステージで 実行されます すべての移行が有効になっている場合 パイプラインは続けて実行します すべてのリ ビジョンは パイプラインによる正常な実行の一部としてデプロイされます (継続的なデプロイ) 一度に 1 つのリビジョンしかステージを通して実行できないため AWS CodePipeline は次のステージ が利用可能になるまで前のステージを完了したリビジョンをバッチ処理します 最新のリビジョンがス テージを通して実行されると バッチされたリビジョンは最新のリビジョンに置き換えられます 承認アクションは 権限が許可されるまでパイプラインが次のアクションに移行するのを防ぎます (た とえば 認定されたIAMユーザーからの手動承認を受けて) たとえば コードレビューが成功した後に のみパイプラインを継続したい場合や パイプラインが最終的な本番稼働ステージに移行する時間を制 御したい場合は 承認アクションを使用することができます この場合 本番稼働の直前のステージに 手動の承認アクションを追加し 変更を一般公開する準備ができたら自分で承認することができます 失敗は 正常に完了していないステージのアクションです ステージで 1 つのアクションが失敗した 場合 そのリビジョンはステージの次のアクションまたはパイプラインの次のステージに移行しませ ん 障害が発生した場合 そのリビジョンのパイプラインでの移行はそれ以上発生しません AWS CodePipeline は 以下のいずれかが発生するまでパイプラインを一時停止します 失敗したアクションを含むステージを手動で再試行します そのリビジョンのパイプラインを再度開始します ソースステージのアクションでは 別のリビジョンが作成されます パイプラインは (パイプラインのソースアクションで定義された) ソースの場所が変更されたとき ま たは手動でパイプラインを開始したときに自動的に開始されます 指定したイベントが発生したときに 自動的にパイプラインを開始するように Amazon CloudWatch でルールを設定することもできます パ イプラインが開始された後 リビジョンはパイプラインのあらゆるステージとアクションで実行されま す パイプラインビューページで 各アクションの最後の実行の詳細をパイプラインで表示できます 7

15 AWS CodePipeline による AWS CodeCommit ソースリポジトリを持つコンソールでパイプラインを作成または編集する と AWS CodePipeline は Amazon CloudWatch Events を使用してリポジトリ内の変更を検出 し 変更が発生したときにパイプラインを開始します 次の図は AWS CodePipeline コンソールのサンプルパイプラインの 2 つのステージを示しています こ れには 各ステージのアクションと 2 つのステージ間の有効な移行が含まれます 8

16 ステップ 1: AWS アカウントの作成 AWS CodePipeline の使用開始 AWS CodePipeline を初めて使用する場合は 事前に以下のステップをすべて行う必要があります トピック ステップ 1: AWS アカウントの作成 (p. 9) ステップ 2: IAM ユーザーを作成または使用する (p. 9) ステップ 3: IAM 管理ポリシーを使用して IAM ユーザーへ AWS CodePipeline のアクセス許可を割り当 てる (p. 9) 手順 4: AWS CLI をインストールする (p. 10) ステップ 5: AWS CodePipeline コンソールを開く (p. 10) 次のステップ (p. 10) ステップ 1: AWS アカウントの作成 AWS アカウントを作成します (まだ持ってない場合) そのためには にアクセ スし [サインアップ] を選択します ステップ 2: IAM ユーザーを作成または使用する IAM ユーザーを作成するか AWS アカウントに関連付けられた既存のユーザーを使用します AWS アク セスキー ID および AWS シークレットアクセスキーがその IAM ユーザーに関連付けられていることを確 認します 詳細については AWS アカウント内での IAM ユーザーの作成 を参照してください ステップ 3: IAM 管理ポリシーを使用して IAM ユー ザーへ AWS CodePipeline のアクセス許可を割り当 てる IAM ユーザーのアクセス許可を付与して AWS CodePipeline と連携する必要があります これを行う最も 簡単な方法は AWSCodePipelineFullAccess 管理ポリシーを IAM ユーザーに適用することです AWS マネジメントコンソール を使用して IAM ユーザーにアクセス許可を付与するには AWS マネジメントコンソール にサインインし IAM コンソール iam/ を開きます IAM コンソールのナビゲーションペインで [ポリシー] を選択して ポリシーのリストから AWSCodePipelineFullAccess 管理ポリシーを選択します [Policy Details] ページで [Attached Entities] タブを選択して [Attach] を選択します [ポリシーのアタッチ] ページで IAM ユーザーまたはグループの横にあるチェックボックスをオンに し [ポリシーのアタッチ] を選択します AWSCodePipelineFullAccess ポリシーでは IAM ユーザーがアクセスできるすべての AWS CodePipeline アクションおよびリソースだけでなく パイプラインのステージ (AWS 9

17 手順 4: AWS CLI をインストールする CodeDeploy Elastic Beanstalk または Amazon S3 を含むステージなど) の作成時に可能な すべてのアクションに対するアクセス許可を付与します ベストプラクティスとして 職務 遂行に必要な許可のみを個人に付与することをお勧めします IAM ユーザーがアクセス可能 な AWS CodePipeline アクションおよびリソースを制限する方法の詳細については 未使 用の AWS サービスのアクセス許可の削除 (p. 225) を参照してください 手順 4: AWS CLI をインストールする AWS CLI をインストールして設定するには 1. ローカルマシンで AWS CLI をダウンロードしてインストールします これにより コマンドライン から AWS CodePipeline とやり取りすることができます 詳細については AWS コマンドラインイ ンターフェイスの設定 を参照してください AWS CodePipeline は AWS CLI versions 以降でのみ動作します インストールし た AWS CLI のバージョンを確認するには aws --version コマンドを実行します 古い バージョンの AWS CLI を最新のバージョンにアップグレードするには AWS CLI のアン インストール の指示に従ってから AWS Command Line Interface のインストール の 指示に従います 2. 以下のように configure コマンドを使用して AWS CLI を設定します aws configure プロンプトが表示されたら AWS CodePipeline で使用する IAM ユーザーの AWS アクセスキーと AWS シークレットアクセスキーを指定します デフォルトのリージョン名の入力を求められたら パ イプラインを作成するリージョン (us-east-2 など) を指定します デフォルトの出力形式の入力を 求められたら json を指定します 以下に例を示します AWS Access Key ID [None]: Type your target AWS access key ID here, and then press Enter AWS Secret Access Key [None]: Type your target AWS secret access key here, and then press Enter Default region name [None]: Type us-east-2 here, and then press Enter Default output format [None]: Type json here, and then press Enter IAM アクセスキー シークレットキーの詳細については IAM ユーザーのアクセスキー の管理 および 認証情報を取得する方法 を参照してください AWS CodePipeline で使用できるリージョンとエンドポイントの詳細については リー ジョンとエンドポイント を参照してください ステップ 5: AWS CodePipeline コンソールを開く AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline) を開きます 次のステップ 前提条件を完了しました AWS CodePipeline の使用を開始できます AWS CodePipeline の使用を開始す る方法については AWS CodePipeline のチュートリアル (p. 27) を参照してください 10

18 AWS CodePipeline アクションの種類との統合 AWS CodePipeline による製品とサー ビスの統合 デフォルトで AWS CodePipeline は多数の AWS のサービス およびパートナーの製品やサービス と統合されています 以下のセクションの情報は 使用する製品やサービスを統合するための AWS CodePipeline の設定に役立ちます トピック AWS CodePipeline アクションの種類との統合 (p. 11) AWS CodePipeline との一般的な統合 (p. 19) コミュニティからの例 (p. 23) AWS CodePipeline アクションの種類との統合 このトピックの統合情報は AWS CodePipeline アクションの種類によって編成されます トピック ソース操作の統合 (p. 11) アクション統合をビルドする (p. 13) テストアクションの統合 (p. 15) デプロイ アクションの統合 (p. 16) 承認アクションの統合 (p. 19) アクション統合の呼び出し (p. 19) ソース操作の統合 以下の情報は AWS CodePipeline のアクションの種類別に整理されており AWS CodePipeline を使用し ている製品やサービスと統合するように設定するのに役立ちます Amazon Simple Storage Service (Amazon S3) Amazon S3 はインターネット用のストレージサービスです Amazon S3 を使用すると データの大きさにかかわらず ウェブ上のどんな場所か らでもいつでも保存 取得することができます バージョン管理された Amazon S3 バケットをコードのソースステージとして使用するように AWS CodePipeline を設定できます ステージ内のソースアクションの一部とし てバケットを使用するパイプラインを作成する前に まずバケットを作成し てバージョニングを有効にする必要があります 詳細はこちら: ステップ 1: アプリケーションの Amazon S3 バケットを作成す る (p. 28) パイプラインを作成する (CLI の場合) (p. 120) AWS CodePipeline は Amazon CloudWatch Events を使用して Amazon S3 ソースバケットの変更を検出します 各ソースアクションには対 応するイベントルールがあります このイベントルールにより ソー スに変更が発生すると 自動的にパイプラインを開始します AWS CodePipeline との一般的な統合 (p. 19) を参照してください 11

19 ソース操作の統合 AWS CodeCommit AWS CodeCommit は クラウド内のアセット (ドキュメント ソースコー ド バイナリファイルなど) を非公開で保存および管理するために使用でき る AWS によってホストされるバージョン管理サービスです コードのソー スステージとして AWS CodeCommit リポジトリ内のブランチを使用するよ うに AWS CodePipeline を設定できます ステージ内のソースアクション の一部としてブランチを使用するパイプラインを作成する前に まずリポジ トリを作成し それをローカルマシン上の作業ディレクトリに関連付ける必 要があります AWS CodeCommit リポジトリに接続するには 新しいパイ プラインを作成するか 既存のパイプラインを編集します 詳細はこちら: チュートリアル: シンプルなパイプラインを作成する (AWS CodeCommit リポジトリの場合) (p. 44) AWS での DevOps 入門ガイド AWS CodePipeline を使用して AWS CodeCommit リポジトリのソースコードを AWS CodeDeploy Elastic Beanstalk および AWS OpsWorks のデプロイターゲットに継続的にデリ バリーおよびデプロイする方法について説明します AWS CodePipeline は Amazon CloudWatch Events を利用して パイプ ラインのソースとして使用される AWS CodeCommit リポジトリの変更 を検出します 各ソースアクションには対応するイベントルールがあり ます このイベントルールにより リポジトリに変更が発生すると 自 動的にパイプラインを開始します AWS CodePipeline との一般的な統 合 (p. 19) を参照してください 12

20 アクション統合をビルドする GitHub コードのソースステージとして GitHub リポジトリを使用するように AWS CodePipeline を設定できます これ以前に GitHub アカウントと少なくとも 1 つの GitHub リポジトリを作成しておく必要があります GitHub リポジト リに接続するには 新しいパイプラインを作成するか 既存のパイプライン を編集します GitHub Enterprise との AWS CodePipeline の統合はサポートされて いません GitHub リポジトリを最初にパイプラインに追加すると リポジトリへの AWS CodePipeline アクセスを承認するように要求されます GitHub と 統合するために AWS CodePipeline はパイプラインに OAuth アプリケー ションを作成します コンソールでパイプラインを作成または更新した場 合 AWS CodePipeline はリポジトリで変更が生じたときにパイプライン を開始する GitHub ウェブフックを作成します トークンとウェブフックに は 以下の GitHub スコープが必要となります repo スコープ これは パブリックおよびプライベートリポジトリから パイプラインにアーティファクトを読み込んでプルする完全制御に使用さ れます admin:repo_hook スコープ これは リポジトリフックの完全制御に 使用されます GitHub のスコープに関する詳細については GitHub 開発者 API リファレ ンス を参照してください AWS CodePipeline のアクセスは その GitHub アカウントがアクセスで きるすべてのリポジトリに対して設定されます 現在は個々のリポジトリ 用に設定することはできません [設定] [アプリケーション] を選択し 次に [認定アプリケーション] で認可されたアプリケーションのリスト で AWS CodePipeline を見つけ [取り消し] を選択して このアクセス を GitHub から取り消すことができます アクセスを取り消すと 直ちに GitHub アカウントへのアクセス用に設定された GitHub リポジトリに AWS CodePipeline がアクセスできなくなります AWS CodePipeline による特定のリポジトリセットへのアクセスを制限する 場合は GitHub アカウントを作成し そのアカウントに AWS CodePipeline と統合するリポジトリのみへのアクセスを許可し AWS CodePipeline を設 定するときにそのアカウントを使用して パイプラインのソースステージに GitHub リポジトリを使用するようにします 詳細はこちら: チュートリアル: 4 ステージのパイプラインを作成する (p. 56) ウェブフックを使用して自動的に GitHub パイプラインを開始す る (p. 105) アクション統合をビルドする AWS CodeBuild AWS CodeBuild は クラウド内でソースコードをコンパイルし 単体テス トを実行して デプロイ可能なアーティファクトを生成する完全マネージド 型のビルドサービスです 13

21 アクション統合をビルドする AWS CodeBuild を ビルドアクションとしてパイプラインのビルドス テージに追加できます 既存のビルドプロジェクトを使用するか AWS CodePipeline コンソールで作成することができます その後 パイプライ ンの一部として ビルドプロジェクトの出力をデプロイできます AWS CodeBuild は ビルド出力の有無にかかわらず テストアク ションとしてパイプラインに含めることもできます 詳細はこちら: AWS CodeBuild とは? AWS CodeBuild で AWS CodePipeline を使用してコードをテストし ビルドを実行する の AWS CodeBuild ビルドアクションをパイプライ ンに追加する AWS CodeBuild でビルドプロジェクトを操作する AWS CodeBuild 完全マネージド型ビルドサービス CloudBees パイプラインの 1 つ以上のアクションで CloudBees を使用してコードをビ ルドまたはテストするように AWS CodePipeline を設定できます 詳細はこちら: ビルドとテストのジョブを実行するための CloudBees Jenkins プラット フォームと AWS CodePipeline の統合に関する CloudBees のドキュメン ト Jenkins パイプラインの 1 つ以上のアクションで Jenkins CI を使用してコードをビ ルドまたはテストするように AWS CodePipeline を設定できます これ以前 に Jenkins プロジェクトを作成し そのプロジェクト用に Jenkins の AWS CodePipeline プラグイン をインストールして設定しておく必要がありま す Jenkins プロジェクトに接続するには 新しいパイプラインを作成する か 既存のパイプラインを編集します Jenkinsのアクセスは プロジェクトベースで設定されます AWS CodePipeline で使用するすべての Jenkins インスタンスに Jenkins の AWS CodePipeline プラグイン をインストールする必要があります さらに Jenkins プロジェクトへの AWS CodePipeline アクセスを設定 する必要があります HTTPS/SSL 接続のみを受け入れるように設定し て Jenkins プロジェクトを安全にする必要があります Jenkins プロジェ クトが Amazon EC2 インスタンスにインストールされている場合 AWS 認 証情報を提供するには 各インスタンスに AWS CLI をインストールし そ のインスタンスの AWS プロファイルで AWS CodePipeline と Jenkins と の接続に使用する IAM ユーザープロファイルと AWS 認証情報を設定してく ださい Jenkins のウェブインターフェイスで それらの認証情報を追加し たり 保存したりしないでください 詳細はこちら: Jenkins のアクセス チュートリアル: 4 ステージのパイプラインを作成する (p. 56) 14

22 テストアクションの統合 Solano CI パイプラインの 1 つ以上のアクションで Solano Labs を使用してコードをビ ルドしてテストするように AWS CodePipeline を設定できます 詳細はこちら: AWS CodePipeline で Solano CI を使用するための Solano Labs のドキュ メント TeamCity パイプラインの 1 つ以上のアクションで TeamCity を使用してコードをビル ドまたはテストするように AWS CodePipeline を設定できます 詳細はこちら: AWS CodePipeline の TeamCity プラグイン AWS と TeamCity でのエンドツーエンドの継続的デリバリーおよびデプ ロイパイプラインの構築 テストアクションの統合 AWS CodeBuild AWS CodeBuild は クラウド内でソースコードをコンパイルし 単体テス トを実行して デプロイ可能なアーティファクトを生成する完全マネージド 型のビルドサービスです AWS CodeBuild をテストアクションとしてパイプラインに追加して ビル ド出力アーティファクトの有無にかかわらず コードに対してユニットテス トを実行することができます テストアクションの出力アーティファクトを 生成すると パイプラインの一部としてデプロイできます 既存のビルドプ ロジェクトを使用するか AWS CodePipeline コンソールで作成することが できます AWS CodeBuild は 必須ビルド出力アーティファクトを持つビル ドアクションとしてパイプラインに含めることもできます 詳細はこちら: AWS CodeBuild とは? AWS CodeBuild で AWS CodePipeline を使用してコードをテストし ビルドを実行する の AWS CodeBuild テストアクションをパイプライ ンに追加する AWS Device Farm AWS Device Farm は アマゾン ウェブ サービス (AWS) によりホストされ ている実際の物理的な電話やタブレットで Android や ios およびウェ ブアプリケーションをテストしてやり取りできるアプリケーションテスト サービスです パイプラインの 1 つ以上のアクションで AWS Device Farm を使用してコードをテストするように AWS CodePipeline を設定できま す AWS Device Farm により 独自のテストをアップロードしたり 組 み込みのスクリプトフリーの互換性テストを使用したりできます テス トは自動的に並列実行されるため テストは複数のデバイスで数分のうち に開始されます 高レベルの結果 低レベルのログ ピクセルからピクセ ルへのスクリーンショット パフォーマンスデータを含むテストレポート は テストが完了すると更新されます AWS Device Farm は ネイティ ブかつハイブリッドな Android ios および Fire OS アプリケーション (PhoneGap Titanium Xamarin などのフレームワークで作成されたアプリ ケーション) のテストをサポートしています Android アプリのリモートア 15

23 デプロイ アクションの統合 クセスをサポートしているため テストデバイスと直接やりとりすることが できます 詳細はこちら: AWS Device Farm とは? AWS CodePipeline テストステージでの AWS Device Farm の使用 BlazeMeter パイプラインの 1 つ以上のアクションで BlazeMeter を使用してコードをビ ルドしてテストするように AWS CodePipeline を設定できます 詳細はこちら: AWS CodePipeline でテストするための BlazeMeter のドキュメント Ghost Inspector パイプラインの 1 つ以上のアクションで Ghost Inspector を使用してコード をビルドしてテストするように AWS CodePipeline を設定できます 詳細はこちら: AWS CodePipeline とのサービス統合のための Ghost Inspector のドキュ メント HPE StormRunner Load パイプラインの 1 つ以上のアクションで HPE StormRunner Load を使用し てコードをビルドしてテストするように AWS CodePipeline を設定できま す 詳細はこちら: AWS CodePipeline との統合のための HPE StormRunner Load のドキュメ ント Nouvola パイプラインの 1 つ以上のアクションで Nouvola を使用してコードをビル ドしてテストするように AWS CodePipeline を設定できます 詳細はこちら: AWS CodePipeline の Nouvola プラグイン Runscope パイプラインの 1 つ以上のアクションで Runscope を使用してコードをビル ドしてテストするように AWS CodePipeline を設定できます 詳細はこちら: AWS CodePipeline との統合のための Runscope ドキュメント デプロイ アクションの統合 AWS CloudFormation AWS CloudFormation では 開発者とシステム管理者は AWS リソースの プロビジョニングおよび更新用のテンプレートを使用して 関連する一連の リソースを簡単に作成および管理できます AWS CloudFormation のサンプ ルテンプレートを使用するか 独自のテンプレートを作成して アプリケー ションの実行に必要な AWS リソース および関連する依存関係や実行時パ ラメータを定義できます AWS サーバーレスアプリケーションモデル (AWS SAM) は AWS CloudFormation を拡張して サーバーレスアプリケーションを定義してデ 16

24 デプロイ アクションの統合 プロイするための簡単な方法を提供します AWS SAM は Amazon API Gateway API AWS Lambda 関数 および Amazon DynamoDB テーブルを サポートしています AWS CodePipeline を AWS CloudFormation および AWS サーバーレスアプリケーションモデルと共に使用して サーバーレス アプリケーションの継続的デリバリーが可能です デプロイプロバイダーとして AWS CloudFormation を使用するパイプラ インにアクションを追加できます デプロイプロバイダーとしての AWS CloudFormation の一意のロールにより パイプライン実行の一環とし て AWS CloudFormation スタックと変更セットに対してアクションを実 行できます AWS CloudFormation は パイプラインの実行時にスタッ クと変更セットを作成 更新 置換 削除できます その結果 AWS CloudFormation テンプレートおよびパラメータ定義で指定した仕様に従っ て AWS およびカスタムリソースをパイプライン実行中に自動的に作成 プロビジョニング 更新 または終了することができます 詳細はこちら: AWS CodePipeline による継続的デリバリー AWS CodePipeline を使用 して AWS CloudFormation の継続的デリバリーワークフローを構築する方 法について説明します Lambda ベースのアプリケーションのデプロイの自動化 - AWS サー バーレスアプリケーションモデルと AWS CloudFormation を使用し て Lambda ベースのアプリケーションの継続的デリバリーワークフロー を構築する方法について説明します AWS CodeDeploy AWS CodeDeploy は Amazon EC2 インスタンス オンプレミスインス タンス または両方へのアプリケーションのデプロイを調整します AWS CodeDeploy を使用してコードをデプロイするように AWS CodePipeline を設定できます パイプラインの作成前または [パイプラインの作成] ウィザードの使用時に ステージのデプロイアクションに使用する AWS CodeDeploy アプリケーション デプロイ およびデプロイグループを作成 できます 詳細はこちら: ステップ 4: AWS CodeDeploy でアプリケーションを作成する (p. 32) Pipeline Starter Kit による AWS での継続的デリバリーの確認 Amazon Elastic Container Amazon ECS は スケーラビリティに優れた高性能なコンテナ管理サービ Service スで AWS クラウド上でコンテナベースのアプリケーションを実行する ことができます パイプラインを作成すると デプロイプロバイダとして Amazon ECS を選択できます ソースコントロールリポジトリのコードを 変更すると パイプラインが新しい Docker イメージを作成し コンテナレ ジストリにプッシュし 更新されたイメージを Amazon ECS にデプロイし ます 詳細はこちら: Amazon ECS とは チュートリアル: AWS CodePipeline による継続的デプロイ AWS CodePipeline でパイプラインを作成する (p. 113) 17

25 デプロイ アクションの統合 AWS Elastic Beanstalk Elastic Beanstalk は Java.NET PHP Node.js Python Ruby Go Docker で開発され たウェブアプリケーションとサービスを Apache Nginx Passenger IIS などの一般的なサーバーにデプロイしてスケーリングする使いやすいサー ビスです Elastic Beanstalk を使用してコードをデプロイするように AWS CodePipeline を設定できます パイプラインの作成前または [パイプライン の作成] ウィザードの使用時に ステージのデプロイアクションに使用する Elastic Beanstalk アプリケーションおよび環境を作成できます 詳細はこちら: Elastic Beanstalk チュートリアル AWS CodePipeline でパイプラインを作成する (p. 113) AWS OpsWorks Stacks 設定管理サービスである AWS OpsWorks を使用すると お客様は Chef を 使用して あらゆる種類とサイズのアプリケーションを簡単に設定したり運 用したりできます AWS OpsWorks Stacks を使用すると, パッケージのイ ンストール ソフトウェア設定およびストレージなどのリソースを含む 各 コンポーネントのアプリケーションのアーキテクチャおよび仕様を定義でき ます AWS OpsWorks Stacks を使用して AWS OpsWorks で作成された カスタム Chef クックブックおよびアプリケーションと共にコードをデプロ イするように AWS CodePipeline を設定できます カスタム Chef クックブック AWS OpsWorks は Chef クックブックを 使用して パッケージのインストールと設定 アプリケーションのデプロ イなどのタスクを処理します アプリケーション AWS OpsWorks アプリケーションは アプリケー ションサーバーで実行するコードで構成されます アプリケーションコー ドは Amazon S3 バケットなどのリポジトリに格納されています パイプラインを作成する前に使用する AWS OpsWorks スタックとレイヤー を作成します パイプラインの作成前または [パイプラインの作成] ウィザー ドの使用時に ステージのデプロイアクションに使用する AWS OpsWorks アプリケーションを作成できます AWS OpsWorks の AWS CodePipeline サポートは 米国東部 バージニア 北部 リージョン (us-east-1) でのみ利用可能です 詳細はこちら: AWS CodePipeline を AWS OpsWorks Stacks に使用する クックブックとレシピ AWS OpsWorks アプリケーション XebiaLabs パイプラインの 1 つ以上のアクションで XebiaLabs を使用してコードをデ プロイするように AWS CodePipeline を設定できます 詳細はこちら: AWS CodePipeline での XL デプロイの使用に関する XebiaLabs のドキュ メント 18

26 承認アクションの統合 承認アクションの統合 Amazon Simple Notification Service Amazon SNS は 高速かつ柔軟な完全マネージド型のプッシュ通知サービ スです このサービスを使用すると 個々のメッセージを送信したり 多数 の受信者にメッセージをファンアウトしたりできます Amazon SNS によ り 簡単かつコスト効率の高い方法で モバイルデバイスユーザーおよび E メール受信者にプッシュ通知を送信したり 他の分散サービスにメッセージ を送信したりできます AWS CodePipeline で手動承認リクエストを作成する場合は 必要に応じ て Amazon SNS にトピックを発行して サブスクライブしているすべての IAM ユーザーに承認アクションが承認または却下する準備ができたことが通 知されます 詳細はこちら: Amazon SNS とは? AWS CodePipeline サービスロールへの Amazon SNS アクセス許可の付 与 (p. 178) アクション統合の呼び出し AWS Lambda Lambda を使用すると サーバーをプロビジョニングまたは管理しなくても コードを実行できます Lambda 関数を使用してパイプラインに柔軟性と機 能性を追加するように AWS CodePipeline を設定できます パイプラインの 作成前または [パイプラインの作成] ウィザードの使用時に ステージのアク ションとして追加する Lambda 関数を作成できます 詳細はこちら: AWS CodePipeline で パイプラインに AWS Lambda 関数を呼び出 す (p. 156) AWS CodePipeline との一般的な統合 以下の AWS サービス統合は AWS CodePipeline アクションの種類に基づいていません AWS CloudTrail CloudTrail は AWS アカウントによってまたは代わって行われた AWS API コールと関連イベントをキャプチャし 指定した Amazon S3 バケットにロ グファイルを配信します AWS CodePipeline コンソールからの AWS CLI での AWS CodePipeline からの さらに AWS CodePipeline API からの API コールをキャプチャするように CloudTrail を設定できます 詳細はこちら: AWS CodePipeline での AWS CloudTrail API コールのログ記録 (p. 197) Amazon CloudWatch Amazon CloudWatch は AWS リソースをモニタリングします 詳細はこちら: Amazon CloudWatch とは? 19

27 AWS CodePipeline との一般的な統合 Amazon CloudWatch Events Amazon CloudWatch Events は 変更が発生したときに 定義したルール に基づいて AWS サービスの変更を検出し 指定された 1 つ以上の AWS の サービスでアクションを呼び出すウェブサービスです 何かが変更されたときに自動的にパイプライン実行を開始する Amazon CloudWatch Events で設定されたルールのターゲットとして AWS CodePipeline を設定できます これにより 別のサービスが変更された ときに自動的にパイプラインが開始されるように設定されます 詳細はこちら: Amazon CloudWatch Events とは? AWS CodePipeline でパイプラインの実行を開始する (p. 90). CloudWatch イベント ルールを使用して AWS CodeCommit パイプライ ンを自動的に開始する (p. 92) パイプラインの状態が変更されたときに通知を受け取る Amazon CloudWatch Events ルールを設定して パイプライン ステージ または アクションの実行状態の変更を検出して対応することができます 詳細はこちら: Amazon CloudWatch Events でパイプラインの状態の変更を検出し対応 する (p. 189) チュートリアル: CloudWatch イベント ルールをセットアップし パイ プラインの状態が変わったときに E メール通知を送信する (p. 64) 20

28 AWS CodePipeline との一般的な統合 AWS Key Management Service AWS KMS は データの暗号化に使用される暗号化キーの作成と管理を容易 にするマネージド型サービスです デフォルトでは AWS CodePipeline は AWS KMS を使用して Amazon S3 バケットに保存されているパイプライ ンのアーティファクトを暗号化します 詳細はこちら: 21

29 AWS CodePipeline との一般的な統合 Amazon S3 アーティファクトのサーバー側の暗号化を設定するには 次の 2 つの方法があります AWS CodePipeline は [パイプラインの作成] ウィザードを使用して パイプラインを作成すると Amazon S3 アーティファクトバケット とデフォルトの AWS が管理する SSE-KMS 暗号化キーを作成しま す マスターキーはオブジェクトデータとともに暗号化され AWS によって管理されます 独自のカスタマー管理 SSE-KMS キーを作成して管理することができ ます デフォルトの Amazon S3 キーを使用している場合 この AWS 管理 キーを変更または削除することはできません AWS KMS で顧客管理 キーを使用して Amazon S3 バケット内のアーティファクトを暗号化ま たは復号化する場合は 必要に応じてこのキーを変更または回転できま す Amazon S3 は バケットに格納されているすべてのオブジェクトに対 してサーバー側の暗号化が必要な場合に使用できるバケットポリシーを サポートしています たとえば SSE-KMS を使用したサーバー側の暗 号化を要求する x-amz-server-side-encryption ヘッダーがリク エストに含まれていない場合 次のバケットポリシーはすべてのユー ザーに対し オブジェクト (s3:putobject) をアップロードするアク セス許可を拒否します "Version": " ", "Id": "SSEAndSSLPolicy", "Statement": [ "Sid": "DenyUnEncryptedObjectUploads", "Effect": "Deny", "Principal": "*", "Action": "s3:putobject", "Resource": "arn:aws:s3:::codepipeline-uswest /*", "Condition": "StringNotEquals": "s3:x-amz-server-side-encryption": "aws:kms" API バージョン 22,

30 コミュニティからの例 (p. 237) コミュニティからの例 以下のセクションは ブログの投稿や記事 およびコミュニティで提供されている例へのリンクです これらのリンクは 情報提供のみを目的として提供されており 包括的なリストまたはコンテン ツの例の内容を推奨するものではありません AWS は 外部コンテンツの内容または正確性につ いて責任を負いません トピック 統合の例: ブログの投稿 (p. 23) 統合の例: 動画 (p. 25) 統合の例: ブログの投稿 AWS CodePipeline を使用した DevSecOps の実装 予防的および発見的なセキュリティ制御を自動化するために AWS CodePipeline で CI/CD パイプライ ンを使用する方法について説明します この記事では パイプラインを使用して簡単なセキュリティグ ループを作成し ソース テスト および本番稼働ステージでセキュリティチェックを実行して AWS アカウントのセキュリティ状態を改善する方法について説明します 2017年３月発行 AWS CodePipeline AWS CodeBuild Amazon ECR および AWS CloudFormation を使用した Amazon ECS への継続的なデプロイ Amazon Elastic Container Service (Amazon ECS) への継続的なデプロイパイプラインを作成する方法に ついて説明します アプリケーションは AWS CodePipeline AWS CodeBuild Amazon ECR およ び AWS CloudFormation を使用して Docker コンテナとして配信されます サンプル AWS CloudFormation テンプレートをダウンロードし GitHub の ECS リファレンスアー キテクチャ: 継続的デプロイ リポジトリから独自の継続的デプロイパイプラインを作成するための使 い方をダウンロードしてください 2017 年 1 月投稿 サーバーレスアプリケーションの継続的なデプロイ AWS サービスのコレクションを使用して サーバーレスアプリケーション用の継続的なデプロイパイプ ラインを作成する方法について説明します サーバーレスアプリケーションモデル (SAM) を使用してア プリケーションとそのリソースを定義し AWS CodePipeline はアプリケーションのデプロイを調整し ます Gin フレームワークと API ゲートウェイプロキシシムでの実行で書かれたサンプルアプリケーション の表示 発行日 2016年12月 Git と AWS CodePipeline の統合 GitHub Enterprise Bitbucket GitLab などの webhooks 機能をサポートする Git サーバーと AWS CodePipeline を統合する方法について説明します 2016 年 11 月公開 AWS CodePipeline と Dynatrace を使用した DevOps デプロイのスケーリング 23

31 ブログの投稿 Dynatrace のモニタリングソリューションを使用して AWS CodePipeline のパイプラインを拡張し コードがコミットされる前にテストの実行を自動的に分析し 最適なリードタイムを維持する方法につ いて説明します 2016 年 11 月公開 CloudFormation と CodeCommit を使用して AWS CodePipeline で AWS Elastic Beanstalk 用のパイプラ インを作成する AWS Elastic Beanstalk のアプリケーションの AWS CodePipeline パイプラインで継続的デリバリーを 実装する方法について説明します すべての AWS リソースは AWS CloudFormation テンプレートを 使用して自動的にプロビジョニングされます このチュートリアルには AWS CodeCommit と AWS Identity and Access Management (IAM) も取り入れられています 2016 年 5 月投稿 AWS CloudFormation における AWS CodeCommit と AWS CodePipeline の自動化 AWS CloudFormation を使用して AWS CodeCommit AWS CodePipeline AWS CodeDeploy およ び AWS Identity and Access Management を使用する継続的デリバリーパイプライン用の AWS リソー スのプロビジョニングを自動化します 2016 年 4 月公開 AWS CodePipeline でクロスアカウントパイプラインを作成する AWS Identity and Access Management を使用して AWS CodePipeline のパイプラインへのクロスアカ ウントアクセスのプロビジョニングを自動化する方法について説明します 例が AWS CloudFormation テンプレートに含まれます 2016年３月発行 ASP.NET コアパート 2 の学習: 継続的な配信 AWS CodeDeploy と AWS CodePipeline を使用して ASP.NET Core アプリケーション用の完全な継続 的デリバリーシステムを作成する方法について説明します 2016年３月発行 AWS CodePipeline コンソールを使用してパイプラインを作成する AWS CodePipeline の チュートリアル: 4 ステージのパイプラインを作成する (p. 56) に基づく チュートリアルで AWS CodePipeline コンソールを使用して 2 ステージパイプラインを作成する方法に ついて説明します 2016年３月発行 AWS Lambda での AWS CodePipeline パイプラインの模擬表示 パイプラインが動作する前に AWS CodePipeline ソフトウェア配信プロセスのアクションやステージ を設計する際に そのアクションやステージを視覚化できる Lambda 関数を呼び出す方法について説明 します パイプライン構造を設計するときに Lambda 関数を使用して パイプラインが正常に完了す るかどうかをテストできます 2016 年 2 月投稿 AWS CloudFormation を使用した AWS CodePipeline での AWS Lambda 関数の実行 ユーザーガイドタスク AWS CodePipeline で パイプラインに AWS Lambda 関数を呼び出す (p. 156) で使用されるすべての AWS リソースをプロビジョニングする AWS CloudFormation スタックを作成す る方法について説明します 2016 年 2 月投稿 AWS CloudFormation でのカスタム AWS CodePipeline アクションのプロビジョニング 24

32 動画 AWS CloudFormation を使用して AWS CodePipeline でカスタムアクションをプロビジョニングする方 法について説明します 2016 年 1 月投稿 AWS CloudFormation を使用した AWS CodePipeline のプロビジョニング AWS CloudFormation を使用して AWS CodePipeline に基本的な継続的デリバリーパイプラインをプロ ビジョニングする方法について説明します 発行日 2015年12月 AWS CodePipeline Jenkins Elastic Beanstalk を使用した AWS での継続的デプロイの構築 GitHub AWS CodePipeline Jenkins Elastic Beanstalk を使用して コードを変更するたびに自動的 に更新されるウェブアプリケーションのデプロイパイプラインを作成する方法について説明します 発行日 2015年12月 AWS CodePipeline Elastic Beanstalk Solano Labs を使用した PHP アプリケーションの継続的デリバ リー AWS CodePipeline で Solano CI と PHPUnit を使用して PHP アプリケーションをテストし アプリ ケーションを Elastic Beanstalk にデプロイする方法について説明します 発行日 2015年12月 AWS CodePipeline と BlazeMeter を使用した継続的デリバリーにおけるパフォーマンステスト BlazeMeter のネイティブ AWS CodePipeline 統合により AWS CodePipeline 配信ワークフローの適切 な場所に自動読み込みテストを挿入する方法について説明します 2015 年 9 月公開 カスタムアクションと AWS Lambda を使用した AWS CodePipeline から AWS OpsWorks へのデプロイ AWS CodePipeline を使用して AWS OpsWorks にデプロイするためのパイプラインと AWS Lambda 関 数の設定方法について説明します 2015年７月発行 自動配信受け入れテスト Nirvana: AWS CodePipeline CloudWatch BlazeMeter を活用 AWS CodePipeline CloudWatch BlazeMeter を使用して継続的デリバリーワークフローを作成するこ とで リリースまでの時間を短縮し リリース中の開発者のテストカバレッジを向上させる方法につい て説明します 2015年７月発行 統合の例: 動画 AWS CodePipeline コンソールを使用してパイプラインを作成する AWS CodePipeline コンソールで AWS CodeDeploy と Amazon S3 を使用するパイプラインを作成する 方法について説明します AWS CodePipeline コンソールを使用してパイプラインを作成する 2016年３月発行 所要時間: 8:53 Solano CI および AWS CodePipeline 25

33 動画 Solano CI を使用して デモの設定と AWS CodePipeline の正常な実行を表示します Solano CI および AWS CodePipeline 2015 年 11 月公開 所要時間: 3:07 26

34 チュートリアル: シンプルなパイプライン を作成する (Amazon S3 バケットの場合) AWS CodePipeline のチュートリアル AWS CodePipeline の使用開始 (p. 9) のステップが完了したら このユーザーガイドのチュートリアル のいずれかを実行することができます AWS CodeDeploy を使用するパイプラインを作成 して サンプルアプリケーションを Amazon S3 バケットから Amazon Linux を実行中の Amazon EC2 インスタンスにデプロイできます チュートリアル: シンプルなパイプラインを作成 する (Amazon S3 バケットの場合) (p. 27) を 参照してください AWS CodeDeploy を使用するパイプラインを 作成して サンプルアプリケーションを AWS CodeCommit リポジトリから Amazon Linux を実 行中の Amazon EC2 インスタンスにデプロイしま す チュートリアル: シンプルなパイプラインを 作成する (AWS CodeCommit リポジトリの場 合) (p. 44) を参照してください チュートリアル: 4 ステージのパイプラインを作成する (p. 56) では GitHub リポジトリか らソースコードを取得するパイプラインを作成する方法を示します また Jenkins を使用して ソースコードをビルドおよびテストし AWS CodeDeploy を使用して ビルドおよびテストした コードを Amazon Linux または Microsoft Windows Server を実行している Amazon EC2 インスタ ンスにデプロイします このチュートリアルは ウォークスルーの範囲であるコンセプトでビル ドされているため まずいずれかを完了することをお勧めします 必要なリソースをすべて設定せずに AWS CodeDeploy を使用して AWS CodePipeline を進める場合は パイプラインスタートキットを使用して AWS の継続的な配信を確認す る を参照してください スターターキットを使用して 数ステップで サンプルアプリケー ションをビルドしてデプロイする完全なパイプラインをセットアップできます その際 AWS CloudFormation テンプレートを使用して 米国東部 バージニア北部 リージョンのパイプライ ンとそのリソースをすべて作成します 他のユーザーガイドにある以下のチュートリアルおよびウォークスルーでは 他の AWS サービスをパイ プラインに統合するガイダンスを提供しています AWS CodeBuild ユーザーガイド の AWS CodeBuild を使用するパイプラインを作成する AWS OpsWorks ユーザーガイド の AWS OpsWorks Stacks を使用した AWS CodePipeline の使用 AWS CloudFormation ユーザーガイド のAWS CodePipeline を使用した継続的な配信 AWS Elastic Beanstalk 開発者ガイド の Elastic Beanstalk のウォークスルー DevOps 用 AWS 入門ガイド Pipeline Starter Kit による AWS での継続的デリバリーの確認 AWS CodePipeline を使用した継続的なデプロイのパイプラインのセットアップ チュートリアル: シンプルなパイプラインを作成す る (Amazon S3 バケットの場合) パイプラインを最も簡単に作成するには AWS CodePipeline コンソールでパイプラインの作成ウィザー ドを使用します 27

35 Amazon S3 バケットの作成 このチュートリアルでは バージョニングされた Amazon S3 バケットおよび AWS CodeDeploy を使用し てサンプルアプリケーションをリリースする 2 ステージのパイプラインを作成します Amazon S3 ソースのパイプラインの場合 Amazon CloudWatch Events ルールがソースの変更 を検出し 変更発生時にパイプラインを開始します コンソールを使用してパイプラインを作 成または変更すると ルールおよびすべての関連付けられるリソースが作成されます CLI ま たは AWS CloudFormation で Amazon S3 パイプラインを作成または変更する場合は Amazon CloudWatch Events ルール IAM ロール および AWS CloudTrail 証跡を手動で作成する必要が あります このシンプルなパイプラインを作成したら 別のステージを追加し ステージ間の移行を無効化または有 効化します Important AWS CodePipeline の使用開始 (p. 9) のステップに加えて 起動後に Amazon EC2 イン スタンスへの接続に使用する Amazon EC2 インスタンスのキーペアを作成する必要がありま す Amazon EC2 インスタンスキーペアを作成するには Amazon EC2 を使用してキーペアを 作成する の手順に従います お探しのものではありませんか コードリポジトリとして AWS CodeCommit ブランチを使用してシン プルなパイプラインを作成する方法については チュートリアル: シンプルなパイプラインを作成する (AWS CodeCommit リポジトリの場合) (p. 44) を参照してください 開始する前に AWS CodePipeline の使用開始 (p. 9) の前提条件を完了する必要があります トピック ステップ 1: アプリケーションの Amazon S3 バケットを作成する (p. 28) ステップ 3: Amazon EC2 Windows インスタンスの作成および AWS CodeDeploy エージェントのイン ストール (p. 30) ステップ 4: AWS CodeDeploy でアプリケーションを作成する (p. 32) ステップ 5: AWS CodePipeline で最初のパイプラインを作成する (p. 33) ステップ 6: 別のステージをパイプラインに追加する (p. 36) ステップ 5: AWS CodePipeline のステージ間の移行を有効化または無効化する (p. 42) ステップ 6: リソースをクリーンアップする (p. 43) ステップ 1: アプリケーションの Amazon S3 バケット を作成する ソースファイルまたはアプリケーションをバージョニングされた場所に保存します このチュートリアル では サンプルアプリケーション用に Amazon S3 バケットを作成し そのバケットでバージョニングを 有効にします バージョニングを有効化したら サンプルアプリケーションをそのバケットにコピーしま す 既存の Amazon S3 バケットを使用する方法については バケットのバージョニングの有効化 を参照 してください サンプルアプリケーションをそのバケットにコピーし ステップ 4: AWS CodeDeploy でアプリケーションを作成する (p. 32) のステップに進みます Amazon S3 バケットではなく GitHub リポジトリを使用する場合は サンプルアプリケーションをそのリ ポジトリにコピーして ステップ 4: AWS CodeDeploy でアプリケーションを作成する (p. 32) の手 順に進みます 28

36 Amazon S3 バケットの作成 Amazon S3 バケットを作成するには 1. AWS マネジメントコンソール にサインインし Amazon S3 コンソール ( console.aws.amazon.com/s3/) を開きます 2. [Create bucket] を選択します 3. [Bucket Name (バケット名)] に バケットの名前 (例: awscodepipeline-demobucket-exampledate) を入力します Amazon S3 内のすべてのバケット名は一意になる必要があるため 例に示す名前ではなく 独自のバケット名を使用してください 例に示す名前は 日付を追加するだけでも変更でき ます このチュートリアルの残りの部分で必要となるため この名前を書き留めます [Region (リージョン)] で パイプラインを作成するリージョン ([米国西部 (オレゴン)] など) を選択し てから [Next (次へ)] を選択します 4. [バージョニング] で [同じバケット内でオブジェクトの複数のバージョンを保持します] を選択し [Next (次へ)] を選択します バージョニングが有効になったら Amazon S3 によって各オブジェクトのすべてのバージョンがバ ケットに保存されます 5. [バージョニング] で オブジェクトに対するアカウントの読み取り/書き込みアクセスを許可するデ フォルトのアクセス許可を受け入れ [Next (次へ)] を選択します Amazon S3 バケットおよびオブ ジェクトへのアクセス権限の詳細については ポリシーでのアクセス権限の指定 を参照してくだ さい 6. [Create bucket] を選択します 7. 次に GitHub リポジトリからサンプルをダウンロードし ローカルコンピュータのフォルダーまたは ディレクトリに保存します Important GitHub リポジトリでは [Clone or download] や [Download ZIP] のボタンを使用しないでくだ さい 使用すると AWS CodeDeploy で機能しない入れ子になったフォルダー構造が作成さ れます a. サンプルをホストする GitHub リポジトリを開きます AWS CodeDeploy を使用して Amazon Linux インスタンスにデプロイする場合 のサンプルを 使用します AWS CodeDeploy を使用して Windows Server インスタンスにデプロイする場合 github.com/awslabs/awscodepipeline-s3-awscodedeploy_windows のサンプルを使用しま す b. [dist] フォルダーを選択します c. ファイル名を選択します Amazon Linux インスタンスにデプロイする場合 aws-codepipeline-s3-awscodedeploy_linux.zip を使用します Windows Server インスタンスにデプロイする場合 AWSCodePipeline-S3AWSCodeDeploy_Windows.zip を使用します d. 8. [View Raw] を選択し サンプルファイルをローカルコンピュータに保存します バケットの Amazon S3 コンソールで [アップロード] を選択し の手順に従って.zip ファイルを バケットにアップロードします 29

37 Windows Server Amazon EC2 インスタンスの作成お よび AWS CodeDeploy エージェントのインストール ステップ 3: Amazon EC2 Windows インスタンスの 作成および AWS CodeDeploy エージェントのインス トール このステップでは サンプルアプリケーションをデプロイする Windows Server Amazon EC2 インスタン スを作成します このプロセスの一環として AWS CodeDeploy エージェントをインスタンスにインス トールします AWS CodeDeploy エージェントは AWS CodeDeploy デプロイメントでインスタンスを 使用できるようにするソフトウェアパッケージです インスタンスを起動するには 1. にある Amazon EC2 コンソールを開きます 2. コンソールダッシュボードで [Launch Instance] を選択します 3. [Step 1: Choose an Amazon Machine Image (AMI) (ステップ 1: Amazon マシンイメージ (AMI) の選択] ページで Microsoft Windows Server 2016 Base の HVM エディションの行を見つけ [選択] を選択し ます (この AMI は "Free tier eligible" とラベル付けされており リストの先頭にあります) 4. [ステップ 2: インスタンスタイプの選択] ページで インスタンスのハードウェア構成として無料利用 枠対象の t2.micro タイプを選択してから [次の手順: インスタンスの詳細の設定] を選択します 5. [ステップ 3: インスタンスの詳細の設定] ページで 以下の操作を行います [インスタンス数] に 2 と入力します [Auto-assign Public IP] で [Enable] を選択します [IAM ロール] で AWS CodeDeploy 用の IAM インスタンスプロファイルとして使用するように設定 した IAM ロールを選択します IAM インスタンスプロファイルがない場合は [新しい IAM ロール の作成] を選択し Amazon EC2 インスタンス用の IAM インスタンスプロファイルの作成 の手 順に従います このチュートリアルでは AWS CodeDeploy 用の IAM インスタンスプロファイルで以下 の無制限のポリシーを使用できます 開発ワークフローで使用するパイプラインに対して は より制限の厳しいバケットポリシーを作成できます 6. "Version": " ", "Statement": [ "Action": [ "s3:get*", "s3:list*" ], "Effect": "Allow", "Resource": "*" ] ステップ 3: インスタンスの詳細の設定ページで 高度な詳細を展開し ユーザーデータで [As text (テ キストとして表示)] が選択されている状態で 以下のように入力します <powershell> New-Item -Path c:\temp -ItemType "directory" -Force powershell.exe -Command Read-S3Object -BucketName bucket-name/latest -Key codedeployagent.msi -File c:\temp\codedeploy-agent.msi Start-Process -Wait -FilePath c:\temp\codedeploy-agent.msi -WindowStyle Hidden 30

38 Windows Server Amazon EC2 インスタンスの作成お よび AWS CodeDeploy エージェントのインストール </powershell> このコードは インスタンスの作成時に AWS CodeDeploy エージェントをインストールします こ のスクリプトは Windows インスタンス専用です 7. [ステップ 3: インスタンスの詳細の設定] ページの残りの項目はそのままにします [次の手順: スト レージの追加] を選択し [ステップ 4: ストレージの追加] ページの項目をそのままにして [次の手順: タグの追加] を選択します 8. [タグの追加] ページで [キー] ボックスに "Name" と表示されるので [値] ボックスに MyCodePipelineDotNetDemo と入力し [次の手順: セキュリティグループの設定] を選択しま す Important [キー] および [値] ボックスでは 大文字と小文字が区別されます 9. [ステップ 6: セキュリティグループの設定] ページで 以下の操作を行います [セキュリティグループの割り当て] の横にある [新規セキュリティグループを作成] を選択します [SSH] の行の [ソース] で [マイ IP] を選択します [ルールの追加] [HTTP] の順に選択し [ソース] で [マイ IP] を選択します 10. [Review and Launch] を選択します 11. [インスタンス起動の確認] ページで [起動] を選択し キーペアの入力を求められたら 以下のいずれ かの操作を行います Amazon EC2 インスタンスで使用するキーペアがすでにある場合は [既存のキーペアを選択] を選 択してから キーペアを選択します まだキーペアを作成していない場合は [新しいキーペアの作成] を選択し キーペアの名前を入力 してから [キーペアのダウンロード] を選択します このタイミングでのみ プライベートキー ファイルを保存できます 必ずそのキーファイルをダウンロードしてください プライベートキー ファイルを安全な場所に保存します インスタンスの起動時に キーペアの名前を指定する必要 があります インスタンスに接続するたびに 対応するプライベートキーを提供する必要がありま す 詳細については Amazon EC2 のキーペア を参照してください Warning [Proceed without a key pair] オプションは選択しないでください キーペアを指定せずにイン スタンスを起動すると AWS CodeDeploy エージェントのトラブルシューティングが必要に なった場合 そのインスタンスに接続できません 準備ができたら 確認チェックボックスをオンにし [Launch Instances] を選択します 12. [View Instances] を選択して確認ページを閉じ コンソールに戻ります 13. [インスタンス] ページで 起動のステータスを表示できます インスタンスを起動した直後のステー タスは pending です インスタンスを起動した後は 状態が running に変わり パブリック DNS 名を受け取ります([パブリック DNS] 列が表示されていない場合は [表示/非表示] アイコンを選択し てから [パブリック DNS] を選択します) 14. インスタンスに接続可能になるまでには 数分かかることがあります インスタンスのステータス チェックが成功していることを確認します この情報は [ステータスチェック] 列で確認できます AWS CodeDeploy エージェントが正しく設定されていることを確認するには SSH を使用して Linux イン スタンスに接続し AWS CodeDeploy エージェントが実行中であることを確認します 31

39 AWS CodeDeploy でアプリケーションを作成する ステップ 4: AWS CodeDeploy でアプリケーションを 作成する AWS CodeDeploy では アプリケーションは 識別子です デプロイするコードで指定し 名前形式で表 します AWS CodeDeploy では この名前を使用して デプロイ時に リビジョン デプロイ設定 デプ ロイグループが正しい組み合わせで参照されるようにします このチュートリアルの後半でパイプライン を作成する際 このステップで作成した AWS CodeDeploy アプリケーションの名前を選択します AWS CodeDeploy でアプリケーションを作成するには 1. AWS CodeDeploy コンソール ( を開きます 2. [アプリケーション] ページが表示されない場合は AWS CodeDeploy メニューで [アプリケーション] を選択します 3. [Create application] を選択します 4. [Custom application (カスタムアプリケーション)] を選択したままにします [アプリケーション名] に MyDemoApplication と入力します 5. [コンピューティングプラットフォーム] で [EC2/オンプレミス] を選択します 6. [Create application] を選択します 7. [デプロイグループ名] ボックスに MyDemoDeploymentGroup と入力します 8. [Deployment type] で [In-place deployment] を選択します 9. [Environment configuration (環境設定)] で Amazon EC2 インスタンスタブを選択してから Amazon EC2 タグタイプを選択します [Key (キー)] ボックスで [名前] を選択し [値] ボックスに MyCodePipelineDotNetDemo と入力します Important Name キーには Amazon EC2 インスタンスの作成時に割り当てた同じ値を選択する必要が あります インスタンスに MyCodePipelineDemo 以外のタグを付けた場合は ここでもそ のタグを使用してください 10. [デプロイ設定] リストで CodeDeployDefault.OneAtaTime を選択します 11. [サービスロール ARN] ボックスで AWS CodeDeploy を信頼するサービスロールの Amazon リソー スネーム (ARN) を選択します このロールには最低限 AWS CodeDeploy のサービスロールを作 成する で説明している信頼とアクセス権限が必要です サービスロール ARN を取得するには サービスロール ARN の取得 (コンソール) を参照してください 12. [Create application] を選択します アプリケーションが表示されます このページに留まります AWS CodeDeploy でデプロイグループを作成するには 1. アプリケーションが表示されるページで [Create deployment group (デプロイグループの作成)] を選 択します 2. [デプロイグループ名] に MyDemoDeploymentGroup と入力します 3. [サービスロール] で AWS CodeDeploy のサービスロールを作成する で説明されている信頼およ びアクセス権限を少なくとも持つ AWS CodeDeploy を信頼するサービスロールを選択します サー ビスロール ARN を取得するには サービスロール ARN の取得 (コンソール) を参照してくださ い 4. [デプロイタイプ] で [インプレース] を選択します 5. [環境設定] で [Amazon EC2 Instances (Amazon EC2 インスタンス) ] を選択します [Key (キー)] ボックスで [名前] を選択し [値] ボックスに MyCodePipelineDemo と入力します 32

40 最初のパイプラインを作成 Important Name キーには Amazon EC2 インスタンスの作成時に割り当てた同じ値を選択する必要が あります インスタンスに MyCodePipelineDemo 以外のタグを付けた場合は ここでもそ のタグを使用してください 6. [デプロイ設定] で [CodeDeployDefault.OneAtaTime] を選択します 7. [Load Balancer (ロードバランサー)] で [Enable load balancing (ロードバランシングの有効化)] をオ フにします 8. [Advanced (詳細)] セクションを展開します [アラーム] で [アラーム設定を無視する] を選択しま す 9. [Create deployment group] を選択します ステップ 5: AWS CodePipeline で最初のパイプライン を作成する チュートリアルのこの部分では パイプラインを作成します サンプルは パイプラインを通して自動的 に実行されます AWS CodePipeline 自動リリースプロセスを作成するには 1. AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline) を開きます 2. [ようこそ] ページ [Getting started (開始方法)] ページ または [パイプライン] ページで [パイプライ ンの作成] を選択します 3. [Step 1: Choose pipeline settings (ステップ 1: パイプラインの設定の選択)] の [パイプライン名] で MyFirstPipeline と入力します パイプラインに別の名前を選択した場合は このチュートリアルの残りの部分で MyFirstPipeline の代わりにその名前を使用してください バケットを作成したら その 名前を変更することはできません パイプラインの名前にはいくつかの制限がある場合があ ります 詳細については AWS CodePipeline 制限 (p. 252) を参照してください 4. [ロール名] で 以下のいずれかの操作を行います サービスロールがない場合は [New service role (新しいサービスロール)] を選択し [ロール名] に 新しいサービスロールの名前を入力します IAM により 自動的にロールが作成されました 以前に AWS-CodePipeline-Service サービスロールを作成している場合は [Existing service role (既 存のサービスロール)] を選択します サービスロールを作成したタイミングに応じて 追加の AWS のサービスをサポートするた めにロールのアクセス権限の更新が必要になる場合があります 詳細については 他の AWS サービスのアクセス許可の追加 (p. 222) を参照してください 5. [アーティファクトの場所] で 以下のいずれかの操作を行います a. [Default location (デフォルトの場所)] を選択し パイプライン用に選択したリージョン内のパイ プラインのデフォルトのアーティファクトストア (デフォルトとして指定された Amazon S3 アー ティファクトバケットなど) を使用します b. 作成した既存のアーティファクトストア (Amazon S3 アーティファクトバケットなど) がパイプ ラインと同じリージョンにある場合は [Custom location (カスタムの場所)] を選択します 33

41 最初のパイプラインを作成 これはパイプラインのソースコードのソースバケットではありません パイプラインのアー ティファクトストアです Amazon S3 バケットのような個別のアーティファクトストアが パイプラインと同じリージョン内の各パイプラインに必要です [Next (次へ)] を選択します 6. [Step 2: Add source stage (ステップ 2: ソースステージの追加)] の [ソースプロバイダ] で [Amazon S3] を選択します [Bucket (バケット)] に ステップ 1: アプリケーションの Amazon S3 バケット を作成する (p. 28) で作成した Amazon S3 バケットの名前を入力します [S3 object key (S3 オ ブジェクトキー)] で そのバケットにコピーしたサンプルファイル aws-codepipeline-s3-awscodedeploy_linux.zip または AWSCodePipeline-S3-AWSCodeDeploy_Windows.zip を入力 します [Next step] を選択します たとえば バケットに awscodepipeline-demobucket-example-date という名前を付け AWS CodeDeploy で Amazon EC2 インスタンスに対して Amazon Linux を選択した場合は 次のように入 力します s3://awscodepipeline-demobucket-example-date/aws-codepipeline-s3-awscodedeploy_linux.zip バケットに awscodepipeline-demobucket-example-date という名前を付け AWS CodeDeploy で Amazon EC2 インスタンスに対して Windows を選択した場合は 次のように入力し ます s3://awscodepipeline-demobucket-example-date/awscodepipeline-s3awscodedeploy_windows.zip サンプルアプリケーションを Amazon S3 バケットではなく GitHub リポジトリにコピーする 場合は ソースプロバイダのリストから [GitHub] を選択し 指示に従います 詳細について は パイプラインの作成 (コンソールの場合) (p. 115) を参照してください [Change detection options] で デフォルト値のままにします これにより AWS CodePipeline は Amazon CloudWatch Events を使用して ソースバケットの変更を検出できます [Next (次へ)] を選択します 7. [Step 3: Add build stage (ステップ 3: ビルドステージの追加)] で [Skip (スキップ)] を選択し [Skip (ス キップ)] を選択して警告メッセージを受け入れます [Next (次へ)] を選択します 34

42 最初のパイプラインを作成 クラウド上の完全マネージド型のビルドサービスである AWS CodeBuild などのプロバイダ を使用してビルドアクションを設定できます また Jenkins など ビルドサーバーまたは システムと備えたプロバイダを使用するビルドアクションを設定することもできます 次の チュートリアル チュートリアル: 4 ステージのパイプラインを作成する (p. 56) では ビルドリソースを設定する手順と それらのリソースを使用するパイプラインを作成する手 順について説明します 8. [Step 4: Add deploy stage (ステップ 4: デプロイステージの追加)] の [デプロイプロバイダ] で [AWS CodeDeploy] を選択します [アプリケーション名] に CodePipelineDemoApplication を入力す るか 更新ボタンを選択してリストからそのアプリケーション名を選択します [デプロイグループ] に CodePipelineDemoFleet と入力するか リストからその名前を選択します その後 [Next (次へ)] を選択します "Deploy" は [Step 4: Add deploy stage (ステップ 4: デプロイステージの追加)] ステップで作 成されるステージにデフォルトで付けられる名前であり "Source" は パイプラインの最初 のステージに付けられる名前です 9. [ステップ 5: 確認] で情報を確認し [パイプラインの作成] を選択します 10. パイプラインの実行が開始されます AWS CodePipeline サンプルがウェブページを AWS CodeDeploy デプロイの各 Amazon EC2 インスタンスにデプロイしている間 進行状況と成功/失敗 メッセージを表示できます これで シンプルなパイプラインが AWS CodePipeline に作成されました パイプラインには 2 つのス テージがあります Amazon S3 バケットに保存されたバージョニング済みのサンプルアプリケーションにおける変更を検出 し パイプラインにこの変更をプルする [ソース] という名前のソースステージ この変更を AWS CodeDeploy で Amazon EC2 インスタンスにデプロイする [Deploy] ステージ ここで 結果を確認します パイプラインが正常に実行されたことを確認するには 1. パイプラインの最初の進行状況を表示します 各ステージのステータスは [まだ実行はありません] から [進行中] に変わり その後 [Succeeded (成功)] または [Failed (失敗)] のいずれかに変わりま す パイプラインの最初の実行は数分で完了します 2. アクションのステータスに [Succeeded] が表示されたら [Staging] ステージのステータス領域で [Details] を選択します これにより AWS CodeDeploy コンソールが開きます 3. [デプロイグループ] タブの [Deployment lifecycle events (デプロイライフサイクルイベント)] の下で インスタンス ID を選択します これにより EC2 コンソールが開きます 35

43 別のステージの追加 4. [Description] タブの [Public DNS] でアドレスをコピーし ウェブブラウザーのアドレスバーに貼り付 けます Amazon S3 バケットにアップロードしたサンプルアプリケーションのインデックスページを 表示します 以下のページは Amazon S3 バケットにアップロードしたサンプルアプリケーションです ステージ アクション パイプラインの仕組みの詳細については AWS CodePipeline の概念 (p. 4) を 参照してください ステップ 6: 別のステージをパイプラインに追加する 次に 別のステージをパイプラインに追加し AWS CodeDeploy を使用してステージングサーバーから 本稼働サーバーにデプロイできるようにします まず 別のデプロイグループを AWS CodeDeploy の CodePipelineDemoApplication に作成します その後 このデプロイグループを使用するアクションを含 むステージを追加します 別のステージを追加するには AWS CodePipeline コンソールまたは AWS CLI を使用して JSON ファイルのパイプライン構造を取得し 手動で編集します その後 update-pipeline コマンドを実行して パイプラインの変更を更新します トピック 2番目のデプロイグループを AWS CodeDeploy に作成する (p. 36) パイプラインの他のステージとしてデプロイグループを追加する (p. 37) 2番目のデプロイグループを AWS CodeDeploy に作成する チュートリアルのこの部分では 2 番目のデプロイグループを作成しますが 以前と同じ Amazon EC2 インスタンスにデプロイします このウォークスルーは デモンストレーションの みを目的としています AWS CodePipeline でエラーを表示する方法を示すために 意図的に失 敗するように設計されています AWS CodeDeploy で 2 番目のデプロイグループを作成するには AWS CodeDeploy コンソール ( を開きます [アプリケーション] を選択し アプリケーションのリストで [CodePipelineDemoApplication] を選択し ます 36

44 別のステージの追加 3. [デプロイグループ] タブを選択して [Create deployment group (デプロイグループの作成)] を選びま す 4. [Create deployment group (デプロイグループの作成)] ページの [Deployment group name (デプロイグ ループ名)] に 2 番目のデプロイグループの名前 (たとえば CodePipelineProductionFleet) を 入力します 5. [In-place deployment] を選択します 6. [Key (キー)] には Name と入力しますが [値] ではリストから [CodePipelineDemo] を選択します [デ プロイ設定] のデフォルト設定をそのままにします [サービスロール ARN] で 最初のデプロイに使 用した同じ AWS CodeDeploy サービスロール (AWS CodePipeline サービスロールではない) を選択し てから [デプロイグループの作成] を選択します パイプラインの他のステージとしてデプロイグループを追加する 別のデプロイグループが追加されたため このデプロイグループを使用するステージを追加して 前の手 順で使用したのと同じ Amazon EC2 インスタンスにデプロイできます AWS CodePipeline コンソールま たは AWS CLI を使用してこのステージを追加できます トピック 3 番目のステージの追加 (コンソールの場合) (p. 37) 3 番目のステージの追加 (CLI の場合) (p. 39) 3 番目のステージの追加 (コンソールの場合) AWS CodePipeline コンソールを使用して 新しいデプロイグループを使用する新しいステージを追加で きます このデプロイグループは すでに使用した Amazon EC2 インスタンスにデプロイされているた め このステージのデプロイアクションは失敗します 1. AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline) を開きます 2. [名前] で 作成したパイプラインの名前 MyFirstPipeline を選択します 3. パイプライン詳細ページで [編集] を選択します 4. [Edit (編集)] ページで [+ Add stage (+ ステージの追加)] を選択して [Deploy] ステージの直後にス テージを追加します 37

45 別のステージの追加 5. [Add stage (ステージの追加)] で [Stage name (ステージ名)] に Production を入力します [Add stage (ステージの追加)] を選択します 6. 新しいステージで [+ Add action group (+ アクショングループの追加)] を選択します 7. [アクションの編集] の [アクション名] に Deploy-Second-Deployment を入力します [Action provider (アクションプロバイダ)] の [デプロイ] で [AWS CodeDeploy] を選択します 8. AWS CodeDeploy セクションの [アプリケーション名] で パイプラインの作成時と同様に ドロップ ダウンリストから [CodePipelineDemoApplication] を選択します [デプロイグループ] で 先ほど作 成したデプロイグループ CodePipelineProductionFleet を選択します [入力アーティファクト] で [MyApp] を選択します [Save] を選択します ソースアーティファクトは入力アーティファクト MyApp の名前であり ソースアクションの 出力アーティファクトとして [Create pipeline (パイプラインの作成)] ウィザードで自動的に 作成されました すべてのアクションには入力アーティファクト (アクションの実行対象の アーティファクト) 出力アーティファクト (成果物またはそのアクションの結果) またはそ の両方があります この例では デプロイアクションはソースアクションの出力をソースス テージ MyApp に入力し デプロイします 前のステージ (Deploy) に対して設定されたアク ションが 同じ Amazon EC2 インスタンスにアプリケーションをすでにデプロイしているた め このアクションは失敗します 入力アーティファクトと出力アーティファクト および パイプラインの構造の詳細については AWS CodePipeline パイプライン構造のリファレ ンス (p. 244) を参照してください 9. [Edit (編集)] ページで [Save (保存)] を選択します [パイプラインの変更を保存] で [Save (保存)] を 選択します 10. 新しいステージがパイプラインに追加されていますが パイプラインの別の実行をトリガーした変更 がないため [まだ実行はありません] というステータスが表示されます 最新のリビジョンを手動で 再度実行して 編集されたパイプラインの実行度を確認する必要があります パイプラインの詳細 ページで [変更のリリース] を選択し プロンプトが表示されたら [リリース] を選択します これに より ソースアクションで指定した各ソース場所における最新のリビジョンがパイプラインで実行さ れます または AWS CLI を使用してパイプラインを再実行するには ローカル Linux, macos, or Unix マシ ンのターミナルから またはローカル Windows マシンのコマンドプロンプトから パイプラインの名 前を指定して start-pipeline-execution コマンドを実行します これにより ソースバケット内のアプ リケーションの 2 回目の実行がパイプラインで実行されます aws codepipeline start-pipeline-execution --name MyFirstPipeline このコマンドは pipelineexecutionid オブジェクトを返します 11. AWS CodePipeline コンソールに戻り パイプラインのリストで [MyFirstPipeline] を選択してビュー ページを開きます パイプラインには 3 つのステージがあり それらの各ステージのアーティファクトの状態が示され ます パイプラインがすべてのステージを実行するまでに最大 5 分かかることがあります 前回と同 じように 最初の 2 つのステージではデプロイが成功しますが [Production (本番稼働用)] ステージ では [Deploy-Second-Deployment (2 番目のデプロイをデプロイ)] アクションが失敗したことが示され ます 38

46 別のステージの追加 12. [Deploy-Second-Deployment] アクションで [Details] を選択します AWS CodeDeploy デプロイの ページにリダイレクトされます この場合 その失敗の結果 最初のインスタンスグループがすべて の Amazon EC2 インスタンスにデプロイされ 2 番目のデプロイグループ用にインスタンスは残りま せん この失敗は パイプラインのステージにエラーがある場合にどうなるかを示すために 意図 的に起こしたものです 3 番目のステージの追加 (CLI の場合) AWS CLI を使用してステージをパイプラインに追加するのは コンソールを使用するよりも複雑ですが パイプラインの構造が見やすくなります パイプラインの 3 番目のステージを作成するには 1. ローカル Linux, macos, or Unix マシンのターミナルセッションを開くか ローカル Windows マシン のコマンドプロンプトを開き get-pipeline コマンドを実行して 先ほど作成したパイプラインの構造 を表示します MyFirstPipeline に対して 以下のコマンドを入力します aws codepipeline get-pipeline --name "MyFirstPipeline" 39

47 別のステージの追加 このコマンドは MyFirstPipeline の構造を返します 出力の最初の部分は以下のようになります "pipeline": "rolearn": "arn:aws:iam::80398example:role/aws-codepipeline-service", "stages": [... 出力の最後のパートにはパイプラインのメタデータが含まれており 次のようになります ], "artifactstore": "type": "S3" "location": "codepipeline-us-east ",, "name": "MyFirstPipeline", "version": 4, "metadata": "pipelinearn": "arn:aws:codepipeline:us-east-2:80398example:myfirstpipeline", "updated": , "created": この構造をコピーしてプレーンテキストエディタに貼り付け ファイルを pipeline.json として保 存します 便利なように aws codepipeline コマンドを実行する同じディレクトリにこのファイルを 保存します 以下のように get-pipeline コマンドを使用して パイプ処理で JSON をファイルに渡すこと ができます aws codepipeline get-pipeline --name MyFirstPipeline >pipeline.json 3. [Staging] ステージセクションをコピーし 最初の 2 つのステージの後に貼り付けます これはデプロ イステージであるため [ステージング] ステージと同様に 3 番目のステージのテンプレートとして 使用します 4. ステージの名前とデプロイグループの詳細を変更し ファイルを保存します 以下の例では [Staging] ステージの後に pipeline.json ファイルに追加する JSON を示しています 強 調表示された要素を新しい値で編集します [Staging] と [Production] のステージ定義を区切るには 必ずカンマを使用してください, "name": "Production", "actions": [ "inputartifacts": [ "name": "MyApp" ], "name": "Deploy-Second-Deployment", "actiontypeid": "category": "Deploy", "owner": "AWS", 40

48 別のステージの追加 "version": "1", "provider": "CodeDeploy", "outputartifacts": [], "configuration": "ApplicationName": "CodePipelineDemoApplication", "DeploymentGroupName": "CodePipelineProductionFleet", "runorder": 1 5. ] 以下のようにパイプライン JSON ファイルを指定して update-pipeline コマンドを実行します aws codepipeline update-pipeline --cli-input-json file://pipeline.json このコマンドは 更新されたパイプラインの構造全体を返します Important ファイル名の前に必ず file:// を含めてください このコマンドでは必須です 6. パイプラインの名前を指定して start-pipeline-execution コマンドを実行します これにより ソー スバケット内のアプリケーションの 2 回目の実行がパイプラインで実行されます aws codepipeline start-pipeline-execution --name MyFirstPipeline このコマンドは pipelineexecutionid オブジェクトを返します 7. AWS CodePipeline コンソールを開き パイプラインのリストから [MyFirstPipeline] を選択します パイプラインには 3 つのステージがあり それらの各ステージのアーティファクトの状態が示され ます パイプラインがすべてのステージを実行するまでに最大 5 分かかることがあります 前回と同 じように 最初の 2 つのステージではデプロイが成功しますが [Production] ステージでは [DeploySecond-Deployment] アクションが失敗したことが示されます 41

49 ステージ間の移行を有効化または無効化する 8. [Deploy-Second-Deployment] アクションで [Details] を選択すると その失敗の詳細が表示されま す AWS CodeDeploy デプロイの詳細ページにリダイレクトされます この場合 その失敗の結果 最初のインスタンスグループがすべての Amazon EC2 インスタンスにデプロイされ 2 番目のデプロ イグループ用にインスタンスは残りません この失敗は パイプラインのステージにエラーがある場合にどうなるかを示すために 意図 的に起こしたものです ステップ 5: AWS CodePipeline のステージ間の移行を 有効化または無効化する パイプラインのステージ間の移行を有効化または無効化することができます ステージ間の移行を無効に すると ステージ間の移行を手動で制御できるようになります たとえば パイプラインの最初の 2 つの ステージを実行するが 本番環境にデプロイする準備ができるまで または問題のトラブルシューティン グ中か そのステージが失敗するまで 3 番目のステージへの移行を無効化します AWS CodePipeline パイプラインのステージ間の遷移を無効/有効にするには 1. AWS CodePipeline コンソールを開き パイプラインのリストから [MyFirstPipeline] を選択します 42

50 リソースのクリーンアップ 2. パイプラインの詳細ページで 2 番目のステージ ([Staging (ステージング)]) と前のセクションで追 加した 3 番目のステージ ([Production (本番稼働用)]) との間の [移行を無効にする] ボタンを選択しま す 3. [移行を無効にする] で ステージ間の移行を無効にする理由を入力し [無効化] を選択します ステージ間の矢印では アイコンと色の変化 および [移行を有効にする] ボタンが表示されます 4. サンプルをもう一度 Amazon S3 バケットにアップロードします バケットのバージョニングが有効 になっているため この変更によってパイプラインが開始します 詳細については サンプルアプ リケーションのアップロード (p. 29) を参照してください 5. パイプラインの詳細ページに戻り ステージの状態を監視します パイプラインビューでは 最初の 2 つのステージで進行状況が示されて成功に変わりますが 3 番目のステージで変更はありません このプロセスには数分かかることがあります 6. 2 つのステージの間の [移行を有効にする] ボタンを選択して 遷移を有効にします [Enable transition] ダイアログボックスで [Enable] を選択します 3 番目のステージの実行は数分で開始し パイプラインの最初の 2 つのステージですでに実行されているアーティファクトの処理を試みます この 3 番目のステージを成功させるには 遷移を有効にする前に CodePipelineProductionFleet デプロイグループを編集し アプリケーションをデプロイする 別の Amazon EC2 インスタンスを指定します そのための方法の詳細については デプロ イグループの設定を変更する を参照してください 追加の Amazon EC2 インスタンスを作 成すると 追加のコストが発生する場合があります ステップ 6: リソースをクリーンアップする チュートリアル: 4 ステージのパイプラインを作成する (p. 56) 用にこのチュートリアルで作成したリ ソースの一部を使用することができます たとえば AWS CodeDeploy アプリケーションおよびデプロイ メントは再利用できます ただし これらのチュートリアルの完了後 これらのリソースに対する継続利 用料金が発生しないよう 使用したパイプラインおよびリソースを削除する必要があります まず パイ プラインを削除し 続いて AWS CodeDeploy アプリケーションおよび関連付けられた Amazon EC2 イ ンスタンス 最後に Amazon S3 バケットを削除します このチュートリアルで使用されているリソースをクリーンアップするには 1. AWS CodePipeline リソースをクリーンアップするには AWS CodePipeline でパイプラインを削除 する (p. 134) の手順に従います 2. AWS CodeDeploy リソースをクリーンアップするには チュートリアルのデプロイリソースのク リーンアップ の手順に従います 3. Amazon S3 バケットを削除するには Amazon S3 バケットを空にする または削除する の手順 に従います 追加のパイプラインを作成しない場合は パイプラインのアーティファクトの保存用に 作成した Amazon S3 バケットを削除します このバケットの詳細については AWS CodePipeline の概念 (p. 4) を参照してください 43

51 チュートリアル: シンプルなパイプラインを作 成する (AWS CodeCommit リポジトリの場合) チュートリアル: シンプルなパイプラインを作成す る (AWS CodeCommit リポジトリの場合) AWS CodePipeline の使用を開始する最も簡単な方法は AWS CodePipeline コンソールで [パイプライン の作成] ウィザードを使用して シンプルなパイプラインを作成することです このチュートリアルでは AWS CodePipeline を使用して AWS CodeCommit リポジトリで管理されて いるコードを 1 つの Amazon EC2 インスタンスにデプロイします AWS CodeDeploy をデプロイメント サービスとして使用します お探しのものではありませんか バージョニングされた Amazon S3 バケットを使用して コードリポジ トリとしてシンプルなパイプラインを作成する方法については チュートリアル: シンプルなパイプライ ンを作成する (Amazon S3 バケットの場合) (p. 27) を参照してください このチュートリアル完了後 パイプラインのリポジトリとして AWS CodeCommit の概念を使用するに は 十分な練習が必要です AWS CodePipeline は Amazon CloudWatch Events を使用して AWS CodeCommit ソースリポジトリと ブランチの変更を検出します Amazon CloudWatch Events を使用して 変更が発生したときにパイプラ インを開始するのは このソースタイプのデフォルトです コンソールでウィザードを使用してパイプラ インを作成すると 自動的にルールが作成されます 作業を開始する前に 次のタスクが完了していることを確認してください IAM ユーザーを設定する AWS CLI をインストールして設定する Amazon EC2 を使用してキーペアを作成する さらに これらのサービス固有のタスクが完了していることを確認します AWS CodeCommit: Git をインストールして認証情報を設定する AWS CodeDeploy: IAM インスタンスプロファイルと AWS CodeDeploy サービスロールを作成する AWS CodePipeline: IAM ユーザーロールに AWS CodePipeline アクセス権限を割り当てる この チュートリアル: シンプルなパイプラインを作成する (Amazon S3 バケットの場 合) (p. 27) のチュートリアルはすでに完了しているものの リソースをクリーンアップして いない場合は このチュートリアルで使用した多数のリソースに異なる名前を付ける必要があり ます たとえば パイプラインに MyFirstPipeline の代わりに MySecondPipeline という名 前を付けることもできます トピック ステップ 1: AWS CodeCommit リポジトリおよびローカルリポジトリの作成 (p. 45) ステップ 2: AWS CodeCommit リポジトリにサンプルコードを追加する (p. 45) ステップ 3: Amazon EC2 Linux インスタンスの作成および AWS CodeDeploy エージェントのインス トール (p. 46) ステップ 4: AWS CodeDeploy でアプリケーションを作成する (p. 48) ステップ 5: AWS CodePipeline で最初のパイプラインを作成する (p. 49) ステップ 6: AWS CodeCommit リポジトリのコードを変更する (p. 53) ステップ 7: オプションのステージ管理タスク (p. 55) 44

52 AWS CodeCommit リポジトリの作成 ステップ 8: リソースをクリーンアップする (p. 55) ステップ 1: AWS CodeCommit リポジトリおよびロー カルリポジトリの作成 このチュートリアルを開始するには AWS CodeCommit にリポジトリを作成します パイプラインを 実行すると このリポジトリからソースコードが取得されます また AWS CodeCommit リポジトリに プッシュする前にコードを管理および更新するローカルリポジトリも作成します Important AWS CodeCommit は現在 以下のリージョンのパイプラインでサポートされています 米国東部 (オハイオ) リージョン (us-east-2) 米国東部 バージニア北部 リージョン (us-east-1) 米国西部 (オレゴン) リージョン (us-west-2) 欧州 (アイルランド) リージョン (eu-west-1) 南米 (サンパウロ) リージョン (sa-east-1) これらの AWS リージョンのいずれかを選択して このチュートリアルのステップがすべて完了 していることを確認します AWS CodeCommit ユーザーガイドの AWS CodeCommit での Git の使用に関するチュートリアル に記 載されている最初の 2 つの手順に従います ステップ 1: AWS CodeCommit リポジトリの作成 ステップ 2: ローカルリポジトリを作成する 作成したローカルリポジトリへの接続の詳細については AWS CodeCommit リポジトリに接続す る を参照してください 上記 2 つの手順を完了したら このページに戻り 次の手順に進んでください AWS CodeCommit チュートリアルの 3 つめの手順は進めないでください または このチュートリアルの別のステップを行 う必要があります ステップ 2: AWS CodeCommit リポジトリにサンプル コードを追加する このステップでは AWS CodeDeploy サンプルウォークスルーで作成されたサンプルアプリケーションの コードをダウンロードし AWS CodeCommit リポジトリに追加します 1. 以下ファイルをダウンロードします SampleApp_Linux.zip 2. SampleApp_Linux.zip ファイルを 前の手順で作成したローカルディレクトリ (/tmp/my-demorepo や c:\temp\my-demo-repo など) に解凍します それらのファイルはローカルリポジトリに直接配置してください SampleApp_Linux フォルダーは 含めないでください たとえば ローカル Linux, macos, or Unix マシンでは ディレクトリとファイ ル階層は以下のようになります /tmp 45

53 Amazon EC2 インスタンスの作成および AWS CodeDeploy エージェントのインストール my-demo-repo -- appspec.yml -- index.html -- LICENSE.txt `-- scripts -- install_dependencies -- start_server `-- stop_server 3. ディレクトリをローカルリポジトリに変更する: (For Linux, macos, or Unix) cd /tmp/my-demo-repo (For Windows) cd c:\temp\my-demo-repo 4. 以下のコマンドを実行して すべてのファイルを一度にステージングします git add -A 5. 以下のコマンドを実行して コミットメッセージによりファイルをコミットします git commit -m "Added sample application files" 6. 以下のコマンドを実行して ローカルリポジトリから AWS CodeCommit リポジトリにファイルを プッシュします git push 7. ダウンロードしてローカルリポジトリに追加したファイルは AWS CodeCommit MyDemoRepo リポ ジトリの master ブランチに追加され パイプラインに追加可能になります ステップ 3: Amazon EC2 Linux インスタンスの作成お よび AWS CodeDeploy エージェントのインストール このステップでは サンプルアプリケーションをデプロイする Amazon EC2 インスタンスを作成しま す このプロセスの一環として AWS CodeDeploy エージェントをこのインスタンスにインストールしま す AWS CodeDeploy エージェントは AWS CodeDeploy デプロイメントでインスタンスを使用できる ようにするソフトウェアパッケージです インスタンスを起動するには 1. にある Amazon EC2 コンソールを開きます 2. コンソールダッシュボードで [Launch Instance] を選択します 3. [ステップ 1; Amazon マシンイメージ (AMI) の選択] ページで Amazon Linux AMI の HVM エディショ ンの行を見つけ [Select] を選択します(この AMI は "Free tier eligible" とラベル付けされており リ ストの先頭にあります) Amazon マシンイメージ (AMI) と呼ばれるこれらの基本的な構成はインスタンスのテンプ レートとして機能します このチュートリアルは 無料利用枠対象の AMI のいずれでも完了 できます わかりやすいように Amazon Linux AMI の HVM エディションを使用します 4. [ステップ 2: インスタンスタイプの選択] ページで インスタンスのハードウェア構成として無料利用 枠対象の t2.micro タイプを選択してから [次の手順: インスタンスの詳細の設定] を選択します 5. [ステップ 3: インスタンスの詳細の設定] ページで 以下の操作を行います [インスタンス数] に 1 と入力します 46

54 Amazon EC2 インスタンスの作成および AWS CodeDeploy エージェントのインストール [Auto-assign Public IP] で [Enable] を選択します [IAM ロール] で AWS CodeDeploy 用の IAM インスタンスプロファイルとして使用するように設定 した IAM ロールを選択します IAM インスタンスプロファイルがない場合は [新しい IAM ロール の作成] を選択し Amazon EC2 インスタンス用の IAM インスタンスプロファイルの作成 の手 順に従います このチュートリアルでは AWS CodeDeploy 用の IAM インスタンスプロファイルで以下 の無制限のポリシーを使用できます 開発ワークフローで使用するパイプラインに対して は より制限の厳しいバケットポリシーを作成できます 6. "Version": " ", "Statement": [ "Action": [ "s3:get*", "s3:list*" ], "Effect": "Allow", "Resource": "*" ] ステップ 3: インスタンスの詳細の設定ページで 高度な詳細を展開し ユーザーデータフィールドに 以下のように入力します #!/bin/bash yum -y update yum install -y ruby yum install -y aws-cli cd /home/ec2-user aws s3 cp s3://aws-codedeploy-us-east-2/latest/install. --region us-east-2 chmod +x./install./install auto このコードは インスタンスの作成時に AWS CodeDeploy エージェントをインストールします 必要に応じて Linux インスタンスの作成後に SSH を使用してそのインスタンスに接続し AWS CodeDeploy エージェントを手動でインストールできます 7. [ステップ 3: インスタンスの詳細の設定] ページの残りの項目はそのままにします [次の手順: スト レージの追加] を選択し [ステップ 4: ストレージの追加] ページの項目をそのままにして [次の手順: タグの追加] を選択します 8. [タグの追加] ページで [キー] ボックスに "Name" と表示されるので [値] ボックスに MyCodePipelineDemo と入力し [次の手順: セキュリティグループの設定] を選択します Important [キー] および [値] ボックスでは 大文字と小文字が区別されます 9. [ステップ 6: セキュリティグループの設定] ページで 以下の操作を行います [セキュリティグループの割り当て] の横にある [新規セキュリティグループを作成] を選択します [SSH] の行の [ソース] で [マイ IP] を選択します [ルールの追加] [HTTP] の順に選択し [ソース] で [マイ IP] を選択します 10. [Review and Launch] を選択します 11. [インスタンス起動の確認] ページで [起動] を選択し キーペアの入力を求められたら 以下のいずれ かの操作を行います 47

55 AWS CodeDeploy でアプリケーションを作成する Amazon EC2 インスタンスで使用するキーペアがすでにある場合は [既存のキーペアを選択] を選 択してから キーペアを選択します まだキーペアを作成していない場合は [新しいキーペアの作成] を選択し キーペアの名前を入力 してから [キーペアのダウンロード] を選択します このタイミングでのみ プライベートキー ファイルを保存できます 必ずそのキーファイルをダウンロードしてください プライベートキー ファイルを安全な場所に保存します インスタンスの起動時に キーペアの名前を指定する必要 があります インスタンスに接続するたびに 対応するプライベートキーを提供する必要がありま す 詳細については Amazon EC2 のキーペア を参照してください Warning [Proceed without a key pair] オプションは選択しないでください キーペアを指定せずにイン スタンスを起動すると AWS CodeDeploy エージェントのトラブルシューティングが必要に なった場合 そのインスタンスに接続できません 準備ができたら 確認チェックボックスをオンにし [Launch Instances] を選択します 12. [View Instances] を選択して確認ページを閉じ コンソールに戻ります 13. [インスタンス] ページで 起動のステータスを表示できます インスタンスを起動した直後のステー タスは pending です インスタンスを起動した後は 状態が running に変わり パブリック DNS 名を受け取ります([パブリック DNS] 列が表示されていない場合は [表示/非表示] アイコンを選択し てから [パブリック DNS] を選択します) 14. インスタンスに接続可能になるまでには 数分かかることがあります インスタンスのステータス チェックが成功していることを確認します この情報は [ステータスチェック] 列で確認できます AWS CodeDeploy エージェントが正しく設定されていることを確認するには SSH を使用して Linux イン スタンスに接続し AWS CodeDeploy エージェントが実行中であることを確認します ステップ 4: AWS CodeDeploy でアプリケーションを 作成する AWS CodeDeploy では アプリケーションは 識別子です デプロイするコードで指定し 名前形式で表 します AWS CodeDeploy では この名前を使用して デプロイ時に リビジョン デプロイ設定 デプ ロイグループが正しい組み合わせで参照されるようにします このチュートリアルの後半でパイプライン を作成する際 このステップで作成した AWS CodeDeploy アプリケーションの名前を選択します AWS CodeDeploy でアプリケーションを作成するには 1. AWS CodeDeploy コンソール ( を開きます 2. [アプリケーション] ページが表示されない場合は AWS CodeDeploy メニューで [アプリケーション] を選択します 3. [Create application] を選択します 4. [Custom application (カスタムアプリケーション)] を選択したままにします [アプリケーション名] で MyDemoApplication を入力します 5. [コンピューティングプラットフォーム] で [EC2/オンプレミス] を選択します 6. [Create application] を選択します 7. [Deployment group name (デプロイグループ名)] で MyDemoDeploymentGroup を入力します 8. [Deployment type] で [In-place deployment] を選択します 9. [Environment configuration (環境設定)] で Amazon EC2 インスタンスタブを選択してか ら Amazon EC2 タグタイプを選択します [Key (キー)] ボックスで名前を選択し [値] に MyCodePipelineDotNetDemo と入力します 48

56 最初のパイプラインを作成 Important Name キーには Amazon EC2 インスタンスの作成時に割り当てた同じ値を選択する必要が あります インスタンスに MyCodePipelineDemo 以外のタグを付けた場合は ここでもそ のタグを使用してください 10. [Deployment configuration (デプロイ設定)] で CodeDeployDefault.OneAtaTime を選択します 11. [Service role ARN (サービスロール ARN)] で AWS CodeDeploy を信頼するサービスロールの Amazon リソースネーム (ARN) を選択します このロールには最低限 AWS CodeDeploy のサービ スロールを作成する で説明している信頼とアクセス権限が必要です サービスロール ARN を取得 するには サービスロール ARN の取得 (コンソール) を参照してください 12. [Create application] を選択します 表示されたページにとどまります AWS CodeDeploy でデプロイグループを作成するには 1. アプリケーションが表示されたページで [Create deployment group (デプロイグループの作成)] を選 択します 2. [Deployment group name (デプロイグループ名)] で MyDemoDeploymentGroup を入力します 3. [サービスロール] で AWS CodeDeploy のサービスロールを作成する で説明されている信頼およ びアクセス権限を少なくとも持つ AWS CodeDeploy を信頼するサービスロールを選択します サー ビスロール ARN を取得するには サービスロール ARN の取得 (コンソール) を参照してくださ い 4. [デプロイタイプ] で [インプレース] を選択します 5. [環境設定] で [Amazon EC2 Instances (Amazon EC2 インスタンス) ] を選択します [Key (キー)] ボックスで名前を選択し [値] ボックスに MyCodePipelineDemo と入力します Important Name キーには Amazon EC2 インスタンスの作成時に割り当てた同じ値を選択する必要が あります インスタンスに MyCodePipelineDemo 以外のタグを付けた場合は ここでもそ のタグを使用してください 6. [デプロイ設定] で [CodeDeployDefault.OneAtaTime] を選択します 7. [Load Balancer (ロードバランサー)] で [Enable load balancing (ロードバランシングの有効化)] をオ フにします 8. [Advanced (詳細)] セクションを展開します [アラーム] で [アラーム設定を無視する] を選択しま す 9. [Create deployment group] を選択します ステップ 5: AWS CodePipeline で最初のパイプライン を作成する これで 最初のパイプラインを作成および実行する準備ができました AWS CodePipeline 自動リリースプロセスを作成するには 1. AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline) を開きます 2. [ようこそ] ページ [Getting started (開始方法)] ページ または [パイプライン] ページで [パイプライ ンの作成] を選択します 3. [Step 1: Choose pipeline settings (ステップ 1: パイプラインの設定の選択)] の [パイプライン名] で MyFirstPipeline と入力します 49

57 最初のパイプラインを作成 パイプラインに別の名前を選択した場合は このチュートリアルの残りの手順で MyFirstPipeline の代わりにその名前を使用してください バケットを作成したら その 名前を変更することはできません パイプラインの名前にはいくつかの制限がある場合があ ります 詳細については AWS CodePipeline 制限 (p. 252) を参照してください 4. [ロール名] で 以下のいずれかの操作を行います サービスロールがない場合は [New service role (新しいサービスロール)] を選択し [ロール名] に ロールの名前を入力します IAM により ロールが自動的に作成されます 以前に AWS-CodePipeline-Service サービスロールを作成している場合は [Existing service role (既 存のサービスロール)] を選択します サービスロールを作成したタイミングに応じて 追加の AWS のサービスをサポートするた めにロールのアクセス権限の更新が必要になる場合があります 詳細については 他の AWS サービスのアクセス許可の追加 (p. 222) を参照してください 5. [アーティファクトストア] で 以下のいずれかの操作を行います a. [デフォルトの場所] を選択します これにより 選択したリージョンのパイプラインには デ フォルトのアーティファクトストア (デフォルトとして指定された Amazon S3 アーティファクト バケットなど) が使用されるようになります b. Amazon S3 アーティファクトバケットなどのアーティファクトストアがパイプラインと同じリー ジョンにある場合は [Custom location (カスタムの場所)] を選択します これはパイプラインのソースコードのソースバケットではありません パイプラインのアー ティファクトストアです Amazon S3 バケットのような個別のアーティファクトストアが パイプラインと同じリージョン内の各パイプラインに必要です [Next (次へ)] を選択します 6. [Step 2: Add source stage (ステップ 2: ソースステージの追加)] の [ソースプロバイダ] で [AWS CodeCommit] を選択します [リポジトリ名] で ステップ 1: AWS CodeCommit リポジトリおよび ローカルリポジトリの作成 (p. 45) で作成した AWS CodeCommit リポジトリの名前を選択しま す [Branch name] で 最新のコード更新を含むブランチの名前を選択します 独自のブランチを作 成する場合を除き ここで使用できるのは master のみです [Next step] を選択します 50

58 最初のパイプラインを作成 リポジトリ名とブランチを選択した後 このパイプラインのために作成される Amazon CloudWatch Events ルールを示すメッセージが表示されます [Change detection options] で デフォルト値のままにします これにより AWS CodePipeline は Amazon CloudWatch Events を使用して ソースリポジトリの変更を検出できます [Next (次へ)] を選択します 7. [Step 3: Add build stage (ステップ 3: ビルドステージの追加)] で [Skip (スキップ)] を選択し [Skip (ス キップ)] を選択して警告メッセージを受け入れます [Next (次へ)] を選択します このチュートリアルでは ビルドサービスを必要としないコードをデプロイします 8. [Step 4: Add deploy stage (ステップ 4: デプロイステージの追加)] の [デプロイプロバイダ] で [AWS CodeDeploy] を選択します [アプリケーション名] に MyDemoApplication を入力する か 更新ボタンを選択してリストからそのアプリケーション名を選択します [デプロイグループ] に MyDemoDeploymentGroup を入力するか リストから選択し [次のステップ] を選択します デプロイ は [ステップ 4: デプロイ] ステップで作成されるステージにデフォルトで付け られる名前であり ソース は パイプラインの最初のステージに付けられる名前です 9. [ステップ 5: 確認] で情報を確認し [パイプラインの作成] を選択します 10. パイプラインの実行が開始されます AWS CodePipeline サンプルがウェブページを AWS CodeDeploy デプロイの Amazon EC2 インスタンスにデプロイしている間 進行状況と成功/失敗メッ セージを表示できます 51

59 最初のパイプラインを作成 おめでとうございます シンプルなパイプラインが AWS CodePipeline に作成されました パイプライン には 2 つのステージがあります AWS CodeCommit リポジトリに保存されたサンプルアプリケーションにおける変更を検出し パイプ ラインにこの変更をプルするソースステージ ([ソース]) AWS CodeDeploy を使用して Amazon EC2 インスタンスにこれらの変更をデプロイするデプロイス テージ ([デプロイ]) 次に 結果を確認します パイプラインが正常に実行されたことを確認するには 1. パイプラインの最初の進行状況を表示します 各ステージのステータスは [まだ実行はありません] から [進行中] に変わり その後 [Succeeded (成功)] または [Failed (失敗)] のいずれかに変わりま す パイプラインの最初の実行は数分で完了します 2. パイプラインのステータスが [成功] と表示されたら [Staging (ステージング)] ステージのステータス 領域で [詳細] を選択します これにより AWS CodeDeploy コンソールが開きます 3. リストで アプリケーションを選択します [デプロイグループ] タブの [Deployment lifecycle events (デプロイライフサイクルイベント)] で インスタンス ID を選択します これにより EC2 コンソー ルが開きます 4. [Description] タブの [Public DNS] でアドレスをコピーし ウェブブラウザーのアドレスバーに貼り付 けます これは ダウンロードして AWS CodeCommit リポジトリにプッシュしたサンプルアプリケーション です 52

60 AWS CodeCommit リポジトリのコードを更新する ステージ アクション パイプラインの仕組みの詳細については AWS CodePipeline の概念 (p. 4) を 参照してください ステップ 6: AWS CodeCommit リポジトリのコードを 変更する このステップでは Amazon EC2 インスタンスにデプロイしたサンプルの AWS CodeDeploy アプリケー ションの一部である HTML ファイルを変更します このチュートリアルの後半でパイプラインが再度実行 されると URL でその変更を確認できるようになります 1. ディレクトリをローカルリポジトリに変更する: (For Linux, macos, or Unix) cd /tmp/my-demo-repo (For Windows) cd c:\temp\my-demo-repo 2. テキストエディタを使用して index.html ファイルを変更します (For Linux or Unix)gedit index.html (For OS X)open e index.html (For Windows)notepad index.html 3. index.html ファイルのコンテンツを変更して 背景色およびウェブページのテキストの一部を変更 してから ファイルを保存します <!DOCTYPE html> <html> <head> <title>updated Sample Deployment</title> <style> body color: #000000; background-color: #CCFFCC; font-family: Arial, sans-serif; font-size:14px; h1 font-size: 250%; font-weight: normal; margin-bottom: 0; 53

61 AWS CodeCommit リポジトリのコードを更新する h2 font-size: 175%; font-weight: normal; margin-bottom: 0; </style> </head> <body> <div align="center"><h1>updated Sample Deployment</h1></div> <div align="center"><h2>this application was updated using AWS CodePipeline, AWS CodeCommit, and AWS CodeDeploy.</h2></div> <div align="center"> <p>learn more:</p> <p><a href=" CodePipeline User Guide</a></p> <p><a href=" CodeCommit User Guide</a></p> <p><a href=" CodeDeploy User Guide</a></p> </div> </body> </html> 4. 以下のコマンドを一度に 1 つずつ実行することで 変更をコミットし AWS CodeCommit リポジト リにプッシュします git commit -am "Updated sample application files" git push AWS CodeCommit リポジトリのコードが変更されるとパイプラインが実行されるように設定されていま す パイプラインが正常に実行されたことを確認するには 1. パイプラインの最初の進行状況を表示します 各ステージのステータスは [まだ実行はありません] から [進行中] に変わり その後 [Succeeded (成功)] または [Failed (失敗)] のいずれかに変わりま す パイプラインの実行は数分で完了します 2. アクションのステータスに [Succeeded] が表示されたら [Staging] ステージのステータス領域で [Details] を選択します これにより AWS CodeDeploy コンソールが開きます 3. [デプロイグループ] タブの [Deployment lifecycle events (デプロイライフサイクルイベント)] で イン スタンス ID を選択します これにより EC2 コンソールが開きます 4. [Description] タブの [Public DNS] でアドレスをコピーし ウェブブラウザーのアドレスバーに貼り付 けます 更新されたウェブページが表示されます 54

62 オプションのステージ管理タスク ステージ アクション パイプラインの仕組みの詳細については AWS CodePipeline の概念 (p. 4) を 参照してください ステップ 7: オプションのステージ管理タスク チュートリアルを終了する前に ステージの操作経験を深めるには チュートリアル: シンプルなパイ プラインを作成する (Amazon S3 バケットの場合) (p. 27) に記載されている 2 つの追加手順を行いま す ステップ 6: 別のステージをパイプラインに追加する (p. 36) AWS CodePipeline のステージ間の遷移を有効または無効にする (p. 42) 2 つめの手順のステップ 4 では サンプルを Amazon S3 バケットに再度アップロードせずに ローカルリポジトリのサンプルアプリケーションを変更して AWS CodeCommit リポジトリに プッシュします ステップ 8: リソースをクリーンアップする このチュートリアルで作成したリソースの一部は 次のリソース チュートリアル: 4 ステージのパイプラ インを作成する (p. 56) で使用できます たとえば AWS CodeDeploy アプリケーションおよびデプ ロイメントは再利用できます ただし これらのチュートリアルの完了後 これらのリソースに対する継 続利用料金が発生しないよう 使用したパイプラインおよびリソースを削除する必要があります まず パイプラインを削除し 続いて AWS CodeDeploy アプリケーションおよび関連付けられた Amazon EC2 インスタンス 最後に AWS CodeCommit リポジトリを削除します このチュートリアルで使用されているリソースをクリーンアップするには 1. AWS CodePipeline リソースをクリーンアップするには AWS CodePipeline でパイプラインを削除 する (p. 134) の手順に従います 2. AWS CodeDeploy リソースをクリーンアップするには チュートリアルのデプロイリソースのク リーンアップ の手順に従います 3. AWS CodeCommit リポジトリを削除するには AWS CodeCommit リポジトリの削除 の手順に従 います 55

63 チュートリアル: 4 ステージのパイプラインを作成する チュートリアル: 4 ステージのパイプラインを作成 する これで チュートリアル: シンプルなパイプラインを作成する (Amazon S3 バケットの場合) (p. 27) または チュートリアル: シンプルなパイプラインを作成する (AWS CodeCommit リポジトリの場 合) (p. 44) に最初のパイプラインが作成されたため より複雑なパイプラインを作成できるようにな りました このチュートリアルでは 4 つのパイプラインを作成する方法について説明します このパイ プラインでは ソースの GitHub リポジトリ プロジェクトを構築する Jenkins ビルドサーバー ビルドさ れたコードをステージングサーバーにデプロイする AWS CodeDeploy アプリケーションを使用します パ イプラインが作成されたら これを編集して テストアクションを含むステージを追加してコードをテス トします この際 Jenkins も使用します このパイプラインを作成する前に 必要なリソースを設定する必要があります たとえば ソースコー ドに GitHub リポジトリを使用する場合は パイプラインに追加する前にリポジトリを作成する必要があ ります セットアップの一部として このチュートリアルでは デモンストレーション目的で Amazon EC2 インスタンスに Jenkins を設定する方法について説明します このチュートリアルを開始するには AWS CodePipeline の使用開始 (p. 9) の一般的な前提条件を満た している必要があります トピック ステップ 1: 前提条件の設定 (p. 56) ステップ 2: AWS CodePipeline でパイプラインを作成する (p. 59) ステップ 3: 別のステージをパイプラインに追加する (p. 61) ステップ 4: リソースをクリーンアップする (p. 63) ステップ 1: 前提条件の設定 Jenkins と統合するには AWS CodePipeline で AWS CodePipeline を使用する Jenkins のインスタン スに Jenkins の AWS CodePipeline プラグイン をインストールする必要があります また 専用の IAM ユーザーを設定して Jenkins プロジェクトと AWS CodePipeline の間でアクセス権限を使用する必要 があります Jenkins と AWS CodePipeline を統合する最も簡単な方法は Jenkins を統合するために作 成した IAM インスタンスを使用する Amazon EC2 インスタンスに Jenkins をインストールすることで す Jenkins アクション用のパイプラインのリンクを正常に接続するには Jenkins プロジェクトで使用す るポートにインバウンド接続できるように サーバー上または Amazon EC2 インスタンスのプロキシお よびファイアウォールを設定する必要があります これらのポートに接続する前に Jenkins でユーザー を認証してアクセス制御するように設定されていることを確認します (HTTPS 接続のみ使用できるよう に Jenkins のセキュリティを確保するには 443 および 8443 HTTP 接続できるようにするには 80 および 8080) 詳細については Jenkins のセキュリティ確保 を参照してください このチュートリアルでは コードサンプルを使用して Haml から HTML に変換するビルドス テップを設定します GitHub リポジトリからオープンソースのサンプルコードをダウンロードす るには このトピックのステップを行います GitHub リポジトリ内の.zip ファイルだけではな く sample 全体が必要です このチュートリアルでは 以下を前提としています Jenkins のインストールと管理および Jenkins プロジェクトの作成に慣れている Ruby の Rake と Haml gem が 同一コンピュータ または Jenkins プロジェクトをホストする インスタンス上にインストールされていること Rake コマンドを端末またはコマンドラインから実行できるように 必要なシステム環境変数が 設定されていること (たとえば Windows システムで Rake をインストールしたディレクトリ が追加されるように PATH 変数を変更する) 56

64 前提条件の設定 トピック サンプルのコピーまたはクローンを GitHub リポジトリに作成すること (p. 57) IAM ロールを作成して Jenkins 統合に使用すること (p. 57) Jenkins および Jenkins の AWS CodePipeline プラグイン のインストールおよび設定 (p. 57) サンプルのコピーまたはクローンを GitHub リポジトリに作成す ること サンプルを複製し GitHub リポジトリにプッシュする 1. サンプルコードを GitHub リポジトリからダウンロードするか リポジトリをローカルコンピュータ に複製します 2 つのサンプルパッケージがあります サンプルを Amazon Linux RHEL または Ubuntu Server インスタンスにデプロイする場合 は aws-codepipeline-jenkins-aws-codedeploy_linux.zip を選択します サンプルを Windows Server インスタンスにデプロイする場合は AWSCodePipeline-JenkinsAWSCodeDeploy_Windows.zip を選択します 2. リポジトリから [Fork] を選択してサンプルリポジトリを Github アカウントのレポジトリに複製しま す 詳細については GitHub のドキュメントを参照してください IAM ロールを作成して Jenkins 統合に使用すること ベストプラクティスとして Amazon EC2 インスタンスを起動して Jenkins サーバーをホストすること と IAM ロールを使用して必要なアクセス権限をインスタンスに付与して AWS CodePipeline と連携さ せることを検討してください 1. AWS マネジメントコンソール にサインインし IAM コンソール iam/ を開きます 2. IAM コンソールのナビゲーションペインで [ロール] [新しいロールの作成] の順に選択します 3. [ロールタイプの選択] ページで [AWS サービスロール] を選択してから [Amazon EC2] の横にある [選択] を選択します 4. [ポリシーのアタッチ] ページで [AWSCodePipelineCustomActionAccess] 管理ポリシーを選択してか ら [次のステップ] を選択します 5. [確認] ページの [ロール名] ボックスに Jenkins の統合専用に作成するロールの名前 (JenkinsAccess など) を入力し [ロールの作成] を選択します Jenkins をインストールする Amazon EC2 インスタンスを作成するときに [ステップ 3: インスタンスの 詳細の設定] でインスタンスロール (JenkinsAccess など) が選択されていることを確認します インスタンスロールおよび Amazon EC2 の詳細については Amazon EC2 の IAM ロール Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス権限を付与する お よび AWS のサービスにアクセス権限を委任するロールの作成 を参照してください Jenkins および Jenkins の AWS CodePipeline プラグイン のイン ストールおよび設定 Jenkins と Jenkins の AWS CodePipeline プラグイン をインストールするには 1. Jenkins をインストールする Amazon EC2 インスタンスを作成し [ステップ 3: インスタンスの詳細 の設定] でインスタンスロール (JenkinsAccess など) が選択されていることを確認します Amazon 57

65 前提条件の設定 EC2 インスタンスの作成の詳細については Amazon EC2 インスタンスの起動 を参照してくださ い 使用する Jenkins リソースがすでにある場合は 特別な IAM ユーザーを作成し そのユー ザーに AWSCodePipelineCustomActionAccess 管理ポリシーを適用してから Jenkins リソースに対してそのユーザーのアクセス認証情報を設定して使用する必要がありま す Jenkins UI を使用して認証情報を指定する場合は HTTPS のみを許可するように Jenkins を設定します 詳細については AWS CodePipeline のトラブルシューティン グ (p. 202) を参照してください 2. Amazon EC2 インスタンスに Jenkins をインストールします 詳細については Jenkins のドキュメ ントの Jenkins のインストール と Jenkins の開始とアクセス のほか AWS CodePipeline に よる製品とサービスの統合 (p. 11) の Jenkins との統合の詳細 (p. 14) を参照してください 3. Jenkins を起動し ホーム ページで [Manage Jenkins] (Jenkins の管理) を選択します 4. [Jenkins の管理] ページで [プラグインの管理] を選択します 5. [利用可能] タブを選択し [フィルタ] 検索ボックスに AWS CodePipeline と入力します リスト から [Jenkins の AWS CodePipeline プラグイン] を選択してから [ダウンロードして再起動後にイン ストール] を選択します 6. [プラグイン/アップグレードのインストール] ページで [インストール完了後 実行中のジョブがなけ れば Jenkins を再起動する] を選択します 7. [ダッシュボードに戻る] を選択します 8. メインページで [New Item] (新しい項目) を選択します 9. [Item Name] (項目名) に Jenkins プロジェクトの名前 (MyDemoProject など) を入力します [Freestyle project] (フリースタイルプロジェクト) [OK] の順に選択します プロジェクトの名前が AWS CodePipeline の要件を満たしていることを確認します 詳細に ついては AWS CodePipeline 制限 (p. 252) を参照してください 10. プロジェクトの設定ページで [Execute concurrent builds if necessary] (必要な場合に複数のビルドを 並列実行する) チェックボックスをオンにします [ソースコードの管理] で [AWS CodePipeline] を 選択します Amazon EC2 インスタンスに Jenkins をインストールし AWS CodePipeline と Jenkins の統合用に作成した IAM ユーザーのプロファイルで AWS CLI を設定した場合は 他のすべての フィールドを空のままにします 11. [Advanced (詳細)] を選択し [プロバイダ] に AWS CodePipeline で表示されるアクションのプロバ イダの名前 (MyJenkinsProviderName など) を入力します この名前は 必ず一意で覚えやすいも のであることを確認します このチュートリアルの後半でパイプラインにビルドアクションを追加す るときと テストアクションを追加するときに使用します このアクション名は AWS CodePipeline のアクションの命名要件を満たしている必要があ ります 詳細については AWS CodePipeline 制限 (p. 252) を参照してください 12. [Build Triggers] (トリガーのビルド) で チェックボックスをすべてオフにし [Poll SCM] (SCM の ポーリング) を選択します [スケジュール] で 以下のようにスペースで区切ってアスタリスクを 5 つ 入力します * * * * * これにより AWS CodePipeline のポーリングが毎分行われます 13. [ビルド] で [Add build step] (ビルドステップの追加) を選択します [Execute shell (シェルの実行)] (Amazon Linux RHEL または Ubuntu Server) または [Execute batch command (バッチコマンドの 実行)] (Windows Server) を選択し 以下のように入力します 58

66 パイプラインの作成 rake rake の実行に必要な変数と設定が環境で定義されていることを確認します 定義されていな いと ビルドは失敗します 14. [Add post-build action] [AWS CodePipeline Publisher] の順に選択します [Add] を選択し [Build Output Locations] でこの場所は空白のままにします この設定はデフォルトです ビルドプロセスの 最後に圧縮ファイルが作成されます 15. [保存] を選択して Jenkins プロジェクトを保存します ステップ 2: AWS CodePipeline でパイプラインを作成 する チュートリアルのこの部分では [Create Pipeline] ウィザードを使用してパイプラインを作成します AWS CodePipeline 自動リリースプロセスを作成するには 1. AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline) を開きます 2. 必要に応じて リージョンセレクターを使用して リージョンをパイプラインリソースが配置されて いる同じリージョンに変更します たとえば 前のチュートリアルでリソースを us-east-2 に作成し た場合 リージョンセレクターが 米国東部 (オハイオ) に設定されていることを確認します AWS CodePipeline で使用できるリージョンとエンドポイントの詳細については リージョンとエ ンドポイント を参照してください 3. [ようこそ] ページ [Getting started (開始方法)] ページ または [パイプライン] ページで [パイプライ ンの作成] を選択します 4. [Step 1: Choose pipeline settings (ステップ 1: パイプラインの設定の選択)] ページで [パイプライン 名] にパイプラインの名前を入力します 5. [サービスロール] で [New service role (新しいサービスロール)] を選択したままにして [Role name (ロール名)] を未変更のままにします 以前に作成したサービスロールがあれば その既存のロールを 使用することもできます 2018 年 7 月より前に作成された AWS CodePipeline サービスロールを使用している場 合 Device Farm に対するアクセス権限を追加する必要があります これを行うには IAM コンソールを開き ロールを見つけて ロールのポリシーに次のアクセス権限を追加しま す 詳細については 他の AWS サービスのアクセス許可の追加 (p. 222) を参照してく ださい "Effect": "Allow", "Action": [ "devicefarm:listprojects", "devicefarm:listdevicepools", "devicefarm:getrun", "devicefarm:getupload", "devicefarm:createupload", "devicefarm:schedulerun" ], "Resource": "*" 59

67 パイプラインの作成 6. [アーティファクトの場所] で 以下のいずれかの操作を行います a. [デフォルトの場所] を選択します これにより 選択したリージョンのパイプラインには デ フォルトのアーティファクトストア (デフォルトとして指定された Amazon S3 アーティファクト バケットなど) が使用されるようになります b. 作成した既存のアーティファクトストア (Amazon S3 アーティファクトバケットなど) がパイプ ラインと同じリージョンにある場合は [Custom location (カスタムの場所)] を選択します これはパイプラインのソースコードのソースバケットではありません パイプラインのアー ティファクトストアです Amazon S3 バケットのような個別のアーティファクトストアが パイプラインと同じリージョン内の各パイプラインに必要です 7. [Next (次へ)] を選択します 8. [Step 2: Add source stage (ステップ 2: ソースステージの追加)] の [ソースプロバイダ] で [GitHub] を選択してから [GitHub に接続] を選択します これにより GitHub に接続するための新しいブラウ ザーウィンドウが開きます サインインするように求められたら GitHub の認証情報を入力します Important GitHub ウェブサイトで AWS の認証情報を入力しないでください GitHub を選択すると AWS CodePipeline がパイプライン用に GitHub でウェブフックを作成するこ とを知らせるメッセージが表示されます GitHub に接続したら このチュートリアルで使用するサンプル (aws-codepipeline-jenkins-awscodedeploy_linux.zip または AWSCodePipeline-Jenkins-AWSCodeDeploy_Windows.zip) をプッシュす るリポジトリとブランチを選択してから [Next (次へ)] を選択します GitHub では AWS CodePipeline などのアプリケーションに対して使用できる OAuth トーク ンの数は制限されています この制限を超えた場合は AWS CodePipeline が既存のトーク ンを再利用して再接続できるように接続を再試行します 詳細については GitHub からの 個人用のアクセストークンを使用するようにパイプラインを設定するには (p. 205) を参照 してください 9. [Step 3: Add build stage (ステップ 3: ビルドステージの追加)] で [Jenkins の追加] を選択しま す [プロバイダ名] に Jenkins の AWS CodePipeline プラグイン で指定したアクションの名前 (MyJenkinsProviderName など) を入力します この名前は Jenkins の AWS CodePipeline プラ グイン の名前と正確に一致する必要があります [サーバー URL] に Jenkins がインストールされて いる Amazon EC2 インスタンスの URL を入力します [プロジェクト名] に Jenkins で作成したプロ ジェクトの名前 (MyDemoProject など) を入力し [Next (次へ)] を選択します 10. [Step 4: Add deploy stage (ステップ 4: デプロイステージの追加)] では チュートリアル: シンプル なパイプラインを作成する (Amazon S3 バケットの場合) (p. 27) で作成した AWS CodeDeploy アプリケーションおよびデプロイグループを再利用します [デプロイプロバイダ] で [AWS CodeDeploy] を選択します [アプリケーション名] に CodePipelineDemoApplication と入力 するか 更新ボタンを選択してリストからそのアプリケーション名を選択します [デプロイグループ] に CodePipelineDemoFleet と入力するか リストからその名前を選択します その後 [Next (次へ)] を選択します 独自の AWS CodeDeploy リソースを使用することも 新しいリソースを作成することもでき ますが 追加のコストが発生する場合があります 11. [ステップ 5: 確認] で情報を確認し [パイプラインの作成] を選択します 60

68 ステージの追加 12. パイプラインが自動的に開始され パイプラインによりサンプルが実行されます パイプラインが Haml サンプルを HTML にビルドし ウェブページを AWS CodeDeploy デプロイの各 Amazon EC2 インスタンスにデプロイしている間 進行状況と成功/失敗メッセージを表示できます ステップ 3: 別のステージをパイプラインに追加する 次に テストステージ テストアクションの順で サンプルに含まれている Jenkins テストを使用するス テージに追加し ウェブページにコンテンツが含まれているかどうかを確認します このテストは デモ ンストレーションのみを目的としています 他のステージをパイプラインに追加しない場合は パイプラインのステージ (Staging) へテストア クションを追加します その前後にデプロイアクションを行います パイプラインへのテストステージの追加 トピック インスタンスの IP アドレスの検索 (p. 61) Jenkins プロジェクトを作成してデプロイメントをテストする (p. 61) 4 番目のステージを作成する (p. 62) インスタンスの IP アドレスの検索 コードをデプロイしたインスタンスの IP アドレスを確認するには 1. パイプラインのステータスが "Succeeded" と表示されたら [Staging] ステージのステータス領域で [詳細] を選択します 2. [デプロイの詳細] (デプロイの詳細) セクションの [インスタンス ID] で 正常にデプロイされたいずれ かのインスタンスの ID を選択します 3. インスタンスの IP アドレス ( など) をコピーします この IP アドレスは Jenkins テス トで使用します Jenkins プロジェクトを作成してデプロイメントをテストする Jenkins プロジェクトを作成するには 1. Jenkins をインストールしたインスタンスで Jenkins を開き メインページから [New Item] (新しい 項目) を選択します 2. [Item Name] (項目名) に Jenkins プロジェクトの名前 (MyTestProject など) を入力します [Freestyle project] (フリースタイルプロジェクト) [OK] の順に選択します プロジェクトの名前が AWS CodePipeline の要件を満たしていることを確認します 詳細に ついては AWS CodePipeline 制限 (p. 252) を参照してください 3. プロジェクトの設定ページで [Execute concurrent builds if necessary] (必要な場合に複数のビルドを 並列実行する) チェックボックスをオンにします [ソースコードの管理] で [AWS CodePipeline] を 選択します Amazon EC2 インスタンスに Jenkins をインストールし AWS CodePipeline と Jenkins の統合用に作成した IAM ユーザーのプロファイルで AWS CLI を設定した場合は 他のすべての フィールドを空のままにします 61

69 ステージの追加 Important Jenkins プロジェクトを設定していて それが Amazon EC2 インスタンスにインストールさ れていない場合 または Windows オペレーティングシステムを実行している Amazon EC2 インスタンスにインストールされている場合は プロキシホストとポートの設定に従って フィールドを入力し Jenkins と AWS CodePipeline の統合用に設定した IAM ユーザーの認 証情報を指定します 4. [詳細設定] を選択してから [カテゴリ] で [テスト] を選択します 5. [プロバイダ] に ビルドプロジェクトで使用した同じ名前 (MyJenkinsProviderName など) を入力 します この名前は このチュートリアルの後半でパイプラインにテストアクションを追加するとき に使用します この名前は AWS CodePipeline のアクションの命名要件を満たしている必要があります 詳細については AWS CodePipeline 制限 (p. 252) を参照してください 6. [Build Triggers] (トリガーのビルド) で チェックボックスをすべてオフにし [Poll SCM] (SCM の ポーリング) を選択します [スケジュール] で 以下のようにスペースで区切ってアスタリスクを 5 つ 入力します * * * * * これにより AWS CodePipeline のポーリングが毎分行われます 7. [ビルド] で [Add build step] (ビルドステップの追加) を選択します Amazon Linux RHEL または Ubuntu Server インスタンスにデプロイする場合は [Execute shell (シェルの実行)] を選択し 以下の ように入力します ここで アドレスは 先ほどコピーした Amazon EC2 インスタンスのアドレスで す TEST_IP_ADDRESS= rake test Windows Server インスタンスにデプロイする場合は [Execute batch command (バッチコマンドの実 行)] を選択し 以下のように入力します ここで IP アドレスは 先ほどコピーした Amazon EC2 イ ンスタンスのアドレスです set TEST_IP_ADDRESS= rake test このテストでは デフォルトのポート 80 を想定しています 別のポートを指定する場合は 以下のように test port ステートメントを追加します TEST_IP_ADDRESS= TEST_PORT=8000 rake test 8. [Add post-build action] [AWS CodePipeline Publisher] の順に選択します [追加] は選択しないでくだ さい 9. [保存] を選択して Jenkins プロジェクトを保存します 4 番目のステージを作成する Jenkins テストアクションを含むステージをパイプラインに追加するには 1. AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline) を開きます 62

70 リソースのクリーンアップ 2. [名前] で 作成したパイプラインの名前 MySecondPipeline を選択します 3. パイプライン詳細ページで [編集] を選択します 4. [編集] ページで [+ Stage] を選択して [Staging] ステージの直後にステージを追加します 5. 新しいステージの名前フィールドに名前 (Testing など) を入力し [+ Action (アクション追加)] を選 択します 6. [アクションカテゴリー] ドロップダウンリストで [テスト] を選択します [アクション名] に MyJenkinsTest-Action と入力します [テストプロバイダ] で Jenkins で指定したプロバイ ダー名 (MyJenkinsProviderName など) を選択します [プロジェクト名] に Jenkins で作成したプ ロジェクトの名前 (MyTestProject など) を入力します [入力アーティファクト] で デフォルト名 が MyBuiltApp の Jenkins ビルドからのアーティファクトを選択したら [アクションの追加] を選択 します 入力アーティファクトと出力アーティファクト およびパイプラインの構造の詳細については AWS CodePipeline パイプライン構造のリファレンス (p. 244) を参照してください 7. [編集] ページで [パイプラインの変更を保存] を選択します [パイプラインの変更を保存] ダイアログ ボックスで [保存して続行] を選択します 8. パイプラインに新しいステージが追加されましたが パイプラインの別の実行をトリガーした変更が ないため そのステージのステータスは [まだ実行はありません] と表示されます 修正したパイプラ インによりサンプルを実行するには パイプラインの詳細ページで [変更のリリース] を選択します パイプラインビューには パイプラインのステージとアクション それらの 4 つのステージを実行し ているリビジョンの状態が表示されます パイプラインがすべてのステージを実行するのにかかる時 間は アーティファクトのサイズ ビルドとテストのアクションの複雑さ その他の要因によって異 なります ステップ 4: リソースをクリーンアップする これらのチュートリアルが完了したら 使用したパイプラインおよびリソースを削除する必要があるた め このリソースに対する継続利用料金がかかることはありません 今後 AWS CodePipeline を使用し ない場合は パイプラインを削除してから AWS CodeDeploy アプリケーション 関連付けられている Amazon EC2 インスタンス アーティファクトの保存に使用した Amazon S3 バケットの順に削除しま す 今後使用しない場合は GitHub リポジトリなどの他のリソースを削除するかどうかを検討することも 必要です このチュートリアルで使用されているリソースをクリーンアップするには 1. ローカル Linux, macos, or Unix マシンでターミナルセッションを開くか ローカル Windows マシン でコマンドプロンプトを開き delete-pipeline コマンドを実行して 作成したパイプラインを削除し ます MySecondPipeline に対して 以下のコマンドを入力します aws codepipeline delete-pipeline --name "MySecondPipeline" このコマンドは何も返しません 2. AWS CodeDeploy リソースをクリーンアップするには クリーンアップ の手順に従います 3. インスタンスリソースをクリーンアップするには Jenkins をインストールした Amazon EC2 インス タンスを削除します 詳細については インスタンスとボリュームのクリーンアップ を参照して ください 4. 追加のパイプラインを作成したり AWS CodePipeline を再利用したりしない場合は パイプライ ンのアーティファクトの保存に使用した Amazon S3 バケットを削除します バケットを削除するに は バケットの削除 の指示に従います 5. このパイプラインに他のリソースを再利用しない場合は それらのリソースを該当するガイダンスに 従って削除することを検討してください たとえば GitHub リポジトリを削除する場合は GitHub ウェブサイトの リポジトリの削除 の指示に従います 63

71 チュートリアル: CloudWatch イベント ルー ルをセットアップし パイプラインの状態 が変わったときに E メール通知を送信する チュートリアル: CloudWatch イベント ルールを セットアップし パイプラインの状態が変わったと きに E メール通知を送信する パイプラインをセットアップしたら CloudWatch イベント ルールをセットアップして パイプライン またはパイプラインのステージまたはアクションの実行状態に変更があったときに通知を送信できま す CloudWatch イベント を使用してパイプラインの状態の変更の通知をセットアップする方法の詳細に ついては Amazon CloudWatch Events でパイプラインの状態の変更を検出し対応する (p. 189) を参 照してください このチュートリアルでは パイプラインの状態が失敗に変わったら E メールを送信する通知を設定しま す このチュートリアルでは CloudWatch イベント ルールを作成するときの入力変換方法を使用しま す メッセージスキーマの詳細を変換し 人間が読み取れるテキストでメッセージを配信します トピック ステップ 1: Amazon SNS を使用して E メール通知をセットアップする (p. 64) ステップ 2: ルールを作成し SNS トピックをターゲットとして追加する (p. 65) ステップ 3: リソースをクリーンアップする (p. 67) ステップ 1: Amazon SNS を使用して E メール通知を セットアップする Amazon SNS は トピックの使用を調整して サブスクライブしているエンドポイントやクライアントへ のメッセージを配信します Amazon SNS を使用して通知トピックを作成してから E メールアドレスを 使用してトピックをサブスクライブします Amazon SNS トピックが CloudWatch イベント ルールにター ゲットとして追加されます 詳細については Amazon Simple Notification Service 開発者ガイド を参 照してください 1. Amazon SNS でトピックを作成または識別します AWS CodePipeline は Amazon SNS を介してこ のトピックにビルド通知を送信するために CloudWatch イベント を使用します トピックを作成する には: 1. で Amazon SNS コンソールを開きます 2. [Create topic] を選択します 3. [Create new topic (新しいトピックの作成)] ダイアログボックスの [Topic name (トピック名)] で トピックの名前 (例: PipelineNotificationTopic) を入力します 4. [Create topic] を選択します 64

72 AWS CodePipeline の CloudWatch イベント 通知ルールを作成する 詳細については Amazon SNS 開発者ガイド の トピックの作成 を参照してください 2. 1 つかそれ以上の受信者にトピックをサブスクライブさせ E メール通知を受け取ります 受信者に トピックをサブスクライブさせるには: 1. Amazon SNS コンソールで [トピック] リストから 新しいトピックの横にあるチェックボック スをオンにします [Actions, Subscribe to topic] を選択します 2. [Create subscription] ダイアログボックスで ARN が [Topic ARN] に表示されていることを確認 します 3. [Protocol] で [ ] を選択します 4. [Endpoint] に 新しい受信者の完全な E メールアドレスを入力します 結果を以下と比較しま す 5. [Create Subscription] を選択します 6. Amazon SNS は受信者にサブスクリプション確認の E メールを送信します E メール通知を受信 するには 受信者は この E メールで [サブスクリプションを確認] リンクを選択する必要があり ます 受信者がリンクをクリックした後 正常にサブスクライブされたら Amazon SNS により 受信者のウェブブラウザに確認メッセージが表示されます 詳細については Amazon SNS開発者ガイド の トピックのサブスクライブ を参照してくださ い ステップ 2: ルールを作成し SNS トピックをターゲッ トとして追加する AWS CodePipeline でイベントソースとして CloudWatch イベント 通知ルールを作成します 1. CloudWatch コンソールを開きます 2. ナビゲーションペインの [Events] を選択します 3. [Create rule] を選択します [イベントソース] で [AWS CodePipeline] を選択します [イベントタイ プ] で パイプライン実行の状態変更を選択します 4. [特定の状態] を選択し [FAILED] を選択します 5. [編集] を選択し [イベントパターンのプレビュー] ペインで JSON テキストエディタを開きま す pipeline パラメータを 次の例 ( mypipeline という名前のパイプライン) に示すように パ イプラインの名前とともに追加します 65

73 AWS CodePipeline の CloudWatch イベント 通知ルールを作成する 6. [Targets] で [Add target] を選択します 7. ターゲットのリストで [SNS トピック] を選択します [トピック] に 作成したトピックを入力しま す 8. [入力の設定] を展開して [インプットトランスフォーマー] を閉じます 9. [入力パス] ボックスに 次のキーと値のペアを入力します "pipeline" : "$.detail.pipeline" [入力テンプレート] ボックスに 以下のように入力します "The Pipeline <pipeline> has failed." 10. [Configure details] を選択します 11. [ルールの詳細を設定する] ページで 名前とオプションの説明を入力します [状態] では [有効] ボッ クスをオンのままにします 12. [Create rule] を選択します 13. AWS CodePipeline がビルド通知を現在送信していることを確認します たとえば ビルド通知 E メールが受信トレイにあるかどうかを確認します 14. ルールの動作を変更するには CloudWatch コンソールで ルールを選択してから [アクション] [編 集] の順に選択します ルールを編集し [詳細設定] を選択し [Update] を選択します ルールがビルド通知を送信するのを停止するには CloudWatch コンソールで ルールを選択してか ら [アクション] [無効化] を選択します ルールを削除するには CloudWatch コンソールで ルールを選択してから [アクション] [削除] の 順に選択します 66

74 リソースのクリーンアップ ステップ 3: リソースをクリーンアップする これらのチュートリアルが完了したら 使用したパイプラインおよびリソースを削除する必要があるた め このリソースに対する継続利用料金がかかることはありません SNS 通知をクリーンアップして Amazon CloudWatch Events ルールを削除する方法の詳細について は Amazon CloudWatch Events API リファレンス の クリーンアップ (Amazon SNS トピックのサブス クライブ解除) および リファレンス DeleteRule を参照してください チュートリアル: コミットが GitHub リポジトリに プッシュされたときに Android アプリをビルドして テストするパイプラインを作成する AWS CodePipeline を使用して コミットがリポジトリにプッシュされるたびにアプリがビルドされ テ ストされる継続的な統合フローを設定できます このチュートリアルでは GitHub リポジトリのソース コードを使って Android アプリをビルドしてテストするパイプラインを作成して設定する方法を説明しま す パイプラインは AWS CodePipeline が GitHub リポジトリ用に設定したウェブフックを介して新しい コミットの到着を検出し AWS CodeBuild を使用してアプリケーションをビルドし Device Farm でテス トします 既存の Android アプリとテスト定義を使用してこれを試すか Device Farm が提供するサンプルアプリと テスト定義を使用できます 設定 定義の追加 Push ビルドとテスト レポート パイプラインリ ソースを設定する パッケージにビ ルドとテストの 定義を追加する リポジトリに パッケージを プッシュする アプリケーショ ンをビルドし 自動的に開始さ れるビルド出力 アーティファク トをテストする テスト結果 を表示する Device Farm テストを使用するように AWS CodePipeline を設定する 1. アプリケーションのコードのルートに buildspec.yml という名前のファイルを追加してコミット し リポジトリにプッシュします AWS CodeBuild は このファイルを使用してコマンドを実行し アプリケーションをビルドするために必要なアーティファクトにアクセスします 67

75 Device Farm テストを使用するよ うに AWS CodePipeline を設定する version: 0.2 phases: build: commands: - chmod +x./gradlew -./gradlew assembledebug artifacts: files: - './android/app/build/outputs/**/*.apk' discard-paths: yes 2. (オプション) Calabash または Appium を使用してアプリケーションをテストする場合は テスト定義 ファイルをリポジトリに追加します 後のステップで 定義を使用してテストスイートを実行するよ うに Device Farm を設定できます Device Farm の組み込みのテストを使用する場合は このステップを省略できます 3. AWS CodeBuild に プロジェクトを作成するには 次のコマンドを入力します a. AWS マネジメントコンソールにサインインし AWS CodeBuild コンソールを開きます b. ウェルカムページが表示された場合は [今すぐ始める] を選択します ウェルカムページが表示されない場合は ナビゲーションペインで [ビルドプロジェクト] を選択 し 次に [Create build project (ビルドプロジェクトの作成)] を選択します 4. c. [プロジェクト名] に このビルドプロジェクトの名前を入力します d. [ソースプロバイダ] で [AWS CodePipeline] を選択します e. [環境] で [マネージド型イメージ] を選択します [Operating system] で [Ubuntu] を選択しま す f. [ランタイム] で [Android] を選択します [Version (バージョン)] で [aws/codebuild/androidjava-8:26.1.1] を選択します AWS CodeBuild は Android Studio がインストールされているこの OS イメージを使用してアプリケーションをビルドします g. [サービスロール] で AWS CodeBuild サービスロールを選択します h. [ビルド仕様] では [ソースコードのルートディレクトリの buildspec.yml を使用] を選択します i. [Create build project (ビルドプロジェクトの作成)] を選択します これにより 設定用にリポジト リ内の buildspec.yml を使用する AWS CodeBuild プロジェクトが作成されます ビルドプロ ジェクトでは サービスロールを使用して AWS のサービスのアクセス許可を管理します この ステップには数分かかる場合があります パイプラインを作成してソースステージを追加するには 以下の手順を実行します a. AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline/) を開きます b. [Create pipeline] を選択します [Step 1: Choose pipeline settings (ステップ 1: パイプラインの設 定の選択)] ページで [パイプライン名] にパイプラインの名前を入力します c. [サービスロール] で [New service role (新しいサービスロール)] は選択したままにして [Role name (ロール名)] は変更しません 既存のサービスロール (ある場合) を使用することもできま す 2018 年 7 月より前に作成された AWS CodePipeline サービスロールを使用している 場合 Device Farm に対するアクセス権限を追加する必要があります これを行う には IAM コンソールを開き ロールを見つけて ロールのポリシーに次のアクセ ス権限を追加します 詳細については 他の AWS サービスのアクセス許可の追 加 (p. 222) を参照してください 68

76 Device Farm テストを使用するよ うに AWS CodePipeline を設定する d. "Effect": "Allow", "Action": [ "devicefarm:listprojects", "devicefarm:listdevicepools", "devicefarm:getrun", "devicefarm:getupload", "devicefarm:createupload", "devicefarm:schedulerun" ], "Resource": "*" [アーティファクトの場所] で 以下のいずれかの操作を行います i. [Default location (デフォルトの場所)] を選択し パイプライン用に選択したリージョン内の パイプラインのデフォルトのアーティファクトストア (デフォルトとして指定された Amazon S3 アーティファクトバケットなど) を使用します ii. 作成した既存のアーティファクトストア (Amazon S3 アーティファクトバケットなど) がパ イプラインと同じリージョンにある場合は [Custom location (カスタムの場所)] を選択しま す これはパイプラインのソースコードのソースバケットではありません パイプラインの アーティファクトストアです Amazon S3 バケットのような個別のアーティファクトス トアが パイプラインと同じリージョン内の各パイプラインに必要です e. [Next (次へ)] を選択します f. [Step 2: Add source stage (ステップ 2: ソースステージの追加)] ページにある [ソースプロバイダ] で [GitHub] を選択してから [GitHub に接続] を選択します g. ブラウザウィンドウで [Authorize aws-codesuite (aws-codesuite の認証)] を選択します これに より パイプラインでリポジトリをソースにし 新しいコードがリポジトリにプッシュされたこ とを検出するウェブフックを使用することができます h. [リポジトリ] で ソースリポジトリを選択します i. [ブランチ] で 使用するブランチを選択します 69

77 Device Farm テストを使用するよ うに AWS CodePipeline を設定する j. 5. [Next (次へ)] を選択します [ビルド] で ビルドステージを追加します a. [ビルドプロバイダ] で [AWS CodeBuild] を選択します b. [AWS CodeBuild] で [プロジェクト名] を選択して プロジェクトの名前を入力します c. [Next (次へ)] を選択します d. [デプロイプロバイダ] で [スキップ] を選択し 続いて [スキップ] を選択してメッセージを受け 入れて [Next (次へ)] を選択します e. [Step 5: Review (ステップ 5: 確認)] で [パイプラインの作成] を選択します ソースとビルドス テージを示す図が表示されます 70

78 Device Farm テストを使用するよ うに AWS CodePipeline を設定する 6. パイプラインに Device Farm テストアクションを追加します a. 左上の [Edit (編集)] を選択します b. 図の最下部で [+ Add stage (+ ステージの追加)] を選択します c. ステージ名を入力し [+ Add action group (+ アクショングループの追加)] を選択します d. [アクション名] に名前を入力します e. [Action provider (アクションプロバイダ)] で [AWS Device Farm] を選択します 71

79 Device Farm テストを使用するよ うに AWS CodePipeline を設定する f. [ProjectId] で 既存の Device Farm プロジェクトを選択するか [Create a new project (新規プロ ジェクトの作成)] を選択します g. [DevicePoolArn] で 既存のデバイスプールを選択します デバイスプールを作成する場合は 一 連のテストデバイスを選択する必要があります h. [App type (アプリタイプ)] で [Android] を選択します i. [App file path (アプリファイルパス)] にコンパイルされたアプリケーションパッケージのパスを 入力します パスは テストステージの入力アーティファクトのルートを基準とする相対パスで す このパスは app-release.apk に似ています j. [Test type (テストタイプ)] で以下のいずれかを実行します 72

80 Device Farm テストを使用するよ うに AWS CodePipeline を設定する 組み込み Device Farm テストのいずれかを使用している場合は Device Farm プロジェクトで 設定されているテストのタイプを選択します 組み込み Device Farm テストのいずれも使用していない場合は テストのタイプを選択し [Test file path (テストファイルパス)] にテスト定義ファイルのパスを入力します パスは テス トの入力アーティファクトのルートを基準とする相対パスです k. 残りのフィールドにはテストおよびアプリケーションタイプに適した設定を入力します l. (オプション) [アドバンスト] で テストランの情報の設定を行います 73

81 Device Farm テストを使用するよ うに AWS CodePipeline を設定する m. [入力アーティファクト] で テストステージの前にあるステージの出力アーティファクトに一致 する入力アーティファクトを選択します AWS CodePipeline コンソールでは パイプライン図の情報アイコンの上にカーソルを置くこと で 各ステージの出力アーティファクトの名前を見つけることができます パイプラインでアプ リケーションを [Source ] ステージから直接テストする場合は [MyApp] を選択します パイプラ インに [ビルド] ステージが含まれている場合は [MyAppBuild] を選択します n. パネルの下部で [アクションの追加] を選択します o. AWS CodePipeline のペインで [パイプラインの変更を保存] [変更の保存] の順に選択します 74

82 チュートリアル: 変更が Amazon S3 に保存されたと きに ios アプリケーションをビルドしてテストする p. 変更を送信してパイプラインのビルドを開始するには [変更のリリース] [リリース] の順に選択 します チュートリアル: Amazon S3 バケットの変更後に ios アプリをビルドしてテストするパイプラインを 作成する AWS CodePipeline を使用し ソースバケットが変更されるたびにアプリがテストされる継続的な統合フ ローを簡単に設定できます このチュートリアルでは Amazon S3 バケットからビルドした ios アプリ をテストするためのパイプラインを作成して設定する方法を示します パイプラインは保存された変更の 到着を Amazon CloudWatch Events を介して検出し ビルドされたアプリケーションを Device Farm を使 用してテストします 既存の ios アプリを使用して試してみるか サンプル ios アプリを使用できます 設定 定義を追加する アップロード Test レポート パイプラインリ ソースを設定する パッケージにテス ト定義を追加する バケットに.zip を アップロードする 自動的に開始 される出力アー ティファクト をテストする テスト結果 を表示する Device Farm テスト (Amazon S3 の例) を使用するよ うに AWS CodePipeline を設定する バージョニングが有効になっている Amazon S3 バケットを作成または使用します ステップ 1: アプ リケーションの Amazon S3 バケットを作成する (p. 28) のステップの手順に従って Amazon S3 バケットを作成します バケットの Amazon S3 コンソールで [アップロード] を選択し 指示に従って.zip ファイルをアップ ロードします サンプルアプリケーションは.zip ファイルにパッケージ化する必要があります パイプラインを作成してソースステージを追加するには 以下の手順を実行します a. b. AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline/) を開きます [Create pipeline] を選択します [Step 1: Choose pipeline settings (ステップ 1: パイプラインの設 定の選択)] ページで [パイプライン名] にパイプラインの名前を入力します 75

83 Device Farm テスト (Amazon S3 の例) を使 用するように AWS CodePipeline を設定する c. [サービスロール] で [New service role (新しいサービスロール)] は選択したままにして [Role name (ロール名)] は変更しません 既存のサービスロール (ある場合) を使用することもできま す 2018 年 7 月より前に作成された AWS CodePipeline サービスロールを使用している 場合 Device Farm に対するアクセス権限を追加する必要があります これを行う には IAM コンソールを開き ロールを見つけて ロールのポリシーに次のアクセ ス権限を追加します 詳細については 他の AWS サービスのアクセス許可の追 加 (p. 222) を参照してください d. "Effect": "Allow", "Action": [ "devicefarm:listprojects", "devicefarm:listdevicepools", "devicefarm:getrun", "devicefarm:getupload", "devicefarm:createupload", "devicefarm:schedulerun" ], "Resource": "*" [アーティファクトの場所] で 以下のいずれかの操作を行います i. [Default location (デフォルトの場所)] を選択し パイプライン用に選択したリージョン内の パイプラインのデフォルトのアーティファクトストア (デフォルトとして指定された Amazon S3 アーティファクトバケットなど) を使用します ii. 作成した既存のアーティファクトストア (Amazon S3 アーティファクトバケットなど) がパ イプラインと同じリージョンにある場合は [Custom location (カスタムの場所)] を選択しま す これはパイプラインのソースコードのソースバケットではありません パイプラインの アーティファクトストアです Amazon S3 バケットのような個別のアーティファクトス トアが パイプラインと同じリージョン内の各パイプラインに必要です e. [Next (次へ)] を選択します f. [Step 2: Add source stage (ステップ 2: ソースステージの追加)] ページの [ソースプロバイダ] で [Amazon S3] を選択します g. [Amazon S3 の場所] に.zip ファイルのバケットとオブジェクトキーを入力します 76

84 Device Farm テスト (Amazon S3 の例) を使 用するように AWS CodePipeline を設定する h. 4. [Next (次へ)] を選択します [ビルド] で パイプラインのプレースホルダービルドステージを作成します これにより ウィザー ドでパイプラインを作成することができます ウィザードを使用して 2 ステージパイプラインを作成 した後は このプレースホルダービルドステージは不要になります パイプラインが完了した後 こ の第 2 ステージが削除され ステップ 5 で新しいテストステージが追加されます a. [ビルドプロバイダ] で [Jenkins の追加] を選択します このビルド選択はプレースホルダーで す それは使用されていません b. [プロバイダ名] に名前を入力します 名前はプレースホルダーです それは使用されていませ ん c. [サーバー URL] にテキストを入力します テキストはプレースホルダーです それは使用されて いません d. [プロジェクト名] に名前を入力します 名前はプレースホルダーです それは使用されていませ ん 77

85 Device Farm テスト (Amazon S3 の例) を使 用するように AWS CodePipeline を設定する e. [Next (次へ)] を選択します f. [デプロイプロバイダ] で [スキップ] を選択し 続いて [スキップ] を選択してメッセージを受け入 れて [Next (次へ)] を選択します g. [Step 5: Review (ステップ 5: 確認)] で [パイプラインの作成] を選択します ソースとビルドス テージを示す図が表示されます 78

86 Device Farm テスト (Amazon S3 の例) を使 用するように AWS CodePipeline を設定する 5. 次のようにして Device Farm テストアクションをパイプラインに追加します a. 左上の [Edit (編集)] を選択します b. ビルドステージを削除するには [X] アイコンを選択します これにより パイプライン作成のた めには使用しないプレースホルダーステージが削除されます c. 図の最下部で [+ Add stage (+ ステージの追加)] を選択します d. ステージ名を入力し [+ Add action group (+ アクショングループの追加)] を選択します e. [アクション名] に名前を入力します f. [テストプロバイダ] で [AWS Device Farm] を選択します g. [アクション名] で 名前を入力し [テストプロバイダ] から [AWS Device Farm] を選択しま す 79

87 Device Farm テスト (Amazon S3 の例) を使 用するように AWS CodePipeline を設定する h. [プロジェクト名] で 既存の Device Farm プロジェクトを選択するか [新規プロジェクトの作成] を選択します i. [Device pool (デバイスプール)] で 既存のデバイスプールを選択するか [Create a new device pool (新しいデバイスプールの作成)] を選択します デバイスプールを作成する場合は 一連のテ ストデバイスを選択する必要があります j. [App type (アプリタイプ)] で [ios] を選択します 80

88 Device Farm テスト (Amazon S3 の例) を使 用するように AWS CodePipeline を設定する k. [App file path (アプリファイルパス)] にコンパイルされたアプリケーションパッケージのパスを 入力します パスは テストステージの入力アーティファクトのルートを基準とする相対パスで す このパスは ios-test.ipa に似ています l. [Test type (テストタイプ)] で以下のいずれかを実行します 組み込み Device Farm テストのいずれかを使用している場合は Device Farm プロジェクトで 設定されているテストのタイプを選択します 組み込み Device Farm テストのいずれも使用していない場合は テストのタイプを選択し [Test file path (テストファイルパス)] にテスト定義ファイルのパスを入力します パスは テス トの入力アーティファクトのルートを基準とする相対パスです 81

89 Device Farm テスト (Amazon S3 の例) を使 用するように AWS CodePipeline を設定する m. 残りのフィールドにはテストおよびアプリケーションタイプに適した設定を入力します n. (オプション) [アドバンスト] で テストランの情報の設定を行います 82

90 Device Farm テスト (Amazon S3 の例) を使 用するように AWS CodePipeline を設定する o. [入力アーティファクト] で [MyApp] を選択します AWS CodePipeline コンソールでは パイプライン図の情報アイコンの上にカーソルを置くこと で 各ステージの出力アーティファクトの名前を見つけることができます パイプラインはアプ リケーションを [Source ] ステージから直接テストするため [MyApp] を選択します p. パネルの下部で [アクションの追加] を選択します q. AWS CodePipeline のペインで [パイプラインの変更を保存] [変更の保存] の順に選択します 更新されたパイプラインを表示します 83

91 Device Farm テスト (Amazon S3 の例) を使 用するように AWS CodePipeline を設定する r. 変更を送信してパイプラインのビルドを開始するには [変更のリリース] [リリース] の順に選択 します 84

92 ベストプラクティス AWS CodePipeline のベストプラク ティスとユースケース AWS CodePipeline は多数の製品およびサービスと統合されています 以下のセクションでは AWS CodePipeline のベストプラクティスとユースケース およびこれらの関連製品とサービスについて説明し ます AWS CodePipeline の簡単なビジネスユースケースは サービスの実装方法とユーザーアクセスの制御方 法を理解するのに役立ちます ユースケースは一般的な用語で説明されています 求めている結果を得る ために使用する API を規定していません トピック ベストプラクティス (p. 85) AWS CodePipeline のユースケース (p. 86) ベストプラクティス AWS CodePipeline を使用している場合は こちらのセクションで説明されているベストプラクティスを ご利用ください AWS CodePipeline リソースで使用するセキュリティ のベストプラクティス パイプラインに接続するソースリポジトリには暗号化と認証を使用します こちらがセキュリティで使用 する AWS CodePipeline のベストプラクティスです Amazon S3 ソースバケットを使用するパイプラインを作成する場合は AWS CodePipeline 用として Amazon S3 に保存したアーティファクトのサーバー側の暗号化を設定する (p. 237) で説明されている ように AWS KMS 管理キー (SSE-KMS) を管理して AWS CodePipeline 用に Amazon S3 で保存してい るアーティファクトにサーバー側の暗号化を設定します GitHub ソースリポジトリを使用するパイプラインを作成する場合は GitHub 認証を設定しま す GitHub の認証を設定する (p. 239) で説明されているように AWS 管理の OAuth トークンまたは カスタマー管理の個人アクセストークンを使用することができます AWS CodePipeline リソースで使用するモニタリング とログ記録のベストプラクティス AWS のロギング機能を使用すると ユーザーがアカウントで実行したアクションや使用されたリソースを 確認できます ログファイルは次の情報を表示します アクションが実行された日時 アクションのソース IP アドレス 不適切なアクセス権限が理由で失敗したアクティビティ ロギング機能は次の AWS サービスで使用できます 85

93 Jenkins プラグインを使用するためのベストプラクティス AWS CloudTrail は AWS アカウントが行った または AWS のために行われた AWS API コールとそれ に関連するイベントをログするために使用できます 詳細については AWS CodePipeline での AWS CloudTrail API コールのログ記録 (p. 197) を参照してください Amazon CloudWatch Events は AWS クラウドリソースと AWS で実行されるアプリケーションを監視 するために使用できます 定義したメトリクスに基づいて Amazon CloudWatch Events でアラートを 作成できます 詳細については Amazon CloudWatch Events でパイプラインの状態の変更を検出し 対応する (p. 189) を参照してください Jenkins プラグインを使用するためのベストプラク ティス Jenkins アクションプロバイダーを使用するパイプラインでは このセクションに記載されているベスト プラクティスを使用します Jenkins ビルドサーバー用の別の Amazon EC2 インスタンスと IAM ロールを設定する ベストプラクティスとして パイプラインのビルドまたはテストアクションで Jenkins ビルドプロバイダ を使用する場合は Amazon EC2 インスタンスに Jenkins をインストールし 別の EC2 インスタンスプロ ファイルを設定します インスタンスプロファイルによって Jenkins に付与されている AWS アクセス許 可は Amazon S3 からファイルを取得するなどプロジェクトのタスクを実行するために必要なもののみで あることを確認してください インスタンスプロファイルは Amazon EC2 インスタンスで実行されているアプリケーションに 他の AWS サービスにアクセスするための認証情報を提供します そのため AWS 認証情報 (AWS アクセス キーおよびシークレットキー) を設定する必要はありません Jenkins インスタンスプロファイルのロールを作成する方法については IAM ロールを作成して Jenkins 統合に使用すること (p. 57) のステップを参照してください AWS CodePipeline のユースケース 他の AWS サービスと統合するパイプラインを作成できます これらは Amazon S3 などの AWS サービス や GitHub のようなサードパーティ製品です このセクションは AWS CodePipeline を使用して別の製品 統合を使いコードリリースを自動化する場合の例を示しています アクションタイプ別に整理した AWS CodePipeline との統合の一覧は AWS CodePipeline パイプライン構造のリファレンス (p. 244) を参照 してください トピック Amazon S3 AWS CodeCommit および AWS CodeDeploy で AWS CodePipeline を使用す る (p. 87) Use AWS CodePipeline をサードパーティのアクションプロバイダー (GitHub や Jenkins) と使用す る (p. 87) AWS CodePipeline を AWS CodeStar と使用しコードプロジェクトでパイプラインを構築 (p. 88) AWS CodeBuild で AWS CodePipeline を使用してコードをコンパイル 構築 テストを実 行 (p. 88) Amazon ECS と AWS CodePipeline を使用してクラウドにコンテナベースのアプリケーションを継続 的に配信する (p. 88) Elastic Beanstalk と AWS CodePipeline を使用してクラウドにウェブアプリケーションを継続的に配 信する (p. 88) 86

94 Amazon S3 AWS CodeCommit および AWS CodeDeploy で AWS CodePipeline を使用する AWS Lambda と AWS CodePipeline を使用して Lambda ベースアプリケーションとサーバーレスアプ リケーションを継続的に配信する (p. 89) AWS CloudFormation と AWS CodePipeline を使用してクラウドにテンプレートを継続的に配信す る (p. 89) Amazon S3 AWS CodeCommit および AWS CodeDeploy で AWS CodePipeline を使用する パイプラインを作成すると AWS CodePipeline はパイプラインの各ステージでアクションプロバイダー として作動する AWS 製品やサービスと統合します ウィザードでステージを選択する場合は ソースス テージそしてビルドまたはデプロイステージを少なくても 1 つ選ぶ必要があります ウィザードは変更す ることができないデフォルト名を使用してステージを作成します こうしたステージの名前は ウィザー ドで 3 つの完全なステージをセットアップした際に作成されたものです ソース というデフォルト名を使用したソースアクションステージ ビルド というデフォルト名を使用したビルドアクションステージ ステージング というデフォルト名を使用したデプロイアクションステージ このガイドのチュートリアルを使用してパイプラインを作成しステージを指定できます チュートリアル: シンプルなパイプラインを作成する (Amazon S3 バケットの場合) (p. 27) のステップ は ウィザードを使用して Amazon S3 リポジトリがソースプロバイダーとなる ソース と ステー ジング という 2 つのデフォルトステージを含むパイプラインの作成をサポートします このチュート リアルで AWS CodeDeploy を使用するパイプラインを作成し Amazon Linux を実行している Amazon EC2 インスタンスに Amazon S3 バケットからのサンプルアプリケーションをデプロイすることができ ます チュートリアル: シンプルなパイプラインを作成する (AWS CodeCommit リポジトリの場合) (p. 44) の ステップは ウィザードを使用し AWS CodeCommit リポジトリをソースプロバイダーとして利用す る ソース ステージを使ったパイプラインの作成をサポートします このチュートリアルで AWS CodeDeploy を使用するパイプラインを作成し Amazon Linux を実行している Amazon EC2 インスタ ンスに AWS CodeCommit リポジトリからのサンプルアプリケーションをデプロイすることができま す Use AWS CodePipeline をサードパーティのアクショ ンプロバイダー (GitHub や Jenkins) と使用する GitHub や Jenkins といったサードパーティ製品と統合するパイプラインを作成できます チュートリアル: 4 ステージのパイプラインを作成する (p. 56) のステップは 次の操作を実行するパイプラインの作成方法 を示しています GitHub リポジトリからソースコードを取得 Jenkins を使用してソースコードの構築とテストを実行 AWS CodeDeploy を使用して Amazon Linux または Microsoft Windows Server を実行している Amazon EC2 インスタンスに ビルトとテスト済みのソースコードをデプロイします 87

95 AWS CodePipeline を AWS CodeStar と使用 しコードプロジェクトでパイプラインを構築 AWS CodePipeline を AWS CodeStar と使用しコード プロジェクトでパイプラインを構築 AWS CodeStar は AWS でソフトウェア開発プロジェクトを管理するために 統合されたユーザーイン ターフェイスを提供するクラウドベースサービスです AWS リソースをプロジェクト開発のツールチェー ンと組み合わせるため AWS CodeStar は AWS CodePipeline と動作しますAWS CodeStar ダッシュボー ドを使用して パイプライン リポジトリ ソースコード ビルドスペックファイル デプロイ方法を自 動作成したり 完全なコードプロジェクトで必要なインスタンスまたはサーバーレスインスタンスをホス トできます AWS CodeStar プロジェクトを作成するには コード言語とデプロイしたいアプリケーションのタイプを 選択します ウェブアプリケーション ウェブサービス Alexa スキルといったプロジェクトタイプを作 成できます 必要に応じていつでも任意の IDE を AWS CodeStar ダッシュボードで統合できます チームメンバーの 追加や削除を行ったり プロジェクトでチームメンバーのアクセス権限を管理することもできます AWS CodeStar を使用してサーバーレスアプリケーションのサンプルパイプラインを作成するためのチュートリ アルについては チュートリアル: AWS CodeStar でサーバーレスプロジェクトを作成および管理する を 参照してください AWS CodeBuild で AWS CodePipeline を使用して コードをコンパイル 構築 テストを実行 AWS CodeBuild はクラウドにあるマネージド型のビルドサービスで サーバーやシステムを必要とせず にコードを構築したりテストを実行できるようにします AWS CodeBuild と AWS CodePipeline を使用 して ソースコードに変更があるたびにパイプラインを介してソフトウェアビルドの継続デリバリーを 可能にするため リビジョンの実行を自動化できます 詳細については AWS CodePipeline と AWS CodeBuild を使用してコードのテストとビルドを実行する を参照してください Amazon ECS と AWS CodePipeline を使用してクラウ ドにコンテナベースのアプリケーションを継続的に配 信する Amazon ECS はコンテナ管理サービスで クラウド内の Amazon ECS インスタンスにコンテナベースの アプリケーションをデプロイできるようにします Amazon ECS と AWS CodePipeline を使用して ソー スイメージのリポジトリに変更があるたびにパイプラインを介してコンテナベースのアプリケーションの デプロイを継続的に実行できるようにするため リビジョンの実行を自動化できます 詳細については チュートリアル: AWS CodePipeline を使用した継続的なデプロイ を参照してください Elastic Beanstalk と AWS CodePipeline を使用してク ラウドにウェブアプリケーションを継続的に配信する Elastic Beanstalk はウェブサーバーでウェブアプリケーションとサービスをデプロイできるようにするコ ンピューティングサービスです Elastic Beanstalk と AWS CodePipeline を使用してアプリケーション環 境でウェブアプリケーションを継続的にデプロイするAWS CodeStar を使用して Elastic Beanstalk デプロ イアクションでパイプラインを作成することもできます 88

96 AWS Lambda と AWS CodePipeline を使用 して Lambda ベースアプリケーションとサー バーレスアプリケーションを継続的に配信する AWS Lambda と AWS CodePipeline を使用して Lambda ベースアプリケーションとサーバーレスアプ リケーションを継続的に配信する AWS CodePipeline と AWS Lambda を使用して Lambda ベースのアプリケーションのデプロイメント を自動化する で説明されているように AWS Lambda 関数を呼び出すことができます AWS Lambda と AWS CodeStar を使用して サーバーレスアプリケーションをデプロイするためのパイプラインを作成す ることもできます AWS CloudFormation と AWS CodePipeline を使用し てクラウドにテンプレートを継続的に配信する AWS CodePipeline を AWS CloudFormation とともに使用して 継続的な配信と自動化を行うことがで きます 詳細については AWS CodePipeline を使用した継続的配信 を参照してください AWS CloudFormation は AWS CodeStar で作成されたパイプラインのテンプレート作成にも使用されます 89

97 AWS CodePipeline でパイプラインの実行を開始する AWS CodePipeline でのパイプライン の使用 自動リリースプロセスを定義するには ソフトウェアの変更がリリースプロセスをどのように通過するか を記述するワークフロー構造であるパイプラインを作成します パイプラインは 設定するステージおよ びアクションで構成されます AWS CodePipeline が提供するデフォルトオプションに加えて ビルド デプロイ テストまた は呼び出しステージを追加する場合 パイプラインと使用するためにすでに作成したカスタム アクションを選択できます カスタムアクションは 社内で開発したビルドプロセスやテストス イートを実行する等のタスクに使用できます プロバイダーリストのカスタムアクションの異な るバージョンを区別できるよう バージョン識別子が含まれています 詳細については AWS CodePipeline でのカスタムアクションの作成と追加 (p. 146) を参照してください パイプラインを作成する前に まずはAWS CodePipeline の使用開始 (p. 9)のステップを完了する必要があ ります パイプラインの詳細については AWS CodePipeline の概念 (p. 4) および AWS CodePipeline の チュートリアル (p. 27) を参照してください また AWS CLI を使用してパイプラインを作成する場合 は AWS CodePipeline パイプライン構造のリファレンス (p. 244) を参照してください パイプライ ンのリストを表示するには AWS CodePipeline でパイプラインの詳細と履歴を表示する (p. 129) を参照 してください トピック AWS CodePipeline でパイプラインの実行を開始する (p. 90) AWS CodePipeline でパイプラインを作成する (p. 113) AWS CodePipeline でパイプラインを編集する (p. 122) AWS CodePipeline でパイプラインの詳細と履歴を表示する (p. 129) AWS CodePipeline のパイプラインの削除 (p. 134) AWS CodePipeline での実行履歴の表示 (p. 135) 他の AWS アカウントからリソースを使用するパイプラインを AWS CodePipeline に作成 (p. 136) AWS CodePipeline でパイプラインの実行を開始す る パイプラインの実行が開始されると パイプラインのあらゆるステージとアクションでリビジョンが実行 されます パイプラインの実行を開始する方法は 2 つあります 自動: 指定した変更検出方法を使用して リポジトリに変更が加えられたときにパイプラインを自動的に 開始できます または スケジュールに基づいてパイプラインを自動的に開始できます 自動変更検出 方法を以下に示します 90

98 パイプラインの自動開始に使用される変更検出方法 コンソールを使用して AWS CodeCommit ソースリポジトリまたは Amazon S3 ソースバケットがあ るパイプラインを作成する場合 AWS CodePipeline によって リソースが変更されたときにパイ プラインを開始する Amazon CloudWatch Events ルールが作成されます これは推奨される変更検 出方法です AWS CLI を使用してパイプラインを作成する場合 定期的にソースをチェックするこ とで自動的にパイプラインを開始する変更検出方法をデフォルトとします これによって 定期的 なチェックを無効にして しゅどうで追加リソースを作成することが推奨されます 詳細について は CloudWatch イベント ルールを使用して AWS CodeCommit パイプラインを自動的に開始す る (p. 92) を参照してください コンソールを使用して GitHub リポジトリがあるパイプラインを作成する場合 AWS CodePipeline は ソース変更時にパイプラインを開始するウェブフックを作成します これは推奨される変更検出方法 です AWS CLI を使用してパイプラインを作成する場合 定期的にソースをチェックすることで自動 的にパイプラインを開始する変更検出方法をデフォルトとします これによって 定期的なチェック を無効にして しゅどうで追加リソースを作成することが推奨されます 詳細については ウェブ フックを使用して自動的に GitHub パイプラインを開始する (p. 105) を参照してください 手動: AWS CodePipeline でパイプラインを手動で開始する (p. 110) の説明にあるとおり コン ソールまたは AWS CLI を使用してパイプラインを手動で開始できます デフォルトでは 変更検出方法を使用して パイプラインを自動で開始するように設定されています パイプラインは 定義したソースリポジトリとブランチに変更があったときのみ実行されます トピック パイプラインの自動開始に使用される変更検出方法 (p. 91) CloudWatch イベント ルールを使用して AWS CodeCommit パイプラインを自動的に開始す る (p. 92) CloudWatch イベント ルールを使用して Amazon S3 パイプラインを自動的に開始する (p. 99) ウェブフックを使用して自動的に GitHub パイプラインを開始する (p. 105) 定期的なチェックを使用して自動的にパイプラインを開始する (p. 110) AWS CodePipeline でパイプラインを手動で開始する (p. 110) Amazon CloudWatch Events を使用して スケジュールに基づいてパイプラインを自動的に実行す る (p. 111) パイプラインの自動開始に使用される変更検出方法 パイプラインを作成または更新するとき ソースリポジトリの変更に対応するために使用する変更検出方 法を指定します 選択により パイプラインを自動的に開始する方法が決まります 変更検出方法を指定するには コンソール (p. 123) CLI (p. 125) または CloudFormation を使用しま す 送信元 検出方法 説明 Amazon S3 Amazon CloudWatch リポジトリに変更が Events (推奨).これ あるとすぐにパイプ は コンソールで作成 ラインがトリガーさ あるいは編集されたデ れます バケット内 フォルトの S3 パイプ のイベントは AWS ラインです CloudTrail によって 91 追加のリ ソースが必 要ですか? パイプラインを推奨 変更検出方法に移行 する方法 は い Amazon CloudWatch Events ルールお よび AWS ソースの変更を定 期的にチェックして いるパイプラインを 移行するには 変 更の検出に Amazon CloudWatch Events

99 CloudWatch イベント ルールを使用して AWS CodeCommit パイプラインを自動的に開始する 送信元 AWS CodeCommit GitHub 検出方法 説明 追加のリ ソースが必 要ですか? パイプラインを推奨 変更検出方法に移行 する方法 フィルタされ Amazon CloudWatch Events ルールによって開始す るパイプラインがトリ ガーされます 定期的なチェックより も速く より細かな設 定ができます CloudTrail 証 跡を適用す る必要があ ります を使用するように Amazon S3 パイ プラインを設定す る (p. 104) を参 照してください 定期的なチェック AWS CodePipeline は定 期的にソースに接触しま す いいえ Amazon CloudWatch Events (推奨).これ は コンソールで作 成あるいは編集され たデフォルトの AWS CodeCommit パイプ ラインです リポジトリに変更があ るとすぐにパイプライ ンがトリガーされま す 定期的なチェックより も速く より細かな設 定ができます は い Amazon CloudWatch Events ルー ルを適用す る必要があ ります 定期的なチェック AWS CodePipeline は定 期的にソースリポジトリ にコンタクトします いいえ ウェブフック (推奨) リポジトリに変更があ これは コンソール るとすぐにパイプライ で作成あるいは編集 ンがトリガーされま されたデフォルトの す GitHub パイプライン 定期的なチェックより です も速く より細かな設 定ができます はい 定期的なチェック いいえ AWS CodePipeline は定 期的にソースリポジトリ にコンタクトします ソースの変更を定 期的にチェックして いるパイプラインを 移行するには 変 更の検出に Amazon CloudWatch Events を使用するように AWS CodeCommit パイプラインを設定 する (p. 98) を 参照してください ソースの変更を定期 的にチェックしてい るパイプラインを移 行するには 変 更の検出にウェブ フックを使用する ように GitHub パイ プラインを設定す る (p. 109) を参 照してください CloudWatch イベント ルールを使用して AWS CodeCommit パイプラインを自動的に開始する Amazon CloudWatch Events を使用すると ルールまたはスケジュール条件が満たされたときに パイプ ラインをトリガーして自動的に開始することができます Amazon S3 または AWS CodeCommit ソースの パイプラインの場合 Amazon CloudWatch Events ルールがソースの変更を検出し パイプラインを開始 します コンソールを使用してパイプラインを作成または変更すると ルールおよびすべての関連付けら れるリソースが作成されます CLI または AWS CloudFormation で Amazon S3 や AWS CodeCommit パ イプラインを作成または変更する場合は 以下の手順を使用して Amazon CloudWatch Events ルールお よびすべての関連付けられるリソースを手動で作成する必要があります Amazon CloudWatch Events で パイプラインに定義されたソースの状態の変化を検出して対応するルー ルを作成します ルールを作成するには 92

100 CloudWatch イベント ルールを使用して AWS CodeCommit パイプラインを自動的に開始する 1. パイプラインのソースリポジトリをイベントソースとして使用する Amazon CloudWatch Events ルール を作成します 2. AWS CodePipeline をターゲットとして追加します 3. パイプラインを開始するアクセス許可を Amazon CloudWatch Events に付与します ルールを構築する際に コンソールの [イベントパターンのプレビュー] ペイン (または AWS CLI の --event-pattern 出力) に JSON 形式のイベントフィールドが表示されます 次のサンプル AWS CodeCommit イベントパターンは この JSON 構造を使用しています "source": [ "aws.codecommit" ], "detail-type": [ "CodeCommit Repository State Change" ], "resources": [ "CodeCommitRepo_ARN" ], "detail": "event": [ "referencecreated", "referenceupdated"], "referencetype":["branch"], "referencename": ["branch_name"] 以下に示しているのは [イベント] ウィンドウに表示された "master:" という名前のブランチを含む "MyTestRepo" リポジトリのサンプル AWS CodeCommit イベントパターンです "source": [ "aws.codecommit" ], "detail-type": [ "CodeCommit Repository State Change" ], "resources": [ "arn:aws:codecommit:us-west-2:80398example:mytestrepo" ], "detail": "referencetype": [ "branch" ], "referencename": [ "master" ] イベントパターンでは 以下のフィールドを使用します source: は aws.codecommit をイベントソースとして含んでいる必要があります detail-type: には使用可能なイベントタイプが表示されます (CodeCommit Repository State Change) resources: にはリポジトリ ARN が含まれます detail: には リポジトリのブランチ情報 referencetype および referencename が含まれていま す トピック 93

101 CloudWatch イベント ルールを使用して AWS CodeCommit パイプラインを自動的に開始する AWS CodeCommit パイプラインを開始する CloudWatch イベント ルールを作成する (コンソー ル) (p. 94) AWS CodeCommit パイプライン (CLI) を開始する CloudWatch イベント ルールを作成する (p. 96) 変更の検出に Amazon CloudWatch Events を使用するように AWS CodeCommit パイプラインを設定 する (p. 98) AWS CodeCommit パイプラインを開始する CloudWatch イベン ト ルールを作成する (コンソール) AWS CodePipeline のオペレーションで使用する CloudWatch イベント ルールを作成するには 1. CloudWatch コンソールを開きます 2. ナビゲーションペインの [Events] を選択します 3. [ルールの作成] を選択してから [イベントソース] の [サービス名] ドロップダウンリストから [CodeCommit] を選択します 4. サービス名は イベントリソースを所有するサービスを指定します たとえば パイプラインに関連 付けられた AWS CodeCommit リポジトリに変更があるとパイプラインがトリガーされるようにする には AWS CodeCommit を選択します 5. [イベントタイプ] ドロップダウンリストで [CodeCommit リポジトリの状態変更] を選択します 94

102 CloudWatch イベント ルールを使用して AWS CodeCommit パイプラインを自動的に開始する 6. すべてのリポジトリに適用するルールを作成するには [Any resource] を選択します 1 つ以上のリポジトリに適用されるルールを作成するには [Specific resource(s) by ARN] を選択して から ARN を入力します AWS CodeCommit リポジトリの ARN は AWS CodeCommit コンソールの [設定] ページで 見つけることができます リポジトリに関連付けるブランチを指定するには [編集] を選択し リソースタイプブランチおよ びブランチ名を入力します detail のイベントパターンオプションを使用します 前の例では 95

103 CloudWatch イベント ルールを使用して AWS CodeCommit パイプラインを自動的に開始する master という名前の AWS CodeCommit リポジトリブランチの詳細オプションを示しています [Save] を選択します [イベントパターンのプレビュー] ペインで ルールを表示します 7. [ターゲット] エリアで [CodePipeline] を選択します 8. このルールによってトリガーされたときに開始するパイプラインの パイプライン ARN を入力しま す get-pipeline コマンドを実行した後 メタデータ出力でパイプライン ARN を見つけるこ とができます パイプライン ARN はこの形式で作成されます arn:aws:codepipeline:region:account:pipeline-name パイプライン ARN の例: arn:aws:codepipeline:us-east-2:80398example:myfirstpipeline 9. Amazon CloudWatch Events ルールに関連付けられたターゲットを呼び出すための Amazon CloudWatch Events アクセス許可を付与する IAM サービスロールを作成または指定します (この場 合 ターゲットは AWS CodePipeline) トリガーされたときにパイプラインの実行を開始するための Amazon CloudWatch Events アクセス 許可を与えるサービスロールを作成するには [この特定のリソースに対して新しいロールを作成す る] を選択します トリガーされたときにパイプラインの実行を開始するための Amazon CloudWatch Events アクセス 許可を与えるサービスロールを指定するには [既存のロールの使用] を選択します 10. ルール設定を確認して 要件を満たしていることを確認します 11. [Configure details] を選択します 12. [Configure rule details] ページでルールの名前と説明を入力してから [State] を選択してルールを有効 化します 13. ルールが適切であることを確認したら [Create rule] を選択します AWS CodeCommit パイプライン (CLI) を開始する CloudWatch イベント ルールを作成する AWS CLI を使用してルールを作成するには 以下を指定して put-rule コマンドを呼び出します 作成中のルールを一意に識別する名前 この名前は AWS アカウントに関連付けられた AWS CodePipeline で作成するすべてのパイプラインで一意である必要があります ルールで使用するソースと詳細フィールドのイベントパターン 詳細については Amazon CloudWatch Events およびイベントパターン を参照してください AWS CodeCommit をイベントソースとして AWS CodePipeline をターゲットとし て CloudWatch イベント ルールを作成するには 1. AWS CodePipeline を使用してルールを呼び出すための Amazon CloudWatch Events アクセス許可を 追加します 詳細については Amazon CloudWatch Events のリソースベースのポリシーを使用す る を参照してください a. 次のサンプルを使用して CloudWatch イベント がサービスロールを引き受けることができる信 頼ポリシーを作成します 信頼ポリシー名は trustpolicyforcwe.json です "Version": " ", "Statement": [ 96

104 CloudWatch イベント ルールを使用して AWS CodeCommit パイプラインを自動的に開始する b. ] "Effect": "Allow", "Principal": "Service": "events.amazonaws.com", "Action": "sts:assumerole" 以下のコマンドを使用して Role-for-MyRule ロールを作成し 信頼ポリシーをアタッチしま す aws iam create-role --role-name Role-for-MyRule --assume-role-policy-document file://trustpolicyforcwe.json c. このサンプルに示すように アクセス許可ポリシー JSON を MyFirstPipeline という名前のパ イプラインに対して作成します アクセス許可ポリシーに permissionspolicyforcwe.json と いう名前を付けます d. "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "codepipeline:startpipelineexecution" ], "Resource": [ "arn:aws:codepipeline:us-west-2:80398example:myfirstpipeline" ] ] 次のコマンドを使用して CodePipeline-Permissions-Policy-for-CWE アクセス許可ポリシーを Role-for-MyRule ロールにアタッチします aws iam put-role-policy --role-name Role-for-MyRule --policy-name CodePipelinePermissions-Policy-For-CWE --policy-document file://permissionspolicyforcwe.json 2. put-rule コマンドを呼び出し --name および --event-pattern パラメータを含めます 以下の構文を使用します aws events put-rule --name "rule_name" --event-pattern ""source":["aws.service_name"], "detail-type":["event_type"], "resources":"repository_arn"]" 例: 以下のサンプルコマンドは MyCodeCommitRepoRule というルールを作成するために --eventpattern を使用します aws events put-rule --name "MyCodeCommitRepoRule" --event-pattern "\"source\": [\"aws.codecommit\"],\"detail-type\":[\"codecommit Repository State Change\"],\"detail \":\"referencetype\":[\"branch\"],\"referencename \":[\"master\"]" 3. AWS CodePipeline をターゲットとして追加するには put-targets コマンドを呼び出し 次のパラ メータを含めます 97

105 CloudWatch イベント ルールを使用して AWS CodeCommit パイプラインを自動的に開始する --rule パラメータは put-rule を使用して作成した rule_name で使用されます --targets パラメータは ターゲットリストのリスト Id とターゲットパイプラインの ARN で使用さ れます 以下の構文を使用します aws events put-targets --rule rule_name --targets Id,ARN 例: 次のサンプルコマンドでは MyCodeCommitRepoRule と呼ばれるルールに対して指定し ターゲッ ト Id は 1 番で構成されています これは ルールのターゲットのリストが何であるかを示し この場 合は ターゲット 1 です また 以下のサンプルコマンドは リポジトリ内で何かが変更されたときに 開始するパイプラインの ARN の例をターゲットに指定します aws events put-targets --rule MyCodeCommitRepoRule --targets Id=1,Arn=arn:aws:codepipeline:us-west-2:80398EXAMPLE:TestPipeline 変更の検出に Amazon CloudWatch Events を使用するように AWS CodeCommit パイプラインを設定する AWS CodeCommit リポジトリを使用するパイプラインの変更検出方法として イベントベースの Amazon CloudWatch Events ルールを使用できるようになりました Amazon CloudWatch Events は リアルタイ ムで変更を検出し パイプラインを開始します この機能を使用するには 既存のパイプラインを更新す る必要があります コンソールでパイプラインを作成または編集するときに AWS CodePipeline はイベ ントベースの Amazon CloudWatch Events ルールを作成します このテーブルでは AWS CodeCommit パイプラインの手順を紹介しています 方法 Instructions これ以上 何もする必要はあ りませんか コンソールでパイプラ インを設定する 1. コンソールでパイプラインを開きます [Edit] を選択します AWS CodeCommit ソースアクションの横 にある鉛筆アイコンを選択します [Update] を選択します Amazon CloudWatch Events ルールが作成されます これ以上 何もする必要はあ りません [パイプラインの変更を保存する] を選択 します パイプラインの編集 (コンソールの場 合) (p. 123) を参照してください CLI でパイプラインを 設定する update-pipeline コマンドを使用し て PollForSourceChanges パラメータを false に設定します Amazon CloudWatch Events ルールを作成する必要があり ます パイプラインの表示 (AWS CLI の場 合) (p. 125) を参照してください CloudWatch イベント ルールを使用して AWS CodeCommit パイプラインを 98

106 CloudWatch イベント ルールを使用して Amazon S3 パイプラインを自動的に開始する 方法 Instructions これ以上 何もする必要はあ りませんか 自動的に開始する (p. 92) を参照してください AWS CloudFormation でパイプラインを設定 する AWS CloudFormation リソーススタックを更 新します Amazon CloudWatch Events とは? を参照 してください Amazon CloudWatch Events ルールを作成する必要があり ます CloudWatch イベント ルールを使用して AWS CodeCommit パイプラインを 自動的に開始する (p. 92) を参照してください CloudWatch イベント ルールを使用して Amazon S3 パイプラインを自動的に開始する ソースコードの変更を検出してパイプラインを自動的に開始するようにトリガーするには Amazon CloudWatch Events を使用する必要があります パイプラインに Amazon S3 ソースがある場合に は Amazon S3 ソースバケット内のオブジェクトにイベントのログを書き込むために対応する AWS CloudTrail 証跡を作成する必要があります AWS CloudTrail は Amazon S3 ソースバケットでイベントをログしてフィルタリングするサービスで す 証跡はバケットでイベントをフィルタリングし フィルタリングされたソースの変更を Amazon CloudWatch Events ルールに送信します Amazon CloudWatch Events ルールはソースの変更を検出し パイプラインを開始します Amazon S3 ソースのパイプラインの場合 Amazon CloudWatch Events ルールがソースの変更 を検出し 変更発生時にパイプラインを開始します コンソールを使用してパイプラインを作 成または変更すると ルールおよびすべての関連付けられるリソースが作成されます CLI ま たは AWS CloudFormation で Amazon S3 パイプラインを作成または変更する場合は Amazon CloudWatch Events ルール IAM ロール および AWS CloudTrail 証跡を手動で作成する必要が あります 要件: 証跡を作成していない場合は 既存の AWS CloudTrail 証跡を使用して Amazon S3 ソースバケットでイ ベントのログを記録し フィルタリングされたイベントを Amazon CloudWatch Events ルールに送信す る必要があります AWS CloudTrail がログファイルを格納できる場所で既存の S3 バケットを作成または使用する必要があ ります Amazon S3 バケットにログファイルを配信するためには AWS CloudTrail に必要なアクセス 権限がある必要があり リクエスタ支払い バケットとして設定することはできません Amazon S3 バ ケットをコンソールでの証跡の作成あるいは更新の一部として作成するとき AWS CloudTrail はバケッ トに必要なアクセス許可を自動的にアタッチします 詳細については CloudTrail の Amazon S3 バ ケットポリシー を参照して ください Amazon S3 パイプラインを開始する CloudWatch イベント ルー ルを作成する (コンソール) CloudWatch イベント でルールを設定する前に AWS CloudTrail 証跡を作成する必要があります 詳細に ついては コンソールで証跡を作成する を参照してください 99

107 CloudWatch イベント ルールを使用して Amazon S3 パイプラインを自動的に開始する 証跡を作成するには 1. AWS CloudTrail コンソールを開きます 2. ナビゲーションペインで [Trails] を選択します 3. [Create Trail (証跡の作成)] を選択します [Trail name] に 証跡の名前を入力します 4. [Apply trail to all regions (全てのリージョンで証跡を適用)] では [No] を選択します 5. [Data events (データイベント)] で [S3] が選択されていることを確認します フォルダ内のすべてのオ ブジェクトのデータイベントをログ記録するために Amazon S3 バケットおよびオブジェクトプレ フィックス (フォルダ名) を指定します 証跡ごとに 最大 250 個の Amazon S3 オブジェクトを追加 できます 6. [Read/Write events (読み取り/書き込みイベント)] で [なし] を選択します 7. 指定するバケットおよびプレフィックスで [書き込み] オプションの The trail records Amazon S3 object-level API activity (GetObject と PutObject など) を選択します 8. [保存場所] でログファイルを保存するために使用するバケットを作成あるいは指定します デフォル トでは Amazon S3 バケットとオブジェクトはプライベートです リソース所有者 (バケットを作成 した AWS アカウント) のみが バケットとそのオブジェクトにアクセスできます バケットには バ ケット内のオブジェクトにアクセスできる AWS CloudTrail 権限を付与するリソースポリシーがある 必要があります 9. 証跡が適切であることを確認したら [作成] を選択します S3 ソースのパイプラインをターゲットとする CloudWatch イベント ルールを作成するには 1. CloudWatch コンソールを開きます 2. ナビゲーションペインの [Events] を選択します 3. [イベントパターン] を選択したら [サービス別のイベントに一致するイベントパターンの構築] を選 択します 4. [イベントソース] で [サービス名] ドロップダウンリストから [Simple Storage Service (S3) (シンプ ルストレージサービス (S3))] を選択します 5. [イベントタイプ] ドロップダウンリストで [Object Level Operations] を選択し ます 6. [特定のオペレーション] を選択したら [PutObject] を選択します [イベントパターンのプレビュー] ペインで [編集] を選択します この例の myobject.zip という名のオ ブジェクトに示されるように バケット プレフィックス (フォルダ名) オブジェクトの名前に続い て resources パラメータを指定して イベントパターンを編集します リソースを指定するために [編集] ウィンドウを使用する場合 ルールはカスタムイベントパターンを使用するように更新されま す 100

108 CloudWatch イベント ルールを使用して Amazon S3 パイプラインを自動的に開始する 7. [ターゲット] エリアで [CodePipeline] を選択します 8. このルールによってトリガーされたときに開始するパイプラインの パイプライン ARN を入力しま す get-pipeline コマンドを実行した後で メタデータ出力でパイプライン ARN を見つける ことができます パイプライン ARN はこの形式で作成されます arn:aws:codepipeline:region:account:pipeline-name パイプライン ARN の例: arn:aws:codepipeline:us-east-2:80398example:myfirstpipeline 9. 次のいずれかを選択して Amazon CloudWatch Events ルールに関連付けられたターゲットを呼び出 すための Amazon CloudWatch Events アクセス許可を付与する IAM サービスロールを作成または指定 します (この場合 ターゲットは AWS CodePipeline) トリガーされたときにパイプラインの実行を開始するための Amazon CloudWatch Events アクセス 許可を与えるサービスロールを作成するには [この特定のリソースに対して新しいロールを作成す る] を選択します トリガーされたときにパイプラインの実行を開始するための Amazon CloudWatch Events アクセス 許可を与えるサービスロールを指定するには [既存のロールの使用] を選択します 10. ルールを見直して 要件を満たしていることを確認します 11. [Configure details] を選択します 12. [Configure rule details] ページでルールの名前と説明を入力してから [State] を選択してルールを有効 化します 13. ルールが適切であることを確認したら [Create rule] を選択します Amazon S3 パイプライン (CLI) を開始する CloudWatch イベン ト ルールを作成する AWS CloudTrail 証跡を作成して ログ記録を有効にするには AWS CLI を使用して証跡を作成するには 以下を指定して create-trail コマンドを呼び出します 証跡名 AWS CloudTrail にバケットポリシーをすでに適用しているバケットです CLI で証跡を作成する詳細については Creating a Trail with the AWS Command Line Interface (AWS コ マンドラインインターフェースで証跡を作成する) を参照してください 1. create-trail コマンドを呼び出し --name および --s3-bucket-name パラメータを含めます 以下の構文を使用します aws cloudtrail create-trail --name trail_name --s3-bucket-name bucket_name 悪い例: 以下のサンプルコマンドは --name および --s3-bucket-name を使用して my-trail という名前の証跡 と mybucket という名前のバケットを作成します aws cloudtrail create-trail --name my-trail --s3-bucket-name mybucket 101

109 CloudWatch イベント ルールを使用して Amazon S3 パイプラインを自動的に開始する 2. start-logging コマンドを呼び出し --name パラメータを含めます 悪い例: 以下のサンプルコマンドは --name を使用して my-trail という名前の証跡のログ記録を開始します aws cloudtrail start-logging --name my-trail 3. put-event-selectors コマンドを呼び出し --trail-name および --event-selectors パラメータを含めま す イベントセレクタを使用してソースバケットでログ記録するデータイベントを指定し このイベ ントを Amazon CloudWatch Events ルールに送信します 悪い例: 以下のサンプルコマンドは --trail-name および --event-selectors を使用してソースバケットと mybucket/myfolder という名前のプレフィックスにデータイベントの管理を指定します aws cloudtrail put-event-selectors --trail-name my-trail --event-selectors '[ "ReadWriteType": "WriteOnly", "IncludeManagementEvents":false, "DataResources": [ "Type": "AWS::S3::Object", "Values": ["arn:aws:s3:::mybucket/myfolder/ file.zip"] ] ]' Amazon S3 をイベントソース AWS CodePipeline をターゲットとする CloudWatch イベント ルールを作成し アクセス権限ポリシーを適用するには 1. AWS CodePipeline を使用してルールを呼び出すための Amazon CloudWatch Events アクセス許可を 付与します 詳細については Amazon CloudWatch Events のリソースベースのポリシーを使用す る を参照してください a. 次のサンプルを使用して CloudWatch イベント がサービスロールを引き受けるように信頼ポリ シーを作成します これを trustpolicyforcwe.json と名付けます b. "Version": " ", "Statement": [ "Effect": "Allow", "Principal": "Service": "events.amazonaws.com", "Action": "sts:assumerole" ] 以下のコマンドを使用して Role-for-MyRule ロールを作成し 信頼ポリシーをアタッチしま す aws iam create-role --role-name Role-for-MyRule --assume-role-policy-document file://trustpolicyforcwe.json c. このサンプルに示すように アクセス許可ポリシー JSON を MyFirstPipeline という名前のパ イプラインに対して作成します アクセス許可ポリシーに permissionspolicyforcwe.json と いう名前を付けます "Version": " ", "Statement": [ 102

110 CloudWatch イベント ルールを使用して Amazon S3 パイプラインを自動的に開始する d. ] "Effect": "Allow", "Action": [ "codepipeline:startpipelineexecution" ], "Resource": [ "arn:aws:codepipeline:us-west-2:80398example:myfirstpipeline" ] 次のコマンドを使用し 新しい CodePipeline-Permissions-Policy-for-CWE アクセス許可ポリ シーを 作成した Role-for-MyRule ロールにアタッチします aws iam put-role-policy --role-name Role-for-MyRule --policy-name CodePipelinePermissions-Policy-For-CWE --policy-document file://permissionspolicyforcwe.json 2. put-rule コマンドを呼び出し --name および --event-pattern パラメータを含めます 以下の構文を使用します aws events put-rule --name "rule_name" --event-pattern ""source":["aws.service_name"], "detail-type":["event_type"], "resources":"repository_arn"]" 以下のサンプルコマンドは MyS3SourceRule というルールを作成するために --event-pattern を使用 します aws events put-rule --name "MyS3SourceRule" --event-pattern "\"source\":[\"aws.s3\"], \"detail-type\":[\"aws API Call via CloudTrail\"],\"detail\":\"eventSource\": [\"s3.amazonaws.com\"],\"eventname\":[\"putobject\"],\"resources\":\"arn\": [\"arn:aws:s3:::mybucket/myfolder/file.zip\"] 3. AWS CodePipeline をターゲットとして追加するには put-targets コマンドを呼び出し 次のパラ メータを含めます --rule パラメータは put-rule を使用して作成した rule_name で使用されます --targets パラメータは ターゲットリストのリスト Id とターゲットパイプラインの ARN で使用さ れます 以下の構文を使用します aws events put-targets --rule rule_name --targets Id,ARN 次のサンプルコマンドでは MyS3SourceRule と呼ばれるルールに対して指定し ターゲット Id は 1 番で構成されています これは ルールのターゲットのリストが何であるかを示し この場合は ター ゲット 1 です また 以下のサンプルコマンドは リポジトリ内で何かが変更されたときに開始する パイプラインの ARN の例をターゲットに指定します aws events put-targets --rule MyS3SourceRule --targets Id=1,Arn=arn:aws:codepipeline:us-west-2:80398EXAMPLE:TestPipeline 103

111 CloudWatch イベント ルールを使用して Amazon S3 パイプラインを自動的に開始する 変更の検出に Amazon CloudWatch Events を使用するように Amazon S3 パイプラインを設定する Amazon S3 ソースを使用するパイプラインの変更検出方法として イベントベースの Amazon CloudWatch Events ルールを使用できるようになりました Amazon CloudWatch Events は リアルタ イムで変更を検出し パイプラインを開始します この機能を使用するには 既存のパイプラインを更 新する必要があります コンソールでパイプラインを作成または編集するときに AWS CodePipeline は Amazon CloudWatch Events のイベントベースのルールおよび AWS CloudTrail 証跡を作成します このテーブルでは Amazon S3 パイプラインの手順を紹介しています 方法 Instructions これ以上 何もする必要はあ りませんか コンソールでパイプラ インを設定する 1. コンソールでパイプラインを開きます [Edit] を選択します Amazon S3 ソースアクションの横にある 鉛筆アイコンを選択します [変更が発生したときに Amazon CloudWatch イベントを使用してパイプラ インを自動的に開始する] を選択します [Update] を選択します Amazon CloudWatch Events ルールと AWS CloudTrail 証跡 が作成されます これ以上 何もする必要はあ りません [パイプラインの変更を保存する] を選択 します パイプラインの編集 (コンソールの場 合) (p. 123) を参照してください CLI でパイプラインを 設定する update-pipeline コマンドを使用し て PollForSourceChanges パラメータを false に設定します パイプラインの表示 (AWS CLI の場 合) (p. 125) を参照してください 以下を作成する必要がありま す AWS CloudTrail 証跡 Amazon CloudWatch Events ルール CloudWatch イベント ルー ルを使用して Amazon S3 パ イプラインを自動的に開始す る (p. 99) を参照してくだ さい AWS CloudFormation でパイプラインを設定 する AWS CloudFormation リソーススタックを更 新します 以下を作成する必要がありま す Amazon CloudWatch Events とは? を参照 してください AWS CloudTrail 証跡 Amazon CloudWatch Events ルール CloudWatch イベント ルー ルを使用して Amazon S3 パ イプラインを自動的に開始す る (p. 99) を参照してくだ さい 104

112 ウェブフックを使用して自動的 に GitHub パイプラインを開始する ウェブフックを使用して自動的に GitHub パイプライ ンを開始する ウェブフックとは GitHub リポジトリなど 別のツールにおけるイベントを検出し この外部イベントを パイプラインに接続する HTTP 通知です AWS CodePipeline は コンソールを使用して GitHub パイプラインを作成あるいは編集するウェブフック を作成し パイプラインを削除したときにウェブフックも削除します GitHub でこれを手動で管理する必 要はありません GitHub パイプラインの作成または編集に AWS CLI または AWS CloudFormation を使用 する場合は このセクションの情報を使用して各自でウェブフックを管理する必要があります トピック GitHub パイプラインにウェブフックを作成する (p. 105) アカウントのウェブフックのリスト (p. 106) GitHub パイプラインにウェブフックを更新する (p. 107) GitHub パイプラインのウェブフックを削除する (p. 108) 変更の検出にウェブフックを使用するように GitHub パイプラインを設定する (p. 109) GitHub パイプラインにウェブフックを作成する AWS CLI を使用して手動でウェブフックを作成できます 続いて GitHub にウェブフックを登録する必 要があります 指定された AWS エンドポイントがウェブフックに使用され put-webhook コマンドから 提供されます AWS CLI を使用してウェブフックを作成するには put-webhook コマンドを呼び出し 以下を指定しま す ウェブフックを一意に識別する名前 この名前は パイプラインのアカウントのリージョンで一意であ る必要があります GitHub 認証に使用される JSON ファイルのシークレット 1. テキストエディタで 作成するウェブフックの JSON ファイルを作成して保存します mywebhook: という名前のウェブフックには このサンプルを使用します "webhook": "name": "my-webhook", "targetpipeline": "pipeline_name", "targetaction": "source_action_name", "filters": [ "jsonpath": "$.ref", "matchequals": "refs/heads/branch" ], "authentication": "GITHUB_HMAC", "authenticationconfiguration": "SecretToken":"secret" 2. put-webhook コマンドを呼び出し --cli-input および --region パラメータを含めます 以下の構文を使用します aws codepipeline put-webhook 105

113 ウェブフックを使用して自動的 に GitHub パイプラインを開始する --cli-input-json file:"file_name" --region region 例: 次のサンプルコマンドは webhook_json JSON ファイルでウェブフックを作成します aws codepipeline put-webhook --cli-input-json file://webhook_json.json --region "eucentral-1" 3. my-webhook と言う名前のウェブフックのこの例の出力には URL および ARN が返されます 4. "webhook": "url": " "definition": "authenticationconfiguration": "SecretToken": "secret", "name": "my-webhook", "authentication": "GITHUB_HMAC", "targetpipeline": "pipeline_name", "targetaction": "Source", "filters": [ "jsonpath": "$.ref", "matchequals": "refs/heads/branch" ], "arn": "arn:aws:codepipeline:eu-central-1:account_id:webhook:my-webhook" register-webhook-with-third-party コマンドを呼び出し --webhook-name パラメータを含めます 以下の構文を使用します aws codepipeline register-webhook-with-third-party --webhook-name webhook_name 例: 次のサンプルコマンドは my-webhook という名前でウェブフックを登録します aws codepipeline register-webhook-with-third-party --webhook-name my-webhook アカウントのウェブフックのリスト AWS CLI を使用して アカウントのウェブフックを一覧表示できます 1. ウェブフックを一覧表示するには list-webhooks コマンドを呼び出し --endpoint-url および --region パラメータを含めます 以下の構文を使用します aws codepipeline list-webhooks --endpoint-url "endpoint_url" 106

114 ウェブフックを使用して自動的 に GitHub パイプラインを開始する --region region 例: 次のサンプルコマンドは eu-central-1 エンドポイント URL のウェブフックを一覧表示します aws codepipeline list-webhooks --endpoint-url " --region "eu-central-1" 2. ウェブフックのリストと各ウェブフック名および ARN が一覧表示されます "webhooks": [ "url": " trigger example ": "authenticationconfiguration": "SecretToken": "Secret", "name": "my-webhook", "authentication": "GITHUB_HMAC", "targetpipeline": "my-pipeline", "targetaction": "Source", "filters": [ "jsonpath": "$.ref", "matchequals": "refs/heads/branch" ], "arn": "arn:aws:codepipeline:eu-central-1:account_id:webhook:my-webhook" ] 3. GitHub でリポジトリを選択します 4. [Settings] を選択します 5. [ウェブフック] を選択します リポジトリのウェブフック情報を表示します GitHub パイプラインにウェブフックを更新する AWS CLI を使用して リポジトリのウェブフックを編集します ウェブフックを更新する方法に応じて 次のいずれかの方法を使用します コンソールを使用してパイプラインの GitHub ソースアクションを編集する場合 ウェブフックは更新 されます (そして 必要に応じて再登録されます) ウェブフック名を更新せず GitHub リポジトリを変更しない場合 AWS CLI を使用してウェブフック を更新できます この例が以下のウェブフックシークレットの更新手順で示されています 例 1 を参照 してください ウェブフック名あるいは GitHub リポジトリを変更する場合 コンソールでソースアクションを編集す るか CLI でウェブフックを削除して再度作成する必要があります 新規のウェブフックを作成後 そ れを登録します 例 2 を参照してください 例 1: CLI を使用してウェブフックシークレットを更新するには 1. テキストエディタで 更新するウェブフックの JSON ファイルに変更を加えます この例では GitHub パイプラインにウェブフックを作成する (p. 105) でウェブフックの作成に使用したのと 107

115 ウェブフックを使用して自動的 に GitHub パイプラインを開始する 同じファイルに変更を加えます このサンプルは my-webhook という名前のウェブフックを更 新して シークレットトークンを変更します "webhook": "name": "my-webhook", "targetpipeline": "pipeline_name", "targetaction": "source_action_name", "filters": [ "jsonpath": "$.ref", "matchequals": "refs/heads/branch" ], "authentication": "GITHUB_HMAC", "authenticationconfiguration": "SecretToken":"new_secret" 2. put-webhook コマンドを呼び出し --cli-input および --region パラメータを含めます 以下の構文を使用します aws codepipeline put-webhook --cli-input-json file:"file_name" --region region 例: 次のサンプルコマンドは 変更を加えた webhook_json JSON ファイルでウェブフックを更新しま す aws codepipeline put-webhook --cli-input-json file://webhook_json.json --region "eucentral-1" 3. 出力はウェブフックの詳細を返し 新しいシークレットを表示します コンソールで GitHub ソースアクションを編集できます これにより AWS CodePipeline は ウェブフックを管理できます 例 2: CLI を使用してウェブフック名あるいは GitHub リポジトリを更新するには 1. GitHub パイプラインのウェブフックを削除する (p. 108) のステップを使用して 古いウェブ フック名あるいは GitHub リポジトリに関連付けられている既存のウェブフックの登録を解除して削 除します 2. GitHub パイプラインにウェブフックを作成する (p. 105) のステップを使用して 新規のウェブ フックを作成して登録し ウェブフックを再度作成します コンソールで GitHub ソースアクションを編集できます これにより AWS CodePipeline は ウェブフックを管理できます GitHub パイプラインのウェブフックを削除する AWS CLI を使用してウェブフックを削除するには 108

116 ウェブフックを使用して自動的 に GitHub パイプラインを開始する 1. ウェブフックを削除する前に その登録を解除する必要があります deregister-webhook-with-thirdparty コマンドを呼び出し --webhook-name パラメータを含めます 以下の構文を使用します aws codepipeline deregister-webhook-with-third-party --webhook-name webhook_name 例: 次のサンプルコマンドは my-webhook という名前のウェブフックの登録を解除します aws codepipeline deregister-webhook-with-third-party --webhook-name my-webhook 2. delete-webhook コマンドを呼び出し --name パラメータを含めます 以下の構文を使用します aws codepipeline delete-webhook --name "webhook_name" 例: 次のサンプルコマンドは my-webhook という名前のウェブフックを削除します aws codepipeline delete-webhook --name my-webhook 変更の検出にウェブフックを使用するように GitHub パイプライ ンを設定する GitHub リポジトリを使用するパイプラインの変更検出方法として ウェブフックを使用できるようになり ました この機能を使用するには 既存のパイプラインを更新する必要があります コンソールを使用し てパイプラインを作成あるいは編集した場合 AWS CodePipeline はウェブフックを作成します このテーブルでは GitHub パイプラインの手順を紹介しています 方法 Instructions これ以上 何もする必要はあ りませんか コンソールでパイプラ インを設定する 1. コンソールでパイプラインを開きます [Edit] を選択します GitHub ソースアクションの横にある鉛筆 アイコンを選択します [リポジトリに接続する] を選択し [更新] を選択します [パイプラインの変更を保存する] を選択 します ウェブフックが作成さ れ GitHub に登録されます パイプラインの編集 (コンソールの場 合) (p. 123) を参照してください 109 これ以上 何もする必要はあ りません

117 定期的なチェックを使用して自 動的にパイプラインを開始する 方法 Instructions これ以上 何もする必要はあ りませんか CLI でパイプラインを 設定する update-pipeline コマンドを使用し て PollForSourceChanges パラメータを false に設定します ウェブフックを作成し て GitHub に登録することが 必要です パイプラインの表示 (AWS CLI の場 合) (p. 125) を参照してください GitHub パイプライン にウェブフックを作成す る (p. 105) を参照してくだ さい GitHub ソースリポジトリの定期的なチェック を保持します AWS CloudFormation の Webhook リソー スについては AWS::CodePipeline::Webhook を参照してください AWS CloudFormation でパイプラインを設定 する 定期的なチェックを使用して自動的にパイプラインを 開始する リポジトリの変更が検出されるとパイプラインが自動的に開始し 変更検出方法の 1 つが 定期的な チェックとなります PollForSourceChanges フラグを使用すると 定期的なチェックを有効あるいは 無効にできます CLI を使用して作成あるいは更新されたパイプラインでは このパラメータのデフォル トは true ですが これは推奨される設定ではありません 代わりに パイプラインを更新し 推奨される 変更検出方法を使用してこのパラメータを false に設定します 推奨される設定でパイプラインを作成する詳細は パイプラインの作成 (コンソールの場合) (p. 115) および パイプラインを作成する (CLI の場合) (p. 120) を参照してください 推奨される設定でアク ションあるいはパイプラインを更新する詳細は パイプラインの編集 (コンソールの場合) (p. 123) お よび パイプラインを編集する (CLI の場合) (p. 125) を参照してください 詳細については パイプラインの自動開始に使用される変更検出方法 (p. 91) を参照してください AWS CodePipeline でパイプラインを手動で開始する デフォルトでは パイプラインは作成時に自動で開始され その後ソースリポジトリ内で変更があるたび に自動的に開始されます ただし 再度パイプラインを通して 最新のリビジョンを再実行する場合が あります パイプラインを通して 最新のリビジョンを手動で再実行するには AWS CodePipeline コン ソールまたは AWS CLI と start-pipeline-execution コマンドを使用します トピック パイプラインを手動で開始する (コンソール) (p. 110) パイプラインを手動で開始する (CLI) (p. 111) パイプラインを手動で開始する (コンソール) パイプラインを手動で開始し 最新のリビジョンをパイプラインにより実行するには 1. AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline) を開きます 2. [Name] で 開始するパイプラインの名前を選択します 110

118 Amazon CloudWatch Events を使用して スケ ジュールに基づいてパイプラインを自動的に実行する 3. パイプラインの詳細ページで [変更のリリース] を選択します これにより ソースアクションで指 定した各ソース場所における最新のリビジョンがパイプラインにより開始されます パイプラインを手動で開始する (CLI) パイプラインを手動で開始し アーティファクトの最新バージョンをパイプラインにより実行す るには 1. ターミナル (Linux, macos, or Unix) またはコマンドプロンプト (Windows) を開き AWS CLI で手動 で開始するパイプラインの名前を指定して start-pipeline-execution コマンドを実行します たとえ ば MyFirstPipeline という名前のパイプラインにより最後の変更を実行するには 以下のように します aws codepipeline start-pipeline-execution --name MyFirstPipeline 2. 成功したかどうかを確認するには 返されたオブジェクトを表示します このコマンドは 以下のよ うな ExecutionID オブジェクトを返します "pipelineexecutionid": "c53dbd42-this-is-an-example" パイプラインを開始したら AWS CodePipeline コンソールで または get-pipeline-state コ マンドを実行して 進行状況をモニタリングできます 詳細については パイプラインの 詳細と履歴を表示する (コンソール) (p. 129) および パイプラインの詳細と履歴を表示す る (CLI) (p. 131) を参照してください Amazon CloudWatch Events を使用して スケジュー ルに基づいてパイプラインを自動的に実行する Amazon CloudWatch Events でルールを設定して スケジュールに基づいてパイプラインを開始すること ができます パイプラインを開始するスケジュールの CloudWatch イベント ルールを作成する (コンソール) スケジュールをイベントソースとする CloudWatch イベント ルールを作成するには 1. CloudWatch コンソールを開きます 2. ナビゲーションペインの [Events] を選択します 3. [ルールの作成] を選択してから [Event Source] で [Schedule] を選択します 4. 一定間隔または式を使用してスケジュールを設定します 詳細については ルールのスケジュール 式 を参照してください 5. [ターゲット] エリアで [CodePipeline] を選択します 6. このスケジュールによってトリガーされたときに開始されるパイプライン実行の パイプライン ARN を入力します 111

119 Amazon CloudWatch Events を使用して スケ ジュールに基づいてパイプラインを自動的に実行する get-pipeline コマンドを実行した後で メタデータ出力でパイプライン ARN を見つける ことができます 7. 次のいずれかを選択して Amazon CloudWatch Events ルールに関連付けられたターゲットを呼び出 すための Amazon CloudWatch Events アクセス許可を与える IAM サービスロールを作成または指定し ます (この場合 ターゲットは AWS CodePipeline) トリガーされた時にパイプラインの実行を開始するための Amazon CloudWatch Events アクセス許 可を付与するサービスロールを作成するには [この特定のリソースに対して新しいロールを作成す る] を選択します トリガーされた時にパイプラインの実行を開始するための Amazon CloudWatch Events アクセス許 可を付与するサービスロールを指定するには [既存のロールの使用] を選択します 8. [Configure details] を選択します 9. [Configure rule details] ページでルールの名前と説明を入力してから [State] を選択してルールを有効 化します 10. ルールが適切であることを確認したら [Create rule] を選択します パイプラインを開始するスケジュールの CloudWatch イベント ルールを作成する (CLI) AWS CLI を使用してルールを作成するには 以下を指定して put-rule コマンドを呼び出します 作成中のルールを一意に識別する名前 この名前は AWS アカウントに関連付けられた AWS CodePipeline で作成するすべてのパイプラインで一意である必要があります ルールのためのスケジュール式 スケジュールをイベントソースとする CloudWatch イベント ルールを作成するには 1. put-rule コマンドを呼び出し --name および --schedule-expression パラメータを含めます 例: 以下のサンプルコマンドでは --schedule-expression を使用して スケジュールに従って CloudWatch イベント をフィルタリングする MyRule2 というルールを作成します aws events put-rule --schedule-expression 'cron(15 10? * 6L )' --name MyRule2 2. AWS CodePipeline を使用してルールを呼び出すための Amazon CloudWatch Events アクセス許可を 付与します 詳細については Amazon CloudWatch Events のリソースベースのポリシーを使用す る を参照してください a. 次のサンプルを使用して CloudWatch イベントがサービスロールを引き受けるように信頼ポリ シーを作成します これを trustpolicyforcwe.json と名付けます "Version": " ", "Statement": [ "Effect": "Allow", "Principal": "Service": "events.amazonaws.com", "Action": "sts:assumerole" 112

120 パイプラインの作成 b. ] 以下のコマンドを使用して Role-for-MyRule ロールを作成し 信頼ポリシーをアタッチしま す aws iam create-role --role-name Role-for-MyRule --assume-role-policy-document file://trustpolicyforcwe.json c. このサンプルに示すように アクセス許可ポリシー JSON を MyFirstPipeline という名前のパ イプラインに対して作成します アクセス許可ポリシーに permissionspolicyforcwe.json と いう名前を付けます d. "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "codepipeline:startpipelineexecution" ], "Resource": [ "arn:aws:codepipeline:us-west-2:80398example:myfirstpipeline" ] ] 次のコマンドを使用し 新しい CodePipeline-Permissions-Policy-for-CWE アクセス許可ポリ シーを 作成した Role-for-MyRule ロールにアタッチします aws iam put-role-policy --role-name Role-for-MyRule --policy-name CodePipelinePermissions-Policy-For-CWE --policy-document file://permissionspolicyforcwe.json AWS CodePipeline でパイプラインを作成する AWS CodePipeline コンソールまたは AWS CLI を使用してパイプラインを作成できます Amazon ECS をデプロイプロバイダとして使用して コンテナベースのアプリケーションをビルドおよび デプロイするパイプラインを作成することもできます Amazon ECS でコンテナベースのアプリケーショ ンをデプロイするパイプラインを作成する前に イメージ定義ファイルを作成する必要があります AWS CodePipeline では ソースコードの変更がプッシュされたときのパイプラインの開始に変更検出メ ソッドを使用します この検出方法はソースタイプに基づいています AWS CodePipeline は Amazon CloudWatch Events を使用して AWS CodeCommit ソースリポジトリ とブランチの変更や Amazon S3 ソースバケットの変更を検出します AWS CodePipeline はウェブフックを使用して GitHub ソースリポジトリとブランチの変更を検出しま す ウェブフックとは 外部ツールにおけるイベントを検出し この外部イベントをパイプラインに接 続する HTTP 通知です コンソールを使用してパイプラインを作成または編集すると 変更検出リソースが作成されま す AWS CLI を使用してパイプラインを作成するときは 追加のリソースを各自で作成する必要 があります 詳細については CloudWatch イベント ルールを使用して AWS CodeCommit パ イプラインを自動的に開始する (p. 92) を参照してください 113

121 コンテナベースのアプリケーションをデプ ロイするためのイメージ定義ファイルの作成 トピック コンテナベースのアプリケーションをデプロイするためのイメージ定義ファイルの作成 (p. 114) パイプラインの作成 (コンソールの場合) (p. 115) パイプラインを作成する (CLI の場合) (p. 120) コンテナベースのアプリケーションをデプロイするた めのイメージ定義ファイルの作成 イメージ定義ドキュメントは Amazon ECS のコンテナ名およびイメージとタグについて説明する JSON ファイルです コンテナベースのアプリケーションをデプロイする場合は イメージ定義ファイルを生成 して AWS CodePipeline ジョブワーカーに Amazon ECS コンテナを提供し パイプラインのデプロイス テージで使用するイメージ ID を生成する必要があります イメージ定義ファイルの最大ファイルサイズの制限は 100 KB です デプロイアクションの入力アーティファクトとして取り込まれるように イメージ定義ファイルを生成 する必要があります イメージ定義ファイルはコンテナ名とイメージ URI を提供します 次のキーと値のペアのセットで構築す る必要があります イメージ定義ファイルをソースとして作成するか コンテナベースのデプロイのアーティファク トをビルドする キー 値 name コココココ imageuri image_uri コンテナ名が sample-app で イメージ URI が ecs-repo タグが latest の JSON 構造は次のとおり です [ ] "name": "sample-app", "imageuri": "11111EXAMPLE.dkr.ecr.us-west-2.amazonaws.com/ecs-repo:latest" イメージ定義ファイルを構築して 複数のコンテナイメージのペアをリストすることもできます JSON の構造: [,, "name": "simple-app", "imageuri": "httpd:2.4" "name": "simple-app-1", "imageuri": "mysql" "name": "simple-app-2", "imageuri": "java1.8" 114

122 パイプラインの作成 (コンソールの場合) ] パイプラインを作成する前に 以下の手順に従ってイメージ定義ファイルを設定します 1. パイプラインのコンテナベースのアプリケーションデプロイの計画の一環として ソースステージと ビルドステージを計画します (該当する場合) 2. 以下のいずれかを選択します a. パイプラインでビルドステージをスキップしている場合 ソースアクションがアーティファクト を提供できるように 手動で JSON ファイルを作成してソースリポジトリにアップロードする必 要があります テキストエディタを使用してファイルを作成し ファイルに名前を付けます ま たは デフォルトの imagedefinitions.json ファイル名を使用します イメージ定義ファイ ルをソースリポジトリにプッシュします ソースリポジトリが Amazon S3 バケットの場合は JSON ファイルを圧縮してくださ い b. パイプラインにビルドステージがある場合は ビルドフェーズ中にソースリポジトリにイメージ 定義ファイルを出力するコマンドをビルドスペックファイルに追加します 以下の例では printf コマンドを使用して imagedefinitions.json ファイルを作成しています buildspec.yml ファイルの post_build セクションにこのコマンドをリストします printf '["name":"container_name","imageuri":"image_uri"]' > imagedefinitions.json イメージ定義ファイルを出力アーティファクトとして buildspec.yml ファイルに含める必要があ ります 3. コンソールでパイプラインを作成するときは [パイプラインの作成] ウィザードで [デプロイ] ページ の [イメージのファイル名] フィールドにイメージ定義ファイル名を入力する必要があります Amazon ECS をデプロイプロバイダとして使用するパイプラインを作成するための段階的なチュートリア ルについては チュートリアル: AWS CodePipeline を使用した継続的デプロイメント を参照してくだ さい トピック パイプラインの作成 (コンソールの場合) (p. 115) パイプラインを作成する (CLI の場合) (p. 120) パイプラインの作成 (コンソールの場合) コンソールでパイプラインを作成するには ソースファイルの場所と アクションに使用するプロバイ ダーに関する情報を提供する必要があります コンソールを使用してパイプラインを作成する場合 ソースステージに加えて 以下のいずれかまたは両 方が必要です ビルドステージ デプロイステージ パイプラインウィザードを使用する場合 AWS CodePipeline によってステージの名前 (ソース ビルド ステージング) が作成されます これらの名前は変更できません ステージの後半で より詳細な名前 (た とえば BuildToGamma または DeployToProd) を使用することもできます 115

123 パイプラインの作成 (コンソールの場合) ステップ 1: パイプラインの作成と名前付け 1. AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline) を開きます 2. [ようこそ] ページで [パイプラインの作成] を選択します AWS CodePipeline を初めて使用する場合は [今すぐ始める] を選択します 3. [Step 1: Choose pipeline settings (ステップ 1: パイプラインの設定の選択)] ページで [パイプライン 名] にパイプラインの名前を入力します 単一の AWS アカウント内で リージョン内に作成する各パイプラインには一意の名前が必要です 名前は異なるリージョンのパイプラインに再利用できます バケットを作成したら その名前を変更することはできません その他の制限については AWS CodePipeline 制限 (p. 252) を参照してください 4. [ロール名] で 以下のいずれかの操作を行います サービスロールがない場合は [New service role (新しいサービスロール)] を選択し [ロール名] に 新しいサービスロールの名前を入力します IAM により 新しいロールが自動的に作成されます 以前に AWS-CodePipeline-Service サービスロールを作成している場合は [Existing service role (既 存のサービスロール)] を選択します サービスロールを作成したタイミングに応じて 追加の AWS のサービスをサポートするた めにロールのアクセス権限の更新が必要になる場合があります 詳細については 他の AWS サービスのアクセス許可の追加 (p. 222) を参照してください サービスロールとそのポリシーステートメントの詳細については AWS CodePipeline サービス ロールの管理 (p. 220) を参照してください 5. [アーティファクトストア] で 以下のいずれかの操作を行います a. [Default location (デフォルトの場所)] を選択し パイプライン用に選択したリージョン内のパイ プラインのデフォルトのアーティファクトストア (デフォルトとして指定された Amazon S3 アー ティファクトバケットなど) を使用します b. 作成した既存のアーティファクトストア (Amazon S3 アーティファクトバケットなど) がパイプ ラインと同じリージョンにある場合は [Custom location (カスタムの場所)] を選択します これはパイプラインのソースコードのソースバケットではありません パイプラインのアー ティファクトストアです Amazon S3 バケットのような個別のアーティファクトストアが パイプラインと同じリージョン内の各パイプラインに必要です 6. [Next (次へ)] を選択します ステップ 2: ソースステージを作成する [Step 2: Add source stage (ステップ 2: ソースステージの追加)] ページの [ソースプロバイダ] で ソー スコードが保存されているリポジトリのタイプを選択し 必要なオプションを指定してから [次のス テップ] を選択します GitHub の場合: 116

124 パイプラインの作成 (コンソールの場合) 1. [Connect to GitHub] を選択します サインインするように求められたら GitHub の認証情報を 入力します Important AWS の認証情報を入力しないでください 2. AWS CodePipeline から GitHub にこのリージョンで初めて接続する場合は アプリケーション にアカウントへのアクセスを許可するように求められます 統合に必要なアクセス権限を確認 し 続行する場合は [Authorize application] を選択します コンソールで GitHub に接続するとき は 以下のリソースが作成されます AWS CodePipeline は OAuth トークンを使用して AWS CodePipeline で管理される承認済みア プリケーションを作成します GitHub では AWS CodePipeline などのアプリケーションに対して使用できる OAuth トークンの数は制限されています この制限を超えた場合は AWS CodePipeline が 既存のトークンを再利用して再接続できるように接続を再試行します 詳細について は GitHub からの個人用のアクセストークンを使用するようにパイプラインを設定 するには (p. 205) を参照してください AWS CodePipeline は ソースの変更を検出し 変更が生じたときにパイプラインを開始する ウェブフックを GitHub に作成します ウェブフックに加えて AWS CodePipeline は以下を 行います シークレットをランダムに生成し これを使用して GitHub への接続を承認します リージョンのパブリックエンドポイントを使用してウェブフック URL を生成し GitHub に 登録します これによって レポジトリのイベントを受信するための URL がサブスクライ ブされます 3. パイプラインのソース場所として使用する GitHub リポジトリを選択します [Branch ] で ド ロップダウンリストから使用するブランチを選択します Amazon S3 の場合: 1. [Amazon S3 の場所] で Amazon S3 バケットの名前と バージョニングが有効なバケット内の オブジェクトへのパスを入力します バケット名とパスの形式は以下のようになります s3://bucketname/foldername/objectname 2. Amazon S3 ソースバケットを選択すると AWS CodePipeline によってこのパイプライン 用に Amazon CloudWatch Events ルールと AWS CloudTrail 証跡が作成されます [Change detection options (変更検出オプション)] で デフォルト値を受け入れます これにより AWS CodePipeline は Amazon CloudWatch Events と AWS CloudTrail を使用して 新しいパイプライ ンの変更を検出できます [Next] を選択します AWS CodeCommit の場合: [レポジトリ名] で パイプラインのソース場所として使用する AWS CodeCommit リポジトリの 名前を選択します [Branch name] で ドロップダウンリストから使用するブランチを選択しま す AWS CodeCommit リポジトリ名とブランチを選択すると [Change detection options (変更検出 オプション)] にメッセージが表示されて このパイプライン用に作成される Amazon CloudWatch Events ルールが示されます [Change detection options (変更検出オプション)] で デフォルト値 を受け入れます これにより AWS CodePipeline は Amazon CloudWatch Events を使用して 新しいパイプラインの変更を検出できます オブジェクトとファイルのタイプは 使用するデプロイシステム (Elastic Beanstalk や AWS CodeDeploy など) と互換性があることが必要です サポートされているファイルのタイプ 117

125 パイプラインの作成 (コンソールの場合) は.zip.tar.tgz ファイルなどです Elastic Beanstalk でサポートされているコンテナのタ イプの詳細については Elastic Beanstalk 環境のカスタマイズと設定 と サポートされ ているプラットフォーム を参照してください AWS CodeDeploy によるリビジョンのデプ ロイの詳細については アプリケーションリビジョンのアップロード と リビジョンの 準備 を参照してください ステップ 3: ビルドステージを作成する [Step 3: Add build stage (ステップ 3: ビルドステージの追加)] ページで 以下のいずれかの操作を行い [Next (次へ)] を選択します [スキップ] を選択してビルドステージの作成をスキップし 続いて [スキップ] を選択して警告メッ セージを受け入れます 使用するビルドサービスのカスタムアクションプロバイダーを選択し そのプロバイダーの設定の 詳細を指定します ビルドプロバイダーを追加する手順は プロバイダーによって異なります Jenkins をビル ドプロバイダーとして追加する方法の例については チュートリアル: 4 ステージのパイ プラインを作成する (p. 56) を参照してください AWS CodeBuild を選択し [プロジェクト名] でビルドプロジェクトを選択します AWS CodeBuild にビルドプロジェクトがすでにある場合は 選択します または AWS CodeBuild でビルドプロ ジェクトを作成し その後でこのタスクに戻ります AWS CodeBuild ユーザーガイドの AWS CodeBuild を使用するパイプラインを作成する の手順を参照してください ステップ 4: デプロイステージを作成する [Step 4: Add deploy stage (ステップ 4: デプロイステージの追加)] ページで 以下のいずれかの操作を行 い [Next (次へ)] を選択します 以下のいずれかを選択します [スキップ] を選択してデプロイステージの作成をスキップし 続いて [スキップ] を選択して警告 メッセージを受け入れます 前の手順でビルドプロバイダーを選択した場合にのみ デプロイプロバイダーの追加をス キップできます デプロイプロバイダー用に作成したカスタムアクションを選択します [Deploy provider (デプロイプロバイダ)] から 以下のいずれかのデフォルトプロバイダを選択しま す AWS CodeDeploy [アプリケーション名] で 既存の AWS CodeDeploy アプリケーションの名前を入力または選択し ます [デプロイグループ] に アプリケーションのデプロイグループの名前を入力します [Next (次へ)] を選択します アプリケーション デプロイグループ または両方を AWS CodeDeploy コンソールで作成することもできます AWS Elastic Beanstalk [アプリケーション名] で 既存の Elastic Beanstalk アプリケーションの名前を入力または選択し ます [環境名] に アプリケーションの環境を入力します [Next (次へ)] を選択します アプリ ケーション 環境 または両方を Elastic Beanstalk コンソールで作成することもできます AWS OpsWorks Stacks 118

126 パイプラインの作成 (コンソールの場合) [スタック] で 使用するスタックの名前を入力または選択します [レイヤー] で ターゲットイ ンスタンスがあるレイヤーを選択します [デプロイ] で 更新およびデプロイするアプリケー ションを選択します アプリケーションを作成する必要がある場合は [Create a new one in AWS OpsWorks (&OPSlong で新規作成)] を選択します AWS OpsWorks でスタックとレイヤーにアプリケーションを追加する方法については AWS OpsWorks ユーザーガイド の アプリケーションの追加 を参照してください AWS CodePipeline でシンプルなパイプラインを AWS OpsWorks レイヤーで実行するコードの ソースとして使用する方法のエンドツーエンドの例については AWS OpsWorks Stacks での AWS CodePipeline の使用 を参照してください AWS CloudFormation 次のいずれかを行ってください [アクションモード] で [スタックの作成または更新] を選択し スタック名とテンプレート ファイル名を入力します 次に AWS CloudFormation で引き受けるロールの名前を選択しま す 必要に応じて 設定ファイルの名前を入力し IAM 機能オプションを選択します [アクションモード] で [変更セットの作成または置換] を選択し スタック名を入力して セッ ト名を変更します 次に AWS CloudFormation で引き受けるロールの名前を選択します 必 要に応じて 設定ファイルの名前を入力し IAM 機能オプションを選択します AWS CodePipeline で AWS CloudFormation 機能をパイプラインに統合する方法の詳細について は AWS CloudFormation ユーザーガイド の AWS CodePipeline による継続的デプロイメン ト を参照してください Amazon ECS [クラスター名] で 既存の Amazon ECS クラスターの名前を入力または選択します [サービス 名] で クラスターで実行されているサービスの名前を入力または選択します クラスターとサー ビスを作成することもできます [イメージのファイル名] で サービスのコンテナとイメージを 説明するイメージ定義ファイルの名前を入力します [次へ] を選択します Amazon ECS クラスターに 2 つ以上の Amazon ECS インスタンスが設定されているこ とを確認します 1 つはプライマリインスタンスとして維持し もう 1 つは新しいデプ ロイに対応するために使用します パイプラインを使用したコンテナベースのアプリケーションのデプロイに関するチュートリアル については チュートリアル: AWS CodePipeline を使用した継続的デプロイメント を参照し てください ステップ 5: パイプラインの確認 [ステップ 5: 確認] ページで パイプラインの設定を確認したら [パイプラインの作成] を選択して パイプラインを作成するか [戻る] を選択してオプションを編集します パイプラインを作成せずに ウィザードを終了するには [Cancel] を選択します パイプラインが作成され コンソールで表示できるようになりました パイプラインは 作成後に実行さ れます 詳細については AWS CodePipeline でパイプラインの詳細と履歴を表示する (p. 129) を参 照してください パイプラインを変更する方法の詳細については AWS CodePipeline でパイプライン を編集する (p. 122) を参照してください 119

127 パイプラインを作成する (CLI の場合) パイプラインを作成する (CLI の場合) AWS CLI を使用してパイプラインを作成するには JSON ファイルを作成してパイプライン構造を定義 し --cli-input-json パラメータを指定して create-pipeline コマンドを実行します Important AWS CLI を使用して パートナーアクションを含むパイプラインを作成することはできません 代わりに AWS CodePipeline コンソールを使用する必要があります パイプライン構造に関する詳細については AWS CodePipeline パイプライン構造のリファレン ス (p. 244) および AWS CodePipeline API リファレンスの create-pipeline を参照してください JSON ファイルを作成するには 同じパイプラインの JSON ファイルを使用して編集し create-pipeline コマンドを実行するときにこのファイルを呼び出します AWS CodePipeline の使用開始 (p. 9) で AWS CodePipeline 用に作成したサービスロールの ARN お よびパイプラインのアーティファクトを保存する Amazon S3 バケットの名前が必要になります このバ ケットはパイプラインと同じリージョンに存在する必要があります この ARN とバケット名は createpipeline コマンドを実行するときに使用します コンソールとは異なり AWS CLI で create-pipeline コマ ンドを実行しても アーティファクトを保存する Amazon S3 バケットは作成されません バケットが存 在している必要があります get-pipeline コマンドを使用して パイプラインの JSON 構造のコピーを取得し プレーンテキス トエディタで構造を変更することもできます JSON ファイルを作成するには ターミナル (Linux, macos, or Unix) またはコマンドプロンプト (Windows) で ローカルディレクトリ に新規のテキストファイルを作成します プレーンテキストエディタでファイルを開き 作成する構造を反映するように値を編集します 少な くとも パイプラインの名前を変更する必要があります また 変更するかを考慮する必要もありま す このパイプラインのアーティファクトが保存されている Amazon 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", 120

128 パイプラインを作成する (CLI の場合), ] "outputartifacts": [ "name": "MyApp" ], "configuration": "S3Bucket": "awscodepipeline-demobucket-example-date", "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 ", "name": "MyFirstPipeline", "version": 1, "metadata": "pipelinearn": "arn:aws:codepipeline:us-east-2:80398example:myfirstpipeline", "updated": , "created": JSON ファイルの PollForSourceChanges パラメータが次のように設定されていることを確認しま す "PollForSourceChanges": "false", AWS CodePipeline は Amazon CloudWatch Events を使用して AWS CodeCommit ソースリポジト リとブランチの変更または Amazon S3 ソースバケットの変更を検出します AWS CodePipeline は ウェブフックを使用して GitHub ソースリポジトリとブランチの変更を検出します 次のステップに は パイプラインにこれらのリソースを手動で作成する手順が含まれています フラグを false に設 121

129 パイプラインの編集 定すると 定期的なチェックが無効になります これは 推奨される変更検出メソッドを使用してい る場合には 必要ではありません 3. その構造で問題がなければ pipeline.json のような名前でファイルを保存します パイプラインを作成するには 1. 先ほど作成した JSON ファイルを --cli-input-json パラメータで指定して create-pipeline コマ ンドを実行します "MySecondPipeline" という名前を JSON 内の name の値として含む pipeline.json という名前の JSON ファイルを使用して MySecondPipeline という名前のパイプラインを作成する場合 このコ マンドは以下のようになります aws codepipeline create-pipeline --cli-input-json file://pipeline.json Important ファイル名の前に必ず file:// を含めてください このコマンドでは必須です このコマンドは 作成したパイプライン全体の構造を返します 2. 先ほど作成したパイプラインを表示するには AWS CodePipeline コンソールを開いてパイプライ ンのリストから選択するか get-pipeline-state コマンドを使用します 詳細については AWS CodePipeline でパイプラインの詳細と履歴を表示する (p. 129) を参照してください 3. パイプラインの作成に CLI を使用する場合には 推奨される変更検出リソースを手動でパイプライン に作成する必要があります AWS CodeCommit リポジトリでパイプラインを作成する場合 CloudWatch イベント ルールを手 動で作成する必要があります 詳細については AWS CodeCommit パイプライン (CLI) を開始す る CloudWatch イベント ルールを作成する (p. 96) を参照してください Amazon S3 ソースでパイプラインを作成する場合 CloudWatch イベント ルールおよび AWS CloudTrail 証跡を手動で作成する必要があります 詳細については CloudWatch イベント ルー ルを使用して Amazon S3 パイプラインを自動的に開始する (p. 99) を参照してください GitHub ソースでパイプラインを作成する場合 ウェブフックを手動で作成する必要があります 詳 しくは ウェブフックを使用して自動的に GitHub パイプラインを開始する (p. 105) を参照し てください AWS CodePipeline でパイプラインを編集する パイプラインでは 完了させる必要のあるステージやアクションなど AWS CodePipeline で処理するリ リースプロセスについて説明します パイプラインを編集して 要素を追加または削除することができま す ただし パイプラインを編集するときには パイプライン名またはパイプラインメタデータなどの値 を変更することはできません パイプラインを作成する場合とは異なり パイプラインを編集しても パイプラインを通して最新のリビ ジョンが実行されることはありません 編集後のパイプラインを通して 最新のリビジョンを実行する場 合は 手動で再実行する必要があります それ以外の場合 編集後のパイプラインはソースステージで設 定されているソースの場所の次回変更時に実行されます 詳細については AWS CodePipeline でパイプ ラインを手動で開始する (p. 110) を参照してください AWS CodePipeline では ソースコードの変更がプッシュされたときのパイプラインの開始に変更検出メ ソッドを使用します この検出方法はソースタイプに基づいています AWS CodePipeline は Amazon CloudWatch Events を使用して AWS CodeCommit ソースリポジトリ とブランチの変更や Amazon S3 ソースバケットの変更を検出します 122

130 パイプラインの編集 (コンソールの場合) AWS CodePipeline はウェブフックを使用して GitHub ソースリポジトリとブランチの変更を検出しま す 変更検出リソースは コンソールを使用するときに自動的に作成されます コンソールを使用 してパイプラインを作成または編集すると 追加のリソースが作成されます AWS CLI を使用 してパイプラインを作成するときは 追加のリソースを各自で作成する必要があります AWS CodeCommit パイプラインの作成または更新の詳細については AWS CodeCommit パイプ ライン (CLI) を開始する CloudWatch イベント ルールを作成する (p. 96) を参照してくださ い CLI を使用した Amazon S3 パイプラインの作成または更新の詳細については Amazon S3 パイプライン (CLI) を開始する CloudWatch イベント ルールを作成する (p. 101) を参照し てください GitHub パイプラインの作成あるいは更新についての詳細は ウェブフックを使用 して自動的に GitHub パイプラインを開始する (p. 105) を参照してください トピック パイプラインの編集 (コンソールの場合) (p. 123) パイプラインの表示 (AWS CLI の場合) (p. 125) パイプラインの編集 (コンソールの場合) AWS CodePipeline コンソールを使用して パイプラインのステージやステージ内のアクションを追加 編集 または削除できます AWS CodePipeline は Amazon CloudWatch Events を使用して AWS CodeCommit ソースリポジトリと ブランチの変更や Amazon S3 ソースバケットの変更を検出します コンソールを使用して AWS CodeCommit ソースリポジトリや Amazon S3 ソースバケットを含 むパイプラインを編集すると ルールと IAM ロールが自動的に作成されます AWS CLI を使用 してパイプラインを編集する場合は Amazon CloudWatch Events ルールと IAM ロールを自分 で作成する必要があります 詳細については CloudWatch イベント ルールを使用して AWS CodeCommit パイプラインを自動的に開始する (p. 92) を参照してください パイプラインを編集するには 1. AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline) を開きます AWS アカウントに関連付けられているすべてのパイプラインの名前が表示されます 2. [Name] で 編集するパイプラインの名前を選択します これにより パイプラインの詳細ビューが開 いて パイプラインの各ステージの各アクションの状態などがわかります 3. パイプライン詳細ページで [編集] を選択します 4. [編集] ページで 以下のいずれかを行います ステージを編集するには [ステージを編集] を選択します アクションは既存のアクションに対し て直列にも並列にも追加できます これらのアクションの編集アイコンを選択して このビューでアクションを編集することもできま す アクションを削除するには そのアクションの削除アイコンを選択します AWS CodeBuild をビルドアクションまたはテストアクションとしてステージに追加するに は AWS CodeBuild ユーザーガイドの AWS CodeBuild で AWS CodePipeline を使用してコード をテストし ビルドを実行する を参照してください 123

131 パイプラインの編集 (コンソールの場合) アクションを編集するには そのアクションの編集アイコンを選択し [アクションの編集] で値を 変更します アスタリスク (*) の付いた項目は必須です AWS CodeCommit リポジトリ名およびブランチに対して Amazon CloudWatch Events ルー ルがこのパイプラインに作成されることを示すメッセージが表示されます AWS CodeCommit ソースを削除すると Amazon CloudWatch Events ルールが削除されることを示すメッセージが 表示されます Amazon S3 ソースバケットに対して Amazon CloudWatch Events ルールおよび AWS CloudTrail 証跡がこのパイプラインに作成されることを示すメッセージが表示されます Amazon S3 ソースを削除すると Amazon CloudWatch Events ルールと AWS CloudTrail 証跡が削除され ることを示すメッセージが表示されます AWS CloudTrail 証跡が他のパイプラインで使用されて いる場合には この証跡は削除されませんが データイベントは削除されます GitHub ソースの場合 パイプラインに以下のものが追加されます AWS CodePipeline は OAuth トークンを使用して AWS CodePipeline で管理される承認済みア プリケーションを作成します GitHub では AWS CodePipeline などのアプリケーションに対して使用できる OAuth トークンの数は制限されています この制限を超えた場合は AWS CodePipeline が 既存のトークンを再利用して再接続できるように接続を再試行します 詳細について は GitHub からの個人用のアクセストークンを使用するようにパイプラインを設定 するには (p. 205) を参照してください AWS CodePipeline では ソースの変更を検出するためのウェブフックが GitHub に作成され 変更が発生したときにパイプラインが開始されます AWS CodePipeline では ウェブフック と共に以下のものが作成されます シークレットはランダムに生成され GitHub への接続を承認するために使用されます ウェブフック URL は リージョンのパブリックエンドポイントを使用して生成されます ウェブフックは GitHub に登録されます これによって レポジトリのイベントを受信する ための URL がサブスクライブされます GitHub ソースアクションを削除すると ウェブフックは登録解除されて削除されます ステージを追加するには ステージを追加するパイプラインのポイントで [+ Add stage (+ ステージ を追加)] を選択します ステージの名前を入力し 少なくとも 1 つのアクションをそのステージに 追加します アスタリスク (*) の付いた項目は必須です ステージを削除するには そのステージの削除アイコンを選択します ステージとそのすべてのア クションが削除されます たとえば パイプラインのステージにシリアルアクションを追加する場合は 以下のようにします 1. アクションを追加するステージで [Edit stage (ステージを編集)] を選択し [+ Add action group (+ アクショングループの追加)] を選択します 2. [アクションを編集] の [アクション名] でアクションの名前を入力します [Action provider (アク ションプロバイダー)] リストには プロバイダーのオプションがカテゴリ別に表示されます [デプ ロイ] などのカテゴリを探します カテゴリで [AWS CodeDeploy] などのプロバイダーを選択し ます 入力および出力アーティファクトの名前や使用方法など AWS CodePipeline でのアクションの要 件の詳細については AWS CodePipeline のアクション構造の要件 (p. 245) を参照してくださ い GitHub などの一部のアクションプロバイダーでは アクションの設定を完了するために プロバイダーのウェブサイトに接続する必要があります プロバイダーのウェブサイトに 124

132 パイプラインの表示 (AWS CLI の場合) 接続するときは そのウェブサイトの認証情報を使用していることを確認します AWS の認証情報を使用しないでください 3. アクションの設定が完了したら [保存] を選択します 5. コンソールビューでアクションまたはステージの名前を変更することはできません 変更す る名前でステージまたはアクションを追加してから 古いステージまたはアクションを削除 できます 古いステージを削除する前に 必要なすべてのアクションを新しいステージに追 加したことを確認してください パイプラインの編集が終わったら [保存] を選択して概要ページに戻ります Important 変更を保存したら 元に戻すことはできません パイプラインを再度編集する必要がありま す 変更を保存するときにパイプラインによりリビジョンが実行されている場合 その実 行は完了しません 編集したパイプラインにより特定のコミットまたは変更を実行する場合 は パイプラインから手動で実行する必要があります それ以外の場合 次のコミットまた は変更はパイプラインにより自動的に実行されます 6. アクションをテストするには [変更のリリース] を選択して パイプラインによりそのコミットを 処理し パイプラインのソースステージで指定したソースに変更をコミットします または AWS CLI を使用して手動で変更をリリースする場合 AWS CodePipeline でパイプラインを手動で開始す る (p. 110) で次の手順に従います パイプラインの表示 (AWS CLI の場合) パイプラインを編集するには update-pipeline コマンドを使用します Important パートナーアクションを含むパイプラインの編集に AWS CLI を使用することはできますが パー トナーアクションの JSON を手動で編集することはできません これを行った場合 パートナー アクションはパイプライン更新後に失敗します パイプラインを編集するには 1. ターミナルセッション (Linux, macos, or Unix) またはコマンドプロンプト (Windows) を開き getpipeline コマンドを実行して パイプライン構造を JSON ファイルにコピーします たとえ ば MyFirstPipeline という名前のパイプラインに対して 以下のコマンドを入力します aws codepipeline get-pipeline --name MyFirstPipeline >pipeline.json このコマンドは何も返しませんが 作成したファイルは コマンドを実行したディレクトリにありま す 2. 任意のプレーンテキストエディタで JSON ファイルを開き パイプラインに加える変更を反映するよ うにファイルの構造を変更します たとえば ステージを追加または削除すること または 既存の ステージに別のアクションを追加することができます 以下の例では pipeline.json ファイルに別のデプロイステージを追加する方法を示しています この ステージは Staging という名前の最初のデプロイステージの後に実行されます ここで示しているのは そのファイルの一部であり 構造全体ではありません 詳細につい ては AWS CodePipeline パイプライン構造のリファレンス (p. 244) を参照してくださ い 125

133 パイプラインの表示 (AWS CLI の場合), ] "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 ], "name": "Production", "actions": [ "inputartifacts": [ "name": "MyApp" ], "name": "Deploy-Second-Deployment", "actiontypeid": "category": "Deploy", "owner": "AWS", "version": "1", "provider": "CodeDeploy", "outputartifacts": [], "configuration": "ApplicationName": "CodePipelineDemoApplication", "DeploymentGroupName": "CodePipelineProductionFleet", "runorder": 1 ] 以下の例では ソースアクションとして GitHub リポジトリを使用するソースステージを追加する 方法を示しています AWS CodePipeline が GitHub とどのように統合されるかの詳細については ソース操作の統合 (p. 11) を参照してください ここで示しているのは そのファイルの一部であり 構造全体ではありません 詳細につい ては AWS CodePipeline パイプライン構造のリファレンス (p. 244) を参照してくださ い 126

134 パイプラインの表示 (AWS CLI の場合), "name": "Source", "actions": [ "inputartifacts": [], "name": "Source", "actiontypeid": "category": "Source", "owner": "ThirdParty", "provider": "GitHub", "version": "1", "outputartifacts": [ "name": "MyApp" ], "configuration": "Owner": "MyGitHubAccountName", "Repo": "MyGitHubRepositoryName", "PollForSourceChanges": "false", "Branch": "master", "OAuthToken": "****", "runorder": 1 ] AWS CodePipeline による GitHub リポジトリへのアクセスに使用するため OAuthToken の値は マークされたままになります この値には個人用のアクセストークンを使用できます 個人用のアク セストークンを作成するには パイプラインのエラー: 次のメッセージのパイプラインエラーが表示 されます PermissionError: GitHub リポジトリにアクセスできませんでした (p. 205) を参照 してください アクションを 1 つのステージから別のステージに移動するなど 一部の編集では アクショ ンについて最新の既知の状態履歴が削除されます パイプラインにアクションの OAuth トー クンなどの 1 つ以上の秘密パラメーターが含まれている場合 そのトークンは一連のアスタ リスク (****) でマスクされます これらの秘密パラメータは パイプラインのその部分を編 集する場合 (OAuth トークンを含むアクションの名前または OAuth トークンを使用するアク ションを含むステージの名前を変更した場合など) を除き 変更されません OAuth トーク ンを含むアクションに影響を与える変更を行う場合は 編集した JSON にトークンの値を 含める必要があります 詳細については AWS CodePipeline パイプライン構造のリファ レンス (p. 244) を参照してください セキュリティのベストプラクティスは 個人アク セストークンを定期的にローテーションすることです 詳細については GitHub と AWS CodePipeline CLI を使用して GitHub 個人用のアクセストークンを作成し 定期的にロー テーションする (p. 240) を参照してください CLI を使用して承認アクションをパイプラインに追加する方法については AWS CodePipeline のパ イプラインに手動の承認アクションを追加する (p. 179) を参照してください JSON ファイルの PollForSourceChanges パラメータが次のように設定されていることを確認しま す "PollForSourceChanges": "false", 127

135 パイプラインの表示 (AWS CLI の場合) AWS CodePipeline は Amazon CloudWatch Events を使用して AWS CodeCommit ソースリポジト リとブランチの変更または Amazon S3 ソースバケットの変更を検出します AWS CodePipeline は ウェブフックを使用して GitHub ソースリポジトリとブランチの変更を検出します 次のステップに は 手動でこれらのリソースを作成する手順が含まれています フラグを false に設定すると 定期 的なチェックが無効になります これは 推奨される変更検出メソッドを使用する場合には必須では ありません 3. get-pipeline コマンドを使用して取得したパイプライン構造を使用している場合 JSON ファイ ルの構造を変更する必要があります update-pipeline コマンドが使用できるように ファイルか ら metadata 行を削除する必要があります JSON ファイルのパイプライン構造からセクションを削 除します ("metadata": 行と "created" "pipelinearn" および "updated" フィール ド) たとえば 構造から以下の行を削除します "metadata": "pipelinearn": "arn:aws:codepipeline:region:account-id:pipeline-name", "created": "date", "updated": "date" ファイルを保存します 4. パイプラインの編集に CLI を使用する場合には 推奨される変更検出リソースを手動でパイプライン 用に管理する必要があります AWS CodeCommit リポジトリは CloudWatch イベント ルールを作成する必要があります 詳細 については AWS CodeCommit パイプライン (CLI) を開始する CloudWatch イベント ルールを 作成する (p. 96) を参照してください Amazon S3 ソースは CloudWatch イベント ルールおよび AWS CloudTrail 証跡を作成する必要が あります 詳細については CloudWatch イベント ルールを使用して Amazon S3 パイプライン を自動的に開始する (p. 99) を参照してください GitHub ソースを作成する場合 ウェブフックを作成する必要があります 詳しくは ウェブフッ クを使用して自動的に GitHub パイプラインを開始する (p. 105) を参照してください 5. 変更を適用するには パイプライン JSON ファイルを指定して update-pipeline コマンドを実行しま す Important ファイル名の前に必ず file:// を含めてください このコマンドでは必須です aws codepipeline update-pipeline --cli-input-json file://pipeline.json このコマンドは 編集したパイプラインの構造全体を返します update-pipeline コマンドは パイプラインを停止します update-pipeline コマンドを実行し たときにパイプラインによりリビジョンが実行されている場合 その実行は停止します 更 新されたパイプラインによりそのリビジョンを実行するには パイプラインを手動で開始す る必要があります 6. AWS CodePipeline コンソールを開き 編集したパイプラインを選択します そのパイプラインには 行った変更が示されます ソース場所を次に変更すると 修正した構造のパ イプラインによりそのリビジョンが実行されます 128

136 パイプラインの詳細と履歴の表示 7. 修正した構造のパイプラインによりその最新のリビジョンを手動で実行するには start-pipelineexecution コマンドを実行します 詳細については AWS CodePipeline でパイプラインを手動で開 始する (p. 110) を参照してください パイプラインの構造および想定値の詳細については AWS CodePipeline パイプライン構造のリファレ ンス (p. 244) および AWS CodePipeline API リファレンス を参照してください AWS CodePipeline でパイプラインの詳細と履歴を 表示する AWS CodePipeline コンソールまたは AWS CLI を使用して AWS アカウントに関連付けられているパイ プラインの詳細を表示できます トピック パイプラインの詳細と履歴を表示する (コンソール) (p. 129) パイプラインの詳細と履歴を表示する (CLI) (p. 131) パイプラインの詳細と履歴を表示する (コンソール) AWS CodePipeline コンソールを使用して アカウントのすべてのパイプラインのリストを表示できま す パイプラインで最後に実行されたアクション ステージ間の移行が有効か無効か 失敗したアクショ ンの有無 その他の情報など 各パイプラインの詳細を表示することもできます 履歴が記録されたすべ てのパイプライン実行の詳細を示す履歴ページを表示することもできます 実行履歴は 過去 12 か月に 制限されています 1 時間後には パイプラインの詳細ビューがブラウザで自動的に更新されなくなります 現在の 情報を表示するには ページを更新します パイプラインを表示するには 1. AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline) を開きます AWS アカウントに関連付けられているすべてのパイプラインの名前と作成日が表示され 実行履歴を 表示するためのリンクも示されます 2. 1 つのパイプラインの詳細を表示するには [Name] でパイプラインを選択します パイプラインを選 択し [View pipeline (パイプラインの表示)] を選択します パイプラインの詳細ビューが開いて 各 ステージの各アクションの状態や遷移の状態などが表示されます 129

137 パイプラインの詳細と履歴を表示する (コンソール) グラフィカルビューには 各ステージについて以下の情報が表示されます ステージ名 ステージ用に設定されたすべてのアクション ステージ間の遷移の状態 (有効または無効) ステージ間の矢印の状態によって示されます 有効な 移行は矢印とその横にある [移行を無効にする] ボタンとともに示されます 無効にされた移行は 下に取り消し線が付いた矢印 およびその横の [移行を有効にする] ボタンで示されます ステージのステータスを示すカラーバー: グレー: まだ実行はなし 青: 進行中 緑: 成功 赤: 失敗 グラフィカルビューには 各ステージのアクションについて以下の情報も表示されます アクションの名前 AWS CodeDeploy などのアクションのプロバイダー アクションが最後に実行されたとき アクションが成功したか失敗したか アクションの最後の実行について 他の詳細へのリンク (使用可能であれば) 最新のパイプラインの実行によりステージで実行されているソースリビジョンの詳細 また は AWS CodeDeploy デプロイの場合は ターゲットインスタンスにデプロイされた最新のソース リビジョンの詳細 3. パイプラインのステージのアクションについて設定の詳細を表示するには アクションの横にある情 報アイコンを選択するかカーソルを合わせます 4. アクションのプロバイダーの詳細を表示するには プロバイダーを選択します たとえば 上記の例 のパイプラインの [Staging] または [Production] ステージで AWS CodeDeploy を選択した場合 その ステージ用に設定されたデプロイグループの AWS CodeDeploy コンソールページが表示されます 5. ステージのアクションについて進行状況の詳細を表示するには 進行中のアクション ([In Progress] に よって示される) の横に表示される [Details] を選択します アクションが進行中の場合は 段階的な 進行状況と 実行されたステップまたはアクションが表示されます 130

138 パイプラインの詳細と履歴を表示する (CLI) 詳細は GitHub リポジトリから内容を取得するソースアクションについては表示できます が Amazon S3 バケットまたは AWS CodeCommit リポジトリから内容を取得するアクショ ンについては表示できません 6. 手動承認用に設定されたアクションを承認または拒否するには [確認] を選択します 7. 正常に完了しなかったステージでアクションを再試行するには [Retry] を選択します 8. ステージで完了したアクションについてエラーや失敗の詳細を確認するには [Details] を選択しま す 最後に実行されたアクションの詳細が そのアクションの結果も含めて ([成功] または [失敗]) 表 示されます 9. ステージでの最新のパイプラインの実行に使用されているソースアーティファクト (パイプラインの 最初のステージで生成された出力アーティファクト) の詳細を表示するには ステージの下部にある 詳細情報領域をクリックします コミット ID チェックインコメント アーティファクトが作成また は更新されてからの時間など 識別子の詳細を表示できます 詳細については AWS CodePipeline でパイプラインの現在のソースリビジョンの詳細を表示する (p. 199) を参照してください 10. パイプラインの最新の実行の詳細を表示するには [履歴の表示] を選択します 過去の実行について は 実行 ID ステータス 開始時刻と終了時刻 継続時間 コミット ID メッセージなど ソース アーティファクトに関連するリビジョンの詳細を表示できます パイプラインの詳細と履歴を表示する (CLI) パイプラインとパイプラインの実行の詳細を表示するには 以下のコマンドを実行します list-pipelines コマンドは AWS アカウントに関連付けられているすべてのパイプラインの概要を表示し ます get-pipeline コマンドは 1 つのパイプラインの詳細を表示します list-pipeline-executions パイプラインの最新の実行の概要を取得します get-pipeline-execution パイプラインの実行に関する情報 (アーティファクト パイプラインの実行 ID パイプラインの名前 バージョン ステータスなど) を表示します CLI を使用してステージの最新のパイプライン実行で使用されたソースリビジョンの詳細を表示する方法 については パイプラインの現在のソースリビジョンの詳細を表示する (CLI の場合) (p. 200) を参照 してください パイプラインを表示するには 1. ターミナル (Linux, macos, or Unix) またはコマンドプロンプト (Windows) を開き AWS CLI を使用 して list-pipelines コマンドを実行します aws codepipeline list-pipelines このコマンドは AWS アカウントに関連付けられているすべてのパイプラインのリストを返します 2. パイプラインの詳細を表示するには パイプラインの一意の名前を指定して get-pipeline コマンドを 実行します たとえば MyFirstPipeline という名前のパイプラインの詳細を表示するには 以下 のように入力します aws codepipeline get-pipeline --name MyFirstPipeline このコマンドは パイプラインの構造を返します 131

139 パイプラインの詳細と履歴を表示する (CLI) 3. パイプラインの現在の状態の詳細を表示するには パイプラインの一意の名前を指定して getpipeline-state コマンドを実行します たとえば MyFirstPipeline という名前のパイプラインの現 在の状態の詳細を表示するには 以下のように入力します aws codepipeline get-pipeline-state --name MyFirstPipeline このコマンドは パイプラインのすべてのステージの現在のステータスと それらのステージでのア クションのステータスを返します 以下の例では MyFirstPipeline という名前の 3 ステージパイプラインについて返されたデータを 示しています ここで 最初と 2 番目のステージとアクションは成功を示し 3 つ目のステージとア クションは失敗を示しており 2 番目と 3 番目のステージ間の遷移は無効です "updated": , "created": , "pipelineversion": 1, "pipelinename": "MyFirstPipeline", "stagestates": [ "actionstates": [ "actionname": "Source", "entityurl": " "latestexecution": "status": "Succeeded", "laststatuschange": ], "stagename": "Source", "actionstates": [ "actionname": "Deploy-CodeDeploy-Application", "entityurl": " "latestexecution": "status": "Succeeded", "laststatuschange": , "externalexecutionurl": " "externalexecutionid": ""c53dbd42-this-is-an-example"", "summary": "Deployment Succeeded" ], "inboundtransitionstate": "enabled": true, "stagename": "Staging", "actionstates": [ "actionname": "Deploy-Second-Deployment", "entityurl": " "latestexecution": "status": "Failed", "errordetails": "message": "Deployment Group is already deploying deployment...", "code": "JobFailed", 132

140 パイプラインの詳細と履歴を表示する (CLI) 4. ] "laststatuschange": ], "inboundtransitionstate": "disabledreason": "Disabled while I investigate the failure", "enabled": false, "lastchangedat": , "lastchangedby": "arn:aws:iam::80398example:user/codepipelineuser", "stagename": "Production" パイプラインの過去の実行の詳細を表示するには パイプラインの一意の名前を指定して listpipeline-executions コマンドを実行します たとえば MyFirstPipeline という名前のパイプライ ンの現在の状態の詳細を表示するには 以下のように入力します aws codepipeline list-pipeline-executions --pipeline-name MyFirstPipeline このコマンドは 過去 12 か月間に履歴が記録されたすべてのパイプライン実行に関する概要情報を 返します 概要には 開始時刻と終了時刻 期間 ステータスが含まれます 以下の例では 3 つの実行があった MyFirstPipeline という名前のパイプラインについて返された データを示しています "pipelineexecutionsummaries": [ "lastupdatetime": , "pipelineexecutionid": "7cf7f7cb g-j458-d7eu3EXAMPLE", "starttime": , "status": "Succeeded", "lastupdatetime": , "pipelineexecutionid": "3137f7cb-8d494hj4-039j-d84l-d7eu3EXAMPLE", "starttime": , "status": "Succeeded", "lastupdatetime": , "pipelineexecutionid": "4992f7jf-7cf7-913k-k334-d7eu3EXAMPLE", "starttime": , "status": "Succeeded" ] パイプラインの実行について詳細を表示するには パイプライン実行の一意の ID を指定して getpipeline-execution コマンドを実行します たとえば 前の例の最初の実行の詳細を表示するには 以 下のように入力します aws codepipeline get-pipeline-execution --pipeline-name MyFirstPipeline --pipelineexecution-id 7cf7f7cb g-j458-d7eu3EXAMPLE このコマンドは パイプラインの実行の概要情報 (アーティファクトの詳細 パイプラインの実行 ID 名前 バージョン パイプラインのステータスなど) を返します 133

141 パイプラインの削除 以下の例では MyFirstPipeline という名前のパイプラインについて返されたデータを示していま す "pipelineexecution": "pipelineexecutionid": "3137f7cb-7cf7-039j-s83l-d7eu3EXAMPLE", "pipelineversion": 2, "pipelinename": "MyFirstPipeline", "status": "Succeeded", "artifactrevisions": [ "created": , "revisionchangeidentifier": " ", "revisionid": "7636d59f3c461cEXAMPLE8417dbc6371", "name": "MyApp", "revisionsummary": "Updating the application for feature " ] AWS CodePipeline のパイプラインの削除 パイプラインは好きなときに編集して機能を変更することができますが 削除することもできます AWS CodePipeline コンソールまたは delete-pipeline コマンドを AWS CLI で使用して パイプラインを削除で きます トピック パイプラインの削除 (コンソールの場合) (p. 134) パイプラインの削除 (CLI の場合) (p. 134) パイプラインの削除 (コンソールの場合) パイプラインを削除するには 1. AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline) を開きます AWS アカウントに関連付けられているすべてのパイプラインの名前とステータスが表示されます 2. [Name] で 削除するパイプラインの名前を選択します 3. パイプライン詳細ページで [編集] を選択します 4. [Edit] ページで [Delete] を選択します 5. フィールドに delete と入力して確認し [Delete (削除)] を選択します Important このアクションは元に戻すことができません パイプラインの削除 (CLI の場合) AWS CLI を使用してパイプラインを手動で削除するには delete-pipeline コマンドを使用します 134

142 実行履歴の表示 Important パイプラインを削除すると 元に戻すことはできません 確認ダイアログボックスは表示されま せん コマンド実行後 パイプラインは削除されますが パイプラインで使用したリソースは削 除されません これにより そのようなリソースを使用する新しいパイプラインを作成し ソフ トウェアのリリースを自動化しやすくなります パイプラインを削除するには 1. ターミナル (Linux, macos, or Unix) またはコマンドプロンプト (Windows) を開き AWS CLI で削除するパイプラインの名前を指定して delete-pipeline コマンドを実行します たとえ ば MyFirstPipeline という名前のパイプラインを削除するには 以下のように入力します aws codepipeline delete-pipeline --name MyFirstPipeline このコマンドは何も返しません 2. 不要になったリソースをすべて削除します パイプラインを削除しても パイプラインで使用されているリソースは削除されません たとえば コードのデプロイに使用した AWS CodeDeploy または Elastic Beanstalk アプリ ケーションは削除されません また AWS CodePipeline コンソールからパイプラインを作 成した場合は AWS CodePipeline によってパイプラインのアーティファクトの保存用に作 成された Amazon S3 バケットも削除されません 不要なリソースは必ず削除し 今後課金 されないようにしてください たとえば コンソールを使用して初めてパイプラインを作 成する場合 すべてのパイプラインのすべてのアーティファクトを保存するために 1 つの Amazon S3 バケットが AWS CodePipeline で作成されます すべてのパイプラインを削除し た場合は バケットの削除 のステップに従います AWS CodePipeline での実行履歴の表示 パイプラインの実行履歴では パイプラインそれぞれの開始時に関連するコミット ID とソースリビジョン を表示できます トピック 実行履歴の表示 (p. 135) 実行履歴の表示 1. AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline) を開きます AWS アカウントに関連付けられたすべてのパイプラインの名前と そのステータスが表示されます 2. パイプラインの実行履歴を開くには [名前] で パイプラインの名前を選択します 3. パイプラインの各実行に関連するステータス ソースリビジョン 変更の詳細が表示されます 135

143 他のアカウントからリソースを 使用するパイプラインを作成する 他の AWS アカウントからリソースを使用するパイ プラインを AWS CodePipeline に作成 他の AWS アカウントによって作成し 管理されるリソースを使用するパイプラインを作成します たと えば パイプラインと AWS CodeDeploy リソースに別のアカウントを使用します そのためには 使用 する AWS Key Management Service (AWS KMS) を作成してパイプラインに追加し クロスアカウントア クセスを有効化するようにアカウントのポリシーおよびロールをセットアップします ソースアクションでは 他の AWS アカウントの Amazon S3 バケットを使用することはできませ ん このウォークスルーおよびサンプルでは AccountA は パイプラインの作成に使用したアカウントで す このアカウントでは Amazon S3 バケットにアクセスして AWS CodePipeline によって使用される パイプラインアーティファクトおよびサービスロールを保存することができます AccountB は AWS CodeDeploy によって使用される AWS CodeDeploy アプリケーション デプロイグループ サービスロー ルを作成するために使用したアカウントです AccountA でパイプラインを編集して AccountB で作成した AWS CodeDeploy アプリケーションを使 用するには アプリケーションを使用するには AccountA を以下のようにします AccountB の ARN またはアカウント ID をリクエストします (このウォークスルーで AccountB ID は 012ID_ACCOUNT_B) パイプラインのリージョンで AWS KMS カスタマー管理のキーを作成または使用し そのキーを使用 して サービスロール (AWS-CodePipeline-Service) および AccountB にアクセス許可を付与しま す Amazon S3バケットに対する AccountB のアクセス許可を付与する Amazon S3 バケットポリシーを作 成します (例: codepipeline-us-east ) AccountA が AccountB によって設定されているロールを再開できるようにするポリシーを作成し そ のポリシーをサービスロール (AWS-CodePipeline-Service) にアタッチします デフォルトキーではなく カスタマー管理型の AWS KMS キーを使用するようにパイプラインを編集し ます AccountB のリソースが AccountA で作成されているパイプラインにアクセスできるようにするに は AccountB は以下のように行います AccountA の ARN またはアカウント ID をリクエストします (このウォークスルーで AccountA ID は 012ID_ACCOUNT_A) AWS CodeDeploy に設定されている Amazon EC2インスタンスロール に適用されるポリシーを作成 します このポリシーで Amazon S3 bucket (codepipeline-us-east ) にアクセス できます AWS CodeDeploy に設定されている Amazon EC2インスタンスロール に適用されるポリシーを作成 します このポリシーで AWS KMS カスタマー管理型キーにアクセスして AccountA のパイプライン アーティファクトを暗号化できるようになります AccountA がロールを再開できるようにする信頼関係ポリシーを適用して IAM ロール (CrossAccount_Role) を設定し アタッチします パイプラインで必要なデプロイリソースにアクセスできるようにするポリシーを作成 し CrossAccount_Role にアタッチします Amazon S3 バケット (codepipeline-us-east ) にアクセスできるようにするポリ シーを作成し CrossAccount_Role にアタッチします 136

144 前提条件: AWS KMS 暗号化キーの作成 トピック 前提条件: AWS KMS 暗号化キーの作成 (p. 137) ステップ 1: アカウントポリシーおよびロールのセットアップ (p. 137) ステップ 2: パイプラインの編集 (p. 143) 前提条件: AWS KMS 暗号化キーの作成 カスタマー管理型のキーは リージョンだけでなく すべての AWS KMS キーで固有です パイプライン が作成されたリージョンと同じリージョン (例: us-east-2) のカスタマー管理型の AWS KMS キーを作成 する必要があります AWS CodePipeline で使用できるリージョンとエンドポイントの詳細については リージョン とエンドポイント を参照してください AWS KMS でカスタマー管理キーを作成するには 1. AccountA を使用してAWS マネジメントコンソール にサインインし console.aws.amazon.com/iam/ で IAM コンソールを開きます 2. [ダッシュボード] で [Encryption keys] を選択します 3. [Encryption keys] の [Filter] で 選択したリージョンが パイプラインを作成したリージョンと一致す ることを確認してから [Create key] を選択します たとえば パイプラインを us-east-2 に作成した場合は フィルタが 米国東部 (オハイオ) に設定され ていることを確認します 4. [Alias] に このキーに使用するエイリアス (PipelineName-Key など) を入力します 必要に応じ て このキーの説明を入力し [次のステップ] を選択します 5. [キー管理アクセス許可の定義] で このキーの管理者となる IAM ユーザーかその他のユーザー また はグループを選択し [次のステップ] を選択します 6. [キーの使用アクセス許可の定義] の [このアカウント] で パイプラインのサービスロールの名前 (AWS-CodePipeline-Service など) を選択します [外部アカウント] で [外部アカウントの追加] を選 択します ARN の一部として AccountB のアカウント ID を入力し [次のステップ] を選択します 7. [キーポリシーのプレビュー] で ポリシーを確認し [完了] を選択します 8. キーのリストから キーのエイリアスを選択し その ARN (arn:aws:kms:useast-2:012id_account_a:key/ example など) にコピーしま す この ARN は パイプラインの編集時とポリシーの設定時に必要になります ステップ 1: アカウントポリシーおよびロールのセッ トアップ AWS KMS キーを作成したら クロスアカウントアクセスを有効にするポリシーを作成してアタッチしま す 作成するには AccountA および AccountB の両方からアクションを行う必要があります トピック パイプラインを作成するポリシーおよびロールをアカウントに設定 (AccountA) (p. 138) AWS リソースを所有するポリシーおよびロールをアカウントに設定 (AccountB) (p. 140) 137

145 ステップ 1: アカウントポリシー およびロールのセットアップ パイプラインを作成するポリシーおよびロールをアカウントに設 定 (AccountA) 他の AWS アカウントに関連付ける AWS CodeDeploy リソースを使用するパイプラインを作成するに は AccountA で アーティファクトを保存する Amazon S3 バケットおよび AWS CodePipeline のサー ビスロールの両方のポリシーを設定する必要があります AccountB へのアクセスを許可する Amazon S3 バケットのポリシーを作成するには (コンソール) 1. AccountA を使用して AWS マネジメントコンソール にサインインし console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます 2. Amazon S3 バケットのリストで パイプラインのアーティファクトが保存される Amazon S3 バケッ トを選択します このバケットには codepipeline-region example という名前が付けられ ます ここで region はパイプラインを作成した AWS リージョンであり EXAMPLE はバ ケット名を一意にするための 10 桁の乱数です (codepipeline-us-east など) 3. Amazon S3 バケットの詳細ページで [プロパティ] を選択します 4. プロパティペインで [アクセス許可] を展開し [バケットポリシーの追加] を選択します ポリシーが Amazon S3 バケットにすでにアタッチされている場合は [バケットポリシーの 編集] を選択します 以下の例のステートメントを既存のポリシーに追加できます 新しいポ リシーを追加するには そのためのリンクを選択し AWS ポリシージェネレーターの指示に 従います 詳細については IAM ポリシーの概要 を参照してください 5. [Bucket Policy Editor] ウィンドウに以下のポリシーを入力します これにより AccountB は パイ プラインアーティファクトへのアクセスが許可され カスタムソースやビルドアクションなどのアク ションにより出力アーティファクトが作成されたときに そのアーティファクトの追加が可能になり ます 次の例では AccountB の ARN は 012ID_ACCOUNT_B です Amazon S3 バケットの ARN は codepipeline-us-east です これらの ARN を アクセスを許可するアカ ウントの ARN および Amazon S3 バケットの ARN に置き換えます "Version": " ", "Id": "SSEAndSSLPolicy", "Statement": [ "Sid": "DenyUnEncryptedObjectUploads", "Effect": "Deny", "Principal": "*", "Action": "s3:putobject", "Resource": "arn:aws:s3:::codepipeline-us-east /*", "Condition": "StringNotEquals": "s3:x-amz-server-side-encryption": "aws:kms", "Sid": "DenyInsecureConnections", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::codepipeline-us-east /*", "Condition": "Bool": "aws:securetransport": false 138

146 ステップ 1: アカウントポリシー およびロールのセットアップ, "Sid": "", "Effect": "Allow", "Principal": "AWS": "arn:aws:iam::012id_account_b:root", "Action": [ "s3:get*", "s3:put*" ], "Resource": "arn:aws:s3:::codepipeline-us-east /*", "Sid": "", "Effect": "Allow", "Principal": "AWS": "arn:aws:iam::012id_account_b:root", "Action": "s3:listbucket", "Resource": "arn:aws:s3:::codepipeline-us-east " ] 6. [保存] を選択したら ポリシーエディタを閉じます 7. [保存] を選択して Amazon S3 バケットに対するアクセス許可を保存します AWS CodePipeline のサービスロールのポリシーを作成するには (コンソール) 1. AccountA を使用してAWS マネジメントコンソール にサインインし console.aws.amazon.com/iam/ で IAM コンソールを開きます 2. [ダッシュボード] で [ロール] を選択します 3. [ロール名] の下にあるロールのリストで AWS CodePipeline のサービスロールの名前を選択します デフォルトでは AWS-CodePipeline-Service です サービスロールに異なる名前を使用した場合は リストからその名前を選択してください 4. [概要] ページの [アクセス許可] タブで [インラインポリシー] を展開し [ロールポリシーの作成] を選 択します ロールポリシーを以前に作成していない場合 [ロールポリシーの作成] は表示されません 代わりに 新しいポリシーを作成するためのリンクを選択します 5. [許可を設定] ページで [カスタムポリシー] [Select] の順に選択します 6. [ポリシーの確認] ページの [ポリシー名] にポリシーの名前を入力します [ポリシードキュメン ト] に以下のポリシーを入力して AccountB がそのロールを引き受けるようにします 次の例で は 012ID_ACCOUNT_B は AccountB の ARN です "Version": " ", "Statement": "Effect": "Allow", "Action": "sts:assumerole", "Resource": [ "arn:aws:iam::012id_account_b:role/*" ] 139

147 ステップ 1: アカウントポリシー およびロールのセットアップ 7. [Validate Policy] を選択します 8. ポリシーが検証されたら [ポリシーの適用] を選択します AWS リソースを所有するポリシーおよびロールをアカウントに 設定 (AccountB) AWS CodeDeploy にアプリケーション デプロイ デプロイグループを作成したら あわせて Amazon EC2インスタンスロール を作成します ([Run Deployment Walkthrough] ウィザードを使用している場合 はこのロールが作成されますが 手動で作成することもできます ) AccountA で作成されたパイプライ ンで AccountB で作成された AWS CodeDeploy リソースを使用するには 以下のように行います パイプラインアーティファクトが保存されている Amazon S3 バケットにアクセスできるようにするイ ンスタンスロールのポリシーを設定します クロスアカウントアクセス用に設定されている AccountB に 2 番目のロールを作成します この 2 番目のロールでは AccountA の Amazon S3 バケットにのみアクセスできます これに は AWS CodeDeploy リソースにアクセスできるポリシーと AccountA でロールを再開できる信頼関 係ポリシーも必要です これらのポリシーは 各 AWS アカウントを使用して作成されているパイプラインで使用され る AWS CodeDeploy リソースのセットアップにのみ使用できます そのほかの AWS リソース の場合は リソース要件固有のポリシーが必要です AWS CodeDeploy (コンソール) 用に設定した Amazon EC2 インスタンスロールのポリシーを作成 するには 1. AccountB を使用して AWS マネジメントコンソール にサインインし console.aws.amazon.com/iam/ で IAM コンソールを開きます 2. [ダッシュボード] で [ロール] を選択します 3. [ロール名] の下にあるロールのリストで AWS CodeDeploy アプリケーションの Amazon EC2 インス タンスロールとして使用するサービスロールの名前を選択します このロール名はさまざまで デプ ロイグループで複数のインスタンスロールを使用できます 詳細については Amazon EC2 インス タンスの IAM インスタンスプロファイルを作成する を参照してください 4. [概要] ページの [アクセス許可] タブで [インラインポリシー] を展開し [ロールポリシーの作成] を選 択します 5. [許可を設定] ページで [カスタムポリシー] [Select] の順に選択します 6. [ポリシーの確認] ページの [ポリシー名] にポリシーの名前を入力します [ポリシードキュメント] に以下のポリシーを入力して AccountA によってパイプラインのアーティファクト (この例では codepipeline-us-east ) の保存に使用される Amazon S3 バケットへのアクセス を許可します "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "s3:get*" ], "Resource": [ "arn:aws:s3:::codepipeline-us-east /*" ], 140

148 ステップ 1: アカウントポリシー およびロールのセットアップ ] "Effect": "Allow", "Action": [ "s3:listbucket" ], "Resource": [ "arn:aws:s3:::codepipeline-us-east " ] 7. [Validate Policy] を選択します 8. ポリシーが検証されたら [ポリシーの適用] を選択します 9. 2 番目のポリシーを作成します AWS KMS ここでarn:aws:kms:useast-1:012ID_ACCOUNT_A:key/ EXAMPLE は AccountA で作 成されたカスタマー管理キーの ARN であり AccountB にそのキーの使用を許可するように設定し ています "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "kms:describekey", "kms:generatedatakey*", "kms:encrypt", "kms:reencrypt*", "kms:decrypt" ], "Resource": [ "arn:aws:kms:useast-1:012id_account_a:key/ example" ] ] Important ここで示しているように このポリシーでは AWS KMS キーのリソース ARN の一部として AccountA のアカウント ID を使用する必要があります 使用しないと そのポリシーは機能 しません 10. [Validate Policy] を選択します 11. ポリシーが検証されたら [ポリシーの適用] を選択します ここで クロスアカウントアクセスに使用する IAM ロールを作成し AccountA でロールを再開できる ように設定します このロールには AccountA のアーティファクトを保存するために使用する AWS CodeDeploy リソースおよび Amazon S3 バケットにアクセスできるようにするポリシーを追加する必要が あります IAM でクロスアカウントロールを設定するには 1. AccountB を使用して AWS マネジメントコンソール にサインインし console.aws.amazon.com/iam/ で IAM コンソールを開きます 2. [ダッシュボード] で [ロール] [新しいロールの作成] の順に選択します 141

149 ステップ 1: アカウントポリシー およびロールのセットアップ 3. [新しいロールの設定] ページで このロールの名前 (CrossAccount_Role など) を [Role Name] に 入力します IAM の命名規則に従う限り このロールの名前は任意に指定できます ロールの目的が 明確になる名前を付けることを検討してください 4. [ロールタイプの選択] ページで [Role for Cross-Account Access] を選択します [Provide access between AWS accounts you own] の横にある [Select] を選択します 5. AWS CodePipeline でパイプラインを作成するアカウントの AWS アカウント ID (AccountA) を入力 し [次のステップ] を選択します この手順では AccountB と AccountA との間に信頼関係ポリシーを作成します 6. [ポリシーのアタッチ] で [AmazonS3ReadOnlyAccess] を選択してから [次のステップ] を選択しま す これは 使用するポリシーではありません ウィザードを完了するために ポリシーを選択 する必要があります 7. [Review] ページで [Create Role] を選択します 8. ロールのリストから 作成したポリシー (CrossAccount_Role など) を選択して そのロールの [Summary] ページを開きます 9. [アクセス許可] [インラインポリシー] の順に展開します インラインポリシーを作成するためのリン クを選択します 10. [許可を設定] ページで [カスタムポリシー] [Select] の順に選択します 11. [ポリシーの確認] ページの [ポリシー名] にポリシーの名前を入力します [ポリシードキュメント] に 以下のポリシーを入力して AWS CodeDeploy リソースへのアクセスを許可します "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "codedeploy:createdeployment", "codedeploy:getdeployment", "codedeploy:getdeploymentconfig", "codedeploy:getapplicationrevision", "codedeploy:registerapplicationrevision" ], "Resource": "*" ] 12. [Validate Policy] を選択します 13. ポリシーが検証されたら [ポリシーの適用] を選択します 14. [インラインポリシー] で [ロールポリシーの作成] を選択します 15. [許可を設定] ページで [Custom policy] [Select] の順に選択します 16. [ポリシーの確認] ページの [ポリシー名] にポリシーの名前を入力します [ポリシードキュメント] に 以下のポリシーを入力して このロールに AccountA の Amazon S3 バケットに対する入力アーティ ファクトの取得と出力アーティファクトの保存を許可します "Version": " ", "Statement": [ "Effect": "Allow", 142

150 ステップ 2: パイプラインの編集 ] "Action": [ "s3:getobject*", "s3:putobject", "s3:putobjectacl", "codecommit:listbranches", "codecommit:listrepositories" ], "Resource": [ "arn:aws:s3:::codepipeline-us-east /*" ] 17. [Validate Policy] を選択します 18. ポリシーが検証されたら [ポリシーの適用] を選択します 19. [Managed Policies] で [ポリシー名] の下にあるポリシーのリストで AmazonS3ReadOnlyAccess を 見つけ [Detach Policy] を選択します プロンプトが表示されたら [Detach] を選択します ステップ 2: パイプラインの編集 AWS CodePipeline コンソールを使用して 他の AWS アカウントに関連付けられているリソースを使用す るパイプラインを作成または編集することはできません ただし コンソールを使用してパイプラインの 一般的な構造を作成し その後 AWS CLI を使用して パイプラインを編集し そのリソースを追加する ことができます または 既存のパイプラインの構造を使用して リソースを手動で追加することもでき ます 別の AWS アカウントに関連付けられているリソースを追加するには (AWS CLI) 1. ターミナル (Linux, macos, or Unix) またはコマンドプロンプト (Windows) で リソースを追加するパ イプラインに対して get-pipeline コマンドを実行します コマンドの出力を JSON ファイルにコピー します たとえば MyFirstPipeline という名前のパイプラインに対しては 以下のようなコマンドを 入力します aws codepipeline get-pipeline --name MyFirstPipeline >pipeline.json 2. 出力は pipeline.json ファイルに送られます 任意のプレーンテキストエディタで JSON ファイルを開きます アーティファク トストアの "type": "S3" の後に KMS 暗号化キー ID タイプ情報を追加しま す ここで codepipeline-us-east は パイプラインのアー ティファクトの保存に使用される Amazon S3 バケット名で arn:aws:kms:useast-1:012id_account_a:key/ example は 先ほど作成し たカスタマー管理キーの ARN です "artifactstore : "location": "codepipeline-us-east ", "type": "S3", "encryptionkey": "id": "arn:aws:kms:useast-1:012id_account_a:key/ example", "type": "KMS", 3. AccountB に関連付けられている AWS CodeDeploy リソースを使用するためのデプロイアクション をステージに追加して 作成したクロスアカウントロール (CrossAccount_Role) の rolearn 値な どを指定します 143

151 ステップ 2: パイプラインの編集 以下の例では ExternalDeploy という名前のデプロイアクションを追加する JSON を示していま す また Staging という名前のステージで AccountB で作成された AWS CodeDeploy リソースを 使用しています 以下の例では AccountB の ARN は 012ID_ACCOUNT_B です, "name": "Staging", "actions": [ "inputartifacts": [ "name": "MyAppBuild" ], "name": "ExternalDeploy", "actiontypeid": "category": "Deploy", "owner": "AWS", "version": "1", "provider": "CodeDeploy", "outputartifacts": [], "configuration": "ApplicationName": "AccountBApplicationName", "DeploymentGroupName": "AccountBApplicationGroupName", "runorder": 1, "rolearn": "arn:aws:iam::012id_account_b:role/crossaccount_role" ] これは パイプライン全体の JSON ではなく ステージでのアクションの構造です 4. ファイルを保存します 5. 変更を適用するには 以下のように パイプライン JSON ファイルを指定して update-pipeline コマ ンドを実行します Important ファイル名の前に必ず file:// を含めてください このコマンドでは必須です aws codepipeline update-pipeline --cli-input-json file://pipeline.json このコマンドは 編集したパイプラインの構造全体を返します 別の AWS アカウントに関連付けられているリソースを使用するパイプラインをテストするには 1. ターミナル (Linux, macos, or Unix) またはコマンドプロンプト (Windows) で 以下のように パイプ ラインの名前を指定して start-pipeline-execution コマンドを実行します aws codepipeline start-pipeline-execution --name MyFirstPipeline 詳細については AWS CodePipeline でパイプラインを手動で開始する (p. 110) を参照してくだ さい 144

152 ステップ 2: パイプラインの編集 AccountA を使用して AWS マネジメントコンソール にサインインし console.aws.amazon.com/codepipeline で AWS CodePipeline コンソールを開きます AWS アカウントに関連付けられているすべてのパイプラインの名前が表示されます [Name] で 先ほど編集したパイプラインの名前を選択します これにより パイプラインの詳細 ビューが開いて パイプラインの各ステージの各アクションの状態などがわかります パイプラインの進行状況を監視します 別の AWS アカウントに関連付けられているリソースを使用 するアクションの成功メッセージを待ちます AccountA を使用してサインインしている間にアクションの詳細を表示しようとする と エラーが発生します サインアウトしてから AccountB でサインインして AWS CodeDeploy でデプロイの詳細を表示します 145

153 パイプラインのカスタムアクションの作成 AWS CodePipeline でのアクションの 操作 AWS CodePipeline で アクションはパイプラインのステージのシーケンスの一部です また そのス テージのアーティファクトで実行されるタスクです パイプラインのアクションは ステージ設定の定義 に従い 指定された順序で順番に または同時に実行されます AWS CodePipeline では 6 種類のアクションをサポートしています 送信元 ビルド テスト デプロイ 承認 呼び出し アクションの種類に基づいてパイプラインに統合できる AWS サービスや そのパートナー製品および サービスの詳細については AWS CodePipeline アクションの種類との統合 (p. 11) を参照してくださ い トピック AWS CodePipeline でのカスタムアクションの作成と追加 (p. 146) AWS CodePipeline で パイプラインに AWS Lambda 関数を呼び出す (p. 156) AWS CodePipeline で失敗したアクションを再試行する (p. 173) AWS CodePipeline で承認アクションを管理する (p. 175) AWS CodePipeline でのカスタムアクションの作成 と追加 AWS CodePipeline には 自動リリースプロセスの構築 テストおよびデプロイリソースを設定する手助 けとなるアクションが複数含まれています 社内で開発したビルドプロセスやテストスイート等 デフォ ルトアクションに含まれていないアクティビティがリリースプロセスに含まれる場合 その目的のために カスタムアクションを作成し パイプラインに含めることができます AWS CLI を使って AWS アカウ ントに関連付けられたパイプラインにカスタムアクションを作成できます カスタムアクションは次のカテゴリに分類されます: 項目を構築または変換するビルドアクション 項目を 1 つ以上のサーバー ウェブサイトまたはリポジトリにデプロイするデプロイアクション 自動テストを設定して実行するテストアクション 関数を実行する呼び出しアクション カスタムアクション を作成する際 この カスタムアクション のジョブリクエストの AWS CodePipeline をポーリングするジョブワーカーを作成し ジョブを実行してステータス結果を AWS CodePipeline に 返す必要があります このジョブワーカーは AWS CodePipeline のパブリックエンドポイントにアクセ スできる限り どのコンピュータまたはリソースにあっても構いません 簡単にアクセスおよびセキュリ 146

154 カスタムアクション (CLI) の作成 ティを管理するために ジョブワーカーを Amazon EC2 インスタンスにホストすることを考慮してくださ い 次の図では カスタム構築アクションを含むパイプラインの高レベルビューを示します: パイプラインにステージに一部として カスタムアクション が含まれる場合 パイプラインはジョブリクエ ストを作成します カスタムジョブワーカーはそのリクエストを検出し そのジョブを実行します (この 例では サードパーティ構築ソフトウェアを使用するカスタムプロセス) アクションが完了すると ジョ ブワーカーは成功結果または失敗結果を返します 成功結果を受け取ると パイプラインはリビジョンと その アーティファクト を次のアクションに 移行 します 失敗が返された場合 パイプラインはリビジョ ンを次のアクションに 移行 しません これらの手順では すでにAWS CodePipeline の使用開始 (p. 9)のステップを完了していることを 前提としています トピック カスタムアクション (CLI) の作成 (p. 147) カスタムアクションのジョブワーカーの作成 (p. 150) パイプラインにカスタムアクションを追加する (p. 154) カスタムアクション (CLI) の作成 AWS CLI を使用したカスタムアクションの作成 1. テキストエディタを開き アクションカテゴリ アクションプロバイダー およびカスタムアクショ ンで必要な設定を含む カスタムアクションの JSON ファイルを作成します たとえば 1 つのプロ パティのみを必要とするカスタムビルドアクションを作成する場合 JSON ファイルは次のようにな ります "category": "Build", "provider": "My-Build-Provider-Name", "version": "1", "settings": 147

155 カスタムアクション (CLI) の作成 "entityurltemplate": " "executionurltemplate": " lastsuccessfulbuild/externalexecutionid/", "configurationproperties": [ "name": "ProjectName", "required": true, "key": true, "secret": false, "queryable": false, "description": "The name of the build project must be provided when this action is added to the pipeline.", "type": "String" ], "inputartifactdetails": "maximumcount": integer, "minimumcount": integer, "outputartifactdetails": "maximumcount": integer, "minimumcount": integer entityurltemplate および executionurltemplate を含む 2 つのプロパティが JSON ファイ ルに含まれています 設定プロパティが必須で かつシークレットではない限り Config:name 形式に従って URL テンプレート内のカスタムアクションの設定プロパティで名前を参照できます たとえば 上の例では entityurltemplate の値は設定プロパティ ProjectName を参照します entityurltemplate: アクションのサービスプロバイダーに関する情報を提供する静的リンク この例では ビルドシステムには 各ビルドプロジェクトへの静的リンクが含まれます リンク形 式は ビルドプロバイダー (または テストなど別のアクションタイプを作成する場合はその他の サービスプロバイダー) に応じて変わります このリンク形式を指定し カスタムアクションが追 加されたときに ユーザーはこのリンクを選択してブラウザを開き ビルドプロジェクト (または テスト環境) の詳細を提供するウェブサイト上のページに移動できるようにする必要があります executionurltemplate: アクションの現在の実行または最新の実行に関する情報で更新される動 的リンク カスタムジョブワーカーがジョブのステータス (成功 失敗 進行中など) を更新すると きに リンクを完了するために使用される externalexecutionid も提供されます このリンク を使用して アクションの実行に関する詳細を提供できます たとえば パイプラインでアクションを表示すると 次の 2 つのリンクが表示されます 148

156 カスタムアクション (CLI) の作成 この静的リンクは カスタムアクションを追加し entityurltemplate でアドレスを指 した後で表示されます (カスタムアクションを作成するときに指定します) この動的なリンクは アクションを実行し executionurltemplate でアドレスを指す たびに更新されます (カスタムアクションを作成するときに指定します) これらのリンクタイプ および RevisionURLTemplate と ThirdPartyURL の詳細 については AWS CodePipeline API リファレンス の ActionTypeSettings および CreateCustomActionType を参照してください アクション構造の要件とアクションの作成方法の 詳細については AWS CodePipeline パイプライン構造のリファレンス (p. 244) を参照してくだ さい 2. JSON ファイルを保存し 簡単に覚えることができる名前 (MyCustomAction.json など) を付けま す 3. AWS CLI をインストールしたコンピュータで ターミナルセッション (Linux OS X Unix) またはコ マンドプロンプト (Windows) を開きます 4. AWS CLI を使用して aws codepipeline create-custom-action-type コマンドを実行して 先ほど作成 した JSON ファイルの名前を指定します たとえば ビルド カスタムアクション を作成するには以下のようにします Important ファイル名の前に必ず file:// を含めてください このコマンドでは必須です aws codepipeline create-custom-action-type --cli-input-json file://mycustomaction.json 5. このコマンドは 作成したカスタムアクションの構造全体 および追加された JobList アクション 設定プロパティを返します パイプラインにカスタムアクションを追加するときは JobList を使用 して プロバイダーからのプロジェクトのうちジョブをポーリングできるものを指定できます これ を設定しない場合 カスタムジョブワーカーがジョブをポーリングするときに 使用可能なすべての ジョブが返されます たとえば 前のコマンドは 次のような構造を返します "actiontype": "inputartifactdetails": "maximumcount": 1, "minimumcount": 1, "actionconfigurationproperties": [ "secret": false, "required": true, "name": "ProjectName", "key": true, "description": "The name of the build project must be provided when this action is added to the pipeline." ], "outputartifactdetails": "maximumcount": 0, "minimumcount": 0, 149

157 カスタムアクションのジョブワーカーの作成 "id": "category": "Build", "owner": "Custom", "version": "1", "provider": "My-Build-Provider-Name", "settings": "entityurltemplate": " "executionurltemplate": " lastsuccessfulbuild/externalexecutionid/" create-custom-action-type コマンドの出力の一部として id セクションには "owner": "Custom" が含まれます AWS CodePipeline はカスタムアクションタイプの所有者とし て Custom を自動的に割り当てます create-custom-action-type コマンドまたは updatepipeline コマンドを使用する場合 この値を割り当てまたは変更することはできません カスタムアクションのジョブワーカーの作成 カスタムアクションは カスタムアクション のジョブリクエストに AWS CodePipeline をポーリングし ジョブを実行して AWS CodePipeline にステータス結果を返すジョブワーカーを必要とします ジョブ ワーカーは AWS CodePipeline のパブリックエンドポイントにアクセスできる限り どのコンピュータ またはリソースにあっても構いません ジョブワーカーを設計する方法は複数あります 次のセクションでは AWS CodePipeline のカスタム ジョブワーカーを開発するための 実践的なガイダンスを提供します トピック ジョブワーカーのためのアクセス権限管理戦略の選択および設定 (p. 150) カスタムアクションのジョブワーカーを開発する (p. 152) カスタムジョブワーカーのアーキテクチャおよび例 (p. 153) ジョブワーカーのためのアクセス権限管理戦略の選択および設定 AWS CodePipeline でカスタムアクションのカスタムジョブワーカーを開発するには ユーザーやアクセ ス権限管理を統合するための戦略が必要になります 最も簡単な戦略は IAM インスタンスロールで Amazon EC2 インスタンスを作成することでカスタムジョ ブワーカーに必要なインフラストラクチャを追加することです これは 統合に必要なリソースを簡単 にスケールアップすることを可能にします 組み込み統合と AWS を使用し カスタムジョブワーカーと AWS CodePipeline の間の相互作用を簡素化できます Amazon EC2 インスタンスを設定するには 1. Amazon EC2 の詳細を参照し 統合に適しているかどうかを判断します 詳細については Amazon EC2 - 仮想サーバーのホスティング を参照してください 2. Amazon EC2 インスタンスの作成を開始します 詳細については Amazon EC2 Linux インスタン スの使用開始 を参照してください 他に考慮すべき戦略は ID フェデレーションと IAM を使用した既存の ID プロバイダーシステムおよび リソースとの統合です この戦略は お客様がすでに企業 ID プロバイダーを持っているか ウェブ ID プ 150

158 カスタムアクションのジョブワーカーの作成 ロバイダーを使用するユーザーをサポートできるよう設定されている場合に 特に便利です ID フェデ レーションは IAM ユーザーを作成または管理することなく AWS CodePipeline を含めた AWS リソー スへの安全なアクセスを可能とします パスワードのセキュリティや認証情報の更新に機能やポリシーを 活用することができます サンプルアプリケーションをお客様自身の設計のテンプレートとして使用でき ます ID フェデレーションをセットアップするには 1. IAM 認証フェデレーションの詳細について学習します 詳細については フェデレーションの管 理 を参照してください 2. 一時的なアクセス権を付与するシナリオ の例を参照して カスタムアクションのニーズに最適な 一時アクセスのシナリオを確認します 3. インフラストラクチャに関連する ID フェデレーションのコード例を確認します たとえば 以下の参 照先をご覧ください Active Directory ユースケースのための ID フェデレーションのサンプルアプリケーション Amazon Cognito を使用したモバイルアプリケーションの ID フェデレーション 4. ID フェデレーションの設定を開始します 詳細については IAM ユーザーガイド の ID プロバイ ダーとフェデレーション を参照してください 考慮すべき 3 つ目の戦略は カスタムアクションおよびジョブワーカーを実行する際に AWS アカウント の下で使用する IAM ユーザーの作成です IAM ユーザーを設定するには 1. IAM のベストプラクティスとユースケースの詳細については IAM のベストプラクティスとユース ケース を参照してください 2. AWS アカウント内での IAM ユーザーの作成 のステップに従って IAM ユーザーの作成を開始し ます 次は カスタムジョブワーカーで使用するために作成する可能性があるポリシーの例です このポリシー は例に過ぎず そのまま提供されています "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "codepipeline:pollforjobs", "codepipeline:acknowledgejob", "codepipeline:getjobdetails", "codepipeline:putjobsuccessresult", "codepipeline:putjobfailureresult" ], "Resource": [ "arn:aws:codepipeline:us-east-2::actiontype:custom/build/mybuildproject/1/" ] ] IAM ユーザーには AWSCodePipelineCustomActionAccess に管理ポリシーの使用を考慮してくだ さい 151

159 カスタムアクションのジョブワーカーの作成 カスタムアクションのジョブワーカーを開発する アクセス権限管理戦略を選択した後 ジョブワーカーが AWS CodePipeline とどう相互作用するかを考慮 した方が良いでしょう 次の概要図は ビルドプロセスの カスタムアクション およびジョブワーカーの ワークフローを示します 1. ジョブワーカーは PollForJobs を使用するジョブに AWS CodePipeline をポーリングします 2. パイプラインがソースステージでの変更によってトリガーされる際 (例えば 開発者が変更をコミット した際) 自動リリースプロセスが開始します プロセスは カスタムアクション が設定されたステー ジまで継続します このステージのアクションに達すると AWS CodePipeline はジョブをキューにい れます このジョブは ジョブワーカーがステータスを取得するために PollForJobs を再度呼び出す と 表示されます PollForJobs からジョブ詳細を取得し ジョブワーカーに渡します 3. ジョブワーカーは AcknowledgeJob を呼び出し AWS CodePipeline にジョブ確認を送りま す AWS CodePipeline は ジョブワーカーがジョブを継続するべきであることを示す確認を返し (InProgress) または 複数のジョブワーカーがジョブをポーリングしていて 別のジョブワー カーがすでにジョブを要求した場合は InvalidNonceException エラーレスポンスが返されま す InProgress 確認の後 AWS CodePipeline は結果が返されるまで待機します 4. ジョブワーカーはリビジョンで カスタムアクション を開始し その後にアクションが実行されます 他のアクションとともに カスタムアクション は結果をジョブワーカーに返します ビルドカスタムア クションの例では アクションが Amazon S3 バケットからアーティファクトを引き出し 構築して 構築されたアーティファクトを Amazon S3 バケットに正常にプッシュします 5. アクションが実行されている間 ジョブワーカーは継続トークン (JSON フォーマットのビルド識別子 や Amazon S3 オブジェクトキーなど ジョブワーカーによって生成されたジョブの状態のシリアル化) を使って ExternalExecutionId と同様に executionurltemplate のリンクに入力するための PutJobSuccessResult 情報を呼び出すことができます これにより パイプラインのコンソール ビューは 特定のアクション詳細への有効なリンクで進行中に更新されます 必要ではありませんが 152

160 カスタムアクションのジョブワーカーの作成 ユーザーがカスタムアクションの実行中にそのステータスを確認することを可能にするため ベストプ ラクティスです PutJobSuccessResult が呼び出されると ジョブは完了したと見なされます 継続トークンが含 まれる新しいジョブが AWS CodePipeline に作成されます このジョブは ジョブワーカーが再度 PollForJobs を呼び出すと表示されます この新しいジョブは アクションの状態を確認するために 使用でき 継続トークンを伴って返すか アクションが完了すると 継続トークンを伴わずに返しま す ジョブワーカーがカスタムアクションの処理をすべて行っている場合 ジョブワーカーの処理 を少なくとも 2 つのステップに分割することを考慮した方が良いでしょう 最初のステップで は アクションの詳細ページを確立します 詳細ページを作成すると ジョブワーカーの状態 をシリアル化し サイズ制限の対象である継続トークンとして返します (AWS CodePipeline 制限 (p. 252)を参照してください) 例えば 継続トークンとして使用する文字列に アク ションの状態を書き込むことができます ジョブワーカーの処理の 2 番目のステップ (および その後のステップ) が アクションの実際の作業を実行します 最終ステップは 最終ステッ プの継続トークンなしで成功または失敗を AWS CodePipeline に返します 継続トークンの使用に関する詳細については AWS CodePipeline API リファレンス でPutJobSuccessResult の仕様を参照してください 6. カスタムアクションが完了すると ジョブワーカーは 2 つの内 1 つの API を呼び出すことで カスタム アクション の結果を AWS CodePipeline に返します: カスタムアクション の実行が成功したことを示す 継続トークンなしの PutJobSuccessResult カスタムアクション の実行が成功しなかったことを示すPutJobFailureResult 結果によって パイプラインは次のアクションに継続 (成功) するか 停止 (失敗) します カスタムジョブワーカーのアーキテクチャおよび例 高レベルワークフローを綿密に計画した後 ジョブワーカーを作成できます 最終的にはカスタムアク ションの仕様がジョブワーカーに必要なものを決定しますが カスタムアクションのジョブワーカーの多 くは以下の機能を含みます: PollForJobs を使用して AWS CodePipeline からジョブをポーリングする AcknowledgeJob PutJobSuccessResult および PutJobFailureResult を使用してジョブを 確認し AWS CodePipeline に結果を返す パイプラインの Amazon S3 バケットからアーティファクトを取得する または &S3; バケットにアー ティファクトを配置する Amazon S3 バケットからアーティファクトをダウンロードするには 署名 バージョン 4 署名 (Sig V4) を使用する Amazon S3 クライアントを作成する必要があります Sig V4 は SSE-KMS に必要です Amazon S3 バケットにアーティファクトをアップロードするには さらに Amazon S3 PutObject リ クエストを設定する必要があります 現在 暗号化をサポートされているのは SSE-KMS のみです アーティファクトをアップロードするために デフォルトキーとカスタマー管理型のキーのどちらを使 用するべきかについては ジョブワーカーは ジョブデータを参照し 暗号化キープロパティを確認する 必要があります 暗号化キーが設定されている場合 SSE-KMS を設定する際にはその暗号化キー ID を 使用する必要があります キーが Null の場合 デフォルトマスターキーを使用します それ以外に設定 されない限り AWS CodePipeline は デフォルトの Amazon S3 マスターキーを使用します 次のサンプルは Java で KMS パラメータを作成する方法を示します: private static SSEAwsKeyManagementParams createsseawskeymanagementparams(final EncryptionKey encryptionkey) if (encryptionkey!= null 153

161 パイプラインにカスタムアクションを追加する && encryptionkey.getid()!= null && EncryptionKeyType.KMS.toString().equals(encryptionKey.getType())) // Use a customer-managed encryption key return new SSEAwsKeyManagementParams(encryptionKey.getId()); // Use the default master key return new SSEAwsKeyManagementParams(); 他のサンプルについては AWS SDK を使用した Amazon S3 への AWS Key Management Service の 指定 を参照してください AWS CodePipeline の Amazon S3 バケットの詳細については AWS CodePipeline の概念 (p. 4) を参照してください カスタムジョブワーカーのさらに複雑な例が GitHub から入手可能です このサンプルは オープンソー スコードであり 現状のまま提供されています AWS CodePipeline のサンプルジョブワーカー: GitHub リポジトリからサンプルをダウンロードしてく ださい パイプラインにカスタムアクションを追加する ジョブワーカーを入手した後 カスタムアクション をパイプラインに追加できます 追加するには [パイ プラインの作成] ウィザードを使用し 新しいパイプラインを作成して選択するか 既存のパイプラインを 編集して カスタムアクション を追加します または AWS CLI SDK API を使用します ビルドまたはデプロイアクションであれば パイプラインの作成ウィザードでカスタムアクショ ンを含むパイプラインを作成できます カスタムアクションがテスト カテゴリーにある場合は 既存のパイプラインを編集して追加する必要があります トピック パイプラインにカスタムアクションを追加する (コンソール) (p. 154) 既存のパイプラインにカスタムアクションを追加する (CLI) (p. 154) パイプラインにカスタムアクションを追加する (コンソール) AWS CodePipeline コンソールを使用してカスタムアクションでパイプラインを作成するには AWS CodePipeline でパイプラインを作成する (p. 113) のステップに従い 必要な数だけテストしたいステージ からカスタムアクションを選択します AWS CodePipeline コンソールを使用して既存のパイプラインに カスタムアクションを追加するには AWS CodePipeline でパイプラインを編集する (p. 122) のステップ に従い パイプラインの 1 つ以上のステージにカスタムアクションを追加します 既存のパイプラインにカスタムアクションを追加する (CLI) AWS CLI を使用して既存のパイプラインに カスタムアクション を追加します 1. ターミナルセッション (Linux, macos, or Unix) またはコマンドプロンプト (Windows) を開き getpipeline コマンドを実行して 編集するパイプライン構造を JSON ファイルにコピーします たとえ ば MyFirstPipeline という名前のパイプラインの場合は 以下のコマンドを入力します aws codepipeline get-pipeline --name MyFirstPipeline >pipeline.json このコマンドは何も返しませんが 作成したファイルは コマンドを実行したディレクトリにありま す 154

162 パイプラインにカスタムアクションを追加する 2. 任意のテキストエディタで JSON ファイルを開き ファイルの構造を変更して カスタムアクション を既存のステージに追加します そのステージでアクションを別のアクションと並行して実行する場合は そのアクションと 同じ runorder 値を割り当てます たとえば Build という名前のステージを追加し パイプラインの構造を変更してそのステージにビル ドカスタムアクションを追加する場合は次のように JSON を変更して デプロイステージの前にビル ドステージを追加します, "name": "MyBuildStage", "actions": [ "inputartifacts": [ "name": "MyApp" ], "name": "MyBuildCustomAction", "actiontypeid": "category": "Build", "owner": "Custom", "version": "1", "provider": "My-Build-Provider-Name", "outputartifacts": [ "name": "MyBuiltApp" ], "configuration": "ProjectName": "MyBuildProject", "runorder": 1 ], "name": "Staging", "actions": [ "inputartifacts": [ "name": "MyBuiltApp" ], "name": "Deploy-CodeDeploy-Application", "actiontypeid": "category": "Deploy", "owner": "AWS", "version": "1", "provider": "CodeDeploy", "outputartifacts": [], "configuration": "ApplicationName": "CodePipelineDemoApplication", "DeploymentGroupName": "CodePipelineDemoFleet", "runorder": 1 155

163 パイプラインに Lambda 関数を呼び出す 3. ] ] 変更を適用するには 以下のように パイプライン JSON ファイルを指定して update-pipeline コマ ンドを実行します Important ファイル名の前に必ず file:// を含めてください このコマンドでは必須です aws codepipeline update-pipeline --cli-input-json file://pipeline.json このコマンドは 編集したパイプラインの構造全体を返します 4. AWS CodePipeline コンソールを開き 編集したパイプラインの名前を選択します そのパイプラインには 行った変更が示されます ソース場所を次に変更すると 修正した構造のパ イプラインによりそのリビジョンが実行されます AWS CodePipeline で パイプラインに AWS Lambda 関数を呼び出す AWS Lambda はサーバーをプロビジョニングしたり管理したりしなくてもコードを実行できるコンピュー ティングサービスです Lambda 関数を作成し パイプラインでアクションとして追加できます Lambda 機能は ほぼ全てのタスクを実行するための関数を書くことを可能にするため パイプラインの機能をカ スタマイズできます Lambda 関数を作成して実行すると AWS アカウントに課金される場合があります 詳細につい ては 料金表を参照してください Lambda 関数をパイプラインで使用するいくつかの方法を以下に示します AWS CloudFormation テンプレートを適用または更新することで 環境に対する変更を展開するため AWS CloudFormation を使ってパイプラインの 1 つのステージでリソースをオンデマンドで作成し 別 のステージで削除するため CNAME 値を入れ替える Lambda 関数を使用して ダウンタイムなしで アプリケーションバージョン を AWS Elastic Beanstalk にデプロイするため Amazon ECS Docker インスタンスにデプロイするため AMI スナップショットを作成することで リソースをデプロイまたは作成する前にバックアップするた め IRC クライアントにメッセージを投稿する等 サードパーティー製品によってパイプラインに統合を追 加するため このトピックでは お客様が AWS CodePipeline と AWS Lambda に精通しており パイプラインおよび 関数 ならびにそれらが依存する IAM ポリシーおよびロールの作成方法がわかっているとします このト ピックでは 以下の方法を示します ウェブページが正常にデプロイされたかをテストする Lambda 関数を作成する AWS CodePipeline および Lambda 実行ロール ならびにパイプラインの一部として関数を実行するた めに必要なアクセス権限を設定する 156

164 ステップ 1: パイプラインを作成する Lambda 関数をアクションとして追加するためにパイプラインを編集する 手動で変更をリリースすることでアクションをテストする このトピックには AWS CodePipeline で Lambda 関数を使用することによる柔軟性を示すためのサンプ ル関数が含まれています 基本的な関数 (p. 159) AWS CodePipeline で使用する基本的な Lambda 関数を作成する [詳細] リンク内の AWS CodePipeline に アクションの成功または失敗の結果を返す AWS CloudFormation テンプレートを使用するサンプル Python 関数 (p. 164) 複数の設定値を関数に渡すために JSON でエンコードされたユーザーパラメータを使用する (get_user_params) アーティファクトバケットで.zip アーティファクトと相互作用する (get_template) 長時間実行の非同期処理を監視する継続トークンを使用する (continue_job_later) これは 5 分 のランタイム (Lambda での制限) を超えても アクションが継続し 関数が成功することを可能にし ます 各サンプル関数には ロールに追加する必要がある権限についての情報が含まれます AWS Lambda にお けるその他の制限の詳細については AWS Lambda 開発者ガイドの 制限 を参照してください Important このトピックに含まれるサンプルコード ロール およびポリシーは単なる例であり 現状のま ま提供されます トピック ステップ 1: パイプラインを作成する (p. 157) ステップ 2: Lambda 関数を作成する (p. 158) ステップ 3: AWS CodePipeline コンソールのパイプラインへの Lambda 関数の追加 (p. 161) ステップ4: Lambda 関数でパイプラインをテストします (p. 162) ステップ 5: 次のステップ (p. 162) JSON イベントの例 (p. 163) 追加のサンプル関数 (p. 164) ステップ 1: パイプラインを作成する このステップでは 後に Lambda 関数を追加するパイプラインを作成します これは AWS CodePipeline のチュートリアル (p. 27) で作成したものと同じパイプラインです このパイプラインがま だアカウントに設定されていて Lambda 関数を作成する予定のリージョンと同じ場所にある場合 この ステップは省略できます Important Lambda 関数を作成するリージョンと同じ場所に パイプラインおよびそのすべてのリソースを 作成する必要があります パイプラインを作成するには 1. チュートリアル: シンプルなパイプラインを作成する (Amazon S3 バケットの場合) (p. 27) の最初 の 3 つのステップに従って Amazon S3 バケット AWS CodeDeploy リソース 2 ステージパイプ 157

165 ステップ 2: Lambda 関数を作成する ラインを作成します インスタンスタイプに応じて Amazon Linux オプションを選択します パイプ ラインには任意の名前を使用できますが このトピックの手順では MyLambdaTestPipeline を使用し ています 2. パイプラインのステータスページの [AWS CodeDeploy アクション] で [詳細] を選択します デプロ イグループのデプロイの詳細ページで リストからインスタンス ID を選択します 3. Amazon EC2 コンソールのインスタンスの [Description (説明)] タブで [パブリック IP] の IP アドレ ス ( など) をコピーします このアドレスを AWS Lambda で関数のターゲットとして使用 します AWS CodePipeline のデフォルトサービスロールである AWS-CodePipeline-Service は 関数を呼 び出すために必要な Lambda アクセス権限を含むため 追加の呼び出しポリシーやロールを作成 する必要はありません ただし デフォルトサービスロールを変更 または別のものを選択した 場合 ロールのポリシーが lambda:invokefunction および lambda:listfunctions 権限を 許可していることを確認してください そうしない場合 Lambda アクションを含むパイプライ ンは失敗します ステップ 2: Lambda 関数を作成する このステップでは HTTP リクエストを生成し ウェブページ上のテキスト行をチェックする Lambda 関 数を作成します このステップの一環として IAM ポリシーおよび Lambda 実行ロールを作成する必要が あります 詳細については AWS Lambda 開発者ガイドの アクセス権限モデル を参照してください 実行ロールを作成するには 1. AWS マネジメントコンソール にサインインし IAM コンソール iam/ を開きます 2. [Policies] を選択してから [Create Policy] を選択します[JSON] タブを選択して 次のポリシーを フィールドに貼り付けます "Version": " ", "Statement": [ "Action": [ "logs:*" ], "Effect": "Allow", "Resource": "arn:aws:logs:*:*:*", "Action": [ "codepipeline:putjobsuccessresult", "codepipeline:putjobfailureresult" ], "Effect": "Allow", "Resource": "*" ] 3. [ポリシーの確認] を選択します 4. [ポリシーの確認] ページで [名前] に ポリシー名 (CodePipelineLambdaExecPolicy など) を入 力します [説明] で Enables Lambda to execute code を入力します [Create Policy] を選択します 158

166 ステップ 2: Lambda 関数を作成する これらは Lambda 関数が AWS CodePipeline および Amazon CloudWatch とやり取りす るために必要な最小限のアクセス権限です このポリシーを拡張して 関数が他の AWS リ ソースとやり取りできるようにする場合は このポリシーを変更して それらの Lambda 関 数に必要なアクションを許可する必要があります ポリシーダッシュボードページで [ロール] [ロールの作成] の順に選択します [ロールの作成] ページで [AWS service (AWS のサービス)] を選択します [Lambda] を選択し [Next: Permissions (次へ: アクセス許可)] を選択します [アクセス許可ポリシーをアタッチする] ページで [CodePipelineLambdaExecPolicy] の横にある チェックボックスをオンにし [Next: Review(次へ: 確認)] を選択します [確認] ページの [ロール名] で名前を入力し [ロールの作成] を選択します AWS CodePipeline で使用するサンプル Lambda 関数を作成するには AWS マネジメントコンソール にサインインし にある AWS Lambda コンソールを開きます [関数] ページで [関数の作成] を選択します 3. Lambda ページの代わりに [ようこそ] ページが表示された場合は [今すぐ始める] を選択し ます [Create function] ページで [Author from scratch] を選択します [名前] に Lambda 関数の名前を入 力します (たとえば MyLambdaFunctionForAWSCodePipeline) [説明] に関数のオプションの 説明を入力します (たとえば A sample test to check whether the website responds with a 200 (OK) and contains a specific word on the page) [ランタイム] で [Node.js 6.10] を選択し 以下のコードを [Function code (関数コード)] ボックスにコピーします CodePipeline.job キーの下にあるイベントオブジェクトには ジョブの詳細が含まれま す AWS CodePipeline が Lambda に返す JSON イベントの完全な例については JSON イベントの例 (p. 163) を参照してください var assert = require('assert'); var AWS = require('aws-sdk'); var http = require('http'); exports.handler = function(event, context) var codepipeline = new AWS.CodePipeline(); // Retrieve the Job ID from the Lambda action var jobid = event["codepipeline.job"].id; // Retrieve the value of UserParameters from the Lambda action configuration in AWS CodePipeline, in this case a URL which will be // health checked by this function. var url = event["codepipeline.job"].data.actionconfiguration.configuration.userparameters; // Notify AWS CodePipeline of a successful job var putjobsuccess = function(message) var params = jobid: jobid ; codepipeline.putjobsuccessresult(params, function(err, data) 159

167 ステップ 2: Lambda 関数を作成する ; ); if(err) context.fail(err); else context.succeed(message); // Notify AWS CodePipeline of a failed job var putjobfailure = function(message) var params = jobid: jobid, failuredetails: message: JSON.stringify(message), type: 'JobFailed', externalexecutionid: context.invokeid ; codepipeline.putjobfailureresult(params, function(err, data) context.fail(message); ); ; // Validate the URL passed in UserParameters if(!url url.indexof(' === -1) putjobfailure('the UserParameters field must contain a valid URL address to test, including or return; // Helper function to make a HTTP GET request to the page. // The helper will test the response and succeed or fail the job accordingly var getpage = function(url, callback) var pageobject = body: '', statuscode: 0, contains: function(search) return this.body.indexof(search) > -1; ; http.get(url, function(response) pageobject.body = ''; pageobject.statuscode = response.statuscode; response.on('data', function (chunk) pageobject.body += chunk; ); response.on('end', function () callback(pageobject); ); ; response.resume(); ).on('error', function(error) // Fail the job if our request failed putjobfailure(error); ); getpage(url, function(returnedpage) try // Check if the HTTP response has a 200 status assert(returnedpage.statuscode === 200); // Check if the page contains the text "Congratulations" // You can change this to check for different text, or add other tests as required 160

168 ステップ 3: AWS CodePipeline コンソー ルのパイプラインへの Lambda 関数の追加 assert(returnedpage.contains('congratulations')); ; ); // Succeed the job putjobsuccess("tests passed."); catch (ex) // If any of the assertions failed then fail the job putjobfailure(ex); 4. [Role (ロール)] で [既存のロールを選択] を選択します [Existing role (既存のロール)] でロールを選 択し [Create function (関数の作成)] を選択します 5. [Handler (ハンドラ)] はデフォルト値のままにし [Role (ロール)] もデフォルトの CodePipelineLambdaExecRole のままにします 6. [基本設定] で [タイムアウト] で [20] を選択します 7. [Save] を選択します ステップ 3: AWS CodePipeline コンソールのパイプラ インへの Lambda 関数の追加 このステップでは パイプラインに新しいステージを追加し そのステージに関数を呼び出す Lambda ア クションを追加します ステージを追加するには 1. AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline) を開きます 2. [Welcome (ようこそ)] ページで 作成したパイプラインを選択します 3. パイプラインビューページで [編集] を選択します 4. [Edit (編集)] ページで [+ Add stage (ステージの追加)] を選択し AWS CodeDeploy アクショ ンを含むデプロイステージの後にステージを追加します ステージの名前を入力し (たとえ ば LambdaStage) [Add stage (ステージの追加)] を選択します Lambda アクションを既存のステージに追加することもできます デモンストレーション用 に ステージでの唯一のアクションとして Lambda 関数を追加して パイプラインにより アーティファクトが進行するにつれて その進行状況を簡単に表示できるようにしていま す 5. [+ Add action group (+ アクションの追加)] を選択します [アクションの編集] の [アクション名] に Lambda アクション (MyLambdaAction など) の名前を入力しま す [プロバイダ] で [AWS Lambda] を選択します [関数名] に Lambda 関数の名前 (MyLambdaFunctionForAWSCodePipeline など) を選択または入力します [ユーザーパラメータ] で 先ほどコピーした Amazon EC2 インスタンスの IP アドレス ( など) を指定 し [保存] を選択します 161

169 ステップ4: Lambda 関数でパイプラインをテストします このトピックでは IP アドレスを使用していますが 実際のシナリオでは 代わりに登録済 みのウェブサイト名 ( など) を指定できます AWS Lambda の イベントデータとハンドラの詳細については AWS Lambda 開発者ガイドの プログラミン グモデル を参照してください 6. [編集] ページで [パイプラインの変更を保存] を選択します ステップ4: Lambda 関数でパイプラインをテストしま す 関数をテストするには パイプラインを通して最新の変更をリリースします コンソールを使用してパイプラインによりアーティファクトの最新バージョンを実行するには 1. パイプラインの詳細ページで [変更のリリース] を選択します これにより ソースアクションで指 定した各ソース場所における最新のリビジョンがパイプラインで実行されます 2. Lambda アクションが完了したら [詳細] リンクを選択して Amazon CloudWatch での関数のログス トリーム (イベントの課金期間を含む) を表示します 関数が失敗した場合は CloudWatch ログから その原因について情報を得られます ステップ 5: 次のステップ Lambda 関数を作成し アクションとしてパイプラインに追加したので 次を実行できます: 他のウェブページをチェックする Lambda アクションをさらにステージに追加する 別の文字列をチェックする Lambda 関数を変更する 162

170 JSON イベントの例 Lambda 関数を試し パイプラインに独自の Lambda 関数を作成して追加する Lambda 関数を試し終わったら 追加料金を避けるために パイプラインから取り除き AWS Lambda か ら削除し IAM からロールを削除することを考慮してください 詳細については AWS CodePipeline で パイプラインを編集する (p. 122) AWS CodePipeline のパイプラインの削除 (p. 134)およびロールまたは インスタンスプロファイルの削除を参照してください JSON イベントの例 以下の例では AWS CodePipeline によって Lambda に送られたサンプル JSON イベントを示していま す このイベントの構造は GetJobDetails API へのレスポンスと似ていますが actiontypeid お よび pipelinecontext データタイプがありません 2 つのアクション設定の詳細 FunctionName お よび UserParameters は JSON イベントと GetJobDetails API へのレスポンスの両方に含まれま す コココココココココココココ の値は例または説明であり 実際の値ではありません "CodePipeline.job": "id": " abcd-1111-abcd abcdef", "accountid": " ", "data": "actionconfiguration": "configuration": "FunctionName": "MyLambdaFunctionForAWSCodePipeline", "UserParameters": "some-input-such-as-a-url" 163

171 追加のサンプル関数, "inputartifacts": [ "location": "s3location": "bucketname": "the name of the bucket configured as the pipeline artifact store in Amazon S3, for example codepipeline-us-east ", "objectkey": "the name of the application, for example CodePipelineDemoApplication.zip", "type": "S3", "revision": null, "name": "ArtifactName" ], "outputartifacts": [], "artifactcredentials": "secretaccesskey": "wjalrxutnfemi/k7mdeng/bpxrficyexamplekey", "sessiontoken": "MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w 0BAQUFADCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZ WF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIw EAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5 jb20whhcnmtewndi1mja0ntixwhcnmtiwndi0mja0ntixwjcbidelmakga1uebh MCVVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBb WF6b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMx HzAdBgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wgZ8wDQYJKoZIhvcNAQE BBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ21uUSfwfEvySWtC2XADZ4nB+BLYgVI k60cpiwsz3g93vueio3iynoh/f0wyk8m9trdhuduzg3qx4walg5m43q7wgc/mbq ITxOUSQv7c7ugFFDzQGBzZswY6786m86gpEIbb3OhjZnzcvQAaRHhdlQWIMm2nr AgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4nUhVVxYUntneD9+h8Mg9q6q+auN KyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0FkbFFBjvSfpJIlJ00zbhNYS5f6Guo EDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTbNYiytVbZPQUQ5Yaxu2jXnimvw 3rrszlaEXAMPLE=", "accesskeyid": "AKIAIOSFODNN7EXAMPLE", "continuationtoken": "A continuation token if continuing job" 追加のサンプル関数 以下のサンプル Lambda 関数は AWS CodePipeline でパイプラインに利用できる追加の機能を示しま す これらの機能を使うには 各サンプルの概要に示されている通りに Lambda 実行ロールのポリシー を変更する必要がある場合があります トピック AWS CloudFormation テンプレートを使用するサンプル Python 関数 (p. 164) AWS CloudFormation テンプレートを使用するサンプル Python 関数 以下のサンプルは 提供された AWS CloudFormation テンプレートに基づいたスタックを作成または更新 する関数を示します テンプレートによって Amazon S3 バケットが作成されます コストを最小限に抑 えるため デモンストレーション用に過ぎません 理想的には バケットに何かアップロードする前に スタックを削除した方が良いでしょう バケットにファイルをアップロードすると スタックを削除する 際にバケットを削除することはできません バケット自体を削除するには バケット内をすべて手動で削 除する必要があります 164

172 追加のサンプル関数 この Python サンプルは パイプラインで Amazon S3 バケットをソースアクションとして使用するか パイプラインでバージョニングされた Amazon S3 バケットにアクセスできることを前提としていま す AWS CloudFormation テンプレートを作成し 圧縮し.zip ファイルとしてそのバケットにアップ ロードします 次に この.zip ファイルをバケットから取得するソースアクションをパイプラインに追加 する必要があります このサンプルは 以下を紹介します: 複数の設定値を関数に渡すために JSON でエンコードされたユーザーパラメータの使用 (get_user_params) アーティファクトバケットにおける.zip アーティファクトとの相互作用 (get_template) 長時間実行の非同期処理を監視する継続トークンの使用 (continue_job_later) これは 5 分のラン タイム (Lambda での制限) を超えても アクションが継続し 関数が成功することを可能にします このサンプル Lambda 関数を使用するには Lambda 実行ロールのポリシーに AWS CloudFormation Amazon S3 AWS CodePipeline に対する Allow アクセス権限が含まれている必要があ ります (以下のサンプルポリシーを参照) "Version": " ", "Statement": [ "Action": [ "logs:*" ], "Effect": "Allow", "Resource": "arn:aws:logs:*:*:*", "Action": [ "codepipeline:putjobsuccessresult", "codepipeline:putjobfailureresult" ], "Effect": "Allow", "Resource": "*", "Action": [ "cloudformation:describestacks", "cloudformation:createstack", "cloudformation:updatestack" ], "Effect": "Allow", "Resource": "*", "Action": [ "s3:*" ], "Effect": "Allow", "Resource": "*" ] AWS CloudFormation テンプレートを作成するには いずれかのプレーンテキストエディタを開き 以下 のコードをコピーして貼り付けます: "AWSTemplateFormatVersion" : " ", 165

173 追加のサンプル関数 "Description" : "AWS CloudFormation template which creates an S3 bucket", "Resources" : "MySampleBucket" : "Type" : "AWS::S3::Bucket", "Properties" :, "Outputs" : "BucketName" : "Value" : "Ref" : "MySampleBucket", "Description" : "The name of the S3 bucket" これを template.json という名前の JSON ファイルとして template-package という名前のディレ クトリに保存します このディレクトリと template-package.zip という名前のファイルで圧縮 (.zip) ファイルを作成し 圧縮されたファイルをバージョニングされた Amazon S3 バケットにアップロードし ます すでにパイプラインに設定したバケットがある場合 それを使用できます 次に パイプラインを 編集して.zip ファイルを取得するソースアクションを追加します このアクションの出力に MyTemplate と名前を付けます 詳細については AWS CodePipeline でパイプラインを編集する (p. 122) を参照し てください サンプル Lambda 関数は これらのファイル名と圧縮された構造を想定しています ただし 本 サンプルでは独自の AWS CloudFormation テンプレートに置き換えることができます 独自のテ ンプレートを使用する場合は AWS CloudFormation テンプレートに必要な追加機能を許可する ように Lambda 実行ロールのポリシーを変更してください 以下のコードを Lambda 関数として追加するには 1. Lambda コンソールを開き [Create a Lambda function (Lambda 関数の作成)] を選択します 2. [Select blueprint] ページで [Skip] を選択します 3. [Configure function (関数の設定)] ページの [名前] に Lambda 関数の名前を入力します [説明] に関数 のオプションの説明を入力します 4. [Runtime] リストで [Python 2.7] を選択します 5. [Handler name (ハンドラ名)] の値はデフォルト値のままにしますが [Role (ロール)] は Lambda 実行 ロール (CodePipelineLambdaExecRole など) を使用します 6. [詳細設定] の [タイムアウト (秒)] で デフォルトの秒数 3 を 20 に置き換えます 7. 以下のコードを [Lambda function code (Lambda 関数コード)] にコピーします from future import print_function from boto3.session import Session import import import import import import import json urllib boto3 zipfile tempfile botocore traceback print('loading function') cf = boto3.client('cloudformation') code_pipeline = boto3.client('codepipeline') 166

174 追加のサンプル関数 def find_artifact(artifacts, name): """Finds the artifact 'name' among the 'artifacts' Args: artifacts: The list of artifacts available to the function name: The artifact we wish to use Returns: The artifact dictionary found Raises: Exception: If no matching artifact is found """ for artifact in artifacts: if artifact['name'] == name: return artifact raise Exception('Input artifact named "0" not found in event'.format(name)) def get_template(s3, artifact, file_in_zip): """Gets the template artifact Downloads the artifact from the S3 artifact store to a temporary file then extracts the zip and returns the file containing the CloudFormation template. Args: artifact: The artifact to download file_in_zip: The path to the file within the zip containing the template Returns: The CloudFormation template as a string Raises: Exception: Any exception thrown while downloading the artifact or unzipping it """ tmp_file = tempfile.namedtemporaryfile() bucket = artifact['location']['s3location']['bucketname'] key = artifact['location']['s3location']['objectkey'] with tempfile.namedtemporaryfile() as tmp_file: s3.download_file(bucket, key, tmp_file.name) with zipfile.zipfile(tmp_file.name, 'r') as zip: return zip.read(file_in_zip) def update_stack(stack, template): """Start a CloudFormation stack update Args: stack: The stack to update template: The template to apply Returns: True if an update was started, false if there were no changes to the template since the last update. Raises: Exception: Any exception besides "No updates are to be performed." """ try: cf.update_stack(stackname=stack, TemplateBody=template) return True except botocore.exceptions.clienterror as e: 167

175 追加のサンプル関数 if e.response['error']['message'] == 'No updates are to be performed.': return False else: raise Exception('Error updating CloudFormation stack "0"'.format(stack), e) def stack_exists(stack): """Check if a stack exists or not Args: stack: The stack to check Returns: True or False depending on whether the stack exists Raises: Any exceptions raised.describe_stacks() besides that the stack doesn't exist. """ try: cf.describe_stacks(stackname=stack) return True except botocore.exceptions.clienterror as e: if "does not exist" in e.response['error']['message']: return False else: raise e def create_stack(stack, template): """Starts a new CloudFormation stack creation Args: stack: The stack to be created template: The template for the stack to be created with Throws: Exception: Any exception thrown by.create_stack() """ cf.create_stack(stackname=stack, TemplateBody=template) def get_stack_status(stack): """Get the status of an existing CloudFormation stack Args: stack: The name of the stack to check Returns: The CloudFormation status string of the stack such as CREATE_COMPLETE Raises: Exception: Any exception thrown by.describe_stacks() """ stack_description = cf.describe_stacks(stackname=stack) return stack_description['stacks'][0]['stackstatus'] def put_job_success(job, message): """Notify CodePipeline of a successful job Args: job: The CodePipeline job ID message: A message to be logged relating to the job status Raises: Exception: Any exception thrown by.put_job_success_result() 168

176 追加のサンプル関数 """ print('putting job success') print(message) code_pipeline.put_job_success_result(jobid=job) def put_job_failure(job, message): """Notify CodePipeline of a failed job Args: job: The CodePipeline job ID message: A message to be logged relating to the job status Raises: Exception: Any exception thrown by.put_job_failure_result() """ print('putting job failure') print(message) code_pipeline.put_job_failure_result(jobid=job, failuredetails='message': message, 'type': 'JobFailed') def continue_job_later(job, message): """Notify CodePipeline of a continuing job This will cause CodePipeline to invoke the function again with the supplied continuation token. Args: job: The JobID message: A message to be logged relating to the job status continuation_token: The continuation token Raises: Exception: Any exception thrown by.put_job_success_result() """ # Use the continuation token to keep track of any job execution state # This data will be available when a new job is scheduled to continue the current execution continuation_token = json.dumps('previous_job_id': job) print('putting job continuation') print(message) code_pipeline.put_job_success_result(jobid=job, continuationtoken=continuation_token) def start_update_or_create(job_id, stack, template): """Starts the stack update or create process If the stack exists then update, otherwise create. Args: job_id: The ID of the CodePipeline job stack: The stack to create or update template: The template to create/update the stack with """ if stack_exists(stack): status = get_stack_status(stack) if status not in ['CREATE_COMPLETE', 'ROLLBACK_COMPLETE', 'UPDATE_COMPLETE']: # If the CloudFormation stack is not in a state where # it can be updated again then fail the job right away. put_job_failure(job_id, 'Stack cannot be updated when status is: ' + status) 169

177 追加のサンプル関数 return were_updates = update_stack(stack, template) if were_updates: # If there were updates then continue the job so it can monitor # the progress of the update. continue_job_later(job_id, 'Stack update started') else: # If there were no updates then succeed the job immediately put_job_success(job_id, 'There were no stack updates') else: # If the stack doesn't already exist then create it instead # of updating it. create_stack(stack, template) # Continue the job so the pipeline will wait for the CloudFormation # stack to be created. continue_job_later(job_id, 'Stack create started') def check_stack_update_status(job_id, stack): """Monitor an already-running CloudFormation update/create Succeeds, fails or continues the job depending on the stack status. Args: job_id: The CodePipeline job ID stack: The stack to monitor """ status = get_stack_status(stack) if status in ['UPDATE_COMPLETE', 'CREATE_COMPLETE']: # If the update/create finished successfully then # succeed the job and don't continue. put_job_success(job_id, 'Stack update complete') elif status in ['UPDATE_IN_PROGRESS', 'UPDATE_ROLLBACK_IN_PROGRESS', 'UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGRESS', 'CREATE_IN_PROGRESS', 'ROLLBACK_IN_PROGRESS']: # If the job isn't finished yet then continue it continue_job_later(job_id, 'Stack update still in progress') else: # If the Stack is a state which isn't "in progress" or "complete" # then the stack update/create has failed so end the job with # a failed result. put_job_failure(job_id, 'Update failed: ' + status) def get_user_params(job_data): """Decodes the JSON user parameters and validates the required properties. Args: job_data: The job data structure containing the UserParameters string which should be a valid JSON structure Returns: The JSON parameters decoded as a dictionary. Raises: Exception: The JSON can't be decoded or a property is missing. """ try: # Get the user parameters which contain the stack, artifact and file settings user_parameters = job_data['actionconfiguration']['configuration'] ['UserParameters'] 170

178 追加のサンプル関数 decoded_parameters = json.loads(user_parameters) except Exception as e: # We're expecting the user parameters to be encoded as JSON # so we can pass multiple values. If the JSON can't be decoded # then fail the job with a helpful message. raise Exception('UserParameters could not be decoded as JSON') if 'stack' not in decoded_parameters: # Validate that the stack is provided, otherwise fail the job # with a helpful message. raise Exception('Your UserParameters JSON must include the stack name') if 'artifact' not in decoded_parameters: # Validate that the artifact name is provided, otherwise fail the job # with a helpful message. raise Exception('Your UserParameters JSON must include the artifact name') if 'file' not in decoded_parameters: # Validate that the template file is provided, otherwise fail the job # with a helpful message. raise Exception('Your UserParameters JSON must include the template file name') return decoded_parameters def setup_s3_client(job_data): """Creates an S3 client Uses the credentials passed in the event by CodePipeline. These credentials can be used to access the artifact bucket. Args: job_data: The job data structure Returns: An S3 client with the appropriate credentials """ key_id = job_data['artifactcredentials']['accesskeyid'] key_secret = job_data['artifactcredentials']['secretaccesskey'] session_token = job_data['artifactcredentials']['sessiontoken'] session = Session(aws_access_key_id=key_id, aws_secret_access_key=key_secret, aws_session_token=session_token) return session.client('s3', config=botocore.client.config(signature_version='s3v4')) def lambda_handler(event, context): """The Lambda function handler If a continuing job then checks the CloudFormation stack status and updates the job accordingly. If a new job then kick of an update or creation of the target CloudFormation stack. Args: event: The event passed by Lambda context: The context passed by Lambda """ try: # Extract the Job ID job_id = event['codepipeline.job']['id'] 171

179 追加のサンプル関数 # Extract the Job Data job_data = event['codepipeline.job']['data'] # Extract the params params = get_user_params(job_data) # Get the list of artifacts passed to the function artifacts = job_data['inputartifacts'] stack = params['stack'] artifact = params['artifact'] template_file = params['file'] if 'continuationtoken' in job_data: # If we're continuing then the create/update has already been triggered # we just need to check if it has finished. check_stack_update_status(job_id, stack) else: # Get the artifact details artifact_data = find_artifact(artifacts, artifact) # Get S3 client to access artifact with s3 = setup_s3_client(job_data) # Get the JSON template file out of the artifact template = get_template(s3, artifact_data, template_file) # Kick off a stack update or create start_update_or_create(job_id, stack, template) except Exception as e: # If any other exceptions which we didn't expect are raised # then fail the job and log the exception message. print('function failed due to exception.') print(e) traceback.print_exc() put_job_failure(job_id, 'Function exception: ' + str(e)) print('function complete.') return "Complete." 8. 関数を保存します 9. AWS CodePipeline コンソールから パイプラインを編集して 関数をパイプラインのステージのア クションとして追加します [UserParameters] で JSON 文字列に次の 3 つのパラメーターを指定する 必要があります スタックの名前 AWS CloudFormation テンプレート名とファイルへのパス アプリケーション名 中括弧 ( ) を使用し パラメーターをカンマで区切ります たとえば MyTestStack という名前のスタックを 入力アーティファクト MyTemplate のパイプラインに対し て作成するには [UserParameters] に "stack":"myteststack","file":"template-package/ template.json","artifact":"mytemplate" と入力します [UserParameters] で入力アーティファクトを指定した場合でも [入力アーティファクト] の アクションに対しては この入力アーティファクトをやはり指定する必要があります 10. 変更をパイプラインに保存したら 手動で変更をリリースして アクションと Lambda 関数をテスト します 172

180 失敗したアクションを再試行する AWS CodePipeline で失敗したアクションを再試行 する AWS CodePipeline では アクションはステージでアーティファクトに対して実行されるタスクです 1 つ のアクションまたは一連のパラレルアクションが正常に完了しなかった場合 パイプラインは実行を停止 します 最初からパイプラインを再度実行する必要はなく ステージで最新の失敗したアクションを再試行できま す コンソールを使用してパイプラインを表示している場合は 失敗したアクションを再試行できるス テージに [再試行] ボタンが表示されます AWS CLI を使用している場合は get-pipeline-state コマンドを使用して 何らかのアクションが失敗した かどうかを判断できます 次の場合 アクションを再試行できない場合があります アクションが失敗した後 全体のパイプライン構造が変更されました ステージで 1 つ以上のアクションがまだ進行中です ステージで別の再試行がすでに進行中です トピック 失敗したアクションを再試行する (コンソール) (p. 173) 失敗したアクションを再試行する (CLI) (p. 174) 失敗したアクションを再試行する (コンソール) 1. AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline) を開きます AWS アカウントに関連付けられているすべてのパイプラインの名前が表示されます 2. [Name] で パイプラインの名前を選択します 3. 失敗したアクションが含まれるステージを見つけ [Retry] を選択します ステージで再試行できるアクションを特定するには [Retry] ボタンをポイントします 173

181 失敗したアクションを再試行する (CLI) 再試行したアクションがすべて正常に完了した場合 パイプラインは続行されます 失敗したアクションを再試行する (CLI) AWS CLI を使用して失敗したアクションを再試行するには まず パイプライン 失敗したアクションを 含むステージ そのステージでの最新のパイプラインの実行を識別する JSON ファイルを作成します そ の後 retry-stage-execution コマンドに --cli-input-json パラメータを指定して実行します JSON ファイルに必要な詳細を取得するには get-pipeline-state コマンドを使用するのが最も簡単です 1. ターミナル (Linux, macos, or Unix) またはコマンドプロンプト (Windows) で パイプラインに対して get-pipeline-state コマンドを実行します たとえば MyFirstPipeline という名前のパイプラインに対 しては 以下のようなコマンドを入力します aws codepipeline get-pipeline-state --name MyFirstPipeline コマンドに対する応答には 各ステージのパイプラインの状態情報が含まれます 以下の例では 応 答は [Staging] ステージで 1 つ以上のアクションが失敗したことを示しています 2. "updated": , "created": , "pipelineversion": 1, "pipelinename": "MyFirstPipeline", "stagestates": [ "actionstates": [...], "stagename": "Source", "latestexecution": "pipelineexecutionid": "9811f7cb-7cf7-SUCCESS", "status": "Succeeded", "actionstates": [...], "stagename": "Staging", "latestexecution": "pipelineexecutionid": "3137f7cb-7cf7-EXAMPLE", "status": "Failed" ] プレーンテキストエディタで JSON 形式で以下の情報を記録するファイルを作成します 失敗したアクションを含むパイプラインの名前 失敗したアクションを含むステージの名前 ステージでの最新のパイプラインの実行 ID 再試行モード(現在 サポートされている値は FAILED_ACTIONS のみです) 先ほどの MyFirstPipeline の例では ファイルは以下のようになります "pipelinename": "MyFirstPipeline", "stagename": "Staging", "pipelineexecutionid": "3137f7cb-7cf7-EXAMPLE", 174

182 パイプラインの承認アクションを管理する "retrymode": "FAILED_ACTIONS" 3. retry-failed-actions.json のような名前でファイルを保存します 4. retry-stage-execution コマンドを実行したときに作成したファイルを呼び出します (例: Important ファイル名の前に必ず file:// を含めてください このコマンドでは必須です aws codepipeline retry-stage-execution --cli-input-json file://retry-failedactions.json 5. 再試行の結果を表示するには AWS CodePipeline コンソールを開いてから 失敗したアクションが 含まれるパイプラインを選択するか もう一度 get-pipeline-state コマンドを使用します 詳細につい ては AWS CodePipeline でパイプラインの詳細と履歴を表示する (p. 129) を参照してください AWS CodePipeline で承認アクションを管理する AWS CodePipeline で 必要な AWS Identity and Access Management アクセス許可を持つユーザーがア クションを承認または拒否できるように パイプラインの実行を停止するところで承認アクションをパイ プラインのステージに追加することができます アクションが承認されている場合 パイプラインの実行は再開されます アクションが拒否されている か パイプラインのアクションおよび停止のアクションが 7 日間以内に承認または拒否されない場合 は アクションが失敗した時と 同じ結果になり パイプラインの実行は継続されません 次の理由で手動承認を使用する場合があります リビジョンがパイプラインの次のステージに移行される前に コードレビューの実施または管理レ ビューの変更を行う場合 リリース前に 最新バージョンのアプリケーションで手動の品質保証を実行するか ビルドアーティ ファクトの完全性を確認する場合 企業のウェブサイトに公開する前に新規テキストまたは更新済みのテキストをレビューしてもらう場合 AWS CodePipeline での手動の承認アクションに関す る設定オプション AWS CodePipeline には 承認アクションに関して承認者に通知することができる 3 つの設定オプション があります 承認通知の発行 パイプラインがアクションで停止されると Amazon Simple Notification Service トピック にメッセージが発行されるように 承認アクションを設定します Amazon SNS は トピックでサブス クライブされている各エンドポイントにメッセージを送信します承認アクションを含むパイプラインとし て 同一の AWS リージョンで作成されているトピックを使用する必要があります トピックを作成する 際には MyFirstPipeline-us-east-2-approval などの形式で 目的を識別しやすい名前を付ける ことをお勧めします 承認通知を Amazon SNS トピックに発行する場合は E メールか SMS の受取人 SQS キュー HTTP/ HTTPS エンドポイント または Amazon SNS を用いて呼び出す AWS Lambda 関数などの形式から選択 することができます Amazon SNS トピックの通知に関する詳細については 次のトピックを参照してく ださい Amazon Simple Notification Service とは? 175

183 承認アクションのセットアップおよびワークフローの概要 Amazon SNS でトピックを作成します Amazon SQS キューへの Amazon SNS メッセージの送信 Amazon SNS トピックへのキューのサブスクライブ HTTP/HTTPS エンドポイントへの Amazon SNS メッセージの送信 Amazon SNS 通知を用いた Lambda 関数の呼び出し 承認アクションの通知で生成される JSON データの構造については AWS CodePipeline の手動の承認 通知の JSON データ形式 (p. 185) を参照してください レビューする URL の指定 承認アクションの設定の一部として レビューする URL を指定することができ ます この URL は 承認者がテストするウェブアプリケーションか 承認リクエストに関する詳細を含む ページへのリンクです また URL には Amazon SNS トピックに対して発行される通知が含まれます 承認者は コンソールまたは CLI を使用して表示することができます 承認者に対するコメントの入力 承認アクションを作成する場合 コメントを追加して 通知の受取者 ま たはコンソールか CLI レスポンスのアクションを確認するユーザーに表示することもできます 設定オプション不要 これらの 3 つのオプションのいずれも設定しないように選択することもできます た とえば アクションがレビューできる状態になったことや アクションを承認するまでパイプラインを停 止することを直接通知する場合などに これらの設定は不要です AWS CodePipeline での承認アクションのセットアッ プおよびワークフローの概要 手動の承認の設定および使用に関する概要は次のとおりです 1. 承認アクションの承認または拒否に必要な IAM のアクセス許可を組織内の IAM ユーザーに付与しま す 2. (オプション) Amazon SNS 通知を使用している場合 AWS CodePipeline オペレーションで使用してい るサービスロールには Amazon SNS リソースにアクセスするためのアクセス許可が含まれます 3. (Optional) Amazon SNS 通知を使用している場合は Amazon SNS トピックを作成し 1 人以上の受信 者または 1 つ以上のエンドポイントを追加します 4. AWS CLI を使用してパイプラインを作成するか CLI またはコンソールを使用してパイプラインを作成 したら 承認アクションをパイプラインのステージに追加します 通知を使用している場合は アクションの設定に Amazon SNS トピックの Amazon リソースネーム (ARN) を含みます (ARN は Amazon リソース独自の識別子です Amazon SNS トピックの ARN 構造 は arn:aws:sns:us-east-2:80398example:myapprovaltopic のようになります 詳細につい ては アマゾン ウェブ サービス全般のリファレンス の Amazon リソースネーム (ARN) と AWS サー ビスの名前空間 を参照してください 5. 承認アクションに達すると パイプラインは停止します Amazon SNS トピックの ARN がアクショ ン設定に含まれている場合 通知は Amazon SNS トピックにパブリッシュされ メッセージは コン ソールの承認アクションをレビューするリンクと合わせて トピックの受信者またはサブスクライブさ れたエンドポイントに配信されます 6. 承認者は 必要に応じて ターゲット URL およびコメントを確認します 7. 承認者は コンソール CLI SDK を使用して 概要コメントを確認し 次のようなレスポンスを送信 します 承認済み: パイプラインの実行が再開されます 拒否: ステージステータスが 失敗 に変更され パイプラインの実行は再開されません 7 日以内にレスポンスが送信されない場合 アクションは 失敗 とマークされます 176

184 AWS CodePipeline の IAM ユーザーに承認権限を付与する AWS CodePipeline の IAM ユーザーに承認権限を付与 する 組織内の IAM ユーザーが承認アクションを承認または拒否するには パイプラインのアクセスと承認アク ションのステータスの更新を行うアクセス許可が必要です すべてのパイプラインと アカウントの承認 アクションに対するアクセス許可を付与するには AWSCodePipelineApproverAccess 管理ポリシー を IAM ユーザー ロール グループにアタッチします また アクセス許可を制限するには IAM ユー ザー ロール グループでアクセスできる各リソースを指定します このトピックに記載されているアクセス許可でアクセスできる範囲はかなり制限されています ユーザー ロール グループを有効化して 複数の承認アクションを承認または拒否するには 他の管理ポリシーをアタッチします AWS CodePipeline で利用できる管理ポリシーの詳細につ いては AWS CodePipeline での AWS 管理 (事前定義) ポリシー (p. 220) を参照してくださ い 承認のアクセス許可をすべてのパイプラインおよび承認アクショ ンに付与する 1. AWS マネジメントコンソール にサインインし IAM コンソール iam/ を開きます 2. ナビゲーションペインで [グループ] [ロール] または [ユーザー] を選択します 3. アクセス権限を付与するグループ ロール または IAM ユーザーを選択します 4. [Permissions] タブを選択します 5. [アクセス権限の追加] [Attach existing policies directly] (既存のポリシーを直接アタッチする) の順に 選択します 6. AWSCodePipelineApproverAccess 管理ポリシーの横にあるチェックボックスをオンにし [次の 手順: 確認] を選択します 7. [Add permissions] を選択します 特定のパイプラインや承認アクションに対する承認のアクセス許 可を指定します 1. AWS マネジメントコンソール にサインインし IAM コンソール iam/ を開きます Important AWS CodePipeline の使用開始 (p. 9) で使用したのと同じアカウント情報で AWS マネジメン トコンソール にサインインしていることを確認します 2. ナビゲーションペインで 必要に応じて [グループ] または [ユーザー] を選択します 3. 変更するユーザーまたはグループを参照し 選択します 4. 概要ページで [アクセス権限] タブを選択し [インラインポリシー] セクションを展開します 5. 次のいずれかを行ってください [グループ] を選択した場合は [グループポリシーの作成] を選択します [ユーザー] を選択した場合 は [ユーザーポリシーの作成] を選択します インラインポリシーをまだ作成していない場合は [ここをクリックしてください] を選択します 6. [Custom Policy] を選択し [Select] を選択します 7. [ポリシー名] にこのポリシーの名前を入力します 177

185 サービス ロールへの Amazon SNS アクセス許可の付与 8. IAM ユーザーがアクセスできる個々のリソースを指定します たとえば 以下のポリシーは 米国東 部 (オハイオ) リージョン の MyFirstPipeline パイプラインで MyApprovalAction という名前の アクションのみを承認または拒否する権限をユーザーに付与します "Version": " ", "Statement": [ "Action": [ "codepipeline:listpipelines" ], "Resource": [ "*" ], "Effect": "Allow", "Action": [ "codepipeline:getpipeline", "codepipeline:getpipelinestate", "codepipeline:getpipelineexecution" ], "Effect": "Allow", "Resource": "arn:aws:codepipeline:us-east-2:80398example:myfirstpipeline", "Action": [ "codepipeline:putapprovalresult" ], "Effect": "Allow", "Resource": "arn:aws:codepipeline:us-east-2:80398example:myfirstpipeline/ MyApprovalStage/MyApprovalAction" ] IAM ユーザーが AWS CodePipeline ダッシュボードにアクセスしてこのパイプラインのリス トを表示する必要がある場合にのみ codepipeline:listpipelines アクセス許可が必 要です コンソールへのアクセスが必要ない場合は codepipeline:listpipelines を 省略できます 9. [Validate Policy] を選択します ページの上部にある赤いボックスに表示されているエラーを修正しま す 10. ポリシーが完成したら [Apply Policy] を選択します AWS CodePipeline サービスロールへの Amazon SNS アクセス許可の付与 承認アクションでレビューが必要な場合に Amazon SNS を使用してトピックに通知を発行する 場合 AWS CodePipeline オペレーションで使用しているサービスロールでアクセス許可を付与し て Amazon SNS リソースにアクセスできるようにする必要があります IAM コンソールを使用して こ のアクセス許可をサービスロールに付与することができます 1. AWS マネジメントコンソール にサインインし IAM コンソール iam/ を開きます 178

186 手動の承認アクションの追加 Important AWS CodePipeline の使用開始 (p. 9) で使用したのと同じアカウント情報で AWS マネジメン トコンソール にサインインしていることを確認します 2. IAM コンソールのナビゲーションペインで [ロール] を選択します 3. AWS CodePipeline オペレーションで使用するサービスロールの名前を選択します 4. [Permissions] タブの [Inline Policies] エリアで [Create Role Policy] を選択します または [Create Role Policy] ボタンを使用できない場合は [Inline Policies] エリアを拡張して [click here] を 選択します 5. [Set Permissions] ページで [Custom Policy] を選択し 次に [Select] を選択します 6. [Review Policy] ページで [Policy Name] フィールドに このポリシーを識別するための名前 [SNSPublish] などを入力します 7. [Policy Document] フィールドに以下を貼り付けます 8. "Version": " ", "Statement": [ "Effect": "Allow", "Action": "sns:publish", "Resource": "*" ] [Apply Policy] を選択します AWS CodePipeline のパイプラインに手動の承認アク ションを追加する パイプラインを停止するポイントで AWS CodePipeline パイプラインのステージに承認アクションを追 加し そのアクションを手動で承認または拒否することができます 承認アクションをソースステージに追加することはできません ソースステージには ソースア クションのみ含めることができます 承認アクションをレビューする準備が整ったときに Amazon SNS を使用して通知を送信するには まず 次の前提条件を満たす必要があります Amazon SNS リソースにアクセスできるようにするアクセス許可を AWS CodePipeline サービスロール に付与します 詳細については AWS CodePipeline サービスロールへの Amazon SNS アクセス許可の 付与 (p. 178) を参照してください 承認アクションのステータスを更新できるようにするアクセス許可を組織の 1 人以上の IAM ユーザーに 付与します 詳細については AWS CodePipeline の IAM ユーザーに承認権限を付与する (p. 177) を 参照してください 179

187 手動の承認アクションの追加 AWS CodePipeline パイプラインに手動の承認アクションを追加 する (コンソールの場合) AWS CodePipeline コンソールを使用して 既存の AWS CodePipeline パイプラインに承認アクションを 追加します 新しいパイプラインを作成する際に承認アクションを追加する場合は AWS CLI を使用しま す 1. AWS CodePipeline コンソール ( を開きます 2. [Name] で パイプラインを選択します 3. パイプライン詳細ページで [編集] を選択します 4. 承認アクションを新しいステージに追加する場合は 承認リクエストを追加するパイプラインのポイ ントで [+Add stage (+ ステージの追加)] を選択し ステージの名前を入力します 承認アクションを既存のステージに追加する場合は [ステージの編集] を選択します 5. [+ Add action group (+ アクションの追加)] を選択します 6. [アクションの編集] ページで 次の作業を行います 1. [アクション名] に アクションを識別する名前を入力します 2. [アクションプロバイダー] の [承認] で [手動承認l] を選択します 3. (オプション) [SNS トピックの ARN] で 承認アクションの通知を送るために使用するトピックの 名前を選択します 4. (オプション) [URL for review] に 承認者が検討するページまたはアプリケーションの URL を入力 します 承認者は パイプラインのコンソールビューに含まれるリンクからこの URL にアクセス できます 5. (オプション) [コメント] に レビュー者と共有するその他の情報を入力します 完成したページは以下のようになります 180

188 手動の承認アクションの追加 6. [Save] を選択します AWS CodePipeline のパイプラインに手動の承認アクションを追 加する (CLI の場合) CLI を使用して 承認アクションを既存のパイプラインに追加するか パイプライン作成時に追加しま す 追加するには 作成中または編集中のステージで 手動の承認タイプを使用して 承認アクションを 追加します パイプラインの作成および編集に関する詳細は AWS CodePipeline でパイプラインを作成す る (p. 113) および AWS CodePipeline でパイプラインを編集する (p. 122) を参照してください 承認アクションを含むパイプラインにステージを追加するには パイプライン作成時または更新時に 次 の例のように追加します configuration セクションはオプションです このセクションはファイルの一部であり 構造 全体を示したものではありません 詳細については AWS CodePipeline パイプライン構造の リファレンス (p. 244) を参照してください "name": "MyApprovalStage", "actions": [ "name": "MyApprovalAction", "actiontypeid": "category": "Approval", "owner": "AWS", 181

189 手動の承認アクションの追加 "version": "1", "provider": "Manual" ], "inputartifacts": [], "outputartifacts": [], "configuration": "NotificationArn": "arn:aws:sns:us-east-2:80398example:myapprovaltopic", "ExternalEntityLink": " "CustomData": "The latest changes include feedback from Bob.", "runorder": 1 承認アクションが他のアクションを含むステージに存在する場合 このステージを含む JSON ファイルの セクションは 次の例のようになります configuration セクションはオプションです このセクションはファイルの一部であり 構造 全体を示したものではありません 詳細については AWS CodePipeline パイプライン構造の リファレンス (p. 244) を参照してください, "name": "Production", "actions": [ "inputartifacts": [], "name": "MyApprovalStage", "actiontypeid": "category": "Approval", "owner": "AWS", "version": "1", "provider": "Manual", "outputartifacts": [], "configuration": "NotificationArn": "arn:aws:sns:us-east-2:80398example:myapprovaltopic", "ExternalEntityLink": " "CustomData": "The latest changes include feedback from Bob.", "runorder": 1, "inputartifacts": [ "name": "MyApp" ], "name": "MyDeploymentStage", "actiontypeid": "category": "Deploy", "owner": "AWS", "version": "1", "provider": "CodeDeploy", "outputartifacts": [], "configuration": "ApplicationName": "MyDemoApplication", "DeploymentGroupName": "MyProductionFleet", "runorder": 2 182

190 承認アクションの承認または拒否 ] AWS CodePipeline での承認アクションを承認または 拒否する パイプラインに承認アクションが含まれている場合 パイプラインの実行は アクションが実行されたポ イントで停止します 手動でこのアクションを承認しない限り パイプラインが再開されることはありま せん 承認者がアクションを拒否する場合 または承認アクションでパイプラインが停止してから 7 日以 内に承認レスポンスを受け取らない場合 パイプラインのステータスは 失敗 になります 通知が設定されたパイプラインに承認アクションを追加すると 次のような E メールが送信されます 承認アクションを承認または拒否する (コンソールの場合) 承認アクションへの直接リンクを含む通知を受け取った場合は [Approve or reject (承認または却下)] リン クを選択し コンソールにサインインし このステップ 7 に進みます そうでない場合は 以下のすべて の手順を実行します AWS CodePipeline コンソール ( を開きます [All Pipelines (すべてのパイプライン)] ページで パイプラインの名前を選択します 承認アクションが含まれるステージを見つけます 情報アイコンをポイントすると コメントと URL があれば 表示されます メッセージに レビュー するコンテンツの URL があれば それも表示されます 183

191 承認アクションの承認または拒否 5. URL が表示された場合は アクションの [手動承認] リンクを選択してターゲットウェブページを開 き コンテンツをレビューします パイプラインの詳細ビューに戻り [確認] を選択します [改訂の承認または却下] ウィンドウで アクションの承認または却下理由など レビューコメントを 入力し [承認] または [拒否] を選択します 承認リクエストの承認または拒否 (CLI) CLI を使用して承認アクションに応答するには まず get-pipeline-state コマンドを使用して 最新の承認 アクションの実行に関連付けられているトークンを取得します 1. ターミナル (Linux, macos, or Unix) またはコマンドプロンプト (Windows) で 承認アクションが含ま れるパイプラインに対して get-pipeline-state コマンドを実行します たとえば MyFirstPipeline という名前のパイプラインに対して 以下のように入力します aws codepipeline get-pipeline-state --name MyFirstPipeline 2. コマンドに対する応答で 次に示すような承認アクションの actionstates セクションの latestexecution にある token 値を見つけます "created": , "pipelinename": "MyFirstPipeline", "pipelineversion": 1, "stagestates": [ "actionstates": [ "actionname": "MyApprovalAction", "currentrevision": "created": , "revisionchangeid": "CEM7d6Tp7zfelUSLCPPwo234xEXAMPLE", "revisionid": "HYGp7zmwbCPPwo23xCMdTeqIlEXAMPLE", "latestexecution": "lastupdatedby": "arn:aws:iam:: :user/bob", "summary": "The new design needs to be reviewed before release.", "token": "1a2b3c4d-573f-4ea7-a67E-XAMPLETOKEN" //More content might appear here 3. プレーンテキストエディタで JSON 形式で以下の情報を記録するファイルを追加します 承認アクションを含むパイプラインの名前 承認アクションを含むステージの名前 承認アクションの名前 前の手順で収集したトークン値 アクションに対する応答 (承認済みまたは却下) 応答の先頭は大文字であることが必要です 概要コメント 先ほどの MyFirstPipeline の例では ファイルは以下のようになります "pipelinename": "MyFirstPipeline", 184

192 手動の承認通知の JSON データ形式 "stagename": "MyApprovalStage", "actionname": "MyApprovalAction", "token": "1a2b3c4d-573f-4ea7-a67E-XAMPLETOKEN", "result": "status": "Approved", "summary": "The new design looks good. Ready to release to customers." approvalstage-approved.json のような名前でファイルを保存します 以下のように 承認 JSON ファイルの名前を指定して put-approval-result コマンドを実行します Important ファイル名の前に必ず file:// を含めてください このコマンドでは必須です aws codepipeline put-approval-result --cli-input-json file://approvalstageapproved.json AWS CodePipeline の手動の承認通知の JSON データ 形式 Amazon SNS 通知を使用する承認アクションの場合 アクションに関する JSON データは パイプライ ン停止時に Amazon SNS に対して作成し 発行されます この JSON 出力を使用して メッセージを Amazon SQS キューに送信するか AWS Lambda の関数を呼び出します このガイドでは JSON を使用して通知を設定する方法については説明していません 詳細につ いては Amazon SNS 開発者ガイドの Amazon SQS キューへの Amazon SNS メッセージの 送信 および Amazon SNS 通知を使用した Lambda 関数の呼び出し を参照してください 次の例は AWS CodePipeline の承認で使用可能な JSON 出力の構造を示しています "region": "us-east-2", "consolelink": " view/myfirstpipeline", "approval": "pipelinename": "MyFirstPipeline", "stagename": "MyApprovalStage", "actionname": "MyApprovalAction", "token": "1a2b3c4d-573f-4ea7-a67E-XAMPLETOKEN", "expires": " T20:22Z", "externalentitylink": " "approvalreviewlink": " "customdata": "Review the latest changes and approve or reject within seven days." 185

193 移行を無効化または有効化する (コンソールの場合) AWS CodePipeline のステージ移行を 操作する 移行は 無効化または有効化できるパイプラインステージ間のリンクです デフォルトでは有効化されて います 無効化された移行を再度有効化すると 30 日が経過していない限り パイプラインの残りのス テージで最新リビジョンが実行されます パイプラインを実行しても 新しい変更が検出されるか 手動 でパイプラインを再実行する場合を除き 無効期間が 31 日以上の移行が再開されることはありません 手動で承認するまでパイプラインの実行を停止するには 承認アクションを使用します 詳細に ついては AWS CodePipeline で承認アクションを管理する (p. 175) を参照してください トピック 移行を無効化または有効化する (コンソールの場合) (p. 186) 移行を無効化または有効化する (CLI の場合) (p. 188) 移行を無効化または有効化する (コンソールの場合) パイプラインで遷移を無効/有効にするには 1. AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline) を開きます AWS アカウントに関連付けられているすべてのパイプラインの名前が表示されます 2. [Name] で 遷移を有効または無効にするパイプラインの名前を選択します これにより パイプライ ンの詳細ビューが開いて パイプラインのステージ間の遷移がわかります 3. 実行する最後のステージの後の矢印を見つけ その横にあるボタンを選択します たとえば 以下の パイプラインの例で [Staging (ステージング)] ステージのアクションを実行するが [Production (本 番稼働用)] という名前のステージのアクションを実行しないようにするには その 2 つのステージの 間の [Disable transition (移行を無効にする)] ボタンを選択します 186

194 移行を無効化または有効化する (コンソールの場合) 4. [移行を無効にする] ダイアログボックスで 移行を無効にする理由を入力し [無効化] を選択しま す ボタンは 矢印の前のステージと矢印の後のステージとの間で遷移が無効にされたことを示すように 変わります 無効にされた移行の後のステージですでに実行されていたリビジョンは パイプライン により続行されますが それ以降のリビジョンは 無効にされた移行の後には続行されません 5. 矢印の横にある [移行を有効にする] ボタンを選択します [Enable transition] ダイアログボックスで [Enable] を選択します パイプラインはすぐに 2 つのステージ間の移行を有効にします 移行が無効 にされた後 初期ステージで実行されていたリビジョンがある場合 パイプラインはすぐに 以前の 無効にされた移行の後のステージで最新のリビジョンの実行を開始します パイプラインは そのリ ビジョンをパイプラインの残りのすべてのステージで実行します 187

195 移行を無効化または有効化する (CLI の場合) 遷移を有効にした後 AWS CodePipeline コンソールに変更が表示されるまで数秒かかるこ とがあります 移行を無効化または有効化する (CLI の場合) AWS CLI を使用してステージ間の遷移を無効にするには disable-stage-transition コマンドを実行しま す 無効にされた遷移を有効にするには enable-stage-transition コマンドを実行します 遷移を無効にするには 1. ターミナル (Linux, macos, or Unix) またはコマンドプロンプト (Windows) を開き AWS CLI で パ イプラインの名前 遷移を無効にするステージの名前 遷移のタイプ そのステージへの遷移を無効 にする理由を指定して disable-stage-transition コマンドを実行します コンソールを使用する場合 とは異なり ステージに入る (インバウンド) 遷移を無効にするか すべてのアクションが完了した後 にステージから出る (アウトバウンド) 遷移を無効にするかを指定する必要もあります たとえば MyFirstPipeline という名前のパイプラインで Staging という名前のステージへの遷 移を無効にするには 以下のようなコマンドを入力します aws codepipeline disable-stage-transition --pipeline-name MyFirstPipeline --stagename Staging --transition-type Inbound --reason "My Reason" 2. このコマンドは何も返しません 遷移が無効にされたことを確認するには AWS CodePipeline コンソールでパイプラインを表示する か get-pipeline-state コマンドを実行します 詳細については パイプラインの詳細と履歴を表示 する (コンソール) (p. 129) および パイプラインの詳細と履歴を表示する (CLI) (p. 131) を参照し てください 遷移を有効にするには 1. ターミナル (Linux, macos, or Unix) またはコマンドプロンプト (Windows) を開き AWS CLI で パイプラインの名前 遷移を有効にするステージの名前 遷移のタイプを指定して enable-stagetransition コマンドを実行します たとえば MyFirstPipelineという名前のパイプラインで Staging という名前のステージへの遷 移を有効にするには 以下のようなコマンドを入力します aws codepipeline enable-stage-transition --pipeline-name MyFirstPipeline --stagename Staging --transition-type Inbound 2. このコマンドは何も返しません 遷移が無効にされたことを確認するには AWS CodePipeline コンソールでパイプラインを表示する か get-pipeline-state コマンドを実行します 詳細については パイプラインの詳細と履歴を表示 する (コンソール) (p. 129) および パイプラインの詳細と履歴を表示する (CLI) (p. 131) を参照し てください 188

196 CloudWatch イベント でパイプラ インの状態の変更を検出し対応する AWS CodePipeline を使用したパイプ ラインのモニタリング モニタリングは AWS CodePipeline の信頼性 可用性 パフォーマンスを維持する上で重要な部分で す マルチポイント障害が発生した場合は その障害をより簡単にデバッグできるように AWS ソリュー ションのすべての部分からモニタリングデータを収集する必要があります ただし モニタリングを開始 する前に 以下の質問に回答するモニタリング計画を作成する必要があります どのような目的でモニタリングしますか? どのリソースをモニタリングしますか? どのくらいの頻度でこれらのリソースをモニタリングしますか? どのモニタリングツールが使用可能ですか? 誰がモニタリングタスクを実行しますか? 問題が発生した場合 だれが通知を受け取りますか? 次のツールを使用して AWS CodePipeline パイプラインおよびリソースをモニタリングできます Amazon CloudWatch Events Amazon CloudWatch Events を使用してパイプライン実行の状態の変更 を検出して対応します (Amazon SNS 通知の送信 Lambda 関数の呼び出しなど) AWS CloudTrail CloudTrail を使用して AWS アカウントで AWS CodePipeline によって またはそ れに代わって行われた API コールを取得し Amazon S3 バケットにログファイルを配信します 新しい ログファイルが配信されたときに CloudWatch が Amazon SNS 通知を発行するように選択することで すばやく対処できるようにします コンソールと CLI AWS CodePipeline コンソールと CLI を使用して パイプラインのステータスまた は特定のパイプライン実行の詳細を表示できます トピック Amazon CloudWatch Events でパイプラインの状態の変更を検出し対応する (p. 189) AWS CodePipeline での AWS CloudTrail API コールのログ記録 (p. 197) AWS CodePipeline でパイプラインの現在のソースリビジョンの詳細を表示する (p. 199) Amazon CloudWatch Events でパイプラインの状態 の変更を検出し対応する Amazon CloudWatch Events は AWS で実行される AWS リソースやアプリケーションをモニタリングす るウェブサービスです Amazon CloudWatch Events を使用して パイプライン ステージ またはアク ションの状態の変更を検出し対応できます 次に 作成したルールに基づいて CloudWatch イベント はパ イプライン ステージ またはアクションが ルールで指定した状態になると 1 つ以上のターゲットア クションを呼び出します 状態変更のタイプに応じて 通知を送信 状態情報を取得し 修正作業または その他のアクションを取ることができます Amazon CloudWatch Events は以下で構成されています ルール Amazon CloudWatch Events でのイベントは 選択したサービスを使用してイベントソースと してルールを最初に作成することで設定します 189

197 パイプライン実行の状態変更ルールの仕組みを理解する ターゲット 新しいルールは選択したサービスをイベントターゲットとして受け取ります Amazon CloudWatch Events のターゲットとして使用可能なサービスのリストについては Amazon CloudWatch Events とは を参照してください Amazon CloudWatch Events ルールとターゲットの例: EC2 インスタンスがイベントソースで Amazon SNS がイベントターゲットの場合に インスタンスの 状態が変わったとき 通知を送信するルール AWS CodeBuild 設定がイベントソースで Amazon SNS がイベントターゲットの場合に ビルドフェー ズが変わったとき 通知を送信するルール パイプラインの変更を検出し AWS Lambda 関数を呼び出すルール AWS CodePipeline をイベントソースとして設定するには: 1. イベントソースとして AWS CodePipeline を使用する Amazon CloudWatch Events ルールを作成しま す 2. Amazon CloudWatch Events でターゲットとして使用可能なサービス (AWS Lambda や Amazon SNS など) のいずれかを使用するルールのターゲットを作成します 3. Amazon CloudWatch Events へアクセス権限を付与し 選択したターゲットサービスの呼び出しを許可 します パイプライン実行の状態変更ルールの仕組みを理解す る Amazon CloudWatch の [イベント] ウィンドウを使用して パイプラインの状態変更を検出し対応する ルールを構築します ルールを構築する際に コンソールの [イベントパターンのプレビュー] ボックス (または CLI の --event-pattern 出力) に JSON 形式のイベントフィールドが表示されます 以下の状態が変わった時に通知が送信されるように設定できます 指定したパイプラインまたはすべてのパイプライン これを制御するには "detail-type": "CodePipeline Pipeline Execution State Change" を使用します 指定したパイプラインまたはすべてのパイプライン内の 指定したステージまたはすべてのステージ これを制御するには "detail-type": "CodePipeline Stage Execution State Change" を 使用します 指定したパイプラインまたはすべてのパイプライン内の 指定したステージまたはすべてのステー ジ内の 指定したアクションまたはすべてのアクション これを制御するには "detail-type": "CodePipeline Action Execution State Change" を使用します 各タイプの実行の状態変更イベントは 以下の特定のメッセージ内容で通知を送信します 最初の version エントリは CloudWatch イベントのバージョン番号を示します パイプライン detail の version エントリは パイプライン構造のバージョン番号を示します パイプライン detail の execution-id エントリは 状態変更の原因となったパイプラインの実行 ID を示します AWS CodePipeline API リファレンス の GetPipelineExecution API コールを参照します パイプライン実行状態の変更メッセージの内容: パイプライン実行が開始すると 以下の内容の通知が送信 されます この例は us-east-1 リージョンの "mypipeline" という名前のパイプラインです 190

198 パイプライン実行の状態変更ルールの仕組みを理解する "version": "0", "id": event_id, "detail-type": "CodePipeline Pipeline Execution State Change", "source": "aws.codepipeline", "account": Pipeline_Account, "time": TimeStamp, "region": "us-east-1", "resources": [ "arn:aws:codepipeline:us-east-1:account_id:mypipeline" ], "detail": "pipeline": "mypipeline", "version": "1", "state": "STARTED", "execution-id": execution_id ステージ実行状態の変更メッセージの内容: ステージ実行が開始すると 以下の内容の通知が送信されま す この例は "Prod" ステージの us-east-1 リージョンの "mypipeline" という名前のパイプライン です "version": "0", "id": event_id, "detail-type": "CodePipeline Stage Execution State Change", "source": "aws.codepipeline", "account": Pipeline_Account, "time": TimeStamp, "region": "us-east-1", "resources": [ "arn:aws:codepipeline:us-east-1:account_id:mypipeline" ], "detail": "pipeline": "mypipeline", "version": "1", "execution-id": execution_id, "stage": "Prod", "state": "STARTED" アクション実行状態の変更メッセージの内容: アクション実行が開始すると 以下の内容の通知が送信され ます この例は "myaction" アクションの us-east-1 リージョンの "mypipeline" という名前のパ イプラインです "version": "0", "id": event_id, "detail-type": "CodePipeline Action Execution State Change", "source": "aws.codepipeline", "account": Pipeline_Account, "time": TimeStamp, "region": "us-east-1", "resources": [ "arn:aws:codepipeline:us-east-1:account_id:mypipeline" ], "detail": "pipeline": "mypipeline", "version": "1", "execution-id": execution_id, "stage": "Prod", "action": "myaction", 191

199 パイプライン実行の状態変更ルールの仕組みを理解する "state": "STARTED", "type": "owner": "AWS", "category": "Deploy", "provider": "CodeDeploy", "version": 1 状態の有効な値: パイプラインレベルの状態 パイプラインの状態 説明 開始 パイプライン実行が現在実行中です 成功 パイプライン実行が正常に完了しました 再開 失敗したパイプライン実行が RetryStageExecution API コールに応じて再 試行されました 失敗 パイプライン実行が正常に完了しませんでした キャンセル済み パイプライン構造が更新されたため パイプライン実行がキャンセルされま した 置き換え済み このパイプライン実行が次のステージの完了を待機している間に 新しいパ イプライン実行が進行し 代わりにパイプラインを継続しました ステージレベルの状態 ステージの状態 説明 開始 このステージは現在実行中です 成功 ステージは正常に完了しました 再開 失敗したステージが RetryStageExecution API コールに応じて再試行され ました 失敗 ステージは正常に完了しませんでした キャンセル済み パイプライン構造が更新されたため ステージはキャンセルされました アクションレベルの状態 アクションの状態 説明 開始 アクションは現在実行中です 成功 アクションは正常に完了しました 失敗 承認アクションでは 失敗の状態は アクションがレビュー者により拒否さ れたか または誤ったアクション設定のために失敗したことを意味します キャンセル済み パイプライン構造が更新されたため アクションはキャンセルされました 192

200 パイプライン実行の状態変更ルールの仕組みを理解する 前提条件 AWS CodePipeline オペレーションで使用するイベントルールを作成する前に 以下のことを実行する必 要があります CloudWatch イベント 前提条件を完了します 詳細については リージョンのエンドポイント を参 照してください CloudWatch イベント のイベント ルール ターゲットに精通しておいてください 詳細については Amazon CloudWatch Events とは を参照してください Amazon SNS 通知トピックなど イベントルールで使用するターゲットを作成します パイプラインの状態が変わるたびに通知を送信する (コンソール) これらのステップでは CloudWatch コンソールを使用して AWS CodePipeline で変更の通知を送信する ためのルールを作成する方法を示します AWS CodePipeline でイベントソースとして CloudWatch イベント ルールを作成するには 1. CloudWatch コンソールを開きます 2. ナビゲーションペインの [Events] を選択します 3. [Create rule] を選択します [イベントソース] で [サービス名] ドロップダウンリストから [CodePipeline] を選択します 4. [イベントタイプ] ドロップダウンリストで 通知する状態変更のレベルを選択します パイプラインイベントに適用されるルールでは [CodePipeline Pipeline Execution State Change] を選択します ステージレベルのイベントに適用されるルールでは [CodePipeline Stage Execution State Change] を選択します アクションレベルのイベントに適用されるルールでは [CodePipeline Action Execution State Change] を選択します 5. ルールを適用する状態変更を指定します すべての状態変更に適用されるルールには [Any state] を選択します いくつかの状態変更のみに適用されるルールには [Specific state(s)] を選択してから リストから 1 つ以上の値を選択します 193

201 パイプライン実行の状態変更ルールの仕組みを理解する 6. セレクタよりも詳細なイベントパターンには [イベントパターンのプレビュー] ウィンドウの [編集] オプションを使用して JSON 形式のイベントパターンを指定することもできます 以下に示すの は 手動で JSON 構造を編集して mypipeline という名前のパイプラインを指定する例です 194

202 パイプライン実行の状態変更ルールの仕組みを理解する 指定されていない場合 イベントパターンは すべてのパイプライン/ステージ/アクションの 状態に対して作成されます より詳細なイベントパターンについては 次のイベントパターンの例をコピーして [編集] ウィンドウ に貼り付けることができます Example このイベントパターンのサンプルを使用して すべてのパイプラインで失敗したデプロイとビルド アクションをキャプチャします "source": [ "aws.codepipeline" ], "detail-type": [ "CodePipeline Action Execution State Change" ], "detail": "state": [ "FAILED" ], "type": "category": ["Deploy", "Build"] 195

203 パイプライン実行の状態変更ルールの仕組みを理解する Example このイベントパターンのサンプルを使用して すべてのパイプラインで 拒否された または失敗 したすべての承認アクションをキャプチャします "source": [ "aws.codepipeline" ], "detail-type": [ "CodePipeline Action Execution State Change" ], "detail": "state": [ "FAILED" ], "type": "category": ["Approval"] Example このイベントパターンのサンプルを使用して 指定したパイプラインからすべてのイベントをキャ プチャします "source": [ "aws.codepipeline" ], "detail-type": [ "CodePipeline Pipeline Execution State Change", "CodePipeline Action Execution State Change", "CodePipeline Stage Execution State Change" ], "detail": "pipeline": ["mypipeline", "my2ndpipeline"] 7. [Targets] エリアで [Add target*] を選択します 8. [Select target type] リストで このルールのターゲットのタイプを選択してから そのタイプに必要な オプションを設定します 9. [Configure details] を選択します 10. [Configure rule details] ページで ルールの名前と説明を入力し [State] ボックスを選択して すぐに ルールを有効化します 11. [Create rule] を選択します パイプラインの状態が変わるたびに通知を送信する (CLI) これらのステップでは CLI を使用して AWS CodePipeline で変更の通知を送信するための CloudWatch イベント ルールを作成する方法を示します AWS CLI を使用してルールを作成するには 以下を指定して put-rule コマンドを呼び出します 作成中のルールを一意に識別する名前 この名前は AWS アカウントに関連付けられた AWS CodePipeline で作成するすべてのパイプラインで一意である必要があります 196

204 AWS CloudTrail での API コールのログ記録 ルールで使用するソースと詳細フィールドのイベントパターン 詳細については Amazon CloudWatch Events およびイベントパターン を参照してください AWS CodePipeline でイベントソースとして CloudWatch イベント ルールを作成するには 1. put-rule コマンドを呼び出して イベントパターンを指定するルールを作成します (有効な状態につ いては前のテーブルを参照してください ) 以下のサンプルコマンドでは --event-pattern を使用して MyPipelineStateChanges とい うルールを作成し "mypipeline" という名前のパイプラインでパイプライン実行に失敗したときに CloudWatch イベントを送信します aws events put-rule --name "MyPipelineStateChanges" --event-pattern "\"source\": [\"aws.codepipeline\"],\"detail-type\":[\"codepipeline Pipeline Execution State Change \"],\"detail\":\"pipeline\":[\"mypipeline\"],\"state\":[\"failed\"]" 2. この Amazon SNS トピックの例に示すように put-targets コマンドを呼び出して 新しいルールに ターゲットを追加します aws events put-targets --rule MyPipelineStateChanges --targets Id=1,Arn=arn:aws:sns:uswest-2:11111EXAMPLE:MyNotificationTopic 3. Amazon CloudWatch Events のアクセス権限を追加し 通知を呼び出す指定されたターゲットサービ スを使用します 詳細については Amazon CloudWatch Events のリソースベースのポリシーを使 用する を参照してください AWS CodePipeline での AWS CloudTrail API コー ルのログ記録 AWS CodePipeline は CloudTrail サービスと統合されています このサービスは AWS アカウントで AWS CodePipeline が行う API コールまたはこれに代わって行われる API コールのすべてをキャプチャ します その後 指定先の Amazon S3 バケットにログファイルを配信します CloudTrail は AWS CodePipeline コンソールからの AWS CLI での AWS CodePipeline コマンドからの または AWS CodePipeline API からの API コールをキャプチャします CloudTrail によって収集された情報を使用し て AWS CodePipeline に対してどのようなリクエストが行われたかを判断することができます リクエ ストの作成元のソース IP アドレス リクエストの実行者 リクエストの実行日時などです CloudTrail を 設定して有効にする方法などの詳細については AWS CloudTrail User Guide を参照してください CloudTrail での AWS CodePipeline 情報 AWS アカウントで CloudTrail ログ記録を有効にすると AWS CodePipeline に対する API コールはログ ファイルに記録されます AWS CodePipeline レコードは AWS の他のサービスのレコードと一緒にログ ファイルに書き込まれます CloudTrail は 期間とファイルサイズに基づいて新規ファイルの作成と書き 込みのタイミングを決定します AWS CodePipeline アクションはすべてログに記録されます このアクションについては AWS CodePipeline API リファレンス および AWS CodePipeline コマンドラインリファレンス に記載され ています たとえば パイプラインを作成 削除 編集する呼び出しや カスタムアクションの作成に よって CloudTrail ログファイルにエントリが生成されます 各ログエントリには 誰がリクエストを生成したかに関する情報が含まれます ログのユーザー ID 情報 は リクエストが ルートまたは IAM ユーザーの認証情報を使用して送信されたか ロールまたはフェデ レーティッドユーザーの一時的なセキュリティ認証情報を使用して送信されたか あるいは AWS の別の 197

205 AWS CodePipeline ログファイルエントリの概要 サービスによって送信されたかを確認するのに役立ちます 詳細については CloudTrail Event Reference の useridentity フィールドを参照してください ログファイルは無期限に保管できますが ログファイルを自動的にアーカイブまたは削除するにように Amazon S3 ライフサイクルルールを定義することもできます デフォルトでは Amazon S3 のサーバー側 の暗号化 SSE を使用して ログファイルが暗号化されます ログファイルの配信時にすぐにアクションを実行する場合 新しいログファイルの配信時に CloudTrail に より Amazon SNS 通知を発行することを選択できます 詳細については Amazon SNS 通知の構成 を参照してください また 複数の AWS リージョンと複数の AWS アカウントからの AWS CodePipeline ログファイルを 1 つ の Amazon S3 バケットに集約することもできます 詳細については CloudTrail ログファイルの単一の Amazon S3 バケットへの集約 を参照してください AWS CodePipeline ログファイルエントリの概要 CloudTrail ログファイルには 複数の JSON 形式イベントで構成される 1 つ以上のログエントリが記録さ れます ログエントリは任意の送信元からの単一のリクエストを表し リクエストされたアクション パ ラメータ アクションの日時などに関する情報を含みます ログエントリは 特定の順序で生成されるわ けではありません (つまり パブリック API 呼び出しのスタックトレース順にはなりません) 以下の例では パイプラインのアップデートイベントの CloudTrail ログエントリを示します ここ で パイプライン (MyFirstPipeline) は アカウント ID (80398EXAMPLE) を持つユーザー (JaneDoeCodePipeline) によって編集されています ユーザーは パイプラインのソースステージ名を Source か ら MySourceStage に変更しました CloudTrail ログの requestparameters と responseelements のいずれにも 編集後のパイプラインの構造全体が含まれているため これらの要素は 以下の例で省略 されています 強調 が 変更されたパイプラインの requestparameters 部分 以前のバージョン番号 のパイプライン responseelements 部分に追加されています これは バージョン番号が 1 ずつイン クリメントすることを意味します 実際のログエントリでより多くのデータが表示された場合 編集した 部分は省略記号 (...) でマークされます "eventversion":"1.03", "useridentity": "type":"iamuser", "principalid":"akiai44qh8dhbexample", "arn":"arn:aws:iam::80398example:user/janedoe-codepipeline", "accountid":"80398example", "accesskeyid":"akiaiosfodnn7example", "username":"janedoe-codepipeline", "sessioncontext": "attributes": "mfaauthenticated":"false", "creationdate":" t14:44:03z", "invokedby":"signin.amazonaws.com", "eventtime":" t19:12:20z", "eventsource":"codepipeline.amazonaws.com", "eventname":"updatepipeline", "awsregion":"us-east-2", "sourceipaddress":" ", "useragent":"signin.amazonaws.com", "requestparameters": "pipeline": "version":1, "rolearn":"arn:aws:iam::80398example:role/aws-codepipeline-service", "name":"myfirstpipeline", "stages":[ 198

206 パイプラインの現在のソースリビジョンの詳細を表示する "actions":[ "name":"mysourcestage", "actiontype": "owner":"aws", "version":"1", "category":"source", "provider":"s3", "inputartifacts":[], "outputartifacts":[ "name":"myapp" ], "runorder":1, "configuration": "S3Bucket":"awscodepipeline-demobucket-example-date", "S3ObjectKey":"sampleapp_linux.zip" ], "name":"source", (...), "responseelements": "pipeline": "version":2, (...), "requestid":"2c4af5c9-7ce8-example", "eventid":""c53dbd42-this-is-an-example"", "eventtype":"awsapicall", "recipientaccountid":"80398example" ] AWS CodePipeline でパイプラインの現在のソース リビジョンの詳細を表示する AWS CodePipeline コンソールまたは AWS CLI で パイプライン実行に使用するソースアーティファクト (パイプラインの最初のステージで生成される出力アーティファクト) に関する詳細を表示できます この 詳細には コミット ID チェックインコメント アーティファクト作成後または更新後の時間 CLI の使 用時間 ビルドアクションのバージョン番号などの識別子が含まれます 一部のリビジョンタイプでは アーティファクトバージョンのコミットの URL を表示して開くことができます トピック パイプラインの現在のソースリビジョンの詳細を表示する (コンソールの場合) (p. 199) パイプラインの現在のソースリビジョンの詳細を表示する (CLI の場合) (p. 200) パイプラインの現在のソースリビジョンの詳細を表示 する (コンソールの場合) AWS CodePipeline コンソールを使用して パイプラインの実行で追加された最新のソースリビジョンに 関する情報を表示できます 199

207 パイプラインの現在のソースリビ ジョンの詳細を表示する (CLI の場合) パイプラインのソースリビジョンを表示するには AWS マネジメントコンソール にサインインし AWS CodePipeline コンソール ( console.aws.amazon.com/codepipeline) を開きます AWS アカウントに関連付けられているすべてのパイプラインの名前が表示されます ソースリビジョンの詳細を表示するパイプラインの名前を選択します 3. ソースリビジョンの詳細を表示するアクションを見つけ そのステージの下部にあるリビジョン情報 を確認します 4. 詳細エリアをクリックして アーティファクトがコミットされてからの時間など アーティファクト に関する詳細情報を表示します Amazon S3 バケットに格納されているアーティファクトを除いて この情報詳細ビューのコミット ID などの識別子は アーティファクトのソース情報ページにリンクさ れています パイプラインの現在のソースリビジョンの詳細を表示 する (CLI の場合) get-pipeline-execution コマンドを実行して パイプライン実行で追加された最新のソースリビジョンに関 する情報を表示できます まず get-pipeline-state コマンドを実行して パイプラインのすべてのステー ジに関する詳細を表示したら ソースリビジョンの詳細が必要なステージに適用されている実行 ID を特定 します その実行 ID を get-pipeline-execution コマンドに使用します (別のパイプラインが実行されてい る間にパイプラインのステージは正常に完了しているため 別の実行 ID が割り当てられていることがあり ます ) つまり Staging ステージに現在あるアーティファクトに関する詳細を表示する場合は get-pipelinestate コマンドを実行し Staging ステージの現在の実行 ID を特定してから その実行 ID を使用して getpipeline-execution コマンドを実行します パイプラインのソースリビジョンを表示するには 1. ターミナル (Linux, macos, or Unix) またはコマンドプロンプト (Windows) を開き AWS CLI を使用 して get-pipeline-state コマンドを実行します MyFirstPipeline という名前のパイプラインの場合 は 以下のように入力します 200

208 パイプラインの現在のソースリビ ジョンの詳細を表示する (CLI の場合) aws codepipeline get-pipeline-state --name MyFirstPipeline 2. このコマンドは 各ステージの最新のパイプライン実行 ID を含む パイプラインの最新の状態を返し ます パイプライン実行の詳細情報を表示するには パイプラインの一意の名前と アーティファクトの詳 細を表示する特定の実行のパイプライン実行 ID を指定して get-pipeline-execution を実行します たとえば MyFirstPipeline という名前で 実行 ID が 3137f7cb-7cf7-039j-s83l-d7eu3EXAMPLE のパイプライン実行に関する詳細を表示するには 以下のように入力します aws codepipeline get-pipeline-execution --pipeline-name MyFirstPipeline --pipelineexecution-id 3137f7cb-7cf7-039j-s83l-d7eu3EXAMPLE このコマンドは パイプライン実行の一部である各ソースリビジョンに関する情報と パイプライン を識別する情報を返します 実行に含まれていたパイプラインステージに関する情報のみが含まれま す パイプライン実行の一部ではなかった パイプラインの他のステージが存在する可能性がありま す 以下の例に MyFirstPipeline という名前のパイプラインの一部に対して返されたデータを示しま す ここで "MyApp" という名前のアーティファクトは GitHub リポジトリに保存されています 3. "pipelineexecution": "artifactrevisions": [ "created": , "name": "MyApp", "revisionchangeidentifier": " ", "revisionid": "7636d59f3c461cEXAMPLE8417dbc6371", "revisionsummary": "Updating the application for feature ", "revisionurl": " commits/7636d59f3c461cexample8417dbc6371" //More revisions might be listed here ], "pipelineexecutionid": "3137f7cb-7cf7-039j-s83l-d7eu3EXAMPLE", "pipelinename": "MyFirstPipeline", "pipelineversion": 2, "status": "Succeeded" 201

209 パイプラインのエラー: AWS Elastic Beanstalk で 設定されたパイプラインは次のようなエラーメッ セージを返します デプロイに失敗しました 提供されたロールに十分なアクセス権限があり ません: サービス: AmazonElasticLoadBalancing AWS CodePipeline のトラブルシュー ティング 以下の情報は AWS CodePipeline での一般的な問題のトラブルシューティングに役立ちます トピック パイプラインのエラー: AWS Elastic Beanstalk で設定されたパイプラインは次のようなエラーメッ セージを返します デプロイに失敗しました 提供されたロールに十分なアクセス権限がありませ ん: サービス: AmazonElasticLoadBalancing (p. 202) デプロイエラー: DescribeEvents アクセス許可がない場合 AWS Elastic Beanstalk デプロイアク ションで設定したパイプラインは 失敗することなく中止します (p. 203) パイプラインエラー: ソースアクションは次のような不十分な権限メッセージを返します AWS CodeCommit リポジトリ repository-name にアクセスできませんでした パイプラインの IAM ロー ルにリポジトリにはアクセスするための十分な権限があることを確認してください (p. 204) パイプラインのエラー: Jenkins のビルドまたはテストアクションは長期間実行されるため 認証情報 や権限がないと失敗します (p. 204) パイプラインのエラー: GitHub ステージ自分のソースは Git サブモジュールが含まれているが AWS CodePipeline 初期化されていません (p. 204) パイプラインのエラー: 次のメッセージのパイプラインエラーが表示されます PermissionError: GitHub リポジトリにアクセスできませんでした (p. 205) パイプラインのエラー: 別の AWS リージョンで作成されたバケットを使用して 1 つの AWS リー ジョンで作成されたパイプラインは コード JobFailed を使用して InternalError を返しま す (p. 206) デプロイのエラー: WAR ファイルを含む ZIP ファイルは AWS Elastic Beanstalk に正常にデプロイさ れますが アプリケーションの URL に 404 Not Found エラーが報告されます (p. 203) ZIP が外部属性を保持しないときは ソースファイルに GitHub からのファイルアクセス権限は保持さ れません (p. 207) 別の問題で支援が必要ですか? (p. 208) パイプラインのエラー: AWS Elastic Beanstalk で設 定されたパイプラインは次のようなエラーメッセー ジを返します デプロイに失敗しました 提供 されたロールに十分なアクセス権限がありません: サービス: AmazonElasticLoadBalancing 問題: AWS CodePipeline のサービスロールには AWS Elastic Beanstalk に対する十分なアクセス許可が ありません ただし Elastic Load Balancing の一部の操作を含みますが これに限定されません この問 題に対処するために AWS CodePipeline のサービスロールが 2015 年 8 月 6 日に更新されました この 202

210 デプロイエラー: DescribeEvents アクセス許可がな い場合 AWS Elastic Beanstalk デプロイアクションで設 定したパイプラインは 失敗することなく中止します 日付より前にサービスロールを作成したお客様は サービスロールのポリシーステートメントを変更して 必要なアクセス権限を追加する必要があります 可能な変更: 最も簡単な方法は デフォルトの AWS CodePipeline サービスロールのポリシーの確 認 (p. 221) のサービスロールの更新されたポリシーステートメントをコピーし サービスロールを編集 し 古いポリシーステートメントを現在のポリシーで上書きすることです このポリシーステートメント の部分は 次のように Elastic Beanstalk に適用されます "Action": [ "elasticbeanstalk:*", "ec2:*", "elasticloadbalancing:*", "autoscaling:*", "cloudwatch:*", "s3:*", "sns:*", "cloudformation:*", "rds:*", "sqs:*", "ecs:*", "iam:passrole" ], "Resource": "*", "Effect": "Allow", 編集済みのポリシーを適用したら AWS CodePipeline でパイプラインを手動で開始する (p. 110) の ステップに従って Elastic Beanstalk を使用するパイプラインを手動で再実行します セキュリティのニーズに応じて 他の方法でアクセス権限を変更することもできます デプロイエラー: DescribeEvents アクセス許可 がない場合 AWS Elastic Beanstalk デプロイアク ションで設定したパイプラインは 失敗することな く中止します 問題: AWS CodePipeline のサービスロールに AWS Elastic Beanstalk を使用するパイプラインの "elasticbeanstalk:describeevents" アクションが含まれている必要があります このアクセス許 可がないと AWS Elastic Beanstalk のデプロイアクションは失敗やエラーになることなく中止します このアクションがサービスロールに欠落している場合 AWS CodePipeline はユーザーに代わって AWS Elastic Beanstalk のパイプラインデプロイステージを実行するアクセス権限がありません 修正案: AWS CodePipeline のサービスロールを確認します "elasticbeanstalk:describeevents" アクションが欠落している場合は 他の AWS サービスのアクセス許可の追加 (p. 222) の手順に従 い IAM コンソールで [ポリシーの編集] 機能を使用してこのアクションを追加します 編集済みのポリシーを適用したら AWS CodePipeline でパイプラインを手動で開始する (p. 110) の ステップに従って Elastic Beanstalk を使用するパイプラインを手動で再実行します デフォルトのサービスロールの詳細については デフォルトの AWS CodePipeline サービスロールのポ リシーの確認 (p. 221) を参照してください 203

211 パイプラインエラー: ソースアクションは次のような不十分 な権限メッセージを返します AWS CodeCommit リポジ トリ repository-name にアクセスできませんでした パイプラインの IAM ロールにリポジトリにはアクセスす るための十分な権限があることを確認してください パイプラインエラー: ソースアクションは次のよ うな不十分な権限メッセージを返します AWS CodeCommit リポジトリ repository-name にア クセスできませんでした パイプラインの IAM ロールにリポジトリにはアクセスするための十分な 権限があることを確認してください 問題: AWS CodePipeline のサービスロールには AWS CodeCommit に対する十分な権限がなく AWS CodeCommit リポジトリを使用するためのサポートが 2016 年 4 月 18 日に追加される前に作成された 可能性があります この日付より前にサービスロールを作成したお客様は サービスロールのポリシース テートメントを変更して必要なアクセス権限を追加する必要があります 修正案: AWS CodeCommit に必要な権限を AWS CodePipeline サービスロールのポリシーに追加します 詳細については 他の AWS サービスのアクセス許可の追加 (p. 222) を参照してください パイプラインのエラー: Jenkins のビルドまたはテ ストアクションは長期間実行されるため 認証情報 や権限がないと失敗します 問題: Jenkins サーバーが Amazon EC2 インスタンスにインストールされている場合 インスタンスは AWS CodePipeline に必要な権限を持つインスタンスロールで作成されていない可能性があります Jakins サーバー オンプレミスインスタンス または必要な IAM ロールなしで作成された Amazon EC2 インス タンスで IAM ユーザーを使用している場合 IAM ユーザーには必要な権限がないか Jenkins サーバーが サーバー上に設定されたプロファイル介してこれらの認証情報にアクセスできません 修正案: Amazon EC2 インスタンスロールまたは IAM ユーザー が AWSCodePipelineCustomActionAccess 管理されたポリシーまたは同等の権限で設定され ていることを確認します 詳細については AWS CodePipeline での AWS 管理 (事前定義) ポリ シー (p. 220) を参照してください IAM ユーザーを使用している場合は インスタンスで設定された AWS プロファイルが正しい権限で設定 された IAM ユーザーを使用していることを確認してください Jenkins と AWS CodePipeline の統合のた めに設定した IAM ユーザー認証情報を Jenkins UI に直接提供する必要があります これは推奨されるベス トプラクティスではありません その必要がある場合は Jenkins サーバーが保護されており HTTP では なく HTTPS を使用していることを確認してください パイプラインのエラー: GitHub ステージ自分のソー スは Git サブモジュールが含まれているが AWS CodePipeline 初期化されていません 問題: AWS CodePipeline は git サブモジュールをサポートしていません AWS CodePipeline は サブモ ジュールをサポートしていない GitHub のアーカイブリンク API を使用しています 204

212 パイプラインのエラー: 次のメッセージのパイプ ラインエラーが表示されます PermissionError: GitHub リポジトリにアクセスできませんでした 可能な変更: 別スクリプトの一部として直接 GitHub リポジトリをクローンすることを検討してください たとえば Jenkins スクリプトにクローンアクションを含めることができます パイプラインのエラー: 次のメッセージのパイプ ラインエラーが表示されます PermissionError: GitHub リポジトリにアクセスできませんでした 問題: AWS CodePipeline は OAuth トークンを使用して GitHub と統合します AWS CodePipeline の OAuth トークンのアクセス権限を取り消した可能性があります さらに トークンの数は限られています (詳細については GitHubのドキュメント を参照) AWS CodePipeline がその制限に達すると 古い トークンは機能しなくなり そのトークンに依存するパイプラインのアクションは失敗します 解決方法: AWS CodePipeline のアクセス許可が取り消されたかどうかを確認します GitHub にサインイ ンし [アプリケーション] に進み [Authorized OAuth Apps (承認された OAuth アプリ)] を選択します リ ストに AWS CodePipeline が表示されない場合は AWS CodePipeline コンソールを開いてパイプライン を編集し [GitHub に接続] を選択して認証を復元します GitHub の認定アプリケーションのリストに AWS CodePipeline が存在する場合 許容されるトークン数を 超えている可能性があります この問題を解決するには 手動で 1 つの OAuth トークンを個人用のアクセ ストークンとして設定し そのトークンを使用するように AWS アカウントのすべてのパイプラインを設 定します セキュリティのベストプラクティスは 個人アクセストークンを定期的にローテーションすることです 詳細については GitHub と AWS CodePipeline CLI を使用して GitHub 個人用のアクセストークンを 作成し 定期的にローテーションする (p. 240) を参照してください GitHub からの個人用のアクセストークンを使用するようにパイプラインを設定するには 1. GitHub アカウントにサインインし GitHub のドキュメントの 個人用のアクセストークンの作成 の指示に従います トークンが GitHub スコープ (admin:repo_hook と repo) を持つように設定さ れていることを確認します トークンをコピーします 2. ターミナル (Linux, macos, or Unix) またはコマンドプロンプト (Windows) で OAuth トークンを変 更するパイプラインに対して get-pipeline コマンドを実行し コマンドの出力を JSON ファイルにコ ピーします たとえば MyFirstPipeline という名前のパイプラインに対しては 以下のようなコマン ドを入力します aws codepipeline get-pipeline --name MyFirstPipeline >pipeline.json コマンドの出力は pipeline.json ファイルに送られます 3. プレーンテキストエディタでファイルを開き GitHub アクションの OAuthTokenField の値を編集 します アスタリスク (****) を GitHub からコピーしたトークンに置き換えます 例: "configuration": token" 4. "Owner": "MyGitHubUserName", "Repo": "test-repo", "Branch": "master", "OAuthToken": "Replace the **** with your personal access, get-pipeline コマンドを使用して取得されたパイプライン構造を操作している場合 ファイルから metadata 行を削除して JSON ファイルの構造を変更する必要があります そうしないと update 205

213 パイプラインのエラー: 別の AWS リージョンで 作成されたバケットを使用して 1 つの AWS リー ジョンで作成されたパイプラインは コード JobFailed を使用して InternalError を返します pipeline コマンドはこのファイルを使用することができません JSON ファイルのパイプライン 構造からセクションを削除します ("metadata": 行と その中の created" "pipelinearn" および "updated" の各フィールド) たとえば 構造から以下の行を削除します "metadata": "pipelinearn": "arn:aws:codepipeline:region:account-id:pipeline-name", "created": "date", "updated": "date" 5. ファイルを保存したら 先ほど編集した JSON ファイルを --cli-input-json パラメータで指定し て update-pipeline を実行します たとえば MyFirstPipeline という名前のパイプラインを更新する には 以下のように入力します Important ファイル名の前に必ず file:// を含めてください このコマンドでは必須です aws codepipeline update-pipeline --cli-input-json file://pipeline.json 6. GitHub アクションを含むパイプラインごとにステップ 2 4 を繰り返します 7. パイプラインの更新が完了したら それらのパイプラインの更新に使用した.json ファイルを削除し ます パイプラインのエラー: 別の AWS リージョン で作成されたバケットを使用して 1 つの AWS リージョンで作成されたパイプラインは コード JobFailed を使用して InternalError を返しま す 問題: パイプラインとバケットが異なる AWS リージョンに作成されていると Amazon S3 バケットに格 納されたアーティファクトのダウンロードは失敗します 解決方法: アーティファクトが格納されている Amazon S3 バケットが 作成したパイプラインと同じ AWS リージョンにあることを確認します デプロイのエラー: WAR ファイルを含む ZIP ファ イルは AWS Elastic Beanstalk に正常にデプロイ されますが アプリケーションの URL に 404 Not Found エラーが報告されます 問題: WAR ファイルは AWS Elastic Beanstalk 環境に正常にデプロイされますが アプリケーションの URL は 404 Not Found エラーを返します 206

214 ZIP が外部属性を保持しないときは ソースファイルに GitHub からのファイルアクセス権限は保持されません 解決方法: AWS Elastic Beanstalk は ZIP ファイルを展開できますが ZIP ファイルに含まれている WAR ファイルは展開できません buildspec.yml ファイルに WAR ファイルを指定する代わりに デプロイ するコンテンツを含むフォルダを指定します (例: version: 0.1 phases: post_build: commands: - mvn package - mv target/my-web-app./ artifacts: files: - my-web-app/**/* discard-paths: yes たとえば AWS CodeBuild の AWS Elastic Beanstalk サンプル を参照してください ZIP が外部属性を保持しないときは ソースファイ ルに GitHub からのファイルアクセス権限は保持さ れません 問題: GitHub からのソースファイルを持つユーザーは パイプラインの Amazon S3 アーティファクトバ ケットに保存されると 入力アーティファクトがファイルのアクセス許可を失うという問題に直面するか もしれません GitHub からのファイルを圧縮する AWS CodePipeline ソースアクションは 外部属性を保 持しない ZIP ファイルのプロセスを使用するため ファイルはファイルのアクセス権限を保持しません 解決方法: chmod コマンド経由でアーティファクトが消費される場所からファイルのアクセス権限を変更 する必要があります AWS CodeBuild などのビルドプロバイダのビルドスペックファイルを更新し ビ ルドステージが実行されるたびにファイルのアクセス権限を復元します 次の例では build: セクション で chmod コマンドを使用した AWS CodeBuild のビルドスペックを示します version: 0.2 phases: build: commands: - dotnet restore - dotnet build - chmod a+x bin/debug/mytests - bin/debug/mytests artifacts: files: - bin/debug/myapplication AWS CodePipeline コンソールを使用してビルド入力アーティファクトの名前を確認するには パイプラインを表示した後 ビルド アクションで ツールヒントの上にマウスを合わせます 入 力アーティファクトの値をメモします (MyApp など) AWS CLI を使用して S3 アーティファクト バケットの名前を取得するには AWS CodePipeline get-pipeline コマンドを実行します 出 力には artifactstore オブジェクトと バケットの名前を表示する location フィールドが含 まれます 207

215 別の問題で支援が必要ですか? 別の問題で支援が必要ですか? これらの他のリソースを試してください AWS サポートにお問い合わせください AWS CodePipeline フォーラム で質問してください 制限緩和のリクエスト 詳細については AWS CodePipeline 制限 (p. 252) を参照してください 制限緩和のリクエストを処理するには 最大で 2 週間かかる場合があります 208

216 認証 AWS CodePipeline の認証 アクセス コントロール セキュリティ設定の ベストプラクティス AWS CodePipeline へのアクセスには 認証情報が必要です これらの認証情報には Amazon S3 バケッ トからのアーティファクトの取得 AWS CodeDeploy のアプリケーションやデプロイグループに関する情 報へのアクセス 手動の承認アクションを承認または拒否するアクセス許可の付与など AWS リソースへ のアクセス権限が必要です 以下のセクションでは AWS Identity and Access Management (IAM) と AWS CodePipeline を使用してリソースに安全にアクセスする方法について詳しく説明します 認証 (p. 209) IAM ポリシーを使用したアクセスコントロール (p. 210) セキュリティ設定 (p. 236) 認証 AWS には 次のタイプのアイデンティティでアクセスできます AWS アカウントのルートユーザー AWS にサインアップするときは AWS アカウントに関連付けら れた E メールアドレスとパスワードを指定します これらは ルート認証情報であり これらの情報を使 用すると すべての AWS リソースへの完全なアクセスが可能になります Important セキュリティ上の理由から AWS アカウントへの完全なアクセス権限を持つ管理者ユーザー (IAM ユーザー) を作成するためにのみ ルート認証情報を使用することをお勧めします その 後 この管理者ユーザーを使用して 制限されたアクセス権限を持つ他の IAM ユーザーとロー ルを作成できます 詳細については IAM ユーザーガイドの IAM のベストプラクティス お よび 管理者のユーザーおよびグループの作成 を参照してください IAM ユーザー IAM ユーザー は 特定のカスタム許可 (たとえば AWS CodePipeline でターゲット にイベントデータを送信するアクセス許可) を持つ AWS アカウント内の ID です IAM のユーザー名 とパスワードを使用して AWS マネジメントコンソール AWS ディスカッションフォーラム AWS Support Center などのセキュリティ保護された AWS ウェブページにサインインできます ユーザー名とパスワードに加えて 各ユーザーのアクセスキーを生成することもできます いくつかの SDK の 1 つまたは AWS Command Line Interface (AWS CLI) を使ってプログラムで AWS サービスにア クセスするときに これらのキーを使用します SDK と CLI ツールでは アクセスキーを使用してリ クエストが暗号で署名されます AWS ツールを使用しない場合は リクエストを自分で署名する必要 があります AWS CodePipeline supports では 署名バージョン 4 がサポートされています これは インバウンド API リクエストを認証するためのプロトコルです リクエストの認証の詳細については AWS General Reference の 署名バージョン 4 の署名プロセス を参照してください 209

217 IAM ポリシーを使用したアクセスコントロール IAMロール IAM ロールは 特定のアクセス権限を持ち アカウントで作成できるもう 1 つの IAM ID で す これは IAM ユーザーに似ていますが 特定のユーザーに関連付けられていません IAM ロールで は AWS のサービスおよびリソースにアクセスできる一時的なアクセスキーを取得することができま す IAM ロールと一時的な認証情報は 次の状況で役立ちます フェデレーティッドユーザーアクセス IAM ユーザーを作成するのではなく AWS Directory Service エンタープライズユーザーディレクトリ またはウェブアイデンティティプロバイダーの既 存のユーザーアイデンティティを使用することもできます このようなユーザーはフェデレーティッ ドユーザーと呼ばれます AWS では アイデンティティプロバイダーを通じてアクセスがリクエスト されたときに フェデレーティッドユーザーにロールを割り当てます フェデレーティッドユーザー の詳細については IAM ユーザーガイド の フェデレーティッドユーザーとロール を参照して ください クロスアカウントアクセス アカウントで IAM ロールを使って お客様のアカウントのリソースへ のアクセス権を別の AWS アカウントに付与できます この例については IAM ユーザーガイドの チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任 を参照してくださ い AWS サービスアカウント アカウントで IAM ロールを使って お客様のアカウントのリソースにア クセスする AWS サービスのアクセス権限を付与できます たとえば Amazon Redshift がお客様に 代わって Amazon S3 バケットにアクセスし バケットに保存されたデータを Amazon Redshift クラ スターにロードすることを許可するロールを作成できます 詳細については IAM ユーザーガイドの AWS のサービスにアクセス権限を委任するロールの作成 を参照してください Amazon EC2 で実行されるアプリケーション インスタンスで実行し AWS API リクエストを作成 するアプリケーションで使用されるアクセスキーを EC2 インスタンス内に保存する代わりに IAM ロールを使用して これらのアプリケーション用の一時認証情報を管理できます AWS ロールを EC2 インスタンスに割り当て そのすべてのアプリケーションで使用できるようにするには インス タンスにアタッチされたインスタンスプロファイルを作成できます インスタンスプロファイルには ロールが含まれ EC2 インスタンスで実行されるプログラムは一時認証情報を取得することができま す 詳細については IAM ユーザーガイドの Amazon EC2 上のアプリケーションに対するロールの 使用 を参照してください IAM ポリシーを使用したアクセスコントロール リクエストを認証するために有効な認証情報を持つことができますが アクセス許可を持っていなければ AWS CodePipeline リソースを作成またはアクセスすることはできません たとえば パイプラインを作 成 表示 または削除するためのアクセス許可が必要です AWS CodeDeploy のアプリケーションおよび デプロイグループに関する情報の取得 AWS OpsWorks Stacks のスタック アプリ レイヤーに関する 情報の取得 Amazon Simple Storage Service バケットへのアーティファクトの追加 またはバケットか らのアーティファクトの取得などに使用されます 以下のセクションでは AWS CodePipeline のアクセス許可を管理する方法について説明します 最初に 概要のセクションを読むことをお勧めします AWS CodePipeline リソースへのアクセス権限の管理の概要 (p. 211) AWS CodePipeline でアイデンティティベースのポリシー (IAM ポリシー) を使用する (p. 219) AWS CodePipeline の権限リファレンス (p. 233) 210

218 アクセス管理の概要 AWS CodePipeline リソースへのアクセス権限の管理 の概要 すべての AWS リソースは AWS アカウントによって所有され リソースを作成またはアクセスするため のアクセス権限は アクセス権限ポリシーによって管理されます アカウント管理者は アクセス権限ポ リシーを IAM ID (ユーザー グループ ロール) にアタッチでき 一部のサービス (AWS Lambda など) で は アクセス権限ポリシーをリソースにアタッチすることをサポートしています アカウント管理者 (または管理者 IAM ユーザー) は 管理者権限を持つユーザーです 詳細につい ては IAM のベストプラクティス (IAM ユーザーガイド) を参照してください アクセス権限を付与する場合 アクセス権限を取得するユーザー 取得するアクセス権限の対象となるリ ソース およびそれらのリソースに対して許可される特定のアクションを決定します トピック AWS CodePipeline リソースおよびオペレーション (p. 211) AWS CodePipeline API コールでサポートされるリソースレベルのアクセス許可 (p. 212) リソース所有権について (p. 214) リソースへのアクセスの管理 (p. 215) ポリシー要素の指定 : アクション 効果 プリンシパル (p. 218) ポリシーでの条件の指定 (p. 218) AWS CodePipeline リソースおよびオペレーション AWS CodePipeline では プライマリリソースはパイプラインです ポリシーで Amazon リソースネーム (ARN) を使用して ポリシーを適用するリソースを識別します AWS CodePipeline は ステージ アク ション カスタムアクションなど プライマリリソースで使用できる他のリソースを選択します これら はサブリソースと呼ばれます これらのリソースとサブリソースには 一意の Amazon リソースネーム (ARN) が関連付けられています ARN の詳細については アマゾン ウェブ サービス全般のリファレン ス の Amazon リソースネーム ARN と AWS サービスの名前空間 を参照してください パイプラ インに関連付けられたパイプラインの ARN を取得するには CLI を使用して get-pipeline コマンドを実行 します 詳細については AWS CodePipelineAPI Reference の GetPipeline を参照してください リソースタイプ ARN 形式 パイプライン arn:aws:codepipeline:region:account:pipeline-name ステージ arn:aws:codepipeline:region:account:pipeline-name/stage-name アクション arn:aws:codepipeline:region:account:pipeline-name/stagename/action-name カスタムアクション arn:aws:codepipeline:region:account:actiontype:owner/category/ provider/version すべての AWS CodePipeline リソース arn:aws:codepipeline:* 特定リージョンの特定アカ arn:aws:codepipeline:region:account:* ウントが所有するすべての AWS CodePipeline リソー ス 211

219 アクセス管理の概要 AWS のほとんどのサービスでは ARN 内のコロン (:) またはスラッシュ (/) は同じ文字として扱 われます ただし AWS CodePipeline では イベントパターンとルールで完全一致が使用され ます イベントパターンの作成時に正しい ARN 文字を使用して 一致させるリソース内の ARN 構文とそれらの文字が一致する必要があります AWS CodePipeline では リソースレベルのアクセス許可をサポートする API コールがあります リソー スレベルのアクセス許可は API コールでリソース ARN を指定できるかどうか または API コールでワ イルドカードを使用したすべてのリソースの呼び出しのみが可能かどうかを示します リソースレベル のアクセス許可の詳細な説明と リソースレベルのアクセス許可をサポートする AWS CodePipeline API コールの一覧については AWS CodePipeline API コールでサポートされるリソースレベルのアクセス 許可 (p. 212) を参照してください たとえば 以下の要領で ARN を使用して ステートメント内の特定のパイプライン (mypipeline) を指 定することができます "Resource": "arn:aws:codepipeline:us-east-2: :mypipeline" また 以下の要領でワイルドカード文字 (*) を使用して 特定のアカウントに属するすべてのパイプライン を指定することもできます "Resource": "arn:aws:codepipeline:us-east-2: :*" すべてのリソースを指定する場合 または特定の API アクションが ARN をサポートしていない場合は 以下のように Resource 要素内でワイルドカード文字 (*) を使用します "Resource": "*" IAM ポリシーを作成するとき 最小限の特権を認めるという標準的なセキュリティアドバイスに 従いましょう そうすれば タスクを実行するというリクエストのアクセス許可のみを認めるこ とができます API コールが ARN をサポートしている場合 リソースレベルのアクセス許可をサ ポートしていて ワイルドカード文字 (*) を使用する必要はありません 一部の AWS CodePipeline API コールは 複数のリソース (例: GetPipeline) を受け入れます 単一のス テートメントに複数のリソースを指定するには 以下のようにコンマで ARN を区切ります "Resource": ["arn1", "arn2"] AWS CodePipeline には AWS CodePipeline リソースを操作するための一連のオペレーションが用意さ れています 使用可能なオペレーションのリストについては AWS CodePipeline の権限リファレン ス (p. 233) を参照してください AWS CodePipeline API コールでサポートされるリソースレベル のアクセス許可 リソースレベルのアクセス許可 とは ユーザーがアクションを実行可能なリソースを指定できるアクセス 許可です AWS CodePipeline では リソースレベルのアクセス許可が部分的にサポートされます これ は 一部の AWS CodePipeline API コールでは 満たす必要がある条件 またはユーザーが使用できるリ ソースに基づいて ユーザーがそれらのアクションをいつ使用できるかを制御できることを意味します たとえば パイプラインの実行情報を一覧表示できるが 特定のパイプラインに限定するアクセス許可を ユーザーに付与できます 次の表では 現在リソースレベルのアクセス許可をサポートしている AWS CodePipeline API コールと サポートされるリソース リソース ARN および各アクションの条件キーについて説明しています 212

220 アクセス管理の概要 この表に示されていない AWS CodePipeline API コールは リソースレベルのアクセス許可をサ ポートしていません AWS CodePipeline API コールでリソースレベルのアクセス許可がサポー トされない場合 アクションを使用するアクセス許可をユーザーに付与できますが ポリシース テートメントのリソース要素として * を指定する必要があります API コール リソースタイプ PutActionRevision パイプライン arn:aws:codepipeline:region:account:pipeline-name DeleteCustomActionType アクションの種類 arn:aws:codepipeline:region:account:actiontype:owner/category/ provider/version CreatePipeline パイプライン arn:aws:codepipeline:region:account:pipeline-name ListPipelines パイプライン arn:aws:codepipeline:region:account:pipeline-name PollForJobs アクションの種類 arn:aws:codepipeline:region:account:actiontype:owner/category/ provider/version DisableStageTransition パイプライン arn:aws:codepipeline:region:account:pipeline-name StartPipelineExecution パイプライン arn:aws:codepipeline:region:account:pipeline-name UpdatePipeline パイプライン arn:aws:codepipeline:region:account:pipeline-name GetPipelineState パイプライン arn:aws:codepipeline:region:account:pipeline-name RetryStageExecution パイプライン arn:aws:codepipeline:region:account:pipeline-name ListActionTypes アクションの種類 arn:aws:codepipeline:region:account:actiontype:owner/category/ provider/version CreateCustomActionType アクションの種類 arn:aws:codepipeline:region:account:actiontype:owner/category/ provider/version GetPipelineExecution パイプライン 213

221 アクセス管理の概要 API コール リソースタイプ arn:aws:codepipeline:region:account:pipeline-name GetPipeline パイプライン arn:aws:codepipeline:region:account:pipeline-name ListPipelineExecutions パイプライン arn:aws:codepipeline:region:account:pipeline-name DeletePipeline パイプライン arn:aws:codepipeline:region:account:pipeline-name EnableStageTransition パイプライン arn:aws:codepipeline:region:account:pipeline-name PutApprovalResult アクション arn:aws:codepipeline:region:account:pipeline-name/stagename/action-name この API コールはリソースレベルのアクセス権限 をサポートします ただし IAM コンソールまたは Policy Generator を使用してリソース ARN を指定する "codepipeline:putapprovalresult" とポリシーを作成した 場合 エラーが発生する場合もあります エラーが発生した場合 は IAM コンソールの [JSON] タブまたは CLI を使用してポリシー を作成することができます DeleteWebhook Webhook arn:aws:codepipeline:region:account:webhook:webhook-name DeregisterWebhookWithThirdParty Webhook arn:aws:codepipeline:region:account:webhook:webhook-name PutWebhook パイプライン arn:aws:codepipeline:region:account:pipeline-name Webhook arn:aws:codepipeline:region:account:webhook:webhook-name RegisterWebhookWithThirdParty Webhook arn:aws:codepipeline:region:account:webhook:webhook-name リソース所有権について AWS アカウントは 誰がリソースを作成したかにかかわらず アカウントで作成されたリソースを所有し ます 具体的には リソース所有者は リソースの作成リクエストを認証するプリンシパルエンティティ 214

222 アクセス管理の概要 (ルートアカウント IAM ユーザー または IAM ロール) の AWS アカウントです 以下の例では このし くみを示しています AWS アカウントのルートアカウントの認証情報を使用してルールを作成する場合 AWS アカウントは AWS CodePipeline リソースの所有者です AWS アカウントに IAM ユーザーを作成し そのユーザーに AWS CodePipeline リソースを作成するア クセス許可を付与する場合 そのユーザーは AWS CodePipeline リソースを作成できます ただし ユーザーが属する AWS アカウントは AWS CodePipeline リソースを所有しています AWS CodePipeline リソースを作成するためのアクセス許可を持つ AWS アカウントに IAM ロールを作 成する場合は ロールを引き受けることのできるいずれのユーザーも AWS CodePipeline リソースを 作成できます ロールが属する AWS アカウントは AWS CodePipeline リソースを所有しているとしま す リソースへのアクセスの管理 アクセスポリシーでは 誰が何にアクセスできるかを記述します 以下のセクションで アクセス権限の ポリシーを作成するために使用可能なオプションについて説明します このセクションでは AWS CodePipeline のコンテキストでの IAM の使用について説明します これは IAM サービスに関する詳細情報を取得できません 完全な IAM ドキュメントについて は IAM とは? (IAM ユーザーガイド ) を参照してください IAM ポリシー構文の詳細および 説明については IAM ユーザーガイド の AWS IAM ポリシーリファレンス を参照してくださ い IAM アイデンティティにアタッチされたポリシーはアイデンティティベースのポリシー (IAM ポリ シー) と呼ばれ リソースにアタッチされたポリシーはリソースベースのポリシーと呼ばれます AWS CodePipeline では アイデンティティベースのポリシー (IAM ポリシー) のみがサポートされています トピック アイデンティティベースのポリシー (IAM ポリシー) (p. 215) リソースベースのポリシー (p. 217) アイデンティティベースのポリシー (IAM ポリシー) ポリシーを IAM アイデンティティにアタッチできます たとえば 次の操作を実行できます アカウントのユーザーまたはグループにアクセス権限ポリシーをアタッチする AWS CodePipeline コ ンソールのパイプラインを表示するアクセス権限を付与するために ユーザーが所属するユーザーまた はグループにアクセス許可のポリシーをアタッチできます アクセス権限ポリシーをロールにアタッチする (クロスアカウントのアクセス権限を付与する) アイデ ンティティベースのアクセス権限ポリシーを IAM ロールにアタッチして クロスアカウントのアクセス 権限を付与することができます たとえば アカウント A の管理者は 次のように他のまたは AWS に クロスアカウントのアクセス権限を別の AWS アカウント (アカウント B) または AWS サービスに付与 するロールを作成することができます 1. アカウント A の管理者は IAM ロールを作成して アカウント A のリソースに権限を付与するロー ルに権限ポリシーをアタッチします 2. アカウント A の管理者は アカウント B をそのロールを引き受けるプリンシパルとして識別する ロールに 信頼ポリシーをアタッチします 3. アカウント B の管理者は アカウント B のユーザーにロールを引き受ける権限を委任できるように なります これにより アカウント B のユーザーにアカウント A のリソースの作成とアクセスが許 可されます AWS サービスのアクセス権限を付与してロールを引き受けさせたい場合は 信頼ポリ シー内のプリンシパルも AWS サービスのプリンシパルとなることができます 215

223 アクセス管理の概要 IAM を使用したアクセス許可の委任の詳細については IAM ユーザーガイド の アクセス管理 を 参照してください 以下の例では アカウント ( ) のポリシーを示します このポリシーでは ユーザーは AWS CodePipeline コンソールにパイプライン (MyFirstPipeline) を表示することはできますが 変更する ことはできません このポリシーは AWSCodePipelineReadOnlyAccess 管理ポリシーに基づいていま すが パイプライン (MyFirstPipeline) に固有であるため この管理ポリシーを直接使用することは できません ポリシーを特定のパイプラインに制限しない場合は AWS CodePipeline によって作成およ び保守されているいずれかの管理ポリシーを使用することを真剣に検討してください 詳細については 管理ポリシーの使用 を参照してください このポリシーは アクセス用に作成した IAM ロール (例: CrossAccountPipelineViewers) にアタッチする必要があります "Statement": [ "Action": [ "codepipeline:getpipeline", "codepipeline:getpipelinestate", "codepipeline:getpipelineexecution", "codepipeline:listpipelineexecutions", "codepipeline:listactiontypes", "codepipeline:listpipelines", "iam:listroles", "s3:getbucketpolicy", "s3:getobject", "s3:listallmybuckets", "s3:listbucket", "codecommit:listbranches", "codecommit:listrepositories", "codedeploy:getapplication", "codedeploy:getdeploymentgroup", "codedeploy:listapplications", "codedeploy:listdeploymentgroups", "elasticbeanstalk:describeapplications", "elasticbeanstalk:describeenvironments", "lambda:getfunctionconfiguration", "lambda:listfunctions", "opsworks:describeapps", "opsworks:describelayers", "opsworks:describestacks" ], "Effect": "Allow", "Resource": "*" ], "Version": " " このポリシーを作成したら アカウント ( ) に IAM ロールを作成し そのロールにポリシー をアタッチします ロールの信頼関係で このロールを継承する AWS アカウントを追加する必要があり ます 次の例では AWS アカウント ( ) のユーザーが アカウント ( ) で定 義されているロールを継承できるポリシーを示しています "Version": " ", "Statement": [ "Effect": "Allow", "Principal": "AWS": "arn:aws:iam:: :root" 216

224 アクセス管理の概要 ], "Action": "sts:assumerole" 以下の例では AWS アカウント ( ) で作成されたポリシーを示しています このポリシー では ユーザーはアカウント ( ) のロール (CrossAccountPipelineViewers) を継承する ことができます "Version": " ", "Statement": [ "Effect": "Allow", "Action": "sts:assumerole", "Resource": "arn:aws:iam:: :role/crossaccountpipelineviewers" ] お客様のアカウントのユーザーがアクセスを許可される呼び出しとリソースを制限する IAM ポリシーを作 成し IAM ユーザーにそれらのポリシーをアタッチできます IAM ロールを作成する方法 および AWS CodePipeline の IAM ポリシーステートメントの例を調べる方法の詳細については AWS CodePipeline リソースへのアクセス権限の管理の概要 (p. 211) を参照してください リソースベースのポリシー Amazon S3 などの他のサービスでは リソースベースのアクセス権限ポリシーもサポートされています たとえば ポリシーを S3 バケットにアタッチして そのバケットに対するアクセス権限を管理できま す AWS CodePipeline は リソースベースのポリシーをサポートしていませんが バージョニングされ た S3 バケットのパイプラインで使用されるアーティファクトを保存します Example Amazon S3 バケットのポリシーを作成して AWS CodePipeline のアーティファクトス トアとして使用するには バージョニングされた Amazon S3 バケットを AWS CodePipeline のアーティファクトストアとして使 用します [Create Pipeline] ウィザードを使用して 最初のパイプラインを作成した場合 この Amazon S3 バケットは アーティファクトストアにアップロードされているオブジェクトはすべて暗号化されて おり バケットへの接続には 安全性を確保して自動的に作成されます ベストプラクティスとして 独自の Amazon S3 バケットを作成する場合は 以下のポリシーまたはその要素をバケットに追加する ことを検討してください このポリシーでは Amazon S3 バケットの ARN は codepipeline-useast です この ARN を Amazon S3 バケットの ARN に置き換えます "Version": " ", "Id": "SSEAndSSLPolicy", "Statement": [ "Sid": "DenyUnEncryptedObjectUploads", "Effect": "Deny", "Principal": "*", "Action": "s3:putobject", "Resource": "arn:aws:s3:::codepipeline-us-east /*", "Condition": "StringNotEquals": "s3:x-amz-server-side-encryption": "aws:kms" 217

225 アクセス管理の概要, ] "Sid": "DenyInsecureConnections", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::codepipeline-us-east /*", "Condition": "Bool": "aws:securetransport": false ポリシー要素の指定 : アクション 効果 プリンシパル サービスは AWS CodePipeline リソースごとに一連の API オペレーションを定義します こうした API オペレーションへのアクセス権限を付与するために AWS CodePipeline は一連のアクションをポリシー に定義します 一部の API オペレーションは API オペレーションを実行するために複数のアクション に対するアクセス許可を要求できます リソースおよび API オペレーションに関する詳細については AWS CodePipeline リソースおよびオペレーション (p. 211) および AWS CodePipeline の権限リ ファレンス (p. 233) を参照してください 以下は 基本的なポリシーの要素です リソース Amazon リソースネーム (ARN) を使用して ポリシーを適用するリソースを識別します 詳 細については AWS CodePipeline リソースおよびオペレーション (p. 211) を参照してください アクション アクションのキーワードを使用して 許可または拒否するリソースオペレーションを識別 します たとえば codepipeline:getpipeline 権限は GetPipeline オペレーションの実行を ユーザーに許可します 効果 ユーザーが特定のアクションをリクエストする際の効果 (許可または拒否) を指定します リソー スへのアクセスを明示的に許可していない場合 アクセスは暗黙的に拒否されます また 明示的にリ ソースへのアクセスを拒否すると 別のポリシーによってアクセスが許可されている場合でも ユー ザーはそのリソースにアクセスできなくなります プリンシパル アイデンティティベースのポリシー (IAM ポリシー) で ポリシーがアタッチされてい るユーザーが黙示的なプリンシパルとなります リソースベースのポリシーでは 権限 (リソースベー スのポリシーにのみ適用) を受け取りたいユーザー アカウント サービス またはその他のエンティ ティを指定します IAM ポリシーの構文と説明についての詳細については IAM ユーザーガイドの AWS IAM ポリシーのリ ファレンス を参照してください すべての AWS CodePipeline API アクションとそれらが適用されるリソースの表については AWS CodePipeline の権限リファレンス (p. 233) を参照してください ポリシーでの条件の指定 アクセス権限を付与するとき アクセスポリシー言語を使用して ポリシーが有効になる必要がある条件 を指定できます たとえば 特定の日付の後にのみ適用されるポリシーが必要になる場合があります ポ リシー言語での条件の指定の詳細については IAM ユーザーガイドの 条件 を参照してください 条件を表すには あらかじめ定義された条件キーを使用します AWS CodePipeline に固有の条件キーは ありません ただし AWS 全体の条件キーがあり 必要に応じて使用できます AWS 全体を対象とする すべてのキーのリストについては IAM ユーザーガイド の 条件に利用可能なキー を参照してくだ さい 218

226 アイデンティティベースのポリ シー (IAM ポリシー) を使用する AWS CodePipeline でアイデンティティベースのポリ シー (IAM ポリシー) を使用する このトピックでは アカウント管理者が IAM アイデンティティ (ユーザー グループ ロール) へアクセス 権限ポリシーをアタッチする様子を示すアイデンティティベースのポリシーの例を示します Important 初めに AWS CodePipeline リソースへのアクセスを管理するための基本概念と 使用可能なオ プションについて説明する概要トピックをお読みになることをお勧めします 詳細については AWS CodePipeline リソースへのアクセス権限の管理の概要 (p. 211) を参照してください 次のセクションでは AWS CodePipeline に固有の IAM ポリシーを操作する方法について説明します 以下の例では us-west-2 リージョンのパイプライン (MyFirstPipeline) のステージ移行をすべて ユーザーが有効化または無効化できるアクセス権限ポリシーの例を示します "Version": " ", "Statement" : [ "Effect" : "Allow", "Action" : [ "codepipeline:enablestagetransition", "codepipeline:disablestagetransition" ], "Resource" : [ "arn:aws:codepipeline:us-west-2: :myfirstpipeline" ] ] AWS CodePipeline コンソールを使用するために必要 なアクセス権限 AWS CodePipeline コンソールを使用して AWS CodePipeline の作業を行うユーザーの場合 そのユー ザーは AWS アカウントの他の AWS リソースを記述できる 最小限のアクセス許可を持っている必要が あります AWS CodePipeline コンソールで AWS CodePipeline を使用するには 次のサービスからのア クセス許可が必要になります AWS Identity and Access Management 内に位置している Amazon Simple Storage Service 内に位置している 他のサービスをパイプラインに取り入れた場合は 次のアクセス許可が 1 つ以上必要になることがありま す AWS CodeCommit 内に位置している AWS CodeBuild 内に位置している AWS CloudFormation 内に位置している AWS CodeDeploy 内に位置している AWS Elastic Beanstalk 内に位置している AWS Lambda 内に位置している 219

227 AWS CodePipeline での AWS 管理 (事前定義) ポリシー AWS OpsWorks 内に位置している これらの最小限必要なアクセス権限よりも制限された IAMIAM ポリシーを作成している場合 その IAM ポ リシーを使用するユーザーに対してコンソールは意図したとおりには機能しません AWS CodePipeline での AWS 管理 (事前定義) ポリシー (p. 220) で説明されているとおり ユーザーが AWS CodePipeline コンソールを使用できること および AWSCodePipelineReadOnlyAccess 管理対象ポリシーがユー ザーにアタッチされていることを確認してください AWS CLI または AWS CodePipeline API のみを呼び出すユーザーには 最小限のコンソールアクセス権限 を付与する必要はありません AWS CodePipeline での AWS 管理 (事前定義) ポリ シー AWS は AWS によって作成され管理されるスタンドアロンの IAM ポリシーが提供する多くの一般的ユー スケースに対応します 管理ポリシーは 一般的ユースケースに必要なアクセス権限を付与することで どの権限が必要なのかをユーザーが調査する必要をなくすることができます 詳細については IAM ユーザーガイド の AWS 管理ポリシー を参照してください アカウントのユーザーにアタッチ可能な以下の AWS 管理ポリシーは AWS CodePipeline に固有のもので す AWSCodePipelineFullAccess AWS CodePipeline へのフルアクセスを付与します AWSCodePipelineCustomActionAccess AWS CodePipeline でカスタムアクションを作成する か Jenkins リソースを統合してビルドまたはテストアクションを行うためのアクセス許可を IAM ユー ザーに付与します AWSCodePipelineReadOnlyAccess AWS CodePipeline への読み取り専用アクセス権を付与します AWSCodePipelineApproverAccess 手動の承認アクションを承認または拒否するためのアクセス許可を IAM ユーザーに付与します AWS CodePipeline サービスロールの管理 パイプライン実行プロセスの一部に対するアクセス許可は IAM ユーザーではなく AWS CodePipeline に代わって動作する他のロールタイプに付与されます サービスロールは アカウントのリソースを使 用するための AWS CodePipeline のアクセス許可を付与する IAM ロールです サービスロールは AWS CodePipeline で初めてパイプラインを作成する場合にのみ作成する必要があります AWS CodePipeline では パイプラインのステージおよびアクションを通じて リビジョンを処理する際 にこのサービスロールを使用します このロールは パイプラインによって使用される AWS リソースへ のアクセスを制御する 1 つ以上のポリシーで設定されています 追加ポリシーをこのロールにアタッチす る ロールにアタッチされているポリシーを編集する または AWS の他のサービスロールのポリシーを 設定する場合があります また パイプラインへクロスアカウントアクセスを設定する際に ポリシーを ロールにアタッチすることがあります Important ポリシーステートメントを変更するか 他のポリシーをロールにアタッチすると パイプライン の動作が停止することがあります AWS CodePipeline のサービスロールは 必ず影響を理解し た上で変更するようにしてください パイプラインは 必ずサービスロールに変更してからテス トします トピック デフォルトの AWS CodePipeline サービスロールのポリシーの確認 (p. 221) 220

228 AWS CodePipeline サービスロールの管理 他の AWS サービスのアクセス許可の追加 (p. 222) 未使用の AWS サービスのアクセス許可の削除 (p. 225) デフォルトの AWS CodePipeline サービスロールのポリシーの確 認 デフォルトでは AWS CodePipeline の IAM サービスロールのポリシーステートメント AWSCodePipeline-Service には アカウントの他のリソースを使用するために AWS CodePipeline で必要なア クセス許可が含まれます 現在 AWS-CodePipeline-Service には 次のポリシーステートメントが含まれます "Statement": [ "Action": [ "s3:getobject", "s3:getobjectversion", "s3:getbucketversioning" ], "Resource": "*", "Effect": "Allow", "Action": [ "s3:putobject" ], "Resource": [ "arn:aws:s3:::codepipeline*", "arn:aws:s3:::elasticbeanstalk*" ], "Effect": "Allow", "Action": [ "codedeploy:createdeployment", "codedeploy:getapplicationrevision", "codedeploy:getdeployment", "codedeploy:getdeploymentconfig", "codedeploy:registerapplicationrevision" ], "Resource": "*", "Effect": "Allow", "Action": [ "elasticbeanstalk:createapplicationversion", "elasticbeanstalk:describeapplicationversions", "elasticbeanstalk:describeenvironments", "elasticbeanstalk:describeevents", "elasticbeanstalk:updateenvironment", "autoscaling:describeautoscalinggroups", "autoscaling:describelaunchconfigurations", "autoscaling:describescalingactivities", "autoscaling:resumeprocesses", "autoscaling:suspendprocesses", "cloudformation:gettemplate", "cloudformation:describestackresource", "cloudformation:describestackresources", "cloudformation:describestackevents", "cloudformation:describestacks", "cloudformation:updatestack", 221

229 AWS CodePipeline サービスロールの管理 "ec2:describeinstances", "ec2:describeimages", "ec2:describeaddresses", "ec2:describesubnets", "ec2:describevpcs", "ec2:describesecuritygroups", "ec2:describekeypairs", "elasticloadbalancing:describeloadbalancers", "rds:describedbinstances", "rds:describeorderabledbinstanceoptions", "sns:listsubscriptionsbytopic",, ], "Resource": "*", "Effect": "Allow" "Action": [ "lambda:invokefunction", "lambda:listfunctions" ], "Resource": "*", "Effect": "Allow" "Action": [ "s3:listbucket", "s3:getbucketpolicy", "s3:getobjectacl", "s3:putobjectacl", "s3:deleteobject" ], "Resource": "arn:aws:s3:::elasticbeanstalk*", "Effect": "Allow" ], "Version": " " AWS CodePipeline のサービスロールに AWS Elastic Beanstalk を使用するパイプラインの "elasticbeanstalk:describeevents" アクションが含まれていることを確認します この アクセス許可がないと AWS Elastic Beanstalk のデプロイアクションは失敗やエラーになること なく中止します 他の AWS サービスのアクセス許可の追加 サービスロールのポリシーステートメントは パイプラインで使用する前に デフォルトのサービスロー ルのポリシーステートメントに含まれていない AWS サービスのアクセス許可で更新する必要がありま す これは AWS サービスの AWS CodePipeline にサポートが追加される前に パイプラインで使用している サービスロールが作成された場合に特に重要です 以下のテーブルは 他の AWS サービスにサポートが追加された場合の例を示しています AWS サービス AWS CodePipeline のサポート日付 AWS Device Farm 内に位置している 2018 年 7 月 19 日 Amazon ECS 内に位置している 2017 年 12 月 12 日 222

230 AWS CodePipeline サービスロールの管理 AWS サービス AWS CodePipeline のサポート日付 AWS CodeCommit 内に位置している 2016 年 4 月 18 日 AWS OpsWorks 内に位置している 2016 年 6 月 2 日 AWS CloudFormation 2016 年 11 月 3 日 AWS CodeBuild 内に位置している 2016 年 12 月 1 日 追加サポートサービスのアクセス許可を追加するには 以下の手順を行います 1. AWS マネジメントコンソール にサインインし IAM コンソール iam/ を開きます 2. IAM コンソールのナビゲーションペインで [Roles] を選択し ロールのリストから AWSCodePipeline-Service ロールを選択します 3. サービスロールポリシーの列の インラインポリシー の [Permissions] タブで Edit Policy を選択しま す サービスロールには oneclick_aws-codepipeline のような形式の名 前が付いています 4. [Policy Document] ボックスに必要なアクセス許可を追加します たとえば AWS CodeCommit がサ ポートされるように 以下をポリシーステートメントに追加します "Action": [ "codecommit:getbranch", "codecommit:getcommit", "codecommit:uploadarchive", "codecommit:getuploadarchivestatus", "codecommit:canceluploadarchive" ], "Resource": "*", "Effect": "Allow", AWS OpsWorks がサポートされるように 以下をポリシーステートメントに追加します, "Action": [ "opsworks:createdeployment", "opsworks:describeapps", "opsworks:describecommands", "opsworks:describedeployments", "opsworks:describeinstances", "opsworks:describestacks", "opsworks:updateapp", "opsworks:updatestack" ], "Resource": "*", "Effect": "Allow" AWS CloudFormation がサポートされるように 以下をポリシーステートメントに追加します 223

231 AWS CodePipeline サービスロールの管理, "Action": [ "cloudformation:createstack", "cloudformation:deletestack", "cloudformation:describestacks", "cloudformation:updatestack", "cloudformation:createchangeset", "cloudformation:deletechangeset", "cloudformation:describechangeset", "cloudformation:executechangeset", "cloudformation:setstackpolicy", "cloudformation:validatetemplate", "iam:passrole" ], "Resource": "*", "Effect": "Allow" AWS CodeBuild がサポートされるように 以下をポリシーステートメントに追加します, "Action": [ "codebuild:batchgetbuilds", "codebuild:startbuild" ], "Resource": "*", "Effect": "Allow" AWS Device Farm がサポートされるように 以下をポリシーステートメントに追加します, "Action": [ "devicefarm:listprojects", "devicefarm:listdevicepools", "devicefarm:getrun", "devicefarm:getupload", "devicefarm:createupload", "devicefarm:schedulerun" ], "Resource": "*", "Effect": "Allow" 5. Amazon ECS では Amazon ECS デプロイアクションを使用してパイプラインを作成するために必要 な最小限のアクセス許可は次のとおりです, "Action": [ "ecs:describeservices", "ecs:describetaskdefinition", "ecs:describetasks", "ecs:listtasks", "ecs:registertaskdefinition", "ecs:updateservice" ], "Resource": "*", "Effect": "Allow" 224

232 AWS CodePipeline サービスロールの管理 IAM ポリシーを作成するとき 最小限の特権を認めるという標準的なセキュリティアドバイ スに従いましょう そうすれば タスクを実行するというリクエストのアクセス許可のみを 認めることができます 特定の API 呼び出しはリソースベースのアクセス権限をサポート し アクセスを制限することを許可します たとえば この場合 DescribeTasks および ListTasks を呼び出すときにアクセス権限を制限するために ワイルドカード文字 (*) を特定 のリソース ARN またはリソース ARN 内のワイルドカード文字 (*) に置き換えることができま す 6. ポリシーの検証 を選択して ポリシーにエラーがないことを確認します ポリシーにエラーがなけれ ば ポリシーの適用 を選択します 未使用の AWS サービスのアクセス許可の削除 サービスロールのステートメントを編集して 使用していないリソースへのアクセスを削除します たと えば いずれのパイプラインにも Elastic Beanstalk が含まれていない場合は ポリシーステートメントを 編集して Elastic Beanstalk リソースのアクセス許可を付与するセクションを削除します たとえば 次の セクションをポリシーステートメントから削除することができます, "Action": [ "elasticbeanstalk:*", "ec2:*", "elasticloadbalancing:*", "autoscaling:*", "cloudwatch:*", "s3:*", "sns:*", "cloudformation:*", "rds:*", "sqs:*", "ecs:*", "iam:passrole" ], "Resource": "*", "Effect": "Allow" 同様に いずれのパイプラインにも AWS CodeDeploy が含まれていない場合は ポリシーステートメント を編集して AWS CodeDeploy リソースのアクセス許可を付与するセクションを削除できます, "Action": [ "codedeploy:createdeployment", "codedeploy:getapplicationrevision", "codedeploy:getdeployment", "codedeploy:getdeploymentconfig", "codedeploy:registerapplicationrevision" ], "Resource": "*", "Effect": "Allow" IAM ロールの詳細については IAM ロール を参照してください 225

233 お客様が管理するポリシーの例 お客様が管理するポリシーの例 このセクションでは さまざまな AWS CodePipeline アクションのアクセス権限を付与するユーザーポリ シー例を示しています これらのポリシーは AWS CodePipeline API AWS SDK または AWS CLI を 使用しているときに機能します コンソールを使用している場合は AWS CodePipeline コンソールを 使用するために必要なアクセス権限 (p. 219) で説明しているコンソールに固有の追加のアクセス権限を 付与する必要があります すべての例で 米国西部 (オレゴン) リージョン (us-west-2) リージョンを使用し 架空のアカウ ント ID を含めています 例 例 1: パイプラインの状態を取得するためのアクセス許可を付与する (p. 226) 内に位置している 例 2: ステージ間の移行を有効化または無効化するアクセス許可を付与する (p. 226) 内に位置している 例 3: 利用可能なすべてのアクションの種類のリストを取得するためのアクセス許可を付与す る (p. 227) 内に位置している 例 4: 手動の承認アクションを承認または拒否するためのアクセス許可を付与する (p. 227) 内に位置し ている 例 5: カスタムアクションのジョブをポーリングするためのアクセス許可を付与する (p. 228) 内に位置 している 例 6: Jenkins を AWS CodePipeline と統合するためのポリシーをアタッチまたは編集する (p. 228) 内 に位置している 例 7: パイプラインにクロスアカウントアクセスを設定する (p. 228) 内に位置している 例 8: 別のアカウントに関連付けられた AWS リソースをパイプラインで使用する (p. 230) 内に位置し ている 例 1: パイプラインの状態を取得するためのアクセス許可を付与 する 以下の例では パイプライン (MyFirstPipeline) の状態を取得する権限を付与します "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "codepipeline:getpipelinestate" ], "Resource": "arn:aws:codepipeline:us-west-2: :myfirstpipeline" ] 例 2: ステージ間の移行を有効化または無効化するアクセス許可 を付与する 以下の例では パイプライン (MyFirstPipeline) のすべてのステージ間での移行を無効化または有効化 するアクセス許可を付与します 226

234 お客様が管理するポリシーの例 "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "codepipeline:disablestagetransition", "codepipeline:enablestagetransition" ], "Resource": "arn:aws:codepipeline:us-west-2: :myfirstpipeline/*" ] ユーザーが パイプラインの 1 つのステージでの移行を無効化または有効化できるようにするには ス テージを指定する必要があります たとえば ユーザーがパイプライン (MyFirstPipeline) のステージ (Staging) の移行を有効化または無効化できるようにするには 以下を行います "Resource": "arn:aws:codepipeline:us-west-2: :myfirstpipeline/staging" 例 3: 利用可能なすべてのアクションの種類のリストを取得する ためのアクセス許可を付与する 以下の例では us-west-2 リージョンのパイプラインで利用できるすべてのアクションの種類のリスト を取得するためのアクセス許可を付与します "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "codepipeline:listactiontypes" ], "Resource": "arn:aws:codepipeline:us-west-2: :actiontype:*" ] 例 4: 手動の承認アクションを承認または拒否するためのアクセ ス許可を付与する 以下の例では パイプライン (MyFirstPipeline) のステージ (Staging) で手動の承認アクションを承認 または拒否するためのアクセス許可を付与します "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "codepipeline:putapprovalresult" ], "Resource": "arn:aws:codepipeline:us-west-2: :myfirstpipeline/ Staging/*" ] 227

235 お客様が管理するポリシーの例 例 5: カスタムアクションのジョブをポーリングするためのアク セス許可を付与する 以下の例では カスタムアクション (TestProvider) のジョブをポーリングするためのアクセス許可を付 与します これは すべてのパイプラインで最初のバージョンのアクションの種類である Test です カスタムアクションのジョブワーカーは 異なる AWS アカウントを使用して設定するか 特定 の IAM ロールで実行する必要があります "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "codepipeline:pollforjobs" ], "Resource": [ "arn:aws:codepipeline:uswest-2: :actiontype:custom/test/testprovider/1" ] ] 例 6: Jenkins を AWS CodePipeline と統合するためのポリシーを アタッチまたは編集する Jenkins を使用するためにパイプラインを設定して ビルドまたはテストを行う場合は 統合用に別の IAM ユーザーを作成し Jenkins と AWS CodePipeline の統合に必要な最小のアクセス許可を持つ IAM ポ リシーをアタッチします このポリシーは AWSCodePipelineCustomActionAccess 管理ポリシーと同じ です 以下の例では Jenkins との統合で使用する IAM ユーザーにアタッチするポリシーを示します "Statement": [ "Action": [ "codepipeline:acknowledgejob", "codepipeline:getjobdetails", "codepipeline:pollforjobs", "codepipeline:putjobfailureresult", "codepipeline:putjobsuccessresult" ], "Effect": "Allow", "Resource": "*" ], "Version": " " 例 7: パイプラインにクロスアカウントアクセスを設定する 別の AWS アカウントのユーザーおよびグループのパイプラインへのアクセスを設定できます この方法 を行うには パイプラインが作成されたアカウントのロールを作成し 他の AWS アカウントのユーザー がそのロールを継承してパイプラインにアクセスできるようにすることをお勧めします 詳細について は ウォークスルー: ロールを使用したクロスアカウントアクセス を参照してください 228

236 お客様が管理するポリシーの例 以下の例では 80398EXAMPLE アカウントのポリシーを示します このポリシーでは ユーザーは AWS CodePipeline コンソールにパイプライン (MyFirstPipeline)を表示することはできますが 変更する ことはできません このポリシーは AWSCodePipelineReadOnlyAccess 管理ポリシーに基づいていま すが パイプライン (MyFirstPipeline) に固有であるため この管理ポリシーを直接使用することは できません ポリシーを特定のパイプラインに制限しない場合は AWS CodePipeline によって作成およ び保守されているいずれかの管理ポリシーを使用することを真剣に検討してください 詳細については 管理ポリシーの使用 を参照してください このポリシーは アクセス用に作成した IAM ロール (例: CrossAccountPipelineViewers) にアタッチする必要があります "Statement": [ "Action": [ "codepipeline:getpipeline", "codepipeline:getpipelinestate", "codepipeline:listactiontypes", "codepipeline:listpipelines", "iam:listroles", "s3:getbucketpolicy", "s3:getobject", "s3:listallmybuckets", "s3:listbucket", "codedeploy:getapplication", "codedeploy:getdeploymentgroup", "codedeploy:listapplications", "codedeploy:listdeploymentgroups", "elasticbeanstalk:describeapplications", "elasticbeanstalk:describeenvironments", "lambda:getfunctionconfiguration", "lambda:listfunctions" ], "Effect": "Allow", "Resource": "arn:aws:codepipeline:us-east-2:80398example:myfirstpipeline" ], "Version": " " このポリシーを作成したら アカウント 80398EXAMPLE に IAM ロールを作成し そのロールにポリシー をアタッチします ロールの信頼関係で このロールを継承する AWS アカウントを追加する必要があり ます 次の例では AWS アカウント ( ) のユーザーが 80398EXAMPLE アカウント で定 義されているロールを継承できるポリシーを示しています "Version": " ", "Statement": [ "Effect": "Allow", "Principal": "AWS": "arn:aws:iam:: :root", "Action": "sts:assumerole" ] 以下の例では AWS アカウント ( ) で作成されたポリシーを示しています このポリシー では ユーザーは 80398EXAMPLE アカウント のロール (CrossAccountPipelineViewers) を継承す ることができます 229

237 お客様が管理するポリシーの例 "Version": " ", "Statement": [ "Effect": "Allow", "Action": "sts:assumerole", "Resource": "arn:aws:iam::80398example:role/crossaccountpipelineviewers" ] 例 8: 別のアカウントに関連付けられた AWS リソースをパイプ ラインで使用する ユーザーが 他の AWS アカウント内のリソースを使用するパイプラインを作成できるようにするポリ シーを設定できます これを行うには パイプライン (AccountA) を作成するアカウントと パイプライン で使用するリソースを作成したアカウント (AccountB) の両方にポリシーおよびロールを設定する必要があ ります また カスタマー管理型のキーを AWS Key Management Service に作成して クロスアカウン トアクセスに使用する必要があります 詳細およびステップごとの例については 他の AWS アカウン トからリソースを使用するパイプラインを AWS CodePipeline に作成 (p. 136) および セキュリティ設 定 (p. 236) を参照してください 以下の例では パイプラインアーティファクトを保存するために使用される Amazon S3 バケット向 けに AccountA によって設定されるポリシーを示します このポリシーは AccountB (AccountB の ARN) へのアクセス許可を付与します 次の例では AccountB の ARN は 012ID_ACCOUNT_B で す Amazon S3 バケットの ARN は codepipeline-us-east です これらの ARN を アクセスできるようにするアカウントおよび Amazon S3 バケットの ARN と置き換えます "Version": " ", "Id": "SSEAndSSLPolicy", "Statement": [ "Sid": "DenyUnEncryptedObjectUploads", "Effect": "Deny", "Principal": "*", "Action": "s3:putobject", "Resource": "arn:aws:s3:::codepipeline-us-east /*", "Condition": "StringNotEquals": "s3:x-amz-server-side-encryption": "aws:kms", "Sid": "DenyInsecureConnections", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::codepipeline-us-east /*", "Condition": "Bool": "aws:securetransport": false, "Sid": "", "Effect": "Allow", "Principal": "AWS": "arn:aws:iam::012id_account_b:root", 230

238 お客様が管理するポリシーの例, ] "Action": [ "s3:get*", "s3:put*" ], "Resource": "arn:aws:s3:::codepipeline-us-east /*" "Sid": "", "Effect": "Allow", "Principal": "AWS": "arn:aws:iam::012id_account_b:root", "Action": "s3:listbucket", "Resource": "arn:aws:s3:::codepipeline-us-east " 以下の例では AccountA が設定したポリシーを示します このポリシーは AccountB がロールを継承 できるようにします このポリシーは AWS CodePipeline のサービスロール (AWS-CodePipelineService) に適用する必要があります IAM のロールにポリシーを適用する方法については ロールの 修正 を参照してください 次の例では 012ID_ACCOUNT_B は AccountB の ARN です "Version": " ", "Statement": "Effect": "Allow", "Action": "sts:assumerole", "Resource": [ "arn:aws:iam::012id_account_b:role/*" ] 次の例では AccountB によって設定され AWS CodeDeploy の Amazon EC2 インスタンスロール に 適用されたポリシーを示します このポリシーでは パイプラインアーティファクト (codepipelineus-east ) を保存するために AccountA によって使用される Amazon S3 バケットへのア クセスを付与します "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "s3:get*" ], "Resource": [ "arn:aws:s3:::codepipeline-us-east /*" ], "Effect": "Allow", "Action": [ "s3:listbucket" ], "Resource": [ "arn:aws:s3:::codepipeline-us-east " ] ] 231

239 お客様が管理するポリシーの例 以下の例は arn:aws:kms:useast-1:012id_account_a:key/ example は AccountA で作成 されたカスタマー管理キーの ARN であり AccountB にそのキーの使用を許可するように設定している AWS KMS のポリシーを示しています "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "kms:describekey", "kms:generatedatakey*", "kms:encrypt", "kms:reencrypt*", "kms:decrypt" ], "Resource": [ "arn:aws:kms:useast-1:012id_account_a:key/ example" ] ] 次の例では AccountB で作成された IAM ロール (CrossAccount_Role) のインラインポリシーを示 し AccountA のパイプラインで必要な AWS CodeDeploy アクションにアクセスできるようにします "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "codedeploy:createdeployment", "codedeploy:getdeployment", "codedeploy:getdeploymentconfig", "codedeploy:getapplicationrevision", "codedeploy:registerapplicationrevision" ], "Resource": "*" ] 次の例では AccountB で作成された IAM ロール (CrossAccount_Role) のインラインポリシーを示し 入力アーティファクトダウンロードし 出力アーティファクトをアップロードするために Amazon S3 バ ケットにアクセスできるようにします "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "s3:getobject*", "s3:putobject", "s3:putobjectacl" ], "Resource": [ "arn:aws:s3:::codepipeline-us-east /*" ] 232

240 AWS CodePipeline の権限リファレンス ] 必要なポリシー ロール AWS Key Management Service カスタマー管理型のキー作成後にリソースにク ロスアカウントアクセスするために パイプラインを編集する方法については ステップ 2: パイプライ ンの編集 (p. 143) を参照してください AWS CodePipeline の権限リファレンス IAM ポリシーを使用したアクセスコントロール (p. 210) をセットアップし IAM アイデンティティにア タッチできるアクセス権限ポリシー アイデンティティベースのポリシー を作成するときは 以下の 表をリファレンスとして使用できます この表には 各 AWS CodePipeline API オペレーション およ びその実行のためのアクセス権限を付与できる対応するアクションを示しています ポリシーの Action フィールドでアクションを指定し ポリシーの Resource フィールドでリソース値としてワイルドカード 文字 (*) を指定します AWS CodePipeline ポリシーで AWS 全体の条件キーを使用して 条件を表現することができます AWS 全体を対象とするキーの完全なリストについては IAM ユーザーガイド の 利用可能なキー を参照 してください アクションを指定するには API オペレーション名の前 に codepipeline: プレフィックスを使用します 例: codepipeline:getpipeline codepipeline:createpipeline codepipeline:* (すべ ての AWS CodePipeline アクションの場合) 単一のステートメントに複数のアクションを指定するには 次のようにコンマで区切ります "Action": ["codepipeline:action1", "codepipeline:action2"] ワイルドカードを使用して複数のアクションを指定することもできます たとえば Get という単語 で始まる名前のすべてのアクションは 以下のように指定できます "Action": "codepipeline:get*" AWS CodePipeline API アクションをすべて指定するには * ワイルドカードを以下のように使用します "Action": "codepipeline:*" AWS CodePipeline を使用して IAM ポリシーで指定できるアクションは以下のとおりです AWS CodePipelineAPI オペレーションおよびアクションで必要なアクセス許可 AcknowledgeJob アクション: codepipeline:acknowledgejob 特定のジョブに関する情報や そのジョブがジョブワーカーで受け取られたかどうかについて表示す るために必要です カスタムアクションにのみ使用されます AcknowledgeThirdPartyJob アクション: codepipeline:acknowledgethirdpartyjob ジョブワーカーが特定のジョブを受け取ったことを確認するために必要です パートナーアクション にのみ使用されます 233

241 AWS CodePipeline の権限リファレンス CreateCustomActionType アクション: codepipeline:createcustomactiontype AWS アカウントに関連付けられているすべてのパイプラインで使用できる新しいカスタムアクション を作成するために必要です カスタムアクションにのみ使用されます CreatePipeline アクション: codepipeline:createpipeline パイプラインを作成するために必要です DeleteCustomActionType アクション: codepipeline:deletecustomactiontype カスタムアクションを削除済みとマークするために必要です アクションが削除とマークされると カスタムアクションの PollForJobs は失敗します カスタムアクションにのみ使用されます DeletePipeline アクション: codepipeline:deletepipeline パイプラインを削除するために必要です DeleteWebhook アクション: codepipeline:deletewebhook ウェブフックを削除するために必要です DeregisterWebhookWithThirdParty アクション: codepipeline:deregisterwebhookwiththirdparty ウェブフックが削除される前に CodePipeline で作成されたウェブフックと検出されるイベントの外 部ツールとの間の接続を削除するように要求されます 現在のところ GitHub のアクションタイプを ターゲットとするウェブフックでのみサポートされています DisableStageTransition アクション: codepipeline:disablestagetransition パイプラインのアーティファクトが パイプラインの次のステージに移行しないようにするために必 要です EnableStageTransition アクション: codepipeline:enablestagetransition パイプラインのアーティファクトが パイプラインのステージに移行できるようにするために必要で す GetJobDetails アクション: codepipeline:getjobdetails ジョブに関する情報を取得するために必要です カスタムアクションにのみ使用されます GetPipeline アクション: codepipeline:getpipeline パイプライン ARN を含む パイプラインの構造 ステージ アクション およびメタデータを取得 するために必要です 234

242 AWS CodePipeline の権限リファレンス GetPipelineExecution アクション: codepipeline:getpipelineexecution パイプラインの実行に関する情報 (アーティファクト パイプラインの実行 ID パイプラインの名 前 バージョン ステータスなど) を取得するために必要です GetPipelineState アクション: codepipeline:getpipelinestate パイプラインの状態に関する情報 (ステージ アクションなど) を取得するために必要です GetThirdPartyJobDetails アクション: codepipeline:getthirdpartyjobdetails サードパーティアクションのジョブの詳細をリクエストするために必要です パートナーアクション にのみ使用されます ListActionTypes アクション: codepipeline:listactiontypes アカウントに関連付けられたすべての AWS CodePipeline のアクションタイプの概要を生成するため に必要です ListPipelineExecutions アクション: codepipeline:listpipelineexecutions パイプラインの最新の実行の概要を生成するために必要です ListPipelines アクション: codepipeline:listpipelines アカウントに関連付けられたすべてのパイプラインの概要を生成するために必要です ListWebhooks アクション: codepipeline:listwebhooks そのリージョンのアカウントの全ウェブフックの一覧表示に必要です PollForJobs アクション: codepipeline:pollforjobs AWS CodePipeline を実行するジョブに関する情報を取得するために必要です PollForThirdPartyJobs アクション: codepipeline:pollforthirdpartyjobs ジョブワーカーが作用するサードパーティジョブが存在するかどうかを判断するために必要です パートナーアクションにのみ使用されます PutActionRevision アクション: codepipeline:putactionrevision 新しいリビジョンに関する AWS CodePipeline の情報をソースにレポートするために必要です PutApprovalResult アクション: codepipeline:putapprovalresult AWS CodePipeline に対する手動の承認リクエストの応答をレポートするために必要です 有効なレ スポンスには 承認および拒否があります 235

243 セキュリティ設定 PutJobFailureResult アクション: codepipeline:putjobfailureresult ジョブワーカーによってパイプラインに返されたジョブの失敗をレポートするために必要です カス タムアクションにのみ使用されます PutJobSuccessResult アクション: codepipeline:putjobsuccessresult ジョブワーカーによってパイプラインに返されたジョブの成功をレポートするために必要です カス タムアクションにのみ使用されます PutThirdPartyJobFailureResult アクション: codepipeline:putthirdpartyjobfailureresult ジョブワーカーによってパイプラインに返るサードパーティジョブの失敗をレポートするために必要 です パートナーアクションにのみ使用されます PutThirdPartyJobSuccessResult アクション: codepipeline:putthirdpartyjobsuccessresult ジョブワーカーによってパイプラインに返るサードパーティジョブの成功をレポートするために必要 です パートナーアクションにのみ使用されます PutWebhook アクション: codepipeline:putwebhook ウェブフックを作成するために必要です RegisterWebhookWithThirdParty アクション: codepipeline:registerwebhookwiththirdparty ウェブフックの作成後 ウェブフック URL を生成するために サポートされるサードパーティを設定 することが必要です RetryStageExecution アクション: codepipeline:retrystageexecution ステージで最後に失敗したアクションを再試行することでパイプラインの実行を再開するために必要 です StartPipelineExecution アクション: codepipeline:startpipelineexecution 指定のパイプラインを開始するために必要です 具体的に パイプラインの一部として指定されてい るソースロケーションへ最新のコミットの処理が開始されます UpdatePipeline アクション: codepipeline:updatepipeline その構造を編集または変更して 指定のパイプラインを更新するために必要です セキュリティ設定 このセクションでは 次のベストプラクティスに基づいたセキュリティ設定について説明します 236

244 AWS CodePipeline 用として Amazon S3 に保存した アーティファクトのサーバー側の暗号化を設定する S3 アーティファクトのサーバー側の暗号化 (SSE) GitHub 個人用のアクセストークン パラメータストア内の設定パラメータのトラッキング トピック AWS CodePipeline 用として Amazon S3 に保存したアーティファクトのサーバー側の暗号化を設定す る (p. 237) GitHub の認証を設定する (p. 239) データベースパスワードまたはサードパーティの API キーを追跡するためにパラメータストアを使用 する (p. 242) AWS CodePipeline 用として Amazon S3 に保存した アーティファクトのサーバー側の暗号化を設定する Amazon S3 アーティファクトのサーバー側の暗号化を設定するには 次の 2 つの方法があります AWS CodePipeline は [パイプラインの作成] ウィザードを使用してパイプラインを作成する と Amazon S3 アーティファクトバケットとデフォルトの AWS が管理する SSE-KMS 暗号化キーを作 成します マスターキーはオブジェクトデータとともに暗号化され AWS によって管理されます 独自のカスタマー管理 SSE-KMS キーを作成して管理することができます デフォルトの Amazon S3 キーを使用している場合 この AWS 管理キーを変更または削除することはでき ません AWS KMS で顧客管理キーを使用して Amazon S3 バケット内のアーティファクトを暗号化また は復号化する場合は 必要に応じてこのキーを変更または回転できます Amazon S3 は バケットに格納されているすべてのオブジェクトに対してサーバー側の暗号化が必要な場 合に使用できるバケットポリシーをサポートしています たとえば SSE-KMS を使用したサーバー側の 暗号化を要求する x-amz-server-side-encryption ヘッダーがリクエストに含まれていない場合 次 のバケットポリシーはすべてのユーザーに対し オブジェクト (s3:putobject) をアップロードするアク セス許可を拒否します "Version": " ", "Id": "SSEAndSSLPolicy", "Statement": [ "Sid": "DenyUnEncryptedObjectUploads", "Effect": "Deny", "Principal": "*", "Action": "s3:putobject", "Resource": "arn:aws:s3:::codepipeline-us-west /*", "Condition": "StringNotEquals": "s3:x-amz-server-side-encryption": "aws:kms", "Sid": "DenyInsecureConnections", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::codepipeline-us-west /*", "Condition": "Bool": 237

245 AWS CodePipeline 用として Amazon S3 に保存した アーティファクトのサーバー側の暗号化を設定する ] "aws:securetransport": "false" サーバー側の暗号化と AWS KMS の詳細については サーバー側の暗号化を使用したデータの保護 お よび UsingKMSEncryption.html を参照してください AWS KMS の詳細については AWS Key Management Service 開発者ガイド および および UsingKMSEncryption.html を参照してください トピック Amazon S3SSE-KMS のデフォルトの暗号化キーを表示する (p. 238) AWS CloudFormation または CLI の使用時に S3 バケットのサーバー側の暗号化を設定する (p. 238) Amazon S3SSE-KMS のデフォルトの暗号化キーを表示する [Create Pipeline] ウィザードを使用して最初のパイプラインを作成すると Amazon S3 バケットは パ イプラインを作成したのと同じリージョンに作成されます バケットは パイプラインアーティファクト を格納するために使用されます パイプラインが実行されると アーティファクトが Amazon S3 バケッ トに取り込まれ 取得されます デフォルトでは AWS CodePipeline は Amazon S3 のデフォルトキー (aws/s3 キー) を使用して AWS KMS 管理キー (SSE-KMS) でサーバー側の暗号化を使用します この キーは AWS アカウントに作成され 保存されます アーティファクトが Amazon S3 バケットから取得 されると AWS CodePipeline は同じ SSE-KMS プロセスを使用してアーティファクトを復号化します デフォルトの AWS KMS キーに関する情報を表示するには 以下の操作を実行します 1. AWS マネジメントコンソール にサインインし IAM コンソール iam/ を開きます 2. サービスナビゲーションペインで [Encryption Keys] を選択します(ウェルカムページが表示される場 合は [今すぐ始める] を選択します) 3. [Filter] で パイプラインのリージョンを選択します たとえば パイプラインが us-east-2 に作成 されている場合は フィルタが 米国東部 (オハイオ) に設定されていることを確認します AWS CodePipeline で使用できるリージョンとエンドポイントの詳細については リージョンとエ ンドポイント を参照してください 内に位置している 4. 暗号化キーのリストで パイプラインに使用されるエイリアスがあるキー (デフォルトは aws/s3) を選 択します キーの基本情報が表示されます AWS CloudFormation または CLI の使用時に S3 バケットのサー バー側の暗号化を設定する AWS CloudFormation または CLI を使用してパイプラインを作成するときに サーバー側の暗号化を手動 で設定する必要があります 上記のサンプルバケットポリシーを使用して 独自のカスタマー管理 SSEKMS 暗号化キーを作成します 一般的なデフォルトの Amazon S3 キーの代わりに独自のキーを使用する こともできます その一部の理由として次のようなものがあります 組織のビジネス要件またはセキュリティ要件を満たすために スケジュールに基づいてキーのローテー ションをする必要があります 別の AWS アカウントに関連付けられたリソースを使用するパイプラインを作成する必要があります これには カスタマー管理キーを使用する必要があります 詳細については 他の AWS アカウント からリソースを使用するパイプラインを AWS CodePipeline に作成 (p. 136) を参照してください 238

246 GitHub の認証を設定する 暗号化のベストプラクティスでは 暗号化キーの広範な再利用を推奨していません ベストプラクティ スとして キーを定期的にローテーションします AWS Key Management Service (AWS KMS) のカスタ マーマスターキー (CMK) 用の新しい暗号化資料を作成するには 新しい CMK を作成してから 新しい CMK を使用するようにアプリケーションまたはエイリアスを変更します または 既存の CMK の自動 キーローテーションを有効にすることができます SSE-KMS カスタマーマスターキーをローテーションするには カスタマーマスターキーのローテー ション を参照してください GitHub の認証を設定する AWS CodePipeline は GitHub OAuth トークンと個人用のアクセストークンを使用して GitHub リポジト リにアクセスし 最新の変更を取得します GitHub で認証を設定するには 2 つの方法があります コンソールを使用してパイプラインを作成または更新すると AWS はデフォルトの AWS 管理の OAuth トークンを作成します 独自の顧客生成の個人アクセストークンを作成して管理することができます CLI SDK または AWS CloudFormation を使用してパイプラインを作成または更新する場合は 個人アクセストークンが必要で す トピック 認定された OAuth アプリを表示する (p. 239) GitHub と AWS CodePipeline CLI を使用して GitHub 個人用のアクセストークンを作成し 定期的に ローテーションする (p. 240) 認定された OAuth アプリを表示する AWS CodePipeline は OAuth トークンを使用して GitHub と統合します GitHub は AWS CodePipeline の OAuth トークンのアクセス許可を追跡します これらの手順を使用して GitHub で承認された統合を確認します 1. GitHub で プロフィール写真のドロップダウンオプションから [Settings] を選択します 2. [アプリケーション] を選択してから [Authorized OAuth Apps] を選択します 3. 認証されたアプリを確認します 239

247 GitHub の認証を設定する GitHub と AWS CodePipeline CLI を使用して GitHub 個人用の アクセストークンを作成し 定期的にローテーションする スクリプトのパスワードの代わりにトークンを使用する利点は トークンは取り消したりローテーショ ンさせたりできることです また 個人アクセストークンに特定の権限とアクセス許可を与えることも できます トークンは安全に保管し 定期的にローテーションまたは再生成する必要があります トー クンローテーションは RFC-6819 (OAuth 2.0 の脅威モデルとセキュリティ上の考慮事項) セクション で推奨されています 詳細については GitHub ウェブサイトの コマンドライン用の個人アクセストークンの作成 を参照して ください 新しい個人用アクセストークンを再生成したら CLI または API を使用して または AWS CloudFormation を使用して UpdatePipeline を呼び出すことで ローテーションすることができます 同じ個人用のアクセストークンを使用している場合は 他のアプリケーションの更新が必要にな る場合があります セキュリティのベストプラクティスとして 複数のアプリケーション間で 単一のトークンを共有しないでください 各アプリケーションに対して新しい個人用のアクセス トークンを作成します これらの手順を使用して GitHub 個人用アクセストークンをローテーションし パイプライン構造を新し いトークンで更新します 個人用アクセストークンをローテーションした後 古いトークン情報を含む CLI スクリプトまた は AWS CloudFormation テンプレートを必ず更新してください 1. GitHub で プロフィール写真のドロップダウンオプションから [Settings] を選択します 2. [Developer settings] を選択してから [Personal access tokens] を選択します 3. GitHub の個人用アクセストークンの横にある [編集] を選択します 4. [Regenerate token] を選択します 240

248 GitHub の認証を設定する 5. 再生成されたトークンの横にあるコピーアイコンをクリックします 6. ターミナル (Linux, macos, or Unix) またはコマンドプロンプト (Windows) で 個人用アクセストーク ンを変更するパイプラインに対して get-pipeline コマンドを実行し コマンドの出力を JSON ファイ ルにコピーします たとえば MyFirstPipeline という名前のパイプラインに対しては 以下のような コマンドを入力します aws codepipeline get-pipeline --name MyFirstPipeline >pipeline.json コマンドの出力は pipeline.json ファイルに送られます 7. プレーンテキストエディタでファイルを開き GitHub アクションの OAuthTokenField の値を編集 します アスタリスク (****) を GitHub からコピーしたトークンに置き換えます 例: "configuration": "Owner": "MyGitHubUserName", "Repo": "test-repo", 241