Home

This Rundeck WorkflowNodeStep plugin example demonstrates how to use the CODE displayType rendering option to execute a batch of commands (in this case to a Cisco device).

Note: this is not a tutorial about managing Cisco devices via Rundeck but rather how to write a NodeStep plugin to automate a process to some Node but not via a node-executor.

The WorkflowNodeStep plugin.

A WorkflowNodeStep plugin is useful when you want to execute some automated process to a Node but you want to control how you interact with it. In the case of a Cisco device, you can execute device specific actions (eg, IOS commands) using your own mechanism to talk to the device. In this example, a simple script wraps how to talk to the Cisco device using its own SSH implementation and reads IOS commands via a plugin input. The example also shows how to use a boolean configuration property to allow a dry run mode to preview how the commands would execute but does not actually do so.

Here is an example execution of the plugin in a "dry run" mode:

In the screenshot, a user supplied input to two options to the job. The output shows the preview of the commands that would be executed.

The plugin uses the CODE displayType to present a multi-line code editor so the job writer can declare multiple lines of IOS commands.

conf t
vlan ${option.vlan_id}
name ${option.vlan_name}
end

The screenshot below shows the code editor and some example IOS commands. Note how you can embed Rundeck context variables. In this case option variables are referenced but you can reference node and job variables, too.

Here is a YAML fragment from the plugin.yaml file to turn on this so called rendering option:

    - name: ios_script
      title: IOS Commands
      type: String
      required: true
      description: the IOS commands to execute
      renderingOptions:
        displayType: CODE

Sometimes it's desirable to group plugin properties by concern. The next screenshot shows the SSH key and options grouped together.

You name the group using the groupName attribute. In this example the SSH configuration is grouped under the groupName, "SSH". Here are the SSH configuration properties in the plugin.yaml:

    - name: ssh-key-storage-path
      title: SSH Keyfile
      type: String
      required: false
      description: "Storage path for ssh key."
      renderingOptions:
        groupName: SSH
        selectionAccessor: "STORAGE_PATH"
        valueConversion: "STORAGE_PATH_AUTOMATIC_READ"
        storage-path-root: "keys"
        instance-scope-node-attribute: "ssh-key-storage-path"
    - name: ssh-options
      title: SSH Options
      type: String
      required: false
      description: "Extra ssh options"
      default: "-tt -o StrictHostKeyChecking=no"
      renderingOptions:
        groupName: SSH

It's also interesting to note how the SSH key data can be accessed from the Keystore using the "STORAGE_PATH" slectionAccessor. The valueConversion attribute tells rundeck to give the plugin the key data.