今回はAWS ECSサービスに関する記事です。
Azure のコンテナサービス(App Service)をAWSへ移植するために必要な構成を解説していきます。
本記事はシリーズ構成の第四弾として、ECS ExpressModeの構築と、
接続周りを設定するところまで解説します。
※完成するリソースはFargateと同じです
前回記事はこちら⇩
Azure経験者がAWS ECSで同じ構成を作ってみる④ ～ECS ExpressMode展開～
実装内容
前回記事では、ECS Fargate(8-13) を解説しました。
- Route53
- IAMロール
- DynamoDB
- ECR
- S3
- IAMユーザー
- GitHub
- SEG
- ECSクラスター
ECSタスク定義ECS ServiceALB- DynamoDB項目追加
- ExpressModeで構築
今回はECS Fargateの代替としてECS ExpressMode(14)を設定し、
動作確認まで実施します。
本記事は前回第三弾の読者の方を対象とし、8,9,13は構築済の前提で進めていきます。
また、この手順では第三弾で構築した(10-12)までの構成が重複しますので、
視認性を向上するため事前に削除しておきましょう。
※同じリソースが再度作成されます
イメージは以下。
第三弾の構築手順で得られる結果と大差ありませんが、
ALBやAutoScaling部分の面倒を見てくれるのがExpressModeの強みです。
構築前の補足説明
本記事の手順に沿わない場合は、ExpressModeのデフォルト生成物で動作するよう、
あらかじめコンテナイメージや構成を工夫しておくことを推奨します。
筆者環境のようにDynamoDBとの連携、S3の静的Webサイトホスティングからの
APIコールなどが絡んでくると、まず初めにエラーの洗礼を受けると思われます。
各種構築
Expressモード
ECRを開いてExpressモードをクリックするといきなり作成画面になります。
この項目は作成に特化しており、生成物はクラスター配下のサービス定義へ格納されます。
つまり、Expressモードだからといって特別な感じではなく、
第三弾の作成方法で生成した場合と管理UIは同じということです。
(1) アプリをセットアップ
- タスク実行ロール：ecs-task-execution-role
- インフラストラクチャロール：新しいロールの作成
ECRイメージの設定方法は第三弾と同様です。
以下のようにセットしたら、「追加の設定」を開きます。
※筆者の手順を参考にしている場合、まだ作成は押さないようにしましょう（1敗）
(2) 各種設定
第三弾と大体同じ値を、それぞれの項目へ設定していきます。
- ■追加の設定
- ECSクラスター名：
ecs-sample-cluster(第三弾で作成したものを選択) - オブザーバビリティの名前：ecs-EXPressMode
- ECSクラスター名：
- ■コンテナ
- コンテナポート：
8080 - ヘルスチェックパス：
/health
- コンテナポート：
- ■環境変数1
- Key：DYNAMODB_TABLE
- Value：ecs-sample-messages
- ■環境変数2
- Key：AWS_REGION
- Value：ap-northeast-1
- ■タスクロール： ecs-task-role (第一弾で作成したものを選択)
(3) ハードウェア周りの設定部分
下へスクロールすると、ハード周りの定義箇所がありますので設定します。
コンピューティングは適当でも問題ありませんが、
筆者の提供しているコードは、ネットワーキングの設定がブレると動作しなくなりますので
やむなく設定していきます。
- ■コンピューティング
- CPU：
0.25 vCPU - メモリ：
0.5 GB - タスクの最小値：1
- タスクの最大値：1
- CPU：
- ■ネットワーキング
- ネットワーク設定をカスタマイズ
- VPC：デフォルトVPC
- サブネット：デフォルトサブネット３つ
- セキュリティグループ：ECS-SEG (第三弾で作成したものを選択)
これらを設定後、作成を押下します。
(4) リソース生成確認
これまでの手順通りに作業すれば、エラーが出ることなくあっさり構成完了します。
※自動生成されたリソースIDは、この記事を投稿する頃には消滅しているのであえて晒しています
(5) ExpressModeで作成後の静的Webサイト確認
ひとまずこの時点での、Webサイトの動作をチェックしてみます。
当然ですがAWSが自動生成したリソースと関連付けがないため、以下のようになります。
生成物との紐づけ
(6) Route53 の設定変更
第三弾で設定したAレコードのAliasを新しいALBのものへ更新します。
(7) ALBのリスナーポート変更
ExpressModeが用意してくれたHTTPS(443)は、筆者の環境にあっていませんので
HTTP(80)へ変更します。
以下を変更するだけです。
(8) ルールを編集
ExpressModeが用意してくれたルールは、コレまた筆者の環境にあっていませんので、
編集していきます。
ホストヘッダーを用意してくれていますが、
S3の静的ウェブサイトホスティングの値は全く考慮されていませんので、
とりあえず削除します。
条件が空だと次へ進めません。
そのため、雑に以下の値をセットします。
※業務環境を提供する場合や、ALBから複数のECSへルーティングしたい場合は、
もう少し設定値を厳密にしたほうが良いです。
- 条件：パス
- 値：*
(9) セキュリティグループを更新
ExpressModeが用意してくれたALB用のセキュリティグループと筆者環境は一致しませんので、
ここもチューニングが必要です。
ALB-SEG を追加します。
元からセットされているものは放置して問題ありません。
(10) 再び動作確認
ココまで設定を合わせて、ようやく第三弾と同じようにサービスが動作してくれます。
検証手順はここまで
ExpressModeを利用して嬉しいところ
ExpressModeを利用して構成した場合、
ECSのサービスを削除すると、以下もまとめて処分してくれます。
- ECSサービス
- ALB
- AutoScaling
- ACM
内部的にCloudFormationで展開していると想定していますが、
展開／削除の容易さに関して、各部品へアクセスしてメンテする手間が
簡略化出来るところが良かったです。
表にするとざっくり以下のような感じでした⇩
| 項目 | 通常ECS | Express |
| ALB作成 | 手動 | 自動 |
| Target Group | 手動 | 自動 |
| Listner | 手動 | 自動 |
| ACM | 自動(.on.aws) ※独自ドメインは調整 | 半自動 |
| Task Role | 手動 | 手動 |
| VPC | 手動 | 手動 |
| Subnet | 手動 | 手動 |
| SG | 手動 | 手動 |
| 環境変数 | 手動 | 手動 |
ExpressModeを利用して失敗したこと
以下は初回利用時、追加する設定を触らずに動かしてみたときの記録です。
筆者環境はコンテナポート8080で構成しているので、
ExpressModeのデフォルト設定のポート80による展開では
ヘルスチェックがうまく行かずに失敗してしまいました。
自動展開してくれるところが便利な半面、
ユーザーが定義した細かい仕様に対応しているわけではないところに注意が必要です。
本記事でもリソース展開後に、あらためて手動でチューニングをしています。
ExpressModeとは
本記事の検証により
Express = 簡易版 ではなく、
AWSが考える「最短で本番公開するためのECSの仕組み」
であることがわかりました。
Expressを使うべき人／使わない方がいい人
以上より、原則としてECSはExpressModeを利用して展開すべきと思っていますが、
筆者環境とは微妙にマッチしていませんでした。（手直し箇所が多かった）
そこも踏まえて、整理してみると以下の感じと考えます。
■Expressをおすすめできる方
- Dockerイメージはある
- まず公開したい
- ALBを意識したくない
■通常ECSがおすすめの方
- ALBやネットワークを細かく制御したい
- 独自構成が多い
- インフラまで含めて設計したい
関連記事のご紹介
シリーズ初回記事、各種準備と設計のご紹介
シリーズ2回目記事、主にGitHubの設定方法解説
シリーズ3回目記事、ECSデプロイして動作検証まで実施
コメント