© bizoon, 123RF

Das Rückgrat vieler unternehmenskritischer Anwendungen bilden Serverfarmen. Wer als Admin dafür verantwortlich ist, wünscht sich ein leicht bedienbares zentrales Systemmanagement. Eine von mehreren Open-Source-Lösungen für diesen Zweck ist Saltstack.

Systemadministratoren sind heute für ganz andere Infrastrukturen zuständig, als sie noch vor einigen Jahren in Unternehmen üblich waren. Mittlerweile gehören oft auch Server und Dienste zur Systemlandschaft, die in externen Clouds laufen. Unabhängig von den Serverstandorten können schon die bloße Anzahl der Systeme und ihre Unterschiede den Admin vor große Herausforderungen stellen.

Den Alltag vereinfachen

Im Alltagsgeschäft ergeben sich dabei häufig Aufgaben neben der Installation und Konfiguration neuer Systeme, die ein eventuell vorhandenes Konfigurationsmanagement nur umständlich erledigt. In diese Kategorie fällt beispielsweise eine schnelle Überprüfung, ob auch wirklich alle Systeme mit einem bestimmten Paket ausgestattet sind oder ob eine Datei wirklich mit dem erwarteten Inhalt existiert. Wer hier zum Beispiel erst ein Puppet-Manifest oder Chef-Kochbuch schreibt, muss etwas länger auf das Ergebnis warten. Dazu kommt, dass diese Aufgabe vielleicht nur einmalig und nicht immer wieder auszuführen ist – der Einsatz des Konfigurationsmanagements wäre hier schlicht mit unangemessen großem Aufwand verbunden.

Alternativ nutzen viele Admins für solche Aufgaben Skripte, die einfach eine Liste von Hosts abarbeiten und den gewünschten Befehl dann auf jedem Host ausführen. Solche Lösungen funktionieren zwar, müssen jedoch die Besonderheiten der jeweiligen Plattformen berücksichtigen und kommen oft an ihr Limit, etwa wenn einige der Zielsysteme nicht sofort erreichbar sind oder keine SSH-Verbindung zulassen.

Elegante Abstraktion

Eleganter läuft es, wenn der Systembetreuer auf eine Lösung zurückgreifen kann, die von den Unterschieden der verschiedenen Plattformen abstrahiert und Zugriff auf alle Systeme gewährt, egal ob im eigenen Rechenzentrum oder in einer externen Cloud. Auch dafür gibt es im Umfeld der so genannten Orchestration-, Remote-Execution- und Konfigurationsmanagement-Werkzeuge etliche Tools, unter denen Saltstack dank seiner einfachen Bedienung, Geschwindigkeit und Skalierbarkeit hervorsticht.

Salt und Saltstack

Salt oder auch Saltstack (siehe Kasten “Architektur von Salt”) wurde erstmals im März 2011 der Öffentlichkeit zugänglich gemacht und ging aus einer In-House-Software hervor, die der System- und Software-Architekt Thomas S. Hatch für gängige Herausforderungen im Infrastrukturbereich in Python geschrieben hatte http://1. Ziel war es, eine einheitliche Plattform zu schaffen, die große Serverfarmen parallel verwalten kann. Dazu nutzt Salt einen so genannten Master, der zentral auf einem System läuft und die mit Salt-Minions ausgestatteten Zielsysteme durch verschlüsselte Kommunikation bedient.

Architektur von Salt

Saltstack beherbergt eine Vielzahl von Komponenten, die auf verschiedenen Wegen miteinander verzahnt sind (Abbildung 1).

Abbildung 1: Die Salt-Architektur inklusive des häufig eingesetzten Zwischen-Masters Salt-Syndic im Überblick. Die durchgezogenen Linien kennzeichnen die Rückmeldungen, die Zielsysteme an die Master liefern.

