今回はAWS ECSサービスに関する記事です。
Azure のコンテナサービス(App Service)をAWSへ移植するために必要な構成を解説していきます。
本記事はシリーズ構成の第一弾として、設計やIAM準備の部分を解説します。
Azure経験者がAWS ECSで同じ構成を作ってみる① ～基盤準備編～
構成図
モデル構成を提示します。
左のAzure構成を、AWS構成（右のイメージ）へ
変換します。
画像の通り、Azureで構成したほうが部品は少なく済みます。
ただコレだけで「コンテナ展開はAzureのほうが向いている」とは言えません。
AWS構成は複雑になる代わり、
部品を細かくチューニングできる
コンテナ周りは両クラウドそれぞれ一長一短とお考えください。
Azure ⇔ AWS の技術変換表
Azureではナチュラルに利用できていたものが
AWSでは個別定義が必要なケースがあります。
※代表的なものとして、コンテナのDNS名
以下の変換表に沿って実装していきます。
| Azure | AWS |
|---|---|
| App Service | ECS Fargate |
| Storage Account Static Website | S3 Static Website |
| Table Storage | DynamoDB |
| EntraID アプリの登録 | IAM User AccessKey |
| Managed Identity | IAM Role |
| App Service URL | ALB + Route53 |
実装内容
以下のサービスおよび機能の設定を行っていきます。
- Route53
- IAMロール
- DynamoDB
- ECR
- S3
- IAMユーザー
- GitHub
- SEG
- ECSクラスター
- ECSタスク定義
- ECS Service
- ALB
- DynamoDB項目追加
長くなるので記事を分割します。
今回は事前準備にあたる部分(1-5)を設定していきます。イメージは以下。
各種構築
Route53
サブドメインをAWSへ移譲し、今後ECSやS3を独自ドメインで公開できるようにします。
後でALBを利用するので、何かしらRoute53のドメインが必要となります。
本記事では新たにドメインを取得するのではなく、
元々持っているドメインへ「サブドメイン」を作成して、
今回の検証に利用します。
新たにドメイン取得するなら「サブドメイン権限移譲」は不要です。
クラウドSEとして
自分用ドメインをひとつ持っておくと
以下手順のように使いまわしが出来るので重宝しますよ！
■AWS内でのサブドメイン移譲設定 ～サブドメイン作成～
- 元のホストゾーン：
blog.addache.jp - サブドメインのホストゾーン名：
test.blog.addache.jp
※上記は筆者環境でのみ利用できるものです。
皆さまの環境へと置き換えてください - タイプ：パブリックホストゾーン
- ホストゾーン作成後、払い出された NSレコード を控えます。
また画像のようにDNSの有効確認を行うためのAレコードをひとつ作成しておきます。
※サンプルはaaa.test.blog.addache.jp です。
IPアドレスは適当な値(例：192.168.1.1)でOK。
■AWS内でのサブドメイン移譲設定 ～サブドメイン権限委譲～
続いて、元のホストゾーンへも設定を行っていきます。
- レコード種別：NS
- ホスト名：
test - 値：Route53ホストゾーン作成時に払い出された4つのネームサーバ
設定を行ったら、コマンドプロンプトなどで名前解決ができるかチェックします。
# コマンド例 GoogleのDNSへ問い合わせを投げる
nslookup aaa.test.blog.addache.jp 8.8.8.8
このように、応答が返ってきたらサブドメイン権限委譲成功です。
IAM ロール
ECSからAWSサービスへ安全にアクセスするためのIAMロールを作成します。
■コンテナ起動用 IAMロール作成
- IAMロール名：ecs-task-execution-role
- ユースケース：Elastic Container Service Task
Elastic Container Service の選択肢 - 管理ポリシー：AmazonECSTaskExecutionRolePolicy
(1) ロールを作成 クリック
(2) エンティティ／ユースケースの設定
(3) 許可の追加 (ECSタスク実行)
今回はシンプルに、前述した管理ポリシーを利用します。
(4) ロール名の設定
名前の設定だけ行い、他の部分は触らなくてOK。
■アプリが利用する IAMロール作成
- IAMロール名：ecs-task-role
- ユースケース：Elastic Container Service Task
Elastic Container Service の選択肢 - 管理ポリシー：AmazonECSTaskExecutionRolePolicy
※(1)(2) までは同じ手順です。記載割愛。
(3) 許可の追加 (DynamoDBアクセス)
今回はシンプルに、前述した管理ポリシーを利用します。
(4) ロール名の設定
名前の設定だけ行い、他の部分は触らなくてOK。
DynamoDB
AWSネイティブなNoSQLサービスである「DynamoDB」をデータベースとして利用します。
■テーブルの作成
- テーブル名：
ecs-sample-messages - パーティションキー：
id - オンデマンド
(1) テーブルの作成 を押下
(2) テーブルの初期設定
「パーティションキー」は後で変更できません。記述をお間違えなきよう。
「キャパシティモード」はデフォルト設定値がオンデマンドとなっていますが、
念のため確認します。
(3) 状態確認
作成したテーブルがアクティブ になることを確認します。
ECR
ECS設定に先んじて、コンテナイメージをPushする宛先である、ECRを構成します。
- リポジトリ名：
ecs-sample-api
(1) リポジトリを作成
この画面は用語が安定していませんので、文章で説明するのは控えます。
※サンプル画像を参照してください
(2) プライベートリポジトリを作成する
(3) 作成確認
S3 Web
今回はアカウントのリージョナル名前空間を利用しています。
バケット名の重複を気にせず作成できますので、
以下例のバケット名をそのまま使えます。
- バケット名：ecs-sample-web
- アカウントのリージョナル名前空間
index.htmlapp.js- API URLにALBのDNS名を設定 ※後で実施
(1) S3バケットの作成
(2) バケットの設定
アカウントのリージョナル名前空間(推奨) を選択します。
(3) htmlファイルの作成
ファイルを作成して作成したS3バケットへアップロードします。
【index.html】
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>ECS Sample</title>
<style>
body {
font-family: Arial, sans-serif;
background: #f3f6fa;
text-align: center;
margin-top: 80px;
}
h1 {
color: #1f4e79;
}
button {
padding: 12px 25px;
font-size: 16px;
cursor: pointer;
}
#result {
margin-top: 30px;
padding: 20px;
background: white;
display: inline-block;
min-width: 300px;
border-radius: 8px;
box-shadow: 0 0 5px rgba(0,0,0,.2);
}
</style>
</head>
<body>
<h1>Azure → AWS ECS Sample</h1>
<p>S3 Static Website + ECS API</p>
<button onclick="callApi()">API呼び出し</button>
<div id="result">
結果待ち...
</div>
<script src="app.js"></script>
</body>
</html>【app.js】
サンプルでは api.test.blog.addache.jp を使用しています。
実際に利用する際は、ご自身のドメイン名（または ALB の DNS 名）へ読み替えてください。
const API_URL = "http://api.test.blog.addache.jp/api";
async function callApi() {
const result = document.getElementById("result");
result.textContent = "通信中...";
try {
const response = await fetch(API_URL);
if (!response.ok) {
throw new Error(`HTTP ${response.status}`);
}
const data = await response.json();
result.innerHTML = `
<strong>${data.title}</strong><br>
${data.message}
${
data.accessCount !== null
? `<br><small>Access Count: ${data.accessCount}</small>`
: ""
}
`;
} catch (error) {
console.error(error);
result.textContent = "API接続失敗";
}
}(4) ファイルアップロード
アップロードに成功していることを確認します。
(5) 静的ウェブサイトホスティング
S3バケットのプロパティを開き、一番下までスクロールします。
編集を押下します。
有効にして、先程アップロードした
インデックスドキュメント [index.html] を入力します。
※エラードキュメントは必須ではありません
(6) アクセス許可の編集
[ブロックパブリックアクセス設定]
レ点を外します。
※通常は推奨されない設定ですが、
静的Webサイトホスティングを利用する場合必ず無効化
念入りに質問されますが、「確認」を入力して次へ進みます。
※念のため検証用のS3バケットへ、公開htmlコード以外は配置しないようにしましょう。
[バケットポリシーの設定]
続いて、バケットポリシーも編集します。
ポリシー欄へ以下を記入します。
※AWSアカウントIDはご自身の環境に合わせてください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicRead",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::ecs-sample-web-[AWSアカウントID]-ap-northeast-1-an/*"
}
]
}[現時点での静的ウィブサイトホスティング確認]
順序通りに進めていくと、S3プロパティの最下部にて
以下のように静的ウェブサイトホスティングのURLが発行されていますので、
クリックしてみます。
この状態だとアプリの設定がないので、APIは反応しませんが、
以下のようにブラウザが表示できるはずです。
Image Push編へ続く
このあとの手順は次の記事にて解説していきます。
またECSの設定とあわせて、本記事では以下の設定について解説いたしました。
- サブドメイン権限委譲 設定方法
- S3 静的ウェブサイトホスティング
関連記事のご紹介
シリーズ2回目記事、主にGitHubの設定方法解説
シリーズ3回目記事、ECSデプロイして動作検証まで実施
シリーズ4回目記事、ECS ExpressModeでデプロイして動作検証まで実施
コメント