AWS CodeDeploy
ユーザーガイド (API バージョン 2014-10-06)

CodeDeploy デプロイ

このトピックでは、CodeDeploy のデプロイのコンポーネントおよびワークフローについて説明します。デプロイプロセスは、デプロイに使用する compute platform (EC2/オンプレミスまたは Lambda) によって異なります。

注記

Amazon ECS または AWS Lambda compute platform へのデプロイは、アジアパシフィック (大阪: ローカル)、AWS GovCloud (米国東部)、AWS GovCloud (US-West)、中国 (北京)、中国 (寧夏) の各リージョンではサポートされていません。​

AWS Lambda コンピューティングプラットフォームを選択します。 のデプロイ

このトピックでは、AWS Lambda compute platform を使用する CodeDeploy デプロイのコンポーネントおよびワークフローについて説明します。

AWS Lambda コンピューティングプラットフォームのデプロイコンポーネント

次の図は、AWS Lambda compute platform における CodeDeploy デプロイのコンポーネントを示しています。

AWS Lambda コンピューティングプラットフォームのデプロイワークフロー

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

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

  1. アプリケーションを作成し、デプロイするアプリケーションリビジョンを一意に識別する名前を付けます。Lambda 関数をデプロイするには、アプリケーションの作成時に AWS Lambda compute platform を選択します。CodeDeploy では、この名前をデプロイ時に使用して正しいデプロイコンポーネント (デプロイグループ、デプロイ設定、アプリケーションリビジョンなど) を参照していることを確認します。詳細については、「CodeDeploy でアプリケーションを作成」を参照してください。

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

  3. 元の AWS Lambda 関数バージョンから新規の Lambda 関数バージョンにトラフィックを移行する方法を指定するには、デプロイ設定を選択します。詳細については、「デプロイ設定の詳細の表示」を参照してください。

  4. application specification file (AppSpec file) を指定します。YAML または JSON フォーマットでコンソールに入力するか、AWS CLI または SDK で指定して、ファイルを Amazon S3 にアップロードすることができます。AppSpec file は、デプロイの Amazon ECS タスク定義、トラフィックをルーティングするコンテナ名とポートマッピング、およびデプロイライフサイクルフックの後で実行される Lambda 関数を指定するために使用されます。AppSpec file を作成しない場合は、この情報を YAML または JSON 形式で直接コンソールに入力できます。詳細については、「CodeDeploy 用のアプリケーションリビジョンの操作」を参照してください。

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

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

アプリケーションリビジョンのアップロード

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

アプリケーションとデプロイグループの作成

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

アプリケーションリビジョンのデプロイ

これで、AppSpec file で指定した関数リビジョンをデプロイグループにデプロイする準備ができました。CodeDeploy コンソールまたは create-deployment コマンドを使用できます。デプロイを制御するために指定できるパラメータ (リビジョン、デプロイグループ、デプロイ設定など) があります。

アプリケーションの更新

アプリケーションを更新し、CodeDeploy コンソールを使用するか、create-deployment コマンドを呼び出してリビジョンをプッシュできます。

停止、失敗したデプロイ

デプロイを停止するには、CodeDeploy コンソールまたは stop-deployment コマンドを使用できます。デプロイを停止しようとする場合、次の 3 つのうち 1 つのことが発生します。

  • デプロイは停止し、オペレーションは成功というステータスを返す。この場合、停止したデプロイに対してそれ以上デプロイライフサイクルイベントは実行されません。

  • デプロイは即時に停止せず、オペレーションは保留中というステータスを返す。この場合、一部のデプロイライフサイクルイベントは、デプロイグループでまだ実行中である可能性があります。保留中のオペレーションが完了すると、デプロイを停止するためのそれ以降の呼び出しは、成功というステータスを返します。

  • デプロイは停止できず、オペレーションはエラーを返す。詳細については、AWS CodeDeploy API Reference の「ErrorInformation」および「一般的エラー」を参照してください。

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

デプロイと再デプロイのロールバック

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

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

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

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

詳細については、「CodeDeploy を使用した再デプロイおよびデプロイのロールバック」を参照してください。

Amazon ECS コンピューティングプラットフォームを選択します。 のデプロイ

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

