I’ve been looking around lately for something that can handle command-and-control automation across an estate of Linux servers. My requirements are to be able to run jobs and tasks remotely, either ad-hoc or at specified times and capture the results in a meaningful and useful way. I’ve come across some of the “Enterprise” solutions touted by a few proprietary vendors (cough, Control M, cough) and not found anything that really impresses me, or should I say, doesn’t scare me… until now, that is.
My own requirements are fairly specific, I want a GUI and a CLI, I want to be able to run it without client agents, remote execution with SSH is a big bonus and a flat-file configuration structure will make integrating it into other systems fairly painless.
An open source effort to address these requirements has recently been unveiled by DTO Solutions named RunDeck. At first glance it looked like a good fit for my purposes. I decided to give it a test-run after looking at the overall architecture design. Heres a breakdown of my experiences so far with it.
Installation couldn’t be easier. For test purposes I opted to simply download the self contained .jar file and launch it with java -jar launcher.jar and had a working default system in no time. DTO also provide an RPM for use with yum and the source is available in github.
RunDeck uses the concept of a Resource Model to define a collection of hosts, or nodes, on your network. Minimally, you can add a resource model by defining a list of hosts in a simple XML document. Each node within your resource model can be assigned different custom tags and basic OS information (system type, OS, kernel version…etc). Your nodes should be configured with passwordless ssh keys to allow the RunDeck user to execute your commands. RunDeck also supports external sources for your resource model meaning you can import nodes automatically from other systems such as Chef or Puppet. In fact, James Turnbull recently wrote puppet-rundeck, for integrating RunDeck with Puppet, read more in his blog post
RunDeck has an HTML GUI that is clean, uncomplicated and easy to navigate. The three main sections are broken down in to History, Jobs and Run and it doesn’t take long to get comfortable moving around. A huge plus for me is that it seems everything I can do in the GUI can also be done from the command line, extra brownie points for that!
RunDeck in action
Configuring jobs in RunDeck is clear and self explanatory, however the options and abilities are surprisingly versatile. Your job can be made up of any of the following;
- References to other saved jobs
- Server-side scripts to be run on the remote node
- Inline scripts saved within your job
The latter two are particularly useful for me, it means I can import a variety of legacy scripts that I have no hope of getting rid of in the near future, but at least I can wrap some decent execution framework around them.
Once you’ve defined your job you can assign it to a group of hosts based on a very flexible filter that supports regex’s against most properties defined in your resource model (host name, OS, custom tags…etc).
Your job can either be saved to run manually or scheduled to run automatically, and even supports crontab formatted scheduling data.
It’s worth mentioning that if the above sounds a bit much to go through when all you want to do is loop through a list of servers and execute a one off command, then you can use RunDeck’s Ad-Hoc feature. Under the Run section you are presenting with a list of hosts that can be filtered with multiple criteria, and at the top a text box to issue commands. So simple, but so very useful.
I won’t list every feature in depth, as this has been very adequately documented already. The above is my first impressions of RunDeck from spending less than a day test running it. I’m left feeling that this software is slick, well documented, reliable (a few minor bugs, but overall impressive for a 1.0 release) and does what it says on the tin. It’s defiantly placed high in my sysadmin toolstack arsenal.