I have a Terraform file that creates a resource group, storage account, storage shares, database and VMs on Azure. My proposed use case is that in production once the resource group, storage account, storage shares and database are created database, they should stay in place. However, there are cases where the VMs may need to be destroyed and re-created with different specs. I know that I can run the file once to create everything and then taint the VMs and re-create them with an apply, but that doesn't seem like the ideal method.
0
votes
Why not? this is what terraform is planned about, in case you want to change a specific resource you can change it without destroy other resoruces
- Amit Baranes
Were you asking a way that Terraform finds missing components and does not touch does resources with conditional creation?
- Berkhan Berkdemir
@BerkhanBerkdemir yes. My idea was that if the plan were run, rather than generate an error if the resource already existed, it would simply skip the creation step. However, I've read suggestions that this approach is contrary to the idea that TF is the source of truth.
- David Sumner
I would say Terraform is the wrong tool for this purpose. However, because I don't know Azure, I may be wrong and don't want to guide you wrongly.
- Berkhan Berkdemir
1 Answers
0
votes
In regular use, changes to infrastructure should be made by changes to configuration, rather than by running imperative commands like terraform taint. If you change something about the configuration of a VM that requires it to be created then the underlying provider should produce a plan to replace that object automatically, leaving others unchanged.
When you have different objects that need to change on different rhythms -- particularly when some of them are stateful objects like databases -- a good way to model this in Terraform is to decompose the problem into multiple separate Terraform configurations. You can use data sources in one configuration to retrieve information about objects created in another.
Splitting into at least two separate configurations means that the risk of running terraform apply on one of them can be reduced, because the scope of actions it can take is just on the objects managed in that particular configuration. Although in principle you can carefully review the Terraform plan to see when it's planning to make a change that would be harmful, splitting into multiple configurations is extra insurance that many teams use to reduce the possible impact of human error.
