In the previous post, I discussed how to setup a development environment, configuration settings made to the virtual machines and converting virtual machines to templates. This post assumes vRA is operational as I’ll be discussing the following topics as it relates to creating/publishing the NSX-T Blueprint that will be used to deploy PKS:
Network Profiles & Reservation
Network profiles contain pre-defined IP information like gateway, subnet, DNS, and IP address ranges. When a virtual machine is provisioned vRA will assign an IP address based on the information in the network profile. There are three types of Network Profiles as depicted in Figure1. I have opted for NAT network profile (One-to-Many) in order to support multiple deployments. In Figure2 are the network profiles I created for the blueprint. Next, we have to tie the external network profile with our existing port group as shown in Figure3.
Custom specification will destroy any user profile (tsc\administrator) custom configurations we make like MTputty, WinSCP, Chrome/Firefox bookmarks, desktop image, etc. So in order to access the ControlCenter, we need a way to assign the IP address of the external interface.
During a Livefire training event for Hybrid Cloud in Boston a couple weeks ago I struck up a conversation with classmate Chris Smith who focuses on the Cloud Automation. I explained the situation above to him and wanted to get his perspective. He mentioned the easiest way is to use Software Components with bindings. After the completing our session for the day I went back to the hotel and began playing with Software Components/bindings and to my surprise, it just worked! So a huge thank you to Chris for sharing the knowledge. Please check out his site here as he has excellent content around vRA.
The first software component I created was SetExternalIP and created a property called “cc_ip”. We will use this property later when we configure binding. Then proceeded to Actions where I created a basic script that sets the IP address of the External interface. I take the IP address based on the cc_ip property and assign it to [string]$IP. Line 1 of the code below ensure the variable is a string then passes it to the -IPAddress property of New-NetIPAddress cmdlet. The -InterfaceAlias property references the network adapter “External” that was changed in the previous post.
[string]$ip = $cc_ip
New-NetIPAddress –InterfaceAlias “External” -IPAddress $ip `
–PrefixLength 24 -DefaultGateway 10.100.12.x `
-AddressFamily IPv4 -Confirm:$false
SetStaticRouteThe SetStaticRoute software component is simpler only having an action that references the External interface again. I increased the metric to ensure traffic goes through the internal interface. During the Blueprint Design phase, we will attach both software components to the nsxt-controlcenter machine.
Set-NetIPInterface -InterfaceAlias External -InterfaceMetric 2000
With the networking and software component portion complete we can now start working on the blueprint design. To ensure our vSphere templates are imported into vRA lets perform an inventory sync as shown in Figure7. Now click on “Design” tab > Blueprints > New give the blueprint a name shown in Figure8. Select the transport zone and reservation policy Figure9.
We’ll start with a blank canvas shown in figure10.
The first thing to do is drag some network constructs to the canvas Figure11:
- 1 x Existing Network
- 2 x On-Demand NAT Network
Next up is the virtual machines we will focus on the vPodRouter and the ControlCenter VMs (Figure12 – Figure16) as all other VMs will be attached to the vSphereTransitNAT network. We drag over a vSphere (vCenter) Machine then configure the machine to use the vPodRouter template we created in the previous post and attach it to the required networks. We have two virtual machines attached to their corresponding networks (Figure17). Now to attach the software components we created earlier to nsxt-controlcenter machine (Figure18) and then bind property “cc_ip” to “_resource~nsxt-controlcenter~ip_address” (Figure19). This will pass the IP address from the nsxt-controlcenter
Rinse and Repeat
Simply repeat the process for the remaining virtual machines that make up the NSX-T blueprint. Your design canvas should look similar to Figure20 once finished.
Below is a breakdown of the dependency order for the virtual machines inside the blueprint:
vRO PowerShell Host / Event Subscription
- Add PowerShell Host
- Invoke an External Script
In our case, it’s just a simple .ps1 file with Write-Output “Testing ;)” to validate things work. You can see in the screenshot above Invoke an external script ran successfully.
Important: In order to get the scripts to execute successfully I had to update the PowerShell plugin from 1.0.11 to 1.0.13 after doing so the scripts ran without issue.
- Create a vRO workflow that will process the vRA payload looking for the two on-demand networks by finding the port group ids then passing that information to the PowerCLI script that will enable Promiscuous Mode, Forged Transits, and MAC Address Change.
- Create an Event Subscription making sure to define conditions, select workflow (SetSecurityPolicyOnPortGroups) and enable blocking.
- Confirm workflow executed successfully and settings have been changed.
Our blueprint is ready to be published simply click Finish and click Publish (Figure21).
In order to be selectable from the catalog, we need to associate the blueprint with a service assuming Service and Entitlements have already been set up. Navigate to Administration > Catalog Items > Select NSX-T Environment > Configure > Service. In my case, the service is called “VMware [Nested]”.
Note: You can also add an icon here for your blueprint. 😉
If we go to our catalog > VMware [Nested] we should see our new shiny blueprint (Figure22). In our environment, this blueprint takes an hour to deploy (Figure23).
FYI the Blueprint name is “[NAT] NSX-T Environment” is the original blueprint. The “NSX-T Environment” blueprint was created for this post as you can see it’s a popular one (Figure24). 😉
To access the environment I simply get the IP address for the nsxt-controlcenter from the Items tab (Figure25).
Below are screenshots of various components vSphere, NSX-T, and PKS (Figure37 -Figure41). This has been an awesome learning experience I hope you enjoyed the two posts series on developing an NSX-T blueprint in vRealize Automation.
If your interested in seeing a video demonstration of the vRA/NSX-T environment just leave a comment below and I’d be happy to put something together.