Docker 社は、現在プレビュー段階にある Microsoft の Windows Subsystem for Linux 2 (WSL 2) のリリース後、Windows で作業する開発者向けに同社のコンテナ テクノロジがどのようなものになるかについての詳細を公開しました。
WSL 2は既存のWSLとは異なるアプローチを採用しています。システムコールをリダイレクトしてLinuxバイナリを実行するのではなく、WSL 2はHyper-V仮想マシンでLinuxカーネルを実行しますが、ホストWindowsオペレーティングシステムと統合されているため、WSL 1.0のほとんどの機能を引き続き利用できます。
WSL 1.0 の Linux 互換性は Docker コンテナーをサポートするには不十分でしたが、WSL 2 では動作します。
Dockerはこの変化を積極的に受け入れています。Windows版Dockerの簡単な歴史は以下の通りです。まず2015年8月にリリースされたDocker Toolboxは、VirtualBoxハイパーバイザーを用いてVM上でLinuxを実行しました。次に2016年にリリースされたDocker Desktopは、LinuxサポートにHyper-Vを使用し、互換性のないWindowsハイパーバイザーをいくつも使い分けていた開発者の負担を軽減しました。そして2017年、DockerはMicrosoftと協力し、Windows Server Containers（LinuxアプリケーションではなくWindowsアプリケーションを実行するコンテナ）のサポートを追加しました。当時、Microsoftはこれが「[顧客]が同一プラットフォーム上でソフトウェアを構築し、既存アプリケーションを近代化する方法に革命をもたらす」と熱狂的に宣伝しました。現在のバージョンのDocker Desktop for Windowsは、デフォルトでLinuxコンテナがインストールされますが、Windowsコンテナに切り替えるオプションも用意されています。
Docker が WSL 2E でどのように動作するかを示す図
現在、Docker は次のように発表しています。
現在使用しているHyper-V VMをWSL 2統合パッケージに置き換えます。このパッケージは、Kubernetesのワンクリックセットアップ、自動更新、透過的HTTPプロキシ設定、Windowsからのデーモンへのアクセス、Windowsファイルの透過的バインドマウントなど、現在のDocker Desktop VMと同じ機能を提供します。
これにより開発者にとって大きなメリットとなるのは、Linux ツールを使用して Linux Docker デーモン (サービス) と対話できるようになることです。
Docker が追加:
WSL 2 の統合により、Windows とのシームレスな統合が実現されるだけでなく、WSL 内で実行される Linux プログラムでも同様のことが可能になります。
その他の利点としては、WSL 2 での動的なメモリ割り当てにより Docker がリソースをより効率的に使用できるようになること、コールド スタートアップが大幅に高速化され、使用されていないときに Docker デーモンを実行する必要がなくなること、Windows 側のファイルへのコンテナー アクセスがより信頼性が高くなることが挙げられます。
Docker は、開発者が Visual Studio Code (VS Code) の「Remote to WSL」拡張機能を使用して、VS Code ターミナルを介して Linux と対話しながら Windows でコードを編集することを想定していています。
すべて良いニュースでしょうか? Docker の観点からすると、Windows 上で適切に動作させるために必要な作業が少なくなるため、これは良いニュースであり、開発者にとってのメリットは現実的です。
マイクロソフトがペンギンスーツを着用
こうした中で驚くべき点は、MicrosoftがWindows開発者向けにLinuxアプリケーション開発を推進しようと尽力している点です。この方針転換の理由はAzureプラットフォームにあります。Azureプラットフォームは、特にアプリケーションが他のAzureサービスを利用している場合、MicrosoftがLinuxアプリケーションのホスティングからWindowsとほぼ同等の利益を得られることを意味します。
クロスプラットフォームの.NET CoreやLinux向けSQL Serverといったプロジェクトも、このトレンドの一翼を担っています。DockerのニュースはWindowsコンテナを使用している開発者にとってはあまり関心のないものですが、そうした開発者はそれほど多くありません。先月のMicrosoft Buildカンファレンスで、Azure Container ComputeチームのリードプログラムマネージャーであるGabe Monroy氏は、Windowsコンテナはレガシープロジェクト向けで、Linuxコンテナは新規プロジェクト向けなのかという質問を受けました。「それは妥当な説明だと思います」とMonroy氏は答え、この問題に関するMicrosoftの考え方が変化してきたことを示しました。
同様に、WSL 2はWindows上でのLinuxアプリケーション開発をより快適にしますが、欠点もあります。システムコールをリダイレクトするのではなく、VM内でLinuxを実行することは互換性の面で優れていますが、統合性という点では本質的に劣ります。その一因として、WSL 2ではLinux VM内のファイルへのI/Oパフォーマンスは大幅に向上しますが、Linuxとホスト間のI/Oパフォーマンスは低下します。また、WSL 2ではシリアルポートやUSBポートにアクセスできないという点も挙げられます。
「私は主に、信頼できる情報源（自分のファイル）を Windows 側に置きたいと思っています。WSL1 は私にとって完璧な動作モデルでした」と、Windows Insider ビルドのユーザー向けの WSL 2 プレビューの発表に応えて、ある開発者は述べています。
Microsoftの回答は？「これが多くの人にとって障害となる可能性があることを理解しており、WSL 1の開発を中止することはありません。」ただし、これは半分真実です。Microsoftは今後、WSL 2に注力していく予定です。
Windows で開発し、 Linux に展開することは、Microsoft にとって興味深い戦略ですが、Windows 側の将来にとっては明らかなリスクを伴うものです。®
