CodeDeploy ブルー/グリーンデプロイを Amazon ECS ブルー/グリーンデプロイに移行 - Amazon Elastic Container Service
CodeDeploy ブルー/グリーンデプロイの概要Amazon ECS ブルー/グリーンデプロイの概要主要な実装上の相違点移行アプローチ次のステップ

CodeDeploy ブルー/グリーンデプロイを Amazon ECS ブルー/グリーンデプロイに移行

CodeDeploy ブルー/グリーンデプロイと Amazon ECS ブルー/グリーンデプロイの機能は類似していますが、設定および管理方法が異なります。

CodeDeploy ブルー/グリーンデプロイの概要

CodeDeploy を使用して Amazon ECS サービスを作成すると、以下を実行できます。

  1. 本番リスナーおよび (必要に応じて) テストリスナーを使用してロードバランサーを作成します。各リスナーは、すべてのトラフィックを単一のターゲットグループ (プライマリターゲットグループ) にルーティングする 1 つの (デフォルト) ルールで設定されます。

  2. deploymentController タイプが CODE_DEPLOY に設定された状態で、リスナーおよびターゲットグループを使用するように設定された Amazon ECS サービスを作成します。サービスを作成すると、指定されたターゲットグループに登録された (ブルー) タスクセットが作成されます。

  3. CodeDeploy のデプロイグループ (CodeDeploy アプリケーションの一部として) を作成し、デプロイ動作を制御する Amazon ECS クラスター、サービス名、ロードバランサーリスナー、2 つのターゲットグループ (本番のリスナールールで使用されるプライマリターゲットグループ、ならびに代替タスクに使用されるセカンダリターゲットグループ)、サービスロール (Amazon ECS および Elastic Load Balancing リソースを操作するアクセス許可を CodeDeploy に付与するため)、およびさまざまなパラメータの詳細を使って設定します。

CodeDeploy を使用すると、CreateDeployment() を使用してサービスの新しいバージョンがデプロイされ、CodeDeploy のアプリケーション名、デプロイグループ名、新しいリビジョンおよびオプションのライフサイクルフックの詳細を提供する AppSpec ファイルが指定されます。CodeDeploy デプロイでは代替 (緑) タスクセットが作成され、タスクがセカンダリターゲットグループに登録されます。正常になると、テスト (オプション) および本番で利用できます。どちらの場合も、グリーンタスクセットに関連付けられたセカンダリターゲットグループを指すようにリスナールールを変更することで、再ルーティングが実現します。ロールバックは、本番のリスナールールをプライマリターゲットグループに戻すことで実現します。

Amazon ECS ブルー/グリーンデプロイの概要

Amazon ECS ブルー/グリーンデプロイを使用すると、デプロイ設定が Amazon ECS サービス自体の一部になります。

  1. 重みが 1 および 0 で構成される 2 つのターゲットグループを含むルールで、ロードバランサーの本番リスナーを事前設定する必要があります。

  2. 次のリソースを指定するか、サービスリソースを更新する必要があります。

    • このリスナールールの ARN

    • 2 つのターゲットグループ

    • Elastic Load Balancing API を呼び出すアクセス許可を Amazon ECS に付与する IAM ロール

    • Lambda 関数を実行する IAM ロール (オプション)

    • deploymentController タイプを ECS に設定し、deploymentConfiguration.strategy を BLUE_GREEN に設定します。タスクがプライマリターゲットグループに登録されている (ブルー) サービスデプロイが作成されます。

Amazon ECS ブルー/グリーンを使用すると、Amazon ECS UpdateService() を呼び出すことで新しいサービスリビジョンが作成され、新しいリビジョンの詳細が渡されます。サービスデプロイによって新しい (グリーン) サービスリビジョンタスクが作成され、セカンダリターゲットグループに登録されます。Amazon ECS はリスナールールの重みを切り替えることで、再ルーティングおよびロールバックオペレーションを処理します。

主要な実装上の相違点

