Getting Started with Terraform in a vSphere Environment – Part 1

In this series, we will explore how to use Terraform to automate the creation and configuration of a virtual datacenter in a vSphere environment. In part one, we will focus on setting up Terraform and creating the basic definitions for our infrastructure.

To follow along with this series, you will need to have the following already set up and configured:

* The basic folder structure for this series (as shown below)

* Terraform downloaded and installed on your system (available for Windows, Linux, and macOS)

* The Windows x64 version of Terraform will be used in this series

Once you have the basic setup complete, open a command prompt and navigate into the deploy_datacenter folder. Type “terraform version” and hit enter to verify that Terraform is installed correctly and to see the version you are running.

Next, we will create some stub files to define our infrastructure. We will create the following files, then edit each one in turn to provide connection details, credentials, and our infrastructure (defined in code):

* provider.tf

* provider_variables.tf

* main.tf

* variables.tf

In the provider.tf file, we will define the provider type we wish to use, along with the information that it requires. The provider_variables.tf file will declare variables that will be used to pass in our connection details and credentials. The main.tf file will tell Terraform what object we are going to manipulate (either create, amend or destroy). In this case, we will specify a ‘vsphere_datacenter‘ resource to create. The variables.tf file will describe the value we wish to pass into the main.tf file; in this case, the name of our datacenter.

Here is an overview of each file and what it contains:

* provider.tf: This file defines the provider type we wish to use and the information that it requires.

* provider_variables.tf: This file declares variables that will be used to pass in our connection details and credentials.

* main.tf: This file tells Terraform what object we are going to manipulate (either create, amend or destroy). In this case, we will specify a ‘vsphere_datacenter‘ resource to create.

* variables.tf: This file describes the value we wish to pass into the main.tf file; in this case, the name of our datacenter.

Once you have created all of the files, let’s start by editing our provider.tf file. The provider.tf file is going to define the provider type we wish to use, along with the information that it requires. You may be wondering where we are going to find this information out from. It just so happens that the documentation Terraform provides is very detailed and everything we need to know can be found here.

We will continue our journey in part two of this series, where we will generate a plan, apply the plan, and create our datacenter object. Stay tuned!

Note: This article was written by Paul Davey, CIO at Sonar, Automation Practice Lead at Xtravirt, and guitarist in The Waders. He loves IT, automation, programming, music, and is passionate about helping others learn and grow. Copyright AutomationPro 2018.

In part two of this series on getting started with Terraform in a vSphere environment, we will focus on initializing the Terraform folder and producing a plan of the changes our definition will make. Before we can execute our plan, we need to ensure that the required providers exist within our project structure.

To initiate the Terraform process, we open a command prompt and navigate into our `terraform/deploy_datacenter` folder. Once in the folder, we run the command `terraform init`. This command processes the files in the current folder, looking for references to providers. In our case, it will find a reference to the vSphere provider and download it directly from Hashicorp.

Once the provider is downloaded, we have everything we need to execute our first Terraform run and create a new datacenter in our vSphere inventory. However, it’s good practice to run a plan in advance to check what will happen before we apply the changes. To do this, we save the plan output so we can run the `apply` command later, passing in the plan file.

To generate the plan, we execute the command `terraform plan -var “datacenter=our_new_datacenter” -out=newDC.plan`. This tells Terraform to create a plan recording the changes that will take place, with the datacenter variable set to our_new_datacenter. The `-out` flag specifies the output file name as `newDC.plan`.

If we check the folder, we will now see the `newDC.plan` file. However, if we try to open this file in a text editor, we won’t be able to read it! Luckily, Terraform allows us to output the plan to JSON. To do this, we use the command `terraform show -json newDC.plan`.

This will output the plan as JSON, which we can redirect to a file (e.g., `terraform show -json newDC.plan > newDC.plan.json`) and then paste the contents into our favorite JSON viewer to make viewing easier.

