Ansible and chef are configuration management (CM) tools that help sysadmins and DevOps professionals manage a large number of servers. They excel at repetitive task automation, simultaneous deployment of apps and packages to a group of servers or configuration and provisioning of new servers from scratch.
Ansible vs Chef Infographic
What is Ansible?
Ansible was released in 2012 by its parent company AnsibleWorks and has since gained a dedicated following.
Ansible is written in Python and only requires the Python libraries to be present on the servers to be configured, the default on almost all Linux distros.
Ansible's unique selling points are its lightweight, relative ease of use and speed of deployment compared to other CM tools.
In contrast to Chef, you don't need to learn Ruby to use Ansible. This is because Ansible packages all commands into YAML modules called playbooks.
This means as long as your preferred language can output JSON modules, you can use Ansible.
Ansible also does away with agents, all master-agent communication is handle by standard SSH commands or the Paramiko module that provides a Python interface for SSH2.
This is a great added bonus due to SSH's in-built security.
What is Chef?
Chef was released in 2009. It is supported by parent sponsor OpsCode. It is frequently compared and contrasted to other old-timer CM tools like Puppet. Like Puppet, Chef is written in the Ruby programming language and its CLI uses a Ruby-based DSL. The software can be run on a client-server or in a standalone called Chef-solo.
Chef utilizes a master-agent model and a master server. This means a Chef installation requires a workstation to control the master. Agents are installed from the workstation using the knife tool that uses SSH for deployment. From there, managed nodes authenticate with the master through certificates.
Chef agents must be configured to check in with the master periodically and instantaneous master-to-agent rollout changes aren't yet possible.
Chef configs are packaged into JSON files called recipes.
Ansible vs Chef: Where Ansible Wins
Ansible is a simpler approach to the configuration management work. It avoids the master and minions approach used by other open source configuration management tools like Chef.
Rather than setting up a client-server installation, Ansible uses an agentless architecture. This is a different approach Chef, which has one Chef server and numerous Chef-client instances.
Ansible manages remote connections via SSH networking using implementations such as OpenSSH. SSH is widely supported across cloud platforms including AWS, Google Cloud and Microsoft Azure.
This results in faster deployments and reduces the complexity of configuration files.
For enterprises, Ansible Tower a premium product that has a web-based API and graphical inventory management tool. Ansible Tower adds a user-friendly central dashboard where you can see the status of your servers, manage access control and monitor job runs.
Besides the lower learning curve, Ansible is closer to the bare metal operating system on the remote server. Unlike CHef where you need to understand Ruby domain specific language (DSL), Ansible runs fine from the command line with commands you are familiar with. Alongside its simple YAML format for its playbooks.
This means your commands are easier to reason with and the performance on the machine is fast.
Deploying via VM images like VMWare or containerization via Docker is common for making consistent environments easier for DevOps engineers.
Ansible requires no client installation, eliminating another performance penalty from your application deployment setup. If your team is new to DevOps tools, Ansible can cover most use cases without drowning the team in a sea of complex orchestration.
Ansible also safeguards your DevOps team from configuration drift through idempotent configuration management.
Ansible allows you to keep the state of your servers consistent in the future by running Ansible playbooks based on Ansible's inventory update policy.
On future executions of a playbook, Ansible starts by "Gathering Facts" to identify when a specified change was performed in an earlier run of the playbook.
This ensures, for example, if a specified OS user or say, Github remote was already added, it won't be added again in the future when you rerun the playbook.
State changes are only executed if the desired state specified in your playbook is not met.
With its minimalist design, idempotency, and sticking as close as possible to pure SSH, Ansible wins out if you want the least intrusive deployment, orchestration, and configuration management workflow.
Ansible vs Chef: Where Chef Wins
The original use case for Chef at OpsCode when they released their automation tool in 2009. Despite the performance benefits and lower learning curve of Ansible, there are use cases where Chef is not just justifiable but preferable.
Chef's Ruby DSL is a real pleasure to work with for teams composed of a mix of DevOps engineers and software developers who use Ruby for the bulk of their work.
DevOps engineers familiar with the Ruby and other imperative languages such as Python, C++ and Java will be at home with Chef.
While Ansible and YAML are easy to pick up, the declarative paradigm is step removed from everyday imperative coding with Ruby, which is what Chef replicates well.
As Ansible is "just SHH", Chef is "just another Ruby DSL" so it offers little in the way of barriers to entry for a well-versed Rubyist.
The other big advantage for Chef is its flexibility. This is due to the unique power of the DSL that composes Chef recipes and cookbooks, along with embedded Ruby (ERB) templates that provide advanced customization for various configuration files.
If you have a complex cloud deployment across platforms such as Amazon EC2, Google Cloud, Azure and OpenStack with regular schedules for server updates, Chef is a great option.
The latest Chef open source version 15.3.14 was released on September 12 2019 and is available for free.
There is enterprise supported Chef Infra, Chef Inspect, Chef Habitat and Chef Automate. Plans for these look as follows for 100-500 nodes:
- Effortless Infrastructure: $16,500/year for the “Essentials” plan, which goes up to 100 nodes, and $75,000/year for the “Enterprise” option, which goes to 500 nodes and provides Premium Support.
- Enterprise Automation Stack: the “Essentials” plan costs $35,000/year, with Standard Support, side by side with the “Enterprise” plan, which is priced at $150,000/year.
Does Ansible or Chef Have Better Support?
Chef is an older product, so its documentation is better than Ansible’s.
That said, the better documentation may be due to the fact that there is more to learn than with Ansible.
Chef offers support for Linux, *nix and Windows. The browser-based GUI is good but not as complete as Puppet and is lacking features like reporting and advanced config options.
Chef's relative maturity means it may appeal to corporations who place a premium on stability more than individuals. IT is famous for avoiding documenting anything, so it's no surprise that Ansible's documentation is still a weak point.
This is mitigated somewhat by how easy it is to learn.
Ansible is only available for Linux and Unix and its GUI is worse than Chef's, it doesn't sync to the CLI, so the GUI and CLI can give different results.
Ansible’s agentless push-mode using the ZeroMq implementation at the transport layer means quick deployment and low performance overhead, the caveat is it’s just not as flexible and powerful as using agents.
Ansible vs Chef vs Other Configuration Management Tools
Ansible and Chef vie for leadership with other notable configuration management tools like SaltStack, Terraform and Puppet among the most notable.
These tools serve the purpose of provisioning and maintaining server farms in a predictable, time-saving fashion whether hosted on-premise or on cloud platforms like Azure and AWS.
Large scale deployment come with unique challenges like maintaining applications, compliance requirements, patching, configuration drift and software upgrades all pose a unique challenge to DevOps teams.
DevOps tools tend to fall into two categories:
- Orchestration: Deals with provisioning servers and other infrastructure including databases across clusters while handing over responsibility for managing the software running on the instances to configuration management tools.
- Configuration management: Focus on managing the software on infrastructure nodes, including installation and upgrades on servers already in existence
Other DevOps tools:
- SaltStack: Written in Python, SaltStack(Salt) holds your inventory’s state on a master server, with YAML being the default format for storing configurations. SaltStack templates use the Jinja templating language, which will be familiar to Python users.
- Puppet: Another tool on the configuration management side, Puppet requires a master server, called the Puppet master, which stores the configuration of your infrastructure and pushes changes out to clients. Like Ansible Tower, Puppet Enterprise comes with a web dashboard, Puppet Enterprise Console, for managing your inventory.
- Terraform: A different approach to both Ansible and Chef. Terraform focuses on setting up your entire infrastructure and provisioning servers. As such, it falls on the orchestration side of the spectrum, but it can be used alongside configuration focused tools like Chef and Ansible.
Many DevOps teams have found ways to mix and match CM tools to suit the complexity of their configuration and orchestration needs. Often running on virtualization solutions such as Docker containers, Vagrant, Kubernetes and others.
Containerization with Docker is an appealing path to go because Docker containers help ease the configuration process while offering portability across various server operating systems and cloud providers.
In some instances, solutions like Kubernetes or Docker can take care of most of your configuration management needs. For instance, Docker images can have all your software requirements installed.
It is also possible to use Ansible or Chef to deploy Docker containers and manage them, with ready plugins available in the form of a built-in Docker module on Ansible, and a Docker cookbook from the Chef Supermarket.
In terms of popularity for individual configuration management tools, Ansible is now ahead of the pack, with a survey from TechRepublic showing that Ansible had the most widespread usage across survey respondents, at 41%, followed by Chef and Puppet in a tie at 31%, with Terraform at 31%, and Saltstack at 18%.
Conclusion
First off, any admin or DevOps will be mighty glad to have such tools in their corner; just a few years ago there was much less choice in this field. Choosing either of them is a win, and your life will be richer and easier for it.
That said, if you must choose between them, consider your own needs carefully first and weigh them against what each solution offers. You can use the infographic below to compare Chef and Ansible.
.png){kind=avatar}
