Die meisten Admins denken beim Stichwort "Automation" im Bereich Virtualisierung intuitiv an Software, die sich mit Fug und Recht als Urgestein der Branche betiteln darf: Puppet und Chef. Mancher Admin mag auch Ansible vor Augen haben, das als Antithese zu den beiden Erstgenannten 2013 das Licht der Welt erblickte, sich eine treue Fangemeinde erarbeitet hat und mittlerweile zu Red Hat gehört. Die Zahl der Menschen, die bei Automation an Salt – kurz für SaltStack – denken, dürfte eher überschaubar sein. Ganz neu ist jene zwar auch nicht. Bis heute haftet Salt aber der Ruf der Nischenlösung an – die meisten Admins kennen den Begriff, können aber nicht viel mit ihm anfangen.

Umso größer war das Raunen, als VMware im September 2020 verkündete, SaltStack zu kaufen und die Rechte am Produkt zu übernehmen. Die Gründe für das Raunen waren dabei mannigfaltig: Viele Beobachter schienen überrascht, weil sie VMware bisher nicht als Open-Source-affine Firma auf dem Radar hatten. Obgleich dies VMware an dieser Stelle Unrecht tut: In den vergangenen Jahren hat die Firma in Sachen Open Source ordentlich nachgelegt und mittlerweile mehrere quelloffene Produkte im Portfolio. Andere zeigten sich überrascht, weil VMware in Form der Automation Suite eigentlich schon Werkzeuge zur Automatisierung von Prozessen im Programm hat. Gerüchte schossen daraufhin ins Kraut und stellten die Zukunft von SaltStack als Open-Source-Produkt infrage.

Diese Entwicklungen sind Grund genug für IT-Administrator, einmal genauer hinzuschauen:

- Was kann SaltStack Enterprise eigentlich und wie performt es im Gegensatz zu Puppet, Chef & Co.?

- Welche grundlegenden Funktionen bietet die Software und was hebt sie von der Konkurrenz ab?

In diesem Artikel gehen wir der Sache auf den Grund und beleuchten SaltStack im Hinblick auf fünf Aspekte. Der erste Aspekt befasst sich mit dem grundsätzlichen Feature-Set der Software. Was lässt sich mit SaltStack sinnvoll automatisieren, welche Funktionen bietet das Werkzeug und wie schlägt es sich etwa in Sachen Konfigurationsmanagement? Die zweite Disziplin beschäftigt sich mit der Benutzbarkeit der Software: Wie komplex ist der Einstieg, wie steil die Lernkurve?

Der dritte Aspekt bezieht sich auf die Vielseitigkeit von SaltStack: Was lässt sich mit Salt gut automatisieren und wo stößt die Software an ihre Grenzen? Unterstützt sie etwa Workloads in der Cloud und vor Ort gleichermaßen? Kriterium Nummer vier dreht sich um die Erweiterbarkeit des Produkts und die Anbindung an andere Dienste: Wie gut spielt SaltStack zusammen mit Standardkomponenten, wie gut lassen sich spezielle Funktionen per Plug-in oder Erweiterung nachrüsten?

Das fünfte und letzte Kriterium schließlich befasst sich mit einem der wirklich kritischen Aspekte im Rechenzentrum der Gegenwart: Security & Compliance. Bietet SaltStack Funktionen für diese Themenbereiche an, und wie sind sie konzipiert? Wie greift SaltStack dem Admin – idealerweise automatisch – unter die Arme, um die Sicherheit einer Umgebung zu erhöhen?

Am Ende des Beitrags wagen wir auch einen Ausblick: Wohin wird SaltStack sich unter seiner neuen Ägide entwickeln? Was hat VMware mit der Software vor und auf welche Veränderungen müssen sich Administratoren, die heute bereits Salt verwenden, gefasst machen?