どちらのアプローチによってもタスクの初期セットが作成されますが、基盤となる実装は異なります。

  • CodeDeploy ではタスクセットが使用されますが、Amazon ECS ではサービスリビジョンが使用されます。Amazon ECS のタスクセットは、Amazon ECS サービスリビジョンおよびデプロイに置き換えられた古いコンストラクトです。後者はデプロイプロセス、サービスデプロイ、サービスリビジョン履歴をさらに詳細に可視化します。

  • CodeDeploy を使用すると、ライフサイクルフックは CreateDeployment() に提供される AppSpec ファイルの一部として指定されます。つまり、フックは 1 つのデプロイから次のデプロイに変更できます。Amazon ECS ブルー/グリーンを使用すると、フックはサービス設定の一部として指定され、更新には UpdateService() の呼び出しが必要になります。

  • CodeDeploy および Amazon ECS ブルー/グリーンは両方ともフック実装に Lambda を使用しますが、予想される入力および出力は異なります。

    CodeDeploy を使用すると、関数は PutLifecycleEventHookExecutionStatus() を呼び出してフックステータスを返す必要があり、フックステータスは SUCCEEDED または FAILED になります。Amazon ECS を使用すると、Lambda レスポンスが使用されてフックステータスが示されます。

  • CodeDeploy は各フックを 1 回限りの呼び出しとして呼び出し、最終的な実行ステータスは通常 1 時間以内に返されます。Amazon ECS フックは、IN_PROGRESS インジケータを返すことができるという点でより柔軟です。このインジケータにより、フックが SUCCEEDED または FAILED になるまで繰り返し呼び出される必要があることが示されます。詳細については、「Amazon ECS サービスデプロイのライフサイクルフック」を参照してください。

移行アプローチ

CodeDeploy ブルー/グリーンデプロイから Amazon ECS ブルー/グリーンデプロイに移行するアプローチには主に 3 つあります。各アプローチには、複雑さ、リスク、ロールバック機能、潜在的なダウンタイムの点で特性が異なります。

CodeDeploy に使用される Elastic Load Balancing リソースと同じものを再利用します

CodeDeploy デプロイコントローラーの代わりに、ブルー/グリーンデプロイ戦略で Amazon ECS デプロイコントローラーを使用するように、既存の Amazon ECS サービスを更新します。このアプローチを使用する場合は、次の点を考慮してください。

  • 既存の Amazon ECS サービスデプロイコントローラーおよびデプロイ戦略を更新するため、移行手順がよりシンプルになります。

  • 正しく設定および移行されている場合、ダウンタイムはありません。

  • ロールバックには、サービスリビジョンを元に戻す必要があります。

  • ブルー/グリーン設定が並行していないため、リスクが高くなります。

CodeDeploy に使用されるロードバランサーリスナーおよびターゲットグループと同じものを使用します。CloudFormation を使用している場合は、「CloudFormation CodeDeploy ブルー/グリーンデプロイのテンプレートを Amazon ECS ブルー/グリーン CloudFormation テンプレートへの移行」を参照してください。

  1. 本番/テストのリスナーのデフォルトルールを変更して代替ターゲットグループを含め、プライマリターゲットグループの重みを 1 に設定し、代替ターゲットグループの重みを 0 に設定します。

    CodeDeploy の場合、サービスにアタッチされたロードバランサーのリスナーは、すべてのトラフィックを単一のターゲットグループにルーティングする、1 つの (デフォルト) ルールで設定されます。Amazon ECS ブルー/グリーンの場合、ロードバランサーリスナーは重みを持つ 2 つのターゲットグループが含まれるルールで事前設定する必要があります。プライマリターゲットグループは 1 に重み付けされ、代替ターゲットグループは 0 に重み付けされる必要があります。

  2. UpdateService API を呼び出して deploymentController パラメータを ECS に設定し、deploymentStrategy パラメータを BLUE_GREEN に設定することで、既存の Amazon ECS サービスを更新します。ターゲットグループの ARN、代替ターゲットグループ、本番リスナー、オプションのテストリスナーを指定します。

  3. サービスが期待どおりに動作することを確認します。

  4. 現在は Amazon ECS ブルー/グリーンを使用しているため、この Amazon ECS サービスの CodeDeploy 設定を削除します。

