Dockerの目標の1つは、Windows、Mac、Linuxのいずれで作業している場合でも、可能な限りネイティブに近いエクスペリエンスで、デスクトップ環境からコンテナを操作する最高のエクスペリエンスを提供することでした。 これを実現するために、マイクロソフトとアップルが提供するソフトウェアスタックの操作に多くの時間を費やしています。 この作業の一環として、2016 年に Windows サブシステム for Linux (WSL) が導入されて以来、製品にどのように活用できるかを注意深く監視してきました。
元のWSLは、Windows上でLinuxカーネルをエミュレートするための印象的な取り組みでしたが、WindowsとLinuxの間には基本的な違いがあり、ネイティブLinuxと同じ動作で実装することが不可能なものがあり、これは実行が不可能であることを意味しました。 Docker Engine そして WSL 内で直接 Kubernetes を使用します。 その代わりに Docker Desktop Hyper-V VMとLinuxKitを使用して代替ソリューションを開発し、ユーザーが今日期待し、愛しているシームレスな統合を実現しました。
マイクロソフトは、アーキテクチャを大幅に変更したWSL 2を発表しました:エミュレーションを使用する代わりに、実際には軽量VM内で動作する実際のLinuxカーネルを提供しています。 このアプローチは、アーキテクチャ的には、現在の LinuxKit や Hyper-V で行っているアプローチに非常に近いものですが、Docker 単体で提供できるよりも軽量で、Windows と緊密に統合されているという利点もあります。 Dockerデーモンは優れたパフォーマンスでうまく実行され、コールドブートからWSL 2でdockerdを実行するのにかかる時間は、開発者のマシンで約2秒です。 このテクノロジに非常に興奮しており、WSL 2 を活用した新しいバージョンの Docker Desktop に取り組んでおり、7 月にパブリック プレビューが開始されることを発表できることを嬉しく思います。 これにより、コンテナーを使用して開発するための Docker エクスペリエンスがさらに向上し、新しい機能のロックが解除され、WSL 2 は Windows 10 Home エディションで動作するため、Docker Desktop も同様になります。
マイクロソフトとのコラボレーション
Docker Desktop を Windows で Docker を使用する最適な方法にするための共通の取り組みの一環として、Microsoft は WSL 2 の初期ビルドを提供して、テクノロジを評価し、製品にどのように適合するかを確認し、不足しているものや壊れているものに関するフィードバックを共有できるようにしました。 私たちはさまざまなアプローチのプロトタイピングを開始し、今後数か月で何が来るかについて少し共有する準備が整いました。
Docker Desktop Future
現在使用している Hyper-V VM を WSL 2 統合パッケージに置き換えます。 このパッケージは、現在の Docker デスクトップ VM と同じ機能 (Kubernetes の 1 クリック セットアップ、自動更新、透過的な HTTP プロキシ構成、Windows からのデーモンへのアクセス、Windows ファイルの透過的なバインド マウントなど) を提供します。
この統合パッケージには、Docker と Kubernetes を実行するために必要なサーバー側コンポーネントと、WSL 内でこれらのコンポーネントと対話するために使用される CLI ツールの両方が含まれます。 その後、Docker Desktopの新機能であるLinuxワークスペースを導入できるようになります。
Linux ワークスペース
現在 Docker Desktop を使用している場合、デーモンを実行している VM は完全に不透明です: Windows から Docker および Kubernetes API と対話することはできますが、Docker コンテナーまたは Kubernetes Pods 以外の VM 内では何も実行できません。
WSL 2 統合でも、Windows と同じシームレスな統合を体験できますが、WSL 内で実行されている Linux プログラムでも同じことができます。 これは、Linux環境をターゲットとするプロジェクトや、Linux向けに調整されたビルドプロセスで作業している開発者に大きな影響を与えます。 LinuxとWindowsの両方のビルドスクリプトを維持する必要はもうありません! たとえば、Docker の開発者は、Linux マシンの開発者と同じツールとスクリプトのセットを使用して、Windows 上の Linux Docker デーモンで作業できるようになりました。
また、WSL からのバインド マウントは inotify イベントをサポートし、ネイティブ Linux マシンとほぼ同じ I/O パフォーマンスを備えているため、I/O 負荷の高いツールチェーンに関する Docker Desktop の主要な問題点の 1 つが解決されます。 NodeJS、PHP、およびその他のWeb開発ツールは、この機能から大きな恩恵を受けます。
Visual Studio Code "Remote to WSL" と組み合わせることで、Docker Desktop Linux ワークスペースは、Windows 上で実行されている IDE から、ローカル コンピューター上でコンテナーを構築するための完全な Linux ツールチェーンを実行できるようにします。
パフォーマンス
WSL 2 では、Microsoft はパフォーマンスとリソースの割り当てに多大な労力を費やしました: VM は動的メモリ割り当てを使用するように設定されており、ホストが提供できる範囲内で、ホストで実行されている win32 プロセスに対して協調的に、必要なメモリをほとんど (または同じ量) 消費しながら、すべてのホスト CPU で作業をスケジュールできます。
Docker Desktop はこれを活用して、リソース消費を大幅に改善します。 必要なCPUとメモリを必要なだけ使用し、コンテナの構築などのCPU /メモリを集中的に使用するタスクは、現在よりもはるかに高速に実行されます。
さらに、コールド スタート後に WSL 2 ディストリビューションと Docker デーモンを開始する時間は非常に速く、現在のバージョンの Docker Desktop では数十秒であるのに対し、開発用ラップトップでは 2 秒以内です。 これにより、デーモンの起動を最初の API 呼び出しに延期し、コンテナーを実行していないときにデーモンを自動的に停止することで、バッテリ寿命の最適化への扉が開かれます。
ゼロ構成バインドマウントのサポート
特にエンタープライズ環境で、ユーザーがDockerデスクトップで今日抱えている主要な問題の1つは、Windowsファイルバインドマウントの信頼性です。 現在の実装はSamba Windowsサービスに依存しており、非アクティブ化されたり、エンタープライズGPOによってブロックされたり、サードパーティのファイアウォールによってブロックされたりする可能性があります。 WSL 2 を搭載した Docker デスクトップは、Windows ファイルのバインド マウントを実装するために WSL 機能を活用することで、このカテゴリの問題全体を解決します。 箱から出してすぐに「うまくいく」体験を提供します。
WSL 2 用 Docker Desktop のテクニカル プレビュー
マイクロソフトとのコラボレーションのおかげで、私たちはすでにビジョンの実装に懸命に取り組んでいます。 統合パッケージをデプロイし、デーモンを実行してWindowsプロセスに公開し、バインドマウントとポート転送をサポートするコア機能を作成しました。
WSL 2 用の Docker Desktop のテクニカル プレビューは、7 月にダウンロードできるようになります。 現在のバージョンのDocker Desktopと並行して実行されるため、既存のプロジェクトで安全に作業を続けることができます。 最新のWindows Insiderビルドを実行している場合は、これを直接体験することができます。 今後数か月以内に、互換性のあるバージョンの Windows を実行しているすべてのユーザーに対して、WSL 2 アーキテクチャが Docker Desktop で使用されるまで、さらに機能を追加します。