My experience provisioning Azure resources using terraform within GitHub Actions

Introduction

In this article I will be detailing my experience provisioning Azure resources using terraform within GitHub Actions.

The architecture

• The architecture I configured is shown in the image above. It is a fairly simple architecture that makes use of GitHub Actions to automate the deployment of our architecture and allow multiple people to have make changes to it if needed.

• Our remote state file is stored in Azure Blob with a locking feature that doesn't allow any changes to be made while the file is still active (I can verify that it actually locks).

• But first...

• In order for us to do anything in Azure using GitHub Actions, we need our workflow to login to my Azure account. We do this by authenticating with OIDC. To authenticate this way we need to create a service principal, assign it a role (Contributor) and give this service principal credentials to enable confidential applications to identify themselves to the authentication service.

• Most of my time went into creating this workflow as I hadn't known a lot of what I needed to get this workflow working right.

• The terraform code was rather quick to write given how straight forward it is to write terraform in my experience so far.

Challenges

• Given that most of my time went to writing the workflow, most of my challenges were attributed to the workflows. Here is how many times I have run my workflows:

• 22 successful runs. 9 cancelled runs.

• 48 failed runs!!

• Needless to say, I had a lot of issues to solve that I eventually did.

Early challenges

• Most of my early problems were related to syntax and configuration, little tags I had no idea of (using "uses" instead of "run", using deprecated versions of node.js). I quickly understood and solved these thanks to the HashiCorp's good error messages.

• What I learned from these early problems is how to properly write up my workflow files and what tags to use where, when and what they do.

Later challenges

• When I introduced multiple directories into the GitHub repository, I struggled a bit with getting the workflow to run in the proper directory until I ran into some random reddit post in my search for solutions that introduced defaults to me.

• defaults:
        run:
          working-directory: ./app
  

• After this problem was solved a new problem emerged.

• I found out we can't use variables in the backend configuration.

• backend "azurerm" {
    resource_group_name  = "terraform-state"
    storage_account_name = "tfstate44"
    container_name       = "terraform-state"
    key                  = "realtime-chat.tfstate"
    use_oidc             = true
    subscription_id      = var.subscription_id
    client_id            = var.client_id
    tenant_id            = var.tenant_id
  }
  

• The reason for this is because backend configurations are loaded before any variable values are known, so Terraform cannot use variables in the backend configuration.

• A way that I currently know around this problem, without exposing my credentials is by generating the backend configuration dynamically in my deployment scripts (GitHub Actions workflow) and using GitHub secrets to input those values. As of writing this I haven't done so, but I will to remove the hardcoding's.

My last series of problems took the longest to solve, mostly because I didn't have any errors to work with. My workflow would just hang on terraform plan for an unusually long time given how simple the terraform configuration is:

• Throughout this entire process, I didn't use Azure CLI on my machine so I decided to use it to see what it looked like when I do it manually.

• I quickly discovered that after running terraform plan, I was prompted to input variable values like so:

• I tried adding variables to the terraform plan command with no success. It took a while to figure out that all I had to do was assign false to terraform_wrapper and then the workflow wouldn't wait for an entry...it worked.

• But another problem appeared. It turns out I hadn't given my location variable a value.

• I did some clicking around and I defined the value in my .tfvars file that was ignored by my .gitignore. I chose to modify my .gitignore to include .tfvars and it worked.

• I could've just added the value to the variable in definition in "variables.tf", I chose otherwise since my .tfvars doesn't contain any sensitive information.