Now that we have our plan file saved, we can apply the plan, creating our datacenter object. We will do this in part three of this series.

In conclusion, this blog post has covered the initializing of the Terraform folder and producing a plan of the changes our definition will make before applying them to create a new datacenter in our vSphere environment. In the next part of this series, we will apply the plan and create the datacenter object.

Applying Terraform Defintions in vSphere Environment – Part III

In the previous parts of this series, we set up Terraform and created a basic definition to create a virtual datacenter. In part two, we initialized the Terraform folder and produced a plan of the changes our definition will make. Now, it’s time to apply the change and see our new datacenter take shape in the vSphere inventory.

Applying the Definition

To apply our definition, we use the terraform apply command. This command takes the name of the plan file as an argument, which is named based on the resource being created. In our case, the plan file is named newDC.plan. Here’s the command:

terraform apply newDC.plan

When we execute this command, Terraform will process the plan and create the new datacenter in the vSphere inventory. We can see the progress of Terraform as it processes the plan, and once the command is complete, we can see that our new datacenter has been created.

Destroying the Resource

Now that we have applied our definition and created our new datacenter, we no longer need it. To clean up and avoid having an outdated state file, we will use Terraform to destroy the resource. To do this, we execute the following command:

terraform destroy -var “datacenter=our_new_datacenter”

When we run this command, Terraform will print out to the console what resources will be affected by the command. In our case, only the datacenter resource will be affected. To confirm the destruction, we type “yes” and press Enter.

Once the command is complete, we can see that the datacenter resource has been destroyed in the vSphere inventory.

Terraform State File

As mentioned earlier, Terraform cannot work without the state files. The state file allows Terraform to track the infrastructure it is affecting, recording the infrastructure components, their settings (configuration), and dependencies between each other. Without storing a state, Terraform would not know what to do or when to do it.

In this series of posts, we have been using the state file locally, but for testing and learning purposes, it is perfectly fine. In a future post, I will discuss how to properly manage your state files.

Conclusion

In this third part of our series on getting started with Terraform in a vSphere environment, we have applied our definition and created our new datacenter in the vSphere inventory. We have also destroyed the resource using Terraform, ensuring that our state file remains up-to-date.

Terraform is a powerful tool for managing your infrastructure as code, and with these posts, you should now have a good understanding of how to get started with Terraform in a vSphere environment. In the next post, we will discuss more advanced topics such as using modules and count-based resources.

Until then, happy automating!

Configuring Terraform Cloud for Remote State Management

In this blog post, we will explore how to configure Terraform Cloud to remotely host our Terraform state file. We will use the free subscription, and assume that you have some Terraform config already set up. We will also use the results of a previous three-part blog post series, entitled “Terraform and vSphere”.

Creating an Account on Terraform Cloud

First, we need to create an account on the Terraform Cloud portal. Fill in the details for a new account and click “Create Account”. Register your account.

Next, select the option to Create an Organization. Create a new organization and specify a name for it (it must be unique to Terraform Cloud). Specify an email address for future correspondence to go to. Click “Create Organization”.

Specifying Organisation Details

We have now successfully registered our organization on the Terraform Cloud platform.

Generating a Token

While logged in to the Terraform Cloud portal, click the user icon at the top right and select User Settings from the dropdown menu. Navigate to User Settings. Select the Tokens option from the menu on the left. Enter a description for the token (e.g., “terraform_access_token”). Click “Generate Token”. A token will be generated for you and displayed. You must take a copy of this and store it carefully. If you lose it, you will have to delete it and generate a new one.

Storing the Token

On our development system where we have Terraform located, we need to create a file called “terraform.rc” that will contain our generated token. I prefer to keep this file in a folder called “cli_config” and locate it with my other Terraform files. Create a folder called “cli_config” and a blank text file inside called “terraform.rc”.

Configuring Terraform to Read the Token

