Hacker News Reader

Comment by ciupicri | Hacker News Reader

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].

[1] http://ansible.cc/

[2] http://ansible.cc/docs/gettingstarted.html#requirements

View on HN

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.

There is also Fabric [1] to allow management of remote servers using Python scripts.

[1] http://docs.fabfile.org/en/1.5/

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.

Also cuisine[0], a more fully featured configuration management tools built on top of Fabric's lower level functions.

[0]: https://github.com/sebastien/cuisine

And my own tool, this time in Perl, which is thoroughly documented here:

http://www.steve.org.uk/Software/slaughter/guide/

There's also cdist which is python and shell-script based - does not even need python on the target machine, only ssh and a posix shell.

check it out: http://www.nico.schottelius.org/software/cdist/

disclaimer: I work with the author, but not actually on the cdist codebase (not enough to brag about, anyway)

Can someone who has used both chime in? I've used ansible a bit and like it, but I've never heard of Salt before.

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.

Salt does have support for Mercurial through the hg state: http://docs.saltstack.org/en/latest/ref/states/all/salt.stat...

It's also pretty easy to extend and the team who maintain Salt are really friendly and accepting of patches/pull requests.

Ansible is moving at a pretty good clip too.

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.

Sure, you can see some of my comments here.

http://news.ycombinator.com/item?id=5244740

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.

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.

To speed up ssh login time, try adding the following to your ~/.ssh/config:

  Host *
    ControlMaster auto
    ControlPath ~/.ssh/auth/%r@%h:%p
    ControlPersist yes

For me this changes connection times from 1.7 seconds to 0.189 seconds when connecting to a host over the internet.

What does this do?

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.

Interesting tip. Thanks!

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`

I like its syntax too, its simple to understand and model[1].

[1]https://github.com/ansible/ansible/tree/devel/examples/playb...

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.

And it can also use zeromq ;)

Reply on news.ycombinator.com