Dass SaltStack bei vielen Administratoren bisher eher unter dem Radar flog, sagt über die Qualität der Software oder ihren Funktionsumfang freilich nichts aus. Und wenig ist es auch nicht gerade, was die Entwickler bei SaltStack auf die Beine gestellt haben. In Sachen Automation bietet die Software im Grunde alles, wonach Administratoren sich heute sehnen – und zwar mit atemberaubender Vielseitigkeit. So darf sich der Nutzer etwa aussuchen, ob er SaltStack mit einem Agenten ("Minion") (Bild 1) auf den Zielsystemen betreiben möchte, ohne Agent oder mittels eines Proxy-Agenten für vertrackte Netzwerksetups.

Die Architektur auf Basis von Minions ermöglicht es SaltStack, in die Breite zu skalieren. Manchem Admin mag der Schreck bis heute in den Knochen sitzen, der lauert, wenn er einen Puppet-Master erstmals auf eine größere Menge Hosts loslässt. Das Remote-Execution-Framework in SaltStack ist ab Werk darauf ausgelegt, diese Form der Überlast zu verhindern. Stattdessen skalieren die Ressourcen der Automation proportional zur Anzahl der zu bearbeitenden Hosts. Dieselbe Funktionalität unterstützt SaltStack mittlerweile auch auf der Ebene der Master-Server. Von denen lassen sich in aktuellen SaltStack-Versionen nämlich ebenfalls mehrere betreiben, sodass auch hier echte Skalierbarkeit in die Breite gegeben ist.

An dieser Stelle sei auf eine Begrifflichkeit hingewiesen: Das Produkt und die Firma, die VMware sich einverleibt hat, heißen SaltStack (Enterprise). Der Name bezeichnet ein Paket aus verschiedenen Komponenten, von denen eine ein Automatisierer ist. Zu diesem gehört auch das Remote Execution Framework, das seinerseits nur unter "Salt" firmiert. Der Funktionsumfang von Salt enstpricht dem, was wir von einem guten Automatisierer heutzutage erwarten.

Das Hinterlegen passender Konfigurationsdateien ist etwa eine der ureigensten Aufgaben von Automatisierern und Salt enttäuscht den Administrator nicht. Die Struktur, wie Salt Konfigurationsmanagement implementiert, ist allerdings etwas gewöhnungsbedürftig im Vergleich zu anderen Automatisierern. Denn unter der Haube werkelt bei Salt zunächst eine so genannte State Engine. Diese enthält Informationen zu "States", das sind in Salt verschiedene Module, die sich um die Konfiguration einer Komponente kümmern. So gib es einen IPMI-State, einen Apache-2-State, einen Nginx-State und etliche weitere States.

Obendrein steht es dem Administrator frei, selbst eigene States zu schreiben, um Support für Teile der Systemkonfiguration nachzurüsten, die Salt ab Werk nicht unterstützt. Den States stellt der Administrator Dateien zur Seite, die deren konkrete Konfiguration auf einem System beschreiben. Bei den unterstützten Programmier- und Skript- sowie Markup-Sprachen für States gibt Salt sich ausgesprochen vielseitig: Neben einzelnem YAML stehen auch eine große Menge exotischer Notationsmöglichkeiten zur Auswahl, etwa PyDSL, JSON oder – für Konfigurationstemplates extrem wichtig – Jinja.

Die Konfiguration der States ist den Salt-Minions auf allen Hosts zu jedem Zeitpunkt vollständig bekannt. Ruft der Admin Salt auf, um auf einem Zielsystem eine Konfiguration zu hinterlegen, leitet der Salt-Master diesen Befehl an den jeweiligen Minion weiter. Dieser wandelt aus der Konfiguration des States und dem State selbst die hinterlegte Konfiguration in echten Code auf dem System um. Das erweist sich als extrem vielseitig: Vom Anlegen eines Nutzers über das Hinterlegen spezifischer Konfigurationsdateien bis hin zur Installation von Paketen lassen sich beinahe sämtliche vorstellbaren Aufgaben erledigen.