• Salt-Master: Wie alle anderen großen Komponenten von Saltstack auch ist der Salt-Master in Python geschrieben. Er stellt den Messaging-Bus Zero MQ für die Kommunikation mit den Minions bereit. Der Master hat eine Liste aller eingebundenen Zielsysteme in der Hand und kann Befehle, Dateien und Konfigurationssnippets an diese übertragen. Für eine effizientere Kommunikation wählten die Entwickler zudem das Übertragungsformat Messagepack [2], was extrem wenig Overhead verursacht.
• Salt-Minion: Der Salt-Minion läuft auf den Zielsystemen und nimmt verschiedene Daten vom Salt-Master entgegen. Der Minion ist eine Art Agent, der den Master auch über das Ergebnis von ausgeführten Kommandos informiert. Seit einiger Zeit ist es zudem möglich, einen Minion gleich an mehrere Salt-Master zu hängen.
• Salt-Syndic: Für die Kaskadierung von Salt-Mastern bietet sich die Komponente Salt-Syndic an. Salt-Syndic läuft als “Zwischen-Master” zwischen einem Salt-Master und den Zielsystemen (Minions).
• Salt-SSH: In vielen Situationen kann es passieren, dass ein Salt-Minion auf einem Zielsystem nicht lauffähig ist. Das betrifft unter anderem Embedded-Devices. Für solche Fälle kann ein Master direkt via SSH mit einem Zielsystem sprechen. Jedoch verzichtet der Admin dann auf die Vorteile eines Messaging-Bus und einige Funktionalitäten von bestimmten Modulen.
• Salt-Proxy-Minion: Weil bestimmte Endgeräte, zum Beispiel die meisten Router oder Switches, nicht per SSH erreichbar sind, wurde mit dem Proxy-Minion eine Möglichkeit geschaffen, Drittgeräte anzusteuern. Dabei handelt es sich um eine definierte Schnittstelle, die mit anderen Schnittstellen Daten austauschen kann.

Alle Komponenten verwenden dabei einen schnellen und zuverlässigen Messaging-Dienst (Zero MQ). Die Rückmeldung der Aktionen, die die Minions ausführen, landen entweder direkt beim Master oder in einem so genannten Returner (das kann etwa eine MySQL-Datenbank sein).

Salt stellt eine Vielzahl von Funktionen bereit, die die Verwaltung von Serverfarmen vereinfachen. Der Admin kann nicht nur zentralisiert Kommandos auf mehreren Systemen absetzen, ihm stehen auch ein Konfigurationsmanagement, eine Inventarisierung oder ein Jobmanagement zur Verfügung und er kann sogar Windows mit Software versorgen. In Python geschriebene Module decken alle diese Features ab.

Ein Vorteil von Salt ist, dass sich der Admin kaum um die Besonderheiten der Zielplattformen kümmern muss. Egal ob ein Paket unter Debian, Centos oder Suse zu installieren ist – der Befehl in Salt bleibt immer gleich. Dementsprechend simpel gestaltet sich die Bedienung.

Salt-Master und -Minions

Den Salt-Master sollte man auf einem hochverfügbaren System installieren. Jedes System, das er bedienen soll, wird mit einem Salt-Minion ausgestattet. Für diesen Artikel haben die Autoren gleich mehrere Testumgebungen aufgesetzt, wobei Salt teilweise über die Paketverwaltung der jeweiligen Distribution und teils über ein offizielles Bootstrap-Skript installiert wurde. Für den Betrieb von Salt bedeutet dieser Umstand nur insofern einen Unterschied, als es zu teils unterschiedlichen Salt-Versionen führt, wo dann Pakete für zusätzliche Funktionen manuell nachzuinstallieren sind.

In den verschiedenen Test-Setups wurde der Salt-Master unter mehreren Debian- und Centos-Versionen betrieben, wobei Minions unter Debian 6 und 7, Ubuntu 12.04, Centos 6.5, Open Suse 13.1 und Free BSD 9.2 zum Einsatz kamen. Alle Systeme liefen in unterschiedlichen virtualisierten Umgebungen. Alle hier aufgeführten Kommandos lassen sich direkt in einer Shell als Root-Benutzer oder mit »sudo« ausführen.

