# Salt Formulas Masterclass: Professionelle Baukästen für die IT

TL;DR / Management Summary Wer komplexe Dienste wie einen PostgreSQL-Cluster oder ein SAP HANA-System manuell mit Salt-States schreibt, verschwendet Zeit. Salt Formulas sind wiederverwendbare, vorkonfigurierte State-Sammlungen (vergleichbar mit Ansible Roles). Sie folgen einem strikten Schema, sind hochgradig anpassbar via Pillar-Daten und werden von SUSE für viele Enterprise-Anwendungen offiziell bereitgestellt und gewartet.

# 1. Einführung & Architektur

Warum Formulas statt einfacher States?

Formulas trennen die Logik (Was wird getan?) von den Daten (Wie heißt der Host?). Sie nutzen intensiv Jinja2-Templates und das map.jinja Pattern, um zwischen verschiedenen OS-Versionen zu unterscheiden.

# Die Formula-Struktur (Mermaid)

graph TD
    A[Salt Master] --> B[Formula: nginx]
    B --> C[metadata.yml: Info]
    B --> D[map.jinja: Variables]
    B --> E[init.sls: Logic]
    F[User Pillar Data] --> D
    D --> E
    E -->|Applied to| G[Minion: Web Server]

# 2. SUSE Formulas nutzen

Zertifizierte Qualität.

SUSE liefert für den SUSE Manager und SLES viele Formulas fertig mit.

# Installation

# Beispiel: Formula für PostgreSQL
sudo zypper install salt-formulas-postgresql

Die Dateien landen unter /usr/share/salt-formulas/states/. Sie müssen sie in Ihren File-Server-Pfad (/srv/salt/) verlinken oder dort inkludieren.

# 3. Die Macht von map.jinja

Einen Standard für alle Distros.

Ein Senior Admin schreibt Formulas so, dass sie auf SLES 12, SLES 15 und openSUSE laufen.

# Beispiel: map.jinja

{% set apache = salt['grains.filter_by']({
    'Suse': {
        'package': 'apache2',
        'service': 'apache2',
        'config': '/etc/apache2/httpd.conf',
    },
    'RedHat': {
        'package': 'httpd',
        'service': 'httpd',
        'config': '/etc/httpd/conf/httpd.conf',
    },
}, merge=salt['pillar.get']('apache:lookup')) %}

# 4. Day-2 Operations: Customizing via Pillar

Anpassen ohne Code-Änderung.

Sie ändern niemals die Formula-Dateien selbst. Sie steuern das Verhalten ausschließlich über Pillar-Daten.

# Beispiel: Pillar für eine MariaDB Formula

# /srv/pillar/db.sls
mariadb:
  root_password: "supersecret"
  databases:
    - myapp_db
  users:
    - name: appuser
      password: "userpass"

# 5. Troubleshooting & “War Stories”

Wenn die Formel nicht aufgeht.

# Story 1: “Der Namespace-Crash”

Symptom: Ein Admin hat zwei verschiedene Formulas für mysql installiert (eine von SUSE, eine von GitHub). Salt wirft Fehler beim Laden der States. Ursache: Identische Namen in der top.sls. Salt weiß nicht, welche mysql.sls es laden soll. Lösung: Nutzen Sie Verzeichnisse als Namespaces (z.B. mysql-suse und mysql-community) oder nutzen Sie die SUSE-Manager-GUI, die diese Konflikte visualisiert.

# Story 2: “Das veraltete Metadata-File”

Symptom: In der SUSE Manager GUI wird eine neu installierte Formula nicht angezeigt oder wirft Validierungsfehler. Ursache: Das metadata.yml File der Formula ist ungültig oder passt nicht zum erwarteten Schema der GUI. Lösung: Prüfen Sie das File mit einem YAML-Linter. Achten Sie besonders auf die Einrückungen bei den form Definitionen.

# 6. Fazit & Empfehlung

• Zuerst suchen: Bevor Sie einen Dienst automatisieren, prüfen Sie auf GitHub (SaltStack-Formulas), ob es bereits eine gepflegte Formula gibt.
• Wartbarkeit: Formulas sind die einzige Methode, um Automatisierungs-Code über Jahre hinweg im Team wartbar zu halten.
• Wahl: Nutzen Sie SUSE-eigene Formulas für Core-Dienste (HA, SAP, Storage), um Support zu erhalten.

# Anhang: Cheatsheet