2017-06-19 25 views
1

LinuxのApacheからAzure Web Appsへ移行しています。リバースプロキシを使用するように設定された特定のURL(mysite.com/blogおよびその下のもの)コンテンツが実際に別のサービスから来ていることを知らないWebアプリケーションを使用したAzureのリバースプロキシ

私はWeb Apps(IIS上で動作します)内でこれを行うことはできますが、これを行う方法に関するドキュメントは見つかりません。バックアップとして、私はWeb Appの前に別のサービスを入れています。

私はAzureでこれをどのように達成できますか?

更新:私は別のサービスを使用しようとしました - 機能。私のアーキテクチャは次のようになります。enter image description here

これは本番環境で動作しますが、私は開発中に突っ込んでしまいます。 /blogは、エントリポイントによっては動作しない場合があります。試してみると、私たちのDNSはmysite.commysite-proxy.azurewebsites.netを指しているように設定されているため、ユーザーがヒットしたURIはすべて動作します。しかし、devでは、トラフィックマネージャから/blogにアクセスし、が存在しないというWebapp上で/blogにルーティングすることができます。もちろん、webapp上で直接/blogに行くと同じ問題が発生します。これらの例を図の右側に表示しようとしました。

Webアプリケーション自体が/blogプロキシ処理を処理できるように解決策を見つけたいと思います。それで、既存のソリューションと比較してスピードとコストのトレードオフの価値があるかどうかを判断できます。

答えて

4

あなたはAzureの機能プロキシをチェックアウトすることがあります:ヘンリー・ハミド・サフィ@https://docs.microsoft.com/en-us/azure/azure-functions/functions-proxies

+0

- MSFT –

+0

はいファンクション・プロキシが機能アプリではなくウェブアプリのトップでサポートされている私の更新をご覧ください。 1つの選択肢は、すべてのトラフィックがプロキシを備えた機能アプリケーションを通過するようにすることであり、要求がプロキシから来なかった場合、プロキシへのリダイレクトを行うようにWebAppを変更することです。受信ヘッダーが存在しない場合は、ProxyとWebAppとWebAppの間に共有キーヘッダーを追加してリダイレクトできます。はい、私はあなたがこれを動作させるためにあなたのWebアプリケーション上でコードを変更する必要があることを理解しています。 –

+0

基本的には、EasyAuth、共有ヘッダーなどを使用してWebAppバックエンドを保護する必要があります。そのため、WebAppへのリクエストはプロキシからのものにすぎません。 –

関連する問題