Die wohl einfachste Methode, Salt zu installieren, ist das offizielle Bootstrap-Skript. Mit dem Kommando »curl -L http://bootstrap.saltstack.org | sh -s — -M -N« wird das Skript direkt aus dem Internet angesteuert und ausgeführt. In diesem Fall sorgen die Parameter »-M« und »-N« für die Installation des Salt-Masters ohne Minion, wobei das Skript selbstständig die eingesetzte Distribution erkennt und die notwendigen Pakete aus einem offiziellen Repository bezieht. Das Bootstrap-Skript sorgt auch für den automatischen Start der Salt-Master und trifft alle Vorkehrungen für einen automatischen Start dieses Dienstes. Damit die Salt-Minions künftig mit dem Master sprechen können, muss der Admin die TCP-Ports 4505 und 4506 in der Firewall öffnen. Für Zusatzfunktionen sind später gegebenenfalls noch benötigte Pakete nachzuinstallieren (etwa Git).

Analog zum Salt-Master installierten die Autoren den Salt-Minion ebenfalls mit dem offiziellen Bootstrap-Skript: »curl -L http://bootstrap.saltstack.org | sh« Dieses Kommando sollte auf allen Systemen laufen, die unter die Kontrolle des Salt-Masters gelangen.

Standardmäßig versucht sich ein Salt-Minion mit dem Host »salt« zu verbinden. Wer ein anderes Ziel als Salt-Master festlegen möchte, der editiert auf den Salt-Minions jeweils die Datei »/etc/salt/minion« und lässt die Variable »master« auf den alternativen Namen verweisen. Nach einem Reload der Konfiguration versucht der Salt-Minion einen Verbindungsaufbau zum angegebenen Master-Server.

Nach der erfolgreichen Installation von mehreren Salt-Minions erkennt der Salt-Master gleich eine Reihe von neuen Keys, mit denen sich die Minions eintragen möchten. Mit dem Befehl »salt-key -L« lässt sich der Admin eine Liste der noch nicht beim Master registrierten Minions anzeigen. Wer den soeben eingerichteten Salt-Minions vertraut, akzeptiert alle Schlüssel mit dem Befehl »salt-key -A« . Wer die Identität der Minions noch genauer überprüfen will, findet in der Manpage zu »salt-key« entsprechende Hilfestellungen.

Nach dem grundlegenden Setup kann der Admin kontrollieren, ob der Master die Salt-Minions überhaupt bedienen kann. Das Kommando »salt-run manage.status« zeigt an, welche Minions er mit dem Status »Online« erkennt. Wer an dieser Stelle nur Minions mit dem Zustand »Online« oder »Offline« sehen möchte, kann auch präziser nachfragen: »salt-run manage.up« beziehungsweise mit »salt-run manage.down« .

Einen Schritt weiter geht »salt “*” test.ping« : Mit »salt« ruft der Admin den eigentlichen Master auf, während das Sternchen alle Minions adressiert. »test« bezeichnet das von Salt verwendete Modul, und »ping« beschreibt eine darin enthaltene Funktion. In diesem Fall wird also ein Lebenszeichen von allen am Master hängenden Minions eingefordert.

Minions adressieren

Salt bietet gleich mehrere Möglichkeiten, Minions zu adressieren. Während ein »*« alle Systeme adressiert, ist es auch möglich, einzelne Namen oder reguläre Ausdrücke dafür anzugeben. Damit ist der Aufruf »salt “dns*” test.ping« (adressiert alle Hosts, deren Minion-ID mit »dns« beginnen) genauso gültig wie »salt “dns.example.com” test.ping« (adressiert genau dieses eine System). Wer viele Systeme in Salt eingebunden hat, die beispielsweise nach dem Muster »web01.example.com« benannt sind, kann demnach seine Webserver 1 bis 5 mit dem Kommando »salt “web[1-5]*” test.ping« erreichen.

Wem die Adressierung der eigenen Minions aufgrund ihrer Hostnamen zu umständlich erscheint, der darf deren Namen auch ändern. Unter Debian und Ubuntu ist die Datei »/etc/salt/minion_id« dafür zuständig. Sie lässt sich mit einem Texteditor öffnen und anpassen.

Eine im Alltag bewährte Methode ist die Benennung der Minions nach den FQDNs der Systeme; aber auch fiktive Namen sind möglich. Nach dem Umtaufen muss der Salt-Minion seine Konfiguration neu laden. Außerdem ist es notwendig, auf dem Master den neuen Schlüssel zu akzeptieren, mit dem sich der Minion nun gemeldet hat. Den alten Schlüssel kann man mittels »salt-key -d <Schlüsselname« entfernen.

