Great discussion on the different config management tools. My summary is:
Chef is great for folks who know ruby.
Puppet easier for sysadmins with no programming experience,
Ansible easiest of all as it is yaml and its popularity is increasing,
Salt seems to have the least take up.
However it more important How you use these tools rather than which one you use.
‘test-kitchen’ is the key and it supports chef, puppet, ansible, and salt (disclosure i wrote the plugins for puppet and ansible).
test-kitchen allows you to orchestrate your dev environents, run your scripts via push as well as run verification via serverspec tests. This allow much faster development of scripts.
A couple of other thinks i do:
Split config into library and application components. library components are open source and released to the puppet forge, chef commuity or ansible galaxy. berkshelf, librarian-puppet, librarian-ansible used to bring them in at test time (test-kitchen does this automatically) so you don’t store them in your repository. (You should lock the version of library components).
Application components call the library components and are named with a company prefix. Application components DO NOT call other application components. Components that are shared should be made into library components.
This makes dependencies much easier as you only need to look at dependencies when you change versions of library components.
In summary: “It ain’t that important which tool you choose rather it is important how you use them”
Great discussion on the different config management tools. My summary is:
Chef is great for folks who know ruby.
Puppet easier for sysadmins with no programming experience,
Ansible easiest of all as it is yaml and its popularity is increasing,
Salt seems to have the least take up.
However it more important How you use these tools rather than which one you use.
‘test-kitchen’ is the key and it supports chef, puppet, ansible, and salt (disclosure i wrote the plugins for puppet and ansible). test-kitchen allows you to orchestrate your dev environents, run your scripts via push as well as run verification via serverspec tests. This allow much faster development of scripts. A couple of other thinks i do:
Split config into library and application components. library components are open source and released to the puppet forge, chef commuity or ansible galaxy. berkshelf, librarian-puppet, librarian-ansible used to bring them in at test time (test-kitchen does this automatically) so you don’t store them in your repository. (You should lock the version of library components).
Application components call the library components and are named with a company prefix. Application components DO NOT call other application components. Components that are shared should be made into library components. This makes dependencies much easier as you only need to look at dependencies when you change versions of library components.
In summary: “It ain’t that important which tool you choose rather it is important how you use them”