アプリの「コンテナ化(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前後に大きく縮小されました。
Copyright © ITmedia, Inc. All Rights Reserved.