Why would we want to automate Rundeck ? What exactly do we want to automate ? I’ll present my use case, let me know if it applies for you as well:
- We manage a bit less than a hundred different applications. We manage deployment and some administrative tasks with Rundeck. Those tasks are similar between applications. We don’t want to configure 80 different rundeck jobs for each task, instead we want a generic definition of those jobs and instanciate it for each application, taking care of the specificities if needed.
- Everything deployed on production environment should be tested somewhere else, validate, tested, … To ensure that what you deploy on production is the same as what you tested on test environment, you need a way to version your jobs and have a promotion workflow from test to production.
- With multiple projects, if the jobs for each application are managed separately, they will start to diverge. We need to ensure that the procedures implemented as rundeck jobs are coherent and that common code is properly factorized.
What I want, is to manage my Rundeck configuration in the same way I manage my applications and my Puppet modules. With the same build, release, versioning and promotion mechanism. For that, I need simple Puppet resources that will allow me to create projects and jobs. Then, I will be able to control them from a mix of role classes and hiera.
What is missing?
Creating projects is done with the command line
rd-project tool. Configuring the project is done through the Web interface, or by editing the
project.properties file. Project definitions are reloaded mostly automagically, so everything is fine here. I have a basic implementation of a Puppet resource to manage Rundeck project on GitHub.
Managing jobs is a bit harder. You can create jobs through the
rd-jobs, but you don’t get direct access to the job definition once it is created. You can reload a job with the same name and it will override the job definition. This makes it harder to manage correctly modifications to jobs, or job removal. I have a buggy half working implementation of jobs, also on GitHub.
What I want in the future?
I’ll keep working on my Puppet module to better handle the quirks of Rundeck. It already works for the basic use cases, but need some love to manage more complex workflows.
Modification to Rundeck itself could make the job much easier, for example by storing all project and job definition directly in files. While the Rundeck code base is of reasonable size and quite readable, I probably won’t have time to dig into it right now. Any help is welcomed on that side …