I’m going to show how you can provision Kubernetes clusters using vRealize Automation (vRA). I’ll be using kubeadm to install the Kubernetes cluster and since kubeadm is in beta at the time of this posting and doesn’t support HA kube masters, the Kubernetes clusters will be more useful for sandbox type environments.
You’ll be able to select how many Kubernetes worker nodes you want and it will support scale out operations for the worker nodes. Scale in operations are possible, but you’d have to add additional functionality to do this. Currently I don’t have a need for this so I haven’t looked into it. As it stands, you could perform scale in operations and manually remove the longer existing Kubernetes worker nodes.
A common question I get asked when working with customers is why are they unable to see recently created vRealize Orchestrator (vRO) action when creating vRealize Automation (vRA) Property Defintions. For example, let’s say I created the vRO action below:
The main things to notice are:
- The action is called getNames and is under the io.orchestration package
- The return type is Array/string
In my vRA Property Definition I’ll set the Data type to be a String and Display as to Dropdown as shown:
Now if I select set Values to External values (a vRO action) and press Select, I’ll be presented with a list of vRO actions:
Here we can see the same vRO action (getNames) we created in vRO:
Before displaying the Select Script Action screen above, vRA queried vRO for all actions that have a return type of Array/string. This is because in the Property Definition I’m going to be displaying a dropdown box of strings.
If I was to change the Property Definition to use a Data type of Integer:
and tried to use External values, I wouldn’t be able to see my vRO script action:
So as you can see your vRO action’s return type must match the data type defined in your Property Defintion otherwise you’ll be unable to see your vRO action.
Because vRA allows you to configure a global vRO server and vRO servers per tenant, sometimes users will create a vRO action on one vRO server, but their vRA tenant will be configured to be using a different vRO server. If you have ssh access to the vRO servers, you can confirm that you’re working with the correct vRO server by running the following command as you attempt to browse vRO actions from your Property Definition:
tail -F /var/log/vmware/vco/app-server/localhost_access_log.txt | grep getNames
If you’re on the correct server, you’ll see results such as these:
vra73a:/var/log/vmware/vco/app-server # tail -F localhost_access_log.txt | grep getNames
2017-12-07 03:55:28.677+0000 127.0.0.1 – – [http-nio-127.0.0.1-8280-exec-1] “GET /vco/api/actions/com.vmware.o11n.plugin.dynamictypes.configuration/getNamespaceByName HTTP/1.1” 200 1011 194
2017-12-07 03:55:32.875+0000 127.0.0.1 – – [http-nio-127.0.0.1-8280-exec-13] “GET /vco/api/actions/io.orchestration/getNames HTTP/1.1” 200 827 196
I was trying use vRealize Orchestrator (vRO) 7.2 with vSphere 6.5 GA and U1 the other day and was receiving the following error when I selected vRO Servers under Inventory in the vSphere Web Client:
Today I had a customer say that they added the vRA “Unregister (Machine)” entitlement to their account but were unable to see the Unregister action in the Actions dropdown list:
Starting with vRealize Automation 7.3 (vRA) there is native integration with Puppet. This means that there are now Puppet object within the vRA interface that you can drag and drop onto your blueprints as well as select Puppet constructs such as roles from dynamic drop down lists while building and deploying vRA blueprints. You can read the annoucement from Puppet here. Puppet has also provided some starter content to make getting up and running quick.
I’m going to show you how you can use vRealize Automation (vRA), Ansible, Powershell, GitLab and Jenkins together to test software deployments. There are many ways to accomplish what I’m going to demonstrate, but I’m going the simple route in most cases as it will be easier to cover in blog form. Throughout the post I’ll point out other options you may want to explore.
The end result is that when we push new code to our repository it will kick off a Jenkins job that will provision a vRA machine which will proceed to install software based off our updated code.
If you’ve worked with vRealize Automation (vRA) for any amount of time you’ve most likely experienced a provision that has either failed or gotten stuck in progress. I’m going to show how you can begin troubleshooting these scenarios.