はじめに
本記事では、FastAPIで作成したバックエンドアプリケーションをAWSのECR（Elastic Container Registry）とECS（Elastic Container Service）にデプロイするGitHub Actionsワークフローについて整理します。
この内容は、受講しているITスクールのハッカソンにおいて、チームメンバーの方が作成してくださったものを、レビューした際にまとめたものです。（いろいろと作業いただき、ありがとうございます。）
ビルド済みイメージをECRに登録し、ECSで運用することで本番環境への安全なデプロイを実現します。
書こうと思ったきっかけ
バックエンドアプリケーションの運用において、コンテナイメージのビルドとECSサービスの更新を自動化できるよう、作成いただきました。
特に、手動操作によるリスクや作業コストを削減し、確実かつ迅速なリリースを実現するためのデプロイワークフローとなっています。
ワークフローの概要（2025/04/27）
このGitHub Actionsワークフローは、FastAPIアプリケーションのDockerイメージをECRにプッシュし、ECSサービスに適用するために作成されています。
トリガー条件
- 「Build and Test FastAPI Backend」ワークフローが成功した後（
mainブランチ対象） - 手動実行（
workflow_dispatch）
実行内容
-
コードチェックアウト
- GitHubリポジトリからソースコードを取得
-
コミット情報のダウンロードと設定
- ビルド時に保存したコミットSHAを取得し、タグ付けに利用
- 手動実行時は入力されたSHAも使用可能
-
AWS認証情報の設定
- GitHub Secretsに保存されたAWSアクセスキー情報を使ってAWS CLI認証を設定
-
ECRログイン
- Amazon ECRに対してDocker認証を実施
-
Docker Buildxセットアップ
- マルチプラットフォーム対応のビルド機能（Buildx）を有効化
-
APIコンテナビルド＆プッシュ
-
./backend/apiをビルドし、ECRリポジトリにcommit_shaタグとlatestタグでプッシュ
-
-
マイグレーションコンテナビルド＆プッシュ
-
./backend/migrationも同様にビルド＆プッシュ
-
-
ECSタスク定義の更新（API）
- 新しいイメージURIに差し替えたタスク定義ファイルを作成
-
ECSサービス更新（API）
- 更新したタスク定義を使用してECSサービスをデプロイ。サービスの安定化まで待機
-
DBマイグレーション実行
- ECSクラスタ上でマイグレーションタスク（Fargate）をRunTaskとして実行
補足ポイント
- APIとマイグレーションのDockerイメージをそれぞれ別々にビルド＆プッシュしている
- 手動デプロイにも対応しており、柔軟な運用が可能
まとめ
このワークフローにより、FastAPIバックエンドのECR/ECSデプロイが完全自動化され、運用の負荷とリスクが大幅に低減されると思います！
作成いただいた方、本当にありがとうございます...！
まずはこの仕組みを堅牢に運用し、迅速で信頼性の高いサービス運用基盤を築いていきたいと思います...！