Ansible vs Terraform
What are Ansible and Terraform?
If you are in, or looking to get into, the “DevOps” world, Terraform and Ansible are going to be two names you hear very frequently. There is a good reason for this! Both are outstanding products for creating infrastructure as code that can be used to deploy repeatable environments that meet a vast range of complexity requirements. But what is the difference between these two? Why should you choose one over the other…or should you? Let’s dive a little deeper and talk about some of the similarities and differences these applications have.
Configuration Management vs. Orchestration
For those of you who have read previous writing from me (blogs, guides, etc.), you already know I’m a huge fan of analogies, similes, metaphors, etc. This piece will be no different! Ansible and Terraform are two very similar applications with some key differences. One of those key differences involves two very common DevOps concepts: configuration management and orchestration. These terms generally describe types of tools. Ansible is primarily a configuration management tool, commonly abbreviated as “CM”, and Terraform is an orchestration tool. Now, understand that there are overlaps and these terms are not necessarily mutually exclusive. It helps to use tools that match their strengths, so let’s talk a little about what each type of tool is optimized for.
Ok, as promised, time for the analogy! Think of these tools as an orchestra of musicians. The orchestration tool is akin to the conductor. The conductor ensures the right number of instruments are there and that all of them are playing correctly. If there is an issue, an orchestration tool will generally remove the misbehaving instrument and replace it with another. Orchestration tools are usually focused on the end result and help to ensure the environment is always in that “state”. Terraform is like this. Terraform will store the state of the environment, and if anything is out of order or missing, it will automatically provide that resource when it is run again. This is fantastic for environments that require a very steady state. If something goes wrong, another “Terraform Apply” will rectify the issue! On the other hand, a configuration management tool is more like an instrument repair person. The configuration management tool, such as Ansible, will configure each instrument to ensure it is on key, free of damage, and is working properly. If there is a problem with an instrument, the CM tool will work to repair the issue rather than just replace the instrument entirely.
Do keep in mind that Ansible is somewhat of a hybrid in this aspect and able to replace infrastructure and perform orchestration tasks as well, but Terraform is generally regarded as a superior product in this respect due to its more advanced state management capabilities.
Procedural vs. Declarative
Most DevOps tools can be grouped into one of two categories that describe how they perform their actions. These categories are “procedural” and “declarative”. Now, the definition of these terms are pretty succinct, but there is a large overlap in tools that don’t always fit the mold of one or the other exactly. Procedural describes an application that requires the exact steps to be laid out in the code. For instance, if you needed to scale up the EC2 instances in your environment, you would specify exactly how many instances needed to be created. If you needed to scale down, you would specify the number to be removed. Back to our orchestra metaphor, this is like a conductor asking for 5 trumpets and getting 5 MORE trumpets. Declarative “declares” exactly what is needed, not the process by which the result is achieved. So, if the conductor needed 5 trumpets, or you needed 5 EC2 instances, that’s exactly how many you would have after the code has been executed. If you had 10 and you needed 5, you would just specify a count of 5. In procedural, if you had 10 and you needed 5, you would have to specify that 5 be removed.
So where am I going with all this? Terraform is strictly declarative. You will define your environment, and if that environment changes, it will be corrected on the next “Terraform Apply”. Ansible, on the other hand, is somewhat of a hybrid. You can perform ad-hoc commands that allow for procedural-style configuration or use most of the modules that perform declarative-style. Make sure you read the documentation for any Ansible role you read to ensure you understand the behavior to expect and to know whether you need to explicitly indicate the resources required or if you need to add or subtract those resources to obtain the correct result.
What’s best for me?
I honestly wish I could give you a simple answer. Ansible and Terraform both do a lot of things very well. I personally prefer to use Terraform for orchestration and Ansible for configuration management. Why? Because I find Terraform to be much more intuitive for infrastructure orchestration. Orchestration is what Terraform was created for, and that is its primary purpose. All updates for Terraform are focused on orchestration, and it just seems to be more polished for it. Also, “Terraform Plan” is an excellent tool that provides more useful information than the
Ansible --dry-run command. Ansible, on the other hand, is optimized for configuration management. It can perform orchestration tasks, but that is just part of what it does. As evidenced by Deploy to AWS with Terraform and Ansible course on Linux Academy, I prefer to use the best tool for the task. You may find that you prefer to use one tool for everything, and that is perfectly acceptable!
- Using Ansible Facts to View System Properties
- Ansible Roles Explained
- Using Ansible to Manage Software in Linux
- Ansible Quick Start