Hacker News Reader

Hacker News

Comment by susi22 | Hacker News Reader

Parent Full thread

susi22

IMO, ansible is even better:

https://github.com/ansible/ansible/

It doesn't require any deamon and does all its work over the good old unix fashion way: SSH. And it's python too.

View on HN

From the article:

"Chef works atop ssh, which – while the gold standard for cryptographically secure systems management – is computationally expensive to the point where most master servers fall over under the weight of 700-1500 clients. Salt’s approach was far simpler."

Does that assertion about Chef somehow don't apply to Ansible?

On the use case:

"I have this command I want to run across 1,000 servers. I want the command to run on all of those systems within a five second window. It failed on three of them, and I need to know which three."

Well, ansible by default runs with paramiko which is a python implementation of SSH protocol. It will also keep connections open for multiple commands. It also has a pull mode and it also has a fireball mode which uses 0mq:

http://jpmens.net/2012/10/01/dramatically-speeding-up-ansibl...

However, you're not forced to use this. In the beginning, you can just seed your CentOS or debian with a Kickstarter or seed file and then run your inital thing with ansible simply over ssh (using all the goodies, ssh-agent, password less ssh etc..).

One huge plus for ansible is also that it used yaml which is rather simple. I've been following both project for >1 year and it seems that recently ansible has picked up a lot and will probably make the "race" (IMO).

Salt also uses yaml for its configuration backend (by default). You can also write your state in Python if you prefer, with all the power that that brings (including pulling data from databases, remote API calls, or whatever you like).

I'm going to go on a limb here and say that the 700-1500 clients limitation is a non-problem for the vast majority. It's like the C10K "problem" all over again. Newsflash: most shops don't have more than a few dozen servers, if that, and the few ones that do must have already done their homework.

Two solutions: pull-mode playbooks [1] and fireball mode [2] (temporary ØMQ daemon).

[1] http://www.ansibleworks.com/docs/playbooks2.html#pull-mode-p...

[2] http://www.ansibleworks.com/docs/playbooks2.html#fireball-mo...

Ansible can use SSH or ZeroMQ, which is much faster.

And now I'll say if you like Perl then there's a simple CFEngine-lite-like project I started called Slaughter:

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

Policies (read "perl scripts" + "file templates") are fetched from a central location, which could be a git repository, a SSH server, an rsync export, or similar. Then they're compiled and executed locally.

Surprisingly powerful, plus you get the power of Perl + CPAN.

While I would prefer ansible as well, the author does show why ansible is problematic for some people:

> Chef works atop ssh, which – while the gold standard for cryptographically secure systems management – is computationally expensive to the point where most master servers fall over under the weight of 700-1500 clients

That said, unless you must have 700+ simultaneous slave connections, you should probably make life easier on yourself and choose ansible.

I think that "limit" is just FUD - can anyone explain where it comes from? With persistent SSH connections, the overhead of SSH encryption should be comparable to other encryption methods.

It could be that SSH isn't as good as, say, HTTP servers, when it comes to handling a lot of connections. However I'd also like to see data on this.

The overhead of spawning hundreds of SSH processes can be pretty extreme as well.

By default it won't spawn SSH processes but use paramiko instead (python module that implements SSH).

Ssh is good, I think it is scp'ing that kills the master?

FWIW, Chef doesn;t work atop ssh. It and puppet both use HTTP.

Browsing around ansible's website, I found the "quickstart" link. From that page[0]:

> We’ve recorded a free 2-hour presentation designed to ...

Wait. The quickstart presentation is 2 hours?!

Looking for an easier way to get started...

[0]: http://www.ansibleworks.com/quickstart/

Maybe this? http://ansibleworks.com/docs/gettingstarted.html

>It doesn't require any deamon and does all its work over the good old unix fashion way: SSH. And it's python too

Salt is all of these things as well.

And if you don't like Python, you usually don't have to touch it. The tasks you run on the server can be any kind of executable. They read some JSON from stdin, do their action and write some JSON to stdout. Whether that program is a Python/Perl/Ruby/LUA script or go binary doesn't matter.

I came from building a large puppet environment to loving ansible. I much prefer push method in daily operations.

After reading Ender's Game over the weekend, I want to use this.

I started with cdist, but ansible won me over. I bootstrap ansible-pull using cloudinit. It's been an excellent experience so far.

Agreed! The ability to both push and pull is beautiful. Push for most things, pull for deploys via git.

Reply on news.ycombinator.com