posted

0 Comments

In addition to Python and NodeJS, vRealize Automation now supports PowerShell as a scripting language for writing Action Based Extensibility (ABX) code. Actions are executed based on lifecycle events, using functions-as-a-service (FaaS), to extend the functionality of the platform. PowerShell is only supported for on-premises deployments, and requires an appliance deployed alongside the Cloud Proxy if you’re using vRA Cloud.

Note: PowerShell is currently in Beta, so use at your own risk.

To use PowerShell for ABX, you’ll need to complete three steps:

  1. Deploy and Configure a Cloud Extensibility Proxy
  2. Create a PowerShell Action
  3. Create a Subscription

Update 05/2020 – From the May release of vRealize Automation Cloud, ABX Actions can now be shared across all Projects in an Organization, check the box under “Settings” to share.

Deploy and Configure a Cloud Extensibility Proxy

Note: This step is NOT required for vRealize Automation deployed on-premises

Log into vRealize Automation with a user account that has the Cloud Assembly Administrator role. Open Cloud Assembly and navigate Infrastructure > Integrations > ADD INTEGRATION. Select the “Extensibility Actions On Prem” tile:

Extensibility Actions On Prem tile

Click on the “NEW CLOUD EXTENSIBILITY PROXY” button and either download the OVA, or copy the OVA link to deploy directly into vSphere. During the OVA deployment you’ll be asked to enter a one-time key, which should be copied from these install instructions. Once deployed, the Cloud Extensibility Proxy will connect back to vRA Cloud using the copied key, and the ABX integration can be completed.

 

Install Cloud Extensibility Proxy wizard Extensibility Integration Endpoint configuration page

Create a PowerShell Action

Open Cloud Assembly and navigate Extensibility > Actions > NEW ACTION. Enter a Name, Description and select the Project to contain the action. If you’ve got multiple Cloud Extensibility Proxies deployed the tags that are assigned to the Project or Blueprint will determine the placement of the execution. For example, my Proxy deployed above was tagged “cloud:vsphere”, and you will see later that I’m using the same tag as a constraint in the Blueprint.

Once you’ve created the new Action you can select the scripting language from the drop down.

New action dialogue Select PowerShell as the scripting language

Writing an ABX action in PowerShell is the same as with Python or NodeJS – we define a main handler function that receives a context and payload object. Context contains details of the execution of the action, while payload gives details about the deployment and event. The payload is a PSCustomObject whose properties match the event that is being subscribed to (see Extensibility > Event Topics to view each topic and its schema).

The example PowerShell code below takes a custom property from the Blueprint and uses it to rename the Virtual Machine before deployment.

Note that the “On Prem” FaaS provider is selected.

PowerShell Action configuration

Create a Subscription

The final step is to create a Subscription for the “Compute Allocation” event of my Blueprint to trigger the PowerShellABX action. I’ve pre-created a simple one-VM blueprint, with a user input for a custom VM name that is assigned to a custom property. This will be passed to the Action as part of the payload ($payload.customProperties.userDefinedName).

Example blueprint YAML with custom property

To create the subscription navigate to Extensibility > Subscriptions > NEW SUBSCRIPTION. I will use the “Compute allocation” event topic, so that I am able to rename the VM before it’s deployed. I will filter based on the blueprintId to ensure that only my blueprint triggers the execution. Finally, I will assign my PowerShellABX Action and ensure it’s a blocking task so that the blueprint deployment will not continue until the action has executed.

PowerShell Action Subscription configuration

Executing the PowerShell Action

Now that those three steps are completed, we can test the PowerShell Action by triggering a deployment of the blueprint. When the Deployment hits the “Compute allocation” event, the Action is triggered and the PowerShell code executed. The PSCustomObject that is returned by the action updates the resourceName for the VM, and the deployment proceeds with the new name.

Successful execution of the Action

 

Deployment, with renamed VM

Conclusion

The addition of PowerShell to the Action Based Extensibility in vRealize Automation allows administrators who have already invested time in learning PowerShell as a scripting language to quickly develop automation for the lifecycle of their Deployments. In addition, the existing rich PowerShell ecosystem allows further integration into third party systems not yet natively supported by vRealize Automation through the ability to import PowerShell modules.