自宅で Windows Server 2016 用として動かしていた Intel NUC を流用して、Windows 10 Pro をインストールし直し Azure Functions Runtime の環境に作り変えました。
Windows Server 2016 より Windows 10 Pro の方が FCU が扱いやすいので、個人的にお勧めしてます。ドキュメントには Creators Update と書いてましたが、FCU でも問題なく動きました。
インストールの詳細な手順はドキュメントに任せて、自分がはまった部分だけ軽く書いておきます。
Azure Functions Runtime をインストールして、セットアップを行っている途中に SQL Server と接続する必要があります。ドキュメントには書いてないですが、TCP を有効にしないと繋がらないみたいでした。
サーバー名も最初 localhost や .\SQLEXPRESS など試行錯誤しましたが、SQL Browse サービスが動いてないので名前付きインスタンスは TCP で使えず、結局マシン名だけで良いという結論でした。
書いてある通りに sysadmin の権限を持ったログインを作っておく必要があります。データベースの prefix は空っぽで問題なかったのでそのままにしました。
後は設定を順番にポチポチしていけばはまることなく完了します。最後にポータルを開けば完了です。
Function Portal は Windows 認証を使っているみたいなので、Windows へのログインユーザーとパスワードで入れます。Windows 認証をアプリではあまり使ったことないですが、地味に便利。
ログインすると、Azure Portal っぽさある画面になります。
書いてある通りに、最初にサブスクリプションを作成します。将来的には Function の上限をサブスクリプション単位で指定できるのかもしれないですが、今は単なる入れ物っぽいです。
選べる項目も DefaultPlan しかないので、適当に名前を付ければ OK です。
ローカルマシンに対する処理なので、一瞬で作成などは完了するのが新鮮です。
サブスクリプションを作成したら Function App を作成します。この辺りからは普通の Azure Functions と変わりないですが、作成時に Function Runtime のバージョンを選べます。
.NET Framework を選んだ方が選べるトリガーが多いですが、例によって Server Core で実行されるので多少重いです。.NET Core の方は Nano Server なので有利ではあります。
ちなみに HttpTrigger 系はありません。なので多少デバッグが行いにくいですが、大体の場合は TimerTrigger で動作を確認すればよい感じです。
実際に TimerTrigger な Function を作成すると、いろいろと興味深いログが出力されています。
今の App Service のように ACL でサンドボックスを頑張るのではなく、Docker を利用して環境への依存を減らしつつ、Hyper-V Containers を使った高度な分離まで実現出来ているようです。
同時にインストールされる Command Pronpt ショートカットを管理者として起動すれば、Docker コマンドを使ってもうちょっと中身を詳細にみることが出来ます。
Creators Update を対象としているので、FCU からの軽量化されたイメージが使えていないのは残念ですが、Azure Functions Runtime に App Service の未来を見た気がしました。
Windows Containers ベースの App Service への期待が個人的に高まっています。
