Azure Front Doorを使って複数のAzure App Serviceへパスベースルーティングさせる

いわさです。

App Serivceで複数のWebアプリを構成していて、同一ドメインでひとつはWordPress、もうひとつはカスタムBlazorアプリを構成したいシーンがありました。
同一ドメインで複数のサーバーへ転送する場合はAzure Front DoorかAzure Application Gatewayを使って、パスベースでルーティングルールを設定する方法が考えられます。

本日はAzure Front Doorによるパスベースルーティングを試しました。

Azure App Serviceの用意

PHP7.4ランタイムのApp Service Linuxを2台用意し、FTPでルートディレクトリに以下を配置しておきます。
本題ではないのですが、Azure Front Doorを経由した場合のクライアントIPアドレスとx-forwarded-forヘッダーの挙動を確認しておきたくて、確認用のスクリプトにしています。

index.php

<?php
echo("SERVER_NAME: ".$_SERVER["SERVER_NAME"]."<br />");
echo("SERVER_ADDR: ".$_SERVER["SERVER_ADDR"]."<br />");
echo("REMOTE_ADDR: ".$_SERVER["REMOTE_ADDR"]."<br />");
echo("HTTP_X_FORWARDED_FOR: ".$_SERVER["HTTP_X_FORWARDED_FOR"]."<br />");
echo("HTTP_CLIENT_IP: ".$_SERVER["HTTP_CLIENT_IP"]."<br />");
echo("HTTP_HOST: ".$_SERVER["HTTP_HOST"]."<br />");
echo("HTTP_X_CLIENT_IP: ".$_SERVER["HTTP_X_CLIENT_IP"]."<br />");
?>

まずは、App Serviceにデプロイして確認してみます。
App Service1は期待どおり表示されています。

App Service2も期待どおり表示されています。
ちなみに、App Service1と2は同一のApp Serviceプラン上に構築したリソースになります。

120.51.74.235は今回の検証に使った接続元端末のパブリックIPアドレスになります。

Azure Front Doorの用意

Azure Front Doorを新規作成し、構成を行っていきます。
フロントエンドホストの追加ではホスト名といくつかのオプションを設定します。
ロードバランシングをした際にスティッキーセッション動作をさせたい場合はセッションアフィニティを有効にすると良いです。

今回はルールベースのルーティングだけするのでどちらでも良いです。
WAFも今回は特に検証予定がなかったので無効にしています。

バックエンドプールです。
ここで、先程作成したApp Service1とApp Service2をそれぞれバックエンドプールとして追加します。
正常製プローブはヘルスチェックのことですが、ここではデフォルトのままにしています。

さて、次がルーティング規則の設定です。
ここで、どういうパスの時にどのバックエンドプールへどういうURLで転送/リダイレクトさせるかを設定します。

今回は、http://hoge/であればApp Service1へ、http://hoge/iwasa2であればApp Service2へ転送させたいと思います。
ベースのルールはバックエンドプールにApp Service1を指定します。

２つ目のルールはiwasa2にパスが一致する際に、バックエンドプールをApp Service2で指定します。

Azure Front Doorの構成が完了したらアクセスしてみましょう。
ルートパスは期待どおり、App Service1のコンテンツが表示されました。

クライアントIPアドレスが先程と違いますね。
147.243.5.181になっています。

これはAzure Front DoorのIPアドレスを指しているものと思います。
本来のアクセス元であるエンドユーザのIPアドレスはx-forwarded-forヘッダーに格納されていることを確認することが出来ました。

ホスト名などはAzure Front Doorの影響を受けずにそのまま利用出来そうですね。

つづいてApp Service2ですが、404 Not Foundになりました。
これはApp Service2へリクエスト転送はされていますが、転送先でパスiwasa2のリソースを検索してしまうためです。

回避するために２つ目のバックエンドプールのルーティング規則を更新します。
URLの書き換えを有効にし、カスタム転送パスを設定しましょう。

URL書き換えのパターンは非常に多いと思いますが、ここではシンプルに固定のカスタムパスを設定しました。
より細かい設定をするケース（たいていの場合必要だと思いますが）の場合は以下も参考にしてください。

ルール更新後、もう一度確認してみます。

振り分けされていることを確認することが出来ました。
良かったです。

さいごに

本日はAzure Front Doorを使って、複数のバックエンドアプリケーションをひとつのドメイン配下で扱う方法を構成してみました。
Azure Front Doorを採用する前にAzure Application Gatewayと比較してどちらを採用するべきかについては確認したほうが良いです。
今回の目的であればApplication Gatewayも採用可能です。
バックエンドがApp ServiceではなくてVNET内のプライベートインスタンスなどであれば、逆にFront DoorではなくてApplication Gatewayが必須になります。（Azure Front Door + Application Gatewayのパターンもある）

Application Gatewayを使ったパターンについてもいずれ記事にしたいと思います。