コンテナ内でデータベースを起動し、データを追加し、コンテナを削除して、新しいコンテナを起動します。データが消えてしまいました。ほとんどの人がこの教訓を苦労して学びます。 Docker ボリューム とバインド マウントは、1 つのコンテナの存続期間を超えてデータを維持するために存在します。

このガイドでは、それぞれの仕組みと選び方について説明します。ここでのコマンドとファイルは、文書化された Docker の動作に基づいた標準的な例であり、この記事では実行しませんでしたので、最初に使い捨てデータで試してください。詳細は、Docker のバージョン間および Docker Desktop 間で異なる場合があります。コンテナーを初めて使用する場合は、初心者向けの Docker チュートリアルから始めてください。

コンテナデータが消える理由

Docker イメージは読み取り専用レイヤーで構成されます。コンテナーが起動すると、Docker はその上に書き込み可能な薄いレイヤーを追加し、変更はそこに反映されます。このレイヤーは停止して再起動しても残りますが、コンテナーが削除されると削除されます。

docker run -d --name db -e POSTGRES_PASSWORD=devonly postgres:17
# ... create tables and add data ...
docker rm -f db
docker run -d --name db -e POSTGRES_PASSWORD=devonly postgres:17
# The data you added is not there

これは設計によるもので、コンテナーを自由に置き換えることができます。つまり、保持する必要があるものはすべてコンテナの外に存在する必要があります。それには次の 3 つの方法があります。

Docker ボリュームとバインド マウントを並べて比較する

名前付きボリューム

ボリュームは、Docker によって作成および管理されるストレージです。名前で参照するので、物理的にどこに存在するかを気にする必要はありません。

docker volume create pgdata

docker run -d --name db \
  -e POSTGRES_PASSWORD=devonly \
  -v pgdata:/var/lib/postgresql/data \
  postgres:17

現在、データベース ファイルは pgdata に存在します。コンテナを削除し、同じボリュームで新しいコンテナを起動しても、データはそのまま残ります。 Linux では、ボリュームは通常 /var/lib/docker/volumes/ の下にありますが、これらのファイルを直接編集しないでください。 Docker Desktop では、これらは通常のフォルダーではなく、仮想マシン内に存在します。

コンテナ内のパスはイメージによって異なるため、イメージのドキュメントを確認してください。間違ったパスにマウントすることは典型的な間違いです。すべてが機能しているように見えますが、データはまだコンテナー層に書き込まれています。イメージの新しいメジャー バージョンでもこのパスが変更される可能性があるため、アップグレードする前にリリース ノートをお読みください。

名前付きボリュームが存在しない場合、Docker は自動的に名前付きボリュームを作成します。名前を付けずに作成された 匿名ボリューム も機能しますが、長いランダムな ID が付与されるため、簡単に追跡できなくなります。ボリュームには必ず名前を付けてください。

バインドマウント

バインド マウントは、特定のホスト パスをコンテナに直接マッピングします。双方が同じファイルを即座に認識します。これにより、エディターでの編集が再構築せずに実行中のコンテナーに反映されるため、開発に最適になります。

docker run -d --name web \
  -p 8080:80 \
  -v "$(pwd)/site:/usr/share/nginx/html:ro" \
  nginx:1.27

site/ でファイルを編集し、ブラウザを更新すると、変更が表示されます。 :ro はコンテナ内のマウントを読み取り専用にします。これは、コンテナがそこに書き込む必要がない場合に良い習慣です。

バインド マウントにはいくつかのトレードオフがあります。

• それらはあなたをホストに結び付けます。 パスは各マシンに存在する必要があるため、セットアップの移植性は低くなります。
• 画像のコンテンツを隠します。 /app の上にマウントすると、画像に含まれていたものはすべて見えなくなります。よくある例は node_modules が行方不明になることです。
• ホストを公開します。書き込み可能なマウントを持つコンテナは、実際のホスト ファイルを変更または削除できます。リスクを十分に理解していない限り、/ や Docker ソケットのような機密性の高いパスをマウントしないでください。
• パフォーマンスは変動する可能性があります。 macOS および Windows の Docker Desktop では、ファイル共有が仮想化の境界を越えるため、Linux よりも遅くなる可能性があります。

tmpfs マウント

tmpfs マウントはホストのメモリ内に存在し、コンテナ層に書き込まれることはありません。コンテナーが停止すると消えるため、一時ファイル、キャッシュ、および短期間の機密データに適しています。

docker run -d --tmpfs /app/cache:size=64m myapp:1.0

tmpfs は Linux ホストで使用できます。また、データの保持を気にしない使い捨てのテスト環境でデータベースを高速化することもできます。

-v それとも –mount?

どちらのフラグも機能します。 --mount は長いですが、より明示的であり、多くの人がスクリプトで使用することを好みます。

