Saltstack

Saltstack vereinfacht die Konfigurationsverwaltung beliebiger Serverinfrastrukturen. Insbesondere in Umgebungen, die ein Vielzahl ähnlich konfigurierter Systeme gibt/geben soll, ist Saltstack ein wichtiges Hilfsmittel. Aber auch in sehr heterogenen Umgebungen hilft es dabei, Fehler bei der Konfiguration zu vermeiden und die Konfiguration nachvollziehbar zu machen.

Saltstack basiert auf einer Master/Slave Architektur, wobei die Slaves hier Minions genannt werden. Der Master enthält alle Konfigurationsdetails und kann diese dazu nutzen, um die jeweiligen Minions gemäß dieser einzurichten. Auf den Minions muss hierzu der entsprechende Salt-Client installiert werden.

Installation

SaltStack stellt Repositories für verschiedene Linux-Distributionen zur Verfügung. In Debian ist es bereits in den offiziellen Repositories enthalten. Ich nutze aber gern eine etwas aktuellere Fassung.

wget -O - https://repo.saltstack.com/apt/debian/9/amd64/2018.3/SALTSTACK-GPG-KEY.pub | sudo apt-key add -
echo "deb http://repo.saltstack.com/apt/debian/9/amd64/2018.3 stretch main" > /etc/apt/sources.list.d/saltstack.list
apt-get update

Master

Auf dem Master installiere ich immer auch den zugehörigen Salt-Client, so kann sich der Salt-Master selbst verwalten.

apt-get install salt-master salt-minion
systemctl restart salt-master salt-minion

Minion

Auf den Minions reicht der Salt-Client aus:

apt-get install salt-minion
systemctl restart salt-minion

Grundkonfiguration

Die Minions suchen sofort nach dem Start des Dienstes nach dem Master. Sofern dieser unter dem Namen salt im Netzwerk verfügbar ist, sollte dies auch auf Anhieb funktionieren. Ansonsten kann man in der Datei /etc/salt/minion der Eintrag master: salt auf den tatsächlichen Hostname bzw. die korrekte IP geändert werden.

Eine weitergehende Konfiguration ist zunächst weder für Master noch für die Minions erforderlich. Eine vollständige Übersicht über die möglichen Konfigurationseinstellungen findet sich unter:

Verwendung

Sobald sich ein Minion zum ersten Mal bei Master meldet, wird er dort zwar registiert, allerdings muss er noch freigegeben werden. Welche Minions dem Master derzeit bekannt sind kann man mit dem folgenden Befehl prüfen und anzeigen lassen:

salt-key --list-all

Sofern noch unbestätigte Minions aufgelistet werden können diese mit dem Befehl salt-key --accept=<key> akzeptiert werden. Alternativ kann man auch alle wartenden Minions mit einem Schlag annehmen:

salt-key --accept-all

Mit dem Befehl salt '*' test.ping kann man nun prüfen ob die Kommunikation mit den Minions korrekt funktioniert. Alle akzeptierten Minions sollte ein True zurückliefern. Anstelle des Targets '*' kann man auch den Namen eines einzelnen Minions oder Teile davon inkl. Platzhalter (z.B. 'customer*') angeben. Hinter dem Target kommt der Aufruf eines sog. Salt-Moduls (z.B. test) und dessen Funktion (z.B. ping). Die meisten Modulfunktionen erwarten dann noch einen Parameter.

Eine Übersicht über die verfügbaren Module findet sich unter:

States, Grains und Pillars

Seine eigentliche Funktion entfaltet Salt aber erst, wenn man sog. States verwendet. Diese definieren einen gewünschten Zustand und können automatisch bestimmten Servern und Rollen zugewiesen werden. Salt vergleich dann diesen SOLL Zustand mit dem IST Zustand des jeweiligen Minion und nimmt ggf. nötige Änderungen vor, damit der SOLL Zustand hergestellt wird.

Da man häufiger variable Werte bei der Konfiguration berücksichtigen muss, stehen für jeden Minion sogenannte Grains zur Verfügung. Diese enthalten standardmäßig Informationen über den jeweiligen Minion, wie z.B. die Größe des Arbeitsspeichers, den FQDN, etc., können aber auch über die Datei /etc/salt/grains beliebig erweitert werden. Eine entsprechende Konfiguration vorausgesetzt können sogar andere Minions auf die Grains seiner Brüder und Schwestern zugreifen, was z.B. bei der Konfiguration von Monitoringsystemen praktisch sein kann. Damit eignen sich Grains aber natürlich nicht um geheime Informationen zu verwalten. Hier kommen die sogenannten Pillars ins Spiel. Im Gegensatz zu den Grains werden Pillars auf dem Master definiert und dann den jeweiligen Minions (oder Gruppen von Minions) zugewiesen.

Hier ein kleines Beispiel (der Einfachheit halber ohne Verwendung von Grain-/Pillardaten):

httpd:
  pkg.installed

/etc/httpd/conf/httpd.conf:
  file.managed:
    - source: salt://httpd/httpd.conf

Wie man sieht ist ein State im Grunde eine einfache YAML-Datei, in dem die benötigten Salt-Module mit ihren Parameter aufgelistet werden. Um komplexere Aufgaben zu erledigen kann man in States aber auch Jinja2 verwenden.

Der oben aufgeführte State installiert über den jeweils genutzten Paketmanager des Minions das Paket httpd. Außerdem kopiert es die Datei ./httpd/httpd.conf vom Salt-Master als /etc/httpd/conf/httpd.conf auf den Salt-Minion. Auch hier könnte man Jinja2 einsetzen, um z.B. bestimmte Teile der Konfigurationsdatei mit variablen Werten zu befüllen. Die entsprechenden Werte können z.B. aus den Grains oder Pillars des Minion stammen.

Wer mehr über SaltStack wissen möchte, findet hier weitere Informationen: