第14章:bind mount と volume の違い(使い分け判断)⚖️
この章は「どっちを使えばいいか迷わない人」になる回です😊✨ 結論だけ先にいうと——
- ソースコード(ホストで編集して即反映したい)➡️ bind mount 📎
- DBデータ(消えたら泣くやつ)➡️ volume 🧱
- 大量I/Oや安定した永続化➡️ volume が強い💪 (Docker Documentation)
1) まずは“超ざっくり”違いを掴もう😄🧠
bind mount(バインドマウント)📎
- ホストのフォルダをそのままコンテナに見せる方式
- ホストで編集すると、コンテナ側に即反映⚡(開発に超便利)
- ただし、ホストのパスに強く依存する(別PCだと動かないことも) (Docker Documentation)
- デフォルトで書き込み可能なので、コンテナからホストを壊せる危険もある(なので
roが大事な場面あり) (Docker Documentation)
volume(ボリューム)🧱
- Dockerが管理する保存領域をコンテナに接続する方式
- ホストの任意の場所を直接触る感じではなく、Docker側が面倒みる (Docker Documentation)
- バックアップ/移行がしやすい、I/Oが速い、複数コンテナで安全に共有しやすい (Docker Documentation)
- “消えたら困るデータ”の置き場として超定番(DBなど)🛡️
2) Windows + WSL2 での“めちゃ重要注意”🪟⚠️
bind mount は便利なんだけど、置き場所を間違えると遅くて泣くやつがあります🥹
- Windows側のパス(例:
/mnt/c/...)をLinuxコンテナにbind mountすると、パフォーマンスが落ちやすい - さらに、ファイル監視(ホットリロード等)が inotifyイベントを受け取れないケースがある
- なので、ソースコードは WSL(Linuxファイルシステム)側に置くのが推奨 ✅ (Docker Documentation)
イメージ👇
- ❌ 遅くなりやすい:
/mnt/c/Users/.../project - ✅ 推奨:
~/projects/todo-api(WSLのhome配下)
3) ハンズオン①:bind mount を体で覚える📎🔥
ゴール🎯
「ホストで編集 ↔ コンテナで反映」が一瞬で分かるようになる⚡
手順A:準備(WSLターミナルで)🧑💻
cd ~/projects/todo-api # 自分のTodo APIフォルダ(WSL側)にいる想定
mkdir -p playground/bind-demo
echo "hello from host" > playground/bind-demo/note.txt
手順B:bind mount してコンテナ起動🐳
※公式的にも --mountの方が分かりやすく推奨されがち👍 (Docker Documentation)
docker run --rm -it --name bind-demo \
--mount type=bind,src="$(pwd)/playground/bind-demo",dst=/demo \
alpine sh
手順C:コンテナ内で確認🔍
ls -la /demo
cat /demo/note.txt
echo "hello from container" >> /demo/note.txt
exit
手順D:ホスト側で確認(追記されてるはず)✅
cat playground/bind-demo/note.txt
ポイント🎯 bind mount は「同じファイルを両方が触ってる」感じ!📎✨
4) ハンズオン②:volume を体で覚える🧱🔥
ゴール🎯
「コンテナ消してもデータが残る」を一発で体験する💾✨
手順A:ボリューム作成🧱
docker volume create todo-demo-vol
手順B:ボリュームをマウントして起動🐳
docker run --rm -it --name vol-demo \
-v todo-demo-vol:/data \
alpine sh
手順C:コンテナ内でデータ作成✍️
echo "saved in volume!" > /data/note.txt
exit
手順D:別コンテナで“同じvolume”を見に行く👀
docker run --rm -it -v todo-demo-vol:/data alpine sh -lc "cat /data/note.txt"
出た!「saved in volume!」🎉
コンテナは--rmで消えてるのに、データは残ってる=これがvolumeの強さ💪 (Docker Documentation)
5) ここが“使い分け”の核心⚖️😆
使い分け早見(まずはこれだけでOK)✅
- 🧑💻 ホストで編集したい(TSコード、設定ファイル、READMEなど) ➜ bind mount 📎
- 🛡️ 消えたら困る(DB、アップロード、キャッシュでも“残したい系”) ➜ volume 🧱
- 🐢 I/Oが重い(DB、検索インデックス、ビルドキャッシュ的なやつ) ➜ volumeが有利(コンテナの書き込みレイヤより速いことが多い)(Docker Documentation)
- 🧳 別PC/CIでも同じように動かしたい ➜ volume寄り(bindはホストパス依存でコケやすい)(Docker Documentation)
6) 判断フローチャート(文章版)🌳🤖
-
Q1:ホスト(VS Code)で直接編集したい?
- YES ➜ bind mount 📎(例:
./src:/app/src) - NO ➜ Q2へ
- YES ➜ bind mount 📎(例:
-
Q2:消えたら困る?(永続化したい?)
- YES ➜ volume 🧱(例:
pgdata:/var/lib/postgresql/data) - NO ➜ Q3へ
- YES ➜ volume 🧱(例:
-
Q3:速さ(大量I/O)を優先したい?
- YES ➜ volume 🧱 (Docker Documentation)
- NO ➜ どっちでもOK(ただし次の罠だけ注意!)
7) “初心者あるある罠”まとめ🪤😵
罠1:bind mount で「元から入ってたファイル」が消えたように見える😇
bind mount は、**コンテナ内の既存ファイルを“上から隠す”**動きがあります。 一回マウントすると、下にあったファイルは見えなくなる感じ…! (Docker Documentation)
- 例:
/appにアプリが入ってるイメージなのに、-v .:/appしたら中身が変になった! 👉 原因:ホストの.が/appを覆い隠してる
罠2:bind mount はデフォルトで“書ける”📎✍️(危険もある)
コンテナがホストのファイルを削除できるので、やばい場面では読み取り専用にするのが安心👍
readonly / ro が使えます (Docker Documentation)
docker run --rm -it \
--mount type=bind,src="$(pwd)/playground/bind-demo",dst=/demo,readonly \
alpine sh
罠3:-v は“無いフォルダを勝手に作る”ことがある😵💫
-v(--volume)でbind mountすると、ホスト側のパスが無いとディレクトリを作っちゃう挙動があります。
--mountは無ければエラーで止まるので、ミスに気づきやすい👍 (Docker Documentation)
8) Composeでの典型パターン(超よく見るやつ)🧩✨
services:
api:
build: .
volumes:
- ./:/app # 📎 bind mount:ソースコードを即反映したい(開発向け)
db:
image: postgres:16
volumes:
- pgdata:/var/lib/postgresql/data # 🧱 volume:DBデータを守る
volumes:
pgdata:
./:/appみたいな パス指定 ➜ bind mount 📎pgdata:/...みたいな 名前指定 ➜ volume 🧱
9) AI活用(この章の“使える”聞き方)🤖✨
そのままコピペでOKなやつ置いとくね😄👇
-
判断を一撃で固める💡
- 「ソースコード、DB、ログ、アップロード、キャッシュがある。各データは bind mount / volume のどっちが良い?理由も短く。」
-
Composeレビューしてもらう👀
- 「このcompose.ymlのvolumes設計、初心者がハマりそうな点を3つ指摘して、直し案も出して。」
-
WSL/Windows特有の注意点をまとめさせる🪟
- 「Windows + WSL2 + Docker Desktop で bind mount が遅くなる条件と回避策を箇条書きで。」
10) 理解チェッククイズ(3問)📝😆
Q1
TSのソースコードをVS Codeで編集して、コンテナの実行に即反映したい。どっち? ➡️ 📎 / 🧱
Q2
PostgreSQLのデータ。コンテナ消しても残したい。どっち? ➡️ 📎 / 🧱
Q3
「このコンテナ、ホストのファイルを消しそうで怖い…」安全寄りにするには?(一言で) ➡️ _____
✅ 解答🎉
- A1:📎 bind mount
- A2:🧱 volume
- A3:read-only(
ro/readonly)でマウント (Docker Documentation)
次章につながる一言📦😮
次はついに node_modules問題! 「依存をどこに置くのが地雷回避か」ってやつで、ここでの bind vs volume 判断がそのまま効いてきます😆🔥