Docker データ永続化

JPKODA 編集部 May 12, 2026

Docker はデータの永続化 (Persistence) のための複数のメカニズム (Mechanism) を提供しており、その中で バインドマウント (Binding mounts) と 名前付きボリューム (Named volumes) は最も一般的で汎用性の高い2つの選択肢です。本章では、これら2つのメカニズムを深く掘り下げ、その特徴、ユースケース (Use Case)、長所と短所を比較し、あなたのコンテナ化 (Containerized) アプリケーションに最適な方法を選択できるようにします。

1. Docker データ永続化ストレージの深い理解

前述の通り、Docker はデータをコンテナの読み書き可能なレイヤー (Read-write Layer) の外側に永続的に保存できるメカニズムを提供しています。これにより、コンテナが停止、削除 (Remove)、または置換されても、アプリケーションのデータが無傷であることが保証されます。永続化を行わなければ、データベースレコード、アプリケーションのログ、またはユーザーがアップロードしたファイルなどの重要な情報が失われ、コンテナが多くの実際のプロジェクトで使用できなくなってしまいます。私たちのコアな目標は、データとコンテナのライフサイクル (Lifecycle) を分離し、データが独立して生き残れるようにすることです。

2. バインドマウント

バインドマウント（通常は単に "bind mounts" と呼ばれます）は、ホストマシン (Host machine) 上のファイルまたはディレクトリ (Directory) をコンテナに直接マウント (Mount) することを可能にします。これにより、ホストマシン上の特定のパスとコンテナ内の特定のパスの間に直接的なリンクが作成されます。ホストマシン上であれコンテナ内であれ、マウントされたコンテンツに変更を加えると、その変更は即座に両端に同期して反映されます。

2.1 バインドマウントの仕組み

本質的に、バインドマウントは直接的なパスのマッピング (Mapping) です。ホストマシン上のソースパス (Source Path) を指定し、コンテナ内のターゲットパス (Target Path) を指定する必要があります。その後、Docker はコンテナがそのターゲットパスにアクセスした際に、実際にはホストマシンのソースパスを指すようにします。

2.2 いつバインドマウントを使用するか？

バインドマウントは、以下のシナリオで非常に有用です：

開発ワークフロー (Development Workflow): アプリケーションを積極的に開発している際、通常はコードの変更を即座に有効にし、Docker イメージ (Image) を再ビルド (Build) したくない場合があります。ソースコードディレクトリをマウントすることで、コンテナにホストマシン上の最新のコードを使用してアプリケーションを実行させることができます。これは極めて効率的な高速イテレーション (Iteration) のワークフローです。
設定ファイル (Configuration Files): アプリケーション固有の設定ファイルがあり、これらのファイルをホストマシン上で直接管理する場合、それらをコンテナにバインドマウントできます。これにより、イメージを再ビルドしたりデータボリュームを再作成したりすることなく設定を更新できます。
ホストマシン固有のリソース: 読み取り専用のシステムファイル、ホストマシンに保存されているアプリケーションキー、またはホストマシン上に存在しなければならない特定のデータディレクトリなど、ホストマシンのファイルにアクセスする必要がある場合。
巨大なデータセット (Dataset) の共有: データがすでにホストマシン上に存在し、コンテナによって消費（読み取り）される必要があるシナリオ（読み取り専用のデータ分析入力ファイルなど）に適しています。

2.3 バインドマウントの長所と短所

長所:

シンプルで直接的: 設定が非常にシンプルで、標準のホストマシンツールを使用してホストマシンのファイルシステム上のファイルに直接アクセスできます。これは開発フェーズで特に便利です。
リアルタイム更新: ホストマシン上で行われた変更は即座にコンテナ内に表示され、その逆も同様です。これにより開発環境に最適な選択肢となります。
優れたパフォーマンス (Performance): 通常はホストマシンのネイティブファイルシステムキャッシュを直接利用できるため、良好なパフォーマンスを提供できます。