既存のロードバランサーを含む新しいサービス

このアプローチでは、移行にブルー/グリーン戦略を使用します。

このアプローチを使用する場合は、次の点を考慮してください。

  • 中断は最小限に抑えられます。Elastic Load Balancing のポートスワップ中にのみ発生します。

  • ロールバックには、Elastic Load Balancing のポートスワップを元に戻す必要があります。

  • 並列設定があるため、リスクが低くなります。したがって、トラフィックが移行する前にテストできます。

  1. 必要に応じてこの設定に簡単にロールバックできるように、CodeDeploy 設定のリスナー、ターゲットグループ、Amazon ECS サービスはそのままにします。

  2. 既存のロードバランサーの下で、新しいターゲットグループおよび新しいリスナー (元のリスナーとは異なるポートを所有) を作成します。次に、既存の Amazon ECS サービスに一致する新しい Amazon ECS サービスを作成しますが、ECS をデプロイコントローラー、BLUE_GREEN をデプロイ戦略として使用し、新しいターゲットグループおよび新しいリスナールールの ARN を渡します。

  3. サービスに HTTP トラフィックを手動で送信し、新しい設定を確認します。問題がなければ、元のリスナーと新しいリスナーのポートをスワップし、トラフィックを新しい設定にルーティングします。

  4. 新しい設定を確認します。依然として期待どおりにすべてが動作する場合は、CodeDeploy 設定を削除します。

新しいロードバランサーを持った新しいサービス

前のアプローチと同様に、このアプローチでは移行にブルー/グリーン戦略を使用します。主な違いは、CodeDeploy 設定から Amazon ECS ブルー/グリーンの設定への切り替えが、ロードバランサーの上にあるリバースプロキシレイヤーで行われることです。リバースプロキシレイヤーのサンプル実装は、Route 53 および CloudFront です。

このアプローチはこのリバースプロキシレイヤーを既に持っているお客様に適しており、サービスとのすべての通信がこのリバースプロキシレイヤーを通じて行われている場合にも適しています (例えば、ロードバランサーレベルで直接通信がない場合など)。

このアプローチを使用する場合は、次の点を考慮してください。

  • リバースプロキシレイヤーが必要です。

  • 既存の Amazon ECS サービスデプロイコントローラーおよびデプロイ戦略を更新する必要があるため、移行手順がより複雑になります。

  • 中断は最小限に抑えられます。Elastic Load Balancing のポートスワップ中にのみ発生します。

  • ロールバックには、プロキシ設定の変更を元に戻す必要があります。

  • 並列設定があるため、リスクが低くなります。したがって、トラフィックが移行する前にテストできます。

  1. 既存の CodeDeploy 設定を変更しないでください (ロードバランサー、リスナー、ターゲットグループ、Amazon ECS サービス、CodeDeploy デプロイグループ)。

  2. Amazon ECS ブルー/グリーンデプロイ用に設定された新しいロードバランサー、ターゲットグループ、リスナーを作成します。

    適切なリソースを設定します。

  3. ECS および BLUE_GREEN をそれぞれデプロイコントローラーおよびデプロイ戦略とし、新しいロードバランサーリソースを指す新しいサービスを作成します。

  4. 新しいロードバランサーを通じてテストすることで、新しいセットアップを確認します。

  5. リバースプロキシ設定を更新し、トラフィックを新しいロードバランサーにルーティングします。

  6. 新しいサービスリビジョンに従って、期待どおりにすべてが動作し続けた場合、CodeDeploy 設定を削除します。

次のステップ

Amazon ECS ブルー/グリーンデプロイに移行した後

  • CodeDeploy UpdateService API の代わりに、Amazon ECS CreateDeployment API を使用するように、デプロイスクリプトと CI/CD パイプラインを更新します。

  • CodeDeploy デプロイの代わりに、Amazon ECS サービスのデプロイを追跡するように、モニタリングおよびアラートを更新します。

  • 期待どおりに機能することを確認するため、新しいデプロイプロセスの自動テストを実装することを検討してください。