Last week we showed how to configure vRealize Automation to provision AIX, Linux, and IBM i LPARs for IBM PowerVM using PowerVC enabled by OpenStack, the questions come rolling in. What can I do with that Infrastructure? How do I customize it? How do I apply IBM’s 250+ Cloud Builder Patterns? vRealize Automation makes this all very easy using the built-in Event Broker combined with vRealize Orchestrator extensibility.
vRealize Automation Blueprinting and Guest Customization
Creating blueprints in vRA 7 for OpenStack works just like it does for other endpoints using the converged blueprint canvas. In today’s example we’ll use vRealize Automation to provision an LPAR and use an Event Broker callout to run a vRealize Orchestrator workflow to drop a file on the machine, followed by running an SSH command on the machine.
- Start by opening the blueprint Designer.
- Drag a new OpenStack machine onto the canvas.
- Select an image that has been data collected from your PowerVC Endpoint
- Set any custom properties that need to be passed to the Event Broker call-out. To do this, you’ll need to set a custom property on the blueprint to define the custom properties that are sent with the payload to vRealize Orchestrator from the Event Broker.
- Create a custom property named: Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.MachineProvisioned
Note: the name of this property is specific to the Event Broker event selected. In this case, we will be calling vRealize Orchestrator workflows when a machine is provisioned. - Add a comma separated list containing the names of each custom property you would like to have exposed to the vRealize Orchestrator workflow.
Note: As you can see in the screenshot below, we have created a custom property for the SSH Command we will run within the vRealize Orchestrator workflow and we are passing that custom property in via the payload by adding it to the value of the Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.MachineProvisioned property.
- Create a custom property named: Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.MachineProvisioned
- Save your blueprint and publish it!
Set the conditions so that the workflow will only run:
- Post machine-provisioning
- For this blueprint only
To do so, you will need to configure the following:
- Run based on conditions
- All of the following:
- Data>Lifecycle state>Lifecycle state name Equals VMPSMasterWorkflow32.MachineProvisioned
- Data>Lifecycle state>State phase Equals POST
- Date>Blueprint name Equals AIX 7.1
Finally, pick the workflow to run and finish the event subscription:
The vRealize Orchestrator workflow can be quite simple, although more additional steps and error handling may be need in a production environment. In this case, the workflow will do the following:
- Write the payload from vRealize Automation into an XML file. The XML file will be saved to the vRealize Orchestrator server. Note: the payload will only include any custom properties were added to the custom property on the blueprint for the extensibility lifecycle properties (e.g. Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.MachineProvisioned). In our case, we included the out-of-the-box property for the assigned IP address (VirtualMachine.Network0.Address) so that we could access the newly provisioned VM for the SCP and SSH commands.
- Use an SCP put command to copy the file from the vRealize Orchestrator server to the newly provisioned VM. This is an out-of-the-box workflow that is available and the custom workflow uses the standard workflow and passes in the appropriate parameters (e.g. source file name, remote file name, user name, password).
- Run SSH command against the newly provisioned vRO server. This is also an out-of-the-box workflow that is available and the custom workflow uses the standard workflow and passes in the appropriate parameters (e.g. command user name, password). Note: in this case the vRealize Orchestrator workflow uses the command defined in a custom property on the blueprint.
For the purposes of this workflow, the entire payload from the vRealize Automation deployment is written to the XML file and sent through to the newly provisioned machine. The code to write the XML file looks like this:
Pulling this all together we can now manage infrastructure and applications on our x86 virtualization stack and IBM Power Systems stacks with the same user experience, governance and reporting capabilities. This abstracts the infrastructure from the application and gives users the applications that they need in the right cloud without being concerned by the complexity of managing multiple clouds.
A big thanks to Mandy Botsko-Wilson for contributing this content
