DevOps & Automatisierung

Ansible Einstieg für Admins: von der Handarbeit zum reproduzierbaren Playbook

Der Einstieg ist unspektakulär: Inventar, ein Playbook, ein paar Rollen, fertig. Der eigentliche Gewinn kommt nicht durch Zeitersparnis beim ersten Lauf, sondern dadurch, dass der zweite, dritte und hundertste Lauf identisch abläuft.

Team bespricht eine Deployment-Pipeline an einem großen Monitor
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum der Einstieg oft an der falschen Stelle hakt

Der typische Ausgangspunkt sieht so aus: Es gibt eine Handvoll gewachsener Shell-Skripte, ein paar Notizen im Wiki und viel Wissen in den Köpfen. Solange es zehn Server sind, funktioniert das. Sobald Staging und Produktion auseinanderlaufen, ein Paket auf drei von zwanzig Maschinen fehlt oder ein neuer Kollege eine Installation nachvollziehen soll, wird aus fehlender Dokumentation ein Betriebsrisiko. Genau an dieser Stelle wird Configuration Management interessant, und Ansible ist der Einstieg mit der geringsten Hürde, weil es agentenlos über SSH arbeitet und auf den Zielsystemen im Wesentlichen nur einen Python-Interpreter voraussetzt.

Die zweite Hürde ist mental. Viele Admins verschieben den Einstieg, weil sie annehmen, sie müssten erst Python lernen. Das ist ein Missverständnis: Module wie package, service, copy, template, user oder lineinfile sind fertig, du beschreibst in YAML nur den gewünschten Zielzustand. Python brauchst du erst, wenn du eigene Module schreibst, und das ist im Betriebsalltag die Ausnahme. Wer als Admin systemd, Paketverwaltung und Dateirechte versteht, bringt das eigentliche Fachwissen bereits mit.

Typische Anfängerfehler sind dafür recht gut vorhersehbar. Playbooks werden als Skript gedacht und mit command oder shell vollgestopft, statt idempotente Module zu nutzen. Alles landet in einer einzigen langen Datei ohne Rollen. Variablen werden über group_vars, host_vars und Playbook-Definitionen verstreut, bis niemand mehr die Präzedenz nachvollzieht. Und Zugangsdaten liegen im Klartext im Repository, obwohl Ansible Vault genau dafür da ist. Diese Muster lassen sich vermeiden, wenn man sie von Anfang an kennt.

Miniatur-Szene: Endlosschleife als Bahn mit Stationen für Build, Test und Deployment, am Ende eine startende Rakete

Vom Handbetrieb zum automatisierten Zielzustand

  1. 01 Control Node und SSH-Key-Auth
  2. 02 Inventory und Gruppen
  3. 03 Ad-hoc-Module testen
  4. 04 Playbook in YAML
  5. 05 Rollen, Variablen, Vault
  6. 06 Check-Mode, Lint, Pipeline
Was du mitnimmst

So sieht ein sauberer Einstieg konkret aus

Du brauchst keinen großen Rollout-Plan, sondern einen kleinen, ehrlichen Anwendungsfall und die richtige Reihenfolge. Die folgenden Schritte bilden den Weg ab, den wir auch in unseren Ansible-Kursen gehen.

Control Node und Inventory aufsetzen

Ansible wird nur auf einer Maschine installiert, von der aus du dich per SSH mit Key-Authentifizierung auf die Ziele verbindest. Das Inventory beschreibt, welche Hosts es gibt und wie sie gruppiert sind, als INI- oder YAML-Datei zum Start und später dynamisch aus CMDB, Cloud-API oder Virtualisierung. Mit ansible all -m ping prüfst du, ob Verbindung und Python-Interpreter auf den Zielen stimmen.

Ad-hoc-Befehle vor dem ersten Playbook

Bevor du YAML schreibst, lohnt sich die Kommandozeile. Aufrufe wie ansible webserver -m package -a "name=nginx state=present" -b zeigen unmittelbar, wie Module, Argumente und Privilege Escalation zusammenspielen. Wer diese Denkweise verstanden hat, liest Playbooks danach deutlich flüssiger.

Idempotenz als Grundprinzip verstehen

Ein Task beschreibt keinen Vorgang, sondern einen Zielzustand. Beim zweiten Lauf meldet Ansible ok statt changed, weil nichts mehr zu tun ist. Deshalb sind package, service oder template den Aufrufen über shell vorzuziehen. Wo du doch einen Befehl absetzen musst, sichern creates, removes oder changed_when die Wiederholbarkeit ab.

Playbooks strukturieren und in Rollen zerlegen

