前回の準備編を乗り越え、いよいよ本番環境にLaravelをデプロイしていくわけですが、
これがまた、一筋縄じゃいかない。
今回は、実際にDockerやLaravelの構成で詰んだポイントをまとめていきます。
🐳 Dockerの罠
1. Laravelのログが出ない問題
本番環境でなにも表示されない…と思ったら storage/logs/laravel.log が書き込めてないだけ。
chmod -R 777 storage
chmod -R 777 bootstrap/cache
もちろんセキュリティ的には777は微妙だけど、まずは動かすこと優先で。
2. LaravelコンテナとDBコンテナの通信ができない
docker-compose.yaml の networks: がうまく設定されてなかった。
services:
app:
networks:
- laravel-net
db:
networks:
- laravel-net
networks:
laravel-net:
driver: bridge
→ 共通ネットワークに乗せないと、そもそも通信できない。
3. .envのキャッシュが鬼門
ローカルで php artisan config:cache しちゃったやつをビルド時にCOPYすると、
本番の環境変数が反映されない。
→ .envは本番用を別で用意＋キャッシュコマンドは本番で実行すること！
🛠 Laravel特有の落とし穴
1. APP_URLが違うとCookie破損
ログインできない現象、原因は APP_URL=http://localhost のまま本番に突っ込んでたこと。
APP_URL=https://apprentory.click
2. セッションとCSRFのドメイン一致
HTTPS設定後、CSRFやセッションでコケるようになった。
→ .envの SESSION_DOMAIN と SANCTUM_STATEFUL_DOMAINS をちゃんと設定！
SESSION_DOMAIN=apprentory.click
SANCTUM_STATEFUL_DOMAINS=apprentory.click
🧠 ハードウェアの壁にも泣かされた
ここまでソフトウェアの話ばかりしてきたけど、実は
EC2インスタンスのスペック不足にもめちゃくちゃ悩まされた。
Laravelコンテナがまともに立ち上がらない、MySQLが急に落ちる、CloudWatchに何も出てこない……
これ、実はメモリ不足が原因でした。
最初は t2.micro で始めてたんだけど、
swap も設定してない状態で Dockerコンテナ2個はさすがに無理があった。
# topコマンドで確認すると、常にメモリがギリギリ
そこで t2.small に変更したところ、
それまでの不安定さが嘘のように解消。
本番環境はケチらず最低限のリソース確保、大事！
😇 今回の学び（中編）
- Dockerネットワーク設計しないと通信できない
- .envはキャッシュしない、分けて管理が鉄則
- APP_URL、セッション周りは本番でちゃんと設定！
→ もう正直めちゃくちゃ疲れたけど、その分LaravelとDockerへの理解は確実に深まった。
次回、いよいよ最終回。HTTPS化・監視導入・公開までの仕上げ作業をお届けします！