silvesterlangen.de
States
Kommen wir zu den Konfigurationen, die Systemweit über alle Minions automatisch eingerichtet werden sollen. SaltStack ist nicht nur dazu da Befehle vom Master direkt an die Minions zu senden, sondern bietet auch die Möglichkeit Konfigurationen/Einstellungen auf den Minios vorzunehmen. Ich zeige das hier anhand einiger Beispiele, um zu verstehen, was ich meine. Fangen wir aber erst mal klein an und öffnen die Konfigurationsdatei des Masters:
/etc/salt/master
Dort suchen wir folgende Zeilen und nehmen das Kommentarzeichen (#) weg, um diese Einstellung aktiv zu setzen. Mit diesen drei Zeilen aktivieren wir quasi die Konfigurationsmöglichkeit für die Minions. Das sieht dann so aus:
file_roots: base: - /srv/salt/
Nun wechseln wir in das Verzeichnis /srv/salt/. Falls es noch nicht angelegt ist, so solltest du es jetzt anlegen und dorthin wechseln. In diesem Verzeichnis werden die Konfigurationen abgelegt, die auf die Minions übertragen werden sollen.
Benutzerkonten anlegen/löschen
Nehmen wir an, dass wir ein Netz mit 20 Minions und einem Master haben. Die Minions führen einen besonderen Dienst aus der es erfordert, dass auf allen Minions ein bestimmtes Benutzerkonto angelegt ist. Wir wollen uns nicht die Mühe machen auf 20 Minions dieses Benutzerkonto anzulegen. Wir wollen auf dem Master ein mal eine Konfiguration hinterlegen, die dann auf alle Minions ausgerollt wird.
Die erste Konfigurationsdatei heißt immer "top.sls". Zwar kann man alle Konfigurationen gleich darin machen, aber davon rate ich dringend ab, da bei der möglichen Fülle und Komplexität später jede Übersicht verloren geht.
Die top.sls füllen wir mit folgendem Inhalt:
base:
'kernel:Linux':
- match: grain
- create_user
Diese Regel wendet sich automatisch an allen Systemen an, die einen Linux Kernel hat und führt dort das Script create_user.sls aus. Das Skript create_user.sls wird also referenziert. Das .sls schreibt man hier aber nicht mit rein. Beim Anlegen der Datei create_user.sls muss der Extender .sls natürlich hinten dran. Die Datei create_user.sls gehört natürlich ebenfalls in das Verzeichnis /srv/salt/.
Nun erstellen wir die Datei create_user.sls und füllen sie mit folgendem Inhalt.
manfred:
user.present:
- fullname: Manfred
- shell: /bin/bash
- home: /home/manfred
hannes:
user.absent
Was passiert jetzt hier genau? Der User manfred soll erzeugt werden (user.present). Es soll festgelegt werden, dass sein "Fullname" Manfred ist, er die Bash als Shell bekommt und sein HomeDIR in /home/manfred liegt.
Der Absatz hannes besagt, dass, sollte ein User hannes auf dem Minion (oder mehrere) existieren, dieser zu löschen ist.
Da der Syntax hier YAML ist, ist auf die Einrückung unbedingt streng zu achten, da sonst das Script nicht funktioniert! Saltstack meldet dann sowas wie
Comment: No Top file or master_tops data matches found.
Jetzt wird es interessant. Wir können uns jetzt aussuchen, ob wir möchten, dass der Master
- die Konfiguration an alle Minions sendet oder (PUSH)
- die Minions sich die Konfiguration beim Master abholen (PULL)
Die PUSH-Methode
Sie wird auf dem MASTER ausgeführt. Der Master sendet die Konfiguration(en) an die Minions und diese führen sie dann aus. Das bedeutet in der Praxis, dass bspw. ein CRON-Job in einem vordefinierten Intervall einen Befehl ausführt. Mit highstate wird die oberste Ebene der Konfigurationsfiles (also die top.sls) ausgeführt, was dazu führt, dass alle Konfigurationen ausgeführt werden.
salt '*' state.highstate
Möchte man nur einen ganz bestimmte Konfiguration auf dem Minion auslösen wie bspw. unser create_user, dann geht das so.
salt 'minion1.silvesterlangen.de' state.sls create_user
Die PULL-Methode
Die MINIONS holen sich die Konfiguration(en) beim Master ab. Je nach Bedarf macht es Sinn, dass der Minion bspw. wegen möglicher Firewallregeln die Konfiguration beim Master holt. Dann muss man pro Minion einen CRON-Job erstellen, der die Abholung im Intervall sicherstellt.
salt-call state.highstate
Pakete distributionsübergreifend installieren
Wozu haben wir denn ein so schönes System, wenn nicht zur Installation und Konfiguration von Softwarepaketen auf den verschiedenen Distributionen? Wir installieren in diesem Beispiel den Apache2 Webserver. Wie bereits bekannt heißt nicht jedes Paket in jeder Distribution gleich. Der Apache heißt auf Debiansystem "apache2", aber auf RedHat ist es "httpd". Wir müssen irgendwie Saltstack erklären, dass es so oder so heißen kann und er nachsehen muss um welches System es sich handelt, was er in den Grains (hier nachlesen) nachsehen kann.
apache: pkg.installed: {% if grains['os'] == 'RedHat' %} - name: httpd {% elif grains['os'] == 'Ubuntu' %} - name: apache2 {% endif %}Im nächsten Schritt öffnen wir die Datei top.sls und fügen ein
- apache_installhinzu. Die top.sls schaut dann vom Inhalt her so aus:
base: 'kernel:Linux': - match: grain - create_user - apache_install
Nun wollen wir erst mal ausprobieren, ob unsere Konfiguration funktioniert. Dafür können wir einen sog. "Dry Run" (Trockenübung) ausführen. Die Minions führen den Befehl nicht wirklich aus. Sie spielen das Szenario quasi nur durch und geben dann Rückmeldung, ob es funktioniert hätte. Das macht man so:
salt '*' state.highstate test=TRUE
Wenn es ein positives Feedback gegeben hat von allen Minions, dann lässt man das test=TRUE am Ende weg, sodass die Konfigurationen von den Minions tatsächlich ausgeführt werden.
