Docker ボリュームでデータ永続性はどのように機能しますか？

Question

Accepted Answer

デフォルトでは、コンテナ内のデータは**一時的**で、コンテナが削除されると失われます。**ボリューム**（およびバインドマウント）は、コンテナを超えて存続する**永続的ストレージ**を提供し、データベースおよびコンテナの再起動や削除から生き残る必要があるデータに不可欠です。

## コンテナは一時的である問題

```text
A container's writable layer is DELETED when the container is removed:
  → data written inside the container (e.g. a database's files) is LOST
  → containers are meant to be disposable/replaceable → don't store important data in them
→ For persistent data, you need storage OUTSIDE the container's lifecycle.
```

## ボリューム — 管理された永続的ストレージ

```bash
# create and use a named volume (managed by Docker)
docker volume create mydata
docker run -v mydata:/var/lib/mysql mysql      # mount the volume into the container
# → data in /var/lib/mysql persists in the volume, surviving container removal

docker volume ls                 # list volumes
docker volume inspect mydata     # details
```

**ボリューム**は Docker が管理する永続的ストレージ（ホスト上に保存され、Docker によって管理される）で、データを永続化するための推奨される方法です。マウントされたパス内のデータは、コンテナが削除されても生き残ります。

## バインドマウント — ホストディレクトリをマップ

```bash
# bind mount: map a specific HOST directory into the container
docker run -v /host/path:/app -p 3000:3000 myapp
docker run -v $(pwd):/app myapp   # mount the current directory (great for development)
# → changes on the host are reflected in the container (and vice versa)
```

**バインドマウント**は、ホストディレクトリをコンテナにマップします。開発時に有用です（ホスト上でコードを編集して、コンテナ内でライブで変更を確認）。

## ボリューム対バインドマウント

```text
VOLUMES      → Docker-managed, portable, the preferred choice for PERSISTENT DATA
               (databases, uploads) — decoupled from the host's filesystem layout
BIND MOUNTS  → map a specific host path; great for DEVELOPMENT (live code reload)
               and sharing host files; tied to the host's filesystem
tmpfs        → in-memory (non-persistent), for sensitive/temporary data
```

## なぜ重要なのか

ボリュームを使用したデータ永続性を理解することは、データを持つアプリケーションで Docker を正しく使用するために不可欠であり、重要な実用的知識です。

基本的な問題 — **コンテナは一時的であり、削除時に書き込み可能レイヤーが削除される**ため、**コンテナ内に書き込まれたデータが失われる** — は重要な概念です。コンテナは使い捨てを意図しているため、重要なデータ（データベースのファイルなど）をコンテナ内に保存すると、コンテナが置き換わるときにデータが失われます。**ボリューム**はこれを解決します。コンテナのライフサイクルの外に存在する**Docker 管理の永続的ストレージ**を提供することで、データ（データベース、アップロード、任意の状態）がコンテナの削除と置き換えから生き残ります。これはステートフルアプリケーションに不可欠です。

**バインドマウント**（ホストディレクトリをコンテナにマップ）の理解は、**開発**（ホスト上でコードを編集してコンテナ内でライブで変更を確認する、非常に一般的な開発ワークフロー）およびホストファイル共有に重要です。

**区別**を知ること — ボリューム（Docker 管理、ポータブル、データベースなどの永続的アプリケーションデータの推奨される選択肢）対バインドマウント（ホストパス固有、開発に優れている）— は正しいアプローチを選択するのに役立ちます。

コンテナは設計上一時的で、ほとんどの実在するアプリケーションは永続化する必要があるデータ（特にデータベース）を持っており、ボリュームは永続的ストレージの本質的なメカニズム（バインドマウントは開発に重要）であるため、Docker データ永続性の理解 — 一時的コンテナの問題、永続的データのためのボリューム、開発のためのバインドマウント、および各々を使用する時期 — は不可欠で、実践的に関連した Docker の知識です。これはステートフルアプリケーションを正しく実行し、使い捨てコンテナ内に保存されたデータを失うという深刻な誤りを回避するために必要です。