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

# CodeDeploy デプロイ
<a name="deployment-steps"></a>

このトピックでは、CodeDeploy のデプロイのコンポーネントおよびワークフローについて説明します。デプロイプロセスは、デプロイに使用するコンピューティングプラットフォームまたはデプロイ方法 (Lambda、Amazon ECS、EC2/オンプレミス、または 経由 AWS CloudFormation) によって異なります。

**Topics**
+ [AWS Lambda コンピューティングプラットフォームでのデプロイ](deployment-steps-lambda.md)
+ [Amazon ECS コンピューティングプラットフォームのデプロイ](deployment-steps-ecs.md)
+ [EC2/オンプレミスコンピューティングプラットフォームの Blue/Green デプロイ](deployment-steps-server.md)

# AWS Lambda コンピューティングプラットフォームでのデプロイ
<a name="deployment-steps-lambda"></a>

このトピックでは、 AWS Lambda コンピューティングプラットフォームを使用する CodeDeploy デプロイのコンポーネントとワークフローについて説明します。

**Topics**
+ [AWS Lambda コンピューティングプラットフォームでのデプロイワークフロー](#deployment-process-workflow-lambda)
+ [アプリケーションリビジョンのアップロード](#deployment-steps-uploading-your-app-lambda)
+ [アプリケーションとデプロイグループの作成](#deployment-steps-registering-app-deployment-groups-lambda)
+ [アプリケーションリビジョンのデプロイ](#deployment-steps-deploy-lambda)
+ [アプリケーションの更新](#deployment-steps-updating-your-app-lambda)
+ [停止、失敗したデプロイ](#deployment-stop-fail-lambda)
+ [デプロイと再デプロイのロールバック](#deployment-rollback-lambda)

## AWS Lambda コンピューティングプラットフォームでのデプロイワークフロー
<a name="deployment-process-workflow-lambda"></a>

次の図は、新規および更新された AWS Lambda 関数のデプロイの主要なステップを示しています。

![\[CodeDeploy が新規または更新された AWS Lambda 関数をデプロイする方法。\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/images/deployment-process-lambda.png)


ステップには以下が含まれます。

1. アプリケーションを作成し、デプロイするアプリケーションリビジョンを一意に識別する名前を付けます。Lambda 関数をデプロイするには、 AWS Lambda コンピューティングプラットフォームは、アプリケーションを作成するときに使用します。CodeDeploy は、この名前を使用して、デプロイグループ、デプロイ設定、アプリケーションリビジョンなど、正しいデプロイコンポーネントを参照していることを確認します。詳細については、「[CodeDeploy でアプリケーションを作成する](applications-create.md)」を参照してください。

1. デプロイグループを設定するには、デプロイグループの名前を指定します。

1. デプロイ設定を選択して、トラフィックを元の AWS Lambda 関数バージョンから新しい Lambda 関数バージョンに移行する方法を指定します。詳細については、「[CodeDeploy によるデプロイ設定の詳細の表示](deployment-configurations-view-details.md)」を参照してください。

1. *アプリケーション仕様ファイル*(AppSpec ファイル) を Amazon S3 にアップロードします。AppSpec ファイルは、デプロイを検証するために使用される Lambda 関数のバージョンと Lambda 関数を指定します。AppSpec ファイルを作成しない場合は、YAML または JSON を使用して、コンソールで直接 Lambda 関数バージョンと Lambda デプロイ検証用の関数を指定できます。詳細については、「[CodeDeploy のアプリケーションリビジョンの操作](application-revisions.md)」を参照してください。

1. アプリケーションリビジョンをデプロイグループにデプロイします。 は、指定した Lambda 関数リビジョンを AWS CodeDeploy デプロイします。トラフィックを Lambda 関数リビジョンに移行するには、アプリケーション作成時に選択した AppSpec ファイルのデプロイを使用します。詳細については、「[CodeDeploy でデプロイを作成する](deployments-create.md)」を参照してください。

1. デプロイの結果を確認します。詳細については、「[CodeDeploy でのデプロイモニタリング](monitoring.md)」を参照してください。

## アプリケーションリビジョンのアップロード
<a name="deployment-steps-uploading-your-app-lambda"></a>

Amazon S3 に AppSpec ファイルを配置するか、コンソールまたは AWS CLIに直接入力します。詳細については、「[CodeDeploy アプリケーション仕様 (AppSpec) ファイル](application-specification-files.md)」を参照してください。

## アプリケーションとデプロイグループの作成
<a name="deployment-steps-registering-app-deployment-groups-lambda"></a>

 AWS Lambda コンピューティングプラットフォーム上の CodeDeploy デプロイグループは、1 つ以上の AppSpec ファイルのコレクションを識別します。AppSpec ファイルごとに 1 つの Lambda 関数バージョンをデプロイできます。デプロイグループは、今後のデプロイのために、アラームおよびロールバックの設定などの設定オプションのセットを定義します。

## アプリケーションリビジョンのデプロイ
<a name="deployment-steps-deploy-lambda"></a>

これで、AppSpec ファイル で指定した関数リビジョンをデプロイグループにデプロイする準備ができました。CodeDeploy コンソールまたは [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) コマンドを使用できます。デプロイを制御するために指定できるパラメータ (リビジョン、デプロイグループ、デプロイ設定など) があります。

## アプリケーションの更新
<a name="deployment-steps-updating-your-app-lambda"></a>

アプリケーションを更新し、CodeDeploy コンソールを使用するか、[create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) コマンドを呼び出してリビジョンをプッシュできます。

## 停止、失敗したデプロイ
<a name="deployment-stop-fail-lambda"></a>

デプロイを停止するには、CodeDeploy コンソールまたは[stop-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/stop-deployment.html)コマンドを使用できます。デプロイを停止しようとする場合、次の 3 つのうち 1 つのことが発生します。
+ デプロイは停止し、オペレーションは成功というステータスを返す。この場合、停止したデプロイに対してそれ以上デプロイライフサイクルイベントは実行されません。
+ デプロイは即時に停止せず、オペレーションは保留中というステータスを返す。この場合、一部のデプロイライフサイクルイベントは、デプロイグループでまだ実行中である可能性があります。保留中のオペレーションが完了すると、デプロイを停止するためのそれ以降の呼び出しは、成功というステータスを返します。
+ デプロイは停止できず、オペレーションはエラーを返す。詳細については、 AWS CodeDeploy API リファレンスの[ErrorInformation](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_ErrorInformation.html)」と[「一般的なエラー](https://docs.aws.amazon.com/codedeploy/latest/APIReference/CommonErrors.html)」を参照してください。

失敗したデプロイでは、停止されたデプロイのように、一部のデプロイライフサイクルイベントが実行済みになる場合があります。デプロイが失敗した理由を調べるには、CodeDeploy コンソールを使用するか、失敗したデプロイのログファイルデータを分析することができます。詳細については、「[アプリケーションリビジョンとログファイルのクリーンアップ](codedeploy-agent.md#codedeploy-agent-revisions-logs-cleanup)」および「[CodeDeploy EC2/オンプレミスデプロイのログデータの表示](deployments-view-logs.md)」を参照してください。

## デプロイと再デプロイのロールバック
<a name="deployment-rollback-lambda"></a>

CodeDeploy は新しいデプロイとして、以前にデプロイされたリビジョンを再デプロイすることによって、ロールバックを実装します。

デプロイが失敗した、アラームのモニタリングしきい値に一致したなど、特定の条件が満たされた場合に、自動的にデプロイをロールバックするようグループデプロイを設定できます。個別のデプロイで、デプロイグループに指定されたロールバック設定をオーバーライドすることもできます。

以前のデプロイされたバージョンを手動で再デプロイして、失敗したデプロイをロールバックすることもできます。

いずれの場合でも、新しいデプロイまたはロールバックされたデプロイには独自のデプロイ ID が割り当てられます。CodeDeploy コンソールで表示できるデプロイの一覧には、どれが自動デプロイの結果であるかが示されます。

詳細については、「[CodeDeploy を使用した再デプロイおよびデプロイのロールバック](deployments-rollback-and-redeploy.md)」を参照してください。

# Amazon ECS コンピューティングプラットフォームのデプロイ
<a name="deployment-steps-ecs"></a>

このトピックでは、Amazon ECS コンピューティングプラットフォームを使用する CodeDeploy のデプロイのコンポーネントおよびワークフローについて説明します。

**Topics**
+ [Amazon ECS デプロイを開始する前に](#deployment-steps-prerequisites-ecs)
+ [Amazon ECS コンピューティングプラットフォームのデプロイワークフロー (高レベル)](#deployment-process-workflow-ecs)
+ [Amazon ECS デプロイ中の処理で起こっていること](#deployment-steps-what-happens)
+ [アプリケーションリビジョンのアップロード](#deployment-steps-uploading-your-app-ecs)
+ [アプリケーションとデプロイグループの作成](#deployment-steps-registering-app-deployment-groups-ecs)
+ [アプリケーションリビジョンのデプロイ](#deployment-steps-deploy-ecs)
+ [アプリケーションの更新](#deployment-steps-updating-your-app-ecs)
+ [停止、失敗したデプロイ](#deployment-stop-fail-ecs)
+ [デプロイと再デプロイのロールバック](#deployment-rollback-ecs)
+ [による Amazon ECS ブルー/グリーンデプロイ AWS CloudFormation](#deployment-steps-ecs-cf)

## Amazon ECS デプロイを開始する前に
<a name="deployment-steps-prerequisites-ecs"></a>

 Amazon ECS アプリケーションのデプロイを開始する前に、次の準備が完了している必要があります。デプロイグループを作成するときに指定される要件と、AppSpec ファイルで指定される要件があります。


****  

| 要件 | 指定される場所 | 
| --- | --- | 
| Amazon ECS クラスター | デプロイグループ | 
| Amazon ECS サービス | デプロイグループ | 
| Application Load Balancer および Network Load Balancer | デプロイグループ | 
| 本稼働リスナー | デプロイグループ | 
| テストリスナー (オプション) | デプロイグループ | 
| 2 つのターゲットグループ | デプロイグループ | 
| Amazon ECS タスク定義 | AppSpec ファイル | 
| コンテナ名 | AppSpec ファイル | 
| コンテナポート | AppSpec ファイル | 

**Amazon ECS クラスター**  
Amazon ECS*クラスター*は、タスクまたはサービスの論理グループです。CodeDeploy アプリケーションのデプロイグループを作成するときに、Amazon ECS サービスを含む Amazon ECS クラスターを指定します。詳細については、「[Amazon Elastic Container Service ユーザーガイド](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_clusters.html)」の「*Amazon ECS のクラスター*」を参照してください。

**Amazon ECS サービス**  
Amazon ECS *サービス*は、Amazon ECS クラスター内のタスク定義で指定されたインスタンスを維持し、実行します。Amazon ECS サービスが CodeDeploy で有効になっている必要があります。デフォルトでは、Amazon ECS サービスは、Amazon ECS デプロイで有効になっています。デプロイグループを作成するときは、Amazon ECS クラスター内の Amazon ECS サービスをデプロイすることを選択します。詳細については、「*Amazon Elastic Container Service ユーザーガイド*」の「[Amazon ECS のクラスター](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html)」を参照してください。

** Application Load Balancer および Network Load Balancer**  
 Elastic Load Balancing は、Amazon ECS デプロイで更新する Amazon ECS サービスで使用する必要があります。Application Load Balancer または Network Load Balancer を作成できます。動的ポートマッピング、パスベースのルーティング、優先ルールなどの機能を利用できるように、 Application Load Balancer をお勧めします。CodeDeploy アプリケーションのデプロイグループを作成するときに、ロードバランサーを指定します。詳細については、「*Amazon Elastic Container Service ユーザーガイド*」の [CodeDeploy Amazon ECS デプロイ用のロードバランサー、ターゲットグループ、リスナーをセットアップする](deployment-groups-create-load-balancer-for-ecs.md) と「[ロードバランサーの作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-load-balancer.html)」を参照してください。

**1 つまたは 2 つのリスナー**  
ロードバランサーは、*リスナー*を使用してターゲットグループにトラフィックをルーティングします。本稼働リスナーが 1 つ必要です。検証テストの実行中、置き換えタスクセットにトラフィックをルーティングする、2 番目のオプションのテストリスナーを指定できます。デプロイグループを作成するときに、一方または両方のリスナーを指定します。Amazon ECS コンソールを使用して Amazon ECS サービスを作成すると、リスナーが作成されます。詳細については、「*Elastic Load Balancing ユーザーガイド*」の「[Application Load Balancer のリスナー](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listener.html)」そして「*Amazon Elastic Container Service ユーザーガイド*」の「[サービスの作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service.html)」を参照してください。

** 2 つの Amazon ECS ターゲットグループ**  
 *ターゲットグループ*は、登録済みターゲットにトラフィックをルーティングするために使用されます。Amazon ECS デプロイには 2 つのターゲットグループが必要です。1 つは Amazon ECS アプリケーションの元のタスクセット用、もう 1 つはその置き換えタスクセット用です。デプロイ中、CodeDeploy は置き換えタスクセットを作成し、元のタスクセットから新しいタスクセットにトラフィックを再ルーティングします。CodeDeploy アプリケーションのデプロイグループを作成するときに、ターゲットグループを指定します。  
 デプロイ中、CodeDeploy は、ステータス `PRIMARY` (これが元のタスクセット) を持つ、Amazon ECS サービスのタスクセットに関連付けられているターゲットグループを決定し、それに一方のターゲットグループを関連付けます。さらに、もう一方のターゲットグループを置き換えタスクセットと関連付けます。別のデプロイを行う場合、現在のデプロイの元のタスクセットに関連付けられているターゲットグループは、次のデプロイの置き換えタスクセットに関連付けられています。詳細については、「*Elastic Load Balancingのユーザーガイド*」の「[Application Load Balancer のターゲットグループ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html)」を参照してください。

** Amazon ECS タスク定義**  
 Amazon ECS アプリケーションを含んだ Docker コンテナを実行するには、*タスク定義* が必要です。CodeDeploy アプリケーションの AppSpec ファイルで、タスク定義の ARN を指定します。詳細については、「*Amazon Elastic Container Service ユーザーガイド*」と [Amazon ECS デプロイ用の AppSpec の「resources」セクション](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs) の「[Amazon ECS のタスクロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)」を参照してください。

** Amazon ECS アプリケーション用のコンテナ**  
 Docker *コンテナ*は、コードとその依存関係をパッケージ化してアプリケーションを実行できるようにするソフトウェアのユニットです。コンテナはアプリケーションを分離して、さまざまなコンピューティング環境で実行できるようにします。ロードバランサーは、Amazon ECS アプリケーションのタスクセットのコンテナにトラフィックをルーティングします。CodeDeploy アプリケーションの AppSpec ファイルで、コンテナの名前を指定します。AppSpec ファイル で指定したコンテナは、Amazon ECS タスク定義で指定したコンテナのいずれかである必要があります。詳細については、「*Amazon Elastic Container Service ユーザーガイド*」と [Amazon ECS デプロイ用の AppSpec の「resources」セクション](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs) の「[Amazon Elastic Container Service とは](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)」を参照してください。

**置き換えタスクセット用のポート**  
 Amazon ECS デプロイ中に、ロードバランサーが CodeDeploy アプリケーションの AppSpec ファイルで指定されたコンテナ上の *ポート* にトラフィックを指定します。CodeDeploy アプリケーションの AppSpec ファイル でポートを指定します。詳細については、「[Amazon ECS デプロイ用の AppSpec の「resources」セクション](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs)」を参照してください。

## Amazon ECS コンピューティングプラットフォームのデプロイワークフロー (高レベル)
<a name="deployment-process-workflow-ecs"></a>

次の図表は、更新された Amazon ECS サービスのデプロイの主要なステップを示しています。

![\[CodeDeploy がアプリケーションをタスクセットとして Amazon ECS にデプロイする方法。\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/images/deployment-process-ecs.png)


ステップには以下が含まれます。

1. デプロイする内容を一意に表す名前を指定して、 AWS CodeDeploy アプリケーションを作成します。Amazon ECS アプリケーションをデプロイするには、 AWS CodeDeploy アプリケーションで Amazon ECS コンピューティングプラットフォームを選択します。CodeDeploy は、デプロイ中にアプリケーションを使用して、デプロイグループ、ターゲットグループ、リスナー、トラフィックの再ルーティング動作、およびアプリケーションリビジョンなどの正しいデプロイコンポーネント参照します。詳細については、「[CodeDeploy でアプリケーションを作成する](applications-create.md)」を参照してください。

1. デプロイグループをセットアップするには、以下を指定します。
   +  デプロイグループ名。
   +  お客様の Amazon ECS クラスターとサービス名 Amazon ECS サービスのデプロイコントローラーは、CodeDeploy に設定する必要があります。
   +  本稼働リスナー、オプションのテストリスナー、およびターゲットグループは、デプロイ中に使用されます。
   +  本稼働トラフィックを Amazon ECS サービスの置き換え Amazon ECS タスクセットに再ルーティングするタイミングや、Amazon ECS サービスの元の Amazon ECS タスクセットを終了するタイミングなどのデプロイ設定。
   +  トリガー、アラーム、ロールバック動作などのオプション設定。

1. *アプリケーション仕様ファイル* (AppSpec ファイル) を指定します。Amazon S3 にアップロードしたり、YAML または JSON 形式でコンソールに入力したり、 AWS CLI または SDK で指定したりできます。AppSpec ファイル は、デプロイの Amazon ECS タスク定義、トラフィックをルーティングするコンテナ名とポートマッピング、およびデプロイのライフサイクルフックの後で実行される Lambda 関数を指定するために使用されます。コンテナ名は、Amazon ECS タスク定義内のコンテナである必要があります。詳細については、「[CodeDeploy のアプリケーションリビジョンの操作](application-revisions.md)」を参照してください。

1. アプリケーションリビジョンをデプロイします。 AWS CodeDeploy rerout は、Amazon ECS サービスのタスクセットの元のバージョンから新しい置き換えタスクセットにトラフィックをデプロイします。デプロイグループで指定されたターゲットグループは、元のタスクセットと置き換えタスクセットにトラフィックを提供するために使用されます。デプロイが完了すると、元のタスクセットは削除されます。トラフィックが再ルーティングされる前に、テストトラフィックを置き換えバージョンに提供するためのオプションのテストリスナーを指定できます。詳細については、「[CodeDeploy でデプロイを作成する](deployments-create.md)」を参照してください。

1. デプロイの結果を確認します。詳細については、「[CodeDeploy でのデプロイモニタリング](monitoring.md)」を参照してください。

## Amazon ECS デプロイ中の処理で起こっていること
<a name="deployment-steps-what-happens"></a>

テストリスナーを使用して Amazon ECS デプロイを開始する前に、そのコンポーネントを設定する必要があります。詳細については、「[Amazon ECS デプロイを開始する前に](#deployment-steps-prerequisites-ecs)」を参照してください。

 次の図表は、Amazon ECS デプロイを開始する準備ができたときのこれらのコンポーネント間の関係を示しています。

![\[Amazon ECS デプロイを開始する準備ができたときのロードバランサー、リスナー、ターゲットグループ、タスクセットの関係。\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/images/codedeploy-ecs-deployment-step-1.png)


デプロイが開始されたら、デプロイライフサイクルイベントが一度に 1 つずつ実行され始めます。ライフサイクルイベントの中には、AppSpec ファイル で指定されている Lambda 関数のみを実行するフックがあります。次の表のデプロイのライフサイクルイベントは、実行された順序で一覧表示されています。詳細については、「[Amazon ECS のデプロイ向けの AppSpec の「hooks」セクション](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs)」を参照してください。


| ライフサイクルイベント | ライフサイクルイベントアクション | 
| --- | --- | 
| BeforeInstall (Lambda 関数のフック) | Lambda 関数を実行します。 | 
| インストール | 代替タスクの設定を行います。 | 
| AfterInstall (Lambda 関数のフック) | Lambda 関数を実行します。 | 
| AllowTestTraffic | テストリスナーからターゲットグループ 2 にトラフィックをルーティングします。 | 
| AfterAllowTestTraffic (Lambda 関数のフック) | Lambda 関数を実行します。 | 
| BeforeAllowTraffic (Lambda 関数のフック) | Lambda 関数を実行します。 | 
| AllowTraffic | 本稼働リスナーからターゲットグループ 2 にトラフィックをルーティングします。 | 
| AfterAllowTraffic | Lambda 関数を実行します。 | 



**注記**  
フックの Lambda 関数はオプションです。

1. <a name="ecs-before-install"></a>

****

   AppSpec ファイルの `BeforeInstall` フックで指定された Lambda 関数を実行します。

1. <a name="ecs-install"></a>

****

   `Install` ライフサイクルイベント中:

   1.  代替タスクセットが Amazon ECS サービスで作成されます。

   1.  更新後のコンテナ化されたアプリケーションは、置き換えタスクセットにインストールされます。

   1.  2 番目のターゲットグループは置き換えタスクセットに関連付けられています。

    この図は、新しい置き換えタスクセットを含むデプロイコンポーネントを示しています。コンテナ化されたアプリケーションはこのタスクセット内にあります。タスクセットは 3 つのタスクで構成されています。(アプリケーションには任意の数のタスクを含めることができます。) 2 番目のターゲットグループが置き換えタスクセットに関連付けられました。  
![\[新しい置き換えタスクセットを含むデプロイコンポーネント。コンテナ化されたアプリケーションはこのタスクセット内にあります。タスクセットは 3 つのタスクで構成されています。2 番目のターゲットグループが置き換えタスクセットに関連付けられました。\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/images/codedeploy-ecs-deployment-step-2.png)

1. <a name="ecs-after-install"></a>

****

   AppSpec ファイルの `AfterInstall` フックで指定された Lambda 関数を実行します。

1. <a name="ecs-allow-test-traffic"></a>

****

   `AllowTestTraffic` イベントが呼び出されます。このライフサイクルイベントの間、テストリスナーは、更新されたコンテナ化アプリケーションにトラフィックをルーティングします。  
![\[テストリスナーは、更新されたコンテナ化アプリケーションにトラフィックをルーティングします。\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/images/codedeploy-ecs-deployment-step-3.png)

1. <a name="ecs-after-allow-test-traffic"></a>

****

   AppSpec ファイルの `AfterAllowTestTraffic` フックで指定された Lambda 関数を実行します。Lambda 関数は、テストトラフィックを使用してデプロイを検証します。たとえば、Lambda 関数はテストリスナーにトラフィックを送信し、置き換えタスクセットのメトリクスを追跡できます。ロールバックが設定されている場合は、Lambda 関数内の検証テストが失敗したときにロールバックをトリガーする CloudWatch アラームを設定できます。

    検証テストが完了したら、次のいずれかが発生します。
   +  検証が失敗し、ロールバックが設定されている場合、デプロイステータスは `Failed` とマークされ、コンポーネントはデプロイが開始されたときの状態に戻ります。
   +  検証が失敗し、ロールバックが設定されていない場合、デプロイステータスは `Failed` とマークされ、コンポーネントは現在の状態のまま変わりません。
   +  検証が正常に完了すると、デプロイは引き続き `BeforeAllowTraffic` に進みます。

    詳細については[CodeDeploy での CloudWatch アラームを使用したデプロイのモニタリング](monitoring-create-alarms.md)、[自動ロールバック](deployments-rollback-and-redeploy.md#deployments-rollback-and-redeploy-automatic-rollbacks)、および[デプロイグループの詳細オプションの設定](deployment-groups-configure-advanced-options.md)を参照してください。

1. <a name="ecs-before-allow-traffic"></a>

****

   AppSpec ファイルの `BeforeAllowTraffic` フックで指定された Lambda 関数を実行します。

1. <a name="ecs-allow-traffic"></a>

****

   `AllowTraffic` イベントが呼び出されます。本稼働トラフィックは、元のタスクセットから置き換えタスクセットに再ルーティングされます。次の図は、本稼働トラフィックを受信して​​いる代替タスクセットを示しています。  
![\[代替タスクセットは本番トラフィックを受け取ります。\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/images/codedeploy-ecs-deployment-step-4.png)

1. <a name="ecs-after-allow-traffic"></a>

****

   AppSpec ファイルの `AfterAllowTraffic` フックで指定された Lambda 関数を実行します。

1. 

****

   すべてのイベントが正常に完了したら、デプロイステータスは `Succeeded` になり、元のタスクセットは削除されます。  
![\[成功するすべてのイベント。\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/images/codedeploy-ecs-deployment-step-6.png)

## アプリケーションリビジョンのアップロード
<a name="deployment-steps-uploading-your-app-ecs"></a>

Amazon S3 に AppSpec ファイルを配置するか、コンソールまたは AWS CLIに直接入力します。詳細については、「[CodeDeploy アプリケーション仕様 (AppSpec) ファイル](application-specification-files.md)」を参照してください。

## アプリケーションとデプロイグループの作成
<a name="deployment-steps-registering-app-deployment-groups-ecs"></a>

Amazon ECS コンピューティングプラットフォーム上の CodeDeploy デプロイグループは、更新された Amazon ECS アプリケーションへのトラフィックを提供するリスナー、およびデプロイ中に使用される 2 つのターゲットグループを識別します。デプロイグループは、アラームおよびロールバックの設定などの設定オプションのセットも定義します。

## アプリケーションリビジョンのデプロイ
<a name="deployment-steps-deploy-ecs"></a>

これで、デプロイグループで指定された、更新された Amazon ECS サービスをデプロイする準備が整いました。CodeDeploy コンソールまたは [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) コマンドを使用できます。デプロイを制御するために指定できるパラメータ (リビジョン、デプロイグループなど) があります。

## アプリケーションの更新
<a name="deployment-steps-updating-your-app-ecs"></a>

アプリケーションを更新し、CodeDeploy コンソールを使用するか、[create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) コマンドを呼び出してリビジョンをプッシュできます。

## 停止、失敗したデプロイ
<a name="deployment-stop-fail-ecs"></a>

デプロイを停止するには、CodeDeploy コンソールまたは[stop-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/stop-deployment.html)コマンドを使用できます。デプロイを停止しようとする場合、次の 3 つのうち 1 つのことが発生します。
+ デプロイは停止し、オペレーションは成功というステータスを返す。この場合、停止したデプロイに対してそれ以上デプロイライフサイクルイベントは実行されません。
+ デプロイは即時に停止せず、オペレーションは保留中というステータスを返す。この場合、一部のデプロイライフサイクルイベントは、デプロイグループでまだ実行中である可能性があります。保留中のオペレーションが完了すると、デプロイを停止するためのそれ以降の呼び出しは、成功というステータスを返します。
+ デプロイは停止できず、オペレーションはエラーを返す。詳細については、 AWS CodeDeploy API リファレンスの[「エラー情報](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_ErrorInformation.html)」と[「一般的なエラー](https://docs.aws.amazon.com/codedeploy/latest/APIReference/CommonErrors.html)」を参照してください。

## デプロイと再デプロイのロールバック
<a name="deployment-rollback-ecs"></a>

CodeDeploy は、置き換えタスクセットから元のタスクセットにトラフィックを再ルーティングすることにより、ロールバックを実装します。

デプロイが失敗した、アラームのモニタリングしきい値に一致したなど、特定の条件が満たされた場合に、自動的にデプロイをロールバックするようグループデプロイを設定できます。個別のデプロイで、デプロイグループに指定されたロールバック設定をオーバーライドすることもできます。

以前のデプロイされたバージョンを手動で再デプロイして、失敗したデプロイをロールバックすることもできます。

いずれの場合でも、新しいデプロイまたはロールバックされたデプロイには独自のデプロイ ID が割り当てられます。CodeDeploy コンソールには、自動デプロイの結果であるデプロイの一覧が表示されます。

デプロイする場合、現在のデプロイの元のタスクセットに関連付けられているターゲットグループは、デプロイの置き換えタスクセットに関連付けられています。

詳細については、「[CodeDeploy を使用した再デプロイおよびデプロイのロールバック](deployments-rollback-and-redeploy.md)」を参照してください。

## による Amazon ECS ブルー/グリーンデプロイ AWS CloudFormation
<a name="deployment-steps-ecs-cf"></a>

を使用して AWS CloudFormation 、CodeDeploy を通じて Amazon ECS ブルー/グリーンデプロイを管理できます。詳細については、「[を使用して Amazon ECS ブルー/グリーンデプロイを作成する CloudFormation](deployments-create-ecs-cfn.md)」を参照してください。

**注記**  
を使用した Amazon ECS ブルー/グリーンデプロイの管理 CloudFormation は、アジアパシフィック (大阪) リージョンでは利用できません。

# EC2/オンプレミスコンピューティングプラットフォームの Blue/Green デプロイ
<a name="deployment-steps-server"></a>

このトピックでは、EC2 オンプレミスのコンピューティングプラットフォームを使用する CodeDeploy のデプロイのコンポーネントおよびワークフローについて説明します。Blue/Green デプロイの詳細については、「[Blue/Green デプロイの概要](welcome.md#welcome-deployment-overview-blue-green)」を参照してください。

**Topics**
+ [EC2/オンプレミスコンピューティングプラットフォームのデプロイコンポーネント](#deployment-steps-components-server)
+ [EC2/オンプレミスコンピューティングプラットフォームのデプロイワークフロー](#deployment-steps-workflow)
+ [インスタンスの設定](#deployment-steps-setting-up-instances)
+ [アプリケーションリビジョンのアップロード](#deployment-steps-uploading-your-app)
+ [アプリケーションとデプロイグループの作成](#deployment-steps-registering-app-deployment-groups)
+ [アプリケーションリビジョンのデプロイ](#deployment-steps-deploy)
+ [アプリケーションの更新](#deployment-steps-updating-your-app)
+ [停止、失敗したデプロイ](#deployment-stop-fail)
+ [デプロイと再デプロイのロールバック](#deployment-rollback)

## EC2/オンプレミスコンピューティングプラットフォームのデプロイコンポーネント
<a name="deployment-steps-components-server"></a>

以下の図表は、EC2/オンプレミスコンピューティングプラットフォームの CodeDeploy デプロイのコンポーネントを示します。

![\[EC2/オンプレミスコンピューティングプラットフォームの CodeDeploy デプロイのコンポーネント。\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/images/deployment-components-workflow.png)


## EC2/オンプレミスコンピューティングプラットフォームのデプロイワークフロー
<a name="deployment-steps-workflow"></a>

次の図は、アプリケーションリビジョンのデプロイの主要なステップを示しています。

![\[アプリケーションリビジョンのデプロイの主要なステップ。\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/images/deployment-process.png)


ステップには以下が含まれます。

1. アプリケーションを作成し、デプロイするアプリケーションリビジョンとアプリケーションのコンピューティングプラットフォームを一意に識別する名前を付けます。CodeDeploy は、この名前を使用して、デプロイグループ、デプロイ設定、アプリケーションリビジョンなど、正しいデプロイコンポーネントを参照していることを確認します。詳細については、「[CodeDeploy でアプリケーションを作成する](applications-create.md)」を参照してください。

1. アプリケーションリビジョンをデプロイするデプロイタイプとインスタンスを指定して、デプロイグループをセットアップします。インプレースデプロイでは、最新のアプリケーションリビジョンでインスタンスを更新します。Blue/Green デプロイはロードバランサーでデプロイグループ用の代替セットを登録し、元のインスタンスを登録解除します。

   インスタンス、Amazon EC2 Auto Scaling グループ名、または両方に適用するタグを指定できます。

   デプロイグループのタグのグループを指定すると、CodeDeploy は指定されたタグの少なくとも 1 つが適用されたインスタンスにデプロイします。2 つ以上のタググループを指定した場合、CodeDeploy はそれぞれのタググループの条件を満たすインスタンスにのみデプロイします。詳細については、「[CodeDeploy 中のデプロイグループのためのインスタンスのタグ付け](instances-tagging.md)」を参照してください。

   いずれの場合も、インスタンスはデプロイで使用するよう設定されていること (つまり、タグが付いているか、Amazon EC2 Auto Scaling グループに所属していること)、および CodeDeploy エージェントをインストールして実行していることが必要です。

   Amazon Linux または Windows Server に基づいて Amazon EC2 インスタンスをすばやくセットアップするために使用できる CloudFormation テンプレートが用意されています。また、スタンドアロン CodeDeploy エージェントも提供しています。これにより、Amazon Linux、Ubuntu Server、Red Hat Enterprise Linux (RHEL)、または Windows Server インスタンスにインストールできます。詳細については、「[CodeDeploy でデプロイグループを作成する](deployment-groups-create.md)」を参照してください。

   また、以下のオプションを指定することもできます。
   + **Amazon SNS の通知** 成功イベントや失敗イベントなど、指定されたイベントがデプロイとインスタンスで発生したときに、Amazon SNS トピックの受信者に通知を送信するトリガーを作成します。詳細については、「[Amazon SNS イベント通知を使用したデプロイのモニタリング](monitoring-sns-event-notifications.md)」を参照してください。
   + **アラームベースのデプロイ管理**。CloudWatch で設定したしきい値を超えるか下回ったときに、デプロイを停止する Amazon CloudWatch アラームモニタリングを実装します。
   + **自動デプロイロールバック**。デプロイが失敗するか、アラームのしきい値に一致したときに、以前の既知の正常なリビジョンに自動的にロールバックするようデプロイを設定します。

1. アプリケーションのリビジョンを同時にデプロイする必要があるインスタンスの数と、デプロイの成功と失敗の条件を示すために、デプロイ構成を指定します。詳細については、「[CodeDeploy によるデプロイ設定の詳細の表示](deployment-configurations-view-details.md)」を参照してください。

1. アプリケーションリビジョンを Amazon S3 または GitHub にアップロードします。デプロイするファイルおよびデプロイ中に実行するスクリプトに加えて、*アプリケーション 仕様ファイル* (AppSpec ファイル) を含める必要があります。このファイルには、ファイルを各インスタンスにコピーする場所や、デプロイスクリプトを実行するタイミングなど、デプロイの手順が含まれています。詳細については、「[CodeDeploy のアプリケーションリビジョンの操作](application-revisions.md)」を参照してください。

1. デプロイグループにアプリケーションリビジョンをデプロイします。デプロイグループの各インスタンスの CodeDeploy エージェントは、Amazon S3 または GitHub からインスタンスにアプリケーションリビジョンをコピーします。次に、CodeDeploy エージェントは、リビジョンをバンドル解除し、AppSpec ファイル を使用してファイルを指定された場所にコピーして、デプロイスクリプトを実行します。詳細については、「[CodeDeploy でデプロイを作成する](deployments-create.md)」を参照してください。

1. デプロイの結果を確認します。詳細については、「[CodeDeploy でのデプロイモニタリング](monitoring.md)」を参照してください。

1. リビジョンをデプロイします。ソースコンテンツのバグを修正する、別の順序でデプロイスクリプトを実行する、または失敗したデプロイに対応する必要がある場合に、この作業を行います。これを行うには、変更したソースコンテンツ、デプロイスクリプト、および AppSpec ファイル を新しいリビジョンを再バンドルし、このリビジョンを Amazon S3 バケットまたは GitHub リポジトリにアップロードします。次に、新しいリビジョンで同じデプロイグループに新しいデプロイを実行します。詳細については、「[CodeDeploy でデプロイを作成する](deployments-create.md)」を参照してください。

## インスタンスの設定
<a name="deployment-steps-setting-up-instances"></a>

 アプリケーションリビジョンを初めてデプロイする前に、インスタンスを設定する必要があります。アプリケーションリビジョンで 3 つの本番稼働用サーバーと 2 つのバックアップサーバーが必要な場合、5 つのインスタンスを起動または使用します。

インスタンスを手動でプロビジョニングするには:

1. CodeDeploy エージェントをインスタンスにインストールする CodeDeploy エージェントは、Amazon Linux、Ubuntu サーバー、RHEL、および Windows Server インスタンスにインストールできます。

1. タグを使用してデプロイグループのインスタンスを識別する場合は、タグ付けを有効にします。CodeDeploy は、CodeDeploy デプロイグループにインスタンスを識別し、グループ化するタグを使用します。入門チュートリアルでは両方を使用しましたが、キーまたは値を使用して、デプロイグループのタグを定義できます。

1. IAM インスタンスプロファイルをアタッチして、Amazon EC2 インスタンスを起動します。CodeDeploy エージェントでインスタンスの ID を検証するには、Amazon EC2 インスタンスを起動する際に IAM インスタンスプロファイルをアタッチする必要があります。

1. サービスロールを作成します。CodeDeploy が AWS アカウントのタグを拡張できるように、サービスアクセスを提供します。

最初のデプロイでは、 CloudFormation テンプレートがこれらをすべて実行します。これにより、CodeDeploy エージェントがインストール済みの Amazon Linux または Windows Serverをベースに、一つの新規Amazon EC2 インスタンスを作成および設定することができます。詳細については、「[CodeDeploy のためにインスタンスを用いた操作](instances.md)」を参照してください。

**注記**  
Blue/Green デプロイでは、置き換え先環境用の既存のインスタンスを使用するか、デプロイプロセスの一部として CodeDeploy で新しいインスタンスをプロビジョニングするか選択できます。

## アプリケーションリビジョンのアップロード
<a name="deployment-steps-uploading-your-app"></a>

アプリケーションのソースコンテンツフォルダ構造で、ルートフォルダの下に AppSpec ファイル を配置します。詳細については、「[CodeDeploy アプリケーション仕様 (AppSpec) ファイル](application-specification-files.md)」を参照してください。

zip、tar、または圧縮された tar などのアーカイブファイル形式にアプリケーションのソースコンテンツフォルダ構造をバンドルします。アーカイブファイル (*リビジョン*) を Amazon S3 バケットまたは GitHub リポジトリにアップロードします。

**注記**  
tar および圧縮 tar アーカイブファイル形式（.tar および .tar.gz）は、Windows Server インスタンスではサポートされていません。

## アプリケーションとデプロイグループの作成
<a name="deployment-steps-registering-app-deployment-groups"></a>

CodeDeploy デプロイグループはタグ、Amazon EC2 Auto Scaling グループ名、または両方に基づいてインスタンスのコレクションを識別します。複数のアプリケーションリビジョンを同じインスタンスにデプロイできます。1 つのアプリケーションリビジョンを複数のインスタンスにデプロイできます 

たとえば、3 つの本番稼働用サーバーに「Prod」というタグを追加し、2 つのバックアップサーバーに「Backup」というタグを追加できます。これら 2 つのタグを使用して、CodeDeploy アプリケーションで 2 つの異なるデプロイグループを作成し、デプロイにどちらのサーバーのセットを参加させるか (または両方を参加させるか) 選択することができます。

デプロイグループの複数のタググループを使用して、デプロイするインスタンスのセットを減らすことができます。詳細については、「[CodeDeploy 中のデプロイグループのためのインスタンスのタグ付け](instances-tagging.md)」を参照してください。

## アプリケーションリビジョンのデプロイ
<a name="deployment-steps-deploy"></a>

これで、Amazon S3 または GitHub からデプロイグループにアプリケーションリビジョンをデプロイできる状態になりました。CodeDeploy コンソールまたは [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) コマンドを使用できます。デプロイを制御するために指定できるパラメータ (リビジョン、デプロイグループ、デプロイ設定など) があります。

## アプリケーションの更新
<a name="deployment-steps-updating-your-app"></a>

アプリケーションを更新し、CodeDeploy コンソールを使用するか、[create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) コマンドを呼び出してリビジョンをプッシュできます。

## 停止、失敗したデプロイ
<a name="deployment-stop-fail"></a>

デプロイを停止するには、CodeDeploy コンソールまたは[stop-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/stop-deployment.html)コマンドを使用できます。デプロイを停止しようとする場合、次の 3 つのうち 1 つのことが発生します。
+ デプロイは停止し、オペレーションは成功というステータスを返す。この場合、停止したデプロイに対してそれ以上デプロイライフサイクルイベントは実行されません。デプロイグループで一部のファイルは既にコピーされ、一部のスクリプトは実行され、1 つ以上のインスタンスが実行されている可能性があります。
+ デプロイは即時に停止せず、オペレーションは保留中というステータスを返す。この場合、一部のデプロイライフサイクルイベントは、デプロイグループでまだ実行中である可能性があります。デプロイグループで一部のファイルは既にコピーされ、一部のスクリプトは実行され、1 つ以上のインスタンスが実行されている可能性があります。保留中のオペレーションが完了すると、デプロイを停止するためのそれ以降の呼び出しは、成功というステータスを返します。
+ デプロイは停止できず、オペレーションはエラーを返す。詳細については、 AWS CodeDeploy API リファレンスの[ErrorInformation](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_ErrorInformation.html)」と[「一般的なエラー](https://docs.aws.amazon.com/codedeploy/latest/APIReference/CommonErrors.html)」を参照してください。

失敗したデプロイでは、停止されたデプロイのように、デプロイグループの 1 つ以上のインスタンスで一部のデプロイライフサイクルイベントが実行済みになる場合があります。デプロイが失敗した理由を調べるには、CodeDeploy コンソールを使用して、[get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html) コマンドを呼び出すか、失敗したデプロイのログファイルデータを分析することができます。詳細については、「[アプリケーションリビジョンとログファイルのクリーンアップ](codedeploy-agent.md#codedeploy-agent-revisions-logs-cleanup)」および「[CodeDeploy EC2/オンプレミスデプロイのログデータの表示](deployments-view-logs.md)」を参照してください。

## デプロイと再デプロイのロールバック
<a name="deployment-rollback"></a>

CodeDeploy は新しいデプロイとして、以前にデプロイされたリビジョンを再デプロイすることによって、ロールバックを実装します。

デプロイが失敗した、アラームのモニタリングしきい値に一致したなど、特定の条件が満たされた場合に、自動的にデプロイをロールバックするようグループデプロイを設定できます。個別のデプロイで、デプロイグループに指定されたロールバック設定をオーバーライドすることもできます。

以前のデプロイされたバージョンを手動で再デプロイして、失敗したデプロイをロールバックすることもできます。

いずれの場合でも、新しいデプロイまたはロールバックされたデプロイには独自のデプロイ ID が割り当てられます。CodeDeploy コンソールで表示できるデプロイの一覧には、どれが自動デプロイの結果であるかが示されます。

詳細については、「[CodeDeploy を使用した再デプロイおよびデプロイのロールバック](deployments-rollback-and-redeploy.md)」を参照してください。