Accessing HTML5 Orchestrator Dashboard in vRealize Automation 7.4

Accessing HTML5 Orchestrator Dashboard in vRealize Automation 7.4

· Read in about 5 min · (952 words) ·

And The BU Said “Let there be HTML5…”

<img src=”/images/2018-04-12-accessing-html5-orchestrator-dash/01-flows.PNG#center” alt="Orchestrator”;>

vRealize 7.4 has gone GA! There's a TON of great stuff in it - and it'll probably dominate my blog for a while because of the depth/breadth of content there is to cover. One of those new features is a really clean dashboard portal for vRealize Orchestrator, in full HTML5/ClarityUI glory!

vRealize Orchestrator (vRO henceforth…) has a pretty mixed audience, but I'm still a huge fan of it (Come at me haters. I feed on your tears.). I think it solves some very real problems surrounding programmatic workflow driven automation. In other words, if you have a process that needs to complete step by step, and be able to build constructs around each of those steps, vRO is still a VERY solid product. It's great to see the BU still giving it some love and giving it a facelift!

That being said, when I upgraded to vRA 7.4 - one of the first things I wanted to do was play with this new dashboard. When I went to the main appliance page and clicked the “vRealize Orchestrator Monitor” (screenshot below) a couple bad things happened…

  • It attempted to load via my load balancer FQDN; this was bad because I didn't configure my NSX load balancer to handle my Control Center port (8283)
  • When I switched to the appliance hostname - it threw a 404 not found. Page didn't exist…

<img src=”/images/2018-04-12-accessing-html5-orchestrator-dash/02-orch-start.PNG#center” alt="Orchestrator”;>

The “How to fix it” Part

It turns out, that the monitoring dashboard is tied directly into the Control Center service. You can't run one without the other. This service isn't started by default on the appliance - however it's an easy fix.

SSH into your vRealize Automation 7.4 Appliance and run service vco-configurator start. This activates the Control Center service, and subsequently the vRO Monitor service as well.

<img src=”/images/2018-04-12-accessing-html5-orchestrator-dash/03-configurator-start.PNG#center” alt="Orchestrator”;>

I started this on both of my appliances (only 02 is screenshot) and manually changed my url in the browser to the appliance FQDN - and voila! I was presented with a WorkspaceOne login from VMware Identity Manager.

<img src=”/images/2018-04-12-accessing-html5-orchestrator-dash/04-vidm.PNG#center” alt="Orchestrator”;>

I logged in with the administrator@vsphere.local credentials I had setup, and was presented with the glorious HTML5 interface I had so longed for!

<img src=”/images/2018-04-12-accessing-html5-orchestrator-dash/05-logged-in.PNG#center” alt="Orchestrator”;>

But my load balancer was still hosed…

Extra Credit - Fixing my NSX Load Balancer

I had recently setup vRA in a new distributed configuration so I could demonstrate the improved automatic fail-over processes that have been added in recent revisions; so now I had 2 appliances behind a load balancer that I had setup. Being an avid NSX user - I configured NSX to load balancer my vRA environment (pro tip - use this guide, it'll perfectly outline setting up the load balancing for all services; except the Orchestrator ones…).

I manually went in, and created a new Application Profile for the configurator service. I stuck with using SSL Pass-through to just let the vRO appliances handle the certs on their own.

<img src=”/images/2018-04-12-accessing-html5-orchestrator-dash/06-app-profile.PNG#center” alt="NSX”;>

I created a simple monitor for the service port, specifically for the Control Center. Most of the Control Center URL's redirect you to a vIDM login page - which messes with what return codes I “wanted” to get (optimally a 200 “OK”). After digging around a bit, I found that the Swagger docs (vco-controlcenter/docs/) was unauthenticated. This was also confirmed when I stumbled upon the formal load balancing Orchestrator guide. The guide suggested to look for a return of the URL however I wasn't able to get that working correctly. I decided to just stick to my guns and look for a 200 response code as shown in the picture below. It's important to note that the trailing / on the end of docs was critical. I mistakenly didn't include that the first time and the monitors failed.

<img src=”/images/2018-04-12-accessing-html5-orchestrator-dash/07-monitor.PNG#center” alt="NSX Health Monitor”;>

Using Python you can easily debug what sort of response codes you are getting from URLs for testing; I did this quite a few times trying different URLs - an example is below.

<img src=”/images/2018-04-12-accessing-html5-orchestrator-dash/08-pythontest.PNG#center” alt="NSX Health Monitor”;>

Pools were fairly standard. The load balancing guide (once I found it…) suggested using IP Hash for the pool Algorithm. I created my 2 nodes and set their ports to the Control Center port and assigned the monitor we created in the previous step.

<img src=”/images/2018-04-12-accessing-html5-orchestrator-dash/09-pools.PNG#center” alt="NSX Health Monitor”;>

Finally, I created a new Virtual Server, using my existing FQDN's IP address. I wired up to port 8283, assigned my pool and hit OK!

<img src=”/images/2018-04-12-accessing-html5-orchestrator-dash/10-vipcreate.PNG#center” alt="NSX Create VIP”;>

With all of that in place, I was able to load up the browser and hit the Control Center and new Monitor dashboard as expected. Easy stuff!

In Closing…

I'll be the first to admit that the dashboard has a relatively low amount of features currently in it. It's great for monitoring the current status of Orchestrator in the environment; but it absolutely leaves you wanting a bit more. The existing Java interface for Orchestrator is clunky - and getting the taste of HTML5 gives you a glimpse of what COULD be.

It's important that we look at the problem the Dashboard is solving. In the Pre-7.4 world, the best way to check the status of Workflow runs was having to LOG INTO vRO. This meant you had to have Java installed on the machine you were working on, and it had to be actually functional (har har har). It's a heavyweight application to run just to be able to monitor whats happening with a workflow run. Having this in a simple to sign into HTML5 interface is a way more effective operating path.