Ebenfalls hilfreich zur Hand gehen dem Administrator hier noch die Salt Grains: In den Grains speichert Salt diverse Details über das Inventar eines Systems, etwa die anliegenden IP-Adressen, die verfügbare Hardware oder die laufenden Dienste. Bei der Arbeit mit States stehen dem Administrator diese Grains ebenso zur Verfügung, und das ohne zusätzlichen Ressourcenbedarf.

Logisch unterscheidet Salt bei seiner Arbeit zwischen dem Ausführen einzelner Aufgaben auf den Systemen und dem Hinterlegen von Konfigurationsdateien. Eine Aufgabe kann etwa das Anlegen eines Benutzers sein, wofür ein entsprechender State zur Verfügung steht. Möchte der Administrator allerdings Dienste mit einer passenden Konfiguration versorgen, bringen ihn States nicht weiter. Hier kommt das bereits erwähnte Jinja zum Einsatz – eine Template-Sprache mit generischen Platzhaltern, die nicht nur bei Salt, sondern etwa auch bei Ansible zum Einsatz kommt.

Der Admin baut ein Konfigurationsskelett und nutzt darin für die einzelnen Konfigurationswerte Platzhalter. Das Jinja-Modul der State Engine ersetzt dann dynamisch in diesen Templates die Platzhalter und packt die fertigen Konfigurationsdateien an die Stelle, an die sie nach Anweisung des Admins gehören. Dass hier Jinja zum Einsatz kommt, hilft, weil die Sprache recht verbreitet ist und vielen Admins vermutlich bereits bekannt. Zudem erlaubt sie neben bloßen Platzhaltern auch komplexere Strukturen wie Wenn-Bedingungen sowie For-Schleifen. Nahtlos übernehmen werden sich die Templates anderer Tools aber in der Regel nicht, weil Salt eigene Bezeichnungen für die Platzhalter in seiner State-Engine nutzt.

Darüber hinaus bietet SaltStack viel grundsätzliche Funktionalität, die Automatisierer in der einen oder der anderen Form erwarten lassen. APIs auf Basis des REST-Prinzips bietet SaltStack beispielsweise als eine Zugriffsmöglichkeit. Zur Verfügung steht aber auch eine intuitive, grafische Benutzeroberfläche. Was dem erfahrenen Kommandozeilen-Jockey wie Teufelszeug vorkommt, hat gerade in sehr großen Umgebungen durchaus eine Daseinsberechtigung: Zustandsdaten von hunderten Servern lassen sich grafisch unstrittig besser aufbereiten, als es auf der Shell der Fall wäre. Praktisch für die Compliance-Abteilung: SaltStack führt über die ausgeführten Arbeitsschritte penibel Buch. Alle jemals durchgeführten Aufgaben finden sich in der Job History ebenso wie in der History pro Benutzer.

Zum Lieferumfang gehört obendrein eine interne Rechteverwaltung zusammen mit einem Role-Based Access Model (RBAC). Das RBAC von SaltStack ermöglicht es, innerhalb der Automationslösung Rollen zu definieren und diese Nutzern zuzuweisen, um ihnen bestimmte Berechtigungen einzuräumen oder zu nehmen. Das wirkt sich auch und insbesondere auf die Multi-Cloud-Eigenschaften von SaltStack aus, auf die wir später im Detail noch eingehen. Denn über das eingebaute RBAC definiert ein Unternehmen bei Bedarf auch, welche Workloads welcher Mitarbeiter in einer spezifischen Cloudumgebung ausrollen darf. Das ist enorm hilfreich, um ein Compliance-Regime zu etablieren und Kosten in Clouds durch "vergessene" Instanzen zu vermeiden.

Ein spezifisches Feature von SaltStack ist schließlich die Redundanz der zentralen Komponenten. Immer mehr Unternehmen gehen dazu über, sich weniger auf Backups und mehr auf Automation zu verlassen. In den Backups landen dann nur noch echte Nutzdaten. Die Konfiguration von Systemen hingegen liegt in einem Git-Verzeichnis der Automation, und falls neue Server zu installieren oder bestehende Server zu ersetzen sind, geht das automatisiert.