Amazon ECS デプロイを開始する前に

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

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

Amazon ECS クラスターは、タスクまたはサービスの論理グループです。CodeDeploy アプリケーションのデプロイグループを作成するときに、Amazon ECS サービスを含む Amazon ECS クラスターを指定します。詳細については、Amazon Elastic Container Service ユーザーガイドの「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 サービス」を参照してください。

Application Load Balancer または Network Load Balancer

Amazon ECS デプロイで更新する Amazon ECS サービスでは、Elastic Load Balancing を使用する必要があります。Application Load Balancer や Network Load Balancer を使用できます。動的ポートマッピング、パスベースのルーティング、優先ルールなどの機能を利用できるように、Application Load Balancer をお勧めします。CodeDeploy アプリケーションのデプロイグループを作成するときに、ロードバランサーを指定します。詳細については、Amazon Elastic Container Service ユーザーガイドの「ロードバランサーの作成」を参照してください。

1 つまたは 2 つのリスナー

ロードバランサーは、リスナーを使用してターゲットグループにトラフィックをルーティングします。本稼働リスナーが 1 つ必要です。検証テストの実行中、置き換えタスクセットにトラフィックをルーティングする、2 番目のオプションのテストリスナーを指定できます。デプロイグループを作成するときに、一方または両方のリスナーを指定します。Amazon ECS コンソールを使用して Amazon ECS サービスを作成すると、リスナーが自動的に作成されます。詳細は、Elastic Load Balancing ユーザーガイドの「Application Load Balancer のリスナー」および Amazon Elastic Container Service ユーザーガイドの「サービスの作成」を参照してください。

2 つの Amazon ECS ターゲットグループ

ターゲットグループは、登録済みターゲットにトラフィックをルーティングするために使用されます。Amazon ECS デプロイには 2 つのターゲットグループが必要です。1 つは Amazon ECS アプリケーションの元のタスクセット用、もう 1 つはその置き換えタスクセット用です。デプロイ中、CodeDeploy は置き換えタスクセットを作成し、元のタスクセットから新しいタスクセットにトラフィックを再ルーティングします。CodeDeploy アプリケーションのデプロイグループを作成するときに、ターゲットグループを指定します。

デプロイ中、CodeDeploy は、ステータス PRIMARY (これが元のタスクセット) を持つ、Amazon ECS サービスのタスクセットに関連付けられているターゲットグループを決定し、それに一方のターゲットグループを関連付けます。さらに、もう一方のターゲットグループを置き換えタスクセットと関連付けます。別のデプロイを行う場合、現在のデプロイの元のタスクセットに関連付けられているターゲットグループは、次のデプロイの置き換えタスクセットに関連付けられています。詳細については、Elastic Load Balancing ユーザーガイドにある「Application Load Balancer のターゲットグループ」を参照してください。

Amazon ECS タスク定義

Amazon ECS アプリケーションを含む Docker コンテナを実行するには、タスク定義が必要です。CodeDeploy アプリケーションの AppSpec file で、タスク定義の ARN を指定します。詳細については、Amazon Elastic Container Service ユーザーガイドの「Amazon ECS タスク定義」および「 Amazon ECS デプロイ用の AppSpec の「resources」セクション 」を参照してください。

Amazon ECS アプリケーション用のコンテナ

Docker コンテナは、コードとその依存関係をパッケージ化してアプリケーションを実行できるようにするソフトウェアのユニットです。コンテナはアプリケーションを分離して、さまざまなコンピューティング環境で実行できるようにします。ロードバランサーは、Amazon ECS アプリケーションのタスクセットのコンテナにトラフィックをルーティングします。CodeDeploy アプリケーションの AppSpec file で、コンテナの名前を指定します。AppSpec file で指定したコンテナは、Amazon ECS タスク定義で指定したコンテナのいずれかである必要があります。詳細については、Amazon Elastic Container Service ユーザーガイドの「Amazon Elastic Container Service とは」および「 Amazon ECS デプロイ用の AppSpec の「resources」セクション 」を参照してください。

置き換えタスクセット用のポート

