Docker Volume 戦略: ハイブリッドアプローチ

Docker Infrastructure プロジェクトにおいて、データ永続化（Volume）の実装は、課題要件を厳密に満たすために特殊な戦略を採用しています。 このドキュメントでは、その仕組みと「なぜこの構成なのか」という背景を解説します。

1. 課題要件のジレンマ

Docker Infrastructure の課題には、一見すると矛盾する2つの要件が存在します。

要件	内容	矛盾点
要件 A	「データベースとWordPressの永続化には Docker Named Volumes を使用すること（Bind Mounts は禁止）」	通常の Named Volume は保存場所を選べない（/var/lib/docker/volumes/ 固定）。
要件 B	「データはホストの /home/login/data ディレクトリ以下に保存すること」	指定パスに保存するには通常 Bind Mount が必要だが、要件Aで禁止されている。

この2つを同時に満たすために採用したのが、「Bind Mount の実体を持つ Named Volume」 というハイブリッドなアプローチです。

2. アーキテクチャ図解

通常の Volume、Bind Mount、そして今回採用したハイブリッド方式の違いを図解します。

• Standard Named Volume: Docker が管理する領域に保存される。場所を変えられないため 要件Bを満たせない。
• Direct Bind Mount: 指定パスに保存できるが、Docker 上の Volume オブジェクトとして管理されないため 要件Aを満たせない。
• Hybrid Named Volume (採用): Docker 上は「Named Volume」として定義しつつ、driver_opts オプションを使って実体を指定パスにマッピングする。これにより 両方の要件をクリア する。

3. 技術的な仕組み

docker-compose.yml での定義は以下のようになっています。

volumes:
  wordpress:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: /home/${USER}/data/wordpress

• driver: local: 標準のローカルドライバーを使用します。
• type: none: Docker に「ファイルシステム作成などの管理をしない」と伝えます。
• o: bind: Linux の mount --bind オプション相当の挙動を指示します。
• device: ホスト側の絶対パスを指定します。

4. この仕組みのメリットと背景

なぜ課題はこの要件を課しているのか？

推測される狙いは以下の通りです。

1. 管理の抽象化 (Docker Way): 直接ファイルパスをコンテナ定義（services 内）に書く「Bind Mount」は、環境依存（パスの違い）が強く出すぎるため、Docker のベストプラクティスとしては「Volume」として抽象化することが推奨されます。 docker volume ls や docker volume inspect で管理できるようにするという意図があります。

2. データの主権と可視性: 一方で、データが /var/lib/docker/... の深い階層に隠蔽されてしまうと、初学者が「データの実体」を意識しづらくなります。 「指定パスに保存せよ」という要件を加えることで、コンテナとデータの分離、そしてデータの永続性を物理的に確認させようとしていると考えられます。

このハイブリッド構成は、「Docker の管理作法（Volume）」と「インフラの物理構成（指定パス）」を両立させるための、高度かつ実践的なテクニックです。