Amazon CodeCatalyst は新規のお客様には提供されなくなりました。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、「[CodeCatalyst から移行する方法](migration.md)」を参照してください。

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

# ワークフローを使用したデプロイ
<a name="deploy"></a>



[CodeCatalyst ワークフロー](workflow.md)を使用すると、Amazon ECS などのさまざまなターゲットにアプリケーションやその他のリソースをデプロイできます AWS Lambda。

## アプリケーションをデプロイする方法を教えてください。
<a name="deploy-concepts"></a>

CodeCatalyst を使用してアプリケーションまたはリソースをデプロイするには、まずワークフローを作成し、その中にデプロイアクションを指定します。*[デプロイアクション]* は、デプロイする*内容*、デプロイする*場所*、デプロイ*方法* (ブルー/グリーンスキームを使用するなど) を定義するワークフロービルドブロックです。CodeCatalyst コンソールのビジュアルエディタ、または YAML エディタを使用して、ワークフローにデプロイアクションを追加します。

アプリケーションまたはリソースをデプロイするための大まかなステップは次のとおりです。

**アプリケーションをビルドするには (概要レベルのタスク)**

1. CodeCatalyst プロジェクトで、デプロイするアプリケーションの **[ソースコードを追加]** します。詳細については、「[CodeCatalyst のプロジェクト用リポジトリにソースコードを保存する](source-repositories.md)」を参照してください。

1. CodeCatalyst プロジェクトで、デプロイ先のターゲット AWS アカウント とオプションの Amazon Virtual Private Cloud (VPC) を定義する**環境を追加します**。詳細については、「[AWS アカウント と VPCs へのデプロイ](deploy-environments.md)」を参照してください。

1. CodeCatalyst プロジェクトで、**[ワークフローを作成]** します。ワークフローでは、アプリケーションをビルド、テスト、デプロイする方法を定義します。詳細については、「[初めてのワークフロー](workflows-getting-started.md)」を参照してください。

1. ワークフローでは、**[トリガーを追加]**、**[ビルドアクション]**、および任意で **[テストアクション]** を追加します。詳細については[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)、[ビルドアクションの追加](build-add-action.md)、および[テストアクションの追加](test-add-action.md)を参照してください。

1. ワークフローで、**[デプロイアクションを追加]** します。CodeCatalyst が提供する複数のデプロイアクションから、Amazon ECS などの異なるターゲットにアプリケーションをデプロイするアクションを選択できます。(ビルドアクションまたは GitHub アクションを使用してアプリケーションをデプロイすることもできます。ビルドアクションと GitHub アクションの詳細については、「[アクションをデプロイする他の方法](#deploy-concepts-alternatives)」を参照してください。)

1. **ワークフローの開始**は、手動で行うか、トリガーを介して自動で行います。ワークフローは、デプロイアクションを順番に実行して、アプリケーションとリソースをターゲットにビルド、テスト、デプロイします。詳細については、「[手動でのワークフロー実行の開始](workflows-manually-start.md)」を参照してください。

## デプロイアクションの一覧
<a name="deploy-concepts-action-supported"></a>

次のデプロイアクションを使用できます。
+  CloudFormation スタックをデプロイする – このアクションは、[AWS Serverless Application Model](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)指定した[CloudFormation テンプレート](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification.html) AWS に基づいて に CloudFormation スタックを作成します。詳細については、「[CloudFormation スタックのデプロイ](deploy-action-cfn.md)」を参照してください。
+ Amazon ECS にデプロイ – このアクションは、指定した [[タスク定義]](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions) ファイルを登録します。詳細については、「[ワークフローを使用した Amazon ECS へのデプロイ](deploy-action-ecs.md)」を参照してください。
+ Kubernetes クラスターにデプロイ – このアクションは、アプリケーションを Amazon Elastic Kubernetes Service クラスターにデプロイします。詳細については、「[ワークフローを使用して Amazon EKS にデプロイする](deploy-action-eks.md)」を参照してください。
+ AWS CDK deploy – このアクションは、[AWS CDK アプリケーションを](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_concepts) にデプロイします AWS。詳細については、「[ワークフローを使用した AWS CDK アプリケーションのデプロイ](cdk-dep-action.md)」を参照してください。

**注記**  
リソースをデプロイできる他の CodeCatalyst アクションもありますが、*[デプロイ]* 情報は **[環境]** ページに表示されないため、デプロイアクションとはみなされません。**[環境]** ページとデプロイの表示の詳細については、「[AWS アカウント と VPCs へのデプロイ](deploy-environments.md)」および「[デプロイ情報の表示](deploy-view-deployment-info.md)」を参照してください。

## デプロイアクションの利点
<a name="deploy-concepts-why-use"></a>

ワークフロー内でデプロイアクションを使用すると、次の利点があります。
+ **デプロイ履歴** – デプロイの履歴を表示して、デプロイされたソフトウェアの変更を管理および伝達できます。
+ **トレーサビリティ** – CodeCatalyst コンソールを使用してデプロイのステータスをトラッキングし、各アプリケーションリビジョンがいつ、どこでデプロイされたかを確認できます。
+ **ロールバック** – エラーが発生した場合は、デプロイを自動的にロールバックします。デプロイのロールバックをアクティブ化するようにアラームを設定することもできます。
+ **モニタリング** – ワークフローのさまざまな段階の進行状況を監視できます。
+ **他の CodeCatalyst 機能との統合** – ソースコードを保存し、それを 1 つのアプリケーションからビルド、テスト、デプロイできます。

## アクションをデプロイする他の方法
<a name="deploy-concepts-alternatives"></a>

デプロイアクションを使用する必要はないものの、前のセクションで説明した利点があるため、使用することを推奨します。代わりに、次の [[CodeCatalyst アクション]](workflows-actions.md#workflows-actions-types-cc) を使用できます。
+ **[ビルド]** アクション。

  通常、対応するデプロイアクションが存在しないターゲットにデプロイする場合、またはデプロイ手順をより詳細に制御する場合は、ビルドアクションを使用します。ビルドアクションを使用してリソースをデプロイする方法については、「[ワークフローを使用したビルド](build-workflow-actions.md)」を参照してください。
+ **[GitHub アクション]**。

  CodeCatalyst ワークフロー内で [[GitHub アクション]](workflows-actions.md#workflows-actions-types-github) を使用して、アプリケーションとリソースを (CodeCatalyst アクションの代わりに) デプロイできます。CodeCatalyst ワークフロー内で GitHub アクションを使用する方法については、「[GitHub Actions との統合](integrations-github-actions.md)」を参照してください。

CodeCatalyst ワークフローを使用しない場合は、次の AWS サービスを使用してアプリケーションをデプロイすることもできます。
+ AWS CodeDeploy – [CodeDeploy とは」を参照してください。](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ AWS CodeBuild および AWS CodePipeline – [「 とは」を参照してください AWS CodeBuild。](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) と [とは AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ CloudFormation – [「 とは」を参照してください CloudFormation。](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)

複雑なエンタープライズデプロイには、CodeDeploy、CodeBuild、CodePipeline、および CloudFormation のサービスを使用します。

**Topics**
+ [アプリケーションをデプロイする方法を教えてください。](#deploy-concepts)
+ [デプロイアクションの一覧](#deploy-concepts-action-supported)
+ [デプロイアクションの利点](#deploy-concepts-why-use)
+ [アクションをデプロイする他の方法](#deploy-concepts-alternatives)
+ [ワークフローを使用した Amazon ECS へのデプロイ](deploy-action-ecs.md)
+ [ワークフローを使用して Amazon EKS にデプロイする](deploy-action-eks.md)
+ [CloudFormation スタックのデプロイ](deploy-action-cfn.md)
+ [ワークフローを使用した AWS CDK アプリケーションのデプロイ](cdk-dep-action.md)
+ [ワークフローを使用して AWS CDK アプリをブートストラップする](cdk-boot-action.md)
+ [ワークフローを使用して Amazon S3 にファイルを発行する](s3-pub-action.md)
+ [AWS アカウント と VPCs へのデプロイ](deploy-environments.md)
+ [ワークフロー図でのアプリケーション URL の表示](deploy-app-url.md)
+ [デプロイターゲットの削除](deploy-remove-target.md)
+ [コミット別のデプロイステータスの追跡](track-changes.md)
+ [デプロイログの表示](deploy-deployment-logs.md)
+ [デプロイ情報の表示](deploy-view-deployment-info.md)

# ワークフローを使用した Amazon ECS へのデプロイ
<a name="deploy-action-ecs"></a>

このセクションでは、CodeCatalyst ワークフローを使用してコンテナ化されたアプリケーションを Amazon Elastic Container Service クラスターにデプロイする方法について説明します。これを行うには、**[Amazon ECS にデプロイ]** アクションをワークフローに追加する必要があります。このアクションは、指定した [[タスク定義]](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions) ファイルを登録します。登録すると、タスク定義は [[Amazon ECS クラスター]](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-clusters) で実行されている [[Amazon ECS サービス]](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html) によってインスタンス化されます。「タスク定義の実装」は、アプリケーションを Amazon ECS にデプロイするのと同等です。

このアクションを使用するには、Amazon ECS クラスター、サービス、タスク定義ファイルを準備しておく必要があります。

Amazon ECS の詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」を参照してください。

**ヒント**  
**[Amazon ECS にデプロイ]** アクションを使用する方法を示すチュートリアルについては、「[チュートリアル: Amazon ECS にアプリケーションをデプロイする](deploy-tut-ecs.md)」を参照してください。

**ヒント**  
**[Amazon ECS にデプロイ]** アクションの実用的な例については、**Node.js API with AWS Fargate** または Java **API with AWS Fargate** ブループリントを使用してプロジェクトを作成します。詳細については、「[ブループリントを使用したプロジェクトの作成](projects-create.md#projects-create-console-template)」を参照してください。

**Topics**
+ [「Amazon ECS にデプロイ」アクションで使用されるランタイムイメージ](#deploy-action-ecs-runtime)
+ [チュートリアル: Amazon ECS にアプリケーションをデプロイする](deploy-tut-ecs.md)
+ [「Amazon ECS にデプロイ」アクションの追加](deploy-action-ecs-adding.md)
+ [「Amazon ECS にデプロイ」する変数](deploy-action-ecs-variables.md)
+ [「Amazon ECS にデプロイ」アクション YAML](deploy-action-ref-ecs.md)

## 「Amazon ECS にデプロイ」アクションで使用されるランタイムイメージ
<a name="deploy-action-ecs-runtime"></a>

**[Amazon ECS にデプロイ]** アクションは、[[2022 年 11 月の画像]](build-images.md#build.previous-image) で実行されます。詳細については、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。

# チュートリアル: Amazon ECS にアプリケーションをデプロイする
<a name="deploy-tut-ecs"></a>

このチュートリアルでは、ワークフロー、Amazon ECS、およびその他のいくつかの AWS サービスを使用して、サーバーレスアプリケーションを Amazon Elastic Container Service (Amazon ECS) にデプロイする方法について説明します。デプロイされたアプリケーションは、Apache ウェブサーバー Docker イメージ上にビルドされたシンプルな Hello World ウェブサイトです。このチュートリアルでは、クラスターのセットアップなど必要な準備作業を順を追って説明し、アプリケーションをビルドおよびデプロイするためのワークフローを作成する方法について説明します。

**ヒント**  
このチュートリアルを進める代わりに、完全な Amazon ECS セットアップを実行するブループリントを使用できます。**[Node.js API with AWS Fargate]** または、**[Java API with AWS Fargate]** ブループリントで使用する必要があります。詳細については、「[ブループリントを使用したプロジェクトの作成](projects-create.md#projects-create-console-template)」を参照してください。

**Topics**
+ [前提条件](#deploy-tut-ecs-prereqs)
+ [ステップ 1: AWS ユーザーと をセットアップする AWS CloudShell](#deploy-tut-ecs-user-cloudshell)
+ [ステップ 2: プレースホルダーアプリケーションを Amazon ECS にデプロイする](#deploy-tut-ecs-placeholder)
+ [ステップ 1: Amazon ECR イメージリポジトリを作成する](#deploy-tut-ecs-ecr)
+ [ステップ 4: AWS ロールを作成する](#deploy-tut-ecs-build-deploy-roles)
+ [ステップ 5: CodeCatalyst に AWS ロールを追加する](#deploy-tut-ecs-import-roles)
+ [ステップ 6: ソースレポジトリを作成する](#deploy-tut-ecs-source-repo)
+ [ステップ 7: ソースファイルを追加する](#deploy-tut-ecs-source-files)
+ [ステップ 8: ワークフローを作成して実行する](#deploy-tut-ecs-workflow)
+ [ステップ 9: ソースファイルを変更する](#deploy-tut-ecs-change)
+ [クリーンアップ](#deploy-tut-ecs-cleanup)

## 前提条件
<a name="deploy-tut-ecs-prereqs"></a>

開始する前に:
+ 接続された AWS アカウントを持つ CodeCatalyst **スペース**が必要です。詳細については、「[スペースを作成する](spaces-create.md)」を参照してください。
+ スペースには、次の名前の空のプロジェクトが必要です。

  ```
  codecatalyst-ecs-project
  ```

  このプロジェクトを作成するには、**[ゼロから開始]** オプションを使用します。

  詳細については、「[Amazon CodeCatalyst での空のプロジェクトの作成](projects-create.md#projects-create-empty)」を参照してください。
+ プロジェクトには、以下と呼ばれる CodeCatalyst **[環境]** が必要です。

  ```
  codecatalyst-ecs-environment
  ```

  この環境を次のように設定します。
  + **[非本番稼働用]** など、任意のタイプを選択します。
  +  AWS アカウントに を接続します。
  + **[デフォルトの IAM ロール]** で、任意のロールを選択します。後で別のロールを指定します。

  詳細については、「[AWS アカウント と VPCs へのデプロイ](deploy-environments.md)」を参照してください。

## ステップ 1: AWS ユーザーと をセットアップする AWS CloudShell
<a name="deploy-tut-ecs-user-cloudshell"></a>

このチュートリアルの最初のステップは、 でユーザーを作成し AWS IAM アイデンティティセンター、このユーザーとしてインスタンスを起動 AWS CloudShell することです。このチュートリアルの期間中、CloudShell は開発用コンピュータであり、 AWS リソースとサービスを設定する場所です。チュートリアルを完了したら、このユーザーを削除してください。

**注記**  
このチュートリアルにルートユーザーを使用しないでください。別のユーザーを作成する必要があります。作成しないと、後で AWS Command Line Interface (CLI) でアクションを実行するときに問題が発生する可能性があります。

IAM アイデンティティセンターユーザーと CloudShell の詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」と「*AWS CloudShell ユーザーガイド*」を参照してください。

**IAM アイデンティティセンターユーザーを作成するには**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/singlesignon/](https://console.aws.amazon.com/singlesignon/) で AWS IAM アイデンティティセンター コンソールを開きます。
**注記**  
CodeCatalyst スペース AWS アカウント に接続されている を使用してサインインしていることを確認してください。スペースに移動し、**[AWS アカウント]** タブを選択することで、接続されているアカウントを確認できます。詳細については、「[スペースを作成する](spaces-create.md)」を参照してください。

1. ナビゲーションペインで **[Users]** (ユーザー)、**[Add user]** (ユーザーの追加) の順に選択します。

1. **[ユーザー名]** に次のように入力します。

   ```
   CodeCatalystECSUser
   ```

1. **[パスワード]** で、**[このユーザーと共有できるワンタイムパスワードを生成]** を選択します。

1. **[E メールアドレス]** と **[E メールアドレスを確認]** で、IAM アイデンティティセンターにまだ存在しない E メールアドレスを入力します。

1. **[名]** と **[姓]** で、次のように入力します。

   ```
   CodeCatalystECSUser
   ```

1. **[表示名]** で、自動的に生成された名前を保持します。

   ```
   CodeCatalystECSUser CodeCatalystECSUser
   ```

1. [**次へ**] を選択します。

1. **[グループにユーザーを追加]** ページで、**[次へ]** を選択します。

1. 「**ユーザーを確認と追加**」ページで情報を確認し、**[ユーザーを追加]** を選択します。

   **[ワンタイムパスワード]** ダイアログボックスが表示されます。

1.  AWS アクセスポータル URL やワンタイムパスワードなど、サインイン情報を **[コピー]** して貼り付けます。

1. [**閉じる**] を選択してください。

**アクセス権限セットを作成するには**

このアクセス許可セットは、後で `CodeCatalystECSUser` に割り当てられます。

1. ナビゲーションペインで [**アクセス許可セット**] を選択し、[**アクセス許可セットの作成**] を選択します。

1. **[事前定義されたアクセス許可セットのポリシー]** で **[AdministratorAccess]** を選択します。このポリシーではすべての AWS のサービスアクションに対するアクセス許可が与えられています。

1. [**次へ**] を選択します。

1. 「**アクセス許可セット名**」に、次のように入力します。

   ```
   CodeCatalystECSPermissionSet
   ```

1. [**次へ**] を選択します。

1. [**確認と作成**] ページで情報を確認し、[**グループの作成**] を選択します。

**アクセス許可セットを CodeCatalystECSUser に割り当てるには**

1. ナビゲーションペインで を選択し**AWS アカウント**、現在サインイン AWS アカウント している の横にあるチェックボックスをオンにします。

1. 「**ユーザーまたはグループを割り当て**」を選択します。

1. **[ユーザー]** タブを選択します。

1. [`CodeCatalystECSUser`] のチェックボックスをオンにします。

1. [**次へ**] を選択します。

1. [`CodeCatalystECSPermissionSet`] のチェックボックスをオンにします。

1. [**次へ**] を選択します。

1. 情報を確認し、[**送信**] を選択します。

   これで、 `CodeCatalystECSUser`と `CodeCatalystECSPermissionSet`を に割り当て AWS アカウント、それらをバインドしました。

**CodeCatalystECSUser としてサインアウトしてサインインし直すには**

1. サインアウトする前に、 AWS アクセスポータル URL と、 のユーザー名とワンタイムパスワードがあることを確認してください`CodeCatalystECSUser`。この情報は、事前にテキストエディタにコピーしておく必要があります。
**注記**  
この情報がない場合は、IAM アイデンティティセンターの `CodeCatalystECSUser` 詳細ページに移動し、**[パスワードをリセット]**、**[ワンタイムパスワードを生成 [...]]** を選択して、もう一度 **[パスワードをリセットする]** と、画面に情報が表示されます。

1. からサインアウトします AWS。

1.  AWS アクセスポータル URL をブラウザのアドレスバーに貼り付けます。

1. `CodeCatalystECSUser` のユーザー名とワンタイムパスワードを使用してサインインします。

1. **[新しいパスワード]** で、パスワードを入力し、**[新しいパスワードを設定]** を選択します。

   画面に **AWS アカウント** ボックスが表示されます。

1. を選択し**AWS アカウント**、`CodeCatalystECSUser`ユーザーとアクセス許可セット AWS アカウント を割り当てた の名前を選択します。

1. `CodeCatalystECSPermissionSet` の横にある [**管理コンソール**] を選択します。

    AWS マネジメントコンソール が表示されます。これで、適切なアクセス許可を使用し、`CodeCatalystECSUser` としてサインインしました。

**AWS CloudShell インスタンスを起動するには**

1. 上部のナビゲーションバー`CodeCatalystECSUser`で、 AWS アイコン () を選択します![\[AWS icon\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/deploy/aws-logo.png)。

   のメインページ AWS マネジメントコンソール が表示されます。

1. 上部のナビゲーションバーで、 AWS CloudShell アイコン () を選択します![\[CloudShell icon\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/deploy/CloudShell.png)。

   CloudShell が開きます。CloudShell 環境が作成されるまで待ちます。
**注記**  
CloudShell アイコンが表示されない場合は、[CloudShell でサポートされているリージョン](https://docs.aws.amazon.com/cloudshell/latest/userguide/faq-list.html#regions-available)にいることを確認してください。このチュートリアルは、米国西部 (オレゴン) リージョンにいることを前提としています。

**AWS CLI がインストールされていることを確認するには**

1. CloudShell ターミナルで、次のように入力します。

   ```
   aws --version
   ```

1. バージョンが表示されることを確認します。

    AWS CLI は現在のユーザー 用にすでに設定されているため`CodeCatalystECSUser`、通常どおり、 AWS CLI キーと認証情報を設定する必要はありません。

## ステップ 2: プレースホルダーアプリケーションを Amazon ECS にデプロイする
<a name="deploy-tut-ecs-placeholder"></a>

このセクションでは、プレースホルダーアプリケーションを Amazon ECS に手動でデプロイします。このプレースホルダーアプリケーションは、ワークフローによってデプロイされた Hello World アプリケーションに置き換えられます。プレースホルダーアプリケーションは Apache Web Server です。

Amazon ECS の詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」を参照してください。

プレースホルダーアプリケーションをデプロイするには、以下の一連の手順を実行します。<a name="deploy-tut-ecs-create-task-execution-role"></a>

**タスク実行のロールを作成するには**

このロールは、ユーザーに代わって API コールを行うアクセス AWS Fargate 許可を Amazon ECS に付与します。

1. 信頼ポリシーを作成します。

   1. で AWS CloudShell、次のコマンドを入力します。

      ```
      cat > codecatalyst-ecs-trust-policy.json
      ```

      CloudShell ターミナルに点滅するプロンプトが表示されます。

   1. プロンプトで、次のコードを入力します。

------
#### [ JSON ]

****  

      ```
      {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
          {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
              "Service": "ecs-tasks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
      ```

------

   1. 最後の角括弧 (`}`) の後にカーソルを置きます。

   1. **Enter** と **Ctrl\$1d** を押してファイルを保存し、終了します。

1. タスク実行ロールを作成する方法

   ```
   aws iam create-role \
         --role-name codecatalyst-ecs-task-execution-role \
         --assume-role-policy-document file://codecatalyst-ecs-trust-policy.json
   ```

1.  AWS 管理`AmazonECSTaskExecutionRolePolicy`ポリシーをロールにアタッチします。

   ```
   aws iam attach-role-policy \
         --role-name codecatalyst-ecs-task-execution-role \
         --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
   ```

1. ロールの詳細を表示します。

   ```
   aws iam get-role \
         --role-name codecatalyst-ecs-task-execution-role
   ```

1. ロールの `"Arn":` 値、例えば `arn:aws:iam::111122223333:role/codecatalyst-ecs-task-execution-role` を書き留めます。この Amazon リソースネーム (ARN) は後で必要になります。

**Amazon ECS クラスターを作成するには**

このクラスターには、Apache プレースホルダーアプリケーションと、それ以降は Hello World アプリケーションが含まれます。

1. として`CodeCatalystECSUser`、 で空のクラスター AWS CloudShellを作成します。

   ```
   aws ecs create-cluster --cluster-name codecatalyst-ecs-cluster
   ```

1. (オプション) クラスターが正常に作成されたことを確認します。

   ```
   aws ecs list-clusters
   ```

   `codecatalyst-ecs-cluster` クラスターの ARN が一覧表示され、正常に作成されたことを示します。

**新しいタスク定義ファイルを作成するには**

タスク定義ファイルは、DockerHub からプルされた [[Apache 2.4 Web サーバー]](https://hub.docker.com/_/httpd) Docker イメージ (`httpd:2.4`) を実行することを示します。

1. として`CodeCatalystECSUser`、 でタスク定義ファイル AWS CloudShellを作成します。

   ```
   cat > taskdef.json
   ```

1. コマンドプロンプトで、以下を貼り付けます。

   ```
   {
       "executionRoleArn": "arn:aws:iam::111122223333:role/codecatalyst-ecs-task-execution-role",
       "containerDefinitions": [
           {
               "name": "codecatalyst-ecs-container",
               "image": "httpd:2.4",
               "essential": true,
               "portMappings": [
                   {
                       "hostPort": 80,
                       "protocol": "tcp",
                       "containerPort": 80
                   }
               ]
           }
       ],
       "requiresCompatibilities": [
           "FARGATE"
       ],
       "cpu": "256",
       "family": "codecatalyst-ecs-task-def",
       "memory": "512",
       "networkMode": "awsvpc"
   }
   ```

   上記のコードで、*[arn:aws:iam::111122223333:role/codecatalyst-ecs-task-execution-role]* を置き換えます。

   [タスク実行のロールを作成するには](#deploy-tut-ecs-create-task-execution-role) でメモしたタスク実行ロールの ARN を使用します。

1. 最後の角括弧 (`}`) の後にカーソルを置きます。

1. **Enter** と **Ctrl\$1d** を押してファイルを保存し、終了します。

**Amazon ECS でタスク定義ファイルに登録します。**

1. として`CodeCatalystECSUser`、タスク定義 AWS CloudShellを登録します。

   ```
   aws ecs register-task-definition \
       --cli-input-json file://taskdef.json
   ```

1. (オプション) タスク定義が登録されていることを確認します。

   ```
   aws ecs list-task-definitions
   ```

   `codecatalyst-ecs-task-def` タスク定義が一覧表示されます。

**Amazon ECS サービスを作成するには**

Amazon ECS サービスは、Apache プレースホルダーアプリケーションのタスク (および関連する Docker コンテナ) を実行し、その後、Hello World アプリケーションを実行します。

1. `CodeCatalystECSUser` として、Amazon Elastic Container Service コンソールをまだ切り替えていない場合は、切り替えます。

1. 先ほど作成したクラスター「`codecatalyst-ecs-cluster`」を選択します。

1. **[サービス]** タブで、**[作成]** を選択します。

1. **[作成]** ページで、次のとおり設定します。

   1. 次に一覧表示されているものを除き、すべてのデフォルト設定を保持します。

   1. [**Launch type (起動タイプ)**] で、[**FARGATE**] を選択します。

   1. **[タスク定義]** の **[ファミリー]** ドロップダウンリストで、以下を選択します。

      `codecatalyst-ecs-task-def`

   1. **[サービス名]** に次のように入力します。

      ```
      codecatalyst-ecs-service
      ```

   1. **[必要なタスク]** に次のように入力します。

      ```
      3
      ```

      このチュートリアルでは、各タスクが単一の Docker コンテナを起動します。

   1. **[ネットワーク]** セクションを展開します。

   1. **[VPC]** で、任意の VPC を選択します。

   1. **[サブネット]** では、任意のサブネットを選択します。
**注記**  
サブネットは 1 つだけ指定します。このチュートリアルに必要なのはこれだけです。
**注記**  
VPC とサブネットがない場合は、作成します。「*Amazon VPC ユーザーガイド*」で、「[VPC を作成](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC)」、「[VPC にサブネットを作成](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#AddaSubnet)」を参照してください。

   1. **[セキュリティグループ]** で、**[新しいセキュリティグループを作成]** を選択し、次の操作を行います。

      1. **[セキュリティグループ名]** に次のように入力します。

         ```
         codecatalyst-ecs-security-group
         ```

      1. **[セキュリティグループの説明]** には、次のように入力します。

         ```
         CodeCatalyst ECS security group
         ```

      1. [**ルールを追加**] を選択してください。**[タイプ]** の場合は、**[HTTP]** を選択し、**[ソース]**の場合は **[任意の場所]** を選択します。

   1. 一番下で **[作成]** を選択します。

   1. サービスが作成されるまで待ちます。このプロセスには数分かかることがあります。

1. **[タスク]** タブを選択し、[更新] を選択します。3 つのタスクすべてで、**[前回のステータス]** 列が **[実行中]** に設定されていることを確認します。

**(オプション) Apache プレースホルダーアプリケーションが実行されていることを確認するには**

1. **[タスク]** タブで、3 つのタスクのいずれかを選択します。

1. **[パブリック IP]** フィールドで、**[オープンアドレス]** を選択します。

   `It Works!` ページが表示されます。これは、Amazon ECS サービスが Apache イメージで Docker コンテナを起動するタスクを正常に開始したことを示します。

   チュートリアルのこの時点で、Amazon ECS クラスター、サービス、タスク定義、および Apache プレースホルダーアプリケーションを手動でデプロイしました。これらの項目がすべて整ったら、Apache プレースホルダーアプリケーションをチュートリアルの Hello World アプリケーションに置き換えるワークフローを作成する準備が整いました。

## ステップ 1: Amazon ECR イメージリポジトリを作成する
<a name="deploy-tut-ecs-ecr"></a>

このセクションでは、Amazon Elastic Container Registry (Amazon ECR) にプライベートイメージリポジトリを作成します。このリポジトリには、以前にデプロイした Apache プレースホルダーイメージを置き換えるチュートリアルの Docker イメージが保存されます。

Amazon ECR の詳細については、*Amazon Elastic Container Registry User Guide* を参照してください。

**Amazon ECR にイメージリポジトリを作成するには**

1. として`CodeCatalystECSUser`、Amazon ECR に空のリポジトリ AWS CloudShellを作成します。

   ```
   aws ecr create-repository --repository-name codecatalyst-ecs-image-repo
   ```

1. Amazon ECR リポジトリの詳細を表示します。

   ```
   aws ecr describe-repositories \
         --repository-names codecatalyst-ecs-image-repo
   ```

1. `“repositoryUri”:` の値、例えば「`111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo`」を書き留めます。

   ワークフローにリポジトリを追加するときは、後にこれが必要となります。

## ステップ 4: AWS ロールを作成する
<a name="deploy-tut-ecs-build-deploy-roles"></a>

このセクションでは、CodeCatalyst ワークフローが機能するために必要な AWS IAM ロールを作成します。これらのロールは次のとおりです。
+ **ビルドロール** – CodeCatalyst ビルドアクション (ワークフロー内) に AWS 、アカウントにアクセスして Amazon ECR と Amazon EC2 に書き込むアクセス許可を付与します。
+ **ロールのデプロイ** – CodeCatalyst **Deploy to ECS** アクション (ワークフロー内) に、 AWS アカウント、Amazon ECS、およびその他のいくつかの AWS サービスにアクセスするためのアクセス許可を付与します。

IAM ロールの詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)」を参照してください。

**注記**  
時間を節約するため、前に一覧表示した 2 つのロールではなく、`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールと呼ばれる 1 つのロールを作成できます。詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールには、セキュリティリスクをもたらす可能性のある非常に広範なアクセス許可があることを理解します。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。このチュートリアルでは、前述の 2 つのロールを作成することを前提としています。

ビルドロールとデプロイロールを作成するには、 AWS マネジメントコンソール または を使用できます AWS CLI。

------
#### [ AWS マネジメントコンソール ]

ビルドロールとデプロイロールを作成するには、以下の一連の手順を実行します。

**ビルドロールを作成するには**

1. ロールのポリシーを以下の手順で作成します。

   1. にサインインします AWS。

   1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

   1. ナビゲーションペインで、**ポリシー** を選択してください。

   1. **[Create policy]** (ポリシーを作成) を選択します。

   1. **JSON** タブを選択します。

   1. 既存のコードを削除します。

   1. 次のコードを貼り付けます。

------
#### [ JSON ]

****  

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": [
                      "ecr:*",
                      "ec2:*"
                  ],
                  "Resource": "*"
              }
          ]
      }
      ```

------
**注記**  
ロールがワークフローアクションの実行に初めて使用されるときは、リソースポリシーステートメントでワイルドカードを使用し、利用可能になった後にリソース名でポリシーの範囲を絞り込みます。  

      ```
      "Resource": "*"
      ```

   1. [**Next: Tags (次へ: タグ)**] を選択します。

   1. **[次へ: レビュー]** を選択します。

   1. **[名前]** に次のように入力します。

      ```
      codecatalyst-ecs-build-policy
      ```

   1. [**Create policy**] (ポリシーの作成) を選択します。

      これで、アクセス許可ポリシーが作成されました。

1. 次のようにビルドロールを作成します。

   1. ナビゲーションペインで **ロール** を選択してから、**ロールを作成する** を選択します。

   1. **[カスタム信頼ポリシー]** を選択します。

   1. 既存のカスタム信頼ポリシーを削除します。

   1. 次の信頼ポリシーを追加します。

   1. [**次へ**] を選択します。

   1. **[アクセス許可ポリシー]** で `codecatalyst-ecs-build-policy` を検索し、チェックボックスを選択します。

   1. [**次へ**] を選択します。

   1. **[ロール名]** には、次のように入力します。

      ```
      codecatalyst-ecs-build-role
      ```

   1. **[ロールの説明]** には、次のように入力します。

      ```
      CodeCatalyst ECS build role
      ```

   1. [**ロールの作成**] を選択してください。

   これで、アクセス許可ポリシーと信頼ポリシーを持つビルドロールが作成されました。

1. 次のようにビルドロール ARN を取得します。

   1. ナビゲーションペインで **Roles (ロール) ** を選択してください。

   1. 検索ボックスに、作成したロールの名前 (`codecatalyst-ecs-build-role`) を入力します。

   1. 使用するロールを一覧から選択します。

      ロールの **[概要]** ページが表示されます。

   1. 上部で、**[ARN]** 値をコピーします。これは後で必要になります。

**デプロイロールを作成するには**

1. ロールのポリシーを以下の手順で作成します。

   1. にサインインします AWS。

   1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

   1. ナビゲーションペインで、**ポリシー** を選択してください。

   1. **[ポリシーを作成]** を選択します。

   1. **JSON** タブを選択します。

   1. 既存のコードを削除します。

   1. 次のコードを貼り付けます。

------
#### [ JSON ]

****  

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [{
          "Action":[
            "ecs:DescribeServices",
            "ecs:CreateTaskSet",
            "ecs:DeleteTaskSet",
            "ecs:ListClusters",
            "ecs:RegisterTaskDefinition",
            "ecs:UpdateServicePrimaryTaskSet",
            "ecs:UpdateService",
            "elasticloadbalancing:DescribeTargetGroups",
            "elasticloadbalancing:DescribeListeners",
            "elasticloadbalancing:ModifyListener",
            "elasticloadbalancing:DescribeRules",
            "elasticloadbalancing:ModifyRule",
            "lambda:InvokeFunction",
            "lambda:ListFunctions",
            "cloudwatch:DescribeAlarms",
            "sns:Publish",
            "sns:ListTopics", 
            "s3:GetObject",
            "s3:GetObjectVersion",
            "codedeploy:CreateApplication", 
            "codedeploy:CreateDeployment", 
            "codedeploy:CreateDeploymentGroup", 
            "codedeploy:GetApplication", 
            "codedeploy:GetDeployment", 
            "codedeploy:GetDeploymentGroup", 
            "codedeploy:ListApplications", 
            "codedeploy:ListDeploymentGroups", 
            "codedeploy:ListDeployments", 
            "codedeploy:StopDeployment", 
            "codedeploy:GetDeploymentTarget", 
            "codedeploy:ListDeploymentTargets", 
            "codedeploy:GetDeploymentConfig", 
            "codedeploy:GetApplicationRevision", 
            "codedeploy:RegisterApplicationRevision", 
            "codedeploy:BatchGetApplicationRevisions", 
            "codedeploy:BatchGetDeploymentGroups", 
            "codedeploy:BatchGetDeployments", 
            "codedeploy:BatchGetApplications", 
            "codedeploy:ListApplicationRevisions", 
            "codedeploy:ListDeploymentConfigs", 
            "codedeploy:ContinueDeployment"           
         ],
         "Resource":"*",
         "Effect":"Allow"
      },{"Action":[
            "iam:PassRole"
         ],
         "Effect":"Allow",
         "Resource":"*",
         "Condition":{"StringLike":{"iam:PassedToService":[
                  "ecs-tasks.amazonaws.com",
                  "codedeploy.amazonaws.com"
               ]
            }
         }
      }]
      }
      ```

------
**注記**  
ロールがワークフローアクションの実行に初めて使用されるときは、リソースポリシーステートメントでワイルドカードを使用します。その後、リソース名を使用してポリシーをスコープダウンできます。  

      ```
      "Resource": "*"
      ```

   1. [**Next: Tags (次へ: タグ)**] を選択します。

   1. **[次へ: レビュー]** を選択します。

   1. **[名前]** に次のように入力します。

      ```
      codecatalyst-ecs-deploy-policy
      ```

   1. [**Create policy**] (ポリシーの作成) を選択します。

      これで、アクセス許可ポリシーが作成されました。

1. 次のようにデプロイロールを作成します。

   1. ナビゲーションペインで **ロール** を選択してから、**ロールを作成する** を選択します。

   1. **[カスタム信頼ポリシー]** を選択します。

   1. 既存のカスタム信頼ポリシーを削除します。

   1. 次の信頼ポリシーを追加します。

   1. [**次へ**] を選択します。

   1. **[アクセス許可ポリシー]** で `codecatalyst-ecs-deploy-policy` を検索し、チェックボックスを選択します。

   1. [**次へ**] を選択します。

   1. **[ロール名]** には、次のように入力します。

      ```
      codecatalyst-ecs-deploy-role
      ```

   1. **[ロールの説明]** には、次のように入力します。

      ```
      CodeCatalyst ECS deploy role
      ```

   1. [**ロールの作成**] を選択してください。

   これで、信頼ポリシーを使用してデプロイロールが作成されました。

1. デプロイロール ARN を次のように取得します。

   1. ナビゲーションペインで **Roles (ロール) ** を選択してください。

   1. 検索ボックスに、作成したロールの名前 (`codecatalyst-ecs-deploy-role`) を入力します。

   1. 使用するロールを一覧から選択します。

      ロールの **[概要]** ページが表示されます。

   1. 上部で、**[ARN]** 値をコピーします。これは後で必要になります。

------
#### [ AWS CLI ]

ビルドロールとデプロイロールを作成するには、以下の一連の手順を実行します。

**両方のロールの信頼ポリシーを作成するには**

として`CodeCatalystECSUser`、信頼ポリシーファイル AWS CloudShellを作成します。

1. ファイルを作成します。

   ```
   cat > codecatalyst-ecs-trust-policy.json
   ```

1. ターミナルプロンプトで、次のコードを貼り付けます。

1. 最後の角括弧 (`}`) の後にカーソルを置きます。

1. **Enter** と **Ctrl\$1d** を押してファイルを保存し、終了します。

**ビルドポリシーとビルドロールを作成するには**

1. ビルドポリシーを作成します。

   1. として`CodeCatalystECSUser`、 でビルドポリシーファイル AWS CloudShellを作成します。

      ```
      cat > codecatalyst-ecs-build-policy.json
      ```

   1. プロンプトで、次のようにコード入力します。

------
#### [ JSON ]

****  

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": [
                      "ecr:*",
                      "ec2:*"
                  ],
                  "Resource": "*"
              }
          ]
      }
      ```

------

   1. 最後の角括弧 (`}`) の後にカーソルを置きます。

   1. **Enter** と **Ctrl\$1d** を押してファイルを保存し、終了します。

1. ビルドポリシーを以下に追加します AWS。

   ```
   aws iam create-policy \
       --policy-name codecatalyst-ecs-build-policy \
       --policy-document file://codecatalyst-ecs-build-policy.json
   ```

1. コマンド出力で、例えば「`arn:aws:iam::111122223333:policy/codecatalyst-ecs-build-policy`」などの `"arn":` 値を書き留めます。この ARN は後で必要になります。

1. ビルドロールーを作成して信頼ポリシーにアタッチします。

   ```
   aws iam create-role \
         --role-name codecatalyst-ecs-build-role \
         --assume-role-policy-document file://codecatalyst-ecs-trust-policy.json
   ```

1. ビルドポリシーをビルドロールにアタッチします。

   ```
   aws iam attach-role-policy \
         --role-name codecatalyst-ecs-build-role \
         --policy-arn arn:aws:iam::111122223333:policy/codecatalyst-ecs-build-policy
   ```

   *[arn:aws:iam::111122223333:policy/codecatalyst-ecs-build-policy]* が、先ほど説明したビルドポリシーの ARN に置き換えられます。

1. ビルドロールの詳細を表示します。

   ```
   aws iam get-role \
         --role-name codecatalyst-ecs-build-role
   ```

1. ロールの `"Arn":` 値、例えば `arn:aws:iam::111122223333:role/codecatalyst-ecs-build-role` を書き留めます。この ARN は後で必要になります。

**デプロイポリシーとデプロイロールを作成するには**

1. デプロイポリシーを作成します。

   1. で AWS CloudShell、デプロイポリシーファイルを作成します。

      ```
      cat > codecatalyst-ecs-deploy-policy.json
      ```

   1. プロンプトで、次のようにコード入力します。

------
#### [ JSON ]

****  

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [{
          "Action":[
            "ecs:DescribeServices",
            "ecs:CreateTaskSet",
            "ecs:DeleteTaskSet",
            "ecs:ListClusters",
            "ecs:RegisterTaskDefinition",
            "ecs:UpdateServicePrimaryTaskSet",
            "ecs:UpdateService",
            "elasticloadbalancing:DescribeTargetGroups",
            "elasticloadbalancing:DescribeListeners",
            "elasticloadbalancing:ModifyListener",
            "elasticloadbalancing:DescribeRules",
            "elasticloadbalancing:ModifyRule",
            "lambda:InvokeFunction",
            "lambda:ListFunctions",
            "cloudwatch:DescribeAlarms",
            "sns:Publish",
            "sns:ListTopics", 
            "s3:GetObject",
            "s3:GetObjectVersion",
            "codedeploy:CreateApplication", 
            "codedeploy:CreateDeployment", 
            "codedeploy:CreateDeploymentGroup", 
            "codedeploy:GetApplication", 
            "codedeploy:GetDeployment", 
            "codedeploy:GetDeploymentGroup", 
            "codedeploy:ListApplications", 
            "codedeploy:ListDeploymentGroups", 
            "codedeploy:ListDeployments", 
            "codedeploy:StopDeployment", 
            "codedeploy:GetDeploymentTarget", 
            "codedeploy:ListDeploymentTargets", 
            "codedeploy:GetDeploymentConfig", 
            "codedeploy:GetApplicationRevision", 
            "codedeploy:RegisterApplicationRevision", 
            "codedeploy:BatchGetApplicationRevisions", 
            "codedeploy:BatchGetDeploymentGroups", 
            "codedeploy:BatchGetDeployments", 
            "codedeploy:BatchGetApplications", 
            "codedeploy:ListApplicationRevisions", 
            "codedeploy:ListDeploymentConfigs", 
            "codedeploy:ContinueDeployment"           
         ],
         "Resource":"*",
         "Effect":"Allow"
      },{"Action":[
            "iam:PassRole"
         ],
         "Effect":"Allow",
         "Resource":"*",
         "Condition":{"StringLike":{"iam:PassedToService":[
                  "ecs-tasks.amazonaws.com",
                  "codedeploy.amazonaws.com"
               ]
            }
         }
      }]
      }
      ```

------
**注記**  
ロールがワークフローアクションの実行に初めて使用されるときは、リソースポリシーステートメントでワイルドカードを使用し、利用可能になった後にリソース名でポリシーの範囲を絞り込みます。  

      ```
      "Resource": "*"
      ```

   1. 最後の角括弧 (`}`) の後にカーソルを置きます。

   1. **Enter** と **Ctrl\$1d** を押してファイルを保存し、終了します。

1. デプロイポリシーを以下に追加します AWS。

   ```
   aws iam create-policy \
       --policy-name codecatalyst-ecs-deploy-policy \
       --policy-document file://codecatalyst-ecs-deploy-policy.json
   ```

1. コマンド出力で、例えば「`arn:aws:iam::111122223333:policy/codecatalyst-ecs-deploy-policy`」などのデプロイポリシーの `"arn":` 値を書き留めます。この ARN は後で必要になります。

1. デプロイロールを作成して信頼ポリシーをデプロイロールにアタッチします。

   ```
   aws iam create-role \
         --role-name codecatalyst-ecs-deploy-role \
         --assume-role-policy-document file://codecatalyst-ecs-trust-policy.json
   ```

1. デプロイポリシーをデプロイロールにアタッチします。ここで、*[arn:aws:iam::111122223333:policy/codecatalyst-ecs-deploy-policy]* は、前述のデプロイポリシーの ARN に置き換えられます。

   ```
   aws iam attach-role-policy \
         --role-name codecatalyst-ecs-deploy-role \
         --policy-arn arn:aws:iam::111122223333:policy/codecatalyst-ecs-deploy-policy
   ```

1. デプロイロールの詳細を表示します。

   ```
   aws iam get-role \
         --role-name codecatalyst-ecs-deploy-role
   ```

1. ロールの `"Arn":` の値、例えば「`arn:aws:iam::111122223333:role/codecatalyst-ecs-deploy-role`」を書き留めます。この ARN は後で必要になります。

------

## ステップ 5: CodeCatalyst に AWS ロールを追加する
<a name="deploy-tut-ecs-import-roles"></a>

このステップでは、ビルドロール (`codecatalyst-ecs-build-role`) を追加し、スペース内の CodeCatalyst アカウント接続にロール (`codecatalyst-ecs-deploy-role`) をデプロイします。

**ビルドロールとデプロイロールをアカウント接続に追加するには**

1. CodeCatalyst で、スペースに移動します。

1. **[AWS アカウント]** を選択します。アカウント接続が一覧表示されます。

1. ビルドロールとデプロイロールを作成したアカウントを表す AWS アカウント接続を選択します。

1. ** AWS 管理コンソールからロールの管理**を選択します。

   **[Amazon CodeCatalyst スペースに IAM ロールの追加]** ページが表示されます。ページにアクセスするには、サインインが必要な場合があります。

1. **[IAM で作成した既存のロールを追加]** を選択します。

   ドロップダウンリストが表示されます。この一覧表示には、`codecatalyst-runner.amazonaws.com` および `codecatalyst.amazonaws.com` サービスプリンシパルを含む信頼ポリシーを持つすべての IAM ロールが表示されます。

1. ドロップダウンリストで [`codecatalyst-ecs-build-role`] を選択し、**[ロールを追加]** を選択します。
**注記**  
`The security token included in the request is invalid` が表示された場合は、適切なアクセス許可がない可能性があります。この問題を修正するには、 からサインアウト AWS して、CodeCatalyst スペースの作成時に使用した AWS アカウントでサインインし直します。

1. **[IAM ロールを追加]** を選択し、**[IAM で作成した既存のロールを追加]** を選択し、ドロップダウンリストから [`codecatalyst-ecs-deploy-role`] を選択します。[**Add role**] を選択します。

   これで、ビルドロールとデプロイロールをスペースに追加しました。

1. **[Amazon CodeCatalyst 表示名]** の値をコピーします。この値は、ワークフローを作成するときに後で必要になります。

## ステップ 6: ソースレポジトリを作成する
<a name="deploy-tut-ecs-source-repo"></a>

このステップでは、CodeCatalyst に空のソースリポジトリを作成します。このリポジトリには、タスク定義ファイルなどのチュートリアルのソースファイルが保存されます。

ソースリポジトリの詳細については、「[ソースリポジトリを作成する](source-repositories-create.md)」を参照してください。

**ソースリポジトリを作成するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクト「`codecatalyst-ecs-project`」に移動します。

1. ナビゲーションペインで **[コード]** を選択してから、**[ソースリポジトリ]** を選択します。

1. **[リポジトリの追加]** を選択し、**[リポジトリの作成]** を選択します。

1. **[リポジトリ名]** に次のように入力します。

   ```
   codecatalyst-ecs-source-repository
   ```

1. **[作成]** を選択します。

## ステップ 7: ソースファイルを追加する
<a name="deploy-tut-ecs-source-files"></a>

このセクションでは、Hello World ソースファイルを CodeCatalyst リポジトリ「`codecatalyst-ecs-source-repository`」 に追加します。これらは以下で構成されます。
+ `index.html` ファイル - ブラウザに Hello World メッセージを表示します。
+ Dockerfile – Docker イメージに使用するベースイメージと、それに適用する Docker コマンドについて説明します。
+ `taskdef.json` ファイル - クラスターでタスクを起動するときに使用する Docker イメージを定義します。

フォルダは次のような構造になっています。

```
.
|— public-html
|  |— index.html
|— Dockerfile
|— taskdef.json
```

**注記**  
次の手順では、CodeCatalyst コンソールを使用してファイルを追加する方法を示しますが、必要に応じて Git を使用できます。詳細については、「[ソースリポジトリのクローンを作成する](source-repositories-clone.md)」を参照してください。

**Topics**
+ [index.html](#deploy-tut-ecs-source-files-index)
+ [Dockerfile](#deploy-tut-ecs-source-files-dockerfile)
+ [taskdef.json](#deploy-tut-ecs-source-files-taskdef)

### index.html
<a name="deploy-tut-ecs-source-files-index"></a>

`index.html` ファイルには、ブラウザに Hello World メッセージが表示されます。

**index.html ファイルを追加するには**

1. CodeCatalyst コンソールで、ソースリポジトリ「`codecatalyst-ecs-source-repository`」に移動します。

1. **[ファイル]** で、**[ファイルを作成]** を選択します。

1. **[ファイル名]** に次のように入力します。

   ```
   public-html/index.html
   ```
**重要**  
同じ名前のフォルダを作成するには、必ず `public-html/` プレフィックスを含めてください。`index.html` は、このフォルダにあることが期待されます。

1. テキストボックスに次のコードを入力します。

   ```
   <html>
     <head>
       <title>Hello World</title>
       <style>
         body {
         background-color: black;
         text-align: center;
         color: white;
         font-family: Arial, Helvetica, sans-serif;
         }  
       </style>
     </head>
     <body>
       <h1>Hello World</h1>
     </body>
   </html>
   ```

1. **[コミット]** を選択し、再度 **[コミット]** を選択します。

   `index.html` は、`public-html` フォルダ内のリポジトリに追加されます。

### Dockerfile
<a name="deploy-tut-ecs-source-files-dockerfile"></a>

Dockerfile は、使用するベース Docker イメージと、それに適用する Docker コマンドについて説明します。Dockerfile の詳細については、「[Dockerfile リファレンス](https://docs.docker.com/engine/reference/builder/)」を参照してください。

ここで指定された Dockerfile は、Apache 2.4 ベースイメージ (`httpd`) を使用することを示します。また、ウェブページを提供する Apache サーバーのフォルダに「`index.html`」というソースファイルをコピーする手順も含まれています。Dockerfile の `EXPOSE` 命令は、コンテナがポート 80 でリッスンしていることを Docker に伝えます。

**Dockerfile を追加するには**

1. ソースリポジトリで、**[ファイルを作成]** を選択します。

1. **[ファイル名]** には、次のように入力します。

   ```
   Dockerfile
   ```

   ファイル名に拡張子は含めないでください。
**重要**  
Dockerfile はリポジトリのルートフォルダに存在する必要があります。ワークフローの `Docker build` コマンドは、ワークフローが存在することを期待します。

1. テキストボックスに次のコードを入力します。

   ```
   FROM httpd:2.4
   COPY ./public-html/index.html /usr/local/apache2/htdocs/index.html
   EXPOSE 80
   ```

1. **[コミット]** を選択し、再度 **[コミット]** を選択します。

   Dockerfile がリポジトリに追加されます。

### taskdef.json
<a name="deploy-tut-ecs-source-files-taskdef"></a>

このステップで追加した `taskdef.json` ファイルは、[ステップ 2: プレースホルダーアプリケーションを Amazon ECS にデプロイする](#deploy-tut-ecs-placeholder) で既に指定したファイルと同じですが、次の違いがあります。

`image:` フィールド (`httpd:2.4`) でハードコードされた Docker イメージ名を指定する代わりに、ここでのタスク定義は、イメージ「`$REPOSITORY_URI`」と「`$IMAGE_TAG`」を示すためにいくつかの変数を使用します。これらの変数は、後のステップでワークフローを実行するときに、ワークフローのビルドアクションによって生成された実際の値に置き換えられます。

タスク定義パラメータに関する詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[タスク定義パラメータ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html)」を参照してください。

**taskdef.json ファイルを追加するには**

1. ソースリポジトリで、**[ファイルを作成]** を選択します。

1. **[ファイル名]** には、次のように入力します。

   ```
   taskdef.json
   ```

1. テキストボックスに次のコードを入力します。

   ```
   {
       "executionRoleArn": "arn:aws:iam::account_ID:role/codecatalyst-ecs-task-execution-role",
       "containerDefinitions": [
           {
               "name": "codecatalyst-ecs-container",
               # The $REPOSITORY_URI and $IMAGE_TAG variables will be replaced 
               # by the workflow at build time (see the build action in the 
               # workflow)
               "image": $REPOSITORY_URI:$IMAGE_TAG,
               "essential": true,
               "portMappings": [
                   {
                       "hostPort": 80,
                       "protocol": "tcp",
                       "containerPort": 80
                   }
               ]
           }
       ],
       "requiresCompatibilities": [
           "FARGATE"
       ],
       "networkMode": "awsvpc",
       "cpu": "256",
       "memory": "512",
       "family": "codecatalyst-ecs-task-def"
   }
   ```

   上記のコードで置き換えます。

   *arn:aws:iam::account\$1ID:role/codecatalyst-ecs-task-execution-role*

   [タスク実行のロールを作成するには](#deploy-tut-ecs-create-task-execution-role) でメモしたタスク実行ロールの ARN を使用します。

1. **[コミット]** を選択し、再度 **[コミット]** を選択します。

   `taskdef.json` ファイルをリポジトリに追加します。

## ステップ 8: ワークフローを作成して実行する
<a name="deploy-tut-ecs-workflow"></a>

このステップでは、ソースファイルを取得し、Docker イメージにビルドし、そのイメージを Amazon ECS クラスターにデプロイするワークフローを作成します。このデプロイは、既存の Apache プレースホルダーアプリケーションを置き換えます。

ワークフローは、連続して実行される次の構成要素で構成されます。
+ トリガー – このトリガーは、ソースリポジトリに変更をプッシュすると、ワークフローを自動的に開始します。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。
+ ビルドアクション (`BuildBackend`) – トリガー時に、アクションは Dockerfile を使用して Docker イメージをビルドし、そのイメージを Amazon ECR にプッシュします。ビルドアクションは、`taskdef.json` を正しい `image` フィールド値で更新し、このファイルの出力アーティファクトを作成します。このアーティファクトは、次のデプロイアクションの入力として使用されます。

  ビルドアクションの詳細については、「[ワークフローを使用したビルド](build-workflow-actions.md)」を参照してください。
+ デプロイアクション (`DeployToECS`) – ビルドアクションが完了すると、デプロイアクションはビルドアクション (`TaskDefArtifact`) によって生成された出力アーティファクトを検索し、その内部の `taskdef.json` を見つけて Amazon ECS サービスに登録します。その後、サービスは `taskdef.json` ファイルの指示に従って、Amazon ECS クラスター内で 3 つの Amazon ECS タスク、および関連付けられた Hello World Docker コンテナを実行します。

**ワークフローを作成するには**

1. CodeCatalyst コンソールのナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. **[ワークフローを作成]** を選択します。

1. **[ソースリポジトリ]** で、`codecatalyst-ecs-source-repository` を選択します。

1. **[ブランチ]** で、`main` を選択します。

1. **[作成]** を選択します。

1. YAML サンプルコードを削除します。

1. 次の YAML コードを追加します。
**注記**  
次の YAML コードでは、必要に応じて `Connections:` セクションを省略できます。このセクションを省略する場合は、環境の **[デフォルト IAM ロール]** フィールドで指定されたロールに、[ステップ 5: CodeCatalyst に AWS ロールを追加する](#deploy-tut-ecs-import-roles) で記述されている両方のロールのアクセス許可と信頼ポリシーが含まれていることを確認する必要があります。デフォルトの IAM ロールを使用して環境を設定する方法の詳細については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

   ```
   Name: codecatalyst-ecs-workflow
   SchemaVersion: 1.0
   
   Triggers:
     - Type: PUSH
       Branches:
         - main
   Actions:
     BuildBackend:
       Identifier: aws/build@v1
       Environment:
         Name: codecatalyst-ecs-environment
         Connections:
           - Name: codecatalyst-account-connection
             Role: codecatalyst-ecs-build-role
       Inputs:
         Sources:
           - WorkflowSource
         Variables:
           - Name: REPOSITORY_URI
             Value: 111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo
           - Name: IMAGE_TAG
             Value: ${WorkflowSource.CommitId}
       Configuration:
         Steps:
           #pre_build:
           - Run: echo Logging in to Amazon ECR...
           - Run: aws --version
           - Run: aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-west-2.amazonaws.com
           #build:
           - Run: echo Build started on `date`
           - Run: echo Building the Docker image...
           - Run: docker build -t $REPOSITORY_URI:latest .
           - Run: docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
           #post_build:
           - Run: echo Build completed on `date`
           - Run: echo Pushing the Docker images...
           - Run: docker push $REPOSITORY_URI:latest
           - Run: docker push $REPOSITORY_URI:$IMAGE_TAG
           # Replace the variables in taskdef.json
           - Run: find taskdef.json -type f | xargs sed -i "s|\$REPOSITORY_URI|$REPOSITORY_URI|g"
           - Run: find taskdef.json -type f | xargs sed -i "s|\$IMAGE_TAG|$IMAGE_TAG|g"
           - Run: cat taskdef.json
           # The output artifact will be a zip file that contains a task definition file.
       Outputs:
         Artifacts:
           - Name: TaskDefArtifact
             Files: 
               - taskdef.json
     DeployToECS:
       DependsOn: 
         - BuildBackend
       Identifier: aws/ecs-deploy@v1
       Environment:
         Name: codecatalyst-ecs-environment
         Connections:
           - Name: codecatalyst-account-connection
             Role: codecatalyst-ecs-deploy-role
       Inputs:
         Sources: []
         Artifacts:
           - TaskDefArtifact
       Configuration:
         region: us-west-2
         cluster: codecatalyst-ecs-cluster
         service: codecatalyst-ecs-service
         task-definition: taskdef.json
   ```

   上記のコードで置き換えます。
   + [前提条件](#deploy-tut-ecs-prereqs) で作成された環境名を持つ *[codecatalyst-ecs-environment]* の両方のインスタンス。
   + アカウント接続の表示名を持つ *codecatalyst-account-connection* の両方のインスタンス。表示名は数値である場合があります。詳細については、「[ステップ 5: CodeCatalyst に AWS ロールを追加する](#deploy-tut-ecs-import-roles)」を参照してください。
   + [ステップ 4: AWS ロールを作成する](#deploy-tut-ecs-build-deploy-roles) で作成したビルドロールの名前を持つ *[codecatalyst-ecs-build-role]*。
   + [ステップ 1: Amazon ECR イメージリポジトリを作成する](#deploy-tut-ecs-ecr) で作成された Amazon ECR リポジトリの URI を持つ *[111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo]* (`Value:` プロパティ内)。
   + *[111122223333.dkr.ecr.us-west-2.amazonaws.com]* (`Run: aws ecr` コマンド内) と、イメージサフィックス (`/codecatalyst-ecs-image-repo`) のない Amazon ECR リポジトリの URI。
   + [ステップ 4: AWS ロールを作成する](#deploy-tut-ecs-build-deploy-roles) で作成したデプロイロールの名前を持つ *[codecatalyst-ecs-deploy-role]*。
   +  AWS リージョンコードを含む *us-west-2* の両方のインスタンス。リージョンコードの一覧については、「*AWS 全般のリファレンス*」の「[Regional endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints)」を参照してください。
**注記**  
ビルドロールとデプロイロールを作成しない場合は、*[codecatalyst-ecs-build-role]* と *[codecatalyst-ecs-deploy-role]* を `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールの名前に置き換えます。このロールの詳細については、「[ステップ 4: AWS ロールを作成する](#deploy-tut-ecs-build-deploy-roles)」を参照してください。
**ヒント**  
前のワークフローコードに示されている `find` および `sed` コマンドを使用してリポジトリとイメージ名を更新する代わりに、この目的のために **[Render Amazon ECS タスク定義]** アクションを使用できます。詳細については、「[Amazon ECS タスク定義の変更](render-ecs-action.md)」を参照してください。

1. (オプション) **[検証]** を選択して、コミットする前に YAML コードが有効であることを確認します。

1. **[コミット]** を選択します。

1. **[コミットワークフロー]** ダイアログボックスで、次のように入力します。

   1. **[コミットメッセージ]** の場合、テキストを削除して次のように入力します。

      ```
      Add first workflow
      ```

   1. **[レポジトリ]** に `codecatalyst-ecs-source-repository` を選択します。

   1. **[ブランチ名]** で、main を選択します。

   1. **[コミット]** を選択します。

   これでワークフローが作成されました。ワークフローの先頭で定義されているトリガーにより、ワークフローの実行が自動的に開始されます。具体的には、`workflow.yaml` ファイルをソースリポジトリにコミット (およびプッシュ) すると、トリガーによってワークフローの実行が開始します。

**ワークフロー実行の進行状況を表示するには**

1. CodeCatalyst コンソールのナビゲーションペインで、**[CI/CD]** を選択し、**[ワークフロー]** を選択します。

1. 先ほど作成したワークフロー「`codecatalyst-ecs-workflow`」を選択します。

1. **[BuildBackend]** を選択すると、ビルドの進行状況が表示されます。

1. **[DeployToECS]** を選択してデプロイの進行状況を確認します。

   実行の詳細を表示する方法については、「[ワークフロー実行のステータスと詳細の表示](workflows-view-run.md)」を参照してください。

**デプロイを確認するには**

1. Amazon ECS クラシックコンソール ([https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/)) を開きます。

1. `codecatalyst-ecs-cluster` でクラスターを選択します。

1. [**タスク**] タブを選択します。

1. 3 つのタスクのいずれかを選択します。

1. **[パブリック IP]** フィールドで、**[オープンアドレス]** を選択します。

   ブラウザに「Hello World」ページが表示され、Amazon ECS サービスがアプリケーションを正常にデプロイしたことを示します。

## ステップ 9: ソースファイルを変更する
<a name="deploy-tut-ecs-change"></a>

このセクションでは、ソースリポジトリ内の `index.html` ファイルを変更します。この変更により、ワークフローは新しい Docker イメージをビルドし、コミット ID でタグ付けして Amazon ECR にプッシュし、Amazon ECS にデプロイします。

**index.html を変更するには**

1. CodeCatalyst コンソールのナビゲーションペインで、**[コード]** を選択し、**[ソースリポジトリ]** を選択し、リポジトリ「`codecatalyst-ecs-source-repository`」を選択します。

1. [`public-html`] を選択し、[`index.html`] を選択します。

   `index.html` の内容が表示されます。

1. **[編集]** を選択します。

1. 行 14 で、`Hello World` テキストを `Tutorial complete!` に変更します。

1. **[コミット]** を選択し、再度 **[コミット]** を選択します。

   コミットにより、新しいワークフローの実行が開始します。

1. (オプション) ソースリポジトリのメインページに移動し、**[コミットを表示]** を選択し、`index.html` 変更のコミット ID を書き留めます。

1. デプロイの進行状況を確認します。

   1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

   1. `codecatalyst-ecs-workflow` を選択して最新の実行を表示します。

   1. **BuildBackend**、および **DeployToECS** を選択して、ワークフローの実行の進行状況を確認します。

1. 次のように、アプリケーションが更新されていることを確認します。

   1. Amazon ECS クラシックコンソール ([https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/)) を開きます。

   1. `codecatalyst-ecs-cluster` でクラスターを選択します。

   1. [**タスク**] タブを選択します。

   1. 3 つのタスクのいずれかを選択します。

   1. **[パブリック IP]** フィールドで、**[オープンアドレス]** を選択します。

      `Tutorial complete!` ページが表示されます。

1. (オプション) で AWS、Amazon ECR コンソールに切り替え、新しい Docker イメージにステップ 6 のコミット ID がタグ付けされていることを確認します。

## クリーンアップ
<a name="deploy-tut-ecs-cleanup"></a>

このチュートリアルで使用されているファイルとサービスをクリーンアップして、料金が発生しないようにします。

で AWS マネジメントコンソール、次の順序でクリーンアップします。

1. Amazon ECS で、以下を実行します。

   1. `codecatalyst-ecs-service` を削除します。

   1. `codecatalyst-ecs-cluster` を削除します。

   1. `codecatalyst-ecs-task-definition` の登録を解除します。

1. Amazon ECR で、`codecatalyst-ecs-image-repo` を削除します。

1. Amazon EC2 で、`codecatalyst-ecs-security-group` を削除します。

1. IAM アイデンティティセンターで削除します。

   1. `CodeCatalystECSUser`

   1. `CodeCatalystECSPermissionSet`

CodeCatalyst コンソールで、次のようにクリーンアップします。

1. `codecatalyst-ecs-workflow` を削除します。

1. `codecatalyst-ecs-environment` を削除します。

1. `codecatalyst-ecs-source-repository` を削除します。

1. `codecatalyst-ecs-project` を削除します。

このチュートリアルでは、CodeCatalyst ワークフローと Amazon ECS へのデプロイアクションを使用してアプリケーションを **[Amazon ECS サービスにデプロイ]** する方法について説明します。

# 「Amazon ECS にデプロイ」アクションの追加
<a name="deploy-action-ecs-adding"></a>

次の手順を使用して、**[Amazon ECS にデプロイ]** アクションをワークフローに追加します。

------
#### [ Visual ]

**ビジュアルエディタを使用して「Amazon ECS にデプロイ」アクションを追加するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[ビジュアル]** を選択します。

1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。

1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。

1. **[Amazon ECS にデプロイ]** アクションを検索し、次のいずれかを実行します。
   + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。

     または
   + **[Amazon ECS にデプロイ]** を選択します。[アクションの詳細] ダイアログボックスが表示されます。このダイアログボックスでは、次の操作を行います。
     + (オプション) **[ダウンロード]** を選択して、[アクションのソースコードを表示](workflows-view-source.md#workflows-view-source.title)します。
     + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。

1. **[入力]** タブと **[設定]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[「Amazon ECS にデプロイ」アクション YAML](deploy-action-ref-ecs.md)」を参照してください。このリファレンスでは、各フィールド (および対応する YAML プロパティ値) について、YAML エディタとビジュアルエディタの両方で表示される詳細情報を提供しています。

1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。

1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。

------
#### [ YAML ]

**YAML エディタを使用して「Amazon ECS にデプロイ」アクションを追加するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[YAML]** を選択します。

1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。

1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。

1. **[Amazon ECS にデプロイ]** アクションを検索し、次のいずれかを実行します。
   + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。

     または
   + **[Amazon ECS にデプロイ]** を選択します。[アクションの詳細] ダイアログボックスが表示されます。このダイアログボックスでは、次の操作を行います。
     + (オプション) **[ダウンロード]** を選択して、[アクションのソースコードを表示](workflows-view-source.md#workflows-view-source.title)します。
     + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。

1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[「Amazon ECS にデプロイ」アクション YAML](deploy-action-ref-ecs.md)」に記載されています。

1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。

1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。

------

# 「Amazon ECS にデプロイ」する変数
<a name="deploy-action-ecs-variables"></a>

**[Amazon ECS にデプロイ]** アクションは、実行時に次の変数を生成して設定します。これらは*事前定義済み変数*と呼ばれます。

ワークフローでこれらの変数を参照する方法については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください


| キー | 値 | 
| --- | --- | 
|  クラスター  |  ワークフローの実行中にデプロイされた Amazon ECS クラスターの名前。 例: `codecatalyst-ecs-cluster`  | 
|  deployment-platform  |  デプロイプラットフォームの名前。 `AWS:ECS` にハードコードされています。  | 
|  サービス  |  ワークフローの実行中にデプロイされた Amazon ECS サービスの名前。 例: `codecatalyst-ecs-service`  | 
|  task-definition-arn  |  ワークフローの実行中に登録されたタスク定義の Amazon リソースネーム (ARN)。 例: `arn:aws:ecs:us-west-2:111122223333:task-definition/codecatalyst-task-def:8`前の例の `:8` は、登録されたリビジョンを示しています。  | 
|  deployment-url  |  Amazon ECS コンソールの **[イベント]** タブへのリンク。ワークフロー実行に関連付けられた Amazon ECS デプロイの詳細を表示できます。 例: `https://console.aws.amazon.com/ecs/home?region=us-west-2#/clusters/codecatalyst-ecs-cluster/services/codecatalyst-ecs-service/events`  | 
|  リージョン  |  ワークフローの実行中に にデプロイ AWS リージョン された のリージョンコード。 例: `us-west-2`  | 

# 「Amazon ECS にデプロイ」アクション YAML
<a name="deploy-action-ref-ecs"></a>

以下は、**[Amazon ECS にデプロイ]** アクションの YAML 定義です。このアクションの使用方法については、「[ワークフローを使用した Amazon ECS へのデプロイ](deploy-action-ecs.md)」を参照してください。

このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。

**注記**  
後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティとともに一覧表示されます。

```
# The workflow definition starts here.
# See 最上位プロパティ for details.
        
Name: MyWorkflow
SchemaVersion: 1.0 
Actions:

# The action definition starts here.   
  ECSDeployAction\$1nn: 
    Identifier: aws/ecs-deploy@v1
    DependsOn:
      - build-action
    Compute:  
      Type: EC2 | Lambda
      Fleet: fleet-name
    Timeout: timeout-minutes
    Environment:
      Name: environment-name
      Connections:
        - Name: account-connection-name
          Role: iam-role-name
    Inputs:
      # Specify a source or an artifact, but not both.
      Sources:
        - source-name-1
      Artifacts:
        - task-definition-artifact
    Configuration: 
      region: us-east-1 
      cluster: ecs-cluster
      service: ecs-service
      task-definition: task-definition-path
      force-new-deployment: false|true
      codedeploy-appspec: app-spec-file-path
      codedeploy-application: application-name
      codedeploy-deployment-group: deployment-group-name
      codedeploy-deployment-description: deployment-description
```

## ECSDeployAction
<a name="deploy.action.ecs.name"></a>

(必須)

アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名の特殊文字とスペースを有効にすることはできません。

デフォルト: `ECSDeployAction_nn`。

対応する UI: [設定] タブ/**[アクション表示名]**

## Identifier
<a name="deploy.action.ecs.identifier"></a>

(*ECSDeployAction*/**Identifier**)

(必須)

アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。

デフォルト: `aws/ecs-deploy@v1`。

対応する UI: ワークフロー図/ECSDeployAction \$1nn/**aws/ecs-deploy@v1** ラベル

## DependsOn
<a name="deploy.action.ecs.dependson"></a>

(*ECSDeployAction*/**DependsOn**)

(オプション)

このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。

「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。

対応する UI: [入力] タブ/**[依存 - オプション]**

## Compute
<a name="deploy.action.ecs.computename"></a>

(*ECSDeployAction*/**Compute**)

(オプション)

ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。

対応する UI: *[なし]*

## Type
<a name="deploy.action.ecs.computetype"></a>

(*ECSDeployAction*/Compute/**Type**)

([Compute](#deploy.action.ecs.computename) が含まれている場合は必須)

コンピューティングエンジンのタイプです。次のいずれかの値を使用できます。
+ **EC2** (ビジュアルエディタ) または `EC2` (YAML エディタ)

  アクション実行時の柔軟性を目的として最適化されています。
+ **Lambda** (ビジュアルエディタ) または `Lambda` (YAML エディタ)

  アクションの起動速度を最適化しました。

コンピューティングタイプの詳細については、「[コンピューティングタイプ](workflows-working-compute.md#compute.types)」を参照してください。

対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングタイプ]**

## Fleet
<a name="deploy.action.ecs.computefleet"></a>

(*ECSDeployAction*/Compute/**Fleet**)

(オプション)

ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。

プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。

`Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。

対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングフリート]**

## Timeout
<a name="deploy.action.ecs.timeout"></a>

(*ECSDeployAction*/**Timeout**)

(オプション)

CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。

対応する UI: [設定] タブ/**[タイムアウト - オプション]**

## Environment
<a name="deploy.action.ecs.environment"></a>

(*ECSDeployAction*/**Environment**)

(必須)

アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウント およびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用して に接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。

**注記**  
デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。

環境タグ付けの詳細については、「[AWS アカウント と VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

対応する UI: [設定] タブ/**[環境]**

## Name
<a name="deploy.action.ecs.environment.name"></a>

(*ECSDeployAction*/Environment/**Name**)

([Environment](#deploy.action.ecs.environment) が含まれている場合は必須)

アクションに関連付ける既存の環境の名前を指定します。

対応する UI: [設定] タブ/**[環境]**

## Connections
<a name="deploy.action.ecs.environment.connections"></a>

(*ECSDeployAction*/Environment/**Connections**)

(新しいバージョンのアクションでは任意。古いバージョンでは必須)

アクションに関連付けるアカウント接続を指定します。`Environment` で最大 1 つのアカウント接続を指定できます。

アカウント接続を指定しない場合:
+ アクションは、CodeCatalyst コンソールの環境で指定された AWS アカウント 接続とデフォルトの IAM ロールを使用します。アカウント接続とデフォルトの IAM ロールを環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。
+ デフォルトの IAM ロールには、アクションに必要なポリシーとアクセス許可が含まれている必要があります。これらのポリシーとアクセス許可を確認するには、アクションの YAML 定義ドキュメントの **[ロール]** プロパティの説明を参照してください。

アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。アカウント接続を環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]**

## Name
<a name="deploy.action.ecs.environment.connections.name"></a>

(*ECSDeployAction*/Environment/Connections/**Name**)

([Connections](#deploy.action.ecs.environment.connections) が含まれている場合は必須)

アカウント接続の名前を指定します。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]**

## Role
<a name="deploy.action.ecs.environment.connections.role"></a>

(*ECSDeployAction*/Environment/Connections/**Role**)

([Connections](#deploy.action.ecs.environment.connections) が含まれている場合は必須)

「**Amazon ECS にデプロイ**」アクションがアクセス AWSとに使用する IAM ロールの名前を指定します。[ロールを CodeCatalyst スペース に追加](ipa-connect-account-addroles.md)し、ロールに次のポリシーが含まれていることを確認します。

IAM ロールを指定しない場合、アクションは CodeCatalyst コンソールの [[環境]](deploy-environments.md) に記載されているデフォルトの IAM ロールを使用します。環境でデフォルトのロールを使用する場合は、次のポリシーがあることを確認してください。
+ 以下のアクセス許可ポリシー:
**警告**  
アクセス許可は、次のポリシーに示すアクセス許可に制限します。より広範なアクセス許可を持つロールを使用すると、セキュリティリスクが発生する可能性があります。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [{
      "Action":[
        "ecs:DescribeServices",
        "ecs:CreateTaskSet",
        "ecs:DeleteTaskSet",
        "ecs:ListClusters",
        "ecs:RegisterTaskDefinition",
        "ecs:UpdateServicePrimaryTaskSet",
        "ecs:UpdateService",
        "elasticloadbalancing:DescribeTargetGroups",
        "elasticloadbalancing:DescribeListeners",
        "elasticloadbalancing:ModifyListener",
        "elasticloadbalancing:DescribeRules",
        "elasticloadbalancing:ModifyRule",
        "lambda:InvokeFunction",
        "lambda:ListFunctions",
        "cloudwatch:DescribeAlarms",
        "sns:Publish",
        "sns:ListTopics", 
        "s3:GetObject",
        "s3:GetObjectVersion",
        "codedeploy:CreateApplication", 
        "codedeploy:CreateDeployment", 
        "codedeploy:CreateDeploymentGroup", 
        "codedeploy:GetApplication", 
        "codedeploy:GetDeployment", 
        "codedeploy:GetDeploymentGroup", 
        "codedeploy:ListApplications", 
        "codedeploy:ListDeploymentGroups", 
        "codedeploy:ListDeployments", 
        "codedeploy:StopDeployment", 
        "codedeploy:GetDeploymentTarget", 
        "codedeploy:ListDeploymentTargets", 
        "codedeploy:GetDeploymentConfig", 
        "codedeploy:GetApplicationRevision", 
        "codedeploy:RegisterApplicationRevision", 
        "codedeploy:BatchGetApplicationRevisions", 
        "codedeploy:BatchGetDeploymentGroups", 
        "codedeploy:BatchGetDeployments", 
        "codedeploy:BatchGetApplications", 
        "codedeploy:ListApplicationRevisions", 
        "codedeploy:ListDeploymentConfigs", 
        "codedeploy:ContinueDeployment"           
     ],
     "Resource":"*",
     "Effect":"Allow"
  },{"Action":[
        "iam:PassRole"
     ],
     "Effect":"Allow",
     "Resource":"*",
     "Condition":{"StringLike":{"iam:PassedToService":[
              "ecs-tasks.amazonaws.com",
              "codedeploy.amazonaws.com"
           ]
        }
     }
  }]
  }
  ```

------
**注記**  
ロールを初めて使用するとき、リソースポリシーステートメントで次のワイルドカードを使用し、使用可能になった後にリソース名でポリシーをスコープダウンします。  

  ```
  "Resource": "*"
  ```
+ 次のカスタム信頼ポリシー:

**注記**  
必要に応じて、このアクションで `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[ロール]**

## Inputs
<a name="deploy.action.ecs.inputs"></a>

(*ECSDeployAction*/**Inputs**)

(オプション)

`Inputs` セクションでは、ワークフローの実行中に `ECSDeployAction` に必要なデータを定義します。

**注記**  
**[Amazon ECS にデプロイ]** アクションごとに 1 つの入力 (ソースまたはアーティファクト) のみが許可されます。

対応する UI: **[入力]** タブ

## Sources
<a name="deploy.action.ecs.inputs.sources"></a>

(*ECSDeployAction*/Inputs/**Sources**)

(タスク定義ファイルがソースリポジトリに保存されている場合は必須)

タスク定義ファイルがソースリポジトリに保存されている場合は、そのソースリポジトリのラベルを指定します。現在サポートされているラベルは、`WorkflowSource` のみです。

タスク定義ファイルがソースリポジトリに含まれていない場合は、別のアクションによって生成されたアーティファクトに存在する必要があります。

sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。

対応する UI: 入力タブ/**[ソース - オプション]**

## Artifacts - input
<a name="deploy.action.ecs.inputs.artifacts"></a>

(*ECSDeployAction*/Inputs/**Artifacts**)

(タスク定義ファイルが前のアクションの[出力アーティファクト](workflows-working-artifacts-output.md)に保存されている場合は必須)

デプロイするタスク定義ファイルが以前のアクションによって生成されたアーティファクトに含まれている場合は、ここでそのアーティファクトを指定します。タスク定義ファイルがアーティファクトに含まれていない場合は、ソースリポジトリに存在する必要があります。

アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。

対応する UI: [設定] タブ/**[アーティファクト - オプション]**

## Configuration
<a name="deploy.action.ecs.configuration"></a>

(*ECSDeployAction*/**Configuration**)

(必須)

アクションの設定プロパティを定義できるセクション。

対応する UI: **[設定]** タブ

## region
<a name="deploy.action.ecs.region"></a>

(Configuration/**region**)

(必須)

Amazon ECS クラスターとサービスが存在する AWS リージョンを指定します。リージョンコードの一覧については、「*AWS 全般のリファレンス*」の「[Regional endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints)」を参照してください。

対応する UI: [設定] タブ/**[リージョン]**

## cluster
<a name="deploy.action.ecs.cluster"></a>

(*ECSDeployAction*/Configuration/**cluster**)

(必須)

既存の Amazon ECS クラスターの名前を指定します。**[Amazon ECS にデプロイ]** アクションは、コンテナ化されたアプリケーションをタスクとしてこのクラスターにデプロイします。詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[クラスター](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-clusters)」を参照してください。

対応する UI: [設定] タブ/**[クラスター]**

## service
<a name="deploy.action.ecs.service"></a>

(*ECSDeployAction*/Configuration/**service**)

(必須)

タスク定義ファイルをインスタンス化する既存の Amazon ECS サービスの名前を指定します。このサービスは、`cluster` フィールドで指定されたクラスターの下に存在する必要があります。Amazon ECS サービスの詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Amazon ECS サービスとは](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html)」を参照してください。

対応する UI: [設定] タブ/**[サービス]**

## task-definition
<a name="deploy.action.ecs.task.definition"></a>

(*ECSDeployAction*/Configuration/**task-definition**)

(必須)

既存のタスク定義ファイルへのパスを指定します。ファイルがソースリポジトリに存在する場合、パスはソースリポジトリのルートフォルダに相対します。ファイルが以前のワークフローアクションのアーティファクトに存在する場合、パスはアーティファクトルートフォルダを基準としています。タスク定義ファイルの詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[タスク定義](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions)」 を参照してください。

対応する UI: [設定] タブ/**[タスク定義]**

## force-new-deployment
<a name="deploy.action.ecs.forcenewdeployment"></a>

(*ECSDeployAction*/Configuration/**force-new-deployment**)

(必須)

有効にすると、Amazon ECS サービスはサービス定義を変更せずに新しいデプロイを開始できます。デプロイを強制すると、サービスは現在実行中のすべてのタスクを停止し、新しいタスクを起動します。新しいデプロイの強制の詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service.html)」を参照してください。

デフォルト: `false`

対応する UI: [設定] タブ/**[サービスの新しいデプロイを強制する]**

## codedeploy-appspec
<a name="deploy.action.ecs.codedeploy.appspec"></a>

(*ECSDeployAction*/Configuration/**codedeploy-appspec**)

(ブルー/グリーンデプロイを使用するように Amazon ECS サービスを設定している場合は必須。それ以外の場合は省略）

既存の CodeDeploy アプリケーション仕様 (AppSpec) ファイルの名前とパスを指定します。このファイルは、CodeCatalyst ソースリポジトリのルートに存在する必要があります。AppSpec ファイルの詳細については、「*AWS CodeDeploy ユーザーガイド*」の「[CodeDeploy アプリケーション指定 (AppSpec)](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html)」を参照してください。

**注記**  
CodeDeploy 情報を指定するのは、Blue/Green デプロイを実行するように Amazon ECS サービスを設定している場合のみです。ローリング更新デプロイ (デフォルト) の場合、CodeDeploy 情報は省略します。Amazon ECS デプロイの詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Amazon ECS のデプロイタイプ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-types.html)」を参照してください。

**注記**  
**[CodeDeploy]** フィールドは、ビジュアルエディタで非表示になっている場合があります。表示するには、「[ビジュアルエディタに CodeDeploy フィールドがないのはなぜですか?](troubleshooting-workflows.md#troubleshooting-workflows-codedeploy)」を参照してください。

対応する UI: [設定] タブ/**[CodeDeploy AppSpec]**

## codedeploy-application
<a name="deploy.action.ecs.codedeploy.application"></a>

(*ECSDeployAction*/Configuration/**codedeploy-application**)

(`codedeploy-appspec` が含まれている場合は必須)

既存の CodeDeploy アプリケーションの名前を指定します。詳細については、「*AWS CodeDeploy ユーザーガイド*」の「[CodeDeploy でアプリケーションを使用する」](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications.html)を参照してください。

対応する UI: [設定] タブ/**[CodeDeploy アプリケーション]**

## codedeploy-deployment-group
<a name="deploy.action.ecs.codedeploy.deploymentgroup"></a>

(*ECSDeployAction*/Configuration/**codedeploy-deployment-group**)

(`codedeploy-appspec` が含まれている場合は必須)

既存の CodeDeploy デプロイグループの名前を指定します。CodeDeploy デプロイグループの詳細については、「*AWS CodeDeploy ユーザーガイド*」の「[CodeDeploy でのデプロイグループを使用する](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html)」を参照してください。

対応する UI: [設定] タブ/**[CodeDeploy デプロイグループ]**

## codedeploy-deployment-description
<a name="deploy.action.ecs.codedeploy.deploymentdescription"></a>

(*ECSDeployAction*/Configuration/**codedeploy-deployment-description**)

(オプション)

このアクションが作成するデプロイの説明を指定します。詳細については、「*AWS CodeDeploy ユーザーガイド*」の「[CodeDeploy でデプロイする](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments.html)」を参照してください。

対応する UI: [設定] タブ/**[CodeDeploy デプロイの説明]**

# ワークフローを使用して Amazon EKS にデプロイする
<a name="deploy-action-eks"></a>

**ヒント**  
**[Kubernetes クラスターにデプロイ]** アクションを使用する方法を示すチュートリアルについては、「[チュートリアル: Amazon EKS にアプリケーションをデプロイする](deploy-tut-eks.md)」を参照してください。

このセクションでは、CodeCatalyst ワークフローを使用してコンテナ化されたアプリケーションを Kubernetes クラスターにデプロイする方法について説明します。これを実現するには、**[Kubernetes クラスターにデプロイ]** アクションをワークフローに追加する必要があります。このアクションは、1 つ以上の Kubernetes マニフェストファイルを使用して Amazon Elastic Kubernetes Service (EKS) で設定した Kubernetes クラスターにアプリケーションをデプロイします。サンプルマニフェストについては、「[チュートリアル: Amazon EKS にアプリケーションをデプロイする](deploy-tut-eks.md)」の「[deployment.yaml](deploy-tut-eks.md#deploy-tut-eks-source-files-deployment-yml)」を参照してください。

Kubernetes の詳細については、[Kubernetes のドキュメント](https://kubernetes.io/docs/home/)を参照してください。

Amazon EKS の詳細については、「*Amazon EKS ユーザーガイド*」の「[Amazon EKS とは](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)」を参照してください。

**Topics**
+ [「Kubernetes クラスターにデプロイ」アクションの仕組み](#deploy-action-eks-howitworks)
+ [「Amazon EKS にデプロイ」アクションで使用されるランタイムイメージ](#deploy-action-eks-runtime)
+ [チュートリアル: Amazon EKS にアプリケーションをデプロイする](deploy-tut-eks.md)
+ [「Kubernetes クラスターにデプロイ」アクションの追加](deploy-action-eks-adding.md)
+ [「Kubernetes クラスターにデプロイ」変数](deploy-action-eks-variables.md)
+ [「Kubernetes クラスターにデプロイ」アクション YAML](deploy-action-ref-eks.md)

## 「Kubernetes クラスターにデプロイ」アクションの仕組み
<a name="deploy-action-eks-howitworks"></a>

**[Kubernetes クラスターにデプロイ]** は次のように動作します。

1. ランタイム時に、アクションは、アクションを実行している CodeCatalyst コンピューティングマシンに Kubernetes `kubectl` ユーティリティをインストールします。アクションは、アクションの設定時に指定した Amazon EKS クラスターを指すように `kubectl` を設定します。`kubectl` ユーティリティは、次に `kubectl apply` コマンドを実行するために必要です。

1. アクションは `kubectl apply -f my-manifest.yaml` コマンドを実行します。コマンドは *my-manifest.yaml* の手順を実行して、アプリケーションを一連のコンテナとポッドとして設定済みのクラスターにデプロイします。このコマンドの詳細については、「*Kubernetes リファレンスドキュメント*」の「[kubectl apply](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply)」トピックを参照してください。

## 「Amazon EKS にデプロイ」アクションで使用されるランタイムイメージ
<a name="deploy-action-eks-runtime"></a>

**[Amazon EKS にデプロイ]** アクションは、[[2022 年 11 月の画像]](build-images.md#build.previous-image) で実行されます。詳細については、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。

# チュートリアル: Amazon EKS にアプリケーションをデプロイする
<a name="deploy-tut-eks"></a>

このチュートリアルでは、Amazon CodeCatalyst ワークフロー、Amazon EKS、およびその他のいくつかの AWS サービスを使用して、コンテナ化されたアプリケーションを Amazon Elastic Kubernetes Service にデプロイする方法について説明します。デプロイされたアプリケーションはシンプルな「Hello, World\$1」です。Apache ウェブサーバー Docker イメージ上にビルドされたウェブサイト。このチュートリアルでは、開発マシンや Amazon EKS クラスターのセットアップなど必要な準備作業を説明し、アプリケーションをビルドしてクラスターにデプロイするワークフローの作成方法を説明します。

最初のデプロイが完了すると、チュートリアルでアプリケーションソースを変更するように指示されます。この変更により、新しい Docker イメージがビルドされ、新しいリビジョン情報を使用して Docker イメージリポジトリにプッシュされます。その後、Docker イメージの新しいリビジョンが Amazon EKS にデプロイされます。

**ヒント**  
このチュートリアルを進める代わりに、完全な Amazon EKS セットアップを実行するブループリントを使用できます。**[EKS App Deployment]** ブループリントを使用する必要があります。詳細については、「[ブループリントを使用したプロジェクトの作成](projects-create.md#projects-create-console-template)」を参照してください。

**Topics**
+ [前提条件](#deploy-tut-eks-prereqs)
+ [ステップ 1: 開発マシンをセットアップする](#deploy-tut-eks-dev-env-create)
+ [ステップ 2: Amazon EKS クラスターを作成する](#deploy-tut-eks-cluster)
+ [ステップ 3: Amazon ECR イメージリポジトリを作成する](#deploy-tut-eks-ecr)
+ [ステップ 4: ソースファイルを追加する](#deploy-tut-eks-source-files)
+ [ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles)
+ [ステップ 6: CodeCatalyst に AWS ロールを追加する](#deploy-tut-eks-import-roles)
+ [ステップ 7: ConfigMap を更新する](#deploy-tut-eks-configmap)
+ [ステップ 8: ワークフローを作成して実行する](#deploy-tut-eks-workflow)
+ [ステップ 9: ソースファイルを変更する](#deploy-tut-eks-change)
+ [クリーンアップ](#deploy-tut-eks-cleanup)

## 前提条件
<a name="deploy-tut-eks-prereqs"></a>

このチュートリアルを開始する前に:
+ 接続された AWS アカウントを持つ Amazon CodeCatalyst **スペース**が必要です。詳細については、「[スペースを作成する](spaces-create.md)」を参照してください。
+ スペースには、次の名前の空のプロジェクトが必要です。

  ```
  codecatalyst-eks-project
  ```

  このプロジェクトを作成するには、**[ゼロから開始]** オプションを使用します。

  詳細については、「[Amazon CodeCatalyst での空のプロジェクトの作成](projects-create.md#projects-create-empty)」を参照してください。
+ プロジェクトには、次の名前の空白の CodeCatalyst **[ソースリポジトリ]** が必要です。

  ```
  codecatalyst-eks-source-repository
  ```

  詳細については、「[CodeCatalyst のソースリポジトリでコードを保存し、共同作業を行うソースリポジトリでコードを保存して共同作業を行う](source.md)」を参照してください。
+ プロジェクトには、CodeCatalyst CI/CD **環境** (開発環境ではない) が必要です。

  ```
  codecatalyst-eks-environment
  ```

  この環境を次のように設定します。
  + **[非本番稼働用]** など、任意のタイプを選択します。
  +  AWS アカウントを接続します。
  + **[デフォルトの IAM ロール]** で、任意のロールを選択します。後で別のロールを指定します。

  詳細については、「[AWS アカウント と VPCs へのデプロイ](deploy-environments.md)」を参照してください。

## ステップ 1: 開発マシンをセットアップする
<a name="deploy-tut-eks-dev-env-create"></a>

このチュートリアルの最初のステップは、このチュートリアル全体で使用するいくつかのツールを使用して開発マシンを設定することです。これらのロールは次のとおりです。
+ `eksctl` ユーティリティ – クラスター作成用
+ `kubectl` ユーティリティ – `eksctl` の前提条件
+  AWS CLI - の前提条件でもあります。 `eksctl`

これらのツールは、既存の開発マシンにインストールすることも、クラウドベースの CodeCatalyst 開発環境を使用することもできます。CodeCatalyst 開発環境の利点は、スピンアップとテイクダウンが簡単で、他の CodeCatalyst サービスと統合されているため、このチュートリアルをより少ないステップで実行できます。

このチュートリアルでは、CodeCatalyst 開発環境を使用することを前提としています。

次の手順では、CodeCatalyst 開発環境を起動し、必要なツールを使用して設定する簡単な方法について説明しますが、詳細な手順が必要な場合は、次を参照してください。
+ このガイドの「[開発環境の作成](devenvironment-create.md)」を参照してください。
+ 「**Amazon EKS ユーザーガイド**」の「[kubectl のインストール](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」。
+ 「**Amazon EKS ユーザーガイド**」の「[eksctl のインストールまたはアップグレード](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html)」。
+ 「*AWS Command Line Interface ユーザーガイド*」の「[AWS CLIの最新バージョンのインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」。

**新しい開発環境を起動するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクト「`codecatalyst-eks-project`」に移動します。

1. ナビゲーションペインで **[コード]** を選択してから、**[ソースリポジトリ]** を選択します。

1. ソースリポジトリの名前「`codecatalyst-eks-source-repository`」を選択します。

1. 上部近くで **[開発環境を作成]** を選択し、**[AWS Cloud9 (ブラウザで)]** を選択します。

1. **[既存のブランチで作業]** と **[メイン]** が選択されていることを確認してから、**[作成]** を選択します。

   開発環境が新しいブラウザタブで起動し、リポジトリ (`codecatalyst-eks-source-repository`) がそこにクローンされます。

**kubectl をインストールして設定するには**

1. 開発環境ターミナルで、次のように入力します。

   ```
   curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.18.9/2020-11-02/bin/linux/amd64/kubectl
   ```

1. 次のように入力します。

   ```
   chmod +x ./kubectl
   ```

1. 次のように入力します。

   ```
   mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin
   ```

1. 次のように入力します。

   ```
   echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc
   ```

1. 次のように入力します。

   ```
   kubectl version --short --client
   ```

1. バージョンが表示されることを確認します。

   `kubectl` がインストールされました。

**eksctl をインストールして設定するには**
**注記**  
`kubectl` を代わりに使用できるため、`eksctl` は必須ではありません。ただし、`eksctl` にはクラスター設定の多くを自動化する利点があるため、このチュートリアルで推奨されるツールです。

1. 開発環境ターミナルで、次のように入力します。

   ```
   curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
   ```

1. 次のように入力します。

   ```
   sudo cp /tmp/eksctl /usr/bin
   ```

1. 次のように入力します。

   ```
   eksctl version
   ```

1. バージョンが表示されることを確認します。

   `eksctl` がインストールされました。

**AWS CLI がインストールされていることを確認するには**

1. 開発環境ターミナルで、次のように入力します。

   ```
   aws --version
   ```

1. バージョンが表示され、 AWS CLI がインストールされていることを確認します。

   残りの手順を完了して、 にアクセスするために必要なアクセス許可 AWS CLI を持つ を設定します AWS。

**を設定するには AWS CLI**

 AWS サービスへのアクセスを許可するには、 アクセスキーとセッショントークン AWS CLI を使用して を設定する必要があります。以下の手順では、キーとトークンを簡単に設定できますが、詳細な手順が必要な場合は、「*AWS Command Line Interface ユーザーガイド*」の「[AWS CLIの設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)」を参照してください。

1. IAM アイデンティティセンターユーザーを次のように作成します。

   1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/singlesignon/](https://console.aws.amazon.com/singlesignon/) で AWS IAM アイデンティティセンター コンソールを開きます。

      (IAM アイデンティティセンターにサインインしたことがない場合は、**[有効化]** を選択する必要があります。)
**注記**  
CodeCatalyst スペース AWS アカウント に接続されている を使用してサインインしてください。スペースに移動し、**[AWS アカウント]** タブを選択することで、接続されているアカウントを確認できます。詳細については、「[スペースを作成する](spaces-create.md)」を参照してください。

   1. ナビゲーションペインで **[Users]** (ユーザー)、**[Add user]** (ユーザーの追加) の順に選択します。

   1. **[ユーザー名]** に次のように入力します。

      ```
      codecatalyst-eks-user
      ```

   1. **[パスワード]** で、**[このユーザーと共有できるワンタイムパスワードを生成]** を選択します。

   1. **[E メールアドレス]** と **[E メールアドレスを確認]** で、IAM アイデンティティセンターにまだ存在しない E メールアドレスを入力します。

   1. **[名（ローマ字）]** に次のように入力します。

      ```
      codecatalyst-eks-user
      ```

   1. **[姓（ローマ字）]** に次のように入力します。

      ```
      codecatalyst-eks-user
      ```

   1. **[表示名]** では、以下を維持します。

      ```
      codecatalyst-eks-user codecatalyst-eks-user
      ```

   1. [**次へ**] を選択します。

   1. **[グループにユーザーを追加]** ページで、**[次へ]** を選択します。

   1. 「**ユーザーを確認と追加**」ページで情報を確認し、**[ユーザーを追加]** を選択します。

      **[ワンタイムパスワード]** ダイアログボックスが表示されます。

   1. **[コピー]** を選択し、サインイン情報をテキストファイルに貼り付けます。サインイン情報は、 AWS アクセスポータル URL、ユーザー名、ワンタイムパスワードで構成されます。

   1. [**閉じる**] を選択してください。

1. 次のようにアクセス権限セットを作成します。

   1. ナビゲーションペインで [**アクセス許可セット**] を選択し、[**アクセス許可セットの作成**] を選択します。

   1. **[事前定義されたアクセス許可セットのポリシー]** で **[AdministratorAccess]** を選択します。このポリシーではすべての AWS のサービスアクションに対するアクセス許可が与えられています。

   1. [**次へ**] を選択します。

   1. **[アクセス許可セット名]** で、`AdministratorAccess` を削除して次のように入力します。

      ```
      codecatalyst-eks-permission-set
      ```

   1. [**次へ**] を選択します。

   1. [**確認と作成**] ページで情報を確認し、[**グループの作成**] を選択します。

1. アクセス許可セットを次のように `codecatalyst-eks-user` に設定します。

   1. ナビゲーションペインで を選択し**AWS アカウント**、現在サインイン AWS アカウント している の横にあるチェックボックスをオンにします。

   1. 「**ユーザーまたはグループを割り当て**」を選択します。

   1. **[ユーザー]** タブを選択します。

   1. [`codecatalyst-eks-user`] のチェックボックスをオンにします。

   1. [**次へ**] を選択します。

   1. [`codecatalyst-eks-permission-set`] のチェックボックスをオンにします。

   1. [**次へ**] を選択します。

   1. 情報を確認し、[**送信**] を選択します。

      これで、 `codecatalyst-eks-user`と `codecatalyst-eks-permission-set`を に割り当て AWS アカウント、それらをバインドしました。

1. 次のように、`codecatalyst-eks-user` のアクセスキーとセッショントークンを取得します。

   1. アクセス AWS ポータル URL と、 のユーザー名およびワンタイムパスワードがあることを確認します`codecatalyst-eks-user`。この情報は、事前にテキストエディタにコピーしておく必要があります。
**注記**  
この情報がない場合は、IAM アイデンティティセンターの `codecatalyst-eks-user` 詳細ページに移動し、**[パスワードをリセット]**、**[ワンタイムパスワードを生成 [...]]** を選択して、もう一度 **[パスワードをリセットする]** と、画面に情報が表示されます。

   1. からサインアウトします AWS。

   1.  AWS アクセスポータル URL をブラウザのアドレスバーに貼り付けます。

   1. 次の情報でサインインします。
      + **ユーザー名**:

        ```
        codecatalyst-eks-user
        ```
      + **パスワード**:

        *one-time-password*

   1. **[新しいパスワードを設定]** で、新しいパスワードを入力し、**[新しいパスワードを設定]** を選択します。

      画面に **AWS アカウント** ボックスが表示されます。

   1. **AWS アカウント** を選択し、 AWS アカウント ユーザーとアクセス許可セットを割り当てた `codecatalyst-eks-user` の名前を選択します。

   1. `codecatalyst-eks-permission-set` の隣にある **[コマンドラインまたはプログラムによるアクセス]** を選択します。

   1. ページの中央にあるコマンドをコピーします。次のような内容です。

      ```
      export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE" 
      export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" 
      export AWS_SESSION_TOKEN="session-token"
      ```

      ...ここでは *[session-token]* は長いランダムな文字列です。

1. 次のように AWS CLI、アクセスキーとセッショントークンを に追加します。

   1. CodeCatalyst 開発環境に戻ります。

   1. ターミナルプロンプトで、コピーしたコマンドを貼り付けます。[Enter] キーを押します。

      これで、 アクセスキーとセッショントークン AWS CLI を使用して を設定しました。を使用して AWS CLI 、このチュートリアルに必要なタスクを完了できるようになりました。
**重要**  
このチュートリアル中に次のようなメッセージが表示される場合:  
`Unable to locate credentials. You can configure credentials by running "aws configure".`  
または:  
`ExpiredToken: The security token included in the request is expired`  
... AWS CLI セッションの有効期限が切れているためです。この場合、`aws configure` コマンドは*実行しないでください*。代わりに、`Obtain codecatalyst-eks-user's access key and session token` で始まるこの手順のステップ 4 の手順を使用して、セッションを更新します。

## ステップ 2: Amazon EKS クラスターを作成する
<a name="deploy-tut-eks-cluster"></a>

このセクションでは、Amazon EKS にクラスターを作成します。以下の手順では、`eksctl` を使用してクラスターを素早く作成する方法について説明しますが、詳細な手順が必要な場合は、次を参照してください。
+ 「**Amazon EKS ユーザーガイド**」の「[eksctl の使用開始](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)」

  または
+ 「**Amazon EKS ユーザーガイド**」の「[コンソールと AWS CLIの開始方法](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html) 」(このトピックでは、クラスター作成用の `kubectl` 手順について説明します) 

**注記**  
[[プライベートクラスター]](https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html) は、Amazon EKS との CodeCatalyst 統合ではサポートされていません。

**[開始する前に]**

開発マシンで次のタスクを完了していることを確認します。
+ `eksctl` ユーティリティをインストールする。
+ `kubectl` ユーティリティをインストールする。
+ をインストール AWS CLI し、アクセスキーとセッショントークンを使用して設定しました。

これらのタスクを完了する方法の詳細については、「[ステップ 1: 開発マシンをセットアップする](#deploy-tut-eks-dev-env-create)」を参照してください。

**クラスターを作成するには**
**重要**  
クラスターが正しく設定されないため、Amazon EKS サービスのユーザーインターフェイスを使用してクラスターを作成しないでください。以下のステップで説明されているように、`eksctl` ユーティリティを使用します。

1. 開発環境に移動します。

1. クラスターおよびノードを作成する

   ```
   eksctl create cluster --name codecatalyst-eks-cluster --region us-west-2
   ```

   コードの説明は以下のとおりです。
   + *[codecatalyst-eks-cluster]* は、クラスターに付ける名前に置き換えられます。
   + *[us-west-2]* を、ご利用のリージョンに置き換えます。

   10～20 分後、次のようなメッセージが表示されます。

   `EKS cluster "codecatalyst-eks-cluster" in "us-west-2" region is ready`
**注記**  
 AWS がクラスターを作成中に複数の `waiting for CloudFormation stack` メッセージが表示されます。これは通常の動作です。

1. クラスターが正常に作成されたことを確認します。

   ```
   kubectl cluster-info
   ```

   クラスターが正常に作成されたことを示す次のようなメッセージが表示されます。

   ```
   Kubernetes master is running at https://long-string.gr7.us-west-2.eks.amazonaws.com
   CoreDNS is running at https://long-string.gr7.us-west-2.eks.amazonaws.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
   ```

## ステップ 3: Amazon ECR イメージリポジトリを作成する
<a name="deploy-tut-eks-ecr"></a>

このセクションでは、Amazon Elastic Container Registry (Amazon ECR) にプライベートイメージリポジトリを作成します。このリポジトリには、チュートリアル用の Docker イメージが保存されます。

Amazon ECR の詳細については、*Amazon Elastic Container Registry User Guide* を参照してください。

**Amazon ECR にイメージリポジトリを作成するには**

1. 開発環境に移動します。

1. Amazon ECR に空白のリポジトリを作成します。

   ```
   aws ecr create-repository --repository-name codecatalyst-eks-image-repo
   ```

   *[codecatalyst-eks-image-repo]* を Amazon ECR リポジトリに付ける名前に置き換えます。

   このチュートリアルでは、リポジトリ に「`codecatalyst-eks-image-repo`」と名前を付けていることを前提としています。

1. Amazon ECR リポジトリの詳細を表示します。

   ```
   aws ecr describe-repositories \
         --repository-names codecatalyst-eks-image-repo
   ```

1. `“repositoryUri”:` の値、例えば「`111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-eks-image-repo`」を書き留めます。

   ワークフローにリポジトリを追加するときは、後にこれが必要となります。

## ステップ 4: ソースファイルを追加する
<a name="deploy-tut-eks-source-files"></a>

このセクションでは、ソースリポジトリ (`codecatalyst-eks-source-repository`) にアプリケーションソースファイルを追加します。これらは以下で構成されます。
+ `index.html` ファイル – 「Hello, World\$1」を表示します。ブラウザのメッセージ。
+ Dockerfile – Docker イメージに使用するベースイメージと、それに適用する Docker コマンドについて説明します。
+ `deployment.yaml` ファイル – Kubernetes サービスとデプロイを定義する Kubernetes マニフェスト。

フォルダは次のような構造になっています。

```
|— codecatalyst-eks-source-repository
   |— Kubernetes
      |— deployment.yaml
   |— public-html
   |  |— index.html
   |— Dockerfile
```

**Topics**
+ [index.html](#deploy-tut-eks-source-files-index)
+ [Dockerfile](#deploy-tut-eks-source-files-dockerfile)
+ [deployment.yaml](#deploy-tut-eks-source-files-deployment-yml)

### index.html
<a name="deploy-tut-eks-source-files-index"></a>

`index.html` ファイルには「Hello, World\$1」と表示されます。ブラウザのメッセージ。

**index.html ファイルを追加するには**

1. 開発環境に移動します。

1. `codecatalyst-eks-source-repository` に「`public-html`」という名前のフォルダを作成します。

1. `/public-html` に「`index.html`」という名前のファイルを次の内容で作成します。

   ```
   <html>
     <head>
       <title>Hello World</title>
       <style>
         body {
         background-color: black;
         text-align: center;
         color: white;
         font-family: Arial, Helvetica, sans-serif;
         }  
       </style>
     </head>
     <body>
       <h1>Hello, World!</h1>
     </body>
   </html>
   ```

1. ターミナルプロンプトで、次のように入力します。

   ```
   cd /projects/codecatalyst-eks-source-repository
   ```

1. 追加、コミット、プッシュ:

   ```
   git add .
   git commit -m "add public-html/index.html"
   git push
   ```

   `index.html` は、`public-html` フォルダ内のリポジトリに追加されます。

### Dockerfile
<a name="deploy-tut-eks-source-files-dockerfile"></a>

Dockerfile は、使用するベース Docker イメージと、それに適用する Docker コマンドについて説明します。Dockerfile の詳細については、「[Dockerfile リファレンス](https://docs.docker.com/engine/reference/builder/)」を参照してください。

ここで指定された Dockerfile は、Apache 2.4 ベースイメージ (`httpd`) を使用することを示します。また、ウェブページを提供する Apache サーバーのフォルダに「`index.html`」というソースファイルをコピーする手順も含まれています。Dockerfile の `EXPOSE` 命令は、コンテナがポート 80 でリッスンしていることを Docker に伝えます。

**Dockerfile を追加するには**

1. `codecatalyst-eks-source-repository` に「`Dockerfile`」という名前のファイルを次の内容で作成します。

   ```
   FROM httpd:2.4
   COPY ./public-html/index.html /usr/local/apache2/htdocs/index.html
   EXPOSE 80
   ```

   ファイル名に拡張子は含めないでください。
**重要**  
Dockerfile はリポジトリのルートフォルダに存在する必要があります。ワークフローの `Docker build` コマンドは、ワークフローが存在することを期待します。

1. 追加、コミット、プッシュ:

   ```
   git add .
   git commit -m "add Dockerfile"
   git push
   ```

   Dockerfile がリポジトリに追加されます。

### deployment.yaml
<a name="deploy-tut-eks-source-files-deployment-yml"></a>

このセクションでは、リポジトリに `deployment.yaml` ファイルを追加します。`deployment.yaml` ファイルは、Kubernetes マニフェストであり、実行する 2 つの Kubernetes リソースタイプまたは*種類*、つまり「サービス」と「デプロイ」を定義します。
+ 「サービス」はロードバランサーを Amazon EC2 にデプロイします。ロードバランサーには、「Hello, World\$1」を参照するために使用できるインターネット向けパブリック URL と標準ポート (ポート 80) が用意されています。アプリケーションをデプロイします。
+ 「デプロイ」は 3 つのポッドをデプロイし、各ポッドには「Hello, World\$1」を含む Docker コンテナが含まれます。アプリケーションをデプロイします。3 つのポッドは、クラスターの作成時に作成されたノードにデプロイされます。

このチュートリアルのマニフェストは短いですが、マニフェストにはポッド、ジョブ、ingress、ネットワークポリシーなど、任意の数の Kubernetes リソースタイプを含めることができます。さらに、デプロイが複雑な場合は、複数のマニフェストファイルを使用できます。

**deployment.yaml ファイルを追加するには**

1. `codecatalyst-eks-source-repository` に、「`Kubernetes`」という名前のフォルダを作成します。

1. `/Kubernetes` に「`deployment.yaml`」という名前のファイルを次の内容で作成します。

   ```
   apiVersion: v1
   kind: Service
   metadata:
     name: my-service
     labels:
       app: my-app
   spec:
     type: LoadBalancer
     selector:
       app: my-app
     ports:
       - protocol: TCP
         port: 80
         targetPort: 80
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-deployment
     labels:
       app: my-app
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: my-app
     template:
       metadata:
         labels:
           app: my-app
       spec:
         containers:
         - name: codecatalyst-eks-container
           # The $REPOSITORY_URI and $IMAGE_TAG placeholders will be replaced by actual values supplied by the build action in your workflow
           image: $REPOSITORY_URI:$IMAGE_TAG
           ports:
           - containerPort: 80
   ```

1. 追加、コミット、プッシュ:

   ```
   git add .
   git commit -m "add Kubernetes/deployment.yaml"
   git push
   ```

   `deployment.yaml` ファイルは、`Kubernetes` というフォルダのリポジトリに追加されます。

これで、すべてのソースファイルが追加されました。

少し時間を取って作業を再確認し、すべてのファイルを正しいフォルダに配置してください。フォルダは次のような構造になっています。

```
|— codecatalyst-eks-source-repository
   |— Kubernetes
      |— deployment.yaml
   |— public-html
   |  |— index.html
   |— Dockerfile
```

## ステップ 5: AWS ロールを作成する
<a name="deploy-tut-eks-roles"></a>

このセクションでは、CodeCatalyst ワークフローが機能するために必要な AWS IAM ロールを作成します。これらのロールは次のとおりです。
+ **ビルドロール** – CodeCatalyst ビルドアクション (ワークフロー内) に AWS 、アカウントにアクセスして Amazon ECR と Amazon EC2 に書き込むためのアクセス許可を付与します。
+ **ロールのデプロイ** – CodeCatalyst **Deploy to Kubernetes クラスター**アクション (ワークフロー内) に AWS 、アカウントと Amazon EKS へのアクセス許可を付与します。

IAM ロールの詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)」を参照してください。

**注記**  
時間を節約するため、前に一覧表示した 2 つのロールではなく、`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールと呼ばれる 1 つのロールを作成できます。詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールには、セキュリティリスクをもたらす可能性のある非常に広範なアクセス許可があることを理解します。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。このチュートリアルでは、前述の 2 つのロールを作成することを前提としています。

ビルドロールとデプロイロールを作成するには、以下の一連の手順を実行します。

**1. 両方のロールの信頼ポリシーを作成するには**

1. 開発環境に移動します。

1. 次の内容で、`Cloud9-long-string` ディレクトリに「`codecatalyst-eks-trust-policy.json`」という名前のファイルを作成します。

**2. ビルドロールのビルドポリシーを作成するには**
+ 次の内容で、`Cloud9-long-string` ディレクトリに「`codecatalyst-eks-build-policy.json`」という名前のファイルを作成します。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "ecr:*",
                  "ec2:*"
              ],
              "Resource": "*"
          }
      ]
  }
  ```

------
**注記**  
ロールがワークフローアクションの実行に初めて使用されるときは、リソースポリシーステートメントでワイルドカードを使用し、利用可能になった後にリソース名でポリシーの範囲を絞り込みます。  

  ```
  "Resource": "*"
  ```

**3. デプロイロールにデプロイポリシーを作成するには**
+ 次の内容で、`Cloud9-long-string` ディレクトリに「`codecatalyst-eks-deploy-policy.json`」という名前のファイルを作成します。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "eks:DescribeCluster",
                  "eks:ListClusters"
              ],
              "Resource": "*"
          }
      ]
  }
  ```

------
**注記**  
ロールがワークフローアクションの実行に初めて使用されるときは、リソースポリシーステートメントでワイルドカードを使用し、利用可能になった後にリソース名でポリシーの範囲を絞り込みます。  

  ```
  "Resource": "*"
  ```

これで、開発環境に 3 つのポリシードキュメントが追加されました。ディレクトリ構造は次のようになります。

```
|— Cloud9-long-string
   |— .c9
   |— codecatalyst-eks-source-repository
      |— Kubernetes
      |— public-html
      |— Dockerfile
   codecatalyst-eks-build-policy.json
   codecatalyst-eks-deploy-policy.json
   codecatalyst-eks-trust-policy.json
```

**4. ビルドポリシーを に追加するには AWS**

1. 開発環境ターミナルで、次のように入力します。

   ```
   cd /projects
   ```

1. 次のように入力します。

   ```
   aws iam create-policy \
       --policy-name codecatalyst-eks-build-policy \
       --policy-document file://codecatalyst-eks-build-policy.json
   ```

1. **[Enter]** キーを押します。

1. コマンド出力で、例えば「`arn:aws:iam::111122223333:policy/codecatalyst-eks-build-policy`」などの `"arn":` 値を書き留めます。この ARN は後で必要になります。

**5. デプロイポリシーを に追加するには AWS**

1. 次のように入力します。

   ```
   aws iam create-policy \
       --policy-name codecatalyst-eks-deploy-policy \
       --policy-document file://codecatalyst-eks-deploy-policy.json
   ```

1. **[Enter]** キーを押します。

1. コマンド出力で、例えば「`arn:aws:iam::111122223333:policy/codecatalyst-eks-deploy-policy`」などのデプロイポリシーの `"arn":` 値を書き留めます。この ARN は後で必要になります。

**6. ビルドロールを作成するには**

1. 次のように入力します。

   ```
   aws iam create-role \
         --role-name codecatalyst-eks-build-role \
         --assume-role-policy-document file://codecatalyst-eks-trust-policy.json
   ```

1. **[Enter]** キーを押します。

1. 次のように入力します。

   ```
   aws iam attach-role-policy \
         --role-name codecatalyst-eks-build-role \
         --policy-arn arn:aws:iam::111122223333:policy/codecatalyst-eks-build-policy
   ```

   *[arn:aws:iam::111122223333:policy/codecatalyst-eks-build-policy]* が、先ほど説明したビルドポリシーの ARN に置き換えられます。

1. **[Enter]** キーを押します。

1. ターミナルプロンプトで、次のように入力します。

   ```
   aws iam get-role \
         --role-name codecatalyst-eks-build-role
   ```

1. **[Enter]** キーを押します。

1. ロールの `"Arn":` の値、例えば「`arn:aws:iam::111122223333:role/codecatalyst-eks-build-role`」を書き留めます。この ARN は後で必要になります。

**7. デプロイロールを作成するには**

1. 次のように入力します。

   ```
   aws iam create-role \
         --role-name codecatalyst-eks-deploy-role \
         --assume-role-policy-document file://codecatalyst-eks-trust-policy.json
   ```

1. **[Enter]** キーを押します。

1. 次のように入力します。

   ```
   aws iam attach-role-policy \
         --role-name codecatalyst-eks-deploy-role \
         --policy-arn arn:aws:iam::111122223333:policy/codecatalyst-eks-deploy-policy
   ```

   *[arn:aws:iam::111122223333:policy/codecatalyst-eks-deploy-policy]* が、先ほど説明したデプロイポリシーの ARN に置き換えられます。

1. **[Enter]** キーを押します。

1. 次のように入力します。

   ```
   aws iam get-role \
         --role-name codecatalyst-eks-deploy-role
   ```

1. **[Enter]** キーを押します。

1. ロールの `"Arn":` の値、例えば「`arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role`」を書き留めます。この ARN は後で必要になります。

これで、ビルドとデプロイのロールが作成され、その ARN が記録されました。

## ステップ 6: CodeCatalyst に AWS ロールを追加する
<a name="deploy-tut-eks-import-roles"></a>

このステップでは、スペースに接続 AWS アカウント した にビルドロール (`codecatalyst-eks-build-role`) を追加し、ロール (`codecatalyst-eks-deploy-role`) をデプロイします。これにより、ロールをワークフローで使用できるようになります。

**ビルドロールとデプロイロールを に追加するには AWS アカウント**

1. CodeCatalyst コンソールで、スペースに移動します。

1. 上部にある **[設定]** をクリックします。

1. ナビゲーションペインで、**[AWS アカウント]** を選択します。アカウントの一覧が表示されます。

1. **Amazon CodeCatalyst の表示名**列で、ビルドロールとデプロイロールを作成した AWS アカウント の表示名をコピーします。(数値である可能性があります。) この値は、ワークフローを作成するときに後で必要になります。

1. 表示名を選択します。

1. ** AWS 管理コンソールからロールの管理**を選択します。

   **[Amazon CodeCatalyst スペースに IAM ロールの追加]** ページが表示されます。ページにアクセスするには、サインインが必要な場合があります。

1. **[IAM で作成した既存のロールを追加]** を選択します。

   ドロップダウンリストが表示されます。この一覧表示には、ビルドロールとデプロイロール、および `codecatalyst-runner.amazonaws.com` と `codecatalyst.amazonaws.com` サービスプリンシパルを含む信頼ポリシーを持つ他の IAM ロールが表示されます。

1. ドロップダウンリストから追加します。
   + `codecatalyst-eks-build-role`
   + `codecatalyst-eks-deploy-role`
**注記**  
`The security token included in the request is invalid` が表示された場合は、適切なアクセス許可がない可能性があります。この問題を修正するには、 からサインアウト AWS して、CodeCatalyst スペースの作成時に使用した AWS アカウントで再度サインインします。

1. CodeCatalyst コンソールに戻り、ページを更新します。

   ビルドロールとデプロイロールが **[IAM ロール]** の下に表示されるようになりました。

   これらのロールが CodeCatalyst ワークフローで使用できるようになりました。

## ステップ 7: ConfigMap を更新する
<a name="deploy-tut-eks-configmap"></a>

**[Kubernetes クラスターにデプロイ]** アクション (ワークフロー内) にクラスターにアクセスして操作できるようにするには、[ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles) で作成したデプロイロールを Kubernetes `ConfigMap` ファイルに追加する必要があります。このタスクは、`eksctl` または `kubectl` を使用できます。

**eksctl を使用して Kubernetes ConfigMap ファイルを設定するには**
+ 開発環境ターミナルで、次のように入力します。

  ```
  eksctl create iamidentitymapping --cluster codecatalyst-eks-cluster --arn arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role --group system:masters --username codecatalyst-eks-deploy-role --region us-west-2
  ```

  コードの説明は以下のとおりです。
  + *codecatalyst-eks-cluster* は、Amazon EKS クラスターのクラスター名に置き換えられます。
  +  *[arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role]* は、[ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles) で作成したデプロイロールの ARN に置き換えられます。
  +  *[codecatalyst-eks-deploy-role]* (`--username` の隣) は、[ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles) で作成したデプロイロールの名前に置き換えられます。
**注記**  
デプロイロールを作成しない場合は、*[codecatalyst-eks-deploy-role]* を `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールの名前に置き換えます。このロールの詳細については、「[ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles)」を参照してください。
  +  *[us-west-2]* を、ご利用のリージョンに置き換えます。

  このコマンドの詳細については、[[IAM ユーザーとロールの管理]](https://eksctl.io/usage/iam-identity-mappings/) を参照してください。

  次のようなメッセージが表示されます。

  ```
  2023-06-09 00:58:29 [ℹ]  checking arn arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role against entries in the auth ConfigMap
  2023-06-09 00:58:29 [ℹ]  adding identity "arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role" to auth ConfigMap
  ```

**kubectl を使用して Kubernetes ConfigMap ファイルを設定するには**

1. 開発環境ターミナルで、次のように入力します。

   ```
   kubectl edit configmap -n kube-system aws-auth
   ```

   ConfigMap ファイルが画面に表示されます。

1. 赤い斜体でテキストを追加します。

   ```
   # Please edit the object below. Lines beginning with a '#' will be ignored,
   # and an empty file will abort the edit. If an error occurs while saving this file will be
   # reopened with the relevant failures.
   #
   apiVersion: v1
   data:
     mapRoles: |
       - groups:
         - system:bootstrappers
         - system:nodes
         rolearn: arn:aws:iam::111122223333:role/eksctl-codecatalyst-eks-cluster-n-NodeInstanceRole-16BC456ME6YR5
         username: system:node:{{EC2PrivateDNSName}}
       - groups:
         - system:masters
         rolearn: arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role
         username: codecatalyst-eks-deploy-role
     mapUsers: |
       []
   kind: ConfigMap
   metadata:
     creationTimestamp: "2023-06-08T19:04:39Z"
     managedFields:
     ...
   ```

   コードの説明は以下のとおりです。
   +  *[arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role]* は、[ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles) で作成したデプロイロールの ARN に置き換えられます。
   +  *[codecatalyst-eks-deploy-role]* (`username:` の隣) は、[ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles) で作成したデプロイロールの名前に置き換えられます。
**注記**  
デプロイロールを作成しない場合は、*[codecatalyst-eks-deploy-role]* を `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールの名前に置き換えます。このロールの詳細については、「[ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles)」を参照してください。

   詳細については、「**Amazon EKS ユーザーガイド**」の「[クラスターへの IAM プリンシパルアクセスを有効化](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html)」を参照してください。

これで、デプロイロールが付与され、さらには Kubernetes クラスターに **[Amazon EKS にデプロイ]** アクション、`system:masters` アクセス許可が付与されました。

## ステップ 8: ワークフローを作成して実行する
<a name="deploy-tut-eks-workflow"></a>

このステップでは、ソースファイルを受け取り、Docker イメージにビルドし、Amazon EKS クラスターのツリーポッドにイメージをデプロイするワークフローを作成します。

ワークフローは、連続して実行される次の構成要素で構成されます。
+ トリガー – このトリガーは、ソースリポジトリに変更をプッシュすると、ワークフローを自動的に開始します。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。
+ ビルドアクション (`BuildBackend`) – トリガー時に、アクションは Dockerfile を使用して Docker イメージをビルドし、そのイメージを Amazon ECR にプッシュします。ビルドアクションは、`deployment.yaml` ファイル内の `$REPOSITORY_URI` および `$IMAGE_TAG` 変数を正しい値で更新し、このファイルと `Kubernetes` フォルダ内の他のすべての出力アーティファクトを作成します。このチュートリアルでは、`Kubernetes` フォルダ内の唯一のファイルは `deployment.yaml` ですが、さらにファイルを含めることができます。このアーティファクトは、次のデプロイアクションの入力として使用されます。

  ビルドアクションの詳細については、「[ワークフローを使用したビルド](build-workflow-actions.md)」を参照してください。
+ デプロイアクション (`DeployToEKS`) – ビルドアクションが完了すると、デプロイアクションはビルドアクション (`Manifests`) によって生成された出力アーティファクトを検索し、その内部の `deployment.yaml` ファイルを見つけます。次に、アクションは `deployment.yaml` ファイルの指示に従って 3 つのポッドを実行します。それぞれに 1 つの「Hello, World\$1」が含まれます。Docker コンテナ — Amazon EKS クラスター内。

**ワークフローを作成するには**

1. CodeCatalyst コンソールを移動します。

1. プロジェクト (`codecatalyst-eks-project`) に移動します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. **[ワークフローを作成]** を選択します。

1. **[ソースリポジトリ]** で、`codecatalyst-eks-source-repository` を選択します。

1. **[ブランチ]** で、`main` を選択します。

1. **[作成]** を選択します。

1. YAML サンプルコードを削除します。

1. 次の YAML コードを追加して、新しいワークフロー定義ファイルを作成します。
**注記**  
ワークフロー定義ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。
**注記**  
次の YAML コードでは、必要に応じて `Connections:` セクションを省略できます。このセクションを省略する場合は、環境の **[デフォルト IAM ロール]** フィールドで指定されたロールに、[ステップ 6: CodeCatalyst に AWS ロールを追加する](#deploy-tut-eks-import-roles) で記述されている両方のロールのアクセス許可と信頼ポリシーが含まれていることを確認する必要があります。デフォルトの IAM ロールを使用して環境を設定する方法の詳細については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

   ```
   Name: codecatalyst-eks-workflow
   SchemaVersion: 1.0
   
   Triggers:
     - Type: PUSH
       Branches:
         - main
   Actions:
     BuildBackend:
       Identifier: aws/build@v1
       Environment:
         Name: codecatalyst-eks-environment
         Connections:
           - Name: codecatalyst-account-connection
             Role: codecatalyst-eks-build-role
       Inputs:
         Sources:
           - WorkflowSource
         Variables:
           - Name: REPOSITORY_URI
             Value: 111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-eks-image-repo
           - Name: IMAGE_TAG
             Value: ${WorkflowSource.CommitId}
       Configuration:
         Steps:
           #pre_build:
           - Run: echo Logging in to Amazon ECR...
           - Run: aws --version
           - Run: aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-west-2.amazonaws.com
           #build:
           - Run: echo Build started on `date`
           - Run: echo Building the Docker image...
           - Run: docker build -t $REPOSITORY_URI:latest .
           - Run: docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
           #post_build:
           - Run: echo Build completed on `date`
           - Run: echo Pushing the Docker images...
           - Run: docker push $REPOSITORY_URI:latest
           - Run: docker push $REPOSITORY_URI:$IMAGE_TAG
           # Replace the variables in deployment.yaml
           - Run: find Kubernetes/ -type f | xargs sed -i "s|\$REPOSITORY_URI|$REPOSITORY_URI|g"
           - Run: find Kubernetes/ -type f | xargs sed -i "s|\$IMAGE_TAG|$IMAGE_TAG|g"
           - Run: cat Kubernetes/*
           # The output artifact will be a zip file that contains Kubernetes manifest files.
       Outputs:
         Artifacts:
           - Name: Manifests
             Files: 
               - "Kubernetes/*"
     DeployToEKS:
       DependsOn: 
         - BuildBackend
       Identifier: aws/kubernetes-deploy@v1
       Environment:
         Name: codecatalyst-eks-environment
         Connections:
           - Name: codecatalyst-account-connection
             Role: codecatalyst-eks-deploy-role
       Inputs:
         Artifacts:
           - Manifests
       Configuration:
         Namespace: default
         Region: us-west-2
         Cluster: codecatalyst-eks-cluster
         Manifests: Kubernetes/
   ```

   上記のコードで置き換えます。
   + [前提条件](#deploy-tut-eks-prereqs) で作成された環境名を持つ *[codecatalyst-eks-environment]* の両方のインスタンス。
   + アカウント接続の表示名を持つ *[codecatalyst-account-connection]* の両方のインスタンス。表示名は数値である場合があります。詳細については、「[ステップ 6: CodeCatalyst に AWS ロールを追加する](#deploy-tut-eks-import-roles)」を参照してください。
   + [ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles) で作成したビルドロールの名前を持つ *[codecatalyst-eks-build-role]*。
   + [ステップ 3: Amazon ECR イメージリポジトリを作成する](#deploy-tut-eks-ecr) で作成された Amazon ECR リポジトリの URI を持つ *[111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-eks-image-repo]* (`Value:` プロパティ内)。
   + *[111122223333.dkr.ecr.us-west-2.amazonaws.com]* (`Run: aws ecr` コマンド内) と、イメージサフィックス (`/codecatalyst-eks-image-repo`) のない Amazon ECR リポジトリの URI。
   + [ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles) で作成したデプロイロールの名前を持つ *[codecatalyst-eks-deploy-role]*。
   +  AWS リージョンコードを含む *us-west-2* の両方のインスタンス。リージョンコードの一覧については、「*AWS 全般のリファレンス*」の「[Regional endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html)」を参照してください。
**注記**  
ビルドロールとデプロイロールを作成しない場合は、*[codecatalyst-eks-build-role]* と *[codecatalyst-eks-deploy-role]* を `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールの名前に置き換えます。このロールの詳細については、「[ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles)」を参照してください。

1. (オプション) **[検証]** を選択して、コミットする前に YAML コードが有効であることを確認します。

1. **[コミット]** を選択します。

1. **[コミットワークフロー]** ダイアログボックスで、次のように入力します。

   1. **[コミットメッセージ]** の場合、テキストを削除して次のように入力します。

      ```
      Add first workflow
      ```

   1. **[レポジトリ]** に `codecatalyst-eks-source-repository` を選択します。

   1. **[ブランチ名]** で、main を選択します。

   1. **[コミット]** を選択します。

   これでワークフローが作成されました。ワークフローの先頭で定義されているトリガーにより、ワークフローの実行が自動的に開始されます。具体的には、`workflow.yaml` ファイルをソースリポジトリにコミット (およびプッシュ) すると、トリガーによってワークフローの実行が開始します。

**ワークフロー実行の進行状況を表示するには**

1. CodeCatalyst コンソールのナビゲーションペインで、**[CI/CD]** を選択し、**[ワークフロー]** を選択します。

1. 先ほど作成したワークフロー「`codecatalyst-eks-workflow`」を選択します。

1. **[BuildBackend]** を選択すると、ビルドの進行状況が表示されます。

1. **[DeployToEKS]** を選択してデプロイの進行状況を確認します。

   実行の詳細を表示する方法については、「[ワークフロー実行のステータスと詳細の表示](workflows-view-run.md)」を参照してください。

**デプロイを確認するには**

1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。

1. 左側の下部近くにある **[ロードバランサー]** を選択します。

1. Kubernetes デプロイの一部として作成されたロードバランサーを選択します。どのロードバランサーを選択するかわからない場合は、**[タグ]** タブで次のタグを探します。
   + `kubernetes.io/service-name`
   + `kubernetes.io/cluster/ekstutorialcluster`

1. 正しいロードバランサーを選択し、**[説明]** タブを選択します。

1. **[DNS 名]** の値をコピーしてブラウザのアドレスバーに貼り付けます。

   「Hello World\$1」 ウェブページがブラウザに表示され、アプリケーションが正常にデプロイされたことを示します。

## ステップ 9: ソースファイルを変更する
<a name="deploy-tut-eks-change"></a>

このセクションでは、ソースリポジトリ内の `index.html` ファイルを変更します。この変更により、ワークフローは新しい Docker イメージをビルドし、コミット ID でタグ付けして Amazon ECR にプッシュし、Amazon ECS にデプロイします。

**index.html を変更するには**

1. 開発環境に移動します。

1. ターミナルプロンプトで、ソースリポジトリに変更します。

   ```
   cd /projects/codecatalyst-eks-source-repository
   ```

1.  最新のワークフロー変更をプルします。

   ```
   git pull
   ```

1. `codecatalyst-eks-source-repository/public-html/index.html` を開きます。

1. 行 14 で、`Hello, World!` テキストを `Tutorial complete!` に変更します。

1. 追加、コミット、プッシュ:

   ```
   git add .
   git commit -m "update index.html title"
   git push
   ```

   ワークフローの実行が自動的に開始します。

1. (オプション) 以下を入力します。

   ```
   git show HEAD
   ```

   `index.html` 変更のコミット ID を書き留めます。このコミット ID は、先ほど開始したワークフロー実行によってデプロイされる Docker イメージにタグ付けされます。

1. デプロイの進行状況を確認します。

   1. CodeCatalyst コンソールのナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

   1. `codecatalyst-eks-workflow` を選択して最新の実行を表示します。

   1. **[BuildBackend]** および **[DeployToEKS]** を選択して、ワークフローの実行の進行状況を確認します。

1. 次のように、アプリケーションが更新されていることを確認します。

   1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。

   1. 左側の下部近くにある **[ロードバランサー]** を選択します。

   1. Kubernetes デプロイの一部として作成されたロードバランサーを選択します。

   1. **[DNS 名]** の値をコピーしてブラウザのアドレスバーに貼り付けます。

      これでチュートリアルは完了です。ウェブページがブラウザに表示され、新バージョンのアプリケーションが正常にデプロイされたことを示します。

1. (オプション) で AWS Amazon ECR コンソールに切り替え、新しい Docker イメージがこの手順のステップ 7 のコミット ID でタグ付けされていることを確認します。

## クリーンアップ
<a name="deploy-tut-eks-cleanup"></a>

このチュートリアルで使用されるストレージリソースとコンピューティングリソースに対して不必要に課金されないように、環境をクリーンアップする必要があります。

**次をクリーンアップするには：**

1. クラスターを削除する

   1. 開発環境ターミナルで、次のように入力します。

     ```
     eksctl delete cluster --region=us-west-2 --name=codecatalyst-eks-cluster
     ```

     コードの説明は以下のとおりです。
     + *[us-west-2]* を、ご利用のリージョンに置き換えます。
     + *[codecatalyst-eks-cluster]* は、作成したクラスターの名前に置き換えられます。

     5～10 分後、クラスターと関連するリソースは削除されます。これには、 CloudFormation スタック、ノードグループ (Amazon EC2 内）、ロードバランサーが含まれますが、これらに限定されません。
**重要**  
`eksctl delete cluster` コマンドが機能しない場合は、 AWS 認証情報または`kubectl`認証情報を更新する必要がある場合があります。更新する認証情報がわからない場合は、まず AWS 認証情報を更新します。 AWS 認証情報を更新するには、「[「認証情報が見つかりません」および「ExpiredToken」というエラーを解決するにはどうすればよいですか?](troubleshooting-workflows.md#troubleshooting-workflows-auth-errors-eks)」を参照してください。`kubectl` 認証情報を更新するには、「[「サーバーに接続できません」というエラーを解決するにはどうすればよいですか?](troubleshooting-workflows.md#troubleshooting-workflows-unable-connect-eks)」を参照してください。

1.  AWS コンソールで、次のようにクリーンアップします。

   1. Amazon ECR で、`codecatalyst-eks-image-repo` を削除します。

   1. IAM アイデンティティセンターで削除します。

      1. `codecatalyst-eks-user`

      1. `codecatalyst-eks-permission-set`

   1. IAM で、次を削除します。
      + `codecatalyst-eks-build-role`
      + `codecatalyst-eks-deploy-role`
      + `codecatalyst-eks-build-policy`
      + `codecatalyst-eks-deploy-policy`

1. CodeCatalyst コンソールで、次のようにクリーンアップします。

   1. `codecatalyst-eks-workflow` を削除します。

   1. `codecatalyst-eks-environment` を削除します。

   1. `codecatalyst-eks-source-repository` を削除します。

   1. 開発環境を削除します。

   1. `codecatalyst-eks-project` を削除します。

このチュートリアルでは、CodeCatalyst ワークフローと Amazon EKS へのデプロイアクションを使用してアプリケーションを **[Kubernetes にデプロイ]** する方法について説明します。

# 「Kubernetes クラスターにデプロイ」アクションの追加
<a name="deploy-action-eks-adding"></a>

次の手順を使用して、**[Kubernetes クラスターにデプロイ]** アクションをワークフローに追加します。

**[開始する前に]**

**[Kubernetes クラスターへのデプロイ]** アクションをワークフローに追加する前に、次の準備が必要です。

**ヒント**  
これらの前提条件をすばやく設定するには、「[チュートリアル: Amazon EKS にアプリケーションをデプロイする](deploy-tut-eks.md)」の手順に従います。
+ Amazon EKS の Kubernetes クラスター。詳細については、「**Amazon EKS ユーザーガイド**」の「[Amazon EKS クラスター](https://docs.aws.amazon.com/eks/latest/userguide/clusters.html)」を参照してください。
+ アプリケーションを Docker イメージにアセンブルする方法を説明する Dockerfile が少なくとも 1 つあります。Dockerfile の詳細については、「[Dockerfile リファレンス](https://docs.docker.com/engine/reference/builder/)」を参照してください。
+ 少なくとも 1 つの Kubernetes マニフェストファイル。Kubernetes ドキュメントの *[設定ファイル]* または *[設定]* と呼ばれます。詳細については、Kubernetes のドキュメントの「[管理リソース](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/)」を参照してください。
+ **[Kubernetes クラスターにデプロイ]** アクションに Amazon EKS クラスターにアクセスして操作できるようにする IAM ロール。詳細については、[「Kubernetes クラスターにデプロイ」アクション YAML](deploy-action-ref-eks.md) の [Role](deploy-action-ref-eks.md#deploy.action.eks.environment.connections.role) トピックを参照してください。

  このロールを作成したら、次の場所に追加する必要があります。
  + Kubernetes ConfigMap ファイル。ConfigMap ファイルにロールを追加する方法については、「**Amazon EKS ユーザーガイド**」の「[クラスターへの IAM プリンシパルアクセスの有効化](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html)」を参照してください。
  + CodeCatalyst。CodeCatalyst に IAM ロールを追加する方法については、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。
+ CodeCatalyst のスペース、プロジェクト、環境。スペースと環境の両方を、アプリケーションをデプロイする AWS アカウントに接続する必要があります。詳細については[スペースを作成する](spaces-create.md)、[Amazon CodeCatalyst での空のプロジェクトの作成](projects-create.md#projects-create-empty)、および[AWS アカウント と VPCs へのデプロイ](deploy-environments.md)を参照してください。
+ CodeCatalyst でサポートされているソースリポジトリ。リポジトリには、アプリケーションソースファイル、Dockerfiles、Kubernetes マニフェストが保存されます。詳細については、「[CodeCatalyst のソースリポジトリでコードを保存し、共同作業を行うソースリポジトリでコードを保存して共同作業を行う](source.md)」を参照してください。

------
#### [ Visual ]

**ビジュアルエディタを使用して「Kubernetes クラスターにデプロイ」アクションを追加するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[ビジュアル]** を選択します。

1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。

1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。

1. **[Kubernetes クラスターにデプロイ]** アクションを検索し、次のいずれかを実行します。
   + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。

     または
   + **[Kubernetes クラスターにデプロイ]** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスでは、次の操作を行います。
     + (オプション) **[ダウンロード]** を選択して、[アクションのソースコードを表示](workflows-view-source.md#workflows-view-source.title)します。
     + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。

1. **[入力]** タブと **[設定]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[「Kubernetes クラスターにデプロイ」アクション YAML](deploy-action-ref-eks.md)」を参照してください。このリファレンスでは、各フィールド (および対応する YAML プロパティ値) について、YAML エディタとビジュアルエディタの両方で表示される詳細情報を提供しています。

1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。

1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。

------
#### [ YAML ]

**YAML エディタを使用して「Kubernetes クラスターにデプロイ」アクションを追加するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[YAML]** を選択します。

1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。

1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。

1. **[Kubernetes クラスターにデプロイ]** アクションを検索し、次のいずれかを実行します。
   + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。

     または
   + **[Kubernetes クラスターにデプロイ]** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスでは、次の操作を行います。
     + (オプション) **[ダウンロード]** を選択して、[アクションのソースコードを表示](workflows-view-source.md#workflows-view-source.title)します。
     + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。

1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[「Kubernetes クラスターにデプロイ」アクション YAML](deploy-action-ref-eks.md)」に記載されています。

1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。

1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。

------

# 「Kubernetes クラスターにデプロイ」変数
<a name="deploy-action-eks-variables"></a>

**[Kubernetes クラスターにデプロイ]** アクションは、実行時に次の変数を生成して設定します。これらは*事前定義済み変数*と呼ばれます。

ワークフローでこれらの変数を参照する方法については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください


| キー | 値 | 
| --- | --- | 
|  クラスター  |  ワークフローの実行中にデプロイされた Amazon EKS クラスターの Amazon.com リソースネーム (ARN)。 例: `arn:aws:eks:us-west-2:111122223333:cluster/codecatalyst-eks-cluster`  | 
|  deployment-platform  |  デプロイプラットフォームの名前。 `AWS:EKS` にハードコードされています。  | 
|  メタデータ  |  リザーブド。ワークフローの実行中にデプロイされたクラスターに関連する JSON 形式のメタデータ。  | 
|  名前空間  |  クラスターがデプロイされた Kubernetes ネームスペース。 例: `default`  | 
|  リソース  |  リザーブド。ワークフローの実行中にデプロイされたリソースに関連する JSON 形式のメタデータ。  | 
|  server  |  API サーバーのエンドポイントの名前は、クラスターとの通信に使用できます (`kubectl` などの管理ツールを使用)。 API サービスエンドポイントの詳細については、「**Amazon EKS ユーザーガイド**」の 「[Amazon EKS クラスターエンドポイントアクセスコントロール](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html)」を参照してください。 例: `https://random-string.gr7.us-west-2.eks.amazonaws.com`  | 

# 「Kubernetes クラスターにデプロイ」アクション YAML
<a name="deploy-action-ref-eks"></a>

**[Kubernetes クラスターにデプロイ]** アクションの YAML 定義を次に示します。このアクションの使用方法については、「[ワークフローを使用して Amazon EKS にデプロイする](deploy-action-eks.md)」を参照してください。

このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。

**注記**  
後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティとともに一覧表示されます。

```
# The workflow definition starts here.
# See 最上位プロパティ for details.
        
Name: MyWorkflow
SchemaVersion: 1.0 
Actions:

# The action definition starts here.   
  DeployToKubernetesCluster\$1nn: 
    Identifier: aws/kubernetes-deploy@v1
    DependsOn:
      - build-action
    Compute:  
        - Type: EC2 | Lambda
        - Fleet: fleet-name
    Timeout: timeout-minutes
    Environment:
      Name: environment-name
      Connections:
        - Name: account-connection-name
          Role: DeployToEKS
    Inputs:
      # Specify a source or an artifact, but not both.
      Sources:
        - source-name-1
      Artifacts:
        - manifest-artifact
    Configuration:
      Namespace: namespace
      Region: us-east-1 
      Cluster: eks-cluster
      Manifests: manifest-path
```

## DeployToKubernetesCluster
<a name="deploy.action.eks.name"></a>

(必須)

アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名の特殊文字とスペースを有効にすることはできません。

デフォルト: `DeployToKubernetesCluster_nn`。

対応する UI: [設定] タブ/**[アクション表示名]**

## Identifier
<a name="deploy.action.eks.identifier"></a>

(*DeployToKubernetesCluster*/**Identifier**)

(必須)

アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。

デフォルト: `aws/kubernetes-deploy@v1`。

対応する UI: ワークフロー図/DeployToKubernetesCluster\$1nn/**aws/kubernetes-deploy@v1** ラベル

## DependsOn
<a name="deploy.action.eks.dependson"></a>

(*DeployToKubernetesCluster*/**DependsOn**)

(オプション)

このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。

「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。

対応する UI: [入力] タブ/**[依存 - オプション]**

## Compute
<a name="deploy.action.eks.computename"></a>

(*DeployToKubernetesCluster*/**Compute**)

(オプション)

ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。

対応する UI: *[なし]*

## Type
<a name="deploy.action.eks.computetype"></a>

(*DeployToKubernetesCluster*/Compute/**Type**)

([Compute](#deploy.action.eks.computename) が含まれている場合は必須)

コンピューティングエンジンのタイプです。次のいずれかの値を使用できます。
+ **EC2** (ビジュアルエディタ) または `EC2` (YAML エディタ)

  アクション実行時の柔軟性を目的として最適化されています。
+ **Lambda** (ビジュアルエディタ) または `Lambda` (YAML エディタ)

  アクションの起動速度を最適化しました。

コンピューティングタイプの詳細については、「[コンピューティングタイプ](workflows-working-compute.md#compute.types)」を参照してください。

対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングタイプ]**

## Fleet
<a name="deploy.action.eks.computefleet"></a>

(*DeployToKubernetesCluster*/Compute/**Fleet**)

(オプション)

ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。

プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。

`Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。

対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングフリート]**

## Timeout
<a name="deploy.action.eks.timeout"></a>

(*DeployToKubernetesCluster*/**Timeout**)

(オプション)

CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。

対応する UI: [設定] タブ/**[タイムアウト - オプション]**

## Environment
<a name="deploy.action.eks.environment"></a>

(*DeployToKubernetesCluster*/**Environment**)

(必須)

アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウント およびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用して に接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。

**注記**  
デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。

環境タグ付けの詳細については、「[AWS アカウント と VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

対応する UI: [設定] タブ/**[環境]**

## Name
<a name="deploy.action.eks.environment.name"></a>

(*DeployToKubernetesCluster*/Environment/**Name**)

([Environment](#deploy.action.eks.environment) が含まれている場合は必須)

アクションに関連付ける既存の環境の名前を指定します。

対応する UI: [設定] タブ/**[環境]**

## Connections
<a name="deploy.action.eks.environment.connections"></a>

(*DeployToKubernetesCluster*/Environment/**Connections**)

(新しいバージョンのアクションでは任意。古いバージョンでは必須)

アクションに関連付けるアカウント接続を指定します。`Environment` で最大 1 つのアカウント接続を指定できます。

アカウント接続を指定しない場合:
+ アクションは、CodeCatalyst コンソールの環境で指定された AWS アカウント 接続とデフォルトの IAM ロールを使用します。アカウント接続とデフォルトの IAM ロールを環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。
+ デフォルトの IAM ロールには、アクションに必要なポリシーとアクセス許可が含まれている必要があります。これらのポリシーとアクセス許可を確認するには、アクションの YAML 定義ドキュメントの **[ロール]** プロパティの説明を参照してください。

アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。アカウント接続を環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]**

## Name
<a name="deploy.action.eks.environment.connections.name"></a>

(*DeployToKubernetesCluster*/Environment/Connections/**Name**)

(オプション)

アカウント接続の名前を指定します。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]**

## Role
<a name="deploy.action.eks.environment.connections.role"></a>

(*DeployToKubernetesCluster*/Environment/Connections/**Role**)

([Connections](#deploy.action.eks.environment.connections) が含まれている場合は必須)

**[Kubernetes クラスターにデプロイ]** アクションがアクセス AWSとに使用する IAM ロールの名前を指定します。[ロールを CodeCatalyst スペース に追加](ipa-connect-account-addroles.md)し、ロールに次のポリシーが含まれていることを確認します。

IAM ロールを指定しない場合、アクションは CodeCatalyst コンソールの [[環境]](deploy-environments.md) に記載されているデフォルトの IAM ロールを使用します。環境でデフォルトのロールを使用する場合は、次のポリシーがあることを確認してください。
+ 以下のアクセス許可ポリシー:
**警告**  
アクセス許可は、次のポリシーに示すアクセス許可に制限します。より広範なアクセス許可を持つロールを使用すると、セキュリティリスクが発生する可能性があります。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "eks:DescribeCluster",
                  "eks:ListClusters"
              ],
              "Resource": "*"
          }
      ]
  }
  ```

------
**注記**  
ロールを初めて使用するとき、リソースポリシーステートメントで次のワイルドカードを使用し、使用可能になった後にリソース名でポリシーをスコープダウンします。  

  ```
  "Resource": "*"
  ```
+ 次のカスタム信頼ポリシー:

このロールが、以下に追加されていることを確認します。
+ アカウント接続です。IAM ロールとアカウント接続の追加の詳細については、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。
+ Kubernetes ConfigMap です。ConfigMap に IAM ロールを追加する方法の詳細については、`eksctl` ドキュメントの「[IAM ユーザーとロールの管理](https://eksctl.io/usage/iam-identity-mappings/)」を参照してください。

**ヒント**  
アカウント接続と ConfigMap に IAM ロールを追加する手順については、「[チュートリアル: Amazon EKS にアプリケーションをデプロイする](deploy-tut-eks.md)」も参照してください。

**注記**  
必要に応じて、このアクションで `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[ロール]**

## Inputs
<a name="deploy.action.eks.inputs"></a>

(*DeployToKubernetesCluster*/**Inputs**)

([Connections](#deploy.action.eks.environment.connections) が含まれている場合は必須)

`Inputs` セクションでは、ワークフローの実行中に `DeployToKubernetesCluster` に必要なデータを定義します。

**注記**  
**[Amazon EKS にデプロイ]** アクションごとに 1 つの入力 (ソースまたはアーティファクト) のみが許可されます。

対応する UI: **[入力]** タブ

## Sources
<a name="deploy.action.eks.inputs.sources"></a>

(*DeployToKubernetesCluster*/Inputs/**Sources**)

(マニフェストファイルがソースリポジトリに保存されている場合は必須)

Kubernetes マニフェストファイルがソースリポジトリに保存されている場合は、そのソースリポジトリのラベルを指定します。現在サポートされているラベルは、`WorkflowSource` のみです。

マニフェストファイルがソースリポジトリに含まれていない場合、別のアクションによって生成されたアーティファクトに存在する必要があります。

sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。

対応する UI: 入力タブ/**[ソース - オプション]**

## Artifacts - input
<a name="deploy.action.eks.inputs.artifacts"></a>

(*DeployToKubernetesCluster*/Inputs/**Artifacts**)

(マニフェストファイルが前のアクションの [[出力アーティファクト]](workflows-working-artifacts-output.md) に保存されている場合は必須)

Kubernetes マニフェストファイルまたはファイルが前のアクションによって生成されたアーティファクトに含まれている場合は、ここでそのアーティファクトを指定します。マニフェストファイルがアーティファクトに含まれていない場合は、ソースリポジトリに存在する必要があります。

アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。

対応する UI: [設定] タブ/**[アーティファクト - オプション]**

## Configuration
<a name="deploy.action.eks.configuration"></a>

(*DeployToKubernetesCluster*/**Configuration**)

(必須)

アクションの設定プロパティを定義できるセクション。

対応する UI: **[設定]** タブ

## Namespace
<a name="deploy.action.eks.namespace"></a>

(*DeployToKubernetesCluster*/Configuration/**Namespace**)

(オプション)

Kubernetes アプリケーションをデプロイする Kubernetes 名前空間を指定します。クラスターで名前空間を使用しない場合は、`default` を使用します。ネームスペースの詳細については、Kubernetes ドキュメントの「[「Kubernetes 名前空間を使用したクラスターの分割](https://kubernetes.io/docs/tasks/administer-cluster/namespaces/#subdividing-your-cluster-using-kubernetes-namespaces)」を参照してください。

名前空間を省略すると、`default` の値が使用されます。

対応する UI: [設定] タブ/**[名前空間]**

## Region
<a name="deploy.action.eks.region"></a>

(*DeployToKubernetesCluster*/Configuration/**Region**)

(必須)

Amazon EKS クラスターとサービスが存在する AWS リージョンを指定します。リージョンコードの一覧については、「*AWS 全般のリファレンス*」の「[Regional endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes)」を参照してください。

対応する UI: [設定] タブ/**[リージョン]**

## Cluster
<a name="deploy.action.eks.cluster"></a>

(*DeployToKubernetesCluster*/Configuration/**Cluster**)

(必須)

既存の Amazon EKS クラスターの名前を指定します。**[Kubernetes クラスターにデプロイ]** アクションは、コンテナ化されたアプリケーションをこのクラスターにデプロイします。詳細については、「**Amazon EKS ユーザーガイド**」の「[クラスター](https://docs.aws.amazon.com/eks/latest/userguide/clusters.html)」を参照してください。

対応する UI: [設定] タブ/**[クラスター]**

## Manifests
<a name="deploy.action.eks.manifest"></a>

(*DeployToKubernetesCluster*/Configuration/**Manifests**)

(必須)

YAML 形式の Kubernetes マニフェストファイルへのパスを指定します (Kubernetes ドキュメントでは、*[設定ファイル]* 、*[設定ファイル]*、または単に *[設定]* と呼ばれます）。

複数のマニフェストファイルを使用している場合は、それらを 1 つのフォルダに配置し、そのフォルダを参照します。マニフェストファイルは Kubernetes によって英数字で処理されるため、処理順序を制御するには、ファイル名の前に必ず数字または文字を増やしてください。例えば、次のようになります。

`00-namespace.yaml`

`01-deployment.yaml`

マニフェストファイルがソースリポジトリに存在する場合、パスはソースリポジトリのルートフォルダに相対します。ファイルが以前のワークフローアクションのアーティファクトに存在する場合、パスはアーティファクトルートフォルダに相対します。

例:

`Manifests/`

`deployment.yaml`

`my-deployment.yml`

ワイルドカード (`*`) は使用しないでください。

**注記**  
[[Helm チャート]](https://helm.sh/docs/topics/charts/) と [[kustomization ファイル]](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/) はサポートされていません。

マニフェストファイルの詳細については、Kubernetes ドキュメントの「[リソース設定の整理](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#organizing-resource-configurations)」を参照してください。

対応する UI: **[設定]** タブ

# CloudFormation スタックのデプロイ
<a name="deploy-action-cfn"></a>

このセクションでは、CodeCatalyst ワークフローを使用して AWS CloudFormation スタックをデプロイする方法について説明します。これを行うには、** CloudFormation スタックのデプロイ**アクションをワークフローに追加する必要があります。アクションは、指定したテンプレート AWS に基づいて、リソースの CloudFormation スタックを にデプロイします。テンプレートは、次のようになります。
+ CloudFormation テンプレート – 詳細については、[「 テンプレートの使用 CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)」を参照してください。
+ AWS SAM テンプレート – 詳細については、[AWS Serverless Application Model 「 (AWS SAM) 仕様](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification.html)」を参照してください。
**注記**  
 AWS SAM テンプレートを使用するには、まず `[sam package](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-package.html)`オペレーションを使用して AWS SAM アプリケーションをパッケージ化する必要があります。Amazon CodeCatalyst ワークフローの一部としてこのパッケージを自動的に実行する方法を示すチュートリアルについては、「[チュートリアル: サーバーレスアプリケーションをデプロイする](deploy-tut-lambda.md)」を参照してください。

スタックが既に存在する場合、アクションは CloudFormation `[CreateChangeSet](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateChangeSet.html)` オペレーションを実行し、次に `[ExecuteChangeSet](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_ExecuteChangeSet.html)` オペレーションを実行します。その後、アクションは変更がデプロイされるのを待ち、結果に応じて、失敗または成功したものとしてマークします。

デプロイするリソースを含む CloudFormation または AWS SAM テンプレートが既にある場合、または AWS SAM や などのツールを使用してワークフロービルドアクションの一部として自動的に生成する予定がある場合は、 ** CloudFormation スタック**のデプロイアクションを使用します[AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html)。 [ビルドアクションの追加](build-add-action.md)

使用できるテンプレートに制限はありません。CloudFormation で作成することも、** CloudFormation スタックのデプロイ**アクションで使用 AWS SAM することもできます。

**ヒント**  
** CloudFormation スタックのデプロイアクションを使用してサーバーレスアプリケーションをデプロイ**する方法を示すチュートリアルについては、「」を参照してください[チュートリアル: サーバーレスアプリケーションをデプロイする](deploy-tut-lambda.md)。

**Topics**
+ [CloudFormation 「スタックをデプロイ」アクションで使用されるランタイムイメージ](#deploy-action-cfn-runtime)
+ [チュートリアル: サーバーレスアプリケーションをデプロイする](deploy-tut-lambda.md)
+ [CloudFormation 「スタックのデプロイ」アクションの追加](deploy-action-cfn-adding.md)
+ [ロールバックの設定](deploy-consumption-enable-alarms.md)
+ [CloudFormation 「スタックをデプロイ」変数](deploy-action-cfn-variables.md)
+ [CloudFormation 「スタックをデプロイ」アクション YAML](deploy-action-ref-cfn.md)

## CloudFormation 「スタックをデプロイ」アクションで使用されるランタイムイメージ
<a name="deploy-action-cfn-runtime"></a>

** CloudFormation スタックのデプロイ**アクションは、[2022 年 11 月のイメージ](build-images.md#build.previous-image)で実行されます。詳細については、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。

# チュートリアル: サーバーレスアプリケーションをデプロイする
<a name="deploy-tut-lambda"></a>

このチュートリアルでは、ワークフローを使用してサーバーレスアプリケーションを CloudFormation スタックとしてビルド、テスト、デプロイする方法について説明します。

このチュートリアルのアプリケーションは、「Hello World」メッセージを出力するシンプルなウェブアプリケーションです。これは AWS Lambda 関数と Amazon API Gateway で構成され、 の拡張機能である [AWS Serverless Application Model (AWS SAM)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html) を使用して構築します[CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)。

**Topics**
+ [前提条件](#deploy-tut-lambda-cfn-prereqs)
+ [ステップ 1: ソースレポジトリを作成する](#deploy-tut-lambda-cfn-source)
+ [ステップ 2: AWS ロールを作成する](#deploy-tut-lambda-cfn-roles)
+ [ステップ 3: CodeCatalyst に AWS ロールを追加する](#deploy-tut-lambda-cfn-roles-add)
+ [ステップ 4: Amazon S3 バケットを作成する](#deploy-tut-lambda-cfn-s3)
+ [ステップ 5: ソースファイルを追加する](#deploy-tut-lambda-cfn-files)
+ [ステップ 6: ワークフローを作成して実行する](#deploy-tut-lambda-cfn-workflow)
+ [ステップ 7: 変更を行う](#deploy-tut-lambda-cfn-change)
+ [クリーンアップ](#deploy-tut-lambda-cfn-clean-up)

## 前提条件
<a name="deploy-tut-lambda-cfn-prereqs"></a>

開始する前に:
+ 接続された AWS アカウントを持つ CodeCatalyst **スペース**が必要です。詳細については、「[スペースを作成する](spaces-create.md)」を参照してください。
+ スペースには、次の名前の空のプロジェクトが必要です。

  ```
  codecatalyst-cfn-project
  ```

  このプロジェクトを作成するには、**[ゼロから開始]** オプションを使用します。

  詳細については、「[Amazon CodeCatalyst での空のプロジェクトの作成](projects-create.md#projects-create-empty)」を参照してください。
+ プロジェクトには、以下と呼ばれる CodeCatalyst **[環境]** が必要です。

  ```
  codecatalyst-cfn-environment
  ```

  この環境を次のように設定します。
  + **[非本番稼働用]** など、任意のタイプを選択します。
  +  AWS アカウントを接続します。
  + **[デフォルトの IAM ロール]** で、任意のロールを選択します。後で別のロールを指定します。

  詳細については、「[AWS アカウント と VPCs へのデプロイ](deploy-environments.md)」を参照してください。

## ステップ 1: ソースレポジトリを作成する
<a name="deploy-tut-lambda-cfn-source"></a>

このステップでは、CodeCatalyst に空のソースリポジトリを作成します。このリポジトリは、Lambda 関数ファイルなどのチュートリアルのソースファイルを保存するために使用されます。

ソースリポジトリの詳細については、「[ソースリポジトリを作成する](source-repositories-create.md)」を参照してください。

**ソースリポジトリを作成するには**

1. ナビゲーションペインの CodeCatalyst で **[コード]** を選択してから、**[ソースリポジトリ]** を選択します。

1. **[リポジトリの追加]** を選択し、**[リポジトリの作成]** を選択します。

1. **[リポジトリ名]** に次のように入力します。

   ```
   codecatalyst-cfn-source-repository
   ```

1. **[作成]** を選択します。

これで、`codecatalyst-cfn-source-repository` というリポジトリが作成されました。

## ステップ 2: AWS ロールを作成する
<a name="deploy-tut-lambda-cfn-roles"></a>

このステップでは、次の IAM AWS ロールを作成します。
+ **ロールのデプロイ** – サーバーレスアプリケーションをデプロイする AWS アカウントと CloudFormation サービスにアクセスするアクセス許可を CodeCatalyst **Deploy CloudFormation スタック**アクションに付与します。** CloudFormation スタックのデプロイ**アクションはワークフローの一部です。
+ **ビルドロール** – CodeCatalyst ビルドアクションに、 AWS アカウントにアクセスし、サーバーレスアプリケーションパッケージが保存される Amazon S3 に書き込むアクセス許可を付与します。ビルドアクションはワークフローの一部です。
+ **スタックロール** – 後で指定する AWS SAM テンプレートで指定されたリソースを読み取って変更するアクセス許可を CloudFormation に付与します。また、CloudWatch にアクセス許可を付与します。

IAM ロールの詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)」を参照してください。

**注記**  
時間を節約するため、前に一覧表示した 3 つのロールではなく、`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールと呼ばれる 1 つのロールを作成できます。詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールには、セキュリティリスクをもたらす可能性のある非常に広範なアクセス許可があることを理解します。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。このチュートリアルでは、前述の 3 つのロールを作成することを前提としています。

**注記**  
[[Lambda 実行ロール]](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) も必要ですが、ステップ 5 でワークフローを実行するときに `sam-template.yml` ファイルが作成するため、今すぐ作成する必要はありません。



**デプロイロールを作成するには**

1. ロールのポリシーを以下の手順で作成します。

   1. にサインインします AWS。

   1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

   1. ナビゲーションペインで、**ポリシー** を選択してください。

   1. **[Create policy]** (ポリシーを作成) を選択します。

   1. **JSON** タブを選択します。

   1. 既存のコードを削除します。

   1. 次のコードを貼り付けます。
**注記**  
ロールがワークフローアクションの実行に初めて使用されるときは、リソースポリシーステートメントでワイルドカードを使用し、利用可能になった後にリソース名でポリシーの範囲を絞り込みます。  

      ```
      "Resource": "*"
      ```

   1. [**Next: Tags (次へ: タグ)**] を選択します。

   1. **[次へ: レビュー]** を選択します。

   1. **[名前]** に次のように入力します。

      ```
      codecatalyst-deploy-policy
      ```

   1. [**Create policy**] (ポリシーの作成) を選択します。

      これで、アクセス許可ポリシーが作成されました。

1. 次のようにデプロイロールを作成します。

   1. ナビゲーションペインで **ロール** を選択してから、**ロールを作成する** を選択します。

   1. **[カスタム信頼ポリシー]** を選択します。

   1. 既存のカスタム信頼ポリシーを削除します。

   1. 次の信頼ポリシーを追加します。

   1. [**次へ**] を選択します。

   1. **[アクセス許可ポリシー]** で `codecatalyst-deploy-policy` を検索し、チェックボックスをオンにします。

   1. [**次へ**] を選択します。

   1. **[ロール名]** には、次のように入力します。

      ```
      codecatalyst-deploy-role
      ```

   1. **[ロールの説明]** には、次のように入力します。

      ```
      CodeCatalyst deploy role
      ```

   1. [**ロールの作成**] を選択してください。

   これで、信頼ポリシーとアクセス許可ポリシーを使用してデプロイロールが作成されました。

1. デプロイロール ARN を次のように取得します。

   1. ナビゲーションペインで **Roles (ロール) ** を選択してください。

   1. 検索ボックスに、作成したロールの名前 (`codecatalyst-deploy-role`) を入力します。

   1. 使用するロールを一覧から選択します。

      ロールの **[概要]** ページが表示されます。

   1. 上部で、**[ARN]** 値をコピーします。

   これで、適切なアクセス許可を持つデプロイロールを作成し、ARN を取得しました。

**ビルドロールを作成するには**

1. ロールのポリシーを以下の手順で作成します。

   1. にサインインします AWS。

   1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

   1. ナビゲーションペインで、**ポリシー** を選択してください。

   1. **[Create policy]** (ポリシーを作成) を選択します。

   1. **JSON** タブを選択します。

   1. 既存のコードを削除します。

   1. 次のコードを貼り付けます。
**注記**  
ロールがワークフローアクションの実行に初めて使用されるときは、リソースポリシーステートメントでワイルドカードを使用し、利用可能になった後にリソース名でポリシーの範囲を絞り込みます。  

      ```
      "Resource": "*"
      ```

   1. [**Next: Tags (次へ: タグ)**] を選択します。

   1. **[次へ: レビュー]** を選択します。

   1. **[名前]** に次のように入力します。

      ```
      codecatalyst-build-policy
      ```

   1. [**Create policy**] (ポリシーの作成) を選択します。

      これで、アクセス許可ポリシーが作成されました。

1. 次のようにビルドロールを作成します。

   1. ナビゲーションペインで **ロール** を選択してから、**ロールを作成する** を選択します。

   1. **[カスタム信頼ポリシー]** を選択します。

   1. 既存のカスタム信頼ポリシーを削除します。

   1. 次の信頼ポリシーを追加します。

   1. [**次へ**] を選択します。

   1. **[アクセス許可ポリシー]** で `codecatalyst-build-policy` を検索し、チェックボックスをオンにします。

   1. [**次へ**] を選択します。

   1. **[ロール名]** には、次のように入力します。

      ```
      codecatalyst-build-role
      ```

   1. **[ロールの説明]** には、次のように入力します。

      ```
      CodeCatalyst build role
      ```

   1. [**ロールの作成**] を選択してください。

   これで、信頼ポリシーとアクセス許可ポリシーを使用してビルドロールが作成されました。

1. 次のようにビルドロール ARN を取得します。

   1. ナビゲーションペインで **Roles (ロール) ** を選択してください。

   1. 検索ボックスに、作成したロールの名前 (`codecatalyst-build-role`) を入力します。

   1. 使用するロールを一覧から選択します。

      ロールの **[概要]** ページが表示されます。

   1. 上部で、**[ARN]** 値をコピーします。

   これで、適切なアクセス許可を持つビルドロールを作成し、その ARN を取得しました。<a name="deploy-tut-lambda-cfn-roles-stack"></a>

**スタックロールを作成するには**

1. スタックをデプロイするアカウント AWS を使用して にサインインします。

1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. 次のようにスタックロールを作成します。

   1. ナビゲーションペインで **Roles (ロール) ** を選択してください。

   1. [**ロールの作成**] を選択してください。

   1. **[AWS サービス]** を選択してください。

   1. **[ユースケース]** セクションで、ドロップダウンリストから **[CloudFormation]** を選択します。

   1. **[CloudFormation]** ラジオボタンを選択します。

   1. 下部で、**[次へ]** を選択します。

   1. 検索ボックスを使用して、次のアクセス許可ポリシーを検索し、それぞれのチェックボックスをオンにします。
**注記**  
ポリシーを検索してもポリシーが表示されない場合は、**[フィルターをクリア]** を選択して再試行してください。
      + **CloudWatchFullAccess**
      + **AWS CloudFormationFullAccess**
      + **IAMFullAccess**
      + **AWS Lambda\$1FullAccess**
      + **AmazonAPIGatewayAdministrator**
      + **AmazonS3FullAccess**
      + **AmazonEC2ContainerRegistryFullAccess**

      最初のポリシーでは、CloudWatch へのアクセスを許可し、アラームが発生したときにスタックのロールバックを有効にします。

      残りのポリシー AWS SAM では、このチュートリアルでデプロイされるスタック内のサービスとリソースへのアクセスを に許可します。詳細については、「*AWS Serverless Application Model デベロッパーガイド*」の「[アクセス許可](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-permissions.html)」を参照してください。

   1. [**次へ**] を選択します。

   1. **[ロール名]** には、次のように入力します。

      ```
      codecatalyst-stack-role
      ```

   1. [**ロールの作成**] を選択してください。

1. 次のように、スタックロールの ARN を取得します。

   1. ナビゲーションペインで **Roles (ロール) ** を選択してください。

   1. 検索ボックスに、作成したロールの名前 (`codecatalyst-stack-role`) を入力します。

   1. 使用するロールを一覧から選択します。

   1. **[概要]** セクションの **[ARN]** 値をコピーします。これは後で必要になります。

   これで、適切なアクセス許可を持つスタックロールを作成し、ARN を取得しました。

## ステップ 3: CodeCatalyst に AWS ロールを追加する
<a name="deploy-tut-lambda-cfn-roles-add"></a>

このステップでは、ビルドロール (`codecatalyst-build-role`) を追加し、スペース内の CodeCatalyst アカウント接続にロール (`codecatalyst-deploy-role`) をデプロイします。

**注記**  
スタックロール (`codecatalyst-stack-role`) を接続に追加する必要はありません。これは、デプロイロールを使用して、CodeCatalyst と AWS 間で接続が既に確立された*後*、スタックロールが *[CloudFormation]* (CodeCatalyst ではない) で使用されるためです。スタックロールは、CodeCatalyst が AWSにアクセスするために使用するものではないため、アカウント接続に関連付ける必要はありません。

**ビルドロールとデプロイロールをアカウント接続に追加するには**

1. CodeCatalyst で、スペースに移動します。

1. **[AWS アカウント]** を選択します。アカウント接続が一覧表示されます。

1. ビルドロールとデプロイロールを作成したアカウントを表す AWS アカウント接続を選択します。

1. ** AWS 管理コンソールからロールの管理**を選択します。

   **[Amazon CodeCatalyst スペースに IAM ロールの追加]** ページが表示されます。ページにアクセスするには、サインインが必要な場合があります。

1. **[IAM で作成した既存のロールを追加]** を選択します。

   ドロップダウンリストが表示されます。この一覧表示には、`codecatalyst-runner.amazonaws.com` および `codecatalyst.amazonaws.com` サービスプリンシパルを含む信頼ポリシーを持つすべての IAM ロールが表示されます。

1. ドロップダウンリストで [`codecatalyst-build-role`] を選択し、**[ロールを追加]** を選択します。

1. **[IAM ロールを追加]** を選択し、**[IAM で作成した既存のロールを追加]** を選択し、ドロップダウンリストから [`codecatalyst-deploy-role`] を選択します。[**Add role**] を選択します。

   これで、ビルドロールとデプロイロールをスペースに追加しました。

1. **[Amazon CodeCatalyst 表示名]** の値をコピーします。この値は、ワークフローを作成するときに後で必要になります。

## ステップ 4: Amazon S3 バケットを作成する
<a name="deploy-tut-lambda-cfn-s3"></a>

このステップでは、サーバーレスアプリケーションのデプロイパッケージ .zip ファイルを保存する Amazon S3 バケットを作成します。

**Amazon S3 バケットを作成するには**

1. Amazon S3 コンソール ([https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)) を開きます。

1. メインペインで、**[バケットを作成]** を選択します。

1. **[バケット名]** に、次のように入力します。

   ```
   codecatalyst-cfn-s3-bucket
   ```

1. **[AWS リージョン]** で、リージョンを選択します。このチュートリアルは、**[米国西部 (オレゴン) us-west-2]** を選択していることを前提としています。Amazon S3 がサポートしているリージョンについては、「*AWS 全般のリファレンス*」の「[Amazon Simple Storage Service エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/s3.html)」を参照してください。

1. ページ下部にある **[バケットを作成]** ボタンを選択します。

これで、米国西部 (オレゴン) us-west-2 リージョンで **codecatalyst-cfn-s3-bucket** という名前のバケットが作成されました。

## ステップ 5: ソースファイルを追加する
<a name="deploy-tut-lambda-cfn-files"></a>

このステップでは、CodeCatalyst ソースリポジトリに複数のアプリケーションソースファイルを追加します。`hello-world` フォルダには、デプロイするアプリケーションファイルが含まれています。`tests` フォルダにはユニットテストが含まれています。フォルダは次のような構造になっています。

```
.
|— hello-world
|  |— tests
|     |— unit
|        |— test-handler.js
|  |— app.js
|— .npmignore
|— package.json
|— sam-template.yml
|— setup-sam.sh
```

### .npmignore ファイル
<a name="deploy-tut-lambda-cfn-files-npmignore"></a>

`.npmignore` ファイルは、アプリケーションパッケージから npm を除外するファイルとフォルダを示します。このチュートリアルでは、npm はアプリケーションの一部ではないため、`tests` フォルダを除外します。

**.npmignore ファイルを追加するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクト「`codecatalyst-cfn-project`」を選択します。

1. ナビゲーションペインで **[コード]** を選択してから、**[ソースリポジトリ]** を選択します。

1. ソースリポジトリのリストから、リポジトリ `codecatalyst-cfn-source-repository` を選択します。

1. **[ファイル]** で、**[ファイルを作成]** を選択します。

1. **[ファイル名]** に次のように入力します。

   ```
   .npmignore
   ```

1. テキストボックスに次のコードを入力します。

   ```
   tests/*
   ```

1. **[コミット]** を選択し、再度 **[コミット]** を選択します。

   これで、リポジトリのルートに `.npmignore` という名前のファイルが作成されました。

### package.json ファイル
<a name="deploy-tut-lambda-cfn-files-package-json"></a>

`package.json` ファイルには、プロジェクト名、バージョン番号、説明、依存関係、およびアプリケーションとやり取りして実行する方法を説明するその他の詳細など、Node プロジェクトに関する重要なメタデータが含まれています。

このチュートリアルの `package.json` には、依存関係の一覧と `test` スクリプトが含まれています。スクリプトは、次を実行します。
+ [[mocha]](https://mochajs.org/) を使用して、テストスクリプトは `hello-world/tests/unit/` で指定されたユニットテストを実行し、[[xunit]]() レポーターを使用して結果を `junit.xml` ファイルに書き込みます。
+ [[Istanbul (nyc)]](https://istanbul.js.org/) を使用すると、テストスクリプトは [[clover]](https://openclover.org/doc/manual/4.2.0/general--about-openclover.html) レポーターを使用してコードカバレッジレポート (`clover.xml`) を生成します。詳細については、「Istanbul ドキュメント」の「[代替レポーターの使用](https://istanbul.js.org/docs/advanced/alternative-reporters/#clover)」を参照してください。

**package.json ファイルを追加するには**

1. リポジトリの **[ファイル]** で、**[ファイルを作成]** を選択します。

1. **[ファイル名]** に次のように入力します。

   ```
   package.json
   ```

1. テキストボックスに次のコードを入力します。

   ```
   {
     "name": "hello_world",
     "version": "1.0.0",
     "description": "hello world sample for NodeJS",
     "main": "app.js",
     "repository": "https://github.com/awslabs/aws-sam-cli/tree/develop/samcli/local/init/templates/cookiecutter-aws-sam-hello-nodejs",
     "author": "SAM CLI",
     "license": "MIT",
     "dependencies": {
       "axios": "^0.21.1",
       "nyc": "^15.1.0"
     },
     "scripts": {
       "test": "nyc --reporter=clover mocha hello-world/tests/unit/ --reporter xunit --reporter-option output=junit.xml"
     },
     "devDependencies": {
       "aws-sdk": "^2.815.0",
       "chai": "^4.2.0",
       "mocha": "^8.2.1"
     }
   }
   ```

1. **[コミット]** を選択し、再度 **[コミット]** を選択します。

   これで、リポジトリのルートに「`package.json`」という名前のファイルが追加されました。

### sam-template.yml ファイル
<a name="deploy-tut-lambda-cfn-files-sam-template-yml"></a>

`sam-template.yml` ファイルには、Lambda 関数と API Gateway をデプロイし、それらを一緒に設定するための手順が含まれています。テンプレート[AWS Serverless Application Model 仕様](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification.html)に従っており、 CloudFormation テンプレート仕様を拡張します。

は便利な [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html) リソースタイプ AWS SAM を提供するため、このチュートリアル AWS SAM では通常のテンプレートの代わりに CloudFormation テンプレートを使用します。このタイプは、基本的な CloudFormation 構文を使用するために通常書き出す必要がある behind-the-scenes の設定を多く実行します。例えば、`AWS::Serverless::Function` は、関数を開始する Lambda 関数、Lambda 実行ロール、イベントソースマッピングを作成します。基本的な CloudFormation を使用して書き込む場合は、これらすべてをコーディングする必要があります。

このチュートリアルでは、事前に作成されたテンプレートを使用しますが、ビルドアクションを使用してワークフローの一部として作成できます。詳細については、「[CloudFormation スタックのデプロイ](deploy-action-cfn.md)」を参照してください。

**sam-template.yml ファイルを追加するには**

1. リポジトリの **[ファイル]** で、**[ファイルを作成]** を選択します。

1. **[ファイル名]** に次のように入力します。

   ```
   sam-template.yml
   ```

1. テキストボックスに次のコードを入力します。

   ```
   AWSTemplateFormatVersion: '2010-09-09'
   Transform: AWS::Serverless-2016-10-31
   Description: >
     serverless-api
   
     Sample SAM Template for serverless-api
     
   # More info about Globals: https://github.com/awslabs/serverless-application-model/blob/master/docs/globals.rst
   Globals:
     Function:
       Timeout: 3
   
   Resources:
     HelloWorldFunction:
       Type: AWS::Serverless::Function # For details on this resource type, see https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
       Properties:
         CodeUri: hello-world/
         Handler: app.lambdaHandler
         Runtime: nodejs12.x
         Events:
           HelloWorld:
             Type: Api # For details on this event source type, see https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api
             Properties:
               Path: /hello
               Method: get
   
   Outputs:
     # ServerlessRestApi is an implicit API created out of the events key under Serverless::Function
     # Find out about other implicit resources you can reference within AWS SAM at
     # https://github.com/awslabs/serverless-application-model/blob/master/docs/internals/generated_resources.rst#api
     HelloWorldApi:
       Description: "API Gateway endpoint URL for the Hello World function"
       Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/"
     HelloWorldFunction:
       Description: "Hello World Lambda function ARN"
       Value: !GetAtt HelloWorldFunction.Arn
     HelloWorldFunctionIamRole:
       Description: "Implicit Lambda execution role created for the Hello World function"
       Value: !GetAtt HelloWorldFunctionRole.Arn
   ```

1. **[コミット]** を選択し、再度 **[コミット]** を選択します。

   これで、リポジトリのルートフォルダに「`sam-template.yml`」という名前のファイルが追加されました。

### setup-sam.sh ファイル
<a name="deploy-tut-lambda-cfn-files-setup-sam"></a>

`setup-sam.sh` ファイルには、 CLI AWS SAM ユーティリティをダウンロードしてインストールする手順が含まれています。ワークフローは、このユーティリティを使用して `hello-world` ソースをパッケージ化します。

**setup-sam.sh ファイルを追加するには**

1. リポジトリの **[ファイル]** で、**[ファイルを作成]** を選択します。

1. **[ファイル名]** に次のように入力します。

   ```
   setup-sam.sh
   ```

1. テキストボックスに次のコードを入力します。

   ```
   #!/usr/bin/env bash
   echo "Setting up sam"
   
   yum install unzip -y
   
   curl -LO https://github.com/aws/aws-sam-cli/releases/latest/download/aws-sam-cli-linux-x86_64.zip
   unzip -qq aws-sam-cli-linux-x86_64.zip -d sam-installation-directory
   
   ./sam-installation-directory/install; export AWS_DEFAULT_REGION=us-west-2
   ```

   上記のコードでは、*[us-west-2]* を AWS リージョンに置き換えます。

1. **[コミット]** を選択し、再度 **[コミット]** を選択します。

   これで、リポジトリのルートに「`setup-sam.sh`」という名前のファイルが追加されました。

### app.js ファイル
<a name="deploy-tut-lambda-cfn-files-app-js"></a>

`app.js` には、Lambda 関数のコードが含まれます。このチュートリアルでは、`hello world` コードはテキストを返します。

**app.js ファイルを追加するには**

1. リポジトリの **[ファイル]** で、**[ファイルを作成]** を選択します。

1. **[ファイル名]** に次のように入力します。

   ```
   hello-world/app.js
   ```

1. テキストボックスに次のコードを入力します。

   ```
   // const axios = require('axios')
   // const url = 'http://checkip.amazonaws.com/';
   let response;
   
   /**
    *
    * Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format
    * @param {Object} event - API Gateway Lambda Proxy Input Format
    *
    * Context doc: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html 
    * @param {Object} context
    *
    * Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html
    * @returns {Object} object - API Gateway Lambda Proxy Output Format
    * 
    */
   exports.lambdaHandler = async (event, context) => {
       try {
           // const ret = await axios(url);
           response = {
               'statusCode': 200,
               'body': JSON.stringify({
                   message: 'hello world',
                   // location: ret.data.trim()
               })
           }
       } catch (err) {
           console.log(err);
           return err;
       }
   
       return response
   };
   ```

1. **[コミット]** を選択し、再度 **[コミット]** を選択します。

   これで、「`hello-world`」というフォルダと「`app.js`」というファイルが作成されました。

### test-handler.js ファイル
<a name="deploy-tut-lambda-cfn-files-test-handler-js"></a>

`test-handler.js` ファイルには、Lambda 関数の単位テストが含まれています。

**test-handler.js ファイルを追加するには**

1. リポジトリの **[ファイル]** で、**[ファイルを作成]** を選択します。

1. **[ファイル名]** に次のように入力します。

   ```
   hello-world/tests/unit/test-handler.js
   ```

1. テキストボックスに次のコードを入力します。

   ```
   'use strict';
   
   const app = require('../../app.js');
   const chai = require('chai');
   const expect = chai.expect;
   var event, context;
   
   describe('Tests index', function () {
       it('verifies successful response', async () => {
           const result = await app.lambdaHandler(event, context)
   
           expect(result).to.be.an('object');
           expect(result.statusCode).to.equal(200);
           expect(result.body).to.be.an('string');
   
           let response = JSON.parse(result.body);
   
           expect(response).to.be.an('object');
           expect(response.message).to.be.equal("hello world");
           // expect(response.location).to.be.an("string");
       });
   });
   ```

1. **[コミット]** を選択し、再度 **[コミット]** を選択します。

   これで、`hello-world/tests/unit` フォルダの下位に「`test-handler.js`」というファイルが追加されました。

これで、すべてのソースファイルが追加されました。

少し時間を取って作業を再確認し、すべてのファイルを正しいフォルダに配置してください。フォルダは次のような構造になっています。

```
.
|— hello-world
|  |— tests
|     |— unit
|        |— test-handler.js
|  |— app.js
|— .npmignore
|— README.md
|— package.json
|— sam-template.yml
|— setup-sam.sh
```

## ステップ 6: ワークフローを作成して実行する
<a name="deploy-tut-lambda-cfn-workflow"></a>

このステップでは、Lambda ソースコードをパッケージ化し、デプロイするワークフローを作成します。ワークフローは、連続して実行される次の構成要素で構成されます。
+ トリガー – このトリガーは、ソースリポジトリに変更をプッシュすると、ワークフローを自動的に開始します。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。
+ テストアクション (`Test`) – トリガー時に、このアクションは [[Node パッケージマネージャー (npm)]](https://www.npmjs.com/) をインストールし、`npm run test` コマンドを実行します。このコマンドは、`package.json` ファイルで定義された `test` スクリプトを実行するように npm に指示します。次に、`test` スクリプトはユニットテストを実行し、テストレポート (`junit.xml`) とコードカバレッジレポート (`clover.xml`) の 2 つのレポートを生成します。詳細については、「[package.json ファイル](#deploy-tut-lambda-cfn-files-package-json)」を参照してください。

  次に、テストアクションは XML レポートを CodeCatalyst レポートに変換し、テストアクションの **[Reports]** タブの CodeCatalyst コンソールに表示します。

  テストアクションの詳細については、「[ワークフローを使用したテストワークフローを使用したテスト](test-workflow-actions.md)」を参照してください。
+ ビルドアクション (`BuildBackend`) – テストアクションが完了すると、ビルドアクションは CLI AWS SAM をダウンロードしてインストールし、`hello-world`ソースをパッケージ化し、パッケージを Lambda サービスが想定する Amazon S3 バケットにコピーします。アクションは、 という新しい AWS SAM テンプレートファイルも出力`sam-template-packaged.yml`し、 という出力アーティファクトに配置します`buildArtifact`。

  ビルドアクションの詳細については、「[ワークフローを使用したビルド](build-workflow-actions.md)」を参照してください。
+ デプロイアクション (`DeployCloudFormationStack`) – ビルドアクションが完了すると、デプロイアクションはビルドアクション (`buildArtifact`) によって生成された出力アーティファクトを検索し、その中に AWS SAM テンプレートを見つけて、テンプレートを実行します。 AWS SAM テンプレートは、サーバーレスアプリケーションをデプロイするスタックを作成します。

**ワークフローを作成するには**

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. **[ワークフローを作成]** を選択します。

1. **[ソースリポジトリ]** で、`codecatalyst-cfn-source-repository` を選択します。

1. **[ブランチ]** で、`main` を選択します。

1. **[作成]** を選択します。

1. YAML サンプルコードを削除します。

1. 次の YAML コードを追加します。
**注記**  
次の YAML コードでは、必要に応じて `Connections:` セクションを省略できます。このセクションを省略する場合は、環境の **[デフォルト IAM ロール]** フィールドで指定されたロールに、[ステップ 2: AWS ロールを作成する](#deploy-tut-lambda-cfn-roles) で記述されている両方のロールのアクセス許可と信頼ポリシーが含まれていることを確認する必要があります。デフォルトの IAM ロールを使用して環境を設定する方法の詳細については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

   ```
   Name: codecatalyst-cfn-workflow
   SchemaVersion: 1.0
   
   Triggers:
     - Type: PUSH
       Branches:
         - main   
   Actions:
     Test:
       Identifier: aws/managed-test@v1
       Inputs:
         Sources:
           - WorkflowSource
       Outputs:
         Reports:
           CoverageReport:
             Format: CLOVERXML
             IncludePaths:
               - "coverage/*"
           TestReport:
             Format: JUNITXML
             IncludePaths:
               - junit.xml
       Configuration:
         Steps:
           - Run: npm install
           - Run: npm run test  
     BuildBackend:
       Identifier: aws/build@v1
       DependsOn:
         - Test
       Environment:
         Name: codecatalyst-cfn-environment
         Connections:
           - Name: codecatalyst-account-connection
             Role: codecatalyst-build-role
       Inputs:
         Sources:
           - WorkflowSource
       Configuration: 
         Steps:
           - Run: . ./setup-sam.sh
           - Run: sam package --template-file sam-template.yml --s3-bucket codecatalyst-cfn-s3-bucket --output-template-file sam-template-packaged.yml --region us-west-2
       Outputs:
         Artifacts:
           - Name: buildArtifact
             Files:
               - "**/*"
     DeployCloudFormationStack:
       Identifier: aws/cfn-deploy@v1
       DependsOn: 
         - BuildBackend
       Environment:
         Name: codecatalyst-cfn-environment
         Connections:
           - Name: codecatalyst-account-connection
             Role: codecatalyst-deploy-role
       Inputs:
         Artifacts:
           - buildArtifact
         Sources: []
       Configuration:
         name: codecatalyst-cfn-stack
         region: us-west-2
         role-arn: arn:aws:iam::111122223333:role/StackRole
         template: ./sam-template-packaged.yml
         capabilities: CAPABILITY_IAM,CAPABILITY_AUTO_EXPAND
   ```

   上記のコードで置き換えます。
   + 環境の名前を持つ *[codecatalyst-cfn-environment]* の両方のインスタンス。
   + アカウント接続の表示名を持つ *[codecatalyst-account-connection]* の両方のインスタンス。表示名は数値である場合があります。詳細については、「[ステップ 3: CodeCatalyst に AWS ロールを追加する](#deploy-tut-lambda-cfn-roles-add)」を参照してください。
   + [ステップ 2: AWS ロールを作成する](#deploy-tut-lambda-cfn-roles) で作成したビルドロールの名前を持つ「*codecatalyst-build-role*」
   + [ステップ 4: Amazon S3 バケットを作成する](#deploy-tut-lambda-cfn-s3) で作成した Amazon S3 バケットの名前を持つ *[codecatalyst-cfn-s3-bucket]*。
   + Amazon S3 バケットが存在するリージョン (1 番目のインスタンス) とスタックがデプロイされるリージョン (2 番目のインスタンス) を持つ *[us-west-2]* のインスタンスの両方。これらのリージョンは異なる場合があります。このチュートリアルでは、両方のリージョンが `us-west-2` に設定されていることを前提としています。Amazon S3 および でサポートされているリージョンの詳細については CloudFormation、の[「サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照してください*AWS 全般のリファレンス*。
   + [ステップ 2: AWS ロールを作成する](#deploy-tut-lambda-cfn-roles) で作成したデプロイロールの名前を持つ「*codecatalyst-deploy-role*」
   + 「[前提条件](#deploy-tut-lambda-cfn-prereqs)」で作成した環境の名前を持つ *[codecatalyst-cfn-environment]*。
   + [ステップ 2: AWS ロールを作成する](#deploy-tut-lambda-cfn-roles) で作成したスタックロールの Amazon リソースネーム (ARN) を持つ *[arn:aws:iam::111122223333:role/StackRole]*。
**注記**  
ビルド、デプロイ、スタックロールを作成しない場合、*codecatalyst-build-role*、*codecatalyst-deploy-role*、および *arn:aws:iam::111122223333:role/StackRole* を `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールの名前または ARN に置き換えます。このロールの詳細については、「[ステップ 2: AWS ロールを作成する](#deploy-tut-lambda-cfn-roles)」を参照してください。

   前述のコードのプロパティの詳細については、「[CloudFormation 「スタックをデプロイ」アクション YAML](deploy-action-ref-cfn.md)」を参照してください。

1. (オプション) **[検証]** を選択して、コミットする前に YAML コードが有効であることを確認します。

1. **[コミット]** を選択します。

1. **[ワークフローをコミット]** ダイアログボックスで、次のように入力します。

   1. **[ワークフローファイル名]** は、デフォルトの「`codecatalyst-cfn-workflow`」のままにします。

   1. **[コミットメッセージ]** には、次のように入力します。

      ```
      add initial workflow file
      ```

   1. **[リポジトリ]** で、**[codecatalyst-cfn-source-repository]** を選択します。

   1. **[ブランチ名]** で、**[main]** を選択します。

   1. **[コミット]** を選択します。

   これでワークフローが作成されました。ワークフローの先頭で定義されているトリガーにより、ワークフローの実行が自動的に開始されます。具体的には、`codecatalyst-cfn-workflow.yaml` ファイルをソースリポジトリにコミット (およびプッシュ) すると、トリガーによってワークフローの実行が開始します。

**ワークフロー実行の進行状況を確認するには**

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. 先ほど作成したワークフロー「`codecatalyst-cfn-workflow`」を選択します。

1. **[実行]** タブを選択します。

1. **[Run ID]** 列で、実行 ID を選択します。

1. **[Test]** を選択して、テストの進行状況を確認します。

1. **[BuildBackend]** を選択すると、ビルドの進行状況が表示されます。

1. **[DeployCloudFormationStack]** を選択してデプロイの進行状況を確認します。

   実行の詳細を表示する方法については、「[ワークフロー実行のステータスと詳細の表示](workflows-view-run.md)」を参照してください。

1. **[DeployCloudFormationStack]** アクションが完了したら、以下を実行します。
   + ワークフローの実行が成功したら、次の手順に進みます。
   + **[Test]** または **[BuildBackend]** ワークフローの実行が失敗した場合は、**[Logs]** を選択して問題をトラブルシューティングします。
   + **[DeployCloudFormationStack]** アクションでワークフローの実行が失敗した場合は、デプロイアクションを選択し、**[概要]** タブを選択します。**[CloudFormation イベント]** セクションにスクロールして、詳細なエラーメッセージを表示します。ロールバックが発生した場合は、ワークフローを再実行する前に、 の CloudFormation コンソール AWS から`codecatalyst-cfn-stack`スタックを削除します。

**デプロイを確認するには**

1. デプロイが成功したら、上部付近の水平メニューバーから **[変数 (7)]** を選択します。(右側のペインで **[変数]** を選択しないでください)。

1. **[HelloWorldApi]** の横にある `https://` URL をブラウザに貼り付けます。

   Lambda 関数からの **[hello world]** JSON メッセージが表示され、ワークフローが Lambda 関数と API Gateway を正常にデプロイおよび設定したことを示します。
**ヒント**  
CodeCatalyst が、いくつかの細かい設定を持つワークフロー図に、この URL を表示するようにできます。詳細については、「[ワークフロー図でのアプリケーション URL の表示](deploy-app-url.md)」を参照してください。

**ユニットテスト結果とコードカバレッジを検証するには**

1. ワークフロー図で、**[Test]** を選択し、**[Reports]** を選択します。

1. **[TestReport]** を選択してユニットテスト結果を表示するか、**[CoverageReport]** を選択してテスト対象のファイルのコードカバレッジの詳細を表示します。この場合、`app.js` と `test-handler.js` です。

**デプロイされたリソースを確認するには**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/apigateway/](https://console.aws.amazon.com/apigateway/) で API Gateway コンソールを開きます。

1.  AWS SAM テンプレートが作成した **codecatalyst-cfn-stack** API を確認します。API 名は、ワークフロー定義ファイル (`codecatalyst-cfn-workflow.yaml`) の `Configuration/name` の値から取得します。

1. [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/) で AWS Lambda コンソールを開きます。

1. ナビゲーションペインで、**[関数]** を選択します。

1. Lambda 関数「`codecatalyst-cfn-stack-HelloWorldFunction-string`」を選択します。

1. API Gateway が 関数のトリガーであることを確認できます。この統合は、 リソースタイプによって自動的に設定されました AWS SAM `AWS::Serverless::Function`。

## ステップ 7: 変更を行う
<a name="deploy-tut-lambda-cfn-change"></a>

このステップでは、Lambda ソースコードを変更してコミットします。このコミットにより、新しいワークフロー実行が開始します。この実行では、Lambda コンソールで指定されたデフォルトのトラフィックシフト設定を使用するブルーグリーンスキームで新しい Lambda 関数をデプロイします。

**Lambda ソースを変更するには**

1. CodeCatalyst で、プロジェクトに移動します。

1. ナビゲーションペインで **[コード]** を選択してから、**[ソースリポジトリ]** を選択します。

1. ソースリポジトリ「`codecatalyst-cfn-source-repository`」を選択します。

1. アプリケーションファイルを変更します。

   1. `hello-world` フォルダを選択します。

   1. `app.js` ファイルを選択します。

   1. **[編集]** を選択します。

   1. 行 23 において、`hello world` を **Tutorial complete\$1** に変更します。

   1. **[コミット]** を選択し、再度 **[コミット]** を選択します。

      コミットにより、ワークフローの実行が開始します。名前の変更を反映するようにユニットテストを更新していないため、この実行は失敗します。

1. ユニットテストを更新します。

   1. `hello-world\tests\unit\test-handler.js` を選択してください。

   1. **[編集]** を選択します。

   1. 行 19 において、`hello world` を **Tutorial complete\$1** に変更します。

   1. **[コミット]** を選択し、再度 **[コミット]** を選択します。

      コミットにより、もう 1 つのワークフローの実行が開始します。この実行は成功します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. [`codecatalyst-cfn-workflow`] を選択し、**[実行]** を選択します。

1. 最新の実行の実行 ID を選択します。この時点では実行中です。

1. **[Test]**、**[BuildBackend]**、**[DeployCloudFormationStack]** を選択し、ワークフローの実行の進行状況を確認します。

1. ワークフローが完了したら、上部の近くの **[変数 (7)]** を選択します。

1. **[HelloWorldApi]** の横にある `https://` URL をブラウザに貼り付けます。

   `Tutorial complete!` メッセージがブラウザに表示されます。これは、アプリケーションが正常にデプロイされたことを示しています。

## クリーンアップ
<a name="deploy-tut-lambda-cfn-clean-up"></a>

このチュートリアルで使用されているファイルとサービスをクリーンアップして、料金が発生しないようにします。

**CodeCatalyst コンソールでクリーンアップするには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. `codecatalyst-cfn-workflow` を削除します。

1. `codecatalyst-cfn-environment` を削除します。

1. `codecatalyst-cfn-source-repository` を削除します。

1. `codecatalyst-cfn-project` を削除します。

**でクリーンアップするには AWS マネジメントコンソール**

1. CloudFormation で次のようにクリーンアップします。

   1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソールを開きます。

   1. `codecatalyst-cfn-stack` を削除します。

      スタックを削除すると、API Gateway および Lambda サービスからすべてのチュートリアルリソースが削除されます。

1. Amazon S3 で次のようにクリーンアップします。

   1. Amazon S3 コンソール ([https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)) を開きます。

   1. [`codecatalyst-cfn-s3-bucket`] を選択します。

   1. バケットのコンテンツを削除します。

   1.  バケットを削除します。

1. IAM で次のようにクリーンアップします。

   1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

   1. `codecatalyst-deploy-policy` を削除します。

   1. `codecatalyst-build-policy` を削除します。

   1. `codecatalyst-stack-policy` を削除します。

   1. `codecatalyst-deploy-role` を削除します。

   1. `codecatalyst-build-role` を削除します。

   1. `codecatalyst-stack-role` を削除します。

このチュートリアルでは、CodeCatalyst ワークフローとデプロイスタックアクションを使用して、サーバーレスアプリケーションを CloudFormation ** CloudFormation スタックとしてデプロイ**する方法を学習しました。

# CloudFormation 「スタックのデプロイ」アクションの追加
<a name="deploy-action-cfn-adding"></a>

次の手順を使用して、ワークフローに**スタックのデプロイ CloudFormation **アクションを追加します。

------
#### [ Visual ]

**ビジュアルエディタを使用して CloudFormation 「スタックのデプロイ」アクションを追加するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[ビジュアル]** を選択します。

1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。

1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。

1. ** CloudFormation スタックのデプロイ**アクションを検索し、次のいずれかを実行します。
   + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。

     または
   + ** CloudFormation スタックをデプロイ **を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスでは、次の操作を行います。
     + (オプション) **[ダウンロード]** を選択して、[アクションのソースコードを表示](workflows-view-source.md#workflows-view-source.title)します。
     + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。

1. **[入力]** タブと **[設定]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[CloudFormation 「スタックをデプロイ」アクション YAML](deploy-action-ref-cfn.md)」を参照してください。このリファレンスでは、各フィールド (および対応する YAML プロパティ値) について、YAML エディタとビジュアルエディタの両方で表示される詳細情報を提供しています。

1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。

1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。

------
#### [ YAML ]

**YAML エディタを使用して CloudFormation 「スタックのデプロイ」アクションを追加するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[YAML]** を選択します。

1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。

1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。

1. ** CloudFormation スタックのデプロイ**アクションを検索し、次のいずれかを実行します。
   + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。

     または
   + ** CloudFormation スタックをデプロイ** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスでは、次の操作を行います。
     + (オプション) **[ダウンロード]** を選択して、[アクションのソースコードを表示](workflows-view-source.md#workflows-view-source.title)します。
     + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。

1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[CloudFormation 「スタックをデプロイ」アクション YAML](deploy-action-ref-cfn.md)」に記載されています。

1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。

1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。

------

# ロールバックの設定
<a name="deploy-consumption-enable-alarms"></a>

デフォルトでは、**スタックのデプロイ CloudFormation **アクションが失敗すると、 はスタック CloudFormation を最後の既知の安定状態にロールバックします。アクションが失敗したときだけでなく、指定された Amazon CloudWatch アラームが発生したときにもロールバックが発生するように動作を変更できます。CloudWatch アラームの使用の詳細については、*Amazon CloudWatch ユーザーガイド*の「[Amazon CloudWatch アラームの使用](https://docs.aws.amazon.com/)」を参照してください。

デフォルトの動作を変更して、アクションが失敗しても CloudFormation がスタックをロールバックしないようにすることもできます。

ロールバックを設定するには、以下の手順に従います。

**注記**  
ロールバックを手動で開始することはできません。

------
#### [ Visual ]

**[開始する前に]**

1. 機能している**スタックのデプロイ CloudFormation **アクションを含む[ワークフロー](workflow.md)があることを確認します。詳細については、「[CloudFormation スタックのデプロイ](deploy-action-cfn.md)」を参照してください。

1. **スタックロール - スタックのデプロイアクションのオプション**フィールドで指定されたロールに、**CloudWatchFullAccess** アクセス許可を必ず含めてください。 ** CloudFormation **必要なアクセス許可を持つロールの作成の詳細については、「[ステップ 2: AWS ロールを作成する](deploy-tut-lambda.md#deploy-tut-lambda-cfn-roles)」を参照してください。

**CloudFormation 「スタックをデプロイ」アクションのロールバックアラームを設定するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[ビジュアル]** を選択します。

1. ** CloudFormation スタックのデプロイ**アクションを選択します。

1. 詳細ペインで、**[設定]** を選択します。

1. 下部で、**[アドバンスト]** を展開します。

1. **[モニターアラーム ARN]** で、**[アラームを追加]** を選択します。

1. 次のフィールドに情報を入力します。
   + **アラーム ARN**

     ロールバックトリガーを追加するには、Amazon CloudWatch アラームの Amazon リソースネーム (ARN) を指定します。例えば、`arn:aws:cloudwatch::123456789012:alarm/MyAlarm`。最大 5 個のロールバックトリガーを持つことができます。
**注記**  
CloudWatch アラーム ARN を指定する場合は、アクションが CloudWatch にアクセスできるようにする追加のアクセス許可も設定する必要があります。詳細については、「[ロールバックの設定](#deploy-consumption-enable-alarms)」を参照してください。
   + **モニタリングタイム**

     CloudFormation が指定されたアラームをモニタリングする 0 ～ 180 分の時間を指定します。モニタリングは、すべてのスタックリソースがデプロイされた*後に*開始します。アラームが指定されたモニタリング時間内に発生した場合、デプロイは失敗し、CloudFormation はスタックオペレーション全体をロールバックします。

     デフォルト: 0。CloudFormation は、スタックリソースがデプロイされている間だけアラームをモニタリングします。その後はモニタリングしません。

------
#### [ YAML ]

**CloudFormation 「スタックをデプロイ」アクションのロールバックトリガーを設定するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. **[ CloudFormation スタックをデプロイ]** アクションを含むワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[YAML]** を選択します。

1. ロールバックトリガーを追加するには、YAML コードに `monitor-alarm-arns` および `monitor-timeout-in-minutes` プロパティを追加します。各プロパティの説明については、「[CloudFormation 「スタックをデプロイ」アクション YAML](deploy-action-ref-cfn.md)」を参照してください。

1. ** CloudFormation スタックのデプロイ**アクションの `role-arn`プロパティで指定されたロールに、**CloudWatchFullAccess** アクセス許可を必ず含めてください。必要なアクセス許可を持つロールの作成の詳細については、「[ステップ 2: AWS ロールを作成する](deploy-tut-lambda.md#deploy-tut-lambda-cfn-roles)」を参照してください。

------

------
#### [ Visual ]

**CloudFormation 「スタックのデプロイ」アクションのロールバックを無効にするには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. **[ CloudFormation スタックをデプロイ]** アクションを含むワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[ビジュアル]** を選択します。

1. ** CloudFormation スタックのデプロイ**アクションを選択します。

1. 詳細ペインで、**[設定]** を選択します。

1. 下部で、**[アドバンスト]** を展開します。

1. **[ロールバックを無効化]** をオンにします。

------
#### [ YAML ]

**CloudFormation 「スタックのデプロイ」アクションのロールバックを無効にするには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. **[ CloudFormation スタックをデプロイ]** アクションを含むワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[YAML]** を選択します。

1. ロールバックを停止するには、YAML コードに `disable-rollback: 1` プロパティを追加します。この動作の説明については、「[CloudFormation 「スタックをデプロイ」アクション YAML](deploy-action-ref-cfn.md)」を参照してください。

------

# CloudFormation 「スタックをデプロイ」変数
<a name="deploy-action-cfn-variables"></a>

** CloudFormation スタックのデプロイ**アクションは、実行時に次の変数を生成して設定します。これらは*事前定義済み変数*と呼ばれます。

ワークフローでこれらの変数を参照する方法については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください


| キー | 値 | 
| --- | --- | 
|  deployment-platform  |  デプロイプラットフォームの名前。 `AWS:CloudFormation` にハードコードされています。  | 
|  リージョン  |  ワークフローの実行中に にデプロイ AWS リージョン された のリージョンコード。 例: `us-west-2`  | 
|  stack-id  |  デプロイジョブの Amazon リソースネーム (ARN)。 例: `arn:aws:cloudformation:us-west-2:111122223333:stack/codecatalyst-cfn-stack/6aad4380-100a-11ec-a10a-03b8a84d40df`  | 

# CloudFormation 「スタックをデプロイ」アクション YAML
<a name="deploy-action-ref-cfn"></a>

** CloudFormation スタックのデプロイ**アクションの YAML 定義を次に示します。このアクションの使用方法については、「[CloudFormation スタックのデプロイ](deploy-action-cfn.md)」を参照してください。

このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。

**注記**  
後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティとともに一覧表示されます。

```
# The workflow definition starts here.
# See 最上位プロパティ for details.
        
Name: MyWorkflow
SchemaVersion: 1.0 
Actions:

# The action definition starts here.    
  DeployCloudFormationStack:  
    Identifier: aws/cfn-deploy@v1
    DependsOn:
      - build-action
    Compute:  
      Type: EC2 | Lambda
      Fleet: fleet-name
    Timeout: timeout-minutes
    Environment:
      Name: environment-name
      Connections:
        - Name: account-connection-name
          Role: DeployRole
    Inputs:
      Sources:
        - source-name-1
      Artifacts:
        - CloudFormation-artifact
    Configuration:
      name: stack-name
      region: us-west-2
      template: template-path
      role-arn: arn:aws:iam::123456789012:role/StackRole        
      capabilities: CAPABILITY_IAM,CAPABILITY_NAMED_IAM,CAPABILITY_AUTO_EXPAND
      parameter-overrides: KeyOne=ValueOne,KeyTwo=ValueTwo | path-to-JSON-file
      no-execute-changeset: 1|0
      fail-on-empty-changeset: 1|0
      disable-rollback: 1|0
      termination-protection: 1|0
      timeout-in-minutes: minutes
      notification-arns: arn:aws:sns:us-east-1:123456789012:MyTopic,arn:aws:sns:us-east-1:123456789012:MyOtherTopic
      monitor-alarm-arns: arn:aws:cloudwatch::123456789012:alarm/MyAlarm,arn:aws:cloudwatch::123456789012:alarm/MyOtherAlarm
      monitor-timeout-in-minutes: minutes       
      tags: '[{"Key":"MyKey1","Value":"MyValue1"},{"Key":"MyKey2","Value":"MyValue2"}]'
```

## DeployCloudFormationStack
<a name="deploy.action.cfn.deploycloudformationstack"></a>

(必須)

アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名の特殊文字とスペースを有効にすることはできません。

デフォルト: `DeployCloudFormationStack_nn`。

対応する UI: [設定] タブ/**[アクション表示名]**

## Identifier
<a name="deploy.action.cfn.identifier"></a>

(*DeployCloudFormationStack*/**Identifier**)

(必須)

アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。

デフォルト: `aws/cfn-deploy@v1`。

対応する UI: ワークフロー図/DeployCloudFormationStack\$1nn/**aws/cfn-deploy@v1** ラベル

## DependsOn
<a name="deploy.action.cfn.dependson"></a>

(*DeployCloudFormationStack*/**DependsOn**)

(オプション)

このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。

「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。

対応する UI: [入力] タブ/**[依存 - オプション]**

## Compute
<a name="deploy.action.cfn.computename"></a>

(*DeployCloudFormationStack*/**Compute**)

(オプション)

ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。

対応する UI: *[なし]*

## Type
<a name="deploy.action.cfn.computetype"></a>

(*DeployCloudFormationStack*/Compute/**Type**)

([Compute](#deploy.action.cfn.computename) が含まれている場合は必須)

コンピューティングエンジンのタイプです。次のいずれかの値を使用できます。
+ **EC2** (ビジュアルエディタ) または `EC2` (YAML エディタ)

  アクション実行時の柔軟性を目的として最適化されています。
+ **Lambda** (ビジュアルエディタ) または `Lambda` (YAML エディタ)

  アクションの起動速度を最適化しました。

コンピューティングタイプの詳細については、「[コンピューティングタイプ](workflows-working-compute.md#compute.types)」を参照してください。

対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングタイプ]**

## Fleet
<a name="deploy.action.cfn.computefleet"></a>

(*DeployCloudFormationStack*/Compute/**Fleet**)

(オプション)

ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。

プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。

`Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。

対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングフリート]**

## Timeout
<a name="deploy.action.cfn.timeout"></a>

(*DeployCloudFormationStack*/**Timeout**)

(オプション)

CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。

対応する UI: [設定] タブ/**[分単位のタイムアウト - オプション]**

## Environment
<a name="deploy.action.cfn.environment"></a>

(*DeployCloudFormationStack*/**Environment**)

(必須)

アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウント およびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用して に接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。

**注記**  
デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。

環境タグ付けの詳細については、「[AWS アカウント と VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

対応する UI: [設定] タブ/**[環境]**

## Name
<a name="deploy.action.cfn.environment.name"></a>

(*DeployCloudFormationStack*/Environment/**Name**)

([Environment](#deploy.action.cfn.environment) が含まれている場合は必須)

アクションに関連付ける既存の環境の名前を指定します。

対応する UI: [設定] タブ/**[環境]**

## Connections
<a name="deploy.action.cfn.environment.connections"></a>

(*DeployCloudFormationStack*/Environment/**Connections**)

(新しいバージョンのアクションでは任意。古いバージョンでは必須)

アクションに関連付けるアカウント接続を指定します。`Environment` で最大 1 つのアカウント接続を指定できます。

アカウント接続を指定しない場合:
+ アクションは、CodeCatalyst コンソールの環境で指定された AWS アカウント 接続とデフォルトの IAM ロールを使用します。アカウント接続とデフォルトの IAM ロールを環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。
+ デフォルトの IAM ロールには、アクションに必要なポリシーとアクセス許可が含まれている必要があります。これらのポリシーとアクセス許可を確認するには、アクションの YAML 定義ドキュメントの **[ロール]** プロパティの説明を参照してください。

アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。アカウント接続を環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]**

## Name
<a name="deploy.action.cfn.environment.connections.name"></a>

(*DeployCloudFormationStack*/Environment/Connections/**Name**)

([Connections](#deploy.action.cfn.environment.connections) が含まれている場合は必須)

アカウント接続の名前を指定します。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]**

## Role
<a name="deploy.action.cfn.environment.connections.role"></a>

(*DeployCloudFormationStack*/Environment/Connections/**Role**)

([Connections](#deploy.action.cfn.environment.connections) が含まれている場合は必須)

** CloudFormation スタックのデプロイ**アクションが AWS および CloudFormation サービスにアクセスするために使用する IAM ロールの名前を指定します。[ロールを CodeCatalyst スペース に追加](ipa-connect-account-addroles.md)し、ロールに次のポリシーが含まれていることを確認します。

IAM ロールを指定しない場合、アクションは CodeCatalyst コンソールの [[環境]](deploy-environments.md) に記載されているデフォルトの IAM ロールを使用します。環境でデフォルトのロールを使用する場合は、次のポリシーがあることを確認してください。
+ 以下のアクセス許可ポリシー:
**警告**  
アクセス許可は、次のポリシーに示すアクセス許可に制限します。より広範なアクセス許可を持つロールを使用すると、セキュリティリスクが発生する可能性があります。
**注記**  
ロールを初めて使用するとき、リソースポリシーステートメントで次のワイルドカードを使用し、使用可能になった後にリソース名でポリシーをスコープダウンします。  

  ```
  "Resource": "*"
  ```
+ 次のカスタム信頼ポリシー:

**注記**  
必要に応じて、このアクションで `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[ロール]**

## Inputs
<a name="deploy.action.cfn.inputs"></a>

(*DeployCloudFormationStack*/**Inputs**)

(オプション)

`Inputs` セクションでは、ワークフローの実行中に `DeployCloudFormationStack` に必要なデータを定義します。

**注記**  
**Deploy CloudFormation スタック**アクションごとに最大 4 つの入力 (1 つのソースと 3 つのアーティファクト) が許可されます。

異なる入力 (ソースとアーティファクトなど) にあるファイルを参照する必要がある場合、ソース入力はプライマリ入力で、アーティファクトはセカンダリ入力になります。セカンダリ入力内のファイルへの参照には、プライマリからファイルを区別するための特別なプレフィックスが付きます。詳細については、「[例: 複数のアーティファクトでのファイルの参照](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file)」を参照してください。

対応する UI: **[入力] タブ**

## Sources
<a name="deploy.action.cfn.inputs.sources"></a>

(*DeployCloudFormationStack*/Inputs/**Sources**)

(CloudFormation または AWS SAM テンプレートがソースリポジトリに保存されている場合は必須)

CloudFormation または AWS SAM テンプレートがソースリポジトリに保存されている場合は、そのソースリポジトリのラベルを指定します。現在サポートされているラベルは、`WorkflowSource` のみです。

CloudFormation または AWS SAM テンプレートがソースリポジトリに含まれていない場合は、別のアクションによって生成されたアーティファクト、または Amazon S3 バケットに存在する必要があります。

sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。

対応する UI: 入力タブ/**ソース - オプション**

## Artifacts - input
<a name="deploy.action.cfn.inputs.artifacts"></a>

(*DeployCloudFormationStack*/Inputs/**Artifacts**)

(CloudFormation または AWS SAM テンプレートが前のアクションの[出力アーティファクト](workflows-working-artifacts-output.md)に保存されている場合に必要です)

デプロイする CloudFormation または AWS SAM テンプレートが、前のアクションによって生成されたアーティファクトに含まれている場合は、ここでそのアーティファクトを指定します。CloudFormation テンプレートがアーティファクトに含まれていない場合は、ソースリポジトリまたは Amazon S3 バケットに存在する必要があります。

アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。

対応する UI: [設定] タブ/**[アーティファクト - オプション]**

## Configuration
<a name="deploy.action.cfn.configuration"></a>

(*DeployCloudFormationStack*/**Configuration**)

(必須)

アクションの設定プロパティを定義できるセクション。

対応する UI: **[設定]** タブ

## name
<a name="deploy.action.cfn.stackname"></a>

(*DeployCloudFormationStack*/Configuration/**name**)

(必須)

**[ CloudFormation スタックをデプロイ]** アクションが作成または更新する CloudFormation スタックの名前を指定します。

対応する UI: [設定] タブ/**[スタック名]**

## region
<a name="deploy.action.cfn.stackregion"></a>

(*DeployCloudFormationStack*/Configuration/**region**)

(必須)

スタックをデプロイする AWS リージョン を指定します。リージョンコードの一覧については、「[リージョンエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes)」を参照してください。

対応する UI: [設定] タブ/**[スタックリージョン]**

## template
<a name="deploy.action.cfn.templatepath"></a>

(*DeployCloudFormationStack*/Configuration/**template**)

(必須)

CloudFormation または AWS SAM テンプレートファイルの名前とパスを指定します。テンプレートは JSON または YAML 形式にすることができ、ソースリポジトリ、以前のアクションのアーティファクト、または Amazon S3 バケットに格納できます。テンプレートファイルがソースリポジトリまたはアーティファクトにある場合、パスはソースまたはアーティファクトルートを基準としています。テンプレートが Amazon S3 バケットにある場合、パスはテンプレートの **[オブジェクト URL]** 値です。

例:

`./MyFolder/MyTemplate.json`

`MyFolder/MyTemplate.yml`

`https://MyBucket.s3.us-west-2.amazonaws.com/MyTemplate.yml`

**注記**  
テンプレートのファイルパスにプレフィックスを追加して、見つけるアーティファクトまたはソースを示す必要がある場合があります。詳細については、「[ソースリポジトリファイルの参照](workflows-sources-reference-files.md)」および「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。

対応する UI: [設定] タブ/**[テンプレート]**

## role-arn
<a name="deploy.action.cfn.stackrolearn"></a>

(*DeployCloudFormationStack*/Configuration/**role-arn**)

(必須)

スタックロールの Amazon リソースネーム (ARN) を指定します。CloudFormation はこのロールを使用して、スタック内のリソースにアクセスして変更します。例: `arn:aws:iam::123456789012:role/StackRole`。

スタックロールに以下が含まれていることを確認します。
+ 1 つ以上のアクセス許可ポリシー。ポリシーは、スタックにあるリソースによって異なります。たとえば、スタックに AWS Lambda 関数が含まれている場合は、Lambda へのアクセスを許可するアクセス許可を追加する必要があります。[チュートリアル: サーバーレスアプリケーションをデプロイする](deploy-tut-lambda.md) で説明されているチュートリアルに従った場合、「[スタックロールを作成するには](deploy-tut-lambda.md#deploy-tut-lambda-cfn-roles-stack)」というタイトルの手順が含まれています。この手順には、一般的なサーバーレスアプリケーションスタックをデプロイする場合にスタックロールが必要とするアクセス許可が一覧表示されます。
**警告**  
スタック内のリソースにアクセスするために CloudFormation サービスが必要とするアクセス許可に制限します。より広範なアクセス許可を持つロールを使用すると、セキュリティリスクが発生する可能性があります。
+ 次の信頼ポリシーを使用します。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Sid": "",
              "Effect": "Allow",
              "Principal": {
                  "Service": "cloudformation.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
          }
      ]
  }
  ```

------

必要に応じて、このロールをアカウント接続に関連付けます。IAM ロールとアカウント接続の関連付けの詳細については、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。スタックロールをアカウント接続に関連付けない場合、スタックロールはビジュアルエディタの **[スタックロール]** ドロップダウンリストに表示されません。ただし、ロール ARN は YAML エディタを使用して `role-arn` フィールドで指定できます。

**注記**  
必要に応じて、このアクションで `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。

対応する UI: [設定] タブ/**[スタックロール - オプション]**

## capabilities
<a name="deploy.action.cfn.capabilities"></a>

(*DeployCloudFormationStack*/Configuration/**capabilities**)

(必須)

が特定のスタック CloudFormation を作成するために必要な IAM 機能のリストを指定します。ほとんどの場合、`CAPABILITY_IAM,CAPABILITY_NAMED_IAM,CAPABILITY_AUTO_EXPAND` のデフォルト値は `capabilities` のままにすることができます。

**[ CloudFormation スタックをデプロイ]** アクションのログに `##[error] requires capabilities: [capability-name]` が表示された場合は、「[IAM 機能エラーを解決するにはどうすればよいですか?](troubleshooting-workflows.md#troubleshooting-workflows-capabilities)」を参照して問題を解決する方法を確認してください。

IAM 機能の詳細については、[「IAM ユーザーガイド」の CloudFormation 「 テンプレートでの IAM リソースの承認](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html#using-iam-capabilities)」を参照してください。 **

対応する UI: [設定] タブ/アドバンスト/**[機能]**

## parameter-overrides
<a name="deploy.action.cfn.parameter.overrides"></a>

(*DeployCloudFormationStack*/Configuration/**parameter-overrides**)

(オプション)

デフォルト値を持たない CloudFormation 、またはデフォルト値以外の値を指定するパラメータを または AWS SAM テンプレートで指定します。パラメータの詳細については、 * AWS CloudFormation ユーザーガイド*の[「パラメータ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html)」を参照してください。

`parameter-overrides` プロパティは以下を受け入れます。
+ パラメータと値を含む JSON ファイル。
+ パラメータと値のカンマ区切りリスト。

**JSON ファイルを指定するには**

1. JSON ファイルで次のいずれかの構文を使用していることを確認します。

   ```
   {
     "Parameters": {
       "Param1": "Value1",
       "Param2": "Value2",
       ...
     }
   }
   ```

   または…

   ```
   [
     {
        "ParameterKey": "Param1",
        "ParameterValue": "Value1"
     },
     ...
   ]
   ```

   (他の構文もありますが、記述時に CodeCatalyst ではサポートされていません。) JSON ファイルで CloudFormation パラメータを指定する方法の詳細については、「*AWS CLI コマンドリファレンス*」の「[サポートされている JSON 構文](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudformation/deploy/index.html#supported-json-syntax)」を参照してください。

1. 次のいずれかの形式を使用して、JSON ファイルへのパスを指定します。
   + JSON ファイルが前のアクションの出力アーティファクトに存在する場合は、以下を使用します。

     `file:///artifacts/current-action-name/output-artifact-name/path-to-json-file`

     詳細については、「**例 1**」を参照してください。
   + JSON ファイルがソースリポジトリにある場合は、以下を使用します。

     `file:///sources/WorkflowSource/path-to-json-file`

     詳細については、「**例 2**」を参照してください。

     **例 1** – JSON ファイルは出力アーティファクトにあります

     ```
     ##My workflow YAML
     ...
     Actions:
       MyBuildAction:
         Identifier: aws/build@v1
         Outputs:
           Artifacts:
             - Name: ParamArtifact
               Files:
                 - params.json
         Configuration:
         ...
       MyDeployCFNStackAction:
         Identifier: aws/cfn-deploy@v1
         Configuration:
           parameter-overrides: file:///artifacts/MyDeployCFNStackAction/ParamArtifact/params.json
     ```

     **例 2** – JSON ファイルは、ソースリポジトリの「`my/folder`」という名前のフォルダにあります。

     ```
     ##My workflow YAML
     ...
     Actions:
       MyDeployCloudFormationStack:
         Identifier: aws/cfn-deploy@v1
         Inputs:
           Sources:
             - WorkflowSource
         Configuration:
           parameter-overrides: file:///sources/WorkflowSource/my/folder/params.json
     ```

**パラメータのカンマ区切りリストを使用するには**
+ 次の形式を使用して、`parameter-overrides` プロパティにパラメータ名と値のペアを追加します。

  `param-1=value-1,param-2=value-2`

  たとえば、次の CloudFormation テンプレートがあるとします。

  ```
  ##My CloudFormation template
  
  Description: My CloudFormation template
  
  Parameters:
    InstanceType:
      Description: Defines the Amazon EC2 compute for the production server.
      Type: String
      Default: t2.micro
      AllowedValues:
        - t2.micro
        - t2.small
        - t3.medium
      
  Resources:
  ...
  ```

  ...`parameter-overrides` プロパティは次のように設定できます。

  ```
  ##My workflow YAML
  ...
  Actions:
  ...
    DeployCloudFormationStack:
      Identifier: aws/cfn-deploy@v1
      Configuration:
        parameter-overrides: InstanceType=t3.medium,UseVPC=true
  ```
**注記**  
パラメータ名は、`undefined` を値として使用して、対応する値なしで指定できます。例えば、次のようになります。  
`parameter-overrides: MyParameter=undefined`  
 スタックの更新中に、CloudFormation は指定されたパラメータ名に既存のパラメータ値を使用するという効果があります。

対応する UI:
+ [設定] タブ/アドバンスト/**[パラメータのオーバーライド]**
+ ファイルを使用して[設定] タブ/アドバンスト/パラメータオーバーライド/**[オーバーライドを指定]**
+ 値セットを使用して[設定] タブ/アドバンスト/パラメータオーバーライド/**値セットを使用してオーバーライドを指定**

## no-execute-changeset
<a name="deploy.action.cfn.noexecutechangeset"></a>

(*DeployCloudFormationStack*/Configuration/**no-execute-changeset**)

(オプション)

CodeCatalyst で CloudFormation 変更セットを作成し、実行する前に停止するかどうかを指定します。これにより、CloudFormation コンソールで変更セットを確認できます。変更セットが正常に見える場合は、このオプションを無効にしてからワークフローを再実行し、CodeCatalyst が停止することなく変更セットを作成および実行できるようにします。デフォルトでは、停止せずに変更セットを作成して実行します。詳細については、*AWS CLI 「 コマンドリファレンス」の* CloudFormation [「deploy](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html) パラメータ」を参照してください。変更セットの表示の詳細については、「*AWS CloudFormation ユーザーガイド*」の「[変更セットの表示](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets-view.html)」を参照してください。

対応する UI: [設定] タブ/詳細/**[実行なしの変更セット]**

## fail-on-empty-changeset
<a name="deploy.action.cfn.failonemptychangeset"></a>

(*DeployCloudFormationStack*/Configuration/**fail-on-empty-changeset**)

(オプション)

CloudFormation 変更セットが空の場合、CodeCatalyst が** CloudFormation スタックのデプロイ**アクションを失敗させるかどうかを指定します。(変更セットが空の場合、最新のデプロイ中にスタックに変更が行われなかったことを意味します。) デフォルトでは、変更セットが空の場合にアクションを続行し、スタックが更新されていなくても `UPDATE_COMPLETE` メッセージを返すことを許可します。

この設定の詳細については、*AWS CLI 「 コマンドリファレンス*」の CloudFormation [「deploy](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html) パラメータ」を参照してください。変更セットの詳細については、「*AWS CloudFormation ユーザーガイド*」の「[変更セットを使用したスタックの更新](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html)」を参照してください。

対応する UI: [設定] タブ/アドバンスト/**[空の変更セットで失敗]**

## disable-rollback
<a name="deploy.action.cfn.disablerollback"></a>

(*DeployCloudFormationStack*/Configuration/**disable-rollback**)

(オプション)

CodeCatalyst がスタックデプロイに失敗した場合にロールバックするかどうかを指定します。ロールバックは、スタックを最後に既知の安定状態に戻します。デフォルトでは、ロールバックを有効にします。この設定の詳細については、*AWS CLI 「 コマンドリファレンス*」の CloudFormation [「deploy](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html) パラメータ」を参照してください。

** CloudFormation スタックのデプロイ**アクションがロールバックを処理する方法の詳細については、「」を参照してください[ロールバックの設定](deploy-consumption-enable-alarms.md)。

スタックのロールバックの詳細については、*「AWS CloudFormation ユーザーガイド*」の「[スタック失敗オプション](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stack-failure-options.html)」を参照してください。

対応する UI: [設定] タブ/アドバンスト/**[ロールバックを無効化]**

## termination-protection
<a name="deploy.action.cfn.terminationprotection"></a>

(*DeployCloudFormationStack*/Configuration/**termination-protection**)

(オプション)

**Deploy CloudFormation スタック**で、デプロイするスタックに終了保護を追加するかどうかを指定します。削除保護を有効にした状態でスタックを削除しようとすると、削除は失敗し、ステータスを含め、スタックが変更されることはありません。終了保護はデフォルトで無効になっています。詳細については、「*AWS CloudFormation ユーザーガイド*」の「[スタックが削除されないように保護する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-protect-stacks.html)」を参照してください。

対応する UI: [設定] タブ/アドバンスト/**[終了保護]**

## timeout-in-minutes
<a name="deploy.action.cfn.timeoutinminutes"></a>

(*DeployCloudFormationStack*/Configuration/**timeout-in-minutes**)

(オプション)

CloudFormation がスタック作成オペレーションのタイムアウトまでに割り当て、スタックのステータスを `CREATE_FAILED` に設定する時間を分で指定します。CloudFormation が割り当てられた時間内にスタック全体を作成できない場合、スタックの作成がタイムアウトで失敗し、スタックはロールバックされます。

デフォルトでは、スタックの作成にタイムアウトはありません。ただし、個々のリソースには、実装するサービスの性質に基づいて、独自のタイムアウトがある可能性があります。例えば、スタック内の個々のリソースがタイムアウトになった場合、スタックの作成に指定されたタイムアウトに到達していない場合でも、スタックの作成もタイムアウトになります。

対応する UI: [設定] タブ/アドバンスト/**[CloudFormation タイムアウト]**

## notification-arns
<a name="deploy.action.cfn.notificationarns"></a>

(*DeployCloudFormationStack*/Configuration/**notification-arns**)

(オプション)

CodeCatalyst が通知メッセージを送信する Amazon SNS トピックの ARN を指定します。例えば、`arn:aws:sns:us-east-1:111222333:MyTopic`。** CloudFormation スタックのデプロイ**アクションが実行されると、CodeCatalyst は CloudFormation と連携して、スタックの作成または更新プロセス中に発生する CloudFormation イベントごとに 1 つの通知を送信します。(イベントは、スタックの CloudFormation コンソールの**イベント**タブに表示されます）。最大 5 つのトピックを追加できます。詳細については、「[Amazon SNS とは](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」を参照してください。

対応する UI: [設定] タブ/アドバンスト/**[通知 ARN]**

## monitor-alarm-arns
<a name="deploy.action.cfn.monitoralarmarns"></a>

(*DeployCloudFormationStack*/Configuration/**monitor-alarm-arns**)

(オプション)

ロールバックトリガーを追加するには、Amazon CloudWatch アラームの Amazon リソースネーム (ARN) を指定します。例えば、`arn:aws:cloudwatch::123456789012:alarm/MyAlarm`。最大 5 個のロールバックトリガーを持つことができます。

**注記**  
CloudWatch アラーム ARN を指定する場合は、アクションが CloudWatch にアクセスできるようにする追加のアクセス許可も設定する必要があります。詳細については、「[ロールバックの設定](deploy-consumption-enable-alarms.md)」を参照してください。

対応する UI: [設定] タブ/アドバンスト/**[モニターアラーム ARN]**

## monitor-timeout-in-minutes
<a name="deploy.action.cfn.monitortimeinminutes"></a>

(*DeployCloudFormationStack*/Configuration/**monitor-timeout-in-minutes**)

(オプション)

CloudFormation が指定されたアラームをモニタリングする 0 ～ 180 分の時間を指定します。モニタリングは、すべてのスタックリソースがデプロイされた*後に*開始します。アラームが指定されたモニタリング時間内に発生した場合、デプロイは失敗し、CloudFormation はスタックオペレーション全体をロールバックします。

デフォルト: 0。CloudFormation は、スタックリソースがデプロイされている間だけアラームをモニタリングします。その後はモニタリングしません。

対応する UI: [設定] タブ/アドバンスト/**[モニタリング時間]**

## tags
<a name="deploy.action.cfn.tags"></a>

(*DeployCloudFormationStack*/Configuration/**tags**)

(オプション)

CloudFormation スタックにアタッチするタグを指定します。タグは、コスト配分など、スタックを識別する目的で使用できる任意のキーと値のペアです。タグとその使用方法の詳細については、「Amazon EC2 ユーザーガイド」の「[リソースのタグ付け](https://docs.aws.amazon.com/)」を参照してください。CloudFormation でのタグ付けの詳細については、*AWS CloudFormation 「 ユーザーガイド*」の[CloudFormation 「スタックオプションの設定](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-add-tags.html)」を参照してください。

キーには英数字またはスペースを含めることができ、最大 127 文字を使用できます。値には英数字またはスペースを含めることができ、最大 255 文字を使用できます。

スタックごとに最大 50 個の一意のタグを追加できます。

対応する UI: [設定] タブ/アドバンスト/**[タグ]**

# ワークフローを使用した AWS CDK アプリケーションのデプロイ
<a name="cdk-dep-action"></a>

このセクションでは、ワークフローを使用して AWS Cloud Development Kit (AWS CDK) アプリを AWS アカウントにデプロイする方法について説明します。これを行うには、**[AWS CDK デプロイ]** アクションをワークフローに追加する必要があります。**AWS CDK デプロイ**アクションは、アプリケーションを合成してデプロイします AWS Cloud Development Kit (AWS CDK) AWS。アプリが にすでに存在する場合 AWS、アクションは必要に応じてアプリを更新します。

を使用したアプリの記述に関する一般的な情報については AWS CDK、[「 とは」を参照してください AWS CDK。](https://docs.aws.amazon.com/cdk/v2/guide/home.html) *AWS Cloud Development Kit (AWS CDK) 「 デベロッパーガイド*」の「�

**Topics**
+ [AWS CDK 「デプロイ」アクションを使用するタイミング](#cdk-dep-action-when-to-use)
+ [AWS CDK 「デプロイ」アクションの仕組み](#cdk-dep-action-how-it-works)
+ [AWS CDK 「デプロイ」アクションで使用される CDK CLI バージョン](#cdk-dep-action-cdk-version)
+ [AWS CDK 「デプロイ」アクションで使用されるランタイムイメージ](#cdk-dep-action-runtime)
+ [アクションはいくつのスタックをデプロイできますか?](#cdk-dep-action-how-many-stacks)
+ [例: AWS CDK アプリケーションのデプロイ](cdk-dep-action-example-workflow.md)
+ [AWS CDK 「デプロイ」アクションの追加](cdk-dep-action-add.md)
+ [「AWS CDK デプロイ」変数](cdk-dep-action-variables.md)
+ [「AWS CDK デプロイ」アクション YAML](cdk-dep-action-ref.md)

## AWS CDK 「デプロイ」アクションを使用するタイミング
<a name="cdk-dep-action-when-to-use"></a>

を使用してアプリケーションを開発し AWS CDK、自動継続的インテグレーションと配信 (CI/CD) ワークフローの一部として自動的にデプロイする場合は、このアクションを使用します。たとえば、誰かが AWS CDK アプリソースに関連するプルリクエストをマージするたびに、 AWS CDK アプリを自動的にデプロイできます。

## AWS CDK 「デプロイ」アクションの仕組み
<a name="cdk-dep-action-how-it-works"></a>

「**AWS CDK デプロイ**」は次のように機能します。

1. 実行時に、 アクションのバージョン 1.0.12 以前を指定した場合、アクションは最新の CDK CLI (Tookit とも呼ばれます) AWS CDK を CodeCatalyst [ランタイム環境イメージ](#cdk-dep-action-runtime)にダウンロードします。

   バージョン 1.0.13 以降を指定した場合、アクションは [特定のバージョン](#cdk-dep-action-cdk-version) の CDK CLI にバンドルされるため、ダウンロードは行われません。

1. アクションは CDK CLI を使用して `cdk deploy` コマンドを実行します。このコマンドは、 AWS CDK アプリケーションを合成してデプロイします AWS。このコマンドの詳細については、「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」の「[AWS CDK ツールキット (cdk コマンド)](https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html)」を参照してください。

## AWS CDK 「デプロイ」アクションで使用される CDK CLI バージョン
<a name="cdk-dep-action-cdk-version"></a>

次の表は、**[AWS CDK デプロイ]** アクションのさまざまなバージョンでデフォルトで使用されている CDK CLI のバージョンを示しています。

**注記**  
デフォルトを上書きできる場合があります。詳細については、「[「AWS CDK デプロイ」アクション YAML](cdk-dep-action-ref.md)」の「[CdkCliVersion](cdk-dep-action-ref.md#cdk.dep.cdk.cli.version)」を参照してください。


| 「AWS CDK デプロイ」アクションバージョン | AWS CDK CLI バージョン | 
| --- | --- | 
|  1.0.0～1.0.12  |  最新  | 
|  1.10.13 以降  |  2.99.1  | 

## AWS CDK 「デプロイ」アクションで使用されるランタイムイメージ
<a name="cdk-dep-action-runtime"></a>

次の表は、CodeCatalyst が **[AWS CDK デプロイ]** アクションのさまざまなバージョンを実行するために使用するランタイム環境イメージを示しています。イメージには、プリインストールされたさまざまなツールのセットが含まれています。詳細については、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。

**注記**  
2024 年 3 月のイメージで利用可能な最新のツールを利用するには、**[AWS CDK デプロイ]** アクションをバージョン 2.x にアップグレードすることをお勧めします。アクションをアップグレードするには、ワークフロー定義ファイルの `Identifier` プロパティを `aws/cdk-deploy@v2` に設定します。詳細については、「[「AWS CDK デプロイ」アクション YAML](cdk-dep-action-ref.md)」を参照してください。


| 「AWS CDK デプロイ」アクションバージョン | ランタイム環境イメージ | 
| --- | --- | 
|  1.x  |  2022 年 11 月のイメージ  | 
|  2.x  |  2024 年 3 月のイメージ  | 

## アクションはいくつのスタックをデプロイできますか?
<a name="cdk-dep-action-how-many-stacks"></a>

**[AWS CDK デプロイ]** は 1 つのスタックのみをデプロイできます。 AWS CDK アプリが複数のスタックで構成されている場合は、ネストされたスタックを持つ親スタックを作成し、このアクションを使用して親をデプロイする必要があります。

# 例: AWS CDK アプリケーションのデプロイ
<a name="cdk-dep-action-example-workflow"></a>

次のワークフローの例には、**[AWS CDK デプロイ]** アクションと **[AWS CDK ブートストラップ]** アクションが含まれています。ワークフローは、連続して実行される次の構成要素で構成されます。
+ **トリガー** – ソースリポジトリに変更をプッシュすると、このトリガーによってワークフローが自動的に開始されます。このリポジトリには AWS CDK アプリが含まれています。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。
+ **AWS CDK ブートストラップ**アクション (`CDKBootstrap`) – トリガー時に、アクションは`CDKToolkit`ブートストラップスタックを にデプロイします AWS。`CDKToolkit` スタックが環境内に既に存在する場合、必要に応じてアップグレードされます。それ以外の場合、何も発生せず、アクションは成功としてマークされます。
+ **AWS CDK デプロイ**アクション (`AWS CDK Deploy`) – **AWS CDK ブートストラップ**アクションが完了すると、**AWS CDK デプロイ**アクションは AWS CDK アプリケーションコードを CloudFormation テンプレートに合成し、テンプレートで定義されたスタックを にデプロイします AWS。

**注記**  
次のワークフロー例は説明を目的としており、追加の設定なしでは機能しません。

**注記**  
次の YAML コードでは、必要に応じて `Connections:` セクションを省略できます。これらのセクションを省略する場合は、環境の **[デフォルト IAM ロールフィールドで指定されたロール]** に、**[AWS CDK ブートストラップ]** アクションと **[AWS CDK デプロイ]** アクションに必要なアクセス許可と信頼ポリシーが含まれていることを確認する必要があります。デフォルトの IAM ロールを使用して環境を設定する方法の詳細については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。**[AWS CDK ブートストラップ]** アクションと **[AWS CDK デプロイ]** アクションに必要なアクセス許可と信頼ポリシーの詳細については、 [「AWS CDK ブートストラップ」アクション YAML](cdk-boot-action-ref.md) および [「AWS CDK デプロイ」アクション YAML](cdk-dep-action-ref.md) の `Role` プロパティの説明を参照してください。

```
Name: codecatalyst-cdk-deploy-workflow
SchemaVersion: 1.0

Triggers:
  - Type: PUSH
    Branches:
      - main
Actions:
  CDKBootstrap:
    Identifier: aws/cdk-bootstrap@v2
    Inputs:
      Sources:
        - WorkflowSource
    Environment:
      Name: codecatalyst-cdk-deploy-environment
      Connections:
        - Name: codecatalyst-account-connection
          Role: codecatalyst-cdk-bootstrap-role
    Configuration:
      Region: us-west-2
        
  CDKDeploy:
    Identifier: aws/cdk-deploy@v2
    DependsOn: 
      - CDKBootstrap
    Environment:
      Name: codecatalyst-cdk-deploy-environment
      Connections:
        - Name: codecatalyst-account-connection
          Role: codecatalyst-cdk-deploy-role
    Inputs:
      Sources:
        - WorkflowSource
    Configuration:
      StackName: my-app-stack
      Region: us-west-2
```

# AWS CDK 「デプロイ」アクションの追加
<a name="cdk-dep-action-add"></a>

 次の手順を使用して、**[AWS CDK デプロイ]** アクションをワークフローに追加します。

**[開始する前に]**

ワークフローに **[AWS CDK デプロイ]** アクションを追加する前に、次のタスクを完了します。

1. ** AWS CDK アプリの準備をします**。v1 または AWS CDK v2 を使用して、 でサポートされている任意のプログラミング言語で AWS CDK アプリを記述できます AWS CDK。 AWS CDK アプリファイルが次の場所で利用可能であることを確認します。
   + CodeCatalyst [[ソースリポジトリ]](source.md)、または 
   + 別のワークフローアクションによって生成された CodeCatalyst [出力アーティファクト](workflows-working-artifacts.md) 

1. ** AWS 環境をブートストラップします**。ブートストラップするには、次の操作を行います。
   + 「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」の「[ブートストラップをする方法](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-howto)」で説明されている方法のいずれかを使用します。
   + **[AWS CDK ブートストラップ]** アクションを使用します。このアクションは、**[AWS CDK デプロイ]** と同じワークフロー、または別のワークフローに追加できます。必要なリソースが配置されるように、**[AWS CDK デプロイ]** アクションを実行する前に、ブートストラップアクションが少なくとも 1 回実行されていることを確認してください。**AWS CDK ブートストラップアクションの詳細については、**「」を参照してください[ワークフローを使用して AWS CDK アプリをブートストラップする](cdk-boot-action.md)。

     ジョブのブックマークの詳細については、「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」 の「[ジョブ ブックマーク](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)」を参照してください。

------
#### [ Visual ]

**ビジュアルエディタを使用してAWS CDK 「デプロイ」アクションを追加するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[ビジュアル]** を選択します。

1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。

1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。

1. **[AWS CDK デプロイ]** アクションを検索し、次のいずれかを実行します。
   + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。

     または
   + **[AWS CDK デプロイ]** を選択します。[アクションの詳細] ダイアログボックスが表示されます。このダイアログボックスでは、次の操作を行います。
     + (オプション) **[ダウンロード]** を選択して、[アクションのソースコードを表示](workflows-view-source.md#workflows-view-source.title)します。
     + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。

1. **[入力]** タブと **[設定]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[「AWS CDK デプロイ」アクション YAML](cdk-dep-action-ref.md)」を参照してください。このリファレンスでは、各フィールド (および対応する YAML プロパティ値) について、YAML エディタとビジュアルエディタの両方で表示される詳細情報を提供しています。

1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。

1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。
**注記**  
**[AWS CDK デプロイ]** アクションが `npm install` エラーで失敗した場合、エラーを修正する方法については、「[「npm install」エラーを解決するにはどうすればよいですか?](troubleshooting-workflows.md#troubleshooting-workflows-npm)」を参照してください。

------
#### [ YAML ]

**YAML エディタを使用してAWS CDK 「デプロイ」アクションを追加するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[YAML]** を選択します。

1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。

1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。

1. **[AWS CDK デプロイ]** アクションを検索し、次のいずれかを実行します。
   + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。

     または
   + **[AWS CDK デプロイ]** を選択します。[アクションの詳細] ダイアログボックスが表示されます。このダイアログボックスでは、次の操作を行います。
     + (オプション) **[ダウンロード]** を選択して、[アクションのソースコードを表示](workflows-view-source.md#workflows-view-source.title)します。
     + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。

1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[「AWS CDK デプロイ」アクション YAML](cdk-dep-action-ref.md)」に記載されています。

1. (オプション) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。

1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。
**注記**  
**[AWS CDK デプロイ]** アクションが `npm install` エラーで失敗した場合、エラーを修正する方法については、「[「npm install」エラーを解決するにはどうすればよいですか?](troubleshooting-workflows.md#troubleshooting-workflows-npm)」を参照してください。

------

# 「AWS CDK デプロイ」変数
<a name="cdk-dep-action-variables"></a>

**[AWS CDK デプロイ]** アクションは、実行時に次の変数を生成して設定します。これらは*事前定義済み変数*と呼ばれます。

ワークフローでこれらの変数を参照する方法については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください


| キー | 値 | 
| --- | --- | 
|  stack-id  |  ワークフローの実行中に にデプロイされた AWS CDK アプリケーションスタックの Amazon リソースネーム (ARN)。 例: `arn:aws:cloudformation:us-west-2:111122223333:stack/codecatalyst-cdk-app-stack/6aad4380-100a-11ec-a10a-03b8a84d40df`  | 
|  deployment-platform  |  デプロイプラットフォームの名前。 `AWS:CloudFormation` にハードコードされています。  | 
|  リージョン  |  ワークフローの実行中に にデプロイ AWS リージョン された のリージョンコード。 例: `us-west-2`  | 
|  SKIP-DEPLOYMENT  |  の値は、ワークフローの実行中に AWS CDK アプリケーションスタックのデプロイがスキップされた`true`ことを示します。前回のデプロイ以降にスタックに変更がない場合、スタックのデプロイはスキップされます。 この変数は、値が `true` の場合にのみ生成されます。 `true` にハードコードされています。  | 
|  *CloudFormation variables*  |  前述の変数を生成するだけでなく、**[AWS CDK デプロイ]** アクションでは、*[CloudFormation]* 出力変数を後続の *[ワークフロー]* アクションで使用するワークフロー変数として公開します。デフォルトでは、このアクションは検出した最初の 4 つ (またはそれ以下の) CloudFormation 変数のみを公開します。どのアクションが公開されているかを確認するには、**[AWS CDK デプロイ]** アクションを 1 回実行し、実行の詳細ページの **[変数]** タブを確認します。**[変数]** タブに一覧表示されている変数が目的の変数でない場合は、YAML `CfnOutputVariables` プロパティを使用して異なる変数を設定できます。詳細については、「[「AWS CDK デプロイ」アクション YAML](cdk-dep-action-ref.md)」の「[CfnOutputVariables](cdk-dep-action-ref.md#cdk.dep.cfn.out) プロパティの説明」をご参照ください。  | 

# 「AWS CDK デプロイ」アクション YAML
<a name="cdk-dep-action-ref"></a>

**[AWS CDK デプロイ]** アクションの YAML 定義を次に示します。このアクションの使用方法については、「[ワークフローを使用した AWS CDK アプリケーションのデプロイ](cdk-dep-action.md)」を参照してください。

このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。

**注記**  
後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティとともに一覧表示されます。

```
# The workflow definition starts here.
# See 最上位プロパティ for details.
        
Name: MyWorkflow
SchemaVersion: 1.0 
Actions:

# The action definition starts here.   
  CDKDeploy\$1nn: 
    Identifier: aws/cdk-deploy@v2
    DependsOn:
      - CDKBootstrap
    Compute:  
      Type: EC2 | Lambda
      Fleet: fleet-name
    Timeout: timeout-minutes
    Inputs:
      # Specify a source or an artifact, but not both.
      Sources:
        - source-name-1
      Artifacts:
        - artifact-name
    Outputs:
      Artifacts:
        - Name: cdk_artifact
          Files: 
            - "cdk.out/**/*"
    Environment:
      Name: environment-name
      Connections:
        - Name: account-connection-name
          Role: iam-role-name
    Configuration:
      StackName: my-cdk-stack
      Region: us-west-2
      Tags: '{"key1": "value1", "key2": "value2"}'
      Context: '{"key1": "value1", "key2": "value2"}'
      CdkCliVersion: version
      CdkRootPath: directory-containing-cdk.json-file
      CfnOutputVariables: '["CnfOutputKey1","CfnOutputKey2","CfnOutputKey3"]'
      CloudAssemblyRootPath: path-to-cdk.out
```

## CDKDeploy
<a name="cdk.dep.name"></a>

(必須)

アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名の特殊文字とスペースを有効にすることはできません。

デフォルト: `CDKDeploy_nn`。

対応する UI: [設定] タブ/**[アクション名]**

## Identifier
<a name="cdk.dep.identifier"></a>

(*CDKDeploy*/**Identifier**)

(必須)

アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。

**注記**  
`aws/cdk-deploy@v2` を指定すると、Node.js 18 などの新しいツールを含む [2024 年](build-images.md#build.default-image) 3 月の画像でアクションが実行されます。`aws/cdk-deploy@v1` を指定すると、Node.js 16 などの古いツールを含む [2022 年 11 月のイメージ](build-images.md#build.previous-image)でアクションが実行されます。

デフォルト: `aws/cdk-deploy@v2`。

対応する UI: ワークフロー図/CDKDeploy\$1nn/**aws/cdk-deploy@v2** ラベル

## DependsOn
<a name="cdk.dep.dependson"></a>

(*CDKDeploy*/**DependsOn**)

(オプション)

このアクションを実行するために正常に実行する必要があるアクション、アクショングループを指定します。次のような **[AWS CDK ブートストラップ]** アクションを `DependsOn` プロパティで指定することをお勧めします。

```
CDKDeploy:
  Identifier: aws/cdk-deploy@v2
  DependsOn:
    - CDKBootstrap
```

**注記**  
[ブートストラップ](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)は、 AWS CDK アプリケーションをデプロイするための必須の前提条件です。ワークフローに **[AWS CDK ブートストラップ]**アクションを含めない場合は、[AWS CDK デプロイアクション] を実行する前に、 AWS CDK ブートストラップスタックをデプロイする別の方法を見つける必要があります。詳細については、「[ワークフローを使用した AWS CDK アプリケーションのデプロイ](cdk-dep-action.md)」の [AWS CDK 「デプロイ」アクションの追加](cdk-dep-action-add.md) を参照してください。

「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。

対応する UI: [入力] タブ/**[依存 - オプション]**

## Compute
<a name="cdk.dep.computename"></a>

(*CDKDeploy*/**Compute**)

(オプション)

ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。

対応する UI: *[なし]*

## Type
<a name="cdk.dep.computetype"></a>

(*CDKDeploy*/Compute/**Type**)

([Compute](#cdk.dep.computename) が含まれている場合は必須)

コンピューティングエンジンのタイプです。次のいずれかの値を使用できます。
+ **EC2** (ビジュアルエディタ) または `EC2` (YAML エディタ)

  アクション実行時の柔軟性を目的として最適化されています。
+ **Lambda** (ビジュアルエディタ) または `Lambda` (YAML エディタ)

  アクションの起動速度を最適化しました。

コンピューティングタイプの詳細については、「[コンピューティングタイプ](workflows-working-compute.md#compute.types)」を参照してください。

対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングタイプ]**

## Fleet
<a name="cdk.dep.computefleet"></a>

(*CDKDeploy*/Compute/**Fleet**)

(オプション)

ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。

プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。

`Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。

対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングフリート]**

## Timeout
<a name="cdk.dep.timeout"></a>

(*CDKDeploy*/**Timeout**)

(必須)

CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。

対応する UI: [設定] タブ/**[タイムアウト - オプション]**

## Inputs
<a name="cdk.dep.inputs"></a>

(*CDKDeploy*/**Inputs**)

(オプション)

`Inputs` セクションでは、ワークフローの実行中に `CDKDeploy` に必要なデータを定義します。

**注記**  
**[AWS CDK デプロイ]** アクションごとに 1 つの入力 (ソースまたはアーティファクト) のみが許可されます。

対応する UI: **[入力]** タブ

## Sources
<a name="cdk.dep.inputs.sources"></a>

(*CDKDeploy*/Inputs/**Sources**)

(デプロイする AWS CDK アプリがソースリポジトリに保存されている場合に必須)

 AWS CDK アプリがソースリポジトリに保存されている場合は、そのソースリポジトリのラベルを指定します。**[AWS CDK デプロイ]** アクションは、デプロイプロセスを開始する前に、このリポジトリ内のアプリケーションを合成します。現在サポートされているラベルは、`WorkflowSource` のみです。

 AWS CDK アプリがソースリポジトリに含まれていない場合は、別のアクションによって生成されたアーティファクトに存在する必要があります。

sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。

対応する UI: 入力タブ/**ソース - オプション**

## Artifacts - input
<a name="cdk.dep.inputs.artifacts"></a>

(*CDKDeploy*/Inputs/**Artifacts**)

(デプロイする AWS CDK アプリケーションが前のアクションの[出力アーティファクト](workflows-working-artifacts-output.md)に保存されている場合に必須)

前のアクションによって生成されたアーティファクトに AWS CDK アプリが含まれている場合は、ここでそのアーティファクトを指定します。**[AWS CDK デプロイ]** アクションは、デプロイプロセスを開始する前に、指定されたアーティファクト内のアプリケーションを CloudFormation テンプレートに合成します。 AWS CDK アプリがアーティファクトに含まれていない場合は、ソースリポジトリに存在する必要があります。

アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。

対応する UI: 入力タブ/**アーティファクト - オプション**

## Outputs
<a name="cdk.dep.outputs"></a>

(*CDKDeploy*/**Outputs**)

(オプション)

ワークフローの実行中にアクションによって出力されるデータを定義します。

対応する UI: **[出力]** タブ

## Artifacts - output
<a name="cdk.dep.outputs.artifacts"></a>

(*CDKDeploy*/Outputs/**Artifacts**

(オプション)

アクションによって生成されたアーティファクトを指定します。このアーティファクトは、他のアクションの入力として参照できます。

アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。

対応する UI: [出力] タブ/**[アーティファクト]**

## Name
<a name="cdk.dep.outputs.artifacts.name"></a>

(*CDKDeploy*/Outputs/Artifacts/**Name**)

([Artifacts - output](#cdk.dep.outputs.artifacts) が含まれている場合は必須)

実行時に**AWS CDK デプロイ**アクションによって合成される CloudFormation テンプレートを含むアーティファクトの名前を指定します。デフォルト値は `cdk_artifact` です。アーティファクトを指定しない場合、アクションはテンプレートを合成しますが、アーティファクトには保存されません。テストまたはトラブルシューティングの目的で、合成されたテンプレートをアーティファクトに保存して、その記録を保持することを検討してください。

対応する UI: [出力] タブ/[アーティファクト]/[アーティファクトを追加]/**[ビルドアーティファクト名]**

## Files
<a name="cdk.dep.outputs.artifacts.files"></a>

(*CDKDeploy*/Outputs/Artifacts/**Files**)

([Artifacts - output](#cdk.dep.outputs.artifacts) が含まれている場合は必須)

アーティファクトに含めるファイルを指定します。 AWS CDK アプリの合成された CloudFormation テンプレートを含める`"cdk.out/**/*"`には、 を指定する必要があります。

**注記**  
`cdk.out` は、合成されたファイルが保存されるデフォルトのディレクトリです。`cdk.json` ファイルで `cdk.out` 以外の出力ディレクトリを指定した場合は、`cdk.out` の代わりに、ここでそのディレクトリを指定します。

対応する UI: [出力] タブ/[アーティファクト]/[アーティファクトを追加]/**[ビルドで生成されるファイル]**

## Environment
<a name="cdk.dep.environment"></a>

(*CDKDeploy*/**Environment**)

(必須)

アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウント およびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用して に接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。

**注記**  
デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。

環境タグ付けの詳細については、「[AWS アカウント と VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

対応する UI: [設定] タブ/**[環境]**

## Name
<a name="cdk.dep.environment.name"></a>

(*CDKDeploy*/Environment/**Name**)

([Environment](#cdk.dep.environment) が含まれている場合は必須)

アクションに関連付ける既存の環境の名前を指定します。

対応する UI: [設定] タブ/**[環境]**

## Connections
<a name="cdk.dep.environment.connections"></a>

(*CDKDeploy*/Environment/**Connections**)

(新しいバージョンのアクションでは任意。古いバージョンでは必須)

アクションに関連付けるアカウント接続を指定します。`Environment` で最大 1 つのアカウント接続を指定できます。

アカウント接続を指定しない場合:
+ アクションは、CodeCatalyst コンソールの環境で指定された AWS アカウント 接続とデフォルトの IAM ロールを使用します。アカウント接続とデフォルトの IAM ロールを環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。
+ デフォルトの IAM ロールには、アクションに必要なポリシーとアクセス許可が含まれている必要があります。これらのポリシーとアクセス許可を確認するには、アクションの YAML 定義ドキュメントの **[ロール]** プロパティの説明を参照してください。

アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。アカウント接続を環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]**

## Name
<a name="cdk.dep.environment.connections.name"></a>

(*CDKDeploy*/Environment/Connections/**Name**)

([Connections](#cdk.dep.environment.connections) が含まれている場合は必須)

アカウント接続の名前を指定します。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]**

## Role
<a name="cdk.dep.environment.connections.role"></a>

(*CDKDeploy*/Environment/Connections/**Role**)

([Connections](#cdk.dep.environment.connections) が含まれている場合は必須)

アカウント接続の名前を指定します。

**AWS CDK デプロイ**アクションが AWS CDK アプリケーションスタックにアクセスして AWS デプロイするために使用する IAM ロールの名前を指定します。[ロールを CodeCatalyst スペース に追加](ipa-connect-account-addroles.md)し、ロールに次のポリシーが含まれていることを確認します。

IAM ロールを指定しない場合、アクションは CodeCatalyst コンソールの [[環境]](deploy-environments.md) に記載されているデフォルトの IAM ロールを使用します。環境でデフォルトのロールを使用する場合は、次のポリシーがあることを確認してください。
+ 以下のアクセス許可ポリシー:
**警告**  
アクセス許可は、次のポリシーに示すアクセス許可に制限します。範囲の広いアクセス許可を持つロールを使用すると、セキュリティリスクが発生する可能性があります。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Sid": "VisualEditor0",
              "Effect": "Allow",
              "Action": [
                  "cloudformation:DescribeStackEvents",
                  "cloudformation:DescribeChangeSet",
                  "cloudformation:DescribeStacks",
                  "cloudformation:ListStackResources"
              ],
              "Resource": "*"
          },
          {
              "Sid": "VisualEditor1",
              "Effect": "Allow",
              "Action": "sts:AssumeRole",
              "Resource": "arn:aws:iam::111122223333:role/cdk-*"
          }
      ]
  }
  ```

------
+ 次のカスタム信頼ポリシー:

**注記**  
必要に応じて、このアクションで `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[ロール]**

## Configuration
<a name="cdk.dep.configuration"></a>

(*CDKDeploy*/**Configuration**)

(必須)

アクションの設定プロパティを定義できるセクション。

対応する UI: **[設定]** タブ

## StackName
<a name="cdk.dep.stack.name"></a>

(*CDKDeploy*/Configuration/**StackName**)

(必須)

 AWS CDK アプリの `bin` ディレクトリのエントリポイントファイルに表示される AWS CDK アプリスタックの名前。次の例は、TypeScript エントリポイントファイルの内容を示し、スタック名は*赤い斜体*で強調表示されています。エントリポイントファイルが別の言語の場合、似ています。

```
import * as cdk from 'aws-cdk-lib';
import { CdkWorksopTypescriptStack } from '../lib/cdk_workshop_typescript-stack';

const app = new cdk.App();
new CdkWorkshopTypescriptStack(app, 'CdkWorkshopTypescriptStack');
```

指定できるスタックは 1 つだけです。

**ヒント**  
複数のスタックがある場合は、ネストされたスタックを使用して親スタックを作成できます。その後、このアクションで親スタックを指定して、すべてのスタックをデプロイできます。

対応する UI: [設定] タブ/**[スタック名]**

## Region
<a name="cdk.dep.region"></a>

(*CDKDeploy*/Configuration/**Region**)

(オプション)

 AWS CDK アプリケーションスタックをデプロイする AWS リージョン を指定します。リージョンコードの一覧については、「[リージョンエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes)」を参照してください。

リージョンを指定しない場合、**AWS CDK デプロイ**アクションは AWS CDK コードで指定されたリージョンにデプロイされます。詳細については、「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」の「[環境枠](https://docs.aws.amazon.com/cdk/v2/guide/environments.html)」を参照してください。

対応する UI: [設定] タブ/**[リージョン]**

## Tags
<a name="cdk.dep.tags"></a>

(*CDKDeploy*/Configuration/**Tags**)

(オプション)

 AWS CDK アプリケーションスタックの AWS リソースに適用するタグを指定します。タグは、スタック自体とスタック内の個々のリソースに適用されます。タグ付けの詳細については、「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」の「[タグ付け](https://docs.aws.amazon.com/cdk/v2/guide/tagging.html)」を参照してください。

対応する UI: [設定] タブ/[高度な設定 - オプション]/**[タグ]**

## Context
<a name="cdk.dep.context"></a>

(*CDKDeploy*/Configuration/**Context**)

(オプション)

 AWS CDK アプリケーションスタックに関連付けるコンテキストをキーと値のペアの形式で指定します。コンテキストの詳細については、「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」の「[ランタイムコンテキスト](https://docs.aws.amazon.com/cdk/v2/guide/context.html)」を参照してください。

対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンテキスト]**

## CdkCliVersion
<a name="cdk.dep.cdk.cli.version"></a>

(*CDKDeploy*/Configuration/**CdkCliVersion**)

(オプション)

このプロパティは、**[AWS CDK デプロイ]** アクションのバージョン 1.0.13 以降、および **[AWS CDK ブートストラップ]** アクションのバージョン 1.0.8 以降で使用できます。

次のいずれかを指定します。
+ このアクションで使用する AWS Cloud Development Kit (AWS CDK) コマンドラインインターフェイス (CLI) のフルバージョン (ツールキットとも呼ばれ AWS CDK ます）。例えば、`2.102.1` などです。アプリケーションのビルドとデプロイ時に一貫性と安定性を確保するため、フルバージョンを指定することを検討してください。

  または
+ `latest`。CDK CLI の最新の機能と修正を活用するには、`latest` を指定することを検討してください。

アクションは、指定されたバージョンの CLI (または最新バージョン) AWS CDK を CodeCatalyst [ビルドイメージ](build-images.md)にダウンロードし、このバージョンを使用して CDK アプリケーションのデプロイまたは環境のブートストラップ AWS に必要なコマンドを実行します。

使用できるサポートされている CDK CLI バージョンの一覧については、[[AWS CDK バージョン]](https://docs.aws.amazon.com/cdk/api/versions.html) を参照してください。

このプロパティを省略すると、アクションは次のいずれかのトピックで説明されているデフォルトの AWS CDK CLI バージョンを使用します。
+ [AWS CDK 「デプロイ」アクションで使用される CDK CLI バージョン](cdk-dep-action.md#cdk-dep-action-cdk-version) 
+ [AWS CDK 「ブートストラップ」アクションで使用される CDK CLI バージョン](cdk-boot-action.md#cdk-boot-action-cdk-version)

対応する UI: 設定タブ/**AWS CDK CLI バージョン**

## CdkRootPath
<a name="cdk.dep.cdk.root.path"></a>

(*CDKDeploy*/Configuration/**CdkRootPath**)

(オプション)

 AWS CDK プロジェクトの `cdk.json` ファイルを含むディレクトリへのパス。**[AWS CDK デプロイ]** アクションはこのフォルダから実行され、アクションによって作成された出力はこのディレクトリに追加されます。指定しない場合、**AWS CDK デプロイ**アクションは`cdk.json`ファイルが AWS CDK プロジェクトのルートにあることを前提としています。

対応する UI: [設定] タブ/**cdk.json が存在するディレクトリ**

## CfnOutputVariables
<a name="cdk.dep.cfn.out"></a>

(*CDKDeploy*/Configuration/**CfnOutputVariables**)

(オプション)

ワークフロー出力変数として公開する AWS CDK アプリケーションコード内の`CfnOutput`コンストラクトを指定します。その後、ワークフロー内の後続のアクションでワークフロー出力変数を参照できます。CodeCatalyst における変数の詳細については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。

たとえば、 AWS CDK アプリケーションコードは次のようになります。

```
import { Duration, Stack, StackProps, CfnOutput, RemovalPolicy} from 'aws-cdk-lib';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import * as s3 from 'aws-cdk-lib/aws-s3';
import { Construct } from 'constructs';
import * as cdk from 'aws-cdk-lib';
export class HelloCdkStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);
    const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', {
      removalPolicy: RemovalPolicy.DESTROY,
    });
    new CfnOutput(this, 'bucketName', {
      value: bucket.bucketName,
      description: 'The name of the s3 bucket',
      exportName: 'amzn-s3-demo-bucket',
    });
    const table = new dynamodb.Table(this, 'todos-table', {
      partitionKey: {name: 'todoId', type: dynamodb.AttributeType.NUMBER},
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
      removalPolicy: RemovalPolicy.DESTROY,
    })
    new CfnOutput(this, 'tableName', {
      value: table.tableName,
      description: 'The name of the dynamodb table',
      exportName: 'myDynamoDbTable',
    });
    ...
  }
}
```

...`CfnOutputVariables` プロパティは次のようになります。

```
Configuration:
  ...
  CfnOutputVariables: '["bucketName","tableName"]'
```

...その後、アクションは次のワークフロー出力変数を生成します。


| キー | 値 | 
| --- | --- | 
|  bucketName  |  `bucket.bucketName`  | 
|  tableName  |  `table.tableName`  | 

その後、後続のアクションで `bucketName` 変数と `tableName` 変数を参照できます。後続のアクションでワークフロー出力変数を参照する方法については、「[事前定義済み変数の参照](workflows-working-with-variables-reference-output-vars.md)」を参照してください。

`CfnOutputVariables` プロパティに `CfnOutput` コンストラクトを指定しない場合、アクションはワークフロー出力変数として検出される最初の 4 つ (またはそれ以下) の CloudFormation 出力変数を公開します。詳細については、「[「AWS CDK デプロイ」変数](cdk-dep-action-variables.md)」を参照してください。

**ヒント**  
アクションが生成するすべての CloudFormation 出力変数の一覧を取得するには、**[AWS CDK デプロイ]** アクションを含むワークフローを 1 回実行し、アクションの **[ログ]** タブを確認します。ログには、 AWS CDK アプリに関連付けられているすべての CloudFormation 出力変数のリストが含まれます。すべての CloudFormation 変数が何であるかがわかったら、`CfnOutputVariables` プロパティを使用してワークフロー出力変数に変換する変数を指定できます。

 CloudFormation 出力変数の詳細については、 *AWS Cloud Development Kit (AWS CDK) API リファレンス*の クラス CfnOutput (コンストラクト) で`CfnOutput`利用可能な コンストラクトのドキュメントを参照してください。 [ CfnOutput ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.CfnOutput.html) 

対応する UI: 設定タブ/**CloudFormation 出力変数**

## CloudAssemblyRootPath
<a name="cdk.dep.cloud"></a>

(*CDKDeploy*/Configuration/**CloudAssemblyRootPath**)

(オプション)

 AWS CDK アプリのスタックを ( `cdk synth`オペレーションを使用して) クラウドアセンブリに既に合成している場合は、クラウドアセンブリディレクトリのルートパス () を指定します`cdk.out`。指定されたクラウドアセンブリディレクトリにある CloudFormation テンプレートは、 `cdk deploy --app` コマンド AWS アカウント を使用してデプロイアクションによって に**AWS CDK デプロイ**されます。`--app` オプションが存在する場合、`cdk synth` オペレーションは実行されません。

クラウドアセンブリディレクトリを指定しない場合、**[AWS CDK デプロイ]** アクションは `--app` オプションなしで `cdk deploy` コマンドを実行します。`--app` オプションがない場合、`cdk deploy`オペレーションは (`cdk synth`) を合成し、 AWS CDK アプリを にデプロイします AWS アカウント。

**AWS CDK 「デプロイ」アクションが実行時に合成できるときに、既存の合成されたクラウドアセンブリを指定するのはなぜですか?**

既存の合成されたクラウドアセンブリを指定して、次のことを行えます。
+ **「デプロイ」アクションを実行するたびに、まったく同じリソースセットがAWS CDK デプロイされていることを確認します。**

  クラウドアセンブリを指定しない場合、**[AWS CDK デプロイ]** アクションは実行時期に応じて異なるファイルを合成してデプロイできます。例えば、**[AWS CDK デプロイ]** アクションは、テストステージ中に 1 つの依存関係のセット、および本番ステージ中に別の依存関係のセット (それらの依存関係がステージ間で変更された場合) を使用してクラウドアセンブリを合成する場合があります。テスト対象とデプロイ対象との正確なパリティを保証するには、一度合成してから、**[Path to cloud assembly directory]** フィールド (ビジュアルエディタ) または `CloudAssemblyRootPath` プロパティ (YAML エディタ) を使用して、既に合成済みのクラウドアセンブリを指定することをお勧めします。
+ ** AWS CDK アプリで非標準パッケージマネージャーとツールを使用する**

  `synth` オペレーション中、**[AWS CDK デプロイ]** アクションは npm や pip などの標準ツールを使用してアプリを実行しようとします。アクションがこれらのツールを使用してアプリを正常に実行できない場合、合成は行われず、アクションは失敗します。この問題を回避するには、アプリの `cdk.json` ファイルで AWS CDK アプリを正常に実行するために必要な正確なコマンドを指定し、**AWS CDK デプロイ**アクションを含まないメソッドを使用してアプリを合成します。クラウドアセンブリが生成されたら、**[AWS CDK デプロイ]** アクションの **[クラウドアセンブリディレクトリへのパス]** フィールド (ビジュアルエディタ) または `CloudAssemblyRootPath` プロパティ (YAML エディタ) で指定できます。

 AWS CDK アプリをインストールして実行するためのコマンドを含めるように `cdk.json` ファイルを設定する方法については、[「アプリコマンドの指定](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-app-command)」を参照してください。

`cdk deploy` および `cdk synth` コマンド、ならびに `--app` オプションの詳細については、「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」の「[スタックのデプロイ](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-deploy)」、「[スタックの合成](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-synth)」、「[合成のスキップ](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-deploy-nosynth)」を参照してください。

クラウドアセンブリの詳細については、「*AWS Cloud Development Kit (AWS CDK) API リファレンス*」の「[クラウドアセンブリ](https://docs.aws.amazon.com/cdk/api/v2/docs/cloud-assembly-schema-readme.html)」を参照してください。

対応する UI: [設定] タブ/**クラウドアセンブリディレクトリへのパス**

# ワークフローを使用して AWS CDK アプリをブートストラップする
<a name="cdk-boot-action"></a>

このセクションでは、CodeCatalyst ワークフローを使用して AWS CDK アプリケーションをブートストラップする方法について説明します。これを行うには、**[AWS CDK ブートストラップ]** アクションをワークフローに追加する必要があります。**[AWS CDK ブートストラップ]** アクションは、[[最新のテンプレート]](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-template) を使用して、 AWS 環境でブートストラップスタックをプロビジョニングします。ブートストラップスタックが既に存在する場合、アクションは必要に応じてそれを更新します。にブートストラップスタックがあること AWS は、 AWS CDK アプリケーションをデプロイするための前提条件です。

ジョブのブックマークの詳細については、「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」 の「[ジョブ ブックマーク](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)」を参照してください。

**Topics**
+ [AWS CDK 「ブートストラップ」アクションを使用するタイミング](#cdk-boot-action-when-to-use)
+ [AWS CDK 「ブートストラップ」アクションの仕組み](#cdk-boot-action-how-it-works)
+ [AWS CDK 「ブートストラップ」アクションで使用される CDK CLI バージョン](#cdk-boot-action-cdk-version)
+ [AWS CDK 「ブートストラップ」アクションで使用されるランタイムイメージ](#cdk-boot-action-runtime)
+ [例: AWS CDK アプリケーションのブートストラップ](cdk-boot-action-example-workflow.md)
+ [AWS CDK 「ブートストラップ」アクションの追加](cdk-boot-action-add.md)
+ [「AWS CDK ブートストラップ」変数](cdk-boot-action-variables.md)
+ [「AWS CDK ブートストラップ」アクション YAML](cdk-boot-action-ref.md)

## AWS CDK 「ブートストラップ」アクションを使用するタイミング
<a name="cdk-boot-action-when-to-use"></a>

 AWS CDK アプリケーションをデプロイするワークフローがあり、ブートストラップスタックを同時にデプロイ (および必要に応じて更新) する場合は、このアクションを使用します。この場合、**AWS CDK ブートストラップ**アクションを、 AWS CDK アプリケーションをデプロイするワークフローと同じワークフローに追加します。

次のいずれかに当てはまる場合は、このアクションを**使用しないでください**。
+ 既に別のメカニズムを使用してブートストラップスタックをデプロイしており、そのままにしたい (更新なし)。
+ [カスタムブートストラップテンプレート](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-customizing) を使用します。これはブート**[AWS CDK ストラップ]** アクションではサポートされていません。

## AWS CDK 「ブートストラップ」アクションの仕組み
<a name="cdk-boot-action-how-it-works"></a>

**[AWS CDK ブートストラップ]** は次のように動作します。

1. 実行時に、 アクションのバージョン 1.0.7 以前を指定した場合、アクションは最新の CDK CLI (Tookit とも呼ばれます) AWS CDK を CodeCatalyst [ビルドイメージ](build-images.md)にダウンロードします。

   バージョン 1.0.8 以降を指定した場合、アクションは [特定のバージョン](cdk-dep-action.md#cdk-dep-action-cdk-version) の CDK CLI にバンドルされるため、ダウンロードは行われません。

1. アクションは CDK CLI を使用して `cdk bootstrap` コマンドを実行します。このコマンドは、「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」の「[ブートストラップ](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)」トピックで説明されているブートストラップタスクを実行します。

## AWS CDK 「ブートストラップ」アクションで使用される CDK CLI バージョン
<a name="cdk-boot-action-cdk-version"></a>

次の表は、**[AWS CDK ブートストラップ]** アクションのさまざまなバージョンでデフォルトで使用されている CDK CLI のバージョンを示しています。

**注記**  
デフォルトを上書きできる場合があります。詳細については、「[「AWS CDK ブートストラップ」アクション YAML](cdk-boot-action-ref.md)」の「[CdkCliVersion](cdk-boot-action-ref.md#cdk.boot.cdk.cli.version)」を参照してください。


| 「AWS CDK ブートストラップ」アクションバージョン | AWS CDK CLI バージョン | 
| --- | --- | 
|  1.0.0～1.0.7  |  最新  | 
|  1.0.8 以降  |  2.99.1  | 

## AWS CDK 「ブートストラップ」アクションで使用されるランタイムイメージ
<a name="cdk-boot-action-runtime"></a>

次の表は、CodeCatalyst が **[AWS CDK ブートストラップ]** アクションのさまざまなバージョンを実行するために使用するランタイム環境イメージを示しています。イメージには、プリインストールされたさまざまなツールのセットが含まれています。詳細については、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。

**注記**  
2024 年 3 月のイメージで利用可能な最新のツールを利用するには、**[AWS CDK ブートストラップ]** アクションをバージョン 2.x にアップグレードすることをお勧めします。アクションをアップグレードするには、ワークフロー定義ファイルの `Identifier` プロパティを `aws/cdk-bootstrap@v2` に設定します。詳細については、「[「AWS CDK デプロイ」アクション YAML](cdk-dep-action-ref.md)」を参照してください。


| 「AWS CDK ブートストラップ」アクションバージョン | ランタイム環境イメージ | 
| --- | --- | 
|  1.x  |  2022 年 11 月のイメージ  | 
|  2.x  |  2024 年 3 月のイメージ  | 

# 例: AWS CDK アプリケーションのブートストラップ
<a name="cdk-boot-action-example-workflow"></a>

「**AWS CDK ** ブートストラップアクションを含むワークフローについては、「[ワークフローを使用した AWS CDK アプリケーションのデプロイ](cdk-dep-action.md)」の「[例: AWS CDK アプリケーションのデプロイ](cdk-dep-action-example-workflow.md)」を参照してください。

# AWS CDK 「ブートストラップ」アクションの追加
<a name="cdk-boot-action-add"></a>

 次の手順を使用して、「**AWS CDK ブートストラップ**」アクションをワークフローに追加します。

**[開始する前に]**

「**AWS CDK ブートストラップ**」アクションを使用する前に、 AWS CDK アプリケーションの準備が整っていることを確認してください。ブートストラップアクションは、ブートストラップの前に AWS CDK アプリケーションを合成します。アプリケーションは、 AWS CDKでサポートされている任意のプログラミング言語で記述できます。

 AWS CDK アプリファイルが次の場所で使用可能であることを確認します。
+ CodeCatalyst [[ソースリポジトリ]](source.md)、または 
+ 別のワークフローアクションによって生成された CodeCatalyst [出力アーティファクト](workflows-working-artifacts.md) 

------
#### [ Visual ]

**ビジュアルエディタを使用してAWS CDK 「ブートストラップ」アクションを追加するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[ビジュアル]** を選択します。

1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。

1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。

1. 「**AWS CDK ブートストラップ**」アクションを検索し、次のいずれかを実行します。
   + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。

     または
   + 「**AWS CDK ブートストラップ**」を選択します。[アクションの詳細] ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。
     + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。
     + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。

1. **[入力]**、**[設定]**、**[出力]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[「AWS CDK ブートストラップ」アクション YAML](cdk-boot-action-ref.md)」を参照してください。このリファレンスでは、各フィールド (および対応する YAML プロパティ値) について、YAML エディタとビジュアルエディタの両方で表示される詳細情報を提供しています。

1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。

1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。
**注記**  
**[AWS CDK ブートストラップ]** アクションが `npm install` エラーで失敗した場合、エラーを修正する方法については、「[「npm install」エラーを解決するにはどうすればよいですか?](troubleshooting-workflows.md#troubleshooting-workflows-npm)」を参照してください。

------
#### [ YAML ]

**YAML エディタを使用してAWS CDK 「ブートストラップ」アクションを追加するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[YAML]** を選択します。

1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。

1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。

1. **[AWS CDK ブートストラップ]** アクションを検索し、**[\$1]** を選択してワークフロー図に追加し、設定ペインを開きます。

1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[「AWS CDK ブートストラップ」アクション YAML](cdk-boot-action-ref.md)」に記載されています。

1. (オプション) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。

1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。
**注記**  
**[AWS CDK ブートストラップ]** アクションが `npm install` エラーで失敗した場合、エラーを修正する方法については、「[「npm install」エラーを解決するにはどうすればよいですか?](troubleshooting-workflows.md#troubleshooting-workflows-npm)」を参照してください。

------

# 「AWS CDK ブートストラップ」変数
<a name="cdk-boot-action-variables"></a>

**[AWS CDK ブートストラップ]** アクションは、実行時に次の変数を生成して設定します。これらは*事前定義済み変数*と呼ばれます。

ワークフローでこれらの変数を参照する方法については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください


| キー | 値 | 
| --- | --- | 
|  deployment-platform  |  デプロイプラットフォームの名前。 `AWS:CloudFormation` にハードコードされています。  | 
|  リージョン  |  ワークフローの実行中に AWS CDK ブートストラップスタック AWS リージョン がデプロイされた のリージョンコード。 例: `us-west-2`  | 
|  stack-id  |  デプロイされた AWS CDK ブートストラップスタックの Amazon リソースネーム (ARN)。 例: `arn:aws:cloudformation:us-west-2:111122223333:stack/codecatalyst-cdk-bootstrap-stack/6aad4380-100a-11ec-a10a-03b8a84d40df`  | 
|  SKIP-DEPLOYMENT  |  の値は、ワークフローの実行中に AWS CDK ブートストラップスタックのデプロイがスキップされた`true`ことを示します。前回のデプロイ以降にスタックに変更がない場合、スタックのデプロイはスキップされます。 この変数は、値が `true` の場合にのみ生成されます。 `true` にハードコードされています。  | 

# 「AWS CDK ブートストラップ」アクション YAML
<a name="cdk-boot-action-ref"></a>

以下は、**[AWS CDK ブートストラップ]** アクションの YAML 定義です。このアクションの使用方法については、「[ワークフローを使用して AWS CDK アプリをブートストラップする](cdk-boot-action.md)」を参照してください。

このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。

**注記**  
後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティとともに一覧表示されます。

```
# The workflow definition starts here.
# See 最上位プロパティ for details.
        
Name: MyWorkflow
SchemaVersion: 1.0 
Actions:

# The action definition starts here.    
  CDKBootstrapAction\$1nn: 
    Identifier: aws/cdk-bootstrap@v2
    DependsOn:
      - action-name
    Compute:  
      Type: EC2 | Lambda
      Fleet: fleet-name
    Timeout: timeout-minutes
    Inputs:
      # Specify a source or an artifact, but not both.
      Sources:
        - source-name-1
      Artifacts:
        - artifact-name
    Outputs:
      Artifacts:
        - Name: cdk_bootstrap_artifacts
          Files: 
            - "cdk.out/**/*"
    Environment:
      Name: environment-name
      Connections:
        - Name: account-connection-name
          Role: iam-role-name
    Configuration:
      Region: us-west-2
      CdkCliVersion: version
```

## CDKBootstrapAction
<a name="cdk.boot.name"></a>

(必須)

アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名の特殊文字とスペースを有効にすることはできません。

デフォルト: `CDKBootstrapAction_nn`。

対応する UI: [設定] タブ/**[アクション表示名]**

## Identifier
<a name="cdk.boot.identifier"></a>

(*CDKBootstrapAction*/**Identifier**)

(必須)

アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。

**注記**  
`aws/cdk-bootstrap@v2` を指定すると、Node.js 18 などの新しいツールを含む [2024 年](build-images.md#build.default-image) 3 月の画像でアクションが実行されます。`aws/cdk-bootstrap@v1` を指定すると、Node.js 16 などの古いツールを含む [2022 年 11 月のイメージ](build-images.md#build.previous-image)でアクションが実行されます。

デフォルト: `aws/cdk-bootstrap@v2`。

対応する UI: ワークフロー図/CDKBootstrapAction\$1nn/**aws/cdk-bootstrap@v2** ラベル

## DependsOn
<a name="cdk.boot.dependson"></a>

(*CDKBootstrapAction*/**DependsOn**)

(オプション)

このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。

「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。

対応する UI: [入力] タブ/**[依存 - オプション]**

## Compute
<a name="cdk.boot.computename"></a>

(*CDKBootstrapAction*/**Compute**)

(オプション)

ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。

対応する UI: *[なし]*

## Type
<a name="cdk.boot.computetype"></a>

(*CDKBootstrapAction*/Compute/**Type**)

([Compute](#cdk.boot.computename) が含まれている場合は必須)

コンピューティングエンジンのタイプです。次のいずれかの値を使用できます。
+ **EC2** (ビジュアルエディタ) または `EC2` (YAML エディタ)

  アクション実行時の柔軟性を目的として最適化されています。
+ **Lambda** (ビジュアルエディタ) または `Lambda` (YAML エディタ)

  アクションの起動速度を最適化しました。

コンピューティングタイプの詳細については、「[コンピューティングタイプ](workflows-working-compute.md#compute.types)」を参照してください。

対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングタイプ]**

## Fleet
<a name="cdk.boot.computefleet"></a>

(*CDKBootstrapAction*/Compute/**Fleet**)

(オプション)

ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。

プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。

`Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。

対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングフリート]**

## Timeout
<a name="cdk.boot.timeout"></a>

(*CDKBootstrapAction*/**Timeout**)

(必須)

CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。

対応する UI: [設定] タブ/**[タイムアウト - オプション]**

## Inputs
<a name="cdk.boot.inputs"></a>

(*CDKBootstrapAction*/**Inputs**)

(オプション)

`Inputs` セクションでは、ワークフローの実行中に **[AWS CDK ブートストラップ]** アクションに必要なデータを定義します。

対応する UI: **[入力]** タブ

**注記**  
**[AWS CDK ブートストラップ]** アクションごとに 1 つの入力 (ソースまたはアーティファクト) のみが許可されます。

## Sources
<a name="cdk.boot.inputs.sources"></a>

(*CDKBootstrapAction*/Inputs/**Sources**)

( AWS CDK アプリがソースリポジトリに保存されている場合は必須)

 AWS CDK アプリがソースリポジトリに保存されている場合は、そのソースリポジトリのラベルを指定します。**[AWS CDK ブートストラップ]** アクションは、ブートストラッププロセスを開始する前に、このリポジトリ内のアプリケーションを合成します。現在、サポートされているリポジトリラベルは `WorkflowSource` のみです。

 AWS CDK アプリがソースリポジトリに含まれていない場合は、別のアクションによって生成されたアーティファクトに存在する必要があります。

sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。

対応する UI: 入力タブ/**ソース - オプション**

## Artifacts - input
<a name="cdk.boot.inputs.artifacts"></a>

(*CDKBootstrapAction*/Inputs/**Artifacts**)

( AWS CDK アプリが前のアクションの[出力アーティファクト](workflows-working-artifacts-output.md)に保存されている場合に必要です)

 AWS CDK アプリが前のアクションによって生成されたアーティファクトに含まれている場合は、ここでそのアーティファクトを指定します。**[AWS CDK ブートストラップ]** アクションは、ブートストラッププロセスを開始する前に、指定されたアーティファクト内のアプリケーションを CloudFormation テンプレートに合成します。 AWS CDK アプリがアーティファクトに含まれていない場合は、ソースリポジトリに存在する必要があります。

アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。

対応する UI: 入力タブ/**アーティファクト - オプション**

## Outputs
<a name="cdk.boot.outputs"></a>

(*CDKBootstrapAction*/**Outputs**)

(オプション)

ワークフローの実行中にアクションによって出力されるデータを定義します。

対応する UI: **[出力]** タブ

## Artifacts - output
<a name="cdk.boot.outputs.artifacts"></a>

(*CDKBootstrapAction*/Outputs/**Artifacts**)

(オプション)

アクションによって生成されたアーティファクトを指定します。このアーティファクトは、他のアクションの入力として参照できます。

アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。

対応する UI: [出力] タブ/**[アーティファクト]**

## Name
<a name="cdk.boot.outputs.artifacts.name"></a>

(*CDKBootstrapAction*/Outputs/Artifacts/**Name**)

([Artifacts - output](#cdk.boot.outputs.artifacts) が含まれている場合は必須)

実行時に**AWS CDK ブートストラップ**アクションによって合成される CloudFormation テンプレートを含むアーティファクトの名前を指定します。デフォルト値は `cdk_bootstrap_artifacts` です。アーティファクトを指定しない場合、アクションはテンプレートを合成しますが、アーティファクトには保存されません。テストまたはトラブルシューティングの目的で、合成されたテンプレートをアーティファクトに保存して、その記録を保持することを検討してください。

対応する UI: [出力] タブ/[アーティファクト]/[アーティファクトを追加]/**[ビルドアーティファクト名]**

## Files
<a name="cdk.boot.outputs.artifacts.files"></a>

(*CDKBootstrapAction*/Outputs/Artifacts/**Files**)

([Artifacts - output](#cdk.boot.outputs.artifacts) が含まれている場合は必須)

アーティファクトに含めるファイルを指定します。 AWS CDK アプリの合成 CloudFormation されたテンプレートを含める`"cdk.out/**/*"`には、 を指定する必要があります。

**注記**  
`cdk.out` は、合成されたファイルが保存されるデフォルトのディレクトリです。`cdk.json` ファイルで `cdk.out` 以外の出力ディレクトリを指定した場合は、`cdk.out` の代わりに、ここでそのディレクトリを指定します。

対応する UI: [出力] タブ/[アーティファクト]/[アーティファクトを追加]/**[ビルドで生成されるファイル]**

## Environment
<a name="cdk.boot.environment"></a>

(*CDKBootstrapAction*/**Environment**)

(必須)

アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウント およびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用して に接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。

**注記**  
デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。

環境タグ付けの詳細については、「[AWS アカウント と VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

対応する UI: [設定] タブ/**[環境]**

## Name
<a name="cdk.boot.environment.name"></a>

(*CDKBootstrapAction*/Environment/**Name**)

([Environment](#cdk.boot.environment) が含まれている場合は必須)

アクションに関連付ける既存の環境の名前を指定します。

対応する UI: [設定] タブ/**[環境]**

## Connections
<a name="cdk.boot.environment.connections"></a>

(*CDKBootstrapAction*/Environment/**Connections**)

(新しいバージョンのアクションでは任意。古いバージョンでは必須)

アクションに関連付けるアカウント接続を指定します。`Environment` で最大 1 つのアカウント接続を指定できます。

アカウント接続を指定しない場合:
+ アクションは、CodeCatalyst コンソールの環境で指定された AWS アカウント 接続とデフォルトの IAM ロールを使用します。アカウント接続とデフォルトの IAM ロールを環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。
+ デフォルトの IAM ロールには、アクションに必要なポリシーとアクセス許可が含まれている必要があります。これらのポリシーとアクセス許可を確認するには、アクションの YAML 定義ドキュメントの **[ロール]** プロパティの説明を参照してください。

アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。アカウント接続を環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]**

## Name
<a name="cdk.boot.environment.connections.name"></a>

(*CDKBootstrapAction*/Environment/Connections/**Name**)

([Connections](#cdk.boot.environment.connections) が含まれている場合は必須)

アカウント接続の名前を指定します。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]**

## Role
<a name="cdk.boot.environment.connections.role"></a>

(*CDKBootstrapAction*/Environment/Connections/**Role**)

([Connections](#cdk.boot.environment.connections) が含まれている場合は必須)

**AWS CDK ブートストラップ**アクションがブートストラップスタックにアクセスして AWS 追加するために使用する IAM ロールの名前を指定します。[ロールを CodeCatalyst スペース に追加](ipa-connect-account-addroles.md)し、ロールに次のポリシーが含まれていることを確認します。

IAM ロールを指定しない場合、アクションは CodeCatalyst コンソールの [[環境]](deploy-environments.md) に記載されているデフォルトの IAM ロールを使用します。環境でデフォルトのロールを使用する場合は、適切なポリシーがあることを確認してください。

必要に応じて、このアクションで `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[ロール]**

## Configuration
<a name="cdk.boot.configuration"></a>

(*CDKBootstrapAction*/**Configuration**)

(必須)

アクションの設定プロパティを定義できるセクション。

対応する UI: **[設定]** タブ

## Region
<a name="cdk.boot.region"></a>

(*CDKBootstrapAction*/Configuration/**Region**)

(必須)

ブートストラップスタックをデプロイする AWS リージョン を指定します。このリージョンは、 AWS CDK アプリがデプロイされているリージョンと一致する必要があります。リージョンコードの一覧については、「[リージョンエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes)」を参照してください。

対応する UI: [設定] タブ/**[リージョン]**

## CdkCliVersion
<a name="cdk.boot.cdk.cli.version"></a>

(*CDKBootstrapAction*/Configuration/**CdkCliVersion**)

(オプション)

このプロパティは、**[AWS CDK デプロイ]** アクションのバージョン 1.0.13 以降、および **[AWS CDK ブートストラップ]** アクションのバージョン 1.0.8 以降で使用できます。

次のいずれかを指定します。
+ このアクションで使用する AWS Cloud Development Kit (AWS CDK) コマンドラインインターフェイス (CLI) のフルバージョン (ツールキットとも呼ばれ AWS CDK ます）。例えば、`2.102.1` などです。アプリケーションのビルドとデプロイ時に一貫性と安定性を確保するため、フルバージョンを指定することを検討してください。

  または
+ `latest`。CDK CLI の最新の機能と修正を活用するには、`latest` を指定することを検討してください。

アクションは、指定されたバージョンの CLI (または最新バージョン) AWS CDK を CodeCatalyst [ビルドイメージ](build-images.md)にダウンロードし、このバージョンを使用して CDK アプリケーションのデプロイまたは環境のブートストラップ AWS に必要なコマンドを実行します。

使用できるサポートされている CDK CLI バージョンの一覧については、[[AWS CDK バージョン]](https://docs.aws.amazon.com/cdk/api/versions.html) を参照してください。

このプロパティを省略すると、アクションは次のいずれかのトピックで説明されているデフォルトの AWS CDK CLI バージョンを使用します。
+ [AWS CDK 「デプロイ」アクションで使用される CDK CLI バージョン](cdk-dep-action.md#cdk-dep-action-cdk-version) 
+ [AWS CDK 「ブートストラップ」アクションで使用される CDK CLI バージョン](cdk-boot-action.md#cdk-boot-action-cdk-version)

対応する UI: 設定タブ/**AWS CDK CLI バージョン**

# ワークフローを使用して Amazon S3 にファイルを発行する
<a name="s3-pub-action"></a>

このセクションでは、CodeCatalyst ワークフローを使用してファイルを Amazon S3 に発行する方法について説明します。これを行うには、**Amazon S3 発行**アクションをワークフローに追加する必要があります。**Amazon S3 発行**アクションは、ソースディレクトリから Amazon S3 バケットにファイルをコピーします。ソースディレクトリとしては、次の場所を利用できます。
+ [ソースリポジトリ](source.md)、または 
+ 別のワークフローアクションによって生成された[出力アーティファクト](workflows-working-artifacts.md)

**Topics**
+ [「Amazon S3 発行」アクションを使用すべき場合](#s3-pub-action-when-to-use)
+ [「Amazon S3 発行」アクションで使用されるランタイムイメージ](#s3-pub-action-runtime)
+ [例: Amazon S3 にファイルを発行する](s3-pub-action-example-workflow.md)
+ [「Amazon S3 発行」アクションの追加](s3-pub-action-add.md)
+ [「Amazon S3 発行」アクションの YAML](s3-pub-action-ref.md)

## 「Amazon S3 発行」アクションを使用すべき場合
<a name="s3-pub-action-when-to-use"></a>

次の場合は、このアクションを使用します。
+ ワークフローで生成されたファイルを Amazon S3 に保存する必要があります。

  例えば、ワークフローで静的ウェブサイトをビルドして、それを Amazon S3 でホストする場合です。この場合、ワークフローには、[ビルド](build-add-action.md)アクション (サイトの HTML とサポートファイルをビルドする) と **Amazon S3 発行**アクション (ファイルを Amazon S3 にコピーする) が含まれます。
+ ソースリポジトリに含まれるファイルを Amazon S3 に保存する必要があります。

  例えば、ソースリポジトリに含まれるアプリケーションソースファイルを毎晩 Amazon S3 にアーカイブする場合です。

## 「Amazon S3 発行」アクションで使用されるランタイムイメージ
<a name="s3-pub-action-runtime"></a>

**Amazon S3 発行**アクションは、[2022 年 11 月のイメージ](build-images.md#build.previous-image)で実行されます。詳細については、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。

# 例: Amazon S3 にファイルを発行する
<a name="s3-pub-action-example-workflow"></a>

次のワークフローの例には、**Amazon S3 発行**アクションとビルドアクションが含まれています。このワークフローは、静的ドキュメントウェブサイトをビルドして、サイトがホストされる Amazon S3 に発行します。このワークフローは、連続して実行される次の構成要素で構成されます。
+ **トリガー** – ソースリポジトリに変更をプッシュすると、このトリガーによってワークフローが自動的に開始されます。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。
+ **ビルド**アクション (`BuildDocs`) – トリガーされると、アクションは静的ドキュメントウェブサイト (`mkdocs build`) をビルドし、関連する HTML ファイルとサポートメタデータを `MyDocsSite` というアーティファクトに追加します。ビルドアクションの詳細については、「[ワークフローを使用したビルド](build-workflow-actions.md)」を参照してください。
+ **Amazon S3 発行**アクション (`PublishToS3`) – ビルドアクションが完了すると、このアクションはアーティファクト `MyDocsSite` のサイトを、ホスティングのために Amazon S3 にコピーします。

**注記**  
次のワークフロー例は説明を目的としており、追加の設定なしでは機能しません。

**注記**  
次の YAML コードでは、必要に応じて `Connections:` セクションを省略できます。このセクションを省略する場合は、環境の**デフォルトの IAM ロール**フィールドで指定されたロールに、**Amazon S3 発行**アクションに必要なアクセス許可と信頼ポリシーが含まれていることを確認する必要があります。デフォルトの IAM ロールを使用して環境を設定する方法の詳細については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。**Amazon S3 発行**アクションに必要なアクセス許可と信頼ポリシーの詳細については、[「Amazon S3 発行」アクションの YAML](s3-pub-action-ref.md) の [Role](s3-pub-action-ref.md#s3.pub.environment.connections.role) プロパティの説明を参照してください。

```
Name: codecatalyst-s3-publish-workflow
SchemaVersion: 1.0

Triggers:
  - Type: PUSH
    Branches:
      - main
Actions:
  BuildDocs:
    Identifier: aws/build@v1
    Inputs:
      Sources:
        - WorkflowSource
    Configuration:
      Steps:
        - Run: echo BuildDocs started on `date`
        - Run: pip install --upgrade pip
        - Run: pip install mkdocs
        - Run: mkdocs build
        - Run: echo BuildDocs completed on `date`
    Outputs:
      Artifacts:
      - Name: MyDocsSite
        Files:
          - "site/**/*"
        
  PublishToS3:
    Identifier: aws/s3-publish@v1
    Environment:
      Name: codecatalyst-s3-publish-environment
      Connections:
        - Name: codecatalyst-account-connection
          Role: codecatalyst-s3-publish-build-role
    Inputs:
      Sources:
        - WorkflowSource
      Artifacts:
        - MyDocsSite
    Configuration:      
      DestinationBucketName: amzn-s3-demo-bucket
      SourcePath: /artifacts/PublishToS3/MyDocSite/site
      TargetPath: my/docs/site
```

# 「Amazon S3 発行」アクションの追加
<a name="s3-pub-action-add"></a>

 次の手順を使用して、**Amazon S3 発行**アクションをワークフローに追加します。

------
#### [ Visual ]

**ビジュアルエディタを使用して「Amazon S3 発行」アクションを追加するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[ビジュアル]** を選択します。

1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。

1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。

1. **[Amazon S3 発行]** アクションを検索し、次のいずれかを実行します。
   + プラス記号 (**＋**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。

     または
   + **[Amazon S3 発行]** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。
     + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。
     + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。

1. **[入力]**、**[設定]**、**[出力]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[「Amazon S3 発行」アクションの YAML](s3-pub-action-ref.md)」を参照してください。このリファレンスでは、YAML エディタとビジュアルエディタの両方に表示される各フィールド (および対応する YAML プロパティ値) に関する詳細情報を提供しています。

1. (オプション) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。

1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。

------
#### [ YAML ]

**YAML エディタを使用して「Amazon S3 発行」アクションを追加するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[YAML]** を選択します。

1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。

1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。

1. **[Amazon S3 発行]** アクションを検索し、次のいずれかを実行します。
   + プラス記号 (**＋**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。

     または
   + **[Amazon S3 発行]** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。
     + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。
     + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。

1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[「Amazon S3 発行」アクションの YAML](s3-pub-action-ref.md)」に記載されています。

1. (オプション) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。

1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。

------

# 「Amazon S3 発行」アクションの YAML
<a name="s3-pub-action-ref"></a>

以下は、**Amazon S3 発行**アクションの YAML 定義です。このアクションの使用方法については、「[ワークフローを使用して Amazon S3 にファイルを発行する](s3-pub-action.md)」を参照してください。

このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。

**注記**  
後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティとともに一覧表示されます。

```
# The workflow definition starts here.
# See 最上位プロパティ for details.
        
Name: MyWorkflow
SchemaVersion: 1.0 
Actions:

# The action definition starts here.    
  S3Publish\$1nn: 
    Identifier: aws/s3-publish@v1
    DependsOn:
      - build-action
    Compute:  
      Type: EC2 | Lambda
      Fleet: fleet-name
    Timeout: timeout-minutes
    Inputs:
      Sources:
        - source-name-1
      Artifacts:
        - artifact-name
      Variables:
        - Name: variable-name-1
          Value: variable-value-1
        - Name: variable-name-2
          Value: variable-value-2
    Environment:
      Name: environment-name
      Connections:
        - Name: account-connection-name
          Role: iam-role-name
    Configuration:
      SourcePath: my/source
      DestinationBucketName: amzn-s3-demo-bucket
      TargetPath: my/target
```

## S3Publish
<a name="s3.pub.name"></a>

(必須)

アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名の特殊文字とスペースを有効にすることはできません。

デフォルト: `S3Publish_nn`。

対応する UI: [設定] タブ/**[アクション名]**

## Identifier
<a name="s3.pub.identifier"></a>

(*S3Publish*/**Identifier**)

(必須)

アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。

デフォルト: `aws/s3-publish@v1`。

対応する UI: ワークフロー図/S3Publish\$1nn/**aws/s3-publish@v1** ラベル

## DependsOn
<a name="s3.pub.dependson"></a>

(*S3Publish*/**DependsOn**)

(オプション)

このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。

「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。

対応する UI: [入力] タブ/**[依存 - オプション]**

## Compute
<a name="s3.pub.computename"></a>

(*S3Publish*/**Compute**)

(オプション)

ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。

対応する UI: *[なし]*

## Type
<a name="s3.pub.computetype"></a>

(*S3Publish*/Compute/**Type**)

([Compute](#s3.pub.computename) が含まれている場合は必須)

コンピューティングエンジンのタイプです。次のいずれかの値を使用できます。
+ **EC2** (ビジュアルエディタ) または `EC2` (YAML エディタ)

  アクション実行時の柔軟性を目的として最適化されています。
+ **Lambda** (ビジュアルエディタ) または `Lambda` (YAML エディタ)

  アクションの起動速度を最適化しました。

コンピューティングタイプの詳細については、「[コンピューティングタイプ](workflows-working-compute.md#compute.types)」を参照してください。

対応する UI: [設定] タブ/**[コンピューティングタイプ]**

## Fleet
<a name="s3.pub.computefleet"></a>

(*S3Publish*/Compute/**Fleet**)

(オプション)

ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。

プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。

`Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。

対応する UI: [設定] タブ/**[コンピューティングフリート]**

## Timeout
<a name="s3.pub.timeout"></a>

(*S3Publish*/**Timeout**)

(必須)

CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。

対応する UI: [設定] タブ/**[タイムアウト - オプション]**

## Inputs
<a name="s3.pub.inputs"></a>

(*S3Publish*/**Inputs**)

(オプション)

`Inputs` セクションでは、ワークフローの実行中に `S3Publish` に必要なデータを定義します。

**注記**  
**AWS CDK デプロイ**アクションごとに最大 4 つの入力 (1 つのソースと 3 つのアーティファクト) が許可されます。変数はこの合計にはカウントされません。

異なる入力 (ソースとアーティファクトなど) にあるファイルを参照する必要がある場合、ソース入力はプライマリ入力で、アーティファクトはセカンダリ入力になります。セカンダリ入力内のファイルへの参照には、プライマリからファイルを区別するための特別なプレフィックスが付きます。詳細については、「[例: 複数のアーティファクトでのファイルの参照](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file)」を参照してください。

対応する UI: **入力**タブ

## Sources
<a name="s3.pub.inputs.sources"></a>

(*S3Publish*/Inputs/**Sources**)

(Amazon S3 に発行するファイルがソースリポジトリに保存されている場合は必須）

Amazon S3 に発行するファイルがソースリポジトリに保存されている場合は、そのソースリポジトリのラベルを指定します。現在サポートされているラベルは、`WorkflowSource` のみです。

Amazon S3 に発行するファイルがソースリポジトリに含まれていない場合は、別のアクションによって生成されたアーティファクトに存在する必要があります。

sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。

対応する UI: 入力タブ/**ソース - オプション**

## Artifacts - input
<a name="s3.pub.inputs.artifacts"></a>

(*S3Publish*/Inputs/**Artifacts**)

(Amazon S3 に発行するファイルが前のアクションの[出力アーティファクト](workflows-working-artifacts-output.md)に保存されている場合は必須）

Amazon S3 に発行するファイルが、前のアクションによって生成されたアーティファクトに含まれている場合は、ここでそのアーティファクトを指定します。ファイルがアーティファクトに含まれていない場合は、ソースリポジトリに存在する必要があります。

アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。

対応する UI: [設定] タブ/**[アーティファクト - オプション]**

## Variables - input
<a name="s3.pub.inputs.variables"></a>

(*S3Publish*/Inputs/**Variables**)

(オプション)

アクションで使用できるようにしたい入力変数を定義する名前と値のペアのシーケンスを指定します。変数名に使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、変数名で特殊文字とスペースを有効にすることはできません。

変数の詳細 (例を含む) については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。

対応する UI: [入力] タブ/**[変数 - オプション]**

## Environment
<a name="s3.pub.environment"></a>

(*S3Publish*/**Environment**)

(必須)

アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウント およびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用して に接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。

**注記**  
デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。

環境タグ付けの詳細については、「[AWS アカウント と VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

対応する UI: [設定] タブ/**[環境]**

## Name
<a name="s3.pub.environment.name"></a>

(*S3Publish*/Environment/**Name**)

([Environment](#s3.pub.environment) が含まれている場合は必須)

アクションに関連付ける既存の環境の名前を指定します。

対応する UI: [設定] タブ/**[環境]**

## Connections
<a name="s3.pub.environment.connections"></a>

(*S3Publish*/Environment/**Connections**)

(新しいバージョンのアクションでは任意。古いバージョンでは必須)

アクションに関連付けるアカウント接続を指定します。`Environment` で最大 1 つのアカウント接続を指定できます。

アカウント接続を指定しない場合:
+ アクションは、CodeCatalyst コンソールの環境で指定された AWS アカウント 接続とデフォルトの IAM ロールを使用します。アカウント接続とデフォルトの IAM ロールを環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。
+ デフォルトの IAM ロールには、アクションに必要なポリシーとアクセス許可が含まれている必要があります。これらのポリシーとアクセス許可を確認するには、アクションの YAML 定義ドキュメントの **[ロール]** プロパティの説明を参照してください。

アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。アカウント接続を環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]**

## Name
<a name="s3.pub.environment.connections.name"></a>

(*S3Publish*/Environment/Connections/**Name**)

([Connections](#s3.pub.environment.connections) が含まれている場合は必須)

アカウント接続の名前を指定します。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]**

## Role
<a name="s3.pub.environment.connections.role"></a>

(*S3Publish*/Environment/Connections/**Role**)

([Connections](#s3.pub.environment.connections) が含まれている場合は必須)

**Amazon S3 発行**アクションがアクセスおよび Amazon S3 へのファイル AWS のコピーに使用する IAM ロールの名前を指定します。 Amazon S3 [ロールを CodeCatalyst スペース に追加](ipa-connect-account-addroles.md)し、ロールに次のポリシーが含まれていることを確認します。

IAM ロールを指定しない場合、アクションは CodeCatalyst コンソールの [[環境]](deploy-environments.md) に記載されているデフォルトの IAM ロールを使用します。環境でデフォルトのロールを使用する場合は、次のポリシーがあることを確認してください。
+ 以下のアクセス許可ポリシー:
**警告**  
アクセス許可は、次のポリシーに示すアクセス許可に制限します。範囲の広いアクセス許可を持つロールを使用すると、セキュリティリスクが発生する可能性があります。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Sid": "VisualEditor0",
              "Effect": "Allow",
              "Action": [
                  "s3:PutObject",
                  "s3:ListBucket",
                  "s3:DeleteObject"
              ],
              "Resource": [
                  "arn:aws:s3:::bucket-name",
                  "arn:aws:s3:::bucket-name/*"
              ]
          }
      ]
  }
  ```

------
+ 次のカスタム信頼ポリシー:

**注記**  
必要に応じて、このアクションで `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。

対応する UI: アクションのバージョンに応じて、次のいずれか。
+ (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]**
+ (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[ロール]**

## Configuration
<a name="s3.pub.configuration"></a>

(*S3Publish*/**Configuration**)

(必須)

アクションの設定プロパティを定義できるセクション。

対応する UI: **[設定]** タブ

## SourcePath
<a name="s3.pub.source.directory"></a>

(*S3Publish*/Configuration/**SourcePath**)

(必須)

Amazon S3 に発行するディレクトリまたはファイルの名前とパスを指定します。ディレクトリまたはファイルは、ソースリポジトリまたは前のアクションからのアーティファクトに存在します。ソースリポジトリまたはアーティファクトのルートへの相対パスを指定します。

例:

`./myFolder/` を指定すると、`/myFolder` の中身が Amazon S3 にコピーされ、内部のディレクトリ構造は保持されます。

`./myFolder/myfile.txt` を指定すると、`myfile.txt` *のみ*が Amazon S3 にコピーされます。（ディレクトリ構造は削除されます。）

ワイルドカードは使用できません。

**注記**  
ディレクトリまたはファイルパスにプレフィックスを追加して、見つけるアーティファクトまたはソースを示す必要がある場合があります。詳細については、「[ソースリポジトリファイルの参照](workflows-sources-reference-files.md)」および「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。

対応する UI: [設定] タブ/**[ソースパス]**

## DestinationBucketName
<a name="s3.pub.dest.bucket"></a>

(*S3Publish*/Configuration/**DestinationBucketName**)

(必須)

ファイルを発行する Amazon S3 バケットの名前を指定します。

対応する UI: [設定] タブ/**[送信先バケット - オプション]**

## TargetPath
<a name="s3.pub.dest.directory"></a>

(*S3Publish*/Configuration/**TargetPath**)

(オプション)

ファイルを発行する Amazon S3 のディレクトリの名前とパスを指定します。ディレクトリが存在しない場合は作成されます。ディレクトリパスにバケット名を含めることはできません。

例:

`myS3Folder`

`./myS3Folder/myS3Subfolder`

対応する UI: [設定] タブ/**[送信先ディレクトリ - オプション]**

# AWS アカウント と VPCs へのデプロイ
<a name="deploy-environments"></a>

[CodeCatalyst ワークフロー](workflow.md)を使用すると、アプリケーションやその他のリソースをデプロイして、 AWS クラウド内の と Amazon VPC AWS アカウントをターゲットにできます。 VPCs これらのデプロイを有効にするには、CodeCatalyst 環境を設定する必要があります。

CodeCatalyst *環境*は、[開発環境](https://docs.aws.amazon.com/codecatalyst/latest/userguide/devenvironment.html)と混同されないように、CodeCatalyst [ワークフロー](workflow.md)が接続するターゲット AWS アカウント とオプションの Amazon VPC を定義します。環境は、ターゲットアカウント内の AWS サービスとリソースにアクセスするためにワークフローが必要とする [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)も定義します。

複数の環境をセットアップし、開発、テスト、ステージング、本番稼働などの名前を付けることができます。これらの環境にデプロイすると、デプロイに関する情報が環境の CodeCatalyst **[デプロイアクティビティ]** と **[デプロイターゲット]** タブに表示されます。

## 環境の使用を開始するにはどうすればよいですか？
<a name="deploy-environments-get-started"></a>

CodeCatalyst 環境を追加および使用する大まかなステップは次のとおりです。

1. CodeCatalyst スペースで、**1 つ以上の AWS アカウントを接続します**。このプロセス中に、ワークフローが AWS アカウントのリソースにアクセスするために必要な IAM ロールを追加します。詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。

1. CodeCatalyst プロジェクトで、**ステップ 1 の と IAM ロールのいずれかを含む環境を作成します**。 AWS アカウント詳細については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

1. CodeCatalyst プロジェクトで、ワークフローに、ステップ 2 で作成した**環境を指す [[アクション]](workflows-actions.md) を追加します**。詳細については、「[ワークフローへのアクションの追加](workflows-add-action.md)」を参照してください。

   これで環境が設定されました。アクションは、 環境で指定された AWS アカウント にリソースをデプロイできるようになりました。

**注記**  
Amazon VPC を環境に追加することもできます。詳細については、「*CodeCatalyst 管理ガイド*」と「[VPC と環境の関連付け](deploy-environments-associate-vpc.md)」の「[スペースの VPC 接続の追加](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)」を参照してください。

## 1 つのワークフロー内に複数の環境が存在する可能性がありますか？
<a name="deploy-environments-multiple"></a>

はい。ワークフローに複数のアクションが含まれている場合、それらの各アクションに環境を割り当てることができます。例えば、2 つのデプロイアクションを含むワークフローがあるとします。1 つは `my-staging-enviroment` 環境を、もう 1 つは `my-production-environment` 環境を割り当てます。

## 環境をサポートするワークフローアクションはどれですか？
<a name="deploy-environments-supported"></a>

リソースを AWS クラウドにデプロイするワークフローアクション、または他の理由 (モニタリングやレポートなど) で AWS サービスと通信するワークフローアクションは、環境をサポートします。

## CodeCatalyst にデプロイ情報を表示することをサポートするアクションはどれですか？
<a name="deploy-environments-supported-targets"></a>

環境をサポートするワークフローアクションのうち、CodeCatalyst コンソールの **[デプロイアクティビティ]** と **[デプロイターゲット]** ページにデプロイ情報が表示されるのはごく少数です。

次のワークフローアクションは、デプロイ情報の表示をサポートします。
+ ** CloudFormation スタックをデプロイする** – 詳細については、「」を参照してください。 [CloudFormation スタックのデプロイ](deploy-action-cfn.md)
+ **Amazon ECS をデプロイ** – 詳細については、「[ワークフローを使用した Amazon ECS へのデプロイ](deploy-action-ecs.md)」を参照してください。
+ **Kubernetes クラスターにデプロイ**する – 詳細については、「[ワークフローを使用して Amazon EKS にデプロイする](deploy-action-eks.md)」を参照してください。
+ **AWS CDK デプロイ** – 詳細については、「」を参照してください。 [ワークフローを使用した AWS CDK アプリケーションのデプロイ](cdk-dep-action.md)

## サポート対象のリージョン
<a name="deploy-environments-supported-regions"></a>

**[環境]** ページには、任意の AWS リージョンのリソースを表示できます。

## 環境は必須ですか？
<a name="deploy-environments-optional-or-mandatory"></a>

環境は、割り当てられたワークフローアクションがリソースを AWS クラウドにデプロイする場合や、その他の理由 (モニタリングやレポートなど) で AWS サービスと通信する場合に必須です。

たとえば、アプリケーションを構築するビルドアクションがあっても、 AWS アカウント または Amazon VPC と通信する必要がない場合は、アクションに環境を割り当てる必要はありません。ただし、ビルドアクションが AWS アカウントの Amazon CloudWatch サービスにログを送信する場合は、アクションに環境を割り当てる必要があります。

**Topics**
+ [環境の使用を開始するにはどうすればよいですか？](#deploy-environments-get-started)
+ [1 つのワークフロー内に複数の環境が存在する可能性がありますか？](#deploy-environments-multiple)
+ [環境をサポートするワークフローアクションはどれですか？](#deploy-environments-supported)
+ [CodeCatalyst にデプロイ情報を表示することをサポートするアクションはどれですか？](#deploy-environments-supported-targets)
+ [サポート対象のリージョン](#deploy-environments-supported-regions)
+ [環境は必須ですか？](#deploy-environments-optional-or-mandatory)
+ [環境を作成する](deploy-environments-creating-environment.md)
+ [環境とアクションの関連付け](deploy-environments-add-app-to-environment.md)
+ [VPC と環境の関連付け](deploy-environments-associate-vpc.md)
+ [環境 AWS アカウント への の関連付け](deploy-environments-associate-account.md)
+ [アクションの IAM ロールの変更](deploy-environments-switch-role.md)

# 環境を作成する
<a name="deploy-environments-creating-environment"></a>

以下の手順に従って、後でワークフローアクションに関連付けることができる環境を作成します。

**[開始する前に]**

また、以下も必要になります。
+ CodeCatalyst スペース。詳細については、「[CodeCatalyst をセットアップしてサインインするCodeCatalyst をセットアップしてサインインする](setting-up-topnode.md)」を参照してください。
+ CodeCatalyst プロジェクト。詳細については、「[ブループリントを使用したプロジェクトの作成](projects-create.md#projects-create-console-template)」を参照してください。
+ ワークフローアクションがアクセスする必要がある IAM ロールを含む AWS アカウント接続 AWS。アカウント接続と作成の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。環境ごとに最大 1 つのアカウント接続を使用できます。
**注記**  
アカウント接続なしで環境を作成できますが、後で接続に戻って追加する必要があります。
+ 次のいずれかの CodeCatalyst ロール:
  + **スペース管理者**
  + **プロジェクト管理者**
  + **寄稿者**
**注記**  
**[Contributor ロール]** がある場合は、環境を作成できますが、 AWS アカウント 接続に関連付けることはできません。環境を AWS アカウント 接続に関連付けるには、**スペース管理者**または**プロジェクト管理者**ロールを持つユーザーに依頼する必要があります。

   ロールとアクセス許可の詳細については、「[ユーザーにプロジェクトアクセス許可を付与する](projects-members.md)」を参照してください。

**環境を作成する方法**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで、**[CI/CD]**、**[環境]** の順に選択します。

1. **[環境名]** に、**Production** や **Staging** などの名前を入力します。

1. **[環境タイプ]** で、次のいずれかを選択します。
   + **非本番環境** – アプリケーションをテストして、本番環境に移行する前に意図したとおりに動作していることを確認することができる環境。
   + **本番稼働用** - 公開され、完成したアプリケーションをホストする「ライブ」環境。

     **[本番稼働用]** を選択すると、環境が関連付けられているアクションの横にある UI に **[本番稼働用]** バッジが表示されます。このバッジは、本番稼働環境にデプロイされているアクションをすばやく確認できます。バッジの外観を除き、本番稼働環境と非本番稼働環境の間に違いはありません。

1. (オプション) **[説明]**で、「**Production environment for the hello-world app**」のような説明を入力します。

1. **AWS アカウント 接続 - オプション**で、この環境に関連付ける AWS アカウント接続を選択します。環境に割り当てられたワークフローアクションが AWS アカウントに接続できるようになります。CodeCatalyst で AWS アカウント 接続を作成する方法の詳細については、「」を参照してください[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)。

   使用する AWS アカウント 接続がリストされていない場合は、プロジェクトで許可されていない可能性があります。詳細については、「*Amazon CodeCatalyst 管理者ガイド*」の「[プロジェクト制限アカウント接続の設定](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html)」を参照してください。

1. **[デフォルトの IAM ロール]** で、この環境に関連付ける IAM ロールを選択します。この環境に割り当てられたワークフローアクションはこの IAM ロールを継承し、これを使用して のサービスとリソースに接続できます AWS アカウント。

   環境を複数のアクションに割り当てる必要があり、これらのアクションにここで指定したデフォルトとは異なる IAM ロールが必要な場合は、**[ロールの切り替え]** オプションを使用して、各アクションの **[設定]** タブで異なるロールを指定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。

   デフォルトとして使用する IAM ロールが表示されていない場合は、まだ AWS アカウント 接続に追加していない可能性があります。アカウント接続に IAM ロールを追加するには、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。

1. (オプション) **[VPC 接続]** で、この環境に関連付ける VPC 接続を選択します。VPC 接続の作成の詳細については、「*Amazon CodeCatalyst 管理者ガイド*」の「[Amazon Virtual Private Clouds の管理](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.html)」を参照してください。

   使用する VPC 接続が表示されていない場合は、プロジェクトで許可されていない AWS アカウント 接続が含まれている可能性があります。詳細については、「*Amazon CodeCatalyst 管理者ガイド*」の「[プロジェクト制限アカウント接続の設定](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html)」を参照してください。

1. [**環境を作成**] を選択します。CodeCatalyst は空の環境を作成します。

**次の手順**
+ 環境を作成したら、ワークフローアクションに関連付ける準備が整いました。詳細については、「[環境とアクションの関連付け](deploy-environments-add-app-to-environment.md)」を参照してください。

# 環境とアクションの関連付け
<a name="deploy-environments-add-app-to-environment"></a>

[サポートされているワークフローアクション](deploy-environments.md#deploy-environments-supported)に環境を関連付けると、環境の AWS アカウント、デフォルトの IAM ロール、およびオプションの Amazon VPC がアクションに割り当てられます。その後、アクションは IAM ロールを使用して AWS アカウント に接続してデプロイし、オプションの Amazon VPC にも接続できます。

環境をアクションに関連付けるには、次の手順に従います。

## ステップ 1: 環境をワークフローアクションに関連付ける
<a name="deploy-environments-add-app-to-environment-assoc"></a>

環境をワークフローアクションに関連付けるには、次の手順に従います。

------
#### [ Visual ]

**ビジュアルエディタを使用して環境をワークフローアクションに関連付けるには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[ビジュアル]** を選択します。

1. ワークフロー図で、環境でサポートされているアクションを選択します。詳細については、「[CodeCatalyst にデプロイ情報を表示することをサポートするアクションはどれですか？](deploy-environments.md#deploy-environments-supported-targets)」を参照してください。

1. **[設定]** タブを選択し、次のように **[環境]** フィールドに情報を指定します。

   **環境**

   アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウント およびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用して に接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。
**注記**  
デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。

   環境タグ付けの詳細については、「[AWS アカウント と VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。

1. (オプション) アクションに関連付けられた IAM ロールを変更します。アクションのアクセス許可のセットが間違っている場合は、ロールを変更できます。

    ロールを作成するには:

   1. 「***my-environment* とは？**」ボックスで、縦楕円アイコン (![\[Ellipsis.\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/flows/elipsis.png)) を選択します。

   1. 次のいずれかを選択します。
      +  **[ロールの切り替え]** このオプションを選択すると、このアクションで使用される IAM ロールが変更され、このアクションのみが変更されます。その他のアクションでは、引き続き、関連付けられた環境で指定されたデフォルトの IAM ロールを使用します。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。
      +  **[環境を編集]** 環境に表示されるデフォルトの IAM ロールを変更するには、このオプションを選択します。このオプションを選択すると、アクション、および同じ環境に関連付けられている他のアクションは、新しいデフォルトの IAM ロールを使用して開始します。
**重要**  
デフォルトの IAM ロールを更新するときは注意してください。ロールを変更すると、環境を共有するすべてのアクションに対してロールのアクセス許可が十分でない場合、アクションが失敗する可能性があります。

1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。

1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。

------
#### [ YAML ]

**YAML エディタを使用して環境をワークフローアクションに関連付けるには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[YAML]** を選択します。

1. 環境に関連付けるワークフローアクションで、次のようなコードを追加します。

   ```
   action-name:
     Environment:
       Name: environment-name
   ```

   詳細については、トピック「[アクションタイプ](workflows-actions.md#workflows-actions-types)」を参照してください。このトピックには、YAML リファレンスを含む各アクションのドキュメントへのリンクが含まれています。

1. (オプション) 環境に一覧表示されているデフォルトの IAM ロールとは異なるロールをアクションで使用する場合は、使用するロールを含む `Connections:` セクションを追加します。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。

1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。

1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。

------

## ステップ 2: デプロイアクティビティページを入力する
<a name="deploy-environments-add-app-to-environment-run"></a>

環境をワークフローアクションに関連付けると、CodeCatalyst コンソールの **[環境]** セクションの **[デプロイアクティビティ]** と **[デプロイターゲット]** ページにデプロイ情報を入力できます。以下の手順に従って、これらのページを入力します。

**注記**  
CodeCatalyst コンソールにデプロイ情報が表示されるのは、いくつかのアクションのみです。詳細については、「[CodeCatalyst にデプロイ情報を表示することをサポートするアクションはどれですか？](deploy-environments.md#deploy-environments-supported-targets)」を参照してください。

**CodeCatalyst にデプロイ情報を追加するには**

1. [ステップ 1: 環境をワークフローアクションに関連付ける](#deploy-environments-add-app-to-environment-assoc) で変更をコミットしたときにワークフローの実行が自動的に開始しない場合は、次のように手動で実行を開始します。

   1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

   1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

   1. **[Run]** (実行) を選択します。

   ワークフローの実行により新しいデプロイが開始し、CodeCatalyst がデプロイ情報を CodeCatalyst に追加します。

1. デプロイアクティビティが CodeCatalyst コンソールに追加されていることを確認します。

   1. ナビゲーションペインで、**[CI/CD]**、**[環境]** の順に選択します。

   1. 環境を選択します (例: `Production`)。

   1. **[デプロイアクティビティ]** タブを選択し、デプロイの **[ステータス]** が **[成功しました]** であることを確認します。これは、ワークフローの実行がアプリケーションリソースを正常にデプロイしたことを示します。

   1. **[デプロイターゲット]** タブを選択し、アプリケーションリソースが表示されることを確認します。

# VPC と環境の関連付け
<a name="deploy-environments-associate-vpc"></a>

アクションが VPC 接続を持つ環境で構成されている場合、アクションは VPC に接続して実行され、関連する VPC によって指定されたネットワークルールとアクセスリソースに従います。同じ VPC 接続を 1 つ以上の環境で使用できます。

VPC 接続を環境に関連付けるには、次の手順を使用します。

**VPC 接続を環境に関連付けるには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで、**[CI/CD]**、**[環境]** の順に選択します。

1. 環境を選択します (例: `Production`)。

1. **[環境プロパティ]** タブを選択します。

1. **[VPC 接続を管理]** を選択し、目的の VPC 接続を選択し、**[確認]** を選択します。これにより、選択した VPC 接続がこの環境に関連付けられます。
**注記**  
使用する VPC 接続が表示されていない場合は、プロジェクトで許可されていない AWS アカウント 接続が含まれている可能性があります。詳細については、「*Amazon CodeCatalyst 管理者ガイド*」の「[プロジェクト制限アカウント接続の設定](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html)」を参照してください。

詳細については、「*CodeCatalyst 管理者ガイド*」の「[Amazon Virtual Private Clouds の管理](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.html)」を参照してください。

# 環境 AWS アカウント への の関連付け
<a name="deploy-environments-associate-account"></a>

環境 AWS アカウント と を関連付けるには、次の手順を使用します。を環境に関連付ける AWS アカウント と、環境に割り当てられたワークフローアクションが に接続できるようになります AWS アカウント。

アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。

**[開始する前に]**

また、以下も必要になります。
+ ワークフローアクションがアクセスする必要がある IAM ロールを含む AWS アカウント接続 AWS。アカウント接続と作成の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。環境ごとに最大 1 つのアカウント接続を使用できます。
+ 次のいずれかの CodeCatalyst ロール: **[スペース管理者]** または **[プロジェクト管理者]**。詳細については、「[ユーザーにプロジェクトアクセス許可を付与する](projects-members.md)」を参照してください。

**AWS アカウント を 環境に関連付けるには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで、**[CI/CD]**、**[環境]** の順に選択します。

1. 環境を選択します (例: `Production`)。

1. **[環境を編集]** を選択します。

1. **[環境プロパティ]** で、**[AWS アカウント 接続 - オプション]** ドロップダウンリストで、目的の AWS アカウントを選択します。

   使用する AWS アカウント 接続がリストされていない場合は、プロジェクトで許可されていない可能性があります。詳細については、「*Amazon CodeCatalyst 管理者ガイド*」の「[プロジェクト制限アカウント接続の設定](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html)」を参照してください。

1. **[デフォルトの IAM ロール]** で、この環境に関連付ける IAM ロールを選択します。この環境に割り当てられたワークフローアクションはこの IAM ロールを継承し、これを使用して のサービスとリソースに接続できます AWS アカウント。

   デフォルトとして使用する IAM ロールが表示されていない場合は、まだ AWS アカウント 接続に追加していない可能性があります。アカウント接続に IAM ロールを追加するには、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。

# アクションの IAM ロールの変更
<a name="deploy-environments-switch-role"></a>

デフォルトでは、[[環境]](deploy-environments.md) をワークフロー[アクション](workflows-actions.md)に関連付けると、アクションは環境で指定されたデフォルトの IAM ロールを継承します。この動作は、アクションが別のロールを使用するように変更できます。デフォルトの IAM ロールに、アクションが AWS クラウドで動作するために必要なアクセス許可がない場合、アクションに別のロールを使用させる場合があります。

アクションに別の IAM ロールを割り当てるには、ビジュアルエディタで **[ロールの切り替え]** オプションを使用するか、YAML エディタで `Connections:` プロパティを使用します。新しいロールは、環境で指定されたデフォルトの IAM ロールを上書きし、デフォルトの IAM ロールをそのまま保持できます。デフォルトの IAM ロールを使用する他のアクションがある場合は、そのままにしておくことをお勧めします。

以下の手順に従って、環境内で指定されたロールとは異なる IAM ロールを使用するようにアクションを設定します。

------
#### [ Visual ]

**アクションに別の IAM ロールを割り当てるには (ビジュアルエディタ)**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. 更新する IAM ロールのアクションを表すボックスを選択します。

1. **[設定]** タブを選択します。

1. 「***my-environment* とは？**」ボックスで、縦楕円アイコン (![\[Ellipsis.\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/flows/elipsis.png)) を選択します。

1. **[ロールの切り替え]** を選択します。

1. **[ロールの切り替え]** ダイアログボックスの **[IAM ロール]** ドロップダウンリストで、アクションで使用する IAM ロールを選択します。このロールは、環境内のデフォルトの IAM ロールを上書きします。使用するロールが一覧にない場合は、必ずスペースに追加してください。詳細については、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。

   選択したロールが、「***my-environment* とは？**」ボックスと **[ワークフローで定義済み]** に表示されます。ロールは、`Connections:` セクションのワークフロー定義ファイルにも表示されます。

1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。

1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。

------
#### [ YAML ]

**アクションに別の IAM ロールを割り当てるには (YAML エディタ）**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[編集]** を選択します。

1. **[YAML]** を選択します。

1. 別の IAM ロールを使用するワークフローアクションで、次のような `Connections:` セクションを追加します。

   ```
   action-name:
     Environment:
       Name: environment-name
       Connections: 
         - Name: account-connection-name
           Role: iam-role-name
   ```

   上記のコードでは、*[account-connection-name]* を IAM ロールを含む [[アカウント接続]](ipa-connect-account.md) の名前に置き換え、*[iam-role-name]* をアクションで使用する IAM ロールの名前に置き換えます。このロールは、環境内のデフォルトの IAM ロールを上書きします。スペースにロールを追加していることを確認してください。詳細については、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。

   詳細については、トピック「[アクションタイプ](workflows-actions.md#workflows-actions-types)」を参照してください。このトピックには、YAML リファレンスを含む各アクションのドキュメントへのリンクが含まれています。

------

# ワークフロー図でのアプリケーション URL の表示
<a name="deploy-app-url"></a>

ワークフローでアプリケーションをデプロイする場合は、アプリケーションの URL をクリック可能なリンクとして表示するように Amazon CodeCatalyst を設定できます。このリンクは、CodeCatalyst コンソールにデプロイしたアクション内に表示されます。次のワークフロー図は、アクションの下部に表示される **[アプリを表示]** URL を示しています。

![\[アプリ URL を表示する\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/deploy/view-app-url.png)


CodeCatalyst コンソールでこの URL をクリック可能にすることで、アプリケーションのデプロイをすばやく確認できます。

**注記**  
アプリ URL は、**[Amazon ECS にデプロイ]** アクションではサポートされていません。

この機能を有効にするには、`appurl`、または `endpointurl` を含む名前で出力変数をアクションに追加します。名前は、結合ダッシュ (`-`）、アンダースコア (`_`)、またはスペース (` `) の有無にかかわらず使用できます。文字列は大文字と小文字を区別しません。変数の値をデプロイされたアプリケーションの `http` または `https` URL に設定します。

**注記**  
既存の出力変数を更新して `app url` または `endpoint url` 文字列を含める場合は、この変数へのすべての参照を更新して新しい変数名を使用します。

詳細については、以下に記載される手順を参照してください。
+ [AWS CDK 「デプロイ」アクションでアプリ URL を表示するには](#deploy-app-url-cdk)
+ [CloudFormation 「スタックのデプロイ」アクションでアプリ URL を表示するには](#deploy-app-url-cfn)
+ [他のすべてのアクションでアプリ URL を表示するには](#deploy-app-url-other)

URL の設定が完了したら、以下の手順に従って、URL が期待どおりに表示されることを確認します。
+ [アプリケーション URL が追加されたことを確認するには](#deploy-app-url-verify)<a name="deploy-app-url-cdk"></a>

**AWS CDK 「デプロイ」アクションでアプリ URL を表示するには**

1. **AWS CDK デプロイ**アクションを使用している場合は、 AWS CDK アプリケーションコードに`CfnOutput`コンストラクト (キーと値のペア) を追加します。
   + キー名には、結合ダッシュ (`-`)、アンダースコア (`_`)、またはスペース (` `) の有無にかかわらず、`appurl` または `endpointurl` を含める必要があります。文字列は大文字と小文字を区別しません。
   + 値は、デプロイされたアプリケーションの `http` または `https` URL である必要があります。

   たとえば、 AWS CDK コードは次のようになります。

   ```
   import { Duration, Stack, StackProps, CfnOutput, RemovalPolicy} from 'aws-cdk-lib';
   import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
   import * as s3 from 'aws-cdk-lib/aws-s3';
   import { Construct } from 'constructs';
   import * as cdk from 'aws-cdk-lib';
   export class HelloCdkStack extends Stack {
     constructor(scope: Construct, id: string, props?: StackProps) {
       super(scope, id, props);
       const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', {
         removalPolicy: RemovalPolicy.DESTROY,
       });
       new CfnOutput(this, 'APP-URL', {
         value: https://mycompany.myapp.com,
         description: 'The URL of the deployed application',
         exportName: 'myApp',
       });
       ...
     }
   }
   ```

   `CfnOutput` コンストラクトの詳細については、「*AWS Cloud Development Kit (AWS CDK) API リファレンス*」の「[インターフェイス CfnOutputProps](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.CfnOutputProps.html)」を参照してください。

1. コードを保存してコミットします。

1. [アプリケーション URL が追加されたことを確認するには](#deploy-app-url-verify) に進みます。<a name="deploy-app-url-cfn"></a>

**CloudFormation 「スタックのデプロイ」アクションでアプリ URL を表示するには**

1. ** CloudFormation スタックのデプロイ**アクションを使用している場合は、CloudFormation テンプレートまたは AWS SAM テンプレートの `Outputs`セクションに、次の特性を持つ出力を追加します。
   + キー (ロジカル ID とも呼ばれます) には、結合ダッシュ (`-`)、アンダースコア (`_`)、またはスペース (` `) の有無にかかわらず、`appurl` または `endpointurl` を含める必要があります。文字列は大文字と小文字を区別しません。
   + 値は、デプロイされたアプリケーションの `http` または `https` URL である必要があります。

   例えば、CloudFormation テンプレートは次のようになります。

   ```
   "Outputs" : {
     "APP-URL" : {
       "Description" : "The URL of the deployed app",
       "Value" : "https://mycompany.myapp.com",
       "Export" : {
         "Name" : "My App"
       }
     }
   }
   ```

   CloudFormation の詳細については、「*AWS CloudFormation ユーザーガイド*」の「[出力](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html)」を参照してください。

1. コードを保存してコミットします。

1. [アプリケーション URL が追加されたことを確認するには](#deploy-app-url-verify) に進みます。<a name="deploy-app-url-other"></a>

**他のすべてのアクションでアプリ URL を表示するには**

ビルドアクションや **[GitHub アクション]** などの別のアクションを使用してアプリケーションをデプロイする場合は、次の操作を実行してアプリケーション URL を表示します。

1. ワークフロー定義ファイルのアクションの `Inputs` または `Steps` セクションで環境変数を定義します。変数には次の特性が必要です。
   + `name` には、結合ダッシュ (`-`)、アンダースコア (`_`)、またはスペース (` `) の有無にかかわらず、`appurl` または `endpointurl` を含める必要があります。文字列は大文字と小文字を区別しません。
   + 値は、デプロイされたアプリケーションの `http` または `https` URL である必要があります。

   例えば、ビルドアクションは次のようになります。

   ```
   Build-action:
     Identifier: aws/build@v1
     Inputs:
       Variables:
         - Name: APP-URL
           Value: https://mycompany.myapp.com
   ```

   または、次のようになります。

   ```
   Actions:
     Build:
       Identifier: aws/build@v1
       Configuration:    
         Steps:
           - Run: APP-URL=https://mycompany.myapp.com
   ```

   定義環境変数の詳細については、「[変数の定義](workflows-working-with-variables-define-input.md)」を参照してください。

1. 変数をエクスポートします。

   例えば、ビルドアクションは次のようになります。

   ```
   Build-action:
     ...
     Outputs:
       Variables:
         - APP-URL
   ```

   エクスポート変数の詳細については、「[他のアクションで使用できるように変数をエクスポートする](workflows-working-with-variables-export-input.md)」を参照してください。

1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。

1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。

1. [アプリケーション URL が追加されたことを確認するには](#deploy-app-url-verify) に進みます。<a name="deploy-app-url-verify"></a>

**アプリケーション URL が追加されたことを確認するには**
+ 自動的に開始していない場合は、ワークフローの実行を開始します。新しい実行では、ワークフロー図にクリック可能なリンクとしてアプリケーション URL が表示される必要があります。実行開始の詳細については、「[手動でのワークフロー実行の開始](workflows-manually-start.md)」を参照してください。

# デプロイターゲットの削除
<a name="deploy-remove-target"></a>

Amazon ECS クラスターや CloudFormation スタックなどのデプロイターゲットは、CodeCatalyst コンソールの**デプロイターゲット**ページから削除できます。

**重要**  
デプロイターゲットを削除すると、CodeCatalyst コンソールから削除されますが、それをホストする AWS サービスで引き続き使用できます (まだ存在する場合）。

CodeCatalyst でターゲットが古くなった場合は、デプロイターゲットの削除を検討してください。次の場合、ターゲットは古くなる可能性があります。
+ ターゲットにデプロイされたワークフローを削除しました。
+ デプロイ先のスタックまたはクラスターを変更しました。
+  AWS コンソールの CloudFormation または Amazon ECS サービスからスタックまたはクラスターを削除しました。

**デプロイターゲットを削除するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで、**[CI/CD]**、**[環境]** の順に選択します。

1. 削除するデプロイターゲットを含む環境の名前を選択します。環境の詳細については、「[AWS アカウント と VPCs へのデプロイ](deploy-environments.md)」を参照してください。

1. **[デプロイ]** タブを選択します。

1. 削除するデプロイターゲットの横にあるラジオボタンを選択します。

1. **[**を削除] を選択します。

   ターゲットはページから削除されます。

# コミット別のデプロイステータスの追跡
<a name="track-changes"></a>

開発ライフサイクルのいずれの時点でも、バグ修正、新機能、およびその他に影響を及ぼす変更など、特定のコミットのデプロイステータスを把握することが重要です。開発チームにとってデプロイステータスの追跡機能が役立つシナリオとして、次の例を考えます。
+ デベロッパーとして、バグの修正を行い、チームのデプロイ環境全体にわたるデプロイのステータスを報告する必要がある。
+ リリースマネージャーとして、デプロイされたコミットのリストを表示し、デプロイのステータスを追跡および報告する必要がある。

CodeCatalyst には、個々のコミットまたは変更がどの場所にデプロイされたか、そしてどの環境にデプロイされたかを一目で確認できるビューが用意されています。このビューには以下が含まれます。
+ コミットのリスト。
+ コミットに対応するデプロイのステータス。
+ コミットが正常にデプロイされた環境。
+ CI/CD ワークフローでのコミットに対するテスト実行のステータス。

次の手順では、このビューに移動し、このビューを使用してプロジェクトの変更を追跡する方法について説明します。

**注記**  
コミット別のデプロイステータスの追跡は、[CodeCatalyst リポジトリ](source.md)でのみサポートされています。この機能は、[GitHub リポジトリ、Bitbucket リポジトリ、または GitLab プロジェクトリポジトリ](extensions.md)では使用できません。

**コミット別にデプロイステータスを追跡するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]** を選択し、**[追跡変更]** を選択します。

1. メインペインの上部にある 2 つのドロップダウンリストで、リリースステータスを表示するコミットが含まれたソースリポジトリおよびソースブランチを選択します。

1. **[変更を表示]** を選択します。

   コミットのリストが表示されます。

   コミットごとに、以下を表示できます。
   + ID、作成者、メッセージ、コミット日時などのコミット情報。詳細については、「[CodeCatalyst のソースリポジトリでコードを保存し、共同作業を行うソースリポジトリでコードを保存して共同作業を行う](source.md)」を参照してください。
   + 各環境へのデプロイのステータス。詳細については、「[AWS アカウント と VPCs へのデプロイ](deploy-environments.md)」を参照してください。
   + テストとコードカバレッジの結果。詳細については、「[ワークフローを使用したテストワークフローを使用したテスト](test-workflow-actions.md)」を参照してください。
**注記**  
ソフトウェア構成分析 (SCA) の結果は表示されません。

1. (オプション) 最新のデプロイ、詳細なコードカバレッジ、ユニットテスト情報など、特定のコミットに関連する変更の詳細を表示するには、そのコミットの **[詳細を表示]** を選択します。

# デプロイログの表示
<a name="deploy-deployment-logs"></a>

特定のデプロイアクションに関連するログを表示して、Amazon CodeCatalyst の問題をトラブルシューティングできます。

[[ワークフロー]](workflow.md) または [[環境]](deploy-environments.md) からログを表示できます。

**ワークフローから開始するデプロイアクションのログを表示するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. **[実行]** を選択します。

1. アプリケーションをデプロイしたワークフロー実行を選択します。

1. ワークフロー図で、ログを表示するアクションを選択します。

1. **[ログ]** タブを選択し、セクションを展開してログメッセージを表示します。

1. その他のログを表示するには、**[概要]** タブを選択し、**[CloudFormation で表示]** (利用可能な場合) を選択して、その他のログを表示します。 AWSにサインインする必要がある場合があります。

**環境から開始するデプロイアクションのログを表示するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで、**[CI/CD]**、**[環境]** の順に選択します。

1. アプリケーションがデプロイされた環境を選択します。

1. **[デプロイアクティビティ]** で、**[ワークフロー実行 ID]** 列を見つけ、スタックをデプロイしたワークフロー実行を選択します。

1. ワークフロー図で、ログを表示するアクションを選択します。

1. **[ログ]** タブを選択し、セクションを展開してログメッセージを表示します。

1. その他のログを表示するには、**[概要]** タブを選択し、**[CloudFormation で表示]** (利用可能な場合) を選択して、その他のログを表示します。 AWSにサインインする必要がある場合があります。

# デプロイ情報の表示
<a name="deploy-view-deployment-info"></a>

Amazon CodeCatalyst のデプロイに関する以下の情報を表示できます。
+ デプロイステータス、開始時刻、終了時刻、履歴、イベントの所要時間を含むデプロイアクティビティ。
+ スタック名 AWS リージョン、最終更新時刻、および関連するワークフロー。
+ リクエストをコミットしてプルします。
+ CloudFormation イベントや出力などのアクション固有の情報。

[[ワークフロー]](workflow.md)、[[環境]](deploy-environments.md)、またはワークフロー [[アクション]](workflows-concepts.md#workflows-concepts-actions) からデプロイ情報を表示できます。

**ワークフローからデプロイ情報を表示するには**
+ アプリケーションをデプロイしたワークフロー実行に移動します。手順については、「[ワークフロー実行のステータスと詳細の表示](workflows-view-run.md)」を参照してください。

**環境からデプロイ情報を表示するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで、**[CI/CD]**、**[環境]** の順に選択します。

1. スタックがデプロイされた環境を選択します。例: `Production`。

1. **[デプロイアクティビティ]** を選択して、スタックのデプロイ履歴、デプロイのステータス (**[成功]** や **[失敗]** など)、およびその他のデプロイ関連情報を表示します。

1. **[デプロイターゲット]** を選択すると、環境にデプロイされたスタック、クラスター、またはその他のターゲットに関する情報が表示されます。スタック名、リージョン、プロバイダー、識別子などの情報を表示できます。

**アクションからデプロイ情報を表示するには**

1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。

1. プロジェクトを選択します。

1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。

1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。

1. ワークフロー図で、アプリケーションをデプロイしたワークフローアクションを選択します。例えば、**[DeployCloudFormationStack]** を選択できます。

1. アクション固有のデプロイ情報については、右側のペインの内容を確認してください。