2023.11.07
ECS・ECRを使った本番環境およびステージング環境の構築方法について
こんにちは。EDX推進部の村上です。
こちらの記事にて、laravelプロジェクトのdocker環境によるローカル環境開発から、ECSの構築、本番環境とステージング環境のCI/CDの構築まで本章で複数回に分けて記載していきたいと思います。
目次
構築手順
・ECSへのCI/CD構築 ※後日記事を記載します
構成図
最終的な構成は以下のように構築します。
こちらの構成が完成すれば、開発と本番環境へのデプロイは以下のようになります。
開発の流れについて
- ローカル環境のdocker上で開発を行う
- 開発したソースコードをgithubにプッシュし、developブランチへマージを行う
- Dockerイメージがコピーされ、DockerイメージがECRに保存される
- ECRに保存されたイメージをもとに、ECSのタスクへデプロイされる
- デプロイが完了次第、ステージング環境のプログラムが最新化される
本番環境への反映方法について
- ステージング環境で動作確認ができれば、developブランチからmainブランチへマージを行う
- 開発の流れの３～５と同じデプロイが行われ、本番環境が最新化される
といった形で比較的簡単にステージングと本番環境へのデプロイが可能です。今まではAWSのCodeStarを使ってCI/CDを構築していたのですが
CodeStarを使うメリット・デメリット
- コンソール上からテンプレートを選ぶだけで簡単にCI/CDの環境が構築できる
- コストは安い
- Fargateが使えない
- Docker環境を作る場合はかなり大変
ECS・ECRを使うメリット・デメリット
- ECSのコンテナオーケストレーションによるコンテナ管理が簡単にできる
- 負荷分散の対策が簡単にできる
- Dockerを使うことにより、開発環境から本番環境まで環境を統一することができる
- デプロイ時、シームレスにタスクを切り替えることができる
- Fargateを使用することができ、ホストマシンを意識した保守が不要
- CI/CDの環境は独自で作る必要がある
- fargateを使う分、料金は高い（codestarを使っているときより1.5倍ほど高くなる
ECS・ECRを使ったインフラ構築はコンテナ管理によるアプリケーション開発に集中できるというところが最大のメリットだと思います。
CodeStarを使ってEC2で開発を行っていましたが、本番とステージング環境ではライブラリのバージョンが異なりエラーになってしまうなど環境依存によって時間がかかってしまっていたものが、Dockerで環境を統一できるのでライブラリのバージョン違いによる不具合がなくなります。また、本番環境適用時には、現行で動いているタスクと、デプロイしているタスクをALBで切り替えるだけでよいので、デプロイによるダウンタイムは限りなく０に近くなります。
料金が価格なってしまうデメリットはありますが、それ以上のメリットのほうが大きいので順次ECSの環境へ切り替えていきたいと思っています。
組織課題を一緒に解決していただける方、リユース事業を通じて新しいサービス開発をしたい方、下記募集ページからご応募お待ちしております。
関連ニュースはこちら
-
2023/11/07
-
2023/11/07
-
2023/11/07