Managed Services April 2024

Why build a tool?

As many companies are moving to deploy infrastructure and solutions using “Infrastructure as code” the tool of choice is often Terraform. Terraform is a solution using plugins/providers to be able to ‘talk’ to many different resource types (Azure, AWS, VMWare etc.).

A challenge with Terraform is that terraform keeps track of changes using a “state”. The state holds information of what already has been deployed. But what if it has not been deployed using terraform? Then such a “state” does not (yet) exist.

This is where the tool comes in. By analyzing the Terraform code and matching this with the already present resources and their configuration, a state file can be built. The great advantage is that existing resources can be transferred under Terraforms control, without redeployment. Which in turn means no, or very little, downtime.

Scope of the tool

The idea to build the tool finds its origins in our landing zone. Initially XMS built landing zones using Bicep (other IaC solution) and now moves to using Terraform. To prevent our customers from experiencing downtime or other issues we would like to make the migration as seamless as possible.

The scope of the tool is oriented on the resources found in the landing zone, exotic resources like Databricks are not part of the tool (yet).

Concept of workings

The highly simplified concept is based on a number of steps

1. Create a deployment framework including pipelines, storage account (for state file), repository holding Terraform code, Service Principal etc. This will later be used to update the platform.
2. Create a state file using the migration tool
3. Store the generated state file to the storage account described in step 1
4. Enjoy updating the hub resources/deployments using Terraform!

The most exciting and challenging part of the process is step 2, creating the state file. This step can be split up in the following parts:

1. Run a Terraform ‘Plan’ to obtain a list of what a deployment would consist of.
2. Verify what the plan would do to existing resources. A large number of updates/deletions may indicate the Terraform code is not aligned with the deployed environment.
3. Retrieve a list of all Azure resources in scope. Filtering resources only in intended subscriptions simplifies the process immensely.
4. Match the Azure resources to the resources in the plan file and use these found matches to import them into the state file.

The illustration underneath explains the process using logical blocks.