テクニカルプレビューからの変更点

今年初めに、WSL 2 を使用した Windows での Docker 開発の将来に関するビジョンの テクニカル プレビューをリリース しました。さまざまなチャネルを介して Windows Insider から多くのフィードバックを受け取り、一般的なエラー ケースを照合しました。 また、自分たちでよく使用し、時間をかけてアーキテクチャを評価しました。

この分析に基づいて、Docker Desktop の WSL2 統合をより堅牢で保守しやすい方法で再設計し、Hyper-V バックエンドで現在使用しているものと同等の機能を確保しました。

新機能

新しいバックエンドアーキテクチャの詳細を掘り下げる前に、どのような新機能があるかを見てみましょう。

1. Kubernetes のサポート: WSL 2 バックエンドを使用するときに Kubernetes を有効にできるようになりました
2. 更新されたデーモン: WSL 2 バックエンドで最新の安定した Docker デーモンが実行されるようになりました
3. VPN 対応のネットワーキング: WSL 2 バックエンドは、vpnkit を使用して VPN 対応のネットワーク スタックを確保し、この分野での取り組みを活用しています
4. さらに、WSL 2 バックエンドは、Hyper-V バックエンドと同等の機能になりました。 HTTPプロキシ設定、信頼できるCA同期、バージョンパックのサポート、新しいコンテナUIのサポート...

この新しいバックエンドは、Docker デスクトップ設定で有効にできます。

WSL 2 が一般公開されると、このチェック ボックスがオフになり、互換性のあるマシンで WSL 2 バックエンドが自動的にオンになります。

新しいアーキテクチャの紹介

ユーザーからのフィードバックと内部で特定した要件に基づいて、WSL 統合アーキテクチャで変更したい 3 つの主要な側面があります。

• 分離された環境で実行する: WSL2 で実行されている他のアプリケーションからの副作用をできるだけ回避するために、別のネットワーク/PID/マウント名前空間で実行する必要があります
• 現在のコードベースを活用して、独自の Hyper-V VM に既に実装されているすべての機能を再実装しないようにします
• ユーザーが使い慣れている既存のUIと完全に統合します。

Hyper-V バックエンドのアーキテクチャ

この新しいアーキテクチャを理解するには、少し戻って、Hyper-V バックエンドの設計方法と、Windows フロントエンドがバックエンドと通信する方法を確認する必要があります。

最も重要なことは、Hyper-Vで実行するLinuxVMです。 このLinuxVMは完全にLinuxKitを使用して構築されているため、その中で実行されるすべてのものを正確に制御することが非常に簡単になります。 Hyper-V と Mac VM の両方で使用される多数の LinuxKit コンポーネントを作成しました: Docker と Kubernetes のライフサイクルを制御するサービス、障害発生時に診断を収集するサービス、ログを集約するサービスなど。 これらのサービスは、Docker デスクトップのインストールディレクトリ (docker-desktop.iso) の iso ファイルにパッケージ化されています。

このベースディストリビューションの上に、実行時にバージョンパックisoと呼ばれる2番目のisoをマウントします。 このファイルには、Docker エンジンと Kubernetes のバージョンに固有のバイナリとデプロイ/アップグレード スクリプトが含まれています。 エンタープライズエディションでは、この2番目のisoは公開するバージョンパックの一部ですが、コミュニティでは、単一のバージョンパックがサポートされています(docker.isoファイルはdockerデスクトップインストールフォルダーにもあります)。

VM を起動する前に、コンテナー イメージと構成、および Kubernetes データ ストアを格納するための VHD もアタッチします。

これらのサービスを Windows 側から到達可能にするために、内部で Hyper-V ソケットを使用して、Unix ソケットを Windows 名前付きパイプとして公開するプロキシを構築しました。

新しい WSL 2 バックエンドへの変換方法

新しいWSLバックエンドの設計はそれに非常に近いですが、VMでLinuxKitディストリビューションを実行しないという違いがありますが...コンテナ内。

これにより、2つのWSLディストリビューションが作成されます。 

• Docker-desktop、ブートストラップディストリビューションと呼びます
• Docker-desktop-data (データ ストア ディストリビューションと呼びます)

大まかに見ると、ブートストラップ ディストリビューションは基本的に Hyper-V を置き換え、データ ストア ディストリビューションは以前に VM にアタッチした VHD を置き換えます。

