Shared and automated vagrant box - automation

Question

I'm thinking of using Vagrant to develop Django applications, but I'm a little confused and I'm not sure if what I would like to do is even possible.
I installed the lucid32 box successfully and created a new "instance" of vagrant, with a Vagrantfile, some shared directories and forwarded ports.
The first issue is that this doesn't seem to me the best choice when working in a team. How can we (me and other 10 developers, for example) share the box so that every change to it is shared? For example, if in 6 months we need postgresql, I need to have it working without having to install postgresql 11 times.
Also, how can I make things (like: postgresql, django, this-service, etc.) to start when the box has started up? I don't think that I have to ssh it and manually start n times all the n things I need every time.
And finally: I don't understand well if things like puppet and chef are meant to completely substitute the manual installation (through pip or apt-get, for example). Is that so?
Thank you.
And I'm sorry for bad english. :-)

Answer 1

I would say that your choice of Vagrant already was a good start to what you are looking for, but now you need to dig a little deeper into either Chef or Puppet, to further automate your provisioning process.
I guess a good choice in your sceneraio would be to first put both, the Vagrantfile and the corresponding Puppet manifest under version control as part of your project. Additionally, all of the configurations concerning this machine should also be put into version control and/or be made available through some sort of artifact repository.
Second, establish the rule in the team that changes (at least these that should live on for longer) to the environment need to be checked in if they are considered ready for the other team members.
Concerning your second question and coming back to my opening: Puppet (which I like) or Chef are your tools of choice and can save you and your colleagues a lot of work in the future. I'll stick to Puppet here, as I don't know Chef too good.
With puppet, you can manage all of what you want, the installation of packages, changing configurations and ensuring that certain services are running, or in general that the system has the state you want it to be. Even better, if you or another team-member made some malicious chages to his/her box, you can just rollback the changes in your Vagrantfile/Puppet manifest, type in
vagrant destroy && vagrant up
and the box is easily taken back to the last versioned state.
For example, take the following manifest file:
package { "mysql-server-5.1":
ensure => present
}
file { "/etc/mysql/my.cnf":
owner => "root",
content => "http://myrepository.local/myProject/configurations/mysql/my.cnf",
require => Package["mysql-server-5.1"]
}
service { "mysql":
ensure => running,
subscribe => File["/etc/mysql/my.cnf"],
require => File["/etc/mysql/my.cnf"]
}
What this does is, it first of all checks the package mechanism of the OS in your box (the names in the example assume a recent Ubuntu) if the package "mysql-server-5.1" is installed, and if not it'll install it. Through the 'require' attribute, the second directive will be executed after the first (and only if it worked), changing the MySQL configuration to the one you have also checked in and/or published somewhere you can reach it (that could also be put into the same folder as the Vagrantfile, and will then be available in the box under /vagrant). The last step, which again only will be executed if the altering of the configuration worked, will ensure that the "mysql" service is up and running or is getting restarted if it already was running when the configuration was changed.
Now you can hook up this manifest in your Vagrantfile:
Vagrant::Config.run do |config|
config.vm.box = "lucid32"
config.vm.box_url = "http://files.vagrantup.com/lucid32.box"
config.vm.define "node1" do |cfg|
cfg.vm.network "10.23.5.11"
cfg.vm.provision :puppet do |puppet|
puppet.manifests_path = "manifests"
puppet.manifest_file = "node1.pp"
end
end
end
With all changes besides the 'trying-stuff-out' ones made to the environment like this, all team mebers are guaranted to have the same setup easily and reproducable just at their fingertips.
I personally like to try stuff out on the box by hand, and when I found the right setup and configuration, translate it into a Puppet manifest to have if ready for later use and sharing with team members.
As Puppet (and Chef also) can manage almost all you need (users, cron jobs, packages, services, files, ...) it is a good choice for exactly such problems, and you have the benefit to even be able to use the configurations to provision staging or testing environments later on if you choose to. Their are much more options with Puppet, and a read through the language guide should give you a good idea what more you can do with it.
Hope I could help :)