To make sure that Terraform reads our configuration file, we need to tell Terraform where to locate it. Add a new environment variable as follows:

Environment Variable: TF_CONFIG_FILE_PATH

Value: cli_config/terraform.rc

Remember, you will need to close and reopen any command prompt windows for the new variable to take effect.

Open the “terraform.rc” file in a text editor (e.g., Visual Studio Code) and enter the following into the file:

Content of terraform.rc file

—————————

[your_organization_name]

Your token will be wrapped in double quotes. Save the file and close the editor.

Creating a Backend File

Navigate into the folder where your Terraform definition is (e.g., “deploy_datacenter”). Create a text file called “backend.tf” and open it in your text editor. This file will tell Terraform where to store the state, using the credential token we supplied in the “terraform.rc” file. We will enter the following details into the file:

Content of backend.tf file

————————-

provider “your_organization_name” {

region = “your_region”

}

backend “your_organization_name” {

token = “your_token”

}

Note: Make sure that the token is wrapped in double quotes.

Saving and Closing the Editor

Once you have entered the relevant information into the “backend.tf” file, save the file and close the text editor.

Initializing Terraform

From within your folder, execute “terraform init”. This will allow Terraform to read through the “backend.tf” file and “terraform.rc” file. Terraform will connect to Terraform Cloud and under your organization create a workspace. If all goes well, you should see a message indicating that Terraform has successfully initialized.

Viewing the State Record in Terraform Cloud

After running “terraform init”, if you look in Terraform Cloud in your workspace, you will find that we now have a stored state from the execution. Future changes in state will now be recorded as a new entry here.

Conclusion

In this blog post, we have explored how to configure Terraform Cloud for remote state management. We have covered creating an account on Terraform Cloud, generating a token, storing the token, configuring Terraform to read the token, creating a backend file, and initializing Terraform. By following these steps, you can now use Terraform Cloud to store and manage your infrastructure as code.

This blog post will demonstrate how to apply one or more licenses to vCenter using Terraform. The tutorial will cover creating a module that can be used across multiple vSphere environments.

First, we will create a folder called “configure_licensing” and within it, we will create the following files:

* provider.tf

* provider_variables.tf

* main.tf

* outputs.tf

The provider.tf file defines the provider to use, while the provider_variables.tf file defines what needs to be passed in to enable the provider. The main.tf file is where we will define our resource and the outputs.tf file is where we will define the outputs we want to receive.

In the variables.tf file, we have declared a variable called “licenses” with a type of list(string). This means it expects to receive one or more license keys, wrapped in quotes and comma separated. We wrap the entire entry in ‘[]‘ brackets. For example, we would pass in something like the following:

[“12345-abcde-fghjk-67890-qwerf”, “67890-qwerf-12345-01CU4-987VC”]

In the main.tf file, we have declared a resource type of vsphere_license.licenseKey. According to the documentation, there are two arguments: one for the license key and one for the user who will be assigned the license. We will only specify the required argument, which is the license key.

To add multiple licenses, we can use a built-in method to find the length of the list, or think of it differently, the size of the list. If we passed in two values (two license keys) into this variable, then the length will be 2. Count will be set to the length.

Here is an example of how we can add multiple licenses:

license_key = var.licenses[count.index]

This is similar to my fruitbowl example (despite the very different syntax!). Terraform will set license_key equal to each of the items in our list(string).

We have also declared a number of outputs that we would like sent to the console when the application has been successful. These outputs are assigned names and can be referenced later on.

To run the application, we will pass in the definitions file with the license keys that we want to register. We will then run a terraform plan and check what changes will be made. Once we are happy with the changes, we can run terraform apply and pass in the plan. The outputs that we requested will be shown at the end of a successful execution.

In conclusion, this tutorial has demonstrated how to apply one or more licenses to vCenter using Terraform. We have also created a module that can be used across multiple vSphere environments. The code for this tutorial can be found in the configure_licensing folder.

