Docker Desktop WSL 2バックエンドは、Windows 10インサイダーユーザーが数か月間利用可能になり、MicrosoftはリリースプレビューチャネルでWSL 2をリリースしました(つまり、GAは非常に近いです)。 私たちと初期のユーザーは、それを使用した経験を蓄積しており、Linuxコンテナプロジェクトに実装するためのいくつかのベストプラクティスを共有できることを嬉しく思います。
WSL 2 バックエンドを備えた Docker Desktop は、以前と同様に Windows ターミナルから使用できます。 現在の開発ワークフローに満足していただけるよう、互換性を重視しました。
しかし、Windows 10 2004を最大限に活用するために、いくつかの推奨事項があります。
WSL 2 を完全に採用する
共有したい最初の最も重要なベスト プラクティスは、WSL 2 を完全に採用することです。プロジェクト ファイルは、選択した WSL 2 ディストリビューション内に格納し、このディストリビューションから docker CLI を実行し、Windows ホストに格納されているファイルへのアクセスをできるだけ避ける必要があります。
下位互換性の理由から、Windows CLI から Docker と対話する可能性は残しましたが、これは推奨されるオプションではなくなりました。
WSLからドッカーCLIを実行すると、次のようになります...
素晴らしいマウント性能
独自の WSL 2 ディストリビューションと Docker-Desktop の両方が同じユーティリティ VM で実行されます。 それらは同じカーネル、VFSキャッシュなどを共有します。 それらは別々の名前空間で実行されるだけなので、完全に独立して実行されているような錯覚があります。 Docker Desktop はこれを利用して、リモート ファイル共有システムを使用せずに WSL 2 ディストリビューションからのバインド マウントを処理します。 つまり、プロジェクトファイルをコンテナにマウントすると(を使用して docker run -v ~/my-project:/sources <...>)、dockerはinotifyイベントを伝播し、独自のディストリビューションと同じキャッシュを共有して、ディスクからファイルの内容を繰り返し読み取ることを回避します。
ただし、Windowsファイルシステムに存在するファイル(with docker run -v /mnt/c/Users/Simon/windows-project:/sources <...>など)をマウントすると、/ mnt / cは実際にはPlan9ファイル共有を介してWindowsファイルを公開するマウントポイントであるため、パフォーマンス上の利点は得られません。
Linuxツールチェーンおよびビルドスクリプトとの互換性
Linuxコンテナを含む最も妥当なサイズのプロジェクトには、多数の自動化スクリプトが付属しています。 これらのスクリプトは、多くの場合、最初に Linux 用に開発され (ほとんどの場合、これらのプロジェクトの CI/CD パイプラインは Linux で実行されるため)、Windows で実行されている開発者は、多くの場合、二級市民と見なされます。 彼らはしばしばそれらのスクリプトのあまり洗練されていないバージョンを使用しており、微妙な動作の違いに対処する必要があります。
WSL 2 を完全に採用することで、Windows 開発者は Linux とまったく同じビルド スクリプトと自動化スクリプトを使用できます。 つまり、Windows 固有のスクリプトを維持する必要がなくなりました。 また、これは、WindowsユーザーとMac / Linuxユーザーの間で異なる行末の問題が発生しないことを意味します。
私のIDEはどうですか?
ファイルを編集するためのIDEが必要な場合は、WSL2ディストリビューション内でホストされている場合でもそれを行うことができます。 3つの異なる方法があります。
- Visual Studio Code Remote to WSL 拡張機能を使用する
IDE が Visual Studio Code の場合、プロジェクトでの作業を続行するには、[リモートから WSL へ] を使用するのが最善の方法です。 Visual Studio Code アーキテクチャは、レンダリングと入力処理を除くほとんどすべてがサーバー プロセスで実行され、UI 自体はクライアント プロセスで実行されるクライアント/サーバー アプローチに基づいています。 WSL へのリモートでは、これを利用して WSL 内でサーバー プロセス全体を実行し、UI は従来の win32 プロセスとして実行します。
つまり、以前と同じエクスペリエンスが得られますが、すべての言語サービス、端末などはWSL内で実行されます。
詳細については、 マイクロソフトの VS Code リモートから WSL へのドキュメントを参照してください。
- IDE をディストリビューション ネットワーク共有にポイントします
WSL は、実行中のディストリビューションごとにネットワーク共有を提供します。 たとえば、Ubuntuディストリビューションの「~/wall-e」にプロジェクトがある場合、特別なネットワーク共有 '\\wsl$\Ubuntu\home\simon\wall-e'を介してWindowsエクスプローラー(および任意のWindowsプロセス)からアクセスできます。
- Windows で X11 サーバーを実行し、Linux ネイティブ IDE を実行する
セットアップはもう少し複雑ですが、Windows(VcXsrv、X410,...)でX11サーバーを実行し、Linux上のGUIアプリが正しくレンダリングされるようにDISPLAY環境変数を構成する可能性は常にあります。
ビルドキットとマルチステージビルドを使用する
Docker デスクトップ WSL 2 バックエンドは、すべての CPU コアにアクセスできます。 これを可能な限り活用するには(そして最新のビルド機能にアクセスするには)、デフォルトでBuildKitを有効にする必要があります。
これを行う最も簡単な方法は、~/.profile ファイルに次の行を追加することです。
エクスポート DOCKER_BUILDKIT=1。
このようにして、Dockerビルドを実行するたびに、さまざまなビルドステージを同時に実行できるすばらしいBuildKitを使用してビルドが実行されます。
リソース制限を使用する
Docker デスクトップ WSL 2 バックエンドは、コンピューター上のほぼすべての CPU とメモリ リソースを使用できます。 これはほとんどの場合素晴らしいことですが、これが問題を引き起こす可能性のあるワークロードのカテゴリがあります。 実際、一部のコンテナー (主にデータベース、またはキャッシュ サービス) は、できるだけ多くのメモリを割り当て、他のプロセス (Linux または Win32) を枯渇させる傾向があります。 Docker は、コンテナーによって割り当て可能なメモリ (および CPU 使用率のクォータ) に制限を課す方法を提供します。 あなたはそれについての文書をここで見つけることができます: https://docs.docker.com/config/containers/resource_constraints/。
キャッシュされたメモリを再利用する
WSL 2 は、解放されると自動的にメモリを再利用して、Windows プロセスで使用できるようにします。 ただし、カーネルがコンテンツをキャッシュに保持することを決定した場合(Dockerでは、それがかなり頻繁に発生する傾向があります)、再利用されるメモリの量が十分でない可能性があります。
より多くのメモリを再利用するには、コンテナーを停止した後、ルートとして実行 echo 1 > /proc/sys/vm/drop_caches してカーネル ページ キャッシュを削除し、WSL 2 で VM によって使用されているメモリを再利用します。
次のステップ
WSL 2 で Docker Desktop を使用するユーザーを歓迎しており、この記事のヒントとテクニックが、すべてのワークロードで最高のパフォーマンスを得るのに役立つことを願っています。
Dockerを使用するために共有したい別のヒントやアイデアがある場合は、@dockerツイートを送信するか 、 実装に関するフィードバックがある場合は、 Githubリポジトリに対してチケットを発行してください。