This blog post is a continuation of the phase 1 blog post for Using Terraform with multiple providers to deploy and configure VMware Cloud on AWS. We will pass parameters from one phase to the other. As noted in the phase 1, all source files are available for download here.
Output file from phase 1
In our phase 1, we created an output.tf file with all the parameters we will need in subsequent phase including the NSX-T proxy.
Below is what the
output.tf file looks like:
All output parameters in this file come from different modules. For example, we can see how the proxy_url output parameter is sourced from the end of the SDDC module:
Using Terraform functions “
trimsuffix” and “
trimprefix” we can remove the string https:// and “
/sks-nsxt-manager” from the
nsxt_reverse_proxy_url output and get the
host value needed for the NXST Provider.
terraform apply command in Phase 1 the output will be:
After we execute the apply command in Phase 1, Terraform will generate a state file for it named
phase1.tfstate. We can read this file and grab output parameters in our
deploy.sh script and set our environment with the following three parameters needed for the NSX-T Terraform provider:
Phase 2 – NSX-T provider
Step 1: Set backend for phase 2 state file and read phase 1 state file.
Step 2: Set NSX-T provider
VMC_subnets variable will hold the details for NSX-T subnets we will create.
main.tf file the NSX module will look like:
Note that the
Home_Gilles variable is for holding my home IP address for a secure vCenter access.
In this module we are going to create the networking and security elements needed in the SDDC. This includes:
- MGW firewall rules
- CGW firewall rules
- NSX segments (12 and 13)
- Compute groups (12 and 13)
- Management group for Home IPs
- Security groups based on NSX tags for Blue VMs and Red VMs
- DFW rules to block ping from Blue VMs to Red VMs
MGW FW rules
Since the VMC Networking environment is pre-build at SDDC creation, we need to use the predefined gateway resource:
For additional protection, we will not allow deletion of this resource using:
The FW rule order in the code is the FW order in the User Interface. As an example, here is the vCenter access rule for my Home IP:
Default rules will need to be added to the code otherwise they will be removed at the first
terraform apply execution:
VMware Cloud on AWS NSX segments are created using the
nsxt_policy_fixed_segment resource. DHCP can be coded as well:
Compute and Management groups
The snippet below shows Compute group configuration based on IP address. Note the
Similarly, the snippet below shows Management group configuration. Note the
NSX Security groups and NSX Tags
Next we will create a compute group for Blue VMs:
DFW Firewall rules
In this example we have 2 compute groups created above for Blue VMs and Red VMs. We want to restrict PING between the 2 groups. To do that we can create a security policy named
Colors with 2 rules:
- Drop PING from Blue_VNs to Red_VMs groups
- Drop PING from Red_VMs to Blue_VMs groups
outputs for this module will be the NSX segment names needed for Phase 3 – vSphere deployment of Virtual Machines.
Phase 2 deployment
After the phase 2
terraform apply in our
deploy.sh script, the output will give us:
VMware Cloud Console
Finally, we can review the created network configuration in the VMC Console UI.
Created CGW FW rules
Created DFW rules
In our next and final blog post (phase 3), we will deploy an S3 Content Library and 6 VMs (3 blue and 3 red)