terraform提供者升级后如何处理资源变化？

Question

I am trying to upgrade the azurerm terraform provider from 2.30.0 to 3.13.0 . For sure there are several changes in some resources (eg resoruce name changes, renamed attributes, removed attributes, etc.). I checked the Azure Resource Manager Upgrade Guide and found those changes by which our configuration is affected.

For example in version 3.0.0 the attribute availibility_zones is replaced by zones for the azurerm_kubernetes_cluster_node_pool ressource. Therefore when i run terraform plan i get an error, that the attribute availibility_zones doesn't exists.

I found a migration guide from deprecated resources . I understood the idea of removing the resource from the state and importing it again by it's resource id, but there are also other resources like azurerm_subnet , azurerm_kubernetes_cluster , azurerm_storage_account they have resource changes, why the terraform import -var-file='./my.tfvars' [..] command fails.

I am not sure if it fails (only) because of the dependencies to some variables they are needed for declaring the resource properly. Or would it also fail because of reading the .tfvars and terraform compares the read variables with the state?

Actually i need a "best practice" guide how to handle resource changes after a provider update. I dont know where to start and where to end. I tried to visualize the dependencies with terraform graph and created a svg to try to figure out the order by which i have to migrate the resource changes. It's unpossible to understand the relations of the whole configuration.. I could also just remove attributes from the state file they doesnt exists anymore, or rename attributes manually.

So How to handle resource changes after provider upgrade in terraform?

Answer 1

So How to handle resource changes after provider upgrade in terraform?

I don't think deleting the state file and then importing the resource and do changes in resources attribute based on when you require to upgrade the azurerm version is a feasible solution.

Terraform Registry already given update/notes for every resource when they did some changes on their upgrading version. Just like below example

we use azurerm_app_service for version ~2.x but for version ~3.0 and ~4.0 azurerm_linux_web_app and azurerm_windows_web_app resources instead.

Would suggest you check the terraform registry for update on particular resources attribute for specific provider version or not and do it accordingly.

Answer 2

General

I was able to update the provider properly - i hope at least. I would like to share my experience, maybe it would help other beginners. This is not a professional guide, but just my experience that i want to share.

First of all you have to remove ALL resources affected by the provider upgrade and then re-import them. What does that mean?

The new provider will contain divers changes on different resources. For example:

• Removed deprecated attributes (attribute is completely removed)
• Superseded attribute (attribute is replaced by another).
• Renamed attributes
• Superseded resources (here the resource can be deprecated or removed by the upgraded version)

Note

The migration guide describes how you can migrate from deprecated resources, but the workflow for attribute changes is the same. How i understood it. This is the only guide that i found.

terraform plan will show you one or several errors for affected resources.

If your terraform configuration is complex and huge, then you shouldn't try to remove and re-import them all at once. Just go step by step and fix one affected resource successively.

terraform plan can show changes although he shouldn't.

• Check the force replacement attribute accurately and understand why terraform detects changes. It's seems be obvious but it doesn't have to.
• There can be a type change eg int -> string
• If the affected change is a kind of missing secret, then you can try to add the secret manually as the value to the related attribute in the state file and run terraform plan again.
• Or there can be also a bug by the provider. So if you can't understand the detected change try to search the issues of the provider - mostly on github. Don't get confused if you can't find any related issue, maybe you have found a bug. Then just create a new issue.

You will also face some other errors or bugs related to terraform itself. You have to search for a workaround patiently, so that you can continue apply the resource changes.

Try to figure out resource changes or to ignore an error for this moment that occurs in another module with resource targeting .

How To

1. ---> !! BACKUP YOUR STATE FILE !! <--- : You have to backup your state file before you start manipulating the state file. You will be able to restore the state of the backed state file if something goes wrong. Also you can use the backed up state file for finding needed id s when you have to import the resource.

2. Get Affected Resource: How you can find all affected resources? After the upgrade the provider will not be able to parse the state file, if a resource contains changes - like i described in the question above. You will get an error for affected resources. Then you can check the changes for this affected resource in the upgrade guide of the provider - can be found in the provider register eg azurerm .

3. Terraform Configuration: Now you have to apply the changes for the affected resources in the terraform configuration modules before you can import them like described in the migration guide .

4. Remove Outdated Resource : Like described in the the migration guide you have to remove the outdated resource from the state file because it contains the old format of the resource. The new provider is not able to handle these resources from the state file. They must be re-imported with the new provider.

5. Import Removed Resource : After you removed the resource you have to re-import it also described in the migration guide . Check the terraform import documentation for better understanding and usage.