8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23c | Misc | PL/SQL | SQL | RAC | WebLogic | Linux
Ansible vs Terraform
Related articles.
What is Ansible?
Here's a quote from Wikipedia about Ansible.
"Ansible is an open-source software provisioning, configuration management, and application-deployment tool enabling infrastructure as code. It runs on many Unix-like systems, and can configure both Unix-like systems as well as Microsoft Windows. It includes its own declarative language to describe system configuration. Ansible was written by Michael DeHaan and acquired by Red Hat in 2015. Ansible is agentless, temporarily connecting remotely via SSH or Windows Remote Management (allowing remote PowerShell execution) to do its tasks."
What is Terraform?
Here's a quote from Wikipedia about Terraform.
"Terraform is an open-source infrastructure as code software tool created by HashiCorp. Users define and provide data center infrastructure using a declarative configuration language known as HashiCorp Configuration Language (HCL), or optionally JSON."
Which is Best?
After reading the two definitions above you could be forgiven for thinking Ansible and Terraform do the same thing, so you only have to pick one of the two right? Unfortunately it's not really that simple. There are many tools that can be used to support infrastructure as code, and they all have their strengths and weaknesses, but also have a lot of overlap in their functionality. Any comparison is overly simplistic and flawed, but this is how I view it.
Terraform's strength is describing and provisioning the big picture. What is our network topology? What cloud services and virtual machines make up our infrastructure? It stores the current state of our infrastructure, and allows our definition (code) to be replayed, only applying changes. This allows us to incrementally change our big picture in a controlled manner. A change may be as simple as adding new disks to a virtual machine (VM) or changing a parameter of a cloud service. It might be as complicated as provisioning a whole new system in our data centre or cloud subscription. Notice the focus on provisioning, and less emphasis on configuration. Cloud platforms can often be configured by Terraform, depending on the support included in the Terraform provider, but Terraform is typically considered a provisioning focussed tool.
Ansible's strength is describing and configuring the fine detail within virtual machines. What packages are installed? What local firewall rules are in place? What is the filesystem layout? What applications are installed? It doesn't store the state of the configuration, but tests to see if tasks have already been applied, and only applies them if it can see the resulting configuration is missing. There is a greater emphasis on configuration management inside kit, and less emphasis on provisioning of kit itself.
Over time Terraform has become better at configuration management, especially for cloud platform as a service (PaaS) offerings. By the same token Ansible has improved for provisioning. There are Ansible modules available to allow us to provision cloud services, but they don't manage state like Terraform. If we have some Ansible to build 10 new VMs, we have to be careful we don't get 10 new VMs every time we run it, rather than maintaining our limit of 10 VMs. Remember, it won't store the state of our big picture.
Because of the overlap there are people that will try to focus on a single tool, when maybe combining the two would be better. For example, we might want to provision our kit using Terraform, but do the long term management of our VMs with Ansible. This should become more clear when we look at example use cases.
Example Use Cases
Giving some example use cases should help to give us a clear picture of which tooling we should be considering.
Regular virtual machines with a long term lifespan
We want to build custom virtual machines that are deployed once, and maintained over a period of time. Any configuration changes are done on the existing VMs, rather than rebuilding them.
- We build bare-bones VM images with Packer.
- We deploy new VMs on-prem or to the cloud using Terraform.
- We configure and perform long term maintenance of the VMs using Ansible.
Regular virtual machines that are replaced rather than maintained
For some VMs, like web servers and basic application servers, we may decide to take a build and burn approach, like we would with Containers. Effectively the VMs are not used as long term systems. Rather than make configuration changes, we rebuild and redeploy them.
- We build complete VM images with Packer, with all necessary software and configuration in place.
- We deploy VMs on-prem or to the cloud using Terraform.
In this use case, we probably don't need to consider long term maintenance, since we just replace the kit, so we probably wouldn't consider Ansible here.
Containers that are replaced rather than maintained
Typically we would not expect to maintain containers. The emphasis is very much on build and burn. If we want to make a change we alter the container image, then replace all containers using that image.
- We build a new version of our container image and push it to our container registry.
- We redeploy all our containers based on the new image using Terraform.
As with the previous example, we don't need to consider the long term maintenance of the containers, so we don't need a tool like Ansible.
Systems made of cloud Platform as a Service (PaaS) offerings
When we are using a cloud platform as a service (PaaS) offering, we are not provisioning traditional VMs. We are not responsible for the low-level implementation or configuration of the underlying kit.
- We deploy the cloud PaaS offering using Terraform.
- We make subsequent configuration changes to the cloud PaaS offering using Terraform.
We don't need a tool like Packer, because we are not using VMs, so we don't need to build images. The Terraform providers for many cloud platforms include the ability to provision them and make basic configuration changes, so we don't need a tool like Ansible for long term configuration management.
Mixed environments
In reality we probably have mixed environments, where we can see examples of all four of the above. We should make the choice of tooling on a case-by-case basis, rather than forcing ourselves into a one-size-fits-all approach.
What About Other Tools
In this article we've focused on the roles of Ansible and Terraform in infrastructure as code, but these are not the only tools that can fulfil these roles. We could make similar arguments for "CloudFormation vs SaltStack" or "Morpheus vs Puppet". In each case these tools have their sweet spot. It's up to us to make an educated decision about which tools fulfil our requirements, and as we have seen the likelihood is we will use several.
For more information see:
Hope this helps. Regards Tim...