7.1

Associating Network and Security Components
You can drag network and security components onto the design canvas to make their seings available for
machine component conguration in the blueprint. After you have dened network and security seings for
the machine, you can optionally associate seings from a load balancer component.
After you add an NSX network or security component to the canvas and dene its available seings, you can
open the network and security tabs of a vSphere machine component in the canvas and congure its
seings.
The network and security component seings that you add to the blueprint design canvas are derived from
your NSX conguration and require that you have installed the NSX plug-in and run data collection for the
NSX inventory for vSphere clusters. Network and security components are specic to NSX and are available
for use with vSphere machine components only. For information about conguring NSX, see NSX
Administration Guide.
For example, you can drag an on-demand NAT network component onto the blueprint's design canvas to
make it available for a vSphere machine component that is also present in the canvas.
Designing Software Components
As the software architect, you create reusable software components, standardizing conguration properties
and using action scripts to specify exactly how components are installed, congured, 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 dening 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 dened 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 dierent environments without modifying your scripts.
Table 4‑33. Life Cycle Actions
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
rst provisioned, either during an initial deployment request or as part of a scale out.
Congure Congure your software. For the Tomcat example, you might set the JAVA_OPTS and
CATALINA_OPTS. Conguration 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 congure 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 specic actions in the application
before a deployment is destroyed. Uninstall scripts run whenever software components are
destroyed.
Configuring vRealize Automation
290 VMware, Inc.