Ansible and Terraform are two popular command line DevOps tools that provision and configure servers. Ansible is the more mature of the two, originating in 2012 and eventually acquired by Red Hat in 2015. Terraform is a Hashicorp product and was first released in 2014. This article takes a look at both tools theory of operation and shows what features they share and how they contrast. First we’ll look at some of the foundational concepts, then a direct comparison followed by how to bring them together to leverage the advantages of each.
Infrastructure as Code
Infrastructure as code (IAC) commonly refers to the practice of defining (usually) virtualized infrastructure in a declarative model defined in text files that can be stored in conventional version control systems commonly used in software engineering. In concert with a cloud orchestrator, the virtualized infrastructure configuration is kept in sync with changes as they occur in the configuration files (i.e. the “code”).
Immutable infrastructure is a practice of replacing infrastructure components rather than modifying their configuration. This approach addresses common problems encountered when modifying configuration over time, namely configuration drift and snowflake servers. The immutable approach will, rather than modifying configuration, create a new instance with the new configuration, switch traffic to it, and then switch over. This makes deployments more predictable and recreatable, but isn’t realistic for frequently reconfigured components like firewalls. Of the two products, Terraform is more compatible with with this approach.
Orchestration vs Configuration Management
Orchestration addresses the needs to automate the lifecycle of environments. It concerns itself with infrastructure provisioning, scaling, deprovision, and operations. Configuration management (CM) automates the configuration of applications or hardware. As such it tends to be highly specialized for particular applications or domains. Orchestrators will delegate to configuration managers to configure elements of a deployment. Such delegation can be either triggered by the orchestrator, or completely delegated for day 2 operations, depending on the CM tool.
Procedural vs Declarative
A procedural approach to automation is similar in concept to what a recipe is for cooking. A procedural automation consists of a listing of each step required to achieve the goal of the automation. Procedural systems are completely general in application, capable of any automation task the underlying hardware is capable of.
Declarative automation is an approach where the end goal or attributes of the automation is described, and through a purpose built program it is interpreted in order to realize the goal. Declarative systems are not general purpose, and are applied to specific domains. Ultimately, declarative systems execute procedural code, and as such are at a higher level of automation.
Provisioning with Ansible vs Terraform
Terraform focuses on infrastructure automation, and interprets a model described in Hashicorp Configuration Language (HCL). With Terraform, the elements of a desired environment are individually described ( e.g. servers, networks, keypairs, etc…) along with their relationships to each other. It evaluates the model, develops a plan based on the dependencies, and commands the IaaS in an optimal way. It’s also idempotent and resource aware, meaning that repeated runs will do nothing if nothing in the environment or plan has changed. If something has changed, it will synchronize the cloud infrastructure with the intent of the plan.
Ansible takes an imperative or procedural approach, which is familiar to anyone experienced in scripting. Users create “playbooks” which are evaluated from top to bottom, and executed in sequence. Playbooks typically concern themselves with the configuration of individual hosts or network devices, which lends itself to a procedural approach. Ansible does have the ability to provision cloud infrastructure as well, but its procedural nature makes it ill suited to large infrastructure deployments. Since Ansible is suited for configuration management, it isn’t really limited to cloud applications. Ansible is as happy configuring bare metal servers as virtual ones.
|Tool category||Orchestration||Configuration management|
|Approach||Immutable infrastructure||Mutable infrastructure|
|Provisioning||Specializes in infrastructure provisioning||Limited support for infrastructure provisioning|
|LIfecycle management||Lifecycle aware. Maintains state of deployments.||No lifecycle awareness|
|Command line operation||Yes||Yes|
Ansible vs Terraform
We’ve seen how Terraform and Ansible are command line oriented tools that are really complimentary in capability rather than adversarial. Lifecycle management of infrastructure lends itself to a Terraform declarative approach, whereas the imperative approach of Ansible is better suited to configuration management because of its customizability. Neither tool is active; both are “run and done”. As such, they don’t really address high scale or high availability requirements.
Cloudify occupies a different niche than these tools; much more focused on enterprise use cases that value high scale and high availability. Rather than a passive approach to state management which potentially requires scanning hundreds or thousands of nodes for health checks, Cloudify integrates with monitoring applications like Nagios and Prometheus in order to respond in a focused manner to provide real time day 2 operations like healing and scaling.
The good news is there is no reason to choose, as Cloudify will perform cloud orchestration by commanding both Terraform and Ansible in scopes where they are best suited. Take a look at the plugins for Terraform and Ansible for details.