What is Rundeck?

That’s actually a fairly common initial question, even from folks who have heard the Rundeck name.  It can be hard to answer concisely since the product does a lot of different things.

At heart, Rundeck is a centralized console for managing the automation in your environment.  It allows you to control who can do what and to leverage your existing scripts.  Though most users interact with Rundeck through a web interface, you can also connect with an API or command line interface, all of which have the same available feature set.

Why should you use Rundeck?

Like the first question, the answer to this one is probably “it depends.”  Your reasons for applying this solution are dependent on the nature of the problems you are trying to solve.

If we address this question at a high level, the reason to use Rundeck usually breaks down to one of the following:

1. Centralize your scheduled work
   • If you have any jobs scheduled on your servers to run through cron, you can probably understand this.  Use a central interface to control when and where jobs will run.
2. Provide your team with consistent jobs and scripts for use in all kinds of tasks
   • Use whatever scripting languages and tools you already have, from one central interface
3. Push job execution closer to your users
   • Once you have finalized your script, you can provide limited access to users (by group) to run specific jobs

What are the core objects you’ll use in Rundeck?

Jobs

Jobs are a defined set of actions and can be triggered by the built-in scheduler or triggered on-demand by users or other tools. Job steps can execute scripts, commands, plugins, or other jobs.

Nodes

Nodes are the objects upon which your jobs will execute.  Nodes can be defined through either static or dynamic method, representing any remote physical (servers, network devices, etc.) or logical (VM, service accounts, containers, etc.) endpoint.  Nodes can be organized using tags or other customizable attributes.

Projects

Projects are a way to organize your jobs. Each project can have different sets of nodes and one or more user access policies.

Projects are often used to logically separate jobs and users to allow different teams to have different processes, procedures and policies.

How does Rundeck connect to target nodes?

Rundeck’s server will connect to a node whenever needed for a job or ad hoc command.  The connection is established using a standard protocol, typically SSH or WinRM.

For the connection to be successful, Rundeck needs to know three things about each node:

1. A username to connect as
2. An IP or FQDN to connect to
3. A key or password for authentication
   • This is usually defined for all or some nodes at the project level

How does a job run?

Each job is defined as either a “node” job or a “local” job

• Node jobs have a filtered set of nodes that will be targeted with each execution.  The set is based on tags so it is evaluated each time the job runs.
• Local jobs are executed locally on the Rundeck server

Each job is composed of one or more job steps, each of which is a “node step” or a “workflow step.”

• Node steps run once for each targeted node
• Workflow steps run once in the workflow and are effectively local steps, even for a node job