Day5：開発効率化（マウント）中盤
テーマ：マウントを“実務で使えるレベル”に深掘りし、COPY との違い・ホットリロードの仕組み・具体的な開発例を理解する
中盤では、前半で学んだ
「マウント＝ホストとコンテナのフォルダ同期」
をさらに実務レベルへ引き上げます。
ここを理解すると、あなたは
Docker を使いながらローカル開発と同じスピードで作業できるエンジニア
になります。
マウントと COPY の違いを深掘りする
COPY は「ビルド時に1回だけコピー」
Dockerfile の COPY は、イメージを作るときに
ホスト → イメージへファイルをコピーするだけ
です。
COPY . /app
これは ビルド時の一回限り で、
その後ホストでコードを変更しても、コンテナには反映されません。
マウントは「実行中ずっと同期し続ける」
docker run -v $(pwd):/app node
これは、
ホストのフォルダとコンテナのフォルダをリアルタイムで同期する
という動作です。
つまり：
- COPY → “一度だけコピー”
- マウント → “ずっと同期し続ける”
この違いが、開発効率に大きな差を生みます。
ホットリロードが実現する仕組みを理解する
ホットリロードは「マウント＋自動再起動ツール」で成立する
マウントだけでは「ファイルが更新される」だけです。
アプリは自動で再起動しません。
そこで使うのが nodemon（Node.js） や watchdog（Python） などの
“変更検知ツール” です。
Node.js の例
docker run -v $(pwd):/app -w /app node npx nodemon app.js
動作の流れ：
- ホストで app.js を保存
- マウントによりコンテナ内の /app/app.js も更新
- nodemon が変更を検知
- アプリを自動再起動
- ブラウザを更新すると即反映
これが 「コード変更 → 即反映」 の正体です。
実務でよくある“マウントの落とし穴”を深掘りする
落とし穴①：コンテナ内のファイルが上書きされる
マウントはホストを優先するため、
コンテナ内の /app に元々あったファイルは ホストの内容で上書き されます。
例：
Dockerfile で /app に何か置いていても、
マウントするとホストのフォルダで上書きされます。
→ 開発用と本番用で Dockerfile を分ける理由の1つ
落とし穴②：Windows と Mac ではパスの書き方が違う
前半で使ったコマンド：
docker run -v $(pwd):/app node
これは Mac / Linux の書き方です。
Windows（PowerShell）では：
docker run -v ${PWD}:/app node
OS によって書き方が違うため、
README に明記しておくと他の人が迷いません。
落とし穴③：node_modules をマウントすると壊れる
Node.js のプロジェクトでよくある問題です。
-v $(pwd):/app
をすると、ホスト側の node_modules がコンテナに反映されます。
しかし、
ホストとコンテナでは OS が違うため、ネイティブモジュールが壊れる
ことがあります。
対策：
- node_modules はマウントしない
- コンテナ内で npm install する
- docker-compose.yml で node_modules を匿名ボリュームにする
volumes:
- /app/node_modules
これでホスト側の node_modules を無視できます。
実務で使う“マウントのベストプラクティス”
1. 開発用と本番用の Dockerfile を分ける
開発用：マウント＋ホットリロード
本番用：COPY＋マルチステージビルド
2. docker-compose.yml でマウントを管理する
毎回 docker run を書くのは非効率なので、
Compose にまとめます。
services:
api:
build: .
volumes:
- .:/app
command: npx nodemon app.js
3. node_modules はマウントしない
壊れる原因になるため、匿名ボリュームで隔離する。
中盤まとめ
あなたがここまで理解できていれば、中盤はクリアです。
- COPY とマウントの違いを説明できる
- ホットリロードは「マウント＋変更検知ツール」で成立する
- node_modules をマウントすると壊れる理由を理解している
- OS によってマウントの書き方が違うことを知っている
- docker-compose.yml にマウントをまとめるのが実務的