今更ながら WSL2 移行作業とか

最先端を追えてない

環境

Windows10 Pro (ホスト)
=> VMware + Windows10 Pro (ゲスト) ←ここに WSL2 環境を作る

既に WSL を利用しており、ubuntu 18.04 をインストールしている。

諸設定

基本

WSL の update のためのパッケージを以下からダウンロードし、インストール
docs.microsoft.com

管理者権限で PowerShell を起動し、以下のコマンドを実行。
どうしても GUI から操作したければ [Windows の機能の有効化または無効化] からでも可。

$ Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
$ Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

将来的に ubuntu 20.04 とか使いそうだなぁと思ったので、
次回以降のディストロに適用するデフォルトを WSL2 にする。

$ wsl --set-default-version 2

既に存在するディストロ (Ubuntu-18.04) のバージョンを WSL2 にする。
ディストロの名前を調べたければ wsl -l で。
このコマンドの実行には長時間かかる可能性がある。

$ wsl --set-version Ubuntu-18.04 2

apt 経由でパッケージを最新状態にする。

$ sudo apt update && sudo apt upgrade

WSL2 のチューニング

Windows の PATH を WSL2 に通さないようにします。

$ nano /etc/wsl.conf

# 以下を追加
[interop]
appendWindowsPath = false

また、WSL2 はファイルシステムEXT4 であり、Windows (NTFS) のものと違うことがおそらく原因で、
特定のドライブを WSL2 にマウントして、当該ドライブ上に開発対象のファイルを置いたりすると極端に速度が遅くなります。
開発するファイルを全て WSL2 に移動し、VSCode 等のリモート拡張で操作するのがいいと思います。

# /e にマウントしていた develop ディレクトリを root 直下に移動。
# パーミッション等も保持したいので -a オプション付与。
$ sudo cp -a /e/develop /develop

WSL2 が際限なくメモリを消費し続けることは既に問題となっており(当該issue)、
WSL2 が占有するメモリの最大使用量を指定することで対処するような方向性で議論がまとまって以来、そのままだと思います。

# Windows 側の %USERPROFILE%\.wslconfig (C:\Users\{ユーザ名}\.wslconfig) で指定する

# 以下を追加(4GB を最大使用量とする例)
[wsl2]
memory=4GB
swap=0

docker desktop

docker を使えるようにします。
通常通り docker desktop の最新版をインストールします。
以下は特別に対応する項目です。

docker desktop の設定から、[User the WSL 2 based engine] をチェックを有効にします。
また、[Expose daemon on tcp://localhost:2375 without TLS] のチェックを外します。

次に、Resources > WSL INTEGRATION > [Enable Integration with additional distros:] のチェックを有効にし、
WSL2 で扱うディストロのトグルを有効にします。

また、[Expose daemon on tcp://localhost:2375 without TLS] を有効にして WSL1 を使っていたユーザは、
.bashrc 等で環境変数 DOCKER_HOST を指定する記述をしていたかと思うので、これをコメントアウトします。

$ nano ~/.bashrc
# export DOCKER_HOST=tcp://localhost:2375
# alias docker="DOCKER_HOST=${DOCKER_HOST} docker"

更に、sudo なしで docker-compose を実行できるように権限を与えておきます。

$ sudo gpasswd -a $USER docker

あと、考えてみりゃ当然ですが、docker-compose.yml で ${PWD} が使えなくなってました。
素直に . を指定しましょう。
(WARNING: The PWD variable is not set. Defaulting to a blank string. が出ました)

また、docker-compose up 時に StoreError('docker-credential-desktop.exe not installed or not available in PATH',) といったエラーが発生しました。
Windows の PATH を通してないはずなんだけどなぁと思いつつ、以下のファイルを削除することで対応しました。

$ rm ~/.docker/config.json

その他

エクスプローラで WSL2 内を確認したい場合、\\wsl$ をアドレスバーに入力することで閲覧できます。
(ナビゲーションバーが自由に編集できないので、クイックアクセスに追加することで対応しました)
エクスプローラアプリの導入を真剣に考える機会か)

xdebug 3

いつの間にか 2 からメジャーアップデートされていて、2 の設定のままではどうにも動かなくなっていた。
xdebug 公式のページで 2 から 3 へ変更する際の設定項目の対応が記述されている。

リモートデバッグを利用する際、クライアント側のホストは host.docker.internal のままで問題がないのだが、
VSCodeデバッグをする場合は hostname の設定が必要になった。

# launch.json に追加
"hostname": "0.0.0.0",

profiler とかはまだ不要だったので、とにかくデバッガ動かしたかった俺の設定は以下になった。

// xdebug.ini
zend_extension=/usr/lib64/php/modules/xdebug.so
xdebug.mode=develop,debug
xdebug.remote_handler=dbgp
xdebug.client_host=${CLIENT_HOST}
xdebug.client_port=${XDEBUG_PORT}
xdebug.start_with_request=yes
xdebug.log="/var/log/httpd/xdebug.txt"
xdebug.idekey="${XDEBUG_IDEKEY}"

// env file
XDEBUG_PORT=9201
XDEBUG_IDEKEY=Listen for XDebug
CLIENT_HOST=host.docker.internal

nil

WSL1 と比較して、開発環境がかなり高速に動作するようになった。
stopwatch はない。

これだけファイルアクセス早くなるんなら Symfony 3.4 とかのキャッシュ地獄もすごく快適になるんだろうなぁと