Azure Functions は Premium V2 / V3 や Premium Consumption を使うことで Regional VNET Integration を有効化しつつ、更に Service Endpoint や Private Endpoint で Azure リソースへの制限が行えますが、同時に作成されるストレージアカウントはパブリックにする必要があります。
そして以前に書きましたが、これまで Private Endpoint を使う場合には Subnet への Service Endpoint の追加や、完全にストレージアカウントを分ける必要がありました。ファイル共有のマウントは Web Worker 単位で行われるので、ある意味仕方ない挙動とも言えます。
このストレージアカウントにはファイル共有や Function Key などの動作に必要なファイルが含まれていて、全体を Private Endpoint で制限していてもここだけ開いているのは気になる人もいるでしょう。
この辺りの制限を取っ払う話が 8 月の Azure Functions Live で予告されていましたが、10 月の Live で Early Preview として公開されたことが発表されました。
要するにファイル共有のマウントも VNET 経由で行えるようになったという話のようです。Regional VNET Integration は Windows の場合はプロセス単位のはずなので、その辺りを拡張したのだと思われます。
ドキュメントが公開されていますが、Early Preview の名に恥じない制約の多さです。現在は West Europe の Windows Premium Consumption でのみ利用が可能になっています。
Private Endpoint がメインで扱われていたように思いますが、Service Endpoint で制限しているストレージアカウントに対しても同じように動作します。ファイル共有が VNET 経由になったというのが肝のはずです。
Premium V2 / V3 でも使えそうな気配はありますが、今回は Premium Consumption でのみ試しています。
とりあえず West Europe に Premium Consumption な Azure Functions と VNET をデプロイし、Regional VNET Integration の設定や Private Endpoint の追加などを行っていきました。
ストレージアカウントへの Private Endpoint は Blob と File に対して追加します。個別に追加しないといけないのは若干のめんどくささを感じますが、命名規約に気を付けて追加します。
設定後はこのままだと Web Worker がストレージアカウントへアクセス出来ないため、以下のように Azure Functions へのアクセスは全く行えない状態になります。
エラーメッセージは度々変わりますが気にしないでください。この状態では Kudu へのアクセスも行えないので、Azure Portal 上でも色々なエラーが出ます。
ここで App Settings に今回追加された WEBSITE_CONTENTOVERVNET というキーを追加します。名前の通り Azure Functions のコンテンツを VNET 経由で参照するための設定になっています。
Early Preview なので若干の不安定さはありますが、設定を追加して再起動を行うと Kudu へのアクセスが復活し、ファイル共有に使われているエンドポイントが Private IP になっていることが確認できます。
設定しても上手く動作しない場合には、別の Tier への Scale up を行って VM を切り替えると上手くいくことがありました。分かっていましたがまだまだ不安定です。
ここで適当に作成しておいた HttpTrigger を実行すると、Function Key での認証を行って実行できることが確認できます。Blob へのアクセスが行えない場合は、Function Key が取得できないので落ちます。
Regional VNET Integration と Private Endpoint をフルに利用したアーキテクチャの場合に、宙ぶらりんになっていた Azure Functions のストレージアカウントがやっと制限することが出来るようになりそうです。
これまでのようにストレージアカウントを分ける必要もないので、Private Endpoint を使いやすくもなったかなと思います。使う場面は少ないかもしれませんが、突っ込まれるポイントを潰せるのは良いことです。
