Let’s start with simply defining what a Terraform provider is. A Terraform provider is a set of tools (like a SDK for developers) that is built specifically to communicate with API’s or, in certain instances, to compute a specific programming task. A few examples below:
1. Azurerm => https://lnkd.in/eN_V6iqH which is the provider that is designed to communicate with the “Azure Resource Manager”
2. Aws => https://lnkd.in/ePU8mvhA which is the provider designed to talk to the “Cloud Control API”
3. Local => https://lnkd.in/eJUB_njw which is used to do operations on the local host machine such as creating output files containing resources.
I just defined a few Terraform providers above. To use them in your Terraform project, simply define a provider block in main.tf for each unique provider that you want to have available at runtime. The thing is, when Terraform is compiling, it will simply download all required dependencies and place them in the Terraform folder that spawns as you run “terraform int” which initializes everything.
Extra: A very quick and efficient way to find the exact resource documentation is to use Google and search with the format:
<provider name> <resource type>
For example: “Azurerm virtual machine” notice how I do not specifically type “Azure virtual machine” since Google knows based on the provider name.
See below some examples using the different providers:
Example 1 - Creating a simple resource group containing a log analytics workspace (Can be copied directly into an IDE)
//Simply using the newest available provider versions
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
}
local = {
source = "hashicorp/local"
}
}
}
provider "azurerm" {
features {
}
}
//The most simple resource to create is a resource group. We need to specify name and location as minimum
//Because we are just getting started no loops or variables are used for simplicity's sake
resource "azurerm_resource_group" "demo_rg_object" {
name = "demo-rg01"
location = "West Europe"
tags = {
"Environment" = "Demo"
}
}
resource "azurerm_log_analytics_workspace" "demo_workspace_object" {
name = "demo-logspace01"
location = azurerm_resource_group.demo_rg_object.location //Parse the location directly from the resource group object, notice that the output block does not need to be provided
resource_group_name = azurerm_resource_group.demo_rg_object.name
}
//More than just creating the resources, we can use the local provider to get a json file provided of the returned objects
//Returning the logspace and using the return values to also directly affect the output filename and adding the content via a function called 'jsonencode'
resource "local_file" "log_analytics_workspace_as_local_json" {
filename = "${azurerm_log_analytics_workspace.demo_workspace_object.name}.json"
content = jsonencode(azurerm_log_analytics_workspace.demo_workspace_object) //Must be converted from a complex return object and into a single string
}If executed right, notice the file being created in the same folder as the terraform main.tf file. Since we simply defined the 'name' parameter in the 'resource local_file' the name returns strings of the logspace and Terraform will then assume the path to be the current directory. Do not forget to add the extension .json at the end, hence wrapping the return call in a '${<return object>}' In order to dynamically add it to the string.
Now, we can do something even cooler. Lets go into the file just created with the .json extension and CTRL + A to copy all the content. Go to website -> Best JSON Viewer and JSON Beautifier Online (codebeautify.org) and copy the content to the left box. Look at the magic happening on the right. We now have a nice looking and fully configured Azure Log Analytics Workspace inside a valid json file.
See the object 'beautified' Below:
All the tools above that we had just used is a way more detailed understanding of how Azure defines a Log Analytics Workspace in terms of API object structure. We can also get a good understanding of the current default values as we only defined 3 required parameters in the resource definition, yet the return contains so much more information. Remember, during Terraform runtime all these attributes and values will be available which can help us build a more durable, flexible and clean Terraform main scripts.
The only thing to be very aware of using this technique, is that Terraform will provide every single secret value as clear text. Therefore use this with caution and NEVER save passwords in clear text in any files, not even in tests or dummy environments.
Going forward we will go way more into details about how Terraform deals with secret values.
Want to learn more about Terraform -> terraform (codeterraform.com)
Want to learn more about other cool stuff like Automation or Powershell -> powershell (codeterraform.com) / automation (codeterraform.com)
Comments