Ansible vs. Chef vs. SaltStack: Configuration Management im Vergleich 2026

Infrastruktur manuell zu konfigurieren war gestern. Configuration Management Tools sorgen dafür, dass Server reproduzierbar, konsistent und automatisch in den gewünschten Zustand gebracht werden. Die drei populärsten Open-Source-Vertreter: Ansible, Chef und SaltStack. Dieser Vergleich zeigt, wann welches Tool die bessere Wahl ist.

Was ist Configuration Management?

Configuration Management (CM) beschreibt den Prozess, Serverkonfigurationen als Code zu verwalten ("Infrastructure as Code"), sodass:

  • Server idempotent in einen definierten Zustand gebracht werden
  • Konfigurationen versioniert und nachvollziehbar sind (Git)
  • Drift erkannt wird (manuelle Änderungen fallen auf)
  • Skalierung auf hunderte oder tausende Server möglich wird

CM-Tools sind eng verwandt mit IaC-Tools wie Terraform oder Pulumi – aber während Terraform Ressourcen provisioniert, kümmern sich CM-Tools um die Softwarekonfiguration der bereits laufenden Systeme.

Ansible: Agentless und YAML-first

Ansible wurde 2012 von Michael DeHaan entwickelt und 2015 von Red Hat (jetzt IBM) übernommen. Es ist das mit Abstand populärste CM-Tool der Welt.

Kerneigenschaften

  • Agentless: Kein Agent auf den Ziel-Hosts nötig – nur SSH (oder WinRM für Windows)
  • Push-Modell: Der Control-Node pushed Änderungen aktiv zu den Hosts
  • YAML-basiert: Playbooks in YAML geschrieben, geringe Lernkurve
  • Idempotent: Mehrfaches Ausführen erzeugt dasselbe Ergebnis

Ansible-Konzepte

# Ansible Playbook: Nginx installieren und konfigurieren
---
- name: Setup Webserver
  hosts: webservers
  become: true  # sudo

  vars:
    nginx_port: 80

  tasks:
    - name: Install nginx
      ansible.builtin.package:
        name: nginx
        state: present

    - name: Deploy nginx config
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
        owner: root
        group: root
        mode: '0644'
      notify: Restart nginx

    - name: Ensure nginx is running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

Inventory (welche Hosts werden verwaltet):

# inventory.ini
[webservers]
web01 ansible_host=192.168.1.10
web02 ansible_host=192.168.1.11

[databases]
db01 ansible_host=192.168.1.20 ansible_user=dbadmin

[production:children]
webservers
databases

Ansible-Ökosystem

  • Ansible Galaxy: Community-Rollen (Nginx, PostgreSQL, Docker) sofort einsetzbar
  • Ansible Collections: Modulare Pakete mit Modulen, Rollen, Playbooks
  • AWX/Tower: Web-UI und Scheduling (AWX = Open Source, Tower = Enterprise)
  • Ansible Lint: Linter für Best Practices
  • Molecule: Testing-Framework für Rollen

Ansible in der Praxis: Stärken und Schwächen

Stärken:

  • Niedrigste Einstiegshürde (YAML + SSH = fertig)
  • Keine dauerhafte Agent-Infrastruktur nötig
  • Ideal für Ad-hoc-Tasks und One-Shot-Automation
  • Riesige Community, tausende vorgefertigte Rollen

Schwächen:

  • Performance bei großen Flotten (500+ Hosts): Langsam durch sequenzielles SSH
  • Kein echter State: Ansible weiß nicht was zuletzt gemacht wurde
  • Fehlerbehandlung in komplexen Playbooks wird unübersichtlich
  • Pull-Modell nicht nativ (obwohl möglich mit Cron + ansible-pull)

Chef: Ruby-based, Enterprise-fokussiert

Chef (jetzt Teil von Progress Software) wurde 2009 von Adam Jacob entwickelt und war jahrelang der Standard in großen Enterprise-Umgebungen. Es ist in Ruby geschrieben und nutzt eine DSL auf Ruby-Basis.