Das setzt freilich voraus, dass die Automation redundant ist. Salt bietet hier gleich mehrere Optionen. Klassische Standby-Hochverfügbarkeit mit Failover im Falle des Ausfalls eines Salt-Masters ist die Grundvariante. Darüber hinaus steht noch die Multi-Master-Option zur Verfügung, bei der die Salt-Master sich die Minions, für die sie zuständig sind, untereinander autark ausmachen. Segnet ein Master dann das Zeitliche, übernehmen die verbliebenen Master dessen Aufgaben.

Besonders stolz sind die Entwickler bei SaltStack zudem auf die Eigenschaft von Salt, sich als Umgebung für "eventbasierte Infrastruktur" anzubieten. Was im Marketingsprech schön klingt, meint eigentlich etwas recht Banales: Salt kann sich an einen Eventbus koppeln und dort Ausschau nach Benachrichtigungen für bestimmte Ereignisse halten – das ist ohnehin im Kern das, was SaltStack mit ZeroMQ tut. Auf Basis seiner Konfiguration ist es in der Lage, auf einzelne Ereignisse mit festgelegten Methoden zu reagieren. Merkt Salt etwa, dass auf einem virtuellen System in einer Cloudumgebung eine bestimmte Lastgrenze überschritten wird, könnte der Administrator mittels dieses Mechanismus dafür sorgen, dass per API zusätzliche Instanzen desselben Dienstes starten. Der wahre Nutzen der Event-Engine in Splunk ist freilich deutlich umfangreicher – doch fällt die Sache bald komplex aus, was uns nahtlos zum nächsten Aspekt von SaltStack bringt.

Die schönste Funktionalität hilft nicht weiter, wenn der Admin sie nicht durchdringt und deshalb nicht nutzen kann. Ein maßgeblicher Faktor bei der Bewertung von Automationssoftware ist deshalb, wie leicht der Admin sich in diese hineindenken kann und wie komplex ihre Nutzung im Alltag ist. Werfen wir einen Blick auf die am Markt existierenden Angebote, ergeben sich zwei Fraktionen: Auf der einen Seite stehen Werkzeuge wie Puppet und Chef, die mit eigener dekla-rativer und eher komplexer Skriptsprache daherkommen. Auf der Gegenseite steht das mittlerweile zu Red Hat gehörende Ansible, das auf Basis von YAML eine recht einfache Syntax befolgt. Gerade Ansible sagen Admins nach, es sei leicht zu erlernen und mithin für Automationsneulinge gut geeignet.

SaltStack orientiert sich allerdings eher an Puppet und Chef, denn das Werkzeug ist komplex – jedenfalls deutlich komplexer als Ansible. Und zwar aus mehreren Gründen. Einerseits besteht SaltStack aus mehr Komponenten als Ansible, der Admin muss also die Architektur der Software erstmal verstehen. Hinzu kommt, dass Salt recht ausführlich mit Begriffen hantiert – die schon erwähnten States und Salts sind nur zwei Beispiele von vielen. Garniert wird all das mit einer auf YAML basierten Syntax, die zwar keine echte deklarative Skriptsprache ist, aber dennoch ihre Eigenheiten besitzt. Schon das Verständnis von SaltStacks sehr grundlegenden Funktionen braucht also einige Zeit.

Von den diversen Zusatzfunktionen war da noch gar nicht die Rede. Die GUI etwa ist zwar intuitiv aufgebaut, doch dürfte der Admin trotzdem etwas Zeit brauchen, um sie zu verstehen und um sich an die Arbeit mit ihr zu gewöhnen. In Summe gibt Salt sich nicht gerade besonders einsteigerfreundlich und konfrontiert Admins mit einer ziemlich steilen Lernkurve. Wer SecOps dazu nimmt – der Artikel geht darauf später noch ausführlich ein –, bekommt einen weiteren Layer an Komplexität hinzu, wo das Erstellen von Reports für Compliance-Zwecke und das Aufzeichnen von Job- und Benutzer-Histories eigentlich schon komplex genug ist.

