前からちょいちょいと情報が出ていた Web App for Containers の Windows 対応が Public Preview としてリリースされました。これで App Service は Windows / Linux で全て出そろった形になります。
基本的な情報は公式ブログと App Service Team のブログを読めば良いです。GAC や GDI など制限なしに扱えるようになるのがメリットとして挙げられてますが、Server Core というのだけは注意ですね。
対応しているイメージは LTSC 2016 限定なので、開発環境が 1709 や 1803 の場合は latest ではなく明示的にタグでバージョンを指定する必要があるので注意。
恐らくは本番は Windows Server 2019 がリリースされた時だと思っています。Semi-Annual Channel は使いにくいので、2019 になったタイミングで様々な恩恵を得られるはずです。
とりあえず実際に App Service を作成して試します。Web App for Containers の作成を行うと、新しく Linux と Windows が選べるようになっています。
公式ブログにあったように App Service Plan は Windows Containers 用に Premium Container というプランが新しく追加されています。Premium V2 が Dv2 系だったのに対して、Premium Container は Dv3 です。
Premium V2 よりもメモリが倍以上になっています。Windows Containers はメモリを食うので仕方ないですが、裏側が Hyper-V Containers になっている気もします。
気になる価格ですが、8 月中は無料になっているみたいなのでまだ公開されてなさそうです。9/13 から 50% 引きのプレビュー価格が始まるようです。
コンテナイメージの設定は Linux と同じです。ACR / Docker Hub / その他が選べます。
CI/CD の場合は例によって Docker Image だけ入れ替えれば良いので楽です。
設定時に対応していないベースイメージかどうかの検証を行ってくれるので、間違って 1709 や 1803 のイメージを設定するような事故は起こりにくそうです。
設定完了後、デプロイ自体は 20 秒ぐらいで完了しますが、それからコンテナが立ち上がってページが見えるようになるまで数分かかります。地味に時間がかかるのが罠です。
コンテナの起動中は以下のようなページが表示されるので、本番で運用する場合は別スロットを使ってスワップが必要になりそうです。
起動処理は Docker Image の pull も行っているので、キャッシュが効くイメージを使うと改善します。
数分待つとアプリケーションが立ち上がります。普通の ASP.NET アプリケーションが動きました。
Docker Image を作るのは AppVeyor や VSTS を使って行えば、簡単に CI/CD が組めるのはメリットです。規模が大きくなって AKS に移行する場合も、同じ Docker Image を使えるので楽です。
ちなみに Kudu はちゃんと生きています。Debug Console を使うと Docker のログを簡単に確認できるので便利です。Log stream は開いておかないと見れないですが、こっちはいつでも確認できます。
ただし Process Explorer や Site Extension はほぼ無意味なので、使うことは少ないでしょう。
Windows Containers な Web App for Containers は最初から Deployment Slot が使えます。
Linux の時と同様に、デプロイに関しては Deployment Slot を使うのはほぼ必須でしょう。
スワップを実行すればスロットが入れ替わってくれますが、今の実装ではスワップ実行時に差分が無くても必ずコンテナが再起動してしまうようで、全く持ってメリットがありません。
普通は再起動しないので、今後改善されるとは思いますが、現時点では本番向けには使えませんね。
Linux のように SSH は使えませんが、代わりに Win-RM を使って実行中のコンテナに入って操作することが出来ます。On にすると PowerShell を使ってログインできます。
実行中のコンテナにログインする必要をほぼ感じないので、正直使うことはないかなと思っています。むしろ使ったら負けだと思っています。
通常の App Service では実行できなかったアプリケーションも、Windows Containers を使うと制約がほぼ無くなるので移行パスとして良い選択肢になるかと思います。AKS は流石に大げさというケースも多いはず。