Kerneigenschaften

  • Agent-basiert: Chef-Client auf jedem Node als Daemon
  • Pull-Modell: Nodes ziehen ihre Konfiguration periodisch vom Chef-Server
  • Ruby-DSL: Cookbooks in Ruby geschrieben (Lernkurve für Nicht-Rubyisten)
  • Idempotent: Ressource-basiertes Modell mit converge-Phase

Chef-Konzepte

# Chef Recipe: Nginx installieren
package 'nginx' do
  action :install
end

template '/etc/nginx/nginx.conf' do
  source 'nginx.conf.erb'
  owner 'root'
  group 'root'
  mode '0644'
  notifies :restart, 'service[nginx]', :delayed
end

service 'nginx' do
  action [:enable, :start]
end

Chef-Infrastruktur:

┌─────────────────┐    pull      ┌─────────────────┐
│   Chef Server   │ ◄────────── │   Chef Client   │
│  (Konfiguration │    (Node)    │ (auf jedem Host) │
│     zentral)    │              └─────────────────┘
└─────────────────┘
        │
        │ Verwaltet
        ▼
┌─────────────────┐
│  Cookbooks,     │
│  Roles,         │
│  Data Bags      │
└─────────────────┘

Chef-Stärken und Schwächen

Stärken:

  • Mature und battle-tested für sehr große Flotten (100.000+ Nodes)
  • Test Kitchen: Erstklassiges Test-Framework für Cookbooks
  • InSpec: Compliance-as-Code direkt integriert
  • Habitat: Anwendungspaketierung (wie Nix/Flatpak)

Schwächen:

  • Hohe Lernkurve durch Ruby-DSL
  • Komplexe Infrastruktur: Chef Server braucht eigene Wartung
  • Kleinere Community als Ansible (Abwanderung seit ~2018)
  • Lizenzänderungen: Chef Infra wurde 2019 vollständig Open Source (Apache 2.0) – aber das Misstrauen bleibt

SaltStack: Schnell, skalierbar, eventbasiert

SaltStack (kurz: Salt) wurde 2011 von Thomas Hatch entwickelt und 2020 von VMware übernommen (heute wieder eigenständig unter Broadcom, aber als Open-Source via Salt Project aktiv). Salt ist in Python geschrieben.

Kerneigenschaften

  • Agent-basiert: Salt-Minion auf jedem Node
  • Pull- und Push-Modell: Beides nativ unterstützt
  • ZeroMQ: Hochperformante Nachrichtenwarteschlange für Master-Minion-Kommunikation
  • Event-Bus: Reaktive Automation auf Basis von Events
  • Python-DSL: State-Files in YAML oder Python

SaltStack-Konzepte

# Salt State: Nginx installieren
nginx:
  pkg.installed: []
  service.running:
    - enable: True
    - require:
      - pkg: nginx

/etc/nginx/nginx.conf:
  file.managed:
    - source: salt://nginx/files/nginx.conf
    - template: jinja
    - user: root
    - group: root
    - mode: 644
    - watch_in:
      - service: nginx

Salt-Reaktion auf Events:

# reactor.conf: Automatisch reagieren wenn neuer Minion aufkommt
reactor:
  - 'minion/start':
    - /srv/reactor/auto-accept.sls

  - 'salt/cloud/*/created':
    - /srv/reactor/setup-new-server.sls

Remote-Execution (killer feature):

# Direkter Befehl an alle Webserver-Nodes
salt 'web*' cmd.run 'systemctl restart nginx'

# Software-Version prüfen
salt '*' pkg.version nginx

# Disk-Nutzung auf allen Nodes
salt '*' disk.usage

SaltStack-Stärken und Schwächen

Stärken:

  • Sehr schnell bei großen Flotten (ZeroMQ, parallele Ausführung)
  • Echtzeit-Feedback via Event-Bus (kein Polling nötig)
  • Granular: Remote Execution direkt aus CLI
  • Reaktive Automation: Events triggern States automatisch
  • Gut skalierbar: Getestet mit 100.000+ Minions

Schwächen:

  • Komplexe Architektur: Master, Minions, ZeroMQ müssen betrieben werden
  • Lernkurve: State-System und Jinja-Templates sind komplex
  • VMware/Broadcom-Unsicherheit: Ownership-Wechsel hat Community verunsichert
  • Dokumentation: Weniger gut strukturiert als Ansible

