vCloud Director is one of the VMware products which help service providers with the public cloud delivery. As with the most VMware products, developers can communicate with it by API. So if something has API, it may have its own Terraform Provider! To be honest, I use vSphere Provider more than vCloud, but sometimes it’s better to use Terraform instead of using GUI or even PowerCLI. Of course, I don’t save the states of my infrastructure, because I don’t need to destroy or change it later, but I can save my time during the creation of new infrastructure. One of that case would be applying many NAT or Firewall rules. But, you know, it’s very annoying when I must copy and paste one block of configuration and change only the specific values.
Why should you use vCloud HCL generator for Terraform?
I’m sure some of you actually seem to feel that any generators are unnecessary. If you want to migrate the whole NAT and Firewall rules from one Edge Gateway to another, PowerCLI is enough. Most VMware Administrators will use PowerCLI for almost everything – and me too. But sometimes there are some cases when the PowerCLI (and other typical tools) is insufficient. For example, when you try to deploy the whole infrastructure:
- Org Vdc Network (or Networks)
- some vApps with provisioned VMs
- VPN tunnels
- NAT and Firewall rules
it’s definitely faster when you use Terraform for that. Unfortunately, configuration files are full of recurring blocks so creating these files is… a little bit annoying. Anyway, it’s very annoying for me. For that reason, I’ve created a simple NAT and Firewall HCL generator for Terraform. It generates the complete configuration files with the NAT and Firewall rules. Of course, I know that I could make something more than only those resources, but it’s a new project. I want to develop the script and widen the scope of its usability. For now, it solves the most important (in my opinion) problem.
How does HCL generator for Terraform work?
The script needs the CSV files with the NAT/Firewall rules. The current version requires a specific fields’ order, but I wonder about making it independent from that. Each CSV corresponds to the correct Terraform resource. It’s not necessary to generate all of HCL files. If you want to create only the SNAT resource (vcd_snat), you can run the script without DNAT and Firewall CSV files. Whenever you want, you can print help with the following command:
$ python /path/to/script/hcl_edge_gen.py --help
There you have the example of the CSV files with the correct order. You can also find it in the source code. Moreover, I’ve added samples to the GitHub repository.
You can modify the existing files provided with the script or create your own. If you don’t want to create the specific resource – just don’t create a CSV file. By default HCL generator for Terraform searches for “datadnat.csv”, “datasnat.csv” and “datafw.csv” files. You can use other names and then tell the script which files it should use:
python /path/to/script/hcl_edge_gen.py --dnat=file.csv --snat=another.csv
Then the HCL generator for Terraform will create the configuration files based on your tabular data. The result is ready to use HCL files named snat.tf, dnat.tf and firewall.tf. Of course, the script checks whether those files exist before and remove them first. It’s quite important because my generator opens files in the appending mode. Without removing the existing objects, it would add a new content after the previously created.
How can I get this fantastic thing?
In a very simple way. Just visit my Github repository of this project and download/clone git repository.
$ git clone https://github.com/ewypych/hcl-edge-generator.git
dnat: allow different src/translated port
Now, this script supports the current Terraform version, 0.9.X. Hence you cannot specify different ports in the DNAT configuration. Since the 0.10 version every Provider will be managed in the separate repository (I wrote about this in the “Separating Providers from the Terraform core”). I track changes in the vSphere Provider and vCloud Director Provider and I know, that there is a closed (merged) Pull Request which allows specifying different ports. I will try to create an additional branch (and in the future merge it with master) with code that will take into account these changes.