As the software architect, you create reusable software components, standardizing configuration properties and using action scripts to specify exactly how components are installed, configured, uninstalled, or updated during deployment scale operations. You can rewrite these action scripts at any time and publish live to push changes to provisioned software components.
You can design your action scripts to be generic and reusable by defining and consuming name and value pairs called software properties and passing them as parameters to your action scripts. If your software properties have values that are unknown or need to be defined in the future, you can either require or allow other blueprint architects or end users to provide the values. If you need a value from another component in a blueprint, for example the IP address of a machine, you can bind your software property to that machine's IP address property. Using software properties to parameterize your action scripts makes them generic and reusable so you can deploy software components on different environments without modifying your scripts.
|Life Cycle Actions||Description|
|Install||Install your software. For example, you might download Tomcat server installation bits and install a Tomcat service. Scripts you write for the Install life cycle action run when software is first provisioned, either during an initial deployment request or as part of a scale out.|
|Configure||Configure your software. For the Tomcat example, you might set the JAVA_OPTS and CATALINA_OPTS. Configuration scripts run after the install action completes.|
|Start||Start your software. For example, you might start the Tomcat service using the start command in the Tomcat server. Start scripts run after the configure action completes.|
|Update||If you are designing your software component to support scalable blueprints, handle any updates that are required after a scale in or scale out operation. For example, you might change the cluster size for a scaled deployment and manage the clustered nodes using a load balancer. Design your update scripts to run multiple times (idempotent) and to handle both the scale in and the scale out cases. When a scale operation is performed, update scripts run on all dependent software components.|
|Uninstall||Uninstall your software. For example, you might perform specific actions in the application before a deployment is destroyed. Uninstall scripts run whenever software components are destroyed.|
You can download predefined Software components for a variety of middleware services and applications from the VMware Solution Exchange. Using either the vRealize CloudClient or vRealize Automation REST API, you can programmatically import predefined Software components into your vRealize Automation instance.
- To visit the VMware Solution Exchange, see https://solutionexchange.vmware.com/store/category_groups/cloud-management.
- For information about vRealize Automation REST API, see Programming Guide and vRealize Automation API Reference.
- For information about vRealize CloudClient, see https://developercenter.vmware.com/tool/cloudclient.