Importing cloud resources into the management of Terraform
What is state drift?
In the world of cloud infrastructure management where environments can change fast, maintaining consistency and accuracy can be a challenge when working with Infrastructure as Code. State drift occurs when the actual state of your infrastructure does not match the expected state defined in your Terraform configuration files. This introduces a gap between your infrastructure's intended design and its real-world implementation and look.
Why does it happen? Well it can be a number of things, it can be due to manual changes in the portal or CLI, external processes, or resource modifications that are not captured by Terraforms state files. Without addressing state drift, you risk deploying new changes that could disrupt your services or make codebases entirely useless and redundant.
By understanding and addressing state drift, you can ensure that your infrastructure remains secure, compliant, and aligned with best practices for your resources.
Scenario - state drift and remediation
We will simulate some state drift in our environment and how we can remediate it. We will create folder called demo and a main.tf file with a resource-group. In a proper scenario we would configure some backend configuration to host our state-file like Azure storage so our team can work with the same state but for simplicitys sake we will just use local state in this example.
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "3.71.0"
}
}
}
provider "azurerm" {
features {}
}
resource "azurerm_resource_group" "this" {
name = "rg-test-we-demo"
location = "Sweden Central"
}
In your CLI run terraform init & terraform plan and we should see the following output:
This means we can run terraform apply to create our resource. Approve the changes or alternatively you can type terraform apply -auto-approve to skip the extra verification step.
Introducing drift
Imagine you did not only configure the RG but you also created a bunch of other resources which you have tracked in your statefile. Once you are finished with your work you notice there is a storage account in your resource-group that was not created with Terraform but rather by a co-worker who just deployed from the portal:
There are some ways we can deal with this. You can run the terraform import command but there is since Terraform v1.5.0 a terraform import block resource you can use which we will test today. We will update our main.tf file: with the corresponding code:
import {
to = azurerm_storage_account.this
id = "/subscriptions/<subscription-id>/resourceGroups/rg-test-we-demo/providers/Microsoft.Storage/storageAccounts/stdemodrft1337"
}
resource "azurerm_storage_account" "this" {
name = "stdemodrft1337"
resource_group_name = azurerm_resource_group.this.name
location = azurerm_resource_group.this.location
account_tier = "Standard"
account_replication_type = "GRS"
}To use the import block we can see that we first need the import block itself but we also need to create an additional resource in this case an azurerm_storage_account resource where the resource is imported to.
Once we are done here we will run terraform plan and we can see the import configuration happen as well as any configuration changes that we have missed, any properties on the storage account which does not match the cloud resource:
I can chose to update my azurerm_storage_account resource to better reflect the portal or I can just run terraform apply to change the resource.
This storage account is now under Terraform Management and I can see it when I run terraform state list which means it is actively tracked in the state.
References
About me
