フロントエンドはreact、バックエンドはlaravelっていうよくあるSPA構成をAWSのECSにデプロイするのはかなり大変だった。
慣れていればかんたんなのだろうが、不慣れなうちはみるみる工数が溶けてしまう。
本当にECSにデプロイすべきなのか検討してほしい。
開発環境の構築はかんたん。dockerのノリでECSを触ると火傷するよ
開発環境は、もちろん出来合いのdocker-composeでかんたんに構築できる。フロントエンドはyarn startとかyarn devとかでlocalhostにサーバーが立ち上がるし、バックエンドはlaravelなので特に難しいところはなにもない。
ECSにデプロイする
ECSにデプロイするためには、フロントエンドもバックエンドもビルドして固めないといけない。
laravelを含めたバックエンドのビルド
よくある開発用のdocker-composeファイルだと、ローカルのソースフォルダをそのままbindしているが、ビルドするときはDockerFileでコピーしないと中身が空っぽになる。
そして、composer installなどの初期化設定もすべてDockerFileのコマンドに含めないといけない。
サンプルコードはないので自分で書く必要がある。
CORS、セッション管理
ECSは複数のEC2に分散されるため、laravelのセッション管理をステートレス、かつセッションドメインを明示しないと動かない。Sticky sessionにする方法もあるらしいが、開発環境はコンテナ１個なので動かなくなることが多いよね・・
フロントエンドのデプロイ先,APIの接続先。
フロントエンドも、もちろんビルドしてデプロイしないといけないのですが、nginxでホストするならこれもイメージを作ってビルドする必要がある。もしくは、お手軽にS3+CloudFrontの構成を作る必要がある。Amplifyという手段も。
そんなことは開発中は何も考えてなかったので、インフラの構築のこともちゃんと考えておこう。
そして、開発中は同じlocalhostだが、ECS環境だと別のドメインになったりする。ドメインが変わってもちゃんと動くのか確かめておかないと、CORSでブロックされてハマってしまう。
WAF,ALB,VPC,RDSも工数泥棒
本番環境なら、WAF,ALB,VPC,RDSもしっかりセキュリティを考えて構築しないといけないだろう。どこかに問題があると即・繋がらないになってしまうので、切り分けが大変。AWSに精通している人なら問題ないだろうが、不慣れな人にやらせるとあっという間に一ヶ月ぐらい工数が溶けてしまう。
結論
EC2上にdocker-composeで建てるほうがよっぽど楽です・・・
アクセスが増えてきて、1台のEC2でさばけなくなってからECSコンテナ管理へ移行しても、遅くないと思う。エンジニアの貴重な工数を何に使うのか、ECSの構築は恐ろしく工数が溶ける。
覚悟してかかってください。