SaltStack: Salty alternative to the puppet player
There are various programs for the configuration management of servers. The names Puppet, Ansible and Salt are the most common. In the following blog article, some features of S altStack (Salt for short). This helps the reader to decide whether it can be an alternative to Puppet or Ansible. The decisive factor for the choice is for which configurations the corresponding tool is used.
The advantage of Ansible is that deployments are very simple due to the (usually) one-time setup of the software and a one-time configuration. If, on the other hand, you want to permanently maintain or check a certain configuration status on a server and adjust it if necessary, Puppet is probably one of the favorites. Another difference between Puppet and Ansible is that Puppet has an agent running on every managed server that regularly asks the master for the current status.
Ansible is executed via ssh and is therefore “agentless”. Ansible also does not repeat any unnecessary steps. However, each run must be executed via the server on which Ansible is running (a cronjob or similar can of course also be used for regular runs).
Example:
Installation vim on host with Minion (CentOS 7):
salt 'minion' pkg.install vim-enhanced
Installation of vim via salt-ssh on a host that is only defined as a host on the master in the roster file (CentOS 7):
salt-ssh 'testhost' pkg-install vim-enhanced
However, the actual topic of this article is not the comparison of Puppet and Ansible, but Salt. Just like Puppet, Salt can be operated with an agent (salt-minion) in the classic case. Alternatively, it is possible to roll out the configuration on servers via salt-ssh in the same way as Ansible.
The entire configuration can be called up for host groups, environments or individual hosts. The state in which the servers are to be located is defined by so-called states. If the corresponding definitions have already been implemented and are unchanged, they are skipped during the run.
Salt is based on Python at its core, but is easy to understand, so you don’t necessarily need to know Python. However, salt can execute not only these predefined states, but also simple commands. These can be used simultaneously for host groups or an entire environment. It is also possible to sort the hosts according to grains. Grains are system-specific parameters that can be read, for example, via kernel version, operating system or self-defined functions. For salt-ssh to work, an sshkey must first be transferred to the corresponding server. For the variant with agent (Minion), a key is created by the server. If the salt master accepts this, it can connect to it – this administration is analogous to key administration with Puppet.
Example:
A simple state definition that executes the installation as in the previous example but also copies a corresponding vimrc file from the master to the minion and sets the permissions:
vim.sls vim: pkg.installed /etc/vimrc: file.managed: source: salt://vimrc mode: 644 user: root group: root
To briefly introduce frequently used terms from Salt:
- states: Configuration for a specific feature or application. This installs the required packages, copies/edits/creates the corresponding configuration files and starts/stops the services.
- grains: Computer-specific variables such as operating system, kernel, etc., which can be used as parameters in the states.
- pillar: Parameters that are used for the configurations in states. These are either defined in additional directories or are provided by external applications (e.g. Foreman/orcharhino).
- formulas: Ready-made states provided by the community. Often with a sample file for the pillars that can be used with the corresponding state.
For those who have prior knowledge of Puppet the following list shows the corresponding counterparts in Puppet from the Salt vocabulary. This makes it easier to follow the comparison to Puppet
|
Salt |
Puppet |
|---|---|
|
grains |
facts |
|
pillar |
hiera |
|
states |
manifests/modules |
|
formulas |
puppet-forge module |
The mapping between Salt and Puppet is not 100% the same, but makes the comparison easier for people with Puppet experience.
While with Puppet the agents regularly (by default: every 30 minutes) ask the master for changes, Salt has a scheduler for control.
It is not always necessary to transfer every server and every state; in addition to the complete configuration, you can also run only certain states for a specific environment or only individual servers. The runs for states can either be configured for individual times or, as with Puppet, can be implemented for all at once. The regular salt runs make it possible to configure very freely and clearly.
For some programs, there are also formulas that consist of extensive states (similar to Puppet modules). These contain an example of which parameters can be configured. It is therefore not necessary to write all the states yourself. For widely used modules (e.g. mySQL databases or Apache), there are already detailed states that generally support various distributions. However, there is not as much choice here as with the modules in Puppetforge.
Example:A much more complex definition for the installation of vim and configuration of vimrc can be found in the corresponding formula: https://github.com/saltstack-formulas/vim-formula An example pillar.example file is included for this purpose, which shows in an example how the configuration could look. The parameters now have a default value, which can be adapted to your own requirements in a separate pillar directory with a file. |
As with all configuration management tools, environments can be created in Salt for grouping servers (for example, classically in Development, QA and Production). Both the states and the pillars can be distributed to these environments or their parameters can be merged from several folders. When using parameters (pillars), a hierarchy is also defined here – similar to Hiera in Puppet – as to which parameters are overwritten by which configuration at the end.
Salt can not only take over configuration management, but also orchestrate it. Reactors can be set up on the Salt master to respond to events or beacons. Events can be defined for Saltruns and thus intercept errors or react to other events. Beacons can monitor services that are not part of Salt and keep an eye on system and memory utilization, for example. If a predefined value is exceeded or not reached, this in turn can trigger one of the reactors. This means that in a very simple case, the size of the log folder can be monitored. Above a certain size, a reactor is triggered which deletes the logs (or only certain ones) in order to free up memory on the hard disk.
Both the states and the pillars can be managed via Gitrepositories – at least one repo should be used for the pillars and at least one repo for the states. The branches correspond to the different environments (with default settings, the master branch corresponds to the base environment). Several repositories can be integrated here or combined with local folders or, in the case of pillars, with external sources (such as Foreman/orcharhino). The order of the sources in the configuration file of the master represents the hierarchy according to which the values or states are merged if there is more than one source. In the Git directories, the states and pillars are cached on the master. This means that the minions do not require a connection to the corresponding directories, but receive everything directly from the master. To connect to the Git directory, either the corresponding login data (user and password) can be stored or it can be accessed via ssh-key. The configuration for this is analogous to the standard cloning of such a directory.
Salt integration in Foreman/orcharhino
A plugin for the integration of Salt exists for orcharhino and Foreman. However, this feature is not yet as well developed as the integration of Puppet, for example. The management of the keys of minions (salt-ssh is not yet supported) is done via the WebGUI of orcharhino/Foreman. The corresponding states can also be assigned to the hosts or host groups. A new button with “Run Salt” is available via the detail view. This triggers a salt run for the corresponding host. These runs generate a report in the same way as for Puppet. The interface shows which changes have been made and where an error may have occurred. From Salt version 2017.7, reports are also generated for automatic runs via Salt Scheduling, which can then be called up in Foreman. This is not yet supported in older versions
Both the states and the pillars are saved on the Foreman/orcharhino server in the classic way so that they can be imported. External sources for states and pillars, such as the gitfs described above, do not yet work with the integration in orcharhino or Foreman. However, the host parameters that are set in the interface can be used as pillars. This means that corresponding parameters can be used in the states. Alternatively, you can also overwrite pillars via the host parameters; however, this only works for strings. More complex states with different pillars per host or host group must therefore still be created in the corresponding files as in classic Salt. The plugin is already well suited for simple states (e.g. installation and default configuration of software) – they can be used to assign the states to the hosts and trigger a corresponding salt run.
You might also like
ATIX-Crew
Latest posts by ATIX-Crew (see all)
- Foreman Birthday Party 2024 - 1. August 2024
- CrewDay 2024 - 6. June 2024
- Navigating the XZ Security Vulnerability: A Comprehensive Guide - 9. April 2024
