# Salt Stack Deep Dive: Das Gehirn der SUSE-Automatisierung

TL;DR / Management Summary Während Ansible (Push-Modell) oft für kleine Flotten genutzt wird, ist Salt (Pull-Modell via Agent) die strategische Wahl von SUSE. Es ist der technische Unterbau des SUSE Managers und ermöglicht die Verwaltung von tausenden Servern in Millisekunden. Wer Salt unter SLES beherrscht, kann Zustände erzwingen (Idempotenz), Befehle parallel auf ganze Rechenzentren verteilen und komplexe Infrastrukturen als Code (SLS-Dateien) definieren.

# 1. Einführung & Architektur

Master, Minion und der Bus.

Salt nutzt ein Agenten-basiertes Modell. Ein zentraler Master sendet Befehle über einen hochperformanten ZeroMQ-Bus an die Minions (Agenten) auf den Servern.

# Die Kommunikation (Mermaid)

graph TD
    A[Salt Master: /srv/salt/] -->|ZeroMQ Port 4505/4506| B[Minion: Node A]
    A -->|ZeroMQ| C[Minion: Node B]
    A -->|ZeroMQ| D[Minion: Node C]
    B -->|Return Data| A
    C -->|Return Data| A
    subgraph "States & Data"
        E[SLS Files] --> A
        F[Grains: Host Info] --> B
        G[Pillar: Secrets] --> A
    end

# 2. Erste Schritte: Master & Minion

Die Infrastruktur aufbauen.

# Schritt 1: Pakete installieren

# Auf dem Master
sudo zypper install salt-master
sudo systemctl enable --now salt-master

# Auf dem Minion (Zielserver)
sudo zypper install salt-minion

# Schritt 2: Minion anbinden

Datei: /etc/salt/minion

master: salt-master.company.local

Starten: sudo systemctl enable --now salt-minion.

# Schritt 3: Key-Exchange (Vertrauen)

Auf dem Master muss der Schlüssel des neuen Minions akzeptiert werden:

sudo salt-key -L # Zeige wartende Keys
sudo salt-key -a node-a # Akzeptieren

# 3. Salt States (SLS): Der Zielzustand

Programmieren statt Tippen.

Ein State beschreibt, wie ein System aussehen soll.

# Beispiel: /srv/salt/webserver.sls

install_apache:
  pkg.installed:
    - name: apache2

start_apache:
  service.running:
    - name: apache2
    - enable: True
    - watch:
      - pkg: install_apache

# Ausführen des States

sudo salt 'web*' state.apply webserver

# 4. Day-2 Operations: Grains & Pillar

Informationen und Geheimnisse.

• Grains: Informationen, die der Minion über sich selbst weiß (OS-Version, CPU, IP). salt '*' grains.item osfullname
• Pillar: Daten, die der Master dem Minion zuteilt (Passwörter, API-Keys). Pillar-Daten sind für andere Minions nicht sichtbar!

# 5. Troubleshooting & “War Stories”

Wenn der Bus hakt.

# Story 1: “Der hängende Minion”

Symptom: Ein salt '*' test.ping liefert für manche Server keine Antwort, obwohl die VM läuft. Ursache: Der Minion hat die Verbindung zum Master verloren (oft durch IP-Wechsel oder Firewall-Änderungen) und der Reconnect-Timer ist abgelaufen. Lösung: systemctl restart salt-minion. Prävention: Nutzen Sie Grains, um Minions nach Regionen zu filtern und stellen Sie sicher, dass Port 4505/4506 bidirektional offen sind.

# Story 2: “Das Pillar-Sicherheitsloch”

Symptom: Ein Junior-Admin hat ein Passwort in ein SLS-File (State) geschrieben, das für alle User lesbar war. Ursache: Verwechslung von States und Pillars. States landen auf dem Minion-Dateisystem, Pillars bleiben im Speicher. Lösung: Nutzen Sie für alle sensiblen Daten ausschließlich Pillar und verschlüsseln Sie diese in Git via GPG oder nutzen Sie HashiCorp Vault als Backend für Salt.

# 6. Fazit & Empfehlung

• Skalierung: Salt ist die erste Wahl für Infrastrukturen > 100 Server.
• SUSE Manager: Wenn Sie Salt nutzen, ist der SUSE Manager die perfekte GUI-Ergänzung zur Visualisierung.
• Best Practice: Nutzen Sie den “Top-File” (/srv/salt/top.sls), um Rollen automatisch an Server-Gruppen zuzuweisen.

# Anhang: Cheatsheet