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.
- Log in to your local Orchestrator.
- Start the workflow: Library | Orchestrator | Server Management | Add an Orchestrator server.
- Enter the FQDN or IP of your remote Orchestrator and specify port
8281. - It helps if you accept the certificate silently as it creates less work for you.
- You may not want to create proxy workflows at this stage as this will create proxy workflows for every existing workflow (including all the library ones).
- Click on Next. The following page will ask you about the timeouts (in seconds) for the connection to the remote Orchestrator. You should align this according to your bandwidth and or cluster settings.
- The Retry timeout (minutes) is the time the local Orchestrator will wait for a response form the remote Orchestrator.
- Select Yes if you want to share the connection, meaning that the user you specify will be used to execute workflows on the remote Orchestrator. If you select No, the user executing a proxy workflow will be the one that will execute the remote workflow. This requires both the local and the remote Orchestrator to be registered on the same SSO:
- Click on Next. The following page will ask you about the timeouts (in seconds) for the connection to the remote Orchestrator. You should align this according to your bandwidth and or cluster settings. The Retry timeout (minutes) is the time the local Orchestrator will wait for a response form the remote Orchestrator. Select Yes if you want to share the connection, meaning that the user you specify will be used to execute workflows on the remote Orchestrator. If you select No, the user executing a proxy workflow will be the one that will execute the remote workflow. This requires both the local and the remote Orchestrator to be registered on the same SSO: After the workflow has finished, go to the inventory and have a look under the vRO multi-node plugin. There, you will find all the items that exist in the remote Orchestrator.
We declined in the previous section to create proxy workflows because we will do it here:
- Using the local Orchestrator Client, start the workflow by navigating to Library | Orchestrator | Remote Executions | Create a proxy workflow.
- Select the remote workflow you would like to use. Click on Next.
- Choose to create proxy workflows that are executed synchronously (Yes) or asynchronously (No). Synchronous means that Orchestrator will wait until the workflow is executed completely (use the default, which is Yes).
- Wait until the workflow has finished. Then, check whether the new folder has been created in the workflow tree called
VCO@[IP or FQDN Orchestrator]:8281, as well as the workflows under it. See the following collage:
- Now, execute one of the proxy workflows. When finished, check on both Orchestrators; you will find that the proxy workflow will have executed on both sides. However, log messages and variable tracking will only be in place on the remote server.
- It's a good idea to go and check what happened on the remote Orchestrator. Look at the execution and the logs.
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:
- Using the local Orchestrator Client, start the workflow by navigating to Library | Orchestrator | Remote Management | Packages | Deploy a package from a local server.
- Select the package you would like to deploy from the local Orchestrator to the remote Orchestrator.
- When selecting the remote server, you are actually able to choose multiple remote Orchestrators. An array window will open; select Insert Value. An additional popup will show up here; select the remote Orchestrator and click on Add.
- The chosen package is now installed on the remote Orchestrator.
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.