Terraform Cloud: Connecting to Github and Deploying Your First IaC

Terraform Cloud is a SaaS solution from Hashicorp that allows you to have Workspaces, which provide an environment for a infrastructure. They store variables, state files, credentials, and secrets.

You have the ability to run infrastructure as code remotely. Another advantage of using Terraform cloud is the fact that the “plan” phase also calculates the costs to deploy the new infrastructure, as well as checking if your code is compliant with your Sentinel policies.

Terraform Cloud is good not only for small teams, but for companies because when you are working with larger teams, instead of relying on their machines to store the code, state, you have a centralized location that everyone can work and collaborate. Terraform Cloud is free up to 05 users, after that you have to pay by user, read more about the plans here:

HashiCorp Terraform: Enterprise Pricing, Packages & Features

Prerequistes to follow this post

• Github free Account;
• Terraform Cloud free account;
• Have any functional Terraform code to plan and apply;
  Here’s mine from my last post with small adjustments that I’m using in this post:

medium/terraform-cloud at main · RafaelM1994/medium

Creating a new Organization

The first thing you have to do is to create an account on Terraform cloud:

Terraform Cloud by HashiCorp

If you are starting from scratch, you may have to create a new organization first. On the main screen, select “create new organization”:

Fill in the organization name and your email address:

Connecting to a Version Control System (VCS) Provider

In this tutorial we will be using Github as our VCS provider. Terraform also supports Gitlab, Bitbucket and Azure Devops.

Continuing with the workspace set up, we now have to connect to our VCS, but you also have 02 other options at the time of this writing:

CLI driven — Allows you to run Terraform from your command line on your own machine. It will use variables from the appropriate workspace; More about this option here.

API-driven — Allows you to connect to a CI Pipeline and you don’t necessarily need to connect to a VCS provider; More about this here.

For the sake of demonstration, we will go with the VCS option:

Select the Github.com version, which is the public one:

Give Terraform permission to work with your github account:

The next screen will install Terraform cloud on your account. If you are not comfortable installing it in all of your repositories, select the one that you’ll be using for this tutorial:

Now select the repo you have authorized:

Finally, give the workspace a name and hit “Create workspace” button:

->Optional Step

If you have multiple Terraform folders like I have here in my project, you can select another working directory, by default Terraform will use its root path:

To select another path, go to your current workspace, select settings >> General:

Then enter the name of the subfolder you want Terraform to use as its working directory:

Configuring Variables

If you look at the code in my Github, you’ll see that I didn’t add any *.tfvars file, although I have declared some variables to be filled in:

If you don’t declare them, Terraform will throw an error. I didn’t add a *.tfvars file because we don’t need this anymore, we can add all the variables in the workspace and use them from there, let’s see how it goes.

Configuring Variable Sets

Variables sets are sets of variables commonly shared across multiple workspaces within the organization. Here we are going to share the same service principal variables to authenticate to Azure across all workspaces, this way you don’t need to re-create them when you create another workspace, they will be enabled by default.

Since creating a service principal is out of scope for this post, you can refer to my previous post or the Terraform documentation to learn how to do so.

To create a variable set, select your organization, go to Settings >> Variable Sets >> Create variable Set like the following:

In the next screen, you can set your variables, you can also select if you want to apply them to all workspaces or specific ones, it’s up to you. The variables that you need to configure are the following:

• ARM_CLIENT_ID
• ARM_SUBSCRIPTION_ID
• ARM_TENANT_ID
• ARM_CLIENT_SECRET

don’t forget to set them as “Environment variables”, not “Terraform Variables”:

Click save variable set, and you’re good to go.

Configuring Variables

In the previous section, we have configured variable sets that have common variables to be shared across multiple workspaces, now you will create only the variables that you will use in this project only. To do so, go to the recently created workspace, and select variables:

This screen is similar to the one where we configured the variable sets, it’s just a matter of doing the same thing, to configure the variables:

They are the following:

• prefix, location1, location2, vm_size1, vm_size2

Don’t forget this time to change the variables to Terraform Variables, instead of Environment Variables:

We have everything to run our plan now. Let’s do this in the next section.

Running the Plan

Go back to your workspace, in the overview section, select Actions >> Start new plan:

Click Start Plan:

As you can see, the output is basically the same as we would have if we ran from the terminal. You can also download the logs if you want:

You can inspect resource by resource and see if the variables are correct:

Applying the Plan

To apply the plan is as simple as planning it, just go down at the same page and hit “Confirm & Apply”:

Terraform will authenticate to Azure using the variables that were configured in the variable sets.

When the apply is finished, you can check the created resources, as well as the time it took to be provisioned, and download the raw log if you want to debug anything:

It’s worth noting at the end of the report that you have a State file created with a hyperlink to go to it:

When you click on the state file link, you have the exact state file like you would have in your local machine, but this time being managed by Terraform Cloud, which is pretty neat:

Committing New Change in the Code

Let’s see how Terraform Cloud behaves when we make a new commit to the repo that the workspace is linked to.

Here I’m removing 15 vms and leaving only 05 in the code:

When I commit it:

It automatically triggered a plan:

But it didn’t apply because I don’t have Auto Apply Enabled by default as you can see in the following image. You can also see that 45 resources will be deleted:

Same thing as before, if you go to See details page, you’ll see the resources that will be deprovisioned, as well as the option to confirm and apply the change:

And that’s basically it, I have now only what I reuqested to have:

Destroying the Infrastructure

To completely destroy the entire infrastructure, you can go settings >> Destruction and Deletion:

Here you can queue a destroy plan:

After that, your destroy plan will be started. After reviewing everything, you can confirm and apply:

And then, all resources gone:

Wrap Up

That was a long post, with lots of steps, but it’s worth the effort when you learn how simple Terraform Cloud is and how many benefits you can have from it.

In this post you’ve learned how to connect your github account to Terraform cloud to plan and apply your infrastructure as code. You also learned how to destroy them afterwards.

If you have any comments or questions, let me know in the comments section, I will be happy to hear you! :)

Happy Studying!