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 3 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 on premises, 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.
We’ll start by logging in and accessing Cloud Assembly 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, 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 (you can use the same proxy for multiple Cloud Accounts), then add the credentials, and name. Once you are done adding the Cloud Accounts, click Add.
You may have noticed that each Cloud Account type includes the option to specify capability tags. Tags are used by Cloud Assembly for placement determination and governance. 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.
In this case, shown below, I added vc-south and nsx-south. NSX (nsx-south) is now a capability available to the vc-south environment. When deployment decisions are made involving networking, where the capabilities match the blueprint, the association between vc-south and nsx-south will be leveraged.
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 vc-south. I will use the Cluster as a placement destination and have added the tag env:vcs-cluster for later use as a constraint. You can add a tag by clicking the Compute Name and creating a tag in the window which opens. Now that I have confirmed my Compute resources, I need to check what has been discovered for Network constructs.
Next select Networks and find the switch which allows external access. Typically this is the switch with an uplink to the T0 Gateway with 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 can add configurations or view details for that switch. The first thing I did was add the routed network CIDR, 192.168.1.0/24 and default gateway. Adding the CIDR and gateway allows it to be used later in the Network Profile for IP allocation. You can add other details such as domain, DNS servers and search domains, as well allow public IP assignment 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. In this case I also added a tag to constraint, net:ext, which allows me to deploy networks that only use 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. And finally in the third post, I’ll cover blueprints, explain what happens for each network type in the blueprint, and provide examples you can use to get started.
Stay tuned and make sure to check out Cloud Assembly today!
The post Network Automation with Cloud Assembly and NSX – part 1 appeared first on VMware Cloud Management.