【Docker入門】Dockerのバインドマウントとボリュームについてわかりやすくその基本を解説

今回はDockerのわかりにくい概念（機能）のうち、バインドマウントとボリュームという機能について簡単に解説します。あくまで基本的なイメージのつかむための解説となりますが、実際に使う上ではこの基本的なイメージをつかめているだけでかなり理解がはかどると思います。

Dockerでデータを永続化するための2つの方法

Dockerで例えばデータベースのMySQLを使ったコンテナを作るとします。データベースですからデータが保存されます。

ではそのコンテナをDockerから削除すると、コンテナ内部のデータはどうなるのでしょう？

当然消えます。ですが、それでは次のような場合に不便です。

• Dockerは複数のコンテナを立てて連携させ、MySQLコンテナにおけるデータを他のコンテナで利用したいとき
• データだけはしっかりと残しておきたいとき

そこでコンテナから独立させたいデータ管理を実現する方法が用意されています。その方法には次の3つがあります。

• ボリューム
• バインドマウント
• tmpfsマウント

です。このうち一番最初の「ボリューム」は「ボリューム」であって、「ボリュームマウイント」とは言わないようなので用語の使い方として気をつけたいところです。

さて今回はこれら3つのうち、ボリュームとバインドマウントについてその基本を解説していこうと思います。

Dockerのボリュームについて

公式ドキュメント

→ボリュームの使用

基本的なイメージ図

まずコンテナのデータ管理についてボリュームと通常の場合との違いを下の図にしてみました。公式の図とは異なるもので、やや正確性には欠けますが基本的なイメージはつかめると思います。

この画像の←側がボリュームのイメージ図、→が通常の場合となります。

まず通常の場合ですが、コンテナ内部にデータ保存の領域があります。それゆえコンテナを削除すると保存されたデータも消えます。

一方でボリュームを利用する場合は、使っているPC（仮にWindows10マシンとします）の中にDockerによってデータ保存のための特殊な領域が作られ、それをDockerが直接管理します。上の図でDocker Desktop for Windowsの中にボリュームという領域を入れてあるのはそういう意味です。Dockerが直接管理しているという意味です。

基本的にWindows10からそれには簡単にアクセスできません。そしてまたその領域はコンテナとは別の存在です。コンテナはあくまでその領域を利用するだけです。よってコンテナを削除しても、その特別な領域は残ります。

Dockerのバインドマウントについて

公式ドキュメント

→バインド マウントbind mount の使用

基本的なイメージ図

上のボリュームと同様に、正確さにはやや欠けるでしょうが簡単なイメージ図を作ったので見てください。

この画像の内容の説明ですが、今仮に手元のPC（今回の例ではWindows10マシン）で作ったCドライブ中のmountedフォルダが存在しているとします。その中には画像Aなどのファイルが入っています。

そしてDockerのバインドマウント機能を使ってそれをコンテナAのtargetフォルダへマウントさせます。これが画像中の矢印①です。

こうすると、コンテナAのtargetフォルダと手元PCのmountedフォルダがまるで同期しているようになります。スマホとクラウドサービスによるデータ管理みたいな感じですね。

結果、targetフォルダから画像Aを削除すると、mountedフォルダの画像Aも消えます。その逆も然りです。まるで同期しているようになるとはこういう意味です。どちらかをいじると、他方にもそれが反映されます。

ということは、手元のWindows10マシンでコードをいじって、それを（すぐ）コンテナAのほうへ反映させることができるというわけです。

ですが、バインドマウントの場合は、

• コンテナでうっかり何かを削除すると、ホストPCにも影響が及ぶ
• 逆にホストPCでうっかり何かを削除するとコンテナにその影響が及ぶ

という点でけっこうリスクがある機能となります。ですので上の「バインドマウントとの違いとメリット」で書いたとおり、公式ではまずボリュームを使うことが推奨されています。

バインドマウントとボリュームとの違い、それぞれのメリット・デメリットとは？

最後にボリュームとバインドマウントとの違いについて見ておきましょう。上の公式ドキュメントのボリュームの項目では次のようにその違いと、ボリュームを使うメリットとが説明されています。

• ボリュームはバインド マウントに比べ、バックアップや 移動migrate が簡単
• Docker CLI コマンドや Docker API を使ってボリュームを管理可能
• ボリュームは Linux と Windows コンテナの両方で動作
• ボリュームは複数のコンテナ間で、より安全に共有可能
• ボリューム ドライバによって、リモートホストやクラウドプロバイダに保管でき、ボリューム内容の暗号化や、他の機能性も追加可能
• 新しいボリュームは、コンテナによって内容を事前に入力可能
• Docker Desktop 上のボリュームは、Mac と Windows ホストからのバインド マウントに比べ、より高い性能

→ボリュームの使用

ようするに、バインドマウントと比べるとボリュームのほうが処理速度が速く、データの管理という点で使い勝手が良いことが多いという感じですね。したがって、Docker公式としてはまずはボリュームを使うよう検討することが推奨されています。

さらにもっと端的に本質的な違いを述べると、

• バインドマウントはホストPC（DockerがインストールされているPC。今回の例では手元で使っているWindows10）と直接連携し、両者の間でデータの作成・編集・消滅などが同期され、反映される
• ボリュームはホストPCと直接連携はしない。よってボリューム領域のデータを編集しても、ホストPC側には影響しない（反映されない・同期しない）

という2点です。乱暴にいえば、両者の違いはホストPCと連携しているかどうかです。バインドマウントは連携しますが、ボリュームは連携せず無関係です。

したがってホストPC側とDockerコンテナ側とで共有したいデータがあり、両者間でそのデータを（即座に）同期させたいならば、バインドマウントを使おうということになります。

このバインドマウントを利用したのが、Visual Studio Codeとその拡張機能拡張機能 Dev Containersを使ったリモート開発環境です。それについては下の記事で開発環境構築の基本的な解説を行っています。

【初心者向け】VS Code+Docker＋Python環境の作り方の初歩をわかりやすく解説

【初心者もできる】MacでDjango用にVS Code+Docker+Gitのリモート開発環境を構築する方法の解説

また処理速度という観点からは、バインドマウントの場合はホストPCと連携してデータをやり取りするので、ホストPCのOSとDockerの土台となるLinuxとでファイルシステムが異なる場合は、それら異なるシステム間でデータ交換するためにコンピューター内部でうまくデータを相手にあわせて編集・調整することが必要です。

それがマシンにとって余計な負担となります。よって、バインドマウントの場合は処理速度が遅くなりがちです。それゆえ上でボリュームのメリットして処理性能が挙げられているわけです。

なおdocker-compose.ymlでのボリュームとバインドマウントの書き方については下の記事をご覧ください。

【Docker入門】docker-compose.ymlにおけるボリュームとバインドマウントの読み方・書き方についてその基本を解説

以上簡単ながら、Dockerのボリュームとバインドマウントの基本的な考え方の解説でしたが、Dockerの使い方については動画学習サイトUdemyでも次のようなわかりやすい人気講座があるのでおすすめです。