Common Pitfalls to Avoid When Using the Terraform Lifecycle Meta Argument

Need of using “create_before_destroy” lifecycle :-

Let us assume you have a critical MySQL database in production and you wish to move from MySQL database to PostgreSQL database.

Here we could choose to either

1. Delete MySQL DB first and then create PostgreSQL DB later
2. Create PostgreSQL DB first and then delete MYSQL DB

If we choose first option , we will have downtime as our DB is deleted until we create new PostgreSQL DB.

If we choose second option , we will have zero downtime.

So, when working with critical resources as databases, we would wish to create new resources before deleting existing ones.

The same behaviour we can achieve using create_before_destroy lifecycle rule for resources when using Terraform.

Now that we understood the use case of create_before_destroy lifecycle, let’s now jump into our next section .

Problems with using “create_before_destroy” lifecycle :-

Let us look at simple terraform code segment below. We defined a local_file resource with filename and content. When we run “terraform apply ” it will create a file for us with content .

Great! Everything is working as expected. What do you think will happen when we make below change to content and re apply the code? It should be creating a file with the new content right ?

resource "local_file" "file1" {
  filename = "hello.txt"
  content  = "hello world! with a change"
  lifecycle {
    create_before_destroy = true
  }
}

But in reality after applying the changes , the file is gone 😲. But wait, isn’t it supposed to create a file the content! What just happened here 🤔?

Let us see what actually happened here using a simple diagram👇.

1. First , Terraform found a file with defined name already in the real world. So, it needs to replace this file with new file we defined.

2. As we have applied lifecycle rule saying, you must create the resource before deleting the resource in case of replacement , it first tries to create the resource.

3. As it tries to create the resource local_file with name hello.txt , it will find that there is already an file with the name. So, it will ignore creation.

4. Now it will delete older file hello.txt. So, we will left with no file at all at the end.

How can we overcome this problem 🤔? It’s clearly not the behaviour we expected.

Let’s see some possible solutions to overcome this.

Solutions for this problem :-

Solution 1:-

Re-applying Terraform changes ✅

You could just re run “terraform apply” second time.It will create the file this time , as it’s not going to find a existing file with same name. So, it doesn’t need replacement.

Cons:-

1. Some times we may miss to re apply the change.
2. New Developers may find it confusing to second time

Solution 2:-

Using random strings as suffix/prefix to your resource names ✅

Whenever we use create_before_destroy lifecycle make sure to use resource name inside the block have prefix or suffix have a random string. This will ensure whenever it tries to replace resource , it’s not going to skip creation and it will delete the older file as they both them are going to have different names. You could see the steps in below diagram.

Below is the code segment example on how we can use random provider

We can have a random_id as suffix/prefix for our resource name. This random id will change based on the keepers we defined. As we know that whenever content changes we need replacement , we have put content as keeper for random_id re-generation.

Conclusion:-

Whenever you try to use create_before_destroy lifecycle rule , make sure to configure resource names with random suffix/prefix to avoid unintended deletion without creating the resource itself.

Would you like to know more about other lifecycle rules, then here is the link for Terraform lifecycle rules: The lifecycle Meta-Argument