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

# CodeDeploy とは
<a name="welcome"></a>

CodeDeploy は、Amazon EC2 インスタンスやオンプレミスインスタンス、サーバーレス Lambda 関数、または Amazon ECS サービスに対するアプリケーションのデプロイを自動化するデプロイメントサービスです。

以下のような、ほぼ無制限の多様なアプリケーションコンテンツをデプロイできます。
+ コード
+ サーバーレス AWS Lambda 関数
+ ウェブファイルおよび設定ファイル
+ Executables
+ パッケージ
+ スクリプト
+ マルチメディアファイル

CodeDeploy では、サーバーで実行され、Amazon S3 バケット、GitHub リポジトリ、または Bitbucket リポジトリに保存されているアプリケーションコンテンツをデプロイできます。CodeDeploy では、サーバーレス Lambda 関数をデプロイすることもできます。既存のコードを変更することなく CodeDeploy を使用できます。

CodeDeploy を使用すると、以下を容易に行うことができます。
+ 新機能の迅速なリリース。
+  AWS Lambda 関数のバージョンを更新します。
+ アプリケーションのデプロイメント中のダウンタイム回避。
+ アプリケーションの更新に伴う繁雑さを処理。エラーの発生しやすい手動デプロイに伴うリスクの多くを回避できます。

サービスはインフラストラクチャに合わせてスケールするため、1 つのインスタンスまたは数千のインスタンスに簡単にデプロイできます。

