Windows 11、WSL Containersを導入：Linuxコンテナを実行する新しい方法
Windows 11では、ユーザーがLinuxコンテナをネイティブに構築、実行、管理できるようになり、Docker Desktopをバックグラウンドランタイムとして使用する必要がなくなりました。この新機能はWSL Containersと呼ばれ、公的プレビューとして導入されています。本機能をインストールし、実際のワークロードでテストした結果、その機能、制約、セットアッププロセスの概要を以下に示します。
Windows 11でのWSL Containerとは？
WSL Containerは、Windows Subsystem for Linux (WSL)の組み込み機能です。これにより、Windows上でDocker DesktopやPodman Desktopのようなサードパーティランタイムを必要とせずに、Linuxコンテナを直接作成、実行、管理することが可能です。以下の2つの部分で動作します：
- Windowsアプリケーションは、Linuxが関与していることをほとんど目に見えない形で、バックグラウンドでLinuxコンテナを静かにスピンアップし、Linux専用のコードを実行できます。例えば、MicrosoftはLinuxのオープンソースレンダリングエンジンであるMoonrayをWindows実行可能ファイル内で動作させるデモを行いました。
- APIを使用する各Windowsアプリケーションは、コンテナの分離のためにHyper-Vをバックエンドとする独自の仮想マシンを取得します。このアプローチはリソース効率よりもセキュリティを優先し、エンタープライズ利用に適しています。
Linux VM内のコンテナランタイムは、Dockerを支えるオープンソースエンジンであるMobyです。WSL Containersはコンテナを再発明するのではなく、Windowsがコンテナ管理のための純正インターフェースを提供するものです。
Windows 11でWSL Containerをインストールする方法
WSL Containerは現在、WSLのプレリリースチャンネルでのみ利用可能です。始めるには、このチャンネルに参加し、WSLのインストールを更新する必要があります。
- 最新のプレリリース版のWSLをインストールします。
wslcコマンドが認識されない場合は、ターミナルやPCを再起動します。- Hyper-Vをバックエンドとする分離のために、BIOSまたはUEFIで仮想化が有効になっていることを確認します。
注意：一部の開発者から、初回実行時に致命的なエラー（エラーコード：E_UNEXPECTED）が発生したとの報告がありますが、私たちのテストではこれらの問題は発生しませんでした。WSL ContainerにはCopilot+ PCは必要ありませんが、最新のCPU仮想化サポートに依存します。
WSL Containerを使用したコンテナの構築と実行
wslcがセットアップされた後、基本的な例をスキップし、カスタムイメージを構築し、サービスを公開するという実際の使用例でテストしました。以下は手順です：
- サニティチェック：
wslc run -it debian:latestを使用してDebianコンテナをインタラクティブに取得して実行しました。uname -aを実行し、実際のLinuxカーネルが使用されていることを確認しました。 - デタッチと再アタッチ：
Ctrl+P, Ctrl+Qを使用してコンテナをデタッチし、wslc ps -aでコンテナをリストし、wslc attach [container-name]で再アタッチしました。 - カスタムイメージ：
file、exiftool、binutilsなどのツールをパッケージ化したLinux検査ユーティリティ用のContainerfile（Dockerfileに類似）を作成しました。wslc build -t my-linux-inspector .を使用してイメージを構築しました。 - サービスの実行：
wslc run -d -p 5000:5000 --name inspector my-linux-inspectorを使用してポートマッピング付きでコンテナを開始しました。Windowsから追加のネットワーク設定なしで127.0.0.1:5000のFlaskサーバーにアクセスしました。
これにより、サードパーティソフトウェアを使用せずに、Windows上でローカルホストを介してアクセス可能なLinuxカーネルによるサービスが実証されました。
WSL Container内でのGPUアクセスのテスト
AIや機械学習ワークロードにはGPUパススルーが重要です。WSL Containerは--gpus allフラグを使用してこれをサポートし、Dockerの構文と一致します。テストでは、GPUアクセスを持つコンテナが、PyTorchモデルを実行する際、CPUのみを使用するコンテナよりも大幅に優れたパフォーマンスを示しました。
エンタープライズ環境向けのWSL Container
Microsoftは、WSL Containerをプレビュー段階でもエンタープライズ対応と位置付けています。主なエンタープライズ機能には以下が含まれます：
- セキュリティモニタリング： Microsoft Defender for Endpointは、WSLプラグインを通じてコンテナイベントを追跡し、コンテナの活動の可視性を提供します。
- ポリシー管理： IT管理者は、グループポリシーやADMXポリシーを通じてWSL Containersを管理できます。Intuneダッシュボードの完全サポートは近日中に予定されています。
- 開発ツール： VS CodeのDev Containers拡張機能は
wslcをサポートしており、最小限の設定変更で利用可能です。
WSL Containerの現時点での欠点
有望ではあるものの、WSL Containerには現在いくつかの制約があります：
- Docker Composeのサポートがないため、
compose.yamlファイルを必要とするマルチサービスプロジェクトには不向きです。 - GUIダッシュボードやイメージスキャン用のDocker Scoutのような機能が欠如しています。
- Docker Desktopに比べて豊富なプラグインエコシステムがありません。
Microsoftは、LinuxトラフィックをWindowsネットワークスタック経由でルーティングし、VPNやプロキシの問題を解決するConsommeのような実験的なネットワーキング機能を導入しました。これらの機能は、より高速なファイルアクセスを可能にする新しいvirtiofsファイルシステムとともに、現在はWSL Container専用ですが、将来的には通常のWSLディストリビューションにも拡張される可能性があります。
Docker Desktopから移行すべきか？
単一コンテナのシナリオでは、WSL ContainerはDocker Desktopの実行可能な代替手段です。特に、個別のライセンスが不要である点が利点です。しかし、Composeファイル、複数のサービス、またはDockerのプラグインエコシステムを含む複雑なワークフローでは、Docker Desktopが依然としてより完全なソリューションとなります。
Microsoftは、WSL Containerの一般提供を2026年秋までに実現することを目指しています。そのCLIはDockerのものに非常によく似ており、欠けている機能も時間をかけて追加されると予想されます。現時点では、Docker Desktopと並行してWSL Containerを実行することで、この新しい機能をコストなしで試すことができます。