Immerhin: Die Salt- und SaltStack-Dokumentation ist ausgesprochen umfangreich. Sie erklärt Begrifflichkeiten und Funktionsweisen des Programms ausführlich. Sie enthält zudem viele praktische Beispiele, aus denen Administratoren sich anfangs die notwendigen Details für die eigene Salt-Umgebung herleiten können.

Automationssysteme sind niemals eine Insel – sie sind viel mehr integriert in eine Umgebung aus verschiedenen großen und kleinen Rädchen, die sie drehen sollen. Die Frage, mit welchen externen Systemen sich SaltStack verbinden lässt und wie gut die Integration dort jeweils tatsächlich ist, ist deshalb von zentraler Bedeutung. Und tatsächlich gibt SaltStack sich hier sehr offen.

Das wird beispielsweise deutlich, wenn wir uns die Integration von SaltStack in externe Benutzerverzeichnisse ansehen. Wie beschrieben kann SaltStack intern eine eigene Datenbank mit Benutzern und Berechtigungen pflegen. Im Alltag kommt das allerdings eher selten vor, denn auch in kleineren Unternehmen finden sich heute zentrale Benutzerverzeichnisse auf Basis von LDAP oder auch Active Directory (Bild 3). Wer ein zentrales Verzeichnis hat, möchte den Zugriff auf SaltStack natürlich über dieses steuern und nicht eine zweite Quelle für Benutzerdaten in seiner Umgebung schaffen. Mittels Plug-in bietet SaltStack diese Möglichkeit jedoch problemlos und nahtlos. Nutzt der Admin Active Directory oder LDAP statt des eingebauten Nutzerverzeichnisses, lassen sich die RBAC-Regeln ebenso auf diese Accounts anwenden wie auf die lokalen.

Setups in der IT der Gegenwart sind so vielfältig wie die Unternehmen, die sie betreiben. Wohl dem Admin, der es mit einer völlig einheitlichen Umgebung zu tun hat, die etwa nur aus Linux-Servern besteht. Hier lassen sich die meisten Automationssysteme gut einsetzen, und SaltStack bildet keine Ausnahme von dieser Regel. Den Minion für Salt gibt es als fertiges Paket für eine Vielzahl von Linux-Distributionen, wobei der Fokus freilich auf den typischen Systemen für den Enterprise-Betrieb liegt. Zusätzlich lässt sich SaltStack wie eingangs erwähnt auch im "Agentless"-Modus betreiben. Anstelle der Minions, die mittels ZeroMQ-Bus mit ihren SaltStack-Mastern kommunizieren, kommt dann SSH zum Einsatz. In diesem Betriebsmodus ähnelt SaltStack also eher dem, was Admins bei Ansible bekommen. Aber eben nur fast: Praktisch die gesamte Arbeitslast bleibt bei diesem Szenario nämlich beim Master hängen, sodass dieser Ansatz nicht gut skaliert.

SaltStack verwaltet auf Wunsch aber nicht nur Linux-Systeme. Für Windows steht der Salt-Minion ebenfalls als fertige EXE-Datei zur Verfügung und der größte Teil der SaltStack-Funktionalität lässt sich auf Windows ebenso verwenden. Hinzu kommen Minions für die verschiedenen BSDs (Bild 4), deren Reifegrad sich allerdings voneinander unterscheidet und die auch immer wieder neue Features unabhängig voneinander bekommen. Grundlegende Aufgaben lassen sich mit Salt-Stack aber auf allen BSDs ohne Schwierigkeiten implementieren.

