Kubernetes (k8s) is arguably one of the hottest technologies right now. Whether it’s building your own in the private cloud, leveraging vendor implementations to compliment your enterprise apps or consuming public cloud varieties like Amazon Web Service’s EKS – there’s no shortage of ways to deploy k8s.

HobbitCloud utilises the private and public cloud for different workloads. Our on-premises implementation uses Pivotal Container Service (PKS) together with VMware NSX-T to deploy complex workloads with powerful software-defined networking.

However, occasionally developers need to spin-up k8s clusters in the cloud for close proximity to existing workloads, or for specific data location requirements. In order to save the requester time, it would be handy if these clusters could be deployed in the public cloud direct from our enterprise cloud management solution, vRealize Automation.

This article shows you how to achieve just that with Microsoft Azure and Azure Kubernetes Service (AKS).

Other posts in this series:

1. Authentication
2. Deploying the cluster

Getting started

To enable vRA to spin-up AKS clusters in Azure we will be using vRealize Orchestrator (vRO) and the REST API. We will break down the provisioning process into two parts. The first will deal with logging into Azure, the second with deploying the cluster.

Login to vRO and switch to the Design tab at the top. Click the Actions tab and then create a new module. I will use com.hobbitcloud.azure.login. Create an action called createPostText and edit it.

Create three inputs called inClientId, inClientSecret and inResource all of type String. Change the return type to be of type String, and paste the following code into the body of the action:

requestBody="grant_type=client_credentials&" +
	"client_id=" + inClientId + "&" +
	"client_secret=" + inClientSecret + "&" +
	"resource=" + inResource;

return(requestBody);

Save and close the action. When complete, it should look like the following:

Create a new action called createRestHost. Create an input called inUrl of type String, set the return type to Any and paste the following code into the body of the action:

//Prepend the URL
var Url = "https://" + inUrl;

//Define the REST host
var restHost = RESTHostManager.createHost("DynamicRequest");
var transientHost = RESTHostManager.createTransientHostFrom(restHost);
transientHost.url = Url;

return transientHost;

Save and close the action.

Finally, create another action called parseToken. The input should be called inResponse and of type String. The return type should also be of type String. Paste the following code in:

//Parse the response
var jsonResponse = JSON.parse(inResponse);
var token = jsonResponse.access_token

return(token);

Now we have our action, let’s create our workflow to bring it all together.

Azure

Before we can do that, we need to gather our Azure details as we’ll need these for the API call. Specifically we will need the following:

• Client ID
• Client secret
• Tenant ID

The tenant ID can be found easily, either in the portal under Cost Management & Billing / My Subscriptions, or by logging into the Azure CLI.

A client ID and secret needs to be generated in Azure Active Directory / App Registrations. I typically create one for each app that will integrate with Azure, eg. vRealize Automation, vRealize Business for Cloud etc.

Once you have the client ID and secret make a note of them. The secret is shown only once.

Workflow

Once we have these, create a workflow called Request Azure Token. Create the following in attributes (not input parameters), all of type String apart from attRestHost, which should be of type Any:

• attBody
• attClientId
• attClientSecret
• attResource
• attResponse
• attRestHost
• attTenantId
• attUrl

Enter the client ID, client secret and tenant ID values. Set the values of attResource to https://management.azure.com and attUrl to login.microsoftonline.com (the former starting with “https:”, the latter not).

Create an output parameter called outToken and set it to type String.

Click on the Schema tab and drag an action element onto the canvass. In the box that appears, type createPostText to select the action we previously built.

A message will appear asking “Do you want to add the activity’s parameters as input/output to the current workflow?”. Cancel that and move down and select the Visual Binding tab. Here we will map the In Attributes to the In Parameters of the action.

Select attClientId in the bottom left and drag up and across to inClientId. A mapping will then be created. Repeat this step for attClientSecret and attResource. Similarly, map the actionResult to attBody on the right-hand side. When complete, it should look like:

Drag another action from the top left onto the canvass, this time selecting createRestHost. Map attUrl to inUrl, and actionResult to attRestHost:

Drag a Scriptable Task onto the canvass and rename it (using the Info tab) as Submit request. Map attBody, attRestHost and attTenantId as inputs, and attResponse as an output:

Click on the Scripting tab and enter the following code:

//Compute the full URL
var requestUrlString = "/" + attTenantId + "/oauth2/token";
var request = attRestHost.createRequest("POST", requestUrlString, attBody);

//Set the content type
request.contentType = "application\/x-www-form-urlencoded";

//Execute the request and get the response
var response = request.execute();
var statusCode = response.statusCode;

if (statusCode != 200) {
	System.error("Error: " + attBody);
	throw new Error("Failed to get token: " + statusCode);
}

//Set the response
attResponse = response.contentAsString;

Drag the last action onto the canvass and select the parseToken we created previously. Ignore the offer to add parameters, and map attResponse to inResponse, and actionResult to outToken:

Finally, click Validate at the top to check for errors. If you get anything but a green bar and a message stating the workflow is valid, go back and try to find what you’ve missed.

Save and close out of the workflow and run it. It should be successful, and when you look at the variables, the outToken should contain the bearer token:

Up next

In part 2 of this series we will use our freshly created bearer token to authenticate against the Azure API and provision our Kubernetes cluster.