CI/CD パイプライン構築コース

ECS自動デプロイの4ステップ — 変更を安全に届ける順番

ECSへの自動デプロイは、ツールが違っても「ビルド、DBマイグレーション、サービス更新、通知」という順序に収束します。順番の理由と責務分離を掴みます。

TL;DR

ビルド → DBマイグレーション → ECS更新 → 通知。

DockerイメージをECRへpushし、その新版のdb-migratorを単発実行する。成功して初めてサービスを新タスク定義へ更新し、最後に結果を関係者へ知らせる。

DBマイグレーションを通さずにサービスを更新しない依存関係が、アプリとスキーマの不整合を防ぐ。

古いdb-migratorを走らせても、新しいmigrationファイルは反映されない。

先にイメージをビルドしてタグを確定し、そのタグを参照する単発ECSタスクでマイグレーションを実行する。失敗時にサービスを更新しない依存関係が安全弁になる。

db-migratorも新イメージで実行する。古いイメージでは追加したmigrationを反映できない。

基盤の安定した変更と、イメージタグのように頻繁な変更を同じapplyに載せない。

TerraformはVPC・IAM・ECRなど基盤を管理する。ecspressoはSSMからイメージタグを読み、ECSタスク定義とサービスのデプロイに集中する。

頻繁に変わるアプリのデプロイを、基盤全体のterraform applyに巻き込まない。