Lifecyle rules in Terraform

Managing resource lifecycle in Terraform 

-In this lecture, we will discuss lifecycle rules in terraform, but before that we will get an overview about the differences, between mutable infrastructure and immutables infrastructures

Mutable infrastructure VS Immutable infrastructure

- when we talk about something that is mutable, we talk about something that can be changed or updated after its creation

- so for mutable infrastructure, you can continue making changes and updates to the existing object, and there is no need to recreate it with the new configuration

- in contrast to mutable infrastructure, we have immutable infrastructure

- when we talk about an infrastructure object that is immutable, we talk about an object that can't be changed, updated or modified after its creation

- so if you have some changes or updates to apply, you can't apply them to the current object, the only way to apply them, is destroy the old version of the object and to create a new object with the updated configuration

- so we have here two types of infrastructure:

- mutable infrastructure, that can be changed and updated continously after its creation

- and immutable infrastructure that can not  be be modified after its creation, so the only way to update it, is to destroy the old version and then recreate it with the updated configuration

- Terraform treats the infrastucuture as immutable, so when we make a change to the configuration of a resource, and then running the terraform apply command, terraform does not update the existing version, terraform will first of all delete the old version and then create a new one when with the updated configuration

- But this is not always the desired behavior, in some cases, we want a new resource to be created before deleting the old version 

- the way terraform behaves for updating existing resources, can be changed using the lifecycle meta argument which a block that can be nested within any resource block, regardless of the type of the resource

- we have 4 lifecycle rules in terraform, we will discuss them one by one

The create_before_destroy lifecycle rule

- we will discuss first of all the create_before_destory lifecycle rule

- we will understand what happens when we set the create_before_destory argument to true throw a practical example

- we have here a configuration file needed for creating a file called file.txt with the content "Welcome to Terraform!" inside it

- So by running the terraform apply command, a file called file.txt will be created, containing the text "Welcome to Terraform!".

- if we change the filename argument for example to welcome.txt instead of file.txt, and we apply the configuration file again, Terraform will first of all destroy the old version of the file, and then create a new file called welcome.txt with the same content. 

- But let's say that we are unhappy with this behavior! so we want terraform to create the new file first, before deleting the old version of the file

- We can achieve that by adding the lifecycle meta argument block inside the resource block, and inside this block, we will set the create_before_destroy meta argument to true

- and this will tell terraform that we want to reverse the default order, when terraform perform an update operation

- No when we run the terraform apply command, terraform will reverse the default order followed for updating the resource, so terraform will first of all create the new file with the updated name, and then delete the old version

- This can be benificial if you have for example a server, running your application and you want to make some changes to the sever with terraform, 

- so it's better to tell terraform that the new server must be created first, before deleting the old version, to avoid downtime of your application

The prevent_destroy lifecycle rule

- Let's move now to the prevent_destroy life_cycle_rule

- The prevent_destroy meta argument will allow you to proctect resources from being destroyed, by preventing terraform from applying any plan that would destroy the infrastructure object, associated with this resource

- For example if we have a file created by terraform, and we have the prevent_destroy meta argument set to true, When we run the terraform destroy command to destroy the existing infrastructure objects, Terraform will prevent the plan from being applied, and it will throw an error indicating that the local file can't be destroyed, because the prevent_destroy meta argument is set to true

- We will get the same behavior if we try to make a change to the local file, for example changing the filename from file.txt to count.txt and then running the terraform apply command

- Terraform here will generate the same error for the same reason

- The only way to destroy a resource object having the prevent_destroy meta argument set to true, is either by removing this meta argument from the resource block, or by removing the the resource block from the configuration entirely, which will lead to removing the prevent_destroy setting along with it

- and this can be handy when you want to protect critical resources managed by terraform, such as database instances from being deleted accidentally

The ignore_changes lifecycle rule

- We will see now how to work with the ignore_changes lifecycle rule

- After creating a resource with terraform, and making some changes to the configuration, when running the terraform apply command, terraform will compare the current state of the resource object to the new configuration, and it will try to update the resource object, as mentioned in the configuration file

- we will talk about state in terraform later, in more details

- The ignore_changes feature, is intended to be used when a resource is created with data that may change in the future, but should not affect the resource after its creation.

- For example here we have this configuration file, containing a resource block for creating a file called welcome.txt, containg the text welcome to Terraform! 

- and we have the ignore_changes meta argument set a list containing just the filename attribute, to tell terraform that any change made to the filename attribute must be ignored

- when we run the terraform apply command, terraform will create the file as mentioned in the configuration file

- and if we change the filename in the configuration file, for example from welcome.txt to welcome-to-terraform.txt 

- when running the terraform apply command, terraform will display a message indicating that the infrastructure matches the configuration, even if the filename was changed

- and that's because we have told terraform to ignore any changes made to the filename using the ignore_changes meta argument

- You have to know that only attributes defined by the resource type can be ignore. for example for a local file, you can ignore changes made to the filename, the content or both of them, but we can't ignore changes made to meta arguments which are the arguments that can be used with any resource type, like the depends_on meta arguments

The replace_triggered_by lifecycle rule

- Finally, we will talk about the replace triggered by lifecycle rule

- the replace triggered by lifecycle rule can be used when you want to replace a resource whenever a change is made a group of resources or resource attributes

- lets underestand that with an example

- let's say that we want terraform to generate a random integer and to create a file

- then whenever the content of the file was changed,  we want terraform to generate a new integer which will replace the old version 

- for example if the file content was changed from 15 to 25, terraform must recreate the file with the new content and the random integer must be replaced also

- let's see move now to the configuration file, and see how achieve that using the replace triggered by lifecycle rule

- we have here the configuration file needed to create file and to generate a random integer

- in the resource block of the random integer, we will add the lifecycle meta argument, and we will set the replace_triggered_by meta-argument, to a list containing only a reference to the filename attribute of the local file

- when we apply this configuration for the first time, terraform will create the file and generate a random integer

- then if we take the same configuration, and we change just the content from 15 to 25

- now by applying the new configuration, terraform will first of all delete the old version of file and the old version of the random integer, and then it will recreate them using the new configuration

- So here we didn't change anything related to the random integer, but by applying the new configuration terraform delete the old version and generate a new one, and that's because we have told terraform that the random integer must be replaced anytime the content of the file was changed, and that's done using the replace_triggered option of the lifecycle meta argument

- if we set here the replace triggered by option to a list containg a reference to the file and not a specific attribute of the file, the random integer will be replaced whenever a changed is made to any attribute of the file: so anytime the filename is changed or the content is changed, the random integer will be replaced

- So that is for now i hope that everything is clear and thank you very much