Software Components – Reusable Building Blocks
The Project Cava introduction blog mentions visually simple Converged Blueprints of Virtual Machines and Applications that can be deployed into various target platforms (vCenter, various Clouds etc.)
However, there is a complexity behind that simplicity: it resides in Software Components, building blocks of software provisioning (installation) process that gets executed by software installation agents. An ability to create software installation components as part of the new Converged blueprint design canvas is a new important functionality of VMWare vRealize Automation 7.x and it is extensively utilized in CMBU Project Cava.
The Introduction blog mentions that “The blueprint for vRealize Automation 7.0 fits in just 8 boxes”: each of those is an instance of a previously designed and published Software Component that is dynamically configured with input parameters and scripts to be executed during its software provisioning lifecycle. Order of invocation of Components is dictated by reverse direction of the arrows on the Design canvas: installation/configuration of a Component at the arrow head should complete in order for one at the arrow start to get invoked:
Fig. 1. Project Cava vRA 7.x converged blueprint showing order of invocation of included Software Components
In the screenshot above, Common component gets invoked first, then SLES-Update, then vRA-Server, then IaaS-Server (on a different VM), then vRA-ConfigIaaS (on same VM) and finally vRA-InstallQE.
Software Components have parameters that may be static or depend on values of parameters of Virtual Machines or other components. We use computed properties, property bindings, and content properties to dynamically populate values of these parameters to be used by software installation/configuration scripts.
In Project Cava we have an Infrastructure as a Service (IaaS) Software component of vRealize Automation blueprint that needs to be installed and configured after vRealize Virtual Appliance (vRA VA) is provisioned and configured.
There is a number of property values that need to be provided if vRA IaaS component get installed manually (via Interactive installer or silent Installer script), so they also need to be specified in a corresponding Component(s). Some of those properties are:
• vRA VA host name (FQDN)
• vRA VA root user name/password
• vRA VA appliance management port
• IaaS target host name (FQDN)
• IaaS Service user id/password for running services to be installed
• etc.
vRA 7.x Converged blueprint contains Software Component called “VMware-IaaS-Server-7.0” that has properties and scripts for initial installation and configuration of IaaS software modules.
Fig. 2. Software Component VMware IaaS-Server-7.0 properties
Each Property has Name, Description, Type and Value. Values can be Encrypted (e.g. Passwords) so they would not show in a Blueprint view. Other flags for properties are:
– Overridable: indicates whether supplied property value may be changed at run-time or not,
– Required: indicates whether a property has to have a value (entered or computed) in order to allow submission of Provisioning request,
– Computed: indicates whether a property value is computed during execution of the software component’s scripts. If Computed flag is set to Yes, other flags are set to No automatically since that parameter will not be displayed in a request form.
NOTE: Content type properties may also reference externally hosted scripts, for example from the above screen:
task_bootstrap Content http://<URL>/appd/task_bootstrap_7x7.sh
that would load a script content from an external (hosted in this case) URL location into task_bootstrap property for an execution.
In Actions section of a Component we can specify various Scripts that will be executed when that component is provisioned into a target “container” (VM or other type). Software lifecycle stages – Install, Configure, Start, Uninstall – may each have different scripts that will to be invoked when that stage becomes active. These scripts can use static or computed values using other parameters’ value (see “select property to insert” script editing option below) and can also call other scripts passing these parameter values as input.
Fig. 3. Software Component IaaS-Server-7.0 Install script editor showing property selector
This example shows assignment of value of install_script_path parameter to a variable called script_path and then copying value of %task_bootstrap% environment variable into task_bootstrap.bat batch script and consequent execution.
When Software components are placed into “container” VMs in Converged Blueprints Designer, their properties can also be used in combination with those associated with VMs. Screenshot below shows properties of “IaaS-Server” component instance with or without Binding to other properties defined in a scope of blueprint.
Fig. 4. IaaS-Server-7.0 component using URL path to a resource stored in GIT repository for Configure and Install Script paths as well as values of other components.
In this example, properties domain_name, iaas_va_hostname, iaas_va-ip, lookup_hostname_override, ntp_servers are “bound” (i.e. assigned value of) to properties of other components placed into same VM called “vRA”.
In order to bind a Component parameter to other VM or Component level parameter values, click “Edit” button while parameter is highlighted, check “Binding” checkbox and either select pre defined property from a list or use “resource Object browser” to navigate hierarchy of properties by their parent objects as shown below:
Fig 5. Editing bound required custom properties by navigating “resource Object hierarchy”
Another very helpful tip to “externalize” actual scripts that will be executed for Install or Configure tasks is to actually use a URL of a script file stored under a version control system (GIT in case of Project Cava) as install_script_path and configure_script_path parameters have. More on that practice in a separate post.
Parameter scripts_basicauth_username is bound to a value of a parameter with the same name defined in the Common component, similarly ntp_servers parameter – to parameter with same name defined in Common because that component will be provisioned first during Request processing.
Note that the above parameters are Required even though they are not displayed in a Catalog request form since Show in Request flag is set to “no”.
Fig 6. Editing not bound required custom properties by typing in values
There is an option to use “globally defined” properties for Virtual Machines that can be defined in the vRA Administration section called Property Definitions with Label, Description, data type and display style. They can be reused for user input processing by various converged blueprints as gobuild_product_vrava_number and gobuild_product_vrva_type properties are shown below:
Fig 7. Tenant level Property definitions for common use in Converged Blueprint VM properties
How all That Complex Design Comes Together During Provisioning
All of that complex design/development work finally comes to realization when a Catalog request for a Blueprint containing Software components is submitted. After “Container” VMs are provisioned, Installation and Configuration scripts for these components get executed by Software Agents and results of execution first are available in temporary folders of vRA VA and then (if successful) – via Web UI.
Fig. 8. Reviewing order of VM and Software Components provisioning for Cava vRA 7.x completed request
Screenshot above shows that vRA and IaaS VMs got provisioned first, then Common, SLES-Update, vRA-Server and other Components get installed and configured according to defined order in the Container converged blueprint, as described above.
In order to review execution results of Install or Configure scripts, click on a elliptic icon near Component first and look into pop-up window containing Install and Configure tabs which display outputs produced by execution of those scripts:
Fig 9. Sample output of Configure script for IaaS-Server 7.0 component upon its completion
If there are no fatal errors in Components’ Install and Configure scripts, their execution results in fully configured and running vRA 7.x software system with basic Tenant set up that Project Cava users can use for their purposes.
Our Users Can Do This Too!
In Project Cava we have put some advanced vRA Converged Blueprint authoring techniques to work and built blueprints that through their Software components take advantage of external content, pass values between components and compute properties at a runtime without intermediate vRO workflows. This gives us and you as vRA users an opportunity to build complex application stacks that are installed and configured using reusable modular Software Components!
