This blog post is more on the fundamental principle of Terraform and hopefully should provide you a framework and a perspective to understand the Essence of Terraform.
If anyone of you who is going through this does not have a basic understanding of Terraform, I highly encourage you to go through the basics and get back to this blog post.
Having worked with Terraform since its early inception and professionally migrated and provisioned around seven infrastructures, I do feel like I am somewhat qualified to comment on a few aspects of Terraform.
The Essence
Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. -- From Official Terraform Documentation
The above definition of Terraform simply means it is a tool that allows us to write syntactically structured configuration describing infrastructure resources. It is also responsible for managing the lifecycle of resources throughout different stages such as provisioning, changes, versioning, and destruction.
Note: Resources could be your S3 Bucket, AKS cluster, EKS cluster, ECR, EC2 instance, Azure blob, etc. You get the idea.
But if we think about it, Terraform is the best possible documentation you could have of your infrastructure that actively mirrors your live infrastructure.
The advantage here is that Terraform can understand your documentation and augment it with runtime. This runtime will then "ideally" try to reflect your updated documentation with actual infrastructure in your Cloud. For instance, if your documentation mentions 3 EC2 instances and your current infrastructure has 2 instances, it will spawn one extra instance to match your documentation. Similarly, it will remove 2 instances if your documentation mentions 1 instance and your actual infrastructure has 3 instances running.
The only job of Terraform is to match whatever you have documented in the form of configuration against your live infrastructure. And during this process of trying to converge to the desired state from the actual state, it does all sorts of trickery such as deletion of resources, an in-place update of resources, and creation of resources.
It will "magically" figure out the dependency graph of all your resources and comes up with the action plans in order to reach that desired state. This action plan that it comes up with in order to reach the desired state from the actual state is captured by the command called terraform plan. This command will provide you with a series of actions such as create, delete, or update that it will execute to converge to the desired state.
Finally, you will run terraform apply if you think the proposed action plans generated by terraform plan are what you actually intended for. After successful completion of terraform apply, you will have your live infrastructure that exactly matches your documentation.
I believe this is everything you need to know in order to understand the very Essence of Terraform and the rest is implementation details.
P.S. The word "documentation" for writing those configurations is called HCL which stands for Hashicorp Configuration Language. This is JSON compatible and allows us to declare those infrastructure resources which is then interpreted by Terraform. They like to call it "Human Readable", but I am not sure if I agree 100% with that claim.
Top comments (1)
I wish you hadn't shared your private email on the above Terraform lifecycle screenshot. :)