Terraform Libraries for Azure — Blog 4

Steve Dillon
3 min readJan 12, 2021
Blog 4 overview, versioning in Terraform-AzureRM, directory layout, contributing.
Overview of Blog 4

In earlier blogs in this series, we jumped into the Terraform-AzureRM module library and demonstrated how to Git’ R Done. I wanted to take a bit of a breather today and talk about some of the other design decisions that took place in early development of Terraform-AzureRM.

Versioning

We had initially created version numbers for each service as:

services/app-insights/base/v1.0
services/app-insights/base/v1.1

This turned out to be a painful decision:

  1. Version numbers ramped very quickly. If we added or removed any interface variable then it was a breaking change to any consumers.
  2. Keeping our internal code that used the library was difficult to ensure that we were on latest version of modules.
  3. We opened ourselves to a testing nightmare. We can test that Module A and B work together, but do we really want to test Any Version of Module A with Any Version of Module B.

We recently switched to versioning the library as a whole which solves most of the above, but does create some (hopefully smaller issues). The biggest issue is that users of the library need to update all their modules in one go. If you just want a new version of Module A, then you do need to pick up the rest of the changes in a versioned release.

We think and hope that versioning the library as a whole will be less troublesome.

We recommend using Git Submodules to pull the library. If you reference each module individually, terraform will pull a complete copy of the module library for each reference. To recap here is suggested git commands to pull a specific version

:~$ git clone git://github.com/persistentsystems/terraform-azurerm-samples.git
Cloning into 'terraform-azurerm-samples'...
:~$ cd terraform-azurerm-samples/
:~/terraform-azurerm-samples$ git submodule init
Submodule 'submodules/terraform-azurerm' (git://github.com/persistentsystems/terraform-azurerm.git) registered for path 'submodules/terraform-azurerm'
:~/terraform-azurerm-samples$ git submodule update
Cloning into '/home/steve_dillon/terraform-azurerm-samples/submodules/terraform-azurerm'...
Submodule path 'submodules/terraform-azurerm': checked out '0fe1907fc7bb48ea989893715a1532f5b5879421'
:~/terraform-azurerm-samples$ cd submodules/terraform-azurerm/
:~/terraform-azurerm-samples/submodules/terraform-azurerm$ git fetch --all --tags
Fetching origin
:~/terraform-azurerm-samples/submodules/terraform-azurerm$ git tag -n

v0.1.3 bulk conversion, removing all v1.x and move lastest version to V1, we will version with tags
v0.1.4 fix internal reference
v0.1.5 trival change to show tagging
steve_dillon@Azure:~/terraform-azurerm-samples/submodules/terraform-azurerm$ git pull origin v0.1.5

Directory Layout

There are two main directory folders:

/terraform-azurerm/scenarios
/terraform-azurerm/services

The Services directory are close to a 1:1 relationship with an Azure resource, there might be some glue code, but services are tightly focused around an azure resource.

The scenarios are larger picture items, ‘I want to create an API with API Management and Azure Active Directory Autentication’. A scenario will compose a few different services. A scenario can be used directly, but in practice you will see that as you compose more and more objects, each individual is going to want slightly different compositions. So you may also think of scenarios as samples or a starting point.

Contributing

We welcome bug reports, and suggestions for new resources to cover. We also welcome collaboration and pull requests. If you have an idea for a pull request open a discussion (or an issue if fixing a bug) and let us know what you intend to contribute.

Thank you for reading this series of blogs and we hope that terraform-azurerm is a useful to you as it is to us.

--

--

Steve Dillon

Cloud Architect and Automation specialist. Specializing in AWS, Hashicorp and DevOps.