Dockerを利用する際、データの永続化は避けて通れない重要なテーマです。
コンテナは一時的なものであるため、適切な永続化設定をしなければ、大事なデータがコンテナ停止とともに消えてしまいます。

この記事では、Docker初心者の方でもワクワクしながら理解できるように、ボリュームとマウントについて基礎から応用まで丁寧に解説いたします。
実際のサンプルコードを交えながら、すぐに使える形で紹介いたしますので、ぜひ参考にしてください！

コンテナの仕組みによるデータ消失問題

Dockerコンテナは、イメージから起動される一時的なプロセスにすぎません。
コンテナ内に保存されたファイルは、コンテナが削除されると同時に消えてしまうという特徴があります。

項目	内容
コンテナの特徴	一時的な実行環境であり、削除時にデータも消える
データ永続化の必要性	コンテナ停止・再起動後もデータを保持したい

これを防ぐために、Dockerは「ボリューム」と「バインドマウント」という仕組みを提供しています。

ボリュームによるデータ管理の基本

Dockerにおけるボリュームは、コンテナと切り離された永続的なデータ領域を指します。
ボリュームはDockerエンジンによって管理され、コンテナとは独立して存在できるため、非常に信頼性が高いです。

ボリュームの作成と確認

ボリュームは以下のコマンドで作成できます。

bashCopy codedocker volume create my-volume

作成後、一覧表示で確認しましょう。

bashCopy codedocker volume ls

このコマンドを実行すると、作成したボリュームがリストに表示されます。

さらに、ボリュームの詳細情報は以下で確認できます。

bashCopy codedocker volume inspect my-volume

公式ドキュメントリンク

• Docker Volumeの公式解説

ボリュームをコンテナにマウントする方法

ボリュームをコンテナにアタッチすることで、コンテナ内でファイル操作が可能になります。
以下が基本的な起動例です。

bashCopy codedocker run -d \
  --name my-container \
  -v my-volume:/app/data \
  nginx

オプション	説明
-v	ボリュームとコンテナディレクトリをマウントする指定
my-volume:​/​app​/​data	左がボリューム名、右がコンテナ内部パス

この設定により、my-volumeボリュームに保存されたデータは、コンテナ削除後も残ります。

バインドマウントによるファイル共有の基本

バインドマウントは、ホストマシンの特定ディレクトリをコンテナにマウントする方法です。
これにより、開発中のコードや設定ファイルを即座にコンテナに反映できます。

バインドマウントの使用例

次のようにホスト側のパスとコンテナ側のパスを指定します。

bashCopy codedocker run -d \
  --name my-nginx \
  -v /home/user/nginx/html:/usr/share/nginx/html \
  nginx

項目	説明
​/​home​/​user​/​nginx​/​html	ホスト側のディレクトリパス
​/​usr​/​share​/​nginx​/​html	コンテナ内のマウントポイント

この方法を使えば、ローカルのファイル変更が即座にコンテナに反映され、開発効率が大幅に向上します。

公式ドキュメントリンク

• Docker Bind Mountsの公式解説

ボリュームとバインドマウントの違い

比較項目	ボリューム	バインドマウント
管理者	Dockerエンジン	ユーザー（ホスト側）
バックアップ/移行	簡単	難しい（ホスト依存）
セキュリティ	高い	ホストパス依存でリスクあり
利用シーン	データベース、ログ保存など	開発中ファイル共有など

このように、それぞれの特徴に応じて使い分けることが、賢いDocker活用への第一歩となります。

ボリュームの細かい管理テクニック

ボリュームをさらに柔軟に活用するためには、いくつか便利なテクニックを知っておくとよいでしょう。

コンテナ起動時に匿名ボリュームを作成

次のようにコマンドで、名前を付けずにボリュームを作成できます。

bashCopy codedocker run -d -v /app/data nginx

この場合、Dockerが自動でランダムな名前をつけたボリュームを作成してくれます。
ただし、どのボリュームがどの用途なのか把握しづらくなるため、基本は名前付きボリューム推奨です。

複数ボリュームのマウント例

1コンテナに複数のボリュームをマウントすることも可能です。

bashCopy codedocker run -d \
  -v volume1:/path1 \
  -v volume2:/path2 \
  nginx

各ディレクトリごとに異なるボリュームを使い分けることで、データ管理の粒度を細かく調整できます。

データのバックアップと復元

運用において、データのバックアップは非常に重要です。Dockerボリュームは簡単にバックアップ・復元ができます。

バックアップする

ボリュームの中身をtarアーカイブに保存する例です。

bashCopy codedocker run --rm \
  -v my-volume:/volume \
  -v $(pwd):/backup \
  alpine \
  tar czf /backup/backup.tar.gz -C /volume .

項目	説明
​/​volume	ボリュームの中身
​/​backup​/​backup.tar.gz	出力されるバックアップファイル

