Vagrant provisioning shell vs puppet vs chef

Question

I have the following setup:

• Many different projects which are separate git repositories, but all have mostly the same server configuration
• Each project in turn depends on many other projects and we use the composer dependency manager to get them together (PHP language here).

I want to use Vagrant and include a Vagrant file in each repository, so my team members can clone a repository, run vagrant up and be ready to go.

My question is now directed towards the provisioning. I need to install several tools and packages like apache, git, mysql and several php packages, then download some files (like a recent development db dump), set everything up in /var/www and run the composer install command.

So one option to do this is using a manager using recipes like chef or puppet. The alternative would be to write a bash file and use shell provisioning.

I have not much experience with chef / puppet, so naturally, it seems easier to use the shell option, but I want to understand if this is not a good / viable option in the long run.

Why to me it seems a bad approach to go with puppet / chef:

I understand that I will have to use several different recipes and will almost always use the same recipes for my different repositories, so I would have to include all of them in all the repositories. Consider having 20 repos and needing 10 recipes, that means that I will need to add 200 recipes as a git-submodule or alike (also each team member needs to clone the repository, then clone 10 recipe repositories and only then run vagrant up for each project). In contrast, I would just need to have a small repo with my shell script and clone it 20 times.

I am probably missing something, so please advice whether I should opt for chef / puppet and why it makes sense even if my repositories all have a very similar server setup.

Answer 1

Updated 2016

For those who found this through Google, it seems a bunch of developers are moving towards Ansible for the simplicity. From post:

"Ansible is the deployment tool for people who don't like deployment tools. It's close to scripting, doesn't pollute your servers with agents or centralized servers, and just makes immediate sense."

We implemented it recently in our microservice architecture and it's been awesome.

• Super simple
• Took about a day to pick up
• Don't really need to think about it once you're set

Puppet/chef always have a place in my heart / stack, but Ansible is just easier.

Answer 2

The following article concerns yet another CM tool (ansible), but I think the author does an excellent job of explaining the benefits of transitioning away from shell scripts.

http://devopsu.com/blog/ansible-vs-shell-scripts/

quote 1:

What really surprised me was the response from some of these more famous devs. They basically said, "This is really cool, but I probably won't read it since my manual-install/shell-script workflow is fine for now."

I was a little shocked, but once I thought about it for a few minutes, I realized that their choice was perfectly sane and rational given what they knew about CM tools.

quote 2:

For them, using a CM tool meant weeks of effort learning complex concepts, struggling with a complex installation process, and maintaining that complex system over time. They were somewhat aware of the benefits, but the costs of using a CM tool just seemed too high to make it worth the effort.

The benefits over shell scripts are summarized at the end and I think they apply to all CM tools, puppet, chef, salt, ansible...

• Which method is most likely to end up in source control?
• Which method can be run multiple times safely with confidence?
• Which method can easily be run against multiple servers?
• Which method actually verifies (tests) your server for correctness?
• Which method can target certain servers easily (web, db, etc)?
• Which method supports easily templating your configuration files?
• Which method will grow to easily support your whole stack?

Hope this helps.