As a CIO at Sonar and the Automation Practice Lead at Xtravirt, I have always been fascinated by the potential of automation to streamline and optimize IT operations. One tool that has particularly caught my attention is Terraform, an open-source tool from HashiCorp that allows you to define and manage infrastructure as code.

In this blog post, I would like to share two videos that demonstrate the use of Terraform to manipulate vSphere infrastructure. The first video shows how to use Terraform to provision a new virtual machine (VM) in vSphere, while the second video demonstrates how to use Terraform to update the configuration of an existing VM.

Before we dive into the videos, let me provide some background information on Terraform and vSphere. Terraform is an infrastructure as code tool that allows you to define your infrastructure using a human-readable configuration file. This configuration file describes the desired state of your infrastructure, and Terraform ensures that the actual state of your infrastructure matches the desired state.

vSphere, on the other hand, is a virtualization platform from VMware that allows you to create, manage, and deploy virtual machines (VMs) in a data center environment. vSphere provides a robust set of features for managing VMs, including support for multiple operating systems, network virtualization, and high availability.

Now, let’s take a look at the first video, which shows how to use Terraform to provision a new VM in vSphere. In this video, we will create a new VM with a specific configuration, including the operating system, network settings, and storage options. We will also demonstrate how to attach an existing VM to a new VM, creating a nested virtualization environment.

The second video demonstrates how to use Terraform to update the configuration of an existing VM in vSphere. In this video, we will show how to update the number of CPU cores and memory allocated to a running VM, as well as how to update the network settings and storage options.

Both videos are designed to be easy to follow, even for those with limited experience with Terraform or vSphere. However, I want to emphasize that these videos are just basic examples of what is possible with Terraform and vSphere. With more advanced configuration and scripting, you can achieve even more sophisticated automation tasks.

In conclusion, Terraform provides a powerful and flexible way to manage your vSphere infrastructure, allowing you to define and maintain your desired state of infrastructure using a human-readable configuration file. By mastering Terraform and vSphere, you can automate a wide range of IT tasks, from provisioning new VMs to updating existing configurations. So, grab some popcorn, sit back, and enjoy the videos!

The Importance of Standardization in Automation

In the fast-paced world of technology, automation is a key factor in streamlining processes and increasing efficiency. However, without standardization, automation can become a complicated and error-prone task. Recently, I have been working with a financial industry customer who is all in on Automation, but it became apparent quite early on that they haven’t standardized their processes. In this article, we will explore the differences between a non-standardized process and one that has been standardized, and how much simpler it is to automate a standardized process.

Non-Standardized Process

Let’s take the example of creating a new user account. Currently, there are three ways someone can request a new account: via email, phone, or through a web form. This results in multiple edits and updates before the account is ready for handover, as seen in the yellow blocks below.


As we can see, the information can arrive staggered, which introduces the risk of error. For example, the request received via phone might result in the incorrect spelling of a surname, which then requires more edits to the user account. This staggered process also creates multiple touchpoints for human interaction, which can lead to errors and delays.

Standardized Process

Now let’s compare this process to the same process with some standards applied. All requests for a new user must come in through a form, and this form has data fields that the requester must complete before submitting. This ensures that all data required for a user account arrives at once, and because it is via a typed form, we avoid the issues of misinterpretation that we had earlier with the first & last name spelling.


The new process reduces the number of edits and ultimately results in the requester getting their end product – the user account – much sooner. Additionally, with standardization, we can now enforce a set of rules and agreements that all users or consumers must adhere to, ensuring consistent quality and comparable conclusions across all processes.

Benefits of Standardization

Standardization simplifies the automation task in several ways. Without standards, we would need to account for every scenario that the request could follow, allow for breaks in the process, enable human interaction, and provide error correction. With standards, we can allow automation to generate the username, validate the inputs, and hand over the item to the requester.

