In my first blog in the Self Service Hybrid Cloud series I discussed how to create IaaS blueprints and catalog items for a VMware Cloud on AWS environment, you can check out that blog here. I discussed how vRealize Automation consumes SDDC networks, storage and templates and more. This is a powerful solution for organization to be able to truly take advantage of their hybrid cloud investment and provide a rich set of IaaS services on top of that.
In this blog I want to take things up a notch and discuss how vRealize Automation can be used to make API calls to VMware Cloud on AWS for tasks such as:
- Create an SDDC
- Create a Firewall Rule
- Retrieve SDDC Data
- Add a Host
- Create a Network
- and much more!
There are a couple of methods by which API calls can be made from vRealize Automation into various system but in this blog we will look at how vRealize Automation Action-Based Extensibility(ABX) actions provide this functionality and of course ultimately these ABX actions are published to the catalog. So the end goal is to have a Self-Service Catalog that has items to make API calls to VMware Cloud on AWS. I have posted some ABX Python examples here.
This is a joint project I have been working on with Nico Vibert, a VMware Cloud on AWS Engineer, and he blogged about this topic as well here, so check out his blog too!
ABX
ABX (Action-Based-Extensibility) actions are essentially multi-cloud FaaS scripts that can be written in python, node.js or powershell. I chose python as the scripting language for these examples. When you create an ABX action you can “Test” the action straight from the action itself or you can publish the Action to the Service Broker catalog and then build out a catalog of ABX XaaS items. These XaaS items can hit the VMware Cloud on AWS API to perform tasks(POST,PATCH,DELETE) or retrieve data (GET).
If you want to understand ABX in more detail then check out out the blog located here. At a high-level ABX is an extensibility framework designed for multi-cloud. But it can also be used to execute and run python/node.js/powershell scripts and then those actions can be published to the Self-Service Catalog to create a XaaS solution. In this blog we will explore some examples of using ABX specifically for VMware Cloud on AWS use cases.
Sample ABX code may look like this:
Keep in mind, that these scripts will run when you click “Test”.
For GET requests testing using your existing SDDC should be fine since you are not changing anything, but for POST/DELETE/PATCH then just be mindful about cost to your VMware Cloud on AWS.
Now that we have gotten some of the house cleaning out of the way, let’s look at how you can import and use the scripts to start managing your VMware Cloud on AWS SDDC environments.
SDDC and NSX-T API Overview
I wanted to make a quick note about the two primary APIs you will be working with when working with VMware Cloud on AWS. There is the general SDDC API and then a NSX-T API. Both are useful to achieve different things, such as the SDDC Policy API can be used to Add Hosts, etc. Where the NSX-T API is used to Create Firewall Rules etc. So in our sample scripts you will see differences in the structure of the code to reflect that.
Importing ABX Actions
ABX actions can be imported or copy/pasted into a new action, we have created a number of ABX actions and posted them on GIT. You can import those into vRealize Automation and consume them, we have documented the process here
However I will do a brief overview of this process. From the git page with our samples download the .py and .abx action and create a .zip file. Then import that zip file into your ABX Action environment. After importing the scripts you will need add your Refresh Token and in most cases either/or SDDC ID or ORG ID from VMware Cloud on AWS to the script for authentication. You can find out how to generate a Refresh Token here.
Our sample scripts will use our Refresh Token to get the session token so you don’t have to find the session token yourself.
Within the ABX action there is a button called “Test”. When you click the “Test” button the action will execute so be mindful of that especially when you are doing POST or DELETE actions. See example below:
When looking at the ABX Action run after clicking “Test” you can see things like json payload that was sent in this POST request or in the Logs tab you can see the output if it is a GET request for instance.
ABX actions use FaaS providers such as AWS Lambda or On-Prem ABX appliance. The FaaS provider you choose is up to you, if you use AWS Lambda then you will see your Lambda Functions running inside of AWS. If you are concerned about costs associated with Lambda then using the On-Prem appliance could be a good alternative. The On-Prem ABX Appliance also may be a workaround if you are getting “urllib3″mismatch warnings with Lambda. The “urllib3” warning should not hinder the script to run successfully, however if you want to eliminate the warning for visual purposes (i.e. – in a GET request) then the On-Prem appliance has traditionally not displayed these types of warnings. Python also allows for the suppression of some urllib3 warnings (urllib3.disable_warnings( )).
If you choose to just copy/paste the python code into an ABX action then just pay attention to the def handler( ) inputs as those will need to be configured in the Inputs section of the ABX action. See screenshot examples below. The “def handler” section has some inputs like [“number_hosts”], [“targetRegion”],[“sddcName”], those inputs also need to be entered in the inputs section as well.
Publishing the ABX Action to the Catalog
Once you have imported or copy/pasted the ABX action into vRealize Automation, then it is easy enough to publish it to the Catalog for Self-Service consumption. In this blog I will do a basic overview of publishing ABX actions to the catalog but you may also want to read the documentation around this process here.
ABX allows for version control of the action itself and the action needs to be version controlled in order to publish it. First click the “Create Version” button at the top of the page.
Then once it is created, click the “Versions” button and then click the “Release” button next to the version you want to publish to the Catalog.
vRealize Automation Catalog Services
vRealize Automation provides a rich set of catalog services and policies, there are various Content Sources which can be configured to pull in Catalog Items, e.g., Blueprints, vRO Workflows, Code Stream Pipelines, and more. One of the Content Sources is ABX Actions and that is obviously what we have been focusing on in this blog. Publishing ABX Actions to create something similar to what you see in the screenshot below:
In the screenshot of the Catalog you can see various Extensibility Actions (ABX) and I have a few other items as well, like Blueprints and a Pipeline just as an example. The ABX Actions that are published will provide the user with a request form with inputs from the ABX action. Also these request forms can be modified using Custom Forms templates which provide additional customization to the request form. I highly recommend getting familiar with how to configure Custom Forms, when you do I think you will configure them for all of your catalog items.
Now that you have some ABX scripts examples to start with and a methodology to publish these actions to a catalog, it is easier to consume and deliver SDDC to your organization!
Stay tuned for more blogs around VMware Cloud on AWS and vRealize Automation working together!
Blogs to check out:
HOW-TO: ABX/vRO Powershell actions which include additional Modules
Introducing vRealize Automation Cloud Add-On for VMware Cloud on AWS customers!
