I am frequently get asked “Should we deploy the vRealize Automation Identity Appliance or should we connect vRealize to the vCenter SSO server”? The answer to this really depends on what is important to you. There are pro’s and con’s both scenarios. Let’s look at the vRealize Identity appliance first.
vRealize Identity Appliance
The major benefit to running the vRealize Identiy appliance is that it is released as part of the vRealize Automation code stream. This is important because if new features are released in vRealize Automation that have dependencies on specific support from the SSO server the Identity Appliance will be updated with the needed support. This will allow you upgrade when a new version is released without having to worry about external dependencies.
The downside of running the vRealize Identity Appliance is the extra administrative overhead, especially of you are deploying an HA environment. It’s extra servers to support, backup, and maintain on top of the vRA Appliance, IaasS Server, and any deployed for DEM’s/Agents. Not a huge deal, but it’s something to consider.
Once your vCAC Application Services appliance is installed and configured, you must set up a Cloud Provider. A Cloud Provider is a system that will provide infrastructure services for the applications you will manage. In this case, we are using vCAC. At the same time, you can create Templates based on the vCAC Blueprints you’d like to consume.
Follow the steps below to create your Cloud Provider and Templates.
Choose a user account and add it to the Group Manager role in a vCAC Business Group with the privilege to deploy the Blueprint you would like to use as a base for your application installation.
Next login to the Application Services appliance, open the Applications menu in the upper right-hand corner, and navigate to Cloud Providers.
Click the green plus sign to add a new Cloud Provider.
Select the appropriate Cloud Provider Type, vCAC in this case.
Fill in the Name and Description for the Cloud Provider. The vCAC Cloud Provider Type also requires you to input the vCAC Infrastructure URL (the Windows machine, NOT the catalog appliance), as well as your chosen User Name and Password. Be sure to click Validate Connection after you’ve completed all required fields.
To add a Template, click the green plus sign next to the Templates heading in the lower section of the page.
Click the check box for the Blueprints you’d like to enable as Templates in Application Services, then click OK. You can also click the ellipsis to show more information about a Blueprint.
If you’d like, you can change the Name and/or Description of the Template(s). When you are finished, click Save.
This Cloud Provider and Template will now be available for Application deployments.
Now that we have installed and configured NSX I think it’s time we connected it to vCAC. In version 6.1 there are some changes to the integration with NSX and vCAC. When I say changes I should say there are some great new changes. The integration now utilizes a vCO Plug-in that handles all the interactions between NSX and vCAC.
Benefits of vCO plug-in for NSX to vCAC integration
The benefits of the vCO plug-in are huge. These workflows that now exist in vCO are there for you to use in your own customization giving you the ability to interact with NSX in a custom way without having to code against it’s api. Personally I await the day for all integrations to be this way.
As most of you know the vCAC appliance has vCO built in and the built in vCO server already has the NSX plug-in installed for. If you want to use an external vCO you will have to deploy the plug-in to that appliance before trying to connect vCAC to NSX.
vCO Endpoints are used by vCAC when vCAC needs to execute vCO workflows. These can be out of the box workflows such as the NSX workflows, or they can be workflows that you created and want vCAC to execute as part of a deployment state transitions such as during building machine, machine provisioned, machine destroyed or various other master workflow states. vCAC cannot execute these workflows without first having a vCO endpoint to which it can query and call to execute. vCAC can pass machine custom properties and other information through to vCO as part of the execution to parameterize the workflows.