This blog post assumes you have familiarity with vRealize Orchestrator and some experience with importing workflows and working with the HTTP-REST plugin. If these are new concepts for you, please don't be discouraged. Some great references to get comfortable with Orchestrator are:
HOL-1721-SDC-5 - Introduction to vRealize Orchestrator
Blog from vcoteam.info on using the REST plugin
Postman + vRO = HTTP-REST Plug-in Operations
Let's dive in.
|The Example Workflow Schema|
- The workflow uses the alert ID input to get the vR Ops alert (including all the details of the alert).
- The resource ID for the impacted resource is extracted from the alert.
- The resource details are fetched, using the resource ID.
- Because the alert is due to a service monitored by the Endpoint Operations agent, the workflow needs to get the ID of the parent resource. The parent resource is the guest operating system where the agent is installed.
- The parent resource details are fetched, using the resource ID for the parent from step 4.
- Now the workflow extracts the operating system IP address from the resource details.
- Using the IP address, the workflow now issues an SSH command to restart the service.
You can import the example workflow package into your Orchestrator instance. If you aren't familiar with Orchestrator, I highly recommend you visit the vcoteam.info and check out the great tutorials there.
Once you import the package, make a note of the workflow ID for the Restart Service from Alert workflow. You'll need that for the next steps.
|The Workflow ID is found under the General tab|
Configure the REST Host and Create OperationsAs mentioned, Orchestrator uses REST to gather information from vR Ops. So, we will need to add vR Ops as a REST host within Orchestrator. Additionally, the workflow is making three different REST API calls to vR Ops. We will create three REST operations in Orchestrator to support the workflow.
Let's start with adding vR Ops as a REST host. In the Orchestrator client, you can run the workflow from Library > HTTP-REST > Configuration > Add a REST Host. The following screen shots walk through the inputs for my lab environment.
|The "Name" is a friendly name to identify within Orchestrator. |
For the URL, use https://
|For simplicity in testing, I recommend using Basic authentication.|
|Set the Session mode to Shared Session, and provide administrator level credentials for your vR Ops instance.|
|Very likely you won't need a proxy - unless you just like to make things difficult for yourself! :)|
|If you are using self-signed certificates, I recommend leaving this at "No"|
click "Submit" to add the REST host
Create REST Operations
Now that we have added the vR Ops server as a REST host, we can create three REST operations that the workflow will require. They are:
Each of these will be added using Library > HTTP-REST > Configuration > Add a Rest operation workflow.
Once added, you can configure the workflow to use these REST operations. Edit the workflow Restart Service from Alert and modify the attributes for each of the REST:RESTOperation data types, selecting the appropriate REST operations.
Now edit the workflow SSH Restart VMtools and modify the attributes for username and password to an account that has permission to SSH into the OS and start a service.
Now Orchestrator is ready to run the workflow to restart a service with the input of an Alert ID from the Translation Shim! In the next blog post, we'll set up the alert notification, configure an alert and trigger the alert to test everything out.