短所:

ポータビリティ (Portability) の低さ: バインドマウントはホストマシン固有のディレクトリ構造に大きく依存しています。コンテナを別のホストマシンに移動した場合、そのマウントパスが存在しないか、間違った場所を指している可能性があり、エラーの原因となります。これにより、名前付きボリュームよりもポータビリティに劣ります。
セキュリティ (Security) のリスク: コンテナは事実上、指定されたホストマシンパスおよび潜在的にそのサブディレクトリへのアクセス権を獲得します。不適切な設定により機密性の高いホストマシンファイルがコンテナにエクスポーズ (Expose) され、セキュリティリスクをもたらす可能性があります。
バックアップと移行が煩雑: データのバックアップや移行にはホストマシンレベルのファイルシステム操作が含まれ、Docker 組み込みのボリューム管理ツールと比較すると標準化されておらず便利ではありません。
プラットフォーム依存性: 異なるオペレーティングシステムではパスの命名規則が異なります（例：Linux/macOS では /、Windows では C:\）。これにより、バインドマウントを使用するスクリプト (Script) のクロス OS での互換性が低下します。

2.4 バインドマウントの実践例

例 1：ライブリロード (Live Reloading) をサポートする Web 開発

Nginx を使用して静的 Web サイトやフロントエンドアプリケーションを開発しているとします。ホストマシン上で HTML、CSS、または JavaScript ファイルを編集し、実行中の Nginx コンテナにその効果をすぐに見たいと考えています。

# ホストマシン上で Web コンテンツ用のディレクトリを作成する
mkdir -p ~/my_web_app/html

# シンプルな index.html ファイルを作成する
echo "<h1>こんにちは、私の Docker Web アプリから！</h1><p>このコンテンツはホストマシンからのものです。</p>" > ~/my_web_app/html/index.html

# Nginx コンテナを実行し、ホストマシンの html ディレクトリを Nginx のデフォルト Web ルートにバインドマウントする
docker run -d \
  -p 8080:80 \
  --name my-dev-nginx \
  -v ~/my_web_app/html:/usr/share/nginx/html \
  nginx:latest

# コマンドの解説：
# -d: コンテナをバックグラウンド（デタッチモード）で実行します。
# -p 8080:80: ホストマシン上の 8080 番ポートをコンテナ内の 80 番ポートにマッピングします。
# --name my-dev-nginx: コンテナに覚えやすい名前を割り当てます。
# -v ~/my_web_app/html:/usr/share/nginx/html: これがバインドマウントです。
#   - `~/my_web_app/html`: ホストマシン上のソースパス（Linux/macOS を使用していない場合は、Windows では C:\path\to\my_web_app\html など適切に調整してください）。
#   - `/usr/share/nginx/html`: Nginx が Web ページファイルを見つけることを期待している、Nginx コンテナ内のターゲットパス。
# nginx:latest: 使用する Docker イメージ。

# それでは、ブラウザを開いて http://localhost:8080 にアクセスします
# index.html ファイルのコンテンツが見えるはずです。

# ホストマシン上で index.html ファイルを変更します：
echo "<h1>もう一度こんにちは！たった今コンテンツを更新しました。</h1><p>変更はリアルタイムで有効になりました！</p>" > ~/my_web_app/html/index.html

# ブラウザをリロードします。コンテナを再起動することなく、更新されたコンテンツがすぐに表示されます。

例 2：カスタムアプリケーション設定の提供

カスタムアプリケーション (my-custom-app) があり、特定の構成ファイル app_config.json を必要とし、このファイルをホストマシンシステム上で管理したいとします。

# アプリケーション設定用のディレクトリを作成する
mkdir -p ~/my_app_configs

# ホストマシン上でサンプル設定ファイルを作成する
echo '{"database_url": "postgresql://user:password@host:5432/myapp_db", "log_level": "INFO"}' > ~/my_app_configs/app_config.json

