Die Verwaltung von IT-Landschaften wird immer komplexer - die explosionsartige Vermehrung mobiler Clients ist nur eine der vielen Erschwernisse. Zeit also für ... (mehr)

Pillars schützen sensible Daten

Weil State-Daten prinzipiell allen konfigurierten Clients zur Verfügung stehen, sollten Sie darin am besten keine sensiblen Daten speichern. Dafür haben die Entwickler das sogenannte Pillar-System vorgesehen, das über solche Daten auf dem Salt-Server wacht. Außerdem sind die Pillars dafür gedacht, an zentraler Stelle globale Einstellungen zu speichern, die für alle Clients gelten.

Für Pillars gibt es in Saltstack auf dem Master einen eigenen Ablageort, der in der Konfiguration mit “pillar_roots” bestimmt wird. In unserem Beispiel ist es – im Gegensatz zur Saltstack-Dokumentation – das Verzeichnis “/srv/salt/pillar”, sodass States und Pillars unterhalb von “/srv/salt” angesiedelt sind. Die Pillars lassen sich wie die States in verschiedene Environments unterteilen, um etwa für Entwicklung und produktives Deployment unterschiedliche States oder Variablen zu verwenden. Mit Pillars kann der Administrator die Paketnamen des Apache-Webservers je nach Betriebssystem unterscheiden:

{% if grains[‘os’] == ‘CentOS’ %}
webserver: httpd
{% elif grains[‘os’] == ‘Ubuntu’ %}
webserver: apache2
{% endif %}

Damit steht der so definierte Pillar zur Verwendung in der State-Konfiguration zur Verfügung, etwa so:

webserver:

    pkg:
      - installed
      - name: {{ pillar[‘webserver’] }}

Diese Datei speichern Sie beispielsweise als »/srv/salt/pillar/packages.sls« und binden sie in der Top-Level-Datei »/srv/salt/pillar­/top.sls« wie bei der State-Konfiguration ein. Einen Überblick über die Architektur von Saltstack, in der States, Grains und Pillars zu sehen sind, gibt Bild 5.

Bild 5: Die Saltstack-Architektur: Grains identifizieren die Merkmale der Clients (Minions), während States und Pillars auf dem Master deren Konfiguration festlegen.

Fazit

Mit Saltstack steht ein weiteres freies Tool für das Konfigurationsmanagement von Rechnern zur Verfügung, das in Konkurrenz zu Puppet tritt. Durch seine Architektur eignet es sich auch für Umgebungen mit mehreren Tausend Clients. Allerdings verwendet auch Salt eine Vielzahl von Konzepten, was die Einarbeitung in das Tool erschwert. Gerade wer Konfiguration und Templates parametrisieren möchte, kommt um eine intensive Beschäftigung mit Saltstack nicht herum.

Die richtige Strukturierung der Konfiguration ist nicht ganz einfach und zum Teil auch Geschmackssache. Als Best Practice empfehlen die Entwickler, Variablen soviel wie nötig einzusetzen, um etwa zwischen verschiedenen Linux-Distributionen zu unterscheiden, es aber damit nicht zu übertreiben, genauso wie mit der Modularisierung der Salt-States.

Link-Codes

[1] Saltstack: http://www.saltstack.com/

[2] Saltstack-Module: http://docs.saltstack.com/en/latest/ref/modules/all/index.html

[3] YAML: http://www.yaml.org/

comments powered by Disqus
Mehr zum Thema

Automatisieren mit SaltStack

In komplexen IT-Umgebungen ist Automatisierung das sprichwörtliche Salz in der Suppe. Nicht nur Puppet, Chef und Ansible bieten sich dafür an, auch mit SaltStack steht eine leistungsfähige Software bereit. Für Furore sorgte dabei im vergangenen Herbst die Ankündigung von VMware, SaltStack zu übernehmen. In diesem Beitrag stellen wir SaltStack vor und beantworten die Frage, worauf sich Nutzer in Zukunft einstellen dürfen und müssen.
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023