この記事の目的
Dockerは便利ですが
Windows環境で
- npm installが遅い
- ホットリロードが遅い
- ビルドが異常に遅い
のような 開発体験の劣化 が起きがちです。
本記事は
遅い理由を説明しつつ
原因別に対策をチェックリスト化したものです。
先に結論 まず疑う順
- bind mountのI Oが遅い
- ファイル監視が過剰でCPUが燃える
- ボリュームと依存関係の置き場所が悪い
- ビルドキャッシュが効いていない
- そもそもWSL2の設定が弱い
この順で潰すと効率が良いです
よくある症状と原因
bind mountがボトルネック
症状
- node_modulesを含む状態でホストをマウントしている
- 触ってないのにCPUが上がる
なぜ起きる
大量の小さなファイルアクセスが
ホストとコンテナ間で頻発し
I Oが支配的になります。
対策
- node_modulesはコンテナ側に置く
- ソースだけをマウントし 依存はvolumeに逃がす
例の考え方
- ./src はマウント
- /app/node_modules はnamed volume
監視方式が合っていない
症状
- Vite Next.js Webpackでホットリロードが遅い
- 監視が落ちる
なぜ起きる
ファイルイベントが拾えない環境では
ポーリングにフォールバックし
CPUとI Oを使い切ります。
対策
- watch設定でポーリング間隔を調整
- 監視対象を絞る
- 生成物 .next dist を監視対象から除外
Dockerfileのレイヤーが悪い
症状
- 変更のたびに npm install が走る
なぜ起きる
package.jsonが頻繁に変わるレイヤーと
アプリコードのレイヤーが混ざると
キャッシュが毎回破棄されます。
対策
- 依存インストールは package.json と lock を先にCOPY
- その後にソースをCOPY
開発用と本番用が混ざっている
症状
- 開発でも本番buildを毎回している
対策
- dev用composeとprod用composeを分ける
- devはホットリロードを最優先
WSL2のディスク位置が悪い
症状
- Windows側のパスで作業している
なぜ起きる
WSL2のLinuxファイルシステムと
Windowsファイルシステムの間のアクセスは
追加コストが発生しがちです。
対策
- 可能ならLinux側のパスにプロジェクトを置く
最低限の改善テンプレ
node_modulesをvolumeへ
考え方
- ソースはマウント
- 依存はvolume
これでI Oが劇的に改善することが多いです
ビルドキャッシュを効かせる
- lockファイルが変わらない限り依存インストールを再実行しない
まとめ チェックリスト
- node_modulesをbind mountしていない
- 生成物ディレクトリを監視対象から除外した
- Dockerfileで依存レイヤーが分離されている
- devとprodのcomposeが分かれている
- 可能ならWSL2側のパスで作業している
この5つだけでも
WindowsでのDocker開発の体感はかなり改善します