今回はAWS ECSサービスに関する記事です。
Azure のコンテナサービス(App Service)をAWSへ移植するために必要な構成を解説していきます。
本記事はシリーズ構成の第三弾として、いよいよECS Fargateの構築と、
接続周りを設定するところまで解説します。
前回記事はこちら⇩
Azure経験者がAWS ECSで同じ構成を作ってみる③ ～ECS Fargate構築～
実装内容
前回記事では、Image Pushの部分(6-7) を解説しました。
- Route53
- IAMロール
- DynamoDB
- ECR
- S3
- IAMユーザー
- GitHub
- SEG
- ECSクラスター
- ECSタスク定義
- ECS Service
- ALB
- DynamoDB項目追加
イメージは以下。
長くなるので記事を分割します。
今回はいよいよECS Fargate(8-13)を設定し、
動作確認まで実施します。
イメージは以下。
今回はこれまで準備してきたものが一気につながっていきます。
構築前の補足説明
ECSのコンテナ、特にサービスとして起動したい場合は、
以下の概念を意識する必要があります。
Cluster
└─ Service
└─ Task
上記構成を満たさなければ、コンテナ起動という成功体験へ到達できません。
ECSは概念が少し多いため、最初は以下のように考えるとイメージしやすいと思います。
- クラスター ＝ 器（お皿）
- タスク ＝ 料理
- サービス ＝ 注文を受けて料理を提供する店員（ご提供はお皿単位）
例えば Desired Count を「2」にすると、
店員は常に料理を2皿提供し続けます。
1皿落としてしまっても、すぐに新しい料理を作って再び2皿の状態へ戻します。
各種構築
SEG
Azure App Serviceは「アプリケーション」をデプロイする感覚ですが、
AWS ECSは「ネットワークの中にコンテナサーバを配置する」感覚です。
そのため、Security GroupやALB、Target Groupなど、
ネットワーク構成を理解して初めてサービスが公開できます。
■ALB用セキュリティグループ作成
インターネットからのHTTP通信を受け付けます。
外部から直接アクセスされるのはALBだけです。
- SEG名：ALB-SEG
- インバウンド：TCP 80 0.0.0.0/0
- アウトバウンド：ANY
(1) セキュリティグループの作成
(2) ALB-SEG作成
今回はデフォルトVPCを利用します。
タグはセキュリティグループ名と同じ値で作成して、
リスト表示したときに判別がつくようにします。
(3) 正常作成確認
■ECS用セキュリティグループ作成
ALBからの通信だけを許可します。
インターネットからコンテナへ直接アクセスすることはできません。
※Source指定があるので、ALB-SEGを先に作成してください
- SEG名：ECS-SEG
- インバウンド：TCP 8080 Source：ALB-SEG
- アウトバウンド：ANY
(1) ECS-SEG作成
同じ要領で、ECS用のSEGも作成します。
インバウンドルールのソースはIP設定するのではなく、
先に作成を終えているALB-SEGのIDを指定します。
ECS Cluster
続いて、クラスターを作成します。
コレがないとサービス化の設定が完了できません。
※サービス定義の作成画面から呼び出すことも一応可能ですが、
ブラウザの別タブが開いたりして、わかりにくい手順となるので個別作成します
- ECSクラスター名：
ecs-sample-cluster - Fargateのみ
- その他はデフォルト
(1) クラスター作成の画面を開く
(2) クラスターを作成する
ほぼ名前を入力するだけです。
初回のクラスター作成時、ECSのサービスリンクロールを引き受けられない
というエラーが発生しました。
ただしIAM上ではロールが正常に作成されており、
失敗したCloudFormationスタックを削除して再実行すると成功しました。
初回利用時のロール作成・反映タイミングによる一時的なエラーだった可能性があります。
(3) 作成できたことを確認
ECSタスク定義
コンテナの箱に当たる部分である、タスク定義を作成していきます。
- タスク定義ファミリー：
ecs-sample - Fargate
- CPU：
0.25 vCPU - メモリ：
0.5 GB - タスクロール：ecs-task-role
- タスク実行ロール：ecs-task-execution-role
- コンテナの名前：webapi
- コンテナポート：
8080
(1) 新しいタスク定義の作成
(2) タスク定義の設定-1
タスクサイズはデフォルト値が少し大きめなので、以下のように縮小した値を指定します。
タスクロール／タスク実行ロールは第一弾で作成したロールを適切に付与します。
設定を終えたら、下へスクロールします。
(3) タスク定義の設定-2
赤枠部分を設定の後、
青枠を押下します。
(4) ECRイメージを選択
第二弾でPushしたイメージを、以下のように選択します。
(5) ECRイメージを選択
環境変数をふたつ設定します。
※後で追加することも可能ですが、本記事のシナリオに沿うならこの時点での追加を推奨します
- ■環境変数1
- Key：DYNAMODB_TABLE
- Value：ecs-sample-messages
- ■環境変数2
- Key：AWS_REGION
- Value：ap-northeast-1
設定値の入力は以上です。下へスクロールして右下の作成ボタンを押下します。
(6) タスク定義作成完了確認
正常に作成できたことを確認します。
ECS Service
サービス定義を作成することで、
WebAPIとして継続的にサービスを提供することが出来るようになります。
- ECSサービス名：ecs-sample-service
- クラスター：
ecs-sample-cluster - コンピューティングオプション：起動タイプ
- Desired tasks：1
- ヘルスチェックの猶予期間：60
- ALBのTarget Groupへ接続
(1) デプロイからサービス定義作成
先程作成したタスク定義をクリックして、デプロイを押下します。
(2) サービスの作成-1
サービス名や先程作成したクラスターを選択します。
(3) サービスの作成-2
必要なタスク、AZのリバランス、ヘルスチェックの猶予期間を設定します。
※検証用途で作成するだけなら、おおよそ以下で問題ありません
入力したら、「ネットワーキング」の折りたたみを開きます。
(4) サービス定義の作成-3 ネットワーキング
VPCやサブネットはデフォルトVPCのままで問題ありません。
重要なのは、先程デフォルトVPC所属で生成したECS-SEGをアタッチすることです。
また、デフォルト有効になっているパブリックIP のチェックは外さないようにしましょう。
一見不要に見えますが、Image PushしたECRへアクセスするために
パプリックIP、NATゲートウェイ、VPCエンドポイントのいずれかが必要になります。
本記事の検証手順はECSを動作させることを重要視しているため、
「パブリックIPを無効化のうえ業務相当構成とする」ことにはこだわっていません。
また上記の設定後は、同じ画面でALBを構成します。
ALBは個別作成も可能ですが、戻って紐づけを設定しないといけなくなるので
検証手順ではセットで構成します。
ALB
サービス定義作成画面の途中でALBも生成できます。
※こちらは別タブで作業したりしないので、扱いやすいです
- ALB名：ecs-sample-alb
- Internet-facing
- Listener：HTTP 80
- Target Group名：ecs-sample-tg
- Target Group：HTTP 8080
- Target type：
IP - ヘルスチェック：
/health
(5) サービス定義の作成-4 ロードバランシング
ロードバランシングの折りたたみを開きます。
設定項目多めですが、順番に埋めていけば問題ありません。
(6) サービス定義の作成-5 ターゲットグループ
スクロールしてターゲットグループも作成します。
ここまで設定したら、下までスクロールしてサービス定義の作成を押下します。
(7) サービス定義 作成確認
(8) 作成されたALBを開く
上記の画面でALBを作成するとデフォルトSEGが付与されますが、
そのままでは通信できないので、ALBの画面を開いてSEGの設定変更を行います。
(9) ALBへSEG設定
デフォルトSEGは外してOKです。
事前作成したALB-SEGが選択されていることを確認しましょう。
(10) SEGの設定確認
SEGの紐づけを変更できたことを確認します。
また青枠のDNS名は次の手順で選択するため、チェックしておきましょう。
※ALBが１台だけならコピペなど不要
Route53
作成したALBはそのままではDNS名的に使いにくいので、
あらかじめ作成していたホストゾーンでAliasを設定します。
- ホストゾーン名：
test.blog.addache.jp
※上記は筆者環境でのみ利用できるものです。
皆さまの環境へと置き換えてください - レコードの作成：Aレコード
ココまで来たら、一度動作チェックを行います。
先程登録したAレコードを直接打鍵してみます。以下のように応答があればOKです。
また、S3の静的ウェブサイトホスティングも改めてURLを開いてみます。
第一弾時点でErrorとなっていたAPI呼び出し結果も応答するようになっているはずです。
DynamoDBの項目作成
アプリは応答するようになりましたが、このままではDBを配置している意味がないので、
DynamoDBのテーブルへ項目を追加してみます。
{
"id": {
"S": "AzureToAWS"
},
"Message": {
"S": "Hello from DynamoDB!"
},
"Title": {
"S": "Azure → AWS ECS Sample"
},
"Version": {
"S": "1.0"
}
}以下のように、項目がひとつ増えていることを確認します。
この状態で、再度S3の制定ウィ部サイトホスティングを開き、
「API呼び出し」を押下すると、「AccessCount」がカウントアップされるようになります。
⇒DynamoDBとのR/Wが実行できている状態
検証手順はここまで
Azure App Service で構成していたコンテナサービスを、無事 AWS へ移植することができました。
Azure App Service とは異なり、AWS ECS には独自の設計思想があります。
「コンテナアプリケーションを公開する」という目的は同じでも、
- ネットワーク構成を意識する場面が多い
- パーツが細かく、構築手順が多い
- コンテナ単体ではなく、サービスという単位で管理／デプロイする
など、考え方の違いから単純な置き換えはできません。
一方で、AWSにはAzureと対応するサービスが数多く用意されており、
それぞれの役割を理解すれば同等のシステムを構築することが可能です。
本記事が、Azureエンジニアの方がAWSへ挑戦する際の参考になれば幸いです。
予告編
以下の内容も、気が向いたら記事化する予定です。
- Azure App Service を利用した同一構成の検証
- AWS App Runner を利用した同一構成の検証
（App Service に近い運用ができるマネージドサービスです）
ECSは柔軟性が高い反面、学習コストも高めでした。
次回は、よりAzure App Serviceに近い運用ができる AWS App Runner
でも同じ構成を検証してみたいと思います。
お楽しみに！
関連記事のご紹介
シリーズ初回記事、各種準備と設計のご紹介
シリーズ2回目記事、主にGitHubの設定方法解説
コメント