Docker | 2週間で実務レベルに到達するDocker学習:開発効率化(マウント)(Day5)

Docker Docker
スポンサーリンク

Day5のさらに深掘り:マウントとホットリロードの“プロレベル理解”

Day5は「開発効率化」がテーマですが、ここを深掘りすると
Dockerを使った開発がローカル開発と同じスピードで動く理由
が完全に理解できます。

そして、ここを理解しているかどうかで
“Dockerを使える人” と “Dockerを使いこなせる人” の差が生まれます。


マウントの正体をもう一段深く理解する

コンテナのファイルシステムは「レイヤー構造」

Dockerのファイルシステムは、
読み取り専用のレイヤー(イメージ)
書き込み可能なレイヤー(コンテナ)
の組み合わせでできています。

しかし、マウントを使うとこの構造が変わります。

コンテナの /app に対して
ホストのフォルダをマウントすると、
コンテナの書き込みレイヤーよりも優先される“外部ファイルシステム”が差し込まれる
という状態になります。

つまり、
コンテナの /app はもはやコンテナのものではなく、
ホストのフォルダそのものです。

これが「ホストの変更が即コンテナに反映される」理由です。


マウントは“同期”ではなく“共有”である

よくある誤解:同期しているわけではない

初心者がよく言うのが
「ホストとコンテナが同期されている」
という表現ですが、正確には違います。

同期ではなく、
コンテナがホストのフォルダを直接参照している
だけです。

つまり、
ホストのファイルを変更した瞬間、
コンテナは“変更されたファイルを読み直す”だけで、
同期処理は存在しません。

この理解があると、
「なぜホットリロードが即時反応するのか」
が腑に落ちます。


マウントの衝突と優先順位(実務で重要)

COPY とマウントが同じパスを使うとどうなるか

Dockerfile で COPY . /app としていて、
docker run -v $(pwd):/app とすると、
COPY で入れたファイルは 完全に上書きされて見えなくなります

理由は、
マウントが COPY より優先されるからです。

実務ではこれを知らずに
「COPY したはずのファイルが見えない」
というトラブルがよく起きます。


マウントの“片方向性”を理解する

ホスト → コンテナ は反映される

コンテナ → ホスト は反映される(ただし危険)

マウントは双方向です。
つまり、コンテナ内でファイルを変更すると、
ホスト側のファイルも書き換わります。

これは便利ですが、
コンテナ内で誤って rm -rf するとホストのコードも消える
という危険性もあります。

実務では、
「コンテナ内で編集しない」
というルールが徹底される理由がここにあります。


マウントとパフォーマンス問題の深掘り

Mac と Windows は“仮想化層”がある

Docker Desktop は
Linux のコンテナを動かすために
内部で仮想マシンを使っています。

つまり、
ホスト(Mac/Windows)
→ 仮想マシン(Linux)
→ コンテナ
という構造になっています。

このため、
ホストとコンテナ間のファイル共有は
仮想化層をまたぐため遅くなる
という問題があります。

特に Node.js のように大量の小さなファイルを扱う場合、
パフォーマンスが落ちることがあります。


実務で使われる“最適なマウント構成”

コードだけマウントし、依存関係はコンテナに閉じ込める

Node.js の例で説明すると、
次の構成が最も安定します。

Dockerfile で
package.json → npm install
を実行し、
node_modules をコンテナ内に置く。

docker run では
-v $(pwd):/app
でコードだけマウントする。

こうすると、
node_modules の大量ファイルをマウントしなくて済むため、
パフォーマンスが大幅に改善します。


ホットリロードの“限界”と“改善策”

限界:ファイル変更イベントが拾えないケースがある

特に Mac では、
ファイル変更イベントがコンテナに届かないことがあります。

これは Docker Desktop の仕様によるもので、
Node.js の nodemon や Python の uvicorn が
変更を検知できないことがあります。

改善策:polling モードを使う

nodemon なら
--legacy-watch
uvicorn なら
--reload --reload-dir /app
など、
ポーリング(定期チェック)モードを使うことで改善できます。


マウントを使った“プロの開発環境構築”の考え方

1. 依存関係はコンテナに閉じ込める

2. コードだけマウントする

3. ホットリロードツールを使う

4. コンテナ内で編集しない

5. 本番環境ではマウントを使わず COPY を使う

この5つを守ると、
Dockerを使った開発が非常に快適になります。


Day5の深掘りまとめ

マウントは
コンテナのファイルシステムをホストのフォルダで置き換える技術
であり、
ホットリロードはその仕組みの上に成り立っています。

マウントの優先順位、
パフォーマンス問題、
COPY との衝突、
双方向性の危険性、
ホットリロードの限界と改善策。

これらを理解していると、
Dockerを使った開発で困ることがほぼなくなります。

タイトルとURLをコピーしました