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

AWS CodeDeploy とは

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

コード、サーバーレス AWS Lambda 関数、ウェブファイル、設定ファイル、実行可能ファイル、パッケージ、スクリプト、マルチメディアファイルなど、ほぼ無制限の多様なアプリケーションコンテンツをデプロイできます。AWS CodeDeploy では、サーバーで実行され、Amazon S3 バケット、GitHub リポジトリ、または Bitbucket リポジトリに保存されているアプリケーションコンテンツをデプロイできます。AWS CodeDeploy では、サーバーレス Lambda 関数をデプロイすることもできます。既存のコードを変更することなく AWS CodeDeploy を使用できます。

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

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

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

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

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

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

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

AWS CodeDeploy の概要のビデオ

この短い動画 (2:10) は、AWS CodeDeploy が Amazon EC2 インスタンスへのコードのデプロイを自動化し、新しい機能をより簡単かつ迅速にリリースし、デプロイ中のダウンタイムを排除し、エラーが発生しやすい手動操作の必要性を回避する方法について説明しています。

AWS CodeDeploy の利点

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

  • サーバーアプリケーションとサーバーレスアプリケーション。AWS CodeDeploy では、サーバーおよびアプリケーションの両方で従来のアプリケーションをデプロイし、サーバーレス AWS Lambda 関数のバージョンをデプロイすることができます。

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

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

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

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

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

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

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

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

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

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

    AWS Lambda コンピューティングプラットフォームを選択します。 を使用して作成されるアプリケーションは、Canary 設定、線形設定、または一度にすべての設定を選択して、デプロイ中に更新された Lambda 関数のバージョンにトラフィックが振り分けられる方法を管理できます。

次の表に、AWS CodeDeploy コンポーネントが各 コンピューティングプラットフォームを選択します。 で使用される様子を示します。

AWS CodeDeploy コンポーネント EC2/オンプレミス AWS Lambda
デプロイグループ 新しいリビジョンがデプロイされるインスタンスのセットをデプロイします。 可用性の高いコンピューティングインフラストラクチャで Lambda 関数のバージョンをデプロイします。
デプロイメント アプリケーションと AppSpec ファイルから構成される新しいリビジョンをデプロイします。AppSpec は、アプリケーションをデプロイグループのインスタンスにデプロイする方法を指定します。 AppSpec ファイルから構成される新しいリビジョンをデプロイします。AppSpec は、デプロイする Lambda 関数のバージョンを指定します。
デプロイ設定 デプロイの速度と、デプロイ中にいつでも使用できる必要のある正常なインスタンスの最小数を決定する設定。 更新された Lambda 関数バージョンにトラフィックを移行する方法を決定する設定。
Revision AppSpec ファイルとアプリケーションファイルの組み合わせ (例: 実行ファイル、設定ファイル)。 デプロイして更新する Lambda 関数を指定する AppSpec ファイル。
アプリケーション デプロイグループおよびリビジョンのコレクション。EC2/オンプレミス アプリケーションでは、EC2/オンプレミス コンピューティングプラットフォームを選択します。 を使用します。 リビジョンのコレクション。Lambda アプリケーションでは、AWS Lambda コンピューティングプラットフォームを選択します。 を使用します。

AWS CodeDeploy デプロイタイプの概要

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

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

    注記

    AWS Lambda コンピューティングプラットフォームを選択します。 のデプロイでは、インプレイスデプロイタイプを使用できません。

  • Blue/Green デプロイ: デプロイの動作は、使用する コンピューティングプラットフォームを選択します。 により異なります。

    • EC2/オンプレミス コンピューティングプラットフォームを選択します。 の Blue/Green: 以下のステップによって、デプロイグループのインスタンス (元の環境) がインスタンスの別のセット (置き換え先環境) に置き換えられます。

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

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

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

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

      注記

      EC2/オンプレミス コンピューティングプラットフォームを選択します。 を使用する場合、Blue/Green デプロイは Amazon EC2 インスタンスでのみ動作します。

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

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

注記

AWS CodeDeploy エージェントでは、アプリケーションやデプロイグループ、AWS アカウントを使用せずに、ログオンしているインスタンスでデプロイを行うことができます。詳細については、AWS CodeDeploy エージェントを使用してローカルマシン上のデプロイパッケージを検証する を参照してください。

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

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

注記

AWS Lambda コンピューティングプラットフォームを選択します。 のデプロイでは、インプレイスデプロイタイプを使用できません。

処理の流れ

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

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

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

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

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

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

Blue/Green デプロイの概要

トラフィックが、あるセットのインスタンス (元の環境) から別のセット (置き換えられた環境) に再ルーティングされる Blue/Green デプロイには、インプレースデプロイと比べて多くのメリットがあります。

  • アプリケーションは、新しいサーバーにトラフィックを切り替えるだけで、事前に新しいインスタンスにインストールしてテストし、本稼働環境にデプロイすることができます。

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

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

  • AWS Lambda コンピューティングプラットフォームを選択します。 を使用している場合は、元の AWS Lambda 関数のバージョンから新しい AWS Lambda 関数のバージョンにトラフィックを移行する方法を制御します。

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

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

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

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

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

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

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

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

注記

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

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

Amazon EC2 タグまたは Auto Scaling グループを識別する 1 つ以上の Amazon EC2 インスタンスが必要です。インスタンスは、以下の条件を満たす必要があります。

  • 各 Amazon EC2 インスタンスには、適切な IAM インスタンスプロファイルがアタッチされている必要があります。

  • 各インスタンスで AWS CodeDeploy エージェントをインストールして実行する必要があります。

注記

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

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

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

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

処理の流れ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

トピック