4 ms·
I'm not the OP, but: These systems are broadly the same. If you're writing your configuration from scratch, they're all fairly pleasant, and it's mostly a matt
by spoondan 13y ago
I'm not the OP, but:
These systems are broadly the same. If you're writing your configuration from scratch, they're all fairly pleasant, and it's mostly a matter of preference. They share most of the same concepts (although the terminology differs) and features. In my experience, their differences are primarily in feel and community.
For feel: Chef gives you Ruby pretending to be declarative. Puppet and Ansible give you something more declarative at the expense of some expressivity. Puppet has its own syntax, and Ansible shoe-horns some procedural aspects into YAML syntax. I prefer Chef here. (Chef also provides a web UI that lets you edit things, but I strongly advise against using it except for managing nodes. Everything else should be code/JSON.)
For community: With configuration management, one of the things you'll want is good community involvement. You don't want to write every cookbook/playbook/module from scratch. From what I've seen, Chef and Puppet have a large head start in this department.
That said, you should be prepared to customize the community offerings. People generally implement precisely what they need, in precisely the way they need it, and your needs will not always align. Fork all of the community offerings so you can modify them while still pulling from upstream. Managing this is decidedly difficult, but there's no better choice. It's one of the areas where git submodules would be really great, if only they were nicer to use. If you're going to use Chef, consider also using Berkshelf for managing your cookbooks.
If you do not have configuration management in place, pick one of the major ones, learn the hell out of it, and get to automating your operations. Having your infrastructure as code that you can run whenever you want, that you can review to see exactly how something is configured, is life changing. Once you get to doing it, you will never want to go back to the bad old days.
- jacques_chester 13y agoChef and Puppet are quite different, in my opinion. Based on my exposure, Chef ultimately boils down to being a complex remote execution framework. Puppet makes detect-and-correct more central to its model. http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reigning-in-chaos/ http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reign...
- Terretta 13y agoInteresting comparison, but shoukd be mentioned that Dell, AWS, and others, are leveraging knowledge around Chef.
- jacques_chester 13y agoAnd Citrix, Rackspace and Oracle are using Puppet ("leveraging knowledge"? pls no). Appeals to authority don't tell us anything about the technology except that somebody we've heard of is using it.
- Terretta 13y agoDell and Amazon leveraged chef to help build Crowbar and Opsworks respectively. Crowbar ... leveraging ... get it? In any case, noting Opsworks is based on Chef is not an "appeal to authority".[1] That knowing Chef means you have a head start on AWS's official devops tooling, seems a relevant data point for a comparison. (The officially supported devops tooling leveraging a particular CM system is different from simply being able to be managed by a CM system.) As for Rackspace, here's the CM category of their dev blog: http://developer.rackspace.com/blog/categories/configuration-management/ And here's "How Rackspace Uses Chef to Deploy OpenStack in the Private Cloud": http://developer.rackspace.com/blog/cooking-with-chef4.html Quoting a different Rackspace article from Feb 2013: The Rackspace Private Cloud Certification team sought out and tested a number of bare metal provisioning tools. While there are a number of excellent tools on the market, none seemed to fit quite well. On one hand, some tools were all-encompassing in scope and would try to provide an end-to-end solution. On the other hand, tools were too narrow in scope and provided a solution for a specific operating system or did not provide an appropriate amount of flexibility. Eventually, we picked a deployment model consisting of a combination of tools that would provide the right balance of features and flexibility. We chose the Razor provisioning engine, combined with the OpsCode Chef configuration management tool. 1. http://plover.net/~bonds/bdksucks.html http://plover.net/~bonds/bdksucks.html