Windows で Docker が遅い時は、まずソースコードの置き場所を疑う
Windows + Docker Desktop + WSL2 で開発していると、
「Docker が妙に遅い」
「npm install が重い」
「Vite や React の起動がもっさりする」
「ファイル変更の反映が遅い」
ということがあります。
Docker Desktop 自体が重いのか、コンテナの設定が悪いのか、PC スペックの問題なのか……と疑いたくなりますが、
実際には ソースコードを Windows 側のファイルシステムに置いていること が原因になっているケースがあります。
この記事は、Windows + WSL2 + Docker + VS Code で開発していて、Docker 周りの遅さにハマったときの切り分けメモです。
結論
Windows で Docker が遅い場合、まずプロジェクトの置き場所を確認します。
pwd
以下のような場所で作業している場合は、Windows 側のファイルシステムを WSL から触っています。
/mnt/c/Users/xxxx/project
この状態で Docker の volume mount や npm install を行うと、ファイル I/O が遅くなりやすいです。
基本的には、プロジェクトは WSL 側の Linux ファイルシステムに置くほうが安定します。
/home/xxxx/project
自分の場合も、Docker や Node.js の問題というより、
Windows 側に置いたソースを WSL / Docker から扱っていたこと が大きな原因でした。
起きたこと
Windows 環境で Docker を使って開発していたところ、以下のような違和感がありました。
- Docker の起動やビルドが遅い
-
npm installが遅い、または不安定 -
npm run devやnpm run buildがもっさりする - Vite / React 系の開発サーバーが重く感じる
- ファイル変更の反映が遅い
-
node_modules周りで怪しい挙動が出る - VS Code で開いている場所と、WSL のターミナルで触っている場所の感覚がズレる
- Git で
unsafe repositoryのような警告が出ることがある
最初は Dockerfile や docker-compose.yml の書き方、Node.js のバージョン、npm の問題を疑いました。
ただ、冷静に見ると、プロジェクトを置いている場所が /mnt/c/... 側でした。
つまり、WSL を使っているつもりでも、実体としては Windows 側のファイルを WSL から操作している状態でした。
原因
WSL2 では、大きく分けて以下の2種類の場所があります。
# WSL側のLinuxファイルシステム
/home/xxxx/project
# Windows側のファイルシステムをWSLから見た場所
/mnt/c/Users/xxxx/project
どちらも WSL のターミナルから見ると Linux のパスに見えます。
しかし、実体はかなり違います。
/home/... は WSL 側の Linux ファイルシステムです。
一方、/mnt/c/... は Windows 側のファイルシステムを WSL から参照している場所です。
Docker や Node.js の開発では、小さいファイルを大量に読み書きします。
特に影響が出やすいのは以下です。
node_modules- npm install
- Vite / Webpack などの開発サーバー
- Docker の bind mount
- ファイル監視
- Git の操作
- composer / vendor など大量ファイルを扱う処理
このあたりは、Windows 側のファイルシステムをまたぐと体感できるレベルで遅くなることがあります。
確認すること
まず、プロジェクトディレクトリで現在地を確認します。
pwd
結果が以下のようになっていたら、Windows 側です。
/mnt/c/Users/xxxx/project
この場合、Docker が遅い原因としてかなり疑う価値があります。
逆に、以下のような場所なら WSL 側です。
/home/xxxx/project
Docker + WSL2 前提なら、基本的にはこちらに寄せたほうがよいです。
対策
1. プロジェクトを WSL 側に移す
Windows 側に置いているプロジェクトを、WSL 側へ移します。
mkdir -p ~/projects
cp -r /mnt/c/Users/xxxx/project ~/projects/
ただし、Git 管理しているプロジェクトなら、コピーより clone し直すほうがきれいです。
cd ~/projects
git clone git@github.com:example/example.git
移動先は例えば以下のような場所です。
/home/xxxx/projects/project
重要なのは、/mnt/c/... 配下に置かないことです。
2. VS Code は Remote - WSL で開く
WSL 側に置いたプロジェクトディレクトリで、以下を実行します。
code .
このとき、VS Code が Remote - WSL として開かれていれば、エディタ・ターミナル・拡張機能・Node.js 実行環境が WSL 側に揃います。
Windows 側の VS Code から \\wsl$ 経由で開くこともできますが、開発環境が混ざって分かりにくくなることがあります。
自分の場合も、Windows 側の VS Code と WSL 側の VS Code で、見えている環境や拡張機能の扱いが違って少し混乱しました。
Docker / npm / Git を WSL 側で動かすなら、VS Code も Remote - WSL に寄せたほうが素直です。
3. node_modules は作り直す
Windows 側で作った node_modules をそのまま WSL 側に持ってくると、環境差で壊れることがあります。
特に esbuild のように OS 別のバイナリを持つパッケージでは、Windows 側で入れたものと WSL 側で必要なものがズレることがあります。
移動後は、一度削除して入れ直します。
rm -rf node_modules
npm install
必要に応じて、lock ファイルも含めて切り分けます。
rm -rf node_modules package-lock.json
npm install
ただし、package-lock.json を消すかどうかはプロジェクトの運用方針次第です。
単に置き場所を直すだけなら、まずは node_modules の作り直しで十分です。
4. Docker Compose も WSL 側から実行する
プロジェクトを WSL 側に移したら、Docker Compose も WSL のターミナルから実行します。
docker compose up -d
compose ファイルやソースコードが /mnt/c/... にあると、volume mount でも Windows 側のファイルシステムを経由することになります。
例えば以下のような構成です。
services:
app:
volumes:
- ./:/app
この ./ が /mnt/c/... 配下を指していると、コンテナから見た /app の実体は Windows 側のファイルになります。
つまり、コンテナ内では Linux のように見えていても、ホスト側のファイル I/O で遅くなる可能性があります。
unsafe repository が出た場合
環境を移動したり、Windows 側と WSL 側の両方から Git リポジトリを触っていると、以下のような警告が出ることがあります。
fatal: detected dubious ownership in repository
この場合は、Git が「このリポジトリの所有者が想定と違う」と判断しています。
必要であれば、対象ディレクトリを safe.directory に追加します。
git config --global --add safe.directory /home/xxxx/projects/project
ただし、これは警告への対処です。
根本的には、Windows 側・WSL 側・\\wsl$ 経由のどこから触っているのかを整理したほうがよいです。
判断基準
ざっくり以下のように考えると分かりやすいです。
| 状況 | 置き場所 |
|---|---|
| Docker を使う | WSL側 /home/...
|
| npm install を頻繁に行う | WSL側 /home/...
|
| Vite / React / Node.js の開発 | WSL側 /home/...
|
node_modules がある |
WSL側 /home/...
|
| Docker の bind mount を使う | WSL側 /home/...
|
| Windows アプリだけで軽く編集する | Windows側でも可 |
Docker 開発では、基本的に ソースコードは WSL 側に置く でよいと思います。
ハマりどころ
WSL を使っている = WSL 側に置いている、ではない
ここが一番の落とし穴でした。
WSL のターミナルで作業していると、何となく Linux 側で作業している気になります。
しかし、現在地が /mnt/c/... なら、実体は Windows 側です。
pwd
で見るとすぐ分かります。
Docker が遅いのではなく、マウント元が遅いことがある
Docker 自体の問題に見えても、実際には bind mount しているホスト側ディレクトリが原因のことがあります。
特に以下のような構成では注意が必要です。
volumes:
- ./:/app
この . がどこを指しているかで、体感速度が変わります。
/mnt/c/... 配下なら Windows 側です。
/home/... 配下なら WSL 側です。
npm / esbuild / node_modules は環境差が出やすい
node_modules は、ただのテキストファイル群ではありません。
OS ごとのバイナリが含まれることがあります。
そのため、Windows 側で作った node_modules を WSL 側に持ってきたり、逆に WSL 側で作ったものを Windows 側で使ったりすると、壊れることがあります。
場所を変えたら、まず作り直すほうが早いです。
rm -rf node_modules
npm install
VS Code の開き方でも混乱する
Windows 側の VS Code で開いているのか、Remote - WSL で開いているのかによって、使われるターミナルや拡張機能が変わります。
特に、以下が混ざると分かりにくくなります。
- PowerShell
- WSL の bash
- Windows 側の Node.js
- WSL 側の Node.js
- Windows 側の Git
- WSL 側の Git
Docker や npm を WSL 側で動かすなら、VS Code も Remote - WSL に揃えるのが無難です。
まとめ
Windows で Docker が遅いと感じたとき、いきなり Dockerfile や Docker Desktop の設定を疑う前に、まずプロジェクトの置き場所を確認するとよいです。
pwd
以下なら Windows 側です。
/mnt/c/Users/xxxx/project
以下なら WSL 側です。
/home/xxxx/project
Docker + WSL2 + Node.js 系の開発では、基本的に WSL 側にソースコードを置くほうが安定します。
cd ~/projects
git clone git@github.com:example/example.git
cd example
npm install
docker compose up -d
自分の場合、Docker が遅い・npm が不安定・VS Code とターミナルの環境がズレる、という問題を追っていくと、最終的には Windows 側のファイルシステムに置いたプロジェクトを WSL / Docker から扱っていたこと が大きな原因でした。
WSL を使っているかどうかより、
プロジェクトの実体がどこにあるか
のほうが重要です。
Docker が遅いと感じたら、まず /mnt/c/... で作業していないかを見る。
地味ですが、これだけでかなり切り分けが進みます。