When we have standards, estimating the time required for automation also becomes simpler. We have a clearly defined process with a set of inputs (the user details) and an expected outcome (the user account). Once the process is standardized, and automated, changes to this process become more controlled – we can introduce and enforce a review process, which means any changes to the process are agreed within the team and released in an agreed manner.

Conclusion

In conclusion, standardization is essential for successful automation. Without standards, the process becomes complicated and prone to errors. By applying standards, we can simplify the task of automation, reduce the number of edits required, and ultimately deliver a more efficient and effective end product. When we have standards, estimating the time required for automation also becomes simpler, and changes to this process become more controlled.

So, if you’re looking to automate your business processes, don’t forget to standardize them first. It may take a little more effort upfront, but the benefits of simplified automation, improved efficiency, and increased consistency will be well worth it in the long run.

Home Lab Setup: My Experience with Intel NUC

As a professional in the IT industry, I need a home lab to learn, test, and develop solutions on. My requirements are straightforward: a simple vSphere setup with vRA, vRO, and a Windows Domain Controller providing Active Directory, DNS, and DHCP. After experimenting with various options, I decided to go with an Intel NUC. In this article, I’ll share my experience with the Intel NUC and how it meets my home lab needs.

Why I Chose Intel NUC

I considered a few options, including HP rack servers/tower servers on eBay, but I was looking for something standalone, cost-effective, and with minimal space requirements. The Intel NUC fit the bill perfectly. It’s a compact, powerful device that can run vSphere and other virtualization tools seamlessly.

My Setup

I opted for a single Intel NUC8I5BEH, which comes with a quad-core 8th generation Intel Core i5 Processor. It has a single M.2 slot, 4 USB 3.1 ports, a Thunderbolt port, and a Gigabit LAN port. The NUC supports up to 32GB of DDR4 RAM, but I installed 2 x Crucial DDR4 32GB Dimms, giving me 64GB of RAM. For storage, I purchased a Western Digital 3D NAND SSD and installed it as the primary drive. I also have a spare 2.5″ SSD lying around that I installed as well, giving me nearly a terabyte of usable space.

ESXi 6.7, the latest build at the time of writing, runs smoothly on the NUC. The internal disks were discovered without any fiddling, so they both got formatted into VMFS volumes for the host to use. I created a couple of portgroups and sorted out my networking (basic, flat networking on a standard vSwitch, separate routable network to the rest of my house). Then it was on to deploying some VMs and getting things going.

Performance and Resources

The NUC has plenty of resources to handle my home lab needs. With all the virtual machines powered on and while using vRA to deploy a VM from a template, I still have enough free resources that the NUC isn’t suffering or starved. The NUC’s resources are sufficient for my needs, and it handles everything smoothly.

My home lab setup consists of:

* ESXi 6.7 (latest build at time of writing)

* vRealize Automation (vRA)

* vRealize Orchestrator (vRO)

* Windows Domain Controller providing Active Directory, DNS, and DHCP

All the virtual machines run smoothly, and I have plenty of resources left over for future expansion. The NUC has nearly a terabyte of usable space, thanks to the two internal storage devices.

Conclusion

In conclusion, the Intel NUC is an excellent choice for a home lab setup. It’s compact, powerful, and cost-effective. With plenty of resources available, it handles my vSphere and virtualization needs seamlessly. If you’re looking for a similar setup, I highly recommend considering the Intel NUC.

Configuring MS Azure as a Cloud Zone in vRealize Automation 8

In this blog post, we will explore the process of configuring MS Azure as a cloud zone within vRealize Automation 8 (specifically the Cloud Assembly service). We will assume that you have an MS Azure subscription and know how to login to it. If you don’t, best go find out before you try and follow this blog post!

Step 1: Configuring MS Azure Connection

Login to your MS Azure portal. On the Dashboard click the Subscriptions card. Within the Subscriptions screen, make a note of the Subscription ID that you want to deploy virtual machines and services into.

