I am currently migrating a largish (thousands of nodes) site away from using Chef and back to using config files in packages, because it's simpler and has the same effect.
Having been round the houses with cfengine, Chef, Puppet and more now I think these tools are, overall, a poor use of time. In general they're 99% used as config blasters: Yet Another Way To Put Files Onto A Computer.
Turns out, packaging systems already did that and have better dependency analysis.
This also helps to match the lifecycle of configuration management objects with that of the components they configure. I've seen far too many sites that had one big hairball of a Chef/Puppet repository that tried to service the needs of multiple conflicting application releases.
The final nail in the Chef coffin is that it encourages parameterisation of config files rather than configuration by convention, which is simpler and less prone to production-environment gotchas.
Everything else they do can be replaced by a very small shell script.
We have some Debian and some CentOS nodes, and yes it's an apt & yum repository. The repo itself is subdivided, debian-style, into "unstable", "testing" and "stable" which matches the states of components in our continuous delivery pipeline.
So we do per-commit integration testing with "unstable", promote into acceptance & functional & regression testing (and showcases etc) with "testing" and then promote into "stable" for production. The actual promotion is done with some very small shell scripts off a CI server; the installation is managed via rundeck.
The configuration packages are per-node role dependencies and we try to keep granularity large - e.g. there's a configuration package for a core Java webapp that includes the application's own resources & nginx & jetty configuration bits.
For per-environment stuff (like database passwords and external integration endpoints) we just inject a (quite small) yml file to each server for the config packages to find. But configuration by convention is preferred so we also manage the DNS carefully by role (again, from rundeck) so that services are at well-known unqualified label names.
Finally, the per-environment spec itself (i.e. that the rundeck scripts look at) is in a cheesy cvs tree. I keep meaning to move that to git.
The base images themselves are stock virtual machine templates (AMIs for EC2 testing/dev) and the config packages & rundeck take it from there. The first step is to install a basic platform package that has lots of dependencies for our common tools, libs and needs, the the role-specific config package does the rest.
I prefer to use whatever's native to the platform. On Debian that means start-stop-daemon; on CentOS the init.d functions.
It's a whole "my house, my rules" strategy. If you play nice with the underlying platform, it'll play nice with you. The downside is that you do have two packaging models to build for. I know that abstracting this is one of the motivations for Chef et al. I have yet to see a usage where this was worth the opportunity cost.
> Turns out, packaging systems already did that and have better dependency analysis.
The one thing that keeps me from wanting to switch entirely to apt for deployment is its insane insistence that multiple versions of the same package may not be installed at once. This is (usually) fine for user-level stuff, but there are lots of legitimate reasons to want to keep multiple versions installed in a deployment situation.
Having been round the houses with cfengine, Chef, Puppet and more now I think these tools are, overall, a poor use of time. In general they're 99% used as config blasters: Yet Another Way To Put Files Onto A Computer.
Turns out, packaging systems already did that and have better dependency analysis.
This also helps to match the lifecycle of configuration management objects with that of the components they configure. I've seen far too many sites that had one big hairball of a Chef/Puppet repository that tried to service the needs of multiple conflicting application releases.
The final nail in the Chef coffin is that it encourages parameterisation of config files rather than configuration by convention, which is simpler and less prone to production-environment gotchas.
Everything else they do can be replaced by a very small shell script.