Configuration Management Systems are meant to save time both for sysadmins as well as DevOps and encompass all stages of an applications life-cycle. This article takes a closer look at the features of three systems providing similar solutions – Puppet, Ansible, and SaltStack – to discern which one we chose at VapourApps and why. We’d like to share our perspective on their features and properties to get our point across.
Even though they each have myriads of supporters and do well in serving the purpose they were created for, without further ado, let’s see how these CM’s stack against each other and identify their main differences.
Puppet is the most popular CM out of the three as the most mature and oldest between them.Similar to SaltStack, it involves setting up an agent that has to know about the master node – which is not the case for Ansible. We will talk about the pro’s and con’s of this later on.
While some claim that this adds a step in deployments, agent-less CM’s still need to run an ssh daemon as well as a Python interpreter. Agent-based systems are also known to deliver monitoring reports quicker. Puppet offers an Open-Source and an Enterprise version, which indicates it’s probably reached its plateau of development and acquired enough clients to focus on corporate ones. It was built on Ruby but supports C++ and Clojure since version 4.0 and are written in a declarative custom programming language.
That used to be considered the biggest downside, as not many sysadmins are familiar with Ruby, but one can claim that in comparison to Salt and Ansible – both of which use Python; it still deviates from the Open-Source target audience where sysadmins as well as DevOps where the general consensus is that Python is closer to the interpreter that their staff are familiar with. To summarize, while Puppet, as a stable and mature solution, offers strong compliance smooth initial setup for a variety of OSs the Open Source version uses multiple masters for scalability and can make the management process and remote execution quite challenging.
Whereas Puppet’s initial release has been back in 2005 with the initial objective to handle the operations within the organization and only bringing it’s product to the open market when they realized the potential of their solution, Ansible is the newest addition in regards Puppet and SaltStack – comming to the market in 2013 – with the main purpose being to stay away from the agent-based architecture, using ssh-based access to deployments under the master node. As such, it’s considered an agent-less remote orchestration and configuration system.
On one hand, it boasts scalability, however, the ssh-based access complicates that process. Communication is standard as with other CM’s, as usually one Workstation running Ansible is used to access the master nodes – in this case called Bastions.
If you take a closer look at the Github commits and branches on each of these solutions as an indicator, it reflects the release dates and the mind work being employed, with Puppet having the most branches (177) – aluding to the maturity of the project, Ansible being the second in line (33) while SaltStack has the most commits (trippling both Puppet and Ansible), indicating that the project is budding and that it’s community has recognized the upside it has. Ansible, besides its agent-less architecture, shares more similarities with SaltStack in regards of the coding language – it’s written in Python and like Salt uses YAML configuration files to perform tasks, which go under the term playbooks. Roles are a combination of variables, playbooks, and templates – which are basically preconfigured playbooks.
The Enterprise offering from Ansible is called Tower which standardizes over OSs, which basically lets you skip the roles configuration. For access, it uses a Python CLI engine. Ansible also leans towards offering to host for their clients.
SaltsSack is a highly scalable, feature rich configuration system that offers real-time automatization of commands. Anyone knowledgeable in Python and YAML can write a state for configuring a server and even custom modules in Python for common sysadmin tasks. The core of SaltStack is salt-master, a server to which the salt-minions, the client running on the server that needs to managed connects to, uses rabbitmq to send and listen for messages.
Every minion has a different private key with must be accepted by the master. Aside from an id, each minion has its own set of properties gathered from the system it is running on called grains. Additional grains can be appended by the sysadmin and all grains can be used inside the YAML states or Python modules as variables.
The state itself is run by a Python module. Variables that must be set by the admin like passwords, addresses and various configuration options are set in pillars and exported only to minions that require them, increasing security. Salt is highly focused around security, i.e. for security reasons the minions don’t talk to each other, however there is a reactor system, a module or a state running on minion can trigger an event (in SaltStack communication is done by events) for which the salt master will trigger a salt module based on the content of the event. For complex configuration of a group of servers, where servers are interdependent and some servers must be configured before others one can use the orchestration runners.
Runners are modules that run only on the master for master management tasks. The orchestration runner is a bit different, with it you can write a state for the master itself, controlling the way and order by which the master sends commands to the minions. At VapourApps we use SaltStack for provisioning servers with, making tasks more convenient by writing modules for them and in our va-master, a self or cloud hosted server with a web user interface for controlling your cloud providers via salt-cloud and even a single pc running libvirt/Openstack/VmWare, full control over your virtual and bare metal servers, and apps written as salt states for common tasks like mail, Samba AD, backup, Owncloud, monitoring and more. Each app has a panel in the dashboard that communicates over the salt API to the corresponding server, running our custom salt modules and enabling the admin to perform the various everyday task on one web page.
At VapourApps we rely on SaltStack, because of the following key features:
flexible state management which can scale to a great extent;
good support for OpenStack, Libvirt, AWS;
a rich repository of modules;
it is very easy to write own modules in Python;
We use SaltStack from installing an OpenStack server, to download OpenVPN certificates and create users in ActiveDirectory.
If You would like to get more information about our services, feel free to contact us.