Deploying Saltstack : master and minion (archlinux on ARM)

As part of a project to upgrade my servers (Sheevaplug and Cubieboards), I wanted to automate most of the OS and software deployments.

Moreover the idea was also to factorize configurations for all servers and be able to change and replay deployments easily… That’s exactly the purpose of an orchestrator like Puppets, Ansible or Saltstack.

I choosed Saltstack as it seemed the most simple to use to me without any compromise on functionalities (regarding my needs).

Below are my notes about this first install, as well as a little script to to even automate the minions deployment.

Base install

Both Archlinux and Saltstack projects provide good documentation to start:
https://wiki.archlinux.org/index.php/Saltstack
https://docs.saltstack.com/en/latest/ref/configuration/index.html

Unfortunately the “raet” package was not working correctly on arm arch when I tried: it was taking 100% of cpu. So I installed both on Master and Minion the “zmq” version:

Next step : create a dns entry for the master, eg: “salt.local.lan” , so it is easier to change the host without impact on minion’s config file.

I also did the same for all minions, eg: “minion.local.lan”.

Saltstack use 2 TCP ports that must be opened for master and minon if they are on different subnets or vlan protected by a firewall.

Example for an iptables rules file :

 

Enable communication between master and minion

To make the master deals with the minion, it is needed to :

  • Tell the minion who is it’s master (darth Sidious ?)
  • Make the master trusts the minion

Setting the minion’s master requires to set the “master” property in “/etc/salt/minion”:

Then the minion must have the master’s public key fingerprint in “/etc/etc/salt/minion” (the property is named “master_finger”). To get the master key (Saltstack must be running) :

As soon as the key is set in the minion’s config file, saltstack can be started on the minion:

The last step to establish the communication is to allow the minion on the master side:

then test with a “ping” :

Final Adjustments

Everything works, so we can start Saltstack at boot time, on the master:

And on the minion:

Configure log rotation properly (logrotate) with the following in a new file /etc/logrotate.d/salt

 

As some of my minions as well as my master run on low power arm computer (eg: raspberry or odroid c1), I changed the master configuration in /etc/salt/master to set the “timeout” property to 120 and the “worker_thread” to 8.

This allows to be more tolerant for slow answer as the master can wait up to 2 minutes for 8 command’s results.

At this time, salt is able to drive minions… but the true power of SaltStack is the templating of services: the states…

Configure States

Prepare folder architecture

States are configuration templates that are OS agnostic. Saltstack propose a directory and filename based logic to handle the whole thing.

There are basicaly 3 main directories to configure in “/etc/salt/master”:

  • file_roots : for states path
  • module_dirs: for modules (to create custom state’s actions)
  • pillar_roots: pillars (Salstack way of defining and assigning values to minions)

Example of structure :

A simple state

As an example, here is a state that remove “alarm” user and group on am Archlinuxarm distrib.

Create the folder “noalarmuser” in /srv/salt/states/base, then a file named “init.sls” with the following content:

To apply this state to a minion, it is as simple as :

There are 4 kind of information to build a state :

  1. The state name, here defined as a the folder name “noalarmuser” which contains a default definition file “init.sls”
  2. State actions identifiers : “alarm” and “remove_alarm_group”. They have to be unique.
  3. Modules and functions to execute: “user.absent” and “group.absent”
  4. Function’s parameters : “purge: True” and “name: alarm”

A majority (if not all ?) module’s function use a first parameter “name” which default value is taken from the action identifier.

For example, the first state action could have defined as :

Assign states to minons

Saltstack allows to apply a state to one or several minions, but also allows to define which state should be applied to which minion.

Assignation of states to minion is done by defining a file name “top.sls” in the “base” directory. Example in “/srv/salt/states/base/top.sls”:

This allows to remove alarm user and groups to all minions which name ends with “.local.lan”.

To apply states that are set in the top.sls file to a specific minion:

Script to automate Salstack deployment on minions

I’m now using the following script (which is also attached to this article) to install and configure saltstack on any new Archlinux based machine to transform it into a minion.

To use it, just replace “xx:xx:xx:xx:xx:xx:xx:xx” by your master.pub key finger print:

Download the script : salt-minion-install

3 comments

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.