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

CodeDeploy とは

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

以下のような、ほぼ無制限の多様なアプリケーションコンテンツをデプロイできます。

  • コード

  • サーバーレス AWS Lambda 関数

  • ウェブファイルおよび設定ファイル

  • 実行可能ファイル

  • packages

  • スクリプト

  • マルチメディアファイル

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

CodeDeploy を使用すると、以下を容易に行うことができます。

  • 新機能の迅速なリリース。

  • AWS Lambda 関数のバージョンの更新。

  • アプリケーションのデプロイメント中のダウンタイム回避。

  • アプリケーションの更新に伴う繁雑さを処理。エラーの発生しやすい手動デプロイに伴うリスクの多くを回避できます。

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

CodeDeploy は、設定管理、ソース管理、継続的統合継続的配信、および継続的デプロイのための様々なシステムで動作します。詳細については、「製品の統合」を参照してください。

また、CodeDeploy コンソールには、レポジトリ、ビルドプロジェクト、デプロイメントアプリケーション、パイプラインなど、リソースを迅速に検索するための方法が用意されています。[Go to resource (リソースに移動)] を選択するか / キーを押してから、リソースの名前を入力します。一致がある場合は、リストに表示されます。検索では、大文字と小文字が区別されません。表示する権限があるリソースのみ表示されます。詳細については、「コンソールでリソースを表示する」を参照してください。

AWS CodeDeploy の概要のビデオ

この短い動画 (2:10) は、CodeDeploy が Amazon EC2 インスタンスへのコードのデプロイを自動化する方法について説明しています。

AWS CodeDeploy の利点

CodeDeploy は、次の利点を提供します。

  • サーバーアプリケーション、サーバーレスアプリケーション、コンテナアプリケーション。CodeDeploy では、サーバーの従来のアプリケーションと、サーバーレス AWS Lambda 関数バージョン、または Amazon ECS アプリケーションを展開するアプリケーションの両方をデプロイできます。

  • 自動デプロイ。CodeDeploy は、開発、テスト、および本番稼働環境にまたがるアプリケーションのデプロイを完全に自動化します。CodeDeploy は、インフラストラクチャに合わせてスケールするため、1 つのインスタンスまたは数千のインスタンスにデプロイできます。

  • ダウンタイムの最小化。アプリケーションが EC2/オンプレミス compute platform を使用している場合、CodeDeploy はアプリケーションの可用性を最大化します。インプレースデプロイの場合、CodeDeploy は複数の Amazon EC2 インスタンスにまたがってローリング更新を実行します。更新のために、一度にオフラインにするインスタンスの数を指定できます。Blue/Green デプロイの間、最新アプリケーションのリビジョンは、置き換え先インスタンスにインストールされます。トラフィックは、選択するとすぐに、または新しい環境のテストが完了した時点で、これらのインスタンスに再ルーティングされます。どちらのデプロイタイプでも、CodeDeploy は設定したルールに従ってアプリケーションの状態を追跡します。

  • 停止してロールバック。エラーが発生した場合、自動または手動でデプロイを停止してロールバックできます。

  • コントロールの一元化。CodeDeploy コンソールまたは AWS CLI でデプロイを起動し、そのステータスを追跡できます。各アプリケーションのリビジョンがいつデプロイされ、どの Amazon EC2 インスタンスがリストされているかを示すレポートを受け取ります。

  • 導入が簡単。CodeDeploy は、プラットフォームに依存せず、すべてのアプリケーションで動作します。セットアップコードを簡単に再利用できます。また、CodeDeploy はソフトウェアリリースプロセスまたは継続的な配信ツールチェーンと統合できます。

  • 同時デプロイ。EC2/オンプレミス compute platform を使用する複数のアプリケーションがある場合、CodeDeploy は同じインスタンスのセットでこれらを同時にデプロイできます。

CodeDeploy コンピューティングプラットフォームの概要

CodeDeploy では、アプリケーションを 3 つのコンピューティングプラットフォームにデプロイできます。

  • EC2/オンプレミス: Amazon EC2 クラウドインスタンス、オンプレミスサーバー、またはその両方を指定することができる物理サーバーのインスタンスについて説明します。EC2/オンプレミス compute platform を使用して作成されたアプリケーションは、実行可能ファイル、設定ファイル、イメージなどで構成できます。

    EC2/オンプレミス compute platform を使用するデプロイでは、インプレイスまたは Blue/Green デプロイタイプを使用して、トラフィックをインスタンスに振り分ける方法を管理できます。詳細については、「CodeDeploy デプロイタイプの概要」を参照してください。

  • AWS Lambda: Lambda 関数の更新バージョンで構成されるアプリケーションのデプロイに使用します。AWS Lambda は、高可用性コンピューティング構造で構成されるサーバーレスコンピューティング環境で Lambda 関数を管理します。コンピューティングリソースはすべて、AWS Lambda によって管理されます。詳細については、「サーバーレスコンピューティングとアプリケーション」を参照してください。AWS Lambda 関数と Lambda 関数の詳細については、「AWS Lambda」を参照してください。

    AWS Lambda compute platform で作成したアプリケーションでは、Canary 設定、線形設定、または一度にすべての設定を選択して、デプロイ時に更新済み Lambda 関数バージョンにトラフィックを振り分ける方法を管理できます。

  • Amazon ECS: Amazon ECS でコンテナ化されたアプリケーションは、タスクセットとしてのデプロイに使用されます。CodeDeploy は、コンテナ化されたアプリケーションの更新バージョンを新しい置き換えタスクセットとしてインストールすることで、Blue/Green のデプロイを実行します。CodeDeploy は、元のアプリケーションの本稼働トラフィック、またはタスクセットを、置き換えタスクセットに再ルーティングします。デプロイが正常に完了すると、元のタスクセットは削除されます。Amazon ECS の詳細については、「Amazon Elastic Container Service」を参照してください。

次の表に、各 compute platform での CodeDeploy コンポーネントの使用方法を示します。詳細については、以下のトピックを参照してください。

CodeDeploy コンポーネント EC2/オンプレミス AWS Lambda Amazon ECS
デプロイグループ 一連のインスタンスにリビジョンをデプロイします。 可用性の高いコンピューティングインフラストラクチャで、サーバーレス Lambda 関数の新しいバージョンをデプロイします。 タスクセットとしてデプロイする、コンテナ化されたアプリケーション、デプロイされたアプリケーションへのトラフィック提供に使用される本稼働およびオプションのテストリスナー、トラフィックを再ルーティングし、デプロイされたアプリケーションの元のタスクセットを終了するタイミング、オプションのトリガー、アラーム、およびロールバック設定で Amazon ECS サービスを指定します。
デプロイ アプリケーションと AppSpec ファイルから構成される新しいリビジョンをデプロイします。AppSpec は、アプリケーションをデプロイグループのインスタンスにデプロイする方法を指定します。 Lambda 関数の 1 つのバージョンから、同じ関数の新しいバージョンに本稼働トラフィックを移行させます。AppSpec file は、デプロイする Lambda 関数のバージョンを指定します。 Amazon ECS コンテナー化されたアプリケーションの最新バージョンを、新しい置き換えタスクセットとしてデプロイします。CodeDeploy は、元のバージョンのタスクセットから最新バージョンの新しい置き換えタスクセットに本番用トラフィックを再ルーティングします。デプロイ完了時に、元のタスクセットは削除されます。
デプロイ設定 デプロイの速度と、デプロイ中にいつでも使用できる必要のある正常なインスタンスの最小数を決定する設定。 更新された Lambda 関数バージョンにトラフィックを移行する方法を決定する設定。 トラフィックは常に、一度にすべて移行されます。カスタムデプロイ設定を Amazon ECS デプロイに指定することはできません。
リビジョン AppSpec ファイルとアプリケーションファイルの組み合わせ (例: 実行ファイル、設定ファイル)。 デプロイする Lambda 関数と、ライフサイクルイベントフック中に検証テストを実行可能な Lambda 関数を指定する AppSpec ファイル。

以下を指定する AppSpec file。

  • デプロイするためのコンテナー化されたアプリケーションを含む、Amazon ECS サービスの Amazon ECS タスク定義。

  • 最新のアプリケーションがデプロイされているコンテナ。

  • 本稼働トラフィックが再ルーティングされるコンテナのポート。

  • オプションのネットワーク構成設定と、デプロイライフサイクルイベントフック中に検証テストを実行できる Lambda 関数。

