Docker Desktop WSL 2 バックエンド¶
Windows Subsystem for Linux (WSL) 2 は、 Microsoft によって構築された完全な Linux カーネルであり、アーキテクチャが著しく変更されたため、仮想マシンを管理しなくても Linux ディストリビューションを実行できるようになりました。WSL 2 上で Docker Desktop を実行すると、ユーザは Linux ワークスペースを活用できるため、Linux と Windows の両方の構築スクリプトを維持する必要がなくなります。加えて、 WSL 2 はファイルシステム共有や起動時間短縮をもたらすため、 Docker Desktop ユーザはクールな新機能にアクセスできるようになります。
また、Docker Desktop は WSL 2 で導入された動的メモリ割り当て機能も活用できるため、リソースの消費を著しく改善します。つまり、Docker Desktop は、コンテナのビルドのような CPU とメモリを大量に必要とするタスクでも、 CPU とメモリを必要量しか使わないため、より速く実行できます。
さらに、WSL 2 はDocker デーモンのコールド・スタート後は、起動に必要な時間が著しく早くなります。Docker デーモンの起動に、現在の Docker Desktop のバージョンでは数十秒かかるのと比べ、2秒以下です。
動作条件¶
Docker Desktop WSL 2 バックエンドをインストールする前に、以下の手順を完了している必要があります。
Windows 10, version 1903 以上、または Windows 11 をインストール。
Windows 上での WSL2 機能の有効化。詳細手順は マイクロソフトのドキュメント を参照ください。
Linux カーネル更新パッケージ のダウンロードとインストール
ダウンロード¶
Docker Desktop for Windows をダウンロードします。
インストール¶
Docker Desktop をインストールする 前に 、動作条件のセクションで説明した、 事前の手順 を必ず終えてください。
通常の Docker Desktop のインストール手順に従い、インストールを行います。もしサポートしているシステムであれば、 Docker Desktop のインストール中に、 WSL 2 を有効化するかどうか訊ねる画面が出ます。続けるには、画面に表示される文字を読み、WSL 2 を有効化します。
Windows スタート・メニューから Docker Desktop をスタートします。
Docker メニューから、 Settings > General を選択します。
User WSL 2 based engine (WSL2 対応エンジンを使う) のチェックボックスを選択します。
WSL 2 をサポートしているシステム上に Docker Desktop をインストールした場合は、デフォルトでこのオプションが有効化されています。
Apply & Restart (適用と再起動)をクリックします。
以上で終わりです! これで、新しい WSL 2 エンジンを使って docker
コマンドが動作します。
WSL 2 ディストリビューションで Docker サポートの有効化¶
WSL 2 は Widnows に「Linux ディストリビューション」のサポートを追加しています。各ディストリビューションは単一の共有 Linux カーネル上で動作するのを除き、仮想マシンのような挙動です。
Docker Desktop では何らかの Linux ディストリビューションをインストールする必要はありません。 docker
CLI と UI は追加の Linux ディストリビューションがなくても動作します。しかしながら、最高の開発体験を得るためには、少なくとも1つのディストリビューションを追加し、次のようにして Docker サポートを有効化するのを推奨します。
ディストリビューションが WSL 2 モードで実行中かどうかを調べます。WSL は v1 と v2 モードどちらのディストリビューションも実行できます。
WSL モードの確認は、次のように実行します。
wsl.exe -l -v
v2 にアップグレードするには、次のように実行します。
wsl.exe --set-version (distro name) 2
以後のインストールで v2 をデフォルトのバージョンにセットするには、次のように実行します。
wsl.exe --set-default-version 2
2. Docker Desktop を再起動したら、 Settings > Resources > WSL Integration に移動し、Docker でアクセスしたい WSL 2 ディストリビューションを選択します。
WSL 統合によって、デフォルトの WSL ディストリビューションが有効化されます。このデフォルトの WSL ディストリビューションを変更するには
wsl --set-default <ディストリビューション名>
を実行します。たとえば、デフォルト WSL ディストリビューションを Ubuntu に設定するには、
wsl --set-default ubuntu
を実行します。オプションの項目から、WSL 2 上で有効化したい追加ディストリビューションを選択できます。
注釈
Docker-WSL 統合機能コンポーネントの実行には、選択したディストリビューションの glibc に依存します。これにより、 Alpine Linux のような musl ベースのディストリビューションの実行時、問題が発生する場合があります。Alpine の利用者は、WSL 統合下で実行するため、 glibc のデプロイと並行し、 alpine-pkg-glibc パッケージを利用できます。
3. 変更を有効にするには Apply & Restart をクリックします。
ベストプラクティス¶
ファイルのバインド マウント時、ファイルシステムの性能を最大限に活用するには、ソースコードや他のデータの保管を、Windows ファイルシステム上ではなく、Linux コンテナ内(例:
docker run -v <host-path>:<container-path>
を指定)のファイルシステム内にバインド マウントするのを推奨します。また、 Microsoft による 推奨 もご覧ください。Linux コンテナが受け取るファイル変更のイベント( "inotify event" )とは、Linux ファイルシステム内に保管されているオリジナルのファイルに関係するものです。たとえば、いくつかのウェブ開発ワークフローでは、ファイル変更時の自動再読み込みが、 inotify イベントに依存しています。
リモートの Windows ホスト上よりも、Linux ファイルシステムにファイルをバインド マウントする方が、性能がより高くなります。従って、
docker run -v /mnt/c/users:/users
を避けるべきです(/mnt/c
は Windows によってマウントされる場所です)。
docker-desktop-data VHDX の容量に関する懸念や、これを変更したい場合は、 WSL 2 仮想ハードディスクのサイズを拡張する をご覧ください。
CPU やメモリ使用量に懸念がある場合は、メモリ、CPU 、スワップ容量に制限を設けられます。割り当ては WSL 2 ユーティリティ仮想マシン で行えます。
Docker Desktop 上で WSL 2 の使用による潜在的な競合を避けるには、Docker Desktop をインストールする前に、Linux ディストリビューションによってインストールされた あらゆる古いバージョンの Docker Engine のアンインストール と CLI のアンインストールが必要です。
Docker と WSL 2 で開発する¶
以下のセクションでは、Docker と WSL 2 を用いたアプリケーション開発のはじめかた説明します。私たちの推奨は、皆さんのデフォルト Linux ディストリビューションにコードを入れる方法が、Docker と WSL 2 バックエンドを用いた開発体験にベストです。Docker Desktop で WSL 2 を有効化した後は、Linux ディストリビューションの中でコードが動き始めるので、Windows 上でありながら理想的な IDE(統合開発環境)となるでしょう。 VSCode を使えば、 このワークフローはより洗練されるでしょう。
1. VSCode を開き、 Remote - WSL エクステンションをインストールします。この拡張機能によって、Windows 上にある Linux ディストリビューションをリモート サーバとして動かすことができ、Windows 上の IDE クライアントになります。
2. 次に、VSCode をリモートで動作するようにします。そのためには、ターミナルを開き、次のように実行します。
wsl
code .
これにより新しい VSCode のリモート接続先が、スクリーン上で下の端でチェックしている、デフォルトの Linux ディストリビューションになります。
あるいは、スタートメニューからデフォルトの Linux ディストリビューション名を入力し、開き、 code
を実行します。
3. VSCode 内であれば、VSCode のターミナルを使って、Windows マシンからコードを取得し、ネイティブに動かせられます。
GPU サポート¶
Docker Desktop 3.1.0 から、 Docker Desktop は NVIDIA GPU 上で WSL 2 GPU
NVIDIA GPU 搭載マシン
Dev Preview ring の最新 Windows インサイダー バージョン
WSL 2 GPU Paravirtualization をサポートする NVIDIA による ベータ ドライバ
管理者のコマンドプロンプトから
wsl --update
を実行し、 WSL 2 Linux カーネルを最新版に更新Docker Desktop で WSL 2 バックエンドが有効化どうか確認する
全てが期待通りに動作するかどうかを確認するには、以下のコマンドを実行し、GPU に対する短いベンチマークを走らせます。
$ docker run --rm -it --gpus=all nvcr.io/nvidia/k8s/cuda-sample:nbody nbody -gpu -benchmark
Run "nbody -benchmark [-numbodies=<numBodies>]" to measure performance.
-fullscreen (run n-body simulation in fullscreen mode)
-fp64 (use double precision floating point values for simulation)
-hostmem (stores simulation data in host memory)
-benchmark (run benchmark to measure performance)
-numbodies=<N> (number of bodies (>= 1) to run in simulation)
-device=<d> (where d=0,1,2.... for the CUDA device to use)
-numdevices=<i> (where i=(number of CUDA devices > 0) to use for simulation)
-compare (compares simulation results running once on the default GPU and once on the CPU)
-cpu (run n-body simulation on the CPU)
-tipsy=<file.bin> (load a tipsy model file for simulation)
> NOTE: The CUDA Samples are not meant for performance measurements. Results may vary when GPU Boost is enabled.
> Windowed mode
> Simulation data stored in video memory
> Single precision floating point simulation
> 1 Devices used for simulation
MapSMtoCores for SM 7.5 is undefined. Default to use 64 Cores/SM
GPU Device 0: "GeForce RTX 2060 with Max-Q Design" with compute capability 7.5
> Compute 7.5 CUDA device: [GeForce RTX 2060 with Max-Q Design]
30720 bodies, total time for 10 iterations: 69.280 ms
= 136.219 billion interactions per second
= 2724.379 single-precision GFLOP/s at 20 flops per interaction
フィードバック¶
皆さんからのフィードバックが私たちとって重要です。皆さんのフィードバックをお伝えいただくには、 Docker Desktop for Windows GitHub リポジトリで、 WSL 2 ラベルを追加ください。
参考
- Docker Desktop WSL 2 backend