Skip to content
This repository has been archived by the owner on Oct 29, 2020. It is now read-only.

Vagrant and file sharing: SSHFS

Sergii Tkachenko edited this page Mar 30, 2015 · 4 revisions

Why do we have two mounted directories?

Vagrant, by default, shares the host directory where you vagrant up as /vagrant within the virtual machine. This is a convenient file mount, but it's also really really slow. Web apps that love to scan directories and files (e.g., Drupal, Magento) perform poorly in this scenario, because Vagrant's access to this shared mount is slow to scan.

We've built in a three-step workaround to this so Drupal can run much faster:

  1. During the provisioning (Salt Stack's work), Salt copies the contents of /vagrant to /var/www/dev.dosomething.org -- a directory that's native to the Vagrant machine, and thus much faster for it to read.
  2. Salt sets the Apache httpd docroot to /var/www/dev.dosomething.org/html. This is the directory that ds build will create when run from /var/www/dev.dosomething.org.
  3. After provisioning, Vagrant reverse-mounts /var/www/dev.dosomething.org to the host via SSHFS. This is relatively slow for your host machine to read, but that won't affect your life.

The original pull request for this workaround.

How do I work with this?

This leaves one unfortunate complexity: You have two identical directories on your host machine, dosomething (where you initially cloned your repo and ran vagrant up) and dosomething-mount (where Vagrant reverse-mounted /var/www/dev.dosomething.org). Here's the rule:

  • dosomething: Use this for Vagrant operations, including vagrant ssh when you want to access the machine. You only need to update via Git if there are codebase updates that require you to reprovision (i.e., vagrant provision) your machine.
  • dosomething-mount: Use this for your actual work on the app.

Remember, Do not build the app in /vagrant. This is the wrong place.

Instead,

% ds build --install

And when you need to drush:

% cd /var/www/dev.dosomething.org/html
% drush status

Can we do better?

Oh, always. One great contender to replace this business is Docker.

Clone this wiki locally