Just curious what people think is the best way to work with Vagrant and WordPress:
Setting up a Vagrant VM for each project to have it’s own environment
OR
Using Vagrant as a kind of MAMP replacement where all the projects (or many projects) go on one Vagrant VM
I’m leaning to the first one but it seems like setting up an environment for each project could get messy and wasteful in the long run, even though it’s nice to be able to teardown the project when it’s done using vagrant destroy and only keep the necessary project files.
If I went the MAMP replacement route, I’d be setting up 2 Vagrant environments, one for nginx like VVV has and another using Apache for those sites that would be on a shared hosting solution that I don’t have 100% control of.
Anyway, just wanted some ideas – still trying to decide upon my workflow and wanted to know what others were doing.
I’ve been setting up one Vagrant VM per project. For a few projects I used VVV, it’s a cool set up, but takes a long time to provision the first time, and I don’t ever use the develop and trunk versions of WP that it sets up.
That being said, if you did want to have one VM for multiple WP projects, VVV is probably the way to go. I haven’t used this yet, but it does exist, a script to set up new WP installs, which could be used for separate projects: https://github.com/Varying-Vagrant-Vagrants/VVV/wiki/Auto-site-Setup
What I just did this past week was set up a custom Vagrant installation. I used this LAMP stack as a base, and used Bedrock to set up Wordpress:
I really like the set up, as now I can have the VM, the Composer file, and everything set up in my Git repository, while not having Wordpress or any plugins actually in the repo. It feels much better than only using the theme as the repository and manually moving anything else over to staging/production.
Only issue I’m having now is I want to have a few paid-for plugins as part of the Composer install. I’ve added them to their own private repo’s on Bitbucket. It works fine if I run composer install from the host machine, but I’m having issues getting the Vagrant VM to be able to run it, since the vagrant user does not have the correct SSH keys.
Very cool! I’m going to look this over and see if I can just use this to start making a LEMP setup – VVV is a bit overwhelming for me at this point and I honestly think that it’s more than I need.
I played around with creating a key and adding it to the VM and to Bitbucket… but as I was typing this I realized why not just use HTTPS instead of SSH. So that works, I can add in the private plugins as Composer Wordpress plugins, and connect via https://company-vagrant-user:password@bitbucket.org. It does have a generic password, but that user only has access to the plugin repositories, so I don’t foresee it being a big issue.
I was mostly looking for this to be something easy for myself and coworkers going forward. So once Virtualbox, Vagrant, and in this case Chef Berksfile and plugin are installed, we only have to clone the repo and type vagrant up and be on our merry way.
Im looking into Packer and Chef now too – I’m having trouble understanding the benefit of Chef beyond just making the syntax to manage server dependencies nicer (and maybe somehow make it work on any system?); is that all it does? I’m reading through the docs but it’s not clear beyond that…
Yes, Chef and Puppet (I’m not sure about Packer) are tools to help provision servers quicker and more efficiently. I believe they’re more flexible than shell scripts, as they have the ability to say “make sure this is installed”, instead of “apt-get install”. Also they can “make sure this is installed before this”, and “do this after this is already done”. I’m not a big server-side guy though, so I’m sure others would have a better explanation.
I looked at a few Vagrant LAMP stacks on Github and the one I linked seemed like the cleanest one while offering what I needed. Everyone’s needs are different though.
I’m using VVV - one for each project but mostly because I don’t have the time to experiment too much.
It’s working well for me but I do agree it takes a while to setup and I don’t need the dev trunks it sets up. That said you could always delete that stuff from the repo before you run your first vagrant up…
I’d prefer to have one Vagrant box for multiple sites. We host a bunch of sites on one VPS so this approach makes sense for us.
The problem I’ve had with the one-box-per-site approach is it uses about 1gb of space for each box and takes forever to Vagrant up/down for each project. We jump between about 10-15 sites at any time with support requests and add-ons, so it was difficult/time-consuming to manage.
I’m checking out that VVV Auto Site Setup, thanks for posting that.
Are you destroying each box when you finish? After the initial vagrant up, it should be pretty quick to vagrant up after a vagrant suspend or vagrant halt.
I’m using vagrant halt and vagrant up to run and shutdown the machines but on vagrant up it usually takes about a minute or so to load: “Waiting for machine to boot. This may take a few minutes…”
We jump between quite a few sites per day. A 1 min load adds up over time. Our server setup is pretty much the same for most wp-based sites as well so using one vm should be ok unless I’m missing something.
I was going to say it only takes me 1 - 2 minutes to boot my VVV box but in your case @billaddison that makes sense…
I normally work on 1 - 2 projects at a time. Once they launch I prefer to just make FTP edits back and forth. I keep my theme in Git so it’s easy to see if something’s changed or anything like that.