From the main menu [editor: click the 3 line burger menu in the top left corner], select the Azure Active Directory entry. Click App Registrations. To enable vRealize Automation to carry out tasks within our MS Azure subscription, we need to grant it permissions. We do this by registering an Azure Application.

Step 2: Registering an Azure Application

Register a new application. Specify a name, configure the Support account types (I used the first/default option), and set a Redirect URI. The redirect URI won’t actually be used, so you can point this to any fictitious address you like, just as I have here. Finally, click the Register button.

With our new application registered, make a note of the Directory (tenant ID). Click the Certificates & secrets menu entry.

Step 3: Adding a Client Secret

Add a new client secret. This will be used to allow vRealize Automation 8 to authenticate with MS Azure. Enter a description, select an expiry duration, and then click Add. On the following screen, make a record of the secret. Once you leave this screen, you will not be able to view it again.

Step 4: Granting Permissions to vRealize Automation 8

Navigate back to the main Dashboard and select the Subscriptions card. From there, select the Access Control (IAM) entry. For vRealize Automation 8 to be able to use this MS Azure subscription, we are going to have to grant our new application entries the appropriate permissions through roles. Click the Add button on the Add a role assignment card.

In the following screen, configure our application as a Contributor. Then repeat this process so that our registered application entry has the Contributor, Owner, and Reader roles.

We are now ready to configure our MS Azure subscription as a cloud zone within vRealize Automation 8.

Conclusion

In this blog post, we have covered the process of configuring MS Azure as a cloud zone within vRealize Automation 8. We have seen how to register an application within MS Azure and grant it permissions to access our subscription. With these steps completed, vRealize Automation 8 can now use this MS Azure subscription to deploy virtual machines and services.

Paul Davey is CIO at Sonar, Automation Practice Lead at Xtravirt, and guitarist in The Waders. He loves IT, automation, programming, music, and is passionate about helping others learn and adopt new technologies.

VMware vRealize 8: Migration and Blueprints

In the world of cloud computing and virtualization, VMware vRealize 8 is the latest and greatest version of the vRealize platform. With its new features and capabilities, many IT professionals are looking to migrate their existing vRealize 7 instances to the newer version. However, migration can be a complex and daunting task, especially when it comes to blueprints. In this blog post, we’ll explore the migration process, what works and what doesn’t, and how to create cloud-agnostic blueprints in vRealize 8.

Migration Assessment Tool

VMware has provided a Migration Assessment Tool to help you identify the components that can be migrated from your vRealize 7 instance to the newer version. The tool discovers various aspects of your vRealize 7 environment and provides a report on what can be migrated. However, it’s important to note that not all components can be migrated directly, and some may require manual intervention or re-working.

Blueprints in vRealize 8

Blueprints in vRealize 8 have undergone a significant overhaul. Gone are the days of creating separate blueprints for each cloud provider. With vRealize 8, you can create a single blueprint that can deploy to multiple cloud providers, including private and public clouds. This approach not only simplifies your management and deployment process but also enables hybrid cloud deployments.

Creating Cloud-Agnostic Blueprints

To create cloud-agnostic blueprints in vRealize 8, you can use YAML code to define your virtual machines, networks, and other components. With less than 40 lines of YAML code, you can deploy a single blueprint to multiple clouds, including vSphere, AWS, Azure, and Google Cloud. This approach not only streamlines your deployment process but also enables your business to take advantage of the benefits of hybrid cloud deployments.

Conclusion

In conclusion, migrating from vRealize 7 to vRealize 8 can be a complex task, especially when it comes to blueprints. However, with the right approach and tools, you can simplify your management and deployment process while also enabling hybrid cloud deployments. By creating cloud-agnostic blueprints, you can future-proof your business and take advantage of the benefits of multiple cloud providers. Remember, it’s not just about migrating what you have now but also considering what your business may need in the future.