メインコンテンツまでスキップ

第11章：なぜファイル共有が必要？（コードはホスト、実行はコンテナ）🧩

この章でやることはシンプルです👇 「編集する場所（ホスト）」と「動かす場所（コンテナ）」を分けて、同じファイルを“共有”できる感覚をつかみます😊✨

1) まず結論：コンテナは“別のPC”みたいなもの🖥️➡️📦​

コンテナは、ホスト（Windows側）とは 別のファイル置き場 を持っています。 だからそのままだと…

  • VS Codeでホスト側のコードを直しても✍️
  • コンテナ側のコードは変わらない😵（別の世界だから）

そこで登場するのが ファイル共有（マウント） です📎✨ ホストのフォルダをコンテナへ“差し込む”ことで、同じファイルを見れるようになります。

2) イメージ図（文章図解でOK）🗺️✨​

[Windows(ホスト)側]            [コンテナ側]
  あなたが編集する場所              実行する場所
  (VS Codeで保存)✍️               (nodeが動く)🚀
      │
      │  bind mount（ファイル共有）📎
      ▼
  C:\... or \\wsl$\...   ←→   /work や /app など
      （同じ中身を見てる！）👀

ポイント

  • ホスト：編集が快適（VS Code/拡張/AI支援も使いやすい）🧑‍💻🤖
  • コンテナ：実行環境が揃う（Nodeのバージョン差・依存差が減る）📦✅

3) ハンズオン：ホストのファイルをコンテナから読む📖👀​

ここは「体感」が最強です🔥 ホストで保存した内容が、コンテナ側の表示に即反映されるのを見ます。

手順A：準備（フォルダ＆ファイル作成）📁📝​

  1. 任意の作業フォルダを作る（例：mount-demo）
  2. hello.txt を作って、こんな感じで書く👇
こんにちは！はじめてのファイル共有🌟

手順B：コンテナを起動して、ファイルを“ずっと読む”🔁🐳​

ターミナルで mount-demo に移動してから、これ👇

docker run --rm -it -v "$(pwd)":/work -w /work alpine:3.20 \
  sh -lc 'while true; do echo "----"; date; cat hello.txt; sleep 2; done'
  • -v "$(pwd)":/work が ファイル共有（bind mount） 📎
  • cat hello.txt が コンテナ側からファイルを読む 📖
  • 2秒ごとに読み直すので、変更が見えます👀✨

bind mount は「ホストのディレクトリをコンテナに共有できて、保存した変更がすぐ見える」用途に向いています。(Docker Documentation)

手順C：ホスト側でファイルを編集してみる✍️⚡​

VS Codeで hello.txt を開いて、内容を変えて保存👇

更新したよ！即反映キターーー🎉

すると…コンテナ側の表示が 次のループで変わる はずです😆✨ 止めるときは Ctrl + C でOK🛑

4) これが Todo API 開発で何に効くの？🧠🔧​

この後の章でやる Node/TypeScript API をコンテナで動かすときに、

  • ホストでコード編集（VS Codeが快適）✍️
  • コンテナで実行（node/npm環境が固定）🚀
  • 変更は 共有フォルダ経由で即反映 ⚡

という流れが作れます。 つまり 「コンテナ開発＝毎回ビルドし直し」 じゃなくて、いつもの開発テンポのままいけます🏃‍♂️💨

5) よくある勘違い3つ（先に潰す）🪤😵‍💫​

  1. 「コンテナの中にあるコードを直せばいいのでは？」 → もちろん可能。でも編集体験が落ちがち（エディタ/補完/AI支援/差分管理がやりにくい）😇 開発では「編集はホスト」が超強いです💪

  2. 「コンテナを消してもファイルは残るよね？」 → コンテナ内部に置いたものは、消すと消えます🧹 残したいものは 共有（bind mount） か volume に寄せます（次章以降でガッツリ）📦🛡️

  3. 「共有って危なくない？」 → 共有先に書き込みできる設定だと、コンテナからホストのファイルを書き換えられます✍️ だから「共有範囲は最小」にするのが基本ルールです📏✨

6) Windows + WSL2 の“超重要ワンポイント”🪟⚡​

ファイル共有は便利だけど、置き場所で体感速度が変わることがあります😵💦

  • C:\... を WSL から見ると /mnt/c/... になります
  • この Windows側のドライブをまたぐアクセスは、ケースによって遅くなりやすいです🐢
  • 逆に、プロジェクトを WSL 側（Linuxファイルシステム側）に置くと速くなりやすいです🚀

これは Microsoft も「パフォーマンスのために、Linuxツールで作業するならWSL側に置くと良い」と案内しています。(Microsoft Learn)

目安（超ざっくり）

  • よく触る開発プロジェクト（Node/TS、依存多め） → WSL側に置くのが気持ちいいことが多い✨(Microsoft Learn)
  • どうしても Windows 側に置く必要がある大規模PJ → Docker Desktopの同期型ファイル共有みたいな選択肢が役立つこともあります🧰(Docker)
  • そもそも「ファイル共有は何ができて、なぜ遅くなりうるか」の背景整理はDocker公式の解説が分かりやすいです。(Docker)

7) AI活用（この章で効くプロンプト集）🤖✨​

コピペで使ってOKです😄🧠

  • 図解を作らせる🗺️ 「bind mountの仕組みを、文章だけで“図解っぽく”説明して。Windowsホスト/WSL/コンテナの3者を出して」

  • コマンドを自分用に変換🛠️ 「今いるフォルダをコンテナの /work にマウントして、ファイル変更が見えるデモ用コマンドを3つ出して（安全寄り）」

  • つまずき診断🔍 「docker run の -v でマウントしたはずなのにコンテナ内でファイルが見えない。原因候補トップ5と確認手順を短く」

8) 理解チェック✅🎓（5分）​

  • Q1：ホストで保存した変更が、コンテナで“すぐ見える”のは何のおかげ？📎
  • Q2：コンテナの中だけにファイルを置くと、何が起きやすい？🧹
  • Q3：/mnt/c/... と /home/... で、体感速度が変わりやすい理由は？🐢➡️🐇(Microsoft Learn)

9) ミニまとめ🎉​

  • コンテナは“別の世界”🌍📦
  • 開発では 編集＝ホスト、実行＝コンテナ が強い✍️🚀
  • それをつなぐのが ファイル共有（bind mount） 📎✨
  • Windows+WSL2は プロジェクト置き場が速度に効きやすい⚡(Microsoft Learn)

次の第12章で、いよいよ マウントの基本（ホスト↔コンテナ）をガッツリ体験していきますよ〜😆📎🔥