このエントリは2021/03/22現在の情報に基づいています。将来の機能追加・変更に伴い、記載内容との乖離が発生する可能性があります。

標題の通りで、機能実験をやってみた。もちろん、Containerでnginxをプロキシに仕立てて、それをWeb App for Containerに載せてもよいし、API ManagementのGatewayを使ってもいい。もしVNet内のVirtual MachineからWebにアクセスさせたいなら、こういうやり方もある、という実験。

用意するもの

• App Service
  • ランタイムとしてASP.NET、.NET Core、もしくは.NET 5のいずれかを選択
• App Serviceの構成ファイル
  • applicationHost.xdt
  • web.config

構成

App Serviceインスタンス自体はランタイムを選択し、ふつうに作成する。インスタンスの作成が完了したら、App Service Editor （プレビュー）をクリックする。

クリック後、［移動］というリンクが現れるので、これをクリックすると、VS Codeのような、GitHub Codespacesのような画面が現れる（下図）。

[EXPLORE] の中で右クリックするとメニューが現れるので、[New File]を選択、新規作成するファイルの名前を指定する。ここで作成するファイルは以下の2個。

• applicationHost.xdt
• web.config

applicationHost.xdtは以下をそのままコピペしておく。このファイルは、IISのリバースプロキシ機能を有効にするためのファイル。

<?xml version="1.0" encoding="UTF-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.webServer>
    <proxy xdt:Transform="InsertIfMissing"
           enabled="true"
           preserveHostHeader="false"
           reverseRewriteHostInResponseHeaders="false" />
  </system.webServer>
</configuration>

以下はweb.configの例。rule要素でHTTPSを強制していたり、宛先にhttps://www.google.comを指定すると共に、Pathに指定したものをGoogle先生に渡すようにしている。

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="ForcedTLS" enabled="true" stopProcessing="true">
          <match url="(.*)" />
          <conditions>
            <add input="{HTTPS}" pattern="^OFF$" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
        </rule>
        <rule name="AccessTo..." stopProcessing="true">
          <match url="(.*)" />
          <action type="Rewrite" url="https://www.google.com/{R:1}" appendQueryString="true" logRewrittenUrl="false" />
          <!-- action type="Rewrite" url="https://{R:0}" appendQueryString="true" logRewrittenUrl="false" / -->
        </rule>
      </rules>
    </rewrite>
    <httpProtocol>
     <customHeaders>
        <add name="strict-transport-security" value="max-age=15552000; includeSubDomains; preload" />
     </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

URLの書き換えを司るモジュールの構成リファレンスは以下のURLにある。

URL Rewrite Module Configuration Reference
https://docs.microsoft.com/iis/extensions/url-rewrite-module/url-rewrite-module-configuration-reference

両ファイルを作成したら、App Service名をクリックしてドロップダウンメニューを開き、Open Kudu Consoleを選択する（下図）。

この操作で、Kudu Consoleが開く。site > wwwroot とディレクトリをたどると、先ほど作成した2ファイルが存在することを確認できるはず。

最後に、applicationHost.xdtを1個上のディレクトリに移動する。コマンドプロンプトで以下を実行する。

move applicationHost.xdt ..

これで構成は完了。App Serviceは再起動しておく。

動作確認

App ServiceのURLをブラウザから叩くと、www.google.comの画面が表示されていることを確認できる。

指定したパスもGoogle先生に渡すことができる。例えば、/search?q=Azureを渡すと、以下のような感じ。

この内容は、ふつうにGoogle先生に問い合わせた場合 (https://www.google.com/search?q=Azure) と同じ。

さらに、web.configのルールをコメント化されているものに置き換えると、Pathに指定したURLにアクセスすることもできる。以下はその例。

これで何ができそうか

App ServiceをPrivate LinkであるVNetに接続しつつ、別のVNetに対してVNet統合し、NAT Gatewayを組み合わせておけば、オンプレミスのノードはオンプレミスからではなく、Azureからインターネットに出ることが可能。具体的には以下のようなイメージ。

まとめ

他のBlogエントリでは、App ServiceのFTPを有効化する必要がある、というような記述を見ることがあるが、この方法ではFTPを有効化する必要がなく、構成はAzure Portal内で全て完結する点で少々異なる。

再度述べるが、今回の内容は機能実験に過ぎない。そのため、セキュリティなどは全く考慮しておらず、実運用にすぐに使えるわけでもなければ、おすすめすることもないので念のため。