アプリケーション デプロイグループおよびリビジョンのコレクション。EC2/オンプレミス アプリケーションは EC2/オンプレミス compute platform を使用します。 デプロイグループおよびリビジョンのコレクション。AWS Lambda デプロイに使用されるアプリケーションは、Amazon ECS compute platform を使用します。 デプロイグループおよびリビジョンのコレクション。Amazon ECS デプロイに使用されるアプリケーションは、Amazon ECS compute platform を使用します。

CodeDeploy デプロイタイプの概要

CodeDeploy には、2 つのデプロイタイプのオプションがあります。

  • インプレイスデプロイ: デプロイグループの各インスタンス上のアプリケーションが停止され、最新のアプリケーションリビジョンがインストールされて、新バージョンのアプリケーションが開始され検証されます。ロードバランサーを使用すれば、各インスタンスがデプロイ中に登録解除され、デプロイ完了後にサービスに復元されるようにすることができます。インプレイスデプロイは、EC2/オンプレミス compute platform を使用するデプロイでのみ使用できます。インプレイスデプロイの詳細については、「インプレースデプロイの概要」を参照してください。

    注記

    AWS Lambda compute platform のデプロイでは、インプレイスデプロイタイプを使用できません。

  • Blue/Green デプロイ: デプロイの動作は、使用する compute platform によって異なります。

    • EC2/オンプレミス compute platform の Blue/Green: 以下のステップを使用して、デプロイグループのインスタンス (元の環境) がインスタンスの別のセット (置き換え先環境) に置き換えられます。

      • インスタンスは、置き換え先環境に対してプロビジョニングされます。

      • 最新のアプリケーションリビジョンが置き換え先インスタンスにインストールされます。

      • アプリケーションのテストやシステムの検証などのアクティビティでは、オプションの待機時間が発生します。

      • 置き換え先環境のインスタンスは、Elastic Load Balancing ロードバランサーに登録され、トラフィックは、それらに再ルーティングされます。元の環境のインスタンスは登録解除されます。これらのインスタンスは削除するか、その他の用途のために引き続き実行できます。

      注記

      EC2/オンプレミス compute platform を使用する場合、Blue/Green デプロイは Amazon EC2 インスタンスでのみ動作する点に注意してください。

    • AWS Lambda compute platform の Blue/Green: トラフィックは、現在のサーバーレス環境から、更新された Lambda 関数のバージョンの環境に移行されます。検証テストを実行する Lambda 関数を指定し、トラフィックの移行が発生する方法を選択できます。AWS Lambda compute platform のデプロイはすべて、Blue/Green デプロイです。そのため、デプロイタイプを指定する必要はありません。

    • Amazon ECS compute platform の Blue/Green: トラフィックは、Amazon ECS サービス内のコンテナ化されたアプリケーション元のバージョンのタスクセットから、同じサービスの置き換えタスクセットに移行されます。指定されたロードバランサーリスナーのプロトコルとポートは、本稼働トラフィックを再ルーティングするために使用されます。デプロイ中、テストリスナーは、検証テストの実行中に設定された置換タスクセットにトラフィックを配信するために使用することができます。

    Blue/Green デプロイの詳細については、「Blue/Green デプロイの概要」を参照してください。

注記

CodeDeploy エージェントでは、サインインしているインスタンスでデプロイを実行できます。この際にアプリケーションやデプロイグループは不要であり、AWS アカウントさえも不要です。詳細については、CodeDeploy エージェントを使用してローカルマシン上のデプロイパッケージを検証する を参照してください。

インプレースデプロイの概要

次の図は、一般的な CodeDeploy インプレースデプロイのフローを示します。

注記

AWS Lambda compute platform のデプロイでは、インプレイスデプロイタイプを使用できません。

処理の流れ

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

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

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

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

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

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

Blue/Green デプロイの概要