Salt-Grains

Minions auf Grund von Hostnamen zu adressieren genügt jedoch nicht immer den Erfordernissen. Salt sammelt daher auf jedem Minion statische Daten zum Zielsystem und legt sie in so genannten Grains ab (Nutzer von Puppet kennen das Konzept als Facts). Zu den wichtigsten Grains zählen das jeweilige CPU-Modell, die hinterlegten IP-Adressen, die MAC-Adressen, die Kernelversion, der Release-Name der Linux-Distribution oder auch die Info, ob es sich um ein virtuelles oder physikalisches System handelt.

Die Informationen sammelt Salt unter anderem mit Hilfe des Tools »dmidecode« . Der Benutzer muss es manuell nachinstallieren, weil Salt es nicht immer als Abhängigkeit erkennt. Eine Liste von allen Grains auf einem Minion kann der Admin schnell einsehen, wie die gekürzte Ausgabe von Abbildung 2 zeigt.

Abbildung 2: Grains enthalten interessante Daten zu dem System, auf dem sich der Salt-Minion befindet.

Das Ansprechen von Minions an Hand bestimmter Eigenschaften kann demnach recht einfach mit Werten aus den Grains erfolgen. Der Befehl »salt -G “osfullname:openSUSE” test.ping« richtet sich explizit nur an Systeme, die unter Open Suse laufen. Bei Bedarf lässt sich die Methode zur Adressierung mit den Grains an sich verknüpfen – zum Beispiel für Informationen für ein Inventursystem. Ein sinnvoller Aufruf dieser Art wäre »salt -G “cpuarch:x86_64” grains.item num_cpus« , der die CPU-Kerne auf jedem 64-Bit-System anzeigt.

Noch komplexer, aber dafür genauer wird es, wenn man verschiedene Matcher miteinander kombiniert (Compound Matchers). Der Salt-Master akzeptiert mit dem Schalter »-C« gleich mehrere Argumente für das Targeting. Sinnvollerweise dienen die Minion-Namen und -Eigenschaften als kombinierter Filter.

Das folgende Beispiel zeigt, wie man alle Webserver mit 64-Bit-Prozessor und drei oder vier Kernen anspricht. Das kann sinnvoll sein, wenn beispielsweise Ressourcen-hungrige Aufgaben nur auf besonders gut ausgerüsteten Systemen laufen sollen. Denkbar sind an dieser Stelle übrigens auch Adressierungen auf Basis von IP-Adressen oder auch auf der Grundlage von Subnets:

salt -C "*web* and G@cpuarch:x86_64 and G@num_cpus:[34]" test.ping
web01.example.com
 True
web02.example.com
 True
web04.example.com
 True

Salt deckt möglichst viele Bereiche mit vorgefertigen Modulen ab. Alle Module sind in Python geschrieben und umfassen je einen klar abgesteckten Bereich an Funktionen. Das Modul »test« etwa enthält verschiedene Funktionen für die Überprüfung der korrekten Konnektivität der Minions, während »cron« die von Cronjobs verwaltet. Das Modul »mysql« stellt Funktionen zur Verwaltung der verbreiteten Datenbank zur Verfügung.

Modulare Funktionsvielfalt

Die Vielzahl von Modulen ist mehreren Kategorien zugeordnet. Eine vollständige Liste findet sich unter [3]. Die ausführliche Salt-Dokumentation beschreibt jede einzelne Funktion, ist allerdings derzeit nur in englischer Sprache vollständig verfügbar. Das könnte sich jedoch noch in diesem Jahr ändern, da gerade viele Mitglieder aus der Community an der Übersetzung in die jeweils eigene Sprache arbeiten.

Wer frisch mit Salt startet, will für den einfachen Einstieg womöglich erst einmal Informationen von allen Minions abfragen. Abbildung 3 zeigt, wie das Modul »status« Informationen zur Auslastung der Minions anzeigt.

Abbildung 3: »salt “*” status.loadavg« zeigt die aktuelle Load der Minions an.

Analog zu »status.loadavg« lassen sich auch Statistiken zu CPUs (»status.cpustats« ), Festplatten (»status.diskstats« ), Arbeitsspeicher (»status.meminfo« ) und vielen weiteren Systembereichen einfordern. Das dafür verwendet Modul ist ausführlich in der Onlinedokumentation [4] beschrieben.

