はじめに
以下のような経験、勝手な思い込みを解消するために
このように考えると理解しやすかったかなという観点で書きました
-
.:ってなんだよ！ていう当初の困惑 - volumeはすべて、host側をマウントするためにある
- anonymous volumeって劣化named volume？
Dockerでvolumeが必要な理由
Dockerの以下のような仕組みがあり、それぞれを解決するための仕組みがvolumeだと考えています
- 通常はコンテナを停止させると、コンテナ内のデータは保持されない
- ホスト-コンテナ間が独立した環境として扱われ、ファイルの共有ができない
- コンテナ-コンテナ間は独立した環境として扱われ、データの共有はできない
3種類のvolume
- host volume?(ちょっと正確な呼び方がわかりません)
- anonymous volume (匿名volume?anonymous volumeという記述をよく見かけます)
- named volume（名前付きボリューム）
それぞれが必要となるケースから見ていきます
目的から考えるDockerのvolume
コンテナ内のデータを永続化する => すべてのvolumeで可能
通常はコンテナを停止させると、コンテナ内のデータは保持されない(=永続化されていない)
これを永続化する仕組みがvolume
例) DBのデータをはじめ、都度消失しては困るものすべてが対象
ホスト(ローカル側)とコンテナ間で同期を図る => host volumeで可能
Dockerでホスト-コンテナ間が独立した環境として扱われるのに対し、ホスト側の特定のディレクトリをマウントして、ホスト-コンテナ間でデータの同期を図ることが可能
例) 開発環境など、ホストで編集したファイルをコンテナ内に随時反映させてい場合など
volumeを複数のコンテナで共有する => named volumeで可能
通常、コンテナ-コンテナ間は独立した環境として扱われ、ファイルの共有は行われない
named volumeを使用することで容易にコンテナ-コンテナ間でファイルの共有が可能になる
例) Web server(コンテナ)とアプリケーションserver（コンテナ）間で静的コンテンツと共有する場合など
あれ？anonymous volumeは？？
永続性のみ確保したい、ホストとの同期が必要ない、他のコンテナとの共有が必要ないケースではこれで十分かと思います
また、永続化、共有化されたvolumeの一部で、
敢えてコンテナ間の独立性を維持したいというケースで有効な気がします
例えばホストをマウントしたvolume配下の一部ディレクトリを、anonymous volumeでとして切り離すことが可能、anonymous volumeで指定したpathはコンテナ間の独立性を確保できる
設定例 - Dockerのvolume3種類
host mount: <host_path>:<container_path>
ホストのディレクトリをマウントし、コンテナ内のpathと同期する
volumes:
- .:/myapp # .(カレントディレクトリ)をマウントし、コンテナ内の/myappと同期
named volume: <volume_name>:<container_path>
コンテナ内のpathをvolumeとして扱い永続化する、namedであることで他のコンテナとの共有が容易
hostマウントされたpathの配下であっても、named volumeは別のvolumeとして扱われhost側と切り離される
volumes:
- node_modules:/myapp/node_modules # コンテナ内のpathをvolumeとして永続化し、node_modulesという名前をつけて管理
anonymous volume: <container_path>
named volumeとの違いはanonymousである点、名前がない（が、乱数ハッシュが割り当てられている）、他のコンテナと共有することを想定せず永続化だけしたい場合はこれでいいはず
volumes:
- /myapp/node_modules # コンテナ内のpathのみ記述、これをvolumeとして永続化する
(随時更新予定)
参考
”Docker Compose、チョットわかる”になるために知っておきたい頻出オプション - Compose file version 3(3.8) reference - - Qiita