SaltStack: Salzige Alternative zum Puppetspieler
Für das Konfigurationsmanagement von Servern gibt es verschiedene Programme. Dabei tauchen meistens die Namen von Puppet, Ansible und Salt auf. Im folgenden Blogartikel werden einige Features von SaltStack (kurz: Salt) vorgestellt. Das hilft dem Leser dabei zu entscheiden, ob es eine Alternative zu Puppet oder Ansible sein kann. Entscheidend für die Wahl ist, für welche Konfigurationen man das entsprechende Tool einsetzt.
Der Vorteil von Ansible ist, dass Deployments durch ein (meist) einmaliges Einrichten der Software und einer einmaligen Konfiguration sehr einfach sind. Möchte man hingegen bei einem Server einen gewissen Konfigurationsstand dauerhaft erhalten oder überprüfen und gegebenenfalls auch anpassen, ist vermutlich Puppet einer der Favoriten. Was Puppet und Ansible zudem unterscheidet ist, dass bei Puppet auf jedem verwalteten Server ein Agent läuft, der den Master regelmäßig nach dem aktuellen Stand frägt.
Ansible wird per ssh ausgeführt und ist somit „agentless“. Ebenso wiederholt Ansible keine unnötigen Schritte. Jedoch muss jeder Durchlauf über den Server, auf dem Ansible läuft, ausgeführt werden (für regelmäßige runs lässt sich hier natürlich auch ein cronjob oder ähnliches nutzen).
Beispiel:
Installation vim auf Host mit Minion (CentOS 7):
salt 'minion' pkg.install vim-enhanced
Installation von vim über salt-ssh auf einem Host, der nur als Host auf dem Master im rosterfile definiert ist (CentOS 7):
salt-ssh 'testhost' pkg-install vim-enhanced
Doch das eigentliche Thema des Beitrags ist nicht der Vergleich von Puppet und Ansible, sondern Salt. Genau wie Puppet kann Salt im klassischen Fall mit einen Agent (salt-minion) betrieben werden. Alternativ besteht die Möglichkeit über salt-ssh die Konfiguration auf Servern analog zu Ansible auszurollen.
Dabei kann die gesamte Konfiguration für Hostgruppen, Environments oder einzelne Hosts aufgerufen werden. Der Zustand, in dem die Server sich befinden sollen, wird durch sogenannte States festgelegt. Sind entsprechende Definitionen bereits umgesetzt und unverändert, werden diese beim Durchlauf übersprungen.
Salt basiert im Kern auf Python, allerdings leicht verständlich gehalten, sodass man nicht zwingend Pythonkenntnisse braucht. Allerdings können bei salt nicht nur diese vordefinierten States ausgeführt werden, sondern auch einfache Kommandos. Diese können bei Hostgruppen oder einer ganzen Umgebung gleichzeitig angewendet werden. Auch die Sortierung der Hosts nach Grains ist möglich. Grains sind systemspezifische Parameter, die zum Beispiel über Kernelversion, Betriebssystem oder auch eigen definierte Funktionen ausgelesen werden können. Damit salt-ssh funktioniert muss zunächst ein sshkey auf den entsprechenden Server übertragen werden. Für die Variante mit Agent (Minion) wird vom Server ein Key erstellt. Akzeptiert der Salt-Master diesen, kann er sich mit ihm verbinden – diese Verwaltung ist analog zur Key-Verwaltung bei Puppet.
Beispiel:
Ein einfache State-Definition der die Installation wie im vorherigen Beispiel ausführt aber auch eine entsprechende vimrc-Datei vom Master auf den Minion kopiert und die Berechtigungen setzt:
vim.sls vim: pkg.installed /etc/vimrc: file.managed: source: salt://vimrc mode: 644 user: root group: root
Um häufig verwendete Begriffe aus Salt kurz vorzustellen:
- states: Konfiguration für ein bestimmtes Feature bzw. eine bestimmte Anwendung. Damit werden die benötigten Pakete installiert, die entsprechenden Konfigurationsdateien kopiert/editiert/erstellt und die Dienste gestartet/gestoppt.
- grains: Rechnerspezifische Variablen wie Betriebssystem, Kernel etc., diese können als Parameter in den States verwendet werden.
- pillar: Parameter, die für die Konfigurationen in States verwendet werden. Diese sind entweder in zusätzlichen Verzeichnissen definiert oder werden von externen Anwendungen zur Verfügung gestellt (z.B. Foreman/orcharhino).
- formulas: Vorgefertigte States die von der Community zur Verfügung gestellt werden. Häufig mit einer Beispieldatei für die Pillars die mit dem entsprechenden State verwendet werden können.
Für diejenigen, die Vorkenntnisse mit Puppet haben, zeigt die folgende Auflistung die entsprechenden Gegenstücke in Puppet aus dem Saltvokabular. Damit kann der Vergleich zu Puppet leichter verfolgt werden.
| Salt | Puppet |
|---|---|
| grains | facts |
| pillar | hiera |
| states | manifests/modules |
| formulas | puppet-forge module |
Die Zuordnung zwischen Salt und Puppet ist nicht zu 100% gleich, aber erleichtert für Leute mit Puppeterfahrung den Vergleich.
Während bei Puppet die Agents regelmäßig (standardmäßig: alle 30 min) beim Master nach Änderungen nachfragen, gibt es bei Salt einen Scheduler für die Steuerung.
Es muss nicht immer jeder Server und jeder State übergeben werden, sondern man kann neben der kompletten Konfiguration auch nur bestimmte State für ein bestimmtes Environment oder nur einzelne Server laufen lassen. Die Läufe für States sind entweder für einzelne zeitlich konfigurierbar oder wie bei Puppet für alle auf einmal umsetzbar. Durch die regelmäßigen Saltruns entsteht die Möglichkeit, sehr frei und übersichtlich zu konfigurieren.
Für einige Programme gibt es auch Formulas, die aus umfangreichen States bestehen (ähnlich wie Puppetmodule). Diese enthalten ein Beispiel, welche Parameter konfiguriert werden können. So ist es nicht notwendig, alle States selbst zu schreiben. Für weit verbreitete Bausteine (z.B. mySQL-Datenbanken oder Apache) gibt es schon ausführliche States, die in der Regel verschiedene Distributionen unterstützen. Allerdings ist hier keine so große Auswahl vorhanden wie bei den Modulen in der Puppetforge.
Beispiel:Eine deutlich komplexere Definition für die Installation von vim und Konfiguration der vimrc kann in der entsprechenden formula gefunden werden: https://github.com/saltstack-formulas/vim-formula Dazu ist eine beispielhafte pillar.example-Datei enthalten, die in einem Beispiel zeigt wie die Konfiguration aussehen könnte. Dabei haben jetzt die Parameter einen Defaultwert, der in einem eigenen Pillar-Verzeichnis mit einer Datei für die eigenen Bedürfnisse angepasst werden kann. |
Wie bei allen Konfigurationsmanagementtools können bei Salt für die Gruppierung von Servern Environments erstellt werden (zum Beispiel klassisch in Development, QA und Production). Dabei können sowohl die States als auch die Pillars auf diese Environments aufgeteilt werden oder auch aus mehreren Ordnern ihre Parameter mergen. Bei der Verwendung von Parametern (Pillars), wird auch hier – ähnlich wie bei Hiera in Puppet – eine Hierarchie festgelegt, welche Parameter am Ende von welcher Konfiguration überschrieben werden.
Salt kann nicht nur das Konfigurationsmanagement übernehmen, sondern auch orchestrieren. Auf dem Salt-Master können sogenannte Reactors eingerichtet werden, die auf Events oder Beacons reagieren. Events können für Saltruns definiert werden und somit Fehler abfangen oder auf andere Ereignisse reagieren. Beacons können Monitoring von Diensten, die nicht Teil von Salt sind übernehmen und beispielsweise die System- und Speicherauslastung im Auge behalten. Wird ein vordefinierter Wert über- oder unterschritten, kann das wiederum einen der Reactors auslösen. Somit kann in einem sehr simplen Fall überwacht werden, wie groß der Logordner ist. Ab einer bestimmten Größe wird ein Reactor ausgelöst, der die Logs (oder nur bestimmte) löscht, um wieder Speicher auf der Festplatte freizugeben.
Sowohl die States als auch die Pillars lassen sich über Gitrepositories verwalten – dabei sollte mindestens ein Repo für die Pillars und mindestens ein Repo für die States verwendet werden. Dabei entsprechen die Branches den verschiedenen Environments (wobei mit default-Einstellungen der master-Branch dem base-Environment entspricht). Hier lassen sich mehrere Repositories einbinden bzw. mit lokalen Ordnern oder bei den Pillars mit externen Quellen (wie z.B. Foreman/orcharhino) kombinieren. Dabei stellt die Reihenfolge der Quellen im Konfigurationsfile des Masters die Hierachie, nach der bei mehr als einer Quelle die Werte bzw. States zusammengeführt werden, dar. Bei den Git-Verzeichnissen werden die States und Pillars auf dem Master zwischengespeichert. Das bedeutet, dass die Minions keine Verbindung zu den entsprechenden Verzeichnissen benötigen, sondern direkt alles vom Master bekommen. Für die Verbindung zum Git-Verzeichnis können entweder die entsprechenden Login-Daten (User und Passwort) hinterlegt werden oder per ssh-key darauf zugegriffen werden. Die Konfiguration dazu ist analog zum standardmäßigem Klonen eines solchen Verzeichnisses.
Saltintegration in Foreman/orcharhino
Für orcharhino bzw. Foreman existiert ein Plugin zur Integration von Salt. Dieses Feature ist allerdings noch nicht so weit entwickelt wie beispielsweise die Integration von Puppet. Die Verwaltung der Keys von Minions (salt-ssh wird bisher nicht unterstützt) erfolgt über die WebGUI von orcharhino/Foreman. Ebenso können den Hosts bzw. Hostgruppen die entsprechenden States zugewiesen werden. Über die Detailansicht ist ein neuer Button mit „Run Salt“ verfügbar. Durch diesen wird für den entsprechenden Host ein Saltrun angestoßen. Diese Läufe erzeugen genauso wie bei Puppet einen Report. Auf seiner Oberfläche zeigt dieser an, welche Änderungen vorgenommen wurden und wo unter Umständen ein Fehler aufgetreten ist. Für automatische Durchläufe über das Salt Scheduling werden ab der Saltversion 2017.7 auch Reports erzeugt, die anschließend in Foreman abrufbar sind. In älteren Versionen wird dies bisher nicht unterst
Die States als auch die Pillars werden auf dem Foreman/orcharhino-Server klassisch gespeichert, damit diese importiert werden können. Externe Quellen für States und Pillars wie beispielsweise das vorher beschriebene gitfs funktionieren bisher noch nicht mit der Integration in orcharhino bzw. Foreman. Allerdings können die Hostparameter, die in der Oberfläche gesetzt sind, als Pillar genutzt werden. Das bedeutet, dass entsprechende Parameter in den States verwendet werden können. Alternativ kann man über die Hostparameter auch Pillars überschreiben; dies funktioniert aber nur für Strings. Komplexere States mit unterschiedlichen Pillars pro Host oder Hostgruppe müssen somit weiterhin wie im klassischen Salt in den entsprechenden Dateien angelegt werden. Für einfache States (z.B. Installation und Defaultkonfiguration einer Software) ist das Plugin bereits gut geeignet – mit ihnen können die States den Hosts zugewiesen werden und einen entsprechenden Saltrun auszulösen.
Das könnte Sie auch interessieren:
ATIX-Crew
Neueste Artikel von ATIX-Crew (alle ansehen)
- Foreman Birthday Party 2024 - 1. August 2024
- CrewDay 2024 - 6. Juni 2024
- Die XZ-Sicherheitsschwachstelle: Eine Übersicht - 9. April 2024
