しばやん雑記

ASP.NET Core とメイドさんが大好きなフリーランスのプログラマーのブログ

新しい Azure App Service の VNET Integration を試した

App Service の VNET Integration は Gateway が必要となる Point to Site VPN を使っていましたが、去年にプレビュー公開された新しい VNET Integration は Gateway 無しで VNET に参加できるようになってます。

新しい VNET Integration については公式ブログとブチザッキを参照してください。

これまで不可能だった Service Endpoint を経由した通信も行えるようになります。ExpressRoute は詳しい人がいつかは試してくれるのではないかと思うのと、そもそも環境の用意が無理なので放置します。

今頃になって新しい VNET Integration を触ってみようという気になったのは、公式ブログにこっそりと以下の文言が追加されていたからです。

This feature is in Preview in all public regions.

最初はリージョン限定になっていたはずなので、こっそりと更新するのは止めてほしいですね。

気を取り直して実際に App Service を作成して既存の VNET に参加させるわけですが、利用可能な Scale unit が限定されています。具体的には Premium V2 が使える新しい Scale unit じゃないと有効に出来ません。なので App Service 作成時に Premium V2 を指定して作りましょう。

作成した App Service の VNET Integration 設定画面を開くと、ボタンが増えているので分かりやすいです。

f:id:shiba-yan:20190118001559p:plain

Preview の付いている方を選んで VNET と Subnet を指定していくわけですが、例によって App Service 用に新しい Subnet が必要なので適当に作成します。

既に適当に作成しておいたので、既存の Subnet を指定して VNET に追加します。

f:id:shiba-yan:20190118001614p:plain

追加後は 1 度 App Service が自動的に再起動されるみたいです。このあたりはまた謎の技術によって実現されているっぽいので実際の仕組みが気になりますが、外から窺い知ることは難しそうです。

たったこれだけで VNET への参加が完了します。一瞬で終わりました。

参加した VNET 内での通信

確認のために別の Subnet 上に IIS が動いている VM を適当に用意したので、作成した App Service をリバースプロキシとして設定して通信が行えているのか確認してみます。この確認方法に特に意図はなくて、単に確認用のアプリを作るのが面倒だっただけです。

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="VM" stopProcessing="true">
          <match url="vm/(.*)" />
          <action type="Rewrite" url="http://10.0.0.4/{R:1}" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

DNS 周りに関しては詳しそうなぶちぞう RD に任せるとして、とりあえず Private IP を直指定で行きます。普段は VNET を使う機会が本気でないので、このあたりは良くわかってません。

リバースプロキシを作成したので、ブラウザからアクセスして確認します。ちゃんとページが表示されるので、App Service から VM への通信はちゃんと行えています。

f:id:shiba-yan:20190118002616p:plain

ちなみにこの状態でスケールアウトで台数を増やしても問題ないです。ASE みたいに時間がかかるといった罠はないので、GA した後には安心して使うことが出来そうです。

IIS 側ではログを吐くようにしているので、アクセスしてきた IP が確認出来ます。この時は 5 台にスケールアウトしていたので、ちゃんと 5 つの IP からアクセスされたログが残っていました。

f:id:shiba-yan:20190118002749p:plain

Scale unit 共通の Outbound IP ではなく、Private IP からのアクセスというのも確認出来ました。この挙動は当然といえますが、Outbound IP は問題になってくることが多いので確認しておいて損はないです。

Service Endpoint 経由での通信

次は Service Endpoint を使った接続を Storage で試しました。これまでの App Service では不可能だったので、一応確認しておこうと思いました。App Service を VNET に入れた時に一番使いたい機能でしょうし。

適当に Storage を作成して、Service Endpoint を有効化しました。App Service が入っている Subnet を追加するだけなので、こっちも設定は一瞬で終わりました。

f:id:shiba-yan:20190118001624p:plain

先ほどの VM を使った方法と同じように、Blob へのリバースプロキシを追加して通信が行えるかを確認しました。これもまた一番簡単な確認方法だったからという理由です。

以下のような URL Rewrite ルールを作成して、Blob を読み込むようにしています。

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Storage" stopProcessing="true">
          <match url="blob/(.*)" />
          <action type="Rewrite" url="https://serviceendpointtest1.blob.core.windows.net/images/{R:1}" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

予め Blob には適当な画像をアップロードしておいたので、これもまたブラウザから確認しました。

f:id:shiba-yan:20190118002626p:plain

この状態で Service Endpoint から Subnet を削除すると表示出来なくなるので、ちゃんと Service Endpoint 経由で通信出来ていることが確認できます。今回は Storage で試しましたが、Service Endpoint に対応しているサービスなら問題なく使えるはずです。

かなりいい感じに使える新しい VNET Integration ですが、GA は今のところ mid-year of 2019 を目標としているみたいなので、残念ながら少し時間がかかりそうな雰囲気です。