resource "provider_resource" "unique name for this specific intance of the resource" {
...
}
While you can work by convention and Terraform is able to assume which providers are in use based on the resource naming shown previously, I would always recommend specifcally detailing the providers and their versions.
This is a basic example with the version set, this will be fine when we run locally under our own credentials.
provider "azurerm" {
version = "1.21"
}
When you want to run against a specific subscription and in a non-interactive mode, you will need to specifiy the details like so:
provider "azurerm" {
subscription_id = "${var.subscription_id}" # The subscription to execute against
version = "1.21"
client_id = "${var.client_id}" # The service principal ID
client_secret = "${var.client_secret}" # The service principal secret
tenant_id = "${var.tenant_id}" # The tenant ID that the service principal above has been created in.
}
As we have already discussed Terraform has an advantage over ARM templates, which is that it can support 3rd party resources and providers as well as Azure in a single script.
A couple of great examples of this are:
- Kubernetes
Being able to configure things such as namespaces, pods and deployments on top of AKS is great.
- Network Virtual Appliances.
The ability to configure 3rd party NVAs such as a Palo Alto to add rules as part of the environment provisioning is always a great thing. Compared to secondary steps once the VMs have been provisioned.
To start with we are going to focus on using the AzureRM and the Random providers as together these will be key for us to provision resources in Azure. The random provider, while simple is the best way for us to ensure public endpoints are unique.
In the example below on generating a new value when the resource group is defined.
provider "random" {
version = "~> 1.3"
}
resource "random_id" "lab" {
keepers = {
resource_group = "${azurerm_resource_group.lab.name}"
}
byte_length = 2
}
TODO: include a diag of the plan here
A Terraform plan is used to look at both the current state and the Terraform files that have been changed to calculate the dependencies of the resources and any new or changed values.
As we have already covered, another great feature over say PowerShell or the Azure CLI is that it tracks state meaning it is re-runnable, where something like a bash script is more of a run once.
This means that Terraform is able to work with deltas like adding or removing the resources that are new or different. This is great because it means we can quickly add to an environment with confidence that the existing resources will not be touched.
TODO: Couple of images of the output of apply.
Variables in Terraform can be declared and then set at the point you execute Terraform. This means you can use the same scripts and inject different values for different environments, this is great because you get a level of re-use, but I would edge on the side of caution when creating variables, using them only when needed i.e. don't make every possible value a variable.