Ansible vs. Terraform: Comparing Pros and Cons for Cloud Automation and Deployment
Recently, during a morning coffee break, I had a discussion with my DevOps colleague about which tools to use for automating infrastructure and application deployment on cloud platforms such as GCP, AWS, or Azure. Our conversation soon turned into a lengthy discussion about the pros and cons of various tools, and I want to summarize our thoughts for you.
It’s worth noting that this article is not a tutorial on either Ansible or Terraform. To fully understand the content, you should have some hands-on experience with these tools or a general understanding of cloud technology.
Basically, we both agreed that Ansible and Terraform are two of the best tools available, not only because of their existing integrations with different cloud vendors but also because of the large community of open-source developers and the support provided by HashiCorp and RedHat. We believe that these tools will continue to be relevant in the years to come, and we may even see enhanced integration between them.
First, let’s discuss why Terraform might be a good choice for you and then compare it to Ansible. Finally, we’ll explore why it may be beneficial to use both tools together. Although there has been some integration work between the two, we’ll discuss this further at the end of the article.
Why Terraform?
I don’t want to go into too much detail about why Terraform has become a go-to tool for deploying and managing infrastructure in recent years, but I want to provide you with some pro tips on its features and potential drawbacks.
terraform plan -> apply
First of all, I believe the most indispensable feature of Terraform is its ability to keep track of the state of the infrastructure after deployment and allow you to plan changes before applying them. Imagine you want to make a change to your infrastructure, such as deploying another VM or scaling up your Kubernetes cluster resources. If you’re working in a testing environment where you can easily redeploy everything, this might not be a big deal. However, if you’re working in a production environment, any errors or downtime can have significant consequences for your clients. Terraform’s planning stage allows you to do a dry run of your changes and informs you of any potential issues before you apply them, reducing the risk of problems arising during deployment.
terraform refresh
Another useful feature of Terraform is the ability to refresh the deployed infrastructure against the state file. This can be particularly helpful in the event that a resource in your infrastructure fails offline due to an application exception. The apply and plan stages both perform a refresh and if a resource has failed, Terraform will detect it and inform you during the plan or apply stage that it needs to be redeployed.
Dependency Graph
Terraform also allows you to build a dependency graph of the infrastructure you’re trying to deploy. For example, if you want to deploy a Kubernetes cluster, you’ll need to deploy the VPC network and subnetwork beforehand. By using the depends_on parameter, you can define a dependency between the two, ensuring that they are deployed in the correct order. This is quite powerful in comparison to Ansible, which always executes tasks in the order they are specified.
Terraform providers
In addition to using standard community-maintained Terraform providers, you can also develop your own provider. I have personally contributed to the Terraform LXD provider, which is written in Golang code that reads the Terraform HCL specification and turns it into API calls for the corresponding tools. Developing a provider is relatively simple, and it can be a great way to extend Terraform’s functionality to meet your specific needs.
There’s a lot more I could say about best practices for using Terraform, but I’ll leave that for another time. In conclusion, I almost always choose Terraform when setting up infrastructure backbone components, such as Kubernetes clusters and networking. However, it’s important to note that there’s a big difference between infrastructure deployment and application deployment, and this is where Ansible comes into play.
Why Ansible?
While Terraform is great for deploying and managing deployed infrastructure, it lacks the flexibility and support for performing application-level tasks. For example, if you want to deploy a VM and run an application inside it, Terraform can set up the VM but may not be suitable for deploying the application as well. Additionally, Terraform doesn’t apply changes in a pre-defined order like Ansible does, which can be problematic for complex applications that require a specific sequence of commands to deploy or configure.
Ansible, on the other hand, allows you to specify the commands or roles in the order in which they should be executed each time the playbook is run. This not only makes it easier to manage and configure infrastructure but also ensures that all machines are equally configured, potentially saving you a lot of time.
For example, instead of manually SSH-ing into each machine and applying the configuration, Ansible can automate this process and ensure that every machine is configured the same way. This is particularly useful for complex configurations that need to be applied to dozens of machines.
Ansible for infrastructure?
While Ansible is well-suited for post-configuration of the infrastructure, it’s not recommended for infrastructure deployment itself. Let’s say you have 50 VMs deployed on your cloud vendor and one VM fails. In this scenario, Terraform can detect the failure and redeploy only the affected VM, while Ansible would redeploy all 50 VMs every time the playbook is executed due to its imperative design. This approach is not only catastrophic for production environments due to significant downtime but also unnecessary for Ansible to do so. Therefore, it’s essential to use the appropriate tool for each task to avoid any negative impacts on your infrastructure.
Ansible collections
In addition, to Terraform providers, Ansible collections can also be developed and added to the ecosystem. While the working principle is similar, the Ansible backend is written in Python, which may be an advantage for those who prefer it.
To summarize, Terraform is excellent for setting up the infrastructure backbone, while Ansible is better suited for application-level tasks and managing infrastructure configurations. When searching for Terraform providers or Ansible collections, it is important to choose those that are backed by a large community or supported by companies like Google, Red Hat, and others. This ensures that the tool will be maintained and improved over the next few years, and you won’t have to worry about the tool being deprecated.
Why not both?
As you have seen in this post, both Terraform and Ansible excel in their respective domains, but they also have their limitations. While speed and automation are important factors for deployment, it is equally important to have reasonable confidence in the deployment process. Terraform is a robust and reliable tool for deploying infrastructure, whereas Ansible is well-suited for deploying application-level configurations with a lower possibility of human error.
In my case, using Terraform for infrastructure and Ansible for application deployment resolves most of my problems. But how do these tools fit together?
Recently, the Red Hat community, in collaboration with their partners Kyndryl and XLAB, has been adding more value to infrastructure as code by developing tools like Ansible collection cloud.terraform. This tool has been rapidly developed to improve integration between the two tools.
Moreover, Red Hat is promoting the use of both tools together by continuously expanding and adding features to both tools. A recent article (March 20, 2023) showcases some of these new features.
Conclusion
While the integration between the two is still in its early stages, it looks very promising. Combining Terraform and Ansible makes it much easier to manage infrastructure and imposes a nice separation between infrastructure and application deployment. The future will reveal whether the two can be integrated smoothly, but for now, it is an exciting development.
Thanks for reading! 😎 If you enjoyed this article, hit that clap button below 👏
Would mean a lot to me and it helps other people see the story. Say Hello on Linkedin | Twitter
Do you want to start reading exclusive stories on Medium? Use this referral link 🔗
If you liked my post you can buy me a Hot dog 🌭
Checkout the rest of my content on Teodor J. Podobnik, @dorkamotorka and follow me for more, cheers!
