CodeDeploy プライマリコンポーネント - AWS CodeDeploy

CodeDeploy プライマリコンポーネント

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

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

コンピューティングプラットフォーム: CodeDeploy によってアプリケーションがデプロイされるプラットフォーム。

  • 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」を参照してください。

    Canary 設定、線形設定、または一度にすべての設定を選択して、デプロイ時に更新済み Lambda 関数バージョンにトラフィックを移行する方法を管理できます。

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

    Canary 設定、線形設定、または一度にすべての設定を選択して、デプロイ時に更新済みタスクセットにトラフィックを移行する方法を管理できます。

デプロイ設定: デプロイ中に CodeDeploy が使用する一連のデプロイのルール、デプロイの成功条件、デプロイの失敗条件です。デプロイで EC2/オンプレミス compute platform を使用している場合、デプロイの正常なインスタンスの最小数を指定できます。デプロイで AWS Lambda compute platform または Amazon ECS compute platform を使用している場合、更新された Lambda 関数のバージョンにトラフィックがルーティングされる方法を指定できます。

EC2/オンプレミス compute platform を使用したデプロイに対する正常なホストの最小数の指定については、「正常なインスタンスとデプロイの最小数」を参照してください。

以下は、AWS Lambda compute platform を使用するデプロイの間にトラフィックをルーティングする方法を指定するデプロイ設定です。

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

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

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

以下は、Amazon ECS compute platform を使用するデプロイの間にトラフィックをルーティングする方法を指定するデプロイ設定です。

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

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

  • All-at-once: すべてのトラフィックは元の Amazon ECS タスクセットから、更新された Amazon ECS タスクセットに同時に移行されます。

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

デプロイタイプ: デプロイグループのインスタンスで最新のアプリケーションリビジョンを使用可能にするために使用される方法。

  • インプレイスデプロイ: デプロイグループの各インスタンス上のアプリケーションが停止され、最新のアプリケーションリビジョンがインストールされて、新バージョンのアプリケーションが開始され検証されます。ロードバランサーを使用すれば、各インスタンスがデプロイ中に登録解除され、デプロイ完了後にサービスに復元されるようにすることができます。インプレイスデプロイは、EC2/オンプレミス 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 サービス内のアプリケーション元のバージョンのタスクセットから、同じサービスの置き換えタスクセットに移行されます。デプロイメント設定を使用して、トラフィックの移行を線形または Canary に設定できます。指定されたロードバランサーリスナーのプロトコルとポートは、本稼働トラフィックを再ルーティングするために使用されます。デプロイ中、テストリスナーは、検証テストの実行中に設定された置換タスクセットにトラフィックを配信するために使用することができます。

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

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

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

サービスロール: AWS のサービスにアクセス権限を付与して AWS リソースにアクセスできるようにする IAM ロール。サービスロールにアタッチするポリシーによって、どの AWS リソースにサービスがアクセスできるか、およびそれらのリソースで実行できるアクションが決まります。CodeDeploy の場合、サービスロールが以下の目的で使用されます。

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

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

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

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

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

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

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