This chapter is dedicated to the interaction between Orchestrator and vRealize Automation (vRA). In this chapter, we will cover the following topics:
Automation has changed since the arrival of Orchestrator. Before tools such as vCloud Director or vRA, Orchestrator was the main tool for automating vCenter resources. In fact you may remember VMware Life Cycle Manager (LCM) which was the first such product based on Orchestrator.
Now, vRA is the central cornerstone in the VMware automation effort. vRealize Orchestrator (vRO) is used by vRA to interact with and automate VMware and non-VMware products and infrastructure elements.
Throughout the various vRA interactions, the role of Orchestrator has changed substantially. Orchestrator started off as an extension to vCAC and became a central part of vRA. The following list only focuses on the changes that influence Orchestrator:
As you can see in the following diagram, vRA connects to the vCenter Server using an infrastructure endpoint, which allows vRA to conduct basic infrastructure actions, such as power operations, cloning, and so on. It doesn't allow any complex interactions with the vSphere infrastructure such as HA configurations. Using the XaaS endpoint, vRA integrates the Orchestrator (vRO) plugins as additional services. This allows vRA to offer the entire plugin infrastructure as services to vRA. The vCenter Server, AD, and PowerShell plugins are typical of integrations used with vRA.
Using XaaS, you can create integrations that use Orchestrator workflows. XaaS allows you to offer Orchestrator workflows as vRA catalog items, making it possible for tenants to access any IT service that can be configured with Orchestrator via its plugins. The following diagram shows an example using the Active Directory plugin. The Orchestrator Plugin provides access to the AD services. By creating a custom resource using the exposed AD infrastructure, we can create a service Blueprint and resource actions, both of which are based on Orchestrator workflows that use the AD plugin. In the Managing AD users with vRA recipe in this chapter, we will showcase all of these features.
Prior to vRA 7, the only way to integrate additional functions into the life cycle was using Stubs. Stubs were predominately used in vCAC 5.x and allowed you to attach a workflow at certain points (Stubs) in the IaaS workflow, such as pre-provisioning, post-provisioning, and so on. Such actions could be taken to change the VMs HA or DRS configuration or to use the guest integration to install or configure a program on a VM. From vRA7.1 onward, Stubs are deprecated and will soon be removed.
With vRA7, the Event Manager was introduced, allowing for a much higher integration into the life cycle. Where the Stubs offered only 6 entry points for integration, the Event Manager offers 33. We will show how to integrate Orchestrator into the Event Manager in the Using the Event Manager to start Workflows recipe in this chapter.
How to install and configure vRA is out of the scope of this book, but take a look at:
https://www.youtube.com/watch?v=RM-X5TGuKJo .
If you don't have the hardware or the time to install vRA yourself, you can use the VMware Hands-on Labs, which can be accessed after clicking on Try for Free at:
To read more about the Orchestrator integration with vRA, please take a look at the official VMware documentation. At the time of writing the documentation can be found at:
https://www.vmware.com/support/pubs/vrealize-automation-pubs.html .
The document called vrealize-automation-71-extensibility
discusses customization using Stubs.