Amazon ECS のデプロイ中、ロードバランサーは、CodeDeploy アプリケーションの AppSpec file で指定されたコンテナにある、このポートにトラフィックをルーティングします。CodeDeploy アプリケーションの AppSpec file でポートを指定します。詳細については、「 Amazon ECS デプロイ用の AppSpec の「resources」セクション 」を参照してください。

Amazon ECS コンピューティングプラットフォームのデプロイコンポーネント

次の図は、Amazon ECS compute platform における CodeDeploy デプロイのコンポーネントを示しています。

Amazon ECS コンピューティングプラットフォームのデプロイワークフロー (概要)

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

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

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

  2. デプロイグループをセットアップするには、以下を指定します。

    • デプロイグループ名。

    • Amazon ECS クラスターとサービス名。Amazon ECS サービスのデプロイコントローラーは、CodeDeploy に設定する必要があります。

    • 本稼働リスナー、オプションのテストリスナー、およびターゲットグループは、デプロイ中に使用されます。

    • 本稼働トラフィックを Amazon ECS サービスの置き換え Amazon ECS タスクセットに再ルーティングするタイミングや、Amazon ECS サービスの元の Amazon ECS タスクセットを終了するタイミングなどのデプロイ設定。

    • トリガー、アラーム、ロールバック動作などのオプション設定。

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

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

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

Amazon ECS デプロイ中の処理

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

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

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

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

注記

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

  1. AppSpec file の BeforeInstall フックで指定された Lambda 関数を実行します。

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

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

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

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

    この図は、新しい置き換えタスクセットを含むデプロイコンポーネントを示しています。コンテナ化されたアプリケーションはこのタスクセット内にあります。タスクセットは 3 つのタスクで構成されています。(アプリケーションには任意の数のタスクを含めることができます。) 2 番目のターゲットグループが置き換えタスクセットに関連付けられました。

  3. AppSpec file の AfterInstall フックで指定された Lambda 関数を実行します。

  4. AllowTestTraffic イベントが呼び出されます。このライフサイクルイベントの間、テストリスナーは、更新されたコンテナ化アプリケーションにトラフィックをルーティングします。

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

    検証テストが完了したら、次のいずれかが発生します。

    • 検証が失敗し、ロールバックが設定されている場合、デプロイステータスは Failed とマークされ、コンポーネントはデプロイが開始されたときの状態に戻ります。

    • 検証が失敗し、ロールバックが設定されていない場合、デプロイステータスは Failed とマークされ、コンポーネントは現在の状態のまま変わりません。

    • 検証が正常に完了すると、デプロイは引き続き BeforeAllowTraffic に進みます。

    詳細については、「CodeDeploy で CloudWatch アラームを使用してデプロイをモニタリングする」、「自動ロールバック」、および「デプロイグループの詳細オプションの設定」を参照してください。

  6. AppSpec file の BeforeAllowTraffic フックで指定された Lambda 関数を実行します。

  7. AllowTraffic イベントが呼び出されます。本稼働トラフィックは、元のタスクセットから置き換えタスクセットに再ルーティングされます。次の図は、本稼働トラフィックを受信して​​いる代替タスクセットを示しています。

  8. AppSpec file の AfterAllowTraffic フックで指定された Lambda 関数を実行します。

  9. すべてのイベントが正常に完了したら、デプロイステータスは Succeeded になり、元のタスクセットは削除されます。

アプリケーションリビジョンのアップロード

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

アプリケーションとデプロイグループの作成

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

アプリケーションリビジョンのデプロイ

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

アプリケーションの更新

アプリケーションを更新し、CodeDeploy コンソールを使用するか、create-deployment コマンドを呼び出してリビジョンをプッシュできます。

停止、失敗したデプロイ

デプロイを停止するには、CodeDeploy コンソールまたは stop-deployment コマンドを使用できます。デプロイを停止しようとする場合、次の 3 つのうち 1 つのことが発生します。

  • デプロイは停止し、オペレーションは成功というステータスを返す。この場合、停止したデプロイに対してそれ以上デプロイライフサイクルイベントは実行されません。

  • デプロイは即時に停止せず、オペレーションは保留中というステータスを返す。この場合、一部のデプロイライフサイクルイベントは、デプロイグループでまだ実行中である可能性があります。保留中のオペレーションが完了すると、デプロイを停止するためのそれ以降の呼び出しは、成功というステータスを返します。

  • デプロイは停止できず、オペレーションはエラーを返す。詳細については、AWS CodeDeploy API Reference の「エラー情報」および「一般的エラー」を参照してください。

