回答編集履歴
1
言い訳を追加
answer
CHANGED
|
@@ -7,4 +7,11 @@
|
|
|
7
7
|
Docker をこのようにして開発に利用する場合、本番環境用の Dockerfile には、本番向けにビルドされたバイナリを、直接イメージにコピーするような記述を行うはずです。 そこではもう、バインドマウントに頼ることはありません。
|
|
8
8
|
- Docker ホストのファイルやディレクトリ構造が、コンテナーにとって必要となるバインドマウントと合致することが保証されている場合です。
|
|
9
9
|
|
|
10
|
-
バインドマウントはかなり特殊な環境でないと使わないと考えたほうがよいでしょう。
|
|
10
|
+
バインドマウントはかなり特殊な環境でないと使わないと考えたほうがよいでしょう。
|
|
11
|
+
|
|
12
|
+
追記：
|
|
13
|
+
アッ、よく読まずに脊髄でリプしてましたすみません。「Docker 上の Ruby を使ってソースコードを共有しながらすばやく変更を適用しつつ実行させたい」場合は合っています。ただ実際問題わたしの経験ではここまでバインドマウントを活用するかというと微妙なところです（さっき言われて思い出したくらい）。Docker を使うのは最終的にサーバーで動かすイメージを作るときくらい、というところも多いと思います。
|
|
14
|
+
|
|
15
|
+
というのも昨今のプログラミング言語はプロジェクトごとにローカル環境を用意できるようになっており、バージョンの差異やライブラリの依存関係にそこまで気を使わなくて良くなったからです。Ruby であれば rbenv がそれに当たります。もしくはビルドの重い Rust や Haskell などのコンパイルする言語では Docker 内にコンパイル済みキャッシュを溜めといてイメージをメンバーと共有して開発する、なんてケースを今思いつきました。
|
|
16
|
+
|
|
17
|
+
というわけで以上言い訳です！認識合ってますが、ほぼ使われないって感じです！
|