I faced this problem when I started working for a small software company while studing. I should work on a Java application which served a webshop-like aftersales website for one of the biggest German automotive companies. I spend almost an entire week setting up my PC so I could run the project in my browser. I got it working, but there where some bugs which did not occur on the other developers PC. I lost another week trying to solve this. And, and this was real fun, parts of the software didn't behave like on the production servers. The main problem was that nobody could tell me the exact steps to set up an environment which worked. It was all like "Well, you need JBoss" and "I have PostgreSQL installed that way, maybe that's the problem". You can imagine my frustration from day 1.
So, if the above describes your setup, you may want to think about doing it another way.
And as many companies have the same problem, one developed a solution: vagrant. Using it together with chef you can build an environment in a virtual machine that behaves like your production server, is host-os independent and can be set up with one command, installing all the software you need on the guest os every time it gets executed. This solution was brought to my attention by the guys from @mayflower at the #sfugmuc.
The theory
If one thinks about it, it's not very hard to set up a virtual machine. You set up the vm, install a minimal linux (like debian or ubuntu server) and install the software you need. But there are some pitfals:- You need to provide the basic image somehow so everybody has the same to start with
- There are some configurations which might be host-depending, like shared folders, network ip and even stuff like the ServerName for the apache vhost
- Setting up all the software the right way might get nasty if you not only want to have a default lamp stack but need to set up virtual hosts, special php.ini files, mysql databases and many other things.
- You lack flexibility. What if you need to add a software package? Everybody has to get your new virtual machine, every change the others made to their machines are gone and they have to customize again.
Enter vagrant & chef
Managing virtual machines (using virtualbox) is what vagrant does. You provide it with a configuration file like this and it creates your vm if it does not exist, adds the shared folders, boots it and executes your "configuration script". This scripts can either be self written (Please don't even think about doing this!) or you may use a automation tool like puppet or chef. With this tools you say what you want to have installed on the computer and they execute a predefined set of commands so everything is in place. You can configure templates which get moved someplace, so virtual hosts, php.ini or my.cnf are no problem. This templates can be populated with variables which can be filled from the Vagrantfile.With this approach all your developers have to do is install virtualbox, install vagrant and get the vagrant configuration file. They type one command and the virtual machine gets booted, ready to use. If the developer got some non-standard configurations, he changes the vagrant configuration file.
Of course you got some drawbacks: Performance might not be as good as xampp running on windows and developers has to ssh into the virtual box to execute commands and the like. For us, the first one is a minor issue and the second one would be no problem, as we use the command line all the time and it doesn't matter if it's cygwin or putty.
There is more!
All the pros described here are easily enough to get me excited. But there is even more. Since I use vagrant, I play around a bit more, knowing I can just throw away the vm, boot up vagrant and have the same setup as before without my interaction. I installed solr and messed the system up pretty good. Two commands and one coffee later (setting up the vm the first time really takes time for my setup as there is much software installed) solr was no more. It was gone and with it everything I changed.Another very big benefit is that the chef cookbooks give us an exact reciepe what is installed on the vm and in what sequence. We know what software might be needed on production servers. Better yet, as vagrant configuration and chef cookbooks are in git, we can track the progress and see what changed. This may hint us what we need to install on our servers the next time we deploy.
GO!
I pushed my vagrant setup and the chef cookbooks I use into a github repository called symfonyVagrant. It's called that way because it should be sufficient if you develop symfony2 applications. I added some software you might not need like Python, MongoDB and redis, but they are installed optionally. You can fork the repository and use it as a starting point or simply download it and use it right away. It includes cookbooks from opscode and others and some of my own standard files (like php.ini, my.cnf or the mongo.conf). Of course I'm happy if you have some improvements and do a pull request :) And I always appreciate a nice comment here or a email if you find the repository usefull.If you want to start from scratch, I suggest reading the vagrant tutorial (it's very good!) and then looking into the opscode cookbooks. You should pick up what you need on the way.
Keine Kommentare:
Kommentar veröffentlichen