Bash-Skript oder Ansible: So entscheidest du richtig
Einmalige Aufgaben auf einem Host: Bash. Wiederkehrende Zustände auf vielen Hosts: Ansible. Die Grenze verläuft nicht bei der Zeilenzahl, sondern bei der Frage, ob dein Skript ein zweites Mal ohne Schaden laufen darf.
Warum die Frage in fast jedem Team irgendwann auftaucht
Am Anfang steht meistens ein kleines Skript. Es legt einen Benutzer an, kopiert eine Konfigurationsdatei nach /etc, startet einen Dienst neu und schreibt eine Zeile ins Log. Das funktioniert, solange es um einen Server geht und solange derjenige, der es geschrieben hat, noch im Haus ist. Sobald zehn oder zwanzig Systeme dazukommen, wächst um dieses Skript herum eine Sammlung aus Schleifen über Hostlisten, ssh-Aufrufen, scp-Kopien und Sonderfällen für Debian und RHEL.
Der eigentliche Bruch kommt nicht durch die Anzahl der Server, sondern durch die Wiederholung. Ein typisches Bash-Skript beschreibt Schritte, kein Zielbild. Ein zweiter Durchlauf hängt deshalb eine Zeile erneut an eine Konfigurationsdatei an, ein abgebrochener Lauf hinterlässt einen halb konfigurierten Host, und niemand kann verlässlich sagen, welcher Server gerade in welchem Zustand ist. Fehlerbehandlung mit set -euo pipefail, trap und sauberen Rückgabewerten ist möglich, aber sie muss in jedem Skript neu gebaut werden.
Typische Fehler gehen in beide Richtungen. Manche Teams schleppen jahrelang gewachsene Skriptsammlungen mit, in denen sed-Aufrufe auf Konfigurationsdateien die eigentliche Logik sind. Andere führen Ansible ein und schreiben dann Playbooks, die im Wesentlichen aus command- und shell-Tasks bestehen. Beides kostet mehr, als es bringt. Die Entscheidung sollte an der Aufgabe hängen, nicht an der Vorliebe.
Entscheidungskriterien im Überblick
- 01 Einmalig oder wiederkehrend
- 02 Ein Host oder viele Hosts
- 03 Ablauf oder Sollzustand
- 04 Eine Distribution oder gemischt
- 05 Wer pflegt es in zwei Jahren
Die Kriterien, an denen du die Entscheidung festmachst
Es gibt keinen festen Schwellenwert an Servern, ab dem Ansible zwingend wird. Es gibt aber ein paar Eigenschaften einer Aufgabe, die ziemlich zuverlässig zeigen, in welche Richtung du gehen solltest.
Einmaliger Ablauf oder dauerhafter Sollzustand
Ein Backup-Job, eine Auswertung von Logdateien oder eine Migration, die genau einmal läuft, ist in Bash gut aufgehoben. Sobald du einen Zustand beschreibst, der über Monate gleich bleiben soll, etwa installierte Pakete, Benutzer, sudo-Regeln und Dienste, gewinnt ein deklaratives Werkzeug.
Idempotenz, konkret gedacht
Idempotent heißt: Der zweite Lauf ändert nichts mehr. Ansible-Module wie lineinfile, template, package oder service prüfen den Ist-Zustand und melden changed oder ok zurück. In Bash musst du das mit grep -q, Prüfungen auf Dateiexistenz und Vergleichen selbst nachbauen, und genau diese Prüfungen fehlen erfahrungsgemäß zuerst.
Rückmeldung und Nachvollziehbarkeit
Ansible liefert dir pro Host und Task ein Ergebnis, kennt --check und --diff für einen Trockenlauf und bricht bei Fehlern kontrolliert ab. Ein Skript sagt dir im Zweifel nur, dass es fertig ist. Wenn du gegenüber Audit oder Betrieb belegen musst, was auf welchem System passiert ist, ist das ein starkes Argument.
Heterogene Systeme und Wiederverwendung
Sobald du Debian, RHEL und SLES gleichzeitig bedienst, sammeln sich in Bash Fallunterscheidungen für apt, dnf und zypper. Ansible abstrahiert das über Module und Facts, und Rollen lassen sich mit Variablen und Templates für mehrere Umgebungen wiederverwenden, statt für jede Umgebung eine Skriptkopie zu pflegen.
Der Weg dorthin ist kein Bruch
Du musst nichts wegwerfen. Ein sinnvoller erster Schritt ist ein Inventory mit Gruppen, dann eine Rolle für den Standard-Grundzustand eines Servers, danach ziehst du Skript für Skript nach. Bestehende Skripte kannst du übergangsweise über das script-Modul einbinden und später durch echte Module ersetzen.
Bash bleibt trotzdem Pflicht
Auch mit Ansible schreibst du weiter Shell-Code, in Jinja2-Templates, in kleinen Helfern, in systemd-Units und in CI-Pipelines. Wer Umleitungen, Quoting, Exit-Codes und Prozessverwaltung nicht sicher beherrscht, produziert auch in Playbooks unsaubere Tasks.
Kurse zu Automatisierung mit Bash und Ansible bei cmt
Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.
Teste dich und finde deinen Weg
Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.
Häufige Fragen zu Automatisierung mit Bash und Ansible
Noch etwas offen? Wir sind ohne Warteschleife für dich da.
Frag uns direktAb wie vielen Servern lohnt sich Ansible?
Was bedeutet Idempotenz bei Ansible praktisch?
Braucht Ansible einen Agenten auf den Zielsystemen?
Ist Ansible langsamer als ein Shell-Skript?
Welcher cmt-Kurs passt zu welcher Seite der Entscheidung?
Zuletzt geprüft am 26. Juli 2026.
Verwandte Linux-Themen
Alle Linux-Themen im ÜberblickEchte Stimmen aus unseren IT-Kursen
Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Trainer gut und verständlich. Unterlagen nur zum lesen (keine Kopierfunktion). Wissenstransfer erfolgreich.
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.
Du willst die Entscheidung nicht allein treffen?
Sag uns, wie viele Systeme du betreust und was heute schon skriptgesteuert läuft. Wir sagen dir ehrlich, ob ein Shell-Kurs oder der Einstieg in Ansible der sinnvollere nächste Schritt ist. Alle Kurse finden in Präsenz oder Live-Online statt, auf Wunsch auch als Firmenschulung mit deinen eigenen Playbooks und Skripten.