第06章：データの置き場所を“図”で描けるようにする🗺️
この章のゴールはシンプルです👇 「このデータ、どこにあるの？」を“図”で即答できるようになること！😎📌 （ホスト側？コンテナ内？それともvolume？🤔）
6-1. まず“3つの箱”だけ覚える📦📦📦
データの居場所は基本この3つだけです👇
- ホスト（Windows） 🪟
- コンテナ（Linuxの中のフォルダ） 🐳
- volume（Dockerが管理する永続領域） 🧱 volumeは「Dockerが管理する永続化の推奨手段」って位置づけです。(Docker Documentation)
ここで超重要なのは👇 “マウント”は「どこから → どこへ」の矢印ってことです➡️
- Source（元）: ホストのパス or volume名
- Target/Destination（先）: コンテナ内のパス
6-2. 図にするための“読み取りルール”🧠🧩
Composeの volumes: は、基本この2種類👇
A) bind mount（ホストのフォルダ直結）🔌
例：./host-files:/bind
- Source = ホストのフォルダ
- Target = コンテナ内パス
- 特徴：コンテナ内の既存ファイルが“隠れる”ことがある（事故ポイント⚠️）(Docker Documentation)
B) named volume（Docker管理の金庫）🏦
例：toy-vol:/vol
- Source = volume名（Dockerが管理）
- Target = コンテナ内パス
- 特徴：どこに保存されてるかはDocker側が管理（ホストのパスを前提にしない）(Docker Documentation)
6-3. “volume名が思ったのと違う”を防ぐコツ🧷😇
Composeは、プロジェクト名を使って volume や network に「接頭辞」を付けがちです。 デフォルトのプロジェクト名は「Composeファイルがあるディレクトリ名」になりやすいです。(Docker Documentation)
なので、図を安定させたいなら👇
Composeファイルのトップに name: を置くのが便利です✨
（これが“プロジェクト名”として使われます）(Docker Documentation)
6-4. ハンズオン：10分で“1枚図”を完成させる✍️🔥
① フォルダを用意📁
プロジェクト直下にこう作るイメージ👇
-
compose.yaml -
host-files/hello.txt（中身は何でもOK）
② compose.yaml を作る🧩
（ポイント：bind と volume を両方入れる）
name: datamap
services:
toy:
image: alpine:latest
command: sh -c "echo 'toy started 🐣' && tail -f /dev/null"
volumes:
- ./host-files:/bind
- toy-vol:/vol
volumes:
toy-vol:
✅
name: datamapを入れたので、後でdatamap_toy-volみたいな名前になっても納得しやすいです🧠✨（仕組みは公式のプロジェクト名仕様に沿います）(Docker Documentation)
③ 起動する▶️
PowerShellでOKです👌
docker compose up -d
docker compose ps
④ 中でファイルを作って“居場所”を体感する🧪📌
volume側（永続化される箱）🏦
docker compose exec toy sh -lc "echo 'I live in VOLUME 🧱' > /vol/from-container.txt && ls -la /vol"
bind側（ホスト直結）🔌
docker compose exec toy sh -lc "echo 'I live in BIND 🔌' > /bind/from-container.txt && ls -la /bind"
そしてホスト側（Windows）で host-files/from-container.txt が増えてたら成功🎉🪟
⑤ “答え合わせ”：docker inspectでMountsを見る🔎
コンテナ名を取って👇
docker compose ps
出てきた datamap-toy-1 みたいな名前を使って👇
docker inspect datamap-toy-1 --format '{{json .Mounts}}'
ここに Type / Source / Destination が出ます。 この3点が取れたら、図は100%描けます✍️✨
6-5. ついに完成：1枚図テンプレ（この形に当てはめるだけ）🗺️🧠
今回の例だと、こうなります👇（手書きでもこの形でOK✍️）
┌──────────────────────────┐
│ Host (Windows) │
│ ./host-files │
└───────────┬──────────────┘
│ bind mount 🔌
▼
┌─────────────────────────────────────────────────┐
│ Container: toy 🐳 │
│ /bind ←─────────────── (host-files) │
│ /vol ←─────────────── (named volume) 🧱 │
└─────────────────────────────────────────────────┘
▲
│ named volume 🧱
┌───────────┴──────────────┐
│ Volume (Docker-managed) │
│ toy-vol (実体はDocker側) │
└──────────────────────────┘
「Source → Destination」が見えれば勝ちです😎🏁
6-6. 図があると防げる“事故”3選🧯😱
事故1：マウントしたら元のファイルが消えた！？🫠
**消えたんじゃなくて“隠れた”**パターンです。 bind mount で、コンテナ内にもともとあるデータの上に被せると、既存データが見えなくなります。(Docker Documentation) 👉 図で「そこに被せてる」って分かると一発で気づけます🧠💡
事故2：volume名が見つからない🔎💦
Composeはプロジェクト名を使って命名するので、想像とズレることがあります。
プロジェクト名の決まり方／上書き方法（-p や COMPOSE_PROJECT_NAME、name:）は公式にまとまってます。(Docker Documentation)
👉 図に「project名」も書くと迷子になりません🧷
事故3：永続化してるつもりが、コンテナ内だった😇
volumeはDocker管理の永続領域で、永続化の推奨手段です。(Docker Documentation) 👉 図で「/var/lib/... は volume に刺さってる？」みたいに確認できます✅
6-7. 仕上げチェックリスト✅✅✅
図を描いたら、最後にここだけ確認👇
- 全部のマウントに「Source → Destination」が書けてる？✍️
- bind と volume を混ぜてない？（bind=ホストパス、volume=名前）🔌🧱
-
docker inspectの Mounts と図が一致してる？🔎 - Composeの
name:（プロジェクト名）を書いた？🧷
6-8. AIに手伝わせる（安全に）🤖🛡️✨
GitHub Copilot や OpenAI Codex に、こう投げるとめちゃ速いです👇
- 「この compose.yaml の volumes から Source/Destination/Type を抜き出して」
- 「抜き出した結果を元に ASCII図（箱と矢印）で描いて」
- 「事故りそうなマウント（上書き/隠れる系）を指摘して」
※ .env や秘密情報は貼らないでね🔒🙂
この章の成果物🎁
✅ ホスト / コンテナ / volume の対応図（1枚）
✅ docker inspect で “図の答え合わせ” ができる状態🔎✨
次の章（DBのデータディレクトリ系🐘）に入ると、ここで描いた図がそのまま武器になります💪🔥
必要なら、あなたの実プロジェクトの compose.yaml（秘密抜きで）を貼ってくれたら、こっちで“図化”テンプレに落とし込みますよ✍️🗺️