CodeDeploy プライマリ

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

Application

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

コンピューティングプラットフォーム

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

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

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

• AWSLambda: Lambda 関数の更新バージョンで構成されるアプリケーションのデプロイに使用されます。AWS Lambdaは、高可用性コンピューティング構造で構成されるサーバーレスコンピューティング環境で 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 が使用する一連のデプロイのルール、デプロイの成功条件、デプロイの失敗条件です。デプロイで EC2/オンプレミスコンピューティングプラットフォームを使用している場合、デプロイの正常なインスタンスの最小数を指定できます。デプロイメントがAWS Lambdaまたは Amazon ECS コンピューティングプラットフォームでは、更新された Lambda 関数または ECS タスクセットにトラフィックがルーティングされる方法を指定できます。

EC2/オンプレミスコンピューティングプラットフォームを使用するデプロイの正常なホストの最小数の指定については、「」を参照してください。正常なインスタンスの最小数およびデプロイ数。

次のデプロイ設定では、Lambda または ECS コンピューティングプラットフォームを使用するデプロイの間にトラフィックがルーティングされる方法を指定します。

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

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

• オールインワン: すべてのトラフィックは、元の Lambda 関数または ECS タスクセットから、更新された関数またはタスクセットに同時に移行されます。

デプロイグループ

あるデプロイグループは、個々のインスタンスのセットです。デプロイグループには、個別にタグ付けされたインスタンス、Amazon EC2 Auto Scaling グループ内の Amazon EC2 インスタンス、またはその両方が含まれます。Amazon EC2 インスタンスタグの詳細については、「」を参照してください。コンソールでのタグの処理。オンプレミスインスタンスの詳細については、「Working with On-Premises Instances」を参照してください。Amazon EC2 Auto Scaling の詳細については、「」を参照してください。Amazon EC2 Auto Scaling と CodeDeploy。

デプロイタイプ

あるデプロイタイプは、デプロイグループ内のインスタンスで最新のアプリケーションリビジョンを使用できるようにするためのメソッドです。次の 2 種類のデプロイタイプがあります。

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

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

  • EC2/オンプレミスコンピューティングプラットフォームのBlue/Green: デプロイグループのインスタンス (元の環境) は、次の手順を使用して、異なるインスタンスのセット (置き換え先環境) に置き換えられます。

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

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

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

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

    注記

    EC2/オンプレミスのコンピューティングプラットフォームを使用する場合は、ブルー/グリーンのデプロイは Amazon EC2 インスタンスでのみ機能することに注意してください。

  • 上のBlue/GreenAWS Lambdaまたは Amazon ECS コンピューティングプラットフォーム: トラフィックは、Canary,線形, またはオールインワンデプロイ設定。詳細については、「デプロイ設定」を参照してください。

  • を使用した Blue/Green デプロイAWS CloudFormation: トラフィックは、現在のリソースから、更新されたリソースに移行されます。AWS CloudFormationスタックの更新。現時点では、ECS Blue/Green デプロイのみがサポートされています。

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

注記

Amazon ECS Blue/Green デプロイメントは、CodeDeploy とAWS CloudFormation。これらのデプロイの詳細については、以降のセクションで説明します。

IAM インスタンスプロファイル

AnIAM インスタンスプロファイルは、Amazon EC2 インスタンスにアタッチする IAM ロールです。このプロファイルには、アプリケーションが保存される Amazon S3 バケットまたは GitHub リポジトリへのアクセスに必要なアクセス許可が含まれます。詳細については、「ステップ 4: Amazon EC2 インスタンスの IAM インスタンスプロファイルを作成する」を参照してください。

リビジョン

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

サービスロール

あるサービスロールは、アクセス権限を付与する IAM ロールですかAWSアクセスできるようにするサービスAWSリソースの使用料金を見積もることができます。サービスロールにアタッチするポリシーによって、どのポリシーが決まります。AWSサービスがアクセスできるリソースと、これらのリソースで実行できるアクション。CodeDeploy の場合、サービスロールは次の目的で使用されます。

• インスタンスに適用されているタグまたは Amazon EC2 Auto Scaling グループ名を読み取るには、インスタンスに関連付けられています。これにより、CodeDeploy はアプリケーションをデプロイできるインスタンスを識別できます。

• インスタンス、Amazon EC2 Auto Scaling グループ、および Elastic Load Balancing サーでオペレーションを実行するには。

• 指定したデプロイまたはインスタンスイベントが発生したときに通知を送信できるように、Amazon SNS トピックに情報を公開すること。

• CloudWatch アラームに関する情報を取得して、デプロイのアラームモニタリングを設定します。

詳細については、「ステップ 2: CodeDeploy のサービスロールの作成」を参照してください。

ターゲットリビジョン

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

他のコンポーネント

CodeDeploy ワークフローの他のコンポーネントの詳細については、次のトピックを参照してください。

• CodeDeploy リポジトリタイプを選択する

• Deployments

• Application Specification Files

• Instance Health

• CodeDeploy エージェントの使用

• Working with On-Premises Instances