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)