Ansible VS Terraform



IDEOLOGY: 

Two separate platforms, two separate goals.

Minor overlap.


Ansible is a CM (configuration management) tool. It is great at tracelessly 
executing commands (in the form of modules, but on the remote host just 
commands) on a specified group of servers as defined in the inventory file. 
Little to no configuration is required to get an ansible instance up and 
running.

It is extraordinarily versatile and capable of doing nearly anything, like 
orchestration, but some things naturally lend themselves better to 
Ansible’s “vision of the world”. Just because you CAN do something with 
ansible doesn’t mean you should.

Idempotency is the name of the game here, and good ansible scripts can be 
run again and again without changing prior runs.

BUT. 

Ansible is stateless.Ansible modules that are idempotent check “state” of 
very specific things, (such as “file exists”)but ansible itself is not 
aware of anything before a module is run. Ansible does not remember what it 
has done. In this respect, one may consider Ansible to be merely a smarter, 
more powerful scripting language than bash. Logging, history, job execution 
and job run results are all the responsibility of the user to store 
somewhere, or else they simply do not exist after the session that ran them 
has been closed. 

Changing configurations for existing servers gets harder and harder as time 
goes on, because any ansible playbook can be run and you will have no 
knowledge of it having happened, thus leading to many possible errors in 
your configuration.


Terraform, on the other hand, is a stateful orchestration tool. We provide 
state declarations, where we define what we want our infrastructure to look 
like, and then Terraform goes out and actually does it for us. 

A major result of this difference between Ansible and Terraform is after 
the first setup has been completed. Let’s say we have a cluster of 5 nodes, 
which we want to scale out to 10. With ansible, you don’t have any way of 
knowing how many nodes exist. Even if we still have the original parameters 
used to create the cluster, we don’t know for sure that the cluster still 
actually reflects the original configuration. So we have to either trust in 
our own brains and the brains of our team, and former team members, that 
every change and ansible run was always logged, and that everything is well 
documented, or actually manually figure out what nodes exist. 

Let’s say that we live in a perfect world, and we know for a fact that the 
cluster has not changed since creation, and that we still have the original 
parameter file. 

In order r\to scale out our cluster to reach 10, we need to manually tell 
Ansible how many new servers to add in order to reach our new desired 
state. In our example, we need to tell ansible to add another five nodes. 
With Terraform, however, we simply declare that we want 10 nodes, and 
Terraform figures out how many to add based on what actually exists. 

The same goes for deletion.


Such an approach naturally means that Terraform likely does a much better 
job at orchestration, while Ansible should be used for adhoc, often 
unrepeatable tasks. A good example of a time when Ansible does better than 
Terraform is configuring a database instance. 

The Terraform solution for such things is to simply deploy all clusters 
with packer, or docker. Then all configuration is done manually in one 
image, and deployments should be very simple. (Another benefit of this is 
eliminating configuration drift) This seems to require that we maintain a 
multitude of images as templates. 

However, this cannot answer every need, and when, for example, you want to 
update the ~/.bash_aliases file across 500 nodes, Ansible seems to be the 
clear tool for the job.Disclaimer- I have only used ansible. My terraform 
knowledge is only from minor experimenting and research.



USE:

Ansible files are written in YAML. Terraform files are written in HCL 
(Hashi Config Language). Both are human readable.


Ansible files are run sequentially. TF rearranges its code files to run the 
right, logical way.


TF graph manages EVERYTHING - variables, resources, dependencies,etc 
required to launch instances.


SUMMARY:

Ansible and HashiCorp (the company behind Terraform) suggest using both 
tools together 
<https://www.hashicorp.com/resources/ansible-terraform-better-together> 
using both tools together to reach the perfect solution. I tend to agree, 
based on everything I’ve seen in my research on this topic.

On Monday, March 30, 2020 at 8:44:44 PM UTC+3, Kaushal Shriyan wrote:
>
> Hi,
>
> I have read about Ansible suited best for configuration management and 
> Terraform which is best suited for Provisioning. Is there a way to invoke 
> terraform scripts using ansible and Is there a way to invoke Ansible 
> playbook using Terraform?
>
> Any use cases which will help me understand better to choose the right 
> tool for the job? On what scenarios I should use Ansible and Terraform. Can 
> I use both tools to do provisioning and configuration management for Cloud 
> computing platforms like AWS, GCP and Microsoft Azure?
>
> Please let me know if you need any additional details. I look forward to 
> hearing from you and thanks in advance.
>
> Best Regards,
>
> Kaushal 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/f92003c6-66f9-4dea-85b4-a522fa7fa650%40googlegroups.com.

Reply via email to