Terraform: Using AzPreview Features
Description:
Follow this post to use features not yet available in Terraform but are available at the AzureRM level.
To Resolve:
-
In my organization, the flowchart for Terraform development happens in this order:
- Microsoft releases a new AzureRM API endpoint for new/existing resources.
- Hashicorp Terraform developers write Go lang wrappers around the new API.
- They release a new version of the AzureRM provider to Terraform Registry.
- We then consume that version in our modules/infrastructure compositions and provide options for our developers to deploy resource in Azure following our custom business rules.
-
So what happens is sometimes we need to use a feature that is available at the AzureRM level but is not yet provided via Terraform.
- An example is the
public_network_access_enabled
attribute that is now available in the latest version of the AzureRM provider but was not enabled recently. See here for v3.20.0 for example. Of course this makes sense, newer versions of the AzureRM provider will expose new settings.
- An example is the
-
How would you use this setting “ahead of time” so to speak you may wonder? The answer is to use the provider AzApi.
- For example, you can see in this issue that users were able to use the provider like so:
1 2 3 4 5 6 7 8 9 10
resource "azapi_update_resource" "example" { type = "Microsoft.Storage/storageAccounts@2021-09-01" resource_id = azurerm_storage_account.example.id body = jsonencode({ properties = { publicNetworkAccess = "Disabled" } }) }
-
I haven’t personally tested this but that is the general idea if you want to accomplish something available at the API level but not yet available by the AzureRM provider.
-
In researching how the Azure RM Rest provider works, I found some interesting documents about it, feel free to read through:
-
Main takeaway from all the links:
- When Microsoft develops features on Azure, they expose these features as AzureRM Rest API Endpoints.
- You can use Powershell, Az Cli, or the Portal (or SDKs and other tools I’m sure) to call these endpoints in a specific order to get a desired result.
- The key takeaway is that there isn’t a one-to-one mapping between all these tools and the rest endpoints. A single cmdlet like
Get-AzStorageAccount
may call multiple Rest API endpoints under the hood. - But at the end of the day, all these tools will rely only on data types that can be sent and retrieved to a Rest Endpoint. You cannot perform an operation anywhere in Azure that doesn’t use an endpoint. The key is to look at the
API Version
and to read the docs to see what payloads and responses are available for that version to know what is possible in Azure.
-
For example, storage account create version 2022-05-01 will have these features
- The URI params will require multiple strings
- The Request Body will require multiple properties being passed.
- The response object received back will be of type Storage Account which has its own properties like
id
,kind
, etc. - Try switching between the different code sets in the example. Does it make sense now that you can interact with Azure in multiple different ways but they all translate to a Rest API operation in the background? This was incredibly insightful when I first found this out.
Comments