Updated August, 2020
Cloud Assembly provides the ability to create Provider and on-demand networks, plus use existing software defined networks, through our integrations with VMware NSX. NSX isn’t the only option available for Infrastructure as Code needs. Cloud Assembly also allows you to leverage the network resources provided by public cloud providers. Over the next four posts, I’ll go through how to configure the networking options for Cloud Assembly and NSX, explain blueprint options, and which network constructs are created during the deployment process. For this post, I’ll walk through the initial setup and configuration of the vSphere and NSX Cloud Accounts. Also I will cover how to work with discovered compute and network objects.
This blog article assumes you have access to Cloud Assembly, a Cloud Proxy is deployed ( or video ) on premises if you’re using vRA Cloud, you’ve covered all your pre-req bases and are ready to configure and deploy compute and network resources. If you’re not there yet, no problem, you can learn more and create a Cloud Services account here, then check out the getting started documentation and come back when you’re ready.
Adding Cloud Accounts
We’ll start by logging in and accessing Cloud Assembly and then configuring Cloud Accounts. The first thing to do is create a Cloud Account for an on premises vCenter environment. To begin, choose Infrastructure – Cloud Accounts – Add Cloud Account.
Select vCenter first. Add the IP/FQDN for the vCenter, choose a cloud proxy if applicable, enter the vCenter credentials and name, then click Add. On-demand and provider networks are supported on both NSX-v and NSX-T. For this post, I chose NSX-T. Click Add Cloud Account again, choose NSX-T in the Account Types UI, enter the NSX-T management server, cloud proxy if applicable (you can use the same proxy for multiple Cloud Accounts), then add the credentials, and name. With the vRealize Automation Cloud August 2020 release, you can now choose whether you’ll be using Policy or Management APIs with NSX-T (Policy is recommended). Also now multiple associated vCenter(s) can be selected for use with a single NSX-T instance. Once you are done adding the Cloud Accounts, click Add.
Shown below, I added the vCenter from our environment. NSX is now a capability available to my vSphere environment. When deployment decisions are made involving networking, where the capabilities match the blueprint, the association between vCenter and NSX will be taken into account.
Viewing Discovered Resources
The vSphere and NSX accounts are configured. After a few minutes Cloud Assembly will display what’s been discovered. Selecting Compute shows a list of discovered (wait for it…) Compute resources. Below I can see that Cloud Assembly has discovered my cluster and resource pools from my vCenter. You may have noticed the option to specify tags throughout Cloud Assembly. Tags are used by Cloud Assembly for placement determination and governance. Tags are also used to constrain provisioning to compute resources. I will use the Resource Pool as a placement destination and have added the constraint tag env:vsphere for later use. You can add a constraint tag by clicking the Compute Name and creating a tag in the window which opens.
We’ll be using tags (in the second and third posts of this series) to tell Cloud Assembly which network profile to use, more on that later. You can read up on tags and how they’re used within our tags documentation. Also below you can see the different ways tags can be used and created within blueprints in Cloud Assembly. Cloud Assembly uses constraint or capability tags for placement and governance. Other VMware products, including vSphere and NSX, use tags for organization, extensibility, and 3rd party integrations. Cloud Assembly can create tags during deployments and update tags using day-2 actions.
Add the CIDR
Next select Networks and find the switch which allows external access. Typically this is the switch with an uplink to the T-0 Gateway and an external route. I will be using Management – Switch for external access in this example. The first thing we need to do is add the CIDR by clicking the switch name.
Clicking a switch name opens a new window where you add configurations or view details for that switch. The first thing I did was add the CIDR and default gateway. Adding the CIDR and gateway allows it to be used later in the Network Profile for IP allocation and external access. You can add other details such as domain, DNS servers and search domains. Public IP assignment is available for entities using this switch by checking the Support public IP box. Also I can choose to make this the default switch for this zone. Choosing default for zone means the switch will be used, unless other constraints are present, when a blueprint calls for the switch’s associated Cloud Zone. If you’re not sure what Cloud Zones are, you can read more in the Cloud Assembly documentation. You can also add a tag to constraint deployments to this switch. Click Save once the updates are complete.
Once those areas have been configured, we can focus on setting up Network Profiles. In the second post, I will walk through how to setup network profiles that will be used when Cloud Assembly makes placement decisions. Over the next three posts I will cover how to configure and use network profiles, the different network types, and finally load balancers.
Network Automation with Cloud Assembly and NSX part 2 – Network Automation with Cloud Assembly and NSX part 3 – Network Automation with Cloud Assembly and NSX part 4