Als weitere Aufgabe wäre denkbar, dass ein Admin spontan alle »/etc/resolv.conf« -Dateien auf allen Systemen überprüfen muss. Mit Hilfe des File-Moduls ist diese Aufgabe für Salt keine Hürde (Ausgabe stark gekürzt):

salt "*" file.search /etc/resolv.conf '192.168.100.1'
salt_cent:
 False
salt_opensuse:
 False

Erkennbar ist, dass Salt in diesem Fall nicht mit dem Datei-Inhalt, sondern nur mit einen Rückgabewert (True, False) antwortet. Will man die durchsuchte Datei auch gleich korrigieren, kann sich der Systemadministrator entweder eines vorhandenen Konfigurationsmanagements bedienen oder diese Aufgabe unkompliziert mit Salt ausführen (Ausgabe stark gekürzt):

salt "*" file.append /etc/resolv.conf "nameserver 192.168.100"
salt_cent:
 Wrote 1 lines to "/etc/resolv.conf"
salt_opensuse:
 Wrote 1 lines to "/etc/resolv.conf"

Das File-Modul bietet mehr als 70 weitere Funktionen, mit denen der Admin unter anderem Dateien überprüfen oder verwalten kann.

Besonders häufig dürften im Alltag Funktionen für das Setzen von Dateirechten, das Ändern von Eigentümern und das Ersetzen von Inhalten im Einsatz sein. Spätestens hier wird klar, dass sich die Funktionen von Salt zum Teil mit denen eines Konfigurationsmanagements überlappen. Gerade wenn jedoch ganz spontan – ohne vorheriges Schreiben und Ausrollen von Manifesten oder Konfigurations-Snippets – Änderungen vorzunehmen oder Dateien zu überprüfen sind, spielt Salt seine Vorteile als schnelles und unkompliziertes Werkzeug aus.

Ein weiteres mächtiges und wichtiges Modul heißt »pkg« . Es enthält alle Funktionen für das Paketmanagement, man kann mit ihm also beispielsweise Pakete nachinstallieren und installierte Paketversionen überprüfen. Für den Admin spielt es dabei keine Rolle, ob er über den Salt-Master Pakete unter Debian, Centos oder Suse installieren lässt – es ist nur ein Aufruf nötig, der die Aufgabe auf allen Zielsystemen durchführt.

Bei dem Package-Modul handelt es sich um ein virtuelles Modul, das je nach den darunterliegenden Systemen weitere Module aufruft (beispielsweise »aptpkg« für Debian-Pakete oder »yumpgk« für Distributionen, die den Paketverwalter »yum« benutzen).

Das Modul ist recht simpel zu verwenden: Mit »salt “*” pkg.install strace« sorgte der Autor dieses Beitrags zum Beispiel für die Installation des Strace-Pakets. Salt zeigt anschließend die frisch installierte Paketversion an. War das Paket zuvor bereits installiert, wird es gegebenenfalls aktualisiert; in solchen Fällen zeigt Salt zusätzlich die zuvor installierte Paketversion an. Wer zudem wissen möchte, welche Paket-Updates für die Minions anstehen, kann sich des Kommandos »salt “*” pkg.list_upgrades« bedienen.

Ein weiterer immer wiederkehrender Anwendungsfall von Salt dürfte das Verwalten von SSH-Keys auf den Minions sein. Vorstellbar ist beispielsweise ein Szenario, in dem ein Mitarbeiter frisch in das Unternehmen gekommen ist und sofort Zugriff auf alle Systeme benötigt. Wer diese Aufgabe elegant und effizient lösen möchte, kann auf dem Salt-Master nach »/srv/salt« wechseln und mit »mkdir ssh-keys« ein Verzeichnis anlegen, in dem sich später alle SSH-Schlüssel befinden sollen. Mit einem Texteditor lässt sich der SSH-Key des neuen Mitarbeiters in der Datei »/srv/salt/ssh-keys/Mitarbeitername-id_rsa.pub« ablegen.

Der folgende Aufruf des Salt-Masters verteilt den Schlüssel dann auf allen Minions:

