When using Terraform to deploy our AWS infra, if we use the AWS console to redeploy an API Gateway deployment, it creates a new deployment ID. Afterwards when running terraform apply again, Terraform lists aws_api_gateway_stage.deployment_id as an in-place update item. Running terraform refresh does not update the state. It continues to show this as a delta. Am I missing something?
Terraform computes the delta based on what it already has saved on the backend and what there is on AWS at the moment of application. You can use Terraform to apply changes to AWS, but not the other way around, i.e. you cannot change your AWS configuration and expect Terraform to pull the changes into its state.
Related
Learning Terraform, and in one of the tutorials for terraform with azure a requirement was to log in with the az client. Now my understanding is that this was to create a Service Princlple.
I was trying this with Github actions and my assumption was that the properties obtained for the Service Principle. When I tried running terraform plan everything worked out fine.
However, when I tried to do terraform apply it failed until I explicitly did an az login step in the github workflow job.
What am I missing here? Does terraform plan only compare the new configuration file against the state file, not the actual account? Or does it verify the state against the resource-group/subscription in Azure?
I was a little confused with the documentation on terraform plan
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.
As part of my requirement I am trying to create a AWS CodePipeline from Terraform and Trigger the CodePipeline Manually once created. But Unfortunately the CodePipeline is getting triggered automatically once created from Terraform
I am Trying to find a way to stop the Codepipeline from triggering automatically as soon as it is deployed from Terraform.
I was trying to do one of the below 2 methods, But I did not find anything relevant for the same.
Find any Parameter which sets the auto trigger to false.
Or Enable the "DisableInboundStageTransitions" between the Source and the First Stage. So the pipeline stage's will not run even if the source has started.
I see "DisableInboundStageTransitions" is available in CloudFormation but not in Terraform.
It Would be really great if someone can let me know that is it even possible to do the above from Terraform?
Is there any workaround to Achieve the same?
Thanks in Advance.
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.
Does terraform support aws backup feature for to restore the image from vault (https://www.terraform.io/docs/providers/aws/r/backup_plan.html )?
As I read the document I can see that it does support creating of backup plan, assigning resources and policy, creating vault but doesnot support restore of an image or ebs volume
How do i add the restore block in my terraform template
Terraform's execution model is designed for translating declarative descriptions of an intended state into imperative actions to reach that state automatically, and so its model doesn't really support "exceptional" processes like restoring backups.
However, you can develop a process for restoring backups alongside Terraform whereby the main restore action is done using the AWS Console, AWS CLI, or API in your own automation, and then you inform Terraform after the fact that it should use the restored object via its state manipulation commands.
For example, if you have an EBS volume managed by Terraform using an aws_ebs_volume resource, you might also use Terraform to configure an AWS Backup plan for that volume, and then backups will be created automatically as per your plan.
In the exceptional situation where your existing volume is lost or corrupted and you want to restore the backup, the person responding to the incident can follow the following process:
Create an AWS Backup restore job either using the AWS Console, the AWS CLI, or some software of your own design using the AWS Backup API.
Once the backup job is complete, consult the CreatedResourceARN to find the id if the new object that was created by restoring the backup. In the case of an EBS volume, this will be the final part of the after the :volume/ separator.
Tell Terraform to "forget" the existing EBS volume object that is now destroyed or damaged:
terraform state rm aws_ebs_volume.example
Tell Terraform to import the object created by restoring the backup as the new remote object associated with the Terraform resource:
terraform import aws_ebs_volume.example vol-049df61146c4d7901
If your old EBS volume is still present but corrupted or otherwise damaged, the final step would be to locate and manually destroy the remant of it, because Terraform is no longer managing it and therefore it would otherwise be left in place forever.
After this process is complete, Terraform will consider the new object to be the one managed by that resource, and you can use Terraform as normal with that resource moving forward. The same principle applies to any of the object types supported by AWS Backup, as long as they have a resource type in the AWS provider that supports terraform import.