Resource, agent, and procedure considerations

In a default installation, an agent is installed alongside the CloudBees CD/RO server, and a resource named local is automatically created for the agent. In a cluster, the local resource points to only one node. By default, some of the plugins and sample code installed with CloudBees CD/RO automatically use the local resource because it is usually present.

Many CloudBees CD/RO users also write procedures that use the local resource for these reasons:

CloudBees CD/RO does not support the local host IP address (127.0.0.1) for any CloudBees CD/RO configuration, because it is ambiguous when multiple servers are used.

If you are using clustering for performance reasons, you must manage your machine resources efficiently. You use additional machine resources if you run a CloudBees CD/RO agent and CloudBees CD/RO server on the same machine. If you are concerned about performance, remove any agents from your CloudBees CD/RO server node machines. You should also verify that any agents that may have been installed as part of an earlier configuration are also removed. An agent is installed automatically with any CloudBees CD/RO service by default.

If you are using clustering only for reliability reasons, you must reduce or eliminate single points of failure. In this configuration, having a single server node that runs the local agent is counterproductive. If you need a more reliable configuration, you can install agents on all of your CloudBees CD/RO server node machines and put them in a resource pool named local. Local agents should be used for broadcast and maintenance type work. See Agent Resource Strategies for more information.

If you have a local agent on each CloudBees CD/RO server, it may be appropriate for some procedures to have one or more procedure steps that are broadcast across all the resources in the local resource pool. These procedure steps are probably followed by a step that aggregates the resulting data in an appropriate way. For other procedures, it may be more appropriate to use the shared file system to which all the CloudBees CD/RO servers have access, and still have the step run on a single agent.

If you do not have any agents local to any of your server machines, a local resource is not automatically created. There are two possible strategies to handle this:

If anything relies on the local resource being local to the server, it must be modified to work across multiple server nodes, to function remotely from an agent running on another machine, or to be both. In some configurations, you may need to use the shared file system between the CloudBees CD/RO servers and the remote agent.

For example, if you want to write log-parsing procedures using nonlocal agents, you can configure all of your CloudBees CD/RO servers to write their logs to different locations in this shared file system. A procedure step running on a remote agent machine with access to this shared file system can then parse all the server logs.

The built-in database is not supported in a clustered CloudBees CD/RO configuration. Refer to Supported platforms for CloudBees CD/RO on traditional platforms: Databases for the complete list of the officially supported databases for CloudBees CD/RO.

The contents of the DATA_DIRECTORY/broker-data directory can never be shared between nodes in a CloudBees CD/RO cluster.

This may occur when a virtual machine running a CloudBees CD/RO server is cloned, and the DATA_DIRECTORY/broker-data directory is also cloned as part of the cloning operation.

If this occurs, remove the DATA_DIRECTORY/broker-data directory from the new virtual machine (VM) as follows: