Shared Folder Performance in Vagrant


Leading a large and regularly replenished team of programmers, I was faced with the need to quickly develop a development environment without dancing with a tambourine in the spirit of “strange, does this code work for me, and what version of such a library do you have?”

Having once received a link from a customer to Vagrant with the question “why do we still not use it?” began to master this miracle.

After some time, he prepared Vagrantfile, which in a few minutes deploys a complex system of repositories, libraries, servers and deployers. And everything would be fine, but one small unpleasant detail - all this either terribly slowed down / buggy, or (with local execution) did not provide direct access to the repositories stored inside the vagrant.

Many will say why this direct access is needed if you can store copies of files on the host machine and deliver them to the guest machine automatically when saving them to the IDE.

That's right, but there is a nuance - the team needs the ability to switch branches (branches) of git repositories on the server, observe the result in the browser and edit the branch code in its IDE without leaving the cashier.

Many will say what the problem is, there is ssh and console git and even show a maniac who drives console console git client commands from the keyboard faster than the client manages to execute them. You can agree with this statement, but having 10 repositories and several dozen branches on the repository, I prefer to observe and manage all this visually, through SourceTree, and have almost any command to manage this colossus, within three clicks.

  1. Shared Folders - the speed of script processing turned out to be 10 times less than when executing with guest folders
  2. Sshfs
    • persistent reindexing in phpStorm
    • drop out of all files from git index when switching branches, with the need to constantly reset --hard
    • inability of IDE and git clients to notice changes in files
  3. NFS and NFS Reverse - stupidly refused to work on OSX without dancing with a tambourine (according to reviews on the Internet, they also do not solve the issue fundamentally)

After a few days (weeks?) Spent studying this issue, it turned out that I was far from alone in my aspirations, but nothing smarter than one-way synchronization via rsync, to date, the public has not really seen.

The closest thing I could find was the unison utility, which performs two-way incremental synchronization, and the vagrant plugin written for it -

True, another problem arose. The utility itself can automatically synchronize folders only in the mode of every second restart, which was not supported by the vagrant plugin. The plugin can provide automatic synchronization, not even in repeat, but in event-based mode, but only in one direction (host-> guest). Moreover, the plugin was written for version vagrant 1.1, and to date, it has not even performed the functions that are officially declared in it.

It turned out a little later, despite the fact that the plug-in was not updated by the author on April 26, 2013, 7 months ago another programmer made an attempt to bring the plug-in to life. The results of his work can be seen at:

Even his plugin refuses to install on the latest vagrant (1.7.x). By finalizing its code, I managed to achieve
  1. compatibility with 1.7.x;
  2. support repeat mode;
  3. the ability to resolve the conflict of the unison database after “vagrant destroy; vagrant up ”with the sync-cleanup command.

I present to you the result at:
Ready plug-in: - for installation via
vagrant plugin install vagrant-unison-0.0.15.gem

I have been using it for several days and am still pinching myself to make sure that I do not dream of the lack of brakes and glitches.
True, according to rumors, a 4-core processor is required for comfortable operation (and SSD + Parallels is desirable)

PS In connection with the comments that appear, I attach the illustration from the article
Vagrant - NFS shared folders for Mac / Linux hosts, Samba shares for Windows

PS Despite the fact that my fork has attracted attention (mainly a bourgeois) and still lives its own life, I have to say that at the moment I still use nfs_guest. I tried to use it before unison, but on my OSX it quietly refused to work until I found out that for nfs to work on OSX you need to have a localhost entry in / etc / hosts. nfs unfortunately does not inform applications about events in the file system, but amid problems with synchronization and CPU load, this is bearable. Intolerable blinking SourceTree, as it turned out, can be turned off in the settings (Refresh automaticly when files change)

Also popular now: