Ansible, Chef are for building configuration, you know menus, staff schedules, grocery lists. Ensure a restaurant is configured correctly to serve customers with its wait staff (Ansible)
You can use an excavator to configure the stuff inside the restaurant. People do it. It's just not generally the most efficient way to do it. And you could have the wait staff at a restaurant pouring concrete for their second place a town over. You could do that too, but a lot of people would use the excavator.
So what really makes these tools effective is when you start using them at scale. They start to become helpful once you realize how much you can do with how little, and they each have this same strength solving different levels, and their strengths become weaknesses at the other end.
a)Ad hoc scripts
The most straightforward approach to automating anything is to write an ad hoc script. You take whatever task you were doing manually, break it down into discrete steps, use your favorite scripting language (e.g., Bash, Ruby, Python) to define each of those steps in code, and execute that script on your server
b) Configuration management tools Chef, Puppet, Ansible, and SaltStack are all configuration management tools, which means that they are designed to install and manage software on existing servers.
c)Server templating tools An alternative to configuration management that has been growing in popularity recently are server templating tools such as Docker, Packer, and Vagrant. Instead of launching a bunch of servers and configuring them by running the same code on each one, the idea behind server templating tools is to create an image of a server that captures a fully self-contained “snapshot” of the operating system (OS), the software, the files, and all other relevant details.
d)Orchestration tools Server templating tools are great for creating VMs and containers, but how do you actually manage them? Handling these tasks is the realm of orchestration tools such as Kubernetes, Marathon/Mesos, Amazon Elastic Container Service (Amazon ECS), Docker Swarm, and Nomad
e)Provisioning tools Whereas configuration management, server templating, and orchestration tools define the code that runs on each server, provisioning tools such as Terraform, CloudFormation, and OpenStack Heat are responsible for creating the servers themselves. In fact, you can use provisioning tools to not only create servers, but also databases, caches, load balancers, queues, monitoring, subnet configurations, firewall settings, routing rules, Secure Sockets Layer (SSL) certificates, and almost every other aspect of your infrastructure
Ansible is for 'inside' virtual machines or computers, Terraform is for 'outside' virtual machines or computers.
Inside a machine you might have software, configuration, assets. Outside a machine you might network connections, firewalls, disks, dns etc.
This isn't a comprehensive comparison, but when you start from nothing, it doesn't really help to do a syntax, provider or imperative vs. declarative.
https://www.hashicorp.com/resources/ansible-terraform-better...
TLDW; You can do resource management (e.g. creating EC2 instances in AWS) and deployment (e.g. installing packages on an instance) through both Terraform and Ansible. Terraform is best used for resource management - the documentation states using the "provisioning"/deployment function is a last resort. Ansible is great at deploying packages but less so at resource management for the reasons you'll see in the other comments. Either use them together for what they're good at, or use Terraform to do resource management and other techniques (such as prebuilt images) for deployment:
https://www.terraform.io/docs/provisioners/index.html
Also useful:
https://blog.gruntwork.io/why-we-use-terraform-and-not-chef-...
For example, you can use Terraform to provision virtual machines, database instances, or Kubernetes clusters on AWS. Terraform does this via the AWS API.
In my opinion, Terraform is better for provisioning because of the way it manages its own state. Terraform remembers what resources it created the last time it ran, and can edit or delete them according to any change in your Terraform code.
I like Ansible, but not for managing cloud resources. Ansible has no memory. For example, if I ran a playbook that installs MySQL, Ansible has no built-in way to undo this change and bring me back to my previous state.
The Reconciler Pattern basically means:
* there is some notion of "expected" state, which is what you define (declaritively) in the configuration
* there is some "actual" state, which is basically what is running at whatever cloud service, etc. you are dealing with.
* the reconciler's job is to query the actual state, compare it to the expected state, calculate the difference (usually in terms of a graph), then make whatever changes it needs to to bring "actual" in line with "expected".
Kubernetes, SaltStack, and others implement the same pattern (just on different levels of resources) and it's becoming increasingly common and important to understand if you're working with cloud stuff.
https://www.oreilly.com/library/view/cloud-native-infrastruc...
Terraform can only provision cloud resources on AWS/GCP/Azure/other. Usually it gets support first for new products they release. Terraform is very static (see issues with sharing the state file) so it's more indicated to configure very static stuff, like networking and subnets.
Ansible is an imperative way of setting up your cloud. You tell it to do certain things, install this package, copy this over there.
Hope it helps
To a large degree expressing something is a "poor choice" is an opinion, maybe expert, about optimizations, not about capabilities.
When one is learning, adopting the value judgements of experts is a form of premature optimization that actually prevents learning.
The only way to build your own opinions is through your own experience. You will need to have your own problems, and solve them using a variety of tools, to build your own opinions.
Try both tools in real problems, and the mental model that accrues in your experience will start to guide your opinions about ways to optimize your work.
Also- everybody is just making it up. And all tools suck.
I don’t know Ansible much, but I believe it’s more of a procedure-oriented system, where you declare the steps necessary to reach A, then again to go from A to B. This can be an issue if any item is actually not in the state you expected.
Terraform tells how your Infastructure should look like. Ansible what software should be on your infrastructure/servers.
I tend to use Terraform to describe how the underlying Cloud infrastructure should look like. I use Ansible to describe and configure what software should be running on those servers.
Usage cases:
Simply put Terraform cloud infrastructure provisioning. Ansible server software and configuration files provisioning.
Otherwise both are quite good.
If you're familiar with Packer, then Packer is responsible for creating identical VM images which can be integrated to a CI pipeline and provisioned and baked using Ansible. This baked image is then deployed using Terraform.
Be advised that provisioning in Terraform during VM deployment is not recommended since it increases startup time of the machine. To perform ad hoc configuration management, you use Ansible.
You could very well use Ansible for managing and deploying cloud resources, but that's not what it's meant to do. Moreover, Ansible does not support the concept of state as does Terraform.
Usually Ansible is used for declaring the desired state of the individual servers for example you may use it to manage installed packages and configuration files on the servers.
Whereas with Terraform you declare the desired state of cloud resources for example you may ask Terraform to give you 5 EC2 instances, 1 RDS instance for DB and 1 S3 bucket for storage.
There's some overlap between them but what I've said is largely accurate.
Ansible is much more of an imperative system, sort of "executable YAML". You define a series of tasks in a YAML file. There are predefined tasks for standard things that you need to do when configuring a system, e.g. creating a directory or generating a config file by merging Ansible configuration variables with template. You can and should make these tasks idempotent, but as the system gets more complex, it becomes difficult and runtime can be slow as it compares tasks one by one to the running system.
Both systems suffer somewhat from difficulty in writing code. The fundamental task is to transform configuration variables and templates into running resources. To do that, you need loops, if/then/else logic, etc. Ansible has some constructs, but it is basically string manipulation, with a backdoor of being able to write modules in python. Terraform has a better syntax to define resources. Logic is generally things like ternary operator and list comprehensions. Terraform 0.12 improved this tremendously, but it is still somewhat weak. Ansible has a bit better management of config variables. Terraform tends to make you serialize things through environment vars, and it's awkward to define structure sometimes. Both would benefit greatly from first class functions and programming logic, even as they are "functional", just transforming data.
I love them both, and I hate them both. Terraform is best for provisioning complex infrastructure. Ansible is great for setting up instances, and it's easy for everyone to understand, dev and ops. Here is a complete example of deploying a complex, full-featured app to AWS using Terraform and Ansible: https://github.com/cogini/multi-env-deploy
I feel like we are suffering through a period where the tools are immature. People are focusing on syntax, but we are missing fundamental parts of the way the system should work. https://www.cogini.com/blog/is-it-time-for-lisp-in-devops/
The exact same thing is going on in the Kubernetes world. Back in the .com days, we would laugh at the "HTML programmers", but now we are "YAML programmers".
There are a couple of fundamental ways of managing the new cloud systems, all of which are better or worse depending on what you are doing. There are declarative systems like Terraform or CloudFormation. There is imperative with tasks, like Ansible. There are things that talk directly to the API like boto. There are tools like Pulumi which take a library approach in a general purpose programming language. Dockerfiles are crying out for higher level solutions, which are being developed. Ultimately I like the approach of a dedicated syntax like Terraform, but with more programming capability, or Pulumi.