My journey learning Terraform to allow me to deploy workloads into Microsoft Azure continues. If you missed the previous posts, please visit the links below.
Part 1: Terraform with Azure – How to install Terraform
Part 2: Terraform with Azure – How to install Azure cli
Part 3: Terraform with Azure – How to Install Visual Studio Code
Part 4: Terraform with Azure – How to install Azure Terraform Plugin in Visual Studio Code
Part 5: Terraform with Azure – Install Git and initialise repository
In this blog post I go through the process of initiating Terraform and start the process of deploying workloads in Azure.
- Launch VSCode
- Create a new file named main.tf
3. Next we need to configure the provider. In our case, the provider is Azure. I type the below code in the newly created file, main.tf. You can also locate the below code from the Terraform Registry website (At the time of writing this blog post the version was 2.95.0). Save the file
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "2.95.0"
}
}
}
# Configure the Microsoft Azure Provider
provider "azurerm" {
features {}
}
4. Next I add the code to create a new resource group named CloudBuild-RG1 in location UK South. Save the file
# Create a resource group
resource "azurerm_resource_group" "demo" {
name = "CloudBuild-RG1"
location = "UK South"
}
- Azurerm is the plugin name. RM stands for resource manager
- CloudBuild-RG1 is the name of the resource
- “demo” is the resource group name in Terraform and is what we will refer to when creating the resource group
- Location is where we will be deploying the resource group. The region being UK South
5. Let’s run the newly created code. But before executing the code, we need to login to Azure. In powershell or the command terminal type the below command and press enter,
az login
6. The above code launches a web page requesting you login to your azure tenant.
Useful commands,
Terraform version – outputs the version of Terraform installed
Clear – Clears the command window
Terraform validate – validates the code and checks for errors
Terraform apply – this command will read your .tf files and apply the changes. Prior to applying Terraform will output the changes and request confirmation before applying.
Terraform plan – this command outputs the changes Terraform will apply and safer to use compared to command Terraform apply
Terraform init – You would run this command the first time you used Terraform within a new directory/project folder, add a new provider or a module.
Terraform destroy – will remove all resources
Terraform fmt – this command will fix the layout of your file so it’s well presented and easy to read.
Terraform help – outputs a full list of commands
7. Next, we need to initialise Terraform. The below command will read from main.tf file and load the version of Terraform as specified in the file,
terraform init
A terraform folder is populated in the working folder. This folder contains the required config to allow Terraform to deploy resources in Azure.
8. Before deploying the first resource group via Terraform in Azure, I run a command to confirm what will be deployed (added/destroyed) in Azure. Run the command below and press enter. The output below displays that one resource group will be created in Azure.
terraform plan
9. We’re ready to deploy our resource group in Azure. Type the command below and press enter,
terraform apply
10. Before committing, Terraform will prompt you to check and type ‘yes’ to confirm,
Do you want to perform these actions?
Terraform will perform the actions described above.
Only ‘yes’ will be accepted to approve.
Enter a value:
Note: if you wish to bypass the above prompt, you could add -auto -approve after terraform apply, i.e. terraform apply -auto -approve
11. Review, type yes if all looks good, and press enter. The process to create our new resource group is under way. When complete, you’ll receive an Apply complete message as shown below.
12. Login to the Azure Portal, access resource groups. Click the refresh button if the resource group does not appear.
And here is our newly created resource group in Azure
You may have noticed that Terraform has created a new file name ‘terraform.tfstate, as shown in the screenshot below.
This state is used by Terraform to map real world resources to your configuration, keep track of metadata, and to improve performance for large infrastructures. This state is stored by default in a local file named “terraform. tfstate”, but it can also be stored remotely, which works better in a team environment. Source: Terraform
In simple words, this is a very important file because it includes the state of what you have already deployed into Azure. Note that the state file will only know what you have deployed via Terraform, it has no idea what you may have already deployed manually within the Azure Portal or via any other provider, so it’s recommended that once you start using Terraform, stick to it to avoid potential issues and confusion in the future.
What if there are a couple of you working on the same project, how does the state file work in this scenario? You could use an Azure storage account as a central location for the state file, or a jump box (a central server) from where the team always run Terraform. This server would hold the state file. However, for larger teams it’s recommended to use Terraform Enterprise for advanced features and collaboration.
Note, you can not rename a resource, for example, if I was to rename the resource group name in my main.tf file, from CloudBuild-RG1 to CloudBuild-RG2, Terraform would delete CloudBuild-RG1 and create CloudBuild-RG2, so one to watch out for. Give it a try in your lab and don’t forget to run terraform plan to confirm what changes will be performed before applying.
Committing to Git
You may recall we installed Git in part 5 of this series. I will be committing the current version/changes up to now. Note that each time you commit, git takes a snap shot of what the files look like at the time and stores a reference to that snapshot. As additional changes are made to your code, you can continue to commit the changes to Git. To commit to git,
- Type the below command and press enter. This will stage all files in the current folder. You can also specify filenames if you don’t wish to commit the complete folder/project, for example git stage index.html
git stage .
2. To confirm the files have been staged, type the command below and press enter,
git status
Note: if you wish to remove the files or a file from the staging area, you can run command, git rm –cached filename (replace filename with the file you wish to unstage or type . to unstage all files.
3. Now it’s time to make our first commit in Git. Type the below command and press enter, (the message in brackets should be short but useful for tracking purposes)
git commit -m "Initial Commit"
4. And here is the result
Note, you can add files you would like Git to ignore by specifying them in the .gitignore file we created in part 5
5. Type git status again and confirm that the output displays nothing to commit.
6. Type the below command to check the history of your current log,
git log
The above output explained: The long number is the unique identifier for the commit. Each commit is associated with a unique identifier. The author name, date and time of the commit is specified. HEAD indicates that this is the latest commit, and master is the branch name. Finally, the description of the commit was ‘initial commit’.
As additional commits are added, the logs may become difficult to read, so a useful command to shorten the logs is,
git log --oneline
There is so much more to learn about Git, so I recommend you pick up a training course and study Git and GitHub further. I will however continue to work with Git, and GitHub in further blog posts.
In the next blog post (Part 7) I compile and explain the purpose of a terraform variables file.
Part 7: Terraform with Azure – Deploy a variables file in Terraform