bon now

Windows10(Surface Pro4)でWSL+Dockerを利用した開発環境を構築したときに困ったDocker遅すぎ問題についてメモする。

何が起こった

WSLとはWindowsでLinuxが使える仕組みである。ディレクトリはWindowsとLinuxで別れていて、Linux側にWindowsのファイルシステムがmountされてる形で参照できるようになっている。そのため普段ユーザーが使うGUIはWindowsのディレクトリであるため、WSL上のファイルやディレクトリを参照するには少しコツがいるか、そもそもできないかという感じだ。
そしてこのマウント、ある程度ファイルやディレクトリ数が多くなってくるとかなり行き来に時間がかかるようになる。そのため、ディレクトリはWindows側の状態でDockerでNode系のサービスを動かそうとすると、とんでもないファイル数&ディレクトリ数となったnpm_moduleあたりの開発モードにおけるホットリロードが動かないとかディレクトリ差分検知が遅すぎてヤバすぎるとかいう問題が発生する。
まともにDockerコンテナが立ち上がるまでにカップラーメンができるレベルになってしまいフラストレーションが溜まるようになる。発狂しそうだ。

解決策とその他おすすめ

いろんなWebサイトを見たけど、唯一の解決策は サービスのディレクトリをWSLのディレクトリへ置くこと であった。
参考: https://dev.to/orama254/how-to-fix-the-nextjs-hmr-hot-reload-not-working-error-on-wsl2-51c

割とマジで世界が変わるので、 /mnt/c/xxx とか /c/xxx とかにリポジトリおかず、 ~/ 配下においてしまおう。
ただこの状態だとVSCodeから編集するのめんどくさくない？という意見があがるだろう。そういう人のためのVSCodeの機能拡張がある。それが Remote WSL だ。
これに加えて windows terminal を使えば、タブでTerminalが起動できるしウィンドウ分割もできるのである程度は柔軟にWSLを扱うことができる。基本的にはWindows TerminalでVSCodeで開きたいディレクトリ配下へ移動したあと code . と入力してEnterすれば勝手にそのディレクトリ配下をカレントディレクトリとした状態でVSCodeが立ち上がってくる。これだけ。

あとは爆速のnode_moduleを利用したサービスのコンパイルやホットリロードの恩恵を受けることができる。飛ぶぞ。

まとめ

WindowsもだいぶLinux環境のサービス開発が楽になった印象はあったものの、WindowsとWSLを良い感じにバランス良く使うというのはやはり厳しく、基本的にはWSLに寄せた開発環境を構築することが望ましいということがわかった。

ちなみにnode系のサービスでない場合は実はそんなに激遅になるということはない。ただ、node系のサービスとそうでないサービスでそれぞれディレクトリを行き来するのは面倒だと思うので、WSL側に寄せたほうが無難ではあると思う。