Blue/Green デプロイでは、アプリケーションの元の環境から、置き換え先環境にトラフィックを再ルーティングします。環境は、CodeDeploy アプリケーションの compute platform によって異なります。

  • AWS Lambda: Lambda 関数のあるバージョンから、同じ Lamdba 関数の新しいバージョンにトラフィックが移行します。

  • Amazon ECS: Amazon ECS サービスのタスクセットから、同じ Amazon ECS サービスの最新の置き換えタスクセットにトラフィックが移行します。

  • EC2/オンプレミス: 元の環境内の、あるインスタンスセットから、インスタンスの置き換え先のセットにトラフィックが移行します。

すべての AWS Lambda および Amazon ECS デプロイは Blue/green です。EC2/オンプレミス デプロイは、インプレースまたは Blue/Green です。Blue/Green デプロイには、インプレースデプロイと比べて多くのメリットがあります。

  • トラフィックを再ルーティングするだけで、アプリケーションを新しい置き換え先環境にインストールしてテストし、本稼働環境へデプロイできます。

  • EC2/オンプレミス compute platform を使用している場合、最新バージョンのアプリケーションに切り替えることで、より迅速になり、信頼性が高まります。これは、トラフィックが終了していない限り、トラフィックを元のインスタンスにルーティングできるためです。インプレースデプロイでは、以前のバージョンのアプリケーションを再デプロイすることによってバージョンをロールバックする必要があります。

  • EC2/オンプレミス compute platform を使用している場合、新しいインスタンスは Blue/Green デプロイ向けにプロビジョニングされ、最新のサーバー設定が反映されます。これにより、長時間実行するインスタンスで発生する問題を回避できます。

  • AWS Lambda compute platform を使用している場合、元の AWS Lambda 関数バージョンから新しい AWS Lambda 関数バージョンにトラフィックを移行する方法をユーザーが管理します。

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

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

AWS Lambda compute platform を使用している場合は、以下のいずれかのデプロイ設定のタイプを選択して、元の AWS Lambda 関数バージョンから新しい AWS Lambda 関数バージョンにトラフィックを移行する方法を指定する必要があります。

  • Canary: トラフィックは 2 回の増分で移行されます。残りのトラフィックが 2 回目の増分で移行される前に、最初の増分および間隔で更新された Lambda 関数のバージョンに移行されるトラフィックの割合 (%) を分単位で指定する、事前定義された Canary オプションから選択できます。

  • 線形: トラフィックは、毎回同じ間隔 (分) の等しい増分で移行します。増分ごとに移行するトラフィックの割合 (%) と、増分間の間隔 (分) を指定する、事前定義済み線形オプションから選択できます。

  • All-at-once: トラフィックはすべて、元の Lambda 関数から最新バージョンの Lambda 関数に一度に移行されます。

AWS Lambda デプロイ設定の詳細については、「AWS Lambda コンピューティングプラットフォームの事前定義されたデプロイ設定 」を参照してください。

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

Amazon ECS compute platform を使用している場合、本稼働トラフィックは、Amazon ECS サービスの元のタスクセットから置き換えタスクセットに一度にすべて移行します。

Amazon ECS デプロイ設定の詳細については、「 Amazon ECS コンピューティングプラットフォームのデプロイ設定 」を参照してください。

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

注記

EC2/オンプレミス compute platform での Blue/Green デプロイには、Amazon EC2 インスタンスを使用する必要があります。オンプレミスインスタンスは Blue/Green デプロイタイプではサポートされません。

EC2/オンプレミス compute platform を使用している場合は、次が適用されます。

識別用の 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 デプロイを初めて実行するときは、通常、インプレースデプロイで既に使用されているインスタンスを使用します。

  2. 既存の CodeDeploy アプリケーションでは、Blue/Green デプロイグループを作成し、インプレースデプロイに必要なオプションに加えて、次を指定します。

    • Blue/Green デプロイプロセスで元の環境から置き換え先環境にトラフィックをルーティングするロードバランサー。

    • 置き換え先環境にトラフィックを直ちに再ルーティングするか、手動で再ルーティングするまで待つかどうか。

    • トラフィックが置き換え先インスタンスにルーティングされるレート。

    • 置き換え元インスタンスを削除するか引き続き実行するかどうか。

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

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

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

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

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

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

ご意見をお待ちしております

ご意見をお待ちしております。お問い合わせの場合は、CodeDeploy フォーラムをご利用ください。

トピック