g00chyの技術ブログ

Docker for windowsが重たいので対応した

目次

Docker for DesktopをWSL2形式で使用し、開発を行っていたのですが、あまりにもレスポンスが遅かったため調査し、対応内容と結果を書きます。

結論

WindowsでDocker for windowsを使用している人は、Windows側にファイルを配置するのではなく、デフォルトのWSL2VMにファイルを配置しましょう。
また、HUGOなどのファイル変更を受けて動く場合もちゃんと変更を検出してファイルを変えてくれますので、絶対にWSL2側に置きましょう。

環境

  • OS:Windows10 Pro
  • CPU: Ryzen 2400G
  • Docker for windows(WSL2)
docker --version
Docker version 19.03.13, build 4484c46d9d

調査

状況は元々どうだったのか

ファイルは、Windows10側に配置しておりました。
そこで下記のテンプレートを使い、Laravelの開発を行っていたのですが、DB操作もないのにもかかわらず、Laravelを使用したところ、6秒程度レスポンス開始までに時間がかかっている状態でした。

Pi4にファイルをデプロイして、動かすとレスポンスは数ms程度で開始されていたので、「これはあかん」となって調べました。

原因

docker-compose up すると、Windowsの通知で、perform poorlyと表示されてはいました。
これをクリックすると、それまでリンクが開けなかったのですが、とあるときに開けるようになりました。
開くとこのページDocker Desktop WSL 2 backend | Docker Documentationが出てきました。

つまり、

  • dockerを動かすときに、windows側にファイル置いてたらすげぇ遅いよ?
  • WSL2のデフォルトOSにファイルを配置したらいい。

ということですね。

対処法

ファイルの移動

WSL2のデフォルトのVMで下記を行います。

explorer.exe .

こちらを実行すると、デフォルトVMディレクトリをWindowsで開けます。
なので、Windows側のファイルをそのディレクトリに配置します。

コンテナの停止

コンテナを再生成しても、同一のディレクトリを読んだりすると面倒なので、すでにあるコンテナをすべて削除しておきます。
誤って、buildxのコンテナを削除しないように注意します。

docker ps -a
docker stop container_ids
docker rm container_ids

それ以後

ファイル編集するのは、WSL2上のファイルに対して行って下さい。
コンテナの操作に関しては、WSL2上で行えばいいです。

最後に

なんでかなーと思って探し始めるまでに、時間をおいてしまいましたので時間を無駄にしてしまいました。 早くなった後は、「これだったらもっと早めにやっていれば」と若干後悔。


Share

comments powered by Disqus