Hacker News Reader

Comment by chousuke | Hacker News Reader

I've used clusterssh in the past, but nowadays Ansible is simply a better choice. clusterssh is rather brittle.

I don't much like Ansible either (I have opinions about using YAML as a programming language), but for ad-hoc maintenance of a bunch of servers, it works okay.

View on HN

I am also a "reluctant" Ansible user, and I suspect I share some (perhaps many) of your opinions on YAML, but it is a fairly functional tool set for most administrative situations. There are a few situations where I can't use ansible and have to fall back on pure ssh for one reason or another, and this looks like it might be a useful tool.

Better than writing a bash script with a for loop and nested ssh commands at least.

I think similar. YAML is a pain to keep the right indentation. I wish they introduce another format while keeping YAML as legacy format.

It is reluctant to write a config when just sending a file to multiple servers.

I was going to say the same: I've used clusterssh and similar in the past, but these day I am using Ansible for doing those tasks. Primarily, the task I used it for was doing OS updates across the fleet.

Now I do "ansible-playbook dist-upgrade.yml --tags prod" and it takes care of:

- Running on a subset of hosts at a time. - Pinning my own application packages so only the OS packages are updated. - Removing from the load balancer. - Doing the updates. - Adding back into the load balancer. - Waiting for the server to go healthy in the LB. - Unpinning the application packages.

I'll say: I use Ansible a lot, so I've become more comfortable with the "using YAML as a programming language", but I don't disagree with you there. It works, and you can become comfortable with it, and it isn't as bad a fit for configuration management as the base statement would make it seem, but there are things that it's a bad fit for. In particular, the looping, especially with notifications.

Ansible can't do interactive sessions, though, right?

You can with the expect module, although I admit it's no fun.

I think there's a valid argument to be made that anything you would use an interactive session for on multiple servers at once is better done as an interactive session on one server, formalized into some rules of what to do (even if just a bash script with a bunch of grep and sed commands), tested on another server, and that should then be run on lots of servers at once (or better yet, batched into groups of a reasonable amount to check nothing went wonky).

In the words of the venerable DevOps Borat[1], "To make error is human. To propagate error to all server in automatic way is #devops."

1: https://twitter.com/devops_borat/status/41587168870797312

Reply on news.ycombinator.com