What is the best way to set up a git repo for a wordpress project that uses vagrant.
Do you add your vagrant setup to each project repo? What if you then update your vagrant setup?
And currently I deploy using git, but I wouldn’t want the whole git repo deployed. Is there a way to do this?
I know this is all coming in tutorials, but just hoping to get a head start now.
Ideally you have a separate Vagrantfile in each project repo. It gets a bit messy if you have a lot of WP sites for example with the exact same setup though. I’m actually not sure the best way to handle this but you could create your own custom base box and just re-build the VMs whenever you do an update to it.
Can you give an example of why you don’t want to deploy your whole git repo? What are you excluding?
Thanks for the reply. Sorry it took me a while to get back to this - had the flu.
So I’m just a bit lost on what would go in a git repo. Currently I have my repo set up as:
project_dir
-vagrant
-puppet (I know you use chef)
-shared
–www
and then all my wordpress files in the www folder.
It seems that this shouldn’t all be in the one repository, as then if I change my vagrant build, I’d have to go into all the repositories and change it manually.
Also when I deploy, I don’t want to put all the vagrant files on the server, just those files in www.
Having a hard time visualizing your folder structure (seems formatting as a list broke too), but here’s what I think it should look like:
/project /puppet /wp /wp-content wp-config.php index.php Vagrantfile
In your example, what’s in the vagrant directory? Usually you’d have just a Vagrantfile. Vagrant automatically creates a .vagrant dir but that should be git ignored anyway.
If you’re using the same Vagrant setup across a lot of projects, you should probably have your own custom base box so you can update that in one place. Then you’d just need to destroy and re-create your box to get a newer version. But since you’re using Puppet, ideally your manifests are actually a separate repo of their own. For example with Chef, I don’t include the Cookbooks themselves in a project repo. I use Berkshelf and just keep a Berkfile included. For Puppet, there’s librarian-puppet.
Either way, you can update your configuration management files separately (as they probably should be). So your folder would then look like:
/project /wp /wp-content wp-config.php index.php Puppetfile Vagrantfile
In terms of what’s in Git at least. There’s probably some plugins to integrate librarian-puppet with Vagrant but I don’t know enough about them/Puppet.
Sorry the folder structure list did seem to be broken, not sure what happened. My folder structure is very similar to yours, except all the website files are in shared/www because I feel it’s a bit neater.
I do use Vagrant, but setup a new vagrant instance for each project. Is this not what I should be doing.
And thank you, librarian-puppet seems like the missing link in the puzzle.
I’m still a bit lost on what goes in git for your project, do you put the vagrantfile and puppetfile in there straight, or as submodules, or called in with some sort of package manager?
Having a VM setup for each website / virtual host is a major resource drain in my opinion. I’ve been running a single VM (single Vagrant / vagrant file) for the better part of a year with over 30 sites (virtual hosts) configured and operational. Add an extra entry to the Vagrant file, vagrant reload, add an entry to the hosts file and you’re ready to go.
Here is a Vagrant file that really gave me a jump on the LAMP stack.
Works with Vagrant 1.0.5
That’s fairly similar to the vagrant setup that I have using puppet.
Interesting about the 1 VM. I’m just getting my head around all this vagrant stuff still.
Can you please go over that a bit more. You add an entry to the vagrant file, I assume to forward a new port. The hosts file is the hosts file on your machine or on the VM? How does it know which site to point to?
And how do you manage the databases for all these sites? What happens to the databases if you shut down your VM?
I’m using vhosts too for the same basic reason as edcoffin–simpler to manage. I can see that you might have one VM for LEMP and one for LAMP–possibly a few of each if you’re trying to mirror production on certain providers–but I haven’t seen a detailed discussion about the benefits of separate-VM-per-project vs. vhosts.
FWIW, my quick notes on setting up a new vhost under VVV. I dev on Windows. Your hosts location may vary. Would be interested to hear if others use something different. I’ve thought about scripting this. It only needs a sitename and databasename.
In vvv/config/nginx-config/sites, copy sample and change
server_name (siteFQDN)
root (www/site-name/)
Add siteFQDN to local c:\windows\system32\drivers\etc\hosts at 192.168.50.4 (edit as admin)
Copy WP to www/site-name directory
In vvv/database edit init-custom.sql to create new database, user, password
Edit vvv/www/site-name/wp-config.php with database info and salts
vagrant provision
The VM must be up and ready when you run vagrant provision.
I save a copy of init-custom.sql with the project name as an extra node so I can recover it easily if needed.
I have been getting my head around Vagrant with the Varying Vagrant Vagrants repo from @10up also (@jmjf’s post above is also using this repo I believe)
Big fan of the fact that it has all these bits based around the new ‘develop.wordpress.org’ philosophy of WordPress with new build tools and Grunt.
With an edit to your hosts. file
192.168.50.4 local.wordpress.dev local.wordpress-trunk.dev src.wordpress-develop.dev build.wordpress-develop.dev
So to add a new site:
hosts. file.(Had to replace http with hxxp as I can only post 4 links :/)
Great discussion.
@MintyBear - All of my local sites live on the vagrant box, and were setup via the Vagrant file as entries. I have a static IP for the local box, and have NFS turned on (using Mac OS X). I am using ports 8080 and port 8443 (for SSL / HTTPS). I am using a single MySQL server for all the sites. If I shutdown the VM, I can’t access the sites or the database. I rarely ever suspend or halt the VM in fact. Like the others have said, add your custom entry to your hosts file
my-root-site.dev 192.168.0.5
Vagrantfile and Puppetfile should definitely be included in your Git repo. As they’re just single files they shouldn’t be submodules. Maybe you’re thinking that if those files are shared across a lot of projects they should be a separate repo of their own? Obviously that’s usually the correct way to think but I personally don’t like it in this case. Mostly since they’re just files and they will almost always contain project specific configuration.
Ideally you’d have a separate Vagrantfile/box for each project, but that’s easier said than done if you have 30 projects. I only have a few so it’s easy for me to have separate ones. It’s also good to consider what your production setup looks like. If you’re hosting those 30 projects on the same server then that might point to using 1 Vagrant setup for them all. If you have 30 separate production servers, then that points to using separate Vagrant boxes.
Hopefully this makes some sense. Bottom line is there’s general guidelines but it’s always whatever makes the most sense for your projects.
Don’t you lose any database changes you’ve made if you shutdown the VM? how do you handle this?
No, the database files are in a ‘saved state’ within the virtual machine. ‘vagrant up’ and you are right where you left off.
Hmm mine seems to be gone when I shut down, how do you turn off your virtual machine?