HashiCorp announced the release of version 2.0 for the AzureRM Terraform Provider. This release includes an overhaul of how two core resources are described, an introduction of custom timeouts, and the removal of a number of deprecated resources. There are also changes to improve how existing resources are handled while running the CLI command "terraform apply".
In this release, Virtual Machine and Virtual Machine Scale Set resources are now separated by operating system type. Since the introduction of these resources back in 2016, there have been a number of changes within Azure, including the addition of new features. As noted by the AzureRM team, "we've wanted to be able to give better validation during terraform plan, rather than bailing out with an Azure API error during terraform apply, however this isn't possible with the current resource structure, since they're very generic."
In order to better support the changes within Azure and provide better feedback, new resource types were added to split out the virtual machine type by operating system. These resources include:
azurerm_linux_virtual_machine
azurerm_windows_virtual_machine
azurerm_linux_virtual_machine_scale_set
azurerm_windows_virtual_machine_scale_set
azurerm_virtual_machine_scale_set_extension
The existing azurerm_virtual_machine and azurerm_virtual_machine_scale_set resources will continue to be available through the 2.x releases, however, the team notes that they do plan to deprecate them.
With this release it is now possible to set custom timeouts for resources. Previously the timeout value defaulted to one hour, and it was not possible to override this. This could lead to errors with resources that require long timeframes for deletion, such as azurerm_resource_group. The timeouts property can be set on resources as follows:
resource "azurerm_resource_group" "example" {
name = "example-resource-group"
location = "West Europe"
timeouts {
create = "10m"
delete = "30m"
}
}
In previous versions of AzureRM, it was possible to run into challenging errors when running terraform apply if there were existing resources that were not part of the Terraform plan. This conflict could occur due to how Azure uses the resource's name as its unique identifier. As most Azure APIs are upserts, meaning a resource will be updated if it exists otherwise it will be updated, running terraform apply could unintentionally import these existing resources if the name matches a name in the Terraform plan.
With this version, existing resources now must be imported into the state prior to being used. This better aligns with how other Terraform providers operate. Now, prior to creating a resource, Terraform will check for its existence. If a resource with that name is found, an error such as the following will be returned:
A resource with the ID /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/group1 already exists - to be managed via Terraform this resource needs to be imported into the State. Please see the resource documentation for `azurerm_resource_group` for more information.
Resources can be imported using terraform input. Within the documentation for each resource type it includes details on how to import it. For example, a resource group can be imported using the resource id as follows:
terraform import azurerm_resource_group.example /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/group1
This release also has a large number of deprecated resources, data sources, and fields. A complete list of the deprecations is available as is an upgrade guide.
Version 2.0 of the AzureRM provider is available via GitHub. Issues or feature requests should be submitted via GitHub issues.