# カスタムアプリケーションコンテナを実行し、その設定ファイルをマウントする
# ('my-custom-app-image' が /etc/app/config.json で設定を読み取ると想定)
docker run -d \
  --name my-app-with-config \
  -v ~/my_app_configs/app_config.json:/etc/app/config.json \
  my-custom-app-image:latest

# 解説：
# -v フラグは、ホストマシン上の特定のファイル (`~/my_app_configs/app_config.json`) を
# コンテナ内の特定のファイルパス (`/etc/app/config.json`) に指定しています。
# ホストマシン上で app_config.json に加えられた変更はコンテナ内に反映されます（ただしアプリケーションの設計によっては、新しい設定を読み取るためにアプリケーションの再起動が必要になる場合があります）。

想定シナリオ：CI/CD パイプライン (Pipeline) のアーティファクト (Artifacts)

継続的インテグレーション/継続的デプロイメント (CI/CD) パイプラインにおいて、Docker コンテナ内でテストを実行することがあります。テストの完了後、後続の分析やアーティファクトのアーカイブとして、テストレポート（JUnit XML ファイルなど）をホストマシンに戻して保存したいと考えるでしょう。

# ビルドタスクがこのようにコンテナを実行すると仮定します：
docker run --rm \
  --name my-test-runner \
  -v $(pwd)/test-reports:/app/test-output \
  my-test-runner-image:latest sh -c "run_tests.sh && cp /app/reports/* /app/test-output/"

# ここで、コンテナの `/app/test-output` ディレクトリはホストマシンの現在の
# `$(pwd)/test-reports` ディレクトリにバインドマウントされています。`run_tests.sh` が `/app/reports` にレポートを生成した後、
# それらは `/app/test-output` にコピーされます。これは、それらがホストマシンの `test-reports` ディレクトリに直接保存されたことを意味します。
# `--rm` フラグはコンテナが終了した後に自動的に削除されることを保証しますが、ホストマシン上のテストレポートは永続的に保持されます。

3. 名前付きボリューム

名前付きボリュームは、コンテナによって生成および使用されるデータを管理するために特別に設計された、Docker 公式推奨の永続化メカニズムです。ホストマシンのファイルシステム構造に依存するバインドマウントとは異なり、名前付きボリュームは完全に Docker 自身によって管理されます。Docker はホストマシンのファイルシステムの特定の領域（Linux では通常 /var/lib/docker/volumes/）にこれらのボリュームを作成および管理し、基盤となるストレージの場所をユーザーから抽象化 (Abstract) し隠蔽します。ユーザーはボリュームに付けた名前を介してインタラクトするだけで済みます。

3.1 名前付きボリュームの仕組み

名前付きボリュームを作成すると、Docker はホストマシン上に新しいディレクトリをセットアップします。その後、この名前付きボリュームをコンテナにアタッチ (Attach) すると、Docker はこの特定のディレクトリをコンテナ内の指定されたパスにマウントします。Docker はこれらのボリュームの作成、管理、および追跡を全面的に担います。ホストマシン上の実際の物理パスは通常ユーザーに対して透過的であり、これにより優れた抽象化レイヤーが提供されます。

3.2 いつ名前付きボリュームを使用するか？

ほとんどのコンテナデータの永続化要件、特に本番環境 (Production Environment) において、名前付きボリュームは一般的に推奨されるデフォルトの選択肢です：

データベースの永続化: データベースファイル（PostgreSQL、MySQL、MongoDB など）の保存において、これらのシナリオではデータの整合性と永続性が最優先事項です。
アプリケーションデータ: ユーザーがアップロードしたファイル、アプリケーションのログ、キャッシュ (Cache) データ、またはアプリケーションによって生成され、コンテナの寿命よりも長く存続する必要があるその他のデータを永続化します。
データのポータビリティ: データを異なるホストマシンやオペレーティングシステム間で簡単に移行 (Migrate) できるようにする必要がある場合。名前付きボリュームは名前で参照されるため、特定のプラットフォーム (Platform) に制限されません。
Docker Compose とオーケストレーション (Orchestration): Docker Compose や Docker Swarm のようなオーケストレーションツールとシームレスに統合 (Integrate) でき、マルチコンテナアプリケーションのデータ管理を容易にします。
優れたセキュリティ: コンテナはホストマシンの具体的なファイルシステム構造を知る必要がなく、ホストマシンのパスが偶発的にエクスポーズされるリスクを軽減します。

