
【Docker基礎】ボリュームマウントの確認方法
ボリュームマウントは、Docker が管理する専用領域をコンテナに取り付ける仕組みであり、バインドマウントのようにホストで直接ファイルを閲覧・編集するのが難しいところがあります。
そこで、「ちゃんとマウントできているの?」「本当にデータが書き込まれている?」 と疑問に思われる方もいるでしょう。本章では、ボリュームマウントが適切に機能しているかを確認するための代表的な方法を解説します。

なぜボリュームマウントの確認が難しいのか?
- バインドマウント はホスト側ディレクトリを直にコンテナと共有するため、ホスト上でファイルをすぐ見られます。
- ボリュームマウント は Docker が管理するディレクトリ(多くの場合
/var/lib/docker/volumes/…
)をコンテナと共有するため、ホストからは直接参照しにくい。 docker volume inspect
などでメタ情報は取れるが、実際のファイルを直接見るのは容易ではない。
「volume inspect」や「container inspect」での確認
docker volume inspect <ボリューム名>
・ボリュームの Mountpoint(実際にどこに割り当てられているか)などの基本情報を取得docker container inspect <コンテナ名>
・コンテナのMounts
セクションに、どのボリュームがどこにマウントされているかが表示される
これらの方法で、論理的にボリュームがマウントされているか までは確認できます。ただし、「実際にデータを書き込めているのか」という動作面の確認は、もうひと工夫必要になることがあります。
実際の運用で中身を確認する方法
最も確実な方法は、「別のコンテナを起動して、そのコンテナから同じボリュームをマウントし、中身をチェックする」 という手順です。
シナリオ例:WordPress のデータ確認

- WordPress コンテナ
・データベースや画像ファイルなどがボリュームに書き込まれる - Linux だけのコンテナ(Ubuntu, CentOS, Alpine, BusyBox など)
・同じボリュームを-v
オプションでマウント
・ls
コマンドなどでファイル一覧を確認
こうすることで、ホストの OS に依存することなく、コンテナ内のファイル構造を直接閲覧できます。
たとえば、WordPress が volume_wpdata
に画像などを書き込んでいるなら、別途 busybox コンテナを次のように起動し、その中で ls -l /mnt/wpdata
を確認するといった流れです。
docker run --rm -it
-v volume_wpdata:/mnt/wpdata
busybox /bin/bash
BusyBox を使うメリット
- 軽量 かつ 標準的な UNIX コマンド が揃っている。
- 短期ジョブや検証用途に最適
- Ubuntu や CentOS ほど容量を食わない。
まとめ
- 「volume inspect」「container inspect」
・論理的なマウント情報を得られる。
・ファイルの実体までは直接見られない。 - 実際の運用で中身を確認する
・別のコンテナで同じボリュームをマウントし、ls
やcat
でファイルを見る。
・WordPress などのアプリでデータを更新 → 別コンテナで確かめる。 - 軽量なイメージ(BusyBox など)で検証
・余計なパッケージが入っていない分、起動が速い。
・一時的なチェック用に非常に便利
これらの方法を知っておけば、ボリュームマウントが本当に動いているのか、データが正しく書き込まれているのかを確かめる際に役立ちます。次のコンテンツでは、ボリュームのバックアップについて解説していきましょう。