Resource model setup

The Resource Model is the set of available Nodes that Rundeck can dispatch commands to, and their associated metadata. Each Rundeck Project has its own Resource Model.

The initial resource model will contain information just about the Rundeck server host and is useful just for running local commands on the Rundeck server. You can browse the project resource model by going to the "Jobs" page.

Node resources have standard properties, such as "hostname" but these can be extended via attributes. One of the more useful attributes is "tags". A tag is a text label that you give to the Node, perhaps denoting a classification, a role the node plays in the environment, or group membership. A list of tags can be defined for a given node.

The output above shows the "strongbad" node currently has an empty tags property: tags: ''.

It is important to start thinking about node tagging for the nodes you manage because you will use them later when specifying node filtering options.

Each Project has a configuration file called project.properties, located at this path:

• rpm/deb: /var/rundeck/projects/project/etc/project.properties
• launcher: $RDECK_BASE/projects/project/etc/project.properties

This configuration file contains two basic properties for accessing and storing resource model data:

• project.resources.file: A local file path to read a resource model document

In addition, multiple pluggable "Resource Model Sources" can be configured for a project to retrieve additional Resource Model content from other sources. See Resource Model Sources.

You can configure Rundeck to retrieve and store resource model data from any source, so long as it can produce one of the Rundeck resource model document formats. (See Resource Model Document formats.)

Here's the XML document stored for the "examples" project that corresponds to the output printed by the dispatch -v shown earlier:

<project>
  <node name="strongbad" 
    description="the Rundeck server host" tags="" 
    osArch="x86_64" osFamily="unix" osName="Mac OS X" osVersion="10.6.2"
    hostname="strongbad"  username="alexh" />
</project>

You'll notice a single node entry for "strongbad". The node element has a few required such as name, osFamily and tags.

Additional node descriptors can be added by defining new node elements inside the project root element.

The strongbad host does not have any tags defined for it. One or more tags can be defined. Use comma for the delimiter (e.g, tags="tag1,tag2").

Here's an example of a node called "homestar" with tags defined:

<node name="homestar" 
  tags="tag1,tag2"
  osFamily="unix"
  hostname="192.168.1.02" 
  username="alexh" />

The hostname and username values are used for the SSH connection while the name and type are used to define Node identity in the resource model. It is possible to overload the hostname value to include port information (eg, hostname="somehost:2022"). This is useful if your run SSH on a different port.

Chances are you maintain information about your hosts within another tool, perhaps Chef, Puppet, Nagios, Amazon EC2, RightScale or even an in-house database. One of these tools might be considered the authority of knowledge about the nodes deployed in your network. Therefore, it is best to create an interface to the authoritative tool and expose it as Rundeck URL resource model source. This can be done as a simple CGI script that does a transformation from the tool's format to the one Rundeck understands. You can also develop a plugin to interface with the external source.

Of course, a rudimentary alternative is to maintain this information as an XML document, storing it in a source repository that is periodically exported to Rundeck. This method would be practical if your host infrastructure infrequently changes.

Check the Rundeck web site for URL resource model sources. If you are interested in creating your own, see the Resource model source chapter.

Resource Model Document formats

Rundeck currently has two resource model document formats built in:

• XML: resource-XML. Format name: resourcexml.
• Yaml: resource-YAML. Format name: resourceyaml.

You can enable more formats using Resource Format Plugins.

Pluggable Resource Model Sources

Each project can have multiple sources for Resource model information, and you can use or write plugins to enable new sources for entries in the Resource model.

You can configure the sources via the GUI from the Admin page, see Configure Page, or by modifying the project.properties file.