In a previous post I explained why I don’t advocate the use of child modules, but I wanted to quickly explain how I keep Terraform admin overhead to a minimum when creating standard resources whilst also working with the constant rate of change that cloud brings.
Continue Reading...Terraform uses the construct of a module, which is defined by HashiCorp as “a set of Terraform configuration files in a single directory”.
The root module consists of resources defined in the main working directory (which I like to refer to as the ’execution folder’). However, you can also call other modules to include their configuration. These are known as child modules which can be shared and reused by multiple root module configurations. Sounds good, doesn’t it?
This is something I’ve only recently discovered but thought it was worth sharing here.
I have a few configurations where I need to pass JSON to Terraform to process. The most used resource where I do this is azurerm_virtual_machine_extension. The example HashiCorp documentation still shows the use of Heredoc strings which is probably why I hadn’t picked up on it until now.
I recently discovered a HashiCorp article where they tell you that by using the jsonencode and yamlencode functions “Terraform can be responsible for guaranteeing valid JSON or YAML syntax”. This sounded good to me as JSON syntax is not very forgiving, and it is designed to be read and processed by machines (not humans). If you put a comma or a bracket in the wrong place, you will soon be in a whole world of pain. The same is true for YAML and indentations.
Continue Reading...When I started using Terraform in 2018 the content online was mainly written from a developer’s perspective and was based on deploying resources into AWS. This was a great starting point, but the key messages in the blogs I read were all fairly consistent and seemed to align to the excellent blog series by Yevgeniy Brikman from 2016 which is well worth a read.
So, I read the series, took all the key messages onboard and started deploying resources into Azure. However, as our environment began to scale and more engineers came onboard, it was soon clear I needed to formalise our ways of working to ensure everyone followed a standard approach as we wouldn’t be operating the ‘you build it you run it’ model. This meant that once cloud services were provisioned and live, they needed to be handed over to operations who would also need to understand the Terraform configuration.
Continue Reading...