復元する

バックアップファイルから復元する場合は以下のようにします。

bashCopy codedocker run --rm \
  -v my-volume:/volume \
  -v $(pwd):/backup \
  alpine \
  tar xzf /backup/backup.tar.gz -C /volume

これで、以前のデータ状態にコンテナを戻すことが可能です。

Docker Composeを活用したボリューム管理

複数コンテナを連携させる際は、Docker Composeを使うことで、ボリューム管理をより効率的に行えます。

Composeファイル（docker-compose.yml）では、ボリューム定義を記述して、各サービスに簡単に適用できます。

基本的な例

yamlCopy codeversion: '3.9'
services:
  db:
    image: mysql:8
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: example
    volumes:
      - db-data:/var/lib/mysql

volumes:
  db-data:

項目	説明
volumesセクション	グローバルにボリュームを定義
db-data:​/​var​/​lib​/​mysql	db-dataボリュームをコンテナ内の​/​var​/​lib​/​mysqlにマウント

Composeを使うことで、複数環境におけるボリューム設定も統一でき、管理が非常に楽になります。

公式ドキュメントリンク

• Docker Compose Volumesの公式解説

名前付きボリューム活用のベストプラクティス

本番運用では、名前付きボリュームを積極的に使うことが推奨されています。
理由は以下のとおりです。

理由	内容
可読性向上	どのボリュームがどの用途か把握しやすくなる
保守性向上	ボリュームのバックアップ・移行時に混乱しない
安全性向上	不要なデータ削除ミスを防げる

特に、docker-compose.ymlに明示的にボリューム名を指定することで、意図しない匿名ボリュームの作成を防止できます。

ネーミングルール例

サービス	ボリューム名例
MySQL	mysql-data
PostgreSQL	postgresql-data
Nginxログ	nginx-logs

一目見ただけで役割が分かるような名前を付けることがポイントです。

ボリュームとセキュリティ対策

ボリュームを扱う際は、セキュリティにも十分注意しなければなりません。
とくにバインドマウントでは、ホスト側のファイルシステムにアクセスできるため、リスクが高くなりがちです。

注意点

注意点	説明
不要な権限を与えない	コンテナには最低限のファイル/ディレクトリのみマウントする
読み取り専用に設定	誤って変更されないようにする（例：:roオプション）
セキュリティアップデート	マウント先ソフトウェアの脆弱性にも注意

読み取り専用マウント例

bashCopy codedocker run -d \
  -v /etc/config:/app/config:ro \
  my-app

:roオプションをつけることで、コンテナからホストファイルへの書き込みを禁止できます。

実践：WordPress+MySQL構成のデータ永続化

最後に、実践例としてWordPress＋MySQL環境をComposeで構築し、ボリューム管理を体験してみましょう。

docker-compose.yml例

yamlCopy codeversion: '3.9'

services:
  db:
    image: mysql:8
    restart: always
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: user
      MYSQL_PASSWORD: password
      MYSQL_ROOT_PASSWORD: password
    volumes:
      - db-data:/var/lib/mysql

  wordpress:
    image: wordpress:latest
    restart: always
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: user
      WORDPRESS_DB_PASSWORD: password
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - wp-data:/var/www/html

volumes:
  db-data:
  wp-data:

項目	内容
db-dataボリューム	MySQLのデータ永続化
wp-dataボリューム	WordPressコンテンツ（テーマ・画像）の永続化

これにより、コンテナを停止・再作成しても、WordPressのデータや設定は保持され続けます。

よくあるトラブルと解決策

ボリュームやマウントに関連して、初心者の方がつまずきやすいポイントをまとめました。

トラブル	原因	解決策
データが消える	ボリューム設定忘れ、またはマウントパスミス	docker inspectで設定確認
ホストファイルが更新されない	キャッシュやパーミッションの問題	ファイルシステムの権限見直し、キャッシュクリア
パーミッションエラー	UID/GIDの不一致	コンテナ内とホスト側のユーザーIDを合わせる

困ったときは、まずdocker volume inspectやdocker inspect container-nameで、現在の設定状況を冷静に確認することが大切です。

まとめ

Dockerにおけるデータ永続化は、ボリュームとバインドマウントを正しく理解し、場面に応じて使い分けることが鍵となります。

ポイントまとめ
ボリュームは本番向き、バインドマウントは開発向き
名前付きボリュームで可読性・保守性を確保する
Composeでボリューム管理を統一して効率化する
セキュリティにも常に配慮する

データが守られている安心感は、Docker開発・運用の自信にもつながります。
ぜひ本記事の内容を実践して、さらにワンランク上のDockerスキルを手に入れてください！

---

公式リファレンスも合わせて読むと、さらに理解が深まります。

• Docker Storage 公式ドキュメント
• Docker Compose 公式ドキュメント