VMware Hands-on Labs - HOL-2121-04-CMP


Lab Overview - HOL-2121-04-CMP - Administering vRealize Automation - Advanced Use Cases

Lab Guidance


Note: It may take more than 90 minutes to complete this lab. You should expect to only finish 2-3 of the modules during your time.  The modules are independent of each other so you can start at the beginning of any module and proceed from there. You can use the Table of Contents to access any module of your choosing.

The Table of Contents can be accessed in the upper right-hand corner of the Lab Manual.

The intended audience for this lab is a vRealize Automation administrator. The lab covers advanced administration tasks.

This lab covers several advanced topics in administering vRealize Automation. They include: Managing VMware NSX networking constructs in blueprints; advanced blueprint topics such as inputs, expressions and using cloud-init; integration with Infoblox IP address management; extensibility using vRealize Orchestrator and Action-Based Extensibility (ABX); custom day 2 actions; integration with third-party configuration management tools; creating custom resources; and integration with ServiceNow IT Service Management.

There are other vRealize Automation Hands On Labs that cover topics basic vRealize Automation administration tasks as well as labs applicable to end users, developers and DevOps engineers. All vRealize Automation Hands on Lab SKUs begin with "HOL-2121". You can search the Hands On Labs catalog for more information.

Lab Module List:

 Lab Captains: 

 

This lab manual can be downloaded from the Hands-on Labs Document site found here:

http://docs.hol.vmware.com

This lab may be available in other languages.  To set your language preference and have a localized manual deployed with your lab, you may utilize this document to help guide you through the process:

http://docs.hol.vmware.com/announcements/nee-default-language.pdf


 

Location of the Main Console

 

  1. The area in the RED box contains the Main Console.  The Lab Manual is on the tab to the Right of the Main Console.
  2. A particular lab may have additional consoles found on separate tabs in the upper left. You will be directed to open another specific console if needed.
  3. Your lab starts with 90 minutes on the timer.  The lab can not be saved.  All your work must be done during the lab session.  But you can click the EXTEND to increase your time.  If you are at a VMware event, you can extend your lab time twice, for up to 30 minutes.  Each click gives you an additional 15 minutes.  Outside of VMware events, you can extend your lab time up to 9 hours and 30 minutes. Each click gives you an additional hour.

 

 

Do Not Enable The Intercept Paste Feature

 

The lab interface environment has the option of intercepting your paste keyboard shortcut (ctrl-v on Windows, command-v on Mac) to paste from your desktop environment into the lab console. This is not recommend for the lab because you will be copying and pasting within the lab console and enabling this feature will make that impossible.

When you first attempt to use your paste keyboard shortcut within a lab session, you will be prompted to enable the intercept feature. If you are prompted, be sure to:

  1. Click CANCEL

 

 

To Disable Paste Intercept

 

If you do find when copying text in the lab console and attempting to paste it that you are either not getting any text pasted or the text is coming from the host computer where you are accessing the lab, you will need to turn off the Intercept Paste feature.

  1. Click the gear icon at the top-right corner of the interface above the docked manual  

 

  1. Uncheck the Intercept Paste box

 

 

Alternate Methods of Keyboard Data Entry

During this module, you will input text into the Main Console. Besides directly typing it in, there are two very helpful methods of entering data which make it easier to enter complex data.

 

 

Click and Drag Lab Manual Content Into Console Active Window

You can also click and drag text and Command Line Interface (CLI) commands directly from the Lab Manual into the active window in the Main Console.  

 

 

Accessing the Online International Keyboard

 

You can also use the Online International Keyboard found in the Main Console.

  1. Click on the Keyboard Icon found on the Windows Quick Launch Task Bar.

 

 

Click once in active console window

 

In this example, you will use the Online Keyboard to enter the "@" sign used in email addresses. The "@" sign is Shift-2 on US keyboard layouts.

  1. Click once in the active console window.
  2. Click on the Shift key.

 

 

Click on the @ key

 

  1. Click on the "@ key".

Notice the @ sign entered in the active console window.

 

 

Activation Prompt or Watermark

 

When you first start your lab, you may notice a watermark on the desktop indicating that Windows is not activated.  

One of the major benefits of virtualization is that virtual machines can be moved and run on any platform.  The Hands-on Labs utilizes this benefit and we are able to run the labs out of multiple datacenters.  However, these datacenters may not have identical processors, which triggers a Microsoft activation check through the Internet.

Rest assured, VMware and the Hands-on Labs are in full compliance with Microsoft licensing requirements.  The lab that you are using is a self-contained pod and does not have full access to the Internet, which is required for Windows to verify the activation.  Without full access to the Internet, this automated process fails and you see this watermark.

This cosmetic issue has no effect on your lab.  

 

 

Look at the lower right portion of the screen

 

Please check to see that your lab is finished all the startup routines and is ready for you to start. If you see anything other than "Ready", please wait a few minutes.  If after 5 minutes your lab has not changed to "Ready", please ask for assistance.

 

Module 1 - Blueprinting and Managing VMware NSX Networking with vRealize Automation (45 minutes)

Introduction


In this module, we will explore vRealize Automation and NSX-T integration.  Once NSX-T configured as a Cloud Account, Cloud Assembly blueprints can leverage existing NSX network constructs as well as creating new network and security objects on demand. 


 

Leveraging NSX-T in Cloud Assembly

 

In addition to leveraging existing NSX objects in Cloud Assembly alongside vSphere Distributed Switch port groups, integrating vRealize Automation and NSX-T allows for 2 other use cases:

  1. Administrators can create blueprints to deploy and manage network objects, also known as Provider Infrastructure as Code.  These objects can be consumed by other blueprints as existing network resources.
  2. Blueprint consumers can deploy NSX-T resources on demand in deployments, providing deployment-specific networking and security.

In this module, we will configure NSX-T as a Cloud Account and then explore both use cases.

 

Open Chrome Browser


Open Chrome Browser


 

Open Chrome Browser from Windows Quick Launch Task Bar

 

  1. Click on the Chrome Icon on the Windows Quick Launch Task Bar.

 

Logging in to vRealize Automation (HOLadmin)


In this lesson we will start by logging into vRealize Automation.


 

Launch vRealize Automation

 

From within the Chrome web browser:

  1. Click vRealize Automation from the bookmarks bar.

 

 

Log in to vRealize Automation

 

At the Workspace ONE login screen:

  1. Enter holadmin into the username field.
  2. Enter VMware1! into the password field.
  3. Click Sign In.

 

Launch the Cloud Assembly Service



 

Launch the Cloud Assembly Service

 

From within the Cloud Services Console, under My Services:

  1. Click the Cloud Assembly service.

 

Configuring vRealize Automation to Use NSX-T


Before we can use NSX-T objects in vRealize Automation blueprints, we must configure integration between vRealize Automation and NSX-T.  In this lesson, we will configure Cloud Assembly to leverage NSX-T, and set behavior for using NSX-T on-demand networking in blueprints.


 

Navigate to Infrastructure Tab

 

  1. Click on the Infrastructure tab.

 

 

Add New Cloud Account

 

The first step in configuring NSX-T integration with vRealize Automation is to create an NSX-T Cloud Account, and associate it with the existing vCenter Cloud Account.

  1. Click + ADD CLOUD ACCOUNT

 

 

Specify NSX-T Cloud Account Type

 

  1. Click NSX-T to specify this cloud account as an NSX-T cloud account type.

 

 

Configure New Cloud Account

 

  1. Enter NSX-T for the name of this cloud account
  2. For the NSX-T IP address / FQDN, enter nsx-mgr.corp.local
  3. For the Username field, enter admin.
  4. For the Password field, enter VMware1!VMware1!

 

 

Configure New Cloud Account (Continued)

 

  1. Click the VALIDATE button to validate the connection to NSX-T (Note: during the validation process, a prompt will appear with the NSX Manager certificate.  Click ACCEPT to accept this certificate and complete the validation.)
  2. Click the vSphere endpoint field and select Private Cloud from the list (note that this field will only appear after the NSX-T credentials have been validated successfully.)
  3. Click ADD to create this cloud account

 

 

View Existing NSX-T Networks

 

With the NSX-T cloud account created, NSX-T networks will begin to appear within vRealize Automation.  While these networks can be used as existing networks within vRealize Automation blueprints, we will add some additional configuration allowing for on-demand networking to be used as well.

  1. Click Networks to open the list of available networks
  2. Click on the filter text box, and enter nsx and press Enter to filter the list of available networks
  3. Click on the hol-ondemand network to open the network settings

 

 

Configure NSX-T Network

 

  1. For Domain, enter corp.local
  2. For the IPv4 CIDR, enter 172.16.12.0/24
  3. For the IPv4 default gateway, enter 172.16.12.1
  4. Scroll down and click SAVE (not shown) to save this configuration for the NSX-T hol-ondemand network

 

 

View Network Profiles

 

  1. Click Network Profiles to view the existing network profiles
  2. Click OPEN to open the vSphere Networks network profile

In this lesson we will configure an existing network profile for NSX-T on-demand networking.  In a later lesson, we will demonstrate creating a new network profile.

 

 

Add NSX-T Network to Network Profile

 

  1. Click the Networks tab to show the list of available networks.  Currently, only an existing dvSwitch port group is listed.
  2. Click + ADD NETWORK to add an additional network to this profile

 

 

Add NSX-T Network to Network Profile (Continued)

 

  1. Note that available NSX networks are listed by default
  2. Click the checkbox next to hol-ondemand to select it
  3. Click OK to add this network to the profile

 

 

Add a Managed IP Range to NSX-T Network

 

With the NSX-T network added to the vSphere Networks network profile, we will next configure an IP range for vRealize Automation to use.

  1. Click the checkbox next to hol-ondemand to select it and enable the buttons above the list
  2. Click MANAGE IP RANGES

 

 

Add a Managed IP Range to NSX-T Network (Continued)

 

  1. Click + NEW IP RANGE to specify a new range of IP addresses for this network

 

 

Add a Managed IP Range to NSX-T Network (Continued)

 

  1. For Name, enter NSX
  2. For Start IP address, enter 172.16.12.90
  3. For End IP address, enter 172.16.12.99
  4. Click ADD to save this IP range
  5. Click CLOSE to close the Managed IP Ranges window (not shown)

vRealize Automation will use this range to manage IP addresses for machines deployed to this existing NSX-T network.  But what if we want to create NSX-T networks on demand within vRealize Automation blueprints, rather than using existing networking?

 

 

Configure Network Policies

 

The Network Policies tab within the network profile configuration allows for settings to be used for on-demand networking, or on-demand security group creation.  By default, on-demand network policy settings are not configured in a network profile.

  1. Click the Network Policies tab
  2. Note the default Isolation policy setting

 

 

Configure On-Demand Network Policy

 

  1. Change the Isolation policy to Create an on-demand network (this will also update the list of available fields in the Network Resources section)
  2. Click on the Transport Zone field and select TZ-HOL-Overlay from the list
  3. Click on the External network field and select hol-ondemand from the list
  4. Click on the Tier-0 logical router field and select hol-gw
  5. Click on the Edge cluster field and select hol-edge-cluster
  6. Scroll down to view the IP Address Management section (not shown)

Note that the transport zone, external network, tier-0 logical router, and edge cluster are existing constructs already created and configured within NSX-T in this environment.  vRealize Automation will use create new NSX-T configuration using these constructs when a deployment requires on-demand networking.

 

 

 

Configure On-Demand Network Policy (Updated)

 

  1. For CIDR, enter 172.90.2.0/24
  2. Click on the Subnet size field, and select /28 (~14 IP addresses) from the list

In a previous step, we specified a managed IP range for the existing NSX-T network.  In the Network Policy configuration, we are specifying a CIDR of networks to use dynamically when a deployment of a blueprint using on-demand networking is created.  In this example, for each deployment vRealize Automation will create a new /28 subnet within NSX-T.  IPs within this subnet can be statically assigned, assigned via DHCP, or a combination, in which case a portion of the subnet will be reserved for the DHCP scope.

  1. Click SAVE to save and close the network profile

We have now configured vRealize Automation to use NSX-T networking.  NSX-T networks can be consumed as existing networks, just as with vSphere Distributed Switch port groups.  But vRealize Automation can also manage NSX-T networking dynamically.  In the next lesson, we will review and deploy from a blueprint using NSX-T on-demand networking.

 

Using NSX-T On-Demand Networking in Cloud Assembly Blueprints


Now that vRealize Automation has been integrated with NSX-T, both existing NSX networking and on-demand NSX networking can be used in blueprints.  In this section, we will review a blueprint using NSX-T on-demand networking, and create a deployment from it.


 

Open NSX-T On-Demand Networking Blueprint

 

  1. Click Design to navigate to the list of available blueprints
  2. A configured blueprint has already been provided.  Click on the NSX-T On-Demand Networking blueprint to open it in the blueprint designer

 

 

View Blueprint

 

  1. Note the available NSX constructs in the list of resources
  2. This blueprint deploys a single vSphere machine connected to an NSX Network object
  3. In the YAML section, click in front of the word routed in line 15 to view the list of available network types

A networkType of existing or public will use existing NSX-T network configuration.  The other three types (private, outbound, and routed) will crate new NSX-T constructs during deployment.

 

 

NSX-T On-Demand Network Types

 

This image shows the on-demand network types, and the NSX-T constructs created when each type is used within a vRealize Automation blueprint.

 

 

View vCenter Networking

 

Before we create a deployment from this blueprint, we will view the existing vCenter and NSX-T settings.

  1. Click the + to open a new browser tab
  2. Click the vSphere Client bookmark to connect to vCenter

 

 

Log In to vCenter

 

The vCenter credentials are already cached, but the Login button is greyed out by default.

  1. Click anywhere in the window to enable the Login button
  2. Click LOGIN to log in to vCenter

 

 

View vCenter Network Settings

 

  1. Click the Networking icon to view the network configuration
  2. Click the down arrow next to RegionA01 to expand the list of network objects

Note the existence of the hol-ondemand network object.  This is currently the only NSX-T network available.

 

 

View NSX-T Settings

 

  1. Click the + to open a new browser tab
  2. Click the NSX Manager bookmark to connect to NSX Manager

 

 

Log In to NSX Manager

 

  1. Click LOG IN to log in using the cached credentials

 

 

View NSX-T Networks

 

  1. Click Advanced Networking & Security to view the available logical switches.  This list includes the existing hol-ondemand network, as we saw in vCenter.  When we create a deployment of the NSX-T On-Demand Networking blueprint, additional NSX-T objects will be created here.

 

 

Return to vRealize Automation

 

With the existing networking configuration verified, we will return to Cloud Assembly and create a deployment of the blueprint.

  1. Click on the Cloud Assembly browser tab to return to Cloud Assembly

(Note:  if you are logged out of vRealize Automation, click the vRealize Automation bookmark to return to the login screen, sign in again, and return to the NSX-T On-Demand Networking blueprint in the Design section.)

 

 

Create a Deployment

 

  1. Click DEPLOY to start the deployment process

 

 

Create a Deployment (Continued)

 

  1. For Deployment Name, enter NSX-T On-Demand Networking
  2. Click on the Blueprint Version field and select Current Draft
  3. Click DEPLOY to create the deployment

 

 