3.3 名前付きボリュームの長所と短所

長所:

Docker による集中管理: Docker が作成、配置、および権限制御を担当し、データ管理タスクを簡素化します。
高いポータビリティ: 名前による参照により、極めて移植性が高くなります。名前付きボリュームを使用するコンテナを Docker が動作する別のマシンに移動でき、ボリュームが存在しない場合、Docker がデータ転送（または再作成）を処理します。
バックアップと移行の容易さ: Docker は専用のコマンド（docker volume cp など、または外部ツールの使用）を提供しており、ホストマシン固有のバインドマウント操作と比較して、名前付きボリュームのバックアップ、復元、または移行がより標準化され、簡単になります。
優れたセキュリティ: 実際のストレージの場所は抽象化されて隠蔽されているため、コンテナが誤ってホストマシンの他のコアパスにアクセスする可能性は低くなります。
ストレージドライバ (Volume Drivers) による拡張: ボリュームドライバプログラムを介して拡張でき、リモートサーバーやクラウドサービスプロバイダ (Cloud Provider) にデータを保存し、より高度なストレージ機能を提供します。
意図の明確さ: 名前付きボリュームの使用は、このデータの一部が特定のコンテナから独立して永続的に存在するよう設計されていることを明確に示しています。

短所:

ホストマシン上で直接簡単にアクセスできない: Docker 内部のボリュームのストレージパス（ユーザーが直接操作することは推奨されていません）を知らない限り、ホストマシンのファイルシステムを通じてボリュームの内容を簡単に表示することはできません。
わずかに抽象的: 初心者にとって、この抽象的な概念は直接的なバインドマウントよりも最初は理解しにくいかもしれませんが、その利点はすぐにこの小さな欠点を覆い隠します。

3.4 名前付きボリュームの実践例

例 1：データベースの永続化ストレージ

PostgreSQL データベースを使用して、名前付きボリュームがどのようにデータを保護するかをデモンストレーションします。

# 1. PostgreSQL データ用の名前付きボリュームを作成する
docker volume create pg_data

# 解説：このコマンドは、'pg_data' という名前の管理される新しいボリュームを作成するよう Docker に指示します。
# Docker は、ホストマシン上のこのボリュームの実際の物理ストレージの場所を処理します。

# 2. この名前付きボリュームを使用して PostgreSQL コンテナを実行する
docker run -d \
  --name my-postgres-db \
  -e POSTGRES_PASSWORD=mysecretpassword \
  -v pg_data:/var/lib/postgresql/data \
  postgres:latest

# 新しい -v フラグ構文の解説：
# -v pg_data:/var/lib/postgresql/data: ここでは名前付きボリュームが使用されています。
#   - `pg_data`: 今作成した Docker が管理するボリュームの名前。
#   - `/var/lib/postgresql/data`: PostgreSQL がコンテナ内でデータファイルを保存するパス。
# postgres:latest: PostgreSQL の Docker イメージ。

# 3. データベースに接続していくつかデータを作成する（データベースが起動するまで数秒待ちます）
# ホストマシンに 'psql' クライアントをインストールするか、一時的なコンテナを使用して接続する必要がある場合があります。
# 接続に一時的なコンテナを使用します：
docker run --rm -it \
  --network container:my-postgres-db \
  postgres:latest psql -h localhost -U postgres

