This recipe centers on using the multi-node plugin (formerly known as the VCO plugin). This plugin will allow us to manage other Orchestrators.
We need at least two Orchestrator installations.
It is also quite important that both Orchestrator instances are compatible with each other, meaning they should preferable be of the same version and build.
This recipe will call the first Orchestrator installation the local Orchestrator, and the one we add will be called the remote Orchestrator. The remote Orchestrator can be a cluster.
8281
.
We declined in the previous section to create proxy workflows because we will do it here:
VCO@[IP or FQDN Orchestrator]:8281
, as well as the workflows under it. See the following collage:
Instead of just creating one proxy workflow, you can create proxies of all the workflows of the remote Orchestrator by navigating to Library | Orchestrator | Remote Executions | Server Proxies | Create proxy workflows for an Orchestrator Server, or a workflow folder, Library | Orchestrator | Remote Executions | Create proxy workflows from a folder.
Also, note that you can refresh the proxy workflows. This will make sure that changes in the input or output variable are synced to the proxy workflows.
Another useful function is the ability to deploy packages to remote servers. Perform the following steps:
The multi-node plugin can be used in quite a lot of situations. The first and foremost is to manage remote servers that are in a cluster; see the recipe Building an Orchestrator Cluster in this chapter. Using the Multi-Node Plugin, we can now manage the Orchestrator clusters workflows and packages as shown in the following image:
Another good idea is to make sure that workflows, or basically any other Orchestrator element (by building a specific workflow), are replicated between Orchestrator installations. For example, for load-balancing or audit reasons, you have multiple Orchestrator servers and you need to make sure that elements are the same on all of them.
A very common use of the multi-node plugin is for maintenance work, such as cleaning out all finished workflows from remote Orchestrators.
Last but not least, you can execute workflows from a different Orchestrator. For example, you can write a workflow that automatically configures a new Orchestrator installation.
Please note that you can create a task from a workflow (see the recipe Scheduling workflows in Chapter 4, Programming Skills) and thus create an automated push or pull update from a cluster.
Explore the workflows that come with the VCO plugin, as there is quite a lot you can do. The following are examples:
Type |
Description |
Proxy workflows |
Server: Create, delete, refresh; create one proxy workflow, create from folder, create multi-proxy action. |
Packages |
Delete, delete by name, deploy from local, deploy from remote, deploy packages from local. |
Workflows |
Delete all finished, delete remote, deploy from local, deploy from remote.
Refresh stale workflow runs in waiting state.
Start in series, start in parallel.
|
Server |
Add, update, delete. |
Tasks |
Create, create recurring. |
As a last note, when you delete an Orchestrator server using the workflow by navigating to Library | Orchestrator | Server Configuration | Delete a vCO Server, all the proxy workflows of the remote Orchestrator will also be deleted from the local Orchestrator.