タイトルの通り、個人的に Windows Containers を弄ってみて、気になった部分だけを少し調べました。調べ始めるきっかけは Cloud Services で Docker デプロイしたいってことだった気がします。
結局それはダメだったの、Azure Container Service の Windows 対応に期待してます。
Windows Server Containers は C: に Windows が必要
この制約は知りませんでした。Twitter でぶちぞう RD に教えてもらいました。
カーネルをホストと共有する関係上、決め打ちにならざるを得なかったのかしれません。当たり前という感じですが、Hyper-V Containers の場合はこの影響を受けません。
Windows Server Container hosts must have Windows installed to c:. This restriction does not apply if only Hyper-V Containers will be deployed.
Windows Container Requirements
Azure VM などに Windows Server 2016 をデプロイすると、デフォルトで C: にインストールされるので問題ないですが、この制約の影響を全力で受けそうなのが Cloud Services ですね。
Cloud Services では Windows が D: にインストールされているので、そこに依存している App Service の Windows Containers 対応は難しそうです。
コンテナのカルチャとロケール
既にパブリッククラウド向けにアプリケーションを開発している場合には影響しないと思いますが、地味に気になるのがシステムのカルチャとロケールです。それぞれで簡単に確認しておきました。
まずは Windows Server Containers を使って確認します。いつも通り docker run を使います。
docker run -it microsoft/windowsservercore powershell
Windows Server Containers を使って起動したコンテナの場合は、ロケールがホストと同じになるようです。つまり、開発環境では Japanese だけども、クラウドに持っていくと English に変わるということです。
次に Hyper-V Containers を使って確認します。--isolation=hyperv を付けるだけの違いです。
docker run -it --isolation=hyperv microsoft/windowsservercore powershell
Hyper-V Containers を使って起動したコンテナでは、ロケールはホストとは異なり英語になりました。名前の通り Hyper-V を使っているだけあって、通常の VM に近い挙動ですね。
ロケールは変更が出来ないようなので、アプリケーション側で依存しないように作る必要があります。
コンテナのタイムゾーン
いい加減に UTC と JST で失敗する人は少なくなってると思いますが、一応確認しておきます。一般的なクラウドサービスのタイムゾーンは UTC となっているので、依存するのはそもそも NG です。
文字化けしてますが Windows Server Containers と Hyper-V Containers 共にホストのタイムゾーンが反映されていました。開発環境では問題なくても、本番に持っていくと失敗するタイプなので注意しましょう。
要するに Azure App Service などの、ロケールやタイムゾーンが変更できない系 PaaS を使っているアプリケーションは、あっさりと Windows Containers でも動作しそうです。
