こんちくわ。
インフラデビューから5時間が経過した屍人です。
最近、社内システムが乗っかっているEC2上に、新たにWebアプリを追加する話が出てきました。新たにWebアプリを別ポートに構築し、アクセス用のパスベースルーティングを設定する流れです。
ただ、インフラ担当者がタコピーの原罪を観たショックで病んでしまい、私が巻き取る事に。
てなわけで自分の環境を使ってパスベースルーティングの手順を雑に検証し、雑にまとめます。
役に立ったらいいねください。
構成
通常は複数のEC2へそれぞれALBで振り分けたりするとおもいますが、今回は単一のEC2に向けて、ポート番号だけ変えるという感じです。まあ手順にあまり違いはありません。
Aアプリ・Bアプリを同じEC2インスタンス上に構築し、以下のようにルーティングします：
- デフォルト：Aアプリを表示（ポート3000）
- /goriraパス：Bアプリを表示（ポート3001）
1. EC2の用意
EC2は最低限の設定でテキトーに構築します：
・SSHアクセス用のキーペア設定
・sshでつなぐためのセキュリティグループの基本設定
・OSイメージはAmazon Linux
・インスタンスタイプはとりあえずt2.micro
2. ポート3000, 3001用のセキュリティグループを設定
公開アプリへの接続を許可するためのセキュリティグループを作成します。
インバウンドルールにポート範囲3000・3001を指定し、EC2のセキュリティグループに追加します。
これでEC2のポート3000と3001へのアクセスが許可されます。
3. EC2内にWebアプリを用意
公開するアプリをEC2に2つ用意します。とりあえず私のGitHubからNuxtプロジェクトをクローンしました：
- UIライブラリ勉強用に作った自己紹介サイト
- GitHub Copilotに作ってもらったゴリラのサイト
これらをNodeサーバーで各ポート上に起動するように設定します。今回はPM2を使用して起動します。
4. ターゲットグループの作成
「ロードバランシング → ターゲットグループ」から2つのターゲットグループを作成します。
どちらもターゲットは先ほど作成したEC2を指定しますが、ポート番号にはそれぞれ3000と3001を指定します：
ポート3000向けターゲットグループ：
ポート3001向けターゲットグループ：
これで、ポート3000と3001に転送するための2つのターゲットグループが作成されました。
この場合って一つのターゲットグループにまとめられたりするんですかね？わからんけど。
5. Application Load Balancer(ALB)の作成
「ロードバランシング → ロードバランサー」から新規ALBを作成します：
今回は検証なので、リスナーはHTTPのみ追加します。デフォルトアクションには先ほど作成したポート3000向けのターゲットグループを指定します：
この時点でアクセスすると、ポート3000で起動している自己紹介サイト（Aアプリ）が表示されます：
嘆かわしい見た目ですね。
6. ALBにパスベースのルーティングルールを追加
作成したALBの「リスナーとルール」タブから、「ルール」を選択します：
「ルールを追加する」を選択します：
「条件を追加」で「パス」を選択します。:
ここがパスベースルーティングの要です。
パス条件として「/gorira/*」を指定します：
＊画像だと/goriraですが、/gorira/*が正解です。
条件にマッチした場合の転送先を、先ほど作成したポート3001用のターゲットグループに設定します：
最終的に下記のようなリスナールールの構成になりました：
これで以下のルーティング設定が完成です。：
- デフォルト：ポート3000（自己紹介サイト）
- /gorira/*：ポート3001（ゴリラサイト）
7. 動作確認
「/gorira/」パスでアクセスしてみると、ちゃんとゴリラのサイト（Bアプリ）が表示されました：
まとめ
AWSでパスベースのルーティングを実現するには、ALBのリスナールールにパス条件を追加するだけでOKです。
ただし、同一EC2内でのポート分けなら、Nginxなどでリバースプロキシを設定するのもスマートです。
おわり。
おうちに帰りたい