salt "*" ssh.set_auth_key_from_file root salt://ssh-keys/valentin.hoebel-id_rsa.pub

Das Beispiel hinterlegt den Key aus der Datei »valentin.hoebel-id_rsa.pub« auf allen Minions in der Datei »authorized_keys« des Root-Benutzers. In der Folge hat der Benutzer Valentin Höbel nun SSH-Zugriff auf alle Server – beim Verwenden dieses Moduls ist also Vorsicht geboten. Wer lieber schnell einen Key entfernen möchte, ist mit dem Aufruf »salt ‘*’ ssh.rm_auth_key root Schlüssel« gut bedient.

Schon diese kleine Auswahl an Beispielen zeigt die Vielzahl der in Salt eingebauten Funktionen, die sich für viele Alltagsaufgaben des Admin eignen. Wer tiefer einsteigen möchte, findet in der offiziellen Modulübersicht unter [2] weiteren Lesestoff.

Alles können die Salt-Module aber auch nicht abdecken. In solchen Fällen ist hilfreich, dass Salt-Minions bei Bedarf auch vollständige Shellkommandos verarbeiten können. Das Listing 1 zeigt, wie die Autoren testweise einen Befehl absetzten. Wer sich zudem häufiger bei der Ausführung der gleichen Shellkommandos ertappt, kann auch sein eigenes Modul schreiben und es quasi in Salt einhängen [5].

01 [root@salt_master ~]# salt "*" cmd.run "time sleep 1s"
02 salt_cent:
03
04  real 0m1.001s
05  user 0m0.000s
06  sys 0m0.001s
07 salt_opensuse:
08
09  real 0m1.001s
10  user 0m0.000s
11  sys 0m0.000s
12 (Ausgabe stark gekürzt.)

Job statt Modul

Bei jedem mittels Salt abgesetzten Kommando handelt es sich um einen Job, den Salt möglichst vollständig parallel auf allen Zielsystemen ausführt und anschließend mit den Rückmeldungen der Minions zwischenspeichert. Selbst beim Abbruch eines laufenden Jobs sorgt Salt für die Ausführung auf den übrig gebliebenen Minions, wie die Abbildung 4 demonstriert.

Ctrl«+C«« bricht die Ausgabe der Minion-Rückmeldungen, nicht jedoch das eigentliche Kommando ab.” width=”300″ height=”80″ /> Abbildung 4: Der Abbruch mit Ctrl«+C«« bricht die Ausgabe der Minion-Rückmeldungen, nicht jedoch das eigentliche Kommando ab.

Dank des mitgelieferten Tools »salt-run« kann der Master den aktuelle Zustand des Jobs überprüfen (Listing 2). Die Job-Historie lässt sich auf dem Master mit dem Kommando »salt-run jobs.list_jobs« einsehen, wobei man die Rückmeldung der Minions standardmäßig nur für die letzten 24 Jobs aus » salt-run jobs.lookup_jid Job-ID« betrachten kann. Jobs lassen sich übrigens auch ins Konfigurationsmanagement einbauen.

01 [root@salt_master ~]# salt-run jobs.active
02 '20140329181443569112':
03  Arguments:
04  - find /
05  Function: cmd.run
06  Returned:
07  - jid
08  Running:
09  - salt_centos: 6951
10  - salt_opensuse: 8703
11  - salt_syndic_master: 4300
12  - salt_syndic_debian: 9375
13  - salt_bsd: 77541
14  Target: '*'
15  Target-type: glob
16  User: root

Konfigurationsmanagement

Da sich dieser Artikel hauptsächlich mit Salt als Werkzeug für das Ausführen von Remote-Kommandos beschäftigt, reißt er das Konfigurationsmanagement von Salt nur ganz kurz an. Es beruht darauf, dass sich mit Hilfe von so genannten Salt-States die gewünschten Zustände in SLS-Dateien hinterlegen und an Minions verteilen lassen. Dank eines mächtigen Templating-Systems bietet Salt damit ein vollständiges und funktionstüchtiges Konfigurationsmanagement an, das allerdings auf den ersten Blick im Vergleich etwa zu Cfengine 3 oder Puppet vielleicht etwas umständlich wirkt, es aber gar nicht sein muss.

