vRealize Automation 8.0
As the on-prem installation of vRealize Automation 8.0 went GA, I extend my series on vRAC with a report on my first hand-on experiences with the new version. I have tested my installation with all functionality described in my previous blogs.
vRealize Automation Installation
The whole installation process is described in two excellent blog posts and in the official documentation:
I did a simple installation in my home lab: 3 appliances, vRA 8.0 comes in one appliance with an embedded vRealize Orchestrator and the embedded on-prem FaaS provider based on OpenFaaS. Lifecycle Manager and VMware Identity Manager are the two additional appliances automatically installed by the “Easy Installer”. And finally we got rid of the additional Windows Server used in the 7.x versions.
Big Picture of the vRA 8 Appliance Architecture
The vRA code was completely refactored into clearly separated micro services running in containers – each comes with its own web server (spring boot on netty). These containers are orchestrated on a single kubernetes node. If you ssh in the appliance you can check the kubernetes cluster with
kubectl get all -o wide –all-namespaces
Differences to the SaaS Version
Most of the UI and API works exactly like the SaaS version and seems to be packaged from a very recent version of vRAC: I found vRealize Orchestrator 8.0, custom forms, external K8s clusters and the embedded on-prem FaaS provider (based on OpenFaaS) installed out of the box. Nevertheless, there are some minor differences caused by the on-prem installation needs:
- vCenter can only be attached without CloudProxy. Sure, that’s an obvious one, you will only attach your on-prem vCenter resources.
- VMware Identity Manager (VIM) is installed automatically by the Lifecycle Manager. It replaces the my.vmware.com login and the IAM solution of the SaaS version with the full-fledged product. In vRA 7.x there was only a lightweight component without management UI delivered. In VIM you can federate with other Identity Providers, I just tested Windows AD and this worked very well out of the box. I plan to do a further deep dive especially in the OAuth 2 clients supported by the full version of VIM. We have the need to find a good solution for server processes without using headless browser workarounds to get a login via 3rd party IDP.
- The API endpoints are slightly different, the IAM and catalog entpoints are the same (just the root of your vRA installation):
curl -X POST \
https://<your vra8 fqdn>/csp/gateway/am/api/login?access_token= \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
"username": "<-your username->",
"password": "<-your password->"
If you take the refresh code delivered in the response, you can use the API like with the refresh code from the SaaS offering.
curl -X POST \
-H 'Accept: application/json' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d refresh_token=<your refreshtoken>
In the SaaS version this host is used for IAM, most other requests have https://api.mgmt.cloud.vmware.com/ as endpoint. On-prem you do not have to call two different endpoints.
vRA 7 Migration Assessment
Very interesting addition, unfortunately I did not have time to do a deep dive on this functionality. But stay tuned, we have planned some interesting test cases, because this is THE topic for us at Swisscom.
Select the tenants to assess
After you have configured the endpoint of the vRA 7.x to migrate, you will be offered the tenants to assess.
Assessment details on vRO workflows
As you can see, the assessment tool is here flagging the obvious for vRO workflows: the vRA 7.x plugins vCAC and vCACCAFE are not supported anymore. As 7.x workflows will make heavy use of these libraries, this will be the main part of the manual upgrade preparation. Currently there is no replacement for it available and even if it would be delivered, the model has changed dramatically. In one of my previous posts I have shared an approach with the necessary REST library to implement the API calls. You will have to slightly adapt it, because vRO does not have the same directory structures for the “Configuration Elements”. They are now on “web-root” and not on the place I would expect them to be… (see below).
vRealize Orchestrator 8
The old Java Client Application is outphased with vRO 8. The whole functionality is migrated to the web pages in the clarity design (angular). I have the impression, that the kernel of vRO has not changed a lot, it’s just a pimped UI.
The first version of the GIT integration, however, is an important improvement. Now you can push and pull from one repository (on the master branch). Only changed assets are offered to push to the repository – so you do not have a repository containing also the delivered workflows. We had a meeting with Galina Kostova, PM for vRO, at VMworld in Barcelona, and discussed our first impression and our feature requests:
- Switch branches
- One Repository only is good enough: we would have to merge team repos
- Preprocessing resources must be possible: if you want to avoid credential and environment specific variables to be checked in in GIT, you need a preprocessing step. We are working on a concept that should also be applicable for other GIT integrations in vRAC/vRA 8.
The structure in GIT is not optimal:
Top Level GIT directory structure
The root is as expected, but if you go into the packages, you find only flat files named by their object ID:
Folder content, completely flattened
This works for a machine without problems but makes it very difficult for humans. One of the problems is now, that the directory structure of the previous version seems to be completely replaced by a tagging approach. A file imported from com/swisscom/vro/test is not placed in a directory but on the top level tagged with “com.swisscom.vro.test”.
But now you can see the commented GIT history already in vRO
and can even do in place comparisons.
GIT compare view
The GIT workflow is supported in both directions: you can PULL and PUSH your code. Only your files will be pushed, the preinstalled artefacts will not be held in the repository.
Currently only one repository on its master branch is supported, what makes it very hard to support a GIT flow in a team.
The LCM is definitely worth a separate blog post, stay tuned. For now, I leave it with some nice pictures of one of the most attractive functions: you can automatically install additional products:
Repository for Binaries
After having downloaded binaries and licenses
Day 2 action for an existing “Environment”
you just can add additional products to an installation
Select products to add
Here you can see vROPs and vRLI is already added, vRNI could be added to this “environment”.
VMware Identity Manager
The full product as a separate instance. We will do in depth testing with our SAML federations and are hoping for JIT capabilities.
I am delighted with the new version! It is not lagging the cloud version and brings a lot of important improvements: the refactoring has been completed (no IaaS server and agents), the API is much cleaner, and the artefacts are kept in simple yaml formats. The GIT integration is at least a very good start, especially the one for vRO (two way synch).
The easy installer is simply awesome. It makes it very easy to do a setup even of a cluster. I’m looking to see further integration of the products over LCM in cloud foundation – this could be an approach to solve multi-tenancy requirements on a service provider level as multi-instance automated installations.
Of cause I have a huge wish list as always… and I’m looking forward to continue the very fruitful collaboration within the design partner program and many f2f discussions with the responsibles for the product development. One thought from my side right away: I hope VMware is building their products compatible to project pacific (drink your own champage!) and does not use appliances but pure K8s deployments for all of their on-prem products. I was very pleased to see vRA 8 completely revamped to k8s – let’s keep the pace!