Terraform has been the talk of the town lately with its amazing integration and capabilities towards cloud infrastructure. A true Infrastructure as Code solution which still provides full-fledged functionalities despite being an underdog. Yes, it’s true. They are not even at version 1.0.0 yet but still deliver amazing solutions to major cloud providers as well as custom in house solutions.
To increase the value of our Infrastructure as Code solution – Dash1 – we decided to tackle a cool edge-case: we want Windows Servers on VMWare (or any other Cloud-Provider – we just like challenges and started with the most popular solution for on-premise Windows virtualization) to run hybrid Kubernetes-Clusters!
We will talk more in-depth about issues and their solutions we came across during the article.
Terraform uses HCL for its configuration. HCL is a great language, easy to use and standardized across platforms. This makes it easier and fun to learn.
In our case, Terraform-Code will be structured and categorized into four parts.:
Consists of providers, data and resource objects. It’s the heart of the language and where you put all the objects necessary to run your code. It basically defines the deliverable.
Contains needed variables and their description. Used to define variable types like String, Maps, Lists, Integer and the defaults a variable should have. You can find a list of terraform variables and their behavior in this Docs article.
You are now familiar with Terraform variables. Although you can define their values in varibales.tf, it is recommended to use a file with a .tfvars extension to store the actual values of your variables. This is really important in terms of design and usability.
In output.tf we define the output values after the code in main.tf has finished. This file contains attributes that you want to show in the console once the instance is created. You can output attributes like IP address, server name and much more.
You can find all of the code in the vsphere module of dash1.
Since we now have a basic understanding of the Terraform file types we’re using, let’s look at a few code snippets to gain more understanding about the language. For the following code snippet, we have used this variable file. Please investigate it to understand what below variables represent.
We used the vsphere provider and got the connection to the API of a testing vCenter working pretty easily. For your own testing, you’ll have to adjust your variables to match the resources you have access to. Here we defined DC, Datastore cluster, Datastore, resource pools and much more sources to be used in the code.
Check the files to use here: dash1 vSphere module.
A little Background
The count attribute describes the number of servers we want the code to provision. We have given it an IF condition to dynamically assign a number based on var.instances. Basically, all you must know is, if the count value is zero, then terraform will not provision any resource type named windows.
The name attribute should be changed according to the number of instances since the name is a unique value in vcenter. Therefore, we check if the variable vmnameliteral is not set, then it means there’s more than one instance and vmname should be used along with a suffix defined by the user (VMNAME+SUFFIX). Take a look at this section of the Terraform article to understand about if else conditions.
We use the clone configuration to tell vcenter to use “clone the VM from this template” option (HINT: this means you need an existing VM template in your vCenter! If you need advice on how to manage this, reach out!). It contains attributes like join_domain and admin_password to let you customize the windows image as you would normally do in vcenter.
As you can see from the above code, there’s a lot of customizations available in the clone configuration and how I have used conditions like IF ELSE and FOREACH to achieve dynamic assignments of variables. You can check this article from Terraform to learn more about such conditions and how you can apply them in your code. It will be a challenge, but once you master them, Terraform would be the best thing that ever happened to you.
The next part of this article describes an issue we faced after provisioning the VM. It’s regarding configuring SSH and WinRM in the newly created Windows Server 2019 machine. Initially we thought we could use the OpenSSH module along with a Powershell-Script for WinRM to configure both services.
We were trying to copy the required files and binaries over through the file object and used a remote execution command to run them inside the OS. However, due to this bug in Terraform, there’s a limitation of the size you can copy over the network. So, our OpenSSH folder, which contained about 2Mb of files, was not copying over fully.
After some research we learned that there is a new in-built feature in Windows Server 2019 that lets you configure the server as a SSH server.
we created two Powershell scripts that will configure WinRM and SSH and copied them over, using the file provisioner. Since the two file sizes were limited to 10KB, they were not affected by the bug. However, you need to make sure the machine you are running Terraform code from, and the newly built Windows Server 2019 VM, can communicate with each other over network.
After lots of time and effort, we were finally able to successfully create a Windows Server 2019 VM through Terraform on VMWare vSphere. We’re now one step closer to hybrid Kubernetes-Clusters.
The code was well designed, reusable and can be used to create ‘n’ number of windows servers with SSH and WinRM configured.
We urge you to try out Terraform and enter the vast world of Infrastructure as Code to improve your IT infrastructure. The time where system users, developers and stakeholders had to wait for the infrastructure team to create servers for them is over. Now everyone can make their own servers with the configuration they want. Get on with the trend and better yourselves to face the Future of IT.