Configuration management (CM) and Remote Execution tools are fast becoming the tools of choice for many a sysadmin or devops pro. If you consider that the point of computing is to make our data management easier, then CM tools make are the next level of that logic – they make it easier to manage the large groups of servers that make it easier to manage our data. CM tools are great for all sorts of routine activities in the data center: automation of scripts on a number of servers, remote execution and deployment, provisioning and installing the same software on a bunch of new servers, and so on. CM tools will enable you to execute stuff like: “I have this command I want to run across 100 servers. I want the command to run on all of them within a five second window.
If it fails on, say, three of them, I need to know which three. There are a number of CM tools in the market, some better suited to certain tasks than others. The elders in this market are tools like CFEngine, Puppet and Chef; they have been around since the mid-2000’s or earlier, but there are also some new upstarts like Salt and Ansible. Let’s compare Salt and Chef.
What They Are
Salt is a new-ish entrant to this game, first released in 2011. It is built on and uses Python, not Ruby, in its CLI, because its founders believe that Python libraries are in all Linux distros and it’s in more widespread use anyway. This Ruby-Python debate has ignited more than one flame war on the web, and we won’t go into the merits and demerits of each. Salt is open-source and supported by parent company SaltStack, and is gaining a growing following; the user community is particularly active and helpful, and the documentation is extensive and well laid out. There’s also a commercial enterprise version of Salt from SaltStack, and Salt is currently available for Linux and Unix, although there is also rudimentary Windows support.
Chef is an older tool, first released in 2009. It is supported by parent sponsor Opscode (which recently announced they are renaming the entire company Chef to reduce confusion), and is frequently compared and contrasted to Puppet, another older CM tool. Actually, Chef is closer in execution to Puppet than to Salt - it uses a pure Ruby DSL in the CLI, it fully supports Windows as well as Linux and Unix, and it also boasts a proper GUI (though still not as slick as Puppet’s). However, there are complaints that Chef is a muddle to understand for newbies, and the documentation is not easy to wrap your head around.
How They Work
Salt is custom-designed to be simple, scalable and flexible yet still a powerful CM tool. It uses the ZeroMq messaging library for transport and deployment, and that makes it noticeably faster than most other CM tools. It uses a master server and deployed agents called minions to control and communicate with the target servers. You can even configure multiple levels of masters, resulting in a tiered arrangement for load-sharing and increased redundancy. The fly in the ointment here is that this master-minion setup isn’t as secure as SSH, so Salt introduces extra security by way of its own AES implementation. Also, the master and minions all require persistent daemons to be running for communication, and these 2 facts impose a small performance penalty. Salt organizes configs and setups into YAML output files called ‘states’ and centrally-located base configs called ‘pillars’. All these are managed using various modules – Salt-cloud, Salt-virt, Salt-vagrant, Salt-monitor and Salt-ui. Salt also includes a GUI tool called Halite; but this is still a poor, version 0.1 effort – for example it only offers a view of minion status and event logs, but no way to deploy minions or issue commands to them. The SaltStack dev team is working hard on improving Halite, but for now most users will have to rely on the CLI for interaction.
Chef also uses a master-agent setup, and in addition to a master server, a Chef installation also requires a workstation to control the master. The agents can be installed from the workstation using the ‘knife’ tool that uses SSH for deployment to ease installation. But Chef, unlike Salt, doesn’t support push from master to agent. Why this feature is not yet implemented is beyond me. It’s a glaring omission that implies all agents must be configured to check in with the master periodically, so application and rollout of changes and new apps isn't really possible, it only happens the next time an agent dials back home. Continuing with the kitchen motif (see ‘knife’ above), Chef configs are packaged into JSON files called ‘recipes’, and the software can run in client-server (called Chef-server) or standalone mode (called ‘Chef-solo’). The Chef GUI is much better than Salt’s but even it does not have some features like reporting and advanced config rollouts.
Conclusion
Just a few years ago your only choice of a CM tool was CFEngine and a bit later, Puppet. The fact that we now have so many to choose from, each mightily competent in its own way, is a huge bonus. So choosing between Chef and Salt comes down to what your preferences are: an older, trusted tool using Ruby and that can support a mixed Windows-Linux environment, or a newer mostly-Linux tool with speed and easy scalability as its calling cards? The pros and cons chart below will hopefully make this decision easier, but remember you cannot go wrong choosing either.
References
https://medium.com/what-i-learned-building/208eb0044c20
https://missingm.co/2013/06/ansible-and-salt-a-detailed-comparison/
https://www.infoworld.com/article/2609482/data-center-review-puppet-vs-chef-vs-ansible-vs-salt.html?page=3