CodeDeploy は、設定管理、ソース管理、[継続的統合](https://aws.amazon.com/devops/continuous-integration/)、[継続的配信](https://aws.amazon.com/devops/continuous-delivery/)、および継続的デプロイのための様々なシステムで動作します。詳細については、「[製品の統合](https://aws.amazon.com/codedeploy/product-integrations/)」を参照してください。

 また、CodeDeploy コンソールでは、リポジトリ、ビルドプロジェクト、デプロイアプリケーション、パイプラインなどのリソースをすばやく検索することもできます。[**Go to resource (リソースに移動)**] または `/` キーを押して、リソースの名前を入力します。一致するものはすべてリストに表示されます。検索では大文字と小文字が区別されません。リソースを表示する権限がある場合のみ表示されます。詳細については、「[の ID とアクセスの管理 AWS CodeDeploy](security-iam.md)」を参照してください。

**Topics**
+ [

## の利点 AWS CodeDeploy
](#benefits)
+ [

## CodeDeploy コンピューティングプラットフォームの概要
](#compute-platform)
+ [

## CodeDeploy デプロイタイプの概要
](#welcome-deployment-overview)
+ [

## ご意見をお待ちしております
](#welcome-contact-us)
+ [Primary Components](primary-components.md)
+ [Deployments](deployment-steps.md)
+ [Application Specification Files](application-specification-files.md)

## の利点 AWS CodeDeploy
<a name="benefits"></a>

CodeDeploy には、次の利点があります。
+ **サーバー、サーバーレス、コンテナアプリケーション**。CodeDeploy では、従来のアプリケーションと、サーバーレス AWS Lambda 関数バージョンまたは Amazon ECS アプリケーションをデプロイするアプリケーションの両方をデプロイできます。
+ **自動デプロイ** CodeDeploy は、開発、テスト、本番稼働環境にまたがるアプリケーションのデプロイを完全に自動化します。CodeDeployは、インフラストラクチャに合わせてスケールするため、1 つのインスタンスまたは数千のインスタンスにデプロイできます。
+ **ダウンタイムの最小化**。アプリケーションで EC2/オンプレミスコンピューティングプラットフォームを使用している場合、CodeDeploy は、アプリケーションの可用性を最大化します。インプレースデプロイの場合、CodeDeploy は複数の Amazon EC2 インスタンスにまたがってローリング更新を実行します。更新のために、一度にオフラインにするインスタンスの数を指定できます。Blue/Green デプロイの間、最新アプリケーションのリビジョンは、置き換え先インスタンスにインストールされます。トラフィックは、選択するとすぐに、または新しい環境のテストが完了した時点で、これらのインスタンスに再ルーティングされます。どちらのデプロイタイプでも、CodeDeploy は設定したルールに従ってアプリケーションの状態を追跡します。
+ **停止してロールバック**。エラーが発生した場合、自動または手動でデプロイを停止してロールバックできます。
+ **コントロールの一元化**。CodeDeploy コンソールまたは AWS CLIでデプロイを起動し、そのステータスを追跡できます。各アプリケーションのリビジョンがいつデプロイされ、どの Amazon EC2 インスタンスがリストされているかを示すレポートを受け取ります。
+ **使い方が簡単**。CodeDeploy は、プラットフォームに依存せず、すべてのアプリケーションで動作します。セットアップコードは簡単に再利用できます。セットアップコードを簡単に再利用できます。また、CodeDeploy はソフトウェアリリースプロセスまたは継続的な配信ツールチェーンと統合できます。
+ **同時デプロイ**。EC2/オンプレミスコンピューティングプラットフォームを使用する複数のアプリケーションがある場合、CodeDeploy は同じインスタンスのセットでこれらを同時にデプロイできます。



## CodeDeploy コンピューティングプラットフォームの概要
<a name="compute-platform"></a>

CodeDeploy では、アプリケーションを 3 つのコンピューティングプラットフォームにデプロイできます。
+ **EC2/オンプレミス**: Amazon EC2 クラウドインスタンス、オンプレミスサーバー、またはその両方とすることができる物理サーバーのインスタンスを記述します。EC2/オンプレミスコンピューティングプラットフォームを使用して作成されたアプリケーションは、実行可能ファイル、設定ファイル、イメージなどで構成できます。

  EC2/オンプレミス コンピューティングプラットフォームを使用するデプロイでは、インプレイスまたは Blue/Green デプロイタイプを使用して、トラフィックをインスタンスに振り分ける方法を管理できます。詳細については、「[CodeDeploy デプロイタイプの概要](#welcome-deployment-overview)」を参照してください。
+ **AWS Lambda**: 更新されたバージョンの Lambda 関数で構成されるアプリケーションをデプロイするために使用されます。 は、高可用性コンピューティング構造で構成されるサーバーレスコンピューティング環境で Lambda 関数 AWS Lambda を管理します。コンピューティングリソースの管理はすべて、 によって実行されます AWS Lambda。詳細については、「[サーバーレスコンピューティングとアプリケーション](https://aws.amazon.com/serverless/)」を参照してください。 AWS Lambda および Lambda 関数の詳細については、「」を参照してください[AWS Lambda](https://aws.amazon.com/lambda/)。

  Canary 設定、線形設定、または一度にすべての設定を選択して、デプロイ時に更新済み Lambda 関数バージョンにトラフィックを移行する方法を管理できます。
+ **Amazon ECS**：Amazon ECS にコンテナ化されたアプリケーションをタスクセットとしてデプロイするために使用します。CodeDeploy は、アプリケーションの更新バージョンを新しい置き換えタスクセットとしてインストールすることで、blue/Green のデプロイを実行します。CodeDeploy は、元のアプリケーションタスクセットからの本稼働トラフィックを置き換えタスクセットに再ルーティングします。デプロイが正常に完了すると、元のタスクセットは終了します。Amazon ECS の詳細については、「[Amazon Elastic Container Service](https://aws.amazon.com/ecs/)」を参照してください。

  Canary 設定、線形設定、または一度にすべての設定を選択して、デプロイ時に更新済みタスクセットにトラフィックを移行する方法を管理できます。
**注記**  
Amazon ECS blue/Green デプロイは、CodeDeploy と CloudFormationの両方でサポートされています。これらのデプロイの詳細については、以降のセクションで説明します。

次の表に、CodeDeploy コンポーネントが各コンピューティングプラットフォームで使用される様子を示します。詳細については、以下を参照してください。
+  [CodeDeploy でのデプロイグループの使用](deployment-groups.md) 
+  [CodeDeploy でのデプロイグループの使用](deployments.md) 
+  [CodeDeploy でデプロイ設定を使用する](deployment-configurations.md) 
+  [CodeDeploy のアプリケーションリビジョンの操作](application-revisions.md) 
+  [CodeDeploy 内でアプリケーションを用いて作業をする](applications.md) 


| CodeDeploy コンポーネント | EC2/オンプレミス | AWS Lambda | Amazon ECS | 
| --- | --- | --- | --- | 
| デプロイグループ | 一連のインスタンスにリビジョンをデプロイします。 | 可用性の高いコンピューティングインフラストラクチャで、サーバーレス Lambda 関数の新しいバージョンをデプロイします。 | タスクセットとしてデプロイする、コンテナ化されたアプリケーション、デプロイされたアプリケーションへのトラフィック提供に使用される本稼働およびオプションのテストリスナー、トラフィックを再ルーティングし、デプロイされたアプリケーションの元のタスクセットを終了するタイミング、オプションのトリガー、アラーム、およびロールバック設定で Amazon ECS サービスを指定します。 | 
| デプロイメント | アプリケーションと AppSpec ファイルから構成される新しいリビジョンをデプロイします。AppSpec は、アプリケーションをデプロイグループのインスタンスにデプロイする方法を指定します。 | Lambda 関数の 1 つのバージョンから、同じ関数の新しいバージョンに本稼働トラフィックを移行させます。AppSpec は、デプロイする Lambda 関数のバージョンを指定します。 | Amazon ECS コンテナ化されたアプリケーションの更新バージョンを、新しい置き換えタスクセットとしてデプロイします。CodeDeploy は、タスクセットからの本稼働トラフィックを置き換えタスクセットに再ルーティングします。デプロイ完了時に、元のタスクセットは削除されます。 | 
| Deployment configuration | デプロイの速度と、デプロイ中にいつでも使用できる必要のある正常なインスタンスの最小数を決定する設定。 | 更新された Lambda 関数バージョンにトラフィックを移行する方法を決定する設定。 | 更新された Amazon ECS タスクセットにトラフィックを移行する方法を決定する設定。 | 
| リビジョン | AppSpec ファイルとアプリケーションファイルの組み合わせ (例: 実行ファイル、設定ファイル)。 | AppSpec ファイルは Lambda 関数と、ライフサイクルイベントフック中に検証テストを実行可能な Lambda 関数のデプロイを指定します。 |  AppSpec ファイル以下を指定する。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/welcome.html)  | 
| アプリケーション | デプロイグループおよびリビジョンのコレクション。EC2/オンプレミスアプリケーションは、EC2/オンプレミスコンピューティングプラットフォームを使用します。 | デプロイグループおよびリビジョンのコレクション。 AWS Lambda デプロイに使用されるアプリケーションは、サーバーレス AWS Lambda コンピューティングプラットフォームを使用します。 | デプロイグループおよびリビジョンのコレクション。Amazon ECS デプロイに使用されるアプリケーションは、Amazon ECS コンピューティングプラットフォームを使用します。 | 

## CodeDeploy デプロイタイプの概要
<a name="welcome-deployment-overview"></a>

CodeDeploy には、2 つのデプロイタイプのオプションがあります。
+ **インプレイスデプロイ**: デプロイグループの各インスタンス上のアプリケーションが停止され、最新のアプリケーションリビジョンがインストールされて、新バージョンのアプリケーションが開始され検証されます。ロードバランサーを使用し、デプロイ中はインスタンスが登録解除され、デプロイ完了後にサービスに復元されるようにできます。EC2 オンプレミスコンピューティングプラットフォームを使用するデプロイのみが、インプレイスデプロイを使用できます。インプレイスデプロイの詳細については、「[インプレースデプロイの概要](#welcome-deployment-overview-in-place)」を参照してください。
**注記**  
AWS Lambda および Amazon ECS デプロイでは、インプレースデプロイタイプを使用できません。
+ **Blue/Green デプロイ**: デプロイの動作は、使用するコンピューティングプラットフォームにより異なります。
  + **EC2 オンプレミスコンピューティングプラットフォームの Blue/Green**: 以下のステップを使用して、デプロイグループのインスタンス (元の環境) がインスタンスの別のセット (置き換え先環境) に置き換えられます。
    + 置き換え先の環境のインスタンスがプロビジョニングされます。
    + 最新のアプリケーションリビジョンは、置き換え先インスタンスにインストールされます。
    + オプションの待機時間は、アプリケーションのテストやシステム検証などのアクティビティに対して発生します。
    + 置き換え先環境のインスタンスは、1 つまたは複数の Elastic Load Balancing ロードバランサーに登録され、トラフィックは、それらに再ルーティングされます。元の環境のインスタンスは、登録が解除され、終了するか、他の使用のために実行することができます。
**注記**  
EC2/オンプレミスのコンピューティングプラットフォームを使用する場合は、blue/green デプロイが Amazon EC2 インスタンスでのみ機能することに注意してください。
  + ** AWS Lambda または Amazon ECS コンピューティングプラットフォームの Blue/Green**: トラフィックは**、Canary**、**線形**、または **all-at-once**のデプロイ設定に従って増分でシフトされます。
  + **経由のブルー/グリーンデプロイ CloudFormation**: CloudFormation スタックの更新の一環として、トラフィックは現在のリソースから更新されたリソースに移行されます。現時点では、ECS blue/green デプロイのみがサポートされています。

  ブルー/グリーンデプロイの詳細については、「[Blue/Green デプロイの概要](#welcome-deployment-overview-blue-green)」を参照してください。

**注記**  
CodeDeploy エージェントを使用すると、アプリケーション、デプロイグループ、または AWS アカウントを必要とせずに、サインインしているインスタンスでデプロイを実行できます。詳細については、「[CodeDeploy エージェントを使用してローカルマシン上のデプロイパッケージを検証する](deployments-local.md)」を参照してください。

**Topics**
+ [

### インプレースデプロイの概要
](#welcome-deployment-overview-in-place)
+ [

### Blue/Green デプロイの概要
](#welcome-deployment-overview-blue-green)

### インプレースデプロイの概要
<a name="welcome-deployment-overview-in-place"></a>

**注記**  
AWS Lambda および Amazon ECS デプロイでは、インプレースデプロイタイプを使用できません。

インプレイスデプロイの仕組みは次のとおりです。

1. 最初に、ローカルの開発用マシンまたは同様の環境でデプロイ可能なコンテンツを作成し、*アプリケーション特定ファイル*（AppSpecファイル) を追加します。AppSpec ファイルは CodeDeploy に固有です。CodeDeploy で実行するデプロイアクションを定義します。デプロイ可能なコンテンツおよび AppSpec ファイルをアーカイブファイルにバンドルし、Amazon S3 バケットまたは GitHub リポジトリにアップロードします。このアーカイブファイルは、*アプリケーションリビジョン* (または単に*リビジョン*) と呼ばれます。

1. 次に、リビジョンを取得する Amazon S3 バケットまたは GitHub リポジトリ、コンテンツをデプロイする Amazon EC2 インスタンスのセットなど、デプロイに関する情報を CodeDeploy に提供します。CodeDeploy は Amazon EC2 インスタンスのセットを *デプロイグループ* で呼び出します。デプロイグループには、個別にタグ付けされた Amazon EC2 インスタンス、Amazon EC2 Auto Scaling グループ内の Amazon EC2 インスタンス、またはその両方が含まれます。

   デプロイグループにデプロイする新しいアプリケーションリビジョンを正常にアップロードするたびに、そのバンドルはデプロイグループの*ターゲットリビジョン*として設定されます。つまり、現在デプロイ対象となっているアプリケーションリビジョンがターゲットリビジョンです。これは、自動デプロイにプルされるリビジョンでもあります。

1. 次に、各インスタンスの CodeDeploy エージェントが CodeDeploy をポーリングして、指定された Amazon S3 バケットまたは GitHub リポジトリから何をいつ取得するかを決定します。

1. 最後に、各インスタンスの CodeDeploy エージェントは、Amazon S3 バケットや GitHub リポジトリからターゲットリビジョンを取得し、AppSpec ファイルの手順を使用して、コンテンツをインスタンスにデプロイします。

 CodeDeploy は、デプロイステータス、デプロイ設定パラメータ、インスタンスの状態を取得できるように、デプロイのレコードを保持します。

### Blue/Green デプロイの概要
<a name="welcome-deployment-overview-blue-green"></a>

Blue/Green デプロイは、アプリケーションの新しいバージョンの変更による中断を最小限に抑えながら、アプリケーションの更新に使用されます。CodeDeploy は、本番トラフィックを再ルーティングする前に、古いバージョンと一緒に新しいアプリケーションバージョンをプロビジョニングします。
+  **AWS Lambda**: トラフィックは、Lambda 関数の 1 つのバージョンから、同じ Lambda 関数の新しいバージョンに移行されます。
+  **Amazon ECS**: Amazon ECS サービスのタスクセットから、同じ Amazon ECS サービスの最新の置き換えタスクセットにトラフィックが移行します。
+  **EC2/オンプレミス**: 元の環境内の、あるインスタンスセットから、インスタンスの置き換え先のセットにトラフィックが移行します。

すべての AWS Lambda および Amazon ECS デプロイは Blue/Green です。EC2/オンプレミス デプロイは、インプレースまたは Blue/Green です。Blue/Green デプロイには、インプレースデプロイと比べて多くのメリットがあります。
+ トラフィックを再ルーティングするだけで、アプリケーションを新しい置き換え先環境にインストールしてテストし、本稼働環境へデプロイできます。
+  EC2/オンプレミスコンピューティングプラットフォーム を使用している場合、最新バージョンのアプリケーションに切り替えることで、より迅速になり、信頼性が高まります。これは、トラフィックが終了していない限り、トラフィックを元のインスタンスにルーティングできるためです。インプレースデプロイでは、以前のバージョンのアプリケーションを再デプロイすることによってバージョンをロールバックする必要があります。
+ EC2/オンプレミスコンピューティングプラットフォーム を使用している場合、新しいインスタンスは Blue/Green デプロイ向けにプロビジョニングされ、最新のサーバー設定が反映されます。これにより、長時間実行するインスタンスで発生する問題を回避できます。
+  AWS Lambda コンピューティングプラットフォームを使用している場合は、トラフィックを元の AWS Lambda 関数バージョンから新しい Lambda AWS 関数バージョンに移行する方法を制御します。
+ Amazon ECS コンピューティングプラットフォームを使用している場合は、元のタスクセットから新しいタスクセットにトラフィックを移行する方法を制御します。

を使用した Blue/Green デプロイ CloudFormation では、次のいずれかの方法を使用できます。
+ **CloudFormation デプロイ用の テンプレート**: CloudFormation テンプレートを使用してデプロイを設定すると、デプロイは CloudFormation 更新によってトリガーされます。リソースを変更してテンプレートの変更をアップロードすると、 のスタック更新によって新しいデプロイ CloudFormation が開始されます。 CloudFormation テンプレートで使用できるリソースのリストについては、「」を参照してください[CloudFormation CodeDeploy リファレンスの テンプレート](reference-cloudformation-templates.md)。
+ **によるブルー/グリーンデプロイ CloudFormation**: を使用して CloudFormation 、スタックの更新を通じてブルー/グリーンデプロイを管理できます。スタックテンプレート内で、トラフィックルーティングと安定化設定を指定するだけでなく、Blue ソースと Green リソースの両方を定義します。次に、スタックの更新中に選択したリソースを更新すると、 は必要なすべてのグリーンリソース CloudFormation を生成し、指定されたトラフィックルーティングパラメータに基づいてトラフィックをシフトし、ブルーリソースを削除します。詳細については、[[CloudFormationユーザーガイド](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/blue-green.html)] の [*AWS CloudFormation を使用した CodeDeploy による Perform Amazon ECS Blue/Green デプロイの実行*] を参照してください。
**注記**  
Amazon ECS Blue/Green デプロイでのみサポートされます。

Blue/Green デプロイを設定する方法は、使用するコンピューティングプラットフォームによって異なります。



#### AWS Lambda または Amazon ECS コンピューティングプラットフォームでのブルー/グリーンデプロイ
<a name="blue-green-lambda-compute-type"></a>

 AWS Lambda または Amazon ECS コンピューティングプラットフォームを使用している場合は、トラフィックを元の AWS Lambda 関数または Amazon ECS タスクセットから新しい関数またはタスクセットに移行する方法を指定する必要があります。トラフィックを移行する方法を指定するには、以下のいずれかのデプロイ設定を指定する必要があります。
+ **canary**
+ **線形**
+ **一度にすべて**

Canary 設定、線形設定、または一度にすべてのデプロイ設定でトラフィックを移行する方法については、「[Deployment configuration](primary-components.md#primary-components-deployment-configuration)」を参照してください。

Lambda デプロイ設定の詳細については、「[AWS Lambda コンピューティングプラットフォームでのデプロイ設定](deployment-configurations.md#deployment-configuration-lambda)」を参照してください。

Amazon ECS デプロイ設定の詳細については、「[Amazon ECS コンピューティングプラットフォームのデプロイ設定](deployment-configurations.md#deployment-configuration-ecs)」を参照してください。

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

**注記**  
EC2/オンプレミスコンピューティングプラットフォームでの Blue/Green デプロイには、Amazon EC2 インスタンスを使用する必要があります。オンプレミスインスタンスは Blue/Green デプロイタイプではサポートされません。

EC2/オンプレミスコンピューティングプラットフォームを使用している場合は、次が適用されます。

 Amazon EC2 タグまたは Amazon EC2 Auto Scaling グループを識別する 1 つ以上の Amazon EC2 インスタンスが必要です。インスタンスは、以下の条件を満たす必要があります。
+ 各 Amazon EC2 インスタンスには、適切な IAM インスタンスプロファイルが添付されている必要があります。
+ 各インスタンスで CodeDeploy エージェントをインストールして実行する必要があります。

**注記**  
通常は、元の環境のインスタンスでアプリケーションリビジョンも実行しますが、これは Blue/Green デプロイの要件ではありません。

Blue/Green デプロイで使用されるデプロイグループを作成するときは、置き換え先環境の指定方法を選択できます。

**既存の Amazon EC2 Auto Scaling グループのコピー**: Blue/Green デプロイでは、CodeDeploy は、デプロイ中に置き換え先環境用のインスタンスを作成します。このオプションを使用すると、CodeDeploy は、指定した Amazon EC2 Auto Scaling グループを置き換え先環境のテンプレートとして使用します。これには、同じ数の実行中のインスタンスと他の多くの設定オプションが含まれます。

**手動でインスタンスを選択**: Amazon EC2 インスタンスタグ、Amazon EC2 Auto Scaling グループ名、またはその両方を使用して、置き換え先として含めるインスタンスを指定できます。このオプションを選択した場合、デプロイを作成するまで置き換え先環境のインスタンスを指定する必要はありません。

処理の流れ

1. 元の環境となるインスタンスや Amazon EC2 Auto Scaling グループは既にあります。Blue/Green デプロイを初めて実行するときは、通常、インプレースデプロイで既に使用されているインスタンスを使用します。

1. 既存の CodeDeploy アプリケーションでは、Blue/Green デプロイグループを作成し、インプレースデプロイに必要なオプションに加えて、次を指定します。
   + ブルー/グリーンデプロイプロセス中に元の環境から置き換え先環境にトラフィックをルーティングするロードバランサー。
   + 置き換え先環境にトラフィックを直ちに再ルーティングするか、手動で再ルーティングするまで待つかどうか。
   + トラフィックが置き換え先インスタンスにルーティングされるレート。
   + 置き換え元インスタンスを削除するか引き続き実行するかどうか。

1. このデプロイグループのデプロイを作成するときには、次の処理が行われます。

   1. Amazon EC2 Auto Scaling グループをコピーすることを選択した場合、インスタンスは置き換え先環境にプロビジョニングされます。

   1. デプロイに指定したアプリケーションリビジョンは、置き換え先インスタンスにインストールされます。

   1. デプロイグループの設定で待機時間を指定した場合、デプロイは一時停止します。これは置き換え先環境のテストおよび確認を実行できる時間です。待機時間が終了する前にトラフィックを手動で再ルーティングしない場合、デプロイは停止します。

   1. 置き換え先環境のインスタンスは Elastic Load Balancing ロードバランサーに登録され、これらのインスタンスに対してトラフィックのルーティングが開始されます。

   1. 元の環境のインスタンスは、終了するか引き続き実行するか、デプロイグループの指定に従って登録が解除され、処理されます。

#### によるブルー/グリーンデプロイ CloudFormation
<a name="blue-green-cfn-config-type"></a>

 CloudFormation テンプレートを使用してリソースをモデリングすることで、CodeDeploy Blue/Green のデプロイを管理できます。

 CloudFormation テンプレートを使用して Blue/Green リソースをモデル化するときは、タスクセット CloudFormation を更新するスタック更新を に作成します。本稼働トラフィックは、すべて一度に、線形デプロイとベイク処理時間を使用して、または Canary デプロイを使用してサービスの元のタスクセットから置き換えタスクセットにシフトします。スタックの更新により、CodeDeploy でデプロイが開始されます。CodeDeploy でデプロイのステータスと履歴を表示できますが、それ以外の場合は CloudFormation 、テンプレートの外部で CodeDeploy リソースを作成または管理しません。

**注記**  
を通じてブルー/グリーンデプロイを行う場合 CloudFormation、CodeDeploy アプリケーションまたはデプロイグループを作成しません。

この方法では、Amazon ECS Blue/Green デプロイのみサポートされます。によるブルー/グリーンデプロイの詳細については CloudFormation、「」を参照してください[を使用して Amazon ECS ブルー/グリーンデプロイを作成する CloudFormation](deployments-create-ecs-cfn.md)。

## ご意見をお待ちしております
<a name="welcome-contact-us"></a>

ご意見をお待ちしております。お問い合わせの場合には、[CodeDeploy フォーラム](https://forums.aws.amazon.com/forum.jspa?forumID=179) をご利用ください。

**トピック**
+ [Primary Components](primary-components.md)
+ [Deployments](deployment-steps.md)
+ [Application Specification Files](application-specification-files.md)

# CodeDeploy プライマリコンポーネント
<a name="primary-components"></a>

サービスの使用をスタートする前に、CodeDeploy デプロイプロセスの主なコンポーネントを理解しておく必要があります。

**Topics**
+ [

## アプリケーション
](#primary-components-application)
+ [

## コンピューティングプラットフォーム
](#primary-components-compute-platform)
+ [

## Deployment configuration
](#primary-components-deployment-configuration)
+ [

## デプロイグループ
](#primary-components-deployment-group)
+ [

## デプロイタイプ
](#primary-components-deployment-type)
+ [

## IAM インスタンスプロファイル
](#primary-components-iam-instance-profile)
+ [

## リビジョン
](#primary-components-revision)
+ [

## サービスロール
](#primary-components-service-role)
+ [

## ターゲットリビジョン
](#primary-components-target-revision)
+ [

## 他のコンポーネント
](#primary-components-other-components)

## アプリケーション
<a name="primary-components-application"></a>

*アプリケーション*は、デプロイしたいアプリケーションを一意に識別する名前です。CodeDeploy はこの名前をコンテナとして使用して、デプロイ中にリビジョン、デプロイ設定、およびデプロイグループの正しい組み合わせが参照されるようにします。

## コンピューティングプラットフォーム
<a name="primary-components-compute-platform"></a>

*コンピューティングプラットフォーム*は、CodeDeploy がアプリケーションをデプロイするプラットフォームです。コンピューティングプラットフォームは 3 つあります。
+ **EC2/オンプレミス**: Amazon EC2 クラウドインスタンス、オンプレミスサーバー、またはその両方とすることができる物理サーバーのインスタンスを記述します。EC2/オンプレミスコンピューティングプラットフォームを使用して作成されたアプリケーションは、実行可能ファイル、設定ファイル、イメージなどで構成できます。

  EC2/オンプレミス コンピューティングプラットフォームを使用するデプロイでは、インプレイスまたは Blue/Green デプロイタイプを使用して、トラフィックをインスタンスに振り分ける方法を管理できます。詳細については、「[CodeDeploy デプロイタイプの概要](welcome.md#welcome-deployment-overview)」を参照してください。
+ **AWS Lambda**: Lambda 関数の更新バージョンで構成されるアプリケーションをデプロイするために使用されます。 は、高可用性コンピューティング構造で構成されるサーバーレスコンピューティング環境で Lambda 関数 AWS Lambda を管理します。コンピューティングリソースの管理はすべて、 によって実行されます AWS Lambda。詳細については、「[サーバーレスコンピューティングとアプリケーション](https://aws.amazon.com/serverless/)」を参照してください。 AWS Lambda および Lambda 関数の詳細については、「」を参照してください[AWS Lambda](https://aws.amazon.com/lambda/)。

  Canary 設定、線形設定、または一度にすべての設定を選択して、デプロイ時に更新済み Lambda 関数バージョンにトラフィックを移行する方法を管理できます。
+ **Amazon ECS**：Amazon ECS にコンテナ化されたアプリケーションをタスクセットとしてデプロイするために使用します。CodeDeploy は、アプリケーションの更新バージョンを新しい置き換えタスクセットとしてインストールすることで、blue/Green のデプロイを実行します。CodeDeploy は、元のアプリケーションタスクセットからの本稼働トラフィックを置き換えタスクセットに再ルーティングします。デプロイが正常に完了すると、元のタスクセットは終了します。Amazon ECS の詳細については、「[Amazon Elastic Container Service](https://aws.amazon.com/ecs/)」を参照してください。

  Canary 設定、線形設定、または一度にすべての設定を選択して、デプロイ時に更新済みタスクセットにトラフィックを移行する方法を管理できます。

**注記**  
Amazon ECS Blue/Green デプロイは、CodeDeploy と CloudFormationの両方でサポートされています。これらのデプロイの詳細については、以降のセクションで説明します。

## Deployment configuration
<a name="primary-components-deployment-configuration"></a>

*デプロイ設定*は、デプロイ時に CodeDeploy が使用する一連のデプロイのルール、デプロイの成功条件、デプロイの失敗条件です。デプロイで EC2/オンプレミスコンピューティングプラットフォームを使用している場合、デプロイの正常なインスタンスの最小数を指定できます。デプロイで AWS Lambda または Amazon ECS コンピューティングプラットフォームを使用している場合は、更新された Lambda 関数または ECS タスクセットにトラフィックをルーティングする方法を指定できます。

EC2/オンプレミスコンピューティングプラットフォームを使用したデプロイに対する正常なホストの最小数の指定については、「[正常なインスタンスの最小数について](instances-health.md#minimum-healthy-hosts)」を参照してください。

以下のデプロイ設定では、Lambda または ECS コンピューティングプラットフォームを使用するデプロイの間にトラフィックをルーティングする方法を指定します。
+ **Canary**: トラフィックは 2 つの増分で移行されます。事前定義された canary オプションから選択できます。これらのオプションでは、更新された Lambda 関数または ECS タスクセットに、2 回目の増分で移行される前に最初の増分および間隔 (分単位) で移行される、トラフィックの割合 (%) が指定されています。
+ **Linear**: トラフィックは等しい増分で移行され、増分間の間隔 (分) も同じです。増分ごとに移行するトラフィックの割合 (%) と、増分間の間隔 (分) を指定する、事前定義済み線形オプションから選択できます。
+ **一度にすべて**: すべてのトラフィックを元の Lambda 関数または ECS タスクセットから更新された関数またはタスクセットに同時に移行します。

## デプロイグループ
<a name="primary-components-deployment-group"></a>

*デプロイグループ*は、個々のインスタンスのセットです。デプロイグループには、個別にタグ付けされた Amazon EC2 インスタンス、Amazon EC2 Auto Scaling グループ内の Amazon EC2 インスタンス、またはその両方が含まれます。Amazon EC2 インスタンスタグの詳細については、「[コンソールでのタグの操作](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。オンプレミスインスタンスの詳細については、「[CodeDeploy 用のオンプレミスインスタンスを用いての作業](instances-on-premises.md)」を参照してください。Amazon EC2 Auto Scaling の情報に関しては、「[CodeDeploy と Amazon EC2 Auto Scaling の統合](integrations-aws-auto-scaling.md)」を参照してください。

## デプロイタイプ
<a name="primary-components-deployment-type"></a>

*デプロイタイプ*は、デプロイグループ内のインスタンスで最新のアプリケーションリビジョンを使用できるようにするために使用される方法です。次の 2 種類のデプロイタイプがあります。
+ **インプレイスデプロイ**: デプロイグループの各インスタンス上のアプリケーションが停止され、最新のアプリケーションリビジョンがインストールされて、新バージョンのアプリケーションが開始され検証されます。ロードバランサーを使用し、デプロイ中はインスタンスが登録解除され、デプロイ完了後にサービスに復元されるようにできます。EC2 オンプレミスコンピューティングプラットフォームを使用するデプロイのみが、インプレイスデプロイを使用できます。インプレイスデプロイの詳細については、「[インプレースデプロイの概要](welcome.md#welcome-deployment-overview-in-place)」を参照してください。
+ **Blue/Green デプロイ**: デプロイの動作は、使用するコンピューティングプラットフォームにより異なります。
  + **EC2 オンプレミスコンピューティングプラットフォームの Blue/Green**: 以下のステップを使用して、デプロイグループのインスタンス (元の環境) がインスタンスの別のセット (置き換え先環境) に置き換えられます。
    + 置き換え先の環境のインスタンスがプロビジョニングされます。
    + 最新のアプリケーションリビジョンは、置き換え先インスタンスにインストールされます。
    + オプションの待機時間は、アプリケーションのテストやシステム検証などのアクティビティに対して発生します。
    + 置き換え先環境のインスタンスは、1 つまたは複数の Elastic Load Balancing ロードバランサーに登録され、トラフィックは、それらに再ルーティングされます。元の環境のインスタンスは、登録が解除され、終了するか、他の使用のために実行することができます。
**注記**  
EC2/オンプレミスのコンピューティングプラットフォームを使用する場合は、blue/green デプロイが Amazon EC2 インスタンスでのみ機能することに注意してください。
  + ** AWS Lambda または Amazon ECS コンピューティングプラットフォームの Blue/Green**: トラフィックは**、Canary**、**線形**、または **all-at-once**のデプロイ設定に従って増分でシフトされます。
  + **経由のブルー/グリーンデプロイ CloudFormation**: スタック CloudFormation の更新の一環として、トラフィックは現在のリソースから更新されたリソースに移行されます。現時点では、ECS blue/green デプロイのみがサポートされています。

  ブルー/グリーンデプロイの詳細については、「[Blue/Green デプロイの概要](welcome.md#welcome-deployment-overview-blue-green)」を参照してください。

**注記**  
Amazon ECS blue/Green デプロイは、CodeDeploy と CloudFormationの両方でサポートされています。これらのデプロイの詳細については、以降のセクションで説明します。

## IAM インスタンスプロファイル
<a name="primary-components-iam-instance-profile"></a>

*IAM インスタンスプロファイル*は、Amazon EC2 インスタンス にアタッチする IAM ロールです。このプロファイルには、アプリケーションが保存される Amazon S3 バケットまたは GitHub リポジトリへのアクセスに必要な権限が含まれます。詳細については、「[ステップ 4: Amazon EC2 インスタンス用の IAM インスタンスプロファイルを作成する](getting-started-create-iam-instance-profile.md)」を参照してください。

## リビジョン
<a name="primary-components-revision"></a>

リビジョン**は、アプリケーションのバージョンです。 AWS Lambda デプロイリビジョンは、デプロイする Lambda 関数に関する情報を指定する YAML 形式または JSON 形式のファイルです。EC2/オンプレミスデプロイリビジョンは、ソースコンテンツ (ソースコード、ウェブページ、実行可能ファイル、デプロイスクリプト) とアプリケーション仕様ファイル (AppSpec ファイル) を含むアーカイブファイルです。 AWS Lambda リビジョンは Amazon S3 バケットに保存できます。EC2/オンプレミスのリビジョンは Amazon S3 バケットまたは GitHub リポジトリに格納されます。Amazon S3 では、リビジョンの Amazon S3 オブジェクトキー、ETag、バージョン、またはその両方により、リビジョンが一意に識別されます。GitHub では、コミット ID により、リビジョンが一意に識別されます。

## サービスロール
<a name="primary-components-service-role"></a>

*サービスロール*は、 AWS リソースにアクセスできるように AWS サービスにアクセス許可を付与する IAM ロールです。サービスロールにアタッチするポリシーによって、サービスがアクセスできる AWS リソースと、それらのリソースで実行できるアクションが決まります。CodeDeploy では、サービスロールは、以下の目的で使用されます。
+ インスタンスに適用されているタグやインスタンスに関連付けられている Amazon EC2 Auto Scaling グループ名を読み取ることができます。これにより、CodeDeploy はアプリケーションをデプロイできるインスタンスを識別できます。
+ インスタンス、Amazon EC2 Auto Scaling グループ、および Elastic Load Balancing ロードバランサーでオペレーションを実行するには。
+ 指定したデプロイまたはインスタンスイベントが発生したときに通知を送信できるように、Amazon SNS トピックに情報を公開すること。
+ CloudWatch アラームに関する情報を取得して、デプロイのアラームモニタリングを設定します。

詳細については、「[ステップ 2: CodeDeployのサービスのロールを作成する](getting-started-create-service-role.md)」を参照してください。

## ターゲットリビジョン
<a name="primary-components-target-revision"></a>

*ターゲットリビジョン*は、リポジトリにアップロードし、デプロイグループ内のインスタンスにデプロイしたいアプリケーションリビジョンの最新バージョンです。つまり、現在デプロイの対象としているアプリケーションリビジョン。これは、自動デプロイにプルされるリビジョンでもあります。

## 他のコンポーネント
<a name="primary-components-other-components"></a>

CodeDeploy ワークフローの他のコンポーネントの詳細については、次のトピックを参照してください。
+ [CodeDeploy リポジトリタイプを選択する](application-revisions-repository-type.md)
+  [CodeDeploy デプロイ](deployment-steps.md)
+  [CodeDeploy アプリケーション仕様 (AppSpec) ファイル](application-specification-files.md)
+  [CodeDeploy インスタンスのヘルス](instances-health.md)
+  [CodeDeploy エージェントの使用](codedeploy-agent.md)
+  [CodeDeploy 用のオンプレミスインスタンスを用いての作業](instances-on-premises.md)

# 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)」を参照してください。

# CodeDeploy アプリケーション仕様 (AppSpec) ファイル
<a name="application-specification-files"></a>

アプリケーション仕様ファイル (AppSpec ファイル) は、[YAML](http://www.yaml.org) 形式、または [JSON](http://www.json.org) 形式のファイルであり、CodeDeploy に固有のものです。AppSpec ファイルは、ファイルで定義された一連のライフサイクルイベントフックとして、各デプロイを管理するために使用されます。

正しい形式のAppSpec ファイルを作成する方法については、「[CodeDeploy AppSpec ファイルのリファレンス](reference-appspec-file.md)」を参照してください。

**Topics**
+ [

## Amazon ECS コンピューティングプラットフォーム上の AppSpec ファイル
](#appspec-files-on-ecs-compute-platform)
+ [

## AWS Lambda コンピューティングプラットフォーム上の AppSpec ファイル
](#appspec-files-on-lambda-compute-platform)
+ [

## EC2 オンプレミスコンピューティングプラットフォーム上の AppSpec ファイル
](#appspec-files-on-server-compute-platform)
+ [

## CodeDeploy エージェントが AppSpec ファイルを使用する方法
](#application-specification-files-agent-usage)

## Amazon ECS コンピューティングプラットフォーム上の AppSpec ファイル
<a name="appspec-files-on-ecs-compute-platform"></a>

アプリケーションで Amazon ECS コンピューティングプラットフォームを使用している場合は、AppSpec ファイルを YAML または JSON 形式にすることができます。また、コンソールのエディタに直接入力することもできます。AppSpec ファイルは、以下を指定するために使用されます。
+ Amazon ECS サービスの名称と、新しいタスクセットにトラフィックを送信するために使用されるコンテナの名称およびポート。
+ 検証テストとして使用される関数。

Lambda 関数は、デプロイライフサイクルイベント後に検証を実行できます。詳細については[Amazon ECS のデプロイ向けの AppSpec の「hooks」セクション](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs)、[Amazon ECS デプロイ向けの AppSpec ファイル構造](reference-appspec-file-structure.md#ecs-appspec-structure)、および[Amazon ECS デプロイの AppSpec ファイルの例](reference-appspec-file-example.md#appspec-file-example-ecs)を参照してください。

## AWS Lambda コンピューティングプラットフォーム上の AppSpec ファイル
<a name="appspec-files-on-lambda-compute-platform"></a>

アプリケーションで AWS Lambda コンピューティングプラットフォームを使用している場合、AppSpec ファイルは YAML または JSON のいずれかでフォーマットできます。また、コンソールのエディタに直接入力することもできます。AppSpec ファイルは、以下を指定するために使用されます。
+ デプロイする AWS Lambda 関数のバージョン。
+ 検証テストとして使用される関数。

Lambda 関数は、デプロイライフサイクルイベント後に検証を実行できます。詳細については、「[AWS Lambda デプロイの AppSpec 'hooks' セクション](reference-appspec-file-structure-hooks.md#appspec-hooks-lambda)」を参照してください。

## EC2 オンプレミスコンピューティングプラットフォーム上の AppSpec ファイル
<a name="appspec-files-on-server-compute-platform"></a>

アプリケーションで EC2 オンプレミスコンピューティングプラットフォームを使用している場合、AppSpec ファイルは必ず YAML 形式になります。AppSpec ファイルは、以下を目的として使用されます。
+ アプリケーションリビジョンのソースファイルを、インスタンスの宛先にマッピングします。
+ デプロイされたファイルのカスタムアクセス権限を指定する。
+ デプロイプロセスのさまざまなフェーズにおいて、各インスタンスで実行するスクリプトを指定する。

個別のデプロイライフサイクルイベントのうちの多くは、発生後にインスタンス上でスクリプトの実行が可能となっています。CodeDeploy はファイルで指定されているスクリプトのみを実行しますが、これらのスクリプトは、インスタンスの他のスクリプトを呼び出すことができます。インスタンスで実行しているオペレーティングシステムでサポートされている限り、どのタイプのスクリプトでも実行できます。詳細については、「[EC2/オンプレミスのデプロイ向けの AppSpec の「hooks」セクション](reference-appspec-file-structure-hooks.md#appspec-hooks-server)」を参照してください。

## CodeDeploy エージェントが AppSpec ファイルを使用する方法
<a name="application-specification-files-agent-usage"></a>

デプロイ中、CodeDeploy エージェントは、現在のイベントの名前を AppSpec ファイル内の **フック** セクションで検索できます。イベントが見つからない場合、CodeDeploy エージェントは次のステップに進みます。イベントが見つかった場合、CodeDeploy エージェントは実行するスクリプトのリストを取得します。スクリプトはファイルに表示された順序に沿って実行されます。各スクリプトのステータスはインスタンス上の CodeDeploy エージェントログファイルに記録されます。

スクリプトが正常に実行すると、終了コード 0 (ゼロ) を返します。

**注記**  
 CodeDeploy エージェントは、 AWS Lambda または Amazon ECS デプロイでは使用されません。

**Install** イベント中、CodeDeploy エージェントは AppSpec ファイルの **files** セクション内に定義されているマッピングを使用して、リビジョンからインスタンスにコピーするフォルダまたはファイルを判断します。

オペレーティングシステムにインストールされている CodeDeploy エージェントが AppSpec ファイルに記載されているものと一致しない場合、デプロイは失敗します。

CodeDeploy エージェントログファイルの詳細については、[CodeDeploy エージェントの使用](codedeploy-agent.md) を参照してください。