Als bemerkenswert erweist sich der Umstand, dass sich die Salt-States-Dateien (SLS) in unterschiedlichen Formaten schreiben lassen. Auf diese Weise fällt ein Umstieg von anderen Lösungen auf Salt leicht, da nicht jedem Admin das Standardformat Yaml liegt. Umsteiger stellen außerdem fest, dass der Inhalt der SLS-Dateien eher der Beschreibung von Zuständen ähnelt. Dies soll zu besserer Lesbarkeit beitragen.

Besonderes Augenmerk bei den Salt-States liegt auf der Möglichkeit, die Zusammenhänge und damit auch die Gesamtkontexte zu hinterlegen, womit den Anforderungen an ein Orchestrierungssystem Genüge getan wird. Denkbar ist es damit beispielsweise, dass in einem State für Centos-Systeme hinterlegt wird, welche Pakete in welchen Versionen zu installieren sind.

Wenn diese Bedingungen erfüllt sind, kann Salt sich Diensten und Dateien widmen, die immer laufen beziehungsweise immer einen bestimmten Inhalt besitzen sollen. Außerdem ist es möglich, mit Hilfe der so genannten Pillars Informationen auf Minions zu hinterlegen, die dann Salt-Module oder das Konfigurationsmanagement nutzen können. Während der Admin mit Grains also Daten auf den Minions generiert, lassen sich Pillars nutzen, um Informationen vom Master auf die Minions zu verteilen.

Prinzipiell ist das Konfigurationsmanagement von Salt dazu in der Lage, bestehende Lösungen zu ersetzen, auch wenn das gut überlegt sein will. Wenn in dem eigenen Netzwerk noch gar keine Lösung dieser Art implementiert wurde, trifft der Admin mit Salt eine gute Wahl.

Salt-Cloud und Salt-Virt

Der Hersteller scheut sich nicht, Salt als umfassendes Werkzeug für das Deployment und den Betrieb von Cloudumgebungen zu bewerben. Um diesen Anspruch zu erfüllen, entstand mit Salt-Cloud ein Werkzeug für das Provisioning von Cloudinstanzen.

Während das Tool ursprünglich als Stand-alone-Lösung entwickelt wurde, ist es seit der Version 2014.01 fester Bestandteil des ganz normalen Salt. Dank einer Anbindung an gängige Cloudanbieter lassen sich damit Public-Cloud-Umgebungen festlegen, ausrollen sowie verwalten. Damit schließt sich denn auch der Kreis, wenn es um die Verwaltung der gesamten Infrastruktur eines Unternehmens geht (also sowohl Private wie auch Public Cloud).

Weil ein Mischbetrieb aus Linux-, Unix- und Windows-Servern in der Praxis häufig anzutreffen ist, existiert unter [6] ein Salt-Minion auch für Windows, der sich an einen Salt-Master hängen und Befehle von ihm entgegennehmen kann. Ein großer Teil der Salt-Module ist für Windows portiert, womit das Konfigurationsmanagement auch die Rechner aus der Microsoft-Welt betreuen kann. Derzeit ist allerdings nur der Minion für Windows verfügbar; dass es jemals auch einen Master für das geschlossene Betriebssystem geben wird, gilt dagegen als sehr unwahrscheinlich.

Wer nach Hilfsmitteln für das Verwalten von Serverfarmen sucht, wird bei Salt fündig. Es liefert nicht nur zeitsparende Hilfsmittel für die parallele Administration, sondern auch gleich einen durchdachten Mechanismus für Konfigurationsmanagement und Cloudverwaltung. Neben eigenen Servern lassen sich zudem auch die Server von Drittanbietern wie Amazon oder Rackspace anbinden.

Ausgereift

Zusätzliche Schmankerl wie Grains, Windows-Anbindung und Support für Embedded Devices runden das Angebot ab. Die Funktionsvielfalt und Qualität der einzelnen Komponenten lässt erkennen, dass der Saltstack inzwischen zu einem ansehnlichen Produkt herangereift ist. Und mittlerweile stützt auch das Unternehmen Saltstack die Entwicklung der frei verfügbaren Software, das Trainings, Zertifizierungen, Support und eine kommerzielle Version bietet. (jcb)