The thing with one liners is that it is cool when they work, hell when they don't. I'm looking at replacing Puppet (because it's orders of magnitude too slow). Chef was a viable candidate, up until I tried installing it on two pristine installs (Scientific Linux 6 and, when it failed, Ubuntu Server). The instructions seem simple enough:
Chef goes into a frenzy of bootstrapping itself , installing a huge stack of dependencies, takes ages, only to fail with an obscure message in the end about one of its dependencies failing to start (RabbitMQ, if I recall correctly).
Can I work around the failure? Sure! But what does it tell you about a piece of software that its installer fails on two pristine different and common linux distributions? To me, it tells me that it is over-complex and poorly engineered. So, from a different perspective, I really identify with the "gazillion smaller dependencies" comment.
I helps me little that chef-solo is simple. I don't want chef-solo. I want a full config management distributed solution that is dependable (which probably requires lean).
My next candidate is Salt, and so far it looks good.
Be aware that Salt, for reasons passing understanding, implemented their own encrypted channel (instead of TLS) as an alternative to using SSH, and suffered a grievous vulnerability as a result. I'm not saying don't use Salt (I don't know much about it), but I would recommend using SSH with it, and not its custom transport.
I had a look at how Ansible does 0mq encryption the other day, they do key exchange over SSH and then use keyczar to encrypt data over the socket, so that doesn't look too bad. I didn't look at the key exchange or review things in depth, but, assuming keyczar.Encrypt() does the right thing, it shouldn't be too bad.
Does Salt offer all the benefits of Chef server? To my knowledge, the former has no search engine nor any way to return feedback from the managed hosts. Shared storage is absolutely essential for building things like ssh_known_hosts files and Nagios configurations.
Ansible can trade data between machines using 'hostvars' as a variable, so you don't even need the analog of Puppet storeconfigs to assemble facts. (Sorry, don't now the Chef term).
Stop by the list if you'd like more info, but it's easy to generate nagios configs from templates this way.
Who stores hostvars? Does Ansible provide a way to extract a subset of them based on other hostvars? (e.g. "give me all the ssh host keys of my hosts in the intersection of datacenter X and hostgroup Y")
Ansible doesn't store them, but exchanges them in memory. (The assumption is you'd want them to be current anyway). We are going to add some optional caching (likely just requiring sqlite as it's all we need) in a future release.
But yes, it's easy to do that. Assuming you meant a template, you could do:
{% for host in groups["datacenterX"] %}
{% if host in groups["Y"] %}
{{ ssh_host_key_rsa_public }}
{% end if %}
{% endif %}
Ansible is also good at carving up groups based on these things, like if you just wanted to talk to those hosts:
I haven't had trouble with installing Chef 11 server on Ubuntu.
As for installing a huge stack of dependencies: if we're talking about Chef 11, there's nothing to install. All of it is embedded into the omnibus package. It is configuring them.
It's too bad about the RabbitMQ. Have you submitted a ticket?
I'm curious - for what do you use SL? I had tried it at v4 and it did not seem superior to a 'standard' Fedora install at that time, even for scientific analyses (ROOT and GEANT were no different to install IIRC and there wasn't the same healthy package system that comes with Fedora). Has it improved in some way since then?
It's an historic left-over. My company uses CentOS, and back in the days of the transition to v6, CentOS was delayed. SL6 came out at the right time and we switched.
SL is basically the same as CentOS: a community version of RHEL.
http://docs.opscode.com/install_server.html
but when you run:
Chef goes into a frenzy of bootstrapping itself , installing a huge stack of dependencies, takes ages, only to fail with an obscure message in the end about one of its dependencies failing to start (RabbitMQ, if I recall correctly).Can I work around the failure? Sure! But what does it tell you about a piece of software that its installer fails on two pristine different and common linux distributions? To me, it tells me that it is over-complex and poorly engineered. So, from a different perspective, I really identify with the "gazillion smaller dependencies" comment.
I helps me little that chef-solo is simple. I don't want chef-solo. I want a full config management distributed solution that is dependable (which probably requires lean).
My next candidate is Salt, and so far it looks good.