第04回: ボリュームと永続化 — コンテナを消してもデータが消えない仕組み

章: 第1章: Docker基礎と環境理解

コンテナを再作成したらDBが空になった — あなたも経験しましたか?

Dockerを使い始めて最初に驚くのが「コンテナを削除したら、入力していたデータが全部消えた」という体験です。これはDockerの仕様通りの動作ですが、知らないとひどく焦ります。

ボリュームを正しく使うことで、コンテナの外にデータを永続化し、コンテナを何度作り直してもデータを保持できるようになります。

なぜデータが消えるのか、なぜボリュームで解決するのか

コンテナのファイルシステムは「コンテナ自身」に属しています。コンテナが削除されると、その中のデータも一緒に消えます。これはコンテナの「使い捨て可能性」という特性から来ています。

ボリュームはDockerが管理するホスト上の記憶領域で、コンテナのライフサイクルとは独立しています。DBデータやアップロードファイルなど「消えてはいけないデータ」はボリュームに置きます。

バインドマウントとNamed Volumeの違い

チェックポイント: DBデータには必ず Named Volume を使いましょう。Bind Mount はホストのパスに依存するため、DBデータに使うと環境差異でトラブルが起きやすくなります。

最小構成のサンプル

services:
  db:
    image: mysql:8.4
    volumes:
      - db_data:/var/lib/mysql

volumes:
  db_data:

db_data という名前のボリュームを定義し、MySQLのデータディレクトリをそこにマウントしています。docker compose down してもこのボリュームは残り、次回 up したときにデータが復元されます。

まとめ & 次のステップ

• コンテナのデータはデフォルトでコンテナと一緒に消える
• Named Volume を使えばコンテナを削除してもデータが残る
• DBデータは Named Volume、ソースコードは Bind Mount が基本パターン
• docker volume ls で現在のボリューム一覧を確認できる

次回は「ネットワークとサービス間通信」を学びます。なぜコンテナ間で localhost が使えないのか、サービス名で解決する仕組みを理解します。