ゼロからプロダクションへ：Fly.io と GitHub Actions を使った FastAPI のデプロイ

main ブランチにコードをプッシュする。テストが実行される。数分後には API が本番環境で稼働する。

これがプロフェッショナルなデプロイメント・パイプラインの構築方法です。このセットアップにデータベースや Redis は必要ありません。必要なのは、1つの FastAPI アプリ、1つの Docker イメージ、1つの YAML 設定、そして 1つの GitHub Actions ワークフローだけです。

ワークフローは以下の通りです： git push → GitHub Actions → テスト実行 → イメージ構築 → Fly.io へデプロイ → 本番稼働

このシステムは3つの要素で構成されています：

• FastAPI アプリ。どこでも同じように動作するように、Docker イメージにパッケージ化します。
• Fly.io。イメージを軽量なマシン上で実行します。ルーティングやヘルスチェックを自動で行ってくれます。
• GitHub Actions。コードを監視し、プッシュのたびに自動でデプロイを行います。

セキュリティを確保するために、スコープを限定したデプロイ用トークンを使用してください。個人の Fly API トークンは使用しないでください。特定のアプリのみを操作できる権限を持つトークンを作成します。このトークンを GitHub Secrets に FLY_API_TOKEN として保存してください。

セットアップにおける重要な技術的詳細：

• 非ルートユーザーを使用する Dockerfile を使用してください。これによりセキュリティが向上します。
• Dockerfile 内でアプリを 0.0.0.0 にバインドしてください。127.0.0.1 を使用すると、Fly からアプリにアクセスできなくなります。
• fly.yaml ファイルを使用してください。このファイルが「信頼できる唯一の情報源（source of truth）」となります。リージョン、メモリ、ポートをここで定義します。
• FastAPI にヘルスチェック用のエンドポイントを設定してください。Fly はこれを利用して、トラフィックを送信する前にアプリが正常に動作しているかを確認します。これにより、ダウンタイムなしのデプロイ（zero-downtime deployment）が可能になります。

GitHub Actions のワークフローでは、needs: test コマンドを使用してください。これにより、テストに合格した場合のみアプリがデプロイされるようになります。コードに問題がある場合、パイプラインは本番環境に到達する前に停止します。

このセットアップは拡張可能です。fly.stg.yaml や fly.prod.yaml のような異なる設定ファイルを使用することで、ステージング環境や本番環境を追加できます。

手動でのデプロイはやめましょう。「自分の PC で動く」状態から、「マージのたびにリリースされる」状態へと移行しましょう。

出典: https://dev.to/devded/zero-to-production-fastapi-on-flyio-and-github-actions-1ejo