ブートストラップディストリビューションは、前述ののと同じ2つのisoファイルに基づいて独自のルートファイルシステムを持つLinux名前空間を作成し(完全に真実ではありませんが、十分に近い)、VHDの代わりにデータストアディストリビューションをコンテナイメージなどのバッキングストアとして使用します(WSL 2では、現時点では追加のVHDをアタッチすることはできません。 そのため、クロスディストリビューションマウントを活用します)。 最初のisoファイルは元のものからわずかに変更されています:LinuxカーネルとWSL 2によってすぐに提供されるシステムサービスを削除しました。2番目のもの(バージョンパックiso)は、Hyper-V(およびMacでも)で使用するものと厳密に同じです。 ブートストラップディストリビューションは、Linuxkit コンテナからアクセスできる場所に Windows 9p 共有をマウントするようなことも管理し (コンテナと Windows ファイルを共有するために Samba を使用しないようにするため)、Linuxkit コンテナのライフサイクルを制御します (クリーンシャットダウンの確保など)。

このようにして、Docker は Hyper-V および MacOS VM と非常によく似た包含環境で実行されます。 Linuxkitコンポーネントで実際に同じコードベースを共有するほど近いため、同じバージョンパックisosと同じWindows側のコードベースを使用して、Hyper-Vバックエンドとの機能パリティを非常に迅速に達成しました。

これがもたらす大きな違いは、Hyper-V VMよりも15倍速く起動し、WSL 2の動的リソース割り当てのおかげで、マシンのすべてのリソースにアクセスし、本当に必要なだけ消費できることです。 これにより、以前は 2 GB の Hyper-V VM を前もって割り当てることが困難だった低メモリ環境で実行できるようになります。

長期的には、Hyper-Vが利用できないがWSL 2(特にWindows Homeエディション)が利用できるWindowsバージョンをサポートするための扉も開かれます。

Linux ワークスペースのサポート

テクニカルプレビューアーキテクチャにより、Linux Workspacesは非常に簡単に実装できました:デーモンは独自のディストリビューションで実行されるため、ファイルシステムに直接アクセスできました。 デーモンの公開は、バインドマウントと同様に箱から出してすぐに機能しました。

新しいアーキテクチャでは、物事は少しトリッキーです:私たちは別のディストリビューションで、分離された名前空間内で実行されますが、どうすれば同じレベルのパフォーマンスを達成できますか?

WSL 2 は、同じカーネルを共有して、同じユーティリティ VM 内のすべてのディストリビューションを実行します。 最近、Microsoft はクロスディストリビューション バインディングを導入し、特定のディストリビューションの VHD に別のディストリビューションからアクセスできるようになりました。 これを使用すると、実際にデーモンをユーザーディストリビューションに公開でき、ネイティブLinuxパフォーマンスを備えた封じ込め環境内からユーザーディストリビューションファイルにアクセスできます。

バインドマウントをシームレスなエクスペリエンスにするために、ユーザーディストリビューションからの相対パスをLinuxKitコンテナからアクセスできる同じファイルへのパスに変換する、Windowsファイルのバインドマウントを有効にするために使用するものと同様のDockerAPIプロキシを導入しました。

初期の制限

Linux ワークスペースのエクスペリエンスのブラッシュアップにはまだ取り組んでいます。 最初に、次の制限に対処する必要があります。

1. ディストリビューションVHDによってバックアップされたファイルのみをマウントできます(つまり、/ tmp、/ mnt、/ var / run、/ proc、/ sysなど内のマウントをバインドすることはできません)。 ほとんどの人にとって、これは問題ではないはずですが、/ var / run / docker.sockのようなものをコンテナにマウントすることは、最初は機能しません。 私たちはこの問題を解決するためにマイクロソフトと協力しています、将来のWindows Updateは完全なバインドマウントサポートをもたらすでしょう。
2. クライアント バイナリはまだ提供していません。 ディストリビューションにapt、yum、またはその他のパッケージマネージャーを使用して、dockercliとプラグインをインストールする必要があります。 これは今後のアップデートで自動化されます。

なぜそれをしたのですか?

