Archive for August, 2016

Well hello again. I realized this morning that it’s been over six months since I’ve posted anything, nd I’ve got a few things I might want to post about, so I thought I’d check in with everyone. Life has been rather busy of late – I moved to a new house (detached house with about 0.65 acres), and I’m in the middle of sprucing up the townhome to put it on the market. That means, among other things, that I’ve had to redo my home network, and I’ve got a few things to say about that. That will probably be a new post all it’s own.

This time, I want to focus on something I’ve been doing for work. Among my many other responsibilities as a systems administrator, I’ve dealt with quite a number of configuration management schemes. Most of them little more than “if it breaks, make sure the configuration is current, otherwise leave it alone”. Which is to say, no configuration management at all. I’ve used CFEngine – way back in the past – and adapted Nagios to check on configuration items (a very ugly kludge – please don’t ever do that). Recently, I’ve started playing with Ansible, since that’s the tool that my current boss wants me to use.

Ansible is, in a word, lacking. Why do I say that? Several reasons. First – it’s a bigger and more involved version of the Expect SSH script I wrote (adapted from someone I knew at NCSU at the time, who later went on to Red Hat and then elsewhere) over a decade ago. It doesn’t really do much that my decade old script isn’t capable of, so there’s no major benefit to it. It requires a huge amount of setup prior to actually using it, to get authentication (SSH public keys) and escalation (sudo privileges) right, and it can’t handle slow connections or VPN tunnels very well.

The major downfalls of Ansible are in it’s language and it’s operation – the playbook language is rather difficult to wrap your head around. It’s neither simple nor intuitive, and bears little to no resemblance to any already-existing programming or scripting languages. The problem with it’s operation is that it’s a one-shot deal – you have to actively manage errors or connection issues as opposed to having a tool that retries connections or deploys automatically. If I start a deploy to 100+ systems and I get any errors at all, then I get called to a meeting about something else entirely, I can guarantee you that I won’t remember to go back and fix those errors for a day or more, and that is a rather bad thing. A good configuration management system needs to take a config update, and keep attempting to apply it until successful or until it gets an error that requires admin intervention (e.g. a package conflict, as opposed to a connection timeout which it should be able to handle on it’s own). It’s especially difficult if, as with Ansible, the result status is simply logged to the screen as opposed to a file.

Perhaps some of the issues I have with Ansible are because I haven’t gotten into it deeply enough – but if I’m perfectly honest, I shouldn’t have to get into it any more deeply than I have to know how to solve these issues. This is the final issue I have with Ansible – the documentation is, bluntly, atrocious. I could find almost no examples of how to write a playbook. The example playbooks I did find were from a git archive, where the commit messages told me what had been done most recently, but offered no clue as to what a given playbook file was supposed to do.

Overall, I have to say, Ansible is over-hyped and under-performant. It comes across as an attempt by a programmer of mediocre skills to semi-automate systems administration tasks that said programmer shouldn’t be exposed to or aware of in the first place. For me, Ansible doesn’t give me enough ease of use or automation to make it worth the trouble it took to set it up in the first place.