The ability to creating and manage infrastructure and services for your organization just became more flexible and powerful with the introduction of Custom Resources and Resource Actions in vRealize Automation. Taking advantage of the out-of-the-box integration with vRealize Orchestrator (vRO) you can now create Resources and Day-2 actions using vRO workflows in your blueprints and deployments! This functionality presents a powerful method for vRealize Automation admins to further customize deployments and provide more options when creating infrastructure resources.
Lets look at both Custom Resources and Resource Actions in more detail.
What are Custom Resources?
When creating blueprints in vRealize Automation Cloud Assembly, there are a number of Resource Types to choose from. Examples of Resource Types include a variety of cloud native objects and machine types, such as S3 Buckets, Cloud Agnostics Machines, NSX networks, vSphere Machines, Azure Resource Groups and much more. However there may be situations where the existing Resource Types may not be adequate for your use case, so in order to fill those gaps we have introduced Custom Resources. Each Custom Resource is based on a vRO workflow. You can use existing workflows or create your own when building Custom Resources. The Custom Resource then becomes an object that can be dragged onto the blueprint canvas and then is consumed as part of the deployment and are then Lifecycle Managed.
Besides Lifecyle Management option for Custom Resources, admins can also create optional custom Day-2 actions based on vRO Workflows as well. Lets dive into this feature a bit more.
Building Custom Resources
In order to build Custom Resources we will first need to build or identify a vRealize Orchestrator workflow for our use case. In this blog we will build out a simple use case of adding a user to an AD group along with the machine deployment. The vRO workflow is called “Add a user to a group”. This workflow will allow us to query Active Directory for both the Username and the AD Group that we want the user to join. The two inputs that we will be concerned with in our vRO workflow are userGroup and users, see image below.
Once we have properly configured the vRO workflow, we can then use that workflow in our Custom Resource object within vRealize Automation Cloud Assembly. Within Cloud Assembly you will see a Design tab at the top, this is where you will configure blueprints and custom resources. Click on Custom Resources and then New Custom Resource. Fill out the form with the following information:
Name – provide a name of the resource
Description – optional description
Resource Type – what type of resource is it , for our example here it is Custom.AD.User
External Type – the resource type must match the resource type defined in the vRealize Orchestrator workflow, for our example here it is AD:User
Activate – choose this if you want the resource to be available now
Scope – define which projects can consume this resource, if you want all projects to see this resource then just leave it to the default.
After configuring the items above, you can then add the workflows you want to use under the LifeCycle Actions section. There are three types of actions you can configure – Create, Update and Destroy. The only two that are required are Create and Destroy. In the example for our use case we will use the “Remove a user from a user group” for the Destroy action. Towards the bottom of the page there are also optional Day-2 operations that are available for use on the object once it is deployed. For custom Day-2 actions you can create Conditions that must be met before the action will be available.
There is also an option to customize the Request Parameters (click the 
icon) for the Day 2 action request via the Custom Forms Designer.
Once you create the Custom Resource it will show up in the Blueprint canvas a Resource Type. It will show up in Blueprints that are within the project scope you specified when creating the Custom Resource, if you did not specify a project for this object to be tied to then it will show up in all Blueprints as an optional resource.
Once you drag the Custom Resource onto the canvas then the blueprint YAML code will also show the object and the Properties that need to be bound to an input for the AD query. Remember the two inputs that were needed in the workflow – users and userGroup. So those are reflected in the code, I already created the bindings for the inputs under the “Custom_AD User_1:” object (example – user: ‘${input.user}‘).
You can now deploy the blueprint from Cloud Assembly or Service Broker and then query for the User and Group that you fits your needs. Once deployed you can see some information about the object and any Custom Actions you created for the resource. In the image below you can see both the VM that was deployed and the Custom_AD User is highlighted on the canvas revealing the properties on the right hand side as well as the action.
What are Resource Actions?
In addition to the Day-2 actions that are already available for Resource Types within vRealize Automation, you can now configure custom Day-2 actions that make changes to your deployed resources. These custom day-2 actions are referred to in vRealize Automation as Resource Actions.
Building Resource Actions
In order to build a Resource Action you will need to first identify the workflow you want to use as the Day-2 Action. Here is an example workflow that moves a VM to another folder within vCenter. Notice the two inputs – vms and folder. Those both point to the VC (vCenter) plugin so we can query VMs and Folder in the vCenter inventory. For this example there is also an associated action within vRealize Orchestrator that searches for all the VMs by name that is bound to Resource Action, we will see how the binding is done later.
In order to create the Resource Action just go to the Design section where we created the Custom Resource earlier. There you will see a link on the left side called Resource Actions. Fill out the form with the following information:
Display Name – provide a name for the action
Description – optional description
Activate – choose this if you want the resource to be available now
Scope – define which projects can consume this resource, if you want all projects to see this resource then just leave it to the default.
Resource Type – resource type that you want the action bound to, such as Cloud.vSphere.Machine
Workflow – choose the vRealize Orchestrator workflow that will run the action
Requires Condition – choose whether you want a condition tied to the action, such as osType = Linux
Property Binding – create and manage a binding action from vRealize Orchestrator
Edit Request Parameters – choose this if you want to use the Custom Designer to create a Custom Form for the user to interact with when choosing the action from the deployment menu
Earlier I mentioned there was also a vRealize Orchestrator action bound to this resource action, you can see it below in more detail. Basically I need the VM Input to use the Binding Action “getVMbyName” action and will reference the schema property “resourceName”. The “resourceName” property is the name given to the machine by vRealize Automation.
After this has been setup you are ready to deploy a blueprint that has a vSphere Machine so we can then see the action to move it to another folder within the Actions menu. Remember the machine that is being deployed is a Resource Type: Cloud.vSphere.Machine, I used that Resource Type here because I want to be able to move it to another vCenter folder. After it is deployed we now see the option to “Move to a Folder” from the Actions dropdown list. Once that action is chosen the user will be prompted for the Folder they want to move it to via a dropdown menu.
Custom Resources and Resource Actions promises to be a powerful way for customers to expand and customize how they will deliver services to the business and quickly provide value in their automation journey. Being able to use highly flexible workflows to create resources and actions opens up a world of possibilities!
For more information on vRealize Automation, check out these recent blogs:
vRealize Automation Action Based Extensibility (ABX) now supports PowerShell
New Resource Limits in Cloud Assembly
Yes! Code Stream Pipelines as Catalog Item
The post Introducing Custom Resources and Resource Actions in vRealize Automation! appeared first on VMware Cloud Management.