# psql コマンドラインプロンプトに入った後：
# CREATE DATABASE myapp;
# \c myapp;
# CREATE TABLE users (id SERIAL PRIMARY KEY, name VARCHAR(100));
# INSERT INTO users (name) VALUES ('Alice'), ('Bob');
# SELECT * FROM users;
# \q (psql を終了)

# 4. この PostgreSQL コンテナを停止し削除する
docker stop my-postgres-db
docker rm my-postgres-db

# 解説：この時点でコンテナは消滅しましたが、'pg_data' という名前付きボリュームは依然として存在し、
# あなたが先ほど作成したすべてのデータベースデータが含まれています。

# 5. 【同じ】名前付きボリュームを使用して【全く新しい】PostgreSQL コンテナを実行する
docker run -d \
  --name my-new-postgres-db \
  -e POSTGRES_PASSWORD=mysecretpassword \
  -v pg_data:/var/lib/postgresql/data \
  postgres:latest

# 6. 新しいコンテナに接続し、データが永続的に保持されているか検証する
docker run --rm -it \
  --network container:my-new-postgres-db \
  postgres:latest psql -h localhost -U postgres -d myapp

# psql コマンドラインプロンプトに入った後：
# SELECT * FROM users;
# 'Alice' と 'Bob' がまだ存在していることが確認でき、データが正常に永続化されたことが証明されます。
# \q (psql を終了)

# 環境のクリーンアップ：
docker stop my-new-postgres-db
docker rm my-new-postgres-db
docker volume rm pg_data # これらのデータがもう必要ないと確信した場合にのみこのボリュームを削除してください！

例 2：アプリケーションが生成したファイルの永続化

ユーザーがアバターをアップロードできる Web アプリケーションを考えてみましょう。このアプリケーションのコンテナが置き換えられたり更新されたりしても、これらの画像は永続的に保持されなければなりません。

# 1. ユーザーがアップロードしたコンテンツ用に名前付きボリュームを作成する
docker volume create app_uploads

# 2. コンテナを実行する（たとえば、アップロードを処理する架空のイメージ）
# 'my-upload-app' イメージがアップロードされたファイルを `/app/uploads` ディレクトリに保存すると仮定します
docker run -d \
  --name my-upload-service \
  -v app_uploads:/app/uploads \
  my-upload-app:latest

# 解説：コンテナ内の `my-upload-app` が `/app/uploads` に書き込むファイルはすべて、
# `app_uploads` という Docker ボリュームに永続的に保存されます。コンテナがクラッシュしたり削除されたりしても、
# アップロードされたファイルはボリューム内で安全です。

想定シナリオ：永続化をサポートする集中型ログ収集

コンテナ化されたログエージェント (Agent) コンポーネント (Component) が様々なサービスからログを収集し、中央のログ管理システムに送信する前にまずローカルに保存するシナリオを想像してください。エージェントの再起動や更新中のログの損失を防ぐために、名前付きボリュームを使用できます。

# 1. ログストレージ用に名前付きボリュームを作成する
docker volume create log_collector_data

# 2. ログエージェントコンテナを実行する
# (`my-log-agent` がログを収集し、`/var/log/myagent` に保存すると仮定)
docker run -d \
  --name central-log-agent \
  -v log_collector_data:/var/log/myagent \
  my-log-agent:latest

# これにより、`central-log-agent` コンテナが再起動または置換されたとしても、
# 収集されて `/var/log/myagent` に配置されたログはすべて、
# `log_collector_data` ボリューム内に永続的に保持され、処理されて中央システムに送信されるのを待ちます。

4. コアとなる違いと技術的な選択

バインドマウントと名前付きボリュームのどちらを選択するかは、特定のユースケース、環境、およびポータビリティ、セキュリティ、管理方法に対する要件に大きく依存します。

