So tools like chef, ansible ,puppet or saltstack all follow the same Principle “infrastructure as code” . even some of the tools will also configure us with infrastructure. Ansible has the capabilities of creating your infrastructure and also provision it with necessary softwares. So how is terraform different from these tools?. Here are few points that will say why one should use terraform?
Provisioning vs Orchestrating
As we already discussed tools like chef, ansible etc are mainly designed to provision a machine. In order to use these tool we need to have our infrastructure already created and ready. We then can run some cookbooks or playbooks to automate the installation or provisioning of other things on these
On the other hand, we have the orchestrating tools like terraform , Aws cloudformation where these are specifically designed to create infrastructure. We define our infrastructure in a format and these tools read the format and create the infrastructure defined. Once defined we can use the provisioning tools to provision that infrastructure.
Client/Server vs Client
Chef, Puppet , saltstack etc follow the client/server model. You have a client , server and remote node. You write code on the client to automate things for the remote node and push that code to server. The server checks the code and takes the responsibility of making those changes on the remote node. We need to have extra processes like agents that need to run the remote machine to pull the things that are are available with the server and make the changes. We can call this as a server-client model.
Unlike the above ansible and terraform follows a push model. In this model, we define the state to be changed and then push those changes to the remote machine from a command line. We don't need extra processes running on the remote nodes. All communication to the remote machine happen through ssh connections. This is a light weight model and will not have any overload.
Immutable infrastructure
Immutable infrastructure is an approach to manage services and software deployments on IT resources wherein components are replaced rather than changed. In a production environment. when we try to deploy application, we usually undeploy the existing application and then deploy a new version. We usually make the changes in the existing infrastructure only.
In immutable infra , we deploy a new infrastructure with new version of code rather than making changes ( deploying new version of code ) to the existing infrastructure.
When we use tools like ansible, chef etc and apply more and more updates to existing infra it leads us to configuration drift where infra becomes different from other. With every change we apply we have a configuration file available.
Using Terraform , every change that we apply leads to new infra with new code. Once the new infra is up and running with new code we can delete the older existing infra.
Provisioning vs Orchestrating
As we already discussed tools like chef, ansible etc are mainly designed to provision a machine. In order to use these tool we need to have our infrastructure already created and ready. We then can run some cookbooks or playbooks to automate the installation or provisioning of other things on these
On the other hand, we have the orchestrating tools like terraform , Aws cloudformation where these are specifically designed to create infrastructure. We define our infrastructure in a format and these tools read the format and create the infrastructure defined. Once defined we can use the provisioning tools to provision that infrastructure.
Client/Server vs Client
Chef, Puppet , saltstack etc follow the client/server model. You have a client , server and remote node. You write code on the client to automate things for the remote node and push that code to server. The server checks the code and takes the responsibility of making those changes on the remote node. We need to have extra processes like agents that need to run the remote machine to pull the things that are are available with the server and make the changes. We can call this as a server-client model.
Unlike the above ansible and terraform follows a push model. In this model, we define the state to be changed and then push those changes to the remote machine from a command line. We don't need extra processes running on the remote nodes. All communication to the remote machine happen through ssh connections. This is a light weight model and will not have any overload.
Immutable infrastructure
Immutable infrastructure is an approach to manage services and software deployments on IT resources wherein components are replaced rather than changed. In a production environment. when we try to deploy application, we usually undeploy the existing application and then deploy a new version. We usually make the changes in the existing infrastructure only.
In immutable infra , we deploy a new infrastructure with new version of code rather than making changes ( deploying new version of code ) to the existing infrastructure.
When we use tools like ansible, chef etc and apply more and more updates to existing infra it leads us to configuration drift where infra becomes different from other. With every change we apply we have a configuration file available.
Using Terraform , every change that we apply leads to new infra with new code. Once the new infra is up and running with new code we can delete the older existing infra.
Declarative Code definition
Each of the tools above will follow a way to define the state either it can be a procedural or declarative. Terraform strictly follows declarative style where as we define the state or what is needed. We don't define the process by which the result is achieved.
Why declarative is useful - declarative “declares” exactly what is needed, not the process by which result is achieved. Let's say if we want to create 5 aws ec2 instance , we write our code in both procedural and declarative. Both snippets of code may look same but what is different is what happens when we run the code.
In a procedural mode, lets say i have created 5 aws ec2 instances and now i want to create 5 more. Now i can change the value from 5 to 10 and rerun the code. In this case i will be having 15 ( 5 from previous run and 10 from current run ). This is quite different with terraform. In a declarative we declare things and terraform will know how to create them.
In the same above case , if i change the value from 5 to 10, only 10 server will be available. Terraform will only create the new 5 servers that we requested. This is bcoz terraform will save the state of the previous run and we we run again it will first identify the current state and then do the necessary actions.
State Plan & Store
As a part of infra configuration, terraform will store state about the infra and configuration. The state is used by terraform to map real world resources to your configuration, keep track of metadata and to improve performances for larger infrastructure. So when ever we rerun the same code again, terraform will check the current state and perform the necessary actions.
Also before creating the infra itself, terraform will give a detailed information about the infrastructure that is going to create and once confirmed it will move to the creation.
Above a few things that make terraform the best tool for infrastructure creation.
More to Come, Happy learning :-)
No comments :
Post a Comment