View Deployment In Progress

 

The deployment will take three to five minutes to complete.  As the deployment progresses, the NSX network and the vSphere machine objects will appear on the canvas.

 

 

View Deployed Machine Address

 

Once the deployment is complete, we can validate that the vSphere machine has been assigned an address in an on-demand network.

  1. Click on the Cloud_vSphere_Machine_1 object to select it
  2. Note the Address of this machine (this IP may vary from the screenshot)

 

 

View vCenter Networking

 

  1. Click the vSphere browser tab to return to the vSphere Client
  2. Click the Cloud_NSX_Network entry to view more information on it.  Note that this network was not present previously - it was created during the deployment process.

 

 

View NSX-T Networking

 

  1. Click the NSX browser tab to return to NSX Manager
  2. Click the Cloud_NSX_Network entry to view more information on it

Note: It's possible that the networks do not appear initially.  If that happens, click the Refresh Button (not shown) at the botom of the network list pane.

 

 

View NSX-T Networking (Continued)

 

  1. Note the Description of Managed by Cloud Assembly, as well as the Created and Last Updated times
  2. Click the X to the right of the Cloud_NSX_Network detail (not shown) to close the section and return to the list of logical switches

 

 

Delete Deployment

 

  1. Click the Cloud Assembly browser tab to return to Cloud Assembly
  2. Click Actions to open the menu
  3. Click Delete to delete this deployment
  4. Click SUBMIT to confirm the deployment deletion (not shown)

The delete process will take three to five minutes to complete.  Once it is done, feel free to return to the vSphere and NSX browser tabs to view that the on-demand networking has been removed as well (note that if the NSX-T network is still listed, then click REFRESH at the bottom of the window to update the list.)

 

Using Provider Blueprints to Manage NSX Resources in Cloud Assembly


In previous lessons, we've seen how vRealize Automation can leverage NSX-T to dynamically provision networking configuration in new deployments.  But vRealize Automation can also separately provision NSX-T constructs that can be consumed by other blueprints within vRealize Automation as existing resources.

In this lesson, we will deploy a provider NSX-T load balancer as part of a blueprint, and then add it to vRealize Automation as an existing resource.  We will then modify another blueprint to add an NSX-T load balancer, and show how vRealize Automation will use the provider load balancer in the updated blueprint.


 

Open Provider Load Balancer Blueprint

 

  1. Click Design to navigate to the Blueprints section
  2. Click on the Provider Network and Load Balancer blueprint to open it in the designer

 

 

View Provider Load Balancer Blueprint

 

This blueprint deploys an NSX-T subnet, as with the previous lesson.  But it also deploys an NSX-T load balancer with no instances attached.  As with other vRealize Automation blueprints, deployments of this network and load balancer can be created an updated.

  1. Click DEPLOY to begin the deployment process

 

 

Deploy Provider Load Balancer

 

  1. For Deployment Name, enter NSX-T Provider Load Balancer
  2. Click on the Blueprint Version field, and select Current Draft
  3. Click DEPLOY

 

 

View Deployment In Progress

 

As the deployment progresses, the network and load balancer objects will appear in the topology.  This deployment will complete more quickly than the previous lesson.

 

 

View Deployed Load Balancer Information

 

When the deployment completes, we can view the configuration of the created load balancer.

  1. Click on the Cloud_NSX_Load_Balancer_1 object to select it
  2. Note the Resource name and Address of the load balancer

Note:  while the load balancer is available to be used, the associated configuration within NSX is not yet created because no VMs are assigned to this load balancer yet.

 

 

Navigate to Network Profiles

 

Now that the provider load balancer has been deployed, it is available to be used by vRealize Automation as an existing object.  In order to simplify using this load balancer in blueprints, we will create a new network profile that includes this load balancer specifically.

  1. Click the Infrastructure tab
  2. Click Network Profiles
  3. Click + NEW NETWORK PROFILE to create a new network profile for this lesson

 

 

Create a New Network Profile

 

  1. Click on the Account / region field, and select Private Cloud / RegionA01
  2. For Name, enter NSX
  3. Click on the Capability tags field, and type net:provider and press Enter.  This will assign a new capability tag to this network profile, allowing any blueprints that use this tag as a constraint to use this network profile specifically.
  4. Click the Networks tab to proceed

 

 

Add NSX-T Network to Network Profile

 

  1. Click the + ADD NETWORKS button (not shown) to open the Add Network window
  2. Click the checkbox next to the network with the name starting with Cloud_NSX_Network
  3. Click OK to add the network

 

 

Navigate to Load Balancers Tab

 

  1. Click the Load Balancers tab to proceed

 

 

Add Load Balancer

 

  1. Click the + ADD LOAD BALANCER button (not shown) to open the Add Load Balancer window
  2. Click the checkbox next to the listed Cloud_NSX_LoadBalancer object - this is the object we deployed earlier in the lesson
  3. Click OK to add the load balancer to the network profile

 

 

Create Network Profile

 

  1. Click CREATE to complete the network profile creation

 

 

Navigate to Blueprints

 

  1. Click the Design tab.  This will return us to the opened Provider Network and Load Balancer blueprint
  2. Click CLOSE to return to the blueprint list

 

 

Open NSX-T Networking Blueprint

 

  1. Click on the NSX-T Networking blueprint to open it

 

 

Update networkType

 

  1. Double-click the value of routed for the networkType property in this blueprint.  This will open the menu of available networkType property values.
  2. Select existing from the list to update this value

 

 

Add Constraint to Network

 

  1. After updating the networkType value, press Enter to create a new line
  2. In the resulting list of properties that appears, select constraints:

 

 

Specify Constraint Tag

 

  1. After selecting constraints:, press Enter to create a new line and select - tag: from the resulting list (not shown)
  2. After selecting tag, a new list of available constraint tags will appear.  Select net:provider from the list

Specifying the net:provider tag as a constraint for this blueprint will cause vRealize Automation to apply settings from the network profile created earlier to all deployments of this blueprint.  In this way, users can easily consume the NSX-T provider resources in their individual blueprints.

 

 

Add Load Balancer

 

  1. Click on the Load Balancer item in the NSX section of the list of available resources, and drag it onto the canvas to add it
  2. Hover over the left side of the added Cloud_NSX_LoadBalancer_1 object until a small circle appears.  Click on the circle and drag it into the Cloud_NSX_Network_1 object to attach the load balancer to the network.  (Note that the circle may be difficult to see in the lab environment; once the process has been completed successfully, a line will be added from the load balancer to the network as shown in the screenshot.)

 

 

Add VM to Load Balancer

 

  1. Similar to the previous step, hover over the left side of the Cloud_vSphere_Machine_1 object until a small circle appears.  Click on the circle and drag it into the Cloud_NSX_LoadBalancer_1 object.

When the process has been completed successfully, a branching line similar to the screenshot above will appear between the load balancer and the VM on the canvas.

 

 

Increase VM Count

 

  1. Click on the end of the totalMemoryMB line and press Enter to create a new line.  This will also open up the list of additional properties to add to this object.
  2. Select count: from the list
  3. Enter 2 to increase the number of VMs deployed by this blueprint (not shown)

 

 

View Completed Blueprint

 

The completed blueprint will look similar to the screenshot above.

 

 

Test Blueprint

 

Rather than deploying this blueprint, we will use Cloud Assembly's test functionality to show the provisioning process that will be used for this blueprint.

  1. Click TEST to open the test window.  The test will take a few seconds to complete.

 

 

View Test Results

 

With the test complete, we can view the provisioning diagram to see which infrastructure resources vRealize Automation will use when deploying from this blueprint.

  1. Click Provisioning Diagram

 

 

View Network Allocation in Provisioning Diagram

 

The provisioning diagram for this blueprint shows the decision process for the network, the vSphere machine, and the load balancer.

  1. Click the scrollbar to scroll down in the Network Allocation pane
  2. Note the decision tree for choosing from the available network profiles.  The vSphere Networks profile does not meet the criteria for this blueprint, because it does not have the net:provider tag assigned.  Thus, the NSX network profile is selected for use.
  3. Click Load Balancer Allocation and select Cloud_NSX_LoadBalancer_1 from the list (not shown) to view the allocation process for the load balancer

 

 

View Load Balancer Allocation in Provisioning Diagram

 

  1. Note the selected load balancer object to be used by deployments of this blueprint - this is the load balancer we deployed early in this lesson as a provider load balancer.
  2. Click CLOSE to close the provisioning diagram

 

Conclusion


In this module, we configured vRealize Automation and NSX-T integration, and demonstrated both on-demand networking in blueprints and provider infrastructure as code.  Virtual networking allows for greater flexibility in Cloud Assembly blueprints, and the ability to manage the lifecycle of network objects as code.


 

You've finished the module

 

Congratulations on completing the lab module.

If you are looking for additional information, see:

From here you can:

  1. Click to advance to the next page and continue with the next lab module
  2. Open the TABLE OF CONTENTS to jump to any module or lesson in this lab manual
  3. Click on the END button if you are done with the lab for now and want to exit

 

 

Module 2 - Advanced Blueprinting (45 minutes)

Introduction


In this module, we will review additional options for further enhancing Cloud Assembly blueprints.  While previous labs have shown how properties like constraint tags can be used to leverage infrastructure resources, more advanced functionality allows for configuration based on request time input, expressions to dynamically generate property values, and additional customization of both Windows and Linux machines following deployment.


Logging in to vRealize Automation (HOLadmin)


In this lesson we will start by logging into vRealize Automation.


 

Launch vRealize Automation

 

From within the Chrome web browser:

  1. Click vRealize Automation from the bookmarks bar.

 

 

Log in to vRealize Automation

 

At the Workspace ONE login screen:

  1. Enter holadmin into the username field.
  2. Enter VMware1! into the password field.
  3. Click Sign In.

 

Launch the Cloud Assembly Service


Use this for launching the cloud assembly service in your modules


 

Launch the Cloud Assembly Service

 

From within the Cloud Services Console, under My Services:

  1. Click the Cloud Assembly service.

 

Working with Inputs and Expressions


Cloud Assembly blueprints can be enhanced in multiple ways.  In this lesson, we will explore using inputs and expressions to add more functionality to a blueprint.


 

Navigate to Blueprints

 

  1. Click the Design tab

 

 

Open Blueprint With Comments

 

  1. Click on the Blueprint with Comments blueprint to open it

 

 

