There is also Ansible [1] which is written in Python and connects to servers using SSH (combined with sudo if needed). This means you don't need to install anything on the servers you're managing, since most distributions have Python >= 2.4 included. For more details see the requirements page [2].
I love Ansible. After having used puppet and chef at the company I work for, everyone was thrilled about how easy and boiler-plate free Ansible is.
Chef is great for bigger architectures, but if your goal is to provision a limited set of servers and document it's configuration in a readable format, Ansible is truly fantastic.
Thanks! BTW, I'm not sure limited applies. There are several setups with thousands of nodes and users doing some pretty complex multi-tier orchestration magic (N-tier, load balancers, monitoring outage windows, Jenkins, all integrated, etc). And you've got ansible-pull for mega-large scale if you want.
The thread starter meant, AFAICT, that Ansible scales down nicely. If you have 3-4 boxes, maybe 0MQ is overkill, and even running a a Chef client constantly is overkill.
Exactly. Having to install chef and all it's dependencies to install nginx and a few config files in the end feels really wasteful. With ansible, there are zero server-side dependencies.
Fabric is a deployment tool, which makes it useful in many cases where something like Salt would be overkill, but is definitely not in the same category.
We're using salt and while it's incredible buggy still it's the most impressive system we've used so far. It's faster than anything else because it does not go through the process of signing in through ssh and creating a unix session.
That might sound like a boring detail but it opens up many possibilities by doing things like asking all machines for their system time and then doing something with it.
Note that you might need to create the auth subfolder using `mkdir ~/.ssh/auth`, otherwise it might throw an error on connection: `muxserver_listen bind(): No such file or directory`
Maintains a persistent ssh connection to each host once the first is created. Any subsequent ssh commands will be sent over the existing channel, skipping the time-consuming handshake process.
I'm hoping for this too. Especially somebody who has used both exhaustively. At first glance the architecture of both seems to be pretty sensible, clean, minimal and good in all the ways that puppet isn't. I half heartedly picked salt based upon the following:
* More commits in github.
* More pull requests in github.
* Main website is ranked higher by alexa.
However, after using salt for a short while, I ran into a couple of problems (no mercurial state, no ability to specify versions when using a pip state), which ansible seemed to be able to handle.
So, I don't know... salt seems to be more popular. A bit. That's all I can tell.
We do strongly encourage squash commits so I wouldn't go by counts alone, but pick what tool you like to use most and that best fits your needs, and your style, and what you want to do with it.
Well, that's the problem...both look good to me. Similar style, technologies and philosophy behind both.
I'd really appreciate a deeper comparison, though - especially if you feel that there are certain areas/circumstances where ansible may shine over salt.
Main thing on Ansible is the focus on multi-tier and process orchestration, without having to rely on coding up event paths between nodes -- admittedly it's a niche problem, but to me, deployment is as important as config management, and often harder. That being said you can write deployment in anything if you try hard enough, but I built what fit my brain and the particular needs of a few past companies deploying multi-tier web apps. While it is easy to have ad-hoc in the product (Puppet also does this with mCollective), it's a bit harder to be able to both model deployment and declarative state, and then make that into content you can hand over to a security auditor who doesn't know the language and he can say, yep, that's exactly what we want.
Ansible has various connection modes between the client and the server. SSH is the default, but the stock release also including a "fireball" transport that uses a ZeroMQ daemon to dispatch incoming command requests.
What's misleading in these requirements is that the "Python 2.6+" spec implies support for Python 3, which the Ansible authors have actually said they won't support for ideological reasons. It would be more accurate to write "2.6/2.7".
Not ideological reasons but more so pragmatism. But sure 2.X series.
And 2.4+ nodes can be managed.
Once Python 3 is the thing everywhere I'm sure we'll have compliance. Ditto with, say, OpenStack which is also holding off. You kind of treat them as two different languages to a degree, if you still want to support things like RHEL 5 (2.4), you have to.
[1] http://ansible.cc/
[2] http://ansible.cc/docs/gettingstarted.html#requirements