翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
CodeDeploy は、Amazon EC2 インスタンスやオンプレミスインスタンス、サーバーレス Lambda 関数、または Amazon ECS サービスに対するアプリケーションのデプロイを自動化するデプロイメントサービスです。
以下のような、ほぼ無制限の多様なアプリケーションコンテンツをデプロイできます。
-
コード
-
サーバーレス AWS Lambda 関数
-
ウェブファイルおよび設定ファイル
-
Executables
-
パッケージ
-
スクリプト
-
マルチメディアファイル
CodeDeploy では、サーバーで実行され、Amazon S3 バケット、GitHub リポジトリ、または Bitbucket リポジトリに保存されているアプリケーションコンテンツをデプロイできます。CodeDeploy では、サーバーレス Lambda 関数をデプロイすることもできます。既存のコードを変更することなく CodeDeploy を使用できます。
CodeDeploy を使用すると、以下を容易に行うことができます。
-
新機能の迅速なリリース。
-
AWS Lambda 関数のバージョンを更新します。
-
アプリケーションのデプロイメント中のダウンタイム回避。
-
アプリケーションの更新に伴う繁雑さを処理。エラーの発生しやすい手動デプロイに伴うリスクの多くを回避できます。
サービスはインフラストラクチャに合わせてスケールするため、1 つのインスタンスまたは数千のインスタンスに簡単にデプロイできます。
CodeDeploy は、設定管理、ソース管理、継続的統合
また、CodeDeploy コンソールでは、リポジトリ、ビルドプロジェクト、デプロイアプリケーション、パイプラインなどのリソースをすばやく検索することもできます。[Go to resource (リソースに移動)] または / キーを押して、リソースの名前を入力します。一致するものはすべてリストに表示されます。検索では大文字と小文字が区別されません。リソースを表示する権限がある場合のみ表示されます。詳細については、「AWS CodeDeployのためのアイデンティティおよびアクセス管理 」を参照してください。
トピック
の利点 AWS CodeDeploy
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 コンピューティングプラットフォームの概要
CodeDeploy では、アプリケーションを 3 つのコンピューティングプラットフォームにデプロイできます。
EC2/オンプレミス: Amazon EC2 クラウドインスタンス、オンプレミスサーバー、またはその両方とすることができる物理サーバーのインスタンスを記述します。EC2/オンプレミスコンピューティングプラットフォームを使用して作成されたアプリケーションは、実行可能ファイル、設定ファイル、イメージなどで構成できます。
EC2/オンプレミス コンピューティングプラットフォームを使用するデプロイでは、インプレイスまたは Blue/Green デプロイタイプを使用して、トラフィックをインスタンスに振り分ける方法を管理できます。詳細については、「CodeDeploy デプロイタイプの概要」を参照してください。
AWS Lambda: 更新されたバージョンの Lambda 関数で構成されるアプリケーションをデプロイするために使用されます。 は、高可用性コンピューティング構造で構成されるサーバーレスコンピューティング環境で Lambda 関数 AWS Lambda を管理します。コンピューティングリソースの管理はすべて、 によって実行されます AWS Lambda。詳細については、「サーバーレスコンピューティングとアプリケーション
」を参照してください。 AWS Lambda および Lambda 関数の詳細については、「」を参照してくださいAWS Lambda 。 Canary 設定、線形設定、または一度にすべての設定を選択して、デプロイ時に更新済み Lambda 関数バージョンにトラフィックを移行する方法を管理できます。
-
Amazon ECS：Amazon ECS にコンテナ化されたアプリケーションをタスクセットとしてデプロイするために使用します。CodeDeploy は、アプリケーションの更新バージョンを新しい置き換えタスクセットとしてインストールすることで、blue/Green のデプロイを実行します。CodeDeploy は、元のアプリケーションタスクセットからの本稼働トラフィックを置き換えタスクセットに再ルーティングします。デプロイが正常に完了すると、元のタスクセットは削除されます。Amazon ECS の詳細については、「Amazon Elastic Container Service
」を参照してください。 Canary 設定、線形設定、または一度にすべての設定を選択して、デプロイ時に更新済みタスクセットにトラフィックを移行する方法を管理できます。
注記
Amazon ECS blue/Green デプロイは、CodeDeploy と AWS CloudFormationの両方でサポートされています。これらのデプロイの詳細については、以降のセクションで説明します。
次の表に、CodeDeploy コンポーネントが各コンピューティングプラットフォームで使用される様子を示します。詳細については、以下を参照してください。
| CodeDeploy コンポーネント | EC2/オンプレミス | AWS Lambda | Amazon ECS |
|---|---|---|---|
| デプロイグループ | 一連のインスタンスにリビジョンをデプロイします。 | 可用性の高いコンピューティングインフラストラクチャで、サーバーレス Lambda 関数の新しいバージョンをデプロイします。 | タスクセットとしてデプロイする、コンテナ化されたアプリケーション、デプロイされたアプリケーションへのトラフィック提供に使用される本稼働およびオプションのテストリスナー、トラフィックを再ルーティングし、デプロイされたアプリケーションの元のタスクセットを終了するタイミング、オプションのトリガー、アラーム、およびロールバック設定で Amazon ECS サービスを指定します。 |
| デプロイ | アプリケーションと AppSpec ファイルから構成される新しいリビジョンをデプロイします。AppSpec は、アプリケーションをデプロイグループのインスタンスにデプロイする方法を指定します。 | Lambda 関数の 1 つのバージョンから、同じ関数の新しいバージョンに本稼働トラフィックを移行させます。AppSpec は、デプロイする Lambda 関数のバージョンを指定します。 | Amazon ECS コンテナ化されたアプリケーションの更新バージョンを、新しい置き換えタスクセットとしてデプロイします。CodeDeploy は、タスクセットからの本稼働トラフィックを置き換えタスクセットに再ルーティングします。デプロイ完了時に、元のタスクセットは削除されます。 |
| デプロイ設定 | デプロイの速度と、デプロイ中にいつでも使用できる必要のある正常なインスタンスの最小数を決定する設定。 | 更新された Lambda 関数バージョンにトラフィックを移行する方法を決定する設定。 | 更新された Amazon ECS タスクセットにトラフィックを移行する方法を決定する設定。 |
| リビジョン | AppSpec ファイルとアプリケーションファイルの組み合わせ (例: 実行ファイル、設定ファイル)。 | AppSpec ファイルは Lambda 関数と、ライフサイクルイベントフック中に検証テストを実行可能な Lambda 関数のデプロイを指定します。 |
AppSpec ファイル以下を指定する。
|
| アプリケーション | デプロイグループおよびリビジョンのコレクション。EC2/オンプレミスアプリケーションは、EC2/オンプレミスコンピューティングプラットフォームを使用します。 | デプロイグループおよびリビジョンのコレクション。 AWS Lambda デプロイに使用されるアプリケーションは、サーバーレス AWS Lambda コンピューティングプラットフォームを使用します。 | デプロイグループおよびリビジョンのコレクション。Amazon ECS デプロイに使用されるアプリケーションは、Amazon ECS コンピューティングプラットフォームを使用します。 |
CodeDeploy デプロイタイプの概要
CodeDeploy には、2 つのデプロイタイプのオプションがあります。
インプレイスデプロイ: デプロイグループの各インスタンス上のアプリケーションが停止され、最新のアプリケーションリビジョンがインストールされて、新バージョンのアプリケーションが開始され検証されます。ロードバランサーを使用し、デプロイ中はインスタンスが登録解除され、デプロイ完了後にサービスに復元されるようにできます。EC2 オンプレミスコンピューティングプラットフォームを使用するデプロイのみが、インプレイスデプロイを使用できます。インプレイスデプロイの詳細については、「インプレースデプロイの概要」を参照してください。
注記
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デプロイ設定に従って増分でシフトされます。
-
経由のブルー/グリーンデプロイ AWS CloudFormation: スタック AWS CloudFormation の更新の一環として、トラフィックは現在のリソースから更新されたリソースに移行されます。現時点では、ECS blue/green デプロイのみがサポートされています。
ブルー/グリーンデプロイの詳細については、「Blue/Green デプロイの概要」を参照してください。
-
注記
CodeDeploy エージェントを使用すると、アプリケーション、デプロイグループ、または AWS アカウントを必要とせずに、サインインしているインスタンスでデプロイを実行できます。詳細については、CodeDeploy エージェントを使用してローカルマシン上のデプロイパッケージを検証する を参照してください。
インプレースデプロイの概要
注記
AWS Lambda および Amazon ECS デプロイでは、インプレースデプロイタイプを使用できません。
インプレイスデプロイの仕組みは次のとおりです。
-
最初に、ローカルの開発用マシンまたは同様の環境でデプロイ可能なコンテンツを作成し、アプリケーション特定ファイル（AppSpecファイル) を追加します。AppSpec ファイルは CodeDeploy に固有です。CodeDeploy で実行するデプロイアクションを定義します。デプロイ可能なコンテンツおよび AppSpec ファイルをアーカイブファイルにバンドルし、Amazon S3 バケットまたは GitHub リポジトリにアップロードします。このアーカイブファイルは、アプリケーションリビジョン (または単にリビジョン) と呼ばれます。
-
次に、リビジョンを取得する Amazon S3 バケットまたは GitHub リポジトリ、コンテンツをデプロイする Amazon EC2 インスタンスのセットなど、デプロイに関する情報を CodeDeploy に提供します。CodeDeploy は Amazon EC2 インスタンスのセットを デプロイグループ で呼び出します。デプロイグループには、個別にタグ付けされた Amazon EC2 インスタンス、Amazon EC2 Auto Scaling グループ内の Amazon EC2 インスタンス、またはその両方が含まれます。
デプロイグループにデプロイする新しいアプリケーションリビジョンを正常にアップロードするたびに、そのバンドルはデプロイグループのターゲットリビジョンとして設定されます。つまり、現在デプロイ対象となっているアプリケーションリビジョンがターゲットリビジョンです。これは、自動デプロイにプルされるリビジョンでもあります。
-
次に、各インスタンスの CodeDeploy エージェントが CodeDeploy をポーリングして、指定された Amazon S3 バケットまたは GitHub リポジトリから何をいつ取得するかを決定します。
-
最後に、各インスタンスの CodeDeploy エージェントは、Amazon S3 バケットや GitHub リポジトリからターゲットリビジョンを取得し、AppSpec ファイルの手順を使用して、コンテンツをインスタンスにデプロイします。
CodeDeploy は、デプロイステータス、デプロイ設定パラメータ、インスタンスの状態を取得できるように、デプロイのレコードを保持します。
Blue/Green デプロイの概要
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 デプロイ AWS CloudFormation では、次のいずれかの方法を使用できます。
-
AWS CloudFormation デプロイ用の テンプレート: AWS CloudFormation テンプレートを使用してデプロイを設定すると、デプロイは AWS CloudFormation 更新によってトリガーされます。リソースを変更し、テンプレートの変更をアップロードすると、 のスタックの更新によって新しいデプロイ AWS CloudFormation が開始されます。 AWS CloudFormation テンプレートで使用できるリソースのリストについては、「」を参照してくださいAWS CloudFormation CodeDeploy リファレンスの テンプレート。
-
によるブルー/グリーンデプロイ AWS CloudFormation: を使用して AWS CloudFormation 、スタックの更新を通じてブルー/グリーンデプロイを管理できます。スタックテンプレート内で、トラフィックルーティングと安定化設定を指定するだけでなく、Blue ソースと Green リソースの両方を定義します。次に、スタックの更新中に選択したリソースを更新すると、 は必要なすべてのグリーンリソース AWS CloudFormation を生成し、指定されたトラフィックルーティングパラメータに基づいてトラフィックをシフトし、ブルーリソースを削除します。詳細については、[AWS CloudFormationユーザーガイド] の [AWS CloudFormation を使用した CodeDeploy による Perform Amazon ECS Blue/Green デプロイの実行] を参照してください。
注記
Amazon ECS Blue/Green デプロイでのみサポートされます。
Blue/Green デプロイを設定する方法は、使用するコンピューティングプラットフォームによって異なります。
AWS Lambda または Amazon ECS コンピューティングプラットフォームへのブルー/グリーンデプロイ
AWS Lambda または Amazon ECS コンピューティングプラットフォームを使用している場合は、トラフィックを元の AWS Lambda 関数または Amazon ECS タスクセットから新しい関数またはタスクセットに移行する方法を指定する必要があります。トラフィックを移行する方法を指定するには、以下のいずれかのデプロイ設定を指定する必要があります。
-
canary
-
線形
-
一度にすべて
Canary 設定、線形設定、または一度にすべてのデプロイ設定でトラフィックを移行する方法については、「デプロイ設定」を参照してください。
Lambda デプロイ設定の詳細については、「AWS Lambda コンピューティングプラットフォームのデプロイ設定」を参照してください。
Amazon ECS デプロイ設定の詳細については、「Amazon ECS コンピューティングプラットフォームのデプロイ設定」を参照してください。
EC2/オンプレミスコンピューティングプラットフォームの Blue/Green デプロイ
注記
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 グループ名、またはその両方を使用して、置き換え先として含めるインスタンスを指定できます。このオプションを選択した場合、デプロイを作成するまで置き換え先環境のインスタンスを指定する必要はありません。
処理の流れ
-
元の環境となるインスタンスや Amazon EC2 Auto Scaling グループは既にあります。Blue/Green デプロイを初めて実行するときは、通常、インプレースデプロイで既に使用されているインスタンスを使用します。
-
既存の CodeDeploy アプリケーションでは、Blue/Green デプロイグループを作成し、インプレースデプロイに必要なオプションに加えて、次を指定します。
-
ブルー/グリーンデプロイプロセス中に元の環境から置き換え先環境にトラフィックをルーティングするロードバランサー。
-
置き換え先環境にトラフィックを直ちに再ルーティングするか、手動で再ルーティングするまで待つかどうか。
-
トラフィックが置き換え先インスタンスにルーティングされるレート。
-
置き換え元インスタンスを削除するか引き続き実行するかどうか。
-
-
このデプロイグループのデプロイを作成するときには、次の処理が行われます。
-
Amazon EC2 Auto Scaling グループをコピーすることを選択した場合、インスタンスは置き換え先環境にプロビジョニングされます。
-
デプロイに指定したアプリケーションリビジョンは、置き換え先インスタンスにインストールされます。
-
デプロイグループの設定で待機時間を指定した場合、デプロイは一時停止します。これは置き換え先環境のテストおよび確認を実行できる時間です。待機時間が終了する前にトラフィックを手動で再ルーティングしない場合、デプロイは停止します。
-
置き換え先環境のインスタンスは Elastic Load Balancing ロードバランサーに登録され、これらのインスタンスに対してトラフィックのルーティングが開始されます。
-
元の環境のインスタンスは、終了するか引き続き実行するか、デプロイグループの指定に従って登録が解除され、処理されます。
-
によるブルー/グリーンデプロイ AWS CloudFormation
AWS CloudFormation テンプレートを使用してリソースをモデリングすることで、CodeDeploy Blue/Green のデプロイを管理できます。
AWS CloudFormation テンプレートを使用して Blue/Green リソースをモデル化する場合、タスクセット AWS CloudFormation を更新するスタック更新を に作成します。本稼働トラフィックは、すべて一度に、線形デプロイとベイク処理時間を使用して、または Canary デプロイを使用してサービスの元のタスクセットから置き換えタスクセットにシフトします。スタックの更新により、CodeDeploy でデプロイが開始されます。CodeDeploy でデプロイのステータスと履歴を表示できますが、それ以外の場合は、 AWS CloudFormation テンプレートの外部で CodeDeploy リソースを作成または管理しません。
注記
からブルー/グリーンデプロイでは AWS CloudFormation、CodeDeploy アプリケーションまたはデプロイグループを作成しません。
この方法では、Amazon ECS Blue/Green デプロイのみサポートされます。によるブルー/グリーンデプロイの詳細については AWS CloudFormation、「」を参照してくださいを使用して Amazon ECS ブルー/グリーンデプロイを作成する AWS CloudFormation。
ご意見をお待ちしております
ご意見をお待ちしております。お問い合わせの場合には、CodeDeploy フォーラム
トピック
