You can use networking, security, and load balancer resources and settings in cloud template designs and deployments.
For a summary of cloud template design code options, see vRealize Automation Resource Type Schema.
These examples illustrate network, security, and load balancer resources within basic cloud template designs.
Networks
| Resource scenario | Example cloud template design code |
|---|---|
| vSphere machine with multiple NICs connected to vSphere and NSX networks with DHCP IP assignment | resources:
demo-machine:
type: Cloud.vSphere.Machine
properties:
image: ubuntu
flavor: small
networks:
- network: ${resource["demo-vSphere-Network"].id}
deviceIndex: 0
- network: ${resource["demo-NSX-Network"].id}
deviceIndex: 1
demo-vSphere-Network:
type: Cloud.vSphere.Network
properties:
networkType: existing
demo-NSX-Network:
type: Cloud.NSX.Network
properties:
networkType: outbound
|
NSX private network using the vlanIds property to specify an array of 3 VLANs - 123, 456, and 7 |
formatVersion: 1
inputs: {}
resources:
Cloud_Machine_1:
type: Cloud.Machine
properties:
image: test
flavor: test
networks:
- network: '${resource.Cloud_NSX_Network_1.id}'
Cloud_NSX_Network_1:
type: Cloud.NSX.Network
properties:
networkType: private
vlanIds:
- 123
- 456
- 7
|
| Add a private network with a static IP address for an Azure VM deployment | formatVersion: 1
inputs: {}
resources:
Cloud_Azure_Machine_1:
type: Cloud.Machine
properties:
image: photon
flavor: Standard_B1ls
networks:
- network: '${resource.Cloud_Network_1.id}'
assignment: static
address: 10.0.0.45
assignPublicIpAddress: false
Cloud_Network_1:
type: Cloud.Network
properties:
networkType: existing
|
| You can use a static IP assignment with vRealize Automation IPAM (internal as supplied with vRealize Automation or external based on the vRealize Automation IPAM SDK such as for one of the Infloblox plug-ins available in the VMware Marketplace). Other uses of |
resources:
demo_vm:
type: Cloud.vSphere.Machine
properties:
image: 'photon'
cpuCount: 1
totalMemoryMB: 1024
networks:
- network: ${resource.demo_nw.id}
assignment: static
demo_nw:
type: Cloud.vSphere.Network
properties:
networkType: existing |
Add or edit NAT and DNAT port forwarding rules in a Cloud.NSX.NAT resource for an existing deployment. |
resources:
gw:
type: Cloud.NSX.Gateway
properties:
networks:
- ${resource.akout.id}
nat:
type: Cloud.NSX.Nat
properties:
networks:
- ${resource.akout.id}
natRules:
- translatedInstance: ${resource.centos.networks[0].id}
index: 0
protocol: TCP
kind: NAT44
type: DNAT
sourceIPs: any
sourcePorts: 80
translatedPorts: 8080
destinationPorts: 8080
description: edit
- translatedInstance: ${resource.centos.networks[0].id}
index: 1
protocol: TCP
kind: NAT44
type: DNAT
sourceIPs: any
sourcePorts: 90
translatedPorts: 9090
destinationPorts: 9090
description: add
gateway: ${resource.gw.id}
centos:
type: Cloud.vSphere.Machine
properties:
image: WebTinyCentOS65x86
flavor: small
customizationSpec: Linux
networks:
- network: ${resource.akout.id}
assignment: static
akout:
type: Cloud.NSX.Network
properties:
networkType: outbound
constraints:
- tag: nsxt-nat-1-M2
|
| Public cloud machine to use an internal IP instead of a public IP. This example uses a specific network ID. Note: The |
resources:
wf_proxy:
type: Cloud.Machine
properties:
image: ubuntu 16.04
flavor: small
constraints:
- tag: 'platform:vsphere'
networks:
- network: '${resource.wf_net.id}'
assignPublicIpAddress: false |
| Routed network using the NSX network resource type. |
Cloud_NSX_Network_1:
type: Cloud.NSX.Network
properties:
networkType: routed |
| Add a tag to a machine NIC resource in the cloud template. | formatVersion: 1
inputs: {}
resources:
Cloud_Machine_1:
type: Cloud.vSphere.Machine
properties:
flavor: small
image: ubuntu
networks:
- name: '${resource.Cloud_Network_1.name}'
deviceIndex: 0
tags:
- key: 'nic0'
value: null
- key: internal
value: true
- name: '${resource.Cloud_Network_2.name}'
deviceIndex: 1
tags:
- key: 'nic1'
value: null
- key: internal
value: false |
| Tag NSX-T logical switches for an outbound network. Tagging is supported for NSX-T and VMware Cloud on AWS. For more information on this scenario, see community blog post Creating Tags in NSX with Cloud Assembly. |
Cloud_NSX_Network_1:
type: Cloud.NSX.Network
properties:
networkType: outbound
tags:
- key: app
value: opencart
|
Security groups
| Resource scenario | Example cloud template design code |
|---|---|
| Existing security group with a constraint tag applied to a machine NIC. To use an existing security group, enter existing for the securityGroupType property. You can assign tags to a Cloud.SecurityGroup resource to allocate existing security groups by using tag constraints. Security groups that do not contain tags cannot be used in the cloud template design. Constraint tags must be set for |
formatVersion: 1
inputs: {}
resources:
allowSsh_sg:
type: Cloud.SecurityGroup
properties:
securityGroupType: existing
constraints:
- tag: allowSsh
compute:
type: Cloud.Machine
properties:
image: centos
flavor: small
networks:
- network: '${resource.prod-net.id}'
securityGroups:
- '${resource.allowSsh_sg.id}'
prod-net:
type: Cloud.Network
properties:
networkType: existing |
| On-demand security group with two firewall rules illustrating the |
resources:
Cloud_SecurityGroup_1:
type: Cloud.SecurityGroup
properties:
securityGroupType: new
rules:
- ports: 5000
source: 'fc00:10:000:000:000:56ff:fe89:48b4'
access: Allow
direction: inbound
name: allow_5000
protocol: TCP
- ports: 7000
source: 'fc00:10:000:000:000:56ff:fe89:48b4'
access: Deny
direction: inbound
name: deny_7000
protocol: TCP
Cloud_vSphere_Machine_1:
type: Cloud.vSphere.Machine
properties:
image: photon
cpuCount: 1
totalMemoryMB: 256
networks:
- network: '${resource.Cloud_Network_1.id}'
assignIPv6Address: true
assignment: static
securityGroups:
- '${resource.Cloud_SecurityGroup_1.id}'
Cloud_Network_1:
type: Cloud.Network
properties:
networkType: existing
|
|
Complex cloud template with 2 security groups, including:
This sample illustrates different combinations of protocols and ports, services, IP CIDR as source and destination, IP range as source or destination, and the options for any, IPv6, and (::/0). For machine NICs, you can specify the connected network, and security group(s). You can also specify the NIC index or an IP address. |
formatVersion: 1
inputs: {}
resources:
DEMO_ESG : existing security group - security group 1)
type: Cloud.SecurityGroup
properties:
constraints:
- tag: BlockAll
securityGroupType: existing (designation of existing for security group 1)
DEMO_ODSG: (on-demand security group - security group 2))
type: Cloud.SecurityGroup
properties:
rules: (multiple firewall rules in this section)
- name: IN-ANY (rule 1)
source: any
service: any
direction: inbound
access: Deny
- name: IN-SSH (rule 2)
source: any
service: SSH
direction: inbound
access: Allow
- name: IN-SSH-IP (rule 3)
source: 33.33.33.1-33.33.33.250
protocol: TCP
ports: 223
direction: inbound
access: Allow
- name: IPv-6-ANY-SOURCE (rule 4)
source: '::/0'
protocol: TCP
ports: 223
direction: inbound
access: Allow
- name: IN-SSH-IP (rule 5)
source: 44.44.44.1/24
protocol: UDP
ports: 22-25
direction: inbound
access: Allow
- name: IN-EXISTING-SG (rule 6)
source: '${resource["DEMO_ESG"].id}'
protocol: ICMPv6
direction: inbound
access: Allow
- name: OUT-ANY (rule 7)
destination: any
service: any
direction: outbound
access: Deny
- name: OUT-TCP-IPv6 (rule 8)
destination: '2001:0db8:85a3::8a2e:0370:7334/64'
protocol: TCP
ports: 22
direction: outbound
access: Allow
- name: IPv6-ANY-DESTINATION (rule 9)
destination: '::/0'
protocol: UDP
ports: 23
direction: outbound
access: Allow
- name: OUT-UDP-SERVICE (rule 10)
destination: any
service: NTP
direction: outbound
access: Allow
securityGroupType: new (designation of on-demand for security group 2)
DEMO_VC_MACHINE: (machine resource)
type: Cloud.vSphere.Machine
properties:
image: PHOTON
cpuCount: 1
totalMemoryMB: 1024
networks: (Machine network NICs)
- network: '${resource.DEMO_NW.id}'
securityGroups:
- '${resource.DEMO_ODSG.id}'
- '${resource.DEMO_ESG.id}'
DEMO_NETWORK: (network resource)
type: Cloud.vSphere.Network
properties:
networkType: existing
constraints:
- tag: nsx62 |
Load balancers
| Resource scenario | Example cloud template design code |
|---|---|
| Specify a load balancer logging level, algorithm, and size. |
Sample NSX load balancer showing use of logging level, algorithm, and size: resources:
Cloud_LoadBalancer_1:
type: Cloud.NSX.LoadBalancer
properties:
name: myapp-lb
network: '${appnet-public.name}'
instances: '${wordpress.id}'
routes:
- protocol: HTTP port: '80'
loggingLevel: CRITICAL
algorithm: LEAST_CONNECTION
type: MEDIUM
|
| Associate a load balancer with a named machine or a named machine NIC. You can specify either In the first example, the deployment uses the In the second example, the deployment uses the The third example shows both settings used in the same |
You can use the
instances property to define a machine ID or a machine network ID:
|
Add health check settings to an NSX load balancer. Additional options include httpMethod, requestBody, and responseBody. |
myapp-lb: type: Cloud.NSX.LoadBalancer properties: name: myapp-lb network: '${appnet-public.name}' instances: '${wordpress.id}' routes: - protocol: HTTP port: '80' algorithm: ROUND_ROBIN instanceProtocol: HTTP instancePort: '80' healthCheckConfiguration: protocol: HTTP port: '80' urlPath: /mywordpresssite/wp-admin/install.php intervalSeconds: 60 timeoutSeconds: 10 unhealthyThreshold: 10 healthyThreshold: 2 connectionLimit: '50' connectionRateLimit: '50' maxConnections: '500' minConnections: '' internetFacing: true{code} |
| On-demand network with a 1-arm load balancer. |
inputs: {}
resources:
mp-existing:
type: Cloud.Network
properties:
name: mp-existing
networkType: existing
mp-wordpress:
type: Cloud.vSphere.Machine
properties:
name: wordpress
count: 2
flavor: small
image: tiny
customizationSpec: Linux
networks:
- network: '${resource["mp-private"].id}'
mp-private:
type: Cloud.NSX.Network
properties:
name: mp-private
networkType: private
constraints:
- tag: nsxt
mp-wordpress-lb:
type: Cloud.LoadBalancer
properties:
name: wordpress-lb
internetFacing: false
network: '${resource.mp-existing.id}'
instances: '${resource["mp-wordpress"].id}'
routes:
- protocol: HTTP
port: '80'
instanceProtocol: HTTP
instancePort: '80'
healthCheckConfiguration:
protocol: HTTP
port: '80'
urlPath: /index.pl
intervalSeconds: 60
timeoutSeconds: 30
unhealthyThreshold: 5
healthyThreshold: 2
|
| Existing network with a load balancer. |
formatVersion: 1
inputs:
count:
type: integer
default: 1
resources:
ubuntu-vm:
type: Cloud.Machine
properties:
name: ubuntu
flavor: small
image: tiny
count: '${input.count}'
networks:
- network: '${resource.Cloud_NSX_Network_1.id}'
Provider_LoadBalancer_1:
type: Cloud.LoadBalancer
properties:
name: OC-LB
routes:
- protocol: HTTP
port: '80'
instanceProtocol: HTTP
instancePort: '80'
healthCheckConfiguration:
protocol: HTTP
port: '80'
urlPath: /index.html
intervalSeconds: 60
timeoutSeconds: 5
unhealthyThreshold: 5
healthyThreshold: 2
network: '${resource.Cloud_NSX_Network_1.id}'
internetFacing: false
instances: '${resource["ubuntu-vm"].id}'
Cloud_NSX_Network_1:
type: Cloud.NSX.Network
properties:
networkType: existing
constraints:
- tag: nsxt24prod |
Learn more
- vRealize Automation Cloud Assembly Load Balancer with NSX-T Deep Dive
- Network Automation with Cloud Assembly and NSX – Part 1 (includes use of NSX-T and vCenter cloud accounts and network CIDR)
- Network Automation with Cloud Assembly and NSX – Part 2 (includes use of existing and outbound network types)
- Network Automation with Cloud Assembly and NSX – Part 3 (includes use of existing and on-demand security groups)
- Network Automation with Cloud Assembly and NSX – Part 4 (includes use of existing and on-demand load balancers)