特性 (Feature)	バインドマウント (Binding Mounts)	名前付きボリューム (Named Volumes)
管理者	あなた（ユーザーがホストマシンのパスと権限を手動で管理）	Docker（Docker がホストマシンのパスとライフサイクルを全面的に管理）
ホストマシンパス	ユーザーによって明示的にハードコーディングされて指定される (例：`/host/path`)	Docker によって管理され、ユーザーからは抽象化され隠蔽される (通常は `/var/lib/docker/volumes/` 下)
ポータビリティ	低い（ホストマシンのファイルパスに大きく依存）	高い（名前で参照され、Docker が実際の場所を管理）
セキュリティ	設定を誤るとホストマシンのファイルシステムが予期せずエクスポーズされる可能性がある	より優れている（コンテナは実際のホストマシンの物理パスを知らない）
最適なユースケース	ローカル開発、設定ファイルのマウント、特定のホストマシンリソースへのアクセス	本番環境のデータ、データベースストレージ、アプリケーションが生成したデータ、ポータブルなストレージ要件
使いやすさ	ホストマシン上で直接ファイルを操作する必要がある場合、非常に便利	Docker の永続化管理メカニズムを利用できるため、非常に手間がかからない
バックアップと移行	ホストマシンレベルのファイルシステム操作コマンドに依存する必要がある	Docker の公式コマンド (`docker volume`) またはストレージドライバを使用
システム統合度	`docker run` に適している	`docker run`、`Docker Compose`、`Swarm`、`Kubernetes` などに適している
リアルタイムコードホットアップデート	サポートしており、開発環境に極めて適している	通常、リアルタイムでのコード変更には使用されない

いつバインドマウントを選択するか：

開発中: コードを迅速にイテレーションし、イメージを再ビルドすることなくコンテナ内でコード変更の効果をすぐに見たい場合。
設定ファイルの管理: ホストマシン上で直接制御・更新される外部設定ファイルに使用。
ホストマシンリソースへのアクセス: コンテナが実際にホストマシンの特定のファイルまたはディレクトリと直接対話する必要がある場合。

いつ名前付きボリュームを選択するか：

本番環境アプリケーション: 本番環境でアプリケーションデータ（データベース、ユーザーがアップロードしたファイル、ログなど）を永続化するためのデフォルトおよび第一の選択肢。
データのポータビリティの要件: データを異なる Docker ホストマシンや環境間で簡単に移行する必要がある場合。
コンテナオーケストレーション: Docker Compose や Docker Swarm などのオーケストレーションツールを使用する場合、名前付きボリュームはシームレスに統合および管理できます。
マネージド型ストレージ: Docker に複雑なストレージパスや権限の問題を処理させたい場合。

要約すると、名前付きボリュームは一般的なデータ永続化のための、より強力で移植性が高く、「Docker ネイティブ」なソリューション (Solution) を提供し、これは本番環境で特に顕著です。一方、バインドマウントは強力ですが、通常はローカルの開発環境や、ホストマシンのファイルシステムと直接対話する必要がある特定のオペレーション要件により適しています。

5. 総合実践デモンストレーション

具体的なシナリオを通じて、これら2つの概念を実践に適用してみましょう。

5.1 シナリオ 1：バインドマウントを使用した Web アプリケーションの開発

シンプルな静的 Web アプリケーションの開発プロセスをシミュレート (Simulate) します。ホストマシン上で index.html ファイルを作成し、それを Nginx コンテナにマウントしてから、ファイルを変更してリアルタイムの更新を観察します。

1. ホストマシンのディレクトリを準備する：

mkdir -p my_website/html
echo "<h1>私の開発サイトへようこそ！(バージョン 1)</h1><p>このファイルをホストマシンで編集してください。</p>" > my_website/html/index.html

これにより、現在の作業ディレクトリに my_website/html フォルダが作成され、その中に index.html ファイルが生成されます。

2. バインドマウントを使用して Nginx を実行する：

docker run -d \
  --name dev-nginx \
  -p 8080:80 \
  -v "$(pwd)/my_website/html":/usr/share/nginx/html \
  nginx:latest

