This section describes various CloudBees CD behaviors and possible modifications that you may want to make in your CloudBees CD configuration.
In a default installation, an agent is installed alongside the CloudBees CD 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 automatically use the local resource because it is usually present.
Many CloudBees CD users also write procedures that use the local resource for these reasons:
A user knows the local resource exists.
The user needs local access to the file system, such as access to the log files or configuration files.
The user needs local access to resources on the CloudBees CD server to perform tasks such as checking the CPU, memory, or disk space usage.
Any existing procedures for local access to CloudBees CD server file systems or resources need to be modified when you change your installation to run in a server cluster. There are now multiple CloudBees CD server nodes, each with their own log files, configuration files, and local resources. The name of the CloudBees CD log file on a CloudBees CD server node in a cluster has also been changed to
CloudBees CD does not support the local host IP address (127.0.0.1) for any CloudBees CD 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 agent and CloudBees CD server on the same machine. If you are concerned about performance, remove any agents from your CloudBees CD 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 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 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 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 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:
Do not have a local resource and remove any local resource on your system. For everything that is currently configured to use the local resource, reconfigure them to use other resources.
Create a resource pool called local for agents on non-CloudBees CD-server machines. Everything that is configured to use the local resource now runs on an agent of the local pool. However, this agent is no longer local to any of your CloudBees CD server nodes.
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 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 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 configuration. You must use an alternate database listed in Supported Alternate Databases : Oracle, MS SQL Server, or MySQL.
The contents of the DATA_DIRECTORY/broker-data directory can never be shared between nodes in a CloudBees CD cluster.
This may occur when a virtual machine running a CloudBees CD 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:
Shut down the CloudBees CD server on the new VM.
Delete the DATA_DIRECTORY/broker-data directory on the new VM.
Restart the server on the new VM.