-
Notifications
You must be signed in to change notification settings - Fork 0
RunDeck is cross-platform open source software that helps you automate ad-hoc and routine procedures in data center or cloud environments. RunDeck allows you to run tasks on any number of nodes from a web-based or command-line interface. RunDeck also includes other features that make it easy to scale up your scripting efforts including: access control, workflow building, scheduling, logging, and integration with external sources for node and option data.
Rundeck software is free and completely open source. It's licensed under the terms of the Apache 2.0. There are no hidden "gotchas" or some other "enterprise" version that you must pay for, all of Rundeck is free open source software. Download it. Try it. Use it. If you find value in it and would like to actively participate in the project, introduce yourself on the mailing list or the IRC channel.
Bugs are tracked on Github Issues.
Post messages to google groups: http://groups.google.com/group/rundeck-discuss
At irc.freenode.net #rundeck
You can see the irc logs here: http://irclog.rundeck.org
Download a development build from our jenkins-ci instance here: http://build.rundeck.org
There is some overlap between rundeck and Puppet's mcollective and Chef's knife. The three allow administrators to execute commands in a distributed environment, offering a form of real time control. Each provides a mechanism to use metadata-level searches for targeting remote nodes. The three also provide levels of authorization, authentication and auditing.
Rundeck has a few goals of its own though:
- Firstly, we want to create an easy way to define routine sequences as "Job workflows" as a basis for runbook automation solutions.
- Secondly, enable the integration of node and environment metadata sources as RunDeck "resource model providers". In this way, Rundeck can use Puppet or Chef node data to drive remote execution.
- Thirdly, evolve role-based access control definitions into a high level DSL that ties privilege level to resource model and workflow actions
- Lastly, to develop Rundeck into a plugin system supporting the concept of "dispatch providers" to delegate to tools like mcollective, knife, func, fabric, PsExec and others for cross tool execution.
Ultimately, we want to create a tool that is simple to use for the end user of the automated process yet be flexible enough to complement existing tool chains.
Rundeck is not a continuous integration server. At a high level, Rundeck shares some features with Jenkins since both are able to provide a self serve job interface to automate routine procedures. Rundeck and Jenkins are also able to execute shell scripts on remote nodes to facilitate deployment tasks. Rundeck's built-in support for pluggable remote command execution is a key differentiator.
It really comes down to use case. Rundeck is meant as job console for the operations group and is geared to work with that ecosystem of tools.
The jenkins-rundeck plugin really demonstrates how complimentary the two tools actually are in a continuous deployment tool chain. Jenkins handling the build end of the CI loop and triggering Rundeck to provide distributed orchestration across the deployment management tool chain.
We're designing RunDeck to work on unix flavors and windows. This assumes the commands you execute can run on the targeted host.
Currently, we test on Linux (Redhat, Centos, Ubuntu), Solaris x86, MacOSX. It should work on BSD. We have have recently begun testing on Windows.
Yes, RunDeck server can be configured to use SSL. Consult the Security section in the manual. http://rundeck.org/docs/RunDeck-Guide.html#configuring-rundeck-for-ssl
Yes, Rundeck can be configured to authenticate to an LDAP directory service. See http://rundeck.org/docs/RunDeck-Guide.html#managing-logins.
The list is kept here: https://github.com/dtolabs/rundeck/wiki/Resource-model-providers
You can use multiple JAAS loginmodule configurations within a single named JAAS configuration. See Multiple Authentication Modules
You can add configuration to the Rundeck-config.properties file, using the config settings shown under the Grails Mail Plugin "Configuration" section.
Since the default rundeck config file is Java ".properties" format, you will either have to flatten the config hierarchy shown in that document .e.g "grails.mail.host=hostname", or convert your Rundeck config file to Groovy format, and specify the right config file location at Rundeck startup.
To convert to groovy format, make sure you put quotes around all string values, but it is not necessary for true/false or numbers.
#java properties format
some.property=value
//groovy format:
some.property="value"
To specify a new config file location:
For the launcher, place the file in the $BASEDIR/server/config dir, and specify -Drundeck.config.name=rundeck-config.groovy when you run the launcher.
For the rpm/deb, specify a -Drundeck.config.location=/path/to/rundeck-config.groovy in the /etc/rundeck/profile JVM arguments. Or if you are using just the war file, put that in the $CATALINA_OPTS if you are deploying the war to Tomcat for example.