$(pwd) は現在のディレクトリの絶対パスを取得するために使用され、コマンドの実行をより安定させます。
このコマンドは Nginx を起動し、ホストマシンの 8080 番ポートをコンテナの 80 番ポートにマッピングします。
最も核心となる部分は -v "$(pwd)/my_website/html":/usr/share/nginx/html であり、これはホストマシンの my_website/html ディレクトリを Nginx のデフォルト Web ルートに直接マウントします。

3. 初期設定の検証： ブラウザを開いて http://localhost:8080 にアクセスします。「私の開発サイトへようこそ！(バージョン 1)」と表示されるはずです。

4. リアルタイムでの変更の実行： ホストマシン上で index.html ファイルを編集します：

echo "<h1>私の開発サイトへようこそ！(バージョン 2 - リアルタイムで更新されました！)</h1><p>この変更は瞬時に反映されます！</p>" > my_website/html/index.html

5. 更新の観察： ブラウザのタブ http://localhost:8080 をリロードします。すぐに「私の開発サイトへようこそ！(バージョン 2 - リアルタイムで更新されました！)」と表示されます。これは、開発におけるバインドマウントの強大な威力を完璧に示しています。

6. クリーンアップ：

docker stop dev-nginx
docker rm dev-nginx
rm -rf my_website # 不要になった場合はホストマシンのテストディレクトリを削除できます

5.2 シナリオ 2：名前付きボリュームを使用した Redis データの永続化

Redis コンテナを使用してキーバリュー (Key-Value) データを保存し、コンテナを削除して再作成したとしても、名前付きボリュームがデータの永続性を確保できることをデモンストレーションします。

1. 名前付きボリュームを作成する：

docker volume create redis_data_volume

これにより、redis_data_volume という名前の Docker 管理のボリュームが作成されます。

2. この名前付きボリュームを使用して Redis を実行する：

docker run -d \
  --name my-redis-instance \
  -p 6379:6379 \
  -v redis_data_volume:/data \
  redis:latest

Redis コンテナを起動します。
-p 6379:6379 は Redis のデフォルトポートをマッピングします。
-v redis_data_volume:/data は、作成したばかりの名前付きボリューム redis_data_volume を Redis コンテナ内の /data ディレクトリ（これは Redis がデータを永続化するデフォルトのパスです）にマウントします。

3. Redis にデータを追加する： Redis インスタンスに接続し、キーを設定します。一時的な redis-cli コンテナを使用できます。

# 一時的なコンテナを使用して redis-cli ターミナルに入る
docker exec -it my-redis-instance redis-cli

# redis-cli プロンプト内で入力します：
SET mykey "Hello from Redis Volume!"
GET mykey
# "Hello from Redis Volume!" と表示されるはずです。`exit` と入力して redis-cli を終了します。

4. Redis コンテナを停止して削除する：

docker stop my-redis-instance
docker rm my-redis-instance

この時点で、my-redis-instance コンテナは存在しません。しかし、Docker が管理する redis_data_volume ボリュームはホストマシン上に安全に残っており、先ほどのデータが保存されています。

5. 【同じ】名前付きボリュームを使用して【全く新しい】Redis コンテナを実行する：

docker run -d \
  --name my-new-redis-instance \
  -p 6379:6379 \
  -v redis_data_volume:/data \
  redis:latest

ここでは完全に同じ redis_data_volume 名前付きボリュームを使用していることに注意してください。

6. 新しいコンテナでのデータの永続性の検証： 新しい Redis インスタンスに接続し、先ほどのキーをクエリ (Query) します。

docker exec -it my-new-redis-instance redis-cli

# redis-cli プロンプト内で入力します：
GET mykey
# 再び "Hello from Redis Volume!" と表示され、データがコンテナのライフサイクルを超えて生き残ったことが証明されます。`exit` と入力して終了します。

7. クリーンアップ：

docker stop my-new-redis-instance
docker rm my-new-redis-instance
docker volume rm redis_data_volume # データが不要になったと確信した後でこのボリュームを削除してください