Docker和OS X上的文件共享
好。 我正在玩弄不同的工具来准备开发环境。 Docker是不错的select。 我在Docker中创build了整个开发环境，并可以在其中构build一个项目。
该项目的源代码在Docker容器之外（在主机上）。 这样你就可以使用你的IDE编辑它并使用docker来构build它。
但是，有一个问题
a）OS X上的Docker使用VM（VirtualBox VM）
b）文件共享相当慢（比主机上的文件IO慢）
c）项目有一些像gazzilion文件（夸大问题#a和#b）。
如果我在Docker中移动源代码，我将在IDE中遇到同样的问题（它将不得不访问共享文件，速度会变慢）。
我听说了一些解决方法，使其快速。 但是，我似乎无法find关于这个问题的任何信息。
更新1
我使用了Docker文件共享function（意思是我运行）
docker run -P -i -v <VMDIR>:<DOCKERDIR> -t <imageName> /bin/bash 但是，VM和Docker之间的共享不成问题。 它很快。
瓶颈在主机和虚拟机之间共享。
我使用的解决方法是不使用boot2docker，而是使用docker configuration一个stream浪VM。 对于挂载文件夹host-> vagrant-> docker没有这么大的代价。
不利的一面是，我必须将文件夹预先映射到stream浪汉（基本上是我的整个工作目录），并将一系列端口从stream浪盒预先展示给主机，以便直接从那里访问Docker服务。
另一方面，当我想清理未使用的docker垃圾（图像，卷等）时，我只需要摧毁vagrant vm并重新创build它:)
精
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| config.vm.box = "trusty-docker" config.vm.box_url = "https://oss-binaries.phusionpassenger.com/vagrant/boxes/latest/ubuntu-14.04-amd64-vbox.box" config.vm.provision "docker" #by default we'll claim ports 9080-9090 on the host system for i in 9080..9090 config.vm.network :forwarded_port, guest: i, host: i end #NB: this folder mapping will not have the boot2docker issue of slow sync config.vm.synced_folder "~/work", "/home/vagrant/work" end
有这样的：
host$ vagrant up && vagrant ssh vagrant$ docker run -it --rm -v $(pwd)/work:/work ubuntu:12.04 find /work
这不幸是一个典型的问题，Windows和OS X用户目前正在苦苦挣扎，这是无法解决的，特别是在Windows用户的情况下。 主要的罪魁祸首是VirtualBox的vboxfs用于文件共享，尽pipe是非常有用的，导致糟糕的文件系统I / O。
客户虚拟机内部开发项目来源的情况很多，主要有几十个第三方来源，由包pipe理器和Git仓库引入，具有相当大的历史。
显而易见的方法是将vboxfs以外的vboxfs项目相关文件vboxfs guest vboxfs 。 例如，将包pipe理器目录符号链接到项目的vboxfs树中，如下所示：
mkdir /var/cache/node_modules && ln -s /var/cache/node_modules /myproject/node_modules
只有这样，启动时间从〜28秒降低到〜4秒，而Node.js应用程序在我的SSD上运行了几十个依赖项。
不幸的是，这不适用于pipe理Git仓库，除非Git仓库本身在guest虚拟机中进行供应，这迫使您有两个仓库：一个克隆充气环境客人和另一个包含实际来源的地方，巩固两个世界成为一个绝对的痛苦。
处理这种情况的最好方法是：
- 放弃
vboxfs，转而使用共享传输机制，从而在客户机中实现更好的I / O，如networking文件系统 。 不幸的是，对于Windows用户来说，获得NFS服务支持的唯一方法是运行Windows企业版（我相信Windows 10仍然如此）。 - 还原为将原始磁盘分区挂载到guest虚拟机，注意到给予pipe理程序原始磁盘访问的相关风险
如果您的开发人员完全受到Linux和OS X用户的影响，则选项1可能是可行的。 创build一个Vagrant机器并configuration你的主机和客户之间的NFS共享和利润。 如果你有Windows用户，那么，他们没有购买一个企业许可证，最好只要求他们重新分区他们的磁盘，并在访客虚拟机内工作。
我个人使用Windows主机，在我的SSD上有一个64 GB的分区，我可以直接挂载到我的Arch Linux客户机上并从那里操作。 我也切换到了GPT和UEFI，并且有一个选项可以直接启动到Arch Linux，以防止虚拟化硬件的开销，让我两全其美。
两个步骤可以很好地提高你的performance：
-
切换到NFS 。 你可以使用这个脚本来做到这一点 。
-
将您的VBox NIC驱动程序切换到
FAST III。 你可以在你的default机器上运行：
VBoxManage modifyvm default --nictype1 Am79C973 VBoxManage modifyvm default --nictype2 Am79C973
我运行一个简单的监视脚本，在共享的源代码卷中将我的容器中的一个rsync启动到只有容器的卷，每当有任何更改。 我的入口点只能从容器中读取，这样可以避免性能问题，并且rsync工作得非常好，特别是如果您正确设置，以避免像.git文件夹和不经常更改的库那样。
我发现了几条信息
-
我开始使用Vagrant来处理VirtualBox并在其中安装Docker。 它给了更多的灵活性
-
Vagrant VirtualBoxconfiguration中的默认共享非常慢
-
NFS共享要快得多。 但是，它可能会相当慢（特别是如果您的构build过程将创build需要被写回到这个共享的文件）。
-
Vagrant 1.5+有一个rsync选项（使用rsync将文件从主机复制到VM）。 速度更快，因为它不必回写任何更改。
-
这rsync选项有自动同步（连续同步）。
-
这rsync选项消耗了大量的CPU，人们想出了一个gem来克服它（ https://github.com/smerrill/vagrant-gatling-rsync ）
所以，Vagrant + VirtualBox + Rsync共享文件夹+自动rsync +stream浪汉gatling看起来像一个很好的select，我的情况（仍在研究它）。
我尝试了stream浪汉。 但是，这会导致不确定的行为。 我永远不知道新文件是否被复制到虚拟机中。 如果需要1秒钟，这不会是一个问题。 但是，这需要20秒太多（用户可以切换一个窗口，并开始构build，当新的文件尚未同步尚未）。
现在，我正在考虑一些方法来复制只有改变了的文件。 我仍然处于研究阶段。想法是使用FSEvent来监听文件更改并只发送更改的文件。 看起来好像有一些工具可以做到这一点。
BTW。 Gatling内部使用FSEvent。 唯一的问题，它触发完整的rsync（它开始比较date/时间和大小为40K文件）