Ein Playbook ordnet Plays einer Hostgruppe zu und ruft Tasks, Handler und Variablen auf. Sobald mehr als ein Dienst dazukommt, ziehst du wiederkehrende Logik in Rollen mit der üblichen Struktur aus tasks, handlers, templates, defaults und vars. Tags und --limit halten die Läufe auch in größeren Umgebungen beherrschbar.

Variablen, Templates und Geheimnisse trennen

Umgebungsspezifisches gehört in group_vars und host_vars, nicht in die Tasks. Konfigurationsdateien erzeugst du aus Jinja2-Templates mit Fakten aus ansible_facts, etwa Hostname, Adressen oder Distribution. Passwörter, Tokens und private Schlüssel verschlüsselst du mit Ansible Vault, damit das Repository unbedenklich bleibt.

Absichern, testen und in den Betrieb bringen

Mit --check und --diff siehst du vor dem Schreibzugriff, was sich ändern würde. ansible-lint fängt typische Fehler früh ab, eine Testumgebung in Vagrant oder in Containern erspart Überraschungen in der Produktion. Danach folgt der Schritt in die Pipeline, damit Playbooks aus Git heraus laufen und nicht vom Laptop.

Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Gut zu wissen

Häufige Fragen zu Ansible-Grundlagen

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Brauche ich Python-Kenntnisse, um mit Ansible zu arbeiten?
Für den normalen Betrieb nicht. Du beschreibst den gewünschten Zustand in YAML und nutzt dafür mitgelieferte Module, Python läuft nur im Hintergrund auf Control Node und Zielsystem. Relevant wird Python erst, wenn du eigene Module oder Plugins entwickelst, und das ist in der Systemadministration eher die Ausnahme.
Was ist der Unterschied zwischen Playbook, Rolle und Collection?
Ein Playbook ist die ausführbare Datei, die Hostgruppen und Tasks miteinander verbindet. Eine Rolle bündelt wiederverwendbare Tasks, Handler, Templates und Standardvariablen in einer festen Verzeichnisstruktur. Eine Collection ist die Verteilform darüber und liefert Rollen, Module und Plugins gemeinsam aus, etwa über Ansible Galaxy oder den Automation Hub.
Ersetzt Ansible meine bestehenden Bash-Skripte komplett?
Nein, und das ist auch nicht das Ziel. Für einmalige Ad-hoc-Aufgaben, schnelle Auswertungen oder lokale Hilfsfunktionen bleibt die Shell das passende Werkzeug. Ansible spielt seine Stärke dort aus, wo ein Zustand über viele Systeme hinweg reproduzierbar hergestellt werden soll. In der Praxis existieren beide Ansätze nebeneinander, oft ruft eine Rolle sogar ein bestehendes Skript kontrolliert auf.
Wie viel Vorwissen brauche ich für einen Ansible-Kurs?
Sinnvoll ist solide Linux-Administrationserfahrung: Paketverwaltung, systemd, Dateirechte, SSH und ein Grundverständnis der YAML-Syntax. Wer dort noch unsicher ist, startet besser mit einem Linux-Grundkurs oder mit dem Kompaktkurs Linux Systemadministration und Shell-Scripting und kommt danach zu Ansible.
Welcher cmt-Kurs passt zu welchem Ausgangspunkt?
Der Ansible Kompaktkurs ist der distributionsneutrale Einstieg für Admins, die zügig zu eigenen Playbooks kommen wollen. Configuration Management und Service Operations mit Ansible legt den Schwerpunkt stärker auf den laufenden Betrieb. Wer in einer Red-Hat-Landschaft arbeitet und auf eine Zertifizierung zusteuert, ist mit Red Hat Enterprise Linux Automation with Ansible richtig. Sind bereits Playbooks im Einsatz und die Struktur wird unübersichtlich, hilft Ansible für Fortgeschrittene weiter.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Rückmeldung aus dem Kurs „Ansible Kompaktkurs“
Gut vorbereitete professionelle Vermittlung der komplexen Inhalte innerhalb von nur drei Tagen.
Rückmeldung aus dem Kurs „Docker Grundkurs für Einsteiger“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Steig strukturiert in Ansible ein

In unseren Ansible-Trainings arbeitest du an eigenen Übungssystemen und schreibst vom ersten Tag an Inventories, Playbooks und Rollen, die du anschließend direkt weiterverwenden kannst. Die Termine finden vor Ort oder Live-Online statt. Wenn du unsicher bist, welcher Kurs zu deiner Umgebung und deinem Kenntnisstand passt, melde dich einfach bei uns, wir ordnen das gemeinsam ein.