デプロイと再デプロイのロールバック

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

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

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

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

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

詳細については、「CodeDeploy を使用した再デプロイおよびデプロイのロールバック」を参照してください。

EC2/オンプレミス コンピューティングプラットフォームを選択します。 のデプロイ

このトピックでは、EC2/オンプレミス compute platform を使用する CodeDeploy デプロイのコンポーネントおよびワークフローについて説明します。Blue/Green デプロイの詳細については、「Blue/Green デプロイの概要」を参照してください。

EC2/オンプレミスコンピューティングプラットフォームのデプロイコンポーネント

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

EC2/オンプレミスコンピューティングプラットフォームのデプロイワークフロー

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

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

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

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

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

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

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

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

    また、以下のオプションを指定できます。

    • Amazon SNS 通知。成功イベントや失敗イベントなど、指定されたイベントがデプロイとインスタンスで発生したときに、Amazon SNS トピックの受信者に通知を送信するトリガーを作成します。詳細については、Amazon SNS イベント通知を使用したデプロイのモニタリング を参照してください。

    • アラームベースのデプロイ管理。CloudWatch で設定したしきい値を超えるか下回ったときに、デプロイを停止する Amazon CloudWatch アラームモニタリングを実装します。

    • 自動デプロイロールバック。デプロイが失敗するか、アラームのしきい値に一致したときに、以前の既知の正常なリビジョンに自動的にロールバックするようデプロイを設定します。

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

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

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

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

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

インスタンスの設定

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

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

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

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

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

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

初回のデプロイでは、AWS CloudFormation テンプレートによってこれらすべてが実行されます。これにより、Amazon Linux または Windows Server に応じて、CodeDeploy エージェントがインストール済みの新規 Amazon EC2 インスタンスが 1 つ作成および設定されます。詳細については、「CodeDeploy のインスタンスの使用」を参照してください。

注記

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

アプリケーションリビジョンのアップロード

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

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

注記

The tar and compressed tar archive file formats (.tar and .tar.gz) are not supported for Windows Server instances.

アプリケーションとデプロイグループの作成

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

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

デプロイグループの複数のタググループを使用して、デプロイするインスタンスのセットを減らすことができます。詳細については、AWS CodeDeploy デプロイのインスタンスにタグを付ける を参照してください。

アプリケーションリビジョンのデプロイ

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

アプリケーションの更新

アプリケーションを更新し、CodeDeploy コンソールを使用するか、create-deployment コマンドを呼び出してリビジョンをプッシュできます。

停止、失敗したデプロイ

デプロイを停止するには、CodeDeploy コンソールまたは stop-deployment コマンドを使用できます。デプロイを停止しようとする場合、次の 3 つのうち 1 つのことが発生します。

  • デプロイは停止し、オペレーションは成功というステータスを返す。この場合、停止したデプロイに対してそれ以上デプロイライフサイクルイベントは実行されません。デプロイグループで一部のファイルは既にコピーされ、一部のスクリプトは実行され、1 つ以上のインスタンスが実行されている可能性があります。

  • デプロイは即時に停止せず、オペレーションは保留中というステータスを返す。この場合、一部のデプロイライフサイクルイベントは、デプロイグループでまだ実行中である可能性があります。デプロイグループで一部のファイルは既にコピーされ、一部のスクリプトは実行され、1 つ以上のインスタンスが実行されている可能性があります。保留中のオペレーションが完了すると、デプロイを停止するためのそれ以降の呼び出しは、成功というステータスを返します。

  • デプロイは停止できず、オペレーションはエラーを返す。詳細については、AWS CodeDeploy API Reference の「ErrorInformation」および「一般的エラー」を参照してください。

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

デプロイと再デプロイのロールバック

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

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

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

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

詳細については、「CodeDeploy を使用した再デプロイおよびデプロイのロールバック」を参照してください。