We are building a temp review app in terraform. Currently when review app is finished with the resources are destroyed with terraform using terraform apply -destroy. What i need to do is also remove the terraform state file for this infrastructure from the azure container. Could I use terraform -destroy to also remove the state file and how can i do this?
One of the workaround you can follow,
When we are using terraform destroy that time our resource detailed also removed from terraform.tfstate by removing from portal itself.
So to remove any particular resource from .tfstate you can try something like below;
First would suggest you to after destroy the file list the state file you have then remove those.
This below command is used to get the available instances which are in state file.
terraform state list
After listing those try with below which will remove from .tfstate file as mentioned by #Ansuman Bal i have also tried and it works fine .
terraform state rm "azurerm_resource_group.example"
OUTPUT DETAILS FOR REFERENCE:-
NOTE:- This aforementioned cmdlts will remove the instance/resources from .tfstate file only not from portal. Only terraform destroy can do that.
For more information please refer this SO THREAD| Terraform - Removing a resource from local state file.
Related
I'm currently learning terraform and I come across the command terraform refresh. It seems that it syncs the terraform.tfstate file to changes I did manually (I tried changing EC2 instance type). I found out that terraform plan can identify the drift between current and desired state without updating the tfstate file. Also, running terraform apply automatically updates the tfstate file.
So I was thinking, if there are any drifts detected during terraform plan, I will just update the terraform code to account for them and let terraform apply update the tfstate file. Is there any reason to use terraform refresh independently?
P.S.
I'm using terraform v0.15.0
You're correct that terraform refresh is used to update your terraform state file to match the present state--which can drift if resources have been edited outside of terraform.
terraform refresh itself is deprecated, with a note that it can be unsafe in certain situations. The documentation suggests using terraform apply -refresh-only as an alternative, since it prompts for the user to confirm the changes prior to them being persisted.
As to your question of "when is this used?". In my experience, which primarily uses terraform for AWS deployment, we almost never actually run a refresh operation. Terraform automatically checks current state as part of the terraform plan / terraform apply cycle. This may or may not be specific to the AWS provider.
The one scenario where I could see it being important to refresh the state is when the statefile is used as a datasource via a data remote_state_data block. Specifically, if you have intentionally modified the resource and cannot (or haven't yet) updated the terraform markup to reflect the change. In that scenario other terraform modules are reading values from your statefile (as opposed to from the resources themselves)--if your resource and statefile are out of sync then consumers of the statefile would receive inaccurate data.
However in most cases you want your resources to match their terraform representation--so you would terraform apply to bring the resources and state back in alignment with your terraform module.
To create a new Terraform state file, I'm importing some legacy Azure resources into a Terraform configuration with a local state file. As expected, my import syntax is as follows:
terraform import <Terraform Resource Name>.<Resource Label> <Azure Resource ID>
Unfortunately, for one of my resources, I used the wrong Resource Label and had to rename it. I then performed a Terraform plan, but as the earlier Resource Label had already been written into the state file, the plan now displays the message that a resource will be destroyed when applied. Just to clarify, the resource with the corrected Resource Label is also written into the state file, so there's no danger of it being destroyed in Azure.
I however want to clean up the local state file by removing the orphaned resource, so when I ran a Terraform Plan, it reports that:
"No changes. Your infrastructure matches the configuration"
How can I do so safely without compromising my state file or the legacy resources?
As suggested by #luk2302, I tested the command in my environment after I imported a keyvault resource to my local state file and then tried to removed only the keyvault resource from terraform state and it was successful.
The resource is only removed from state file and it can be still found in portal.
Reference:
Command: state rm - Terraform by HashiCorp
We upgraded terraform version and we have a problem with terraform remote state. Basiacaly I run this command to update azurerm provider:
terraform state replace-provider 'registry.terraform.io/-/azurerm' 'registry.terraform.io/hashicorp/azurerm'
Right now when I run plan command it shows me some errors. All are the same but resource if different. For example:
To work with module.name.module.lb_name.azurerm_lb_probe.instance
its original provider configuration at
provider["registry.terraform.io/-/azurerm"] is required, but it has been
removed. This occurs when a provider configuration is removed while objects
created by that provider still exist in the state. Re-add the provider
configuration to destroy
module.name.module.lb_name.azurerm_lb_probe.instance, after which
you can remove the provider configuration again.
Basically the state was updated and the provider looks like this:
"provider": "provider.azurerm"
but it should look like this:
"provider": "provider[\"registry.terraform.io/hashicorp/azurerm\"]"
Is there any way to update it via terraform commands or the only way to fix it is to edit state file manually?
When you replace the providers for the Terraform upgrade with the command:
terraform state replace-provider 'registry.terraform.io/-/azurerm' 'registry.terraform.io/hashicorp/azurerm'
OK, there is no problem. And then you can use the command below to check the current providers:
terraform providers
The screenshot will show like this:
At this time, the providers are the same as the requirement. Then you need to init again to pull the current providers to replace the existing ones with the command below:
terraform init
This is the step you have missed.
I know that when I do terraform apply it does not deploy a resource if the previous deployment within the same terraform state, it would not re-create it .
But I want to do something different:
Create a resource if it is not created by someone else.
But if the resource is already there and even it is not in the terraform state, do not generate an error and have refrence to its name.
Is there any known pattern to do this?
By design Terraform providers will typically not automatically "adopt" existing objects as now being managed by Terraform, because to do so would potentially lead to costly mistakes if you inadvertently bind a remote object to a Terraform resource and then run terraform destroy without realizing what is going to be destroyed.
Instead, you must bind existing objects to your Terraform resources using the terraform import command, telling Terraform explicitly that you intend it to become the sole manager of that object.
I am using Terraform scripts to create azure services, I am having some doubts regarding Terraform,
1) If I have one environment let say dev in azure having some azure resources how can I copy all the resources to new environment lest say prod using terraform script.
2)what are the impact of re-run the terraform file with additional azure resources, what it will do.
3)What if I want to create an app service with the same name from Terraform script that already present in the azure will it update the resource or do nothing after terraform execution completed.
Please feel free to answer the question, it will be great help.
To answer your questions:
You could create a new workspace with terraform workspace new and copy all configuration files (.tf) to the new environment, then run terraform init, plan, apply.
The terraform will compare the content in your current state file with your configuration file, then update the new attributes or creating new resources other than re-creating the existing resources.
You could run terraform import to import existing infrastructure into Terraform. For referencing existing resources in the portal, you can use data sources.