アプリの「コンテナ化(Containerized)」は、クラウドネイティブで、スケーラブルなアプリの開発/実行を可能にし、「DevOps」や「CI/CD」を実現します。現在のWindowsはアプリのコンテナ化に対応していますが、その巨大なイメージサイズが大きな課題となっていました。2023年1月提供のベースOSイメージでは、イメージサイズの大幅な最適化が行われました。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
「Docker」に代表されるコンテナ技術では、コンテナ化されたアプリはホストのカーネル上で動作するプロセスでありながら、アプリはコンテナごとに分離されたランタイム環境を利用できます。コンテナイメージは、抽象化されたバイナリやライブラリ、ストレージをアプリに提供し、そのイメージは再配布可能でパブリックなベースOSイメージやミドルウェア、カスタムのアプリといったレイヤーの積み重ねで構成されます。
Windowsでは「Windows Server 2016」で初めてDocker対応のコンテナのサポートが追加され、現在はさまざまなコンテナプラットフォームおよびツールの上に構築されています(「Docker EE」への依存は初期の実装です)。代表的なコンテナオーケストレーション環境である「Kubernetes」でも、Windowsベースのコンテナが正式にサポートされるようになりました。Kubernetesでは現在、「Mirantis Container Runtime(MCR)」(旧称、Docker EE、Docker Enterprise)」または「Containerd」をコンテナエンジンとして、「Windows Server 2019」以降のWindowsノード(およびポッド)をサポートしています。
Microsoft Azureには、「Azure Container Instances(ACI)」「Azure Kubernetes Service(AKS)」「Azure App Service」などのコンテナ対応サービスがあります。これらは、Linuxベースのコンテナだけでなく、Windowsベースのコンテナのデプロイと実行にも正式に対応しています。これらのサービスやローカルの「Docker Desktop」環境でLinuxベースやWindowsベースのコンテナを扱うとすぐに気が付くことは、Windowsコンテナのイメージサイズの大きさです。
Linuxベースのコンテナの場合、デプロイするとすぐにアプリも利用可能な状態になりますが、Windowsベースのコンテナの場合は、イメージサイズの影響でイメージのプル(pull)/プッシュ(push)/実行(run)に長い時間を要します。
イメージサイズの大きさはWindowsコンテナの大きな課題であり、Windows Serverの新しいバージョンで最適化が続けられてきました。ダウンロード時の圧縮されたイメージのサイズでいうと、Windows Server 2016の「Server Core」(windows/servercore:ltsc2016)のときは5GB以上ありましたが、Windows Server 2019(windows/servercore:ltsc2019)で2GB前後に大きく縮小されました。
初期バージョンでは1GB以上あった「Nano Server」イメージは(windows/nanoserver:ltsc2016)は、コンテナおよび.NET/ASP.NETに特化することでWindows Server 2019(windows/nanoserver:ltsc2019)以降、10分の1の100MB程度に縮小されました。それでも、数MB(コンテナに最適化されたAlpineイメージ)から数十MB(Ubuntuなど)のLinuxのベースOSイメージに比べれば圧倒的に大きなサイズです(画面1)。
MicrosoftはWindowsコンテナのサイズの課題を軽減するため、ベースOSイメージのサイズ最適化に加えて、Azureのサービス側で親イメージをキャッシュして高速化を図れるようにしています。それでも、サイズの大きさが影響して、コンテナが開始してからアプリを利用できるようになるまで、数分間待たされます(画面2)。そもそも、カスタムイメージについては、キャッシュの恩恵を受けることはできません。
Microsoftは2023年1月、Windowsコンテナ(Nano Serverを除くServer CoreやWindows Server)のイメージサイズ削減について発表しました。
Nano Serverを除くWindowsコンテナのイメージは、初期リリース時および不定期に作成される「ベースレイヤー」と、毎月の累積的な更新プログラムの内容を含む「差分(Delta)レイヤー」で構成されます。ベースレイヤーが既に取得済みの場合には、差分レイヤーのダウンロードと展開だけでプル(pull)できるようにしています。この方法は毎月の更新の際、ダウンロードの最適化には寄与しますが、ベースレイヤーの作成から数カ月経過すると差分レイヤーが巨大化し、合計サイズもそれに応じて巨大化していきます。
2023年1月に行われたベースレイヤーの更新は、1つ前のベースレイヤーのサイズよりも小さくなりました。1月には差分レイヤーは存在せず、合計サイズでは2022年12月(ベースレイヤーは2022年5月)と比べて40〜50%小さくなりました(表1)。そして、2023年2月以降の差分レイヤーについても以前と比べて60〜80%のサイズ縮小が見込まれています(画面3、画面4)。
コンテナイメージ | 2022年12月のイメージ | 2023年1月のイメージ | |||||
---|---|---|---|---|---|---|---|
Baseレイヤー | Deltaレイヤー | 合計 | Baseレイヤー | Deltaレイヤー | 合計 | ||
windows/servercore:ltsc2019 | 1.74GB | 0.87GB | 2.52GB | 1.54GB | なし | 1.54GB | |
windows/servercore:ltsc2022 | 1.33GB | 0.93GB | 2.26GB | 1.25GB | なし | 1.25GB | |
windows/server:ltsc2019 | 4.13GB | 2.57GB | 3.68GB | 3.68GB | なし | 3.68GB | |
windows/server:ltsc2022 | 3.06GB | 2.25GB | 3.13GB | 3.13GB | なし | 3.13GB | |
表1 2023年1月にベースレイヤーが刷新され、2023年2月以降の差分レイヤーも60〜80%小さくなる見込み |
真の意味でのWindowsアプリのコンテナ化は、クロスプラットフォームである.NET/ASP.NETに特化したNano Serverイメージ(つまり、Linuxで代替できる場合が多い)ではなく、Server Coreイメージ(または全てのWindowsコンポーネントとWindows APIを利用できるWindows Serverイメージ)でアプリを実装することです。
2023年1月以降のベースOSイメージ(IIS《インターネットインフォメーションサービス》や.NET Frameworkイメージもこの恩恵を受けます)で作成されたWindowsコンテナは、最初のデプロイ時間に対する恩恵はわずかですが、イメージの更新のためのプル(pull)時間が大幅に短縮されると期待できます(ベースレイヤーは取得済みのため、差分レイヤーのみのダウンロード)。これは、運用環境のアプリのスケーリングや、CI/CD(継続的インテグレーション/継続的デリバリー)の実装におけるWindowsコンテナの壁を大きく引き下げることになるでしょう。
岩手県花巻市在住。Microsoft MVP 2009 to 2022(Cloud and Datacenter Management)。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『Windows版Docker&Windowsコンテナーテクノロジ入門』(日経BP社)、『ITプロフェッショナル向けWindowsトラブル解決 コマンド&テクニック集』(日経BP社)。
Copyright © ITmedia, Inc. All Rights Reserved.