Ubuntu 22.04 で Docker コンテナを運用する場合、コンテナを削除しても残したいデータをどこに置くかを決める必要があります。bind mount と volume はどちらも永続化に使えますが、管理主体と向いている用途が異なります。
この記事では、既存の Ubuntu 22.04 環境を保守する前提で、bind mount、Docker volume、--mount、読み取り専用マウント、バックアップ対象の考え方を確認します。
- bind mount と volume の管理主体
--mountを使った指定方法- 読み取り専用 bind mount
- Docker volume の作成と確認
- バックアップ対象と削除時の注意
書籍
Kubernetes完全ガイド 第2版
コンテナ運用、永続化、周辺の運用観点を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
bind mount と volume の違い
bind mount はホスト上の具体的なファイルやディレクトリをコンテナへ見せます。volume は Docker が管理する領域に作成され、コンテナから通常のファイルシステムとして利用されます。
| 種類 | 管理主体 | 向いている用途 |
| bind mount | ホスト OS | 設定ファイル、開発用ディレクトリ、ホストと共有したいファイル |
| volume | Docker | アプリケーションデータ、DB データ、コンテナ再作成後も残すデータ |
使い分けの基準
bind mount はホストのディレクトリ構造に依存します。volume は Docker CLI で管理しやすく、バックアップや移行の単位にしやすいのが特徴です。
- ホストの特定パスを見せたい場合は bind mount を使う
- アプリケーションデータを Docker 管理にしたい場合は volume を使う
- ホスト側から頻繁に編集する設定ファイルは bind mount が扱いやすい
- DB やアプリの永続データは volume の方が管理しやすい
- bind mount はホスト側を書き換えられるため、読み取り専用指定も検討する
Docker の状態を確認する
作業前に Docker Engine の状態と既存 volume を確認します。既存環境では、不要な volume を誤って削除しないことが重要です。
docker version
docker info
docker volume ls
docker ps -abind mount を試す
ホスト側のディレクトリを作成し、Nginx コンテナのドキュメントルートへ読み取り専用でマウントします。
mkdir -p "$HOME/docker-test/html"
tee "$HOME/docker-test/html/index.html" >/dev/null <<'EOF'
<html><body>bind mount test</body></html>
EOF
docker run --rm -d \
--name nginx-bind \
-p 8080:80 \
--mount type=bind,source="$HOME/docker-test/html",target=/usr/share/nginx/html,readonly \
nginx:latest
curl http://127.0.0.1:8080/
docker rm -f nginx-bindbind mount の注意点
bind mount はホストの実ファイルをコンテナへ見せるため、コンテナ内のプロセスがホスト側のファイルを変更できる場合があります。設定ファイルを渡すだけなら readonly を付けると安全です。
docker run --rm \
--mount type=bind,source=/etc/hosts,target=/tmp/hosts,readonly \
ubuntu:22.04 \
cat /tmp/hostsDocker volume を作成する
volume は Docker が管理する永続データ領域です。コンテナを削除しても volume は自動では消えません。
docker volume create nginx-volume
docker volume inspect nginx-volume
docker run --rm -d \
--name nginx-volume-test \
-p 8080:80 \
--mount type=volume,source=nginx-volume,target=/usr/share/nginx/html \
nginx:latest
docker volume ls
docker rm -f nginx-volume-testvolume の中身を確認する
volume の中身は、確認用コンテナからマウントして見るのが扱いやすいです。ホスト上の Docker 管理ディレクトリを直接触るより、Docker CLI 経由で扱う方が安全です。
docker run --rm \
--mount type=volume,source=nginx-volume,target=/data \
ubuntu:22.04 \
find /data -maxdepth 2 -type f -print–mount と -v の使い分け
短い検証では -v でも動きますが、手順として残す場合は --mount の方が意味を読み取りやすくなります。type、source、target、readonly を明示できるためです。
docker run --rm \
--mount type=volume,source=nginx-volume,target=/usr/share/nginx/html \
nginx:latest-v で同じ volume を指定する場合は、短く書けます。
docker run --rm \
-v nginx-volume:/usr/share/nginx/html \
nginx:latestバックアップ対象を確認する
bind mount はホスト側パスがバックアップ対象です。volume は Docker volume としてバックアップ対象を決めます。どちらも、コンテナ名ではなくデータの置き場所で考えます。
docker volume inspect nginx-volume
docker run --rm \
--mount type=volume,source=nginx-volume,target=/data,readonly \
--mount type=bind,source="$PWD",target=/backup \
ubuntu:22.04 \
tar czf /backup/nginx-volume-backup.tar.gz -C /data .削除時の注意
コンテナ削除と volume 削除は別です。不要な volume を削除する場合は、対象名を確認してから実行します。
docker ps -a
docker volume ls
docker volume inspect nginx-volume
docker volume rm nginx-volume運用時に見るポイント
永続化の設計では、コンテナを再作成したときに何が残るか、どこをバックアップすべきか、ホスト移行時に何を持っていくかを決めます。
- 設定ファイルは bind mount、アプリケーションデータは volume を基本に考える
- bind mount は host path への依存を記録する
- volume は
docker volume lsとdocker volume inspectで管理する - 読み取り専用でよいものは
readonlyを付ける - 削除前にバックアップ対象かどうかを確認する
まとめ
Ubuntu 22.04 の Docker でデータを永続化する場合、bind mount と volume は管理主体で使い分けます。ホストの具体的なパスを渡すなら bind mount、Docker 管理の永続データとして扱うなら volume が向いています。
保守対象の環境では、コンテナ名ではなくデータの置き場所を基準にします。--mount で指定内容を明確にし、バックアップと削除の対象を確認してから運用します。
関連記事
Ubuntu 26.04 Bonding の基本設定 – active-backup と 802.3ad を使い分ける
Ubuntu 22.04 NFS クライアント設定 – mount と fstab の基本
Ubuntu 26.04 Docker の基本設定 – Docker Engine / Compose / IPv6 / プロキシを構成する
Ubuntu 22.04 Docker で Nginx コンテナを外部公開する – port publish の基本
Ubuntu 22.04 Podman の基本操作 – Docker との違いを意識して使う
Ubuntu 26.04 Docker Registry の基本設定 – 内部コンテナレジストリを用意する
Ubuntu 22.04 Docker Engine の導入 – Ubuntu 標準パッケージでコンテナ実行環境を構築する
Ubuntu 22.04 389 Directory Server #4 – BIND ユーザーとアクセス制御