# Short form
docker run -v pgdata:/var/lib/postgresql/data postgres:17

# Explicit form
docker run --mount type=volume,source=pgdata,target=/var/lib/postgresql/data postgres:17

# Bind mount, read-only
docker run --mount type=bind,source="$(pwd)"/site,target=/usr/share/nginx/html,readonly nginx:1.27

意味のある違いが 1 つあります。 -v を使用すると、欠落しているホスト パスが空のフォルダーとして作成され、タイプミスを隠すことができます。 --mount とバインド タイプを使用すると、Docker は代わりにエラーを報告します。また、-v では、左側がタイプを決定します。名前はボリュームを意味し、パスはバインド マウントを意味します。したがって、-v data:/x と -v ./data:/x はまったく異なることを行います。

Docker Compose のボリューム

実際のプロジェクトのほとんどは、Compose ファイルでストレージを宣言します。これは両方の種類を使用し、それぞれが適切な役割を果たします。

services:
  web:
    build: .
    ports:
      - "3000:3000"
    volumes:
      - ./src:/app/src      # bind mount: live code
    depends_on:
      - db

  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: devonly
    volumes:
      - pgdata:/var/lib/postgresql/data   # named volume: data

volumes:
  pgdata:

名前付きボリュームは、最上位の volumes セクションで宣言する必要があります。 Compose は、実際の名前の前にプロジェクト名を付けます。完全なチュートリアルについては、Docker Compose チュートリアルを参照してください。

便利なボリュームコマンド

これは元に戻すことができないため、prune で削除される内容を確認してから確認してください。現在コンテナが使用していないボリュームには、重要なデータがまだ保持されている可能性があります。

ボリュームのバックアップと復元

ボリュームとホスト フォルダーの両方をマウントする短期間のコンテナーを実行することで、ボリュームをバックアップできます。

# Back up
docker run --rm \
  -v pgdata:/data:ro \
  -v "$(pwd)":/backup \
  alpine tar czf /backup/pgdata.tar.gz -C /data .

# Restore into a new volume
docker volume create pgdata_restored
docker run --rm \
  -v pgdata_restored:/data \
  -v "$(pwd)":/backup \
  alpine tar xzf /backup/pgdata.tar.gz -C /data

ライブデータベースの場合、このようにファイルをコピーすると、不整合な状態がキャプチャされる可能性があります。最初にコンテナを停止するか、PostgreSQL の pg_dump などのデータベース独自のツールを使用することをお勧めします。また、復元したことのないバックアップは単なる希望にすぎないため、復元をテストしてください。

ファイル権限

「許可が拒否されました」はマウントに関する最も一般的な問題です。ファイルは Linux 上で数値のユーザー ID とグループ ID を保持するため、コンテナーがユーザー 1000 として実行され、ホスト フォルダーが別のユーザーに属している場合、書き込みは失敗します。これを修正するいくつかの方法:

• 一致するユーザーでコンテナを実行します: docker run --user "$(id -u):$(id -g)" ...
• Dockerfile のベスト プラクティス で説明されているように、イメージに正しい所有権を設定します。
• 新しいボリュームは最初に使用されるときにイメージのフォルダーの所有権を引き継ぐため、データには名前付きボリュームを優先します。
• SELinux を使用するシステムでは、バインド マウントに :z または :Z ラベルが必要な場合があります。

Linux コマンド のガイドで説明されているように、chmod 777 の誘惑を避けてください。

どれを使用するべきですか?

最後の行が重要です。運用環境では、コードはイメージに含まれるため、テストしたものが実行されます。クラスターでは、永続ボリュームを介してデータ ストレージが再び異なる動作をします。これについては、広範な Kubernetes ドキュメントで説明されています。私たちのDocker 対 Kubernetesガイドでは、この 2 つがどのように関係するかを説明しています。

よくある間違い

• 間違ったパスにマウントしています。 データはまだコンテナ層に存在しており、後で消えます。
• 気軽に down -v 実行しています。 これにより、名前付きボリュームが削除されます。
• -v での相対パスの使用。 -v data:/x のような形式では、フォルダー マッピングではなくボリュームが作成されます。
• 書き込み可能なバインド マウントにシークレットを配置します。 シークレットを読み取り専用でマウントするか、シークレット機能を使用します。
• 2 つのデータベース コンテナが 1 つのボリュームを指すようにします。 これにより、データが破損する可能性があります。
• バックアップがありません。 ボリュームはバックアップではありません。同じディスク上に存在します。

まとめ

経験則は短く、データには名前付きボリューム、編集中のコードにはバインド マウント、存続すべきではないものには tmpfs を使用します。使い捨てデータベースで試してください。名前付きボリュームを作成し、行を追加し、コンテナーを削除して、新しいボリュームを開始し、行が残っていることを確認します。そして、必要になる前にバックアップと復元を練習してください。

よくある質問

学び続ける