ドキュメントで詳しく述べられています。
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:49
2020/12/31 07:29
2020/12/31 23:37