Auch ab Werk vorgesehen ist die Möglichkeit, aus Salt heraus via "salt-cloud" Workloads direkt in verschiedenen Cloudumgebungen zu verwalten. So startet Salt auf Zuruf beispielsweise eine VM in Amazons AWS, die es anschließend auch gleich mit einem Minion versorgt, der die VM aus der Ferne konfigurierbar macht. Mehr als 20 verschiedene Zielplattformen stehen bei dieser Funktion zur Verfügung. Mit Fug und Recht darf Salt sich deshalb auch als Werkzeug für Multi-Cloud-Umgebungen betiteln. Dabei spielt sicher auch die Orchestrierung eine Rolle – denn auf Zuruf des Admins rollt Salt nicht nur einzelne VMs in Clouds aus, sondern auch Verbünde virtueller Instanzen mit der Konfiguration für den gemeinsamen Betrieb.

Darüber hinaus bietet SaltStack verschiedene Möglichkeiten zur Verbindung von Drittanbietersoftware. Die in SaltStack vorhandenen APIs hat dieser Artikel ja bereits erwähnt – sie erlauben es, Salt Anweisungen über REST-Schnittstellen zu geben. Das "programmatische Ansprechen" der Automationslösung wird auf diese Weise möglich.

Ein vortreffliches Beispiel für den Einsatz im Großkonzern ist die Software für zentralisiertes Logging namens Splunk. Im Kern ist Splunk dem dreiteiligen Gespann aus ElasticSearch, LogStash und Kibana (ELK) sehr ähnlich und richtet sich an Admins, die eine komfortable Lösung für zentrales Logging wollen. De facto ist Splunk mittlerweile viel mehr eine komplexe Monitoringsoftware für Logstreams denn ein einfacher Logaggregator, und diesen Funktionsumfang lässt der Hersteller sich fürstlich entlohnen.

Wer Splunk und SaltStack kombiniert, darf sich allerdings freuen. Denn in seinem App-Store für Splunk Enterprise bietet Splunk neuerdings eine eigene App für die Integration mit SaltStack, die dafür sorgt, dass SaltStack seine gesamte Ausgabe auch an Splunk weiterleitet. Darauf basierend hat der Admin dann die Möglichkeit, Events in Splunk zu definieren, die zu festgelegten Reaktionen führen. Obendrein lassen die Ausgaben aus SaltStack sich auch in Form von Dashboards grafisch aufbereiten, etwa die Metrikdaten von SaltStack selbst. In Splunk lassen sich damit die zentralen SaltStack-Dienste überwachen (Bild 5).

Das Thema Automation spielt unmittelbar in die Themen Sicherheit und Compliance hinein. Eine gute Automation sorgt etwa dafür, dass das Setup aller Systeme stets so konfiguriert ist, wie es die Automation vorgibt (Idempotenz). Per Automation lassen sich also manuelle Änderungen auf einzelnen Systemen, wenn alles richtig eingerichtet ist, erkennen und überschreiben. Salt-Stack bietet ein umfangreiches Repertoire an Reporting-Funktionen. Ebenso lassen sich die in SaltStack selbst vorhandenen Features feingliedrig überwachen und nachvollziehen, zum Beispiel über die schon erwähnten Logdateien für Jobs und Nutzer. Für die Compliance-Abteilung lassen sich anhand einer Vielzahl von Parametern Compliance-Reports erstellen, die auch grafisch aufbereitet sein können.

Besondere Beachtung verdient außerdem das "SecOps"-Add-on zu SaltStack, das mit eigenem Preisschild daherkommt, dafür aber auch sinnvolle Funktionalität bietet. SaltStack offeriert eine Bibliothek fertiger Sicherheitsprofile für spezifische Systemtypen, etwa "Datenbank" oder "Webserver". Hat der Admin SecOps zur Verfügung, kann er diese für seine Systeme verwenden und Probleme oder abweichende Konfigurationen automatisch identifizieren. Zum Paket gehört auch eine automatische Compliance-Überwachung, die Änderungen nicht nur auf Zuruf durch den Admin revidiert, sondern das auch automatisch kann. Die zum Sec­Ops-Plug-in gehörenden Daten sind verschlüsselt, sodass Angreifer sie nicht erbeuten und schon gar nicht manipulieren können. Das CIS-Institut (Certification for Information Security) stellt via SaltStack zudem ein zertifiziertes Profil zur Verfügung, das die Erreichung der CIS-Zertifizierung erleichtert. Dieses lässt sich auf unterstützte Systeme ebenfalls automatisiert anwenden.

