Windows Containers を使っていて非常に悩ましいのが OS バージョンですが、最近は Multi-arch が使われているのでホスト OS のバージョンから適切なものを自動で利用してくれます。
Multi-arch の詳細は Docker 公式ブログを読めば大体理解できるはずです。
最近はちょいちょい Server Core や Nano Server に対応したイメージを見かけますね。
イメージに含まれているプラットフォームを確認する方法も用意されているので、例えば .NET Framework 4.7.2 の SDK イメージの情報を確認したい場合には以下のコマンドを使います。
docker run --rm mplatform/mquery microsoft/dotnet-framework
実行すると、含まれているプラットフォームの一覧が出力されます。
Windows Server の LTSC 2016 / Version 1709 / Version 1803 それぞれに対応していることがすぐにわかります。1709 からはリビジョンの制約がなくなっているので、気にせず使えるのはメリットです。
ビルド済みのイメージに対して docker history を実行すると、ベース OS のバージョンが確認出来ます。
バージョンを気にすることなくイメージを取得して実行できるのは便利なのですが、同じイメージ名なのに落ちてくるものは環境依存となるので、開発やビルド、実行時の OS が異なると簡単に事故ります。
特に実際にイメージを作成する CI 部分と実行環境のバージョン違いは致命的なので、よく使われそうなサービスに関して情報を軽くまとめておきます。
CI SaaS
サービスの大半は LTSC 2016 が使われているので、開発環境が Windows 10 の場合はビルド番号が大きく異なっているはずです。
- ACR Build
- Version 1803 (Hyper-V)
- AppVeyor
- LTSC 2016
- AWS CodeBuild
- LTSC 2016
- Visual Studio Team Services
- LTSC 2016
ACR Build に関してはホスト OS が 1803 ですが、Hyper-V Containers が使われているので LTSC 2016 と Version 1709 のイメージも問題なく扱えるようになっています。
実行環境
数少ない実行環境ですが、こっちも大半が LTSC 2016 が使われています。2019 リリース待ちですね。
- Web App for Containers (Windows)
- LTSC 2016
- Azure Container Instances
- LTSC 2016
- Azure Kubernetes Service
- Version 1709 or 1803
AKS に関しては前に試した時は 1709 が使われていましたが、最近の ACS Engine を見ると 1803 にも対応しているようだったので、両方とも記載しています。Hyper-V Containers ではないので非常に厄介です。
（現時点での）最適なイメージ
現時点での結論としては、使用するイメージは全て LTSC 2016 に統一し、Dockerfile でも明示的に OS バージョンを指定することをお勧めします。
指定していない場合はホスト OS からイメージのバージョンが決定されるので、例えば ACR Build を使うと自動的に 1803 が使われることになります。
# .NET Framework の場合 FROM microsoft/dotnet-framework:4.7.2-sdk-windowsservercore-ltsc2016 # ASP.NET の場合 FROM microsoft/aspnet:4.7.2-windowsservercore-ltsc2016
例外として AKS で Windows Containers を使う場合には、既存の CI SaaS の大半が未対応となってしまうので、ACR Build しか組み合わせる選択肢が存在しないことになります。
2019 リリース後には LTSC 2016 からの移行が発生するであろうこともお忘れなく。
