概要
説明のたびにmarkdownのファイルを投げつｋ・・提示するよりは外部に公開しておいたほうがよいよねという話から執筆しています。
類似の記事はいっぱいあると思うので、B/Gって何？とかより詳しい説明はそちらをお求めください。
デプロイ戦略の変化
2025年7月18日のリリース より前と後について、インフラの人向けに terraform(おそらくCDKでも同じだと思うけど) のdeployment_controller.typeとdeployment_configurationの組み合わせを用いて説明します。
2025年７月以前
2025年7月リリース以前のECSデプロイメントコントローラーとストラテジーの組み合わせ一覧：
| deployment_controller.type | deployment_strategy/configuration | 説明 | 特徴 |
|---|---|---|---|
| ECS (デフォルト) | ROLLING (デフォルト) | ローリングアップデート |
minimumHealthyPercentとmaximumPercentで制御 |
| CODE_DEPLOY | CodeDeployDefault.ECSAllAtOnce | 一括トラフィック移行 | CodeDeployアプリケーション必須 |
| CODE_DEPLOY | CodeDeployDefault.ECSLinear* | 段階的トラフィック移行 | 例: Linear10PercentEvery1Minutes |
| CODE_DEPLOY | CodeDeployDefault.ECSCanary* | カナリアデプロイ | 例: Canary10Percent5Minutes |
| EXTERNAL | （外部ツールで管理） | 外部コントローラー | TaskSet APIで手動管理 |
- ECSコントローラーではROLLINGのみ対応
- B/G、Linear、CanaryはすべてCODE_DEPLOYコントローラー経由でのみ利用可能
現在
現在採用できるdeployment_controller.typeとdeployment_configurationの組み合わせの一覧。
| deployment_controller.type | deployment_strategy | 説明 | 特徴 |
|---|---|---|---|
| ECS (デフォルト) | ROLLING (デフォルト) | ローリングアップデート | タスクを順次置き換え。minimumHealthyPercentとmaximumPercentで制御 |
| ECS | BLUE_GREEN | ネイティブB/G（2025年7月新機能） | ALB/NLB/ServiceConnect必須。ライフサイクルフック、ベイクタイム対応 |
| ECS | LINEAR | 段階的トラフィックシフト | 指定パーセントずつ段階的にトラフィック移行（例：20%ずつ） |
| ECS | CANARY | カナリアデプロイ | 最初に小割合、その後残りを移行（例：10%→90%） |
| CODE_DEPLOY | （CodeDeployで設定） | CodeDeploy管理のB/G | 非推奨。CodeDeployアプリケーション、デプロイメントグループが必要 |
| EXTERNAL | （外部ツールで管理） | 外部コントローラー | TaskSetを手動管理。Jenkins、PipeCDなどのサードパーティツール用 |
- かつてはECSネイティブのBLUE_GREEN/LINEAR/CANARYストラテジーは存在しなかった
- 全この表はAIに作らせていて部を実際に構築して試したわけではないので間違いはあるかもしれないですが、説明したいのはECS+BLUE_GREENのケースについてです、指摘があればコメントにお願いします
ECS+BLUE_GREENのケースについて
B/GやるのにCodeDeployいらないんですって・・・
Code Deployをやろうと思うと信じられないくらいめんどくさかったんですが、それが一切不要になりました。
また、デプロイのためのaws cliのコマンドもローリングアップデートのときと同じです。
# 新しいタスク定義の登録
aws ecs register-task-definition \
--cli-input-json file://task-definition.json \
--region us-east-1
# サービスの更新（新しいタスク定義を使用）
aws ecs update-service \
--cluster my-cluster \
--service my-service \
--task-definition my-task:2 \
--region us-east-1
いろいろ言ってのらりくらり躱してますがまじでCode Deploy作るのめんどくさいので作りたくなかったですが、構築の手間無しでB/Gできると・・・
リリースフローや要件によっては採用たくないネガティヴが消えるかもですね。
採用したくないのは私だけですか、そうですか。
設定に寄ってはローリングアップデートと同じような見た感じの挙動をさせることができるので、まだ検証してませんが次のインフラ構築辺りでコッソリ入れてみようと思います。