In our first article, we introduced Terraform Cloud, explained the functions and features of the free tier, and went through the initial process of creating an account and connecting your new environment to your VSC of choice. In this article, we will start to build out your newly created Organisation with a workspace to fill out your Organisation, which will provide an environment to deploy your code into your environment.
But first, a little history story. Back in the dim mist of time, OK, it was in 2021, we wrote a series of articles that introduced people to coding in Terraform. For a quick review, read the following articles to bring you up to date:
How simple Terraform plans make hybrid and multi-cloud a reality: an introduction
Deploying a LAMP Stack with Terraform – AMIs, network & security
Deploying a LAMP Stack with Terraform – Databases & Webservers
How to create resilient Terraform code
Deploying and configuring HashiCorp Vault to service Terraform
Deploying a LAMP Stack with Terraform Modules
Migrating Terraform from AWS to Azure: credentials & secrets – Amazic
Migrating Terraform from AWS to Azure: changing the provider code – Amazic
Building images and VMs in Azure with Terraform – Amazic
Building auto-scaling groups in Azure with Terraform – Amazic
Create cache, databases and DDoS protection in Azure with Terraform – Amazic
To save having to re-invent the wheel, we will reuse the code base and migrate the workload into GitHub and Terraform Cloud. It is time to start modernising and adding rigour to our environment after two years of successfully deploying our infrastructure as code, our bosses have finally bought into the Infrastructure as Code story and the DevOps lifestyle. By Introducing Terraform Cloud into our environment, we can start to add the correct version and audit controls to our deployments. For ease, the only code changes we will carry out on our Terraform code will be limited to what may be required to run on Terraform Cloud and the latest version of Terraform.
What do we do next?
At the end of the last post, we finished off with the creation of our Organisation. We know that working with Terraform involves managing a collection of infrastructure resources as code. When running our code locally, we would manage each collection of resources by using a separate working directory. Each directory would contain our configuration code, variables and the associated State-file. Terraform Cloud manages infrastructure collections with a workspace construct; functionally, Terraform Cloud workspaces and local working directories serve the same purpose but store their data differently. The Table below is from the official online Hashicorp documentation, and it highlights the similarities and differences between the two constructs:
| Component | Local Terraform | Terraform Cloud |
| Terraform configuration | On disk | In linked version control repository, or periodically uploaded via API/CLI |
| Variable values | As .tfvars files, as CLI arguments, or in shell environment | In workspace |
| State | On disk or in remote backend | In workspace |
| Credentials and secrets | In shell environment or entered at prompts | In workspace, stored as sensitive variables |
Additionally, Terraform Cloud keeps some additional data in each workspace:
- State Versions: when using locally deployed terraform; there is only a current state and a single backup state file. Terraform Cloud retains backups of all its previous state files. This ability is beneficial for tracking changes over time or recovering from problems.
- Run History: When Terraform Cloud manages a workspace’s Terraform runs, it will retain a record of all run activity, including summaries, logs, a reference to the changes that caused the run, and user comments; this is a valuable asset when auditing or troubleshooting.
Let’s Get started
We first need is to create our workspace; from the side menu, click “Workspaces.”
This will open the workspace form; you notice that currently, there is no “workspace” declared or created, so let’s get started.
Click the “New Workspace” button to open the workspace wizard.
You will see that there are three options:
Version Control Workflow
This is the most commonly chosen option, as it hooks into a repository where your files are stored; for the purpose of this article, we will be using the Git Repo that holds the code for the articles mentioned above.
On clicking the first box, you are taken to the following wizard to run you through the creation of your Git Repo Integrated Workspace.
You will notice that the GitHub box is shown, however underneath is a link to allow connection to other Version control systems; Terraform Cloud currently supports:
- GitHub, the SaaS version and the On-Premises deployed Enterprise version,
- GitLab, the SaaS version, the free Community version and the Enterprise version,
- Bitbucket, the SaaS version and the On-Premises version
- Azure DevOps
as shown in the graphic below.
After selecting the GitHub dropdown and picking the “GitHub.Com” link, you will be forwarded to a GitHub authentication form.
After successfully entering your credentials, you will be presented with the following form; if you are happy with the details shown, click the “Authorise Terraform Cloud” button to complete this part of the process.
After successfully linking the accounts, you will be returned to Terraform Cloud and asked to select your desired repository.
After selecting your Repo, the final stage is to give your workspace a name and an optional description and click the “create workspace” button to complete.
Woop-pee we have a new workspace .
Click “continue to workspace overview”
If you open the side menu again, you will see that yet again your menu options have change. We will come back to this later.
CLI-Driven Workflow
When you use the CLI workflow, operations like “terraform plan” or “terraform apply” are remotely executed in Terraform Cloud’s run environment by default, with log output streaming to the local terminal. One benefit is that you can utilise the features of Terraform Cloud within the familiar construct of the traditional Terraform CLI workflow, including variables encrypted at rest in a Terraform Cloud workspace, cost estimates, and policy checking.
Creating a CLI-driven workspace is much simpler than the previous option, as there is no integration into a VCS. After clicking the second box, you will be forwarded to the much more straightforward process, and only be asked to provide a unique name and an optional description, and finally, clicking “Create Workspace” to finalise the process.
You will notice that the form you return to after a successful creation action differs from the previous VCS-integrated workspace creation.
We are not going to concentrate on this workspace in this series, if you wish to delve deeper, I would recommend reading the CLI Configuration Guide for more information
API-Driven Workflow
What an API-driven workflow your workspaces are not directly associated with a VCS repo, and webhooks do not drive runs on your VCS provider. Instead, another of your tools will decide when the configuration has changed, and a run should occur. Usually, this is something like a CI system (Azure DevOps, GitHub Actions or CicleCI, or something else capable of monitoring changes to your Terraform code and performing actions in response.
The process for creating an API driven workspace is exactly the same as the process for creating a CLI driven one.
The sharp-eyed reader amongst us will notice that the resulting form is almost the same as the one that returned after creating the CLI Driven workspace; this is true. However, like the previous workspace, we will not be utilising this. Instead, I recommend reading the following page on the Terraform Cloud site for deeper insight into API Driven Workspaces.
Summary
Now that we have finalised the configuration of Terraform Cloud in our next article we will start the process of using Terraform Cloud in anger.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
