はじめに
どちらもDockerコンテナ内のデータを永続化するための機能ですが、それぞれの違いを調べたので簡単にまとめます。
結論
- ボリュームマウント
- Volumes として、コンテナの外部に保存
- 複数のコンテナから共有可能
- Volumesを削除しない限り残り続ける
- 永続化データの保存には公式もこちらを推奨
- バインドマウント
- 指定したホストマシンのファイルシステム内に保存
- ホストマシンと同期しているため、どちらかでファイルを修正や削除した場合はもう片方（ホストマシン⇄コンテナ）に反映される
- 開発中のソースコードやビルドファイルなど、即時反映させたいものはバインドマウントがおすすめ
ボリュームマウント
コンテナのファイルシステムとは別に、Volumesとしてデータを保存して使用するマウント方法です。
コンテナ外に保存されるため、コンテナが削除されてもデータは残ります。
また、複数のコンテナから同じボリュームをマウントしてデータを共有することも可能です。
以下、docker-compose.yml でボリュームマウントを設定する方法になります。
services:
mysql:
image: mysql
ports:
- 3306:3306
volumes:
- db_data:/var/lib/mysql // 3. 作成したボリュームでコンテナ内のデータをマウント
volumes:
db_data: // 1. 名前を付けてボリュームを作成
app_data: // 2. 複数作成することも可能（今回こちらは作成するのみ）
今回はMySQLのコンテナを例にしましたが、このようにすることで「db_data」というボリュームに対してコンテナ内の「/var/lib/mysql」というディレクトリをマウントしています。
「/var/lib/mysql」にはMySQLのデータが格納されていますが、それらをボリュームとして管理することで永続化を実現しています。
作成したVolumesはdocker volume lsで確認し、docker volume rm <volume_name>で削除することができます。（docker volume pruneで未使用ボリュームの削除）
バインドマウント
パスで指定したホストマシンのファイルをマウントして使用する方法です。
こちらもコンテナ内に保存されるわけではないため、コンテナが削除されてもデータは残ります。
注意点として、ファイルやディレクトリはホストマシンとコンテナ間で同期しているため、どちらかで更新や削除をすればもう片方にも反映されます。
以下、docker-compose.yml でバインドマウントを設定する方法になります。
services:
mysql:
image: mysql
ports:
- 3306:3306
volumes:
- ./docker/db/data:/var/lib/mysql // 2. ホストマシンの「./docker/db/data」にデータをマウント
// 1. 今回はボリュームを作成しません
このように設定すると、「:」の左側に指定しているパスに対してホストマシン側にマウント用のファイルやディレクトリを作成します。
今回であれば指定したパスが「./docker/db/data」なので、docker-compose.yml ファイルがある階層から相対パスで「docker/db/data」というディレクトリを参照し、その中にコンテナ内の「/var/lib/mysql」をマウントします。
前述しましたが、バインドマウントはホストマシンとコンテナのファイルを同期している状態のため、片方でファイルの変更や削除を行うともう片方にも反映されます。
今回はDBデータを例にしましたが、開発中にアプリケーションのビルドファイル等をマウントしておけば変更を即時反映させることも可能です。
まとめ
- ボリュームマウント
- Volumes として、コンテナの外部に保存
- 複数のコンテナから共有可能
- Volumesを削除しない限り残り続ける
- 永続化データの保存には公式もこちらを推奨
- バインドマウント
- 指定したホストマシンのファイルシステム内に保存
- ホストマシンと同期しているため、どちらかでファイルを修正や削除した場合はもう片方（ホストマシン⇄コンテナ）に反映される
- 開発中のソースコードやビルドファイルなど、即時反映させたいものはバインドマウントがおすすめ
用途に合わせて適切にマウント方法を指定しましょう。