今いるディレクトリにNext.jsをセットアップ
npx create-next-app@latest ./
githubリポジトリ作成、httpsのURLを下記コードに張り付けてプッシュ
git remote add origin https://github.com/xxxx
shadcn/ui セットアップ
# shadcn/uiの初期化
npx shadcn@latest init
# 必要なコンポーネントをインストール
npx shadcn@latest add card
npx shadcn@latest add button
npx shadcn@latest add progress
AWSのAmplifyからGitHubを選択してデプロイ
問題点 | 内容 | 対処法 |
---|---|---|
fs.writeFile が使えない | Lambda(Amplify)では /tmp 以外は書き込めない | 一時保存なら /tmp を使う |
public/uploads/ に保存してもアクセスできない | ビルド時に固定化されるため、書き込み内容は見えない | S3へアップロードする |
temporary(テンポラリ)
Amplify に Next.js アプリをデプロイについて整理
そもそも通常のNode.jsサーバーにデプロイする場合(例:VPSやEC2)の場合
npm run build
npm run start
Node.js のサーバーを起動
⬇️
そのサーバーが SSR ページをリクエストごとに生成
→ つまり「SSR処理は常に自前のサーバーで処理してる」、アプリ全体が 1つのNodeプロセスで動いてる
Amplify に Next.js アプリをデプロイする場合(サーバーレス)
AmplifyはSSR/APIの必要な部分を切り出し、SSRページの処理を Lambda@Edge関数として個別に配置
ページアクセス時にそのLambdaが一時的に起動してSSRする
→ つまり「自前でNodeサーバーは立ち上がってない!必要なときだけLambdaで動く!」
実はVercelもAmplifyと同じ「サーバーレス型」ただし、VercelはNext.jsの「公式ホスティング」で、対応範囲がめちゃ広い
Middleware、Edge Functions、StreamingなどのNext.js最新機能に強い
Node.jsを使わずLambda(Amplify)だけでSSRする場合の制限事項
Lambda関数は書き込みできるのは /tmp のみのため、アップロードしたファイルをpublic/uploads保存に保存することはできません
/tmpについて
サーバー側のローカルディスク上の一時領域であって、
クライアント(ブラウザ)からアクセスできない!
/tmpに保存する場合
「保存したら外部に送りたい」って用途だったら、このまま /tmp に一時保存→送信→削除の流れにすればOK!
または保存せず、直接 POST でストリーム転送する方法もあるよ〜。
一般的&シンプルにFastAPIをデプロイする方法(AWS編)
方法 | 特徴 | メリット | デメリット | 推奨ケース |
---|---|---|---|---|
Fargate (ECS) | サーバレスコンテナ | 自由度高、常時稼働OK、運用楽 | 初期設定やや多め | 標準的なAPI運用に◎ |
Lambda + API Gateway | 関数型API | スケーラブル、完全サーバレス | 起動遅い、制限多め | 軽量API・Webhook向け |
EC2 + nginx | 仮想サーバ | 完全自由、チューニング可 | 運用コスト・セキュリティ対応必要 | 学習やがっつり運用 |
Amplify | フロント向けMBaaS | CI/CD込み、簡単デプロイ | FastAPI非対応、裏でLambda | React等との併用時のみ |
App Runner | フルマネージドWebアプリ実行環境 | 最速で公開、HTTPSも簡単 | 実行コストやや高 | 短期PoCやお試しに◎ |
Elastic Beanstalk | PaaS型アプリ実行環境 | デプロイ簡単、監視付き | 古め、挙動が重いことも | レガシー互換・お手軽運用 |
# fastapi-apprunnerという名前の新しいディレクトリを作成します
mkdir fastapi-apprunner
# 作成したfastapi-apprunnerディレクトリに移動します
cd fastapi-apprunner
# venvという名前のPython仮想環境を作成します
python -m venv venv
# 作成したvenv仮想環境を有効化(アクティベート)します(LinuxやmacOSのシェルで使用)
source venv/bin/activate
# WindowsのPowerShellで仮想環境をアクティブ化するには、以下のコマンド
.\venv\Scripts\Activate
(venv) PS C:\ida_test\work\fastapi-apprunner>
# FastAPIとUvicorn(ASGIサーバー)をインストールします
pip install fastapi uvicorn
# 現在の仮想環境にインストールされているパッケージとそのバージョンをrequirements.txtファイルに書き出します
pip freeze > requirements.txt
「venvでローカル実行もして、結局Dockerでも動かす」って、ちょっと二重構成っぽく見えますが、一般的な開発フローです
- venvは開発のためのパワーツール(ローカルチェック)
- Dockerはデプロイ用の本番対応パッケージ
venvで速く試す → 問題なさそう → Dockerでまとめてデプロイ
仮想環境(venv)がアクティブなまま docker buildします
docker build -t fastapi-apprunner .
docker run -p 8000:8000 fastapi-apprunner
App Runner デプロイ手順(GitHub 経由)
① GitHub と App Runner を接続する
AWS マネジメントコンソールへログイン
検索バーで「App Runner」と入力してサービスに移動
「Create service(サービスを作成)」をクリック
② ソースを指定する
ランタイムでDockerfileが指定できないので、下記の手順に変更
Dockerfile を元に AWS App Runner へデプロイ(ECR 経由)
App Runner + ECR + Dockerfile の組み合わせは、コンテナ化されたアプリケーションをAWSで簡単にデプロイ・運用するためのサーバーレスコンテナサービスです。
全体の流れ
- Dockerfileでアプリをコンテナ化
- ECRにDockerイメージをプッシュ
- App RunnerがECRからイメージを取得してデプロイ
AWS CLI をインストール
インストールを確認
aws --version
出力例
aws-cli/2.27.26 Python/3.13.3 Windows/11 exe/AMD64
aws configureで
AWS コンソールで IAM ユーザー作成 & アクセスキー取得
許可を設定→「ポリシーを直接アタッチする」
- AmazonEC2ContainerRegistryFullAccess
- AWSAppRunnerFullAccess
上記でユーザー作成したら、アクセスキーを取得します
AWS Access Key ID [None]: IAMで作成したアクセスキー(通常20文字)
AWS Secret Access Key [None]: 対応する秘密キー(40文字の長い文字列)
Default region name [None]: ap-northeast-1
Default output format [None]: json
ECRリポジトリを作成
aws ecr create-repository --repository-name fastapi-apprunner --region ap-northeast-1
“repositoryUri”: “xxxxxxxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/fastapi-apprunner”,
上記をメモ
Docker を ECR にログイン
aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin xxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com
実行後
Login Succeeded
Docker イメージにタグをつける(ECR用)
docker tag fastapi-apprunner xxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/fastapi-apprunner
Docker イメージを ECR に push!
docker push xxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/fastapi-apprunner