View Blueprint Comments

 

  1. Note that this blueprint will create 1 vSphere Machine object attached to a vSphere network.
  2. The Code section of this blueprint includes several comments (the lines that begin with #.)  The links included at the top of the blueprint will be available at the module's conclusion for further viewing as well.

 

 

Adjust Browser Zoom (Optional)

 

Note that, by default, the browser zoom is set to 80% in this lab environment.  For this lesson it may be difficult to read and update the blueprint parameters.  If necessary, you can decrease the browser zoom.

  1. Click the 3 vertical dots in the upper right corner of the browser
  2. Click the + next to Zoom to adjust the zoom level and make the text larger

 

 

View Existing Blueprint Inputs

 

This blueprint includes 2 inputs.  At deployment time, the requestor will be prompted for these inputs after entering the initial deployment information.

Each of the existing inputs is a freeform string.  Together, the inputs prompt the requestor to enter a new username and a password.  Each input also includes a default value (the "default: " parameter,) and a brief description.  

Later in the blueprint, these inputs will be used to add a new user to the vSphere machine.  We will cover the input assignment and machine configuration later in this lesson, but for now, we will add additional parameters to these inputs.

  1. Click on the end of the line with default: testUser (line 27,) and press Enter

 

 

Add Pattern to Username Input

 

Pressing Enter in the previous step creates a new line, and opens a menu of additional input parameters.  

  1. Select pattern: from the list (not shown)
  2. Enter the following for the value for pattern:  '[a-zA-Z]+' and press Enter

Note the single quotes ' in the value, and the characters between the square brackets.  By using the pattern parameter for this input, we are specifying that the input itself can only contain lowercase or uppercase alphabetical characters (a-z, or A-Z,) and the + at the end of the pattern means 1 or more characters.

 

 

Add Minimum String Length to Username Input

 

Pressing Enter in the previous step creates a new line 29.

  1. Select minLength: from the list (not shown)
  2. Enter 4 for the value, and press Enter

 

 

Add Maximum String Length to Username Input

 

  1. Select maxLength: from the list (not shown)
  2. Enter 8 for the value, and press Enter

Modifications for the username input are now complete.  This input:

Next, we will add parameters to the password input.

 

 

View Password Parameter

 

The password input is similar to the username input - it accepts a string, and has a default value of VMware1!.  One additional parameter for this input is "encrypted: true" - since this input will be used as a password, the input will be masked by asterisks at request time, and it will be encrypted.

  1. Click on the end of the line with "description: " (line 36,) and press Enter

 

 

Add Pattern to Password Parameter

 

  1. Select pattern: from the list (not shown)
  2. For the pattern value, enter '[a-zA-Z0-9#@!$]+' and press Enter

 

 

Add Minimum Length to Password Parameter

 

  1. Select minLength: from the list (not shown)
  2. For the minimum length, enter 6

The password input now must contain at least 6 characters.  These characters can be any lowercase letter, any uppercase letter, or the following symbols: #, @, !, and $.

 

 

Create a New Input

 

  1. Press Enter to create a new line, and press backspace to shift the cursor back (the cursor on the new line 39 should align with the username and password input entries above.)
  2. Type clustersize: to create a new input with this name

Note: if a red validation error appears on the new line as shown in the screenshot, disregard it for now.  This is an indication that the input is missing required information, and it will clear as this information is entered.

 

 

Set Input Type

 

  1. Press Enter to create a new line 40, and press tab to indent the new line since the cursor will initially align with the entry on line 39.
  2. Enter type: string to set the type for this input (or choose type: and then string from the menus, which will appear shortly after using tab to indent the line)

 

 

Add Title and Description to Input

 

  1. Press Enter to create a new line 41, and select title: from the list.  Enter Cluster Size for the value.  Press Enter again to create a new line 42, select description from the list, and enter Standalone or Highly Available for the value.

The first three parameters created for this input are similar to the parameters for the username and password inputs.  Next, we will use a new parameter.

  1. Press Enter once again to create a new line 43, and select enum: from the list

 

 

Add Enumerated List to Input

 

  1. After selecting enum: from the list, press Enter to create a new line 44.  Press tab, and type - Standalone for one value.  Press Enter again, and type - Highly Available for a second value.  Note: make sure to include the dashes in both lines, as well as a single space after each dash!  The result should look like the screenshot above.

With this step, the inputs are complete.  This blueprint takes 3 inputs:

Next, we will apply these input values in the blueprint.

 

 

Using Expressions in Blueprints

 

The inputs reviewed and defined in previous steps will be used in the resources section of the blueprint.  In order to use input values in a blueprint, we will pass them using expressions.  However, passing input values is not the only use of expressions in Cloud Assembly.  In fact, expressions can be used for many things, such as:

This blueprint already uses some expressions in the resources section (it may be necessary to scroll down to see both expressions):

  1. In line 56, the expressions ${input.username} and ${input.password} return the values of the username and password inputs, respectively.
  2. In line 70, the expression ${resource.Cloud_vSphere_Network_1.id} refers to the vSphere Network object in the blueprint.  This expression is automatically added to an object when it is attached to a network, as seen in previous labs using drag and drop.

 

 

Add New Property to vSphere Machine

 

  1. Click on the end of line 51, and press Enter
  2. Select count: from the list once it appears

We will set the count property value based on the Cluster Size input.  Note that the count property expects an integer, but for readability and simplicity, we created the Cluster Size parameter with 2 potential string values: "Standalone," or "Highly Available."  Using expressions, we can convert the human readable strings into integers in the blueprint itself.

 

 

Set Value for Count Property

 

  1. To set the value of the count property, type '${input.clustersize == "Standalone" ? 1 : 2}' (note: you can select the expression from the manual and drag it onto the lab console window to copy and paste.  If you do type the expression, the input and clustersize parameters will autocomplete.)

This expression uses a single-line conditional statement to set a value for the count property based on the value of the Cluster Size input.  If the requestor chooses Standalone for Cluster Size, count will be set to 1 and 1 vSphere Machine will be deployed.  If the requestor chooses Highly Available for Cluster Size, then count will bet set to 2 and 2 vSphere Machines will be deployed.

 

 

View Arithmetic Expression

 

  1. The expression on line 68 uses arithmetic operators to combine several strings, as well as a parameter, into one string used in a command.  Note that single quotes, double quotes, and backslashes must be escaped with a backslash as well (so " would be \" if needed.)
  2. Note that it may be necessary to scroll right to view the entire expression

The result of this expression is:

This command will add a custom Message of the Day (motd) to all logins to the deployed vSphere machines.

 

 

Functions in Expressions

Functions can also be used in Cloud Assembly expression.  Examples include:

For more information on using expressions in Cloud Assembly, see the following examples:

 

 

Close the Blueprint

 

  1. Click CLOSE to return to the blueprint list

 

Using Cloud-Init in vRealize Automation Blueprints


In the previous lesson, we reviewed using inputs and expressions in Cloud Assembly blueprints.  In this lesson, we will explore another method to enhance blueprints - cloud-init.


 

Deploy Blueprint With Comments

 

Cloud-init can be used to customize Linux machines.  For Windows machines, cloudbase-init is used.  In this environment, the Ubuntu18 template and the Windows2019 template have been prepared with cloud-init and cloudbase-init, respectively.  We will review each blueprint, but first, we will create a deployment of each.

  1. Click the checkbox next to Blueprint with Comments
  2. Click DEPLOY

 

 

Enter Deployment Information

 

  1. For Deployment Name, enter Linux cloud-init
  2. Click on the Blueprint Version field, and select Current Draft
  3. Click NEXT

 

 

Enter Deployment Inputs

 

  1. Click on the Cluster Size field, and select Standalone

Note: you can change the Username and/or Password fields if you prefer.  Remember these values for later if they are changed.

  1. Click DEPLOY

 

 

Return to Blueprints

 

The deployment will begin and complete after 3-5 minutes.  While it is in progress, we will deploy another blueprint.

  1. Click the Design tab

 

 

Deploy Windows with cloudbase-init Blueprint

 

  1. Click the checkbox next to Windows with cloudbase-init
  2. Click DEPLOY

 

 

Enter Deployment Information

 

  1. For Deployment Name, enter Windows cloudbase-init
  2. For Blueprint Version, enter Current Draft
  3. Click DEPLOY

 

 

View Blueprint With Comments

 

While the deployments proceed, we will examine each blueprint to discuss the customizations each one performs.

  1. Click the Design tab to return to the blueprints list (not shown)
  2. Click on Blueprint with Comments

 

 

View cloudConfig Section

 

  1. Lines 53-68 of this blueprint represent the customizations that will run on this vSphere Machine object once it is deployed.  This specific section:
  1. Click CLOSE (not shown) to close this blueprint and return to the list

 

 

View Windows with cloudbase-init Blueprint

 

  1. Click on Windows with cloudbase-init

 

 

View cloudConfig Section

 

  1. Lines 15-18 represent the customization that will run on this machine once it is deployed.  This specific section enables the Web-Server feature for the Windows machine.
  2. Click CLOSE (not shown) to close this blueprint and return to the list

 

 

View Deployments

 

  1. Click on the Deployments tab
  2. Note the IP address of the machine in the Linux cloud-init deployment (note that the IP may not match the screenshot)
  3. Click on the PuTTY icon in the taskbar to open it

 

 

Connect to Linux Machine

 

  1. In the Host Name (or IP address) field in the PuTTY Configuration window, enter the IP address from the previous step (note that the IP may not match the screenshot)
  2. Click Open

 

 

Log In and View Message of the Day

 

  1. Click Yes to dismiss the PuTTY Security Alert window (not shown)
  2. Log in to the machine using the username and password entered at deployment time (default username: testUser, default password: VMware1!)

Note that if you changed the Username and/or Password inputs at deployment time, use those values instead.

  1. Note the customized message of the day.  This is the same message set in the cloudConfig section of the Blueprint with Comments blueprint.
  2. Type exit and press Enter to close the PuTTY window

 

 

View Windows Machine in Browser

 

  1. Note the IP address of the Windows machine in the Windows cloudbase-init deployment
  2. Click the + in the browser bar to open a new tab

 

 

View IIS Page

 

  1. In the URL bar, enter http://ip_address, where ip_address is the address of the Windows machine in the previous step.

The default Internet Information Services page is displayed.  This page is available due to the feature installation in the cloudConfig section of the Windows with cloudbase-init blueprint.

 

Conclusion


In this module, we explored additional options for enhancing Cloud Assembly blueprints.  The combination of inputs, expressions, and cloudConfig customization allows for more dynamic and detailed deployments.


 

You've finished the module

 

Congratulations on completing the lab module.

If you are looking for additional information, see:

From here you can:

  1. Click to advance to the next page and continue with the next lab module
  2. Open the TABLE OF CONTENTS to jump to any module or lesson in this lab manual
  3. Click on the END button if you are done with the lab for now and want to exit

 

 

Module 3 - Infoblox IPAM Integration with vRealize Automation (45 minutes)

Introduction


In this module, we will explore integration between Cloud Assembly and Infoblox IPAM using the vRealize Automation 8.1 IPAM SDK.  With the Infoblox package for vRealize Automation 8.1, IP address provisioning and DNS updates can be automated against defined Infoblox networks.


Open Chrome Browser


Let's log in to vRealize Automation first.


 

Open Chrome Browser from Windows Quick Launch Task Bar

 

  1. Click on the Chrome Icon on the Windows Quick Launch Task Bar.

 

Logging in to vRealize Automation (HOLadmin)


In this lesson we will start by logging into vRealize Automation.


 

Launch vRealize Automation

 

From within the Chrome web browser:

  1. Click vRealize Automation from the bookmarks bar.

 

 

Log in to vRealize Automation

 

At the Workspace ONE login screen:

  1. Enter holadmin into the username field.
  2. Enter VMware1! into the password field.
  3. Click Sign In.

 

Launch the Cloud Assembly Service


Use this for launching the cloud assembly service in your modules


 

Launch the Cloud Assembly Service

 

From within the Cloud Services Console, under My Services:

  1. Click the Cloud Assembly service.

 

Configuring vRealize Automation to Integrate with Infoblox DDI


In this lesson, we will add Infoblox as an integration into vRealize Automation and then demonstrate deployment of a blueprint that will use Infoblox for IP Address Management.


 

Navigate to Integrations

 

  1. Click the Infrastructure tab
  2. Click the scrollbar on the left to scroll down
  3. Click Integrations

 

 

View Integrations

 

This lab already includes existing integrations into vRealize Orchestrator, GitHub, and vRealize Operations.  In this lesson, we will create an additional integration.

  1. Click + ADD INTEGRATION

 

 

Select Integration Type

 

  1. Click on IPAM in the selection of available integration types

 

 

Create New Integration

 

  1. For Name, enter Infoblox
  2. Click MANAGE IPAM PROVIDERS to add a new provider.  Currently, no IPAM providers are available in this environment and so one must be added before it can be used in the integration.

 

 

Add Infoblox Provider

 

  1. Click IMPORT PROVIDER PACKAGE (not shown) to open the file selection window
  2. Click the Lab Files folder, and then double click on the 2121-04-CMP folder (not shown) to open it
  3. Click on the Infoblox.zip file to select it
  4. Click Open

 

 

Add Infoblox Provider (Continued)

 

The import process will complete after a few seconds.  Infoblox is now available as an IPAM provider within Cloud Assembly.

  1. Click CLOSE to return to the New Integration screen

 

 

Create New Integration (Continued)

 

  1. With the Infoblox provider installed, click in the Provider field and select Infoblox from the list.  This will add additional fields for Infoblox-specific configuration settings.
  2. For Username, enter admin
  3. For Password, enter VMware1!
  4. For Hostname, enter infoblox.corp.local

 

 

Validate Infoblox Settings

 

Scroll down (not shown) to see the rest of the New Integration settings.

  1. Click VALIDATE to validate the Infoblox credentials (Note: this validation might time out the first attempt.  If it returns with an error, click VALIDATE again.)

 

 

Complete New Integration

 

  1. Click ADD to add the integration

 

 

Navigate to Network Profiles

 

Now that the integration is configured, Infoblox can be used as an IPAM provider for existing networks and for on-demand networks.  In this lesson, we will add Infoblox as a provider for an existing network, which we will add to the already configured network profile in Cloud Assembly.

  1. Click Network Profiles
  2. Click OPEN under the vSphere Networks profile to open it

 

 

Add Network

 

  1. Click the Networks tab

This network profile already has one network configured - a distributed virtual switch port group with a specified CIDR and range of IP addresses.  In order to use Infoblox as a provider for an existing network, we must first add that network to the network profile.

  1. Click + ADD NETWORK

 

 

Add Network (Continued)

 

  1. Click the checkbox next to the port group IPAM-RegionA01-vDS-COMP (Note: it may be necessary to scroll down to see this port group)
  2. Click OK to add the network

(If you have previously completed Module 1 in this lab, then the NSX network configuration will appear in the Add Network list by default.  If this is the case, click the View vSphere Networks link next to the Filter field to change the listed networks.)

 

 

Create a Managed IP Range

 

The port group has been added to our network profile, but Infoblox is not yet configured to manage IP addresses for it.

  1. Click the checkbox next to the IPAM-RegionA01-vDS-COMP port group
  2. Click MANAGE IP RANGES

 

 

Create a Managed IP Range (Continued)

 

Initially, no managed IP ranges exist for this newly added port group.

  1. Click + NEW IP RANGE (not shown) to add a new IP range
  2. Click on the Provider field and select Infoblox
  3. Click on the Address space field, and select default
  4. Click the checkbox next to the 192.168.130.200-192.168.130.219 range
  5. Scroll down and click ADD (not shown) to add this range, and click CLOSE (not shown) to close the Manage IP Ranges window and return to the Network Profile

 

 

IP Range Created

 

The IP range is now available to be used in Cloud Assembly blueprints, and Infoblox will manage IP allocations within the range.  In order to use this network within a blueprint, we will assign a tag to the network itself within the profile - this will allow blueprints to easily use this network, by using this tag as a constraint.

  1. Click the checkbox next to IPAM-RegionA01-vDS-COMP
  2. Click TAGS

 

 

Add Tag

 

  1. In the Add tags field, type net:infoblox and press Enter to add a new tag
  2. Click SAVE to save this tag and apply it to the network

 

 

Save Changes to Network Profile

 

  1. Click SAVE to save the changes made to the network profile

With the configuration complete, Cloud Assembly now has a network available for blueprints to consume with a range managed by Infoblox.  Next, we will examine a blueprint using this network, and create a deployment from it.

 

Using Infoblox IPAM Integration in vRealize Automation Blueprints


Now that we've configured Infoblox as an integration into Cloud Assembly, and configured an existing network to use Infoblox as a provider, we can begin to consume these resources in Cloud Assembly blueprints.


 

Navigate to Blueprints

 

  1. Click the Design tab to go to the list of blueprints
  2. Click the Infoblox-Managed Machine blueprint to open it in the design canvas

 

 

View the Blueprint

 

Take a moment to note how this blueprint is constructed:

  1. This blueprint will deploy a single vSphere machine, attached to a vSphere network
  2. The vSphere machine is configured to use a static IP address at deployment using the assignment: static parameter
  3. The blueprint is configured to use an existing network, that has the tag net:infoblox

 

 

Open Browser Tab

 

  1. Click the + to open a new browser tab
  2. Click the Other bookmarks menu
  3. Select Infoblox from the list to connect to the Infoblox Grid Manager

 

 

Log In to Infoblox

 

  1. Click Login to log in to the Grid Manager

 

 

View IPAM Configuration

 

  1. Click Data Management to navigate to the IPAM Home
  2. Click on the 192.168.0.0/16 network container

 

 

View IPAM Configuration (Continued)

 

  1. Click the List tab to view the list of available networks in this container
  2. Click on the Network 192.168.130.0/24 to view the list of IP addresses for this specific network

 

 

Return to Cloud Assembly

 

This view shows the full list of used and available IP addresses in this network.

  1. Click the Cloud Assembly browser tab to return to Cloud Assembly

 

 

Deploy the Blueprint

 

  1. Click DEPLOY to create a deployment of this blueprint

 

 

Name Deployment

 

  1. For Deployment Name, enter VM with IPAM
  2. Click on the Blueprint Version field, and select Current Draft
  3. Click DEPLOY

 

 

Monitor Deployment in Progress

 

Monitor the deployment in progress.  As the deployment proceeds, the vSphere Machine and Network objects will populate on the Topology canvas.  The deployment will complete after 3-5 minutes.

 

 

Verify IP Address

 

  1. Click on the Cloud_vSphere_Machine_1 object in the canvas to select it
  2. Note the Resource name and Address of this machine for later (these values may vary from the one shown in the screenshot)

 

 

Return to Infoblox tab

 

  1. Click the Infoblox Grid Manager browser tab to return to the Infoblox Grid Manager
  2. In the Go To field, type the IP Address of the deployed machine (192.168.130.200 in this example) and press Enter

 

 

Verify IP

 

  1. Verify that the IP assigned to the machine is showing as Used
  2. Click the right border of the NAME column and drag it to the right to expand the name.  For the IP assigned to the vSphere machine, the name will match the Resource name entry.

 

 

Return to Cloud Assembly and Delete Deployment

 

  1. Click the Cloud Assembly tab to return to Cloud Assembly
  2. Click the Actions link to open the menu
  3. Click Delete to delete the deployment
  4. Click SUBMIT (not shown)

After the deployment has been deleted, if you return to the Infoblox browser tab, you will see that the IP address has been reclaimed as well.

 

Conclusion


In this module, we explored Infoblox IPAM integration in vRealize Automation Cloud Assembly.


 

You've finished the module

 

Congratulations on completing the lab module.

If you are looking for additional information, see:

From here you can:

  1. Click to advance to the next page and continue with the next lab module
  2. Open the TABLE OF CONTENTS to jump to any module or lesson in this lab manual
  3. Click on the END button if you are done with the lab for now and want to exit

 

 

Module 4 - Extensibility Using vRealize Orchestrator and ABX (45 minutes)

Introduction


In this module, we will quickly cover the basics of using VMware vRealize Orchestrator and vRealize Automation to perform extensibility tasks.

The lab module will provide a brief overview of the following topics:


Sign in to vRealize Orchestrator


We are going to sign in to the vRealize Orchestrator environment in this section of the lab.


 

Open the Chrome Browser from Windows Quick Launch Task Bar

 

 

 

Open the bookmark for vRealize Automation

 

  1. Click the vRealize Automation bookmark in the bookmark bar

 

 

Log in to vRealize Automation

 

Login using the following credentials:

Username: holadmin

Password: VMware1!

  1. Click Sign in to log in to the vRealize Automation Cloud Services Console

 

 

Open the vRealize Orchestrator Service

 

Open the Orchestrator service:

  1. Click Orchestrator to open the vRealize Orchestrator Service

We are now signed into the Orchestrator service as the holadmin user.

 

vRealize Orchestrator Multi-Language Support


vRealize Orchestrator now supports the following language runtimes:

This lab section will cover all of these except JavaScript. We will utilize each language to perform a basic REST call to vSphere to create a vSphere tag, get the vSphere tag, and then delete the vSphere tag. This is a basic set of workflows and scriptable tasks that rely on standard REST calls to showcase this new multi-language functionality and extensibility with vRA.


 

Create a New Workflow (Node.js)

 

We will perform the following steps:

  1. Navigate to the Workflows view
  2. Change the view to view the folder hierarchy
  3. Expand the HOL folder and select the 2121-04 folder
  4. Click the button to create a New Workflow.

 

 

Name the Workflow (Node.js)

 

  1. We will name this workflow based on its designated purpose by calling it Create a vSphere Tag (Node.js)
  2. Click the Create button to create the workflow

 

 

vRO Scripting in Node.js

 

We will perform the following steps:

  1. Open the Schema tab at the top
  2. Drag in a Scriptable Task from the palette onto the canvas between the Start and End items.
  3. Click on the Scripting tab in the Scriptable Task panel that opens and select Node.js 12 as our runtime for this script.
  4. Highlight all of the text in the editor and delete it.

 

 

vRO Scripting in Node.js (Continued)

 

We will utilize Node.js code to establish a session to vSphere and then create a tag utilizing the vSphere REST API. The code that we will be using can be found in the C:\hol-2121-lab-files\labfiles\2121-04-CMP\ folder on the control center VM we are working from.

  1. We will open a Windows Explorer window to that folder. The simplest way to do this is to click on Lab Files in the Favorites section of the Explorer Window.
  2. We will need to open the script in notepad by double clicking on hol2121-04-module4-nodejs.txt.
  3. [Not Shown] Copy all of the code from the hol2121-04-module4-nodejs.txt file that will establish the session and create the tag.

Note: If, when trying to paste from the clipboard using the paste keyboard shortcut (ctl-v or command-v), you may have enabled the Paste Intercept feature in the lab environment. To disable the setting, see the information in the Lab Guidance section and then use the Table of Contents to return to this place in the lab manual.

 

 

Save the Workflow and Run It (Node.js)

 

Note: If, when trying to paste from the clipboard using the paste keyboard shortcut (ctl-v or command-v), you may have enabled the Paste Intercept feature in the lab environment. To disable the setting, see the information in the Lab Guidance section and then use the Table of Contents to return to this place in the lab manual.

  1. We will paste the code into the Scripting Task window.
  2. Click Save before running the Workflow to create our tag in vSphere. When we click Save, a popup dialog will appear, and you will need to confirm the save operation.
  3. Click Run to run the workflow.

 

 

Verify the Workflow Ran (Node.js)

 

We need to verify that the workflow ran correctly and that we created our custom tag. After clicking Run, a different view will appear.  We will then perform the following steps:

  1. Wait for the Workflow to show a status of Completed
  2. Wait for the workflow to enter the End task (it will highlight as green).
  3. Click on the Logs tab and observe that the Session Start Status and Tag Creation Status both show a status of 200 (that they completed successfully).

 

 

Return to vRealize Orchestrator Workflows View

When you have verified that the workflow ran correctly, click Close and return back to the Workflows view of vRealize Orchestrator.

 

 

Create a New Workflow (PowerCLI)

 

We will perform the following steps:

  1. Navigate to the Workflows view
  2. Expand the HOL folder and select the 2121-04 folder
  3. Click the button to create a New Workflow.

 

 

Name the Workflow (PowerCLI)

 

  1. We will name this workflow based on its designated purpose by calling it Get a vSphere Tag (PowerCLI)
  2. Click the Create button to create the workflow

 

 

vRO Scripting in PowerCLI

 

We will perform the following steps:

  1. Open the Schema tab at the top
  2. Drag in a Scriptable Task from the palette onto the canvas between the Start and End items.
  3. Click on the Scripting tab in the Scriptable Task panel that opens and select PowerCLI 11 (PowerShell 6.2) as our runtime for this script.
  4. Highlight all of the text in the editor and delete it.

 

 

vRO Scripting in PowerCLI (Continued)

 

We will utilize PowerCLI/PowerShell code to establish a session to vSphere and then get a tag utilizing the vSphere REST API. The code that we will be using can be found in the C:\hol-2121-lab-files\labfiles\2121-04-CMP\ folder on the control center VM we are working from.

  1. We will open a Windows Explorer window to that folder. The simplest way to do this is to click on Lab Files in the Favorites section of the Explorer Window.
  2. We will need to open the script in notepad by double clicking on hol2121-04-module4-powershell.txt.
  3. [Not Shown] Copy all of the code from the hol2121-04-module4-powershell.txt file that will establish the session and get the tag.

Note: If, when trying to paste from the clipboard using the paste keyboard shortcut (ctl-v or command-v), you may have enabled the Paste Intercept feature in the lab environment. To disable the setting, see the information in the Lab Guidance section and then use the Table of Contents to return to this place in the lab manual.

 

 

Save the Workflow and Run It (PowerCLI)

 

Note: If, when trying to paste from the clipboard using the paste keyboard shortcut (ctl-v or command-v), you may have enabled the Paste Intercept feature in the lab environment. To disable the setting, see the information in the Lab Guidance section and then use the Table of Contents to return to this place in the lab manual.

  1. We will paste the code into the Scripting Task window.
  2. Click Save before running the Workflow to create our tag in vSphere. When we click Save, a popup dialog will appear, and you will need to confirm the save operation.
  3. Click Run to run the workflow.

 

 

Verify the Workflow Ran (PowerCLI)

 

We need to verify that the workflow ran correctly and that we created our custom tag. After clicking Run, a different view will appear.  We will then perform the following steps:

  1. Wait for the Workflow to show a status of Completed
  2. Wait for the workflow to enter the End task (it will highlight as green).
  3. Click on the Logs tab and observe the Tag Name, Tag Description, Tag Category ID, and Tag ID are all displayed in the log.

 

 

Return to vRealize Orchestrator Workflows View

When you have verified that the workflow ran correctly, click Close and return back to the Workflows view of vRealize Orchestrator.

 

 

Create a New Workflow (Python)

 

We will perform the following steps:

  1. Navigate to the Workflows view
  2. Expand the HOL folder and select the 2121-04 folder
  3. Click the button to create a New Workflow.

 

 

Name the Workflow (Python)

 

  1. We will name this workflow based on its designated purpose by calling it Delete a vSphere Tag (Python)
  2. Click the Create button to create the workflow

 

 

vRO Scripting in Python

 

We will perform the following steps:

  1. Open the Schema tab at the top
  2. Drag in a Scriptable Task from the palette onto the canvas between the Start and End items.
  3. Click on the Scripting tab in the Scriptable Task panel that opens and select Python 3.7 as our runtime for this script.
  4. Highlight all of the text in the editor and delete it.

 

 

vRO Scripting in Python (Continued)

 

We will utilize Python code to establish a session to vSphere and then delete a tag utilizing the vSphere REST API. The code that we will be using can be found in the C:\hol-2121-lab-files\labfiles\2121-04-CMP\ folder on the control center VM we are working from.

  1. We will open a Windows Explorer window to that folder. The simplest way to do this is to click on Lab Files in the Favorites section of the Explorer Window.
  2. We will need to open the script in notepad by double clicking on hol2121-04-module4-powershell.txt.
  3. [Not Shown] Copy all of the code from the hol2121-04-module4-python.txt file that will establish the session and delete the tag.

Note: If, when trying to paste from the clipboard using the paste keyboard shortcut (ctl-v or command-v), you may have enabled the Paste Intercept feature in the lab environment. To disable the setting, see the information in the Lab Guidance section and then use the Table of Contents to return to this place in the lab manual.

 

 

Save the Workflow and Run It (Python)

 

Note: If, when trying to paste from the clipboard using the paste keyboard shortcut (ctl-v or command-v), you may have enabled the Paste Intercept feature in the lab environment. To disable the setting, see the information in the Lab Guidance section and then use the Table of Contents to return to this place in the lab manual.

  1. We will paste the code into the Scripting Task window.
  2. Click Save before running the Workflow to create our tag in vSphere. When we click Save, a popup dialog will appear, and you will need to confirm the save operation.
  3. Click Run to run the workflow.

 

 

Verify the Workflow Ran (Python)

 

We need to verify that the workflow ran correctly and that we created our custom tag. After clicking Run, a different view will appear.  We will then perform the following steps:

  1. Wait for the Workflow to show a status of Completed
  2. Wait for the workflow to enter the End task (it will highlight as green).
  3. Click on the Logs tab and observe that The Tag was deleted.
  4. [Not Shown] Close out of the Chrome Web Browser as we are finished with this section of the lab.

 

 

Conclusion

This has been a basic introduction to the Polyglot (multi-language) functionality now present in vRealize Orchestrator. There are a lot of possibilities that have not been covered in this section of the lab but are possible with this new functionality.

 

ABX Action Extensibility


In vRealize Automation ABX Actions are executed based on lifecycle events, using functions-as-a-service (FaaS), to extend the functionality of the platform. They support several languages, including PowerShell, NodeJS, and Python and can be executed in either Public Cloud FaaS (Function as a Service) Providers or On Prem.  In this section of the lab, we will utilize a custom PowerShell ABX Action, a Subscription, and a Custom Form Input to change the name of a Virtual Machine resource.  ABX Actions are a powerful method to extend the functionality of vRealize Automation.


 

Open the Chrome Browser from Windows Quick Launch Task Bar

 

 

 

Open the bookmark for vRealize Automation

 

  1. Click the vRealize Automation bookmark in the bookmark bar

 

 

Log in to vRealize Automation

 

Login using the following credentials:

Username: holadmin

Password: VMware1!

  1. Click Sign in to log in to the vRealize Automation Cloud Services Console

 

 

Open the Cloud Assembly Service

 

Open the Cloud Assembly service:

  1. Click Cloud Assembly to open the vRealize Code Stream Service

We are now signed into the Cloud Assembly service as the holadmin user.

 

 

Make a new Extensibility Action

 

We will perform the following steps:

  1. Open the Extensibility tab
  2. Open the Actions view
  3. Create a New Action.

 

 

Name the Action

 

  1. We will name our action renameVirtualMachine
  2. Assign our action to the HOL Project
  3. Click Next to continue.

 

 

Multi Language Support in ABX Actions

 

Once the ABX Action is open, we can choose which of the Action languages we want to use to write the code for our action in.  Thanks to polyglot support, Nodejs, PowerShell, and Python are all supported. For this section of the lab we will be utilizing PowerShell to create an action to rename our Virtual Machine based on a custom input.

  1. Once the view loads, click on the dropdown
  2. Change the language to PowerShell

 

 

Change the Action to Execute On Prem

 

ABX Actions can be executed in several FaaS (Function as a Service) Cloud Providers or they can be executed On Prem. We will make sure our action is going to execute On Prem by:

  1. Selecting the FaaS Provider dropdown.
  2. Click on On Prem.

 

 

Coding our Action

 

  1. We will begin coding our action by highlighting all of the existing code first. Delete the code from the action, in the next step we will add our own custom code back to our action.

 

 

Coding our Action (continued)

 

The code that we will be using can be found in the C:\hol-2121-lab-files\labfiles\2121-04-CMP\ folder on the control center VM we are working from.

  1. We will open a Windows Explorer window to that folder. The simplest way to do this is to click on Lab Files in the Favorites section of the Explorer Window.
  2. We will need to open the script in notepad by double clicking on hol2121-04-module4-ABXps.txt.
  3. [Not Shown] Copy all of the code from the hol2121-04-module4-ABXps.txt file

Note: If, when trying to paste from the clipboard using the paste keyboard shortcut (ctl-v or command-v), you may have enabled the Paste Intercept feature in the lab environment. To disable the setting, see the information in the Lab Guidance section and then use the Table of Contents to return to this place in the lab manual.

 

 

Save and close the Action

 

After entering the code, we should:

  1. Save the action by clicking on Save.
  2. Close out of the Action view by clicking on Close.

 

 

Create a new Subscription

 

Once we are back in the Extensibility view, we will perform the following steps:

  1. Navigate to Subscriptions
  2. Create a New Subscription

 

 

Configure the new Subscription

 

  1. We will first configure the subscription with the Name of renameVmSubscription
  2. Provide a Description that says Rename a VM to a Custom Name.
  3. Click on the ADD button under Event Topic to add a new event topic and then proceed to the next step.

 

 

Add an Event Topic

 

We will perform the following steps:

  1. Start by searching within the window that pops up for compute allocation
  2. Select Compute allocation in the list.
  3. Click Select

 

 

Add the Action

 

After adding our Event Topic, we will go back to the Subscription view and then:

  1. We can click on the Add Button for the Action/Workflow to add to this subscription.

 

 

Add the action (continued)

 

From the window that pops up, we will perform the following steps:

  1. Select our renameVirtualMachine action from the list
  2. Click on select to add it to the Subscription

 

 

Set Blocking and Save the Subscription

 

Back in the Subscription view, we will perform the following steps:

  1. Set our Subscription to Block so our pipeline won't continue until it is complete
  2. Click Save to save the subscription

 

 

Edit the Blueprint Design

 

Next, we will clone our Ubuntu 18 blueprint so that we can customize it.  

  1. Click on the Design Tab
  2. Select the checkbox next to the Ubuntu 18 blueprint
  3. Click Clone

 

 

Configure the clone

 

We will perform the following steps:

  1. Name our Blueprint, myCustomBlueprint
  2. Assign it to the HOL Project
  3. We will select Current Draft for the version
  4. Click the Clone button

 

 

Open our custom blueprint for editing

 

  1. We will need to open our blueprint so that we can edit it and have it call our custom renaming action. Open the blueprint by clicking on myCustomBlueprint.

 

 

Adding an input

 

  1. We will now add a new input to our VM by clicking on the Inputs tab in the left side pane.  
  2. From there we can click on the New button to add a new input.

 

 

Adding an input (continued)

 

  1. From the Create Blueprint Input window that pops up, we will assign a name of customVmName to our input.
  2. We can then click on Create to create our new Input.

 

 

Editing our Blueprint to call our action

 

  1. In this step we will edit our blueprint YAML by clicking back on the Code tab.
  2. We will be adding a new property line under the properties and calling it customName and assigning it to an input of '${input.customVmName}'.

The complete YAML for the blueprint will now look as follows.

formatVersion: 1
name: Ubuntu 18
version: 1
inputs: {}
resources:
  ubuntu:
    type: Cloud.vSphere.Machine
    properties:
      customName: '${input.customVmName}'
      image: Ubuntu18
      flavor: tiny
      constraints:
        - tag: 'cloud:vsphere'
      networks:
        - network: '${resource.vsphere_network.id}'
          assignment: static
  vsphere_network:
    type: Cloud.vSphere.Network
    properties:
      networkType: existing
      constraints:
        - tag: 'net:vsphere'

 

 

Deploy our Blueprint

 

  1. At this point, we can click on the Deploy button in the bottom left of the window and begin deploying our blueprint.

 

 

Deployment Options

 

From the deployment window that opens, we will perform the following steps:

  1. Provide a Deployment Name of myCustomDeployment
  2. Select Current Draft for the Blueprint Version
  3. Click Next

 

 

Deployment Options (continued)

 

From the deployment Inputs window, we will now perform the following steps:

  1. Enter the custom hostname for our Virtual Machine as rainpole
  2. Click Deploy

 

 

Monitor the Deployment

 

The Deployment Creation window will launch, and the topology will be deployed. This may take a few minutes so please be patient as the VM is deployed. We can perform the following steps:

  1. Click the Refresh Button to refresh the deployment status and monitor the progress.
  2. Wait for the deployment window to show the Virtual Machine Resource
  3. Click on it and observe that the Resource Name is rainpole

That concludes a brief introduction to ABX Extensibility options. There are many other ways to utilize the ABX extensibilities present within vRealize Automation so we hope you'll look at some of the resources at the end of the lab and see what else you can do with these amazing automation and extensibility options.

 

Conclusion


In this module we walked through the basics of using VMware vRealize Orchestrator and vRealize Automation to perform extensibility tasks.


 

You've finished the module

 

Congratulations on completing the lab module.

If you are looking for additional information on vRealize Orchestrator and vRealize Automation, you can start

here: 

https://www.vmware.com/products/vrealize-orchestrator.html

https://www.vmware.com/products/vrealize-automation.html

From here you can:

  1. Click to advance to the next page and continue with the next lab module
  2. Open the TABLE OF CONTENTS to jump to any module or lesson in this lab manual
  3. Click on the END button if you are done with the lab for now and want to exit

 

 

Module 5 - Custom Day 2 Actions (30 minutes)

Introduction


This Module will focus on how the vRealize Automation Resource Actions feature can be used to extend the Day 2 capabilities of deployed resources using custom Resource Actions (based on vRealize Orchestrator workflows).  We will also see how Day 2 Action policies can be used to ensure that custom Resource Actions are visible to only those who need them.

The key lessons in this Module are:                    

You will need approximately 30 minutes to complete all of the lessons within this Module.

Lab Captain: Christopher Lewis


An introduction to XaaS


Anything-as-a-Service (XaaS) is the ability to take a vRealize Orchestrator workflow and bind it to a vRealize Automation catalog function such as a Blueprint or a custom Resource Action.  Using vRealize Orchestrator we have the power to automate ANY business function or IT process that can be accomplished via API,  Script or CLI and deliver it as a service in a service catalog item for users to consume.

For more information on vRealize Orchestrator, see HOL-2121-06-CMP - Getting Started with vRealize Orchestrator.

Within vRealize Automation, there are three main use cases for XaaS:

1. vRealize Orchestrator Workflow as a Catalog Item

This is where we can publish vRealize Orchestrator workflows as Catalog Items, customize the request form and publish them within the Service Catalog so we can wrap the vRealize Automation governance engine (such as Approval Policies and Role Based Access Control) around them.

This use case is covered in Module 7 - XaaS with vRealize Automation (45 minutes).

2. Custom Resource

A Custom Resource is a resource type, based on a vRealize Orchestrator workflow, that can be used to expand the capability of vRealize Automation.  A Custom Resource also enables vRealize Orchestrator workflows to be consumed within the Blueprint canvas just like any other resource type.

This use case is covered in Module 7 - XaaS with vRealize Automation (45 minutes).

3. Resource Actions (Day 2)

A Resource Action is used when we want to configure a vRealize Orchestrator workflow so that it can be run as part of the Day 2 operations of a vRealize Automation managed resource.  These can be completed against out of the box resource types (such as Virtual Machines) or against a Custom Resource.  We can also wrap governance around these using Day 2 Action policies.

This use case is covered in this Module.


Scenario: Custom Snapshots


You have just received the monthly report on the Hybrid Cloud platform from vRealize Operations.  You have noticed that the number of snapshots on Virtual Machines within the App-Dev project is steadily increasing the amount of storage being consumed.  You are concerned that if something isn't done soon then the number of snapshots will start to negatively impact the performance of the platform.

You talk to the App-Dev manager about the problem.  The App-Dev manager says that it is important that the users can create snapshots on their vSphere Virtual Machines so they can quickly revert their Virtual Machines to a known good state whilst they are installing new applications and testing their code.  The App-Dev manager then adds that the users have complained about the amount of information they need to fill out and whether they should be doing memory snapshots or not (because they seem to take a long time to do!).  

As a compromise, rather than taking away the ability to perform snapshots altogether or applying an onerous governance layer that could impact productivity, you agree with the App-Dev manager to put some governance guard rails into vRealize Automation to help keep the number of snapshots down.

You agree to the following governance model around Virtual Machine Snapshots:

1. Snapshot will continue to be a Day 2 Action.

2. Every user of the App-Dev project will only be able to have one active snapshot per virtual machine.

3. All snapshot requests will automatically have the option for memory snapshot set to false.

4. All snapshot requests will automatically have the option for quiesce the OS set to false.

5. The only thing the developer will be asked to fill out will be the reason for the snapshot from a defined list:

Software Install

OS Patch

Software Patch

Code Release


Logging in to vRealize Automation


In this lesson we are going to go through the basics of logging into vRealize Automation.


 

Open Chrome Browser from Windows Quick Launch Task Bar

 

  1. Click on the Chrome Icon on the Windows Quick Launch Task Bar.

 

 

Launch vRealize Automation

 

From within the Chrome web browser:

  1. Click vRealize Automation from the bookmarks bar.

 

 

Log in to vRealize Automation

 

At the Workspace ONE login screen, assuming corp.local is the active domain, we can log straight in:

  1. Enter holadmin into the username field.
  2. Enter VMware1! into the password field.
  3. Click Sign In.

 

Reset the Resources for the Module


To support the number of different Modules using the same HOL image/environment means it is necessary to reset resources so that we can complete this Module.


 

Launching the Code Stream Service

 

From within the Cloud Services Console, under My Services:

  1. Click the Code Stream service.

 

 

Run the Reset Resources Pipeline

 

We are going to run a Code Stream Pipeline to reset the HOL environment.

  1. Click Pipelines.
  2. Locate the Reset Resources pipeline and click RUN.

 

 

Execute the Pipeline

 

At the Execute Reset Resources dialog:

  1. Click RUN.

 

 

View the Pipeline Execution

 

We are going to monitor the pipeline execution so we know when it has completed.

  1. Click ACTIONS.
  2. Click View Executions.

 

 

Wait for the Pipeline to Complete

 

  1. Wait for the execution to be completed.

 

 

Switch to the Cloud Services Console

 

  1. Click the 9-dot icon.
  2. Click Cloud Services Console.

 

Creating a Snapshot Custom Resource Action for a vSphere Cloud Machine


In this lesson we will be working as the Cloud Administrator to provide a solution to the scenario that has been presented to us in Scenario: Snapshots. We will create a custom Resource Action (AKA Custom Day 2 action) for the vSphere Cloud Machine resource type using an existing vRealize Orchestrator workflow (see Workflow: Snapshot VM). This will allow the App-Dev team (or any other project) to consume this Resource Action.

Within this lesson the main vRealize Automation service we will be using is Cloud Assembly.


 

Required Components

Before we can configure a custom Resource Action, we need to ensure that we have a vRealize Orchestrator workflow available to complete the desired outcome.  As this lesson is not about the actual creation of the workflows, the following components have been provided.

 

 

Launching the Cloud Assembly Service

 

From within the Cloud Services Console, under My Services:

  1. Click the Cloud Assembly service.

 

 

Creating a Custom Day 2 Resource Action

 

  1. Click the Design tab.
  2. Click Resource Actions.
  3. Click NEW RESOURCE ACTION.

 

 

Testing the Custom Day 2 Action

 

  1. Click the Deployments tab.
  2. Click the vSphere Ubuntu Deployment.

 

Scenario: Custom Snapshots - Update


You have just reviewed the new monthly report on the Hybrid Cloud platform and you are surprised to see that there are still deployments out there with more than one snapshot, especially in the App-Dev project.  You give the App-Dev manager a call to discuss why his team are still creating multiple snapshots and are not using the action you created.  

The App-Dev manager speaks to the team and responds by saying that there seems to be some confusion because there are currently two snapshot actions available to select, Create Snapshot and VM Snapshot.  It seems some of the team are using the right action and others are just click the first action they find in the list of actions (which happens to be the Create Snapshot).

The App-Dev manager has asked if there is any way to get rid of the out of the box action, just have the new custom Resource Action but rename it Create Snapshot like the old one.


Applying Day 2 Action Policies in Service Broker


In this lesson we will be making changes to the environment to respond to the latest request from the App-Dev manager.  We are going to configure a governance policy for Day 2 Actions so that the out of the box Create Snapshot action is replaced with the one we previously created.

 This lesson requires you to have successfully completed the previous lesson in this module, Creating a Custom Day 2 Action for vSphere Cloud Machine.

Whilst we will start our lesson within the Cloud Assembly service, the main vRealize Automation service we will be using is Service Broker.


 

Updating the Custom Day 2 Resource Action

 

  1. Click the Design tab.
  2. Click Resource Actions.
  3. Click CustomSnapshot.

 

 

Switch to the Service Broker Service

 

We are now going to switch to the Service Broker service to configure the Day 2 Action Policy for the scenario.

  1. Click the 9-dot icon.
  2. Click Service Broker.

 

 

Create a New Governance Policy

 

  1. Click the Content & Policies tab.
  2. Click Definitions.
  3. Click NEW POLICY.

 

 

Test the Day 2 Action Policy

 

We are going to sign out and log back in as HOL User to check that the new Snapshot Day 2 Action is available.

  1. Click the Admin HOL user.
  2. Click SIGN OUT.

 

Conclusion


Congratulations on completing Module 5.

In this Module we have discovered more about custom Resource Actions which is one of the key Anything As A Service (XaaS) use cases supported by vRealize Automation.  

As a recap, using the scenario within the Module, we have walked through:

1. Creating a custom Resource Action to make it easier for the App-Dev team to create Virtual Machine Snapshots in a more consistent manner.

2. Applying a Day 2 Action policy so that the new Snapshot Action replaces the out of the box Create Snapshot action.


 

You've finished the module

 

Congratulations on completing the lab module.

If you are looking for additional information on Resource Actions within vRealize Automation, go to https://docs.vmware.com.

From here you can:

  1. Click to advance to the next page and continue with the next lab module
  2. Open the TABLE OF CONTENTS to jump to any module or lesson in this lab manual
  3. Click on the END button if you are done with the lab for now and want to exit

 

 

Module 6 - Configuration Management Integration (45 minutes)

Introduction


This Module will focus on how vRealize Automation can leverage existing investment into, and integrate with, third party Configuration Management toolsets to enable the provisioning, management and de-provisioning of applications as part of a vRealize Automation Cloud Assembly blueprint.

The main lessons in this Module are:       

You will need about 45 minutes to complete all of the lessons within this Module.

Lab Captain: Christopher Lewis


Configuration Management with vRealize Automation


Configuration management is a process for maintaining computer systems,  servers, and software in a desired, consistent state. 

A Configuration Management toolset is normally deployed to ensure that a system's desired state is maintained over time (i.e. configuration drift) in an automated fashion.

Within vRealize Automation, VMware supports the out of the box integration with the following Configuration Management toolsets:

- Red Hat Ansible Open Source
- Red Hat Ansible Tower
- Puppet Enterprise


Logging in to vRealize Automation


In this lesson we are going to go through the basics of logging into vRealize Automation.


 

Open Chrome Browser from Windows Quick Launch Task Bar

 

  1. Click on the Chrome Icon on the Windows Quick Launch Task Bar.

 

 

Launch vRealize Automation

 

From within the Chrome web browser:

  1. Click vRealize Automation from the bookmarks bar.

 

 

Log in to vRealize Automation

 

At the Workspace ONE login screen, assuming corp.local is the active domain, we can log straight in:

  1. Enter holadmin into the username field.
  2. Enter VMware1! into the password field.
  3. Click Sign In.

 

Integrating vRealize Automation with Red Hat Ansible Open Source


In this lesson of the module, we are going to configure the Red Hat Ansible Open Source integration so that in future lessons we can consume Ansible components on the Cloud Assembly Blueprint Canvas.


 

Launching the Cloud Assembly Service

 

From within the Cloud Services Console, under My Services:

  1. Click the Cloud Assembly service.

 

 

Configure the Red Hat Ansible Open Source Integration

 

  1. Click the Infrastructure tab.
  2. Click Integrations.
  3. Click ADD INTEGRATION.

 

Blueprint: Ansible Base


In this lesson, we are going to review the components of the Ansible Base blueprint.

The Ansible Base Cloud Assembly blueprint has been provided so that we have a template blueprint structure to build upon.  We will use the Ansible Base blueprint as the starting place for all of the other lessons in this module.


 

Navigate to Blueprints

 

We are going to navigate to the Blueprints screen so we can open the Ansible Base Blueprint and review the contents.

From within the Cloud Assembly service:

  1. Click the Design tab.
  2. Click Blueprints.

 

 

The Blueprint

 

When we look at the Ansible Base blueprint, we can see that it is a basic Cloud.vSphere.Machine blueprint.  Let us walk through the main components and how they are configured:

  1. linuxVM - A Cloud.vSphere.Machine resource type, configured with:
  2. vsphere_network - A Cloud.vSphere.Network resource type, configured with:
    • A constraint tag for vSphere networks only (i.e. cloud:vsphere).

 

 

The Inputs - Explained

 

In the Ansible Base blueprint we are providing 4 inputs and they are configured as follows:

  1. Input: image - this is the name of Image Mapping we want the user to select during the request. As this input is an enumeration (enum), we are providing a list of string values (i.e. ubuntu18 or centos7) we want the user to select from a dropdown.  The default value will be ubuntu18.
  2. Input: size - this is the name of the Flavor Mapping we want the user to select during the request. As this input is an enumeration (enum), we are providing a list of string values (i.e. tiny, small, medium, large) we want the user to select from a dropdown.  The default value will be tiny.
  3. Input: ansible-key - this is a string value that represents the public ssh key of the Ansible control machine.  We have set the default value and hidden the input on the form so that the standard requestor will not see (or need to replace) the value.  Finally, we have created this as an input for two reasons:
    • We can use the value throughout the blueprint, but only declare it once.
    • If we want to override the value through the API, we can.
  4. Input: ansible-user - this is a string value that represents the user that Ansible should run as on the deployed machines.  We have set the default value and hidden the input on the form so that the standard requestor will not see or be able to change this value in the form.

You may have noticed that the ansible-key field is currently null. This is so that it can be synchronized using Git.  One of the first things we will do in the next lesson is to update the input with the correct value.

 

 

The cloudConfig Script

 

In the Ansible Blueprint, on the linuxVM resource, we can see there is a cloudConfig (cloud-init) script.  Why are we using cloudConfig when this module is about Ansible? The most important thing to remember is that they are not mutually exclusive technologies. We can think of cloudConfig as an alternative way to configure vSphere machines to the vSphere Customization Specification.  The added advantage is that cloud-init can used across multiple clouds (not just vSphere).  We can use cloud-init to complete install/build time configurations and use Ansible for ongoing Configuration Management.

  1. Log all outputs from the cloud-init script to the log file specified.
  2. Take the ansible-key input and echo it into the /root/.ssh/authorised_keys file so that SSH communication to the Ansible control host is authorized for the user.

 

Updating the Ansible Base Blueprint


In this lesson we will quickly update the Ansible Base Blueprint with the SSH Key of the Ansible Control Machine for this lab.


 

Locate the SSH Key

 

From the desktop of the Windows machine:

  1. Open the Lab Files folder.

 

 

Update the Ansible Base Blueprint with the SSH Key

 

  1. Click the Chrome window for Cloud Assembly.

If the session has timed out you may need to log in again as the HOL Admin account.

 

Adding an Ansible Playbook to a Cloud Assembly Blueprint


In this lesson of the module we are going to start to configure our first blueprint to utilize the newly configured Ansible Open Source Integration.  We are going to be starting with a clone the existing Ansible Base blueprint and then we will add a simple Ansible playbook so we can test the solution is working.

Within this lesson the main vRealize Automation service we will be using is Cloud Assembly.


 

Playbook: hol-2121-04-1.yml

 

We are going to be using the hol-2121-04-1.yml playbook in this lesson.  This is a simple playbook that creates a new file called ansible.txt within the /tmp folder on the target host with a single line in it with the hardcoded Ansible username in it.

 

 

Clone the Blueprint

 

  1. Under Blueprints, check the Ansible Base checkbox.
  2. Click Clone.

 

 

Configure the New Blueprint

 

  1. At the Name field, type Basic Ansible.
  2. At the Project field, select HOL Project.
  3. At the Version field, select Current Draft.
  4. Click CLONE.

 

 

Edit the Basic Ansible Blueprint

 

Open the Basic Ansible blueprint in the Blueprint canvas.

  1. Click the Basic Ansible blueprint.

 

 

Version the Basic Ansible Blueprint

 

As we have made quite a few changes to the blueprint, we're going to create a new version.

  1. Click VERSION.

 

 

Close the Basic Ansible Blueprint

 

  1. Click CLOSE.

 

 

Test the Basic Ansible Blueprint

 

We are now going to deploy the new Basic Ansible Blueprint.

  1. Select the Basic Ansible Blueprint.
  2. Click DEPLOY.

 

 

Destroy the Deployment

 

We no longer need the Basic Ansible Test blueprint so we are going to delete it.

  1. Select Deployment tab.
  2. Locate the Basic Ansible Test deployment.
  3. Click the ACTIONS menu.
  4. Select Delete.

 

 

Lesson Recap: What did we just do?

At the start of the lesson, we detailed the playbook we were going to deploy.  Within the Ansible playbook, we created a file and added a line of text to the file with the hardcoded name of the user (i.e. root).  We then included that Ansible playbook in the vRealize Automation blueprint and it ran after the Virtual Machine was deployed.  This was evidenced by the test we carried out.

 

Adding Ansible Host Variables to a Cloud Assembly Blueprint


In this lesson of the module we are going to build on what we learnt in the previous lesson and leverage some advanced features of the Ansible Open Source Integration.  We are going to be updating the blueprint to use a slightly different playbook that expects some Ansible host variables to be sent as part of the request. Once deployed we will go ahead and test that the solution is working.

We are going to be enhancing the Basic Ansible blueprint we created in the previous lesson (see Add an Ansible Playbook to a Cloud Assembly Blueprint).  If you did not complete the lesson then please go back and do so now.

Within this lesson the main vRealize Automation service we will be using is Cloud Assembly.


 

Playbook: hol-2121-04-2.yml

 

We are going to be using the hol-2121-04-2 playbook in this lesson.  This is a slightly upgraded playbook to the previous lesson.  This playbook still creates a new file called ansible.txt within the /tmp folder on the target host, but the blueprint is going to be passing through an Ansible Host Variable (username) that will be used in the file.

 

 

Clone the Basic Ansible Blueprint

 

  1. Click Design.
  2. Under Blueprints, check the Basic Ansible checkbox.
  3. Click CLONE.

 

 

Configure the New Blueprint

 

  1. At the Name field, type Advanced Ansible.
  2. At the Project field, select HOL Project.
  3. At the Version field, select Current Draft.
  4. Click CLONE.

 

 

Edit the Advanced Ansible Blueprint

 

Open the Advanced Ansible blueprint.

  1. Click the Advanced Ansible blueprint.

 

 

Version the Advanced Ansible Blueprint

 

As we have made quite a few changes to the blueprint, we're going to create a new version.

  1. Click VERSION.

 

 

Test the Advanced Ansible Blueprint

 

We are now going to deploy the new Advanced Ansible Blueprint.

  1. Select the Advanced Ansible Blueprint.
  2. Click DEPLOY.

 

 

Destroy the Deployment

 

We no longer need the Advanced Ansible Test deployment so we are going to delete it.

  1. Select Deployment tab.
  2. Locate the Advanced Ansible Test deployment.
  3. Click the ACTIONS menu.
  4. Select Delete.

 

 

Lesson Recap: What did we just do?

At the start of the lesson, we detailed the playbook we were going to deploy.  Within the playbook, we are essentially creating a file and adding a line of text to the file. The line of text included a variable called username, i.e. This file was created by {{ username }}.  We then updated the vRealize Automation blueprint and we specified the hostVariable in the Cloud.Ansible object, the deployment essentially passes the host variable to the Ansible playbook at run time so the variable is replaced.

 

Deploying a Web Server with Ansible and vRealize Automation


In this lesson of the module we are going to build on what we learnt in the previous lesson and deploy a NGINX webs server onto a virtual machine using the Ansible Open Source Integration.  We are going to be updating the blueprint to use an additional playbook that will configure the web server and create a basic webpage.  Once deployed we will go ahead and test that the solution is working.

We are going to be enhancing the Advanced Ansible blueprint we created in the previous lesson (see Add an Ansible Playbook to a Cloud Assembly Blueprint).  If you did not complete this lesson then please go back and do so now.

Within this lesson the main vRealize Automation service we will be using is Cloud Assembly.


 

Playbook: hol-2121-04-3.yml

 

We are going to be using the hol-2121-04-3 playbook in this lesson.  This is new playbook that completes a number of tasks including copy files, creating files from a template and changing permissions. To reduce the length of time the deployment takes, the template already includes the NGNIX installation and the supporting image files for the website home page.

 

 

Navigate to Blueprints

 

From within the Cloud Assembly service:

  1. Click the Design tab.
  2. Click Blueprints.

 

 

Edit the Web Server Blueprint

 

Open the Web Server blueprint.

  1. Click the Web Server blueprint.

 

 

Version the Web Server Blueprint

 

As we have made quite a few changes to the blueprint, we're going to create a new version.

  1. Click VERSION.

 

 

Test the Web Server Blueprint

 

We are now going to deploy the new Web Server Blueprint.

  1. Select the Web Server Blueprint.
  2. Click DEPLOY.

 

 

Destroy the Deployment

 

We no longer need the Ansible Web Server Test blueprint so we are going to delete it.

  1. Select Deployment tab.
  2. Locate the Ansible Web Server Test deployment.
  3. Click the ACTIONS menu.
  4. Select Delete.

 

 

Lesson Recap: What did we just do?

At the start of the lesson, we detailed the additional playbook we were going to deploy.  Using the new playbook and the host group functionality, we deployed and configured NGINX to show a custom web page.  We also demonstrated the fact we could deploy more than one playbook to a single machine by keeping the previous playbook in the blueprint also.  

 

Conclusion


Congratulations on completing Module 6.

In this Module you have discovered how vRealize Automation can integrate with Configuration Management toolsets to deploy applications and manage a desired state.

As a recap, we have walked through:

1. Configuring the out of the box integration for Red Hat Ansible Open Source.

2. Creating a vRealize Automation Blueprint to call one or more Ansible playbooks.

3. Creating a vRealize Automation Blueprint that declared some Ansible host variables that were then used by the Ansible playbook.

4. Creating a vRealize Automation Blueprint to install and configure a basic Web Server using NGINX.


 

You've finished the module

 

Congratulations on completing the lab module.

If you are looking for additional information on integrating supported Configuration Management toolsets with vRealize Automation check out the VMware Documentation.

From here you can:

  1. Click to advance to the next page and continue with the next lab module
  2. Open the TABLE OF CONTENTS to jump to any module or lesson in this lab manual
  3. Click on the END button if you are done with the lab for now and want to exit

 

 

Module 7 - XaaS with vRealize Automation (45 minutes)

Introduction


This Module will focus on how vRealize Automation's Anything-as-a-Service (XaaS) capability can be used to provide self-service access and management to the automated business and processes created within vRealize Orchestrator.

The main lessons in this Module are:

You will need about 45 minutes to complete all of the lessons within this Module.

Lab Captain: Christopher Lewis


An Introduction to XaaS


Anything-as-a-Service (XaaS) is the ability to take a vRealize Orchestrator workflow and bind it to a vRealize Automation catalog function such as a blueprint or a custom Resource Action.  Using vRealize Orchestrator we have the power to automate ANY business function or IT process that can be accomplished via API,  Script or CLI and deliver it as-a-service in a service catalog item for users to consume.

For more information on vRealize Orchestrator, see HOL-2121-06-CMP - Getting Started with vRealize Orchestrator.

Within vRealize Automation, there are three main use cases:

1. vRealize Orchestrator Workflow as a Catalog Item

This is where we can publish vRealize Orchestrator workflows as Catalog Items, customise the request form and publish them within the Service Catalog so we can wrap the vRealize Automation governance engine (such as Approval Policies and Role Based Access Control) around them.

This use case is covered in this Module.

2. Custom Resource

A Custom Resource is a resource type, based on a vRealize Orchestrator workflow, that can be used to expand the capability of vRealize Automation.  A Custom Resource also enables vRealize Orchestrator workflows to be consumed within the Blueprint canvas just like any other resource type.

This use case is covered in this Module.

3. Resource Actions (Day 2)

A Resource Action is used when we want to configure a vRealize Orchestrator workflow so that it can be run as part of the Day 2 operations of a vRealize Automation managed resource.  These can be completed against out of the box resource types (such as Virtual Machines) or against a Custom Resource.  We can also wrap governance around these using Day 2 Action policies.

This use case is covered in this Module 5 - Custom Day 2 Actions (30 minutes).


Scenario: Service Desk


The Service Desk has seen a steady increase in call volume recently due to the fact that lots of new starters are being hired as the company grows.

The top 5 requests to the Service Desk are all around the creation and management of new accounts:

1. Creating new User Accounts

2. Password Resets

3. Enabling disabled User Accounts

4. Adding new Users to AD Groups

5. Deleting User Accounts

The Service Desk Manager is concerned because the top 5 requests the team deal with all require an advanced level of skills/knowledge that a number of the team do not have.  With the increased workload, the Service Desk Manager is concerned that the service provided by the Service Desk staff will be impacted and therefore has requested help from the IT Manager to help solve the problem.

The IT Manager has suggested the creation of a Self-Service portal for the Service Desk Analysts to use. The IT Manager recommends that the portal start with just a single catalog item to help the Service Desk Analysts create and manage new User Accounts.


Logging in to vRealize Automation


In this lesson we are going to go through the basics of logging into vRealize Automation.


 

Open Chrome Browser from Windows Quick Launch Task Bar

 

  1. Click on the Chrome Icon on the Windows Quick Launch Task Bar.

 

 

Launch vRealize Automation

 

From within the Chrome web browser:

  1. Click vRealize Automation from the bookmarks bar.

 

 

Log in to vRealize Automation

 

At the Workspace ONE login screen, assuming corp.local is the active domain, we can log straight in:

  1. Enter holadmin into the username field.
  2. Enter VMware1! into the password field.
  3. Click Sign In.

 

Reset the Resources for the Module


To support the number of different Modules using the same HOL environment means it is necessary to reset resources so that we can complete this module.


 

Launching the Code Stream Service

 

From within the Cloud Services Console, under My Services:

  1. Click the Code Stream service.

 

 

Run the Reset Resources Pipeline

 

We are going to run the Code Stream Pipeline to Reset the HOL environment.

  1. Click Pipelines.
  2. Locate the Reset Resources pipeline and click RUN.

 

 

Execute the Pipeline

 

At the Execute Reset Resources dialog:

  1. Click RUN.

 

 

View the Pipeline Execution

 

We are going to monitor the pipeline so we know when it completes.

  1. Click ACTIONS.
  2. Click View Executions.

 

 

Wait for the Pipeline to Complete

 

  1. Wait for the execution to be completed.

 

 

Switch to the Cloud Services Console

 

  1. Click the 9-dot icon.
  2. Click Cloud Services Console.

 

The New User Request Workflow


After discussions with the IT Manager, the Cloud Administrator successfully configures the the Active Directory Plug-In for vRealize Orchestrator and then creates a new vRealize Orchestrator workflow called New User Request to support the IT Service Desk Portal's main use case.

Within this lesson of the Module, we will be reviewing the New User Request workflow so we can get an idea of how the solution is brought together.

The main vRealize Automation service we will be using is Orchestrator.


 

Launching the Orchestrator Service

 

From within the Cloud Services Console, under My Services:

  1. Click the Orchestrator service.

 

 

Navigate to Workflows

 

  1. Click Workflows.

 

 

Navigate to the New User Request Workflow

 

  1. Click Tree-View icon.
  2. Expand the HOL folder.
  3. Expand the 2121-04 folder.
  4. Click the New User Request workflow.

 

 

New User Request: Variables

 

  1. Click the Variables tab.

We can see the New User Request workflow has two variables, newADUser and err_0.  

1. The newADUser variable is created by the Create a user with a password in an organizational unit workflow and used to store the AD:User object so it can be used by different parts of the workflow.  

2. The err_0 variable is used to store the string value of the exception.

 

 

New User Request: Input/Outputs

 

  1. Click the Inputs/Outputs tab.

We can see the New User Request workflow has a number  of inputs but only one output.  

1. The newADUser variable is created by the Create a user with a password in an organizational unit workflow and used to store the AD:User object so it can be used by different parts of the workflow.  

2. The err_0 variable is used to store the string value of the exception.

 

 

New User Request: Schema

 

  1. Click the Schema tab.

 

 

New User Request: Schema Walkthrough

 

To keep the solution simple and easy to maintain, the Cloud Administrator uses the following components in the new workflow:

1. The Create a user with a password in an organizational unit out of the box workflow that returns an AD:User object.

2. A decision to check if the firstName has been completed entered in the form.

3. A new Action with two inputs: adUser (AD:User) and firstName (string) and, apart from some logging code, has a single line of code:

adUser.setAttribute("givenName", firstName);

4. A decision to check if the lastName has been completed entered in the form.

5. A new Action with two inputs: adUser (AD:User) and lastName (string) and, apart from some logging code, has a single line of code:

adUser.setAttribute("sn", lastName);

6. A decision to check if the emailAddress has been completed entered in the form.

7. A new Action with two inputs: adUser (AD:User) and emailAddress (string) and, apart from some logging code, has a single line of code:

adUser.setAttribute("mail", emailAddress);

8. A Scriptable Task that ensures the variable being passed between the different components of the script is the returned object of the workflow.

We can take the time to review each script, action or workflow.  When you are ready, we can move onto the next lesson.

For more information on how to create vRealize Orchestrator workflows, be sure to check out HOL-2121-06-CMP.

 

Adding vRealize Orchestrator Workflows to the vRealize Automation Service Broker


In this lesson of the Module, we will import an existing vRealize Orchestrator workflow into Service Broker and publishing it as a Service Catalog item to a Project to support the Service Desk use case.

Within this lesson the main vRealize Automation service we will be using is Service Broker.


 

Switch to the Service Broker

 

  1. Click the 9-dot icon.
  2. Click Service Broker.

 

 

Navigate to Content Sources

 

Before we create a new Content Source, let us just recap on what they are.  

A Content Source is created to enable the import of templates or integrations into the service catalog.  A Content Source can only contain one type of content.  After you add a Content Source, templates are refreshed every six hours and any changes to the templates in the external sources are reflected in the catalog after it is refreshed.  If you are adding a new template or want to see the changes in existing templates before the default refresh, you can click Save and Import to refresh the Content Source.  If the template is new, you must also share the content.

To enable us to import vRealize Orchestrator workflows into the Service Broker and use them as Catalog Items for different Projects, we first need to create a Content Source.

  1. Click Content & Policies
  2. Click Content Sources
  3. Click New

 

 

Select the Content Source Type

 

 

As part of the Service Desk project we are going to be importing vRealize Orchestrator workflows into Service Broker, so that is the type we need to select.

At the Content Sources screen:

  1. Click the vRealize Orchestrator Workflow icon.

 

 

Name the Content Source

 

It is important that we make the name of a Content Source descriptive.  After-all as you add more content into vRealize Automation, there needs to be an easy way to identify the right source if we're troubleshooting or adding new content.

From within the New Content Source screen:

  1. At the Name field, type Service Desk Workflows.
  2. Click ADD.

 

 

Add the vRealize Orchestrator Workflow

 

In our deployment we will be using the embedded vRealize Orchestrator, but external vRealize Orchestrator content is also supported.  There are literally hundreds of out of the box workflows, so it is important to make sure the name of your workflow is also descriptive.  Rather than scrolling down to find the workflow(s) we can use the search filter to reduce the number of displayed workflows.

To filter the list of available workflows:

  1. Type New User Request into the search field and press Enter.
  2. Check the checkbox for the New User Request workflow.
  3. Click ADD.

 

 

Create the Content Source

 

Now that we have added all the content we needed, we can go ahead and create the content source and import the content.  

  1. Click CREATE & IMPORT to finalize the creation of the Content Source.

Should we need to add or remove vRealize Orchestrator workflows at a later date, we can come back to the Content Source and make the changes here.

 

 

Configure Content Sharing to a Project

 

Now that we have created the Content Source, we then need to decide which Project(s) we would like to share our Content with.  We also can decide whether to share all of the content in a Content Source or just some of it.  Without sharing any content to a project, the Service Broker catalog for users within that project would not contain any items.

  1. Click Content Sharing.
  2. At the Project field, type Service and then select the Service Desk Project.
  3. Click ADD ITEMS.

 

 

Select which content to Share with the Project

 

When you filter by CONTENT SOURCE, it is important to understand that all the content within the source are shared. To share individual items of content from within available Content Sources, you must filter by ALL CONTENT.  Finally, whilst not relevant for our lesson, if the content source is Cloud Assembly Blueprints, the content list only includes those Blueprints that are associated with the Project or that have been configured as shared Blueprints.

As the Content Source only includes one workflow, we can import the whole Content Source:

  1. Check the Service Desk Workflows checkbox.
  2. Click Save.

 

 

Test the Service Catalog Item

 

Now we have imported and shared some content to the Service Broker catalog, we really need to check to make sure if everything is as expected.  

  1. Click Catalog.

We now have a new catalog item, with a vRealize Orchestrator icon displayed, called New User Request.

  1. Click REQUEST.

 

 

Start the Request Form

 

Before we do anything else, we need to test to make sure the workflow actually works through Service Broker. We do this by completing the mandatory fields in the request form. See if you can spot the issue we will fix in the next lesson.

  1. At the Deployment Name field, type Test User Request 1.
  2. At the Project dropdown, select Service Desk Project.
  3. At the Last Name field, type User1.
  4. At the Password field, type VMware1!.
  5. At the First Name field, type Test.
  6. At the Username field, type test.user1.

 

 

Complete the Request Form

 

As we scroll down on the New Request screen, we can fill out the rest of form:

  1. At the Display Name field, type Test User1.
  2. At the Organizational Unit field, type Users and then select the Users OU.
  3. At the Email Address field, type test.user1@corp.local.
  4. At the Confirm Password field, type VMware1!.
  5. Click SUBMIT to start the deployment.

Now we have filled out the default request form for the catalog item, can you see what the problem was? The order in which the fields (or Workflow Inputs) have appeared in the form need to be changed to make it more usable for the end user.

We will be doing that in the next lesson,

But before we get to that, we need to check to make sure the deployment was successful!

 

 

Checking the Deployment

 

When clicked Submit, we were automatically redirected to the Deployments tab within Service Broker.  From here we can monitor the deployment that is in progress.  After a small amount of time, we can see that the deployment completed successfully and a new resource has been created within the Service Desk project.

But did the deployment actually create the requested user object in Active Directory? Lets go find out.

 

 

Check the Active Directory User

 

  1. Click the Active Directory Users and Computers icon to open the application.

 

 

Checking the new User in Active Directory Users and Computers

 

Within Active Directory Users and Computers, we are going to check that the user account from the request has not only been created, but we are also going to make sure it is in the right Organizational Unit (OU) and the User Attributes have been set:

  1. Select and expand the corp.local domain.
  2. Select and expand the HOL OU.
  3. Select the Users OU.
  4. Double click on test.user1 to open the User Properties dialog.

 

 

Active Directory User Properties Dialog

 

Finally we need to check to make sure all of the additional attributes in the New User Request workflow have set the AD User attributes correctly:

  1. Check the First name field is set to Test.
  2. Check the Last name field is set to  User1.
  3. Check the E-mail field is set to test.user1@corp.local.
  4. Click Cancel.

Now we have checked the user account is in the correct OU and is configured as expected, minimize the Active Directory Users and Computers application and switch back to the Service Broker service.

 

Scenario: Service Desk - Update


After successfully demonstrating the basic solution created in the previous lesson to the IT Manager, there was lots of positive feedback about the progress made but it was agreed that the catalog item needed some work to make it usable.

The feedback from the Service Desk Manager included the following suggestions based on the processes the Service Desk currently use now for creating new user accounts:

1. The user display name always has the following format; <first name> <last name>.

2. The user email address always has the same format, <username>@<domain name>.

3. The user should always be placed into the Users OU, but sometimes get put into the Users container and then have to be moved afterwards.


Customising the Service Broker Catalog Item


In this lesson you will be working as the Cloud Administrator to update the New User Request catalog item to create a Service Broker Custom Form.  In addition, you will update the default icon to use a an icon that will make the New User Request easier to locate within the catalog.

With the Custom Form, we are going to make the following changes:

1. Move Input Fields around so they are in a logical order and fit on one screen.

2. Make the Display Name field a Read-Only field based on the first and last name of the new user.

3. Make the Email Address field a Read-Only field based on the username and domain name.

4. Set a default value for Organizational Unit field and hide it because it never needs to change.

Within this lesson the main vRealize Automation service we will be using is Service Broker.


 

Open the Custom Form editor

 

 

Moving the First Name and Display Name Input Fields

 

Within the Custom Form canvas, you can drag and drop the inputs around to make them more logical.  The canvas is essentially split into 3 columns.  By default all of the fields are in Column 1.

  1. Click the First Name field and drag and drop it onto the Last Name field so that the Last Name field moves over to Column 2.
  2. Click the Display Name field and move (drag) it under the First Name field.

 

 

Change the First Name to a Mandatory Field

 

  1. Click the First Name field.
  2. Click the Constraints tab.
  3. Click Required dropdown.
  4. Select Yes

 

 

Change the Last Name to a Mandatory Field

 

  1. Click the Last Name field.
  2. Click the Constraints tab.
  3. Click Required dropdown.
  4. Select Yes.

 

 

Change the Display Name to a Computed Field

 

When creating a form, we want the user to fill out only the fields they need to.  In this instance we're going to make the Display Name input field a computed value field consisting of the First Name, Last Name and a space.

  1. Click the Display Name input field.
  2. Select Values.
  3. Click > to expand Default Value.
  4. Select Computed Value from the Value source dropdown.
  5. Select Concatenate from the Operator dropdown.
  6. Click ADD VALUE.

 

 

Change the Display Name to a Computed Field

 

First we add the value of the First Name field to the computed value, then we add the <space>.

  1. Select Field from the dropdown.
  2. Select First Name from the Field dropdown.
  3. Click ADD VALUE.
  4. Select Constant from the dropdown
  5. Type <space> into the field.

 

 

Change the Display Name to a Computed Field

 

Then we add the value of the Last Name field. This will make the Display Name field, show <First Name> <space> <Last Name>.

  1. Click ADD VALUE.
  2. Select Field from the dropdown.
  3. Select Last Name from the Field dropdown.

 

 

Change the Display Name to a Read Only Field

 

Finally, because we now have configured computed value, we are going to change the Display Name field to a Read Only field so it cannot be changed by the user.

  1. Select the Appearance tab.
  2. Change the value for Read-only dropdown to Yes.

 

 

Finalizing the placement of the Input Fields

 

  1. Move the Username field under the Display Name field.
  2. Move the Domain Name field to be next to the Username field
  3. Move the Confirm Password field under the Password field.
  4. Move the Change Password At Next Logon checkbox next to the Confirm Password field.

 

 

Configure the Organization Unit Field's Default Value

 

As we outlined at the start of the lesson, as the Organizational Unit (OU) is always going to be the Users OU, we're going to select the default value and then hide the field.

  1. Select the Organizational Unit field.
  2. Select the Values tab.
  3. In the Default Value field, type Users.
  4. Select Users from the available options.

 

 

Change the Visibility of the Organization Unit Field

 

The next step is to hide the Organizational Unit input field so it does not show on the request form.

  1. Select the Appearance tab.
  2. Click the Visibility dropdown.
  3. Select No.

How do we know this is actually going to choose the Users OU rather than the default Users Container within Active Directory.  If you check out the Reference type of the input, this is set to  AD:Organizational.Unit which is a different construct to a AD Container.  There isn't actually a vRealize Orchestrator Type for AD Container, so you would just see the Reference type being set to Any.

 

 

Change the Domain Name Field to a Dropdown

 

  1. Select the Domain Name field.
  2. Select the Appearance tab.
  3. Select DropDown from the Display type dropdown.

 

 

Enter Static Values for the Dropdown

 

  1. Select the Values tab.
  2. Click > to expand Value options.
  3. At the Value source field, type corp.local|corp.local.

 

 

Change the Domain Name to a Mandatory Field

 

  1. Click the Constraints tab.
  2. Click Required dropdown.
  3. Select Yes.

 

 

Configure Confirm Password Matching

 

We are now going to configure the Confirm Password field so that the value inputed matches the value used in the Password field.  After all, they need to be the same!

  1. Select the Confirm Password field.
  2. Select the Constraints tab.
  3. Click the Match field dropdown.
  4. Select Password as the field to match.

 

 

Change the Email Address Field to a Computed Field

 

  1. Select the Email Address field.
  2. Select the Values tab.
  3. Click > to expand Default Value.
  4. Select Computed Value from the Value source dropdown.
  5. Select Concatenate from the Operator dropdown.

 

 

Start the Computed Value for Email Address

 

  1. Click ADD VALUE.
  2. Select Field from the dropdown.
  3. Select Username from the Field dropdown.

 

 

Complete the Computed Value for Email Address

 

  1. Click ADD VALUE.
  2. Type @ in the constant field.
  3. Click ADD VALUE.
  4. Select Field from the dropdown.
  5. Select Domain Name from the Field dropdown.

 

 

Change the Email Address to Read-Only

 

  1. Select the Appearance tab.
  2. Select Yes from the Read-only dropdown.

 

 

Enable the Custom Form

 

We now need to enable the Custom Form so that it shows at request time:

  1. Click ENABLE.

 

 

Save the Custom Form

 

Before we move on we need to ensure we save all the changes that have been made.

  1. Click Save.

 

 

Updating the Icon of a Catalog Item in Service Broker

 

The last thing we are going to do before we test the final Catalog Item is to update the Icon that displays in Service Broker.  The main reason for doing this is because all vRealize Orchestrator catalog items all have the same icon which can make it time consuming to find the right workflow to run!  With only one catalog item,  we could have decided not to change it, but it is a good habit to get into. From within Service Broker:

  1. Click Content & Policies.
  2. Click Content.

Locate the New User Request workflow, then:

  1. Click the 'three vertical dots' icon.
  2. Click Configure Item.

 

 

Configure the Catalog Item Icon

 

  1. Click CHANGE ICON.

 

 

Select the Icon file

 

  1. Navigate to C:\hol-2121-lab-files\labfiles\HOL-2121-04-CMP\.
  2. Click New User Request.png.
  3. Click Open.

 

 

Save the Catalog Item

 

  1. Click SAVE.

 

 

Testing Deployment with the New Custom Form in Service Broker

 

From within Service Broker:

1. Click Catalog.

Locate the New User Request Catalog item.

  1. Click REQUEST.

 

 

Complete the Request Form - Part 1

 

  1. At the Deployment Name field, type Test User Request 2.
  2. Ensure that Service Desk is selected from the Project dropdown.
  3. At the First Name field, type Test.
  4. At the Last Name field, type User2.

 

 

Complete the Request Form - Part 2

 

  1. At the Username field, type test.user2.
  2. Select corp.local from the Domain Name dropdown.
  3. At the Password field, type VMware1!.
  4. At the Confirm Password field, type VMware1!.
  5. Click SUBMIT.

As we work through the new request form, it is clear there is a more logical flow to it.  This will definitely make it easier for the Service Desk Analysts to use.

 

 

Checking the Deployment

 

We can now see that we have two successful deployments.  One within the original request form and one with the Custom Form applied.  Time to tidy up the deployment made during testing.

 

Cleaning up the Deployments


In this short lesson we are going to be cleaning up our existing deployments so we can move onto the next lesson.


 

Delete the Deployments from Service Broker

 

If you are not already on the Deployments tab.

  1. Click the Deployments tab.

Locate the Test User Request 2 deployment.

  1. Click the Actions menu.
  2. Select Delete.

 

 

Confirm Deletion

 

When prompted to confirm the deletion.

  1. Click SUBMIT.

Complete the same process to also delete the Test User Request 1 deployment.

 

 

Open Active Directory Users and Computers

 

  1. Click the Active Directory Users and Computers icon to open the application.

 

 

Checking Active Directory

 

Now we need to check to make sure the Active Directory objects for the deployments have been removed.

  1. Click corp.local to expand the domain.
  2. Click the HOL OU to expand it
  3. Click the Users OU.

As you have found, when we delete our deployments in Service Broker, the Active Directory objects will not be deleted.  Why?  The reason behind this is that we are creating resources/objects that are external to vRealize Automation and are not being managed within vRealize Automation.  To delete those objects using vRealize Orchestrator catalog items, we would need to import and run an associated "delete" object workflow.  In the example of Active Directory users, we could import the aptly named "Destroy a User" workflow from vRealize Orchestrator and select the object as part of the request.

 

 

Deleting the Test User Accounts

 

  1. Highlight each of the accounts to be deleted.
  2. Click the X to delete.
  3. When prompted to confirm the deletion, click Yes.

 

 

Scenario: Service Desk - Update


The Service Desk Manager is really pleased with the new Service Desk Portal that has been created for the Service Desk Analysts.  There been an increase in productivity throughout the team because the portal has allowed the task that is generating the largest number of calls (Creating new User Accounts) to be completed by junior members.  

The Service Desk Manager is trying to understand whether some of the other tasks in his top five list can be automated to help further increase the teams productivity.

To recap, the top 5 requests to the Service Desk are:

1. Creating new User Accounts

2. Password Resets

3. Enabling disabled User Accounts

4. Adding new Users to AD Groups

5. Deleting User Accounts


After talking to the Cloud Administrator in the team, the IT Manager informs the Service Desk Manager that with just a few changes, the Service Desk Analysts will be able to complete all of the top 5 requests for new users through the Service Desk portal.


Creating XaaS Custom Resources in vRealize Automation


In this lesson we are going to see how we can use Custom Resources to create and manage external items/resources as custom objects within vRealize Automation.

Working as the Cloud Administrator, we're going to complete the following tasks in support of the Service Desk:

1. Create an Active Directory User Custom Resource with the following workflows:

- New User Request

- Destroy A User.

2. Assign the four Custom Day 2 Actions using vRealize Orchestrator Workflows:

- Enable User

- Disable User

- Change User Password

- Add User to Group

Within this lesson the main vRealize Automation service we will be using is Cloud Assembly.


 

Switch to the Cloud Assembly Service

 

  1. Click the 9-dot icon.
  2. Click the Cloud Assembly service.

 

 

Navigate to the Design Tab

 

From within the Cloud Assembly service:

  1. Click Design.
  2. Click Custom Resources.
  3. Click NEW CUSTOM RESOURCE.

 

 

Create New Custom Resource

 

Here we fill out the basic information for the new Custom Resource. We need to give it a descriptive name so it is easy to see at a glance what it is used for.  We need to decide on the naming convention we are going to use for the resource type (this is especially important if we need to drag this onto the Blueprint Canvas).  The advice is to keep it simple! We are going to user dot notation to separate out AD and User (i.e. Custom.AD.User) because if we needed to create a Custom Resource for AD Groups, we could use the same naming convention (i.e. Custom.AD.Group) to keep it consistant.  We will then specify which external resource type to map the Custom Resource type back to in vRealize Orchestrator.

  1. At the Name field, enter Active Directory User.
  2. At the Resource Type field, type Custom.AD.User.
  3. At the External Type field, type AD:User.
  4. Slide the Activate toggle to the on position.

 

 

Add the Lifecycle Actions to the Custom Object

 

Now we are going to choose the vRealize Orchestrator workflows that will be run when we choose to Create or Destroy the Custom Resource object within vRealize Automation as part of a deployment or Day 2 action.

  1. At the Create field, click + ADD.

 

 

Select the Create vRealize Orchestrator Workflow

 

To filter the list of available workflows:

  1. Enter New User Request into the search field and press Enter.
  2. Select the option for the New User Request workflow.
  3. Click ADD.

 

 

Add the Destroy vRealize Orchestrator Workflow

 

  1. At the Destroy field, click ADD.

 

 

Select the right workflow

 

  1. At the search filter, type Destroy and press Enter.
  2. Locate and select the Destroy a User workflow.
  3. Click ADD.

 

 

Add Change a User Password Action

 

  1. Under the Additional actions section, Click ADD.

 

 

Configure the Change a User Password Action

 

  1. At the Workflow search field, type Change a user password and then select the subsequent workflow in the list.
  2. At the Name field, type Change A User Password.
  3. At the Menu label field, type Change Password.
  4. Click ADD.

 

 

Add the Enable A User Action

 

  1. Click ADD.

 

 

Configure the Enable A User Action.

 

  1. At the Workflow search field, type Enable a User and then select the Enable a User workflow from the list.
  2. At the Name field, type Enable a User.
  3. At the Menu label field, type Enable.
  4. Click ADD.

 

 

Add the Disable a User Action

 

  1. Click ADD.

 

 

Configure the Disable a User Action

 

  1. At the Workflow search field, type Disable a User and then select the Disable a User workflow from the list.
  2. At the Name field, type Disable A User.
  3. At the Menu label field, type Disable.
  4. Click ADD.

 

 

Add the Add a User to User Group Action

 

  1. Click ADD.

 

 

Configure the Add a User to User Group Action

 

  1. At the Workflow search field, type Add a user and then select the Add a user to a user group workflow from the list.
  2. At the Name field, type Add A User To A Group.
  3. At the Menu label field, type Add To Group.
  4. Click ADD.

 

 

Create the Custom Resource Object

 

Now that we have configured all the Day 2 action operations workflows, we can finally create the Custom Resource!

  1. Click CREATE.

 

 

Logout of vRealize Automation

 

In the next lesson we will be demonstrating the work to the Service Desk Manager, so we can sign out of vRealize Automation as the Administrator.

  1. Click on the Admin HOL user name.
  2. Click SIGN OUT.

 

Demonstrating to the Service Desk Manager


In this lesson we will be walking through the solution we have built as if you were giving a demonstration to the Service Desk Manager.


 

Launch vRealize Automation

 

From within the Chrome web browser:

  1. Click vRealize Automation from the bookmarks bar.

 

 

Log in to vRealize Automation

 

At the Workspace ONE login screen:

  1. At the username field, type holservicedesk.
  2. At the password field, type VMware1!.
  3. Click Sign In.

 

 

Launch the Service Broker Service

 

From within the Cloud Services Console, under My Services:

  1. Click the Service Broker service.

 

 

Demonstrate User Provisioning

 

  1. Click Catalog.

Locate the New User Request Catalog item.

  1. Click REQUEST.

 

 

Demonstrate Day 2 Actions

 

We are now going to demonstrate the available Day 2 options to the Service Desk Manager.

  1. Click Topology.
  2. Click the Active Directory User object on the canvas.

 

 

Open Active Directory Users and Computers

 

  1. Click the Active Directory Users and Computers icon to open the application.

 

Scenario: App-Dev Team


After the successful demonstration to the Service Desk Manager, the Service Desk 1.0 Portal has been successfully rolled out and productivity in that part of the business has increased. The Service Desk Manager has already spoken to the IT Manager about tackling other user related service requests, including:

1. Creating & Managing new AD Groups

2. Managing membership of existing AD Groups

3. Managing existing user accounts (enable, disable, password changes, deletions)

It seems the Service Desk Manager really gets the value proposition of vRealize Automation and XaaS.

In fact, the Service Desk Manager happened to mention to the App-Dev Manager what a wonderful job the IT Team had done and that the company now had a way of creating an Active Directory User in an automated and controlled fashion through a Self-Service Portal.

On hearing this, the App-Dev Manager reached out to the IT Manager about a use-case his team has for creating an Active Directory account as part of blueprint deployment.  The App-Dev manager has asked for a quick demonstration on how that could work. 


Adding a Custom Resource to the Blueprint Canvas in Cloud Assembly


In this final lesson of the Module, we are going to demonstrate the one of key capabilities of the Custom Resource.  We are going to demonstrate to the App-Dev team how they can add the Active Directory User Custom Resource we created in the previous lessons into a Cloud Assembly blueprint and treat it like any other out of the box resource type that is natively support in vRealize Automation.

To successfully complete this lesson, you must have completed the Creating XaaS Custom Resources in vRealize Automation lesson.

Within this lesson the main vRealize Automation service we will be using is Cloud Assembly.


 

Launch vRealize Automation

 

From within the Chrome web browser:

  1. Click vRealize Automation from the bookmarks bar.

 

 

Log in to vRealize Automation

 

At the Workspace ONE login screen, assuming corp.local is the active domain, we can log straight in:

  1. Enter holadmin into the username field.
  2. Enter VMware1! into the password field.
  3. Click Sign In.

 

 

Launch the Cloud Assembly Service

 

From within the Cloud Services Console, under My Services:

  1. Click the Cloud Assembly service.

 

 

Open the App-Dev Demo Blueprint

 

  1. Click the Design tab.
  2. Click Blueprints.
  3. Click the App-Dev Demo Blueprint.

 

 

Drag the Active Directory User Custom Resource to the Canvas

 

We are now going to add the Active Directory User Custom Resource object we created in a previous lesson onto the Blueprint Canvas.

  1. At the Resource Type search field, type User and press Enter.
  2. Locate the Active Directory User Custom Resource under Custom Resources.
  3. Drag and Drop the Custom Resource object onto the canvas.

 

 

Create a Dependency from the Virtual Machine to the Custom Resource

 

We are going to add a dependency between the vSphere Machine and the custom Active Directory User object so that.

  1. Click the small dot on the ubuntu machine
  2. Drag it onto the Custom Resource object.
  3. Check the code window to make sure the dependsOn property is added to the ubuntu resource.

 

 

Add the Input Parameter for Password

 

We are now going to update the value of the password property with to use an input call password.  The password input has already been declared in the inputs section of the blueprint yaml file.

  1. At the Custom Resource type password property, type '${input.password}'.

 

 

Add the confirmPassword Property

 

We are now going to add the the confirmPassword property to the Custom Resource.  Whilst this property is not a mandatory field within the original vRealize Orchestrator workflow, the workflow fails without it!

  1. Press Enter to start a new line.
  2. Select confirmPassword from the available properties.

 

We are going to configure this Blueprint so that the confirmPassword property uses the same input value as the Password property.  This means we'll only have one password field to fill out in the form.

  1. At the Custom Resource type confirmPassword property, type '${input.password}'.

 

 

Fill out the other Custom Resource properties

 

  1. Update the custom resource properties with the following values:
    • accountName = '${input.accountName}'.
    • displayName = '${input.displayName}'.
    • ouContainer = '${input.ouContainer}'.

 

 

Demonstrate the Deployment from the Blueprint Canvas

 

Now we have configured all the properties to have input values we are ready to demonstrate the deployment.

  1. Click DEPLOY.

 

 

Configure Deployment Type

 

  1. At the Deployment Name field, type App-Dev Demo.
  2. At the Blueprint Version field, select Current Draft.
  3. Click NEXT.

 

 

Enter the Deployment Inputs

 

  1. At the Account Name field, type app-dev-service.
  2. At the Display Name field, type app-dev-service.
  3. At the Password field, type VMware1!
  4. At the AD OU container field, type Users.
  5. Select Users from the list of results.
  6. Click DEPLOY.

Wait for the deployment to complete.

 

 

Check the Deployed Resources

 

As we can see from the Deployment's Topology view, both the user account and virtual machine were deployed successfully.  We can now manage the user account that has been created as part of this deployment just like it was any other resource type using the custom day 2 actions that we defined within the Custom Resource configuration.

  1. Click the Custom_AD_User Object.
  2. Click the Actions menu to show the available Day 2 Actions.

 

 

Delete the Deployment

 

We are now going to delete the deployment.

  1. Click the ACTIONS menu.
  2. Select Delete.

 

Conclusion


Congratulations on completing  Module 7.

In this Module we have discovered the final two use cases for Anything As A Service (XaaS) supported by vRealize Automation.  

As a recap, using the Service Desk and App-Dev scenarios, we have walked through:

1. Publishing a vRealize Orchestrator Workflow to the Service Broker Catalog to enable the creation/management of external objects and services.

2. Applying Custom Forms to a vRealize Orchestrator Workflow in the Service Catalog Item to make it easier to consume by the end user.

3. Creating Custom Resources so that the vRealize Orchestrator workflow creates an object that can be managed inside vRealize Automation.

4. Consuming Custom Resources on the Blueprint Canvas so that they can be included as part of a wider deployment.


 

You've finished the module

 

Congratulations on completing the lab module.

If you are looking for additional information on Custom Resources, go the VMware Documentation site for Custom Resources.

From here you can:

  1. Click to advanced to the next page and continue with the next lab module
  2. Open the TABLE OF CONTENTS to jump to any module or lesson in this lab manual
  3. Click on the END button if you are done with the lab for now and want to exit

 

 

Module 8 - ITSM Integration with ServiceNow (15 minutes)

Introduction


In this module, we will quickly cover the basics of integrating vRealize Automation with Service Now. 

The lab module will provide a brief overview of the following topics:



Hands-on Labs Interactive Simulation: ITSM Integration with ServiceNow


This part of the lab is presented as a Hands-on Labs Interactive Simulation. This will allow you to experience steps which are too time-consuming or resource intensive to do live in the lab environment. In this simulation, you can use the software interface as if you are interacting with a live environment.

  1. Click here to open the interactive simulation. It will open in a new browser window or tab.
  2. When finished, click the “Return to the lab” link to continue with this lab.

The lab continues to run in the background. If the lab goes into standby mode, you can resume it after completing the module.


Conclusion


In this module we walked through integrating vRealize Automation with Service Now.


 

You've finished the module

 

Congratulations on completing the lab module.

If you are looking for additional information on vRealize Automation, you can start here: 

https://www.vmware.com/products/vrealize-automation.html

From here you can:

  1. Click to advance to the next page and continue with the next lab module
  2. Open the TABLE OF CONTENTS to jump to any module or lesson in this lab manual
  3. Click on the END button if you are done with the lab for now and want to exit

 

 

Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-2121-04-CMP

Version: 20200814-201549