bind mount

bind mount は、ホスト側の特定フォルダやファイルを、コンテナ へそのまま見せる仕組みです。
Docker Docs でも、bind mounts はホストの filesystem から container に file or directory を mount する仕組みとして説明されています。

初心者向けにかなりざっくり言うと、手元のフォルダを、そのままコンテナ側から見えるようにする方法 です。
そのため、ローカルで編集したコードをすぐコンテナ側へ反映したい開発用途でかなりよく使われます。

まず押さえたいポイント

• ホストの特定パスをそのままコンテナへ見せる
• コードを手元で編集しながらコンテナで実行したいときに便利
• ボリューム と違って、Docker ではなくホスト側のパスに強く依存する
• 永続データ保管より、開発時のファイル共有で使われやすい

どんな場面で使うか

bind mount は、ローカル開発で特によく使われます。
たとえば、手元のソースコードをエディタで編集しながら、コンテナ側のアプリで即反映を見たいときにかなり便利です。

たとえば、

• PHP アプリのコードをローカルで編集する
• コンテナ側の PHP / Node.js / Python 実行環境でそのまま動かす

という流れでは、bind mount がかなり相性がいいです。

ボリュームとの違い

ここがいちばん混ざりやすいです。

• bind mount: ホストの既存パスをそのまま見せる
• ボリューム: Docker が管理する保存領域を使う

コード共有や開発中の即時反映は bind mount、DB データの永続化はボリューム、くらいで最初は整理すると分かりやすいです。

実務で見るポイント

bind mount は便利ですが、ホストOSのパス構成、権限、改行コード、ファイル監視の挙動などの影響を受けやすいです。
そのため、開発では便利でも、本番運用の永続データ保管まで全部 bind mount で済ませるとは限りません。

特に、チーム全員が同じOSではない場合は、自分のPCでは動くが他では権限やパス差で詰まる こともあります。

よくある誤解

bind mount は volume の上位互換？

そうではありません。
どちらもマウントですが、向いている用途が違います。

bind mount ならデータは絶対安全？

そこまでは言えません。
ホスト側のファイルを直接触るので、消したり壊したりしたら普通に影響します。バックアップの代わりにはなりません。