Mehr Struktur

Zum strukturierten Konfigurationsmanagement bietet Salt aber bessere Möglichkeiten als das Ausführen einzelner Befehle. Der Sinn ist ja, die Konfiguration eines Systems deklarativ festzulegen und es dann einem System wie Saltstack zu überlassen, sie umzusetzen. Bei Saltstack legt der Administrator über sogenannte States fest, welche Dienste auf den beteiligten Rechnern installiert sind. Über diesen Mechanismus verwaltet er auch die Konfigurationsdateien und startet und stoppt die installierten Dienste.

Über die SLS-Dateien (SaLt State) steuert der Administrator alle Details der Konfiguration. An oberster Stelle befindet sich als Einstiegspunkt die Datei top.sls, die festlegt, für welche Rechner welche weiteren SLS-Dateien zurate gezogen werden. Wo die Dateien liegen, bestimmt die Einstellung “file_roots” in der Saltstack-Konfiguration in »/etc/salt/master« . Es gibt dafür eine obligatorische Basis-Einstellung »base« und optionale Werte wie »dev« und »prod« für Entwicklung und Produktion. Im Prinzip kann der Administrator hier nach Belieben eigene Namen vergeben, weil diese an anderer Stelle nur als Namen für bestimmte Zustände oder zum Matchen von Servern verwendet werden. Per Default liegen die State-Dateien im Verzeichnis “/srv/salt/”. In diesem Artikel verwenden wir aber ein weiteres Unterverzeichnis, also “/src/salt/states”.

Bei der Verzeichnisstruktur der States selbst und deren Dateinamen ist der Administrator relativ frei. So legt eine Datei namens »webserver.sls« den State “webserver” fest. Befindet sich etwa im Unterverzeichnis “servers” die Datei »ssh.sls« , wird damit der State »servers.ssh« definiert. Heißt die Datei aber »init.sls« , besitzt der resultierende State nur den Namen des Verzeichnisses. Um nun auf dem Rechner “node1” den Apache-Webserver zu installieren, muss »top.sls« die folgenden Zeilen enthalten:

base:
    ‘*’:
      - apache2

Bild 3: Saltstack bringt eine Vielzahl von Modulen für diverse Aufgaben mit; auf einem CentOS-6.5-System sind es knapp 700.

Die Salt-Konfigurationsdateien müssen im YAML-Format (Yet Another Markup Language [3]) abgefasst sein, bei dem es auf die Einrückungstiefe ankommt. Die genaue Anzahl der führenden Leerzeichen ist nicht wichtig, aber Elemente, die auf einer Stufe stehen, müssen mit gleichviel Leerzeichen eingerückt sein, also etwa:

base:
    ‘host1’:
      - postfix
    ‘host2’:     
      - apache2

Hier müssen die beiden Host-Definitionen in einer Spalte stehen, während die Einrückung der jeweiligen Software-Definitionen nicht gleich tief eingerückt sein müssen – sie haben ja auch nichts miteinander zu tun.

Damit sich mit den obigen State-Definitionen auch Software installieren lässt, fehlen noch die entsprechenden State-Dateien für die verwendeten Pakete. Für den Apache-Server kann das folgendermaßen aussehen:

apache2-package:
    pkg:
      - name: apache2
      - installed

Diese Zeilen müssen gemäß den oben beschriebenen Regeln in der Datei »/srv­/salt­/states/apache2.sls« stehen. Die erste Zeile ist eine “ID Declaration”, die einen Bezeichner für den folgenden Zustand angibt. In diesem Fall handelt es sich, wie das Schlüsselwort “pkg” anzeigt, um eine Paketdefinition. Der Name des Pakets, wie er sich im distributionseigenen Paketmanagement wiederfinden muss, ist hinter »name« spezifiziert. Schließlich folgt der angestrebte Zustand des Pakets.

Ein Aufruf von Salt auf dem Server bringt das Programm dazu, den angestrebten Zustand umzusetzen — funktioniert alles wie gewünscht, gibt Salt das aus oder meldet ansonsten, was schiefgelaufen ist:

salt ‘*’ state.highstate

Neben dem Paket benötigt ein Webserver die passende Konfiguration, die Sie ihm über das State-File übergeben können. Nach dem Dateinamen, der hierbei als ID Declaration dient, folgt der Typ der Ressource (hier: “file”) und diverse Attribute, die den State genauer spezifizieren, zum Beispiel seine Abhängigkeiten:

/etc/apache2/sites-enabled/000-default.conf:
    file:
      - managed
      - source:
salt://apache2/default.conf
      - require:
         - pkg: apache2

Die Zeile “source” gibt an, wo die Datei gespeichert ist, die auf den so konfigurierten Server wandern soll. Bei der Installation zeigt Salt als Ergebnis ein Diff-File an, das die Unterschiede zwischen der Original-Datei – sofern vorhanden – und dem neuen File auflistet.

Typischerweise soll eine solche Konfiguration aber nicht für alle Rechner gleich aussehen,sondern sich beispielsweise in Pfadnamen, IP-Adressen und ähnlichen Aspekten unterscheiden. Dafür bietet Saltstack die Möglichkeit, Dateien als Templates zu behandeln, in denen es vor dem Kopieren einzelne Variablen durch Werte ersetzt. Darüber hinaus sind beispielsweise auch Fallunterscheidungen und andere Programmierkonstrukte möglich. Als Template-Syntax unterstützt Saltstack die aus dem Web-Umfeld stammenden Jinja und Mako. Damit Salt eine Datei als Template behandelt, geben Sie den Template-Dialekt als Attribut an:

      file:
         ...
      - template: jinja

Um zum Beispiel die IP-Adresse des Minions in der Konfigurationsdatei zu verwenden, weisen Sie sie im State-File einer Variablen zu:

- context:
      my_ip: {{ salt[‘network.interfaces’]()[‘eth0’][‘inet’][0][‘address’] }}

In der Template-Variablen setzen Sie den Wert dann folgendermaßen ein:

Auf diese Weise lassen sich Konfigurationsdateien etwa zum Aufbau eines Clusters parametrisieren und auf die einzelnen Minions anpassen.

Mit Grains gezielt Clients anpassen

Neben der Identifikation von Client-Rechnern über Namen und Wildcards bietet Saltstack noch einige weitere Möglichkeiten, die in der Praxis nützlich sind. Viele davon sind in der Saltstack-typischen Bildsprache etwas eigentümlich nach Gegenständen benannt, die irgendwie mit Salz zu tun haben, etwa die sogenannten Grains, also Körnchen. Sie stehen für einen bestimmten Aspekt eines Clients, der beim Management als Identifikationsmerkmal dient. Das kann beispielsweise die Betriebssystem- oder Kernel-Version sein, die CPU, die Architektur, die IP-Adresse und viele andere mehr. Grains lassen sich auch nach Bedarf selbst vergeben.

Zum Beispiel ließe sich beim Management eines Glusterfs-Clusters jedem Node ein Grain mit dem Namen “glusternode” zuweisen, um später alle Mitglieder des Verbunds zusammen anzusprechen. Hierfür gibt es mehrere Möglichkeiten. Die Grain-Konfiguration eines Minions ist in der Datei »/etc/salt/grains« gespeichert und kann beispielsweise so aussehen:

roles:
      - glusternode

Hiermit wird ein Grain namens “roles” definiert, das mehrere Rollen umfassen kann, hier aber nur die Rolle “glusternode” enthält. Diese Grain-Konfiguration lässt sich beispielsweise schon bei der Betriebssystem-Installation mit Puppet oder Foreman hinterlegen. Theoretisch kann der Administrator sie auch mit dem folgenden Befehl auf den Client kopieren, wobei die Konfiguration zunächst in der lokalen Datei »grains.txt« gespeichert ist:

salt-cp ‘*’ grains.txt /etc/salt/grains

Dabei landet die Konfiguration wegen des Sternchens auf allen verwalteten Rechnern. Alternativ geben Sie hier die Namen der gewünschten Rechner an. Damit die Minions die neue Konfiguration einlesen, müssen Sie sie neu starten. Auch das geht mit Saltstack selbst:

salt ‘*’ service.restart salt-minion

Jetzt verfügen die entsprechend konfigurierten Minions über die Rolle »glusternode« , wovon Sie sich so überzeugen können:

salt -G ‘roles:glusternode’ grains.item roles

Dieser Befehl verifiziert die Konfiguration gewissermaßen doppelt, denn zum ersten verwendet er schon zur Identifizierung mit -G das Grain “roles” und zeigt dann noch einmal den Inhalt dieses Grains mit »grains.item roles« an. Alle vorhandenen Grains zeigt »grains.ls« beziehungsweise »grains.items« .

Bild 4: Mit der passenden Konfiguration lassen sich Glusterfs-Knoten mit einem Befehl installieren.

Weil die Zuweisung von Rollen aber eine sinnvolle und entsprechend oft benutzte Operation ist, bietet Saltstack für die obige Prozedur eine Abkürzung in Form des Befehls »grains.setval« , den Sie zum Setzen der Rolle folgendermaßen verwenden:

salt ‘*’ grains.setval roles [‘glusternode’]

Um auf den so vorbereiteten Minions die Glusterfs-Software zu installieren, konfigurieren Sie das passende Paket wie im Apache-Beispiel wie im Listing “glusterfs/server.sls”.

glusterfs-package:
    pkg:
      - name: glusterfs-server
      - installed
glusterfs-service:
    service:
      {% if grains[‘os’] == ‘CentOS’ %}
      - name: glusterd
      {% else %}
      - name: glusterfs-server
      {% endif %}
      - running
      - enable: True

Neben der schon bekannten Struktur für Paketinstallation und Service ist hier zu sehen, wie man damit umgeht, dass die Pakete beziehungsweise Dienste auf unterschiedlichen Linux-Distributionen andere Namen haben. Wieder kommt die Jinja2-Template-Syntax zum Einsatz, um über ein Grain das zugrunde liegende Betriebssystem abzufragen. Ist es CentOS, verwendet Saltstack als Namen für den Dienst “glusterd”, ansonsten “glusterfs-server”. Auf diese Weise lässt sich die Salt-stack-Konfiguration plattformübergreifend modularisieren.

Ein Eintrag in »top.sls« weist den Glusternodes per Grain ihre Konfiguration zu:

base:
    ‘roles:glusternode’:
      - match: grain
      - glusterfs.server

Ist alles vorbereitet, installiert der oben beschriebene Highstate-Aufruf die Pakete und startet anschließend die Dienste auf den Glusterfs-Knoten. Statt pauschal den Highstate aufzurufen, der möglicherweise eine Vielzahl von Zuständen überprüft, können Sie den spezifischen State mit folgendem Befehl herbeiführen. Dazu muss der State nicht in »top.sls« eingetragen sein:

salt ‘*’ state.sls glusterfs.server

Das Ergebnis ist in Bild 4 zu sehen. Die Installation der Pakete setzt natürlich voraus, dass die passenden Paket-Repositories konfiguriert sind. Ist das noch nicht passiert, können Sie es mit Hilfe von Saltstack und dessen Modul “salt.states.pkgrepo” nachholen. Das Gleiche gilt für die Firewall-Konfiguration, die Sie über Saltstack mit dem Modul “iptables” anpassen. Mehr dazu verrät »salt ‘*’ sys.doc iptables« .