Using an Existing Vagrant Setup for PHP Development
Then I went to WhiskyWeb, which had a hackathon. I’m unclear on exactly what happened because my attention was elsewhere but it seems like @JayTaph showed off puppet and vagrant to @deizel*, who immediately built a vagrant setup for joind.in, which is an open source project that I’m currently leading. With the shiny new technology all packaged for me, I decided it was time to take a look!
Starting the VM
The goal is that a user can simply grab the code base and type a single command:
vagrant up
When you do this the first time, then a “base box” is downloaded and puppet installs the various packages that will be used to run your platform. Once you have the base box, you can use it again with a different configuration; very handy for anyone working with similar-but-not-quite-identical projects. The setup process goes beyond the platform and also sets up the application with appropriate configuration files, databases created and so on. This is fabulous because if you break something, change platforms, or otherwise get into a tangle of any kind – you can just recreate your platform!
If you’ve run the virtual machine before, this command just starts the VM again so that you can use it.
Pausing Between Sessions
You probably don’t want to leave the VM running all the time (I have a shiny new machine with enough RAM that I can if I want to, which is nice!), and just like any other virtual machine you can shut it off and restart it at the same point later on, using:
vagrant suspend
What I like about this is that it’s so simple :)
Throw it All Away
If for any reason, either you broke something, or you have new puppet config perhaps, you want to throw away your VM and start again, that’s easy to do:
vagrant destroy
We keep the base box, but throw away the actual VM instance when we do the above. This means that you get an entirely clean installation when you run vagrant up the next time, with everything reset to the way that it was. All the settings are very configurable so if you do end up making any changes on the VM, you can also make them in the configuration so that the next time you create the VM anew, those changes will be included.
Network Topology
Something I really liked about this setup, in comparison to the way that I usually do virtual machines, is that the VM shares files with the host machine. Joind.in is hosted on github, so I grab a copy of the repo, type vagrant up, and then just edit the files in the current directory as I normally would. I’m a vim user, so editing files on virtual machines has never really bothered me, but if you use a desktop IDE then this feature will make a big difference to the way that you work with it – and even for vim users, this eliminates the need for copying of .vimrc files and swearing at distros that install one leg of vi and call it good!
The vagrant box also knows how to connect to itself, so to get shell access you simply need to ask for it:
vagrant ssh
I think especially if you have a bunch of machines running, or potentially running, because all your development uses these platforms, this approach becomes increasingly valuable as you don’t have to keep tabs on hostnames or IP addresses. When you are in the directory for this project, the command gives you access to this VM … simple!
Shiny New Tools
It’s always easiest to learn something new by looking over someone’s shoulder (which is why I teach a tools course) and while I’m sure I’ll be diving into configuring the virtual machines in detail over time, just having this setup to try has been a great way to get started and see how it could work, tweak a few things on my own copy and so on. Personally I’m delighted to have come across vagrant in such an approachable way – if you want to have a play yourself, then feel free to clone the joind.in repo on github to take a look at what we have there. Thanks again to all the fabulous contributors who make this project what it is and continue to educate me every day!
* I haven’t figured out if it makes more sense to link to twitter or github when citing people who have done cool code-related things
Thanks for this. I’m not sure if my thoughts are entirely relevant to your post, but i’ll type them in anyway :)
I’m having a hard time understanding the current fad for things like virtualisation. I don’t see what’s wrong with a dev team simply having a central development server with vhosts, rather than each be forced to maintain a complex dev environment on their own machine.
I was forced to use this kind of setup on a recent contract, specifically using Vagrant, and I can honestly say that over the course of the project, about 20% – that’s weeks and weeks – of developer time was wasted faffing about with Vagrant and the things living within it.
Compare that to a previous employer, or the contract I’m on now, where it takes less than 5 minutes to get a developer up and running on the dev server, and maintenance is negligible. We spend out time developing instead.
I just find it puzzling.
@Paul:
Reasons for using a tool like Vagrant can include:
* Offline development and mobility
* Network connectivity
* Access and security
* etc
Not to mention that with a centralized environment, disruption to one equals disruption to all.
Thanks for the mention Lorna. I should probably give some props to my colleague @mmoscosa who helped out on the day.
> or you have new puppet config perhaps, you want to throw away your VM and start again
Worth pointing out here that the `vagrant provision` command will re-run your Puppet manifests (or Chef recipes) without the added wait of booting up a fresh VM (plus it won’t have to reinstall any packages that are already on the existing VM).
Paul, I can see where you are coming from. Compared to setting up your typical LAMP server, Vagrant is not without it’s own set of potential issues. You have to add varying versions of Vagrant, Ruby and VirtualBox to your stack (well, each developer’s machine, but likely the same versions of each), decide on an existing base box from somewhere or make your own (Google “veewee” for that), verse yourselves with any provisioning scripts you are using (Puppet/Chef/shell scripts), and maybe Google some obscure error messages generated by these tools you don’t normally use.
However, I think the advantages (time savings) lie within the infrastructure management side of things. To explain, let me try to create some scenarios if you don’t mind:
You set up a development box manually and lock it down enough so people don’t break things, or alternatively you create a VM instead (making snapshots possible). You run this VM centrally on bare-metal (using a hypervisor), or developers run this VM locally in VirtualBox (using their mouse), or they can run it in VirtualBox with Vagrant (using their command-line). Any of these options are equally viable, but hopefully you are somehow saving yourself the hassle of having to set up the development environment from scratch at a later date.
Beyond that (and this blog post, and maybe even the point you were making), the rest of the power seems to lie within the provisioning scripts themselves (not the virtualisation). Instead of manually installing all the required packages needed inside your development server (physical or virtual), you script it instead. These scripts act as documentation but can then be added to version control and used to consistently provision not only your development server(s), but also any staging server(s) and production server(s) – again, physical or virtual.
With things hitting “the cloud” more these days (back to virtual), this allows you to more easily scale applications horizontally by automating the infrastructure. Sure, you could just clone an existing VM (assuming virtual, still) as it already has the required packages, but here-in lies another advantage – automating environment consistency:
Say you are using Puppet; you have taken some time to set up any old server as a “Puppet master”; and now you want to move some of your application’s stack to a new version (say PHP 5.3 to 5.4, or simply a config value in php.ini). You change a line in your provisioning scripts, commit it to version control, and within minutes various servers start checking in to the master (or is it the other way around) and are told exactly how to go about their automated upgrade. Developers also get these changes from version control and all servers (the real ones and the developer’s toy ones) end up on identical versions. (Thanks again for sharing the knowledge @JayTaph)
I guess the point here is that YMMV. The tools are new but they scale well. The bigger your deployment(s) and/or number of projects, the more advantages you gain from learning them. And yes, the opposite can also be true as you point out, especially in the initial stages. The 80/20 split you mention – where developers spend time playing with virtual machines and configuration management instead of, well, developing – can probably be best be attributed to the “DevOps” term (which appeared on Wikipedia just two years ago).