When we first started working on Varying Vagrant Vagrants, the overarching goal was far different than it is now.
Originally, we wanted to build a project template that could be easily customized to individual project needs. The idea was that a new project would consist of just a few configuration settings on top of an otherwise vanilla VVV install. You could ship your project configuration to a coworker and they could be up-and-running with a project-specific virtual machine in seconds.
To this end, when I started coding on a Mac I set up individual Vagrant boxes for each and every project in the hope that our little templating system would continue to evolve. It did, but not how I expected it.
Varying Vagrant Vagrants today is a much larger project sandbox than I originally thought it would be. The default box comes pre-installed with PHPUnit for testing, Grunt for building projects, Ruby for running Sass, and three separate instances of WordPress for core development. VVV has evolved into a suitable replacement for MAMP, Xampp, and Wamp, and most developers are using it that way.
To be honest, I even use it this way on my Windows machine. Granted, I have some customizations I’ve made over there that I finally decided to port over to my Mac environment.
Making Changes
The first change I made was to force MySQL to leave its data in the virtual machine. Trying to continually access the database across a shared connection was slow. I put up with it for a long time because I didn’t realize just how slow it really was. Once I set up Hyper-V on my Windows machine, though, I realized it was a night and day difference.
First, don’t mount the [cci]/data[/cci] directory in your virtual machine. This prevents the directory from being mapped within the VM, so all databases and tables will live there rather than on the host machine.
Second, edit [cci]my.conf[/cci] (in the MySQL part of the configuration settings) to include the following line: [cci]innodb_file_per_table=1[/cci].[ref]This prevents MySQL from dumping the entirety of its data store into one file. If you create, say, a 10GB client database, this file would expand to contain it. Deleting the database would not free up harddisk space or contract the file. Using this setting creates a new file for every table, so you can more easily clean up the database later.[/ref]
Next, I forced the directory shares to use NFS. I use Samba on my Windows machine, and it’s incredibly faster than VirtualBox’s native file sharing setup. To use NFS, you’ll need to add [cci]type: “nfs”[/cci] to each of your shared directory declarations. For example:
[cc lang=ruby]config.vm.synced_folder “www/”, “/srv/www/”, type: “nfs”[/cc]
You will also need to remove any owner or mount options (file-permissions) settings from your declaration since these aren’t compatible with the way NFS will be mounting the drives.
That’s it!
Local Development Evolved
I usually try to change as little as possible when I’m working with released software. What I do change I offer back to the community so others can iterate on any potential improvements I find (or can ridicule me for doing something wrong).
Either way, the settings above were all I had to change to get my Mac environment to match my Windows one. VVV is far faster with these changes set up, and I’m super happy using a single environment for all of my projects rather than juggling multiple VVV installs.[ref]Each VVV setup was between 500MB and 10GB on its own. I was running a total of 7 environments on my machine, so it wasn’t a trivial thing. Instead, I now have one environment that weighs in at 3GB. Still large, but not unmanageable.[/ref]