Direkter Vergleich

Kriterium Ansible Chef SaltStack
Architektur Agentless (SSH) Agent + Server Agent + Master
Modell Push Pull Push + Pull
Sprache YAML (Jinja2) Ruby DSL YAML / Python
Lernkurve Niedrig ⭐ Hoch Mittel
Performance (500+ Hosts) Mittel Hoch Sehr hoch
State-Management Begrenzt Ja Ja
Event-basierte Automation Nein Begrenzt Ja ⭐
Windows-Support Gut Gut Gut
Community-Größe Sehr groß ⭐ Klein Mittel
Vorgefertigte Inhalte Galaxy (riesig) Supermarket Formulas
Testsuite Molecule Test Kitchen ⭐ Nein (Testsalt via Pytest)
Compliance Begrenzt InSpec ⭐ Nein
Lizenz GPLv3 / Community Apache 2.0 Apache 2.0
Bestes für Ad-hoc, kleine Teams Enterprise-Compliance Große, event-driven Flotten

Wann welches Tool?

Ansible wählen wenn:

  • Dein Team keine Ruby- oder Python-Expertise hat
  • Du schnell starten willst (SSH + YAML reicht)
  • Ad-hoc-Automation und Playbooks für eine überschaubare Infrastruktur
  • Kein dauerhafter Agent-Betrieb gewünscht wird
  • Du Kubernetes und Cloud-Provider via Collections verwaltest

Idealfall: Startup, KMU, 10-200 Server, gemischte Skills im Team

Chef wählen wenn:

  • Enterprise-Compliance via InSpec unverzichtbar ist
  • Dein Team Ruby-Kenntnisse hat
  • Du Test Kitchen für erstklassiges Cookbook-Testing brauchst
  • Langfristige Wartbarkeit von Konfigurationslogik wichtig ist

Idealfall: Enterprise, stark reguliertes Umfeld (Banking, Healthcare), 200-5000 Nodes

SaltStack wählen wenn:

  • Sehr große Flotten (500+ Nodes) schnell reagieren müssen
  • Event-basierte Reaktion auf Infrastructure-Changes gebraucht wird
  • Du Remote-Execution als primäres Feature nutzen willst
  • Python-Expertise im Team vorhanden ist

Idealfall: Große Infra-Teams, Cloud-Provider, Telekommunikation, 1000+ Nodes

Kombinationen in der Praxis

Viele Teams kombinieren Tools:

  • Terraform + Ansible: Terraform provisioniert, Ansible konfiguriert (sehr verbreitet)
  • Ansible + Chef: Ansible für Bootstrapping, Chef für tägliche Drift-Korrektur
  • SaltStack + Kubernetes: Salt für Bare-Metal-Nodes, Helm/Flux für K8s

Fazit: Ansible dominiert – aus gutem Grund

Für 2026 ist die Empfehlung klar:

Ansible ist der Standard für die meisten Anwendungsfälle. Die niedrige Einstiegshürde, die riesige Community, die exzellente Integration mit Cloud-Providern, Kubernetes und modernen CI/CD-Pipelines machen es zum Go-to-Tool.

Chef ist nur noch dann erste Wahl, wenn InSpec für Compliance unverzichtbar ist und ein Ruby-affines Team existiert – sonst hat die Community-Abwanderung zu Ansible zu starke Spuren hinterlassen.

SaltStack bleibt relevant für sehr große Infrastrukturen mit event-driven Anforderungen – aber die Ownership-Wechsel und die schrumpfende Community machen einen Neueinstieg 2026 riskant. Als Alternative bietet sich Pulumi (programmierbar) oder Ansible mit AWX an.

Kurzempfehlung:

  • 🟢 Standard-Wahl, Teams aller Größen → Ansible
  • 🟡 Enterprise-Compliance, Ruby-Teams → Chef (inkl. InSpec)
  • 🟡 10.000+ Nodes, Event-driven → SaltStack (mit Vorsicht)

Weiterführende Artikel

Verwandte Technologien im Techradar