# Salt (SaltStack): High-Speed Management für massive Infrastrukturen

TL;DR / Management Summary Während Ansible (Artikel 793) agentenlos und eher langsam arbeitet, setzt Salt (früher SaltStack) auf eine permanente Master-Minion-Architektur. Durch den Einsatz von ZeroMQ ist Salt extrem schnell und kann zehntausende Server in Sekunden verwalten. Ein Senior Admin nutzt Salt für Event-Driven Automation: Die Infrastruktur reagiert selbstständig auf Ereignisse (z.B. “Webserver-Last hoch -> Salt startet neue Proxmox-VM”).

# 1. Architektur: Der Master und seine Minions

Echtzeit-Kommunikation.

1. Salt Master: Die Zentrale. Er schickt Befehle und speichert die Konfigurationen (States).
2. Salt Minion: Der Agent auf jedem Server. Er hält eine permanente TCP-Verbindung zum Master.
3. ZeroMQ: Der Hochleistungs-Bus, über den die Nachrichten fließen.

# 2. Grundbegriffe: Grains & Pillars

Daten über den Host.

• Grains: Statische Informationen, die der Minion vom System sammelt (OS-Version, RAM, CPU-Modell).
  • Nutzen: “Führe Update nur auf allen Debian-Systemen aus”.
• Pillars: Sensible Daten, die der Master dem Minion zuteilt (Passwörter, Keys).
  • Vorteil: Nur der berechtigte Minion kann seinen Pillar sehen.

# 3. Deep Dive: Salt States (SLS)

Definition des Soll-Zustands.

In Salt beschreiben wir Zustände in SLS-Dateien (YAML).

# /srv/salt/webserver.sls
apache2:
  pkg.installed: []
  service.running:
    - enable: True
    - watch:
      - file: /etc/apache2/ports.conf

/etc/apache2/ports.conf:
  file.managed:
    - source: salt://configs/apache_ports.conf

• Watch-Mechanismus: Wenn die Datei sich ändert, startet Salt den Dienst automatisch neu.

# 4. Day-2 Operations: Remote Execution

Befehle an tausende Server.

Salt ist unschlagbar bei Ad-hoc Aufgaben:

# Zeigt den freien Speicherplatz auf ALLEN Servern weltweit (in < 1 Sekunde)
salt '*' disk.usage

# Installiert ein Paket auf allen 'Minions' in der Gruppe 'Marketing'
salt -G 'dept:marketing' pkg.install htop

# 5. Troubleshooting & “War Stories”

Wenn die Minions schweigen.

# Top 3 Fehlerbilder

1. Symptom: Minion meldet sich nicht beim Master.

   • Ursache: Firewall blockiert Ports TCP 4505 & 4506.
   • Lösung: OPNsense Regeln prüfen (Artikel 553).

2. Symptom: “Minion Key rejected”.

   • Ursache: Der Public-Key des neuen Minions wurde am Master noch nicht akzeptiert.
   • Fix: salt-key -a <minion_id>.

3. Symptom: High CPU Last am Master.

   • Ursache: Zu viele Events im Bus (Event-Storm).

# “War Story”: Der “Selbstheilende” Fileserver

Ein Admin konfigurierte einen Salt-Reaktor (Beacons/Reactor). Das Ereignis: Ein User löschte versehentlich die Konfigurationsdatei des zentralen Samba-Servers. Das Ergebnis: Der Salt-Minion bemerkte die Änderung am Dateisystem innerhalb von Millisekunden (Beacon) und meldete dies dem Master. Der Master schickte sofort den ursprünglichen Zustand zurück (Reactor). Lehre: Mit Salt können Sie Infrastrukturen bauen, die sich innerhalb von Sekunden selbst reparieren, ohne dass ein Mensch eingreifen muss.

# 6. Monitoring & Reporting

Dashboarding.

# Salt-GUI (Enterprise) / Salt-API

Nutzen Sie die REST-API von Salt, um Statusdaten in Ihr Grafana (Artikel 698) zu integrieren.

• KPI: minion_last_seen. (Warnt, wenn ein Agent offline geht).

# 7. Fazit & Empfehlung

Wählen Sie Salt, wenn Sie Skalierbarkeit und Echtzeit-Reaktion benötigen.

• Empfehlung: Nutzen Sie Salt für Umgebungen mit > 500 Servern.
• Wichtig: Sichern Sie den Salt-Master besser als Ihr AD. Wer den Master kontrolliert, hat Root-Zugriff auf jedes verbundene System.

# Anhang: Cheatsheet (Salt CLI)

# Referenzen

• SaltStack Documentation (VMware)
• SaltStack Best Practices Guide
• Introduction to Event-Driven Infrastructure