LinuxのApacheからAzure Web Appsへ移行しています。リバースプロキシを使用するように設定された特定のURL(mysite.com/blogおよびその下のもの)コンテンツが実際に別のサービスから来ていることを知らないWebアプリケーションを使用したAzureのリバースプロキシ
私はWeb Apps(IIS上で動作します)内でこれを行うことはできますが、これを行う方法に関するドキュメントは見つかりません。バックアップとして、私はWeb Appの前に別のサービスを入れています。
私はAzureでこれをどのように達成できますか?
更新:私は別のサービスを使用しようとしました - 機能。私のアーキテクチャは次のようになります。
これは本番環境で動作しますが、私は開発中に突っ込んでしまいます。 /blog
は、エントリポイントによっては動作しない場合があります。試してみると、私たちのDNSはmysite.com
がmysite-proxy.azurewebsites.net
を指しているように設定されているため、ユーザーがヒットしたURIはすべて動作します。しかし、devでは、トラフィックマネージャから/blog
にアクセスし、が存在しないというWebapp上で/blog
にルーティングすることができます。もちろん、webapp上で直接/blog
に行くと同じ問題が発生します。これらの例を図の右側に表示しようとしました。
Webアプリケーション自体が/blog
プロキシ処理を処理できるように解決策を見つけたいと思います。それで、既存のソリューションと比較してスピードとコストのトレードオフの価値があるかどうかを判断できます。
- MSFT –
はいファンクション・プロキシが機能アプリではなくウェブアプリのトップでサポートされている私の更新をご覧ください。 1つの選択肢は、すべてのトラフィックがプロキシを備えた機能アプリケーションを通過するようにすることであり、要求がプロキシから来なかった場合、プロキシへのリダイレクトを行うようにWebAppを変更することです。受信ヘッダーが存在しない場合は、ProxyとWebAppとWebAppの間に共有キーヘッダーを追加してリダイレクトできます。はい、私はあなたがこれを動作させるためにあなたのWebアプリケーション上でコードを変更する必要があることを理解しています。 –
基本的には、EasyAuth、共有ヘッダーなどを使用してWebAppバックエンドを保護する必要があります。そのため、WebAppへのリクエストはプロキシからのものにすぎません。 –