Search code examples
shellchef-infravagrantpuppetprovisioning

Vagrant provisioning shell vs puppet vs chef


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.


Solution

  • 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.