テクニカルプレビューをリリースしたとき、私たちが望んでいたのは、WindowsでのLinuxコンテナ開発の将来についてのビジョンを表す、実際のユーザーの手に渡ることでした。 メインのDockerデスクトッププロジェクトを除いて、実験できるものを構築するために非常に迅速に作業し、多くのユーザーフィードバックを収集しました(ちなみに、Windows Insiderに感謝します、これは大いに役立ちました!

また、メンテナンスコスト、問題診断、安定性、更新処理、他のバックエンドとのコード共有などの長期的な懸念の観点から、技術プレビューアーキテクチャにも挑戦しました。

その後、ホワイトボードに戻り、いくつかの潜在的な代替アーキテクチャを設計し、最小限の労力で、WSL 2 内のコンテナーで LinuxKit VM を非常に小さな変更で実行できることがわかりました。このアプローチにより、問題の診断、更新の処理、バージョンパックのサポートの確保、他のバックエンドとの機能の同等性などについて、現在とまったく同じメカニズムを非常に簡単に実装できます。

私たちはプロトタイピング段階に進み、成功したことが証明され、それをDockerデスクトップコードベースに直接統合しました。

この決定を推進する主な問題

ユーザーは Kubernetes のサポートを求めています

より大きな範囲では、Hyper-V バックエンドと同等の機能が必要です。 これには、もちろんKubernetesのサポートが含まれますが、次のような多くの隠された機能も含まれます。

• エンタープライズでのバージョンパックのサポート
• 信頼された CA の同期
• VPNフレンドリーなネットワーキング
• HTTP プロキシのサポート

私たちの新しいアーキテクチャは、これらすべてを解決します。

ドッカー作成は WSL 2 エンジンと通信できません

テクニカルプレビューに同梱されているdocker-composeのバージョンは、ドッカーコンテキストを認識していませんでした。 docker-composeの修正に取り組んでいますが、新しいアーキテクチャにより、dockerコンテキストをまだサポートしていないクライアントツール(古いバージョンのdocker-composeを含む)を簡単に操作できます。

コンテナネットワークが機能しない場合があります

その理由はいくつか特定しましたが、それらはすべて元の設計の欠陥に関連しています:技術プレビューは独自のディストリビューション内で実行されます。 このディストリビューションでは、ネットワークインターフェイスやiptablesなどを扱う可能性のある他のアプリケーションを実行している可能性があります。 それは完全に私たちのコントロールの外にある対立を引き起こす可能性があります。

さらに悪いことに、すべてのWSL2ディストリビューションは同じネットワーク名前空間で実行されます...2つのディストリビューションで同時にDockerを実行しようとしたために問題が発生した一部のユーザーからの報告がありました。 当然のことながら、2つのDockerデーモンは、競合するiptablesルールを作成することで互いに殺し合いました。

私たちの新しいアーキテクチャは、もはやこの問題の対象ではありません。

診断は悪夢です

私たちが制御していないディストリビューション内で実行すると、問題診断の面で大きな課題が発生します。 特に Kubernetes のサポートを追加する場合。

ユーザーがすべてを壊す方法は多すぎて、私たちが制御していないシステムで機密性の低いデータのみを収集する診断システムを作成することは非常に困難です。 分離されたコンテナー内で実行すると、この問題が解決され、Hyper-V および Mac バックエンドで既に使用しているのと同じ診断サービスを活用できます。

複数の「ホスティングディストリビューション」をサポートすることは困難です

すべてのユーザーがUbuntuで実行したいわけではありませんが、私たちはそれを認識しており、彼らに選択肢を与えたいと考えています。 ただし、統合パッケージのインストールを本当に「普遍的な」方法で自動化することは非常に困難です。 コンテナー内の独自のWSLディストリビューションで実行することで、この問題は発生しなくなり、クロスディストリビューションバインドマウントのおかげで同じファイルシステムのパフォーマンスが維持されます。

統合パッケージのメンテナンスコストが非常に高い

Hyper-VおよびMacバックエンドのアーキテクチャにより、多くのコードを簡単に共有できます。 Mac と Windows の VM はほぼ同じであり、WSL 2 でもこの優れた生産性の価値を維持したいと考えています。 統合パッケージを使用してすべての機能を新しい方法で実装するコストが高すぎました。

私たちの新しいアプローチにより、Linuxコードベースの大部分をMac、Hyper-V、WSL 2バックエンド間で共有できます。

アップグレードの処理は非常に困難です

Dockerデスクトップでのアップグレードの処理に豊富な経験があります。 それは難しいです、そして私たちはこの仕事を複製したくありません。

新しいアーキテクチャは、Hyper-V および Mac バックエンドに用意されているロジックとまったく同じロジックを共有しています。

Docker Desktop の未来

マイクロソフトが WSL 2 を一般公開したら、サポートされているすべての Windows バージョンで WSL 2 エンジンを既定で有効にする予定です。 マイクロソフトがWSL 2のないWindowsバージョンのサポートを停止するまで、Hyper-Vバックエンドは引き続きサポートされますが、フォールバックメカニズムとしてのみです。

この「WSL 2ファースト」のアプローチに移行することで、そのユニークな特性を活用して、将来的に新機能のロックを解除したいと考えています。 たとえば、WSL 2 は Windows 10 Home でサポートされています。 これを利用して、将来的に新しいユーザーにリーチしたいと考えています(まだ発表するものはありませんが、間違いなくバックログにあります)。

この新しいバックエンドは、エキサイティングな新機能への道を開くものであり、皆様からのフィードバックをお待ちしております。

新しい WSL 2 アーキテクチャは、次の Docker デスクトップ エッジ リリースの一部としてリリースされる予定です。 既に WSL 2 を使用している Windows ユーザー向け 今すぐエッジをダウンロード 今後数週間で最新のDockerアーキテクチャにアクセスできるようにします。