4.2 Docker Named Volume完全ガイド|docker volume create/ls/inspect/rm の使い方

【第2章】イメージとコンテナの基本操作

Docker Named Volume完全ガイド|docker volume create/ls/inspect/rm の使い方

前回(4-1 エフェメラル性)で「コンテナを rm するとデータが消える」という悲しい事実を確認しました。今回はその救世主、Named Volume(名前付きボリューム)を使いこなします。

ゴールは「PostgreSQLコンテナを作り直してもデータが1件も失われない」状態を実現すること。コマンド4つ(create / ls / inspect / rm)を押さえれば OK です。

💡 この記事のゴール
① Named Volume の正体と保存場所を把握
docker volume 4コマンドの使い分け
-v mydata:/path の書き方と実戦投入
ハンズオン:PostgreSQL に入れたデータがコンテナ削除後も残ることを確認
⑤ 匿名ボリュームとの違い・Bind Mount(4-3)への繋ぎを理解

目次

  1. Named Volume とは何か
  2. どこに保存されるのか
  3. docker volume 4つの基本コマンド
  4. docker run -v でコンテナから使う
  5. ハンズオン:Postgres でデータ永続化を実証
  6. 匿名ボリューム vs Named Volume
  7. ボリュームの寿命とコンテナの寿命
  8. 使わないボリュームの掃除(prune
  9. どんなときに使う?/bind mount との違い
  10. まとめ

1. Named Volume とは何か

Named Volume は、Dockerが管理する名前付きのデータ保管箱です。コンテナとは独立した寿命を持ち、コンテナが消えてもボリュームは残り続けます

【コンテナ × Named Volume の関係】
📦 コンテナ「db1」
寿命: docker run 〜 rm
中から /data を読み書き

🗄️ Named Volume「mydata」
寿命: 明示的に rm するまで永遠
複数コンテナで共有可

🔗 -v mydata:/data で紐付け
コンテナを rm しても mydata は残る。新コンテナが -v mydata:/data で再アタッチすれば、前回書いたファイルがそのまま見える。
💡 ボリュームは「コンテナの外付けHDD」のイメージ
コンテナを壊しても、HDD(ボリューム)は無事。次に新しいコンテナを繋げば、同じデータで作業を続けられます。これが「永続化」の正体です。

2. どこに保存されるのか

Named Volume の実体は、Dockerが管理するホスト側のディレクトリに保存されます。Linux ではここ:

/var/lib/docker/volumes/<ボリューム名>/_data/

たとえば mydata という名前のボリュームなら、中身は /var/lib/docker/volumes/mydata/_data/ にファイルとして存在します。

【ホスト側のパス ↔ コンテナ側のパス】
🖥️ ホスト(Docker管理領域)
/var/lib/docker/volumes/
└── mydata/
└── _data/
├── file1
└── file2

📦 コンテナ内
/data/
├── file1
└── file2

↑ 同じ実体を、ホストとコンテナ両方から見ている。コンテナから書き込めば即座にホスト側にも書かれる。
⚠️ ホスト側のパスを直接いじらない
/var/lib/docker/volumes/ を直接 rm したり chmod したりすると、Docker が管理している権限・メタ情報と食い違ってトラブルになります。操作は必ず docker volume コマンドで。Windows/macOS では Docker Desktop の VM 内部にあるので、そもそも直接は見えません。
💡 Windows/macOS の場合
コンテナは Linux カーネル上で動く(1-1 復習)ため、ボリュームも Docker Desktop が管理する 軽量 Linux VM の中に保存されます。つまり Windows のエクスプローラーでは辿れません。docker volume inspect で確認できる Mountpoint は「VM内のパス」です。

3. docker volume 4つの基本コマンド

ボリューム操作の全てはこの4コマンドに集約されます。

コマンド 役割 頻度
docker volume create <名前> ボリュームを作成 ★★★
docker volume ls ボリューム一覧を表示 ★★★
docker volume inspect <名前> 詳細情報(保存場所・ドライバなど) ★★
docker volume rm <名前> ボリュームを削除 ★★

3-1. volume create(作成)

$ docker volume create mydata
mydata

コマンドが成功するとボリューム名がそのまま出力されます。この時点でホスト側 /var/lib/docker/volumes/mydata/_data/ が作られ、空ディレクトリになっています。

💡 実は create は省略できる
docker run -v mydata:/data ... を実行したとき、mydata という名前のボリュームがまだ存在しなければ Docker が自動的に作成します。明示的に create しなくても動きます。ただし、あらかじめ作っておく方が「意図してボリュームを準備した」ことが明確で、チーム作業では推奨。

3-2. volume ls(一覧)

$ docker volume ls
DRIVER    VOLUME NAME
local     mydata
local     pgdata-prod
local     redis-cache

DRIVER 列は普通 local(ホストOS上に保存する標準ドライバ)。特殊な用途で NFS / Azure Files など外部ストレージ用のドライバを使うこともあります。

3-3. volume inspect(詳細)

$ docker volume inspect mydata
[
    {
        "CreatedAt": "2026-04-20T12:34:56Z",
        "Driver": "local",
        "Labels": null,
        "Mountpoint": "/var/lib/docker/volumes/mydata/_data",
        "Name": "mydata",
        "Options": null,
        "Scope": "local"
    }
]
フィールド 意味
Mountpoint ホスト側の実体パス(Linux直接運用時のみ意味あり)
Driver ボリュームドライバ(通常 local
CreatedAt 作成日時
Labels 任意のラベル(-l env=prod 等で付ける、検索・掃除に便利)

3-4. volume rm(削除)

$ docker volume rm mydata
mydata
⚠️ 使用中のボリュームは削除できない
そのボリュームを使っているコンテナが1つでも残っていると、docker volume rm は次のエラーで失敗します:
Error response from daemon: remove mydata: volume is in use - [xxxx...]
先にコンテナを docker rm してから再実行してください(「停止」だけではなく「削除」が必要)。

docker run -v でコンテナから使う

作った(または自動作成される)ボリュームを実際にコンテナにマウントする書式:

docker run -v <ボリューム名>:<コンテナ内のパス>[:ro] <image>

# 例
docker run -d --name web -v mydata:/usr/share/nginx/html nginx
docker run -d -v pgdata:/var/lib/postgresql/data -e POSTGRES_PASSWORD=secret postgres:16
部分 意味
mydata ホスト側のボリューム名(絶対パスではないことに注意)
/usr/share/nginx/html コンテナ内のマウント先パス
:ro(任意) read-only。コンテナから書き込ませたくないとき
💡 -v の左辺で Named / Bind を自動判別
-v mydata:/data → 名前のみ → Named Volume(4-2 の話)
-v /home/me/src:/data絶対パスBind Mount(4-3 で詳しく)
左辺がスラッシュで始まるかどうかで Docker が自動判別します。

5. ハンズオン:Postgres でデータ永続化を実証

「コンテナを消してもデータが残る」を実際に目で確認します。PostgreSQL を題材にします。

5-1. ボリュームを作る

$ docker volume create pgdata
pgdata

$ docker volume ls
DRIVER    VOLUME NAME
local     pgdata

5-2. Postgres コンテナをボリューム付きで起動

docker run -d --name db1 \
  -e POSTGRES_PASSWORD=secret \
  -v pgdata:/var/lib/postgresql/data \
  postgres:16

ここでのポイントは /var/lib/postgresql/data。これがPostgres がデータベースのファイルを置くデフォルトのパスです。ここにボリュームをマウントすることで、DBの中身をボリュームに書き込ませます。

💡 マウント先は「そのイメージがデータを置く場所」
どのパスをマウントすべきかはイメージごとに決まっているので、Docker Hub の各イメージの README で確認します:
postgres/var/lib/postgresql/data
mysql/var/lib/mysql
mongo/data/db
redis/data

5-3. データを入れる

$ docker exec -it db1 psql -U postgres

postgres=# CREATE TABLE users (id SERIAL PRIMARY KEY, name TEXT);
CREATE TABLE

postgres=# INSERT INTO users (name) VALUES ('Alice'), ('Bob'), ('Carol');
INSERT 0 3

postgres=# SELECT * FROM users;
 id | name
----+-------
  1 | Alice
  2 | Bob
  3 | Carol
(3 rows)

postgres=# \q

5-4. コンテナを完全に削除する(ドキドキ)

$ docker rm -f db1
db1

$ docker ps -a | grep db1
(何も表示されない — 完全に消えた)

$ docker volume ls
DRIVER    VOLUME NAME
local     pgdata          ← ボリュームは生きている!
✅ ここが今回のハイライト
コンテナは完全に消えました。でも pgdata ボリュームは docker volume lsまだ存在していることが確認できます。

5-5. 新しいコンテナで同じボリュームに繋ぐ

docker run -d --name db2 \
  -e POSTGRES_PASSWORD=secret \
  -v pgdata:/var/lib/postgresql/data \
  postgres:16

$ docker exec -it db2 psql -U postgres

postgres=# SELECT * FROM users;
 id | name
----+-------
  1 | Alice
  2 | Bob
  3 | Carol
(3 rows)                     ← データが生き残ってる!🎉

postgres=# \q
✅ 実証完了
コンテナを完全削除してから新しいコンテナを立ち上げたのに、Alice・Bob・Carol の3レコードが生き残っていました。これが Named Volume の威力です。

5-6. 後片付け

# コンテナを止めて消す
docker stop db2
docker rm db2

# ボリュームも消したいなら
docker volume rm pgdata

5-7. シミュレータでマウントの挙動を確認

Named Volume と Bind Mount の違い、そしてコンテナ削除後もボリューム側のファイルが残る様子を下のシミュレータで確認できます。


6. 匿名ボリューム vs Named Volume

実は Named ではない「匿名ボリューム(anonymous volume)」も存在します。知らないうちに作られて増え続けるので、違いを把握しておきましょう。

  Named Volume 匿名ボリューム
作られ方 -v mydata:/data -v /data(左辺なし)や Dockerfile の VOLUME
名前 人間が付けた名前 64桁のランダム16進数
再利用 簡単(名前で指定すればOK) ほぼ不可(IDを覚えていないと)
使いどころ DBデータなど意図的に残したいもの 「とりあえず書き込み先が欲しい」系の一時的用途
放置するとどうなる? 明示的に削除するまで残る 同じくディスクに残り続け、どれがどれか分からなくなる
docker volume ls で見たときの違い】
DRIVER    VOLUME NAME
local     pgdata                         ← Named(わかりやすい)
local     redis-cache                    ← Named
local     2f8a4e1b9c7d6e5f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f  ← 匿名(謎)
local     9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f8a7b  ← 匿名(謎)
⚠️ 匿名ボリュームが増え続ける落とし穴
postgresmysql などの公式イメージは Dockerfile の VOLUME 命令でマウントポイントを宣言しています。-v pgdata:/var/lib/postgresql/data付け忘れて docker run postgres しただけでも、Docker が自動で匿名ボリュームを作って /var/lib/postgresql/data にマウントします。コンテナを消してもこの匿名ボリュームはディスクに残ります。定期的に docker volume prune で掃除しましょう(後述)。

7. ボリュームの寿命とコンテナの寿命

ボリュームの寿命はコンテナよりずっと長いことを時間軸で整理します。

【コンテナの寿命 vs ボリュームの寿命】
t=0
volume create

t=1
run db1
→ INSERT

t=2
rm db1
✅ vol残る

t=3
run db2
→ SELECT OK

t=N
volume rm
💥 消滅

コンテナ寿命: t=1 〜 t=2、 t=3 〜 …
ボリューム寿命: t=0 〜 t=N(コンテナをまたいで生き続ける)


8. 使わないボリュームの掃除(prune

開発していると「どのコンテナにもアタッチされていない匿名ボリューム」が溜まっていきます。まとめて掃除するには prune

$ docker volume prune
WARNING! This will remove anonymous local volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Volumes:
2f8a4e1b9c7d...
9a8b7c6d5e4f...

Total reclaimed space: 2.3 GB
⚠️ 本番サーバでの prune は慎重に
デフォルトの docker volume prune は「どのコンテナからも使われていない」ボリュームを削除します。停止中のコンテナが後で使う予定のボリュームがあると、意図せず消してしまう可能性があります。本番では docker volume ls -f dangling=true で対象を事前確認しましょう。
また docker volume prune -a--all)は Named も含めて削除するので、個人のローカル以外では使わないのが無難です。

9. どんなときに使う?/bind mount との違い

Named Volume と Bind Mount(4-3)の使い分けを先に一覧しておきます。

観点 Named Volume Bind Mount
保存先 Docker 管理領域(/var/lib/docker/volumes) ホストの任意パス(例:~/project)
管理主体 Docker が責任を持つ ユーザが責任を持つ
ポータビリティ 高い(ホストOSに依存しにくい) 低い(パスが環境ごとに違う)
Windows/macOS での性能 良い 遅いことがある(VM経由のファイル共有)
向く用途 DB データ・本番の永続データ 開発中のソースコード・設定ファイル
ホストから中身を編集 やりづらい(直接触らない前提) やりやすい(いつもの場所に居る)
💡 迷ったら:本番 = Named Volume / 開発 = Bind Mount
・本番環境のDB・ユーザーアップロード → Named Volume
・開発中に自分のエディタでゴリゴリ編集したい → Bind Mount(4-3)
両方を併用することもよくあります(例:bind mount でコード反映、named volume で DB 永続化)。

10. まとめ

押さえどころ ポイント
正体 Docker管理の「外付けHDD」。コンテナ寿命を超えて生き残る
保存場所 /var/lib/docker/volumes/<名前>/_data/(Linux直接時)
作る docker volume create <名前>(または run -v で自動作成)
使う docker run -v <名前>:<コンテナ内パス> ...
調べる docker volume ls / docker volume inspect
消す docker volume rm(使用中だと失敗)/ docker volume prune
匿名を避ける DBイメージは必ず -v mydata:/... を付ける
✅ 次のステップ
4-3 バインドマウント完全ガイドで、もう一つの永続化方式「ホストの任意ディレクトリを直接繋ぐ」方法を学びます。開発中に「コードを書く → コンテナで即反映」のループを作る時の主役です。Named Volume との使い分けの判断軸もその記事で最終確認します。

参考リンク


Dockerの基礎を動画で体系的に学びませんか?

実務で使う基礎だけを3時間に凝縮。環境構築から丁寧に解説しています。

Udemy Docker入門講座 クーポン割引で講座を見る →

コメント

タイトルとURLをコピーしました