PowerCLI has long since been a popular scripting tool for vSphere administrators. Throughout the years, we have built sizable libraries of scripts we depend on to automate various tasks. But attempting to share these scripts with other administrators -- or delegate the execution to other vSphere admins -- can present challenges. What if you were able to fuse PowerCLI with vCenter Orchestrator (vCO) for even more control over your virtual infrastructure?
This two-part series walks through the steps on how to make this streamlined administration happen. In part one, we explore the configuration of vCO and integrating it in vSphere Web Client. In part two here, we focus on the PowerShell plug-in and the creation of the workflow to execute our scripts.
PowerShell is an easy tool to use -- once you are familiar with it. Certain things such as passing parameters to the scripts or ensuring the proper modules are installed on the target machines can be a daunting task to those with little to no PowerShell experience.
Great power just a right-click away
Thankfully, vSphere administrators can execute these scripts without ever dropping into a PowerShell console. Utilizing vCO or the integration between vCO and vCenter Server, we can create workflows to execute scripts, which can be triggered directly from within the vSphere Web Client. And it doesn't stop there: We can then associate the vCO workflows to be available on specific vSphere inventory objects. For example, say we had a script that accepts a host parameter and performs different tasks dealing with the host. Instead of passing a host name to it, we can execute this script through a vCO workflow by right-clicking on a target host within the Web Client. It is certainly a much easier and more efficient way of getting the same results.
There are two steps to integrating vCO and vCenter.
1. Configure single sign-on
The first step to integrate vCO and vCenter is to configure vCO to allow it to authenticate with single sign-on (SSO). This permits vCO and vCenter to obtain tokens from the SSO instance, which allows them to communicate with each other securely.
To start, we need to import a couple of SSL certificates; one located on the vCenter Server and the other located on the SSO instance. Navigate to the SSL Trust Manager tab of the Networking section inside of the vCO configuration page using your vCO IP address on port 8283.
Import the standard Web services certificate from vCenter by populating the URL box with the fully qualified domain name (FQDN) of vCenter on port 443. Click Import to retrieve and display the certificate. Click Import again to install the certificate in vCO -- that takes care of vCenter.
The same process needs to be completed for SSO by again populating the URL box, but this time with the SSO address using the FQDN of the SSO instance on port 7444, following the same import steps.
With the certificates imported, configure vCO to authenticate with the SSO instance. Click on the Authentication menu. VCO uses a local instance of OpenLDAP to provide authentication by default. We can change this to SSO by selecting SSO Authentication from the Authentication mode drop-down box. Then specify the SSO instance in the Host box and provide the administrator credentials of the default domain that was created when SSO was installed. In 5.1 this domain was "system-domain" but has been since changed to "vsphere.local" in 5.5.
After clicking Register Orchestrator we can define the vCO admin group. The chosen group will define who has rights to perform administrative functions inside vCO, not who has rights to authenticate and create workflows. Select a group and click Accept Orchestrator Configuration.
Now the SSO authentication can be tested. Enter some credentials in the Test Login tab. We should be able to authenticate through this manner using any user credentials that have access to the vCenter Server.
2. Register vCO with vCenter
The second and final step to integrate vCO with vCenter is to configure the vCenter Server plug-in by adding a new vCenter Server host. When doing so, vCO will contact vCenter to register and configure itself as a vCenter Server extension.
Start on the New vCenter Server Host tab after selecting vCenter Server from the left navigation menu. This requires the FQDN of your vCenter Server along with some connection credentials that have the right to install extensions. The only setting we normally modify here deals with how vCO manages user access on the vCenter Server.
Sharing a unique session allows vCO to create only one connection to the vCenter Server using the provided credentials. Session per user creates a new connection to vCenter for all users who log into vCO, using their currently logged-on credentials. Either setting will work, but there are pros and cons to both. Sharing a unique session uses fewer resources on both your vCO and vCenter servers, but session per user provides a more secure connection.
Choose the option that works best in your environment. After completing this step and restarting the vCO server service through Startup Options, vCO will now be registered as an extension inside of vCenter.
vCO and vCenter as one
Open the vSphere Web Client and look at the integration of vCO. By selecting vCenter Orchestrator from the home screen in the Web Client, then selecting Workflows we can view all the default workflows that are shipped with vCO. There are a quite a few, all performing different functions such as removing snapshots to the configuration of a vSwitch. From here, we can right-click and execute these workflows immediately or schedule them to run at a different time.
This integration of vCO with vCenter inside of the vSphere Web Client gives access to execute the default workflows that are shipped with vCO. There will always be those complex scenarios that we have solved by writing PowerCLI scripts that can't be duplicated in a workflow.
In the second part of this series, we will install and configure the PowerShell plug-in and demonstrate how to build vCO workflows to execute and pass parameters to a PowerCLI script. I'll also explain how to associate these workflows with an inventory object to enable a sysadmins to run workflows with nothing more than a right-click.