Besonders praktisch ist obendrein die bei SecOps eingebaute Analyse für offene Sicherheitsprobleme auf den Systemen. Hierzu vergleicht SecOps die auf den Systemen installierten Versionen von Paketen mit einer Liste aller bekannten Sicherheitsbugs und schlägt Alarm, falls ein Paket veraltet ist.

Über die Art und Weise, wie SaltStack sich selbst schützt, ist ein Kommentar hingegen fast überflüssig. Denn das Produkt nutzt alle gängigen Standards äußerst konsequent aus, indem es etwa sich selbst per SSL-Zertifikat absichert und die Anbindung externer Benutzerverzeichnisse wie beschrieben ermöglicht. Die Kommunikation zwischen Minions und Master lässt sich auf Wunsch ebenfalls per SSL absichern.

Am Ende unserer Betrachtung stellt sich noch die Frage, in welche Richtung sich SaltStack entwickelt und womit Admins rechnen dürfen und müssen. Grundsätzlich gilt: VMware hat SaltStack mit einiger Wahrscheinlichkeit nicht gekauft, um die Software nun in ein Closed-Source-Produkt zu verwandeln und die vorhandene Nutzerschaft auszupressen. Ganz im Gegenteil: In den vergangenen Jahren hat der Hersteller eine glaubhafte Open-Source-Reputation aufgebaut und die eigenen Anstrengungen in diese Richtung eher verstärkt denn vermindert. Möglich scheint hingegen durchaus, dass künftig mehr kommerzielle Zusatzfunktionen bleiben, die es nicht oder erst später in die Open-Source-Variante schaffen. Admins dürfen aber nach menschlichem Ermessen aktuell davon ausgehen, dass ihnen SaltStack und Salt als dessen Kern erhalten bleiben.

Auch stellt sich schließlich die Frage, wer das alles bezahlen soll – und SaltStack gehört leider zu jenen Anbietern, die sich im Hinblick auf das eigene Preismodell äußerst verschlossen geben. Konkrete Zahlen gibt es nur, wenn Interessenten den Anbieter um ein maßgeschneidertes Angebot bitten. Eine Recherche im Netz jedoch fördert ein paar Details zutage. Wer SaltStack Enterprise mit SecOps als Appliance in AWS betreiben möchte, zahlt für einen Master und 50 Minions bei jährlicher Zahlweise gute 15.000 US-Dollar. Andere Nutzer berichten von Beträgen zwischen 80 und 100 US-Dollar pro Knoten pro Monat bei einer unlimitierten Anzahl von Mastern. Für nicht-gehostete Varianten von SaltStack Enterprise finden sich im Netz vergleichbare Angaben, die von 80 bis 120 US-Dollar pro Knoten pro Jahr zuzüglich einer Grundgebühr sprechen. Preislich liegt SaltStack damit auf einem Niveau mit Puppet, Chef und Ansible Tower, sodass diese Zahlen plausibel scheinen.

SaltStack Enterprise erfindet an vielen Stellen das Rad nicht neu, liefert aber eine saubere Implementierung des Prinzips "Rad". Die Eingewöhnung in die doch recht spezielle Syntax beansprucht etwas Zeit. Funktional präsentiert das Produkt sich auf der Höhe der Zeit. Grundsätzliche Funktionen liefert die Software ebenso wie eine große Vielfalt im Hinblick auf die zu verwaltenden Systeme. Wer auf der Suche nach einem Automatisierer ist, sollte SaltStack als eine Option jedenfalls auf der Rechnung haben.