バインドマウントとネームドボリュームの実践での使い分け

dockerを勉強して3日目の初心者です。
検討違いの質問してたらすみません。

バインドマウントとネームドボリュームについて。

両者のコマンドや比較ついての情報はウェブ上でよく見受けられるのですが、
実践においてどう使い分けするのか分かりません。

ruby on railsによるアプリを動かす想定です。

私なりにこうするのかな？と考えてみました
↓
・保存場所を知る必要がないためDBは、ネームドボリュームにする
・rubyファイルなど編集するものは、場所が分からないといけないのでappごとバインドマウントにする

間違っていればご指摘いただけると幸いです。

他に実務ではこういう使い分けしてるよ、というのがあれば是非教えてほしいです。
諸先輩方よろしくお願いします。

行動規範の内容に同意します

回答2件

ドキュメントで詳しく述べられています。
Docker におけるデータ管理 | Docker ドキュメント

一般的には、可能なかぎりボリュームを用いるべきです。バインドマウントは、以下のような利用例において適切と考えられます。

設定ファイルをホストマシンからコンテナーに共有するような場合です。デフォルトで Docker はコンテナーに対し DNS 解決機能を提供しますが、それがこの状況に相当します。この場合、/etc/resolv.conf をホストマシンから各コンテナーへマウントすることを行います。
ソースコードやビルド結果を、Docker ホスト上の開発環境とコンテナーとの間で共有する場合です。たとえば Maven の target/ ディレクトリをコンテナーにマウントします。 Docker ホスト上にて Maven プロジェクトをビルドするたびに、コンテナーは再ビルドされた結果をすぐに利用します。
Docker をこのようにして開発に利用する場合、本番環境用の Dockerfile には、本番向けにビルドされたバイナリを、直接イメージにコピーするような記述を行うはずです。そこではもう、バインドマウントに頼ることはありません。
Docker ホストのファイルやディレクトリ構造が、コンテナーにとって必要となるバインドマウントと合致することが保証されている場合です。

バインドマウントはかなり特殊な環境でないと使わないと考えたほうがよいでしょう。

追記：
アッ、よく読まずに脊髄でリプしてましたすみません。「Docker 上の Ruby を使ってソースコードを共有しながらすばやく変更を適用しつつ実行させたい」場合は合っています。ただ実際問題わたしの経験ではここまでバインドマウントを活用するかというと微妙なところです（さっき言われて思い出したくらい）。Docker を使うのは最終的にサーバーで動かすイメージを作るときくらい、というところも多いと思います。

というのも昨今のプログラミング言語はプロジェクトごとにローカル環境を用意できるようになっており、バージョンの差異やライブラリの依存関係にそこまで気を使わなくて良くなったからです。Ruby であれば rbenv がそれに当たります。もしくはビルドの重い Rust や Haskell などのコンパイルする言語では Docker 内にコンパイル済みキャッシュを溜めといてイメージをメンバーと共有して開発する、なんてケースを今思いつきました。

というわけで以上言い訳です！認識合ってますが、ほぼ使われないって感じです！

投稿2020/12/31 05:01

編集2020/12/31 07:29

A_kirisaki

総合スコア2853

pecchan

2020/12/31 05:49

A_kirisaki様有難う御座います。 >バインドマウントはかなり特殊な環境でないと使わないと考えたほうがよいでしょう。 railsのコーディングは、「特殊な環境」にあたるという理解でよろしいでしょうか？ドキュメントの以下の部分が該当するようですが・・・。「・ソースコードやビルド結果を、Docker ホスト上の開発環境とコンテナーとの間で共有する場合です。」またdockerチュートリアルにも、「バインドマウントを使えば、ホスト上の正確なMountpointをコントロールできます。データの永続化にも使用できますが、追加のデータをコンテナに提供するのによく使われます。アプリを開発する場合、バインドマウントでソースコードをコンテナに接続して、コードを変更したり、応答したり、変更をすぐに確認したりできます。」とありました。